The Rot

[Richard Hughes]

On 02/03/07, Martin Owens <doctormo at gmail.com> wrote:
> Greetings All;
>
> Following the recent icons thread I feel compelled to ask the list
> about the direction that HAL is taking. every month I see new things
> being added to HAL that have no baring on providing standard hardware
> interfaces and is moving slowly but surly into the realms of providing
> user information and lots of other indisputably useful features which
> may be clouding the HAL development direction.

Sure, thanks for your mail, it's good to talk about direction.

> As I see it there are the following functional features which would be
> more useful if thought about separately:
>
>  1) To provide a standard way to interface with hardware classes
> through standard methods (HAL, CUPS/gp, Sane)
>  2) To provide dbus messaging for hardware detection and identification (HAL)
>  3) To attach to the identified hardware pertinent information for
> operational performance and usability (HAL)
>  4) To attach to the identified hardware trivial user information for
> user query and visibility (HAL?, Dohickey)
>  5) To aid the software selection and soft-plugging of passive ports
> (Serial, Parallel, Monitor etc) including probing and detection (None
> built to any degree of quality)

Why think about this separately? Surely HAL is just a way of getting
information about the hardware and letting the session interact with
it in a sane way?

It seems quite sane to me to wok out if a usb device is a mobile phone
or a IPod at the hardware abstraction point, not at the desktop, which
should just be a consumer in my opinion.

> If you can identify more single functions do let me know.
>
> So what we have is a number of projects all rolled into one; yes dbus
> is quite cool. yes fdi files are very useful for keeping information;
> but do we really want to keep things like 'names', descriptions,
> pictures, icons and the like in fdi files which are loaded when the
> computer boots and loads hal?

Why not? On embeded we can --configure the options to make hald really
small, and even distributors can patch out parts that they do now want
to ship.

I would much rather see my "usb disk" called "Nokia N800" with the
correct icon, and unless we start to do hardware abstraction (pardon
the pun) in the session then we don't get this.

> it seems keeping the fdi files small
> and well managed may well be a good way to keep hals performance lean
> and keep the project on some sort of track.

Hang on a minute. Rob and myself have been profiling hal pretty hard
the last few months, and with the introduction of the mmap'able cache
and the other fdi speed improvements, we are much better now than we
were, compared to just reading indervidual files. I'm further working
on string compressable cache which will reduce the size of the mmap by
about 80% which is great for small boxes or embedded.

Also, with the splitting of hal-info we can choose what fdi files we
want to install at compile time, saving the need to process the video
resume xml if we are on a low power machine that wakes up fine without
hacks.

> The idea that occurs to me at this juncture is that 1 and 2 above are
> innate, that is to say they are required regardless of the kind of
> device and can provide extensions to other things; 3 can be such an
> extension with a method which returns pertinent information to drivers
> and clients alike; 4 and 5 can also be operated as extensions with
> methods specifically aimed towards getting trivial hardware
> information and getting/setting passive port status/hardware
> identification. this would at least have the effect of keeping all the
> features we all want in a nice clean way without complicating the HAL
> project.

I don't think the HAL project is bloated. I think it's picking up new
features, like per-device ACL's but all these are required for a
proper session experience. And furthermore, they are configurable.

> Please do tell me if I'm talking out of my arse though, it has been known.

No, you are not, it's good to have this sort of discussion.

Richard.