Re: Hardware Abstraction Layer

[David Zeuthen <david@fubar.dk>]

On Sat, 2003-09-20 at 02:17, Greg KH wrote:
> Well, welcome.  Looking forward to a working implementation :)
> 

Thanks! I hope not to be too far away from some proof of concept
hot-pluggable usb storage. Only hotplug and device info stuff is
missing.. All the other stuff seem stable enough now.. (stable, but not
exactly production quality yet)

> >  2. Having a single device info file concept that OEM's ship with
> >     their devices. This device info file should cover most popular 
> >     distros and OS'es and versions thereof.
> >     It should specify what the device is and what the user needs
> >     to do in order to interact with it. In order to match a device
> >     do this it need specifics of the hardware like usb.idVendor etc.
> 
> This might be much more difficult due to the ways different OSs
> implement different device support.  But hey, it's good to have dreams.
> 

It sure is :-)

In fact, I think it need not be too difficult - remember the HAL I'm
working on is essentially just a database of information (and links to
information) plus some well-defined properties that makes sense for many
OS'es. Plus some rules on what happens when properties change due to
external events such as hot-plugging or desktop application interaction.

For, e.g., a storage device to be usable, some existing software below
my HAL would have to mount into the file system.. We even have to assume
a file system that you can mount stuff into. I just want a device info
file format that allow people to do this in different ways for different
OS'es by specifying how and where to mount it in an OS-neutral way.

(assuming we also do device interfaces, similar nice stories for other
categories of devices can be made)

Plus, having device info files, the OEM can tweak, he can put in
properties about addresses for tech support, logo to display etc. This
will make us appear a little bit more OEM friendly. (I know that Windows
support this)

The big question that remains, is really who's life we are going to make
easier or harder? the app developers, the users, the kernel people, the
OEM's or the device library people? I don't think necessarily everyone
can win.. And we need adoption from most, if not all, of these people..

So, yeah, it's going to be very difficult. (I'm done rambling now :-))

> >  3. Provide some place where user-made settings are stored and persisted
> >     for a device. For instance UI-things like device name, where to
> >     mount a storage device and with what options (storage only readable
> >     by the user or not etc.). 
> 
> Some of that will be taken care of in udev for Linux.  But others (like
> where to mount the device) would be up to you.
> 

Yes. I did install 2.6.0-test5 over the weekend and played around with
udev 0.2, /sys and libsysfs + tools. It seems udev can't handle USB
storage devices yet? It didn't worked for me at least.

Side question: Is it really true that the only way to obtain where the
SCSI subsystem mounts the usb-storage is by inspecting /var/log/messages
on 2.4? I couldn't find anything on 2.5/2.6 through googling either...
It's very frustrating

Further, and this is because I known little or nothing of Linux kernel
programming, /sys seems a little intimidating (but very cool - I looked
at it in awe for over an hour).

So, what is your opinion on this: I plan, for some devices, to have
well-defined properties (that makes sense on other OS'es also) that is
dynamically retrieved from well-known sources such as /sys or /proc. 

An obvious example is the CPU-frequency for a CPU device - ya know,
stuff that desktop application programmers like to use but a) is quite
difficult and a pain to obtain (parsing /proc/cpuinfo); and b) varies
over a lot of OS'es. So in this example, when the laptop user
disconnects power and his CPU slows down, the property
CPU.ClockFrequency is automatically updated and the desktop application
will be notified. Another example might be free space for storage
devices.
(Just to stress it, the keyword here is linking rather than duplication,
which I why I'd like your opinion.)

More on udev: how will it fit with the linux-hotplug project?

Maybe it's already there, but it could be nice to have a set of
prioritized hotplug scripts that is invoked a'la /etc/init.d.. So one
for loading a kernel module, udev for naming the device and one for
sending a D-BUS message, notifying, among others, the HAL. In the chain
of invoking these, the environment would grow. 

While we're on the topic, I'll look into the D-BUS messages I'd like
from hot-plugging. Will send a proposal one of these days. Since D-BUS
is a moving target, we'll probably have to change it at some point
though.

Thanks,
David




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel