From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Zeuthen Date: Sun, 21 Sep 2003 20:56:26 +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 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