boot0cfg -s vs. GEOM_PART_*?
Marcel Moolenaar
xcllnt at mac.com
Tue Feb 17 16:19:58 PST 2009
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
More information about the freebsd-current
mailing list