Reduced Development Cycle [LWN.net]

Reduced Development Cycle

Posted Aug 30, 2002 1:54 UTC (Fri) by mmarq (guest, #2332)
In reply to: initramfs status? by cpeterso
Parent article: The 2.5 device model

Maybe I'm wrong, but I belive the main reason, beside of cleaning a lot of hairy and or duplicated code, is really to get all code related to device_drivers out of Kernel "core". In the end I belive we would't have a HAL(hardware abstraction layer), but something more flexible and sligthly resembling the I2O model. Of course this would't be 2.6, but there's an obvious advantage of having a completely separeted kernel development and device_driver development, that could translate in a global development cycle of about 1 year, half of what is today.

It would even more wonderful, if it somehow could reach compatibility at the device_driver level wiht the I2O model.Because it will mean a lot faster asyncronous I/O (and syncronous), solve for good the proprietary device_driver problem, and set the standard for a Unix like device driver model that definitely breaks the MS grasp on the x86 platform (same hardware_driver could run everywhere: Linux, Solaris, MacOSX...X86, spark, ppc...it only neds a recompile). Maybe this is not so stupid and in the clouds, as it sounds; a lot in Patrick Mochel device model could be tweaked that way, missing a little more will and imagination!!

(Log in to post comments)

Reduced Development Cycle

Posted Aug 30, 2002 8:50 UTC (Fri) by mmarq (guest, #2332) [Link]

A crazy idea!!!

Following the description of the driver model in this article, why not instead of a "struct device_driver, which is registered for each driver in the system" we could have a " pool of stackable struct device_drivers-one for each class of drivers in the system, which are (pool) registered for each driver in the system. This poll, individualy and or as a whole, could provide not only the "probe" function and others of this driver model, but most of all, every other functions allowing it to function as the middle communication layer of the split driver model of I2O(http://www.intelligent-io.com/specs_resources/V2.0_spec.pdf.

It dosent have to follow the intire V2.0_spec, and could even be more flexible and simple in lots of aspects. The main point here is to provide a way, par exemple, for a ethernet_board_driver talk directly to a sound_board_driver or a graphics_board_driver, and provide the interfaces for those hardware_drivers to be completely independent of the rest of the OS, in such a way that the same driver in a x86 platform(exemple) could be used wihtout alterations by all the OSes that implement the driver model. If we go to "spark" or "ppc", the same thing.

I belive, IMO, that this could be the deal that the hardware industry could not refuse, better than one gun pointed to the head in one hand, and a pen to sign the contrat in the other!!!...it'll definitely mean nº1 hardware support for Linux.

Reduced Development Cycle

Posted Sep 4, 2002 1:59 UTC (Wed) by mmarq (guest, #2332) [Link]

More on crazy idea!!!

For those that thoughed that I must had been on drugs, here is another dose!!!

Since the proposed transferes between a Ethernet board and a graphics or sound board( in the exemple), could be essencialy by nature, a streaming data transfer mode, I not departure even more from I2O V2.0 spec, and use the "facilities" of the STCP(stream protocol)[an alternative could be ST-RTP, another open protocol] now introduced in the 2.5 kernel. Since the real interesting thing about a middle communication layer- apart from isolate device_drivers from the rest of the kernel, is the direct communication between device_drivers wihtout or with minimal interruping of the central CPU, then streaming all possible transfers of data could be a very efective way of achieving this. The use of STCP or alternatives could be the key to use I2O defined "hardware_drivers", whihtout special Mobos or expansion boards with IOP(interrup processores), and with very little overhead - I2O "device-drivers" on plain commodity hardware!!!

And since there was the famous kernel in a IBM wristwatch, and since the STCP can propagate even on the INTERNET(some developers think it could replace TCP), this could propel the use of a Linux box not only to use and control it's own devices and peripherals, but also remote devices and peripherals, connected or not to other computers, and including devices like HDTV or HI-FI set!!!...remote now has no limit...Imagine watching and program your home cable HDTV set recording facilities, from a laptop in a hotel, in another continent, connected trough the internet???!!!!