[TEST/REVIEW] boot0cfg/fdisk issue fix

[Marcel Moolenaar]

On Jul 6, 2005, at 2:50 PM, Poul-Henning Kamp wrote:

> In message <20050706212043.GA6215 at ns1.xcllnt.net>, Marcel Moolenaar 
> writes:
>
>> That would be better, yes. Would a slicer-specific API that's
>> implemented in terms of g_ctl be welcome in libgeom? It would
>> help convert the existing tools to use GEOM more directly,
>> which helps the convergence of the functionality into a single
>> tool: geom(8). For geom(8) it would then probably be a class
>> library, right?
>
> My worry about this is that the "DWIM" aspect will render most
> generic stuff obsolete.

Doesn't that depend entirely on having the necessary abstractions
and having those translated to hard "currency" at the right time?

Where "the right time" is not too soon (i.e. at a level too high,
say the UI) or too late (i.e. at a level to low, say the hardware
driver).

> For instance, in a MBR, if I say
> 	"create ad0s3 max"
> in order to use the largest free slap of space, that end sector
> number should be rounded down to a cylinder boundary and the start
> sector number to a track boundary if it would otherwise occupy the
> first track.

But this example merely demonstrates that sizes and offsets are subject
to normalization at the slicer level and that any attempt to conclude
anything at the levels above it prior to the normalization is moot. It
doesn't show that "create ad0s3 max" can not be implemented using a
generic API. If you add a normalization function to the API that lets
slicers round up or round down based on geometry constraints, then
at the higher levels you don't have to worry about it (other than
making sure that you work with normalized values).

We already have the magic in libdisk. We only need to beef up the
interface so that it isn't only usable by sysinstall. This might
be a good way to prototype and work towards a common API and a
common tool.

-- 
  Marcel Moolenaar         USPA: A-39004          marcel at xcllnt.net