"Charles M. Hannum" <root@ihack.net> writes:
> DIOCSDINFO is supposed to set the in-core label and *not* write it
> out.  If the label is simply discarded, that entirely defeats the
> point of DIOCSDINFO.

false.  it could very well be that you're doing what disklabel is in
the '-r -w' case (if i recall the code correctly): setting the in-core
label before you clobber the on-disk label.  immediately after you're
done doing that, you may _want_ to close the device and have the
kernel re-read the label from disk.

However, I will agree that in many cases this is undesirable and
perhaps making DIOCSDINFO be 'sticky' (until cleared) is the right
thing.  If it is, then it's desirable to change e.g. 'disklabel -w -r'
so that it clears the 'sticky' flag right after writing the label, so
that the next open gets the real (just written) on-disk label.


> There are a number of cases where this behaviour
> is desirable (e.g. using a disk that has a partition table for a
> different system, and you don't want to modify it).

Sure, I understand that it's desirable to have behaviour which allows
'sticky' labels, but my statement is that:

* subtly changing the API without documenting it well is bogus,

* this is subtle a _change_ to the API as it existed, which has
implications that were not properly examined.


> I submit that what you're arguing for goes direcly against historic
> practice *and* the actual API.

I believe there's at least one 'historic' program in our source tree
whose use of the ioctls disagrees with your interpretation.  Further,
that if the change was only made in the last hear, as far as NetBSD's
history goes, the old behaviour _was_ our history.  8-)

Anyway, there's no point in going there: I think the historic API as I
see it needs to be improved, but the way to do that is _not_ to make
all labels 'sticky' when first they are read from disk!  Only SDINFO
should have that power, and there should be a way to clear it (other
than by writing a new label to the disk with WDINFO).



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.