Subject: Re: Moving getmaxpartitions to libc
To: Wolfgang Solfrank <email@example.com>
From: Leo Weppelman <firstname.lastname@example.org>
Date: 09/02/1999 07:32:11
On Wed 01 Sep 1999, Wolfgang Solfrank wrote:
> > 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
> > 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 ;-)