boot0cfg -s vs. GEOM_PART_*?

[Marcel Moolenaar]

On Feb 17, 2009, at 11:38 AM, Ulf Lilleengen wrote:

> On Tue, Feb 17, 2009 at 10:29:10AM -0800, Marcel Moolenaar wrote:
>>
>> On Feb 17, 2009, at 3:46 AM, Bjoern A. Zeeb wrote:
>>
>>> with a fresh kernel and world from last night I get:
>>>
>>> dopt# boot0cfg -s 3 ad4
>>> boot0cfg: /dev/ad4: ad4
>>> boot0cfg: /dev/ad4: ioctl DIOCSMBR: Inappropriate ioctl for device
>>>
>>> is this GEOM_PART_* fallout and can it be fixed?
>>
>> boot0cfg is not (yet) supported by GPART. It should not
>> be too hard:
>> 1.  We need to expose the current bootcode through
>>     kern.geom.confxml
>> 2.  boot0cfg grabs the bootcode from the XML, makes
>>     the changes in memory and then uses existing
>>     g_part ctlreq to update the bootcode.
> Mhm, this seems to be a good way to do it. Also, fdisk and bsdlabel  
> might
> need a sweep as well.

That won't be as easy as boot0cfg. Both fdisk and bsdlabel
do all partitioning operations in memory and then expect to
dump/write the blob. This is not how gpart works, so there's
a mismatch in paradigm.

With respect to partitioning, I'd rather we focus our
attention to a more user-friendly tool. The geom tool is
really low-level and could use some UI "fodder".

Also, I started writing pe(8) a while back, which is
a ncurses-based partition editor. I think a nice
partitioning tool would be good to have.

For those interested in pe(8), I have diffs here. It's
nowhere near useful, but it should give a first glipse
of what I was thinking of:
	http://people.freebsd.org/~marcel/gpt.diff

Certain aspects of the code show early thinking and has
been implemented differently in gpart nowadays... :-)

-- 
Marcel Moolenaar
xcllnt at mac.com