On Tue, 22 Sep 2009, Ethan Quach wrote: >>> usr/src/cmd/Makefile.cmd >>> ------------------------ >>> 45 - nit - Why not just call this ROOTLIBSVCSHARE ? >> >> Is there precedent to call it ROOTLIBSVCSHARE instead? > > Just that some of the other ROOT*** variables are named as > their explicit path values. e.g. /lib/svc/method is > ROOTLIBSVCMETHOD
Makes sense then, changed. >>> usr/src/cmd/auto-install/svc/manifest-locator >>> --------------------------------------------- >>> 78-82, 102-104 - This should be done in get_manifest itself. >> >> I don't think get_manifest should make the assumption >> that it can get called just on the console. > > That's fair enough then. Though I have a couple of > additional questions then ... > > 1) > TERM=sun-color > export TERM > > Does this work properly for all cases, even when a user > is tipped in via serial line? Yep, it does. > 2) > exec </dev/console >/dev/console 2>&1 > > Is this a workaround for some known issue? If so, do you > know what? I don't actually know if this a workaround for something but it is needed for prompts to be displayed on the console. I did try your suggestion of specifying the "need_session" property in the SMF manifest as a way of indicating that the manifest-locator service can have controlling access to the console but it doesn't work. I still don't see the prompts on the console. So, I think I'm going to stick to what I have for now. >> In this >> specific case, the caller knows that it will be called in a >> certain scenario so it seems that the caller should do >> the appropriate setup prior to calling get_manifest. >> >>> 57-60 - Can we loop and process instead of processing a set >>> number of args? >> >> Sure, I can look into that. I actually ended up not implementing this change because I didn't see the benefit of doing so given the use of a single 'prtconf -vp' call to get bootargs; and, us needing to reference only two of the arguments. If at some point there's value in processing all of the args, this can be extended pretty easily. >>> usr/src/cmd/slim-install/svc/live-root-fs-minimal.xml >>> ----------------------------------------------------- >>> 87 - Is there any other way of making this determination >>> for x86? >> >> I don't think so, our code uses the same check all over >> the place. > > The code is in other places, but it seems this is the first > place we're using it to determine whether or not we're booted > from media or from net. > > My concern is that we're using an implementation detail to > imply meaning of something that's not necessarily related. > > What happens if a user edited the grub menu entry when > booted to AI bootable media and added 'install_media' ? > (I think we want this case to actually work eventually, > to support users who need to use the bootable media as a > boot-shim to get around DHCP or other network limitations.) > > If parsing the boot args is our only means of differentiating > right now, could we just define a new boot arg to determine > this explicitly? e.g. media_boot=true or something? Okay, I'm bought into this and I've made the code changes to support media_boot=true. I am still uncomfortable with the way we make this determination on sparc (check for the existence of a certain device) however. But I can't think of a better way of doing it either. Alok
