Subject: Re: Some help with disklabel please?
To: None <current-users@NetBSD.ORG>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 08/08/1995 18:08:49
I'm mailing this follow-up to -current as it touches on a topic I've
been wondering about, and which (IMHO) should be addressed at a full-
system level (not just port specific).
> > So. . . Two questions: First, how do I use disklabel under MacBSD; do I
> > need to build something like a disktab file first; or is it just not
> > functioning yet? Second, is there a man page that lists the allowed
> > filesystem types?
> 1) It's not functioning, yet. I am still thinking about how to handle
> this. I'm currently leaning toward continuing an improved version of
> the current system for disks that will share with MacOS. On disks that
> are dedicated to BSD, however, we will handle the standard disklabels.
I've been wondering about this idea for a while. NetBSD knows how to deal
with a lot of file systems, including native ones (such as dos and the
Amiga's OS (I think)). But there is no support for knowing about different
kinds of disks. So I could compile the dos filesystem code on my mac, but
I could never hook a dos hard disk up to my Mac as the disktab won't
find partitions correctly.
So what would it take to change the drive probing so that all the ports
could (if so configured) sense the drive type and then disklabel accordingly?
Basically what I envision is:
1) sdXc gets set up to the full disk (all ports leave the full disk in c, no?)
2) A series of routines get called to figure out what kind of disk the
drive is. The routine looks for its magic cookie and returns true
if it matches.
3) After a match, a companion routine gets called to build the disktab.
Actually, if the port doesn't want the whole disk in c, the port
could change it at this step.
If a drive fails all tests, it gets a BSD disktab. On formats where we
feel like partitioning, we can write out the disklabes, too. Each port
would be responsable for writing the sensor and disktab maker for it's
native OS. But they've already done this, so the only effort is to
modularize the code and to coordinate things.
What do people think? Though I'll agree that this feature mightn't get
used often, I think it might occasionally really-save-someone's-butt in
a multi-vendor environment.
I actually wouldn't mind working on this, though I am not really up to
speed on filesystems, etc, and thus might not be the best person to turn
loose on it.