This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]