Remove iBCS support
Subsystems (2)
PATCH 1/1 Remove iBCS support
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.
--- fs/binfmt_elf.c | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-)
fs/binfmt_elf.c +3 -12
@@ -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 ;
Quoted 2 lines · Andi Kleen
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.
Quoted 5 lines · David Newall
Quoted 2 lines · Andi Kleen
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?
Quoted 1 line
compatibility. This is a sleeping giant for Linux. There are plenty of
Interesting choice of words.
Quoted 4 lines
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
Quoted 1 line
Quoted 7 lines · Andi Kleen
Quoted 2 lines · David Newall
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.
Quoted 3 lines
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.
Quoted 10 lines · David Newall
Quoted 7 lines · Andi Kleen
Quoted 2 lines · David Newall
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 1 line
simplification of the story, I know, but still hits the plot highlights.
You're worried about this patch generating headlines?
-Andi
Quoted 13 lines · Andi Kleen
Quoted 11 lines · David Newall
Quoted 9 lines · Andi Kleen
Quoted 3 lines · David Newall
compatibility. This is a sleeping giant for Linux. There are plenty of
Interesting choice of words.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 9 lines
Quoted 8 lines
Quoted 4 lines
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.
Quoted 5 lines
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.
Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 4 lines
Quoted 2 lines
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.
Quoted 5 lines · David Newall
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.
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Quoted 5 lines
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.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 5 lines
Quoted 4 lines
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)
Quoted 4 lines
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
Quoted 9 lines · Andi Kleen
Quoted 6 lines · David Newall
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.
Quoted 3 lines
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.
Quoted 4 lines
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.
Quoted 3 lines
(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.
Quoted 7 lines
Quoted 5 lines
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? :)
Quoted 2 lines
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
Quoted 2 lines · Andi Kleen
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.
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
Quoted 10 lines · David Newall
Quoted 2 lines · Andi Kleen
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 4 lines
Karl Kiniger mailto:[email protected] 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
Quoted 4 lines · Karl Kiniger
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?
Quoted 8 lines · David Newall
Quoted 3 lines · Karl Kiniger
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
Signature · 4 lines
"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 SeedQuoted 5 lines · 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.
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
Quoted 11 lines · Andi Kleen
Quoted 5 lines · 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.
So just add a reversed version of my
binfmt_elfpatch 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
Quoted 2 lines
-Andi
Signature · 4 lines
Karl Kiniger mailto:[email protected] 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
Quoted 8 lines · On Wednesday 23 January 2008 15:12:22 Karl Kiniger wrote:
Quoted 7 lines · Andi Kleen
Quoted 5 lines · 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.
Quoted 7 lines
Quoted 3 lines
So just add a reversed version of my
binfmt_elfpatch 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
Quoted 3 lines · Andi Kleen
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.
Quoted 6 lines · David Newall
Quoted 2 lines · Andi Kleen
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
Quoted 7 lines · Ingo Molnar
Quoted 4 lines · David Newall
Quoted 2 lines · Andi Kleen
You seem to be under the illusion that iBCS2 support works currently in mainline and that only this patch would break it.
Quoted 6 lines
Quoted 2 lines
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 <[email protected]>
ibcs-3.4
* support for Kernel 2.6.23 added
* support for SUSE AppArmor
I did not try this one myself.
Karl
Quoted 17 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 4 lines
Karl Kiniger mailto:[email protected] 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
Quoted 7 lines · Ingo Molnar
Quoted 5 lines · David Newall
Quoted 3 lines · Andi Kleen
You seem to be under the illusion that iBCS2 support works currently in mainline and that only this patch would break it.
Quoted 8 lines
Quoted 3 lines
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.
Quoted 12 lines · David Newall
Quoted 11 lines
Quoted 6 lines
Quoted 3 lines
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?
Quoted 4 lines
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
Quoted 7 lines · Ingo Molnar
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.
Quoted 7 lines
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.
Quoted 17 lines · David Newall
Quoted 7 lines · Ingo Molnar
Quoted 5 lines · David Newall
Quoted 3 lines · Andi Kleen
You seem to be under the illusion that iBCS2 support works currently in mainline and that only this patch would break it.
Quoted 8 lines
Quoted 3 lines
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?
Quoted 4 lines
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
Signature · 4 lines
"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 SeedQuoted 3 lines · Adrian Bunk
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.
Quoted 6 lines · David Newall
Quoted 3 lines · Adrian Bunk
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.
Quoted 3 lines
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
Signature · 4 lines
"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 SeedQuoted 5 lines · Adrian Bunk
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.
Quoted 3 lines
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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 8 lines · David Newall
Quoted 4 lines · Adrian Bunk
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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 9 lines
Quoted 7 lines
Quoted 4 lines
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?
Quoted 14 lines
Quoted 2 lines
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.
Quoted 7 lines
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
Signature · 4 lines
"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 SeedQuoted 11 lines · Adrian Bunk
Quoted 3 lines · David Newall
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.
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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.
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
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.
...
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 3 lines · David Newall
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.
Quoted 4 lines
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.
Quoted 1 line
The performance benefit is trivial,
That's actually not true when you're talking about potential cache misses. Cache misses are very expensive.
-Andi
Quoted 6 lines · Andi Kleen
Quoted 2 lines
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.
Quoted 10 lines · David Newall
Quoted 5 lines · Adrian Bunk
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.
Quoted 8 lines
Quoted 3 lines
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
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 13 lines · Pavel Machek
/-------------------------\
| | | 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.
Quoted 5 lines
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
Quoted 10 lines · Alan Cox
Quoted 7 lines
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.
Quoted 9 lines · Andi Kleen
Quoted 2 lines
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-.....)
Signature · 1 line
[email protected]
Quoted 5 lines
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
Quoted 8 lines · Alan Cox
Quoted 6 lines
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.
Quoted 2 lines
or they do a quick port to the fujitsu
cobol->javavm 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.)
Quoted 3 lines
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.
Quoted 5 lines
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
Quoted 10 lines · Andi Kleen
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