Kernel Traffic #329 For 26 Sep 2005 By Zack Brown Table Of Contents * Standard Format * Text Format * XML Source * Mailing List Stats For This Week * Threads Covered 1. 9 Sep 2005 - 15 Sep 2005 (5 Using linux/irq.h Or asm/irq.h In posts) Drivers 2. 12 Sep 2005 - 18 Sep 2005 (55 Linux 2.6.13-mm3 Released posts) 3. 12 Sep 2005 - 16 Sep 2005 (56 Linux 2.6.14-rc1 Released posts) 4. 14 Sep 2005 - 17 Sep 2005 (42 Framework For Automatic Kernel posts) Configuration 5. 14 Sep 2005 - 15 Sep 2005 (20 Review Cycle Starts For Linux posts) 2.6.13.2 6. 15 Sep 2005 (4 New CS5535 Audio ALSA Driver posts) 7. 15 Sep 2005 (7 Russell's Projects posts) 8. 15 Sep 2005 - 17 Sep 2005 (27 Proposed Reorganization For SysFS posts) 9. 16 Sep 2005 - 17 Sep 2005 (26 Linux 2.6.14-rc1-mm1 Released posts) 10. 16 Sep 2005 - 18 Sep 2005 (12 master.kernel.org Moves To New Home posts) 11. 16 Sep 2005 (2 Linux 2.6.13.2 Released posts) 12. 18 Sep 2005 - 20 Sep 2005 (7 git 0.99.7 Released; Cogito 0.15 posts) Released 13. 19 Sep 2005 (3 Status Of PWC Driver posts) 14. 19 Sep 2005 - 21 Sep 2005 (38 Linux 2.6.14-rc2 Released posts) 15. 21 Sep 2005 (1 post) kprobes Maintainership Mailing List Stats For This Week We looked at 2114 posts in 13MB. See the Full Statistics. There were 694 different contributors. 278 posted more than once. The average length of each message was 105 lines. +-----------------------------------------------------------------------------+ |The top posters of the week | The top subjects of the week were: | | were: | | |----------------------------+------------------------------------------------| |67 posts in 317KB by andrew |55 posts in 264KB for "[patch] support utf-8 | |morton |scripts" | |66 posts in 814KB by |49 posts in 197KB for "p = kmalloc(sizeof(*p), )| |dtor_core@ameritech.net |" | |46 posts in 191KB by al viro|44 posts in 222KB for ""read my lips: no more | |45 posts in 285KB by nick |merges" - aka linux 2.6.14-rc1" | |piggin |42 posts in 274KB for "automatic configuration | |44 posts in 208KB by |of a kernel" | |blaisorblade |37 posts in 161KB for "[rfc] splitting out | | |kernel<=>userspace abi headers" | +-----------------------------------------------------------------------------+ These stats generated by mboxstats version 2.8 1. Using linux/irq.h Or asm/irq.h In Drivers 9 Sep 2005 - 15 Sep 2005 (5 posts) Archive Link: "[RFC] killing linux/irq.h" People: Alexander Viro, Geert Uytterhoeven, Matthew Wilcox, Christoph Hellwig Alexander Viro said: We get regular portability bugs when somebody decides to include linux/irq.h into a driver instead of asm/irq.h. It's almost always a wrong thing to do and, in fact, causes immediate breakage on e.g. arm. Here's what I'm going to do: * check current includes of linux/irq.h; e.g. in arch/x86_64 all but two had been 100% useless, one should've been asm/irq.h and one - asm/irq.h + asm/ hw_irq.h. The only legitimate user of linux/irq.h on amd64 was asm/ hardirq.h. Situation elsewhere in arch/* is similar - most of includes are not needed at all. * remove bogus includes, arch by arch for architectures that live in main tree. Switch ones that should've been asm/irq.h to that form. * put the current contents of linux/irq.h to asm-generic/hardirq.h (which is what it really is - declarations for hardirq code, relevant on many but not all platforms). * switch remaining users of linux/irq.h to asm-generic/hardirq.h (again, for architectures that live in main tree) * replace contents of linux/irq.h with #warning and #include . * after 2.6.14 kill linux/irq.h completely. Objections? That variant leaves out-of-tree folks with window until 2.6.15 to convert and that's really more than enough... But Geert Uytterhoeven suggested, "Wouldn't it be more logical to make linux/ irq.h the preferred include? Usually the linux/* versions are preferred over the asm/* versions." Matthew Wilcox replied, "There's almost no reason to want <*/irq.h> in the first place. Almost all drivers really want " But Christoph Hellwig pointed out, " doesn't include and variours achitectures have important prototypes in there." The thread ended here, with not clear determination to prefer linux/ irq.h or asm/irq.h. 2. Linux 2.6.13-mm3 Released 12 Sep 2005 - 18 Sep 2005 (55 posts) Archive Link: "2.6.13-mm3" Topics: Kernel Release Announcement, Profiling People: Andrew Morton Andrew Morton announced Linux 2.6.13-mm3, saying: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm3 / (temp copy at http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-mm3.gz) * perfctr was dropped. Mikael has ceased development and recommends that the focus be upon perfmon. See http://sourceforge.net/mailarchive/forum.php? thread_id=8102899&forum_id=2237 * There are several performance tuning patches here which need careful attention and testing. (Does anyone do performance testing any more?) + An update to the anticipatory scheduler to fix a performance problem where processes do a single read then exit, in the presence of competing I/O acticity. + The size of the page allocator per-cpu magazines has been increased + The page allocator has been changed to use higher-order allocations when batch-loading the per-cpu magazines. This is intended to give improved cache colouring effects however it might have the downside of causing extra page allocator fragmentation. + The page allocator's per-cpu magazines have had their lower threshold set to zero. And we can't remember why it ever had a lower threshold. * Dropped all the virtualisation preparatory patches. Will later pick these up from a git tree which chrisw is running. * There are still quite a few patches here for 2.6.14 (30-50, perhaps). 3. Linux 2.6.14-rc1 Released 12 Sep 2005 - 16 Sep 2005 (56 posts) Archive Link: ""Read my lips: no more merges" - aka Linux 2.6.14-rc1" Topics: Bug Tracking, Digital Video Broadcasting, I2C, Kernel Release Announcement, PCI, Power Management: ACPI People: Linus Torvalds, Peter Osterlund, Chuck Ebbert Linus Torvalds announced Linux 2.6.14-rc1, saying: Ok, it's been two weeks (actually, two weeks and one day) since 2.6.13, and that means that the merge window is closed. I've released a 2.6.14-rc1, and we're now all supposed to help just clean up and fix everything, and aim for a really solid 2.6.14 release. Both the diffstat and the shortlog are so big that I can't post them on the kernel mailing list without getting the email killed by the size restrictions, so there's not a lot to say. alpha, arm, x86, x86-64, ppc, ia64, mips, sparc, um.. Pretty much every architecture got some updates. And an absolutely _huge_ ACPI diff, largely because of some re-indentation. drm, watchdog, hwmon, i2c, infiniband, input layer, md, dvb, v4l, network, pci, pcmcia, scsi, usb and sound driver updates. People may appreciate that the most common wireless network drivers got merged - centrino support is now in the standard kernel. On the filesystem level, FUSE got merged, and ntfs and xfs got updated. In the core VFS layer, the "struct files" thing is now handled with RCU and has less expensive locking. And networking changes. In other words, a lot of stuff all over the place. Be nice now, and follow the rules: put away the new toys, and instead work on making sure the stuff that got merged is all solid. Ok? Anybody with git can do the shortlog with git-rev-list --no-merges --pretty=short v2.6.14-rc1 ^v2.6.13 | git-shortlog | less -S which is actually pretty informative. Peter Osterlund replied: My Compaq Presario R3057EA hangs during ACPI initialization. The last message is "Executing all Device _STA and _INI methods". git bisect told me that: 66759a01adbfe8828dd063e32cf5ed3f46696181 is first bad commit diff-tree 66759a01adbfe8828dd063e32cf5ed3f46696181 (from 049cdefe19f95b67b06b70915cd8e4ae7173337a) Author: Chuck Ebbert <76306.1226@compuserve.com> Date: Mon Sep 12 18:49:25 2005 +0200 [PATCH] x86-64: i386/x86-64: Fix time going twice as fast problem on ATI Xpress chipsets Original patch from Bertro Simul This is probably still not quite correct, but seems to be the best solution so far. Signed-off-by: Linus Torvalds Linus replied, "Ok. That patch has been one big pain, and was clearly totally half-baked. I think I'll disable the automated checks, since they are clearly wrong. You can still enable it manually with a kernel command line." He posted a patch, and Peter said this fixed it for him. In his own defense, Chuck Ebbert said: Well I never meant it to be merged, but Andi picked it up from Bugzilla bug # 3927, added some bugs of his own, then sent it on. This bug was mine, though: just checking for vendor == ATI was a bad idea. Current earlyquirk code actually looks at PCI bridges instead of host bridge, so to get an accurate test I guess it needs to look at PCI dev 00:00.0 and check both vendor and device ID. As new models come out they will have to be added one by one. With a real understanding of what's going on maybe this problem can be solved reliably with generic code, but it's beyond me... 4. Framework For Automatic Kernel Configuration 14 Sep 2005 - 17 Sep 2005 (42 posts) Archive Link: "Automatic Configuration of a Kernel" People: Ahmad Reza Cheraghi, Hua Zhong, Roman Zippel Ahmad Reza Cheraghi said: I wrote this Framework for making a .config based on the System Hardwares. It would be a great help if some people would give me their opinion about it. The readme: http://www.energyparty.de/ahmad/readme The Kernel Patch: www.energyparty.de/ahmad/autoconfig_0_1_patch.tgz (http://www.energyparty.de/ ahmad/autoconfig_0_1_patch.tgz) The sources: http://www.energyparty.de/ahmad/autoconfig_0_1.tgz A lot of folks liked this work. As Hua Zhong put it, "There seems to be a trend that discourages normal users from running kernel.org kernels, but I rarely find myself agree with such mind set." But Roman Zippel was skeptical that Ahmad (or anyone) would have the wherewithal to finish the project. He felt the work involved would be huge, but Ahmad and others felt it would be possible to bypass a lot of the difficulties. At one point elsewhere, Ahmad also said: I want to tell why I came to this Idea of doing that. As I was trying to configurate a Kernel for the first time but without any success. Then I thought about it, why this cannot be automatically. So for the first thought, my spirit of doing this, was for those who doesn't know e.g. what the option "Enable loadable module support" means and if they have to choose that or not. But right now I know that it is not possible to do all the things automatically(like the filesystem, Protokolls...). And that is the reason why I make a Framework, so everybody(I mean the experts) can give theire suggestion what isthe best way to answering, a optione like mention above comes, automatically. So if someone wants to use a new kernel didn't end up desperate and regrated using Linux(a new Kernel). 5. Review Cycle Starts For Linux 2.6.13.2 14 Sep 2005 - 15 Sep 2005 (20 posts) Archive Link: "[PATCH 00/11] -stable review" Topics: FS: JFS, Ioctls, PCI, SMP, Security People: Chris Wright, Martin Mares, David Lang, Andrew Morton, Alexander Nyberg , Manfred Spraul, Ingo Molnar, Marc Lehmann, Linus Torvalds, Dave Kleikamp, Chuck Ebbert, Patrick McHardy, Roland McGrath, Jeff Garzik, Andi Kleen, Andre Hedrick, Adam Kropelin Chris Wright announced the start of the review process leading up to 2.6.13.2, saying: There are 11 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a signed-off-by: line to the patch, please respond with it. These patches are sent out with a number of different people on the Cc: line. If you wish to be a reviewer, please email stable@kernel.org to add your name to the list. If you want to be off the reviewer list, also email us. Responses should be made by Sat Sep 17 01:00 2005 UTC. Anything received after that time, might be too late. He replied to this with a series of patches, whose changelogs follow: * This patch adds lost fput in 32bit tiocgdev ioctl on x86-64 I believe this is a security issues, since user can fget() file as many times as he wants to. So file refcounter can be overlapped and first fput() will free resources though there will be still structures pointing to the file, mnt, dentry etc. Also fput() sets f_dentry and f_vfsmnt to NULL, so other file users will OOPS. The oops can be done under files_lock and others, so this is really exploitable DoS on SMP. Didn't checked it on practice actually. (chrisw: Update to use fget_light/fput_light) Signed-Off-By: Kirill Korotaev Signed-Off-By: Maxim Giryaev Signed-off-by: Chris Wright * This patch adds lost sockfd_put() in 32bit compat rounting_ioctl() on 64bit platforms I believe this is a security issues, since user can fget() file as many times as he wants to. So file refcounter can be overlapped and first fput() will free resources though there will be still structures pointing to the file, mnt, dentry etc. Also fput() sets f_dentry and f_vfsmnt to NULL, so other file users will OOPS. The oops can be done under files_lock and others, so this can be an exploitable DoS on SMP. Didn't checked it on practice actually. Signed-Off-By: Kirill Korotaev Signed-Off-By: Maxim Giryaev Signed-off-by: Chris Wright * Rodiger found a bug in nv_open that explains some of the reports with duplex mismatches: nv_open calls nv_update_link_speed for initializing the hardware link speed registers. If current link setting matches the values in np->linkspeed and np->duplex, then the function does nothing. Usually, doing nothing is the right thing, but not in nv_open: During nv_open, the registers must be initialized because the nic was reset. The attached patch fixes that by setting np->linkspeed to an invalid value before calling nv_update_link_speed from nv_open. Signed-Off-By: Manfred Spraul Signed-off-by: Jeff Garzik Signed-off-by: Chris Wright * This same patch was reported to fix the MAC address detection on sunhme (next patch). Most people seem to be running this on Sparcs or PPC machines, where we get the MAC address from their respective firmware rather than from the (previously broken) ROM mapping routines. Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright * This ports the Sun GEM ROM mapping/enable fixes it sunhme (which used the same PCI ROM mapping code). Without this, I get NULL MAC addresses for all 4 ports (it's a SUN QFE). With it, I get the correct addresses (the ones printed on the label on the card). Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright * In 2.6.13-rcX the MASQUERADE target was changed not to exclude local packets for better source address consistency. This breaks DHCP clients using UDP sockets when the DHCP requests are caught by a MASQUERADE rule because the MASQUERADE target drops packets when no address is configured on the outgoing interface. This patch makes it ignore packets with a source address of 0. Thanks to Rusty for this suggestion. Signed-off-by: Patrick McHardy Signed-off-by: Chris Wright * From Chuck Ebbert: I'm submitting this patch for -stable: o it reportedly fixes an oops o it's already in 2.6.13-git JFS: jfs_delete_inode should always call clear_inode. Signed-off-by: Dave Kleikamp Signed-off-by: Chris Wright * There was a pretty bad bug in there that the code would always check the full VMA, not the range the user requested. When the VMA to be checked was merged with the previous VMA this could lead to spurious failures. Signed-off-by: Andi Kleen Signed-off-by: Chris Wright * It's a dword thing, and the value we write is a dword. Doing a byte write to it is nonsensical, and writes only the low byte, which only contains the enable bit. So we enable a nonsensical address (usually zero), which causes the controller no end of problems. Trivial fix, but nasty to find. Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright * ftdi_sio: I messed up the baud_base for custom baud rate support in 2.6.13. The attached one-liner patch fixes it. Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright * This is one heck of a confused driver. It uses a byte write to a dword register to enable a ROM resource that it doesn't even seem to be using. "Lost and wandering in the desert of confusion" Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright That last one had some discussion. Martin Mares said, "Once upon a time when I was the PCI maintainer, I was arguing with Andre Hedrick about this one and he kept asserting that enabling the ROM is necessary to make the chip work. Not that I believe it :)" There was no reply to this, but close by, David Lang said, "didn't Linus find similar bugs in a couple of the other hpt drivers as well? if so can they be fixed at the same time?" Andrew Morton confirmed, "Adam Kropelin did a sweep and picked up four similar cases. I queued the patches and they should be considered for 2.6.13.3" But Chris said these fixes were already part of the patch. Elsewhere, Alexander Nyberg suggested adding another patch to the stable review series. He said: This might be worth putting in too (has been hit by at least two people in the real world etc.) tree e3a704026e65bf6fea0c7747f0fb75a506f54127 parent 32a3658533c6f4c6bf370dd730213e802464ef9b author Alexander Nyberg Wed, 14 Sep 2005 18:54:06 +0200 committer Linus Torvalds Thu, 15 Sep 2005 00:26:34 -0700 [PATCH] Fix fs/exec.c:788 (de_thread()) BUG_ON It turns out that the BUG_ON() in fs/exec.c: de_thread() is unreliable and can trigger due to the test itself being racy. de_thread() does while (atomic_read(&sig->count) > count) { } ..... ..... BUG_ON(!thread_group_empty(current)); but release_task does write_lock_irq(&tasklist_lock) __exit_signal (this is where atomic_dec(&sig->count) is run) __exit_sighand __unhash_process takes write lock on tasklist_lock remove itself out of PIDTYPE_TGID list write_unlock_irq(&tasklist_lock) so there's a clear (although small) window between the atomic_dec(&sig->count) and the actual PIDTYPE_TGID unhashing of the thread. And actually there is no need for all threads to have exited at this point, so we simply kill the BUG_ON. Big thanks to Marc Lehmann who provided the test-case. Fixes Bug 5170 (http://bugme.osdl.org/show_bug.cgi?id=5170) Signed-off-by: Alexander Nyberg Cc: Roland McGrath Cc: Andrew Morton Cc: Ingo Molnar Acked-by: Andi Kleen Signed-off-by: Linus Torvalds Chris said, yes, he'd add that to the queue for the upcoming release. 6. New CS5535 Audio ALSA Driver 15 Sep 2005 (4 posts) Archive Link: "[RFC 2.6.13.1 1/1] CS5535 AUDIO ALSA driver" Topics: MAINTAINERS File, PCI, Sound: ALSA People: Jaya Kumar, Takashi Iwai, Andrew Morton Jaya Kumar said, "Appended is my patch adding support for the CS5535 Audio device. I've done this patch against 2.6.13.1. I didn't find the CS5535 pci id in pci_ids so I've added those and the remaining pci functions for the CS5535 device as defines there. I don't have the ability to test the chip's SPDIF capability yet. I'll add support for it next. Please let me know if it looks okay so far and if you have any feedback or suggestions." In addition to the technical stuff, Jaya's patch modified the MAINTAINERS file to list himself as maintainer of the CS5535 audio ALSA driver. Takashi Iwai replied with some small glitches in the patch, and Jaya promised to release a fixed version. Several days later, in a different thread, he did, and Andrew Morton discussed the technical details with him. 7. Russell's Projects 15 Sep 2005 (7 posts) Archive Link: "[PATCH] epca iomem annotations + several missing readw()" People: Russell King, Alexander Viro Alexander Viro posted a patch to the EPCA driver, and Cced Russell King in the email. Russell replied, "Thanks for copying me, but I have no interest in any serial driver which doesn't use the serial core interface. I don't want to act as "person to review any change just because the driver says serial" - that's not the role I decided to get involved with." Alexander replied: Hey, seeing the intensity of your complaints about _not_ being Cc'd... Better safe than serial maintainer ;-) OK, so what stuff do you want to be Cc'd on? My current approximation would be arch/arm/*, include/asm-arm/*,drivers/serial/*,include/linux/serial*. Well, and any changes of tty interfaces, if I ever get involved in such... Any additions/ removals? Russell replied: Broadly, it's: arch/arm/* drivers/*/ arm drivers/mfd (this fits at the moment, but whether it will in the future depends /* what else appears there.) drivers/mmc /* drivers/ (though only the drivers in there actually using serial_core - serial* unfortunately some non-serial_core drivers appear to have been placed in there.) include/ asm-arm/* include/ linux/8250* include/ linux/ serial* fs/adfs/* but there are various drivers authored by myself which I'd obviously be interested in CC'ed. 8. Proposed Reorganization For SysFS 15 Sep 2005 - 17 Sep 2005 (27 posts) Archive Link: "[RFC] subclasses in sysfs to solve world peace" Topics: FS: devfs, FS: sysfs, Hot-Plugging, Ottawa Linux Symposium People: Greg KH, Dmitry Torokhov Greg KH said: Ok, first off, I hate talking about architecture changes without showing the code for what I am talking about first, but as this is an issue that needs to be agreed upon by a wide range of developers, I'll just write up what I am thinking about doing before actually doing it... The problem: We need a way to show complex class and class device structures properly in sysfs. Examples of these "complex" views are the input layer's use of different input drivers for devices (usually the same device), the video subsystem view of frame buffer devices and monitors, and even the block layer with it's disks and partitions. Proposed solutions in the past have been either add the ability to nest classes themselves (as shown in Dmitry's recent proposal for fixing the input layer), or add the ability to nest class_device structures (I think others have tried to do this in the past, sorry for not remembering the specifics.) Both of these proposals don't really solve the real problem, that of the fact that we need to come up with a solution that all of the different subsystems can use properly. So, here's my take on it. Feel free to tell me what I messed up :) I would like to add something called "subclasses" for lack of a better term. These subclasses would have both drivers, and devices associated with them. This would show up as the following tree of directories: /sys/class/input/ |-- input0 | |-- event0 | `-- mouse0 |-- input1 | |-- event1 | `-- ts0 |-- mice `-- drivers |-- event |-- mouse `-- ts Here we have 3 struct class_devices like today, input0, input1, and mice. We also have struct subclass_drivers of event, mouse, and ts. These will create the struct subclass_devices event0, mouse0, event1, and ts0. The "dev" node files will show up in the directories mice, event0, mouse0, event1, and ts0, like you would expect them too. So, this lets us create a solution for the input subsystem, but will it also work for block and video? For block, yes, I think so. There is no requirement for a subclass_driver to create the subclass devices. Any code can create and register with the class core a subclass device, just set up the parent pointer and away you go. So, in the following instance: /sys/class/block/ `-- sda |-- sda1 |-- sda2 `-- sda3 "block" would represent the struct class. "sda" would represent the struct class_device. "sda1", "sda2", and "sda3" would represent the different subclass devices that are bound to the class device "sda". And yes, before you all point out the class_interface logic, yes, the subclass_driver stuff looks a lot like this idea. Possibly we could just get rid of the interface stuff and use the subclass_driver logic, but I'd have to look at how people are using the interface logic before I can give a confident answer about that. Hotplug events would be simple with this scheme, the class stuff would remain the same, and the devpath would just point to the subdir (hotplug events would happen for both the class devices and the subclass devices.) And yes, udev and libsysfs would have to be changed to support this, so we better get this right before pushing it out to the world... But, what about video devices? David and Pat, we talked about this at OLS, but Pat kept the paper we drew on, and the beer we were drinking at the time has made my memory a bit fuzzy as to all of your requirements for the video subsystem. I remember things about frame buffers and monitors and other things like that, but nothing specific, sorry. Could you outline your needs and I'll see if this proposed structure would solve your issues? Well, that was a very brief summary, of which I know there are lots of questions for the areas I didn't explain well enough. Comments? Criticisms? Want to see the code before commenting? There was a little discussion, but nothing that resulted in a modification of Greg's proposal. Dmitry Torokhov was the most critical reviewer, saying that Greg's idea did not make it easy to identify all the input interfaces present on the system. He went so far as to suggest abandoning the whole idea of a 'class', because "This way everything will grow from their respective hardware devices. Class represent a set of objects with similar characteristics. In this regard event0 is no "lesser" than input0. Although they are linked they are objects of the same importance. I do want to see all input interfaces without scanning bunch of directories." But Greg just said, "Not going to happen, sorry :)" 9. Linux 2.6.14-rc1-mm1 Released 16 Sep 2005 - 17 Sep 2005 (26 posts) Archive Link: "2.6.14-rc1-mm1" Topics: FS: sysfs, Kernel Release Announcement People: Andrew Morton Andrew Morton announced Linux 2.6.14-rc1-mm1, saying: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc1/ 2.6.14-rc1-mm1/ (temp copy at http://www.zip.com.au/~akpm/linux/patches/stuff/ 2.6.14-rc1-mm1.gz) * Big reiser4 update which is said to address all review comments. * Added version 1 of Dmitry's big sysfs/input revamp. * Lots of tty drivers still don't compile. 10. master.kernel.org Moves To New Home 16 Sep 2005 - 18 Sep 2005 (12 posts) Archive Link: "[KORG] REMINDER: master.kernel.org extended downtime" People: H. Peter Anvin, Michael Marineau, Linus Torvalds, Kees Cook H. Peter Anvin reported: master.kernel.org will be offline starting shortly after 15:00 PDT/22:00 UTC today, September 16, 2005; for a move to the Oregon State University Open Source Lab. This should give much better bandwidth and a more reliable backup solution, in addition to access to a real, staffed NOC. Special thanks to Javier Henderson for volunteering to fly the machine up there by private airplane, thus minimizing downtime. It is expected to be back online around 12:00 PDT/19:00 UTC tomorrow, Saturday, September 17. The new IP address of the machine will be 140.211.167.34. After the move, Michael Marineau replied, "Btw, to any one interested Scott Kveton posted photos of the welcoming party (http://osuosl.org/photos/kernel/ view) here this morning. :-)" Elsewhere, Linus Torvalds remarked, "Well, it's back up and working, but it looks like mirroring to the public kernel.org machines may not have been turned on again?" And Kees Cook said, "It was stalled, but I corrected it about an hour ago. It just finished the first update cycle a little while ago, and it is now working on the full daily sync, which will take a while, and then it'll be back to the regular updates cycles again." 11. Linux 2.6.13.2 Released 16 Sep 2005 (2 posts) Archive Link: "Linux 2.6.13.2" Topics: Ioctls, Networking, PCI, USB People: Chris Wright, Manfred Spraul, Chris Wright:, Linus Torvalds, Dave Kleikamp, Patrick McHardy, Andi Kleen, Willy Tarreau Chris Wright announced Linux 2.6.13.2, saying: We (the -stable team) are announcing the release of the 2.6.13.2 kernel. The diffstat and short summary of the fixes are below. I'll also be replying to this message with a copy of the patch between 2.6.13.1 and 2.6.13.2, as it is small enough to do so. The updated 2.6.13.y git tree can be found at: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/chrisw/linux-2.6.13.y.git and can be browsed at the normal kernel.org git web browser: www.kernel.org/git/ (http://www.kernel.org/git/) Note: The above info won't be valid until master.kernel.org is back online. In the interim you can find the tarball, patches, changelogs etc. at Summary of changes from v2.6.13.1 to v2.6.13.2 Andi Kleen: Fix MPOL_F_VERIFY Chris Wright: Linux 2.6.13.2 Dave Kleikamp: jfs: jfs_delete_inode must call clear_inode Ian Abbott: USB: ftdi_sio: custom baud rate fix Linus Torvalds: hpt366: write the full 4 bytes of ROM address, not just low 1 byte Sun GEM ethernet: enable and map PCI ROM properly Fix up more strange byte writes to the PCI_ROM_ADDRESS config word Manfred Spraul: forcedeth: Initialize link settings in every nv_open() Maxim Giryaev: lost fput in 32bit ioctl on x86-64 Lost sockfd_put() in routing_ioctl() Patrick McHardy: Fix DHCP + MASQUERADE problem Willy Tarreau: Sun HME: enable and map PCI ROM properly 12. git 0.99.7 Released; Cogito 0.15 Released 18 Sep 2005 - 20 Sep 2005 (7 posts) Archive Link: "[ANNOUNCE] GIT 0.99.7" Topics: Spam People: Junio C. Hamano, Petr Baudis, Pavel Machek, Linus Torvalds, Nigel Cunningham Junio C. Hamano said: I am hoping that sending this out to the kernel list is not considered too much of useless spamming, but I promise I wouldn't do thit next time for 0.99.8, if I hear from somebody not to. Here comes GIT 0.99.7 Done in 0.99.7 Organization Some commands and most scripts are renamed for consistency. * We have an official standard terminology list (http://www.kernel.org/pub/ software/scm/git/docs/glossary.html) . To match this, commands that operate on index files now have 'index' instead of 'cache' in their names, and ones that download are called 'fetch' instead of 'pull'. * We used to install most of the commands that happen to be implemented as scripts as 'git-*-script', which was cumbersome to remember and type unless you always used 'git' wrapper. They lost '-script' suffix from their names. For now, we install synonyms as symbolic links so that old names continue to work, but they are planned to be removed in 0.99.8 (or later if there are enough objections on the list -- so far I have heard none). Also ancient environment variables (SHA1_FILE_DIRECTORIES AUTHOR_DATE AUTHOR_EMAIL AUTHOR_NAME COMMIT_AUTHOR_EMAIL COMMIT_AUTHOR_NAME SHA1_FILE_DIRECTORY) are not supported anymore. New Features and Commands Downloaders that are not fully git aware have been taught about the mechanism to borrow objects from other repositories via objects/info/alternates the server side may be using. 'git fetch' and 'git pull' commands over rsync and http transport should be able to handle such repositories (But not grafts). People found interesting cases where the 'stupid' three-way merge mechanism does the wrong thing without noticing. We have two new merge algorithms by Daniel and Fredrik that attempt to do better in such cases. A new 'git merge' command has been introduced to make it easier to experiment with and choose among different merge strategies. Note that 'git pull' still uses the traditional three-way merge after downloading, but it is expected to be switched to use 'git merge' sometime in the future. Importing from tla archives has been improved and documentated. 'git branch' command acquired '-d' flag to delete a branch that has already been merged into the current branch. 'git bisect' command is easier to use by logging the earlier good/bad choices and make it replayable. 'git repack' has -a' flag to pack the whole repository into a single pack. 'git grep' is a new command to run grep on files 'git' knows about. Fixes * 'git-diff-*' commands used to mark copy/rename incorrectly when an (A,B) => (B,C) rename was made. We said the new B is a copy of old A, not a rename of old A. * When the user exported CDPATH into environment, 'cd' took scripts to unexpected places. Unset it upfront to guard us. * 'git format-patch' knows about 'git cherry' and skips patches already merged upstream. * hopefully plugged memory leak in diffcore-rename properly. * commit walkers incorrectly assumed having a commit means we have the whole history leading up to it -- which is not true if the previous download was interrupted. As a safety measure, we now only trust the commits that are pointed by the existing refs. * 'git rev-list' uses a lot less memory. * The build should be a bit friendlier to Solaris and Darwin now. * 'git ssh-{push,pull}' are friendlier to tcsh. * http transport is nicer to caching proxies. * 'git daemon' port is registered with IANA. * Many documentation updates. Nigel Cunningham asked for a URL, and Chris White pointed to the kernel.org page (http://www.kernel.org/pub/software/scm/git/) . Elsewhere, Petr Baudis took the opportunity to announce: this is the release of Cogito-0.15. It fixes several minor bugs, and adds a feature or two. The most important thing though is that this depends on Git-core-0.99.7 and uses the new command names. Everyone is encouraged to upgrade at least to this Cogito version in the next few days, since the older Cogito versions likely won't work with the future Git-core releases. To stay in sync with the Git terminology, Cogito also renames its cg-pull to cg-fetch. Since this is a major naming change (I'm not too happy about it, personally), cg-pull will stay aliased to cg-fetch for at least one (likely two) next major Cogito releases (it also produces a warning when invoked as cg-pull). In the more distant future, cg-pull will slowly become the new name of cg-update, to make it confusing. While at it, we also renamed the *-id scriptlets to cg-*-id. Other notable stuff is cg-init respecting the ignore rules, and better UI for cg-add wrt. directories (including cg-add -r support). Now let's see what the usual bug-right-after-release (major release, so a major bug?) will be this time. Pavel Machek asked, "Could we keep at least the cg-update name? It is certainly not a *pull* because it does update local repository (and tree, too)." Petr replied, "AIUI, that's what makes it a pull for *cough* some people. ;-)" He added, "I want to retain it. I'm not 100% decided yet whether to actually use the pull term for anything in Cogito. Previous usage reportedly confused some, the new usage actually confuses me and apparently some other people. So I might just avoid the 'pull' term in the future altogether. Not decided yet, though, and opinions obviously welcomed." Linus Torvalds also replied to Pavel, saying that he was the "some people" Petr referred to. He said updating a local repository from a remote was exactly what "pull" meant. He added, ""fetch" is the one that only updates the history. A "pull" also does a merge and updates the current branch _and_ the currently checked out tree." 13. Status Of PWC Driver 19 Sep 2005 (3 posts) Archive Link: "PWC 10.x driver in the kernel?" Topics: Philips Webcam Driver, Spam People: Joshua Kwan, Alistair John Strachan Joshua Kwan asked, "I've just acquired a Logitech webcam and I couldn't get it to work with the version of the PWC driver currently in the kernel. Given all the contention about PWCX etc., are there plans to merge in the new 10.x version of the driver available at http://www.saillard.org/linux/pwc/? (This version does work with my webcam.) Just like the one in the kernel tree right now, this version does not require pwcx at all (the binary blob was reverse-engineered), so I think it's a big improvement," Alistair John Strachan replied, "Even if the reverse engineered component was deemed unacceptable, I'd like to see the (other) differences between the two drivers merged ASAP. AFAIK, the 10.x pwc driver supports the v4l2 API which is useful, and as you mentioned actually works on more camera (the 9.x versions just spam errors to dmesg on my PWC740K)." But there was no further discussion. 14. Linux 2.6.14-rc2 Released 19 Sep 2005 - 21 Sep 2005 (38 posts) Archive Link: "Arrr! Linux v2.6.14-rc2" Topics: Disks: SCSI, Kernel Release Announcement, Sound: ALSA People: Linus Torvalds, Martin J. Bligh, James Bottomley On International Talk-like-a-pirate Day (http://www.talklikeapirate.com/ piratehome.html) , Linus Torvalds announced Linux 2.6.14-rc2, saying: Ahoy landlubbers! Here be t' Linux-2.6.14-rc2 release. Not a whole lot o' excitement, ye scurvy dogs, but it has t' ALSA, LSM, audit and watchdog merges that be missed from -rc1, and a merge series with Andrew. But on t' whole pretty reasonable - you can see t' details in the shortlog (appended). Arrr! Martin J. Bligh, with absolutely no smile, reported, "SCSI is broken in several cases by a lack of the patch below, which means some of the regular test boxes can't - James, any chance of getting that one upstream?" James Bottomley replied, "It already is ... unfortunately just after 2.6.14-rc2, but if you use the latest git head you should get it." And Martin was pleased. 15. kprobes Maintainership 21 Sep 2005 (1 post) Archive Link: "Updating maintainers list with the kprobes maintainers" People: Prasanna S. Panchamukhi, David S. Miller, Ananth N. Mavinakayanahalli Prasanna S. Panchamukhi posted a patch to list himself, Ananth N. Mavinakayanahalli, Anil S. Keshavamurthy, and David S. Miller as official maintainers of kprobes. There was no discussion. 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.