[PATCH for mm] Remove iBCS support

[PATCH for mm] Remove iBCS support

[Andi Kleen]

Hi Andrew,

Can you please queue this patch in -mm for .25. It was posted earlier
and nobody complained.

Thanks,
-Andi

----


Remove ibcs2 support in ELF loader too

ibcs2 support has never been supported on 2.6 kernels as far as I know,
and if it has it must have been an external patch. Anyways, if anybody
applies an external patch they could as well readd the ibcs checking
code to the ELF loader in the same patch. But there is no reason
to keep this code running in all Linux kernels. This will save at least
two strcmps each ELF execution.

No deprecation period because it could not have been used anyways.

Signed-off-by: Andi Kleen <ak@suse.de>

---
 fs/binfmt_elf.c |   15 +++------------
 1 file changed, 3 insertions(+), 12 deletions(-)

Index: linux/fs/binfmt_elf.c
===================================================================
--- linux.orig/fs/binfmt_elf.c
+++ linux/fs/binfmt_elf.c
@@ -530,7 +530,6 @@ static int load_elf_binary(struct linux_
  	unsigned long load_addr = 0, load_bias = 0;
 	int load_addr_set = 0;
 	char * elf_interpreter = NULL;
-	unsigned char ibcs2_interpreter = 0;
 	unsigned long error;
 	struct elf_phdr *elf_ppnt, *elf_phdata;
 	unsigned long elf_bss, elf_brk;
@@ -647,14 +646,6 @@ static int load_elf_binary(struct linux_
 			if (elf_interpreter[elf_ppnt->p_filesz - 1] != '\0')
 				goto out_free_interp;
 
-			/* If the program interpreter is one of these two,
-			 * then assume an iBCS2 image. Otherwise assume
-			 * a native linux image.
-			 */
-			if (strcmp(elf_interpreter,"/usr/lib/libc.so.1") == 0 ||
-			    strcmp(elf_interpreter,"/usr/lib/ld.so.1") == 0)
-				ibcs2_interpreter = 1;
-
 			/*
 			 * The early SET_PERSONALITY here is so that the lookup
 			 * for the interpreter happens in the namespace of the 
@@ -674,7 +665,7 @@ static int load_elf_binary(struct linux_
 			 * switch really is going to happen - do this in
 			 * flush_thread().	- akpm
 			 */
-			SET_PERSONALITY(loc->elf_ex, ibcs2_interpreter);
+			SET_PERSONALITY(loc->elf_ex, 0);
 
 			interpreter = open_exec(elf_interpreter);
 			retval = PTR_ERR(interpreter);
@@ -725,7 +716,7 @@ static int load_elf_binary(struct linux_
 			goto out_free_dentry;
 	} else {
 		/* Executables without an interpreter also need a personality  */
-		SET_PERSONALITY(loc->elf_ex, ibcs2_interpreter);
+		SET_PERSONALITY(loc->elf_ex, 0);
 	}
 
 	/* OK, we are done with that, now set up the arg stuff,
@@ -748,7 +739,7 @@ static int load_elf_binary(struct linux_
 
 	/* Do this immediately, since STACK_TOP as used in setup_arg_pages
 	   may depend on the personality.  */
-	SET_PERSONALITY(loc->elf_ex, ibcs2_interpreter);
+	SET_PERSONALITY(loc->elf_ex, 0);
 	if (elf_read_implies_exec(loc->elf_ex, executable_stack))
 		current->personality |= READ_IMPLIES_EXEC;
 

Re: [PATCH for mm] Remove iBCS support

[David Newall]

Andi Kleen wrote:
> Can you please queue this patch in -mm for .25. It was posted earlier
> and nobody complained.

I'm sure I complained.  I'm sure I said something about SCO
compatibility.  This is a sleeping giant for Linux.  There are plenty of
machines running legacy SCO applications, just waiting for painless
migration to some other platform.

We should not be dismantling the scaffolding that's needed for that.

Re: [PATCH for mm] Remove iBCS support

[Andi Kleen]

On Sun, Jan 20, 2008 at 12:57:29PM +1030, David Newall wrote:
> Andi Kleen wrote:
> > Can you please queue this patch in -mm for .25. It was posted earlier
> > and nobody complained.
> 
> I'm sure I complained.  I'm sure I said something about SCO

Did you? 

> compatibility.  This is a sleeping giant for Linux.  There are plenty of

Interesting choice of words.

> machines running legacy SCO applications, just waiting for painless
> migration to some other platform.
> 
> We should not be dismantling the scaffolding that's needed for that.

See the rationale in the patch -- any iBCS application will need a significant
kernel patch. If people add this kernel patch they can easily patch the three
more places that detect the executables.

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.

Now if iBCS support is truly as important as you claim I'm sure
someone will eventually submit a patch for mainline to support it properly.
If yes the hooks can be readded in a clean way, not in a hackish way
like they currently exists.

-Andi

> 

Re: [PATCH for mm] Remove iBCS support

[David Newall]

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.


> 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.

Likewise, I take your point about proper iBCS support (and I suppose
it's really iBCS2 that we're talking about.)  My concern is that
removing this now gains almost nothing, 2 strcmp per exec is as close to
nothing as anything, but it sends a message with which I disagree.  The
message should be that Linux is good for, well the same things FreeBSD
is, and includes running Solaris and SCO binaries.  This is a major
simplification of the story, I know, but still hits the plot highlights.

Re: [PATCH for mm] Remove iBCS support

[Andi Kleen]

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.

> > 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.

Especially since the few people who might really
need it can easily readd it.

> Likewise, I take your point about proper iBCS support (and I suppose
> it's really iBCS2 that we're talking about.)  My concern is that
> removing this now gains almost nothing, 2 strcmp per exec is as close to
> nothing as anything, but it sends a message with which I disagree.  The
> message should be that Linux is good for, well the same things FreeBSD
> is, and includes running Solaris and SCO binaries.  This is a major

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.

> simplification of the story, I know, but still hits the plot highlights.

You're worried about this patch generating headlines?

-Andi

Re: [PATCH for mm] Remove iBCS support

[David Newall]

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.

Re: [PATCH for mm] Remove iBCS support

[Andi Kleen]

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.
And for that person it will be only a few minutes to readd these hunks.

However it doesn't make any sense to have all Linux systems ever
out there who can't even run these binaries without significantly
changing the kernel have carry the overhead of these unnecessary checks.

> 
> >>> 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.

I'm not sure the cost is that low because they access one (or more likely
two) out of line data cache line for the two strings and kernel often runs
cache cold because userland tends to fill the caches and then a cache miss
can be actually hundreds of cycles, possibly multiplied by two.

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 should be certainly
measurable on most stop watches.

> 
> > Especially since the few people who might really
> > need it can easily readd it.
> >   
> No.  Very few people can add it, easily or otherwise.

They have to patch the kernel in non trivial ways anyways because they
would need to patch in the whole old iBCS emulation layer.

(e.g. the old default ldt code which was for iBCS was just dropped --
strangely you didn't raise your voice against that)

>  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.

-Andi

Re: [PATCH for mm] Remove iBCS support

[David Newall]

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? :)

Re: [PATCH for mm] Remove iBCS support

[Andi Kleen]

> I think I do.  You appear to be arguing that small businesses, such as
> paint shops or garages, could re-install iBCS2 support. 

You seem to be under the illusion that iBCS2 support works currently
in mainline and that only this patch would break it. That's not 
the case.

It's a significant patchkit that was only available in 2.4 and is
now missing a lot of infrastructure and would probably be significant
non-trivial work to forward port. Now if someone does that work
they can as well readd the few hunks I'm removing here.

-Andi

Re: [PATCH for mm] Remove iBCS support

[David Newall]

Andi Kleen wrote:
> You seem to be under the illusion that iBCS2 support works currently
> in mainline and that only this patch would break it.
I cannot imagine what brings you to that conclusion.  Suffice to say you
are entirely and inexplicably wrong.

Re: [PATCH for mm] Remove iBCS support

[Karl Kiniger]

FYI, 

on http://www.feise.com/~jfeise/Downloads/linux-abi/

a patch named  linux-abi-2.6.22.3_3.diff.bz2 can be found.

(and I know a friend of mine got it working OK - old
Informix 4GL medical app compiled for SCO ... :-)

Karl


On Mon 080121, David Newall wrote:
> Andi Kleen wrote:
> > You seem to be under the illusion that iBCS2 support works currently
> > in mainline and that only this patch would break it.
> I cannot imagine what brings you to that conclusion.  Suffice to say you
> are entirely and inexplicably wrong.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Karl Kiniger            mailto:karl.kiniger@med.ge.com
GE Medical Systems Kretztechnik GmbH & Co OHG
Tiefenbach 15           Tel: (++43) 7682-3800-710  Voip(GE): 1662 710
A-4871 Zipf Austria     Fax: (++43) 7682-3800-47 C: +43 6991 3800 710

Re: [PATCH for mm] Remove iBCS support

[David Newall]

Karl Kiniger wrote:
> on http://www.feise.com/~jfeise/Downloads/linux-abi/
>
> a patch named  linux-abi-2.6.22.3_3.diff.bz2 can be found.
>   

Thankyou for that.

Matter of interest: if it works, why isn't it in the mainline?

Re: [PATCH for mm] Remove iBCS support

[Adrian Bunk]

On Wed, Jan 23, 2008 at 01:36:27AM +1030, David Newall wrote:
> Karl Kiniger wrote:
> > on http://www.feise.com/~jfeise/Downloads/linux-abi/
> >
> > a patch named  linux-abi-2.6.22.3_3.diff.bz2 can be found.
> 
> Thankyou for that.
> 
> Matter of interest: if it works, why isn't it in the mainline?

This you have to ask the person offering this patch.

Patches don't enter the kernel by themselves, someone has to submit 
them.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH for mm] Remove iBCS support

