Re: disk driver interface

[christos%astron.com@localhost (Christos Zoulas)]

In article <m7qg4d$3kt$1%serpens.de@localhost>,
Michael van Elst <mlelstv%serpens.de@localhost> wrote:
>
>Currently NetBSD has three programming interfaces to determine
>disk geometry from userland.
>
>- ioctl DIOCGDINFO. The traditional interface, limited to 32bit
>  numbers or disks < 2TB because its data structure corresponds
>  to the binary on-disk structure.
>
>- the "get-properties" command to the drvctl(4) driver. drvctl(4)
>  is missing on some ports and some disk drivers don't make
>  geometry properties available.
>
>- ioctl DIOCGWEDGEINFO. Works only for wedges but not for the
>  disk drivers themselves. This is fine for operations on
>  data blocks of a wedge but doesn't help e.g. partitioning
>  tools. It also does not provide the sector size.

Actually there is also:
 - ioctl DIOCGDISKINFO. This is supposed to work for all kinds of
   disks but it returns a plist, and it is a pain to use.
>
>To solve this, we could
>
>- create a new DIOCGDINFO version that uses larger numbers. AFAIK
>  that is about what OpenBSD does. The on-disk structure could be
>  translated but writing a label might be incompatible if partitions
>  are defined beyond the 2TB limit.

I think we should decide on a single API/interface to get general
information about disk devices. If a "big" DIOCGDINFO is that,
fine.  But we decided it was not providing enough information a
while ago and so we got DIOCGDISKINFO. Providing a "big" DIOCGDINFO
would allow us to have compatibility with OpenBSD and bring a 70's
technology to the 21st century.

>- make drvctl(4) mandatory and make all disk drivers provide
>  geometry properties.

Well, I don't particularly like to have to go through an auxiliary
driver to get information that should be readily available from
the direct driver, but we could consider making drvctl mandatory.
The only problem would be "small" kernels.

>- make DIOCGWEDGEINFO available for the disk drivers and
>  ignore wedge-related information.

Well, we have DIOCGDISKINFO... which provides the kitchensink, but
it is hard to use. I think it is a demonstration on how a fully
generalized API that provides everything loses because of programming
complexity. Having said that, for the most part (getting struct
disk_geom out of it), it works once abstracted (see partutil.[ch]
in sbin/fsck/). Perhaps adding a DIOCGDISKGEOM that returns just
disk_geom would be nice to have and can replace DIOCGDINFO.

>- import FreeBSD DIOCGMEDIASIZE (and DIOCGSECTORSIZE) ioctls.

I would do that anyway, since it is simple and most things just
need those two numbers.

christos