Re: Removal of compat-FreeBSD

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Feb 16, 2015 at 12:13:07AM +0100, Jean-Yves Migeon wrote:
 > >  > The funny thing is that a simple, *valid* call to sched_getparam()
 > >  > crashes the system. Clearly, it means that in 6 years, nobody
 > >  > tested it. As I stated, we should normally have received a bug
 > >  > report from someone, but we didn't. It either means there's an
 > >  > insidious conspiracy against us, or, nobody uses it.
 > >
 > >sched_getparam() is hardly a main-line function. I could easily
 > >imagine running compat binaries for years and never happening to use
 > >one that calls it. So I think your reasoning is suspect.
 > 
 > Arguable perhaps, but not suspect. We all know that nasty bugs lie in
 > unused/rarely used code, yet they are still there to play with if someone
 > wants to. And there goes bad press. The big difference between this and a
 > crappy ioctl is that the ioctl works only when the hardware behind is
 > present.

No, the logic was "nobody stepped on this bug in this obscure corner,
therefore nobody uses the code".

 > >By this same reasoning we should not have any binary compat code at
 > >all. The only thing you've cited that's different about the freebsd
 > >compat code is that it's out of date -- the proper response to that is
 > >to update it. It's not like freebsd's syscall ABI is secret or
 > >anything.
 > 
 > I hardly see the point in updating such compat code, unless some new binary
 > requires a more recent freebsd API/ABI. In that particular case better move
 > to compat_linux (I hardly see who would provide a FreeBSD binary without a
 > Linux one nowadays).
 > 
 > Or deprecate old code gradually by making it root-only first (at least for
 > syscall related stuff) then squash it at a later time.

You're missing the point. The same logic could be used to argue for
removing compat_linux as well.

-- 
David A. Holland
dholland%netbsd.org@localhost