From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Thu, 18 Sep 2003 17:36:35 +0000 Subject: Re: Hardware Abstraction Layer Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Thu, Sep 18, 2003 at 01:24:39PM +0200, David Zeuthen wrote: > On Thu, 2003-09-18 at 02:29, Greg KH wrote: > > On Wed, Sep 17, 2003 at 02:40:12AM +0200, David Zeuthen wrote: > > > On Tue, 2003-09-16 at 18:39, Greg KH wrote: > > > > On Sat, Sep 13, 2003 at 03:30:38PM +0200, David Zeuthen wrote: > > > > > Hi, > > > > > > > > > > I'm currently working on a hardware abstraction layer, see > > > > > > > > > > http://pdx.freedesktop.org/~hal/ > > > > > > > > > > for use in desktop environments such as GNOME or KDE. The HAL project > > > > > is in it's early stages - there is a draft spec planned and I got an > > > > > implementation running as well. > > > > > > > > How does this differ from D-BUS? Hm, in looking at your page, it says > > > > you are using D-BUS messages. > > > > > > I use D-BUS as the IPC mechanism between hotplug agents and applications > > > wanting to query a device database. In the middle there is a daemon. > > > > > > In a sense I want the entire HAL not to care about specific hardware > > > issues at all, but build on existing software like linux-hotplug ;-) > > > (see my recent post to the xdg-list for detail) > > > > Hm, in looking over your post I think you are going to be duplicating a > > lot of existing information that is dynamically available to you from > > the kernel. > > > > I see your point. You specifically mention the word ''post'', so I'll > assume that you are talking about my initial message to the xdg-list. > This post mentions both ''drivers'' and ''kernel modules'', which I > admit is confusing. Yes, that is what I was referring to. > In the latest version, available at the link above, I specifically avoid > using these words and only talk about ''device info files'' and ''boot > programs''. > > The contention is that properties for a device should contain a) > bus-device-specific properties (such as usb.idVendor, usb.bcdDevice, > usb.linux_devfs etc.) and category-specific properties (such as > Storage.Device=/dev/sda1 and Storage.MountPoint=/mnt/flash). But my main point is, why store this info anywhere, when it is already stored on your machine today? And it is automatically already handled properly today, without any need for "yet another abstraction layer" to handle it? Yes, I know this only works on Linux, and you want to be "cross-platform". Might I suggest you get the other OSs that you want to support to also support what Linux already does, instead of trying to duplicate work? Oh, what oses are you wanting to support? I think FreeBSD already handles much of what Linux does, with it's devfs implementation, but I haven't looked at that in a long time to verify this. > Applications of the HAL (e.g. desktop environments) will then use > standard kernel and OS interfaces to e.g. display the amount of free > space on a Storage device. > > I hope this clear matters up? Not really. I'm getting the impression that you don't realize the current state of Linux and how hotplugging and driver loading and device naming currently works. A lot of what you are saying you want to do, already works today. The only "major" piece that is missing, is what udev is working on solving (the persistant device naming issue.) Now I agree that udev and the hotplug scripts, and the raw hotplug events should get sent using dbus events, but I was thinking that userspace programs (like GNOME and KDE) that cared about those events would be listening for them. I didn't think there needed to be a whole intermediate layer for these messages to have to go through. But hey, I'm probably missing something big here :) > > For example, the kernel already knows what USB devices are supported by > > what drivers. It exports that info to userspace in the modules.*map > > files in /lib/modules// > > > > The existing hotplug scripts already handle the mapping from device to > > driver, so you don't need to duplicate that functionaity. > > You are right. Note that the HAL needs to be kernel / OS agnostic but > the idea is to handle this at the device-info level. So, for Linux the > BootProgram for a storage-device simply mounts the device somewhere > chosen by the user or the desktop environment. On other OS'es the > bootprogram may need to insert modules or whatever into a running > kernel. > > This implies that, for instance, /etc/hotplug/usb.hotplug will need to > send a DBUS message *after* the kernel modules have been successfully > loaded - see proposal below. That's fine. > Side question: If a device vendor ships a (kernel) driver for his USB > device will modules.*map get updated? Side question to your side question: What device vendor ships kernel drivers for USB devices? :) Anyway, yes, it will get updated, next boot time when depmod is run. Actually in 2.6, those files are not needed at all, and people activly want to get rid of them. And I agree with them, it's just that the current hotplug scripts rely too much on them at this time... They should be rewritten as to not need them at all. So be aware that they might go away in the future. > > > > Also, D-BUS messages will be > > > > created for all /sbin/hotplug events too. You might want to work with > > > > that if it's easier for you. > > > > > > > > > > I'll be interested in this, definately. Are you using the service > > > org.freedesktop.DBus.Broadcast for this? > > > > I'm not using anything :) > > > > There was a simple command line program that generated dbus messages. > > Someone needs to take that and have it convert hotplug messages into > > dbus messages. I think it's going to use the org.kernel namespace. > > > > My initial experiments was actually to patch /etc/hotplug/usb.hotplug > and used the same command-line tool. The tool is a bit weak still (but > DBUS is not at 1.0 yet) in so far that obvious data-types like > dictionaries are not available yet. Now I just have a hackish C program > using libdbus to parse the environment given from the kernel and send it > off to the HAL daemon. Nice. > IMHO, the best possible scenario for HAL (wrt. hotplugging) would be to > have a well-defined DBUS message scheme for each bus type and > linux-hotplug to implement this broadcasting it through the service > org.freedesktop.DBus.Broadcast. Hm, why that address? I thought the org.kernel namespace was going to be reserved for these types of messages. Ah, but the org.kernel name should be used for "raw" hotplug events (which some people might want to listen for). Ok, I understand now. > Data in these messages would contain the usb.* fields and information > about what (linux) kernel modules was loaded if any (cannot find device > driver etc.). Why would loading a new driver really be of any interest to anyone? Userspace can't do anything with that. Userspace can only interact with /dev nodes. But I can understand that if no driver is found for a device, that would be useful. Also remember that not all USB devices use kernel drivers (like all of the cameras that use libusb and gphoto2 to talk to devices, there is no kernel driver in use there.) > If there is not a well-defined scheme yet, I'll volunteer to write a > spec and implement it as part of linux-hotplug. We can put this spec at > either the HAL site or the linux-hotplug site. The former would IMHO be > better since we want the scheme to be OS agnostic, but I'm flexible. I'm > quite certain the scheme, to an extent, can be OS agnostic. > > What is your take on this? I think I need to see your spec first :) > > > In the event this is not possible the hotplug agent must somehow convey > > > this information so I can append a counter to make the ID unique in that > > > way.. > > > > The kernel will tell you that this is a new device. It's up to > > userspace to do something with that info. udev will determine the /dev > > name for the device. It's up to other programs to do other things with > > this info (which is what I'm thinking your proposal does, correct?) > > > > Ok, the HAL daemon can take care of this as long as we agree on the DBUS > message format. HAL is strictly user-space. So is udev. And yes, I have no problem agreeing on the dbus message format. 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