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 [email protected]
