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"


On Mon, 9 Jun 2008, Eric Blake wrote:

> 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.

You can change the struct, provided it's a different struct.  AFAICS, the
above #defines take care of this.  Applications compiled against the old
Cygwin versions will use uname (and struct utsname), and the newly
compiled code will use uname_long and struct utsname_long.

> 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.

Right.  The main problem is not with changing the size of the fields
(though that is helpful), but with changing the actual content of those
fields (which will break things that rely on uname(2)).

> 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.

Does autoconf usually care whether it runs on Vista or XP or NT?

> 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.

Right.  I figured as much.  We'd want to move the underlying Windows
information into some field in utsname*.

> Do all of the fields need to be made larger, or just sysname?

Actually, it's version and release that are filled close to capacity.

> 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.

That would work if we only wanted to extend sysname.

> 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.

I recommended that it would be exactly "Cygwin", and that any extra
version information be released in the version field.

Again, does congif.guess care that it's running on Vista/XP/2k/NT?
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"That which is hateful to you, do not do to your neighbor.  That is the whole
Torah; the rest is commentary.  Go and study it." -- Rabbi Hillel


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