Date: Sat, 13 Mar 1999 02:50:10 +1300 From: Joe Abley <jabley@clear.co.nz> To: Mike Smith <mike@smith.net.au> Cc: Michael Robinson <robinson@netrinsics.com>, freebsd-mobile@FreeBSD.ORG, jabley@clear.co.nz Subject: Re: compatibility list Message-ID: <19990313025010.C64180@clear.co.nz> In-Reply-To: <199903112018.MAA01000@dingo.cdrom.com>; from Mike Smith on Thu, Mar 11, 1999 at 12:18:05PM -0800 References: <199903111020.SAA06918@netrinsics.com> <199903112018.MAA01000@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 11, 1999 at 12:18:05PM -0800, Mike Smith wrote: > > May I humbly submit that your first (or nearly first) order of business > > should be getting the Cathedral architects to cough up some blueprints, > > so that we mere rockbangers might labor with focus and direction? > > There's a standing offer out whereby we will help fund the exorbitantly > expensive PCCARD documentation for seriously interested parties. I thought that this original message was more in reference to the FreeBSD generic removable device architecture, rather than PCMCIA-specific stuff. I have essentially no experience whatsoever with PC hardware design other than watching kernel boot messages with a slightly perplexed and worried expression, but I take it that a key issue for generic removable devices is that of interrupt probing while the kernel is generally scrabbling for the alarm clock and fumbling about for the first cigarette of the day. I'd just like to get a conceptual picture of what a future design might be as seen from userland -- maybe someone could comment on this? + for busses which are known to support removable devices, there will be an (interrupt-driven, presumably) mechanism for the bus to signal the kernel that a device change has taken place. + in the kernel, the removal of a device will cause the interrupt handling code for that device to be dropped from the list of active interrupt handlers. Kernel calls involving the inactive device will subsequently return errors. + in the kernel, the additional of a device will cause appropriate interrupt handling code to be brought live, and device initialisation code to be executed, as long as support for the device is present (static or KLD). + the kernel will signal userland in some way (like pccardd?) so that userland scripts can react to devices appearing and disappearing. + if a device is inserted for which no driver is currently loaded, the kernel will signal the userland daemon so that (e.g.) a KLD can be located and loaded. Where does the interrupt probing issue come into this? Presumably "busses with removable devices" might be pretty much all of them on a laptop with (e.g.) removable disks, CD-ROM drives, PC cards, etc. Even USB keyboards might be plugged in and pulled out at will. Hot-swap PCI cards would be nice in the machine room, and presumably will come (if they're not here already). Is the idea to treat _all_ busses as potentially supporting nomadic devices, to give maximum genericism? Is there _any_ device that needs to be treated as permenant? If _all_ devices are generically considered removable, does this make a devfs-type scheme more workable? Or were the previous issues with devfs different? "just trying to learn something so I can be more useful in this area" :) Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990313025010.C64180>