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:	Sun, 20 Jan 2008 16:53:30 +1030
From:	David Newall <davidn@...idnewall.com>
To:	Andi Kleen <andi@...stfloor.org>
CC:	akpm@...l.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH for mm] Remove iBCS support

Andi Kleen wrote:
> On Sun, Jan 20, 2008 at 04:03:22PM +1030, David Newall wrote:
>   
>> It's not necessarily that simple.  It might be for KFC and Dominoes, but
>> for others, SCO is not the complete story.  Many legacy systems are
>> written in COBOL, and must pay a per-seat licence for that on top of the
>> per-seat licence for UNIX.  It is these systems that are most attracted
>> towards SCO compatibility.
>>     
>
> Well I'm sure if they migrate they can either recompile or pay someone
> to forward port and apply and support the iBCS emulation patchkit.
>   
If they migrate they buy a new run-time licence.  These costs about a
thousand dollars for small sites.

> But assuming there is no cache miss (which is a very conservative
> assumption) and the strcmps cost 20 cycles and you got 1 million
> 2Ghz Linux systems out there doing 100k execs each day we're talking
> about 1000 CPU seconds wasted each day.
That's not a very useful metric.  It says nothing about what the benefit
will be.  Will any job complete sooner?  Not measurably.  Will less
hardware be required?  No.

> (e.g. the old default ldt code which was for iBCS was just dropped --
> strangely you didn't raise your voice against that)
>   
I wasn't around then, or I would have.

>>  Perhaps KFC could
>> employ somebody to add it, but they'd more likely be able to convert
>> their entire software stack instead.  The paint shops and mechanics of
>> the world would have little chance of that.
>>     
>
> Sorry, but I don't think you know what you're talking about here.
I think I do.  You appear to be arguing that small businesses, such as
paint shops or garages, could re-install iBCS2 support.  That is, of
course, a nonsense in any other sense other than the purely theoretical,
devoid as it is of realities such as--and this is just the most
obvious--a sound business case.  It's just not going to happen that
way.  Perhaps it's best we all ignore the outburst.


I've stated the disadvantage, such as it is, in removing iBCS.  What's
the benefit?  Is it, as I say, a tiny performance improvement per exec
versus removing an itch that leads towards market domination? :)
--
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/