Re: disk driver interface

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

On Dec 29,  4:11pm, jnemeth%cue.bc.ca@localhost (John Nemeth) wrote:
-- Subject: Re: disk driver interface

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

I think that using it directly makes sense. If you want you can
delete the drvctl and partutil code in gpt. Now that we have both
the ioctls and the DIOCGDISKINFO code, doing the same thing 3
different ways does not make a lot of sense, except to demonstrate
we (like perl) have many different ways of doing the same thing but
with varying complexity and possibility of error.

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

Michael fixed cgd and I fixed ccd. I am not sure about getdiskinfo(),
the API is clumsy. If is what I found useful when converting the
individual fsck and dump utilities to wedges. It should and could
be improved.  getdisksize() on the other hand can be abstracted to
the two new ioctls() + opendisk() now...

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

Right, this is probably too much work for too little gain.

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

Yes, then we don't need all the plist crap in partutil.c, since the
only thing that partutil uses from the plist is geometry. I think that
we should add this ioctl and not need to go through the hoops of
extracting the geometry from the plist now.

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

Michael did that already.

christos