Date: Tue, 06 Feb 2007 18:00:19 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Marcel Moolenaar <xcllnt@mac.com> Cc: geom@FreeBSD.org Subject: Re: New g_part class Message-ID: <94029.1170784819@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 06 Feb 2007 09:38:13 PST." <835A2C66-BBEB-4A19-B6A3-A60E17572604@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <835A2C66-BBEB-4A19-B6A3-A60E17572604@mac.com>, Marcel Moolenaar wri tes: >Editing is of course still done in user space. The application >is responsible for providing the right values to the kernel and >the kernel will simply fail the operation if something is not >correct. > >The reason why the kernel supports the application with these >verbs is simple: the kernel needs to be involved because the >application cannot write to disk directly in all cases. Right, but the current scheme handles this by asking the kernel to write the finished metadata image, which the kernels taste functionality can be used to validate and parse. That way, the kernel doesn't have very rarely used code for editing the metadata, only the necessary code to parse and configure based on the on-disk metadata. >Libdisk is badly designed (if at all) and badly implemented [...] No argument there, and that's from the guy who slapped it together between changing diapers :-) >It's the application that should exhibit artificial intelligence >(if at all), not the kernel. So what is the advantage of editing the metadata in the kernel instead of userland ? Userland still needs to know about the entrails of each slicer method, so what is the benefit of your scheme, compared to editing the metadata in userland and just having a "write new metadata" verb ? If you could have writte a generic partitioning tool that didn't know about the different formats, then I could see the point, but having to have the code both in userland and in the kernel makes little no sense to me, in particular given how seldom it is used. >> BSD labels represent a particular nasty case, because of the >> possibility that the label sector is inside on a partition. I will >> advocate that if we go this direction, we should not migrate BSD, >> but leave it behind to die, eventually. > >I wouldn't mind if BSD labels die. At this time the g_part class >already supports the notion of leaf partitioning schemes, of >which BSD will be one. Leaf schemes cannot have sub-partitions. I'm not sure I understand the need for this restriction ? The problem with BSD labels is that you need to intercept writes to the metadata part if one of the partitions allows this to happen. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?94029.1170784819>