From mboxrd@z Thu Jan 1 00:00:00 1970 From: Havoc Pennington Date: Thu, 18 Sep 2003 18:30:40 +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, 2003-09-18 at 13:36, Greg KH wrote: > But my main point is, why store this info anywhere, when it is already > stored on your machine today? Keep in mind the original proposal at http://ometer.com/hardware.html which is that the HAL _merges_ information from various sources into a single list/tree of devices, and property set for each device. So we may read some stuff from the USB hardware itself, then add some info provided by the kernel, then add some metadata from some systemwide files, then add some data that has been obtained by the desktop and stored per-user, then look at some blacklist, and finally we have a complete picture of everything known about that particular device. But the exact set of things merged varies by device. The suggestion someone else posted about having "interfaces" is interesting in this respect. One point of the HAL is to abstract where this information is coming from. Each info source is part of the "backend" not the application-visible API. > And it is automatically already handled > properly today, without any need for "yet another abstraction layer" to > handle it? Things aren't handled properly today in the sense that there's no UI on it, there's no integration with applications. To add that on the desktop/app level, we first have to have a single API that will work with different kinds of device and on different operating systems. One principle to keep in mind is: application code should not know the details of specific devices. If I add a new device model, apps should automatically use it. Ideally, I can even add a new kind of bus and apps can use devices on that bus; e.g. an app doesn't care if a scanner is SCSI or USB. >From an OEM standpoint, if I submit a patch to one or a small well-defined set of projects, then my device should get used by all the interesting apps. You may be lumping all userspace code together. Remember that the main desktop apps are built on dozens of libraries, all with opaque long-term-frozen ABIs that create additional abstraction layers. > 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? That doesn't help, unless the other OSs have _exactly_ the same filenames, interfaces, executables, and all other details. If there's _any_ difference between any interesting versions of Linux and any interesting versions of any other kernel, then we have to have the abstraction barrier. Apps can't contain #ifdef hell, it's not practical. App authors know _nothing_ about any specific hardware models or buses, and understand a single OS if that. They are on the level of "list the cameras, get the pictures from each" Interesting kernels at the moment seem to be Solaris, Linux, and *BSD including Darwin primarily. I don't see coordinating exact interfaces between those as practical. If it is practical, it definitely involves writing a spec for what the interfaces are, and a conformance suite, and committing to maintaining spec conformance over time. I haven't seen anything like this for the Linux stuff yet. ;-) > 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. Isn't devfs a device naming solution? HAL really has little or nothing to do with device naming; from an app standpoint I don't think we care at all what's in /dev other than being able to find out what to use in there, see the "implementation goals" point #2 in http://ometer.com/hardware.html Think of it this way: it's a bug if we have a field in the UI like: Device Node: [ /dev/foo ] that the user has to fill in. Sometimes we might have to do it, but it's a UI bug for the OS/desktop combo as a whole system. Instead the UI should be: Cameras: [x] Minolta XYZ [ ] Canon where those may be on different buses/kernel subsystems. > 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 :) Possibly you're expecting apps to understand the specifics of each kernel subsystem (USB, etc.) and have significant Linux-specific code. That's not feasible from the GNOME/KDE/OpenOffice.org/Mozilla/etc. standpoint. To the user we display "here are your cameras"; and at some level there has to be an abstraction layer that puts things on the level of "cameras" not "USB devices" - that layer needs to be below the application, so that all apps have the same list of cameras. (Cameras are just an example of course.) The motivation is partly portability, and partly simply shielding app developers from having to have a deep understanding of hardware in order to write the UI for it. App developers _won't_ have such an understanding, so if they have to, not much UI will happen. Another angle on the motivation is the OEM one, allowing hardware to just drop in and work after I bought it at the store, at least when possible (e.g. the kernel driver is a generic one). Maybe the most important motivation is getting the UI right, which requires us to know as much as we can about each device. > 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. If you have a device and you don't know which driver to use, the desktop could ask the user which driver to use. Also, if I'm an OEM and I know my device works with a standard Linux driver, but that some deployed kernels won't know that, I could ideally ship the information in a little file of some kind for the user to install. > But I can understand that if no driver is found for a device, that would > be useful. Right. > 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.) Right, this is another reason to have the HAL. Apps do not want to sort out all this which-device-uses-what stuff. They want to get a list of cameras, then pass a camera in to a camera API (e.g. gphoto) that magically gets the photos. And nobody wants to know what kind of plug is on the camera or who implemented the driver where. ;-) Hopefully this mail helps clarify some of the goals. To use hardware effectively, apps need to have a hard dependency on an ABI for doing so. Hard deps must be portable and well-encapsulated/well-defined in terms of the semantics/ABI exported. Below this abstraction barrier, the various OS-specific stuff would be hooked in. So "HAL" essentially just means "the project that contains the abstraction barrier, and chains out to the per-OS per-device-model implementations" - my writeup has one speculation on what this project should look like, but I won't pretend to know for sure. Havoc ------------------------------------------------------- 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