This document is an early draft document, intended to facilitate early discussions. Once it firms up a bit, it will be presented for a formal vote by DevCouncil.
Today, illumos based systems report their uname -s -r as "SunOS 5.11". There are some compelling historical reasons for this, as well as some strong technical reasons. However, given the advent of Oracle SunOS 11.1 and 11.2, and the anticipated advent of SunOS 12, it seems clear that the use of SunOS 11 as illumos' programmatic identification is unfortunate. We seem to be stuck in time at a release version that is now over four 4 years old.
Clearly, illumos has continued to evolve, and it is neither the case that we would like to self-identify as an earlier (and therefore presumably inferior) version of Oracle Solaris, nor do we want to give the impression that we are stagnant.
Additionally, the various illumos downstreams & distributors would like to have a meaningful "tag" for identifying releases as some sort of tagged and human intelligible conversation. (While git checksums are technically sufficient here, these hardly are useful to ordinary mortals who want to discuss releases, and the lack of any clear ordering relationship makes it harder to talk about newer release.
Finally, we have a number of interfaces in illumos which are "promised" at some stability level. Unfortunately, without a release vehicle and suitable versioning, it becomes difficult or impossible to infer anything meaningful about interface stability. We have to date left this as a matter for the distributions to solve, but some of these promises need to be considered in the "big picture", which means we need to have an understanding of what we can and cannot break or change, and how we can set expectations for software developers, distributors, and administrators. This problem was well understand (and generally well-solved) at Sun. We've neglected to carry that diligence forward, and it may be time for us to resume doing so.
The SunOS "brand" (the output from uname -s) has a special place in the hearts of many within the illumos community. While the marketing name was known as Solaris, the "SunOS" name for the consolidation also known as OS/Net is a key part of our history, and there are strong emotional ties to it.
Additionally, there are technical concerns, as many many software packages have designed special checks for SunOS in the output of uname -s to enable Solaris specific behaviors. Historically, its been appropriate that these behaviors also be applied to software running on illumos, as our platform is derived from SunOS / Solaris, and we have also a shared goal to remain reasonably compatible with Solaris. (Indeed it can be argued that in many ways we are more compatible with Solaris 10 than official Oracle Solaris.)
Note that SunOS is an Oracle Mark, and we expect Oracle to continue to use that mark in the output of uname -s for future releases of their operating system, which has had some significant and incompatible divergence from the the ONNV_147 that forms the basis for illumos.
In spite of all this history, and reasons not to change the output of uname -s, the need to do so remains strong, and will only get stronger as the two platforms continue to diverge and grow. It is time for illumos to stand up and self identify proudly. Indeed, in a number of other places we have already done so (in conditional macros in system headers, and in the library versioning, we use the illumos "brand".)
So there can be no question that it would be nice to reach the point where uname -s reported "illumos".
Challenges & Compatibility
Of course, the problem is that there is an enormous amount of software that is expecting the name "SunOS" to be reported from uname -s. (And coincidentally, also 5.11 or something similar from uname -r). Simply outright breaking that installed base is entirely unacceptable. But at the same time, we have to offer a way for software developers to start using the new name, which means we need to develop a transition path. This transition path should support older software which desires to use the old uname output, while letting new software be developed to understand the new name. Indeed, its likely that simply making it possible for the GNU autotools maintainers to identify illumos will address a substantial portion of the software which needs to be illumos aware.
There are a couple of possible ways we can consider:
- Shared library shims. One could imagine that we offer a newuname wrapper around libc that changes the result from uname -s (and -r) to specific values. (Alternatively, one can imagine the reverse,that we supply a "legacy" version, and supply the new uname values by default.)
- We could use the branded zones infrastructure, but this seems like it would only help non-global zones, so we should ignore this for now. (Although it does seem that a legacy SunOS 11 or SunOS 10 brand might be useful long after the illumos uname switch has been made.)
- We could change the behavior based on both global (/etc/system) and per-process (environment variables, or possibly adding an inherited flag to the user area of the processes, along with some kind of tool to manipulate it, perhaps something like what pfexec does (imagine "oldunameexec" or some such) – I'd propose this be a boolean flag to be removed in the future. The global /etc/system variable could be used together with this to set the "default" value, so distributions could change their "default" personality on their own schedule(s).
These can of course be mixed and matched. The library interface could be provided as an emergency escape hatch even in the event of other global settings.
Proposed Implementation Specifics
We propose to add a new flags field to the struct user. This would be an 8-bit value as defined as "char u_flags;" This can occupy the space adjacent to u_acflag & u_systrap, thereby not changing the size of the structure at all, and leaving 8 more bits available for future purposes. The lowest order bit of these flags would be called "U_FLAG_OLDUNAME". If present, the uname() syscall would return "SunOS" in uts.sysname, and "5.11" in uts.release.
If not present, the system call would instead report "illumos" in uts.sysname. The value stored in uts.release would be a semantic version, as defined in the Versions section below.
The default value would be clear, unless the global variable (new) int uname_sunos is non-zero. (The intent is that this can be set in /etc/system.) Furthermore, the sense of the flag could be set using a new tool, puname, a new proctool. This tool would have the following usage:
The -s flag ("SunOS") would set the flag, and the -i ("illumos") flag would clear it. The -c would actually execute a new command (fork and set the flag sense appropriately), and the <pid> would be used to change the state of an existing command. The state of the flag would be inherited across fork. If neither -s nor -i is presented, but a <pid> is, then the command would just report the state of the flag.
The right to change the flag would be similar to the right to send the process a signal. Generally this means the process owner, or a process with the PRIV_PROC_OWNER privileges (similar to the rights required to send a process a signal).
A shared library can still be provided but we think this will be unnecessary.
In order to facilitate meaningful conversations, as well as programmatic, use of version numbers, we would like semantic versioning to be used, although it presents some challenges. This matches the historical use of uname -r on SunOS.
There is a question as to what the initial value ought to be. For lack of a better approach, we suggest that the value 5.14.0. The starting point is somewhat arbitrary, but we believe that use of a 5.x number is reasonably consistent with giving a nod to our SunOS heritage, using the number 14 can be seen both as a representation of the current year (2014) and a number larger than Oracle is likely to use for Solaris for a couple of years (giving us time to get folks used to the illumos identity. The final ".0" should be a value that increments regularly.
With versioning, we need to also recognize that this represents a "brand" as well, with potentially broad ramifications. We suggest that the "5" will probably be fixed forever, as illumos version 6 would likely represent a total departure into something else. (For example, if illumos were to switch to a Plan 9 based kernel...) So that leaves the "minor" version for major feature changes, and "planned" EOFs and breakage. As this is a marketing impact level of change, we propose that Dev Council will have ultimate determination on the release schedule and the time frame to bump that version.
The micro number would be something we would expect to increment at regular intervals. We are proposing a quarterly release schedule. Ideally this would be include some level of testing and actual binary packages for direct integration by distributions. Also, this would be a time to produce release notes, etc. We think once a quarter is probably the maximum rate this should change, barring critical bug fixes. Ultimately DevCouncil shall own this number as well, although we expect that authority to be delegated to a release engineering team.
It goes without saying some release planning and release engineering work will be required to pull this off. But other OSS projects are able to do this with even fewer resources than we have in illumos. Its time to step up.