Path: supernews.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!
look.ca!newshub2.rdc1.sfba.home.com!news.home.com!newshub1-work.home.com!
gehenna.pell.portland.or.us!nntp-server.caltech.edu!nntp-server.caltech.edu!
mail2news96
Newsgroups: mlist.linux.kernel
Date: Thu, 4 Jan 2001 16:01:22 -0800 (PST)
From: Linus Torvalds <torva...@transmeta.com>
X-To: Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: And oh, btw..
Message-ID:
<linux.kernel.Pine.LNX.4.10.10101041546120.1153-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved: n...@nntp-server.caltech.edu
Lines: 167
In a move unanimously hailed by the trade press and industry analysts as
being a sure sign of incipient braindamage, Linus Torvalds (also known as
the "father of Linux" or, more commonly, as "mush-for-brains") decided
that enough is enough, and that things don't get better from having the
same people test it over and over again. In short, 2.4.0 is out there.
Anxiously awaited for the last too many months, 2.4.0 brings to the table
many improvements, none of which come to mind to the exhausted release
manager right now. "It's better", was the only printable quote. Pressed
for details, Linus bared his teeth and hissed at reporters, most of which
suddenly remembered that they'd rather cover "Home and Gardening" than the
IT industry anyway.
Anyway, have fun. And don't bother reporting any bugs for the next few
days. I won't care anyway.
Linus
-----
Changes since the prerelease:
David Mosberger:
- ia64 update
NIIBE Yutaka:
- SuperH update
Karsten Keil:
- re-do ISDN certification checksums
Tim Waugh:
- VIA DMA=255 bug fix
- IEEE 1284 config message
- IEEE 1284 probe fix
- missing printk argument
- ppa driver reconnect timeout tweak
Matthew Dharm:
- USB hotplug fix - specify exactly which fields to match on
Rik Faith:
- drm driver synch with XFree86-4.0.2
- oops: we synched a bit too far. Backsync to the _real_ 4.0.2 level.
Geert Uytterhoeven:
- m68k updates
- Amiga resource management updates
- m68k loops_per_jiffy updates
- m68k keyboard delay/repeat
- m68k SCSI updates
- m68k exported symbols update
- m68k Lance updates
- fbdev config fixes
- Amiga Ethernet updates
- Amiga builtin serial updates
- m68k config updates
- m68k __ashldi3
- Amiga Y2K fixes (a bit late, wouldn't you say?)
- Misc m68k updates
- fbdev init order fix
- Mac/m68k IDE updates
- m68k asm constraint fixes
Marc ZYNGIER:
- SMP lockup with IrDA
David Huggins-Daines:
- remove extra "remove_wait_queue()" in drivers/sound/cs46xx.c. It
would lock up badly on nonblocking reads.
Matti Aarnio:
- teach tulip driver about media types 5 and 6
- fix ATM LANE driver linkage issues
- fix DECNET driver unload time cleanup
- fix pointer comparison type warning
- get rid of excessive '##' token pasting that newer gcc's warn about
Keith Owens:
- fix drm Makefile to not use the same objects built-in and in a module
- update modutils version numbers to match 2.4.x kernel
Russell Kroll:
- fix radio card drivers that got the request_region sense inverted
Rich Baum:
- Remove compile warnings with newer gcc versions for lables with no
expression at the end of a compound block
Andreas Franck:
- Make the x86 semaphore implementation compile properly with current
gcc snapshots. Newer gcc's will release the memory allocated for a
data structure too early if only the pointer to that memory is passed
to an asm.
Alan Cox:
- pcxx.c: make it compile ("mseconds" -> "msec")
- Documentation: fix typos/glitches
- CCISS bugfix
- riscom setup bugfix
- toshoboe and wavelan overlarge udelay
- clean/bugfixes amateur radio
- yam/mkiss build fix
- old tulip chips driver update
- sg driver unchecked scsi_allocate_request
- i810 audio fix
- RTC CMOS locking fixes
David Miller:
- update sparc to "loops_per_jiffy"
- sparc32 uses ix86-like semaphores now
- missing flush_dcache_page in kiovec support layer
- netfilter: use "long" for values operated on using bitops
- more empty statement warning fixes
- LVM 32-bit compat ioctl checks
- Include param.h into Sparc64's delay.h to get HZ define
- Fix Zilog serial port speed setting checks
Neil Brown:
- raid5 missing unlock on degraded array
- knfsd inode semaphore: get it early
Johannes Erdfelt:
- USB oops on unplug fix for dc2xx and ov511 driver
Mitch Davis:
- prettier printout of IDE registers if < 0x100
Richard Henderson:
- alpha "loops_per_jiffy" update
Oliver Neukum:
- fix for SMP race in v4l open()
Andreas Bombe:
- Makefile fix for ieee1394
- IEEE 1394 up-to-date
Kai Germaschewski:
- fix ISDN diversion services name-clash (and crash)
Andre Hedrick:
- IDE chipset update, DVD-RAM update
Rik van Riel:
- don't deactivate partially written pages in generic_file_write
Michael Lang:
- ibmmca upgrade: docs and small bugs
Marko Kreen:
- big udelay's in fb drivers. Fix.
Me:
- drivers/net/rcpci45.c: make it compile ("rcpci_pci_table" ->
"rcpci45_pci_table")
- mark_buffer_dirty() only does a "balance_dirty()" if the
buffer was previously clean.
- mm sanity: never decrement page count past zero
- no synchronous bdflush wait
- mm VM scanning and exit race cleanup: mmlist_lock
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
Path: supernews.google.com!sn-xit-02!supernews.com!news.tele.dk!
128.230.129.106!news.maxwell.syr.edu!newshub2.home.com!news.home.com!
newshub1-work.home.com!gehenna.pell.portland.or.us!nntp-server.caltech.edu!
nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Date: Thu, 4 Jan 2001 21:06:34 -0200 (BRST)
From: Marcelo Tosatti <marc...@conectiva.com.br>
X-To: Linus Torvalds <torva...@transmeta.com>
X-cc: Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: Re: And oh, btw..
Message-ID:
<linux.kernel.Pine.LNX.4.21.0101042050421.1453-100000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved: n...@nntp-server.caltech.edu
Lines: 52
On Thu, 4 Jan 2001, Linus Torvalds wrote:
>
> In a move unanimously hailed by the trade press and industry analysts as
> being a sure sign of incipient braindamage, Linus Torvalds (also known as
> the "father of Linux" or, more commonly, as "mush-for-brains") decided
> that enough is enough, and that things don't get better from having the
> same people test it over and over again. In short, 2.4.0 is out there.
I have 1 patch which has not been answered and I still dont know if you
want it only for 2.5.
I dunno if you've read the swap write clustering patch I sent sometime
ago. Basically it changes swap_writepage to search for physically
contiguous dirty swap cache pages and if it finds them, it writes all of
them in a cluster. The nice thing is that we save disk seek time which are
well known to be nasty.
I've received one report of 13% improvement with dbench and reiserfs, and
on my own benchmarks I've seen improvements of 15% successful write merges
on the swap device (using SAR patch to measure).
I'm not sure if its a intrusive change now with 2.4.0 released. What do
you think?
----
Another problem which we have now is swap-in readahead. Currently swapin
readahead is done on a physical device basis.
The problem is that physical swap pages are not necessarily virtually
contiguous. So what can happen (and is happening) is that we readahead
pages which are not going to be used soon.
What we probably want to do is only readahead swap pages if they really
are virtually contiguous too, to avoid wasting memory and IO processing
with "guesses" about the swap device.
I have a patch which does that (I'm still searching for an SMP deadlock
but I'm looking at it). It walks the virtually contiguous pte's starting
from the one which was faulted, and then it only cluster them if they are
virtually contiguous too.
I'll send the patch as soon as I figured out the deadlock and stress it a
more.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
Path: supernews.google.com!sn-xit-02!supernews.com!news.tele.dk!
128.230.129.106!news.maxwell.syr.edu!newshub2.home.com!news.home.com!
newshub1-work.home.com!gehenna.pell.portland.or.us!nntp-server.caltech.edu!
nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Date: Thu, 4 Jan 2001 17:11:00 -0800 (PST)
From: Linus Torvalds <torva...@transmeta.com>
X-To: Marcelo Tosatti <marc...@conectiva.com.br>
X-cc: Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: Re: And oh, btw..
Message-ID:
<linux.kernel.Pine.LNX.4.10.10101041709110.1249-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved: n...@nntp-server.caltech.edu
Lines: 21
On Thu, 4 Jan 2001, Marcelo Tosatti wrote:
>
> I have 1 patch which has not been answered and I still dont know if you
> want it only for 2.5.
The swap clustering looks ok, but it also looked like something I could
safely delay until a bit later in the 2.4.x series. Basically, the
PageDirty handling is new enough that I didn't want to add any other
wrinkles on top of it, even if they looked clean..
Life does not end at 2.4.0. Think o fit more as a "no more excuses"
release.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
Path: supernews.google.com!sn-xit-02!supernews.com!news-x.support.nl!
newsfeeds.belnet.be!news.belnet.be!news.tele.dk!134.222.94.5!
npeer.kpnqwest.net!EU.net!Norway.EU.net!uninett.no!ntnu.no!uio.no!
hrotti.ifi.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
X-Authentication-Warning: palladium.transmeta.com:
mail set sender to n...@transmeta.com using -f
To: linux-ker...@vger.kernel.org
From: torva...@transmeta.com (Linus Torvalds)
Subject: Linux-2.4.x patch submission policy
Original-Date: 6 Jan 2001 10:17:02 -0800
Original-Message-ID: <937neu$p95$1@penguin.transmeta.com>
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Transmeta Corporation
Date: Sat, 6 Jan 2001 18:18:28 GMT
Message-ID: <fa.igetlbv.c2uj87@ifi.uio.no>
Lines: 94
I thought I'd mention the policy for 2.4.x patches so that nobody gets
confused about these things. In some cases people seem to think that
"since 2.4.x is out now, we can relax, go party, and generally goof
off".
Not so.
The linux kernel has had an interesting release pattern: usually the .0
release was actually fairly good (there's almost always _something_
stupid, but on the whole not really horrible). And every single time so
far, .1 has been worse. It usually takes until something like .5 until
it has caught up and surpassed the stability of .0 again.
Why? Because there are a lot of pent-up patches waiting for inclusion,
that didn't get through the "we need to get a release out, that patch
can wait" filter. So early on in the stable tree, some of those patches
make it. And it turns out to be a bad idea.
In an effort to avoid this mess this time, I have two guidelines:
- I've basically thrown away all patches sent to me so far, and I will
continue to do so at least over the weekend. I'm not going to bother
thinking about patches for a few days.
- In order for a patch to be accepted, it needs to be accompanied by
some pretty strong arguments for the fact that not only is it really
fixing bugs, but that those bugs are _serious_ and can cause real
problems.
Obviously, the size of the patch matters too: if you can make an
obvious fix in 5 lines, do it. Don't try to make a clean fix that
fixes the problem the clever way in 150 lines.
In short, releasing 2.4.0 does not open up the floor to just about
anything. In fact, to some degree it will probably make patches _less_
likely to be accepted than before, at least for a while. I want to be
absolutely convicned that the basic 2.4.x infrastructure is solid as a
rock before starting to accept more involved patches.
Right now my ChangeLog looks like this:
- Don't drop a megabyte off the old-style memory size detection
- remember to UnlockPage() in ramfs_writepage()
- 3c59x driver update from Andrew Morton
The first two are true one-liners that have already bitten some people
(not what I'd call a showstopper, but trivially fixable stuff that are
just thinkos). The third one looks like a real fix for some rather
common hardware that could do bad things without it.
Now, I'm sure that ChangeLog will grow. There's the apparent fbcon bug
with MTRR handling that looks like a prime candidate already, and I'll
have people asking me for many many more. But basically what I'm asking
people for is that before you send me a patch, ask yourself whether it
absolutely HAS to happen now, or whether it could wait another month.
Another way of putting it: if you have a patch, ask yourself what would
happen if it got left off the next RedHat/SuSE/Debian/Turbo/whatever
distribution CD. Would it really be a big problem? If not, then I'd
rather spend the time _really_ beating on the patches that _would_ be a
big issue. Things like security (_especially_ remote attacks), outright
crashes, or just totally unusable systems because it can't see the
harddisk.
We'll all be happier if my ChangeLog is short and sweet, and if a 2.4.1
(tomorrow, in a week, in two, in a month, depending on what comes up)
actually ends up being _better_ than 2.4.0. That would be a good new
tradition to start.
And before you even bother asking about 2.5.x: it won't be opened until
I feel happy to pass on 2.4.x to somebody else (hopefully Alan Cox
doesn't feel burnt out and wants to continue to carry the torch and
feels ok with leaving 2.2.x behind by then).
Historically, that's been at least a few months. In the 2.2.x series,
2.3.0 was the same as 2.2.8 with just the version changed - and it came
out in May, almost four months after 2.2.0. In the 2.0.x series, 2.1.x
was based off 2.0.21, four and a half months after 2.0.0.
Yes, I know this is boring, and all I'm asking is for people to not make
it any harder for me than they have to. Think twice before sending me a
patch, and when you _do_ send me a patch, try to think like a release
manager and explain to me why the patch really makes sense to apply now.
In short, I'm hoping for a fairly boring next few months. The more
boring, the better.
Thanks,
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
Path: supernews.google.com!sn-xit-02!supernews.com!bignews.mediaways.net!
newsfeeds.belnet.be!news.belnet.be!newsfeed.direct.ca!look.ca!
newshub2.rdc1.sfba.home.com!news.home.com!newshub1-work.home.com!
gehenna.pell.portland.or.us!nntp-server.caltech.edu!nntp-server.caltech.edu!
mail2news96
Newsgroups: mlist.linux.kernel
Subject: Re: Linux-2.4.x patch submission policy
X-To: torva...@transmeta.com (Linus Torvalds)
Date: Sat, 6 Jan 2001 19:33:22 +0000 (GMT)
X-Cc: linux-ker...@vger.kernel.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <linux.kernel.E14Ez5g-0001QJ-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Approved: n...@nntp-server.caltech.edu
Lines: 20
> rather spend the time _really_ beating on the patches that _would_ be a
> big issue. Things like security (_especially_ remote attacks), outright
> crashes, or just totally unusable systems because it can't see the
> harddisk.
In which case the priority should be fixing all the broken LFS support.
> Yes, I know this is boring, and all I'm asking is for people to not make
> it any harder for me than they have to. Think twice before sending me a
> patch, and when you _do_ send me a patch, try to think like a release
> manager and explain to me why the patch really makes sense to apply now.
Think of -ac as a way to get patches you need that everyone else might not
need yet, and a way to filter stuff. Im happy to take sane stuff Linus doesn't
(within reason) and propogate it on as (or more to the point if) it proves sane
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
Path: supernews.google.com!sn-xit-02!supernews.com!sienna.impulse.net!
newsxfer.interpacket.net!cyclone-sjo1.usenetserver.com!
news-out.usenetserver.com!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.home.com!gehenna.pell.portland.or.us!nntp-server.caltech.edu!
nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Date: Sun, 7 Jan 2001 14:37:47 -0200 (BRDT)
From: Rik van Riel <r...@conectiva.com.br>
X-To: Linus Torvalds <torva...@transmeta.com>
X-cc: linux-ker...@vger.kernel.org
Subject: Re: Linux-2.4.x patch submission policy
Message-ID:
<linux.kernel.Pine.LNX.4.21.0101071434370.21675-100000@duckman.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved: n...@nntp-server.caltech.edu
Lines: 33
On 6 Jan 2001, Linus Torvalds wrote:
> In short, releasing 2.4.0 does not open up the floor to just
> about anything. In fact, to some degree it will probably make
> patches _less_ likely to be accepted than before, at least for a
> while.
I think this is an excellent idea. To help with this I'll
gather all non-bug VM patches and combine them into a
special big patch periodically.
Once we are sure 2.4 is stable for just about anybody I
will submit some of the really trivial enhancements for
inclusion; all non-trivial patches I will maintain in a
VM bigpatch, which will be submitted for inclusion around
2.5.0 and should provide one easy patch for those distribution
vendors who think 2.4 VM performance isn't good enough for
them ;)
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to loose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
|