Re: disk driver interface

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Dec 29,  4:46pm, Christos Zoulas wrote:
} 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.

     A semi-quick look around shows that pretty much everything
that would support the drvctl(4) method would also support the
DIOCGDISKINFO method.  Both methods return the same proplib dictionary
for disk geometry info.  So perhaps the DIOCGDISKINFO method should
always be used in preference to the drvctl(4) method.

     As far as I know, the only drivers that don't support drvctl(4)
and DIOCGDISKINFO are ccd(4) and cgd(4).  They should just be fixed.
Then DIOCGDISKINFO can be used always with everything else relegated
to compat.  Also src/sbin/fsck/partutil.* should probably be moved
to libutil as they appear to be of general utility, instead of
having random utilities pulling in parts of fsck.

} >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.

     It's a dead technology.  Besides, for real OpenBSD compability
we would have to deal with their on-disk changes as well.

} >- 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.

     DIOCGDISKGEOM could easily be added to
src/sys/kern/disk_subr.c:disk_ioctl(), then all drivers that support
DIOCGDISKINFO would automatically support DIOCGDISKGEOM.

} >- import FreeBSD DIOCGMEDIASIZE (and DIOCGSECTORSIZE) ioctls.
} 
} I would do that anyway, since it is simple and most things just
} need those two numbers.

     These ioctls could probably also be added to
src/sys/kern/disk_subr.c:disk_ioctl().  Any disk drivers that don't
call that function should be fixed.

}-- End of excerpt from Christos Zoulas