I think this is a false dichotomy; the way I'd probably implement it if I set out on such a project is neither of these, but a mixture, as follows:

- knowledge of various kinds of disklabel is built into disklabel drivers in the kernel. But this knowledge is kept encapsulated.

- if being able to have everything automatically appear is important, you also write a probe routine that you put in the kernel.

- but you do not try to activate these disklabel devices, or the probe, automatically from the kernel, except maybe once someplace near the end of the boot sequence. Instead, you have someplace a daemon that receives notifications when a new disk appears and tries to work out something intelligent to do with it. (The probe routine could be here instead of the kernel, too, maybe.)

As far as the other problems you bring up:

- if you weren't worried about kernel bloat, you could have one of the device nodes generated by the disklabel hold some abstract representation of the partition table, and automatically intercept and handle modifications appropriately.

- if you were worried about kernel bloat, you just might disallow writing to the partition table while a partition device was active. This would be easy, because /dev/wd0 would be busy while the partitions were available, and none of the other /dev/wd0* would make the partition table visible. A slightly more dangerous option is to create a /dev/wd0-table device that held the table and automatically forced a reread if the table was modified. You also require a process to issue an ioctl before writing the table, to keep it from happening by accident.

- you don't have any trouble with booting; either you put the partition table probe code in the kernel (IMO a perfectly reasonable place for it), or configure the boot drive's partition table format at kernel build time, or require require the boot drive to have some (probably machine-specific) particular partition table format.

- read-write locking of partitions is exactly the same problem as it is right now. That is, it's messy, but not directly relevant.

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message