grub-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Reimplement 10_freebsd.in using 10_linux.in


From: Vladimir 'phcoder' Serbinenko
Subject: Re: [PATCH] Reimplement 10_freebsd.in using 10_linux.in
Date: Mon, 17 Aug 2009 16:27:51 +0200

On Mon, Aug 17, 2009 at 4:01 PM, Robert Millan<address@hidden> wrote:
> On Sun, Aug 16, 2009 at 09:29:08PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> As discussed on IRC this patch has problems on FreeBSD.
>> Among them
>> 1) stat and readlink are different. Does anyone have an idea how to
>> make scripts always use right syntax?
>
> AFAIK a custom autoconf snippet is the only way.
I would prefer it to be done on runtime if possible.
>  Do you know how to reliably
> identify GNU-incompatible readlink?
Perhaps "readlink --version | head -n 1 |grep GNU" ?
> I'm not sure what "readlink -f /" will do
> on FreeBSD.
>
It complains about unknown option.
>> -  if path=`readlink -f $path` ; then : ; else
>> +  if path=`realpath $path` ; then : ; else
>
> Note that this introduces an external dependency on GNU systems (readlink is
> part of coreutils), which better be avoided (specially since the version of
> realpath commonly used there has a problematic license).
>
On FreeBSD it's a part of base system AFAIR. GNU readlink is available
through ports but is named greadlink. Perhaps we should try in script
first realpath and if it's not found try readlink?
>> 2) "FreeBSD, kFreeBSD ..." isn't what FreeBSD user expects.
>
> Ok.
>
>> 3) Version isn't detected correctly.
>
> Since this part is not in your patch, can you explain the problem?
>
I haven't looked in it but I guess the problem is that the kernel is
named just "kernel" with no version string.
>> 5) device.hints are forgotten
>
> Ok.
>
>> 4) Doesn't use UUID
>> 6) Doesn't support ZFS
>
> These two are in the previous version too, so I'd fix/merge them separately
> (increasing commit granularity is a good thing).
>
ZFS in mkconfig isn't ready at all. I think it can be postponed
without any problems
> --
> Robert Millan
>
>  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>  how) you may access your data; but nobody's threatening your freedom: we
>  still allow you to remove your data and not access it at all."
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git




reply via email to

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