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 Tue, 10 Jun 2008, Christopher Faylor wrote:

> On Tue, Jun 10, 2008 at 01:10:44AM -0400, Igor Peshansky wrote:
> >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.
>
> Maybe it isn't clear.  This may be new territory to you but we have
> already done things like changing the size of a structure by using
> #define (and other) trickery in Cygwin even before transitioning from
> stat64 to stat.  You also need a new function, of course.

Right.  It's not new territory at all -- I know it's been done in Cygwin
before, so I don't quite understand why the issue of changing the size of
the struct keeps coming up.

> I haven't seen any good explanation of how you'd deal with any
> application which is relying on the current behavior since you'd be
> breaking externally visible backwards compatibility.  That's the
> difference between changing the structure size for uname versus changing
> the structure size for stat or terminfo.

By the current behavior you mean the fact that the underlying Windows
information is appended to the sysname field?  In one of my previous
messages I suggested adding a CYGWIN-env flag to force the old behavior:

> As for compatibility with older applications, one could imagine adding a
> $CYGWIN flag (e.g., uname_compat) that would produce old-style output.

Another alternative is a new environment variable altogether (though it's
probably better to keep all flags affecting the behavior of the Cygwin DLL
in $CYGWIN).
	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]