> 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
>
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 porte
Pavel Machek wrote:
> /-\
> | |
> | Stop feeding the TROLL |
> | |
> \-/
> ||
> ||
> ||
> ||
> ||
> ||
> ||
>
Pavel
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 co
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
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 e
> 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
> maintainabili
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 no
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 yo
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 supp
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 an
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 jus
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
di
> 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 mainline?
* 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 inexpli
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. Suff
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 linux-kerne
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 conclusion
* 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 inexplic
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
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 li
> 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 ben
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
> tow
> 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 pa
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 licenc
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 Do
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 opport
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 gi
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 wai
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
41 matches
Mail list logo
