| |||||||||||
|
| |||||||||||
Reduced Development CycleReduced Development CyclePosted Aug 30, 2002 8:50 UTC (Fri) by mmarq (guest, #2332)In reply to: Reduced Development Cycle by mmarq Parent article: The 2.5 device model 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.
(Log in to post comments)
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???!!!!
|
|||||||||||