- A hozzászóláshoz be kell jelentkezni
- 2587 megtekintés
Hozzászólások
Azért kiváncsi lennék, hogy valójában mennyire systemd nyomásra került be.
A bejelentés eléggé kerülgeti, de azért az egyértelmű utalások megvannak:
- "hundreds of thousands of messages passed at _boot time_"
- "benefit of having this in the kernel, rather than as a userspace daemon, is that you can now easily use the bus from the initrd, or up to the very end when the system shuts down"
...
Hát ez meg... "Some "crazy" people are playing with using kdbus for audio data in the system."
Vajon kire utalhat az a "crazy" people?! Hadd találjam ki...
És igen.
Természetesen.
Ki más is lehetett volna... Ááá túl könnyű volt.
---
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Regarding binder: binder and kdbus follow very different design concepts. Binder implies the use of thread-pools to dispatch incoming method calls. This is a very efficient scheme, and completely natural in programming languages like Java. On most Linux programs, however, there's a much stronger focus on central poll() loops that dispatch all sources a program cares about. kdbus is much more usable in such environments, as it doesn't enforce a threading model, and it is happy with serialized dispatching. In fact, this major difference had an effect on much of the design decisions: binder does not guarantee global message ordering due to the parallel dispatching in the thread-pools, but kdbus does. Moreover, there's also a difference in the way message handling. In kdbus, every message is basically taken and dispatched as one blob, while in binder, continious connections to other peers are created, which are then used to send messages on. Hence, the models are quite different, and they serve different needs. I believe that the D-Bus/kdbus model is more compatible and friendly with how Linux programs are usually implemented.
Ennek most örülnünk kéne?
- A hozzászóláshoz be kell jelentkezni