---- On Wed, 06 Jul 2016 23:48:53 -0700 Andrey Chernov <a...@freebsd.org>
wrote ----
> On 07.07.2016 9:40, Matthew Macy wrote:
> >
> >
> >
> > ---- On Wed, 06 Jul 2016 23:28:40 -0700 Andrey Chernov <a...@freebsd.org>
> > wrote ----
> > > On 07.07.2016 7:52, K. Macy wrote:
> > > > On Wednesday, July 6, 2016, Don Lewis <truck...@freebsd.org> wrote:
> > > >
> > > >> On 6 Jul, Matthew Macy wrote:
> > > >>> As a first step towards managing linux user space in a chrooted
> > > >>> /compat/linux, initially for i915 testing with intel gpu tools,
> > later
> > > >>> on to get widevine and steam to work I'm trying to get apt to work.
> >
> > > >>> I've fixed a number of issues to date in pseudofs/linprocfs but now
> >
> > > >>> I'm running in to a bug caused by differences in SIGCHLD handling
> > > >>> between Linux and FreeBSD. The situation is that apt will spawn
> > dpkg
> > > >>> and wait on a pipe read. On Linux when dpkg exits the SIGCHLD to
> > apt
> > > >>> causes a short read on the pipe which lets apt then continue. On
> > > >>> FreeBSD a SIGCHLD is silently ignored. I've even experimented with
> > > >>> doing a kill -20 <apt pid> to no effect.
> > > >>>
> > > >>> It would be easy enough to check sysvec against linux in pipe_read
> > and
> > > >>> break out of the loop when it's awakened from msleep (assuming
> > there
> > > >>> aren't deeper issues with signal propagation for anything other
> > than
> > > >>> SIGINT/SIGKILL) and then do a short read. However, I'm assuming
> > that
> > > >>> anyone who has worked in this area probably has a cleaner solution.
> >
> > > >>
> > > >> It shoulds like SA_RESTART is set in sa_flags for SIGCHLD but
> > shouldn't
> > > >> be in this case.
> > > >
> > > >
> > > >
> > > > Good point.
> > > >
> > > > Thinking more about it, this seems like a bug in FreeBSD. Not a valid
> >
> > > > behavioral difference.
> > >
> > > You better need consult with POSIX before fixing things toward any
> > > Linuxisms blindly in our native code. I don't have a time now to see,
> > is
> > > it really a bug according to POSIX, but please read or just find all
> > > SIGCHLD there:
> > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html
> > > it explain SIGCHLD actions in deep details.
> > > And that one too:
> > > http://pubs.opengroup.org/onlinepubs/009695399/functions/sigaction.html
> >
> >
> >
> >
> > I was pretty clear in my initial email that I'm only interested in
> > changing behavior for Linux programs.
>
> Of course, but in case it is FreeBSD bug, it should be fixed in our
> native code first before making any changes in Linuxator.
>
> > And I was asking for help with that, not a link to SUSv3 or POSIX.
>
> In case I was not helpful, sorry for that. Before you try to change
> something in Linuxator you need to be sure that FreeBSD does it right
> (or wrong, then fix FreeBSD native code first). I am just insisting on
> proper steps of fixing it.
>
I'm sorry for snapping . I misunderstood your intent. Using a SIGCHLD to
deliberately interrupt a pipe read is such a weird idiom. I'll test fork vs
clone on Linux and see how OS X responds to a SIGCHLD during a pipe read.
Thanks.
-M
> _______________________________________________
> freebsd-hack...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
