David Bustos wrote: >Quoth Michael Shapiro on Thu, Oct 26, 2006 at 10:27:59PM -0700: > > > ... > >>So before we go add this, I'd like to see a detailed discussion of exactly >>what issue NFS is having and let's apply first principles to that. >> >> > >Sure. I think the root problem is that SMF asks developers to divide >their features up along error boundaries and then automatically presents >the resulting pieces to the user through svcs & svcadm. This works >great for most services since they are self-contained. telnetd, for >example, implements a feature all by itself, so being able to use svcadm >to turn it on and off is appropriate and a boon. NFS, on the other >hand, is implemented by multiple daemons. Setting sharetab aside for >a moment, the NFS developers could choose to pack all of them into the >nfs/server service, in which case using svcadm to turn it on or off >would be appropriate. But then they wouldn't get individual-daemon- >restart semantics. For that they have to put each daemon into its own >service. And then they get the accidental user interface into the >implementation of the feature. Perhaps a better way to talk about this >problem is by saying the NFS developers should be able to declare the >general/enabled property of its services as less than public, in >response to which svcadm & svccfg would advise the user about the >correct way to achieve the property modification. > >
This problem sounds similar to the one with IPFilter, except it has started at the other end - there's a bunch of internal details that aren't easily accessible from the outside with SMF. Maybe we need to think about sub-service interaction using svcadm so that we can use it to restart the locking daemon in the NFS server service or the logging daemon in IPFilter or... Darren
