Jonathan Morton wrote:
>
> >- the AGE_FACTOR calculation will overflow after the system has
> > an uptime of just _3_ days
>
> Tsk tsk tsk...
>
> >Now if you can make something which preserves the heuristics which
> >serve us so well on desktop boxes and add something that makes it
> >also
Alan Cox wrote:
>
> > That depends what you mean by "must not". If it's your missile guidance
> > system, aircraft autopilot or life support system, the system must not run
> > out of memory in the first place. If the system breaks down badly, killing
> > init and thus panicking (hence
Rik van Riel wrote:
>
> On Sun, 25 Mar 2001, Martin Dalecki wrote:
>
> > Ah... and of course I think this patch can already go directly
> > into the official kernel. The quality of code should permit
> > it. I would esp. request Rik van
Linus Torvalds wrote:
>
> On Sat, 24 Mar 2001 [EMAIL PROTECTED] wrote:
> >
> > We need a size, and I am strongly in favor of sizeof(dev_t) = 8;
> > this is already true in glibc.
>
> The fact that glibc is a quivering mass of bloat, and total and utter crap
> makes you suggest that the Linux
Stephen Satchell wrote:
>
> At 12:41 AM 3/25/01 +0100, you wrote:
> >If your box is running for example a mail server, and it appears that
> >another process is juste eating the free memory, do you really want to kill
> >the mail server, just because it's the main process and consuming more
>
Jonathan Morton wrote:
>
> >Right now my best approximation is to make the OOM test be as optimistic as
> >it is safe to be, and the vm_enough_memory() test as pessimistic as
> >sensible. Expect a test patch to appear on this list soon.
>
> ...and here it is!
>
> This fixes a number of small
Jeff Garzik wrote:
>
> Also for 2.5, kdev_t needs to go away, along with all those arrays based
> on major number, and be replaced with either "struct char_device" or
> "struct block_device" depending on the device.
>
> I actually went through the kernel in 2.4.0-test days and did this.
> Most
Benoit Garnier wrote:
>
> Szabolcs Szakacsits wrote :
>
> > But if you start
> > to think you get the conclusion that process killing can't be avoided if
> > you want the system keep running.
>
> What's the point in keeping the OS running if the applications are silently
> killed?
>
> If your
Mike Galbraith wrote:
>
> On Sat, 24 Mar 2001, Doug Ledford wrote:
>
> [snip list of naughty behavior]
>
> > What was that you were saying about "should *never* happen"? Oh, and let's
> Get off your lazy butts and do something about it. Don't work on the
> oom-killer though.. that's only a
Doug Ledford wrote:
>
> Horst von Brand wrote:
> >
> > "Christian Bodmer" <[EMAIL PROTECTED]> said:
> >
> > > I can't say I understand the whole MM system, however the random killing
> > > of processes seems like a rather unfortunate solution to the problem. If
> > > someone has a spare minute,
Martin Dalecki wrote:
>
> I have a constructive proposal:
>
> It would make much sense to make the oom killer
> leave not just root processes alone but processes belonging to a UID
> lower
> then a certain value as well (500). This would be:
>
> 1. Easly managable by
Martin Dalecki wrote:
I have a constructive proposal:
It would make much sense to make the oom killer
leave not just root processes alone but processes belonging to a UID
lower
then a certain value as well (500). This would be:
1. Easly managable by the admin. Just let oracle/www
Doug Ledford wrote:
Horst von Brand wrote:
"Christian Bodmer" [EMAIL PROTECTED] said:
I can't say I understand the whole MM system, however the random killing
of processes seems like a rather unfortunate solution to the problem. If
someone has a spare minute, maybe they could
Mike Galbraith wrote:
On Sat, 24 Mar 2001, Doug Ledford wrote:
[snip list of naughty behavior]
What was that you were saying about "should *never* happen"? Oh, and let's
Get off your lazy butts and do something about it. Don't work on the
oom-killer though.. that's only a symptom.
Jeff Garzik wrote:
Also for 2.5, kdev_t needs to go away, along with all those arrays based
on major number, and be replaced with either "struct char_device" or
"struct block_device" depending on the device.
I actually went through the kernel in 2.4.0-test days and did this.
Most kdev_t
Benoit Garnier wrote:
Szabolcs Szakacsits wrote :
But if you start
to think you get the conclusion that process killing can't be avoided if
you want the system keep running.
What's the point in keeping the OS running if the applications are silently
killed?
If your box is
Jonathan Morton wrote:
Right now my best approximation is to make the OOM test be as optimistic as
it is safe to be, and the vm_enough_memory() test as pessimistic as
sensible. Expect a test patch to appear on this list soon.
...and here it is!
This fixes a number of small but linked
Stephen Satchell wrote:
At 12:41 AM 3/25/01 +0100, you wrote:
If your box is running for example a mail server, and it appears that
another process is juste eating the free memory, do you really want to kill
the mail server, just because it's the main process and consuming more
memory and
Linus Torvalds wrote:
On Sat, 24 Mar 2001 [EMAIL PROTECTED] wrote:
We need a size, and I am strongly in favor of sizeof(dev_t) = 8;
this is already true in glibc.
The fact that glibc is a quivering mass of bloat, and total and utter crap
makes you suggest that the Linux kernel should
Rik van Riel wrote:
On Sun, 25 Mar 2001, Martin Dalecki wrote:
Ah... and of course I think this patch can already go directly
into the official kernel. The quality of code should permit
it. I would esp. request Rik van Riel to have a closer look
at it...
- the algorithms are just
Alan Cox wrote:
That depends what you mean by "must not". If it's your missile guidance
system, aircraft autopilot or life support system, the system must not run
out of memory in the first place. If the system breaks down badly, killing
init and thus panicking (hence rebooting, if the
Jonathan Morton wrote:
- the AGE_FACTOR calculation will overflow after the system has
an uptime of just _3_ days
Tsk tsk tsk...
Now if you can make something which preserves the heuristics which
serve us so well on desktop boxes and add something that makes it
also work on your
[EMAIL PROTECTED] wrote:
>
> [to various people]
>
> No, ulimit does not work. (But it helps a little.)
> No, /proc/sys/vm/overcommit_memory does not work.
>
> [to Alan]
>
> > Nobody feels its very important because nobody has implemented it.
>
> Yes, that is the right response.
> What can
SodaPop wrote:
>
> On Fri, 23 Mar 2001, Martin Dalecki wrote:
>
> > SodaPop wrote:
> > >
> > > Rik, is there any way we could get a /proc entry for this, so that one
> > > could do something like:
> >
> > I will respond; NO there is n
[EMAIL PROTECTED] wrote:
>
> Please point me to an Operating System that runs on any commonly available
> platform and fits your requirements.
> Nick
You don't beleve me if I tell you: DOS extender and JVM (Java Virtual
Machine)
-
To unsubscribe from this list: send the line
I have a constructive proposal:
It would make much sense to make the oom killer
leave not just root processes alone but processes belonging to a UID
lower
then a certain value as well (500). This would be:
1. Easly managable by the admin. Just let oracle/www and analogous users
have a UID
SodaPop wrote:
>
> Rik, is there any way we could get a /proc entry for this, so that one
> could do something like:
I will respond; NO there is no way for security reasons this is not a
good idea.
> cat /proc/oom-kill-scores | sort +3
-
To unsubscribe from this list: send the line
Rik van Riel wrote:
>
> On Sat, 23 Mar 2002, Martin Dalecki wrote:
>
> > This is due to the broken calculation formula in oom_kill().
>
> Feel free to write better-working code.
I don't get paid for it and I'm not idling through my days...
-
To unsubscribe from thi
Rik van Riel wrote:
On Sat, 23 Mar 2002, Martin Dalecki wrote:
This is due to the broken calculation formula in oom_kill().
Feel free to write better-working code.
I don't get paid for it and I'm not idling through my days...
-
To unsubscribe from this list: send the line "unsubs
SodaPop wrote:
Rik, is there any way we could get a /proc entry for this, so that one
could do something like:
I will respond; NO there is no way for security reasons this is not a
good idea.
cat /proc/oom-kill-scores | sort +3
-
To unsubscribe from this list: send the line "unsubscribe
I have a constructive proposal:
It would make much sense to make the oom killer
leave not just root processes alone but processes belonging to a UID
lower
then a certain value as well (500). This would be:
1. Easly managable by the admin. Just let oracle/www and analogous users
have a UID
[EMAIL PROTECTED] wrote:
Please point me to an Operating System that runs on any commonly available
platform and fits your requirements.
Nick
You don't beleve me if I tell you: DOS extender and JVM (Java Virtual
Machine)
-
To unsubscribe from this list: send the line "unsubscribe
SodaPop wrote:
On Fri, 23 Mar 2001, Martin Dalecki wrote:
SodaPop wrote:
Rik, is there any way we could get a /proc entry for this, so that one
could do something like:
I will respond; NO there is no way for security reasons this is not a
good idea.
cat /proc/oom-kill
[EMAIL PROTECTED] wrote:
[to various people]
No, ulimit does not work. (But it helps a little.)
No, /proc/sys/vm/overcommit_memory does not work.
[to Alan]
Nobody feels its very important because nobody has implemented it.
Yes, that is the right response.
What can one say? One
Rik van Riel wrote:
>
> On Sat, 23 Mar 2002, Martin Dalecki wrote:
>
> > Uptime of a process is a much better mesaure for a killing
> > candidate then it's size.
>
> You'll have fun with your root shell, then ;)
You mean the remote one?
> The current OOM code
Stephen Clouse wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sat, Mar 23, 2002 at 01:33:50AM +0100, Martin Dalecki wrote:
> > AMEN! TO THIS!
> > Uptime of a process is a much better mesaure for a killing candidate
> > then it's size.
>
Rik van Riel wrote:
On Sat, 23 Mar 2002, Martin Dalecki wrote:
Uptime of a process is a much better mesaure for a killing
candidate then it's size.
You'll have fun with your root shell, then ;)
You mean the remote one?
The current OOM code takes things like uptime, used cpu, size
Jonathan Morton wrote:
>
> >> If crashes are routine on this machine, I'd recommend that you take
> >> a serious look at your ram. (or if you're overclocking, don't)
> >
> >Crashes were routine, and I was not overclocking, so I took Mike's
> >advice and bought a new 256MB DIMM. The computer
Jonathan Morton wrote:
If crashes are routine on this machine, I'd recommend that you take
a serious look at your ram. (or if you're overclocking, don't)
Crashes were routine, and I was not overclocking, so I took Mike's
advice and bought a new 256MB DIMM. The computer hasn't crashed
Rik van Riel wrote:
>
> On Tue, 13 Mar 2001, Albert D. Cahalan wrote:
>
> > Bloat removal: being able to run without /proc mounted.
> >
> > We don't have "kernel speed". We have kernel-mode screwing around
> > with text formatting.
>
> Sounds like you might want to maintain an external patch
>
Rik van Riel wrote:
On Tue, 13 Mar 2001, Albert D. Cahalan wrote:
Bloat removal: being able to run without /proc mounted.
We don't have "kernel speed". We have kernel-mode screwing around
with text formatting.
Sounds like you might want to maintain an external patch
for the
Alan Cox wrote:
>
> > My work will concern with the internationalization of Linux
> > So, could anybody tell me what kinds of features should be in the
> > consideration when linux be localized from english to Japanese or chinese,
> > say using 2 bytes character set.
>
> Most of the Linux
"Albert D. Cahalan" wrote:
>
> Geert Uytterhoeven writes:
>
> > - The colors for the 16 color logo are wrong. We used a hack to
> > give the logo its own color palette, but this no longer works
> > as a side effect of a console color map bug being fixed a while
> > ago. The
"Albert D. Cahalan" wrote:
Geert Uytterhoeven writes:
- The colors for the 16 color logo are wrong. We used a hack to
give the logo its own color palette, but this no longer works
as a side effect of a console color map bug being fixed a while
ago. The solution is to
Alan Cox wrote:
My work will concern with the internationalization of Linux
So, could anybody tell me what kinds of features should be in the
consideration when linux be localized from english to Japanese or chinese,
say using 2 bytes character set.
Most of the Linux userspace
Peter Samuelson wrote:
>
> [BERECZ Szabolcs]
> > Here is a new syscall. With this you can change the owner of a running
> > procces.
>
> > + if (current->euid)
> > + return -EPERM;
>
> Use capable().
>
> > + p = find_task_by_pid(pid);
> > + p->fsuid = p->euid =
Peter Samuelson wrote:
[BERECZ Szabolcs]
Here is a new syscall. With this you can change the owner of a running
procces.
+ if (current-euid)
+ return -EPERM;
Use capable().
+ p = find_task_by_pid(pid);
+ p-fsuid = p-euid = p-suid = p-uid =
Linus Torvalds wrote:
>
> On Thu, 8 Feb 2001, Rik van Riel wrote:
>
> > On Thu, 8 Feb 2001, Mikulas Patocka wrote:
> >
> > > > > You need aio_open.
> > > > Could you explain this?
> > >
> > > If the server is sending many small files, disk spends huge
> > > amount time walking directory tree
Linus Torvalds wrote:
On Thu, 8 Feb 2001, Rik van Riel wrote:
On Thu, 8 Feb 2001, Mikulas Patocka wrote:
You need aio_open.
Could you explain this?
If the server is sending many small files, disk spends huge
amount time walking directory tree and seeking to inodes.
Linus Torvalds wrote:
>
> On Tue, 6 Feb 2001, Ben LaHaise wrote:
> >
> > On Tue, 6 Feb 2001, Stephen C. Tweedie wrote:
> >
> > > The whole point of the post was that it is merging, not splitting,
> > > which is troublesome. How are you going to merge requests without
> > > having chains of
Dnia Wto 19. Grudzie? 2000 18:45, Andries Brouwer napisa?:
> On Tue, Dec 19, 2000 at 06:14:04AM -0500, Paul Gortmaker wrote:
> > I always disliked the unknown partition table messages you get when you
> > mke2fs a whole disk and don't bother with a table at all, so I fixed it.
> > Output
Dnia Wto 19. Grudzie? 2000 18:45, Andries Brouwer napisa?:
On Tue, Dec 19, 2000 at 06:14:04AM -0500, Paul Gortmaker wrote:
I always disliked the unknown partition table messages you get when you
mke2fs a whole disk and don't bother with a table at all, so I fixed it.
Output before/after
"Justin T. Gibbs" wrote:
>
> >
> >What's wrong with current? It's perfectly fine, since it's the main data
> >context entity you are working with during it's usage... Just remember
> >it as
> >CURRENT MAIN PROBLEM the kernel is struggling with at time.
>
> What's wrong with the aic7xxx driver
"Justin T. Gibbs" wrote:
>
> >> BSD has curproc, but that is considerably less likely to be
> >> used in "inoccent code" than "current". I mean, "current what?".
> >> It could be anything, current privledges, current process, current
> >> thread, the current time...
> >
> >I see and I assume
"Justin T. Gibbs" wrote:
BSD has curproc, but that is considerably less likely to be
used in "inoccent code" than "current". I mean, "current what?".
It could be anything, current privledges, current process, current
thread, the current time...
I see and I assume calling a random
"Justin T. Gibbs" wrote:
What's wrong with current? It's perfectly fine, since it's the main data
context entity you are working with during it's usage... Just remember
it as
CURRENT MAIN PROBLEM the kernel is struggling with at time.
What's wrong with the aic7xxx driver storing the
Dietmar Kling wrote:
>
> Ok guys i take your arguments...
> (i really loved to hear them)
>
> and i'd like to continue them in a
> private discussion( but i am
> tired now ... :) )
>
> but a last one i cannot resist...
>
>
> but why are your ideas not widespread and
> so successful like
Dietmar Kling wrote:
Ok guys i take your arguments...
(i really loved to hear them)
and i'd like to continue them in a
private discussion( but i am
tired now ... :) )
but a last one i cannot resist...
sarcasm
but why are your ideas not widespread and
so successful like
Just a small trivial obviously correct update...
diff -ur linux/include/linux/pci_ids.h linux-mega/include/linux/pci_ids.h
--- linux/include/linux/pci_ids.h Tue Nov 21 16:31:52 2000
+++ linux-mega/include/linux/pci_ids.h Tue Nov 21 18:54:58 2000
@@ -257,6 +257,11 @@
#define
Just a small trivial obviously correct update...
diff -ur linux/include/linux/pci_ids.h linux-mega/include/linux/pci_ids.h
--- linux/include/linux/pci_ids.h Tue Nov 21 16:31:52 2000
+++ linux-mega/include/linux/pci_ids.h Tue Nov 21 18:54:58 2000
@@ -257,6 +257,11 @@
#define
Alexander Viro wrote:
>
> On 9 Nov 2000, Mike Coleman wrote:
>
> > Alexander Viro <[EMAIL PROTECTED]> writes:
> > > RMS had repeatedly demonstrated what he's worth as a designer
> > > and programmer. Way below zero. You may like or dislike his ideology,
> > > but when it comes to technical
Alexander Viro wrote:
On 9 Nov 2000, Mike Coleman wrote:
Alexander Viro [EMAIL PROTECTED] writes:
shrug RMS had repeatedly demonstrated what he's worth as a designer
and programmer. Way below zero. You may like or dislike his ideology,
but when it comes to technical stuff... Not
Martin Mares wrote:
>
> Hi Alan!
>
> > If the sound card is only used some of the time or setup and then used
> > for TV its nice to get the 60K + 128K DMA buffer back when you dont need it
> > especially on a low end box
>
> So why don't we allocate / free the DMA buffer on device open /
Martin Mares wrote:
Hi Alan!
If the sound card is only used some of the time or setup and then used
for TV its nice to get the 60K + 128K DMA buffer back when you dont need it
especially on a low end box
So why don't we allocate / free the DMA buffer on device open / close instead
Alan Cox wrote:
>
> > >Just load the driver at bootup and forget about it. Problem solved.
> >
> > I daily curse the name of whoever added autoload and autounload.
> > Autoload maybe useful, autounload is just asking for problems.
>
> Deal with it. Hardware is also now auto load and auto
David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > * Driver initializes mixer to 100% muted * Userspace app sets desired
> > values to /dev/mixer * Userspace app opens /dev/dsp to play sound
>
> > I don't see where any sound can "escape" in this scenario, and it
> > doesn't require any
David Woodhouse wrote:
[EMAIL PROTECTED] said:
* Driver initializes mixer to 100% muted * Userspace app sets desired
values to /dev/mixer * Userspace app opens /dev/dsp to play sound
I don't see where any sound can "escape" in this scenario, and it
doesn't require any module data
Alan Cox wrote:
Just load the driver at bootup and forget about it. Problem solved.
I daily curse the name of whoever added autoload and autounload.
Autoload maybe useful, autounload is just asking for problems.
Deal with it. Hardware is also now auto load and auto unloading too.
Mo McKinlay wrote:
>
> I recently obtained an HP Omnibook XE2 laptop. It's a reasonably
> nicely-specced machine, although (unsuprsingly) the hardware isn't too
> well supported with Linux.
>
> I've given up on the internal modem (I'm 90% sure it's some kind of
> software modem, and I have an
Richard Henderson wrote:
>
> On Wed, Nov 01, 2000 at 09:46:19AM -0500, [EMAIL PROTECTED] wrote:
> > What versions of gcc produce the built-in functions?
>
> 2.95 and previous. In 2.96 somewhere we fixed a bug that
> automatically prototypes these builtin functions for you;
> ie with current
Richard Henderson wrote:
On Wed, Nov 01, 2000 at 09:46:19AM -0500, [EMAIL PROTECTED] wrote:
What versions of gcc produce the built-in functions?
2.95 and previous. In 2.96 somewhere we fixed a bug that
automatically prototypes these builtin functions for you;
ie with current code you
Mo McKinlay wrote:
I recently obtained an HP Omnibook XE2 laptop. It's a reasonably
nicely-specced machine, although (unsuprsingly) the hardware isn't too
well supported with Linux.
I've given up on the internal modem (I'm 90% sure it's some kind of
software modem, and I have an external
Horst von Brand wrote:
>
> Martin Dalecki <[EMAIL PROTECTED]> said:
> > Peter Samuelson wrote:
>
> [...]
>
> > > * Red Hat "2.96" or CVS 2.97 will probably break any known kernel.
>
> > Works fine for me and 2.4.0-test10-pre5... howe
Horst von Brand wrote:
Martin Dalecki [EMAIL PROTECTED] said:
Peter Samuelson wrote:
[...]
* Red Hat "2.96" or CVS 2.97 will probably break any known kernel.
Works fine for me and 2.4.0-test10-pre5... however there are tons of
preprocessor warnings in some drivers.
Linus Torvalds wrote:
>
> On Wed, 25 Oct 2000, Rik van Riel wrote:
> >
> > OTOH, block-dev readahead makes sense for filesystems where
> > the packing locality is close to the access pattern BUT NOT
> > close to anything the page cache would recognise as being
> > close.
>
> I dunno. The main
Jakub Jelinek wrote:
>
> On Mon, Oct 30, 2000 at 03:01:16PM +0100, Martin Dalecki wrote:
> > Horst von Brand wrote:
> > >
> > > Red Hat 7.0, i686, gcc-20001027 (Yes, I know. Just to flush out bugs on
> > > both sides).
> > >
> > > abs()
Horst von Brand wrote:
>
> Red Hat 7.0, i686, gcc-20001027 (Yes, I know. Just to flush out bugs on
> both sides).
>
> abs() is used at least in:
>
> arch/i386/kernel/time.c
> drivers/md/raid1.c
> drivers/sound/sb_ess.c
>
> gcc warns about use of a non-declared function each time.
>
> No
Peter Samuelson wrote:
>
> > So which is the recommended compiler for each kernel version 2.2.x,
> > 2.4.x(pre?) nowadays?
>
> * 2.91.66 aka egcs 1.1.2. It has been officially blessed for 2.4 and
> has been given an informal thumbs-up by Alan for 2.2. (It does NOT
> work for 2.0, if you
Peter Samuelson wrote:
So which is the recommended compiler for each kernel version 2.2.x,
2.4.x(pre?) nowadays?
* 2.91.66 aka egcs 1.1.2. It has been officially blessed for 2.4 and
has been given an informal thumbs-up by Alan for 2.2. (It does NOT
work for 2.0, if you still care
Horst von Brand wrote:
Red Hat 7.0, i686, gcc-20001027 (Yes, I know. Just to flush out bugs on
both sides).
abs() is used at least in:
arch/i386/kernel/time.c
drivers/md/raid1.c
drivers/sound/sb_ess.c
gcc warns about use of a non-declared function each time.
No definition for
Jakub Jelinek wrote:
On Mon, Oct 30, 2000 at 03:01:16PM +0100, Martin Dalecki wrote:
Horst von Brand wrote:
Red Hat 7.0, i686, gcc-20001027 (Yes, I know. Just to flush out bugs on
both sides).
abs() is used at least in:
arch/i386/kernel/time.c
drivers/md/raid1.c
Linus Torvalds wrote:
On Wed, 25 Oct 2000, Rik van Riel wrote:
OTOH, block-dev readahead makes sense for filesystems where
the packing locality is close to the access pattern BUT NOT
close to anything the page cache would recognise as being
close.
I dunno. The main reason I'd like
Jeff Garzik wrote:
>
> > Please have a look at the following patch and feel free to be scared
> > by the fact how UTTERLY BROKEN and ARBITRARY the current usage of the
> > read_ahead[] array and during the whole past decade was!
> > If you really care about clean internal interfaces this should
Rik van Riel wrote:
>
> On Tue, 24 Oct 2000, Martin Dalecki wrote:
>
> > The most amanzing thing is that the whole test10-pre5 kernel
> > with this patch applied doesn't show any performance penalties
> > for me at all! And of corse it's about 10k smaller...
>
Rik van Riel wrote:
On Tue, 24 Oct 2000, Martin Dalecki wrote:
The most amanzing thing is that the whole test10-pre5 kernel
with this patch applied doesn't show any performance penalties
for me at all! And of corse it's about 10k smaller...
Ideally we should (IMHO) get rid of all
Jeff Garzik wrote:
Please have a look at the following patch and feel free to be scared
by the fact how UTTERLY BROKEN and ARBITRARY the current usage of the
read_ahead[] array and during the whole past decade was!
If you really care about clean internal interfaces this should be
one
Igmar Palsenberg wrote:
>
> > I wouldn't mind, either, if this didn't mean that programs compiled
> > on rehdat need redhat versions of the development toolchain / runtime
> > environment to use them :(
Ever tried to recompile SuSE apache from the src.rpm they provide?
I wish you good louck
Richard Henderson wrote:
> Frankly, I didn't even consider C++ ABI compatibility with other
> Linux vendors, since I think that's a losing proposition until
> everyone is using gcc3. We were _already_ incompatible, since
> there are a mix of egcs and gcc versions involved.
C++ ABI breaking:
Marc Lehmann wrote:
> If you disagree personally or technically with me you either say this
> in public or private or keep quiet. Attacking me over totally unrelated
> things is obviously some maneuver to distract people from the real,
> kernel-related question, and I have no idea why you are
Alan Cox wrote:
>
> > > They released a supported ex-Cygnus people approved compiler.
> >
> > Which still makes it an broken, experimental, unreleased and unofficial
> > compiler, with all the consequences I said.
>
> And didnt you write something called pgcc once.
And then there isn't
Marc Lehmann wrote:
>
> On Sat, Sep 30, 2000 at 03:07:49PM +0100, Alan Cox <[EMAIL PROTECTED]> wrote:
> > > If you don't like this, I suggest you send mail complaining to RedHat.
> > > Customer complaints are going to be the only way that RH is going to be
> > > influenced not to play games like
Marc Lehmann wrote:
On Sat, Sep 30, 2000 at 03:07:49PM +0100, Alan Cox [EMAIL PROTECTED] wrote:
If you don't like this, I suggest you send mail complaining to RedHat.
Customer complaints are going to be the only way that RH is going to be
influenced not to play games like this
Alan Cox wrote:
They released a supported ex-Cygnus people approved compiler.
Which still makes it an broken, experimental, unreleased and unofficial
compiler, with all the consequences I said.
And didnt you write something called pgcc once.
And then there isn't anything I could
Marc Lehmann wrote:
If you disagree personally or technically with me you either say this
in public or private or keep quiet. Attacking me over totally unrelated
things is obviously some maneuver to distract people from the real,
kernel-related question, and I have no idea why you are doing
Richard Henderson wrote:
Frankly, I didn't even consider C++ ABI compatibility with other
Linux vendors, since I think that's a losing proposition until
everyone is using gcc3. We were _already_ incompatible, since
there are a mix of egcs and gcc versions involved.
C++ ABI breaking: SuSE
Ragnar Hojland Espinosa wrote:
>
> On Thu, Sep 28, 2000 at 01:45:40AM +0200, Igmar Palsenberg wrote:
> > Some arguments why not to use it in the kernel :
> >
> > - C++ gives overhead. With something like a kernel that's unwanted.
>
> You pay for what you use, no less no more. C++ compilers
Ragnar Hojland Espinosa wrote:
On Thu, Sep 28, 2000 at 01:45:40AM +0200, Igmar Palsenberg wrote:
Some arguments why not to use it in the kernel :
- C++ gives overhead. With something like a kernel that's unwanted.
You pay for what you use, no less no more. C++ compilers don't
Andrea Arcangeli wrote:
>
> On Wed, Sep 20, 2000 at 01:22:50AM +0200, Andi Kleen wrote:
> > Better would be to use statement blocks like
> > #define bla(x) ({ __u32 tmp__ = (x); ; tmp__; })
>
> Agreed.
Not agreed. In this case older version of GCC will have
almost exactly the same provlems
Andi Kleen wrote:
>
> On Tue, Sep 19, 2000 at 07:13:31PM -0400, Alexander Viro wrote:
> > Nice spotting, but bad fix, IMO. swab...() stuff is a perfect example of
> > the dangerous use of macros. BTW, 2.4 has the same problem.
>
> inlines usually generate worse code than macros (the gcc manual
Andrea Arcangeli wrote:
On Wed, Sep 20, 2000 at 01:22:50AM +0200, Andi Kleen wrote:
Better would be to use statement blocks like
#define bla(x) ({ __u32 tmp__ = (x); ; tmp__; })
Agreed.
Not agreed. In this case older version of GCC will have
almost exactly the same provlems as with
101 - 200 of 239 matches
Mail list logo
