Re: Someone using COMPAT_SVR4(_32) ?

Le 02/08/2017 à 17:31, Dave McGuire a écrit :
> On 08/02/2017 01:34 AM, Maxime Villard wrote:
>> What I'm saying is, if someone here is interested in doing this
>> work, there is no reason to remove compat_svr4.
> 
>    Whether that's the case or not, there is STILL no reason to remove it.

Again, so we never remove anything, and keep stockpiling dead code.

>   It can be disabled in kernel builds, and if someone needs it, either
> now or in the future, they can enable it and either take the risks or
> fix the bugs.

Sure, it's disabled since a few days. But it does not solve the problem that
I'm talking about: clean code.

>> No one, and I'm just here to do some survey, and ask people how they
>>   use compat_svr4 if they do. When I have some basic idea on the
>> subject, I can open a discussion. Nothing less, nothing more.
> 
>    No.  In your first message on this subject, you stated that your
> intention was to remove this functionality:
> 
>    "I plan to remove both of them, but I'd like some feedback."
> 
>    This was pretty clear to me.  "I plan to remove both of them" is not
> the same thing as "I'm just here to do some survey".

Yes, I plan to remove both of them, but I'm asking people whether there's
a use case before, to see if the plan is legitimate.

You can keep playing on words endlessly if you like.

>> It is curious to see how you (John, Dave and Eduardo) are trying to
>> put some drama in this thread, while I'm just asking how people use
>> compat_svr4.
> 
>    No, you're not "just asking how people use compat_svr4".  You
> announced a PLAN to remove it.

see above

>> I understand that you three do not use compat_svr4, because if you
>> were, you would have told me already. That's fine, I'm not accusing
>> you of anything, I'm just asking.
> 
>    Fallacious logic.

no

> I myself have used it, I don't currently, but I may
> in the future.  It's not up to you to decide that I will no longer have
> the option.

Ah, so you're finally answering the right question. Not sure why it took you so
long, but I guess it takes all kinds these days.

What kind of binary(ies) was that? Is it available on Linux nowadays?

>    Very few of the people who run this software are on this mailing list.
> You will reach almost none of the users with your survey attempts.

Point taken. I feared this a bit. But when you want to remove something, it has
to start somewhere, and it starts by asking who uses it.

> Removing functionality that has been there for a couple of decades is
> not a good approach. 

We've done this in the past. I would be curious to know what your good approach
at cleaning up old code is. If you have a proposal to keep the feature, and
at the same time move things around so that they don't "pollute" the base
system, I'll be happy to hear about it.

Another solution would be compartmentalizing the compat options into kernel
modules - which is the current proposal on tech-kern@. With this, we would have
the code of each option in exactly one folder; the module is compiled and
shipped by default, but not loaded.

This would be a way to preserve the feature, and make it have less of an impact
on the clearness of the native code. But, this involves modifying a non-
negligible number of things, and ensuring they work afterwards. That's some
work, and the effort has to be "worth" it.

To get the notion of "worth", you need to know whether someone uses the feature.

Regardless of what you are telling me, the general feeling, which is perfectly
translated in the logs, is that no one is interested in working on svr4. You
will understand, therefore, that chances are low that someone shows up now and
is ready to compartmentalize the feature. That's what we get when something is
not maintained: whatever clean alternative is available, no one will show up to
do the work. Hence the initial plan to remove it, plain and simple.

Apart from that, we can choose to do nothing, let this feature disabled and let
it rot, until another guy like me starts a similar thread in ten years because
no one will have maintained the feature in the meantime.

> You seem to have a desire to contribute effort.
> If you're able, why don't YOU take a whack at fixing the bugs. 

Verily, I did fix some shit in the compat layers two years ago, including svr4.
But I let down, because:
a) I cannot test my changes
b) I don't use these features on a regular basis
What I've seen, though, is that it was causing a lot of pain to the users - who
were automatically vulnerable. What I'm fearing now, is that it remains
unmaintained and keeps polluting the code base, even if disabled.

> A more
> reasonable approach would be something like: "There are problems in this
> code, is anyone working on this?  If not, I'll take a whack at it."

This is ridiculous. It is not pleasant to work on something and being
constrained because some buggy code lurking around needs to be fixed too. Most
of us (developers) are contributing code for free on our spare time. Saying
"*I* may use the feature, but I want *you* to do all the necessary work to fix
it" is not very respectful, but whatever.

It seems that it is where we strongly disagree: you think that since my plan
is to remove the feature because it is buggy/unmaintained/~unused, I should be
the one who should fix it not to remove it. My opinion is that those who insist
on keeping the feature should be the ones putting up some effort to maintain it.

Maxime