[Andi Kleen]

Karl Kiniger <karl.kiniger@med.ge.com> writes:

> FYI, 
> 
> on http://www.feise.com/~jfeise/Downloads/linux-abi/
> 
> a patch named  linux-abi-2.6.22.3_3.diff.bz2 can be found.

So just add a reversed version of my binfmt_elf patch to that.
If people need to apply a patch anyways it doesn't make much
difference if it has a few more hunks.

-Andi

Re: [PATCH for mm] Remove iBCS support

[Karl Kiniger]

On Wed 080123, Andi Kleen wrote:
> Karl Kiniger <karl.kiniger@med.ge.com> writes:
> 
> > FYI, 
> > 
> > on http://www.feise.com/~jfeise/Downloads/linux-abi/
> > 
> > a patch named  linux-abi-2.6.22.3_3.diff.bz2 can be found.
> 
> So just add a reversed version of my binfmt_elf patch to that.
> If people need to apply a patch anyways it doesn't make much
> difference if it has a few more hunks.

it will force to recompile. The latest version of linux-abi  on 
SourceForge is named ibcs-3_4.tgz and IIRC it can be built
as an external module w/o kernel recompile.

Karl

> 
> -Andi

-- 
Karl Kiniger            mailto:karl.kiniger@med.ge.com
GE Medical Systems Kretztechnik GmbH & Co OHG
Tiefenbach 15           Tel: (++43) 7682-3800-710  Voip(GE): 1662 710
A-4871 Zipf Austria     Fax: (++43) 7682-3800-47 C: +43 6991 3800 710

