This issue of Kernel Traffic is dedicated to the tireless folks over at the San Mateo County Mosquito Abatement District, without whom Silicon Valley (inhabited by many kernel developers) would be infested with dangerous mosquitos, ticks, and other deadly carriers of diseases like malaria, yellow fever, hantavirus and the plague. Forget about getting hit by a bus. What if Linus caught the Black Death!?!?!
Like the men in black, the agents of MAD are rarely seen or remembered. No one in their jurisdiction says, "boy, it was great to sleep through the whole night without getting eaten alive by mosquitos," mainly because there are no mosquitos around to complain about. But California used to be a mosquito haven, the likes of which you would not believe! I'm talking, big, mean mosquitos who absolutely would not stop until you were dead!
These dudes have the best job ever (as I recently discovered)! First, they get to fly around in a hovercraft. That by itself makes it worth signing up. The reason they need a hovercraft is because a lot of mosquito breeding grounds are in swampy areas that can't be reached by car or boat, or even helicopter in some cases. (of course, I'm secretly hoping they'll read this and offer me a hover, one day)
They also run around in level 3 biohazard suits, which, although not absolutely hermetically sealed, are still really stylish. They need the suits because, believe it or not, the black plague really is still very much alive, and is only kept in check by the tireless efforts of these selfless adventurers.
So this issue is for them. They rock big-time. Hats off.
Oh yeah. Saturday was also my birthday. Woo hoo!
Jochen Suckfuell reported that /proc/partitions was displaying incorrect input/output statistics under 2.4 kernels. He said that over time, the values for currently running requests would get too high or too low. He asked if anyone was working on a fix. Adrian Bunk replied that Marcelo Tossatti's tree (to be released as 2.4.19-rc2) included a patch to remove the entire feature. But Bill Davidsen cried out:
Is this the new Linux way of life? Removing modules is hard, GET RID OF THE FEATURE! Stats in /proc/partitions are not always correct, GET RID OF THE FEATURE!
The IDE support in 2.5 sucks rocks off the bottom of the ocean, is that next?
To the point, the stats are there, there are used by many of the widely used distributions, this is supposed to be stable, that's the excuse for not adding features, how can that justify taking out a feature? That's one of the useful things for determining which (if any) partitions have enough traffic to be best candidates for a separate drive. Yes I know there are other more complex ways than looking at human readable numbers. Why is that desirable? Why not fix the feature (I don't agree it's all that far off in most cases).
Andries Brouwer replied that /proc/partitions had never been in the
official kernel. He said, It is not in 2.4.18,
and it looks like it will not be in 2.4.19. It is in some vendor kernels,
but it is ugly and causes various problems.
Someone else added that
the feature hadn't really been removed, only moved to /proc/diskstat. At
that point the discussion skewed off into a bug-hunt, and petered out.
Jens Axboe announced, I've forward ported
the 2.4 IDE core (well 2.4.19-pre10-ac2 to be exact) to 2.5.25.
He explained:
So why did I do this? Well, I needed stable IDE for 2.5 testing and it was/is clear that 2.5 just isn't quite there yet. I intend to maintain this patch set until I deem 2.5 IDE stable enough (in code) that I'm willing to spend time on that instead. So the life span of this patch depends heavily on that. That said, I know of others who would like to be able to test 2.5 and not having to worry too much about the state-of-the-day of the IDE core. This patch set may be useful to them as well.
Also some notes on why I _didn't_ do this. I didn't do it because I think Martin is a jerk or because 2.5 IDE is forever doomed. I didn't do this because Andre twisted my arm. I didn't do this because of some hidden agenda.
That said, the patch works for me here. I've ripped out ide-tape and ide-floppy (frankly, I don't think it's worth my time updating these), but apart from that I think it's 2.4 feature complete. PIO multi count breaks for multi page bio's, if you intend to use that you should change MPAGE_BIO_MAX_SIZE as noted in fs/mpage.c. I'll fix that in the next iteration.
A number of people burst into applause. One person also reported a problem compiling the patches under certain configurations, and Jens posted a quick temporary fix, promising a better one in the next release.
About the patch in general, Erik Andersen exclaimed, Wonderful! Thus far, 2.5.x has been far too scary to try.
This patch is a sufficient safety blanket that I'm now willing to give it
a try, and I'm sure thats also the case for many others. 2.5.x just became
far more accessible. Thanks!
Elsewhere, Miles Lane remarked, Thank you Jens, It is really quite perturbing to think how
much the IDE instability has held back development of other features in the
unstable kernel. The warm reception of your patch speaks volumes.
Anton Altaparmakov was also thrilled to see Jens' work, and asked,
Seeing that the patches are bitkeeper
generated, would it be possible for you to make a repository available
with the patches? (on bkbits perhaps?) Would make it a lot easier for us
bitkeeper users just to pull from your repository... Especially once you
update the patches...
Jens said he would, and other folks also said
they were happy to see these patches available. At one point, Jens cautioned,
Let me add that I've only tested on x86 right now,
other archs should "just work" with a few changes to include/asm/ide.h
(see the changes in 15_24-misc-bits-1).
Later he gave a link to a
BitKeeper tree
from which to pull the patches.
At one point in the general discussion, Rogier Wolff said:
Ehmm. We have had "old IDE support" in the kernel for "ages". We have two aic7xxx driver, two rtl8139 drivers, two, or more ncr53c8xx drivers.
So why in the case of IDE has the "new IDE" driver not been forked and implemented under a new "name" such that those working on other stuff can chose to use the "old reliable" driver while others daring to test the new advanced rewrite can do so?
And Jens replied, That's a really good question,
in retrospect this is what should have happened IMO.
In the course of a perfectly normal discussion, Alexander Viro said:
So I'd just do
vi fs/dcache.c -c '/|= DCACHE_R/d|/nr_un/pu|<|x'
and be done with that. Linus?
Linus Torvalds replied, Done. For future
reference - don't anybody else try to send patches as vi scripts, please. Yes,
it's manly, but let's face it, so is bungee-jumping with the cord tied to
your testicles.
Someone asked if anyone had done any tests to see which was the most
stable kernel available. A number of people said that there was no way
to really test such things, but Paul Larson did give a link to the Linux Test Project. Bill Davidsen
recommended using Alan Cox's patches, if SMP under high load was required;
and Joe Sloan recommended Andrea Arcangeli's tree as being very stable. Tomas
Szepe said he'd been running 2.4.19-pre10-ac2 for 36 days, and 2.4.19-pre10
for 38 days. Steven Cole remarked, Even with an early
2.4.x kernel, you can get good results. I guess it really depends on your
load.
And Kelsey Hudson replied, indeed --
i had a box colocated in an ISP's basement running 2.4.2 on an abit bp6, twin
366MHz celerons, that stayed up for nearly 300 days. I think the grand total
was 284 days or something ridiculous like that; impressive for both such an
old release of the kernel and inherently broken hardware. the isp has since
gone out of business due to financial problems, and that's the only reason the
machine went down, otherwise i'm certain it would still be up now.
Muli Ben-Yehuda suggested compiling the kernel with the -Werror compiler
option, so that warnings wouldn't fly off the screen unread. Several people
suggested, instead of -Werror, redirecting the compiler output to a file and
going over it later, and Alan Cox also remarked, Adding
-Werror doesn't help because gcc emits far too many bogus warnings for
that.
Linus Torvalds replied:
Especially _some_ versions of gcc.
We've tried this before, and there are versions of gcc that have some warnings on by default that simply aren't acceptable and cannot be avoided sanely (I think at least some snapshots had the sign warnings on, for example, which causes some really silly warnings where the warnings are less odious than the changes required to get rid of them).
That said, I don't think -Werror is really wrong. It might make it less likely to have new drivers introducing unnecessary warnings..
Someone asked if the 2.0 kernel tree would stop being maintained after 2.6 came out. The poster felt this would be a good idea, since it would free up developer time for the more recent kernels. A number of people disagreed. The concensus was that anyone still using 2.0 should be able to fix bugs if they wished. As Alan Cox put it:
Why should you care ? 2.0 can continue to slowly and cautiously get critical bug fixes between now and the end of time providing someone cares enough to do the work. There are plenty of 2.0 boxes employed as routers, print servers, intranet dialins etc which will probably only become 2.4 boxes when the hardware is taken out of service.
I can't speak for David Weinehall's experience, and I know he does a lot more chasing down of bug reports than I bother to with 2.2 but in my experience maintaining a very stable kernel tree like 2.2 is nowdays is not a massive workload. It primarily consists of sending emails out which say "no"
At one point David Weinehall, the 2.0 maintainer, said:
The developer-force going into the 2.0-series is not very big. I consolidate the few fixes I get sent my way that are reasonable, and reject the rest (lately, most have been reasonable...), and try to backport some fixes from 2.2/2.4 that are applicable. No new drivers are added (or developed), and no new features are added.
Besides me, there are a few (no more than five) persons that regularly report their success/failure/personal gripes with the latest 2.0-releases, and remind me to increase the release-number (I'm as bad as Alan in this regard...)
The amount of work that I'd spend on a newer kernel would be about the same, and since I've grown fond of this work, I'll probably not drop 2.0 unless I get offered to take over 2.2 or 2.4 some point in the future.
Mind you, there _are_ people that still use 2.0 and wouldn't consider an upgrade the next few years, simply because they know that their software/hardware works with 2.0 and have documented all quirks. Upgrading to a newer kernel-series means going through this work again. And most likely, the upgrade would be to 2.2 rather than 2.4, because 2.4 still gets new features and API-changes now and then, something generally frowned upon in a controlled environment.
I am about to release 2.0.40 soon, and while 40 is a nice round number, 42 is an even better number to stop at, so that'll probably be the end of the road. That end lies quite some time in the future, though.
Guillaume Boissiere posted a summary of 2.5 kernel developments,
and remarked, With the code freeze date
approaching soon, it is obvious that many of these projects will not get
merged in the next 3 months. What would you rather me do? Keep them
in here just for reference, mark them as post-code freeze or just delete
them?
Randy Dunlap pointed out that the freeze was scheduled for
October 31, which was more than three months away. Rik van Riel suggested
marking longer-term projects as post-code-freeze instead of removing them,
so folks wouldn't forget about them. Dave Jones replied, Indeed. It may even be an idea to take what I started doing at http://www.codemonkey.org.uk/Linux-2.5.html,
merging the two and Guillaume running with this if you have time, because
these days, between hacking and merging patches, I'm kept pretty busy, so
updates to that file are getting less frequent.
Guillaume replied:
I would like to be able to do more to help the community, and in particular you Dave as feature freeze for 2.6 approaches and it becomes critical to track things down, but unless a Linux company out there can sponsor me, I just won't be able to dedicate more time than I am already dedicating to this.
Doing a good job at tracking a gazillion items and bugging people about patches and status is just incredibly time consuming.
Josh Litherland asked if he could use both a PS/2 keyboard and a USB numeric keypad on his laptop, with the current keyboard driver. Greg K-H said it should work just fine, but Josh said that under 2.4.18, he couldn't receive events from the keypad. He loaded the evdev driver, and confirmed that the device was detected, but no events would come through. Brad Hards replied:
evdev is on the userspace side of the input core (and USB is on the other). If evdev reports events (and you can decode them, if you are interested, using tools available from the linuxconsole CVS), then all is probably well with USB and the input core.
The obvious error would be not compiling in the input layer keyboard driver (or not loading the module, whatever).
If that definately isn't wrong (like lsmod shows the module, or a normal USB keyboard works fine and the keypad doesn't), then we'll likely need the HID descriptors. Probably easiest to get them from evdev using the evtest tool from linuxconsole CVS.
Josh replied that Brad had hit the nail on the head. After compiling and loading the input layer keyboard driver, the keyboard and keypad worked correctly together.