grub-devel
[Top][All Lists]
Advanced

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

Re: [patch] set prefix on PPC


From: Marco Gerards
Subject: Re: [patch] set prefix on PPC
Date: Tue, 15 Feb 2005 21:31:27 +0000
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Hollis Blanchard <address@hidden> writes:

>> How is the file blessed and why does that make it a problem to keep
>> /boot on a HFS partition?
>
> The file is blessed with hfsutils, spefically hattrib(1). I do not
> know if the in-kernel HFS(+) drivers allow for such changes (via
> ioctls for example). That will be worth investigating.
>
> Actually it seems I was mistaken, and "blessed" refers to the
> directory rather than the file itself. I believe then the proper file
> to be booted is found from its 4-byte HFS file type, "tbxi" being the
> magic "Mac OS kernel" type.

Ok.  But the file does not need to be blessed to boot from it.  It's
just used so the user can use:

boot hd,0

instead of:

boot hd,0:grubof

To me the second sounds good enough.  Or does that cause other problems?

> Ok. I assume you want to test my patch and review it further, so I
> will wait for more comments before committing it.

Sure, I will test and review it on both of my PPC systems and review
the patch.  I hope you understand that it can take a while. :/

>> I don't want to add a fancy parser yet.  At the moment we just use a
>> single argument.  If more will be used, this code has to be changed.
>
> And in that case, the format of "bootargs" will have to change
> too. It's never too early to think about backwards compatibility,
> especially if people are thinking of packaging and distributing a
> grub2.deb... :)

Huh?  Why would backward compatibility be broken?

>>> Confused... how is this related to bootargs and prefix?
>>
>> It is required to make GNU/Linux boot here, just like the bootargs
>> stuff. ;)
>>
>> It is separated with a blank line to make clear they do not serve the
>> same purpose.
>
> I thought each ChangeLog entry represented a distinct "changeset",
> with changesets being logically different changes to a group of
> files. The ChangeLog was explained to me as emulating a changeset in
> version control systems that lack the concept (such as CVS).

>From the GCS:

   "Separate unrelated change log entries with blank lines.  When two
entries represent parts of the same change, so that they work together,
then don't put blank lines between them.  Then you can omit the file
name and the asterisk when successive entries are in the same file."

Did I misinterpret this?

> Since I believe the ChangeLog is an anachronism, I don't really care
> what it looks like or what format it's in. But since these changes are
> logically distinct, I believe they should at least be committed with
> separate "cvs commit" commands.

One commit it one ChangeLog entry, it's the same.

Thanks,
Marco





reply via email to

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