This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Output of "uname -s" and "uname -o"
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