Re: [patch] NetBSD disklabel support for geom_bsd

Dmitry Pryanishnikov wrote:

>
> Hello!
>
>   I've installed NetBSD 3.0 recently on the same HDD with FreeBSD-CURRENT
> and found that OSes just don't see each other's partitions. I thought
> that it would be convenient for FreeBSD developers if FreeBSD were able
> to understand NetBSD's disklabel as we borrow their code occasionally ;)
> After detailed analysis I understood the difference between disklabel 
> formats:
> they are essentially the same except 2 points:
>
> 1) NetBSD people extended partition table to 16 entries vs. our 8. 
> That's OK,
>    we have place for 22 entries within 512-byte sector for disklabel 
> offset 0,
>    and 18 for offset 64 bytes (Alpha's case).
>
> 2) (most important) NetBSD disklabel describes partitions not 
> slice-relative
>    (like ours), but the whole device-relative. They have no slice 
> devices, so
>    their disklabel actually duplicates functionality of device slice
>    table, and describes both NetBSD partitions and other slices as 
> partitions.
>    E.g., for my HDD I've got the following NetBSD disklabel:
>
> 16 partitions:
> #        size    offset     fstype [fsize bsize cpg/sgs]
>  a:   2097648 147942585     4.2BSD   2048 16384 21872
>  b:   2097648 150040233       swap
>  c:  81931500 147942585     unused      0     0
>  d: 312579695         0     unused      0     0
>  e:   2088387        63      MSDOS
>  f:  61440624 152137881     4.2BSD   2048 16384 28704
>  g:  10150560 213578505     4.2BSD   2048 16384 28456
>
>   and so on.
>
>    So, from the FreeBSD's POV the only useful information from NetBSD
> disklabel are the entries which point within NetBSD slice (in my example,
> a-c,f,g). Others already have FreeBSD's counterparts (my NetBSD slice
> is ad0s3, but partition 'd' describes the whole ad0, and 'e' == ad0s1),
> and it would be wrong and even dangerous to keep them.
>
>  I've created simple patches against geom_bsd.c for CURRENT and RELENG_6:
>
>     ftp://external.atlantis.dp.ua/FreeBSD/geom_bsd/CURRENT.diff
>     ftp://external.atlantis.dp.ua/FreeBSD/geom_bsd/RELENG_6.diff
>
> which implement recognition of NetBSD disklabel only on slicer level
> (no support for ioctls == no support for bsdlabel), but IMHO that's
> enough - rest can be done from the NetBSD itself. My patches are quite
> simple:
>
> 1. g_bsd_try() modified to accept large (>8) number of partitions;
>
> 2. g_bsd_taste() accepts NetBSD's slice type 169 and does special
>    processing for it: truncates partition table to 8 entries,
>    converts offsets from absolute to slice-relative, and removes
>    entries which describe areas outside the NetBSD slice.
>
> I have verified these patches against 2 different NetBSD partition
> layouts, they work as expected (for the shown case, create ad0s3a-c,
> ad0s3f-g). The only drawback in my solution is that only first 8 
> partitions
> (of currently 16 NetBSD's) can be represented. If you'll create separate
> /, /usr, /var, /home and user-defined partition during NetBSD install,
> they'll be: 'a', 'f', 'g', 'h' and 'm' for my HDD layout, and 'm' will
> be unreachable from the FreeBSD. I could remap it to the free slot
> (e.g. 'd'), but I've decided not to do it, because it could add confusion
> IMHO. After all, both slices (FreeBSD and NetBSD) are usually managed
> by the same person, so [s]he'll create reasonable NetBSD partition
> layout.
>
>  I hope my patch can be useful, and would like to get feedback about it.

why not make a completely separate type and allow access to all teh 
slices with the
same partition letters that netBSD uses.. i.e. a g_nbsd type..

>
> Sincerely, Dmitry