| 1 |
On Sunday 17 May 2009 03:33:22 pk wrote: |
| 2 |
> Alan McKinnon wrote: |
| 3 |
> > As I see it, at the bottom of the stack you have a kernel and at the top |
| 4 |
> > a user space app (the X server will do for an example). Plug in a USB |
| 5 |
> > device that the app can use, and the kernel needs to make a node in /dev |
| 6 |
> > for it if it's not already there. The kernel should not be interrogating |
| 7 |
> > the device for all possible info - that is expensive - and doesn't need |
| 8 |
> > to. It only needs enough info to know what driver, major and minor |
| 9 |
> > numbers to use. X OTOH, can |
| 10 |
> |
| 11 |
> I couldn't agree more. And this is what Udev, as a user space app, does. |
| 12 |
> The only thing it doesn't handle is communicating with other user space |
| 13 |
> apps; this is currently Hals job. |
| 14 |
> |
| 15 |
> > the current model uses udev as the interface to the kernel's nodes and |
| 16 |
> > HAL as the interface to exactly what hardware you have. Seems pretty sane |
| 17 |
> > for the most usual use case. At some point in the stack you will need the |
| 18 |
> > OS-dependant part, my guess is the best place is between hal and udev. |
| 19 |
> > Only Linux uses |
| 20 |
> |
| 21 |
> Well, as I understand it this is what it looks like today: |
| 22 |
> |
| 23 |
> kernel <-> udev (or equivalent for non-linux kernel/OS) <-> hal <-> dbus |
| 24 |
> <-> user apps |
| 25 |
> |
| 26 |
> To me that seems a bit redundant... |
| 27 |
|
| 28 |
No, there's nothing redundant in that. udev talks kernel-speak, hal talks |
| 29 |
userspace-speak. Hal could be distro-agnostic, udev can't be (not in a sane |
| 30 |
environment) and dbus is simply a transport layer for messages. That's five |
| 31 |
different functions going on, and none of them logically belong with any other |
| 32 |
in the same layer. |
| 33 |
|
| 34 |
> What I would like to see: |
| 35 |
> |
| 36 |
> kernel <-> udev <-> user apps |
| 37 |
|
| 38 |
Then X must talk to udev directly. Two problems: |
| 39 |
|
| 40 |
- only Linux has udev. Other OSes may not need, want or be willing to touch |
| 41 |
udev with a bargepole. |
| 42 |
- X is multi-platform. Good luck getting Keith to agree to make it essentially |
| 43 |
Linux only :-) |
| 44 |
|
| 45 |
> Or at the most: |
| 46 |
> |
| 47 |
> kernel <-> udev <-> daemon <-> user apps. |
| 48 |
|
| 49 |
But you have that in the current setup. Hal (for better or worse) is the |
| 50 |
daemon. dbus is simply a message transport and can be omitted from the |
| 51 |
conceptual diagram |
| 52 |
|
| 53 |
> > udev, but all OSes use something in that spot. And if not, they have |
| 54 |
> > static nodes. |
| 55 |
> |
| 56 |
> Yes, but if the developers could agree on a common API for the udev |
| 57 |
> daemon and it's equivalents on other platforms (what does BSD use?)... |
| 58 |
> Or if they could agree on using "Hal v2" (rewritten from scratch with no |
| 59 |
> or a minimum of dependencies). |
| 60 |
|
| 61 |
I don't think that's feasible. Easiest would be the bottom layer of hal has |
| 62 |
OS-specific code to talk to udev (or it's equivalent in other OSes). Or |
| 63 |
perhaps a plugin/module type system. |
| 64 |
|
| 65 |
> > Meanwhile we have an acknowledged problem with hal - it's too complex, |
| 66 |
> > too many things have been shoved into it that were never catered for in |
| 67 |
> > the design, configuration is horrific - and the devs are having their |
| 68 |
> > usual spirited debate about how best to approach a solution. This is |
| 69 |
> > perfectly normal and perfectly healthy |
| 70 |
> |
| 71 |
> Yes, I guess so. Since I'm (currently) not in the position to help out |
| 72 |
> I'll have to live with whatever they come up with. But sometimes it's a |
| 73 |
> bit frustrating... Sorry for the ranting. |
| 74 |
|
| 75 |
Hey, it could be worse. |
| 76 |
|
| 77 |
You could be forced to use Windows... |
| 78 |
|
| 79 |
|
| 80 |
-- |
| 81 |
alan dot mckinnon at gmail dot com |
Archives