LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: David Newall <davidn@davidnewall.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH for mm] Remove iBCS support
Date: Sun, 20 Jan 2008 16:03:22 +1030	[thread overview]
Message-ID: <4792DD22.4070902@davidnewall.com> (raw)
In-Reply-To: <20080120051822.GB19784@one.firstfloor.org>

Andi Kleen wrote:
> On Sun, Jan 20, 2008 at 03:16:25PM +1030, David Newall wrote:
>   
>> Andi Kleen wrote:
>>     
>>> On Sun, Jan 20, 2008 at 12:57:29PM +1030, David Newall wrote:
>>>   
>>>       
>>>> compatibility.  This is a sleeping giant for Linux.  There are plenty of
>>>>     
>>>>         
>>> Interesting choice of words.
>>>   
>>>       
>> KFC and Dominoes use SCO for their cash registers, to pick just two
>> enormous future opportunities.
>>     
>
> I suppose if they update their cash registers they will just go 
> with fully Linux binaries.
>   

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.

>>> But it does not make sense for all Linux kernels to always check for iBCS executables
>>> when they don't have to code to run them anyways.
>>>   
>>>       
>> I don't suppose you're suggesting this will make a big difference.  Even
>> if every exec did nothing but immediately exit, it still wouldn't make
>> much difference.
>>     
>
> It's not a big difference, but why do unnecessary work on all 
> Linux kernels? There are a lot of Linux machines out there and 
> if all of them only do a little unnecessary work each fork()
> over a year it adds up to really a lot of wasted cycles.
>   

It still adds up to something that nobody can perceive, not even using a
very fine stopwatch and counting over a period of years.

> Especially since the few people who might really
> need it can easily readd it.
>   
No.  Very few people can add it, easily or otherwise.  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.

> But Linux is not good for this currently, at least not unless you
> add a significant patch (which I'm not sure does even exist
> for modern 2.6; iBCS was mainly deployed on 2.4 kernels). And when you 
> add that patch you can easily readd the strcmps too.
>   

Yes, I agree.  Neither side of this issue is of great moment.  On the
one hand we have something that's half-baked at best; on the other hand
we want to remove it for non perceivable gain or benefit.

>> simplification of the story, I know, but still hits the plot highlights.
>>     
>
> You're worried about this patch generating headlines?

No, I don't see this as headline making material.  The existing code,
though, is a rough spot in the kernel.  So long as it's there, somebody
will feel the need to scratch it, as you do.  Absent the choice of
removing the code, and the only way left to scratch is to complete it. 
Remove the code and there's nothing there that itches, which is a bad
thing in this case.

  reply	other threads:[~2008-01-20  5:33 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-19  4:59 Andi Kleen
2008-01-20  2:27 ` David Newall
2008-01-20  3:11   ` Andi Kleen
2008-01-20  4:46     ` David Newall
2008-01-20  5:18       ` Andi Kleen
2008-01-20  5:33         ` David Newall [this message]
2008-01-20  5:55           ` Andi Kleen
2008-01-20  6:23             ` David Newall
2008-01-20  7:29               ` Andi Kleen
2008-01-21  1:37                 ` David Newall
2008-01-22 10:24                   ` Karl Kiniger
2008-01-22 15:06                     ` David Newall
2008-01-22 15:52                       ` Adrian Bunk
2008-01-23  8:48                     ` Andi Kleen
2008-01-23 14:12                       ` Karl Kiniger
2008-01-23 14:24                         ` Andi Kleen
2008-01-24 17:06                           ` David Newall
2008-01-22 11:12                   ` Ingo Molnar
2008-01-22 12:42                     ` Karl Kiniger
2008-01-22 15:13                     ` David Newall
2008-01-22 15:49                       ` Ingo Molnar
2008-01-24 17:01                         ` David Newall
2008-01-22 16:01                       ` Adrian Bunk
2008-01-24 17:04                         ` David Newall
2008-01-24 17:24                           ` Adrian Bunk
2008-01-24 17:55                             ` David Newall
2008-01-24 18:14                               ` Adrian Bunk
2008-01-25  2:14                                 ` David Newall
2008-01-25  5:12                                   ` Valdis.Kletnieks
2008-01-25 16:40                                   ` Alan Cox
2008-01-24 19:51                               ` Pavel Machek
2008-01-25  2:17                                 ` David Newall
2008-01-24 20:37                               ` Andi Kleen
2008-01-25  2:16                                 ` David Newall
2008-01-22 16:50                       ` Alan Cox
2008-01-24 17:08                         ` David Newall
2008-01-22 13:20                 ` Giulio
2008-01-20 13:06           ` Alan Cox
2008-01-20 13:43             ` David Newall
2008-01-20 13:51               ` Alan Cox
2008-01-25 12:17 ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4792DD22.4070902@davidnewall.com \
    --to=davidn@davidnewall.com \
    --cc=akpm@osdl.org \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: [PATCH for mm] Remove iBCS support' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).