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