* Evan Layton ([email protected]) wrote: > On 4/21/10 8:23 AM, Dave Miner wrote: > >On 04/21/10 12:45 AM, Evan Layton wrote: > >>On 4/20/10 10:18 PM, Seth Goldberg wrote: > >>> > >>> > >>>Quoting Evan Layton, who wrote the following on Tue, 20 Apr 2010: > >>> > >>>>On 4/20/10 10:10 PM, Seth Goldberg wrote: > >>>>> > >>>>> > >>>>>Quoting Seth Goldberg, who wrote the following on Tue, 20 Apr 2010: > >>>>> > >>>>>> > >>>>>>Well, I was just suggesting the minimum set of files needed to at > >>>>>>least show a boot panic :). unix, genunix and the boot archive are > >>>>>>that set, I believe. > >>>>> > >>>>>I should say that genunix will be loaded from the boot archive, so > >>>>>testing the validity of genunix in the boot archive (i.e. via loopback > >>>>>mounting it and running `file' or elfdump on genunix (admittedly, both > >>>>>are not great tests, but they're something -- other suggestions are > >>>>>welcomed :))) might be a better idea. > >>>> > >>>>Ick, that's really not something I really want to be doing from a C > >>>>library if I can avoid it... > >>> > >>>I hear ya. I'm just suggesting checks that would made validation more > >>>airtight. Most of them are just calls to system() and checking the > >>>return values. > >> > >>I don't think we can really get to "airtight". ;-) > >> > >>I'd really rather not add this kind of check that requires running > >>something like elfdump. It doesn't really "ensure" that genunix is > >>valid only that it is more likely to be valid. However that "more > >>likely to be valid" check may be something we should do anyway. If > >>folks feel that we should do this check I'll add that as well. > >> > > > >I think you have two possible requirements, which likely lead to > >different solutions: > > I agree that based on the comments and what you've put here that > these are the requirements. > > > > >- don't list datasets in "beadm list" that really aren't BE's. Any > >checks here need to be cheap, as systems with a few dozen BE's are known > >to exist in the wild and having a listing take many seconds on such a > >system would be disagreeable (beadm list on a system with 50 BE's takes > >.25s with the existing implementation). > > This is what I was thinking when I coded the fix and this is what > the fix handles. However as you point out this really isn't enough > for the activate case. > > > > >- don't activate BE's that aren't bootable. Activation can be reasonably > >expected to take a few seconds, so more time-consuming tests are > >allowable, and you're only acting on one BE. I don't think there's any > >scenario in which "airtight" is possible, though; you'd be into running > >things like "pkg verify" to get very close, and even that would be > >problematic in the face of developer use of (cap-I) Install for kernel > >work. > > I agree that activate should be treated differently and that we should > do the extra checking in this instance. I also think that this check > should have it's own error message to more clearly state that the BE may > not be bootable. However I think that this check should only be done if > this BE passes the cheaper check so that we're not running the more > time-consuming check for a BE that we already know isn't valid. > > Also I think the "cheaper" check should be done for the rest of the > subcommands to limit users attempting to act on invalid BE's without > impacting those commands as much.
FWIW, I agree with what you're proposing. Cheers, -- Glenn _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
