> >> yeah, right... then you need an XML parser in the driver... somehow I > >> don't think the kernel people will think it's a good idea... > >=20 > > I agree. KISS. > >=20 > > Peter > > Why in the kernel? A perfect driver can be created from the XML > description in userland, compile & insmod. Well optimized for the given > hw and no overhead implementing support for something what is not in HW > (fpga).
If this is a graphics card, and you are using it as the system console, you need to use it to print info from the firmware, before you have an OS, much less a userland. If you are not using the device as the system console, then the firmware can ignore it. > The driver must be a module (if handles some system level functionality > - e.g. IDE card), but i'll rather want to see it as a library on the top > of some general OGA-PCI driver (for application level - e.g. hw > compression on fpga - that does not need a kernel driver and such things > should not go into kernel). > > I don't think, that the kernel is ready for runtime-reconfigurable hw > (fpga boards), so be open to new ideas ;) Perhaps this could be handled like hotpluggable devices? (SCSI, Firewire, USB, ...) There seems to be a trend towards handling USB devices with a generic device driver and a userland library. This has the advantage of keeping the OS specific device driver smaller. The userland library would be portable across *BSD, Linux, etc. A similar strategy could be useful, here, if it doesn't hurt performance too much. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
