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? -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
