On Wed 01 Sep 1999, Wolfgang Solfrank wrote:
> Hi,
> 
> > There is a difference between tty-parameters and a disklabel. The big one
> > being that incase of the tty-parameters, only the hardware keeps state. It
> > has no (seeable) software state like an in-core label. So unless the the
> > tty-hardware is explicitely modified, the parameters are OK. This is less
> > clear with disks (see the dd(1) example).
> 
> Hmm, do you think that echo is done by hardware? :-)

No, I am trying to say that you are comparing apples and pears ;-)
Obviously, I haven't been very clear and successful in this... 
What I was trying to say is that tty-parameters describe the hardware.
They also form some default setting of the hardware (this can be: don't
echo to my printer or please don't juggle those handshake lines while the
port is closed). Sticky tty-parameters usually remain valid until you
explicitely meddle with the hardware. Disklabels are an entirely different
beast in my opinion. The in-core version is usually some translation of the
on-disk label and both can be modified independently in various ways.

I would like to keep the focus on disklabels ;-)

> > What interests me is how you think it should function. Like when does the
> > in-core label come into existence and when and how it gets wiped out...
> 
> IMHO, in-core disklabels should normally be read/constructed from information
> found on the disk on any first open of one (no particular) partition of the
> device after startup or a media change.  And this happens to be the way our

It looks like you are trading the problem of in-core disklabels that get
lost on the last close with the problem of how to get rid of an in-core
disklabel. Turning things around here does not solve the problems.

> For your problem with using sunlabel to partition a disk for use in NetBSD
> it might make sense to add some ioctl to the disk drivers to invalidate
> the incore label.

I have an atari, no sun ;-) Anyway, I was trying to avoid yet another ioctl.
My idea was to explicitely add a field to the disklabel structure that
indicates if this label is meant to be sticky or not.  If the flag is set,
the driver does not clear the in-core label on the last close nor does it
overwrite the in-core label on the next open. If the flag is clear, historic
behaviour (say pre-1999 ;-) is retained.

> However I'm not really sure that it's worth to support this; it probably
> makes more sense to enhance or rewrite our standard disklabel utility to
> provide the same functionality/user friendliness as does the one you
> prefer.
> 
> > Oh, on tech-kern a simular discussion popped up subject: 'sd rereads'.
> 
> Yes, I was just going to reply to that one, too, but Manuel beat me to it :-).

It now looks like a day in another timezone has passed ;-)

Leo.