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_interp...
[ message continues ]

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

--

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.

--

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

KFC and Dominoes use SCO for their cash registers, to pick just two
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.

--

I suppose if they update their cash registers they will just go 
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
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 
You're worried about this patch generating headlines?
-Andi

--

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
It still adds up to something that nobody can perceive, not even using a

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

--

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

--

Or RM Cobol, which is also available on Linux.  Both of these require

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

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

--

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
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
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 --
Sorry, but I don't think you know what you're talking about here.
-Andi
--

If they migrate they buy a new run-time licence.  These costs about a

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

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

--

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

--

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

--

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

--

Apparently a patch already exists.

--

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

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.

--

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

The performance benefit is trivial, and the improvement to
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

I don't know when.  Are you disputing that it ever did?  I think it's a
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.

--

/-------------------------\

|                         |

| 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

--

Pavel is trolling.  He is using an emotional attack in an attempt to

thwart discussion.  I take his advice.  I feed him not.

--

> The performance benefit is trivial,
That's actually not true when you're talking about potential cache misses.

Cache misses are very expensive.
-Andi
--

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.

--

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

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
I'm comfortable with that.  I'm also comfortable that consensus might go
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.
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

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

--

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.

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

--

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.

--

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

--

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

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

--

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

--

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

--

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

--

Why?  It's a trivial expense.  Alternatively, (rhetorically), why not

also remove AOUT and COFF support?  Same argument.

--

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