On 07/14/10 01:14 PM, Alok Aggarwal wrote:
On Wed, 14 Jul 2010, Sarah Jelinek wrote:
On 07/14/10 12:39 PM, Dave Miner wrote:
On 07/14/10 10:54 AM, Sarah Jelinek wrote:
...
- Are the existing GRUB menu customizations that are specified at a
high level expected to move to arguments to the checkpoint that
consumes them?
That's what I was thinking. I figured that this would be easier. I
didn't want to clutter the schema with this. If the user wants
modifications it seems as if they could provide this on the
checkpoint
line as args. However, if others think it should be in the schema
I am
open to that.
I have decided that this will be a configuration option, that is
'grub'
as a type and the user has to provide an external reference to a file
that has the grub modifications to apply. This seems to make the most
sense.
Guess I'm wondering how this will work - currently we use tags in
the manifest to structure what the grub checkpoint does, so will it
need to define a small schema to replicate that, or something else?
I could provide a schema that allows users to specify this. We have
to provide them a published format for providing us this data.
Enabling them to provide the grub args to the checkpoint wouldn't
really be any different in terms of us having to tell them what the
form and keywords need to be.
I think the problem with this approach though is
that how would the grub specification get parsed
now? Would the Configuration DataObject class'es
from_xml need to source the grub file and somehow
facilitate it's parsing?
Much like the SMF profile needs to be parsed if externally referenced,
or the zone configuration data, we would have to parse this, if
specified, as part of the checkpoint. Or, if we have a configuration
type of 'grub' we could have the MP parse it as well, as part of the
initial parsing.
With the current approach, the parser parses the
grub section along with others and the grub_setup
checkpoint simply references that information.
I can certainly do it this way, if this seems better, easier, etc...
sarah
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss