Re: Hardware Abstraction Layer

[Greg KH <greg@kroah.com>]

On Sun, Sep 21, 2003 at 10:56:26PM +0200, David Zeuthen wrote:
> 
> 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..

The users are the most important ones here.

> > >  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.

Should work just fine.  They show up as block devices, just like any
other disk (look in /sys/block).  My demo at OLS 2003 used my usb camera
which is a usb storage device.

> 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

Don't remember, sorry.  There are a bunch of different scsi programs for
doing this.  Search the linux-scsi archives for links to them.

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

Heh, thanks.  It's pretty impressive to finally see all of those links
that were always internal to the kernel.

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

I think there's already a user library to get the cpu frequency stuff
out of /proc or /sys to userspace.  You might want to look into that.

But yes, unifying this for user apps would be a good thing.

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

It uses the hotplug-base package, that's all.

> 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. 

Heh, we already have that.  See the latest release of the linux-hotplug
package :)

thanks,

greg k-h


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