Dan Kegel reported that khttpd gave an oops on his Power PC, and wouldn't
serve any pages when he tried it on his x86. Anton Blanchard asked, Any reason for not using tux? Its been tested heavily
on ppc64, the same patches should work on ppc32.
Dan replied, That's an excellent suggestion. It certainly seems that khttpd
is no longer production quality (if it ever was), and tux is.
But Ken
Brownfield said, khttpd is very much production
quality on IA32, and has been since 2.4.0-test1. TUX2 is not, however,
since under load it enters a 99% CPU busy loop. You may not have enough
load to cause TUX2 to do this, and TUX1 may not have this problem.
But Anton said, Tux2 has been stable for me on
very large specweb runs. Ingo has been able to fix all the bugs I couldnt -
a detailed bug report here would be helpful.
And Dan pointed out that
khttpd had given him oopsen if he tried cycling it up and down in a loop.
Elsewhere, under the Subject: khttpd
rotten? Dan said, Seems like it's time to either
fix khttpd or pull it from the kernel. What was the last kernel version
where khttpd was stable (if any)?
David S. Miller replied:
We are going to pull it from the kernel.
The only argument is whether to replace it with TUX or not. There is a lot of compelling evidence that suggests that reasonably close performance can be obtained in userspace.
I guess the decision on TUX is not a prerequisite for pulling khttpd though.
Dan replied, Right. If khttpd had been pulled
from 2.4.17, I would have had weeks of warning that khttpd is unstable;
instead, I learned only when someone started doing his own stress testing,
and I have little time to fix it. I say pull it from 2.4.19-pre9. Marcello,
put it out of its misery asap, please... it'd time for khttpd to become a
standalone patch again.
Various patches began floating around; and various folks objected that they'd been using khttpd for awhile with no problems, and were sorry to see it go.
The question of whether Tux would go into the kernel was left open, although
it was pointed out that Red Hat already includes it in their kernel. Andrea
Arcangeli asked why there was any problem putting it into the main sources if
Red Hat already did that, and Alan Cox explained, The
Red Hat goal is to provide an extremely high quality tested distribution.
There are several things TuX needs that are stable, and high quality but which
Linus rejected because they put TuX specific code in places like the dcache
where from a pure clean kernel point of view it is undesirable.
Clifford White asked if a single process could have over 3G of
RAM. Luigi Genoni said that 3.6G was the maximum. Robert Love also said,
You can go to 3.5GB, anything more and stuff starts
getting real tight and not very nice. You can only do 3.5/0.5 on non-PAE,
though - PAE requires segments to be aligned on 1GB-boundaries.
In the course of discussion, Tomas Szepe asked whatever became of
CML2. He said, I haven't seen any updates since
about February and haven't almost certainly stumbled upon a post from ESR for
quite long either.
Dave Jones replied, The
majority seemed to be of the opinion it was too overfeatured whilst lacking
some of the more basic functionality desired from those who would end up
using it on a daily basis in favour of eye candy for users who compile a
kernel once per release.
Someone else remarked, also in reply to
Tomas, that Eric S. Raymond had been "blasted" away from the mailing list;
which the poster thought unfair, considering how much Eric had put in to
the project. Sean Hunter replied:
Perhaps that will be a lesson to the self-styled "Hacker of social systems" that there is a reason he has two ears and only one mouth.
As a low-evel hacker he needed to elicit support from others to get his work recognised and included. He was unwilling to listen to advice and criticism from those who know a lot better than him, and his work was not of such obvious brilliance that people were prepared to accept it without change.
He was not prepared to make the changes folks wanted, so he took his ball and went away in a strop.
But Andrew Rodland agreed with the earlier unnamed poster. He said, I did a lot of testing and some grunt-level coding
on CML2, and I think it addressed a lot of problems that existed, and was
getting steadily better. Sure, it had some flaky spots, but I really don't
see all of the problems that people had with it. Even autoconfig had this
tendency to do the Right Thing. I think it was just about ready to start
getting some wide testing and use, when everyone abandoned it... And now
nobody wants to use it, because of course patches don't play nice with it,
and etc... Pretty sad.
Larry McVoy reported, we've got a problem in
one of Linus' trees and it has started to propagate around. I need your
help to track it down and fix it. Please run the following script on your
Linux BK trees and contact me if it tells you to do so.
Eli Carter
asked what the problem was, and Larry replied:
The short summary is that two people used Linus' import tools and because of no error on his part, simply the way things worked out, that caused what we call "duplicate keys" (a lot like duplicate inodes, a lot like it) when the trees with the imported patch came together. I wrote a script to fix up the trees after the fact and the application of that script went wrong in Linus' tree but was not noticed until later. It started showing up as pull errors and then we tracked it down.
The long explanation would take me too long to do in email, I have carpal problems and it would amount to writing a "how BK works" paper and that's too much for me right now. If you want to understand the nitty gritty, we can go to voice and I'll tell you. So far, talking doesn't seem to hurt my wrists :)
Richard Gooch announced:
Version 212 of my devfs patch is now available from: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html The devfs FAQ is also available here.
Patch directly available from:
ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.5/devfs-patch-current.gz
AND:
ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.5/devfs-patch-current.gz
NOTE: kernel 2.5.1 and later require devfsd-v1.3.19 or later.
This is against 2.5.14. Highlights of this release:
- Added BKL to <devfs_open> because drivers still need it
Alexander Viro noticed a race condition, and Richard confirmed it after some investigation. He said:
OK, I've had a look. There is indeed a race there. While it is safe against module unloading, it isn't safe against removal of entries from the directory. I'm considering some different options to fix this (one is simple and obvious, the other will be a little more efficient).
Question: can invalidate_device() and the bdops methods check_media_change() and revalidate() be called with a lock held?
Alexander replied:
Erm... Depends on the nature of lock. Spinlocks are out of question, obviously (at the very least we reread partition table if disk had been changed and you can't make that nonblocking ;-). Semaphore might work, but I would be very careful with deadlocks - the same rereading partition table could add or remove devfs entries.
Could you describe what are you trying to achieve in the callers of check_disc_changed()? I'd been unable to deduce that from code and some comments would be very welcome.
Richard explained:
There are two cases where we want to do a partition re-read:
- in lookup(), if the entry was not found
- in readdir().
The point of this is to make sure that the partition list is updated (if media has changed) whenever user-space might care. Without the above code, if the media changes, and thus the partitioning changes, the list of partitions that devfs has is stale. Two things (at least) could go wrong in this case:
- ls on directory reports partitions that are no longer valid
- a new partition cannot be accessed because the entry hasn't been registered yet.
The code prevents these problems.
End of thread.