On Fri, Jul 3, 2009 at 7:22 PM, Pavel Roskin<pro...@gnu.org> wrote: > On Fri, 2009-07-03 at 01:29 +0200, Vladimir 'phcoder' Serbinenko wrote: > >> > It doesn't apply in loader/i386/pc/chainloader.c at all. >> Ok, I'll rediff. > > Take your time. > > Actually, the chainloader patch refers to "disk->parition" (misspelled > "partition"), so i doubt that it was even compile tested. My bad. Normally I test my patches and perhaps I just compiled wrong directory (I build externally and may have forgotten configure). I don't remember what exactly happened but I clearly did a big mistake /me feels ashamed >> > I don't think >> > there are any objections against supporting nested partitions. >> Yes but I thought someone may have comments like "let's shave ths part >> from the kernel". The patch doesn't increase the core.img because >> increase of kernel size is compensated by pc.mod/bsdlabel.mod split. >> It the cases when bsdlabel.mod is used usually no modules like raid or >> lvm are used > > Such objections may be raised once there is a patch that compiles. > Distributors must consider worst case scenarios. > If worst-case scenarios don't fit into mbr gap we may consider another approaches 1) progressive loading (e.g. FS-parsing bootsectors in worst case bring some kind of stage1.5 back) 2) replace lzma with xz 3) use another embedding areas. E.g. lvm has to divide PV in PE of equal length. This often results in last block of space being smaller then PE. This space is reported by pvdisplay as unusable and we may use it w/o problems. I'm not an lvm expert though so don't rely on my word
> OK, good to know. Well it's still a considerable effort but not as hge as implementing TCP/IP stack from scratch -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
