> Michael Shapiro writes: > > > 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. > > I think that completely misses the point I was making. I wasn't > suggesting "exposing" the door as a fixed path name. In fact, I said > nothing about how the API itself (perhaps a wrapper library) would be > constructed. > > The problem still happens even if the library hides the location of > the door. How does the library know where the door might be located > if it doesn't have some way to get at $SMF_TMPDIR? > > The only way it can do that is by making part of the construction of > $SMF_TMPDIR visible and predictable, at least to the library author.
Sorry if I missed your point. $SMF_TMPDIR can be exposed as an environment variable to scripts or a non-persistent property to the service. The latter would allow a library to hardcode only one thing, the FMRI, which is really the one thing upon which it can depend. Then everything else can be derived from that by querying properties, or using properties to bootstrap a conversation with the service itself. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
