In message <20050706181310.GA5167_at_ns1.xcllnt.net>, Marcel Moolenaar writes: >On Wed, Jul 06, 2005 at 07:58:23PM +0300, Maxim Sobolev wrote: >A completely different approach that helps to abstract the details >of the slicer (i.e. MBR, GPT or BSD) is a functional interface. >Have a device special file for each slicer and implement ioctl(2) on >them for adding, removing, resizing etc of partitions. That way >GEOM gets to see requests like: > "remove slice number 3, please" If you want to implement this, don't add bogodevices with magic ioctls, use the g_ctl API instead, it is designed for this kind of thing. The main reason I have not implemented something like what you suggest is that I don't think it makes life that much easier for us to put it in the kernel. First of all, it is code which is extremely seldomly used, and it is not a trivial amount of code to add, so the cost/benefit is dubious at best. Second, there is no real advantage to doing it in the kernel that cannot be realized equally or better entirely in userland. >Potentionally we could end up with a single tool to manipulate any >and all slicers, provided we define the ioctl interface correctly. My original hope was that this tool would be called geom(8) and be the unified management tool for all GEOM classes, not just slices. I can't see why it would have to matter to the user what kind of GEOM class implements a given function, slicing, mirroring or RAID3, the commands to fiddle it should be the same. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk_at_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.Received on Wed Jul 06 2005 - 17:43:44 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:38 UTC