Re: [PATCH for mm] Remove iBCS support

[Andi Kleen]

On Wednesday 23 January 2008 15:12:22 Karl Kiniger wrote:
> On Wed 080123, Andi Kleen wrote:
> > Karl Kiniger <karl.kiniger@med.ge.com> writes:
> > > FYI,
> > >
> > > on http://www.feise.com/~jfeise/Downloads/linux-abi/
> > >
> > > a patch named  linux-abi-2.6.22.3_3.diff.bz2 can be found.
> >
> > So just add a reversed version of my binfmt_elf patch to that.
> > If people need to apply a patch anyways it doesn't make much
> > difference if it has a few more hunks.
>
> it will force to recompile. The latest version of linux-abi  on
> SourceForge is named ibcs-3_4.tgz and IIRC it can be built
> as an external module w/o kernel recompile.

Ok I wasn't aware of that earlier.

Does it really work on a recent kernel (as in .23 or .24-rc)? I have my doubts 
especially since  the default_ldt is gone it will be probably difficult for 
an external module to implement the lcall7 and lcall27 entry points.

<reads code> Ok it seems to load its own GDT and IDT. With that lcall
might still work. It's unclear how it works on SMP and how TLS rewriting
still works. But you don't really expect us to support any kernel modules who 
do such hacks, do you? This thing is likely pure race country anyways. I hope
nobody uses it in production.

