I ahve a PC box at hand, which ist containing 8 PCI slots.
Four of them are sitting behind a PCI bridge.
The error in the new kernel series is that during the
PCI bus setup if a card is sitting behind the bridge, it
will be miracelously detected TWICE. Once in front of the
bridge and once behind
I ahve a PC box at hand, which ist containing 8 PCI slots.
Four of them are sitting behind a PCI bridge.
The error in the new kernel series is that during the
PCI bus setup if a card is sitting behind the bridge, it
will be miracelously detected TWICE. Once in front of the
bridge and once behind
William Park wrote:
>
> On Mon, Jun 25, 2001 at 08:51:28PM +0200, Martin Dalecki wrote:
> > Just a note...
> >
> > This card get's detected twofold by the plain 2.4.5 kernel.
> > It get's listed twice under both lspci and during the kernel boot
> > sequence
Just a note...
This card get's detected twofold by the plain 2.4.5 kernel.
It get's listed twice under both lspci and during the kernel boot
sequence on a HP LHr3 system.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Just a note...
This card get's detected twofold by the plain 2.4.5 kernel.
It get's listed twice under both lspci and during the kernel boot
sequence on a HP LHr3 system.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
William Park wrote:
On Mon, Jun 25, 2001 at 08:51:28PM +0200, Martin Dalecki wrote:
Just a note...
This card get's detected twofold by the plain 2.4.5 kernel.
It get's listed twice under both lspci and during the kernel boot
sequence on a HP LHr3 system.
I get only one message, I
Mike Harrold wrote:
> So what? Crusoe isn't designed for use in supercomputers. It's designed
> for use in laptops where the user is running an email reader, a web
> browser, a word processor, and where the user couldn't give a cr*p about
> performance as long as it isn't noticeable (20% *isn't*
Rob Landley wrote:
> The same arguments were made 30 years ago about writing the OS in a high
> level language like C rather than in raw assembly. And back in the days of
> the sub-1-mhz CPU, that really meant something.
And then those days we are still writing lot's of ASM in kernels...
> I
Rob Landley wrote:
The same arguments were made 30 years ago about writing the OS in a high
level language like C rather than in raw assembly. And back in the days of
the sub-1-mhz CPU, that really meant something.
And then those days we are still writing lot's of ASM in kernels...
I
Mike Harrold wrote:
So what? Crusoe isn't designed for use in supercomputers. It's designed
for use in laptops where the user is running an email reader, a web
browser, a word processor, and where the user couldn't give a cr*p about
performance as long as it isn't noticeable (20% *isn't* for
Joel Becker wrote:
>
> On Wed, May 30, 2001 at 05:24:37PM -0700, Jonathan Lundell wrote:
> > FWIW (perhaps not much in this context), the POSIX way is sysconf(_SC_CLK_TCK)
> >
> > POSIX sysconf is pretty useful for this kind of thing (not just HZ, either).
>
> Well, how many hundred
> Standard is right.
> Believe me as someone who are living in Belarus ;-)
OK. I trust you.
>
> Official country name: Belarus
> Language/Nationality: Belarusian
>
> Standard has taken things right as we pronounce them.
>
> Please apply the
Joel Becker wrote:
On Wed, May 30, 2001 at 05:24:37PM -0700, Jonathan Lundell wrote:
FWIW (perhaps not much in this context), the POSIX way is sysconf(_SC_CLK_TCK)
POSIX sysconf is pretty useful for this kind of thing (not just HZ, either).
Well, how many hundred things on
Standard is right.
Believe me as someone who are living in Belarus ;-)
OK. I trust you.
Official country name: Belarus
Language/Nationality: Belarusian
Standard has taken things right as we pronounce them.
Please apply the patch.
P.
Linus Torvalds wrote:
>
> On Tue, 22 May 2001, Jeff Garzik wrote:
> >
> > IMHO it would be nice to (for 2.4) create wrappers for accessing the
> > block arrays, so that we can more easily dispose of the arrays when 2.5
> > rolls around...
>
> No.
>
> We do not create wrappers "so that we can
Linus Torvalds wrote:
On Tue, 22 May 2001, Jeff Garzik wrote:
IMHO it would be nice to (for 2.4) create wrappers for accessing the
block arrays, so that we can more easily dispose of the arrays when 2.5
rolls around...
No.
We do not create wrappers so that we can easily change
w/drivers/char/raw.c Mon Apr 30 22:57:20 2001
@@ -124,22 +124,25 @@
return err;
}
-
- /*
-* Don't interfere with mounted devices: we cannot safely set
- * the blocksize on a device which is already mounted.
+ /*
+* 29.04.2001 Martin Dalecki:
+*
+
And if we are at the topic... Those are the places where blk_size[]
get's
abused, since it's in fact a property of a FS in fact and not the
property of
a particular device... blksect_size is the array describing the physical
access limits of a device and blk_size get's usually checked against it.
[EMAIL PROTECTED] wrote:
>
> Martin Dalecki writes:
>
> > Erm... I wasn't talking about the DESIRED state of affairs!
> > I was talking about the CURRENT state of affairs. OK?
>
> Oh, but in 1995 it was quite possible to compile the kernel
> with kdev_t a
[EMAIL PROTECTED] wrote:
>
> Martin Dalecki writes:
>
> > I fully agree with you.
>
> Good.
>
> Unfortunately I do not fully agree with you.
>
> > Most of the places where there kernel is passing kdev_t
> > would be entierly satisfied with only the k
[EMAIL PROTECTED] wrote:
>
> > They are entirely different. Too different sets of operations.
>
> Maybe you didnt understand what I meant.
> both bdev and cdev take care of the correspondence
> device number <---> struct with operations.
>
> The operations are different, but all bdev/cdev code
[EMAIL PROTECTED] wrote:
They are entirely different. Too different sets of operations.
Maybe you didnt understand what I meant.
both bdev and cdev take care of the correspondence
device number --- struct with operations.
The operations are different, but all bdev/cdev code is
[EMAIL PROTECTED] wrote:
Martin Dalecki writes:
I fully agree with you.
Good.
Unfortunately I do not fully agree with you.
Most of the places where there kernel is passing kdev_t
would be entierly satisfied with only the knowlendge of
the minor number.
My kdev_t
[EMAIL PROTECTED] wrote:
Martin Dalecki writes:
Erm... I wasn't talking about the DESIRED state of affairs!
I was talking about the CURRENT state of affairs. OK?
Oh, but in 1995 it was quite possible to compile the kernel
with kdev_t a pointer type, and I have done it several times
And if we are at the topic... Those are the places where blk_size[]
get's
abused, since it's in fact a property of a FS in fact and not the
property of
a particular device... blksect_size is the array describing the physical
access limits of a device and blk_size get's usually checked against it.
with mounted devices: we cannot safely set
-* the blocksize on a device which is already mounted.
+ /*
+* 29.04.2001 Martin Dalecki:
+*
+* The original comment here was saying:
+*
+* Don't interfere with mounted devices: we cannot safely set
Andrzej Krzysztofowicz wrote:
>
> Hi,
> The following patch cleans up a bit usage of parameters related to
> number of minors per disk in the SCSI subsystem. This is a preliminary
> patch and it seems to not contain any problematic changes. The full version
> of the patch (that allows to
Linus Torvalds wrote:
> and then use
>
> fd = open("/dev/fd0/colourspace", O_RDWR);
> This, btw, is Al Viro's wet dream. But I have to agree: using name spaces
> etc is MUCH preferable to ioctl's, makes code more readable and logical,
> and often makes it possible to do things you
Linus Torvalds wrote:
>
> On Mon, 14 May 2001, Alan Cox wrote:
> >
> > Except that Linus wont hand out major numbers, which means I can't even boot
> > simply off such a device. I bet the vendors in question dont think the sun
> > shines out of linus backside any more.
>
> Actually, it does.
Linus Torvalds wrote:
On Mon, 14 May 2001, Alan Cox wrote:
Except that Linus wont hand out major numbers, which means I can't even boot
simply off such a device. I bet the vendors in question dont think the sun
shines out of linus backside any more.
Actually, it does. It's just that
Linus Torvalds wrote:
and then use
fd = open(/dev/fd0/colourspace, O_RDWR);
This, btw, is Al Viro's wet dream. But I have to agree: using name spaces
etc is MUCH preferable to ioctl's, makes code more readable and logical,
and often makes it possible to do things you couldn't
Andrzej Krzysztofowicz wrote:
Hi,
The following patch cleans up a bit usage of parameters related to
number of minors per disk in the SCSI subsystem. This is a preliminary
patch and it seems to not contain any problematic changes. The full version
of the patch (that allows to succesfully
> - Political fixes:
> o There were still some penguins left carrying a glass of beer or wine.
> This problem is about 2 years old!
Could You please for the sake of political correctness just replace
the beer with a glass of vodka please... It tastes better anyway!
-
To
- Political fixes:
o There were still some penguins left carrying a glass of beer or wine.
This problem is about 2 years old!
Could You please for the sake of political correctness just replace
the beer with a glass of vodka please... It tastes better anyway!
-
To unsubscribe
Andrea Arcangeli wrote:
>
> On Wed, May 09, 2001 at 11:13:33AM +0200, Martin Dalecki wrote:
> > > (buffered and direct) to work with a 4096 bytes granularity instead of
> >
> > You mean PAGE_SIZE :-).
>
> In my first patch it is really 4096 bytes, b
Andrea Arcangeli wrote:
> (btw, also the current rawio uses a 512byte bh->b_size granularity that is even
> worse than the 1024byte b_size of the blkdev, O_DIRECT is much smarter
> on this side as it uses the softblocksize of the fs that can be as well
> 4k if you created the fs with -b 4096)
Rusty Russell wrote:
>
> In message <[EMAIL PROTECTED]> you write:
> >
> > Jonathan Morton writes:
> > > >- page_count(page) == (1 + !!page->buffers));
> > >
> > > Two inversions in a row?
> >
> > It is the most straightforward way to make a '1' or '0'
> > integer from the
Rusty Russell wrote:
In message [EMAIL PROTECTED] you write:
Jonathan Morton writes:
- page_count(page) == (1 + !!page-buffers));
Two inversions in a row?
It is the most straightforward way to make a '1' or '0'
integer from the NULL state of a pointer.
Andrea Arcangeli wrote:
(btw, also the current rawio uses a 512byte bh-b_size granularity that is even
worse than the 1024byte b_size of the blkdev, O_DIRECT is much smarter
on this side as it uses the softblocksize of the fs that can be as well
4k if you created the fs with -b 4096)
Amen
Andrea Arcangeli wrote:
On Wed, May 09, 2001 at 11:13:33AM +0200, Martin Dalecki wrote:
(buffered and direct) to work with a 4096 bytes granularity instead of
You mean PAGE_SIZE :-).
In my first patch it is really 4096 bytes, but yes I agree we should
change
"H. Peter Anvin" wrote:
>
> Hi guys,
>
> I was looking over the iso9660 code, and noticed that it was doing
> endianness conversion via ad hoc *functions*, not even inlines; nor did
> it take any advantage of the fact that iso9660 is bi-endian (has "all"
> data in both bigendian and
H. Peter Anvin wrote:
Hi guys,
I was looking over the iso9660 code, and noticed that it was doing
endianness conversion via ad hoc *functions*, not even inlines; nor did
it take any advantage of the fact that iso9660 is bi-endian (has all
data in both bigendian and littleendian format.)
Don't interfere with mounted devices: we cannot safely set
-* the blocksize on a device which is already mounted.
+ /*
+* 29.04.2001 Martin Dalecki:
+*
+* The original comment here was saying:
+*
+* "Don't interfere with mounted de
is already mounted.
+ /*
+* 29.04.2001 Martin Dalecki:
+*
+* The original comment here was saying:
+*
+* Don't interfere with mounted devices: we cannot safely set the
+* blocksize on a device which is already mounted.
+*
+* However
Alexander Viro wrote:
>
> On Sat, 28 Apr 2001, Martin Dalecki wrote:
>
> > I think in the context you are inventig the proposed function,
> > the drivers has allways an inode at hand. And contrary to what Linus
>
> Read the patch. Almost all cases are of the &
Alexander Viro wrote:
On Sat, 28 Apr 2001, Martin Dalecki wrote:
I think in the context you are inventig the proposed function,
the drivers has allways an inode at hand. And contrary to what Linus
Read the patch. Almost all cases are of the loop over partitions of foo
kind.
says
Alexander Viro wrote:
>
> On Fri, 27 Apr 2001, Alexander Viro wrote:
>
> > Fine with me. Actually in _all_ cases execept cdrom.c it's preceded by
> > either sync_dev() or fsync_dev(). What do you think about pulling that
> > into the same function? Actually, that's what I've done in namespace
>
Alexander Viro wrote:
On Fri, 27 Apr 2001, Alexander Viro wrote:
Fine with me. Actually in _all_ cases execept cdrom.c it's preceded by
either sync_dev() or fsync_dev(). What do you think about pulling that
into the same function? Actually, that's what I've done in namespace
patch
Linus Torvalds wrote:
> Dump was a stupid program in the first place. Leave it behind.
Not quite Linus - dump/restore are nice tools to create for example
automatic over network installation servers, i.e. efficient system
images
or such. tar/cpio and friends don't deal properly with
a. holes
[EMAIL PROTECTED] wrote:
>
> From: Martin Dalecki <[EMAIL PROTECTED]>
>
> The attached patch is fixing georgeous "backward compatibility"
> in the mount system command. It is removing two useless defines in
> the kernel headers and fina
[EMAIL PROTECTED] wrote:
From: Martin Dalecki [EMAIL PROTECTED]
The attached patch is fixing georgeous backward compatibility
in the mount system command. It is removing two useless defines in
the kernel headers and finally doubles the number of possible
flags
Linus Torvalds wrote:
Dump was a stupid program in the first place. Leave it behind.
Not quite Linus - dump/restore are nice tools to create for example
automatic over network installation servers, i.e. efficient system
images
or such. tar/cpio and friends don't deal properly with
a. holes
Ingo Oeser wrote:
>
> On Thu, Apr 26, 2001 at 10:58:46AM +0200, Martin Dalecki wrote:
> > 1. Help making the module interface cleaner by a tinny margin :-).
>
> You only help changing the API during a stable[1] series. Wait until 2.5
> for this.
>
> API cannot change
Hello!
The following patch is making the get_empty_super() function
just local to the place where it's only use is and where it's only
use should be: fs/super.c
The removal of this symbol from ksyms.c should:
1. Help making the module interface cleaner by a tinny margin :-).
2. shouldn't hurt
The attached patch is fixing georgeous "backward compatibility"
in the mount system command. It is removing two useless defines in
the kernel headers and finally doubles the number of possible
flags for the mount command.
Please apply.
If there are any line count difference warnings when
The attached patch is fixing georgeous backward compatibility
in the mount system command. It is removing two useless defines in
the kernel headers and finally doubles the number of possible
flags for the mount command.
Please apply.
If there are any line count difference warnings when applying
Hello!
The following patch is making the get_empty_super() function
just local to the place where it's only use is and where it's only
use should be: fs/super.c
The removal of this symbol from ksyms.c should:
1. Help making the module interface cleaner by a tinny margin :-).
2. shouldn't hurt
Ingo Oeser wrote:
On Thu, Apr 26, 2001 at 10:58:46AM +0200, Martin Dalecki wrote:
1. Help making the module interface cleaner by a tinny margin :-).
You only help changing the API during a stable[1] series. Wait until 2.5
for this.
API cannot change during stable series. (ABI can, BTW
Tim Jansen wrote:
>
> On Tuesday 24 April 2001 11:40, Martin Dalecki wrote:
> > Tim Jansen wrote:
> > > The Linux Device Registry (devreg) is a kernel patch that adds a device
> > > database in XML format to the /proc filesystem. It collects all
> > OH SHIT!!
Tim Jansen wrote:
>
> The Linux Device Registry (devreg) is a kernel patch that adds a device
> database in XML format to the /proc filesystem. It collects all information
OH SHIT!! ^^^
Why don't you just add postscript output to /proc?
> about the system's physical devices, creates
Tim Jansen wrote:
The Linux Device Registry (devreg) is a kernel patch that adds a device
database in XML format to the /proc filesystem. It collects all information
OH SHIT!! ^^^
IRONY
Why don't you just add postscript output to /proc?
/IRONY
about the system's physical devices,
Tim Jansen wrote:
On Tuesday 24 April 2001 11:40, Martin Dalecki wrote:
Tim Jansen wrote:
The Linux Device Registry (devreg) is a kernel patch that adds a device
database in XML format to the /proc filesystem. It collects all
OH SHIT!! ^^^
Why don't you just add postscript
"Dupuis, Don" wrote:
>
> I have already sent a patch to Alan and Linus on this issue. Linus has
> never responed and Alan said he would look into it in the middle of April.
> Nothing is new at this point
>
> -Original Message-
> From: PhiloVivero [mailto:[EMAIL PROTECTED]]
> Sent:
Jeff Chua wrote:
>
> On Mon, 23 Apr 2001, Martin Dalecki wrote:
>
> > > > depmod: *** Unresolved symbols in
>/lib/modules/2.4.3-ac11/kernel/drivers/md/lvm-mod.o
>
> try this (after you have applied the patch for lvm 0.9.1_beta7) ...
>
> Jeff
> [[E
Jens Axboe wrote:
>
> On Sat, Apr 21 2001, Ed Tomlinson wrote:
> > Hi,
> >
> > building a kernel with 2.4.3-ac11 and lvm beta7 + vfs_locking_patch-2.4.2 yields:
> >
> > oscar# depmod -ae 2.4.3-ac11
> > depmod: *** Unresolved symbols in
>/lib/modules/2.4.3-ac11/kernel/drivers/md/lvm-mod.o
> >
Jens Axboe wrote:
On Sat, Apr 21 2001, Ed Tomlinson wrote:
Hi,
building a kernel with 2.4.3-ac11 and lvm beta7 + vfs_locking_patch-2.4.2 yields:
oscar# depmod -ae 2.4.3-ac11
depmod: *** Unresolved symbols in
/lib/modules/2.4.3-ac11/kernel/drivers/md/lvm-mod.o
depmod:
Jeff Chua wrote:
On Mon, 23 Apr 2001, Martin Dalecki wrote:
depmod: *** Unresolved symbols in
/lib/modules/2.4.3-ac11/kernel/drivers/md/lvm-mod.o
try this (after you have applied the patch for lvm 0.9.1_beta7) ...
Jeff
[[EMAIL PROTECTED]]
--- /u2/src/linux/drivers/md/lvm.c.org
Dupuis, Don wrote:
I have already sent a patch to Alan and Linus on this issue. Linus has
never responed and Alan said he would look into it in the middle of April.
Nothing is new at this point
-Original Message-
From: PhiloVivero [mailto:[EMAIL PROTECTED]]
Sent: Sunday, April
Hello!
The attached patch remove the get_hardblock_size() function entierly
from the kernel. This is due to the fact that this function is
compleatly
unneccessary due to the existance of get_hardsect_size(), which got
introduced to properly encapsulate acesses to the hardsec_size[].
As a side
Hello!
The attached patch remove the get_hardblock_size() function entierly
from the kernel. This is due to the fact that this function is
compleatly
unneccessary due to the existance of get_hardsect_size(), which got
introduced to properly encapsulate acesses to the hardsec_size[].
As a side
> One thing I certainly miss: DevFS is not mandatory (yet).
That's "only" due to the fact that DevFS is an insanely racy and
instable
piece of CRAP. I'm unhappy it's there anyway...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Alan Cox wrote:
>
> > If anything I'm a *SERIOUS* production user. And I wouldn't allow
> > *ANYBODY* here to run am explicitly tagged as developement kernel
> > here anyway in an production enviornment. That's what releases are for
> > damn.
> > Or do you think that Linux should still preserve
Alan Cox wrote:
>
> > So change them as well for a new distribution. What's there problem.
> > There isn't anything out there you can't do by hand.
> > Fortunately so!
>
> So users cannot go back and forward between new and old kernels. Very good.
> Try explaining that to serious production
[EMAIL PROTECTED] wrote:
>
> OK - everybody back from San Jose - pity I couldnt come -
> and it is no longer April 1st, so we can continue quarreling
> a little.
>
> Interesting that where I had divided stuff in the trivial part,
> the interesting part and the lot-of-work part we already start
Alan Cox wrote:
So change them as well for a new distribution. What's there problem.
There isn't anything out there you can't do by hand.
Fortunately so!
So users cannot go back and forward between new and old kernels. Very good.
Try explaining that to serious production -users- of a
Alan Cox wrote:
If anything I'm a *SERIOUS* production user. And I wouldn't allow
*ANYBODY* here to run am explicitly tagged as developement kernel
here anyway in an production enviornment. That's what releases are for
damn.
Or do you think that Linux should still preserve DOS
One thing I certainly miss: DevFS is not mandatory (yet).
That's "only" due to the fact that DevFS is an insanely racy and
instable
piece of CRAP. I'm unhappy it's there anyway...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Alan Cox wrote:
>
> > Why do you worry about installers? New distro - new kernel - new
> > installer
>
> Because the same code tends to be shared with post install configuration
> tools too.
So change them as well for a new distribution. What's there problem.
There isn't anything out there you
Alan Cox wrote:
Why do you worry about installers? New distro - new kernel - new
installer
Because the same code tends to be shared with post install configuration
tools too.
So change them as well for a new distribution. What's there problem.
There isn't anything out there you can't
Alan Cox wrote:
>
> > Exactly. It's just that for historical reasons, I think the major for
> > "disk" should be either the old IDE or SCSI one, which just can show more
> > devices. That way old installers etc work without having to suddenly start
> > knowing about /dev/disk0.
>
> They will
> what do other vaguely unix-like systems do? does, say, plan9 have a
> better way of dealing with all this?
Yes.
Normal UNIX has as well. For reffernece see: block ver raw
devices on docs.sun.com :-).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Alan Cox wrote:
>
> > high-end-disks. Rather the reverse. I'm advocating the SCSI layer not
> > hogging a major number, but letting low-level drivers get at _their_
> > requests directly.
>
> A major for 'disk' generically makes total sense. Classing raid controllers
> as 'scsi' isnt
Linus Torvalds wrote:
>
> On Tue, 27 Mar 2001, Andre Hedrick wrote:
> >
> > Am I hearing you state you want dynamic device points and dynamic majors?
>
> Yes and no.
>
> We need static structures for user space - from a user perspective it
> makes a ton more sense to say "I want to see all
"H. Peter Anvin" wrote:
>
> Alan Cox wrote:
> >
> > > Another example: all the stupid pseudo-SCSI drivers that got their own
> > > major numbers, and wanted their very own names in /dev. They are BAD for
> > > the user. Install-scripts etc used to be able to just test /dev/hd[a-d]
> > > and
"H. Peter Anvin" wrote:
>
> This is my opinion on the issue. Short summary: "I'm sick of the
> administrative burden associated with keeping dev_t dense."
>
> Linus Torvalds wrote:
> >
> > And let's take a look at /dev. Do a "ls -l /dev" and think about it. Every
> > device needs a unique
"H. Peter Anvin" wrote:
This is my opinion on the issue. Short summary: "I'm sick of the
administrative burden associated with keeping dev_t dense."
Linus Torvalds wrote:
And let's take a look at /dev. Do a "ls -l /dev" and think about it. Every
device needs a unique number. Do you
"H. Peter Anvin" wrote:
Alan Cox wrote:
Another example: all the stupid pseudo-SCSI drivers that got their own
major numbers, and wanted their very own names in /dev. They are BAD for
the user. Install-scripts etc used to be able to just test /dev/hd[a-d]
and /dev/sd[0-x] and
Alan Cox wrote:
high-end-disks. Rather the reverse. I'm advocating the SCSI layer not
hogging a major number, but letting low-level drivers get at _their_
requests directly.
A major for 'disk' generically makes total sense. Classing raid controllers
as 'scsi' isnt neccessarily
Linus Torvalds wrote:
On Tue, 27 Mar 2001, Andre Hedrick wrote:
Am I hearing you state you want dynamic device points and dynamic majors?
Yes and no.
We need static structures for user space - from a user perspective it
makes a ton more sense to say "I want to see all disks" than it
what do other vaguely unix-like systems do? does, say, plan9 have a
better way of dealing with all this?
Yes.
Normal UNIX has as well. For reffernece see: block ver raw
devices on docs.sun.com :-).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Alan Cox wrote:
Exactly. It's just that for historical reasons, I think the major for
"disk" should be either the old IDE or SCSI one, which just can show more
devices. That way old installers etc work without having to suddenly start
knowing about /dev/disk0.
They will mostly break.
Ingo Oeser wrote:
>
> On Tue, Mar 27, 2001 at 03:24:16PM +0200, Martin Dalecki wrote:
> > > @@ -93,6 +95,10 @@
> > > p->uid == 0 || p->euid == 0)
> > > points /= 4;
> > >
> > >
Michel Wilson wrote:
>
> > relative ages. The major flaw in my code is that a sufficiently
> > long-lived
> > process becomes virtually immortal, even if it happens to spring a serious
> > leak after this time - the flaw in yours is that system processes
>
> I think this could easily be fixed
Jonathan Morton wrote:
>
> Oh and BTW, I think Bit/sqr(seconds) is a perfectly acceptable unit for
> "badness". Think about it - it increases with pigginess and decreases with
> longevity. I really don't see a problem with it per se.
Right it's not a problem pre se, but as you already
Jonathan Morton wrote:
>
> >Out of Memory: Killed process 117 (sendmail).
> >
> >What we did to run it out of memory, I don't know. But I do know that
> >it shouldn't be killing one process more than once... (the process
> >should not exist after one try...)
>
> This is a known bug in the
Jonathan Morton wrote:
Out of Memory: Killed process 117 (sendmail).
What we did to run it out of memory, I don't know. But I do know that
it shouldn't be killing one process more than once... (the process
should not exist after one try...)
This is a known bug in the Out-of-Memory
Jonathan Morton wrote:
Oh and BTW, I think Bit/sqr(seconds) is a perfectly acceptable unit for
"badness". Think about it - it increases with pigginess and decreases with
longevity. I really don't see a problem with it per se.
Right it's not a problem pre se, but as you already explained
Ingo Oeser wrote:
On Tue, Mar 27, 2001 at 03:24:16PM +0200, Martin Dalecki wrote:
@@ -93,6 +95,10 @@
p-uid == 0 || p-euid == 0)
points /= 4;
+ /* Much the same goes for processes with low UIDs */
+ if(p-uid 100 || p
"Eric W. Biederman" wrote:
>
> Matthew Wilcox <[EMAIL PROTECTED]> writes:
>
> > On Mon, Mar 26, 2001 at 10:47:13AM -0700, Andreas Dilger wrote:
> > > What do you mean by problems 5 years down the road? The real issue is that
> > > this 32-bit block count limit affects composite devices like MD
"Eric W. Biederman" wrote:
Matthew Wilcox [EMAIL PROTECTED] writes:
On Mon, Mar 26, 2001 at 10:47:13AM -0700, Andreas Dilger wrote:
What do you mean by problems 5 years down the road? The real issue is that
this 32-bit block count limit affects composite devices like MD RAID and
1 - 100 of 239 matches
Mail list logo
