Re: [Qemu-devel] Does i386-linux-user build on an i686 host?

[Aleksandar Markovic]

On Fri, Aug 9, 2019 at 2:57 PM Peter Maydell <address@hidden>
wrote:

> On Fri, 9 Aug 2019 at 13:22, Peter Maydell <address@hidden>
> wrote:
> >
> > On Thu, 8 Aug 2019 at 16:37, Markus Armbruster <address@hidden>
> wrote:
> > >
> > > Fails for me, but perhaps I'm doing it wrong:
> >
> >
> > > NOTE: cross-compilers enabled:  'cc'
> > > $ make
> > >   CC      i386-linux-user/linux-user/syscall.o
> > > /home/armbru/qemu/linux-user/ioctls.h:306:9: error:
> ‘SNDCTL_DSP_MAPINBUF’ undeclared here (not in a function)
> > >    IOCTL(SNDCTL_DSP_MAPINBUF, IOC_R,
> MK_PTR(MK_STRUCT(STRUCT_buffmem_desc)))
> > >          ^
> > > /home/armbru/qemu/linux-user/syscall.c:5023:23: note: in definition of
> macro ‘IOCTL’
> > >      { TARGET_ ## cmd, cmd, #cmd, access, 0, {  __VA_ARGS__ } },
> > >                        ^
> > > /home/armbru/qemu/linux-user/ioctls.h:307:9: error:
> ‘SNDCTL_DSP_MAPOUTBUF’ undeclared here (not in a function)
> > >    IOCTL(SNDCTL_DSP_MAPOUTBUF, IOC_R,
> MK_PTR(MK_STRUCT(STRUCT_buffmem_desc)))
> > >          ^
> > > /home/armbru/qemu/linux-user/syscall.c:5023:23: note: in definition of
> macro ‘IOCTL’
> > >      { TARGET_ ## cmd, cmd, #cmd, access, 0, {  __VA_ARGS__ } },
> > >                        ^
> > > /home/armbru/qemu/linux-user/ioctls.h:362:9: error:
> ‘SOUND_MIXER_ACCESS’ undeclared here (not in a function)
> > >    IOCTL(SOUND_MIXER_ACCESS, 0, TYPE_PTRVOID)
> > >          ^
> > > /home/armbru/qemu/linux-user/syscall.c:5023:23: note: in definition of
> macro ‘IOCTL’
> > >      { TARGET_ ## cmd, cmd, #cmd, access, 0, {  __VA_ARGS__ } },
> > >                        ^
> >
> > We expect these to be provided by the system's "linux/soundcard.h".
> > For my Debian system that's provided by the linux-libc-dev package,
> > but I imagine you have that installed or you wouldn't have got
> > this far in the configure/compile process...
>
> Further investigation shows that this is because the system has
> the 'oss4-dev' package installed, which diverts
> /usr/include/linux/soundcard.h
> and installs its own version which doesn't provide all the symbols
> that the kernel one does.
>
> Easy fix: uninstall oss4-dev.
>
> Better fix: patch QEMU to provide its own versions of these constants
> if the system headers don't.
>
>
Another related case, needing internal-to-QEMU ioctl constant definitions:

Linux namespaces and their ioctls:
===========================

http://man7.org/linux/man-pages/man7/namespaces.7.html

http://man7.org/linux/man-pages/man2/ioctl_ns.2.html

Kernel support exist since 4.9 (amended in 4.11), but there is no
header that exposes ioctl definitions - an applications must contain
something like this:

       #ifndef NS_GET_USERNS
       #define NSIO    0xb7
       #define NS_GET_USERNS   _IO(NSIO, 0x1)
       #define NS_GET_PARENT   _IO(NSIO, 0x2)
       #endif

QEMU does not support these ioctls (regardless of the presence of
host kernel support) - however, if we had the above definitions in our
code, we could support them (of course, relying on the support in the
host kernel, otherwise we would return "unknown ioctl").

Cordially,
Aleksandar



> Utopian fix: I've wondered occasionally whether for cases like this
> where the constant is known to be the same for the host and the guest
> we should have some sort of approach which lets us use the QEMU
> copies of the linux kernel headers rather than having to rely on
> the host system, which might have an older version that restricts
> us unnecessarily on what we could support...
>
> Issue previously reported in 2016:
> https://lists.gnu.org/archive/html/qemu-devel/2016-12/msg01421.html
>
> thanks
> -- PMM
>
>