Anyways what it could still do is to register an own copy or wrapper of the 
ELF loader that is registered before the normal binfmt_elf and then
checks for its own flavour of ELF and handles that and passes all
other binaries on.

I stand by my earlier point that it doesn't make sense to have all
Linux kernels always execute these strcmps.

-Andi

Re: [PATCH for mm] Remove iBCS support

[David Newall]

Andi Kleen wrote:
> I stand by my earlier point that it doesn't make sense to have all
> Linux kernels always execute these strcmps.
>   

Why?  It's a trivial expense.  Alternatively, (rhetorically), why not
also remove AOUT and COFF support?  Same argument.

Re: [PATCH for mm] Remove iBCS support

[Ingo Molnar]

* David Newall <davidn@davidnewall.com> wrote:

> Andi Kleen wrote:
> > You seem to be under the illusion that iBCS2 support works currently
> > in mainline and that only this patch would break it.
>
> I cannot imagine what brings you to that conclusion.  Suffice to say 
> you are entirely and inexplicably wrong.

it should be very easy for you to prove me wrong then. I've got a very 
simple question: please tell me, how do i run a binary compiled for an 
iBCS2 platform under Linux v2.6.23?

I've got plenty of v2.6.23-running testsystems, tell me, if i wanted, 
how could i run any iBCS2 binary on them? All i see is a massive, 
2.4-kernels-only patchkit:

   http://www.kernel.org/pub/linux/kernel/people/hch/linux-abi/v2.4/

which external patch-kit was not picked up by major distros and which 
was never integrated into the upstream kernel either. iBCS2 support in 
Linux 2.6 simply does not exist.

	Ingo

Re: [PATCH for mm] Remove iBCS support

[Karl Kiniger]

On Tue 080122, Ingo Molnar wrote:
> 
> * David Newall <davidn@davidnewall.com> wrote:
> 
> > Andi Kleen wrote:
> > > You seem to be under the illusion that iBCS2 support works currently
> > > in mainline and that only this patch would break it.
> >
> > I cannot imagine what brings you to that conclusion.  Suffice to say 
> > you are entirely and inexplicably wrong.
> 
> it should be very easy for you to prove me wrong then. I've got a very 
> simple question: please tell me, how do i run a binary compiled for an 
> iBCS2 platform under Linux v2.6.23?


at least the Changelog for ibcs-3.4.tar.gz found on

http://sourceforge.net/project/showfiles.php?group_id=13130

says:

2007-10-11  Alex <agon04@users.sourceforge.net>

        ibcs-3.4

        * support for Kernel 2.6.23 added
        * support for SUSE AppArmor


I did not try this one myself.

Karl

> 
> I've got plenty of v2.6.23-running testsystems, tell me, if i wanted, 
> how could i run any iBCS2 binary on them? All i see is a massive, 
> 2.4-kernels-only patchkit:
> 
>    http://www.kernel.org/pub/linux/kernel/people/hch/linux-abi/v2.4/
> 
> which external patch-kit was not picked up by major distros and which 
> was never integrated into the upstream kernel either. iBCS2 support in 
> Linux 2.6 simply does not exist.
> 
> 	Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Karl Kiniger            mailto:karl.kiniger@med.ge.com
GE Medical Systems Kretztechnik GmbH & Co OHG
Tiefenbach 15           Tel: (++43) 7682-3800-710  Voip(GE): 1662 710
A-4871 Zipf Austria     Fax: (++43) 7682-3800-47 C: +43 6991 3800 710

Re: [PATCH for mm] Remove iBCS support

[David Newall]

