Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 13 Aug 2017 13:23:23 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: SIOCGSTAMPNS definition missing

On Sun, Aug 13, 2017 at 06:35:15PM +0200, Szabolcs Nagy wrote:
> * Szabolcs Nagy <nsz@...t70.net> [2017-08-13 18:03:01 +0200]:
> 
> > * Rich Felker <dalias@...c.org> [2017-08-11 20:53:38 -0400]:
> > > On Tue, Aug 01, 2017 at 10:08:02AM +0000, yamabiko@...netbeyond.org wrote:
> > > > Hello,
> > > > when I tried to compile qemu on a Gentoo musl based system it
> > > > complained about "SIOCGSTAMPNS" being undeclared. Using
> > > > "-DSIOCGSTAMPNS=0x8907" as CFLAG worked as a workaround. So it looks
> > > > like the definition it's missing from some header file (ioctl.h?)
> > > > See https://forums.gentoo.org/viewtopic-t-1066924.html for more info
> > > 
> > > Thanks for the report.
> > > 
> > > Has anyone else looked at this yet? It probably needs per-arch
> > > additions to the bits/ioctl.h headers.
> > > 
> > 
> > it seems to be defined in asm/sockios.h which
> > is included via sys/socket.h in glibc i think so
> > musl should put it into sys/socket.h if anywhere.
> 
> it seems i proposed the sockios stuff to be removed
> from ioctl.h, but that was not applied:
> 
> http://www.openwall.com/lists/musl/2016/07/03/22
> 
> i think those sockios macros should be moved from
> ioctl.h to socket.h and the SIOCGSTAMPNS should
> be added to them. (or we can add the macro now
> to ioctl.h and move them later)

They're not in the reserved namespace for socket.h, and unless there's
a strong legacy-compat argument for having them in socket.h, I think
it's rather undesirable to put them there even under default ("BSD")
feature profile since in practice almost everything uses the default.
If almost nothing has broken so far from not having them in socket.h,
that suggests to me that putting them there is probably undesirable.

> one issue is that the mips macros are currently
> wrong (don't match the kernel uapi definitions).

Uhg.

Rich

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