Re: [TEST/REVIEW] boot0cfg/fdisk issue fix

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.

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.

You have to put that MBR magicness, BSD magicness and GPT, Apple,
Sun magicness *somewhere* in the end, and what's more, you have
to be able to give the user a sensibly detailed explanation of
what happened and why.

If we are willing to forgo that kind of DWIM, then I don't see a
problem, but quite frankly: I hate having to add obscenely large
sectornumbers in my head myself, so I suspect we want at least some
level of DWIM.

And while diskpartitioning sounds like a great OO programmin excercise
or as somebody who shall remain uname suggested: "use PROLOG to
resolve the constraints in optimal fashion", one should not forget
that this is a seldomly used system administration tool.

It is simply not worth spending a year of your life on (IMO).

So I tend to lean towards a model where we fix the major loosage
in the existing tools (mostly fdisk really) and leave it at that.

With respect to the current tools, fdisk just sucks.

The userinterface of bsdlabel is much better (the save/restore thing
and the use of the users own editor is great).

Sysinstall is not my cup of tea, but does give some of the visual
feedback DWIM that people want.

With all that discouragement out of the way, if somebody wants to
do more about it, they are more than welcome.

Burned by my own experience, I would advocate a lot of prototyping
because there doesn't seem to be a free lunch anywhere in this area.

Poul-Henning

-- 
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.