Subject: Re: Some help with disklabel please?
To: Bill Studenmund <email@example.com>
From: Jason Thorpe <firstname.lastname@example.org>
Date: 08/09/1995 15:24:49
On Wed, 9 Aug 1995 14:51:56 -0700 (PDT)
email@example.com (Bill Studenmund) wrote:
> > Indeed, it's arguable that all NetBSD ports should support the disklabel
> > format of all other NetBSD ports of at least the same byte order...
> I think that all ports should be able to deal w/ all byte-orders. Why?
> I think everybody should be able to read DOS disks as they are so
> prevelant. Yes, many people think DOS is evil. Unfortunatly it is
> becoming a standard. Also, being able to support variable-endianness
> would complicate things. But the ISO CDROM code does this, so we'd
> have a working model for int-swapping routines, etc.
Note I said "at least the same byte order". :-) Yah, cd9660 does this,
but I've gathered from a discussion or two that it's non-trivial to do
this with FFS, at least. msdosfs may be a different story ... unknown.
Also, your reasoning goes that all ports should also be able to read
SunOS disks (which was my original motivation; I had to plug one into my
hp380) since they're so prevalent.
I don't dispute that this is a worthy goal. It's just not as easy as one
> > Ummm ... well, given that disklabels are _not_ UFS-specific, this is a
> > less-than-desirable place to put them. My code lived in
> > sys/kern/subr_disklabel.c.
> I'd tend to agree with you on this point. Maybe sys/kern/disklabels or
> sys/miscfs/disklabels? Though exactly where is not a big deal, IMHO.
Why do you even need a directory?
> > * At least in the MI SCSI code, the disklabel is read then the
> > device is opened, not when it is probed/matched/attached.
> My ignorance shows at this point. When _which_ device is opened? One of the
> sdXY's? But don't you need a disktab to see if a device really does
> anything? Also, is the timing of when the disklabel gets read critical?
> As long as it's after the ability to talk to the drive exists, and before
> people want to use the partitions, does it make a difference?
No, you don't need a `disktab' file ... that's only used by a few
user-land utilities whenever a disklabel isn't available (like, when
newfs'ing floppies, for example). disklabel(8) can also use it to
install `default' partitioning on new disks, but given that /etc/disktab
is not really up to date with the latest disk hardware releases, it's not
particularly useful anyhow.
* open the device. Make sure the partition info is a up-to-date as can be.
sdopen(dev, flag, fmt)
int flag, fmt;
struct sd_softc *sd;
[ . . . ]
/* Load the partition info if not already loaded. */
SC_DEBUG(sc_link, SDEV_DB3, ("Disklabel loaded "));
[ . . . ]
While is says "if not already loaded", the in-core copy of the disklabel
is updated _every time_ a partition on any given disk is opened, as far
as I can tell.
Also note, that if you swap to sd0b, for example, sdsize() gets called by
the swap code, to get the size of the partition. This causes an open/close
sequence on that partition, which causes the disklabel to be updated.
> > * Not all ports keep the `whole disk' in the `c' partition.
> I don't think this will be a problem. The disktab reading routine
> can read whatever it needs off of "c" to build a new disktab. It then
> closes "c", installs the new disktab, and away it goes. At that point,
> the port does whatever it wants.
Ummm ... no, because `c' doesn't mean the same thing on, for example, the
i386 port and the hp300 port (two of the four I work with the most). And,
that exactly are you reading off of `c' to build a new `disktab'?
> I.E. most system's would have something in d, and the disk in c. On
> a platform that does it different, the something would go into c, and
> the whole disk into d.
Not necessarily ... the i386 port, for example, keeps the `whole disk' in
`d', and `all of NetBSD's portion of the disk' in `c'. So, a simple swap
doesn't work. Not to mention, that sort of violates the convention
behind partition naming...
> Why do some ports not keep everything in c?
Another point to make here, I suppose, is that not all ports that use
NetBSD-format disklabels keep them in the same place (for various
reasons). Just something else to think about :-)
Jason R. Thorpe firstname.lastname@example.org
NASA Ames Research Center Home: 408.866.1912
NAS: M/S 258-6 Work: 415.604.0935
Moffett Field, CA 94035 Pager: 415.428.6939