Ingo Molnar wrote:
> * David Newall <davidn@davidnewall.com> wrote:
>   
>> Andi Kleen wrote:
>>     
>>> You seem to be under the illusion that iBCS2 support works currently
>>> in mainline and that only this patch would break it.
>>>       
>> I cannot imagine what brings you to that conclusion.  Suffice to say 
>> you are entirely and inexplicably wrong.
>>     
>
> it should be very easy for you to prove me wrong then. I've got a very 
> simple question: please tell me, how do i run a binary compiled for an 
> iBCS2 platform under Linux v2.6.23?
>   

You're being silly.  Either that or you're not reading what I write. 
You know perfectly well iBCS2 compatibility doesn't work (anymore.)  The
question, in my mind, is will it ever be made to work again?  I think
the answer should be yes.

Re: [PATCH for mm] Remove iBCS support

[Ingo Molnar]

* David Newall <davidn@davidnewall.com> wrote:

> >>> You seem to be under the illusion that iBCS2 support works currently
> >>> in mainline and that only this patch would break it.
> >>>       
> >> I cannot imagine what brings you to that conclusion.  Suffice to say 
> >> you are entirely and inexplicably wrong.
> >>     
> >
> > it should be very easy for you to prove me wrong then. I've got a very 
> > simple question: please tell me, how do i run a binary compiled for an 
> > iBCS2 platform under Linux v2.6.23?
> >   
> 
> You're being silly.  Either that or you're not reading what I write. 
> You know perfectly well iBCS2 compatibility doesn't work (anymore.)  
> The question, in my mind, is will it ever be made to work again?  I 
> think the answer should be yes.

unfortunately you have not replied to my (rather clear) question. Let me 
repeat the question (which can be clearly seen in the quoted sections 
above). Andi made this assertion:

|  You seem to be under the illusion that iBCS2 support works currently 
|  in mainline and that only this patch would break it.

And you claimed that what Andi says is false:

||  I cannot imagine what brings you to that conclusion.  Suffice to say 
||  you are entirely and inexplicably wrong.

All i did was to ask your proof for why you claim that Andi is wrong - 
i.e. why you think that: "iBCS2 support works currently in mainline" is 
not an illusion. Please give me that proof or retract your statement, if 
it was done in error. v2.6.23 is the current mainline kernel.

	Ingo

Re: [PATCH for mm] Remove iBCS support

[David Newall]

Ingo Molnar wrote:
> unfortunately you have not replied to my (rather clear) question. Let me
> repeat the question (which can be clearly seen in the quoted sections 
> above). Andi made this assertion:
>
> |  You seem to be under the illusion that iBCS2 support works currently 
> |  in mainline and that only this patch would break it.
>
> And you claimed that what Andi says is false:
>
> ||  I cannot imagine what brings you to that conclusion.  Suffice to say 
> ||  you are entirely and inexplicably wrong.
>   
> All i did was to ask your proof for why you claim that Andi is wrong - 
>   
I am under no illusion that iBCS2 support works currently in mainline. 
I have said nothing that suggest otherwise.  Please stop wasting
everyone's time, and especially mine, with this wilful failure to
understand.

Re: [PATCH for mm] Remove iBCS support

[Adrian Bunk]

On Wed, Jan 23, 2008 at 01:43:30AM +1030, David Newall wrote:
> Ingo Molnar wrote:
> > * David Newall <davidn@davidnewall.com> wrote:
> >   
> >> Andi Kleen wrote:
> >>     
> >>> You seem to be under the illusion that iBCS2 support works currently
> >>> in mainline and that only this patch would break it.
> >>>       
> >> I cannot imagine what brings you to that conclusion.  Suffice to say 
> >> you are entirely and inexplicably wrong.
> >>     
> >
> > it should be very easy for you to prove me wrong then. I've got a very 
> > simple question: please tell me, how do i run a binary compiled for an 
> > iBCS2 platform under Linux v2.6.23?
> >   
> 
> You're being silly.  Either that or you're not reading what I write. 
> You know perfectly well iBCS2 compatibility doesn't work (anymore.)  The
> question, in my mind, is will it ever be made to work again?  I think
> the answer should be yes.

Fact is that it isn't working with what is in the kernel today.

That is enough for justifying the removal of what is dead code today.

If someone submits at some point in the future a patch using this stuff 
he can as well put these tiny bits back.

