| 1 |
On Sonntag 17 Mai 2009, Alan McKinnon wrote: |
| 2 |
> On Sunday 17 May 2009 03:33:22 pk wrote: |
| 3 |
> > Alan McKinnon wrote: |
| 4 |
> > > As I see it, at the bottom of the stack you have a kernel and at the |
| 5 |
> > > top a user space app (the X server will do for an example). Plug in a |
| 6 |
> > > USB device that the app can use, and the kernel needs to make a node in |
| 7 |
> > > /dev for it if it's not already there. The kernel should not be |
| 8 |
> > > interrogating the device for all possible info - that is expensive - |
| 9 |
> > > and doesn't need to. It only needs enough info to know what driver, |
| 10 |
> > > major and minor numbers to use. X OTOH, can |
| 11 |
> > |
| 12 |
> > I couldn't agree more. And this is what Udev, as a user space app, does. |
| 13 |
> > The only thing it doesn't handle is communicating with other user space |
| 14 |
> > apps; this is currently Hals job. |
| 15 |
> > |
| 16 |
> > > the current model uses udev as the interface to the kernel's nodes and |
| 17 |
> > > HAL as the interface to exactly what hardware you have. Seems pretty |
| 18 |
> > > sane for the most usual use case. At some point in the stack you will |
| 19 |
> > > need the OS-dependant part, my guess is the best place is between hal |
| 20 |
> > > and udev. Only Linux uses |
| 21 |
> > |
| 22 |
> > Well, as I understand it this is what it looks like today: |
| 23 |
> > |
| 24 |
> > kernel <-> udev (or equivalent for non-linux kernel/OS) <-> hal <-> dbus |
| 25 |
> > <-> user apps |
| 26 |
> > |
| 27 |
> > To me that seems a bit redundant... |
| 28 |
> |
| 29 |
> No, there's nothing redundant in that. udev talks kernel-speak, hal talks |
| 30 |
> userspace-speak. Hal could be distro-agnostic, udev can't be (not in a sane |
| 31 |
> environment) and dbus is simply a transport layer for messages. That's five |
| 32 |
> different functions going on, and none of them logically belong with any |
| 33 |
> other in the same layer. |
| 34 |
> |
| 35 |
> > What I would like to see: |
| 36 |
> > |
| 37 |
> > kernel <-> udev <-> user apps |
| 38 |
> |
| 39 |
> Then X must talk to udev directly. Two problems: |
| 40 |
> |
| 41 |
> - only Linux has udev. Other OSes may not need, want or be willing to touch |
| 42 |
> udev with a bargepole. |
| 43 |
> - X is multi-platform. Good luck getting Keith to agree to make it |
| 44 |
> essentially Linux only :-) |
| 45 |
|
| 46 |
which is not a problem at all. udev only creates device nodes. There is no |
| 47 |
need to 'talk udev' or do special crap for udev. |
| 48 |
|
| 49 |
> |
| 50 |
> > Yes, but if the developers could agree on a common API for the udev |
| 51 |
> > daemon and it's equivalents on other platforms (what does BSD use?)... |
| 52 |
|
| 53 |
and there already is one. It is called '/dev' |
Archives