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>