compatability: struct sigaction missing sa_restorer

compatability: struct sigaction missing sa_restorer

[Isaac Dunham]

Kernel headers (asm/signal.h) and glibc headers agree that struct
sigaction should have sa_restorer; musl provides __sa_restorer
This is not mandated in X/Open or POSIX, AFAICT.
However, the specification says "struct sigaction includes at least the
following members", so here the glibc/kernel approach is conformant, as
well as being simple and obvious--as opposed to the possible approach:
#ifdef _GNU_SOURCE || _BSD_SOURCE
#define sa_restorer ....
#endif

This prevents building Xvesa; I definitely won't patch it to use
__sa_restorer.  Don't know if sa_restorer is commonly used.

I think that's the last issue, but could be wrong.

As far as __[gu]id_t goes:
$ grep -r  __[gu]id_t /usr/include|wc -l
101

So that's a fair-sized problem (sed already posted, fwiw).

Re: compatability: struct sigaction missing sa_restorer

[Rich Felker]

On Fri, Apr 13, 2012 at 07:20:18PM -0700, Isaac Dunham wrote:
> Kernel headers (asm/signal.h) and glibc headers agree that struct
> sigaction should have sa_restorer; musl provides __sa_restorer
> This is not mandated in X/Open or POSIX, AFAICT.
> However, the specification says "struct sigaction includes at least the
> following members", so here the glibc/kernel approach is conformant, as
> well as being simple and obvious--as opposed to the possible approach:

The "at least" wording does not automatically make the GNU behavior
conformant. The structure can contain extra members, but those members
must be in the reserved namespace. Fortunately for us, per POSIX XSH
2.2.2 The Name Space, sa_* is in the reserved namespace for signal.h,
so it's valid to just call it sa_restorer. As such, I'll fix it.

> This prevents building Xvesa; I definitely won't patch it to use
> __sa_restorer.  Don't know if sa_restorer is commonly used.

With that said, installing your own sa_restorer is not a very good
idea, and almost surely a very bad design... Not sure why Xvesa is
doing this...

Rich

Re: compatability: struct sigaction missing sa_restorer

[Isaac Dunham]

On Fri, 13 Apr 2012 23:03:02 -0400
Rich Felker <dalias@aerifal.cx> wrote:
..
> must be in the reserved namespace. Fortunately for us, per POSIX XSH
> 2.2.2 The Name Space, sa_* is in the reserved namespace for signal.h,
> so it's valid to just call it sa_restorer. As such, I'll fix it.
> 
> > This prevents building Xvesa; I definitely won't patch it to use
> > __sa_restorer.  Don't know if sa_restorer is commonly used.
> 
> With that said, installing your own sa_restorer is not a very good
> idea, and almost surely a very bad design... Not sure why Xvesa is
> doing this...

Just initializing certain parts to 0, apparently:

act.sa_handler = LinuxVTRequest;
sigemptyset (&act.sa_mask);
act.sa_flags = 0;
act.sa_restorer = 0; /* PROBLEM */
sigaction(SIGUSR1, &act, 0);

..
Looks like a later version of Xvesa just deleted this line, so I'll do that.

Xvesa was axed a couple years ago, but Xfbdev requires working framebuffer drivers (not a given, when an i810 system is one of the planned targets) and Xorg may not work without dynamic linking (every driver is a library), so I've been using the amigolinux version of TinyX (version "1.2.61", based on an *old* Xorg).  This is the only maintained Xvesa, and is a fairly small, single download.
It's only been tested against uclibc, but the developers are ready to patch it.

Incidentally, when I mentioned some of the issues I've been having, some of the developers mentioned that a BSD-licensed libc will be better for them than a LGPL-licensed libc--they're working on a tiny, pure static, multicall binary based distro.
 One of them has put rootfs on an in-kernel initrd for a sub-1MB single-file distro. 
-- 
Isaac Dunham <idunham@lavabit.com>

Re: compatability: struct sigaction missing sa_restorer

[Rich Felker]

On Sat, Apr 14, 2012 at 01:18:42PM -0700, Isaac Dunham wrote:
> On Fri, 13 Apr 2012 23:03:02 -0400
> Rich Felker <dalias@aerifal.cx> wrote:
> ...
> > must be in the reserved namespace. Fortunately for us, per POSIX XSH
> > 2.2.2 The Name Space, sa_* is in the reserved namespace for signal.h,
> > so it's valid to just call it sa_restorer. As such, I'll fix it.
> > 
> > > This prevents building Xvesa; I definitely won't patch it to use
> > > __sa_restorer.  Don't know if sa_restorer is commonly used.
> > 
> > With that said, installing your own sa_restorer is not a very good
> > idea, and almost surely a very bad design... Not sure why Xvesa is
> > doing this...
> 
> Just initializing certain parts to 0, apparently:
> 
> act.sa_handler = LinuxVTRequest;
> sigemptyset (&act.sa_mask);
> act.sa_flags = 0;
> act.sa_restorer = 0; /* PROBLEM */
> sigaction(SIGUSR1, &act, 0);
> 
> ...
> Looks like a later version of Xvesa just deleted this line, so I'll do that.

This is definitely wrong and unnecessary. If it were necessary, it
would be impossible to write portable programs using sigaction. The
reason it's unnecessary is that even libcs that use sa_restorer
require the SA_RESTORER flag to be set in order to use it; otherwise
it's ignored.

> Xvesa was axed a couple years ago, but Xfbdev requires working
> framebuffer drivers (not a given, when an i810 system is one of the
> planned targets) and Xorg may not work without dynamic linking
> (every driver is a library), so I've been using the amigolinux
> version of TinyX (version "1.2.61", based on an *old* Xorg). This is
> the only maintained Xvesa, and is a fairly small, single download.
> 
> It's only been tested against uclibc, but the developers are ready
> to patch it.

IMO they should patch it out. It's dead code and leads to portability
problems. You can cite my explanation above if you need to.

Rich