But Linux kernel development is not driven by people producing hot air 
about what they wish to see in the future, Linux kernel development is 
driven by people sending patches.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH for mm] Remove iBCS support

[David Newall]

Adrian Bunk wrote:
> But Linux kernel development is not driven by people producing hot air 
> about what they wish to see in the future, Linux kernel development is 
> driven by people sending patches.

Removal of code is not development.  It's the opposite of development.

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.

Re: [PATCH for mm] Remove iBCS support

[Adrian Bunk]

On Fri, Jan 25, 2008 at 03:34:17AM +1030, David Newall wrote:
> Adrian Bunk wrote:
> > But Linux kernel development is not driven by people producing hot air 
> > about what they wish to see in the future, Linux kernel development is 
> > driven by people sending patches.
> 
> Removal of code is not development.  It's the opposite of development.

Removing dead code makes:
- the kernel smaller,
- the kernel faster and
- makes it easier to maintain the non-dead code.

All of these are considered useful by the people who actually 
contribute to the Linux kernel.

> 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?

And if you consider iBCS2 support that important I can only repeat that 
the language on Linux kernel are patches, not hot air.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH for mm] Remove iBCS support

[David Newall]

Adrian Bunk wrote:
> Removing dead code makes:
> - the kernel smaller,
> - the kernel faster and
> - makes it easier to maintain the non-dead code.
>   

The performance benefit is trivial, and the improvement to
maintainability is even less.

> All of these are considered useful by the people who actually 
> contribute to the Linux kernel.
>   

Contributions to the kernel take forms other than just code.  I'm
contributing in this very instance by putting the argument against
removal of code.  Once removed it'll be much harder to re-insert than to
repair in-situ.

>> 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.

> And if you consider iBCS2 support that important I can only repeat that 
> the language on Linux kernel are patches, not hot air.
>   

Fools believe that code is the only acceptable offering, and you, by
reputation, are not a fool.  There are plenty of examples where
suggestions made on list have value far exceeding a lot of the code. 
For that matter, some of the code that's offered is crap.  For that
matter, good contributed code too often (and in some cases famously)
gets ignored or rejected for reasons of ego.  You diminish yourself by
implying that code is the only thing that matters, and present the
impression that you know little about good development practice, in
which design effort exceeds that of coding.  I do not believe you are a
cowboy; stop talking like one.

Look at the merits of iBCS2 support.  Is it desirable?  Yes.  Is it
useful to remove what support remains?  Not particularly.  Does it
improve performance?  Trivially; almost immeasurably.   Does it improve
clarity?  No.  Does the code serve any useful purpose?  Yes, by acting
as a reminder of work still be done.  It's like the /* XXX */ comments
that are widely sprinkled through the system, only more concrete.  The
benefits of removing it do not outweigh the benefits of leaving it.

Re: [PATCH for mm] Remove iBCS support

[Adrian Bunk]

On Fri, Jan 25, 2008 at 04:25:24AM +1030, David Newall wrote:
> Adrian Bunk wrote:
> > Removing dead code makes:
> > - the kernel smaller,
> > - the kernel faster and
> > - makes it easier to maintain the non-dead code.
> 
> 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.

Even in the hypothetical case that someone would use it, he could simply 
re-add it.

> > All of these are considered useful by the people who actually 
> > contribute to the Linux kernel.
> 
> Contributions to the kernel take forms other than just code.  I'm
> contributing in this very instance by putting the argument against
> removal of code.  Once removed it'll be much harder to re-insert than to
> repair in-situ.

What you are doing is not contributing but wasting other people's time.

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

> >> 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.

Which kernels under ftp://ftp.kernel.org/pub/linux/kernel/v*.*/ fulfill 
your claim?

