Michael Harris wrote:
>
> [2.] The problem occurs in a forking server similar in function to
> inetd. The server employs a very simple SIGCHLD handler that loops on
> wait(2), until all zombie processes have been collected. For no
> immediately apparent reason, the parent process behaves as if
Michael Harris wrote:
[2.] The problem occurs in a forking server similar in function to
inetd. The server employs a very simple SIGCHLD handler that loops on
wait(2), until all zombie processes have been collected. For no
immediately apparent reason, the parent process behaves as if it no
On Thu, 21 Apr 2005, Chris Friesen wrote:
>
> Does mainline have a high precision monotonic wallclock that is not
> affected by time-of-day changes? Something like "nano/mico seconds
> since boot"?
On newer kernels with the posix timers (I think 2.6 - not sure though)
there's
On Thu, 21 Apr 2005, Chris Friesen wrote:
Does mainline have a high precision monotonic wallclock that is not
affected by time-of-day changes? Something like nano/mico seconds
since boot?
On newer kernels with the posix timers (I think 2.6 - not sure though)
there's
Thomas Speck wrote:
>
> tio.c_cflag = baud | CLOCAL;
How about adding CREAD?
Ciao, ET.
-
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
Thomas Speck wrote:
tio.c_cflag = baud | CLOCAL;
How about adding CREAD?
Ciao, ET.
-
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
Alexander Viro wrote:
>
> On Thu, 7 Jun 2001, Edgar Toernig wrote:
>
> > Alexander Viro wrote:
> > > ...
> > > dir = open("/usr/local", O_DIRECTORY);
> > > /* error handling */
> > > new_mount(dir, MNT_
Alexander Viro wrote:
> ...
> dir = open("/usr/local", O_DIRECTORY);
> /* error handling */
> new_mount(dir, MNT_SET, fs_fd); /* closes dir and fs_fd */
Do you really want to start using fds instead of strings for tree
modifying commands (link, unlink, symlink,
Alexander Viro wrote:
...
dir = open(/usr/local, O_DIRECTORY);
/* error handling */
new_mount(dir, MNT_SET, fs_fd); /* closes dir and fs_fd */
Do you really want to start using fds instead of strings for tree
modifying commands (link, unlink, symlink, rename,
Alexander Viro wrote:
On Thu, 7 Jun 2001, Edgar Toernig wrote:
Alexander Viro wrote:
...
dir = open(/usr/local, O_DIRECTORY);
/* error handling */
new_mount(dir, MNT_SET, fs_fd); /* closes dir and fs_fd */
Do you really want to start using
Daniel Phillips wrote:
>
> It won't, the open for "." is handled in the VFS, not the filesystem -
> it will open the directory. (Without needing to be told it's a
> directory via O_DIRECTORY.) If you do open("magicdev") you'll get the
> device, because that's handled by magicdevfs.
You really
Daniel Phillips wrote:
It won't, the open for . is handled in the VFS, not the filesystem -
it will open the directory. (Without needing to be told it's a
directory via O_DIRECTORY.) If you do open(magicdev) you'll get the
device, because that's handled by magicdevfs.
You really mean
Daniel Phillips wrote:
>
> Oops, oh wait, there's already another open point: your breakage
> examples both rely on opening ".". You're right, "." should always be
> a directory and I believe that's enforced by the VFS. So we don't have
> an example of breakage yet.
That's just because I did
Daniel Phillips wrote:
Oops, oh wait, there's already another open point: your breakage
examples both rely on opening .. You're right, . should always be
a directory and I believe that's enforced by the VFS. So we don't have
an example of breakage yet.
That's just because I did a simple
Daniel Phillips wrote:
> On Wednesday 23 May 2001 06:19, Edgar Toernig wrote:
> > Daniel Phillips wrote:
> > > On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
> > > > On Mon, 21 May 2001, Daniel Phillips wrote:
> > > > > On Monday 21 May 2001 19:1
Daniel Phillips wrote:
On Wednesday 23 May 2001 06:19, Edgar Toernig wrote:
Daniel Phillips wrote:
On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
On Mon, 21 May 2001, Daniel Phillips wrote:
On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
What I'd like to see
Daniel Phillips wrote:
>
> On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
> > On Mon, 21 May 2001, Daniel Phillips wrote:
> > > On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
> > > > What I'd like to see:
> > > >
> > > > - An interface for registering an array of related devices
> > > >
Daniel Phillips wrote:
On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
On Mon, 21 May 2001, Daniel Phillips wrote:
On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
What I'd like to see:
- An interface for registering an array of related devices
(almost always two:
Alexander Viro wrote:
>
> On Sun, 20 May 2001, Edgar Toernig wrote:
>
> > IMHO any scheme that requires a special name to perform ioctl like
> > functions will not work. Often you don't known the name of the
> > device you're talking to and then you're lost.
>
&
Alexander Viro wrote:
>
> For the latter, though,
> we need to write commands into files and here your miscdevices (or procfs
> files, or /dev/foo/ctl - whatever) is needed.
IMHO any scheme that requires a special name to perform ioctl like
functions will not work. Often you don't known the
Alexander Viro wrote:
For the latter, though,
we need to write commands into files and here your miscdevices (or procfs
files, or /dev/foo/ctl - whatever) is needed.
IMHO any scheme that requires a special name to perform ioctl like
functions will not work. Often you don't known the name
Alexander Viro wrote:
On Sun, 20 May 2001, Edgar Toernig wrote:
IMHO any scheme that requires a special name to perform ioctl like
functions will not work. Often you don't known the name of the
device you're talking to and then you're lost.
ls -l /proc/self/fd/n
Oh come on. You
nitpicking: a system call without side effects would be pretty useless.
Alexander Viro wrote:
> A lot of stuff relies on the fact that close(open(foo, O_RDONLY)) is a
> no-op. Breaking that assumption is a Bad Thing(tm).
That assumption is totally bogus. Even for regular files you have side
nitpicking: a system call without side effects would be pretty useless.
Alexander Viro wrote:
A lot of stuff relies on the fact that close(open(foo, O_RDONLY)) is a
no-op. Breaking that assumption is a Bad Thing(tm).
That assumption is totally bogus. Even for regular files you have side
Larry McVoy wrote:
>
> Let's review: ECC is nice, but it doesn't solve all data corruption
> problems. Applications which do their own end to end data integrity
> checks will catch many more error cases than what ECC catches.
I think you have a wrong idea why the ECC is there. ECC deals with
Larry McVoy wrote:
Let's review: ECC is nice, but it doesn't solve all data corruption
problems. Applications which do their own end to end data integrity
checks will catch many more error cases than what ECC catches.
I think you have a wrong idea why the ECC is there. ECC deals with
the
Hi,
Michael Clark wrote:
>
> An obvious kernel improvement for userspace meters like NeTraMet would
> be to give libpcap's pcap_read a kernel interface that can return more
> than one packet at a time (the libpcap interface has this capability).
It's already there - the turbo packet interface
Hi,
[EMAIL PROTECTED] wrote:
>
> 1. for tp_frame_size, I dont want to truncate any data on ethernet, I
> need 1514 bytes, is this the best way to do it and not waste space?
>
> static const int TURBO_FRAME_SIZE=
> TPACKET_ALIGN(TPACKET_ALIGN(sizeof(tpacket_hdr)) +
>
Hi,
[EMAIL PROTECTED] wrote:
1. for tp_frame_size, I dont want to truncate any data on ethernet, I
need 1514 bytes, is this the best way to do it and not waste space?
static const int TURBO_FRAME_SIZE=
TPACKET_ALIGN(TPACKET_ALIGN(sizeof(tpacket_hdr)) +
Hi,
Michael Clark wrote:
An obvious kernel improvement for userspace meters like NeTraMet would
be to give libpcap's pcap_read a kernel interface that can return more
than one packet at a time (the libpcap interface has this capability).
It's already there - the turbo packet interface
Michael Lindner wrote:
>[...]
> send(s, ".", 1, 0);
>[...]
> while (select(r+1, , 0, 0, 0) > 0) {
>[...]
>[select returns only after about 1 HZ]
Ever heard of nagle? (If not, there's a long thread about
it on the mailing list *g*)
It's not the select that waits. It's a
Michael Lindner wrote:
[...]
send(s, ".", 1, 0);
[...]
while (select(r+1, readfds, 0, 0, 0) 0) {
[...]
[select returns only after about 1 HZ]
Ever heard of nagle? (If not, there's a long thread about
it on the mailing list *g*)
It's not the select that waits. It's a
Linus Torvalds wrote:
>
> The point they disagree is when the event gets removed from the event
> queue. For edge triggered, this one is trivial: when a get_events() thing
> happens and moves it into user land. This is basically a one-liner, and it
> is local to get_events() and needs absolutely
Linus Torvalds wrote:
The point they disagree is when the event gets removed from the event
queue. For edge triggered, this one is trivial: when a get_events() thing
happens and moves it into user land. This is basically a one-liner, and it
is local to get_events() and needs absolutely no
34 matches
Mail list logo
