From mboxrd@z Thu Jan 1 00:00:00 1970 From: Havoc Pennington Date: Wed, 01 Oct 2003 01:30:08 +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 Hi, I just learned from a comment on gnomedesktop.org that I missed most of this thread, it landed in the wrong mail folder or something. ;-) On Fri, 2003-09-19 at 20:12, Greg KH wrote: > > 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. > > Hm, for a lot of this a UI isn't needed, right? The user doesn't need > to know that a driver was just automatically loaded for their device, > correct? That's right. The bulk of the UI should be about using devices rather than getting them connected and working. > Again, there are very notable exceptions, the digital cameras supported > by gphoto2 and the USB scanners supported by xsane, both using userspace > only code. I'm just pretty skeptical that something can be created that > would allow OEMs to plop into a userspace location that would enable > device support across multiple operating systems. But please, prove me > wrong, I will be very happy. Ah, I don't really mean that the OEM interface would be OS-independent; either the file plopped would have to contain OS-specific portions, or there would be a per-OS file. That's OK since we can expect an OEM to deal with each OS independently, as they only have 1 device * N OSes. It's the app developers that have to be insulated from M devices * N OSes. The OS independent portion is the part the app sees. Some properties exported by the HAL are probably even OS-specific, but the point is there's an OS-independent core/subset. (i.e. the idea is to let you write portable code, not to keep you from punching down to OS details if you want) > I understand this. The kernel doesn't contain #ifdef hell for that very > reason. But this is my main point as to how this might get very tough > for having cross platform support. The BSDs support lots of USB devices > today in a very different manner than Linux does. I think of it as "portability by subdirectory" ;-) You have an API that apps talk to, and then some generic code, and then a per-OS backend with a subdirectory for each backend: hal/ include/ hal/hal.h generic/ hal.c linux/ usb.c freebsd/ usb.c It isn't so much that the freebsd/ subdir is populated immediately, but rather that when someone appears with the skills and motivation they can add that subdir without having to rearchitect everything. The desktop userspace doesn't have a list of required platforms so much as the requirement that "if someone is actively maintaining a platform they can keep that platform working" > I'm happy to see this work happening, and if there's anything that you > need from the kernel, hotplug scripts, or udev that I can help out with, > please let me know. I really appreciate your interest/help, btw. I'm curious how many iterations of all this we'll go through before we're happy with it. Wait, I've worked on software long enough to know the answer is "infinite"... ;-) 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