Table Of Contents
|1.||26�Dec�2003�-�7�Jan�2004||(17 posts)||ide-scsi Maintainership And Status; The Saga Continues|
|2.||30�Dec�2003�-�7�Jan�2004||(37 posts)||New kthread Threading Functions|
|3.||31�Dec�2003�-�4�Jan�2004||(16 posts)||Linux 2.6.0-rc1-mm1|
|4.||1�Jan�2004�-�5�Jan�2004||(14 posts)||Some Problems With SuSE gcc 3.3 Prereleases|
|5.||2�Jan�2004||(14 posts)||Some Filesystem Comparisons|
|6.||2�Jan�2004�-�10�Jan�2004||(11 posts)||Minimizing The Kernel|
|7.||3�Jan�2004�-�4�Jan�2004||(19 posts)||New Set Of Input Patches|
|8.||4�Jan�2004||(2 posts)||kernel.org Web Page HTML Validity|
|9.||4�Jan�2004||(1 post)||Usagi Stable Version 5 Released|
|10.||4�Jan�2004�-�5�Jan�2004||(8 posts)||Status Of HPT372 And HPT374 IDE Controller Support|
|11.||5�Jan�2004�-�7�Jan�2004||(8 posts)||Linux 2.6.1-rc1-mm2 Released|
|12.||5�Jan�2004�-�6�Jan�2004||(11 posts)||Linux 2.4.24 To Be Serious Bugfix Only; mremap Exploit Plugged; XFS Inclusion Delayed|
|13.||5�Jan�2004�-�8�Jan�2004||(22 posts)||mremap Security Patch For 2.6|
|14.||5�Jan�2004||(5 posts)||Hotplug Scripts Version 2004_01_05 Released|
|15.||6�Jan�2004�-�9�Jan�2004||(12 posts)||Linux 2.4.24-pre4 Released; htree Code Not Yet Merged|
|16.||6�Jan�2004||(16 posts)||Linus Talks About Declaring 'volatile' Variables|
|17.||7�Jan�2004||(1 post)||FUSE 1.1-pre1 Released|
|18.||7�Jan�2004||(1 post)||kgdb 2.0 For 2.6.0|
|19.||7�Jan�2004||(1 post)||iostat 2.0 Released|
|20.||7�Jan�2004||(6 posts)||Using Floating Point Operations In Kernel Code|
|21.||7�Jan�2004�-�8�Jan�2004||(2 posts)||Linux 2.6.1-rc3 Released|
|22.||7�Jan�2004�-�9�Jan�2004||(19 posts)||Linux 2.6.1-rc2-mm1 Released; Also Uptodate Against 2.6.1-rc3|
|23.||7�Jan�2004�-�9�Jan�2004||(5 posts)||RAM Hotplugging And Allocation|
|24.||8�Jan�2004||(1 post)||Linux Test Project January Version Released|
|25.||8�Jan�2004�-�9�Jan�2004||(2 posts)||Keycode Problems In Recent Kernels|
DVD CCA has surrendered in the Bunner case (http://www.eff.org/IP/Video/DVDCCA_case/20040122_eff_pr.php) , probably due in large part to the Jon Johansen decision (http://www.eff.org/news/breaking/archives/2004_01.php#001162) . As a result of this, the author of the DeCSS Haiku (http://www-2.cs.cmu.edu/~dst/DeCSS/Gallery/decss-haiku.txt) has decided to step forward and acknowledge his authorship. If he had done so before now, he would almost certainly have become the target of a terrible lawsuit.
The true author of the DeCSS Haiku is in reality Seth David Schoen (http://www.loyalty.org/~schoen/) , the Staff Technologist of the Electronic Frontier Foundation (http://eff.org/) . Now that he's stepping out of the shadows, he's written a really great article (http://www.loyalty.org/~schoen/haiku.html) about what he did and why. Don't miss the easter egg!
Mailing List Stats For This Week
We looked at 1877 posts in 9836K.
There were 581 different contributors. 288 posted more than once. 180 posted last week too.
The top posters of the week were:
1. ide-scsi Maintainership And Status; The Saga Continues
26�Dec�2003�-�7�Jan�2004 (17 posts) Archive Link: "The survival of ide-scsi in 2.6.x"
Topics: Disks: IDE, Disks: SCSI, USB
People: Willem Riede,�Pete Zaitcev,�Mikael Pettersson,�Bartlomiej Zolnierkiewicz,�James Bottomley,�Bill Davidsen,�Jens Axboe,�Wakko Warner,�Stephen Tweedie,�Linus Torvalds
Back in November, Linus Torvalds had some pretty harsh words to say about ide-scsi, covered in Issue�#242, Section�#1� (3�Nov�2003:�Status Of IDE-SCSI Maintainance) .
This week, Willem Riede said:
I know that many feel that ide-scsi is useless, and should go away. And you are probably tired of message threads talking about it. Yet I ask respectfully that you hear me out, and give me feedback.
I need ide-scsi to survive. Why? I maintain osst, a driver for OnStream tape drives, which need special handling. These drives exist in SCSI, ATAPI, USB and IEEE1394 versions.
One high-level driver, osst, handles all of them, and that's how it should be, right? For ATAPI, it relies on ide-scsi.
(By the way, ide-tape contains code for the ATAPI version, the DI-30, but that code is old and has serveral known problems - I'd like to see it removed - or at least deprecated - I will do that myself later if people want me to.)
So can we agree to keep ide-scsi? I know it is not desired any more for cd writers. To avoid the problem reports from people who don't realize that and select ide-scsi anyway, we can refuse to attach to a cd-type device (today it just warns). And/or make a new explicit module parameter to tell ide-scsi exactly which drives to attach to.
Today, ide-scsi is buggy, and that needs fixing. The underlying problem is that ide-scsi stands with one leg in the IDE world and one leg in the SCSI world, which creates the challenge to make the IDE error recovery work in sync with, and under the direction of the SCSI error handler.
Example bug reports are , , , , , and .
A recurring problem is scheduling while atomic, see , , . Linus points bluntly to the problem in . I plead guilty to having introduced that code segment in . I later attempted to improve on the error handling in , but that patch was not accepted (and wouldn't have fixed that particular problem).
 is different, and has me baffled - what can evoke a page fault in idescsi_transfer_pc?
In the spirit of cleaning up one's own mess, I am working on a new patch, to hopefully alleviate the problems. I've made liberal use of the attachments to the osdl bug reports - created by Mike Christie and a patch from Philip Auld , to give credit where it is due. I've also looked at ide-cd to see what it does differently.
Please look at the attachment (looking past the touch-ups that I made while I was at it...). Am I moving in the right direction? Specific changes I need advise on:
I've tested the patched ide-scsi with 2.6.0 - and it works fine. Too good actually, meaning the new error routines have not been adequately exercised. Any hints as to how to simulate errors at the ide subsystem level? Something like Stephen Tweedie's testdrive  perhaps (if applicable to char device), but for 2.6?
Linus states in  that ide-scsi needs a maintainer. I haven't seen anyone step forward, so that leads me to believe I may be the only person that depends enough on ide-scsi to be motivated?
If people will have me, I am prepared to take on that responsibility. I am just concerned that I may not have enough of a variety of devices to be able to thoroughly test it (unless the DI-30 is the only one :-)). What do people see as the requirements to be able to maintain ide-scsi?
OK, let me have it... Thanks, Willem Riede.
Wakko Warner suggested, half-seriously, just getting rid of both the IDE and the SCSI layers entirely, and replacing them with a generic layer that both could share. Short of that, he felt the IDE layer at least had always been ugly, and could be replaced by an IDE-to-SCSI converter, so all IDE devices would appear to be SCSI to the system.
Pete Zaitcev also replied to Willem, saying, "Based on my expirience with ide-tape, I would rather have it killed instead. One neat trick to appease enemies of ide-scsi might be to rename it into ide-scsi into ide-tape-bis. Might even add DSC bit handling... But the ide-tape is too ugly to live for sure." Willem agreed in principal, but asked, "are there any IDE tape drives currently supported by ide-tape, that are not compatble with ide-scsi plus st?" Mikael Pettersson offered, "My Seagate STT8000A works better with ide-scsi+st than with ide-tape. As long as a working ide-scsi is around, I couldn't care less about the ide-tape abomination." At this point, Bartlomiej Zolnierkiewicz said, "Both ide-tape and ide-scsi are to stay in 2.6.x and die in 2.7.x."
Elsewhere, James Bottomley also replied to Willem's initial post, saying that since no one else was interested, Willem was certainly welcome to start sending in patches; and James would look at them. He added, "In the long term, I think libata will end up assuming much of the role that ide-scsi does now, but since it doesn't interface to a lot of existing motherboard chipsets, we're going to need ide-scsi around for a while at least." Willem thanked him, adding that Linus had asked Jens Axboe to look over Willem's original patch; and Jens said he hadn't gotten to it yet, but would look it over soon.
Elsewhere, Bill Davidsen also thought it would be fine for Willem to do what he could with ide-scsi. Bill said, "here we have someone who has the need, the ambition, and the time to do this. Users of tape and MO still have need for ide-scsi, and would be happy to help test at least."
2. New kthread Threading Functions
30�Dec�2003�-�7�Jan�2004 (37 posts) Archive Link: "[PATCH 1/2] kthread_create"
People: Rusty Russell,�Jeff Garzik,�Andrew Morton
Rusty Russell posted a patch, saying:
The hotplug CPU code introduces two major problems:
Unfortunately, stopping a thread is fairly baroque, involving memory barriers, a completion and spinning until the task is actually dead.
There are also three problems in starting a thread:
Place all this logic in some primitives to make life easier: kthread_create(), kthread_start() and kthread_destroy(). These primitives require no extra data-structures in the caller: they operate on normal "struct task_struct"s.
Andrew Morton suggested putting all the hotplugging patches in one location for easy review, and Rusty said, "I've had this on kernel.org for a few years now. It's even at the top of the page: http://www.kernel.org/pub/linux/kernel/people/rusty"
Elsewhere, Jeff Garzik really liked Rusty's work, and said:
there are two mechanisms I (and some others) felt were missing from the equally nifty workqueue stuff:
For #1, your patch seems to cover that nicely.
For #2, that's to be used for situations where (a) you need a thread context _and_ (b) you simply cannot wait for keventd to become available (since there are no time guarantees).
Rusty replied, regarding Jeff's item 1, "It's really for persistent threads, but you can use it as one-shot by either (1) calling exit() in the core function (and noone calls kthread_destroy), or (2) not having a core function and just having an init function. I used this in a test patch."
3. Linux 2.6.0-rc1-mm1
31�Dec�2003�-�4�Jan�2004 (16 posts) Archive Link: "2.6.0-rc1-mm1"
Topics: Version Control
People: Matthias Urlichs,�Andrew Morton
Andrew Morton posted 2.6.1-rc1-mm1 (ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1-rc1/2.6.1-rc1-mm1/) , primarily to resync with the mainline 2.6 tree. Various folks posted fixes, and Matthias Urlichs also said Andrew's release was
available via Bitkeeper at <bk://smurf.bkbits.net/linux-2.6-mm>.
If you use this tree, please consider dropping me a note or whatever; I don't like to work in a vacuum...
The way I've built this, in case anybody's curious:
Oh yes, I've stopped prefixing the patch tags with mm; that would get too confusing in the long run.
4. Some Problems With SuSE gcc 3.3 Prereleases
1�Jan�2004�-�5�Jan�2004 (14 posts) Archive Link: "[PATCH] disable gcc warnings of sign/unsigned comparison"
People: Paul Jackson,�Adrian Bunk,�Trond Myklebust,�Andrew Morton
Paul Jackson posted a patch to disable gcc warnings on comparing signed and unsigned numbers, because he was seeing a lot of these when using gcc 3.3 under SuSE. In a later post he said:
Right now, compiling a 2.6.0-mm1 (what I had handy) with the 3.3 gcc on my Pentium system for arch i386 generates 1386 signed and unsigned warnings, of the two kinds:
warning: signed and unsigned type in conditional expression warning: comparison between signed and unsigned
A patch that resolved these 1386 warnings would (1) generate more crap than it cleaned up, (2) immediately result in adding more bugs than removed, and (3) due to the crap level rising, generate more bugs long term than it avoided.
Andrew Morton was revolted by this, and was all set to go with Paul's path, in spite of the fact that Trond Myklebust and others felt it would be better to just fix the kernel code causing the warnings instead. But before Andrew could add the patch to his tree, Paul discovered that "the only place I can find the gcc with this bug (that -Wall implies -Wsign-compare) is the gcc 3.3 that came with my SuSE Linux 8.2 distribution. Each of the 3.3, 3.3.1 and 3.3.2 versions available at ftp.gnu.org/gnu/gcc are ok - no such bug." Some folks began to speculate that the bug was in 3.3, and that is had been fixed subsequently; but elsewhere in the thread, Adrian Bunk also said, "It was _not_ a bug in gcc 3.3 . It was a bug in some _prerelease_ versions of gcc 3.3 SuSE decided to ship in a release of their distribution. There is no officially released version of gcc with this problem."
5. Some Filesystem Comparisons
2�Jan�2004 (14 posts) Archive Link: "file system technical comparisons"
Topics: FS: JFS, FS: NTFS, FS: ReiserFS, FS: ext3
People: Randy Dunlap
Steve Glines asked for a technical comparison between ext3, reiserfs, xfs jfs, and if possible any other supported filesystems. Stewart Smith said he'd done some comparisons of a number of filesystems in his honor's thesis (http://www.flamingspork.com/honors/) , notable exceptions being JFS and NTFS. Someone else also gave a link to a Linux Magazine article (http://www.linux-mag.com/2002-10/jfs_01.html) . Randy Dunlap also gave a pointer to a comparison he'd done (http://developer.osdl.org/rddunlap/journal_fs/lwe-jgfs.pdf) in the 2.4 era, which he said was quite dated and probably not so accurate anymore.
6. Minimizing The Kernel
2�Jan�2004�-�10�Jan�2004 (11 posts) Archive Link: "2.6.1-rc1-tiny1 tree for small systems"
Topics: FS: ext2, Networking, Small Systems
People: Matt Mackall,�Eric W. Biederman,�Andi Kleen
Matt Mackall announced:
This is the third release of the -tiny kernel tree. The aim of this tree is to collect patches that reduce kernel disk and memory footprint as well as tools for working on small systems. Target users are things like embedded systems, small or legacy desktop folks, and handhelds.
Latest release includes:
The big bit here is SLOB, which optionally replaces the SLAB allocator and kmalloc wrappers with a traditional malloc arena and a SLAB emulation layer. SLOB is less than a tenth the size of the SLAB code and is considerably more space efficient with its allocations, but is not as fast and may prove less resistant to long-term fragmentation.
Thanks to Andi Kleen, Magnus Naeslund, and various others for their contributions and suggestions.
The patch can be found at:
Contributions and suggestions are encouraged. In particular, it would be helpful if people with non-x86 hardware could take a stab at extending some of the stuff that's currently only been done for X86 to other architectures.
Eric W. Biederman gave it a try, and found that he was able to create a 220K compressed kernel, which he felt was a huge reduction compared with other kernels. He also felt there was a lot of room for improvement, because there were many non-optional features still in Matt's tree. Matt said, "Suggestions? I'm rapidly exhausting a lot of the obvious candidates. My target build at the moment is ide + ext2 + proc + ipv4 + console, and that's currently at around 800K uncompressed, booting in a little less than 2.5MB. Hoping to get that under 2." Eric replied:
I have a 386 I really should try this out on.
Of note IPv4 is about 90K compressed. And I know you can do a minimal IPv4 stack in about 8K compressed.
My target is a minimal kernel that can be used as a bootloader. But what I am looking for at first is to be able to turn as many things off as possible so that we can test to see how much individual pieces add.
If you look at ELKS or one of the old unix like kernels you can get those down to 64K and still be usable.
I'm currently looking at removing the buffer cache, since I most of the time I don't care about disks. This is complicated by the fact that many of the default paths in the kernel when they don't have a better implementation use buffer cache methods. But I'm making headway.
Proc is one of things that frequently has loads of crap that are not needed in a minimal setup.
Until I find more candidates to turn off I can't see any low hanging fruit for shrinking in size.
Later, Eric posted a patch to remove block device support from Matt's kernel. This brought his compiled bzImage down to 191K. After some feedback, he posted a cleaner patch that also did more, and Matt merged it into his tree.
7. New Set Of Input Patches
3�Jan�2004�-�4�Jan�2004 (19 posts) Archive Link: "New set of input patches"
People: Dmitry Torokhov,�Vojtech Pavlik
Dmitry Torokhov said to Vojtech Pavlik:
I have a new set of input patches, could you take look at them?
The patches are on top of 2 other input patches (remove jitter and ps2 emulation) that I have sent to the list earlier. You can find the complete set of patches at http://www.geocities.com/dt_or/input/2_6_0-rc1/ and http://www.geocities.com/dt_or/input/2_6_0-rc1-mm1/
After some discussion and typo-hunting, Vojtech said, "Andrew, please apply these patches to your tree and/or schedule them for inclusion into mainline."
8. kernel.org Web Page HTML Validity
4�Jan�2004 (2 posts) Archive Link: "Kernel.org: Webpage validator and Web accessibility."
People: Tim Cambrant
Someone pointed out that if one were to run http://www.kernel.org through the http://validator.w3.org/ W3C HTML validator, the page would turn out invalid. Tim Cambrant replied, "You should contact the webmaster of http://kernel.org at firstname.lastname@example.org about this, since it isn't a kernel-development issue. I agree though, standards should be followed, and making it valid really doesn't take long."
9. Usagi Stable Version 5 Released
4�Jan�2004 (1 post) Archive Link: "USAGI STABLE Release 5"
People: Yuji Sekiya
Yuji Sekiya announced:
We are glad to announce the USAGI STABLE RELEASE 5, dated on January 4th, 2004. This is the last major STABLE release based on linux-2.4 kernel from USAGI Project. Our primary target of development is moved to linux-2.6 kernel.
Changes from the STABLE RELEASE 4.1 are:
However, the IPsec and Mobile IPv6 implementations included in this STABLE release may not developed further. Because the IPsec stack was written for linux-2.4 kernel by USAGI Project and currently we have rewritten NEW IPsec stack for linux-2.6 kernel and the stack is included linux-2.6 mainline kernel. The IPsec stack included linux-2.6 kernel is implemented based on "xfrm" architecture and we will continue developing based on the NEW IPsec stack.
The Mobile IPv6 stack is the same situation as the IPsec. The Mobile IPv6 stack included in this release is developed by HUT GO Project and the stack is mainly written for linux-2.4 kernel. Currently USAGI Project and GO Project have started joint project for developing new Mobile IPv6 stack based on linux-2.6 kernel.
You can get our complete kit which includes kernel tree, library and applications from <ftp://ftp.linux-ipv6.org/pub/usagi/stable/kit/>.
We also provide separate patches against the main-line kernel and the tools <ftp://ftp.linux-ipv6.org/pub/usagi/stable/split/>.
Many of our efforts are already in mainline kernel tree. We will continue making reasonable size patches and trying to merge it into mainline kernel tree.
We announce the latest information on our web pages. Please check our web site <http://www.linux-ipv6.org>.
We also manage the mailing lists for USAGI users. If you have questions, please join the mailing list. Comments and advises are also welcome on that mailing list. Please visit <http://www.linux-ipv6.org/ml/> for further information.
10. Status Of HPT372 And HPT374 IDE Controller Support
4�Jan�2004�-�5�Jan�2004 (8 posts) Archive Link: "Any hope for HPT372/HPT374 IDE controller?"
Topics: Disks: IDE
People: Andre Hedrick
Tom Wallard asked if the Highpoint HPT372 and HPT374 IDE controllers had been fixed yet. As reported way back in Issue�#216, Section�#3� (29�Apr�2003:�'Must-Fix' Bug List For 2.6 (Or 3.0)) , at least the HPT372N would "eat disks" in 2.5; Andre Hedrick replied:
I have a version stable for the KT400 chipset, it is the KT600 which is unstable now. As soon as I finish resolving the issues one of my customers is having with the KT600, it will be released shortly there after.
Some of the problems appear with the APIC routing and interrupts being lost and not begin processed.
Various reports followed Tom's, including some claiming to work perfectly, and others claiming to exhibit problems.
11. Linux 2.6.1-rc1-mm2 Released
5�Jan�2004�-�7�Jan�2004 (8 posts) Archive Link: "2.6.1-rc1-mm2"
Topics: Version Control
People: Andrew Morton,�Matthias Urlichs
Andrew Morton announced 2.6.1-rc1-mm2 (ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1-rc1/2.6.1-rc1-mm2) , saying, "Many new fixes, all over the place." Matthias Urlichs said that this release "will be bitkeeperized shortly, in fact as soon as anything-non-kernel.bkbits.net is again reachable. :-/"
12. Linux 2.4.24 To Be Serious Bugfix Only; mremap Exploit Plugged; XFS Inclusion Delayed
5�Jan�2004�-�6�Jan�2004 (11 posts) Archive Link: "Linux 2.4.24-rc1"
Topics: FS: XFS
People: Marcelo Tosatti,�Martin Knoblauch
Marcelo Tosatti announced 2.4.24-rc1, saying:
This release fixes a few critical problems in 2.4.23, including fixes for two security bugs.
Upgrade is recommended.
The release dealt with a recently discovered mremap vulnerability (http://isec.pl/vulnerabilities/isec-0013-mremap.txt) . Martin Knoblauch asked if this release postponed other changes that had already been accepted into the 2.4 pre-releases; things like XFS, in particular. Marcelo explained, "Yes. The 2.4.24-pre tree with all its modifications becomes 2.4.25-pre."
13. mremap Security Patch For 2.6
5�Jan�2004�-�8�Jan�2004 (22 posts) Archive Link: "[patchlet link] Re: 2.6.1-rc1 affected?"
Topics: Version Control
People: Linus Torvalds,�Bastiaan Spandaw,�Tomas Szepe
Markus Hastbacka asked if there would be a patch against 2.6 to fix the recently discovered mremap security hold (http://isec.pl/vulnerabilities/isec-0013-mremap.txt) . Linus Torvalds replied, "Yup. I'd actually personally prefer a stronger test than the one in 2.4.24, and my personal preference would be for just disallowing the degenerate cases entirely. I don't see a "mremap away" as being a valid thing to do, since if that is what you want, why not just do a "munmap()"?" Marcus asked why there wasn't already a new -rc release for 2.6; and Linus replied, "Because nobody actually contacted me about the problem and I read about it on linux-kernel like everybody else? Because I just got up and created the patch? And because nobody has an exploit yet, and one may be hard or impossible to create? And because people who care about these things tend to not update to x.0 kernels anyway?" He added, "They'll get a 2.6.1 soonish. The patch is in the current BK tree, will be in -rc2, and will be in 2.6.1. Let's just make sure we don't screw up the release due to being too much in a hurry either.."
At some point, Tomas Szepe asked for some sample code to prove that an exploit was possible, and Bastiaan Spandaw said, "According to a slashdot comment this is proof of concept code. http://linuxfromscratch.org/~devine/mremap_poc.c" . Several folks tested this on a few kernels and found it to successfully exploit the hole.
14. Hotplug Scripts Version 2004_01_05 Released
5�Jan�2004 (5 posts) Archive Link: "[ANNOUNCE] 2004-01-05 release of hotplug scripts"
Topics: Backward Compatibility, Hot-Plugging
People: Greg KH
Greg KH announced:
I've just packaged up the latest Linux hotplug scripts into a release,
which can be found at:
Or from your favorite kernel.org mirror at:
or for those who like bz2 packages:
I've also packaged up some pre-built (and signed) Red Hat FC 1 based rpms:
The source rpm is available if you want to rebuild it for other distros
or versions of Red Hat at:
The main web site for the linux-hotplug project can be found at:
which contains lots of documentation on the whole linux-hotplug process.
This release is recommended for _anyone_ using the 2.6.0 and beyond kernels who is still using hotplug scripts older than 2003_08_05, as a number of changes have been made in order to support the 2.6 kernel properly.
The release is still backwards compatible with 2.4, so there is no need to worry about upgrading.
15. Linux 2.4.24-pre4 Released; htree Code Not Yet Merged
6�Jan�2004�-�9�Jan�2004 (12 posts) Archive Link: "Linux 2.4.25-pre4"
Topics: FS: ext2, Version Control
People: Marcelo Tosatti,�Mike Fedyk
Marcelo Tosatti said:
Moving on with the 2.4.24-pre tree, here is 2.4.25-pre4.
It contains an ext2/3 update (mostly forward compatibility related), the usual architecture updates (this time S390, PPC64/32, SH), osst update, TG3 bugfixes, amongst others.
Some of the fixes listed in this changelog (the rtc fixes, the IrDA "log buster" fix and the netfilter MASQUERADE oops) were already in other -pre's, they got removed and re added for technical BK reasons.
Mike Fedyk asked if Marcelo planned to merge the htree code, and Marcelo said yes, in the next -pre release.
16. Linus Talks About Declaring 'volatile' Variables
6�Jan�2004 (16 posts) Archive Link: "[PATCH] fix get_jiffies_64 to work on voyager"
Topics: Assembly, PCI, SMP
People: Linus Torvalds
In the course of discussion, during which the suggestion was made to declare a variable 'volatile', Linus Torvalds said:
we should _never_ make anything volatile. There just isn't any reason to. The compiler will never do any "better" with a volatile, it will only ever do worse.
If there are memory ordering constraints etc, the compiler won't be able to handle them anyway, and volatile will be a no-op. That's why we have "barrier()" and "mb()" and friends.
The _only_ acceptable use of "volatile" is basically:
in _code_ (not data structures), where we might mark a place as making a special type of access. For example, in the PCI MMIO read functions, rather than use inline assembly to force the particular access (which would work equally well), we can force the pointer to a volatile type.
Similarly, we force this for "test_bit()" macros etc, because they are documented to work on SMP-safe. But it's the _code_ that works that way, not the data structures.
And this is an important distinctions: there are specific pieces of _code_ that may be SMP-safe (for whatever reasons the writer thinks). Data structures themselves are never SMP safe.
Ergo: never mark data structures "volatile". It's a sure sign of a bug if the thing isn't a memory-mapped IO register (and even then it's likely a bug, since you really should be using the proper functions).
(Some driver writers use "volatile" for mailboxes that are updated by DMA from the hardware. It _can_ be correct there, but the fact is, you might as well put the "volatile" in the code just out of principle).
That said, the "sure sign of a bug" case has one specific sub-case:
But the "jiffies" case is safe only _exactly_ because it's an atomic read. You always get a valid value - so it's actually "safe" to mark jiffies as baing volatile. It allows people to be sloppy (bad), but at least it allows people to be sloppy in a safe way.
In contrast, "jiffies_64" is _not_ an area where you can safely let the compiler read a unstable value, so "volatile" is fundamentally wrong for it. You need to have some locking, or to explicitly say "we don't care in this case", and in both cases it would be wrong to call the thing "volatile". With locking, it _isn't_ volatile, and with "we don't care", it had better not make any difference. In either case the "volatile" is wrong.
We had absolutely _tons_ of bugs in the original networking code, where clueless people thougth that "volatile" somehow means that you don't need locking. EVERY SINGLE CASE, and I mean EVERY ONE, was a bug.
There are some other cases where the "volatile" keyword is fine, notably inline asm has a specific meaning that is pretty well-defined and very useful. But in all other cases I'd suggest having the volatile be part of the code, possibly with an explanation _why_ it is ok to use volatile there unless it is obvious.
17. FUSE 1.1-pre1 Released
7�Jan�2004 (1 post) Archive Link: "[ANNOUNCE] Filesystem in Userspace (FUSE) 1.1-pre1"
People: Miklos Szeredi
Miklos Szeredi announced FUSE (Filesystem in User SpacE) version 1.1-pre1, and said:
I did a release at long last, it's got proper 2.6 kernel support and all the rest of the stuff that people contributed since 1.0.
It can be downloaded from the usual place:
18. kgdb 2.0 For 2.6.0
7�Jan�2004 (1 post) Archive Link: "kgdb 2.0 for kernel 2.6.0"
People: Amit S. Kale,�George Anzinger,�Andi Kleen,�Andrew Morton
Amit S. Kale said:
I have released kgdb 2.0 for kernel 2.6.0 for i386 and x86_64 architectures at http://kgdb.sourceforge.net.
This version of kgdb has been supported by TimeSys Corporation and Storad Inc. It contains code from kgdb patches maintained by Andrew Morton (George Anzinger), Andi Kleen and Jim Housten.
Significant changes since previous version:
19. iostat 2.0 Released
7�Jan�2004 (1 post) Archive Link: "iostat - Linux I/O performance monitoring utility"
People: Zlatko Calusic
Zlatko Calusic said:
iostat v2.0 is out!
It works flawlessly on both 2.4 & 2.6, compiles on Debian, Redhat, you name it... IOW, it's perfect. :)
Looks something like this:
extended device statistics device mgr/s mgw/s r/s w/s kr/s kw/s size queue wait svc_t %b hde 0 3530 5.0 92.0 20.2 14597.8 150.6 68.1 563.2 6.0 58 hdg 0 0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 hda 0 105 159.6 69.4 637.7 812.9 6.3 56.0 176.4 4.1 95
Find it on: http://linux.inet.hr/
20. Using Floating Point Operations In Kernel Code
7�Jan�2004 (6 posts) Archive Link: "Use of floating point in the kernel"
People: H. Peter Anvin,�Linus Torvalds
Pekka Pietikainen found some cases of floating point math operations inside kernel code, which is not supposed to be allowed; H. Peter Anvin said, "Has anyone considered asking the gcc people to add an -fno-fpu (or -mno-fpu) option, throwing an error if any FP instructions are used?" Linus Torvalds replied:
We really should, but there really are some rare cases where it is actually ok.
In particular, you _can_ do math, if you just do the proper "kernel_fpu_begin()"/index.html"kernel_fpu_end()" around it, and you have reason to believe that you can assume a math processor exists.
Is it needed? I dunno. I'd frown on it in general, but I don't see it being fundamentally wrong under the rigth circumstances.
21. Linux 2.6.1-rc3 Released
7�Jan�2004�-�8�Jan�2004 (2 posts) Archive Link: "2.6.1-rc3"
Topics: Kernel Release Announcement
People: Linus Torvalds
Linus Torvalds announced kernel 2.6.1-rc3, saying, "Not a lot to say, the ChangeLog says it all (and I include the -rc2 log too, since I forgot to actually ever post it). Mostly random smaller stuff all over. The big merges were all in rc1 and do not seem to have caused any huge headaches."
22. Linux 2.6.1-rc2-mm1 Released; Also Uptodate Against 2.6.1-rc3
7�Jan�2004�-�9�Jan�2004 (19 posts) Archive Link: "2.6.1-rc2-mm1"
Topics: Disk Arrays: RAID, FS: ext2, Framebuffer, Power Management: ACPI, Security, User-Mode Linux, Version Control
People: Andrew Morton
Andrew Morton announced:
A significant amount of work on remap_file_pages() from Ingo. Most notably, we now support per-page protections within a single VMA. This is aimed at UML and similar specialised applications which are presently forced to allocate one VMA per page.
Anyone who is interested in remap_file_pages(), please test.
This adds a new syscall and breaks all non-ia32 architectures. Instructions as to how to unbreak them is in the remap_file_pages-prot-2.6.1-H2 patch.
The remap_file_pages non-blocking infrastructure has been used to implement prefaulting of minor faults for mappings. This will reduce the kernel's minor fault rate by up to a factor of eight and has been shown to offer a few percent speedup on some things.
This needs serious benchmarking please. Tests which involve short-lived processes.
The remap_file_pages work will probably live in -mm for a while. It needs careful review - alterations to largely unused code paths are a concern because of the potential for long-lived security and DoS holes.
He replied to himself, having noticed that Linus had put out 2.6.1-rc3 just moment's before Andrew's own release. He said, "2.6.1-rc2-mm1 contains everything which is in 2.6.1-rc3."
23. RAM Hotplugging And Allocation
7�Jan�2004�-�9�Jan�2004 (5 posts) Archive Link: "a new version of memory hotremove patch"
Topics: Big Memory Support, Hot-Plugging
People: Toshihiro Iwamoto,�Hirokazu Takahashi
Toshihiro Iwamoto said:
This is an update of the memory hot removal patch. As I'll merge this patch over Goto-san's hotplug patch (http://marc.theaimsgroup.com/?l=linux-kernel&m=107214532922184&w=2), this will be the final version in this standalone form. When that is done, there will be no more zone_active checks in page allocation code.
Changes from the previous version (dated 20031126) are:
I guess many of you think this patch has no use for yourselves, but it was at least useful for finding some kind of kernel memory leaks. :)
http://people.valinux.co.jp/~iwamoto/mh.html contains some patch explaination and usage info. This page hasn't changed much since the last post.
Hirokazu Takahashi replied:
I just implemented a patch which allow us to allocate huge continuous pages easily. As We know it's very hard to allocate them on demand, since free memory on system may be fragmented. My approach is that I let annoying pages move to another place so that we can make free coninuous space on memory. Iwamoto's memory-hot-removal patch will help to do it.
I believe moving pages approach will be much better than random swaping page out approach for this purpose.
iwamoto> This is an update of the memory hot removal patch.
My patch needs the iwamoto's memory-hot-removeval patch. You should apply both of them against linux-2.6.0.
24. Linux Test Project January Version Released
8�Jan�2004 (1 post) Archive Link: "[ANNOUNCE] Linux Test Project January Release Announcement"
People: Robert Williamson,�Randy Hron,�Erik Andersen
Robert Williamson said:
The Linux Test Project test suite <http://www.linuxtestproject.org> has been released. The latest version of the testsuite contains 2100+ tests for the Linux OS. Our web site also contains other information such as: test results, a Linux test tools matrix, technical papers and HowTos on Linux testing, and a code coverage analysis tool.
Developers from the Linux Test Project co-authored the whitepaper, "Putting Linux Reliability to the Test". This article documents the test results and analysis of the Linux kernel and other core OS components, including everything from libraries and device drivers to file systems and networking, all under some fairly adverse conditions, over a period of 60 days. You can find the paper at: http://www.ibm.com/developerworks/linux/library/l-rel
We encourage the community to post results to email@example.com, and patches, new tests, or comments/questions to firstname.lastname@example.org.
25. Keycode Problems In Recent Kernels
8�Jan�2004�-�9�Jan�2004 (2 posts) Archive Link: "Broken keycodes in recent kernels"
Topics: Microsoft, USB
People: Andries Brouwer,�Vojtech Pavlik
Andries Brouwer said:
Just received my tenth complaint this year about the fact that kbd and recent kernels disagree as to what the right keycodes are. Since I maintain kbd it follows that recent kernels are broken.
What is right?
The old Linux convention is that for 1-88 keycode equals scancode. Above that things are a bit messy, mainly because the 128 scancodes xx and the 128 escaped scancodes e0 xx and the single combination e1 1d 45 are put into 127 keycodes, and that doesnt fit.
OK. So we want at least to preserve this 1-88 range, and may worry about the rest later. All common keys should keep their keycode. See also setkeycodes(8).
2.6 does first an untranslate and then a map to keycode, so the fact that keycode equals (translated) scancode now becomes atkbd_set2_keycode[atkbd_unxlate_table[i]] == i for i=1,...,88.
Looking at 2.6.0 we see a single mistake: scancode 84 is translated incorrectly. And many Japanese complained. Looking at 2.6.1-rc1 we see two mistakes: also scancode 85 is now mistranslated.
So, I think the change of 2.6.1-rc1 was not necessarily an improvement, but 2.6.0 needs a fix.
I can look at the details, but perhaps Vojtech wants to comment.
Vojtech Pavlik replied:
I won't argue that the 2.6.1-rc situation is correct, but I'll describe it and the difference from 2.4:
On 2.4, keycode 84 is the SysRq keycode, since historically AT keyboards do emit a different keycode for SysRq than form PrintScreen, although they're on the same key.
On 2.6, there is only one keycode for PrintScreen, in an attempt to be a bit saner, and that is 99. And here comes my mistake - since 84 was not used anymore, I used it for the "103rd" European key.
The 103rd key usually produces either backslash-bar or hash-tilde, or other national combo. I believe that 2.4 did emit keycode 43 for it, since this keyboard is treated the same as backslash by AT Set 2 keyboards, in hardware.
USB keyboards, and Set 3 keyboards, however differentiate between this key and the real backslash, and since there also can be the real backslash in addition to this key on the keyboard, it makes sense to allocate a scancode to it.
Now my snafu was that I allocated a 2.4-used scancode to it, and one that is mapped to SAK in 2.4 keymaps usually.
This bites French, British and probably Brazilian people, too.
I'm open to suggestions about how to fix it.
Scancode 85 (translated, set2) at the moment is not mapped to any keycode. There are other scancodes that are not mapped at all, only known scancodes are mapped, the rest should be changed by the user.
Keycode 85 is defined as F13 (in keymaps), and is mapped to scancode 93 (both in atkbd.c and keyboard.c), which is F13, according to Microsoft documentation, which was used as reference, since that's what keyboard manufacturers tend to follow nowadays.
Japanese and Korean keys.
2.6 has unified support for Japanese and Korean keys on both USB and PS/2 keyboards.
The keycodes are defined as:
KEY_INTL1 181 /* Romanji */ KEY_INTL2 182 /* Hiragana / Katakana */ KEY_INTL3 183 /* Yen */ KEY_INTL4 184 /* Henkan */ KEY_INTL5 185 /* Muhenkan */ KEY_INTL6 186 /* PC9800 KP , */ KEY_LANG1 190 /* Hanguel */ KEY_LANG2 191 /* Hanja */ KEY_LANG3 192 /* Katakana */ KEY_LANG4 193 /* Hiragana */ KEY_LANG5 194 /* Zenkaku / Hankaku */
These keycodes are translated back to the PS/2 scancodes in raw mode.
The problem here lies in that that all the keycodes are above 128, and are different from what 2.4 used for these keys on an AT keyboard.
We could go back to the 2.4 layout, where the keycodes are scattered where there was space in the translated set2 scancode list, and not even all fit there, but I think that way lies madness. The 2.6 layout is based on the USB HUT definition.
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.