Date: Mon, 21 Apr 1997 14:15:22 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-hackers@freebsd.org Subject: Re: disklabel -- owner? Message-ID: <199704212115.OAA23175@phaeton.artisoft.com> In-Reply-To: <19970421203928.LG60164@uriah.heep.sax.de> from "J Wunsch" at Apr 21, 97 08:39:28 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > One problem, I think, is with device organization: I think it's
> > idiotic to have 'c' and 'd' used the way they are; one can be
>
> Hmm, but that's not FreeBSD you're talking about, is it? The
> magicness of the `d' partition went away with the slice code in
> 2.0.5R.
>
> The magicness of the `c' partition simply solves the chicken-and-egg
> problem for an unlabelled disk. I agree that it doesn't necessarily
> need to be a pseudo-partition, but either way, you'll end up with
> basically the same as there is now (since you need a minor number for
> it anyway), so why change the traditional method? POLA.
You don't need a minor number for it at all, *if* you reexport devices
based on the fan-out from a DOS partition table.
For instance, say I have a /dev/wd0; if it has DOS partitions, then
I get /dev/wd0a, /dev/wd0b, /dev/wd0c, and /dev/wd0d, one for each
partition.
I'd prefer this be hierarchical, actually, but that's negotiable...
it's going to be hierarchical any way you look at it, and if you
want to make the namespace have an ambiguity because you want to
avoid putting a hierarchy seperator ("/") in there, well, that's
your business.
Basically, when a device probes true, it "arrives". I'm going to
call this "arrives" from here on, because the "arrival" code needs
to be shared with some events other than just probing true.
So wd0 "arrives" and has a DOS partition table on it.
The devfs exports the device node "/dev/dsk/wd0", and that's "the
whole disk". Note that it's a namespace thing, not a minor number
thing.
The devfs, after it exports the node, but before it returns from
handling the "arrival" event (returns to the probe code) calls
(this is all pseudocode):
dev_arrive( dev_t parent, dev_t dev, name)
{
struct log_to_phys *ltpp;
dev_register( parent, dev, name); /* ("/dev/dsk", dev, "wd0")*/
for( ltpp = mapping_layer_list; ltpp != NULL; ltpp = ltpp->next) {
if( ltpp->reconize( dev)) {
/* this mapping layer recognizes this dev...*/
break;
}
}
/*
* NOTE: CLEVER FUTURE EXPANSION
*
if( ltpp == NULL) {
/*
* device not recognized as containing a partitioning
* schema. Devices which "arrive" without partitionig
* schema on them are probably file systems -- attempt
* to automount the device using the "last mounted on"
* field, if present in /etc/fstab and not mounted.
* Later, we will always mount and use /etc/fstab solely
* to map a mounted FS into the root FS hierarchy...
*/
...
}
*
*/
}
The ltp_dospart.c looks like:
/*
* ID string; displayed by user interface when offering up what
* types of partitions you are allowed to create...
*/
static char *dospart_idstring = "DOS Primary Partition Table";
static int
dospart_recognize( dev)
{
int rv = 0; /* default: not recognized*/
int i;
/* read what would be the partition table if it was there*/
...
/* verify is valid*/
if( ((dos_part_table *)data)->sig != 0xaa55)
goto fail;
/* allocate a DOS-partitioning style ltpp record...*/
dltpp = ...;
/* copy the partition table data into the record*/
memcpy( dltpp->dospart, data, sizeof(dos_part_table));
/* fill out the rest of the record...*/
dltpp->ltp.id = dospart_idstring; /* char */
...
/* for each valid partition, add a device*/
for( i = 0; i< 4; i++) {
dev_t newdev;
char newname[ 2];
/* is this partition valid?*/
if( dltpp->dospart.id[ i] == 0)
continue; /* no; skip*/
newdev = devfs_mksubdev( dev, offset,
length, (ltpp)dltpp, i);
newname[ 0] = 'a' + i;
newname[ 1] = 0;
dev_arrive( dev, newdev, newname);
}
rv = 1; /* this l-to-p driver eats this device*/
fail:
return( rv);
}
...
static struct log_to_phys dospart = {
dospart_recognize, /* recognize partition*/
dospart_read, /* read slice data*/
dospart_write, /* write slice data*/
4, /* max slices*/
LTOP_IS_LINEAR, /* linear; can collapse mappings*/
... /* etc.*/
};
/* register ltop layer with system...*/
SYSINIT( ... dospart ...);
Actually, theres no reason this couldn't be handled without devfs... but
it's more complicated to do the MAKEDEV to make it work without devfs
(about equal to as complicated as it currently is without devfs).
Then you define an l-to-p mapping for:
DOS partitioning
DOS extended partitioning
FreeBSD disklabel partitioning
OpenBSD disklabel partitioning
SVR4 VTOC partitioning
DEC OSF partitioning
HPUX partitioning
Solaris partitioning
OnTrack Disk Manager 6.x/7.x LBA support
BAD144 handling (not linear - media perfection layer)
CCD stipe set management
etc., etc.
And everything just comes up as appropriate devices, automagically. It
even automatically hides the differences between a "dangerously dedidcated"
and a normal install...
You need to support mapping into the correct ltop mapping layer for a
given device by retrieving the ltpp and entry index passed to create
the device in devfs_mksubdev() (or the non-devfs equivalent) so that
you can mainpulate an existing table (read/write/edit).
You also need to be able to retrieve the "depends on" information so
you can warn when you delete a DOS partition that has BSD partitioning
on it.
Finally, you need to be able to enumerate the available l-to-p layers
so that you can apply them to a device without any existing partitioning.
You need *at least* these ioctl's:
LTOP_READ Read partitioning information. Assumes that
the partitioning already exists. The ioctl()
will return -1 if there is no schema associated
with the device.
LTOP_WRITE Write partitioning information. Assumes that
the partitioning already exists. The ioctl()
will return -1 if there is no schema associated
with the device.
LTOP_STAT Get meta-information specific to the partitiong
scheme for the current device. Assumes that
the partitioning already exists. The ioctl()
will return -1 if there is no schema associated
with the device.
LTOP_ENUM Enumerate registered partitioning schema; this
is a get-next interface. The first time you
call this interface, the index in the argument
struct must be 0; it is updated when the id
of the schema (a string) is returned. The
ioctl() returns -1 when there are no more schema,
0 otherwise.
LTOP_INIT Takes a registered partitioning schema and a
device, and associates the schema with the
device (it does this by internally enumerating
the available ltop layers to find the layer for
the specified schema, and calling the schema
specific 'read' with a (dev_t)-1 to get a
"default, uninitialized" schema written to the
device).
LTOP_DEL Removes the registered partitioning schema by
writing all zeros to the data area for the
partition type information. All subpartition
data areas must be deleted via LTOP_WRITE or
this command will be refused.
And assuming you handle the data record iteration properly, you should
be able to support all types of partitioning with the same utility,
which operates on a device hierarchy (you will need to support 1-n
sets of partition data being shoved across the interface for any given
type of partitioning. The value of n is obtained via LTOP_STAT.).
Note that the LTOP_WRITE takes the place of a user space writing on
a disk.
The vnode configuration needs to go through an "arrival" to allow this
to still be applied for FS floppies for install/fixit, etc..
One utility... makes the problem a bit simpler, no?
If you wanted to force relationships, you could have the layers know
about their parent's by going through the 'parent dev' to see if the
parent is acceptable to them... for instance, a "DOS primary partition"
probably wants its parent to be a real device, and a "DOS extended
partition" probably wants its parent to be a "DOS primary partition".
A "BSD disklabel" may or may not prefer that its parent be a "DOS
primary partition" or "DOS extended partition", etc..
You will probably (if you have devfs) want newly created devices to
"arrive" or newly removed ones to "depart" as a result of the LTOP_WRITE
invocation.
You will probably (eventually) use this same arrival/departure mechanism
for nomadic computing (roaming, docked + no net, docked + net, roaming +
dialup net, roming + transient IR connectivity, etc.).
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704212115.OAA23175>