Re: boot0cfg -s vs. GEOM_PART_*?

On Feb 17, 2009, at 2:35 PM, Poul-Henning Kamp wrote:

> In message <E842D9CC-DEA8-4198-825F-46ED29437AE0_at_mac.com>, Marcel  
> Moolenaar wri
> tes:
>
>>> In message <D29A6039-5105-49CB-B613-DD561CDD1A89_at_mac.com>, Marcel
>>> Moolenaar wri
>>> tes:
>>>
>>>> For boot0cfg this is probably acceptable, because
>>>> it only operates on MBRs. But as a generic solution
>>>> this won't work.
>>>
>>> Then pick up the bootcode via ioctls, it does not belong
>>> in the confxml sysctl.
>>
>> On what grounds doesn't it belong in the confxml?
>
> Because the way we (currently) implement confxml and the uses it is
> put to would generally be greatly inconvenienced if you have to  
> include
> 8KB of hexdump data in the xml stream.
>
>> And how do these not apply to ioctls?
>
> ioctls was designed and built to move binary blobs across the
> userland/kernel barrier to and from I/O devices.

I'll consider this.

 From my perspective:

o   The fact that we have a separate OAM interface that
     doesn't use file descriptors (at the application
     level), having to use ioctl(2) all of a sudden is...
     well... odd. Likewise for regular read/write. Just
     for boot code do we need o worry about mapping GEOM
     names to device special files.
o   XML is ideally suited for any and all kinds of data.
     Since all of the information related to GPART is
     obtained through the confxml, it seems inconsistent
     to not have the boot code obtained in that manner.
     To me it becomes a question of inconsistency vs
     inconvenience and inconsistency is always worse.
o   geom_getxml(3) allocates 1MB up-front for the XML.
     Either the XML is in that order of magnitude, in which
     case up to 10KB or so for boot code is insignificant,
     or 1MB is way too large and we have plenty of room for
     10KB of boot code. Either way, it looks like it was
     envisioned that the XML can be large. How inconvenient
     can 10KB be, objectively, I wonder.

-- 
Marcel Moolenaar
xcllnt_at_mac.com