> > And if you consider iBCS2 support that important I can only repeat that 
> > the language on Linux kernel are patches, not hot air.
> 
> Fools believe that code is the only acceptable offering, and you, by
> reputation, are not a fool.  There are plenty of examples where
> suggestions made on list have value far exceeding a lot of the code. 
> For that matter, some of the code that's offered is crap.  For that
> matter, good contributed code too often (and in some cases famously)
> gets ignored or rejected for reasons of ego.  You diminish yourself by
> implying that code is the only thing that matters, and present the
> impression that you know little about good development practice, in
> which design effort exceeds that of coding.  I do not believe you are a
> cowboy; stop talking like one.
> 
> Look at the merits of iBCS2 support.  Is it desirable?  Yes.  Is it
> useful to remove what support remains?  Not particularly.  Does it
> improve performance?  Trivially; almost immeasurably.   Does it improve
> clarity?  No.  Does the code serve any useful purpose?  Yes, by acting
> as a reminder of work still be done.  It's like the /* XXX */ comments
> that are widely sprinkled through the system, only more concrete.  The
> benefits of removing it do not outweigh the benefits of leaving it.

The point is that ideas do not turn themselves into code.

And there are far too many people who want to see their great ideas 
implemented without implementing it themselves.

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

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH for mm] Remove iBCS support

[David Newall]

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.

Re: [PATCH for mm] Remove iBCS support

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

On Fri, 25 Jan 2008 12:44:05 +1030, David Newall said:

> 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.

Well, if the 2.4 version hasn't been ported by 2.6.24, maybe we'll check
back in *another* 4 years when we're up to 2.6.48.  There's a limit to
how much "eventually" we should drag along.

We (especially Adrian) remove stuff from the kernel *all the time* with the
notation "If anybody wants to get this hook back, it's easy enough to re-add it
when an actual user shows up".  I don't see why iBCS should be treated any
differently.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH for mm] Remove iBCS support

[Alan Cox]

> 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.

And whoever does the work can put the code back. It's not a big deal. So
- get it sorted, polished and as I said before - send patches -. The
amount of time you've spent making mailing list noise should have been
sufficient to do the code instead.

Re: [PATCH for mm] Remove iBCS support

[Pavel Machek]

On Fri 2008-01-25 04:25:24, David Newall wrote:
> Adrian Bunk wrote:
> > Removing dead code makes:
> > - the kernel smaller,
> > - the kernel faster and
> > - makes it easier to maintain the non-dead code.
> >   
> 
> The performance benefit is trivial, and the improvement to
> maintainability is even less.
> 
> > All of these are considered useful by the people who actually 
> > contribute to the Linux kernel.
> >   
> 
> Contributions to the kernel take forms other than just code.  I'm
> contributing in this very instance by putting the argument against
> removal of code.  Once removed it'll be much harder to re-insert than to
> repair in-situ.

/-------------------------\
|                         |
| Stop feeding the TROLL  |
|                         |
\-------------------------/
            ||
            ||
            ||
            ||
            ||
            ||
            ||
				(yes, that's you, David. You are
				wasting everyone's time. Go away.)

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH for mm] Remove iBCS support

[David Newall]

Pavel Machek wrote:
> /-------------------------\
> |                         |
> | Stop feeding the TROLL  |
> |                         |
> \-------------------------/
>             ||
>             ||
>             ||
>             ||
>             ||
>             ||
>             ||
>   
Pavel is trolling.  He is using an emotional attack in an attempt to
thwart discussion.  I take his advice.  I feed him not.

Re: [PATCH for mm] Remove iBCS support

[Andi Kleen]

> The performance benefit is trivial,

That's actually not true when you're talking about potential cache misses.
Cache misses are very expensive.

-Andi

Re: [PATCH for mm] Remove iBCS support

[David Newall]

Andi Kleen wrote:
>> The performance benefit is trivial,
>>     
>
> That's actually not true when you're talking about potential cache misses.
> Cache misses are very expensive.
>   

They are when in a tight loop, but are trivial in this case.  I'll go
further and say that unless the system is constantly execing, there will
always be a cache miss, and that removing this code will not improve
that at all.

Re: [PATCH for mm] Remove iBCS support

[Alan Cox]

 
> You're being silly.  Either that or you're not reading what I write. 
> You know perfectly well iBCS2 compatibility doesn't work (anymore.)  The
> question, in my mind, is will it ever be made to work again?  I think
> the answer should be yes.

We await your patches. If you think it should be done then rework the
code, test it and figure how to merge it nicely.

Alan

Re: [PATCH for mm] Remove iBCS support

[David Newall]

