Re: [RFC] grub-install C rewrite

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2271 bytes --]

On 26.09.2013 15:35, Lennart Sorensen wrote:
> On Thu, Sep 26, 2013 at 03:08:54PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> Hello, all. Recently I made some order in hostdisk.c and getroot.c
>> involving splitting in OS-specific parts.
>> In the same time I added WinAPI version of getroot/hostdisk allowing
>> grub-probe to work on windows natively
>> Also on-going is AROS-specific parts.
>> Windows and AROS are not friendly with bash.
>> The attempt to make both multiple files of same type work and handling
>> whitespaces/newlines/... in filenames would result in very ugly code
>> with loads of evals.
>> Current code may have subtle assumptions on behaviour of common tools
>> like sed and on locale (E.g. "[a-z]" doesn't cover u if locale is Estonian).
>> So to check viability I rewrote grub-install in C. This is mostly proof
>> of concept with loads of FIXMEs but I could boot i386-pc install made
>> with it. In many aspects (static variables, some tests, general
>> structure) it's reminiscent of sh version of grub-install it's based on.
>> Some functionality is likely to stay OS-specific, e.g. executing
>> compressors or determining firmware.
>>
>> I'd like to know the opinion of other people on possible switchover. If
>> switched then it'll have to be all grub-install, grub-mkrescue,
>> grub-mknetdir and grub-mkstandalone.
>> I'd like to hear from other people.
> 
> Given the number of times I have had to edit grub-install in the past to
> get it to work right on a powerpc machine (I think it is now working OK),
> I would hate to have had that be C code.  After all it really is mainly
> a wrapper around other grub tools.
> 
What kind of changes was it? Could we make them into some (possibly
hidden) options?
> I think windows not having bash is a rather low priority to most people
> compared to actually be able to work with grub on the platforms where
> it is pretty much the only choice.
> 
windows is low priority and more of a bonus. The problems of handling
anything that looks like a list (e.g. list of devices where / resides on
in case of btrfs) and code becoming hairy to handle those cases is
bigger reason.
> So personally, based on my experience, I hate this idea.
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]