> > 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. > > That might work in a few cases, but it'd have a significant downside: > the actual location of the temporary data would be variable and > unpredictable by things that are outside of the running service > itself. That'd likely make the feature unusable by many (if not most) > users. > > For example, suppose I have a server with a door fattach'd into the > file system so that users can send requests or queries to the server. > If I want to create a door in the file system early in boot, but the > path I'm using for fattach is $SMF_TMPDIR, then separate user tool > won't be able to find the door. > > We need stable paths to make things like that work. It'd be nice if > the stable path weren't tied to an SMF historical artifact, which is > why I think /etc/volatile is much better than /etc/svc/volatile.
Exposing a door as a fixed pathname is a bad idea: expose a library interface either to the fd, or wrapped around the protocol itself, because that is the place we actually have proper versioning technology. Temporary files should be implementation details, not interfaces. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
