Re: disk driver interface

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

On Dec 29,  9:28pm, Christos Zoulas wrote:
} On Dec 29,  4:11pm, jnemeth%cue.bc.ca@localhost (John Nemeth) wrote:
} 
} |      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.

     I want to pullup gpt(8) to all branches, so now I have to
figure out what to do with it.  I'm thinking I might just pullup
everything before the recent change.  Given that, I can just blow
away the drvctl(4) stuff.

} |      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(),

     I saw that you added a call to disk_ioctl() to ccd.  I'm just
not sure what you expected it to do, given that the struct disk_geom
wasn't filled in.  I just fixed that problem.

} 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.
} 
}-- End of excerpt from Christos Zoulas