The search engine is back. Kir Kolyshkin and Alexander F Avdonkin have graciously set up an aspseek engine to provide searching capabilities for this site. Aspseek is a company that releases its search engine under the GPL. They have promised that the only banner ads on the search pages will be for their own company, which seems fitting.
Many thanks to Kir and Alexander for doing all the hard work. Thanks, folks!
Jeremy Elgar asked if there were any problems with using the pre-emptive
patches alongside the XFS patches. Bill Dunn thought Jeremy might have to do
a little massaging to get the patches to play nice together, which he found
to be common with multiply-patched kernels. But Michael Dunsky and Anuradha
Ratnaweera reported that they'd been running kernels with those patches
for some time, with no problems, and Robert Love added for good measure,
The only problem reported was a compile error,
which Keith Owens merged a fix for. If you do have problems, report them
and perhaps we can help.
In the course of asking a different question, Gerard Roudier asked
Marcelo Tosatti, By the way, I missed the
postings that made you the maintainer of 2.4 kernel neither saw any comments
from Alan about. I am sure that you will do the best you can and will do
a very good work, but I feel a bit frustrated not to know the reasons of
this decision. If you can point me to the corresponding articles, I will
be very interested in.
Christophe Barbe pointed Gerard to an Advogato entry from Alan
Cox, but Gerard replied that this satisfied him, but Mike Fedyk said,
This doesn't really show *why* he was chosen.
Marcello hasn't gotten much press in the past.
He added, Yes, it does look like a big change from the outside.
Even for LKML readers ;)
Elsewhere, Marcelo also replied to Gerard's initial question, pointing to the
Advogato entry and saying, Well, basically, it
seems Alan got tired of maintenance... :)
Someone encountered some compiler errors while trying to test 2.5.1-pre2, and Linus Torvalds replied:
Yes.
The next-generation block-layer support is starting to be merged into the 2.5.x tree, and that breaks old drivers that haven't been updated to the new locking.
In particular, there used to be _one_ lock for the whole IO system ("io_request_lock"), and these days it's a per-block-queue lock.
In many cases the fix is as simple as just replacing the "io_request_lock" with "host->host_lock", but sometimes this is complicated by the need to pass the right data structures down far enough..
Many drivers have been converted (ie IDE, symbios, aic7xxx etc), but many more have not (especially older SCSI drivers, in your case it's the classic aha1542).
It will probably take some time until most drivers have been converted. Tested patches are more than welcome.
Christoph Hellwig suggested that, as long as they were breaking SCSI,
he'd be happy to submit a patch to remove the
old-style (2.0) scsi error handling completly, forcing drivers still using
it to be fixed? Early 2.5 looks like a good time for that to me..
Robert Love also supported this idea, and Linus said, I agree, that sounds like a good thing, and as I consider the block
layer to be one of the major pushes for 2.5.x it makes perfect sense.
Christoph posted the patch, and he, Andreas Dilger, and Martin Dalecki had
a brief technical discussion about it.
Paul Mackerras also replied to Linus, asking, Is there a description of the new block layer and
its interface to block device drivers somewhere? That would be
helpful, since Ben Herrenschmidt and I are going to have to convert
several powermac-specific drivers.
Daniel Phillips gave a link to http://lse.sourceforge.net/io/bionotes.txt,
and Linus confirmed that this was the doc to go by. Various folks discussed
the ideas in that doc.
James Simmons posted a patch against 2.5.0 and announced happily:
This is my first public release of the new api of the framebuffer layer. The basic goal is to remove all the excess duplicate code and to place all the console related code into fbcon.c. The second goal to allow the framebuffer layer to exist without the console system. On embedded devices that lack a keyboard it makes no sense plus it takes up valiable space to have the VT system compiled in. The 3rd and finally goal is to allow fbdev driver writing to be easy and yet flexiable.
This patch shows 3 basic things I like to change.
- Universal cursor api. This allows the fbcon layer to not be required hooks to program the cursor for every type of card avaliable. This allows a seperation of fbdev and fbcon.
- Move from framebuffer base to more accel engine base. This allows the complete removal of console code from the low level framebuffer drivers and we get ride of those god forsaken fbcon-cfb* files. So we end up with a huge code reducution and this encourages the driver write to write much faster fbdev drivers. Note these our the basic accels needed for the fbcon layer. They are not used by userland in anyway. It also means you have only 3 basic functions to deal with instead of the 7 of struct display_switch.
- Removal of duplicate code. Examples are the fb_cmap functions which are basically the same in every driver. So you will be seeing soon a fbgen2 that will have the same code that is duplicated over and over again in each driver.
Geert Uytterhoeven and Petr Vandrovec had some technical comments, and they all went back and forth briefly about it.
David Hansen posted a patch to remove the big kernel lock (BKL)
from a bunch of places in drivers in the 2.5 tree. He explained, Many of these patches simply remove the BKL from
the file. This causes no harm because the BKL was not really protecting
anything, anyway. Other patches try to actually fix the locking. Some do
this by making use of atomic operations with the atomic_* functions, or the
(test|set)_bit functions. Most of these patches replace uses of normal
integers which were used to keep open counts in the drivers. In other some
cases, a spinlock was added when the atomic operations could not guarantee
proper serialization by themselves. And, in very few cases, the existing
locking was extended to protect more things. These cases are very uncommon
because locking is very uncommon in most of these drivers.
Various
folks discussed this, with the general concensus being that getting rid of
the BKL was always good.
Marcelo Tosatti announced 2.4.17-pre2. He included the changelog:
Lots of driver changes this time...
Also, I want to know if people feel any difference on interactivity under heavy IO workloads.
pre2:
- Remove userland header from bonding driver (David S. Miller)
- Create a SLAB for page tables on i386 (Christoph Hellwig)
- Unregister devices at shaper unload time (David S. Miller)
- Remove several unused variables from various places in the kernel (David S. Miller)
- Fix slab code to not blindly trust cc_data(): it may be not valid on some platforms (David S. Miller)
- Fix RTC driver bug (David S. Miller)
- SPARC 32/64 update (David S. Miller)
- W9966 V4L driver update (Jakob Jemi)
- ad1848 driver fixes (Alan Cox/Daniel T. Cobra)
- PCMCIA update (David Hinds)
- Fix PCMCIA problem with multiple PCI busses (Paul Mackerras)
- Correctly free per-process signal struct (Dave McCracken)
- IA64 PAL/signal headers cleanup (Nathan Myers)
- ymfpci driver cleanup (Pete Zaitcev)
- Change NLS "licenses" to be "GPL/BSD" instead only BSD. (Robert Love)
- Fix serial module use count (Russell King)
- Update sg to 3.1.22 (Douglas Gilbert)
- ieee1394 update (Ben Collins)
- ReiserFS fixes (Nikita Danilov)
- Update ACPI documentantion (Patrick Mochel)
- Smarter atime update (Andrew Morton)
- Correctly mark ext2 sb as dirty and sync it (Andrew Morton)
- IrDA update (Jean Tourrilhes)
- Count locked buffers at balance_dirty_state(): Helps interactivity under heavy IO workloads (Andrew Morton)
- USB update (Greg KH)
- ide-scsi locking fix (Christoph Hellwig)
Patrick Dijkkamp pointed out that Marcelo had forgotten to update the version number again, as he had last week.
Justin Wells asked if there were some way to tag kernels on kernel.org, so users could tell which releases were better than others. Mike Fedyk suggested that Justin volunteer to keep track of how good each kernel was, but Willy Tarreau said:
well, at least there's a very simple way to get valuable information : install a voting system on a web site (kernel.org...) so that people who go there to get a new kernel can also tell which kernel they're using, the approximative uptime they have, if they encountered problems, if they had to patch it to gain stability, and eventually what they do with it (io/net/desktop/all).
A further step could be to qualify recensed patches on the net in the same manner. There *are* ways to get very stable kernels even now, for a given application. Not everyone has the same needs of course, but it could help even the maintainers by giving them a more global feedback about which patches could most likely be included with low risk.
I think that if even one tenth of the LKML subscribers rank their kernels at least once a week, we'll quickly see some stable and unusable kernels.
Mike really liked that idea, and Ian Stirling put in, I've proposed in the past a more extensive version of this.
make register or similar. Which you run, and it grabs a snapshot of system
setup, optionally with comments, and sends it in to a registry. You can
then do make comment and report issues. These would vary from "it crashes",
to "my hard drive died/is dying" So we get information on systems, and some
idea on which are reliable or not.
H. Peter Anvin announced:
I have created a robot on kernel.org which makes incremental prepatches available. It looks for standard-named prepatches in the /pub/linux/kernel/v*.*/testing directories, and creates incrementals in the corresponding /pub/linux/kernel/v*.*/testing/incr directory.
For example:
hera 86 % cd /pub/linux/kernel/v2.5/testing/incr/ hera 87 % ls -l *.gz -rw-rw-r-- 1 kdist kernel 177158 Nov 27 10:17 patch-2.5.1-pre1-pre2.gz -rw-rw-r-- 1 kdist kernel 102202 Nov 28 15:35 patch-2.5.1-pre2-pre3.gz -rw-rw-r-- 1 kdist kernel 52955 Nov 29 15:29 patch-2.5.1-pre3-pre4.gz -rw-rw-r-- 1 kdist kernel 53616 Nov 30 17:04 patch-2.5.1-pre4-pre5.gzThe naming and function of the patches should be obvious.
.bz2 and .sign files are available too, of course.
Several folks burst into applause, and Matt Domsch asked, Would you be interested in setting up a kdist-like list to email out
the changelog, diffstat, and incremental patch too as a product of the patch
generation script? That would increase the usefulness of comments like "Alan
- much merging" in the changelogs. Also, a script to update a web page ala
www.bzimage.org would make patch browsing really easy. I volunteer to help
if you like.
There was no reply to this, but elsewhere, Anders Peter
Fugmann suggested to H. Peter, Could you
(when you have the time) extend the system to include a patch between the
last pre version and a final version?
H. Peter replied that he'd
intended to do this but had forgotten. He whipped up the feature and added
it, and Anders replied, Thats about as
perfect as it gets.
Zwane Mwaikambo had some cleanup patches for OSS. He knew that OSS would
soon be replaced by ALSA, and asked if it was worth the trouble to continue
his OSS work. Alan Cox replied, Well if you've done
the work why not - people will be running 2.4 for a long time. The PM changes
may also be relevant to ALSA anyway.
At one point John Gluck asked if ALSA would make it into 2.4; and Jeff
Garzik said, IMHO ALSA should -never- go into 2.4.
It's fine as a patch but 2.5 is the time for big merges, and since it's
already available for 2.4 outside the kernel there shouldn't be any need
for backporting.
Hans-Christian Armingeon asked if the linux-kernel mailing list was dead,
and Ragnar Hojland Espinosa confirmed that it Seems that its hickuping a bit..
And Matti Aarnio explained:
I would say "that is an understatement"...
For several good reasons there has been an attempt at renumbering vger into an alternate address space. That project, however, did yield massive amounts of DNS lookups failing in a way which did yield "NO ERROR" status, but also no data at all.
Moving vger back to old address failed partially too, and it took serious gymnastics to sort things out again.
The situation motivating for such drastic operation of renumbering is that some systems consider it right and proper to reject email just because DNS lookup does timeout somehow on them (no attempt of yielding 400-series error codes).
Some people (a LOT of people) seem to think that it is right and proper to analyze the parameter value given to the EHLO/HELO greeting verb. ISP's know that they just can't do that, world is full broken MUAs (for some reason, usually at M$ systems) which are trying to submit email via ISP hubs.. Spam-spewers usually do get that part correctly.
Some people seem to think that it is proper to even imagine of analyzing that the SMTP client's IP address has working DNS reverser entry. (Combine that with a failure to handle timeouts..)
Manfred Spraul announced:
CONFIG_DEBUG_SPINLOCK only adds spinlock tests for SMP builds. The attached patch adds runtime checks for uniprocessor builds.
Tested on i386/UP, but it should work on all platforms. It contains runtime checks for:
- missing initialization
- recursive lock
- double unlock
- incorrect use of spin_is_locked() or spin_trylock() [both function do not work as expected on uniprocessor builds] The next step are checks for spinlock ordering mismatches.
Which other runtime checks are possible? Tests for correct _irq usage are not possible, several drivers use disable_irq().
There was a bit of a technical discussion following.
Marcelo Tosatti announced 2.4.17-pre3, and said, People with Pentium Pro, please test if the workaround is really
working correctly...
Alex Buell asked, Where
are the sparc fixes? There are some fixes that's been queued since 2.4.16 that
really needs to go in!
Marcelo asked Alex to send the patches to him,
and David S. Miller replied, I sent you them twice
already, once I merge up to 2.4.17-pre4 I'll resend them to you.