Date: Fri, 10 Nov 2000 10:36:31 -0800
From: "Matt D. Robinson" [EMAIL PROTECTED]
As soon as I finish writing raw write disk routines (not using kiobufs),
we can _maybe_ get LKCD accepted one of these days, especially now that we
don't have to build 'lcrash' against a kernel
Date: Thu, 9 Nov 2000 14:26:33 + (GMT)
From: Alan Cox <[EMAIL PROTECTED]>
> Actually, he's been quite specific. It's ok to have binary modules as
> long as they conform to the interface defined in /proc/ksyms.
What is completely unclear is if he has the authority to say
Date:Wed, 08 Nov 2000 16:35:33 -0500
From: Michael Rothwell <[EMAIL PROTECTED]>
Sounds great; unfortunately, the core group has spoken out against a
modular kernel.
This is true; that's because a modular kernel means that interfaces have
to be frozen in time, usually
Date:Thu, 09 Nov 2000 08:43:14 -0500
From: Michael Rothwell <[EMAIL PROTECTED]>
And how would a hypothetical Advanced Linux Kernel Project be different?
Set aside the GKHI and the issue of binary-only hook modules; how would
an "enterprise" fork be any different than RT or
Date:Thu, 9 Nov 2000 13:39:04 + (GMT)
From: Paul Jakma <[EMAIL PROTECTED]>
I actually think Linus has been too loose/vague on modules. The
official COPYING txt file in the tree contains an exception on linking
to the kernel using syscalls from linus and the GPL.
Date:Thu, 9 Nov 2000 13:39:04 + (GMT)
From: Paul Jakma [EMAIL PROTECTED]
I actually think Linus has been too loose/vague on modules. The
official COPYING txt file in the tree contains an exception on linking
to the kernel using syscalls from linus and the GPL. nothing
Date:Thu, 09 Nov 2000 08:43:14 -0500
From: Michael Rothwell [EMAIL PROTECTED]
And how would a hypothetical Advanced Linux Kernel Project be different?
Set aside the GKHI and the issue of binary-only hook modules; how would
an "enterprise" fork be any different than RT or
Date:Wed, 08 Nov 2000 16:35:33 -0500
From: Michael Rothwell [EMAIL PROTECTED]
Sounds great; unfortunately, the core group has spoken out against a
modular kernel.
This is true; that's because a modular kernel means that interfaces have
to be frozen in time, usually forever.
Date: Thu, 9 Nov 2000 14:26:33 + (GMT)
From: Alan Cox [EMAIL PROTECTED]
Actually, he's been quite specific. It's ok to have binary modules as
long as they conform to the interface defined in /proc/ksyms.
What is completely unclear is if he has the authority to say that
From: Ulrich Drepper <[EMAIL PROTECTED]>
Date: 06 Nov 2000 10:50:37 -0800
> Arguably though the bug is in glibc, in that if it's using signals
> behinds the scenes, it should have passed SA_RESTART to sigaction.
Why are you talking such a nonsense?
The claim was made that
From: Ulrich Drepper [EMAIL PROTECTED]
Date: 06 Nov 2000 10:50:37 -0800
Arguably though the bug is in glibc, in that if it's using signals
behinds the scenes, it should have passed SA_RESTART to sigaction.
Why are you talking such a nonsense?
The claim was made that pthreads
Date:Mon, 6 Nov 2000 09:13:25 -0500 (EST)
From: George Talbot <[EMAIL PROTECTED]>
I respectfully disagree that programs which don't surround some of the
most common system calls with
do
{
rv = __some_system_call__(...);
}
Date:Mon, 6 Nov 2000 09:13:25 -0500 (EST)
From: George Talbot [EMAIL PROTECTED]
I respectfully disagree that programs which don't surround some of the
most common system calls with
do
{
rv = __some_system_call__(...);
}
Date:Fri, 03 Nov 2000 14:44:17 -0500
From: [EMAIL PROTECTED]
My problem is that pthread_create (glibc 2.1.3, kernel 2.2.17 i686) is
failing because, deep inside glibc somewhere, nanosleep() is returning
EINTR.
Sounds like it might be a bug in pthread_create although
Date:Fri, 03 Nov 2000 14:44:17 -0500
From: [EMAIL PROTECTED]
My problem is that pthread_create (glibc 2.1.3, kernel 2.2.17 i686) is
failing because, deep inside glibc somewhere, nanosleep() is returning
EINTR.
Sounds like it might be a bug in pthread_create although
Date: Thu, 02 Nov 2000 13:53:55 -0700
From: Tim Riker <[EMAIL PROTECTED]>
As is being discussed here, C99 has some replacements to the gcc syntax
the kernel uses. I believe the C99 syntax will win in the near future,
and thus the gcc syntax will have to be removed at some point.
Date:Thu, 02 Nov 2000 12:31:51 -0700
From: Tim Riker <[EMAIL PROTECTED]>
Me or Alan? I did not mean this as a dig. I feel strongly that one
should have the choice here. I do not choose to enforce my beliefs on
anyone else. I am suggesting only that others should provide
Date:Thu, 02 Nov 2000 12:31:51 -0700
From: Tim Riker [EMAIL PROTECTED]
Me or Alan? I did not mean this as a dig. I feel strongly that one
should have the choice here. I do not choose to enforce my beliefs on
anyone else. I am suggesting only that others should provide the
Date: Thu, 02 Nov 2000 13:53:55 -0700
From: Tim Riker [EMAIL PROTECTED]
As is being discussed here, C99 has some replacements to the gcc syntax
the kernel uses. I believe the C99 syntax will win in the near future,
and thus the gcc syntax will have to be removed at some point. In
Date: Wed, 1 Nov 2000 09:46:19 -0500
From: [EMAIL PROTECTED]
On Mon, Oct 30, 2000 at 05:14:34PM +0100, Martin Dalecki wrote:
> Of corse right! BTW. There are tons of places where log2 is calculated
> explicitly in kernel which should be replaced with the corresponding
> built
Date: Wed, 1 Nov 2000 09:46:19 -0500
From: [EMAIL PROTECTED]
On Mon, Oct 30, 2000 at 05:14:34PM +0100, Martin Dalecki wrote:
Of corse right! BTW. There are tons of places where log2 is calculated
explicitly in kernel which should be replaced with the corresponding
built
Date: Tue, 24 Oct 2000 11:14:13 +0200
From: octave klaba <[EMAIL PROTECTED]>
> Can you actually give me some details of how your system "crashed"? It
> certainly shouldn't have. Kermit will sometimes hang waiting for the
> terminal to flush if it's enabled hardware flow control
Date: Tue, 24 Oct 2000 11:14:13 +0200
From: octave klaba [EMAIL PROTECTED]
Can you actually give me some details of how your system "crashed"? It
certainly shouldn't have. Kermit will sometimes hang waiting for the
terminal to flush if it's enabled hardware flow control and
Date:Fri, 06 Oct 2000 12:01:34 -0500
From: Jeff Dike <[EMAIL PROTECTED]>
tty_register_devfs and tty_unregister_devfs both declare "struct tty_struct" locals.
According to gdb:
(gdb) p sizeof(struct tty_struct)
$20 = 3084
This eats up most of a 4K page, and on UML
Date:Fri, 06 Oct 2000 12:01:34 -0500
From: Jeff Dike [EMAIL PROTECTED]
tty_register_devfs and tty_unregister_devfs both declare "struct tty_struct" locals.
According to gdb:
(gdb) p sizeof(struct tty_struct)
$20 = 3084
This eats up most of a 4K page, and on UML
Date: Fri, 29 Sep 2000 22:16:53 -0700 (PDT)
From: Andre Hedrick <[EMAIL PROTECTED]>
Basically you can de-stroke a drive with what you let the OS/FS report.
Once this is done there is no way any FS can get to the stuff beyond what
it knows about.
I'm not sure what you mean by
Date: Fri, 29 Sep 2000 22:16:53 -0700 (PDT)
From: Andre Hedrick [EMAIL PROTECTED]
Basically you can de-stroke a drive with what you let the OS/FS report.
Once this is done there is no way any FS can get to the stuff beyond what
it knows about.
I'm not sure what you mean by
Date:Sat, 30 Sep 2000 04:10:59 +0200
From: Marc Lehmann <[EMAIL PROTECTED]>
Do you really think that explicitly supporting broken distributions
(redhat 7.0 comes with a experimental snapshot of gcc which is neither
binary compatible to 2.95 nor to 3.0, cutting binary
Date:Fri, 29 Sep 2000 17:49:04 -0600
From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
This is going to be a continuing problem for non-Unix file systems like
NTFS and NWFS that rely on the ability to read and write variable length
sector runs.
It's not just non-Unix file
Date:Fri, 29 Sep 2000 19:24:01 +0200
From: Frederic Magniette <[EMAIL PROTECTED]>
We would like to do some operations on a ext2 disk while it is
mounted read-only. The problem is that our operations have no
effects because everithing is cached. Is it possible to shrink
Date:Fri, 29 Sep 2000 17:49:04 -0600
From: "Jeff V. Merkey" [EMAIL PROTECTED]
This is going to be a continuing problem for non-Unix file systems like
NTFS and NWFS that rely on the ability to read and write variable length
sector runs.
It's not just non-Unix file
Date:Sat, 30 Sep 2000 04:10:59 +0200
From: Marc Lehmann [EMAIL PROTECTED]
Do you really think that explicitly supporting broken distributions
(redhat 7.0 comes with a experimental snapshot of gcc which is neither
binary compatible to 2.95 nor to 3.0, cutting binary
Date:Fri, 15 Sep 2000 15:01:25 +0200
From: Matthias Andree <[EMAIL PROTECTED]>
BUG DESCRIPTION:
(This is for IPv4, someone would have to check IPv6 as well).
The socket flag O_NONBLOCK is _NOT_ properly inherited through an
accept(2) call, in spite of what
Date:Fri, 15 Sep 2000 15:01:25 +0200
From: Matthias Andree [EMAIL PROTECTED]
BUG DESCRIPTION:
(This is for IPv4, someone would have to check IPv6 as well).
The socket flag O_NONBLOCK is _NOT_ properly inherited through an
accept(2) call, in spite of what socket(7)
Date: Fri, 15 Sep 2000 01:06:24 +0200 (MEST)
From: [EMAIL PROTECTED] (Rogier Wolff)
My suggestion is indeed effectivly (almost) doubling the inode size.
However, it provides an upgrade path, where you can double-boot with a
kernel that DOESN"T know about the inodes.
The 2.2
Date: Thu, 14 Sep 2000 15:45:24 -0700
From: Larry McVoy <[EMAIL PROTECTED]>
I'm going to have to respectfully disagree. First of all, having a flag
day where everyone switches to BK just isn't a realistic expectation,
even if the license wasn't an issue. Things just don't work
Date: Wed, 13 Sep 2000 17:17:01 -0400
From: Jeff Garzik <[EMAIL PROTECTED]>
I ran with the idea, and created the attached patch, against
2.4.0-test8. It converts serial.c to the new PCI API (quite compactly,
I might add) It should be possible with this patch to now hotplug
From: "Mike" <[EMAIL PROTECTED]>
Date:Thu, 14 Sep 2000 20:34:42 +0400
Just have compiled 2.4.0-test8 today...
Nothing interesting
Everything goes the same way as 2 test releases before...
All my devices are detected right, but... :-(
Kernel panic again at the file
Date: Thu, 14 Sep 2000 17:12:35 +0200 (MEST)
From: [EMAIL PROTECTED] (Rogier Wolff)
The "right" way to do this is to have a "this spot is in use, but you
don't understand it" indication for an inode (*). The "expansion ptr"
can then normally point to the directly following inode,
Date: Thu, 14 Sep 2000 17:03:11 +0200 (CEST)
From: Trond Myklebust <[EMAIL PROTECTED]>
For the timestamps, yes, but inode caching will take most of that
hit. After all, the only time stat() reads from disk is when the inode
has completely fallen out of the cache.
For commonly
Date: Thu, 14 Sep 2000 15:09:35 +0200 (CEST)
From: Trond Myklebust <[EMAIL PROTECTED]>
Would it perhaps make sense to use one of these last 'free' fields
as a pointer to an 'inode entension'?
If you still want ext2fs to be able to accommodate new projects and
ideas, then it
From: "Albert D. Cahalan" <[EMAIL PROTECTED]>
Date:Wed, 13 Sep 2000 19:20:42 -0400 (EDT)
The ext2 inode has 6 obviously free bytes, 6 that are only used
on filesystems marked as Hurd-type, and 8 that seem to be claimed
by competing security and EA projects. So, being
From: "Albert D. Cahalan" [EMAIL PROTECTED]
Date:Wed, 13 Sep 2000 19:20:42 -0400 (EDT)
The ext2 inode has 6 obviously free bytes, 6 that are only used
on filesystems marked as Hurd-type, and 8 that seem to be claimed
by competing security and EA projects. So, being
Date: Thu, 14 Sep 2000 15:09:35 +0200 (CEST)
From: Trond Myklebust [EMAIL PROTECTED]
Would it perhaps make sense to use one of these last 'free' fields
as a pointer to an 'inode entension'?
If you still want ext2fs to be able to accommodate new projects and
ideas, then it seems
From: "Mike" [EMAIL PROTECTED]
Date:Thu, 14 Sep 2000 20:34:42 +0400
Just have compiled 2.4.0-test8 today...
Nothing interesting
Everything goes the same way as 2 test releases before...
All my devices are detected right, but... :-(
Kernel panic again at the file
Date: Fri, 15 Sep 2000 01:06:24 +0200 (MEST)
From: [EMAIL PROTECTED] (Rogier Wolff)
My suggestion is indeed effectivly (almost) doubling the inode size.
However, it provides an upgrade path, where you can double-boot with a
kernel that DOESN"T know about the inodes.
The 2.2
Date: Thu, 14 Sep 2000 15:45:24 -0700
From: Larry McVoy [EMAIL PROTECTED]
I'm going to have to respectfully disagree. First of all, having a flag
day where everyone switches to BK just isn't a realistic expectation,
even if the license wasn't an issue. Things just don't work
Date: Wed, 13 Sep 2000 22:35:10 +0200 (CEST)
From: Trond Myklebust <[EMAIL PROTECTED]>
You might be able to steal a couple of bytes and then rewrite ext2fs
to mask those out from the 'i_generation' field, but it would mean that
you could no longer boot your old 2.2.16 kernel
From: "Dunlap, Randy" <[EMAIL PROTECTED]>
Date: Wed, 13 Sep 2000 09:17:55 -0700
I appreciate Alan and you doing the kernel Status/TODO lists,
but I think that you ought to simplify it for yourself at
least (not that this would help Linus) by having maintainers
do it instead of
Date: Wed, 13 Sep 2000 17:14:57 +0200 (MEST)
From: [EMAIL PROTECTED] (Rogier Wolff)
Today we fixed a problem in a driver we maintain here. We should've
gone ahead and generate the patch and queued it for Linus. However,
in reality we'd like the complaining customer to test the
Date:Wed, 13 Sep 2000 12:56:22 +0100 (BST)
From: Alan Cox <[EMAIL PROTECTED]>
> suggest a unique identifier for your patch? Humans are usually better
> at picking sensible names than a machine, and in discussions, it is
> better to refer to 'ide-foobar-fix3' than KP7562
Date:Wed, 13 Sep 2000 12:54:49 +0200 (CEST)
From: Trond Myklebust <[EMAIL PROTECTED]>
Don't forget that 2^20 > 10^6, hence if you really want units of
microseconds, you actually only need to save 3 bytes worth of data per
timestamp.
For the purposes of NFS, however the
Date:Wed, 13 Sep 2000 02:27:07 -0700
From: "David S. Miller" <[EMAIL PROTECTED]>
rsync [EMAIL PROTECTED]:/home/torvalds/src/linux \
ftp.kernel.org:/pub/linux/kernel/LIVE/linux
would be the real helper for people like me whose only real issue
now is bothering
Date:Wed, 13 Sep 2000 03:30:39 -0700
From: "David S. Miller" <[EMAIL PROTECTED]>
From: Daniel Quinlan <[EMAIL PROTECTED]>
Date: Wed, 13 Sep 2000 03:18:14 -0700 (PDT)
How exactly does a system to tracking patches and bugs/fixes (not to
mention helping
Date: Wed, 13 Sep 2000 10:03:39 +0200
From: Andries Brouwer <[EMAIL PROTECTED]>
On Wed, Sep 13, 2000 at 01:56:39AM -0400, [EMAIL PROTECTED] wrote:
> 8. Fix Exists But Isnt Merged
...
> 9. To Do
> * Mount of new fs over existing mointpoint should return an error
>
Date: Tue, 12 Sep 2000 23:55:55 -0700
From: David Ford <[EMAIL PROTECTED]>
Please add 'APM resume returns the machine to the first tty, crashes
X' This appeared w/ test8. If this is intended, I'd be very happy to
know if so and I can write in to xfree86 about it. If not
Date:Wed, 13 Sep 2000 08:46:00 +0200
From: Harald Dunkel <[EMAIL PROTECTED]>
How can I submit a bug report to be added to this list?
I *try* to follow bug reports sent to Linux-kernel, but if you want to
be sure, send it directly to me ([EMAIL PROTECTED]).
(And now for the
Date: Tue, 12 Sep 2000 23:37:57 -0700
From: David Ford <[EMAIL PROTECTED]>
> > 4. Boot Time Failures
> >
> > * Use PCI DMA 'lost interrupt' problem with some hw [which ?] (NEC
> >Versa LX with PIIX tuning)
>
> If this is a rare version of the BX/LX that has a
Date:Wed, 13 Sep 2000 12:54:49 +0200 (CEST)
From: Trond Myklebust [EMAIL PROTECTED]
Don't forget that 2^20 10^6, hence if you really want units of
microseconds, you actually only need to save 3 bytes worth of data per
timestamp.
For the purposes of NFS, however the
Date: Wed, 13 Sep 2000 22:35:10 +0200 (CEST)
From: Trond Myklebust [EMAIL PROTECTED]
You might be able to steal a couple of bytes and then rewrite ext2fs
to mask those out from the 'i_generation' field, but it would mean that
you could no longer boot your old 2.2.16 kernel without
Date:Wed, 13 Sep 2000 03:30:39 -0700
From: "David S. Miller" [EMAIL PROTECTED]
From: Daniel Quinlan [EMAIL PROTECTED]
Date: Wed, 13 Sep 2000 03:18:14 -0700 (PDT)
How exactly does a system to tracking patches and bugs/fixes (not to
mention helping Linus
Date:Wed, 13 Sep 2000 02:27:07 -0700
From: "David S. Miller" [EMAIL PROTECTED]
rsync [EMAIL PROTECTED]:/home/torvalds/src/linux \
ftp.kernel.org:/pub/linux/kernel/LIVE/linux
would be the real helper for people like me whose only real issue
now is bothering
From: "Dunlap, Randy" [EMAIL PROTECTED]
Date: Wed, 13 Sep 2000 09:17:55 -0700
I appreciate Alan and you doing the kernel Status/TODO lists,
but I think that you ought to simplify it for yourself at
least (not that this would help Linus) by having maintainers
do it instead of
Date:Wed, 13 Sep 2000 01:23:30 +0200 (CEST)
From: Igmar Palsenberg <[EMAIL PROTECTED]>
> No, not true. The mixing into the entropy pool uses a twisted LFSR, but
> all outputs from the pool (to either /dev/random or /dev/urandom)
> filters the output through SHA-1 as a
Date: Tue, 12 Sep 2000 09:56:12 +
From: Pravir Chandra <[EMAIL PROTECTED]>
i agree that the yarrow generator does place some faith on the crypto
cipher and the accumulator uses a hash, but current /dev/random
places faith on a crc and urandom uses a hash.
No, not true. The
Date:Mon, 11 Sep 2000 18:27:30 -0700
From: David Ford <[EMAIL PROTECTED]>
> I've told Linus several times about this problems but he puts out one
> test release after the other without this fixed.
This is kinda important, I run DNS tools which are threaded amongst
Date: Mon, 11 Sep 2000 17:51:20 -0600
From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
I support source level in the kernel. Based on Andi Klein's review, I
have grabbed ext2utils and am looking at a minimal int 0x13 interface to
load files into memory. hardest problem here for Linux
On Mon, 11 Sep 2000, Jeff V. Merkey wrote:
>
> Thanks Ted. I know, but a kernel debugger is one of those nasty pieaces
> of software that can quickly get out of sync if it's maintained
> separately from the tree -- the speed at which changes occur in Linux
> would render it a very difficult
Date:Mon, 11 Sep 2000 13:08:59 +
From: Pravir Chandra <[EMAIL PROTECTED]>
I've been working to change the implementation of /dev/random over to the
Yarrow-160a algorithm created by Bruce Schneier and John Kelsey. We've been
working on parallel development for Linux and
Date:Mon, 11 Sep 2000 13:08:59 +
From: Pravir Chandra [EMAIL PROTECTED]
I've been working to change the implementation of /dev/random over to the
Yarrow-160a algorithm created by Bruce Schneier and John Kelsey. We've been
working on parallel development for Linux and
On Mon, 11 Sep 2000, Jeff V. Merkey wrote:
Thanks Ted. I know, but a kernel debugger is one of those nasty pieaces
of software that can quickly get out of sync if it's maintained
separately from the tree -- the speed at which changes occur in Linux
would render it a very difficult project
Date: Mon, 11 Sep 2000 17:51:20 -0600
From: "Jeff V. Merkey" [EMAIL PROTECTED]
I support source level in the kernel. Based on Andi Klein's review, I
have grabbed ext2utils and am looking at a minimal int 0x13 interface to
load files into memory. hardest problem here for Linux is
Date:Mon, 11 Sep 2000 18:27:30 -0700
From: David Ford [EMAIL PROTECTED]
I've told Linus several times about this problems but he puts out one
test release after the other without this fixed.
This is kinda important, I run DNS tools which are threaded amongst
numerous
Date: Tue, 12 Sep 2000 09:56:12 +
From: Pravir Chandra [EMAIL PROTECTED]
i agree that the yarrow generator does place some faith on the crypto
cipher and the accumulator uses a hash, but current /dev/random
places faith on a crc and urandom uses a hash.
No, not true. The
Date:Wed, 13 Sep 2000 01:23:30 +0200 (CEST)
From: Igmar Palsenberg [EMAIL PROTECTED]
No, not true. The mixing into the entropy pool uses a twisted LFSR, but
all outputs from the pool (to either /dev/random or /dev/urandom)
filters the output through SHA-1 as a
Date:Wed, 6 Sep 2000 01:43:47 +0100 (BST)
From: Alex Buell <[EMAIL PROTECTED]>
> Only, with the former, I get to restart the application everytime it
> croaks, with the latter (modules excluded) I have to reboot. This is
> much more time consuming and means you really have
Date:Wed, 6 Sep 2000 01:43:47 +0100 (BST)
From: Alex Buell [EMAIL PROTECTED]
Only, with the former, I get to restart the application everytime it
croaks, with the latter (modules excluded) I have to reboot. This is
much more time consuming and means you really have to
From: Russell Coker <[EMAIL PROTECTED]>
Date:Mon, 4 Sep 2000 15:42:57 +0200
In test7 the stallion.c serial driver is in the drivers/media/video
directory. This means that it won't compile and that compilation will break
if the Stallion driver is enabled.
Could this
From: Ulrich Drepper <[EMAIL PROTECTED]>
Date:01 Sep 2000 14:52:28 -0700
1st Problem: One signal handler process process-wide
What is handled correctly now is sending signals to the group. Also
that every thread has its mask. But there must be exactly one signal
Date:Fri, 01 Sep 2000 08:47:04 -0700
From: Stephen Satchell <[EMAIL PROTECTED]>
5) Even better would be to obtain the services of a PR firm used to
dealing with high-tech questions -- if you would like a list of potential
sponsors I can poll the IPG to see who might be
From: Daniel Phillips <[EMAIL PROTECTED]>
Date:Fri, 01 Sep 2000 20:49:14 +0200
Curiously, this field is measured in 512 byte units, giving a 2TB Ext2
filesize limit. That's starting to look uncomfortably small - I can
easily imagine a single database file wanting to be
From: Russell King <[EMAIL PROTECTED]>
Date: Fri, 1 Sep 2000 16:23:39 +0100 (BST)
At the marked line (! - line 647), what if flip.count is equal to
TTY_FLIPBUF_SIZE? Surely we're writing to a character outside the
flag_buf_ptr array? If that is the case, should we not move this
Date:Fri, 1 Sep 2000 12:47:44 +0200 (MESZ)
From: "Dr. Michael Weller" <[EMAIL PROTECTED]>
Sorry, I've no idea about the ext2 and fs implementation.
However did you read the comment below and convince yourself that 'err' is
always set correctly?
I looked at it and was
From: Russell King [EMAIL PROTECTED]
Date: Fri, 1 Sep 2000 16:23:39 +0100 (BST)
At the marked line (! - line 647), what if flip.count is equal to
TTY_FLIPBUF_SIZE? Surely we're writing to a character outside the
flag_buf_ptr array? If that is the case, should we not move this
From: Daniel Phillips [EMAIL PROTECTED]
Date:Fri, 01 Sep 2000 20:49:14 +0200
Curiously, this field is measured in 512 byte units, giving a 2TB Ext2
filesize limit. That's starting to look uncomfortably small - I can
easily imagine a single database file wanting to be
From: Ulrich Drepper [EMAIL PROTECTED]
Date:01 Sep 2000 14:52:28 -0700
1st Problem: One signal handler process process-wide
What is handled correctly now is sending signals to the group. Also
that every thread has its mask. But there must be exactly one signal
801 - 886 of 886 matches
Mail list logo
