Add this:
append="mem=1024M"
to your lilo boot profiles.
... 2.4 correctly detects memory size more often than 2.2.16 ...
- Original Message -
From: "Edouard Soriano" <[EMAIL PROTECTED]>
Subject: 1GB system working with 64MB
> Hello Folks,
> Environment: linux 2.2.16smp
> RedHat
Add this:
append=mem=1024M
to your lilo boot profiles.
... 2.4 correctly detects memory size more often than 2.2.16 ...
- Original Message -
From: Edouard Soriano [EMAIL PROTECTED]
Subject: 1GB system working with 64MB
Hello Folks,
Environment: linux 2.2.16smp
RedHat 7.0
My
uot; 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/
--
Michael Rothwell
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
>
> Send all your spam to [EMAIL PROTECTED] (spam digging piggy)
>
> -
> 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
> Plea
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/
--
Michael Rothwell
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
the FAQ at http://www.tux.org/lkml/
--
Michael Rothwell
[EMAIL PROTECTED]
-
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
On 20 Jun 2001 10:14:48 +0100, Alan Cox wrote:
> It does.
... not
> They are always readable.
That's not very useful. Not in the sense of supporting aync,
non-blocking i/o to disk files without using threads.
--
Michael Rothwell
[EMAIL PROTECTED]
-
To unsubscribe from this list
On 20 Jun 2001 10:14:48 +0100, Alan Cox wrote:
It does.
... not
They are always readable.
That's not very useful. Not in the sense of supporting aync,
non-blocking i/o to disk files without using threads.
--
Michael Rothwell
[EMAIL PROTECTED]
-
To unsubscribe from this list: send
On 19 Jun 2001 20:01:56 +0100, Alan Cox wrote:
> Linux inherits several unix properties which are not friendly to good state
> based programming - lack of good AIO for one.
Oh, how I would love for select() and poll() to work on files... or for
any other working AIO mothods to be present.
What
On 19 Jun 2001 20:01:56 +0100, Alan Cox wrote:
Linux inherits several unix properties which are not friendly to good state
based programming - lack of good AIO for one.
Oh, how I would love for select() and poll() to work on files... or for
any other working AIO mothods to be present.
What
; > Please read the FAQ at http://www.tux.org/lkml/
>
> --
> -------
> Russell Leighton[EMAIL PROTECTED]
> ---
>
>
> -
> To unsubscribe from this list: send the line "uns
vices will be a part of the
mainstream kernel...
--
Michael Rothwell
[EMAIL PROTECTED]
-
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/
doing both.
However, I wrote a REALLY SIMPLE hook tht supported exactly my needs,
since it's in the category of ugly hack waiting for input api. Maybe
I'll write a version for your hook.
I wonder when the input api stuff for ps/2 devices will be a part of the
mainstream kernel...
--
Michael
]
---
-
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/
--
Michael Rothwell
[EMAIL PROTECTED]
-
To unsubscribe from this list
Thanks, I'm loking through your driver now. Does the input api already/currently
support ps2 keyboards?
-M
On Sat, Jun 02, 2001 at 08:40:04PM -0700, James Simmons wrote:
>
> Hi!
>
>Your best bet for a kernel driver is to use the linux input api like
> the usb keyboard do. The drivers are
Input API looks nice. For now, I'll write a patch against pc_keyb.c to add a hook for
my qoder stuff, and a loadable module for the meat of the driver. Then I'll port up to
the input API. The Qoder is strictly ps/2 keyboard, as far as its interface goes, so I
cannot use the input API for now.
Input API looks nice. For now, I'll write a patch against pc_keyb.c to add a hook for
my qoder stuff, and a loadable module for the meat of the driver. Then I'll port up to
the input API. The Qoder is strictly ps/2 keyboard, as far as its interface goes, so I
cannot use the input API for now.
Thanks, I'm loking through your driver now. Does the input api already/currently
support ps2 keyboards?
-M
On Sat, Jun 02, 2001 at 08:40:04PM -0700, James Simmons wrote:
Hi!
Your best bet for a kernel driver is to use the linux input api like
the usb keyboard do. The drivers are
hat
data and make it available via /proc, or something.
Does anyone have any suggestions before I go ugly-up the keyboard
driver?
Thanks,
--
Michael Rothwell
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECT
.
Does anyone have any suggestions before I go ugly-up the keyboard
driver?
Thanks,
--
Michael Rothwell
[EMAIL PROTECTED]
-
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
Just your friendly neighborhood oops report. Unfortunately, the kernel didn't log very
much:
May 14 18:00:49 gateway kernel: scanner.c: read_scanner(0): funky result:-32. Please
notify the maintainer.
May 14 18:01:13 gateway PAM_pwdb[10338]: (login) session opened for user rothwell by
Just your friendly neighborhood oops report. Unfortunately, the kernel didn't log very
much:
May 14 18:00:49 gateway kernel: scanner.c: read_scanner(0): funky result:-32. Please
notify the maintainer.
May 14 18:01:13 gateway PAM_pwdb[10338]: (login) session opened for user rothwell by
There seems to be a contingent of people on the LKML who think that it
is appropriate to flame people off-list, in order to bask in their own
superiority, or prove that they are smarter by pointing out that someone
is an idiot, etc. I would figure that most intelligent people would
simply ignore
There seems to be a contingent of people on the LKML who think that it
is appropriate to flame people off-list, in order to bask in their own
superiority, or prove that they are smarter by pointing out that someone
is an idiot, etc. I would figure that most intelligent people would
simply ignore
According to tests performed at IBM:
http://www-106.ibm.com/developerworks/linux/library/l-rt1/
Linux's sycalls are a little more than twice as fast as those of Windows
2000. 0.75usec vs 2.0msec. Not too shabby. And this "magic page" idea
means it may get faster.
-M
-
To unsubscribe from this
According to tests performed at IBM:
http://www-106.ibm.com/developerworks/linux/library/l-rt1/
Linux's sycalls are a little more than twice as fast as those of Windows
2000. 0.75usec vs 2.0msec. Not too shabby. And this magic page idea
means it may get faster.
-M
-
To unsubscribe from this
To whom are you referring?
-M
On 30 Apr 2001 10:11:04 -0600, [EMAIL PROTECTED] wrote:
> Thank you for the =constructive= answer Mohammad. I have thusfar only received
>criticism for my question, with no further information, which I think is destructive
>to the spirit of the list, and to the
To whom are you referring?
-M
On 30 Apr 2001 10:11:04 -0600, [EMAIL PROTECTED] wrote:
Thank you for the =constructive= answer Mohammad. I have thusfar only received
criticism for my question, with no further information, which I think is destructive
to the spirit of the list, and to the
Great. I'm running 4.02. How do I enable "silken mouse"?
Thanks,
-Michael
On 29 Apr 2001 14:44:11 -0700, Jim Gettys wrote:
> The biggest single issue in GUI responsiveness on Linux has been caused
> by XFree86's implementation of mouse tracking in user space.
>
> On typical UNIX systems, the
Great. I'm running 4.02. How do I enable silken mouse?
Thanks,
-Michael
On 29 Apr 2001 14:44:11 -0700, Jim Gettys wrote:
The biggest single issue in GUI responsiveness on Linux has been caused
by XFree86's implementation of mouse tracking in user space.
On typical UNIX systems, the mouse
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
> "dcim" probably stands for "digital camera images". At least Canon
> digital cameras always put their data in a directory named dcim.
Makes sense. FAT's root directory is limited in the number of entries it can
contain, to something like 32. Cameras
Hmmm... this is the kernel list... not only the wrong place to ask UI
questions, but lots of people here don't even like UIs. :)
http://www.gnome.org
-M
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, April 28, 2001 2:13 PM
Subject: Common GUI
Hmmm... this is the kernel list... not only the wrong place to ask UI
questions, but lots of people here don't even like UIs. :)
http://www.gnome.org
-M
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, April 28, 2001 2:13 PM
Subject: Common GUI Config
From: H. Peter Anvin [EMAIL PROTECTED]
dcim probably stands for digital camera images. At least Canon
digital cameras always put their data in a directory named dcim.
Makes sense. FAT's root directory is limited in the number of entries it can
contain, to something like 32. Cameras can easily
Well, for kicks, I tried setting HZ to 1024 with 2.2.19. It seemed a
little more responsive, but that could be psychosomatic. :) I did notice
that I was unable to sync my palm pilot until I set it back to 100.
YMMV. The most useful "performace" tweak for a GUI that I've come across is:
Well, for kicks, I tried setting HZ to 1024 with 2.2.19. It seemed a
little more responsive, but that could be psychosomatic. :) I did notice
that I was unable to sync my palm pilot until I set it back to 100.
YMMV. The most useful performace tweak for a GUI that I've come across is:
#define
Are there any negative effects of editing include/asm/param.h to change
HZ from 100 to 1024? Or any other number? This has been suggested as a
way to improve the responsiveness of the GUI on a Linux system. Does it
throw off anything else, like serial port timing, etc.?
-
To unsubscribe from
I'm installing Linux onto a Compaq iPaq IA-1 -- the little "MSN
Companion" thing. I wish Compaq didn't feel compelled to name everything
"iPaq." This device is essentially a laptop with a strange case, no hard
drive, and 32MB of RAM. It has a VIA chipset and four USB ports. The
southbridge is a
I'm installing Linux onto a Compaq iPaq IA-1 -- the little "MSN
Companion" thing. I wish Compaq didn't feel compelled to name everything
"iPaq." This device is essentially a laptop with a strange case, no hard
drive, and 32MB of RAM. It has a VIA chipset and four USB ports. The
southbridge is a
Sweet! Thanks!
I'm working on 2.2 for now, but the 2.4 API looks nicer... :)
-M
On 08 Mar 2001 11:43:24 -0500, Alexander Viro wrote:
>
>
> On 8 Mar 2001, Michael Rothwell wrote:
>
> > Figured it out -- I think. This appears to be the answer:
> >
> >
)
{
MOD_DEC_USE_COUNT;
return;
};
if (v==1)
{
MOD_INC_USE_COUNT;
return;
};
};
... right? :)
On 08 Mar 2001 11:01:28 -0500, Michael Rothwell wrote:
> How can I detect that open() has been called on a file in procfs that a
> module provides? If I modprobe my module, open one or more
How can I detect that open() has been called on a file in procfs that a
module provides? If I modprobe my module, open one or more if its proc
entries, then rmmod the module while the proc files are still open, then
the deletion of those entries is deferred. When I close the file(s), the
kernel
How can I detect that open() has been called on a file in procfs that a
module provides? If I modprobe my module, open one or more if its proc
entries, then rmmod the module while the proc files are still open, then
the deletion of those entries is deferred. When I close the file(s), the
kernel
)
{
MOD_DEC_USE_COUNT;
return;
};
if (v==1)
{
MOD_INC_USE_COUNT;
return;
};
};
... right? :)
On 08 Mar 2001 11:01:28 -0500, Michael Rothwell wrote:
How can I detect that open() has been called on a file in procfs that a
module provides? If I modprobe my module, open one or more if its
Sweet! Thanks!
I'm working on 2.2 for now, but the 2.4 API looks nicer... :)
-M
On 08 Mar 2001 11:43:24 -0500, Alexander Viro wrote:
On 8 Mar 2001, Michael Rothwell wrote:
Figured it out -- I think. This appears to be the answer:
In struct proc_dir_entry,set the fill_inode
physmem= `head -10 /var/log/dmesg | grep Memory: | cut -d" " -f2 | cut
-d "/" -f1 | cut -d"k" -f1`
-
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
pyhsmem = `free | grep Mem | tr -s "/ / /" | cut -f2 -d" "`
On 03 Mar 2001 13:37:42 -0500, Denis Perchine wrote:
> Hello,
>
> actually the question is in subj.
> Problem is that there is a program which needs to know physical memory
> size. This information is used to justify memory
On 03 Mar 2001 12:54:36 +0100, Vojtech Pavlik wrote:
> No, they have a separate USB chip, but it has the same PCI ID as the
> builtin silicon in the southbridge.
Ah. I went and looked up that chip ID at via's website, and saw only
southbridge chips, no USB-only chips at all. But, my real
On 03 Mar 2001 12:54:36 +0100, Vojtech Pavlik wrote:
No, they have a separate USB chip, but it has the same PCI ID as the
builtin silicon in the southbridge.
Ah. I went and looked up that chip ID at via's website, and saw only
southbridge chips, no USB-only chips at all. But, my real question
physmem= `head -10 /var/log/dmesg | grep Memory: | cut -d" " -f2 | cut
-d "/" -f1 | cut -d"k" -f1`
-
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
I have a USB PCI card, which shows up as this in `lspci`:
00:09.0 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 04)
... it appears that they tossed the whole southbridge chip onto a pci
board, and disabled everything but USB. Anyway, this device seems to be
semi-functional under
I have a USB PCI card, which shows up as this in `lspci`:
00:09.0 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 04)
... it appears that they tossed the whole southbridge chip onto a pci
board, and disabled everything but USB. Anyway, this device seems to be
semi-functional under
> IBM withdrew the proposal.
... from public view
-
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/
IBM withdrew the proposal.
... from public view
-
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/
> Then HPA may ask: but why do you want to run the serial console at
> 115200?? The answer is simple: because we ...
... don't want to drag out debugging the kernel on a 38400 connection.
Because printks are our only debugging option ("thanks", Linus), and a slow
serial port block and can change
Thanks. Has Brad Hards made his version available somewhere?
-M
- Original Message -
From: "Eric Sandeen" <[EMAIL PROTECTED]>
To: "Michael Rothwell" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, February 04, 2001 9:30 AM
Subject: R
Thanks. Has Brad Hards made his version available somewhere?
-M
- Original Message -
From: "Eric Sandeen" [EMAIL PROTECTED]
To: "Michael Rothwell" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, February 04, 2001 9:30 AM
Subject: Re: "kaweth" usb ethe
On 03 Feb 2001 14:22:02 -0600, Eric Sandeen wrote:
> The driver is included with the USB stuff for 2.2, but not in 2.4.
That's because we stopped fooling with 2.4 around the middle of the
pre-test-ac series of releases. We'll probably pick it back up around
2.4.7 or so.
> It also doesn't
On 03 Feb 2001 14:22:02 -0600, Eric Sandeen wrote:
The driver is included with the USB stuff for 2.2, but not in 2.4.
That's because we stopped fooling with 2.4 around the middle of the
pre-test-ac series of releases. We'll probably pick it back up around
2.4.7 or so.
It also doesn't seem
Mo McKinlay wrote:
> I would too, but POSIX won't let us unless we start enforcing side-effect
> rules for all filesystems. Hence why I came up with openstream() :)
So, openstream() is probably the most painless way to get named streams
support into Linux in the immediate future. Openstream()
Mo McKinlay wrote:
I would too, but POSIX won't let us unless we start enforcing side-effect
rules for all filesystems. Hence why I came up with openstream() :)
So, openstream() is probably the most painless way to get named streams
support into Linux in the immediate future. Openstream() will
>From within a filesystem driver, how would I completely remove a page
cache mapping for an inode in 2.2.18?
-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
From within a filesystem driver, how would I completely remove a page
cache mapping for an inode in 2.2.18?
-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
ve, i.e., Win32) apps, there are limitations on what a filename can
contain.
-M
- Original Message -
From: "Albert D. Cahalan" <[EMAIL PROTECTED]>
To: "Michael Rothwell" <[EMAIL PROTECTED]>
Cc: "Mo McKinlay" <[EMAIL PROTECTED]>; "Peter Samuelson&
e., Win32) apps, there are limitations on what a filename can
contain.
-M
- Original Message -
From: "Albert D. Cahalan" [EMAIL PROTECTED]
To: "Michael Rothwell" [EMAIL PROTECTED]
Cc: "Mo McKinlay" [EMAIL PROTECTED]; "Peter Samuelson"
[EMAIL PROTECTED]; [EMA
What version of the raidtools to I need for 2.2.18 software raid?
Documentation/md.txt has a non-functional URL in it.
Thanks.
-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
Mo McKinlay wrote:
> Nono, that's not what I mean - each of the filesystems fails if it
> doesn't support what you're trying to do, that's given - but having a
> different delimeter registered by the filesystem (and hence the
> possibility of every single filesystem using a different delimeter)
Mo McKinlay wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Today, Michael Rothwell ([EMAIL PROTECTED]) wrote:
>
> > The filesystem, when registering that it supports the "named streams"
> > namespace, could specify its preferred
Mo McKinlay wrote:
> (Take symbolic linking, for example - if you ln -s on VFAT, you get
> 'operation not permitted' - named stream/EA operations on a filesystem
> that doesn't support them should return the same, IMHO).
And they would, if the chosen namespace was not supported.
> Also, I
Mo McKinlay wrote:
> openstream(file, stream, flags)
>
> Where 'file' should be an fd (although i'm sure the VFS gods will think of
> plenty of reasons why this is a bad idea, at which point I'll
> conventiently change my mind ;). Stream is simply the name of the stream,
> flags are as with
Mo McKinlay wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Today, Michael Rothwell ([EMAIL PROTECTED]) wrote:
>
> > Unfortunately, unix allows everything but "/" in filenames. This was
> > probably a mistake, as it makes it nearly i
Robert Kaiser wrote:
>
> On Thu Jan 18 16:30:30 2001 [EMAIL PROTECTED] wrote
> > Has anyone had any luck getting a 2.4 kernel to run on Cobalt x86
> > hardware? It doesn't even seem to start (I get nothing on the screen from
> >t he kernel, it just sits there and does nothing). :(
>
> What
Robert Kaiser wrote:
On Thu Jan 18 16:30:30 2001 [EMAIL PROTECTED] wrote
Has anyone had any luck getting a 2.4 kernel to run on Cobalt x86
hardware? It doesn't even seem to start (I get nothing on the screen from
t he kernel, it just sits there and does nothing). :(
What processor
Mo McKinlay wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Today, Michael Rothwell ([EMAIL PROTECTED]) wrote:
Unfortunately, unix allows everything but "/" in filenames. This was
probably a mistake, as it makes it nearly impossible to augment the
Mo McKinlay wrote:
openstream(file, stream, flags)
Where 'file' should be an fd (although i'm sure the VFS gods will think of
plenty of reasons why this is a bad idea, at which point I'll
conventiently change my mind ;). Stream is simply the name of the stream,
flags are as with open()
Mo McKinlay wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Today, Michael Rothwell ([EMAIL PROTECTED]) wrote:
The filesystem, when registering that it supports the "named streams"
namespace, could specify its preferred delimiter to the VFS as well.
Ext4
Mo McKinlay wrote:
Nono, that's not what I mean - each of the filesystems fails if it
doesn't support what you're trying to do, that's given - but having a
different delimeter registered by the filesystem (and hence the
possibility of every single filesystem using a different delimeter)
What version of the raidtools to I need for 2.2.18 software raid?
Documentation/md.txt has a non-functional URL in it.
Thanks.
-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
Unfortunately, unix allows everything but "/" in filenames. This was
probably a mistake, as it makes it nearly impossible to augment the
namespace, but it is the reality.
Did you read the "new namespace" section of the paper?
It also talked a bit about supporting Extended Attributes, which are
Unfortunately, unix allows everything but "/" in filenames. This was
probably a mistake, as it makes it nearly impossible to augment the
namespace, but it is the reality.
Did you read the "new namespace" section of the paper?
It also talked a bit about supporting Extended Attributes, which are
> What if you copy both 'filename' and 'filename:ext' onto the same fs?
> Do they get combined into one file?
ON Ext2, you get two files. On NTFS, you get one file, and a stream on that
file.
> Any semantics by which 'filename:stream' and 'filename' refer to the
> same file would be b0rken.
"James H. Cloos Jr." wrote:
>
> Michael> Please read and comment! :)
>
> There should be some discussion on what to do about filenames which
> contain colons in such a setup. Moving a file w/ a colon from a fs
> which does not support named streams to one which does should DTRT;
> exactly what
"James H. Cloos Jr." wrote:
Michael Please read and comment! :)
There should be some discussion on what to do about filenames which
contain colons in such a setup. Moving a file w/ a colon from a fs
which does not support named streams to one which does should DTRT;
exactly what TRT is
What if you copy both 'filename' and 'filename:ext' onto the same fs?
Do they get combined into one file?
ON Ext2, you get two files. On NTFS, you get one file, and a stream on that
file.
Any semantics by which 'filename:stream' and 'filename' refer to the
same file would be b0rken. If
Alan Cox wrote:
>
> > using the O_NONBLOCK flag, then read() and write() will always return
> > immediately and not block the calling process. This does not appear to
> > be true; but perhaps I am doing something wrong. If I open() a file (on
> > 2.2.18) from a floppy or NFS mount (to test in a
Alan Cox wrote:
using the O_NONBLOCK flag, then read() and write() will always return
immediately and not block the calling process. This does not appear to
be true; but perhaps I am doing something wrong. If I open() a file (on
2.2.18) from a floppy or NFS mount (to test in a slow
The man pages for open, read and write say that if a file is opened
using the O_NONBLOCK flag, then read() and write() will always return
immediately and not block the calling process. This does not appear to
be true; but perhaps I am doing something wrong. If I open() a file (on
2.2.18) from a
CORRECTION:
> existing, widely-deployed filesystems (e.g., NFS, XFS, BeFS, HFS, etc.),
NTFS---^
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
Now that 2.4 is out, it will probably be a few .x releases until 2.5
begins.
A discussion on Named Streams and Extended Attributes was put off until
2.5 earlier in the 2.4 development cycle. For compatibility with
existing, widely-deployed filesystems (e.g., NFS, XFS, BeFS, HFS, etc.),
Linux
Now that 2.4 is out, it will probably be a few .x releases until 2.5
begins.
A discussion on Named Streams and Extended Attributes was put off until
2.5 earlier in the 2.4 development cycle. For compatibility with
existing, widely-deployed filesystems (e.g., NFS, XFS, BeFS, HFS, etc.),
Linux
CORRECTION:
existing, widely-deployed filesystems (e.g., NFS, XFS, BeFS, HFS, etc.),
NTFS---^
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
The man pages for open, read and write say that if a file is opened
using the O_NONBLOCK flag, then read() and write() will always return
immediately and not block the calling process. This does not appear to
be true; but perhaps I am doing something wrong. If I open() a file (on
2.2.18) from a
> On Wed, 3 Jan 2001, Dr. David Gilbert wrote:
>
> > I got wondering as to whether the various journaling file
> > system activities were designed to survive the occasional
> > unclean shutdown or were designed to allow the user to just pull
> > the plug as a regular means of shutting down.
>
On Wed, 3 Jan 2001, Dr. David Gilbert wrote:
I got wondering as to whether the various journaling file
system activities were designed to survive the occasional
unclean shutdown or were designed to allow the user to just pull
the plug as a regular means of shutting down.
Ruth Ivimey-Cook wrote:
> No. Java on NT uses proper NT threads. However, a thread on NT is a rather
> different beast to a cloned thread on Linux. I don't know whether the
> differences are important.
On Linux, threads are processes. On NT, processes are distinct from
threads, and usually have
Ruth Ivimey-Cook wrote:
No. Java on NT uses proper NT threads. However, a thread on NT is a rather
different beast to a cloned thread on Linux. I don't know whether the
differences are important.
On Linux, threads are processes. On NT, processes are distinct from
threads, and usually have at
Felix von Leitner wrote:
>
> > IPChains is essentially useless as a firewall due to its lack of
> > stateful packet filering.
>
> Bullshit.
> Go back to the bowels or Redmond where you belong, luser.
Thanks. I appreciate that.
-M
-
To unsubscribe from this list: send the line "unsubscribe
Felix von Leitner wrote:
IPChains is essentially useless as a firewall due to its lack of
stateful packet filering.
Bullshit.
Go back to the bowels or Redmond where you belong, luser.
Thanks. I appreciate that.
-M
-
To unsubscribe from this list: send the line "unsubscribe
Alan Cox wrote:
> There have been at least five holes found in pile that _could_ have been
> [speech]
> safe is the day you end up hurt.
Your specific example of an executable (windows) attachment, not buffer
overflows, etc. what what I was replying to. In general, you are
correct. Now, how
Alan Cox wrote:
> It does SYN checking. If you are running 'serious' security you wouldnt be
> allowing outgoing connections anyway. One windows christmascard.exe virus that
> connects back to an irc server to take input and you are hosed.
Thankfully, pine and mutt are, to date, immune to that
1 - 100 of 202 matches
Mail list logo
