Sorry to be a week late in this conversation. :-)

On Thu, 10 Feb 2000, Julian Coleman wrote:

> Hmm, API ... some thoughts ...
> 
> Purpose of the library ... routines to read native labels _and_ to read
> other ports' disks.

Let's phrase that a little differently: To read disklabels. :-)

The only MD bit of the thing I had in mind was a default scanning order.
All the reading routines would be the same, just ports would look for
formats in a different order.

> (with or without underscores).  I prefer the former (and libahdi is
> implemented like that).  There's also the additional complication of
> different native and NetBSD labels on some ports.  For example, we need

I like readlabel_foo, etc. :-)

>   ahdi_readlabel()	(native Atari disk label)
> 
> and
> 
>   atari_readlabel()	(NetBSD port/Atari disk label) 
> 
> to read Atari disks on all ports.

Why? What I envisioned was a routine which would be fed a strategy routine
and private data for it, and then just try to read the disk. If it found
an Atari disk format, it would do the right thing (reading the NetBSD
disklabel if present, if not, doing whatever the Atari disklabel code does
now when there's no NetBSD disk label).

Note: the reason for this choice of interface is so that the exact same
code could be used for the kernel, boot loaders, and userland. In userland
have an open file. In the kenrel, we are using the buffer cache. Who knows
what we're doing in boot loaders. :-)

Also, the drive above for this lib is different than what I think you had.
I think we really need something to let all ports READ other disk layouts.
I don't think we really need a library for WRITING other diks layouts.

> We also want a function that takes the native label and updates only the
> in-core disklabel with this information (for dealing with foreign labels).

I like the idea of something which you hand a disk, and it fills in a
struct disklabel. You can then shove it into the kernel if you wish.

> Next, data structures.  Would it be good to be able to 'import' all the
> foreign labels into a common structure?  Can we do this sensibly?  At the
> moment, I have :

I suspect not. And we really only need this sophistication if we want to
write them, which I don't think we really want, so we don't need it in the
kernel.

For instance, each different disk layout editor will need to present a
different UI. There are fields present in MacOS formatted disks not
present in others. Likewise for Atari from what I gather from you. I don't
see a sane way for one program to be able to edit multiple different
formats. :-)

>   int
>   ahdi_readlabel(struct ahdi_ptable *ptable, char *diskname, int flags);
> 
> so that the native label is parsed into a 'struct ahdi_ptable'.  This
> contains :
> 
>   number of sectors/track
>   number of tracks/cylinder
>   number of cylinders
>   number of sectors/cylinder
>   number of total sectors
>   number of partitions
> 
> and for each partition :
> 
>   partition flag
>   id: GEM, BGM, NBD, ...
>   root sector (the sector on the disk containing the parition information)
>   start sector
>   size in sectors
>   partition letter (the NetBSD letter to be assigned to this partition)
> 
> Perhaps a separate data type for each native partition form would be better,
> with a common disk information data type.

As above, let's just leave the writing side of things to format-specific
programs. I think the thing we'd get if we try to make an internal format
which covers everything would be rather gross.

> Obstacles (all that I've thought of so far, some obvious) :
> 
>   MI vs. MD headers
> 
>     At the moment all (?) ports have header files describing their disk
>     labels in header files that are not installed for all other ports.
>     These header files need splitting into MD and MI headers.  The MI
>     headers should go in src/sys/sys?

I started some work in this direction, and used sys/dev/disklabel, which
would install into /usr/include/disklabel.

>   Number of partitions
> 
>     Different ports support different numbers of partitions.  The data types
>     should handle the maximum number.  However, the current state of affairs
>     means all partitions on a particular disk may not be accessible at once
>     to certain architectures.  For example, accessing my 10 partition disk 
>     on a Sun.  Not sure what to do about this ...

See all the discussion last Sept or Oct when Leo was talking about making
libc work on all m68k ports. Let's just go to new major numbers, and 64
minors per disk.

>   Data sizes
> 
>     All data sizes must be explicitly specified.  This may impact the MI vs.
>     MD headers above.
> 
>   Endian
> 
>     The routines must be endian-independent.  Again, this may impact the
>     headers.

?? If we just limit the library to a collection of routines which read a
disk and spit out the disklabel thingie Leo was talking about, this isn't
a problem. i.e. the routines would use htobe or htole where appropriate.

>   Partition usage.
> 
>     Different ports specify RAW_PART (and SWAP_PART?) differently.  Not sure
>     if this will be a problem

See what came up in the previous thread: basically when we go to the new
device, partition 0 (which has no letter) is the RAW_PART.

SWAP_PART is a MacOS partitioning ism. The disklabel from a MacOS disk is
faked up from the MacOS partitions present. SWAP_PART is a define to say
where the first found MacOS UNIX swap partition is put (i.e. which letter
it goes into).

> Time scale
> 
>   This requires quite an overhaul of code.  Wait until after 1.5 before
>   putting this in the main tree?

Yes. :-)

Take care,

Bill