On Fri, Mar 06, 2020 at 02:37:43PM +0100, Vladimir 'phcoder' Serbinenko wrote: > Le ven. 6 mars 2020 à 13:43, Daniel Kiper <dki...@net-space.pl> a écrit : > > > Re-adding grub-devel@gnu.org... > > > > On Fri, Mar 06, 2020 at 12:44:05PM +0100, Vladimir 'phcoder' Serbinenko > > wrote: > > > Le ven. 6 mars 2020 à 12:42, Daniel Kiper <dki...@net-space.pl> a écrit > > : > > > > > > > On Thu, Mar 05, 2020 at 03:22:31PM +0100, Vladimir 'phcoder' Serbinenko > > > > wrote: > > > > > Please evaluate size increase for this. In the past passing file and > > line > > > > > number to grub_dprintf was a huge source of increased Kern and core > > size > > > > > > > > I think it does not matter much if we stop pretending that we support > > > > small MBR gaps right now [1]. Does it? > > > > > > > There are still a lot of installations that used older tools and never > > > reformatted. We still care about them > > > > If we go that way then we have to care about them by the end of the > > universe. And this means more and more issues like [1]. If somebody > > wants to use new GRUB then he/she have to reinstall the machine or > > something like that. IMO we should not care about users who do not want > > upgrade their machines or whatnot. Or at least their choices cannot > > impact GRUB development too much. And I think that this MBR constraint > > is hindering the project too much at this point. So, as above... > > > > Sorry for being blunt... > > > It does not. Core doesn't need to have everything and the kitchen sink. > It's small by design.
I am not saying that. I am saying that limitations of one ancient platform should not make development of other platforms more difficult. Daniel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
