| |||||||||||
initramfs status?initramfs status?Posted Aug 29, 2002 16:44 UTC (Thu) by cpeterso (guest, #305)Parent article: The 2.5 device model
I think this is cool how the kernel is taking a more structured approach to devices (and their drivers). But does anyone know the status of the initramfs work? In the Linux 2.5 status updates, Alan Cox's work to replace ALL statically-linked device drivers with modules stored in the kernel file's initramfs is always still in the planning stage. This sounds like another way to unify a lot of hairy, duplicate code in the kernel, but it doesn't seem like it will see the light of day in time for the Linux 2.6 feature freeze on October 31.. :-(
(Log in to post comments)
initramfs status? Posted Aug 29, 2002 17:48 UTC (Thu) by iabervon (subscriber, #722) [Link] I believe that nobody's managed to get all of the efficiencies of having things statically linked into the kernel with modules. Additionally, people keep reducing the duplication; there's no inherent reason a device driver can't act like a module while being linked into the kernel image (getting the code into memory and linked is the same for all modules; once it's linked, it can run the same whether it's always been there or was loaded dynamically). So it may turn out that the main useful idea of Alan's work (code initializes the same way regardless of whether it's in the kernel file or not) will be implemented without some of the other properties of the idea which people don't like.
initramfs status? Posted Aug 29, 2002 22:21 UTC (Thu) by giraffedata (subscriber, #1954) [Link] >I believe that nobody's managed to get all of the efficiencies of having>things statically linked into the kernel with modules I believe there are no such efficiencies. I maintain the loadable kernel module ("module") HOWTO and have been collecting information on that question, and all I've come up with is one possible efficiency that statically linked modules have over dynamically loaded ones in that the base kernel lives in a block of virtual=real memory, whereas a dynamically loaded one may get loaded into a region where the virtual address is not the same as the real address. And that _may_ have some measurable effect on speed in _some_ architectures. But probably nothing significant. And even that is pretty easy to fix in the initramfs concept, since the loading of the base kernel and of all the other modules is happening at about the same time.
initramfs status? Posted Sep 1, 2002 7:42 UTC (Sun) by qubes (subscriber, #2562) [Link] A staticly linked kernel lives in a memory space mapped with 4M tlb entries. Loaded modules don't get loaded into the same memory space, and the jump to "far" addresses take longer then jumps within the same tlb. Given that, the difference is usually in the noise of any kernel profile.... initramfs really needs a developer to fall in love with the userland side of the problem...and Alan currently hacking on the IDE bits that will hopefully get stable in 2.5.
Reduced Development Cycle Posted Aug 30, 2002 1:54 UTC (Fri) by mmarq (guest, #2332) [Link] 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!!
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???!!!!
|
|||||||||||