On Wed, Jul 06, 2005 at 07:58:23PM +0300, Maxim Sobolev wrote: > > I wonder if there cound be a "better" fix. Yes, there is. > Another good feature to have is the ability to tell geom_mbr/geom_bsd > (via sysctl or ioctl) to make in-core copy of the table/label and > release any locks it helds on this region, so that it can be replaced > with completely different version if needed via simple write(2). The > same applies to the disklabel class. This is really necessary for some > cases, when the user or the program know he/is trying to do. Yes, I've been arguing that. 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" Those are very easy to validate. Much better than getting a block of raw bits and having to figure out what exactly changed and if something's not acceptable. The request to add a slice is understood by any and all slicers, so you solve the problem generically, not by kluging the one and only slicer your brain is fixated on and leaving the problem unaddressed for every other slicer. Concretely: Suppose we have a SCSI disk with a MBR and a BSD label. We'll have the following device special files: da0 da0.mbr da0s1.bsd da0s1a da0s1b da0s1c da0s1d da0s1e da0s1f da0s2 da0s3 da0s4 Potentionally we could end up with a single tool to manipulate any and all slicers, provided we define the ioctl interface correctly. Just another thought, -- Marcel Moolenaar USPA: A-39004 marcel_at_xcllnt.netReceived on Wed Jul 06 2005 - 16:13:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:38 UTC