On Sun, 13 Feb 2000, Julian Coleman wrote:

> Jason Thorpe wrote:
> Do you mean something like :
> 
>   struct disklabel_handle {
> 	int (*reading_routine) (...);
> 	int (*writing_routine) (...);
> 	int (*check_consistency_routine) (...);
> 	int (*convert_to_struct_disklabel) (...);
> 	int (*convert_from_struct_disklabel) (...);
> 	  ...
>   }

I really think trying to shove all of the different partition formats we
have into one overall scheme will give us something large and unweildy.
Let's just stick with a set of (read me a disklabel) routines.

> ?  Then the functions :
> 
>   nativelabel_read (h.reading_routine, ...);
>   nativelabel_write (h.writing_routine, ...);
>   nativelabel_check (h.check_consistency_routine, ...);
>   native_to_disklabel (h.convert_to_struct_disklabel, ...);
>   disklabel_to_native (h.convert_from_struct_disklabel, ...);
>   update_incore (struct disklabel);
>   write_disktab (struct disklabel);
>     ...

nativelabel doesn't make sense in a number of ports, please zap it. :-)

> der Mouse wrote:
> > Or are you talking about the fact that on some ports, native labels
> > aren't the same as NetBSD labels?
> 
> Yes.  And in some cases (e.g. Atari), you'll need to parse the native label
> before you can parse the NetBSD label.  In the Atari case, the NetBSD label
> is stored at the beginning of the first NetBSD partition (there's no room
> in the native label).  Then again, maybe you want to read a native label
> where there is no NetBSD label on the disk.

Right. The routine which knows how to recognise an Atari disk format would
know to look for a NetBSD disklabel, and baring that, to fall back to
something it fakes up.

Actually in terms of the scheme Leo mentioned: there'd be 63 partitions to
be filled in for this disk (the raw part, partition 0, is invariant). As
an example, if it's an Atari-format disk, reserve the first 8
to-be-filled-in slots for what is currently a NetBSD disklabel. Then put
Atari-format partitions above that. That way you can get at all of the
partitions on the disk (even AtariOS-used ones), and adding a partition to
the NetBSD disklabel won't move stuff around.

> > The major problem I see with this is that some ports' native labels
> > contain information (such as partition names) that cannot be
> > represented in a struct disklabel.
> 
> Yes.  This is especially important if you want to edit the native label.
> As this was the original goal of libahdi, I don't want to lose this
> functionality.  So, it would be nice if 'native' tools can also use the
> library, e.g. editahdi, editmbr, sysinst.

I agree that the ability to write an Atari-formatted disk on something
other than an Atari is cool. But why does the one overall disklabel
reading library need to know how to edit them? Only editahdi (well and
maybe xeditahdi) needs to know the innards of ahdi, doesn't it?

Oh, sysinst should be able to farm things out to the different programs so
that it doesn't need to duplicate code. :-)

> > I'm not entirely sure why there have to be header files describing the
> > various label formats.  After all, nobody but libdisklabel is ever
> > supposed to be messing with them, right?

I vote we should go to a lot of little programs, each of which edits its
own format.

If you look at all of the defines in disklabel now, it looks like a lot of
swiss cheese. :-)

> At the moment, ports have MD (e.g. sys/arch/atari/include/disklabel.h) and
> MI (e.g. sys/sys/disklabel_mbr.h) headers describing their label formats.
> If there is a library to manipulate these labels, it seemed sensible to me
> to make all the header files MI.  That might also mean they need to be
> modified for endianness and data sizes considerations.
> 
> > As for Suns, well, I've got 16-partition disks on /sparc and /sun3
> > already.
> 
> Is this compatible with native Sun disklabels?  BTW, I seem to remember a
> proposal to move all ports to a common format (slices?) ...

Right. Well, the "slices" format Leo and I spoke of is different from what
FreeBSD did, mainly as it needs to scale to lots of formats where FreeBSD
doesn't.

> > Only if there are structs describing "foreign" on-disk data structures
> > (often a bad idea anyway, if only for endianness reasons).
> 
> But, see above.  I think the same struct should be able to describe one
> ports on-disk data structure for all ports.

Given all the different things different disk layouts do, I think this is
a VERY tall wish, and that we'd be most unhappy with what we'd get.

For instance, MacOS partitions each take up one sector in the partition
map. So a correct representation of this format would need at least
512-bytes per partition (and it gets even more bizzar on non-512-byte
disks).

Also, don't forget that some partitioning schemes can co-exist. I know MBR
& MacOS can co-exist, as can MacOS and macppc's disklabel format. Given
how things are laid out, I expect you can get MacOS, MBR, and a disklabel
format partitioning all on the same disk.

That's why I think, for our heads to not explode, we would be better
served by not trying to make generic tools that can modify all different
partitioning formats.

[Endianness]

> I really meant that the routines need to know the endianness of the native
> label and the port reading the label.  So, the code will need to convert the
> on-disk data structures to the local endianness (if different).

Yep!

Maybe the best thing to do is have a libdisklabel which is able to read
all the different formats and shove them into the new in-kernel disk
layout structure Leo mentioned, and to let the different partitioning
schemes descide if they want a shared lib for their modifying/writing
routines. Like editahdi and xeditahdi could use a libdisklabel_ahdi, etc..

Thoughts?

Take care,

Bill