Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5

[Alan McKinnon <alan.mckinnon@gmail.com>]

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 :-)

> Or at the most:
>
> kernel <-> udev <-> daemon <-> user apps.

But you have that in the current setup. Hal (for better or worse) is the 
daemon. dbus is simply a message transport and can be omitted from the 
conceptual diagram

> > udev, but all OSes use something in that spot. And if not, they have
> > static nodes.
>
> 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?)...
> Or if they could agree on using "Hal v2" (rewritten from scratch with no
> or a minimum of dependencies).

I don't think that's feasible. Easiest would be the bottom layer of hal has 
OS-specific code to talk to udev (or it's equivalent in other OSes). Or 
perhaps a plugin/module type system. 

> > Meanwhile we have an acknowledged problem with hal - it's too complex,
> > too many things have been shoved into it that were never catered for in
> > the design, configuration is horrific - and the devs are having their
> > usual spirited debate about how best to approach a solution. This is
> > perfectly normal and perfectly healthy
>
> Yes, I guess so. Since I'm (currently) not in the position to help out
> I'll have to live with whatever they come up with. But sometimes it's a
> bit frustrating... Sorry for the ranting.

Hey, it could be worse.

You could be forced to use Windows...


-- 
alan dot mckinnon at gmail dot com