grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IA64 port


From: Marco Gerards
Subject: Re: IA64 port
Date: Tue, 29 Jan 2008 15:46:50 +0100
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)

Robert Millan <address@hidden> writes:

> On Tue, Jan 29, 2008 at 01:56:49PM +0100, address@hidden wrote:
>> Quoting Robert Millan <address@hidden>:
>> 
>> > On Tue, Jan 29, 2008 at 11:35:26AM +0100, address@hidden wrote:
>> > > Quoting Robert Millan <address@hidden>:
>> > > > > > Why is this needed?  I'm not sure if it's good to exploit this
>> > > > "unreliability"
>> > > > > > feature that fat provides us ;-)
>> > > > >
>> > > > > On EFI, the prefix is extracted from an EFI path, whose case may not
>> > match
>> > > > > the FAT entries.
>> > > >
>> > > > Can you be more specific about this?  What do the specs say?  We wrote
>> > > > /boot/grub ourselves via grub-install;  is an EFI-compliant firmware
>> > > > allowed to actively mess up case in paths we provided?
>> > >
>> > > On EFI, we don't really know where grub is stored.  There is a filesystem
>> > > layout convention we'd better to follow.  As a consequence, we extract 
>> > > the
>> > > path from an EFI structure (I didn't write this code - it's in the EFI
>> > common
>> > > code).
>> >
>> > What would you think of case-insensitive search in grub_efi_set_prefix() ?
>> 
>> You mean walking the filesystem in grub_efi_set_prefix ?  Humm, this looks
>> like a hack.
>
> It does, I admit ;-).  From my POV, it's a workaround for a bug, and it's not
> so strange that workarounds tend to look like ugly hacks.
>
> Anyway, does EFI replace the string with a case-unsensitive equivalent in
> practise?
>
>> The filesystem may not be FAT and there may be no way to read
>> directory entries (eg tftp - even if not yet supported).
>
> You can still do this kind of search by stating for a lot of specific files
> instead of iterating.  This would be a PITA, though :-(
>
>> If you really don't like it I can put it away for now.  Grub should work
>> without this patch in most cases.
>
> Could you wait untill the maintainers have their say on this?  If Marco or
> Okuji think it is fine, I have no objection then.

Personally I do not like working around an issue in specific code (in
this case specific to *-efi) in generic code.  Usually, this doesn't
improve shared code.

In this case, FAT is modified so fit the need of EFI.  However, FAT is
case insensitive.  On windows C:\FOO.TXT is the same as c:\foo.txt.
Although I have troubles believing people want to use a technically
flawed non-free OS that costs a lot of money.  But that might be
something personally ;-)

What matters is that it is normal that FAT is not case sensitive.
It's defined that way.  This change can't and won't be made for ext2,
for example.  You can have a ~/foo and ~/FOO side by side.  AFAIK,
this is not possible with FAT.  So I think this patch is ok :-)

Robert suggested some changes.  I also noticed in the discussion that
you didn't follow common practise (like an existing grub-mkimage
implementation).  Personally, as maintainer, I am against maintaining
two different approaches of the same problem.  It costs us time to
maintain this and both case have separate bugs.  So I rather see the
code shared, one way or the other.  To safe time, it might save you
some work if you initiate a discussion about this.

If you send in a new patch that addresses Robert's concerns +
Changelog entry, I will go over it ASAP :-).  Giving the same comments
as Robert does seems like a waste of time for everyone.  Is this ok
for you?

--
Marco






reply via email to

[Prev in Thread] Current Thread [Next in Thread]