![]() | ||||||||||
Messages in this thread |
Eric W. Biederman wrote: > > O.k. I have been thinking about this some more, and I have come up with a couple > alternate of solutions. > > The simplest is the observation that right now 10MB is about what it > takes to hold every Linux driver out there. So all you really need is > a 16MB system, to avoid a device probing loader. And probably > noticeably less than that. The only systems I see having real > problems are old systems where device enumeration is not reliable, and > require human intervention anyway. > > A second is to just make certain there is some kind of fallback path > so if the image is too large have a way to load a smaller one. When > you consider that older systems had less memory it has a reasonable > chance of working properly. > > My final and favorite is to take an ELF image, define a couple of ELF > note types, and add a bunch those notes saying which pieces are > hardware dependent. So a smart ELF loader can prune the image as it > is loaded, and a stupid one will just attempt to load everything. And > with the setup for this not being bootloader specific it will probably > encourage device pruning loaders. > > Am I being optimistic or are there any pressing cases for callbacks to > the firmware? > Ok, now let me ask the question that hopefully should be obvious to everyone now... WHAT'S THE POINT? All you're doing is an awfully complex song and dance to *avoid* implementing a solution that, while imperfect, is thoroughly established and has worked for 20 years. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2005-03-22 12:23 [from the cache] ©2003-2008 | ||||||||||