Re: kern/53666: tcpdump for i386 does not work with COMPAT_NETBSD32 on amd64

[Rin Okuyama <rokuyama%rk.phys.keio.ac.jp@localhost>]

Sorry for the late reply,

On 2018/10/12 18:09, Paul Goyette wrote:
> On Fri, 12 Oct 2018, Rin Okuyama wrote:
...
> > Is it OK to have #ifdef COMPAT_50 (or equivalently,
> > #ifdef BIOC[GS]ORTIMEOUT) in netbsd32_ioctl.c?
>
> Oh, joy!  Here comes another conflict with the pgoyette-compat
> branch!
>
> But YES, for now it would be acceptable to have a #ifdef COMPAT_50
> block.  I will extract the conditional code and move it into
> compat/netbsd32/netbsd32_compat_50.c and provide an appropriate
> linkage/hook.
>
> (Actually, this prompted me to look at the existing code on my
> branch, and it seems I've still got some clean-up work to do here
> for compat32_50_rnd_ioctl() - the "hook" needs to use the new
> MP-safe mechanism to prevent the module code from being unloaded
> while the code is executing!)

and sorry for troubling you...

> > Anyway, I would like to decide the way before proceeding further.
> >
> > (1) add unused "u_long cmd" argument to all netbsd32_{to,from}_foo()
> > functions in netbsd32_conv.h, and move netbsd32_{to,from}_foo() in
> > netbsd32_ioctl.c to netbsd32_conv.h
> >
> > or
> >
> > (2) leave preprocessor mess as is
> >
> > or
> >
> > (3) other
> >
> > Paul, how do you think?
>
> Neither 1 nor 2 "feels right" to me.  But I don't have any better
> choice to offer.

Hmm, unfortunately, support for BIOC[GS]ORTIMEOUT makes the situation
worse. We have netbsd32_{to,from}_timeval50() in netbsd32_conv.h, and
they convert between netbsd32_timeval50 and timeval, not timeval50!
Apparently, we have too many different kinds of functions that share
the same naming rule :(.

Fix may be made in two steps: (1) minimum fix to HEAD for now and
netbsd-8, in order to reduce conflicts b/w pgoyette-compat branch as
much as possible, then (2) real fix after merge of pgoyette-compat.

However, I'm not sure neither whether "the minimum fix" like this

  http://www.netbsd.org/~rin/netbsd32_ioctl_20181015.patch

is acceptable, nor how "the real fix" should be...

Thanks,
rin