1 |
On Saturday 16 May 2009 19:14:17 pk wrote: |
2 |
> Alan McKinnon wrote: |
3 |
> > I'm not sure who's criticizing DeviceKit, but it isn't me :-) |
4 |
> |
5 |
> I guess it was me... :-) |
6 |
> |
7 |
> I find this thread interesting: |
8 |
> http://lists.freedesktop.org/archives/xorg/2009-May/045561.html |
9 |
> |
10 |
> ...especially this: |
11 |
> http://lists.freedesktop.org/archives/xorg/2009-May/045574.html |
12 |
> |
13 |
> Which seems like a much more sane way... to me. I don't know what BSD |
14 |
> and other platforms use (instead of Udev) but I'm sure one could come up |
15 |
> with a common API. |
16 |
|
17 |
Sometimes you have to make several horrendous errors to know what to not do |
18 |
and thereby deduce what you should do - the only version 3 rule of thumb :-) |
19 |
|
20 |
From threads involving the hal maintainers I get the idea that the problem is |
21 |
not so much the idea of hal, but rather it's implementation. And then there's |
22 |
those fdi files... |
23 |
|
24 |
As I see it, at the bottom of the stack you have a kernel and at the top a |
25 |
user space app (the X server will do for an example). Plug in a USB device |
26 |
that the app can use, and the kernel needs to make a node in /dev for it if |
27 |
it's not already there. The kernel should not be interrogating the device for |
28 |
all possible info - that is expensive - and doesn't need to. It only needs |
29 |
enough info to know what driver, major and minor numbers to use. X OTOH, can |
30 |
successfully use much more info. If you have a 19 button mouse, it would like |
31 |
to know and could even use it as a one-handed keyboard (extreme example). So |
32 |
the current model uses udev as the interface to the kernel's nodes and HAL as |
33 |
the interface to exactly what hardware you have. Seems pretty sane for the |
34 |
most usual use case. At some point in the stack you will need the OS-dependant |
35 |
part, my guess is the best place is between hal and udev. Only Linux uses |
36 |
udev, but all OSes use something in that spot. And if not, they have static |
37 |
nodes. |
38 |
|
39 |
Meanwhile we have an acknowledged problem with hal - it's too complex, too |
40 |
many things have been shoved into it that were never catered for in the |
41 |
design, configuration is horrific - and the devs are having their usual |
42 |
spirited debate about how best to approach a solution. This is perfectly |
43 |
normal and perfectly healthy |
44 |
|
45 |
-- |
46 |
alan dot mckinnon at gmail dot com |