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
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 clock_gettime(CLOC
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
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, ren
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:
>
> 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
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 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
> > > >
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'r
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 nam
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
eff
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
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)) +
>TPAC
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.
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
17 matches
Mail list logo
