Date: Tue, 06 Feb 2007 07:36:15 +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: <89489.1170747375@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 05 Feb 2007 22:40:52 PST." <BA11EE01-2B86-42EA-94AC-6F977EF7E680@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <BA11EE01-2B86-42EA-94AC-6F977EF7E680@mac.com>, Marcel Moolenaar wri tes: >All, > >I sent a diff to re@ for review, but I figured this is also a good >place. >The diff can be found here: > http://mail.xcllnt.net/~marcel/g_part.diff > >The g_part class is a generic partitioning class with a rich set of >g_ctl verbs for creating and modifying partition schemes. I did think about doing things this way originally, but I couldn't convince myself that it would make more sense to do so and I'm still not convinced I see a net benefit from sticking all the slice edititing code into the kernel. First there is obviously the size/bloat argument. Currently the slicers only have to have the taste functionality. Writing new layouts can generally reuse the same code for the permission check, Although MS-DOS extended partition tables are an example that cannot. Considering the fact that editing can be done equally well in userland, what is the rationale or benefit of putting the code into the kernel, to deal with very infrequent operations to change the disk-layout ? My second concern is if we might still have to replicate all the error detection in userland, if we want to retain the option for atomic changes, ie: allowing users to specify a set of changes (with disklabel -e for instance) before committing them all ? Third, I doubt this will prove as useful as expected in writing partitioning tools. For instance, how will the partitioning tool know about the geometry/alignment restrictions of MBR ? If you study libdisk, you will find that there are a couple of DWIW functiosn that translate the users wish for a NN MB size thing into a properly aligned and sized thing for the MBR. Where does that functionality live in this situation ? Does the kernel return "no good, try these parameters instead ?" or does it silently truncate and align ? So I would advocate that you try to implement the MBR method next and then do a prototype disk-editor utility, so we can see if this actually makes life easier or not. >schemes like MBR, BSD, SUN and/or PC98. 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. Poul-Henning -- 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?89489.1170747375>