James Carlson wrote: > Jan Setje-Eilers writes: >> Darren J Moffat wrote: >>> I'm derailing this case there appears to be a very strong consensus from >>> those that have commented on the case that: >>> a) it doesn't solve the root causes of the problem >>> b) it could actually make it worse in some cases >>> c) makes Solaris look like it needs tuning for enterprise use. >> This sounds like you're simply opposed to this case, I'm not sure I >> understand what you hope to achieve by derailing it. > > The main thing it'd achieve would be the creation of a written opinion > and a vote on the project, rather than just letting it get approved. > That doesn't seem like a bad thing, especially since we'd effectively > be reversing a decision we made in PSARC 2004/454. > > I agree with you that it doesn't seem like there's a great deal more > to discuss at a meeting, other than perhaps user documentation, but I > suppose I could be missing something. > >> There is work both to perform automated recovery, as well as to >> further refine the check (to automatically drive on whenever "clear" was >> the right solution) under way. However I don't see how that has anything >> to do with whether or not it is correct to update the archives on udamin >> when we can (ie the administrator has declared it reasonable to perform >> work at that point). > > I'd still like to know if we're talking about uadmin(1M) or > uadmin(2). If it's the latter, then I'm really curious about how this > will actually work. Does libc's syscall wrapper check for the flag > and fork/exec the archive update? Is it some magic in the kernel? Or > something else entirely? If it's the former, then are we sure the > customer doesn't just use uadmin(2) from his application? >
It is uadmin(2) that we are modifying : Snv webrev: http://jurassic.eng/net/ssaesrv.eng/export/users/gm149974/scratch/bootadm/webrev/ S10 webrev: http://jurassic.eng/net/on10-public.sfbay/builds/gm149974/s10sust/webrev/ Thanks, Gangadhar