Alan Cox wrote:
>  
>   
>> You're being silly.  Either that or you're not reading what I write. 
>> You know perfectly well iBCS2 compatibility doesn't work (anymore.)  The
>> question, in my mind, is will it ever be made to work again?  I think
>> the answer should be yes.
>>     
>
> We await your patches. If you think it should be done then rework the
> code, test it and figure how to merge it nicely.

Apparently a patch already exists.

Re: [PATCH for mm] Remove iBCS support

[Giulio]

Andi Kleen <andi@firstfloor.org> wrote:

>> I think I do.  You appear to be arguing that small businesses, such as
>> paint shops or garages, could re-install iBCS2 support. 
>
>You seem to be under the illusion that iBCS2 support works currently
>in mainline and that only this patch would break it. That's not 
>the case.
>
>It's a significant patchkit that was only available in 2.4 and is
>now missing a lot of infrastructure and would probably be significant

AFAIK ibcs is fully functional in 2.6 via external modules (no patch
needed).
http://downloads.sourceforge.net/linux-abi/ibcs-3_4.tgz

If your proposed change goes in, I think a patch will be necessary (ie no
more kmod-ibcs-.....)
-- 
giulioo@pobox.com

Re: [PATCH for mm] Remove iBCS support

[Alan Cox]

> 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.

And they mostly use microfocus cobol which is available on Linux and uses
a vm is a trivial port, or they do a quick port to the fujitsu
cobol->java vm translator.

There are people in this community who deal day in and day out with
migrations. I don't hear a whisper of concern from those I deal with
about losing iBCS. 

Alan

Re: [PATCH for mm] Remove iBCS support

[David Newall]

Alan Cox 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.
>>     
>
> And they mostly use microfocus cobol which is available on Linux
Or RM Cobol, which is also available on Linux.  Both of these require
significant expense in new licences.

> or they do a quick port to the fujitsu cobol->java vm translator.
>   
I don't know of this thing, but I have looked, on behalf of a colleague,
for tools that can compile his existing COBOL source, and found only
partial solutions (i.e. found nothing.)

> There are people in this community who deal day in and day out with
> migrations. I don't hear a whisper of concern from those I deal with
> about losing iBCS. 
Well, I'm whispering:  The cost is that something desirable but
incomplete would be removed.  While it's there it's a constant source of
irritation to those in the know.  Once removed it can be forgotten.  So
the cost is really that iBCS2 compatibility becomes less likely.  What's
the benefit in removing it?  Up to 20 cycles per exec?  That's nothing.

Re: [PATCH for mm] Remove iBCS support

[Alan Cox]

> Well, I'm whispering:  The cost is that something desirable but
> incomplete would be removed.  While it's there it's a constant source of
> irritation to those in the know.  Once removed it can be forgotten.  So
> the cost is really that iBCS2 compatibility becomes less likely.  What's
> the benefit in removing it?  Up to 20 cycles per exec?  That's nothing.

Well you whispered many years too late. iBCS support vanished in 2.4
because nobody cared, nobody wanted to maintain it and not a single
vendor saw a business demand to justify assigning someone to do any work
with it.

If you want it back then you need to port the 2.4 iBCS emulation layer
code to 2.6 first. Of course you could probably  also do it all in user
space with some LD_PRELOAD work and binfmt_misc. That might be a bit
slower but a lot more portable.

Alan

Re: [PATCH for mm] Remove iBCS support

[Ingo Molnar]

* Andi Kleen <andi@firstfloor.org> wrote:

> Remove ibcs2 support in ELF loader too
> 
> ibcs2 support has never been supported on 2.6 kernels as far as I 
> know, and if it has it must have been an external patch. Anyways, if 
> anybody applies an external patch they could as well readd the ibcs 
> checking code to the ELF loader in the same patch. But there is no 
> reason to keep this code running in all Linux kernels. This will save 
> at least two strcmps each ELF execution.
> 
> No deprecation period because it could not have been used anyways.

thanks Andi, i have applied your cleanup patch to x86.git a couple of 
days ago and it (no surprise) caused no testing problems so far. (I dont 
think we need to backport this cleanup to v2.6.24.1, as iBCS2 support 
was never present in any upstream Linux kernel anyway)

	Ingo