| 1 |
Alan McKinnon wrote: |
| 2 |
|
| 3 |
> As I see it, at the bottom of the stack you have a kernel and at the top a |
| 4 |
> user space app (the X server will do for an example). Plug in a USB device |
| 5 |
> that the app can use, and the kernel needs to make a node in /dev for it if |
| 6 |
> it's not already there. The kernel should not be interrogating the device for |
| 7 |
> all possible info - that is expensive - and doesn't need to. It only needs |
| 8 |
> enough info to know what driver, major and minor numbers to use. X OTOH, can |
| 9 |
|
| 10 |
I couldn't agree more. And this is what Udev, as a user space app, does. |
| 11 |
The only thing it doesn't handle is communicating with other user space |
| 12 |
apps; this is currently Hals job. |
| 13 |
|
| 14 |
> the current model uses udev as the interface to the kernel's nodes and HAL as |
| 15 |
> the interface to exactly what hardware you have. Seems pretty sane for the |
| 16 |
> most usual use case. At some point in the stack you will need the OS-dependant |
| 17 |
> part, my guess is the best place is between hal and udev. Only Linux uses |
| 18 |
|
| 19 |
Well, as I understand it this is what it looks like today: |
| 20 |
|
| 21 |
kernel <-> udev (or equivalent for non-linux kernel/OS) <-> hal <-> dbus |
| 22 |
<-> user apps |
| 23 |
|
| 24 |
To me that seems a bit redundant... |
| 25 |
|
| 26 |
What I would like to see: |
| 27 |
|
| 28 |
kernel <-> udev <-> user apps |
| 29 |
|
| 30 |
Or at the most: |
| 31 |
|
| 32 |
kernel <-> udev <-> daemon <-> user apps. |
| 33 |
|
| 34 |
> udev, but all OSes use something in that spot. And if not, they have static |
| 35 |
> nodes. |
| 36 |
|
| 37 |
Yes, but if the developers could agree on a common API for the udev |
| 38 |
daemon and it's equivalents on other platforms (what does BSD use?)... |
| 39 |
Or if they could agree on using "Hal v2" (rewritten from scratch with no |
| 40 |
or a minimum of dependencies). |
| 41 |
|
| 42 |
> Meanwhile we have an acknowledged problem with hal - it's too complex, too |
| 43 |
> many things have been shoved into it that were never catered for in the |
| 44 |
> design, configuration is horrific - and the devs are having their usual |
| 45 |
> spirited debate about how best to approach a solution. This is perfectly |
| 46 |
> normal and perfectly healthy |
| 47 |
|
| 48 |
Yes, I guess so. Since I'm (currently) not in the position to help out |
| 49 |
I'll have to live with whatever they come up with. But sometimes it's a |
| 50 |
bit frustrating... Sorry for the ranting. |
| 51 |
|
| 52 |
Best regards |
| 53 |
|
| 54 |
Peter K |
Archives