nevermind, i found it, thankyou :)
-d
--
"There is a natural aristocracy among men. The grounds of this are
virtue and talents", Thomas Jefferson [1742-1826], 3rd US President
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
org:http://www.kalifornia.com/images/paradise.jpg">
adr:;;
I was looking through the current versions of the kernel, was re-reading
through some past "TODO before release" sort of messages, and was wondering,
could these TODO type of items be included in an actual TODO file at the
source top level (or in the Documentation if this would be more appropriate
Hello,
I realise this may be a little off topic but I think the kernel is the
only
place I will be able to pull this stunt.
I need a block of memory that can notify me or even a flag set when
it has been written to. I was thinking of letting the user code generate
some sort of page fault... Any
I'm the author of a malloc debugger (http://fscked.org/proj/njamd.shtml), and
I was trying to pin down some bugs people were reporting about not being able
to debug large apps despite having plenty of ram. Eventually I paired it down
to the Linux mm system rejecting map requests if the number of m
Hi,
The following piece of code in ll_rw_block() aims to limit the number of
locked buffers by making processes throttle on IO if the number of on
flight requests is bigger than a high watermaker. IO will only start
again if we're under a low watermark.
if (atomic_read(&queued_
(1) Random paging request errors
(2) Every so often, I get a non-fatal error on my screen about a kernel
paging request error. I can't identify when it happens, or why, but I
thought people on this list might be able to interpret the message. If
more information from the moment of err
r
the line "stopping all md devices":
^ [] [] [] [<..>]
^ ...
^
^ Code: <1>Unable to handle kernel paging request at virtual address
872f
^ Current->tss.cr3 = 069c, %cr3 = 069c
^ *pde =
^ Oops:
^ CPU:0
^ EIP:0010:[]
^ EFLAGS: 00010046
^ ea
From: "Eric Bresie" <[EMAIL PROTECTED]>
Date:Mon, 9 Oct 2000 15:31:56 -0500
The existing TODO type list I refer to are those produced by Kenneth C.
Arnold ( http://kena.8k.com/linux-kernel/ ) (who is doing a fine job I might
add) and formerly by Alan Cox.
I've taken a look
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 11, 2000 5:43 PM
>
> I've taken a look at that list, and it looks fairly obsolete, as far as
> I could tell. There is an actively maintained list which I post
> periodically to the Linux-Kernel mailing list, and whic
users are getting files OK etc. The can't
get
request slot is plaguing many others in different ways.
It looks like
an NFS issue. How can this be proven? Then we can
work on the
problem.
Thanks
--
Grahame Jordan
Network Manager
Interim Technology Training Institute
Mobile: +61 3 0408 05
When playing audio CDs under kernel 2.4.0, syslog is showing the
following message repeatedly:
sr0: CDROM (ioctl) reports ILLEGAL REQUEST.
The command line utility cdplay seems to only cause this occasionally,
when I start playing a CD or skip to a different track, while gnome's
gtcd
> mprotect the page(s) you are interested in so you can't write to them
> and catch SEGV -- when someone attempts to write you can pull apart
> the stack frame mark the page(s) RO and continue.
>
> if you are really stuck i think i have example code to do this
> somewhere for ia32 (stack frame i
Leslie Donaldson wrote:
> I need a block of memory that can notify me or even a flag set when
> it has been written to. I was thinking of letting the user code generate
> some sort of page fault... Any random thoughts would be greatly
> appreciated.
Look for the Boehm garbage collector. It has c
On Thu, Feb 22 2001, Marcelo Tosatti wrote:
> The following piece of code in ll_rw_block() aims to limit the number of
> locked buffers by making processes throttle on IO if the number of on
> flight requests is bigger than a high watermaker. IO will only start
> again if we're under a low waterma
On Thu, 22 Feb 2001, Jens Axboe wrote:
> On Thu, Feb 22 2001, Marcelo Tosatti wrote:
> > The following piece of code in ll_rw_block() aims to limit the number of
> > locked buffers by making processes throttle on IO if the number of on
> > flight requests is bigger than a high watermaker. IO wi
ARE_WAIT_QUEUE_HEAD(blk_buffers_wait);
static inline int get_max_sectors(kdev_t dev)
{
@@ -397,11 +390,17 @@
rq = kmem_cache_alloc(request_cachep, SLAB_KERNEL);
memset(rq, 0, sizeof(struct request));
rq->rq_status = RQ_INACTIVE;
- l
On Thu, 22 Feb 2001, Linus Torvalds wrote:
>
>
> On Thu, 22 Feb 2001, Jens Axboe wrote:
>
> > On Thu, Feb 22 2001, Marcelo Tosatti wrote:
> > > The following piece of code in ll_rw_block() aims to limit the number of
> > > locked buffers by making processes throttle on IO if the number of on
On Thu, 22 Feb 2001, Andrea Arcangeli wrote:
> On Thu, Feb 22, 2001 at 10:59:20AM -0800, Linus Torvalds wrote:
> > I'd prefer for this check to be a per-queue one.
>
> I'm running this in my tree since a few weeks, however I never had the courage
> to post it publically because I didn't benchma
bal unplug
even if without the global limit.
The only reason we added the limit of I/O in flight is to be allowed to have an
huge number of requests so we can do very large reordering and merges in the
elevator with seeking I/O (4k large IO request) _but_ still we don't have to
wait to l
On Thu, Feb 22, 2001 at 11:57:00PM +0100, Andrea Arcangeli wrote:
> unsane to wait kupdate to submit 10G of ram to a single harddisk before
> unplugging on a 30G machine.
actually kupdate will unplug itself the queue but in theory it can grow the
queue still up to such level after the I/O started
On Thu, 22 Feb 2001, Andrea Arcangeli wrote:
> However if you have houndred of different queues doing I/O at the same
> time it may make a difference, but probably with tons of harddisks
> you'll also have tons of ram... In theory we could put a global limit
> on top of the the per-queue one.
On Thu, Feb 22, 2001 at 07:44:11PM -0200, Marcelo Tosatti wrote:
> The global limit on top of the per-queue limit sounds good.
Probably.
> Since you're talking about the "total_ram / 3" hardcoded value... it
> should be /proc tunable IMO. (Andi Kleen already suggested this)
Yes, IIRC Andi also
d Linus. It
is possible to find pathetic cases where the per-queue limit suffers
compared to the global one, but in reality I don't think it's worth
it. And the per-queue limits saves us the atomic updates since it's
done under the io_request_lock (or queue later, still fine) so that&#
On Sun, Feb 25, 2001 at 06:34:01PM +0100, Jens Axboe wrote:
> Any reason why you don't have a lower wake-up limit for the queue?
The watermark diff looked too high (it's 128M in current Linus's tree), but it's
probably a good idea to resurrect it with a max difference of a few full sized
requests
On Wed, 11 Apr 2001, Jon Eisenstein wrote:
> (2) Every so often, I get a non-fatal error on my screen about a
> kernel paging request error.
If it's usually the same address, we're probably dealing with
a kernel bug. If you always get different addresses, chances
are your RAM is
> > (2) Every so often, I get a non-fatal error on my screen about a
> > kernel paging request error.
>
> If it's usually the same address, we're probably dealing with
> a kernel bug. If you always get different addresses, chances
> are your RAM is broken (you
nable to eject, last error: Invalid argument
vanilla linux 2.2.19 SMP (2x700 Mhz Pentium III Coppermine, 512 MB)
SuSE 7.1 distro
output from scsi_inquiry /dev/sr1:
PLEXTOR CD-R PX-W1210S 1.01, byte_7=0x18
in /var/log/messages:
kernel: sr1: CDROM (ioctl) reports ILLEGAL REQUEST.
Can I som
fs: server student not responding, still
trying
Nov 10 04:33:17 spc81 kernel: nfs: server student OK
Nov 10 04:34:59 spc81 kernel: nfs: server student not responding, still
trying
Nov 10 04:35:04 spc81 kernel: nfs: task 20823 can't get a request slot
Nov 10 04:35:35 spc81 kernel: nfs: server st
spc81 kernel: nfs: task 20457 can't get a request slot
> Nov 10 04:46:00 spc81 kernel: nfs: server student OK
One four second one here
> We have changed the NIC on this server to 3Com 3c90x for no change in status.
> Clients are using CNETPro120 200 and Intel eepro100
If samba is ok
Hi guys,
I wanted to give you a preview of the CPUID revision patch; it is not
100% ready yet in that (a) it still has a bunch of debugging printk() and
(b) I haven't ported over mtrr.c yet.
This code took a lot longer to write than I had expected, mostly because
I kept running into various form
but EVERY TIME shut my machine down, I always get the following message,
just after
>the line "stopping all md devices":
I also used to get the same messages on my celeron machine, but after i
disabled the support of RAID in kernel, it started working nicely.
I don't know the reason.
regards,
Ani
> By the evidence that we have gathered it seems that the Server is not
> taxed too much as samba users are getting files OK etc. The can't get
> request slot is plaguing many others in different ways. It looks like
> an NFS issue. How can this be proven? Then we can work
Alan,
student:/susr/ /usr
nfs defaults,rsize=1024,wsize=1024
0 0
Thanks
Graham Jordan
Alan Cox wrote:
> By the evidence that we have gathered it seems
that the Server is not
> taxed too much as samba users are getting files OK etc. The
can't ge
On Sun, Jan 21 2001, Gregory T. Norris wrote:
> When playing audio CDs under kernel 2.4.0, syslog is showing the
> following message repeatedly:
>
> sr0: CDROM (ioctl) reports ILLEGAL REQUEST.
>
> The command line utility cdplay seems to only cause this occasionally,
>
Hello,
I'm working at a customer site with custom hardware. The 2.4.0 series
kernel almost works out of the box, but the machine has 52 PCI busses.
Plans are to produce a 4-way box which would have over 80 PCI busses. The
file include/asm-i386/mpspec.h allocates space for 32 busses in the
On Wed, Jan 31, 2001 at 03:38:55PM -0500, George wrote:
> It's somewhat annoying that by choosing SMP NR_CPUS goes to 32 when I know
> I only have (and ever will have) 2 in this machine. Don't make busses have
> the same assumptions that just waste memory.
It's just sad that bumping to NR_CPUS
Hi, list
In ll_rw_block.c, before calling block device specific request function
( i mean do_hd_request, do_ftl_request, ... ) the io_request_lock is
locking, and all interrupts are disabling. I know, that request handler
routine have to be atomic, but when we read data from a flash device
This is a proposal for an attribution metadata system in the Linux kernel
sources. The goal of the system is to make it easy for people reading
any given piece of code to identify the responsible maintainer. The motivation
for this proposal is that the present system, a single top-level MAINTAI
TIA
-- Hans.
---[ OOPS1 ]--
ksymoops 2.3.4 on i686 2.4.0-test9. Options used
-v /usr/src/linux/vmlinux (specified)
-k ./ksyms (specified)
-l ./modules (specified)
-o /lib/modules/2.4.0-test9 (specified)
-m /usr/src/linux/System.map (specified)
Unable to handle kernel paging re
rnels? It sounds like a very
odd request from someone with a linuxcare.com email address. I would think that
you'd WANT to provide patched kernels so that the customer can keep paying you
(until they learn how to use a text editor, at which point they can patch the
kernel themselves!!!)
--
Timu
Christopher Neufeld wrote:
> The only patch
> which has to be applied to make Linux run stably on these systems is to
> increase that limit. Would it be possible to bump it up to 128, or even
> 256, in later 2.4.* kernel releases? That would allow this customer to
> work with an unpatched kern
In article <[EMAIL PROTECTED]> you wrote:
> 256, in later 2.4.* kernel releases? That would allow this customer to
> work with an unpatched kernel, at the cost of an additional 3.5 kB of
> variables in the kernel.
Don't think this is fairly common. So especially since I consider that kind of
har
In article <[EMAIL PROTECTED]> you wrote:
> I guess the cleanest solution would be to allow variable setting of the
> maximum number of PCI busses in the config file, similar to the
> CONFIG_UNIX98_PTY_COUNT setting, so that "exotic" users with 32+ PCI
> busses can boost the standard value accordi
nal Message -
From: "Timur Tabi" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 30, 2001 18:36
Subject: Re: Request: increase in PCI bus limit
> ** Reply to message from Christopher Neufeld <[EMAIL PROTECTED]> on
Tue, 30
> Jan 2001 16:08:32
[Bernd Eckenfels]
> May even decrease the kernel for systems < 4 busses.
Be careful, though. Users may set this thinking "I have a generic
system with only one PCI bus" without realizing that AGP, cardbus and
some motherboard devices are all counted. Pad the CONFIG option by
about 4 busses and
"Udo A. Steinberg" wrote:
>
> Christopher Neufeld wrote:
>
> > The only patch
> > which has to be applied to make Linux run stably on these systems is to
> > increase that limit. Would it be possible to bump it up to 128, or even
> > 256, in later 2.4.* kernel releases? That would allow this
re you know it, the
> kernel is 200KB larger.
>
> Besides, why is your client afraid of patched kernels? It sounds like a very
> odd request from someone with a linuxcare.com email address. I would think that
> you'd WANT to provide patched kernels so that the customer can keep
>
>I'm working at a customer site with custom hardware. The 2.4.0 series
> kernel almost works out of the box, but the machine has 52 PCI busses.
> Plans are to produce a 4-way box which would have over 80 PCI busses. The
> file include/asm-i386/mpspec.h allocates space for 32 busses in th
From: Timur Tabi <[EMAIL PROTECTED]>
>
>Besides, why is your client afraid of patched kernels? It sounds like a very
>odd request from someone with a linuxcare.com email address. I would think that
>you'd WANT to provide patched kernels so that the customer can keep
On Wed, 31 Jan 2001, Peter Samuelson wrote:
>[Bernd Eckenfels]
>> May even decrease the kernel for systems < 4 busses.
>
>Be careful, though. Users may set this thinking "I have a generic
>system with only one PCI bus" without realizing that AGP, cardbus and
>some motherboard devices are all cou
On Wed, 31 Jan 2001, George wrote:
>
> If someone says 1 bus, give them one bus.
>
> Just make the description say:
> Add 1 for every PCI
> Add 1 for every AGP
> Add 1 for every CardBus
> Also account for anything else funny in the system.
>
> Then panic on boot if they're wrong (sort of
On Wed, 31 Jan 2001, Scott Laird wrote:
> Where do cards with PCI-PCI bridges, like multiport PCI ethernet cards,
> fit into this? I can easily add 3 or 4 extra busses into a box just by
> grabbing a couple extra Intel dual-port Ethernet cards.
I loaded a PC with quad-tulip cards once and the re
depends on the network card. The adaptecs have one. the Obsidion X16 and
X24 have them. Many dual channel SCSI cards use them, and even some nicer
motherboards have them onboard. I would like to recommend autodetection
at boot, but I'm assuming that someone has looked into it and determined
it
On Wed, 31 Jan 2001, Scott Laird wrote:
> On Wed, 31 Jan 2001, George wrote:
> > Also account for anything else funny in the system.
> >
> > Then panic on boot if they're wrong (sort of like processor type).
>
> Where do cards with PCI-PCI bridges, like multiport PCI ethernet cards,
> fit into
pagin request seems to happen always at the
virtual address 53565755, if it can help...
I attach the very first lines of the log and the gzipped full
file. I was unable to compile the ksymoops because it does not
find bfd.h.
Can someone suggest me where to look for a solution? Sorry, I'm a
novi
/System.map (specified)
Unable to handle kernel paging request at virtual address 9fac
*pde =
CPU:1
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: ebx: c01071c0 ecx: c1228000 edx: c1228000
esi: c1228000 edi: c01071c0 ebp
Hi, I would like to know whether following limits are right for kernel
2.4.x:
Max. N. of CPU: 32 (SMP)
Max. CPU speed: > 2 Ghz (up to ?)
Max. RAM size: 64 GB (any slowness accessing RAM over 4 GB
with
Hello, today I got an Oops in 2.4.4-ac6, X crashed and gdm restarted, my
system is a dual 2x200MMX, 96Mb, Voodoo 3 2000pci XFree 4.0.3, no drm.
The firsts bits are the output of ksymoops, and the last ones are the
ones in my /var/log/messages.
Unable to handle kernel paging request at virtual
On Fri, May 25 2001, Alexandr Andreev wrote:
> Hi, list
> In ll_rw_block.c, before calling block device specific request function
> ( i mean do_hd_request, do_ftl_request, ... ) the io_request_lock is
> locking, and all interrupts are disabling. I know, that request handler
>
Jens Axboe wrote
>
>Even with dropping io_request_lock, it's not recommended to sleep inside
>the request_fn. WIth plugging, you are basically preventing the other
>plugged queues from being run until you return.
>
>You could use a timer or similar to call you on a specified timeout
>instead.
>
D
On Sat, Apr 21, 2001 at 11:49:42AM -0400, Eric S. Raymond wrote:
...
> If this proposal meets with approval, I am willing to do three things:
Sounds good for me.
>
> 1. Generate a patch to distribute the information presently in the
>MAINTAINERS file into map blocks and %Map files.
>
> 2.
Henning P. Schmiedehausen <[EMAIL PROTECTED]> ecrit :
[...]
> What's wrong with:
>
[xml]
I'd rather use c/etags.
Seriously, it won't create maintainers automagically.
I don't see the benefit.
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Sat, Apr 21, 2001 at 04:38:59PM +, Henning P. Schmiedehausen wrote:
> What's wrong with:
[...xml horror deleted...]
The myriads of external tools/libraries you will need (and that usually do not
work properly, spewing out undecryptable error messages, or are currently not
installed on yo
Eric S. Raymond writes:
> This is a proposal for an attribution metadata system in the Linux
> kernel sources. The goal of the system is to make it easy for
> people reading any given piece of code to identify the responsible
> maintainer. The motivation for this proposal is that the present
>
Albert D. Cahalan <[EMAIL PROTECTED]>:
> Eric S. Raymond writes:
>
> > This is a proposal for an attribution metadata system in the Linux
> > kernel sources. The goal of the system is to make it easy for
> > people reading any given piece of code to identify the responsible
> > maintainer. The
On Sat, 21 Apr 2001, Albert D. Cahalan wrote:
> Eric S. Raymond writes:
>
> > This is a proposal for an attribution metadata system in the Linux
> > kernel sources. The goal of the system is to make it easy for
> > people reading any given piece of code to identify the responsible
> > maintai
Alexander Viro <[EMAIL PROTECTED]>:
> The real problem is that large part of the kernel has no permanent
> maintainers. Which makes the whole (overdesigned) idea completely moot.
One of the problems this `overdesign' can help solve is actually identifying
the parts that have semi-permanent mainta
Eric S. Raymond <[EMAIL PROTECTED]> ecrit :
[...]
> One of the problems this `overdesign' can help solve is actually identifying
> the parts that have semi-permanent maintainers, and the parts that don't.
>
> One way to use the meta-information, for example, would be to use it to
> periodically
Francois Romieu <[EMAIL PROTECTED]>:
> YN
> The kernel will perform better [ ] [*]
> Somebody will have less work [*] [ ]
Yes, anybody trying to figure out how to get a fix made.
> It's fun (TM)[*] [ ]
Fun for me. I like solvi
Hello Eric ,
On Sat, 21 Apr 2001, Albert D. Cahalan wrote:
> Eric S. Raymond writes:
> > This is a proposal for an attribution metadata system in the Linux
> > kernel sources. The goal of the system is to make it easy for
> > people reading any given piece of code to identify the respon
Eric S. Raymond <[EMAIL PROTECTED]> ecrit :
> Francois Romieu <[EMAIL PROTECTED]>:
[...]
> > Somebody will have less work [*] [ ]
>
> Yes, anybody trying to figure out how to get a fix made.
Provided it's kept up-to-date. I.e. it calls for some tools (and these
require the suggested changes
Francois Romieu <[EMAIL PROTECTED]>:
> Provided it's kept up-to-date. I.e. it calls for some tools (and these
> require the suggested changes).
Yes. I'll write the tools.
> I'll only object that imho there is no global problem here:
> * If user meets a serious problem, the maintainer will s
> Eric wants an easy way to find the owner of a CONFIG_ entry.
> True, the consensus seems to be that this isn't a particularly
> useful thing to do, but if it must be done, this seems like an
> eminently sane way to do it.
So we need a system to handle the thousand odd entries, a person to maint
On Sun, 22 Apr 2001, Russell King wrote:
> > C: CONFIG_SCSI_BLARG
> > F: drivers/scsi/blarg.c
> > F: drivers/scsi/blarg.h
> And what would:
>
> C: CONFIG_ARM
>
> tell you? Nothing that is not described in the rest of the "ARM PORT"
> entry.
True, but it would tell it to a script without interv
Russell King <[EMAIL PROTECTED]>:
> I'll grant you that it does solve the "who owns a CONFIG_ symbol", but
> that is only one small problem - there's the bigger problem as to who
> owns each line of code. Are we going to start labelling each source
> code line as well?
Per-file or per-directory
Matthew Kirkwood <[EMAIL PROTECTED]>:
> Eric wants an easy way to find the owner of a CONFIG_ entry.
No, I want much more than that.
--
http://www.tuxedo.org/~esr/">Eric S. Raymond
"This country, with its institutions, belongs to the people who
inhabit it. Whenever they shall gr
Russell King <[EMAIL PROTECTED]>:
> Could that be because there _is no_ maintainer for the config.in files?
> Therefore, splitting up the MAINTAINERS file achieves nothing.
It's not just splitting up the file that I'm advocating. However, as I
said, I'm going to stop arguing and demonstrate,
--
Alexander Viro <[EMAIL PROTECTED]>:
> Eric, it would save everyone a lot of time if you actually cared to
> pull your head out of your... theoretical constructions and spent
> some efforts figuring out how the things really work.
I've had my nose rubbed in how things really work. That's why I wa
> "Eric" == Eric S Raymond <[EMAIL PROTECTED]> writes:
Eric> Alan Cox <[EMAIL PROTECTED]>:
>> I actually prefer MAINTAINERS because it breaks things down by area
>> and reflects the actual maintainership and areas covered. Something
>> that per file does not
Eric> Instead of arguing this poi
[EMAIL PROTECTED] said:
> I've had my nose rubbed in how things really work. That's why I want
> to fix the things that are broken about how things really work.
Then you're going to conjure up maintainers for the code which is currently
orphaned?
For most stuff, the way to co-ordinate global
David Woodhouse <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] said:
> > I've had my nose rubbed in how things really work. That's why I want
> > to fix the things that are broken about how things really work.
>
> Then you're going to conjure up maintainers for the code which is currently
> orphaned
On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> Alexander Viro <[EMAIL PROTECTED]>:
> > Eric, it would save everyone a lot of time if you actually cared to
> > pull your head out of your... theoretical constructions and spent
> > some efforts figuring out how the things really work.
>
> I've had
On Sun, Apr 22, 2001 at 02:42:29PM +0100, Matthew Kirkwood wrote:
> On Sun, 22 Apr 2001, Russell King wrote:
> > And what would:
> >
> > C: CONFIG_ARM
> >
> > tell you? Nothing that is not described in the rest of the "ARM PORT"
> > entry.
>
> True, but it would tell it to a script without inter
Alexander Viro <[EMAIL PROTECTED]>:
> Sigh... Would these broken things, by any chance, be "my grand ideas are
> not met with applause"?
Nope. Not at all. Stay tuned, because I'll explain.
And before you write me off as one of the $BIGNUM clueless
visionaries, you might do well to remember tha
On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> David Woodhouse <[EMAIL PROTECTED]>:
> > [EMAIL PROTECTED] said:
> > > I've had my nose rubbed in how things really work. That's why I want
> > > to fix the things that are broken about how things really work.
> >
> > Then you're going to conjure up
On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> And before you write me off as one of the $BIGNUM clueless
> visionaries, you might do well to remember that I actually *have*
> radically changed the world lkml operates in. At least twice.
Let me see ...
1) fetchmail, allowing dialup users to get
Rik van Riel <[EMAIL PROTECTED]>:
> Let me see ...
>
> 1) fetchmail, allowing dialup users to get lkml
> 2) getting snake.thyrsus.com out of ORBS and starting
>the mother of all lkml threads
>
> Did I forget anything ?
Yes, Rik, you did. It's not `snake', it's `snark'.
:-)
--
> And before you write me off as one of the $BIGNUM clueless
> visionaries, you might do well to remember that I actually *have*
> radically changed the world lkml operates in. At least twice.
I must have missed them 8)
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> Alexander Viro <[EMAIL PROTECTED]>:
> > Sigh... Would these broken things, by any chance, be "my grand ideas are
> > not met with applause"?
>
> Nope. Not at all. Stay tuned, because I'll explain.
>
> And before you write me off as one of the $B
> * you've ignored the robustness of design behind the UNIX kernel.
> These beasts keep going without falling apart even after serious injuries.
Do you mean design or operation? In fact UNIX design has a number of
serious errors/problems, we just have gotten accustomed to it so much
that we
"Eric S. Raymond" <[EMAIL PROTECTED]> said:
> Alexander Viro <[EMAIL PROTECTED]>:
> > Eric, it would save everyone a lot of time if you actually cared to
> > pull your head out of your... theoretical constructions and spent
> > some efforts figuring out how the things really work.
>
> I've had my
Horst von Brand <[EMAIL PROTECTED]>:
> Then explain to everybody here in a language they'll understand _what_ is
> wrong and _why_. Then propose a solution.
I'm on it. You'll see the results fairly shortly.
--
http://www.tuxedo.org/~esr/">Eric S. Raymond
Strict gun laws are abo
On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> Horst von Brand <[EMAIL PROTECTED]>:
> > Then explain to everybody here in a language they'll understand _what_ is
> > wrong and _why_. Then propose a solution.
>
> I'm on it. You'll see the results fairly shortly.
"Here, have this solution. I'm su
On Sun, Apr 22, 2001 at 01:49:16PM -0300, Rik van Riel wrote:
> On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> > David Woodhouse <[EMAIL PROTECTED]>:
> > > Then you're going to conjure up maintainers for the code which is currently
> > > orphaned?
> >
> > That's a *really* hard problem. I don't
Roger Gammans <[EMAIL PROTECTED]>:
> It's entirley possible the problem will solve itself
> when/if people like myself who hang around the edge of
> kernel dev , find their favourite piece of kernel has
> no maintainer - and volunteer.
>
> So Eric solution may get new maintainers to appear for
Roger Gammans <[EMAIL PROTECTED]> said:
[...]
> It's entirley possible the problem will solve itself
> when/if people like myself who hang around the edge of
> kernel dev , find their favourite piece of kernel has
> no maintainer - and volunteer.
What stops you right now from to trying to fi
On Tue, Apr 24, 2001 at 09:14:41AM -0400, Horst von Brand wrote:
> Roger Gammans <[EMAIL PROTECTED]> said:
>
> People who want to take over "because it is s00 k3w1 to be a maintainer"
> with no real interest in the code, just in the fact that it is orphaned...
No. People who want to give somethi
On Sat, 21 Apr 2001, Albert D. Cahalan wrote:
> Eric S. Raymond writes:
>
> > This is a proposal for an attribution metadata system in the Linux
> > kernel sources. The goal of the system is to make it easy for
> > people reading any given piece of code to identify the responsible
> > maintain
Roger Gammans <[EMAIL PROTECTED]>:
> On Tue, Apr 24, 2001 at 09:14:41AM -0400, Horst von Brand wrote:
> > People who want to take over "because it is s00 k3w1 to be a maintainer"
> > with no real interest in the code, just in the fact that it is orphaned...
>
> No. People who want to give somethi
Hi!
> > The real problem is that large part of the kernel has no permanent
> > maintainers. Which makes the whole (overdesigned) idea completely moot.
>
> One of the problems this
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTEC
1 - 100 of 184 matches
Mail list logo
