tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: svr4, again
Le 17/12/2018 à 19:21, Hisashi T Fujinaka a écrit :
On Mon, 17 Dec 2018, Christos Zoulas wrote:
In article <7fd8e657-dafb-1efc-0a23-762803589b92%m00nbsd.net@localhost>,
Maxime Villard <max%m00nbsd.net@localhost> wrote:
Should I re-start a fight about dropping COMPAT_SVR4? Because I keep finding
bugs, and it's becoming tiring. Over time I've come across at least a good
dozen of bugs in it, by just grepping through the tree searching for unrelated
things. The last one is this [1], while working on kcov, exit1() is called but
the proc mutex is not held.
The thing is just broken beyond repair.
It is dead wood that consumes APIs and makes stuff harder to change, just like
the network components we (thankfully) retired.
[1] https://nxr.netbsd.org/xref/src/sys/compat/svr4_32/svr4_32_signal.c#661
I would start by checking if anyone is using it. Can it still run Solaris
binaries? I have not used it in a decade or more...
Why start a fight? You should first ask if someone is using it, as
Christos says.
Already done, repeatedly, here [1], and here [2], and long before that in
private discussions with several people. And before myself, I seem to
remember that one or two people did talk about that, but I can't remember
who and when.
The conclusion is always the same: no one uses compat_svr4. Another fact
is that it is completely buggy; it has cost us in DEFCON 25, and still
remains today a maintenance burden. This is the same kind of burden for
dead wood in general: APIs that are consumed, changes that can't be
tested, bugs that keep being found, and so on.
There have been all kinds of wrong and incoherent arguments given to keep
it, which have more or less started brawls in the past.
Now I'm re-putting the subject on the table, because, as if it wasn't
already glaringly obvious, COMPAT_SVR4 is broken beyond repair. I keep
unintentionally finding bugs in it, and it just doesn't make any sense
to keep it to me.
[1] http://mail-index.netbsd.org/port-sparc64/2017/07/31/msg002635.html
[2] http://mail-index.netbsd.org/port-sparc64/2017/08/26/msg002651.html
Home |
Main Index |
Thread Index |
Old Index