> 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
* Andi Kleen <[EMAIL PROTECTED]> 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
* Andi Kleen [EMAIL PROTECTED] 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
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
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
Pavel Machek wrote:
> /-\
> | |
> | Stop feeding the TROLL |
> | |
> \-/
> ||
> ||
> ||
> ||
> ||
> ||
> ||
>
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
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
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
> The performance benefit is trivial,
That's actually not true when you're talking about potential cache misses.
Cache misses are very expensive.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
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
>
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
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
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
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.
--
To unsubscribe from this list: send
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
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
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
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
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.
--
To unsubscribe from this list: send
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.
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
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
The performance benefit is trivial,
That's actually not true when you're talking about potential cache misses.
Cache misses are very expensive.
-Andi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
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.
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
Pavel Machek wrote:
/-\
| |
| Stop feeding the TROLL |
| |
\-/
||
||
||
||
||
||
||
Pavel is
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
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
On Wednesday 23 January 2008 15:12:22 Karl Kiniger wrote:
> On Wed 080123, Andi Kleen wrote:
> > Karl Kiniger <[EMAIL PROTECTED]> 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
On Wed 080123, Andi Kleen wrote:
> Karl Kiniger <[EMAIL PROTECTED]> 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
Karl Kiniger <[EMAIL PROTECTED]> 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
Karl Kiniger [EMAIL PROTECTED] 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
On Wed 080123, Andi Kleen wrote:
Karl Kiniger [EMAIL PROTECTED] 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
> 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
On Wed, Jan 23, 2008 at 01:43:30AM +1030, David Newall wrote:
> Ingo Molnar wrote:
> > * David Newall <[EMAIL PROTECTED]> 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
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
* David Newall <[EMAIL PROTECTED]> 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
Ingo Molnar wrote:
> * David Newall <[EMAIL PROTECTED]> 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.
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?
--
To unsubscribe from this list: send the line "unsubscribe
Andi Kleen <[EMAIL PROTECTED]> 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.
On Tue 080122, Ingo Molnar wrote:
>
> * David Newall <[EMAIL PROTECTED]> 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
* David Newall <[EMAIL PROTECTED]> 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
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
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
* David Newall [EMAIL PROTECTED] 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
On Tue 080122, Ingo Molnar wrote:
* David Newall [EMAIL PROTECTED] 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
Andi Kleen [EMAIL PROTECTED] 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
Ingo Molnar wrote:
* David Newall [EMAIL PROTECTED] 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
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
On Wed, Jan 23, 2008 at 01:43:30AM +1030, David Newall wrote:
Ingo Molnar wrote:
* David Newall [EMAIL PROTECTED] 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
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
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
> 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
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
> 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'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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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.
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.
78 matches
Mail list logo
