Robert Millan <[EMAIL PROTECTED]> writes: [...]
>> > This is a lot of code being added to kernel, and space in kernel is highly >> > valuable. >> > >> > Would the same functionality work if put inside a module? >> For the reasons discussed above in the loader.h snippet, I don't think >> so: the only "lighter" solution would be to just put a drivemap_hook >> variable that would be called before boot, but as I mentioned before, >> this solution can be employed by other modules as well. >> >> Besides (and I realize this is not a great defense) it's not _that_ much >> code: just a simple linked-list implementation with add and delete >> operations, and the iteration of it on loader_boot. I did not check how >> many bytes does this patch add by itself, but I can run some simulations >> (I totally _had_ to say that ^^) if you want. > > Having a small kernel is highly desireable for most users. If the kernel is > too big, it won't fit and then either we have to use blocklists (which are > unreliable), or we have to abort the install. > > Please, try to find a way that doesn't increase kernel size significantly. > > If the kernel interfaces are not extensible enough, you could try to readjust > them for your needs. This approach works well most of the time (although I > haven't studied this particular problem in detail). Like discussed before. Bring up such modifications like hooks up in a *separate* thread. I already said that not everyone reads this discussion. I will not accept a patch that changes the kernel if it is part of a bigger patch that not many people read. Please don't discuss this over with Robert and me, you know that it was pointed out that this has to be a patch in a separate thread. Furthermore, this is a way to get some feedback from Bean who wants something similar, IIRC. -- Marco _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
