From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: Are BSD partitions not supported?
Date: Mon, 31 May 2010 23:16:09 +0200 [thread overview]
Message-ID: <4C042719.4050907@gmail.com> (raw)
In-Reply-To: <4BF8FA66.5060702@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3183 bytes --]
Grégoire Sutre wrote:
> On 05/19/2010 09:20 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>
> [snip]
> - delta = grub_partition_get_start (disk->partition);
> + delta = grub_le_to_cpu32 (whole_disk_be.offset);
>
> As dicsussed on irc, this makes the delta completely dependent on the
> c: entry of the disklabel, which could be bogus.
>
Looks like we have to have different behaviour for different BSDs. Since
it looks like generic code would fail for ThisBSD or ThatBSD, I propose
to go by as-needed basis. So I think we should:
-restrict bsdlabel to being embed into msdos partitions of types a5, a6
or a9.
-conditionalise the behaviour and use my patch for a5 (FreeBSD) and
current behaviour for a6 (OpenBSD) and a9 (NetBSD).
I recognise that it's ugly.
Another possibility is to have both (hdX,msdosY,freebsdZ) and
(hdX,msdosY,netbsdZ) syntax but it would result in many confusing ghost
partitions. But since bsdlabel is so disorganised and ugly I prefer to
limit its support to minimum.
> For instance, on NetBSD/i386, the system seems to work fine with random
> entries for c: in the disk label stored on the disk. Even a null offset
> is fine. The in-core disklabel shown by the command disklabel (without
> -r) is the correct one. I give an example below, which was obtained on
> system booted from wd0.
>
> IMHO, the current code is better for the cases where the offsets in the
> disklabel are absolute addresses, since it performs exactly the inverse
> translation of the one done in grub_partition_get_start(), which AFAICS
> is supposed to return the absolute address.
>
> What we want here is to diverge from that code when the disklabel
> offsets are relative. I believe that testing whether c: has a null
> offset gives the answer. I changed Vladimir's second patch to do that.
>
> We still have the problem that NetSBD uses c: for the whole-disk
> partition on many ports (but it's d: on i386 and amd64), see [1]. For
> those ports, the normal offset for c: is 0. But maybe it's fair to
> assume that, on those ports, the NetBSD slice is never embedded in
> another partition?
>
> Grégoire
>
> [1] http://nxr.netbsd.org/source/s?defs=RAW_PART&project=/src
>
> On-disk label
> niagara# disklabel -r wd0
> 16 partitions:
> # size offset fstype
> a: 263088 10233405 4.2BSD
> b: 2097648 10496493 swap
> c: 82345673 0 unused
> d: 117210240 0 unused
> .
> .
> .
>
> -------------------------------------------------------------------------
> In-core label
>
> niagara# disklabel wd0
> # /dev/rwd0d:
> .
> .
> .
> 16 partitions:
> # size offset fstype
> a: 263088 10233405 4.2BSD
> b: 2097648 10496493 swap
> c: 58605120 10233405 unused
> d: 117210240 0 unused
> .
> .
> .
> ------------------------------------------------------------------------
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]
next prev parent reply other threads:[~2010-05-31 21:16 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-16 16:24 Are BSD partitions not supported? C. P. Ghost
2010-05-18 18:08 ` C. P. Ghost
2010-05-18 18:37 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-05-18 19:33 ` C. P. Ghost
2010-05-18 20:20 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-05-18 22:06 ` C. P. Ghost
2010-05-19 17:49 ` C. P. Ghost
2010-05-19 18:00 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-05-19 18:33 ` C. P. Ghost
2010-05-19 18:40 ` C. P. Ghost
2010-05-19 18:50 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-05-19 18:54 ` Navdeep Parhar
2010-05-19 19:20 ` C. P. Ghost
2010-05-19 19:12 ` C. P. Ghost
2010-05-19 19:20 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-05-19 19:41 ` C. P. Ghost
2010-05-20 16:19 ` C. P. Ghost
2010-05-23 9:50 ` Grégoire Sutre
2010-05-23 15:44 ` C. P. Ghost
2010-05-24 0:56 ` Grégoire Sutre
2010-05-24 16:50 ` C. P. Ghost
2010-05-31 21:16 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2010-06-01 10:34 ` Grégoire Sutre
2010-06-01 11:21 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-06-06 17:05 ` Grégoire Sutre
2010-05-19 18:48 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-05-18 22:20 ` Vladimir 'φ-coder/phcoder' Serbinenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C042719.4050907@gmail.com \
--to=phcoder@gmail.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.