> > > There is no explicit interface around that directory, but etc/svc > > is Committed, and I see no problem with just using it as-is under > > the general rule that pre-usr services can make use of that. > > Would this rule include third-party software? >
>From an implementation and functional perspective, following the convention I proposed would include third-party software in terms of making sense. >From an interface perspective, no rule includes third-party software. There is this directory. Any process can dump stuff there if it likes. We have no control over that regardless of what rules or documents we invent. There's nothing to say some application isn't already dumping stuff there. A directory isn't like an ABI: there's no linker to enforce interface bindings. One could imagine such things, e.g. ACLs on directories associated with UIDs reserved for certain processes, such that only webservd can put stuff here, and only smf can put stuff there, but we have nothing like that at the moment. If you wanted to achieve something more globally useful for SMF that had better namespace isolation and interface stability, the thing to do would be to propose a new SMF variable, let's say $SMF_TMPDIR, that was handed from SMF to a client service as some private tmpfs directory in which the service can do whatever it likes, thereby isolating it from any other processes that might create things of a similar name. Then have SMF put this directory in etc/svc/volatile named <fmri>.dir just as it does today for logs. This would actually achieve better isolation of the namespace, and would also give us the flexibility to move the root of this directory around to various locations in the future. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
