Jeff Garzik <[EMAIL PROTECTED]> writes: > OSKit is indeed pretty neat. I would try to avoid using linux drivers > unless forced to, though. elfBIOS needs a far more simple driver > API... something akin to linux 2.2 or 2.0 driver api, if even that > complex. Coming from the hacking-on-Linux-drivers perspective, I still > maintain there is much bloat that is not needed here (but needed in a > normal driver)
Oh I agree that there is a fair amount of unncessary bloat. A simplified version of the 2.4.x api is more what we are looking for though. We need the PnP, and modular enhancements that came with 2.4.x. Code being self contained. Code being auto selected because of it's device ID. The linuxbios core can trivially export enough information that the onboard devices can be found in a pnp way. And I have a strange suspicion that we made to go to 2.5.x for a clean block driver template. But no we don't need the locking, irq handling or high performance features of 2.4.x's APIs. Just the high maintainable features. What using linux drivers gets you is something you can get working when are under a deadline crunch, or you don't have a driver writier handy. But you do have someone who knows enough to compile a kernel and do cp /usr/src/linux/drivers/net/eepr100.c /usr/src/oskit/linux/src/drivers/net configure. make blah. At this point I much more like the idea of oskit than the oskit code. A set of libraries that provides device driver functionaly and let's you build your os/bootloader however you need is to very attractive. I already have etherboot as a benchmak on the low end that can provide a standalone network bootloader with one driver in 16KB. There is a minor premium for being that small though. When you have other priorities the other drivers tend not to get written. Now if you are volunteering to write up all the drivers we need in a month for each kind of driver. A month for scsi a month for network etc. I can give up on the linux kernel driver framework. But otherwise I need a solution for the less talented, and more time constrained. A set of GPL'd libraries for standalone applications, that optionally can use linux or BSD drivers looks like a good start. Eric
