Jeffrey Hutzelman writes: > On Thu, 20 Mar 2008, James Carlson wrote: > > If anyone involved with OpenSolaris (or Sun) were to try that, it > > wouldn't be by way of stealth, as you seem to be suggesting. It would > > be done openly, first with an ARC case that describes exactly how > > things transition in a compatible way, and then public notice to _all_ > > customers at least a year in advance of the change. > > I'd like to believe that, but can you point to documentation which > classifies this as a Committed interface? I was unable to find such on a > Solaris 9 system, and the init.d(4) man page on Solaris 10 contains this:
Solaris is old. Very old. Many of the things in it were designed long before there was any architectural review process at Sun, and well before we ever had any notions of interface stability. When those processes were introduced, we could have taken a two or three year break and carefully documented every single interface, and padded out all of the man pages to conform. We didn't do that. Instead, we chose to apply judgement: while new interfaces have their stated stability, old ones require some inspection when a stability is needed (either as part of a review or as part of some odd side discussion on a mailing list ;-}). If they're part of any standard environment or documented use, they're Committed. If they're just some human-mediated debug interface, they're probably Volatile. If they're something else, then apply some experience to it. The problem boils down to resolving the reasonable expectations of those who use those interfaces, and making sure that we don't violate those. What that means is that the old System V interfaces, particularly the ones that are documented and in use by software, can't really go anywhere. > The service management facility (see smf(5)) is the pre- > ferred mechanism for service initiation and termination. > The init.d and rc?.d directories are obsolete, and are pro- > vided for compatibility purposes only. Applications launched > from these directories by svc.startd(1M) are incomplete ser- > vices, and will not be restarted on failure. All of which is correct. "Obsolete" merely means that there are now better choices (according to Sun's engineers ;-}), and that we encourage everyone to migrate when possible rather than using those old interfaces. That says _nothing_ about whether they'll actually be removed at any point in time. Furthermore, actual removal is separate from marking something as "obsolete." It takes a separate review and, as I noted before, generally requires notification of customers before it happens. Within the ARC, we look at these cases carefully. If the thing being removed is never used or represents some sort of security hazard, removal is usually simple. If it's sometimes used but migration is possible, then standard notification of a year is needed. If it's common (as this is) and simple migration is implausible (as it is here), removal might not be possible at all -- ever. (The above assumes a Minor release. Major releases are different, though they're very rare. The last one was Solaris 2.0 and the switch from BSD to System V.) I'm just one ARC member, so I can't speak for the others, but I think it's just plainly obvious that if someone approached us asking to remove /etc/rc*.d/ from Solaris, we'd simply say "no." It wouldn't require a lot of discussion, I'd hope, and no amount of pointing at man pages and hand-wringing over the possible changes in the future would alter that. The interface taxonomy and other ARC documents have more information on the processes involved here, if anyone's interested. -- 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
