On 01/24/11 14:39, Keith Mitchell wrote:
5.3.2: Rather than splitting the registration path; can we
leverage the registration path? We have support for registering
*functions* as well as *classes* - so long as whatever it is
returns an instance of a checkpoint, whether it's a class
constructor or function doesn't matter. So, would it make sense to
register a function that will decide which kind of checkpoint to
return?
Are you suggesting to register a function instead of a class
because you want to isolate the knowledge of whether
we are running a net-booted installer or a media booted installer
from the installer application?
I think this is a great idea. Going through how things will work
if we register a function, I have the following
algorithm in mind. Let me know if this is not what you have in
mind as well.
When the registered function is executed, it will determine whether
we are net booted or media booted.
If net booted, the special /.cdrom/.media-transfer directory will
be downloaded from the server,
and the NetPrepareMediaTransfer checkpoint will be instantiated and
returned. If booted from media,
the media's prepare transfer checkpoint will be instantiated and
returned.
The execute() of either NetPrepareMediaTransfer or
PrepareMediaTransfer
will populate the DOC with the content of software.xml that's
downloaded or from media
accordingly. In the current version of my spec, populating the DOC
is done by the installer app,
but I think the above is better.
That sounds more or less like what I was thinking. Out of curiosity,
are you planning on using the dot-files to determine boot method
(.livecd, .textinstall, .autoinstall), or a different method?
By the time the installers are run, I believe I can determine the
boot method without relying on
on the .livecd, .textinstall and .autoinstall files.
I am planning to determine how we are booted based on how the zlibs
are mounted.
For example, if we are booting from media, solaris.zlib will be
mounted from /.cdrom/solaris.zlib
However, if we are booting from net, solaris.zlib will be mounted
from /tmp/solaris.zlib.
This creates a 'contract' of sorts between how the .zlibs are mounted
and how the installers run. While both are contained within
slim_source, perhaps the concept could be expanded one more level:
check which SMF services are enabled/disabled, perhaps. If
filesystem/root:media is enabled, it's a media-boot; if
filesystem/root:net is enabled, it's a net-boot.
- Keith
I completely forgot about the SMF services. Checking for whether
filesystem/root:net
or filesystem/root:media is enabled is a much cleaner solution.
Thank you for the suggestion.
--Karen
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
