Kernel Traffic #329 by Zack Brown
[email protected] Mon, 26 Sep 2005 08:06:46 -0700
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #329 For 26 Sep
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 9 Sep - 15 Sep (5 posts) Using linux/irq.h Or asm/irq.h In Drivers
2. 12 Sep - 18 Sep (55 Linux 2.6.13-mm3 Released
posts)
3. 12 Sep - 16 Sep (56 Linux 2.6.14-rc1 Released
posts)
4. 14 Sep - 17 Sep (42 Framework For Automatic Kernel
posts) Configuration
5. 14 Sep - 15 Sep (20 Review Cycle Starts For Linux 2.6.13.2
posts)
6. 15 Sep (4 posts) New CS5535 Audio ALSA Driver
7. 15 Sep (7 posts) Russell's Projects
8. 15 Sep - 17 Sep (27 Proposed Reorganization For SysFS
posts)
9. 16 Sep - 17 Sep (26 Linux 2.6.14-rc1-mm1 Released
posts)
10. 16 Sep - 18 Sep (12 master.kernel.org Moves To New Home
posts)
11. 16 Sep (2 posts) Linux 2.6.13.2 Released
12. 18 Sep - 20 Sep (7 posts) git 0.99.7 Released; Cogito 0.15 Released
13. 19 Sep (3 posts) Status Of PWC Driver
14. 19 Sep - 21 Sep (38 Linux 2.6.14-rc2 Released
posts)
15. 21 Sep (1 post) kprobes Maintainership
Mailing List Stats For This Week
We looked at 2114 posts in 13MB.
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), )|
|[email protected] |" |
|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" |
+-----------------------------------------------------------------------------+
Full Statistics generated by mboxstats version 2.8
1. Using linux/irq.h Or asm/irq.h In Drivers
9 Sep - 15 Sep (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 <asm-generic/
hardirq.h>.
* 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 <linux/
interrupt.h>" But Christoph Hellwig pointed out, "<linux/interrupt.h> doesn't
include <asm/irq.h> 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 - 18 Sep (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 - 16 Sep (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 <[email protected]>
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 <[email protected]>
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 - 17 Sep (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 - 15 Sep (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 [email protected] 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 <[email protected]>
Signed-Off-By: Maxim Giryaev <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
* 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 <[email protected]>
Signed-Off-By: Maxim Giryaev <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
* 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 <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
* 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 <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
* 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 <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
* 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 <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
* 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 <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
* 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 <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
* 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 <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
* 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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
* 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 <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
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 <[email protected]> Wed, 14 Sep 2005 18:54:06 +0200
committer Linus Torvalds <[email protected]> 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 <[email protected]>
Cc: Roland McGrath <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Ingo Molnar <[email protected]>
Acked-by: Andi Kleen <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Chris said, yes, he'd add that to the queue for the upcoming release.
6. New CS5535 Audio ALSA Driver
15 Sep (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 (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 - 17 Sep (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 - 17 Sep (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 - 18 Sep (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 (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 <http://
developer.osdl.org/chrisw/stable/2.6.13.2/>
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 - 20 Sep (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 (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 - 21 Sep (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 (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.