Output of "uname -s" and "uname -o"

[Eric Blake]

According to Igor Peshansky on 6/9/2008 8:37 AM:
>> Old header files plus backward compatibility.  The structure is exposed
>> to applications.  Every change here requires to check for the Cygwin
>> version under which the application has been built.  I cursed the short
>> field length myself at onepoint, but the added complexity looks a bit
>> questionable.
> 
> #define uname uname_long
> #define utsname utsname_long
> #define _UTSNAME_LENGTH 20
> struct utsname_long {
>   char sysname[_UTSNAME_LENGTH];
>   char nodename[_UTSNAME_LENGTH];
>   char release[_UTSNAME_LENGTH];
>   char version[_UTSNAME_LENGTH];
>   char machine[_UTSNAME_LENGTH];
> };
> int uname_long (struct utsname_long *);
> 
> Or something along those lines...
> 	Igor

This would be a similar change to when stat64 was created.  You can't make 
a struct have larger fields without adding compatibility checks to make 
cygwin1.dll support the old size for some time to come, unless we declare 
all applications compiled before the larger-size struct as 
no-longer-supported.  On the other hand, 1.7.0 is a big enough banner day, 
and uname(2) is called seldom enough, that we could probably just make 
that change for 1.7.0 and deal with the resulting applications that crash 
because they used the wrong size struct definition to parse what 
cygwin1.dll handed back to them (for example, coreutils would need to be 
recompiled, but what else?).  More things rely on uname(1) than uname(2), 
so a coreutils recompile will pacify most users.

uname without arguments defaults to uname -s; that is where we can/should 
have the most effect - according to the autoconf documentation, uname with 
options is not viable until you have first used uname without options to 
see which options are likely to work.

uname -o is hardcoded to a value learned at configure time (derived from 
config.{sub,guess} which in turn comes from uname -s); it would be 
relatively easy to do a cygwin-specific patch to change its value, but 
harder to make it dynamic.  But with untouched upstream, plain 'Cygwin' is 
the best we can ask for, since I don't think people running on Vista want 
to know that I compiled coreutils on XP.

Do all of the fields need to be made larger, or just sysname?  Suppose we did:

#define _UTSNAME_SHORT 20
#define _UTSNAME_LONG 64

struct __utsname32 {
   char sysname[_UTSNAME_SHORT];
   char nodename[_UTSNAME_SHORT];
   char release[_UTSNAME_SHORT];
   char version[_UTSNAME_SHORT];
   char machine[_UTSNAME_SHORT];
};
struct __utsname64 {
   char __unused[_UTSNAME_SHORT];
   char nodename[_UTSNAME_SHORT];
   char release[_UTSNAME_SHORT];
   char version[_UTSNAME_SHORT];
   char machine[_UTSNAME_SHORT];
   char sysname[_UTSNAME_LONG];
};
typedef struct __utsname64 utsname

Then cygwin1.dll has to leave sysname alone and populate __unused with 20 
bytes if the application was not compiled for 1.7.0, and populate sysname 
otherwise; but the rest of the fields are unchanged between versions. 
What format of strings do we want in sysname?  We may also have to 
propagate any changes in output format to the config.guess maintainers. 
Whatever we do, I highly recommend that the first 6 characters of sysname 
still be (at least case-insensitively) "Cygwin".  And I _do_ like the idea 
of giving more information about the underlying Windows version alongside 
the system name of cygwin.

-- 
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net