linux-kernel - Re: [PATCH for mm] Remove iBCS support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 25 Jan 2008 12:44:05 +1030
From:	David Newall <davidn@...idnewall.com>
To:	Adrian Bunk <bunk@...nel.org>
CC:	Ingo Molnar <mingo@...e.hu>, Andi Kleen <andi@...stfloor.org>,
	akpm@...l.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH for mm] Remove iBCS support

Adrian Bunk wrote:
> On Fri, Jan 25, 2008 at 04:25:24AM +1030, David Newall wrote:
>   
>> The performance benefit is trivial, and the improvement to
>> maintainability is even less.
>>     
>
> The effects become bigger when you realize that there are many such 
> places in the kernel.
>
> And the benefit of keeping it is zero.
>   

The benefit is not zero.  Repeating myself: While the code is there, it
encourages either removal or repair.  If the option to remove is taken
off the table then it will eventually be repaired.

> What you are doing is not contributing but wasting other people's time.
>   
You want to remove the code so you attack me.  Sadly for you, your
personal taste is irrelevant to the benefit that I bring.  What kind of
a person considers robust debate to be a waste of time?  A  bit
pathetic, sadly.

> The only thing you could ever achieve with this kind of "contribution" 
> is to end up in some killfiles.
>   

I'm comfortable with that.  I'm also comfortable that consensus might go
against me.  This childish threat of kill-files is not going to stop me.

>>>> At one stage iBCS2 support DID work.  Now it doesn't.  Now there's an
>>>> argument that the remaining infrastructure should be removed.  This is
>>>> the wrong direction to take.
>>>>     
>>>>         
>>> When did iBCS2 support work in a plain ftp.kernel.org kernel?
>>>   
>>>       
>> I don't know when.  Are you disputing that it ever did?  I think it's a
>> given that once it worked.
>>     
>
> AFAIK the kernel never shipped with iBCS2 support.
>   

Are you claiming that it never did?  Is that even important?  Clearly
there was support for it in the mainline kernel.  Anecdotally the
support worked.

...
> The point is that ideas do not turn themselves into code.
>   
This discussion is about removing code.  That's a bit like tearing down
the pergola because the vine has shrivelled.  Easy to do, but
counter-productive.  LIkewise, removing iBCS2 code would be
unproductive.  It would achieve no benefit, whilst simultaneously
leading Linux in the wrong direction.  This is a point you have
consistently failed to address.

> And there are far too many people who want to see their great ideas 
> implemented without implementing it themselves.
>   
This is not about a great idea.  It's about a pointless idea.  Even
allowing what you say to be true, and it probably is, there is nothing
wrong with somebody having a great idea and leaving it to others to
implement.  If the only people allowed to have great ideas were those
who could implement them then the world would be a much poorer place. 
You demonstrate a twisted view of value.

> Talking about a feature without having anyone willing to implement it 
> simply has no value.

Who said nobody is willing to implement it?  We've all recently learned
that there is a patch.  From there to implementation is much closer than
you or I thought last week.  So already this discussion has prompted
tangible benefit.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/