Kernel Traffic #281 by Zack Brown
[email protected] Sat, 30 Oct 2004 09:01:23 -0700
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #281 For 30 Oct
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 22 Sep - 8 Oct (36 Linux 2.6.9-rc2-mm2 Released; Various Config
posts) Options Break ia64 In Various Kernels
2. 4 Oct - 13 Oct (11 Prototype Of NFS Caching Files Locally Via
posts) CacheFS
3. 4 Oct - 8 Oct (21 Special Serial Flow Control For Some Braille
posts) Terminals
4. 7 Oct - 8 Oct (41 Linux 2.6.9-rc3-mm3 Released
posts)
5. 7 Oct (2 udev 034 Released; udev Web Page Created
posts)
6. 8 Oct - 11 Oct (20 Some Issues Of Infiniband Patents
posts)
7. 9 Oct - 12 Oct (16 iswraid Going Into 2.4; Device Mapper Subsystem
posts) Too Invasive For Inclusion
8. 10 Oct - 12 Oct (35 Linux 2.6.9-rc4 Released
posts)
Mailing List Stats For This Week
We looked at 1634 posts in 9476K.
There were 454 different contributors. 247 posted more than once. 188 posted
last week too.
The top posters of the week were:
* 62 posts in 350K by Andrew Morton
* 33 posts in 133K by Hanna Linder
* 32 posts in 113K by Alan Cox
* 29 posts in 121K by Nick Piggin
* 28 posts in 91K by Lee Revell
* Full Stats
1. Linux 2.6.9-rc2-mm2 Released; Various Config Options Break ia64 In Various
Kernels
22 Sep - 8 Oct (36 posts) Archive Link: "2.6.9-rc2-mm2"
Topics: FS: ext3, Kernel Release Announcement, Kexec, SMP
People: Andrew Morton, Jesse Barnes, Tony Luck
Andrew Morton announced Linux 2.6.9-rc2-mm2, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc2/
2.6.9-rc2-mm2/
+ Added Bart's bk-ide-dev tree to the -mm external tree lineup.
+ Added Peter Williams' Single Priority Array (SPA) O(1) CPU Scheduler,
aka the "zaphod" cpu scheduler.
It has a number of tunables and lots of documentation - see the
changelog entry in zaphod-scheduler.patch for details.
+ This kernel doesn't work on ia64 (instant reboot). But neither does
2.6.9-rc2, nor current Linus -bk. Is it just me?
+ Added the kexec-based crashdump code. This is the code which uses kexec
to jump into a new mini-kernel when the main kernel crashes. Userspace
code in that mini-kernel then dumps the main kernel's memory to disk.
These new patches provide the bits and pieces which the mini-kernel
needs to be able to get at the main kernel's memory.
There seem to be no hints as to how to get all this working - that will
come.
+ Found (and fixed) the bug which was causing those
ext3-goes-readonly-under-load problems. It was in the new wait/wakeup
code.
Responding to this and other kernels booting on ia64, Jesse Barnes said,
"Current bk works on my 2p Altix, and iirc 2.6.9-rc2 worked as well. I'm trying
2.6.9-rc2-mm2 right now. I haven't tried generic_defconfig yet either, maybe
that's it?" Andrew posted his config file, but Jesse couldn't find anything
suspicious in it. Elsewhere, Jesse speculated, "Maybe this is another, more
severe instance of the problem James reported last week that was worked around
by enabling CONFIG_DISCONTIGMEM." Andrew replied, "It looks like Tony is
wearing the BPB." [Brown Paper Bag] "The below patch from September 8 is what
causes my non-discontigmem virtual-mem-map ia64 box instantly reboot. Reverting
it makes things happy." He also asked a "Process question: how is it possible
that the ia64 tree could have been this dead for this long?" Tony Luck replied,
"Because we have immense confusion about which combinations of config options
(NUMA, DISCONTIG, VIRTUAL_MEM_MAP, SMP) are supported. Kconfig allows almost
any combination of them, but on any given week only some combinations work. The
patch that broke things for you came in to fix a problem for Peter." He said
he'd investigate further.
2. Prototype Of NFS Caching Files Locally Via CacheFS
4 Oct - 13 Oct (11 posts) Archive Link: "[PATCH] NFS using CacheFS"
Topics: FS: CacheFS, FS: NFS, Networking, POSIX
People: Steve Dickson, Trond Myklebust
Steve Dickson said to Trond Myklebust:
Here here is the first stab at having NFS use the CacheFS that is currently
in the -mm tree. As you know CacheFS is a caching filesystem that allows
network filesystems, such as AFS and now NFS, to cache data pages on the
local disk. This is a big win (especially with read-only filesystems) since
it drastically cuts down on the amount of data read across the network.
Plus the cached data survives umounts and reboots (since CacheFS journals
the data). So when a client comes back up or the filesystem is remounted,
all that is needed is a few small getattrs to insure the data is still
valid. If it is, NFS reads are turned into local disk reads.... A Huge gain
in performance!!!!
I have structured that patch so CacheFS is a mount option. I figured this
was the safest way to introduce CacheFS and not completely break NFS....
And if for some reason, NFS is not able to get an initial Cachefs cookie
(i.e. it can't use CacheFS) , NFS will dynamically turn off the mount
option, disabling the use of the cache..
But as usual there are some issues....
1. NFS aliasing. The fact that:
mount hades:/hades /a
mount hades:/hades/xxx /b
creates separate super blocks causes problems for CacheFS. With the
current -mm code, these type of mount actual causes CacheFS to crash
(although I do have a proposed patch that David is looking at).
2. NFS4 is not supported. I simply have not had time to get this working.
But I will!!
3. There is no user level support. I realize this is extremely cheesy but
I noticed that the NFS posix mount option (in the 2.6 kernel) was no
longer being used, so I high jacked it. Which means to make NFS to used
CacheFS you need to use the posix option:
mount -o posix server:/export/home /mnt/server/home
PS. The new CacheFS mailing that have been set up is at http://
www.redhat.com/mailman/listinfo/linux-cachefs I encourage you and anybody
else interested in this type of technology to subscribe....
Trond replied, regaring using the posix option in mount:
This is my one and only real gripe about it. The posix mount option is
clearly documented, so we really cannot play around with it. Why can't you
just add a separate cachefs flag?
Otherwise, I'm a bit dubious about the wisdom of putting nfs_invalidatepage
() and nfs_releasepage() into fs/nfs/file.c. These are not file operations,
but rather pure page cache operations. I would have thought that either
read.c or possibly nfs-cachefs.c would be more appropriate.
Please note too that Chuck has made generic functions for copying and
comparing NFS filehandles. They should be used in nfs_cache_fh_match() &
co. I'm a bit worried about the use of the raw IP address in
nfs_cache_server_match(). It seems to me that when we add the NFSv4.1
support for trunking over several different transport mechanisms (RDMA,
IPv4/v6 etc) on the same mountpoint, then we may end up with a problem. We
can probably leave it in for now, but later we may want to consider
switching to using server->hostname or something equivalent.
Otherwise, it looks good. Looking forward to try it out...
Clemens Schwaighofer also liked the idea of a CacheFS flag, and David said that
the current behavior was just a convenience for prototyping, that could be done
away with later. Steve Dickson confirmed, "it was the easiest way to get things
started (i.e. no userlevel changes needed at all).... The 'fscache' flag will
be coming along with the nfs4 support, since nfs4 mounting code does not have
an open (unused) mounting flag...."
3. Special Serial Flow Control For Some Braille Terminals
4 Oct - 8 Oct (21 posts) Archive Link: "[Patch] new serial flow control"
Topics: Braille, Ioctls
People: Samuel Thibault
Samuel Thibault said:
Some Visiobraille braille terminals (TVB) need a peculiar serial flow
control:
+ There is no flow control for the PC -> device way (yes, oddly enough)
+ For the device -> PC way,
o RTS must be kept low, the device keeps CTS low as well.
o when the device wants to send data, it raises CTS. RTS must be
raised as well. Data can then pass, CTS and RTS are lowered.
We tried to implement that in user space, with ioctl(TIOCMBIS) & al, but
the responsiveness is too low: RTS is not raised soon enough, and the
device aborts transmission.
Here is a patch for 2.4, a 2.6 patch is coming in another mail. It defines
a CTVB flag the same way CRTSCTS is defined, letting user space choose
whether to use it or not (better ideas for the name are welcome). This
makes the device work perfectly (even better than shipped drivers for DOS).
Applying it to vanilla kernel would be a real good thing for people having
such costly and useful hardware.
A minute later he posted a 2.6 patch as well.
4. Linux 2.6.9-rc3-mm3 Released
7 Oct - 8 Oct (41 posts) Archive Link: "2.6.9-rc3-mm3"
Topics: Kernel Release Announcement
People: Andrew Morton
Andrew Morton announced Linux 2.6.9-rc3-mm3, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc3/
2.6.9-rc3-mm3/
+ The zaphod scheduler was dropped - we have some performance-related
changes here which need testing.
+ Various fixes, updated patches, etc.
+ sparc64 and ppc64 successfully compile again.
5. udev 034 Released; udev Web Page Created
7 Oct (2 posts) Archive Link: "[ANNOUNCE] udev 034 release"
Topics: FS: devfs, FS: sysfs, Hot-Plugging, Version Control
People: Greg KH, Greg KH
Greg KH said:
I've released the 034 version of udev. It can be found at: kernel.org/pub/
linux/utils/kernel/hotplug/udev-034.tar.gz (http://www.kernel.org/pub/linux
/utils/kernel/hotplug/udev-034.tar.gz)
(hm, last announcement I sent out was for 031, sorry about that...)
udev allows users to have a dynamic /dev and provides the ability to have
persistent device names. It uses sysfs and /sbin/hotplug and runs entirely
in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG enabled to run.
Please see the udev FAQ for any questions about it: kernel.org/pub/linux/
utils/kernel/hotplug/udev-FAQ (http://www.kernel.org/pub/linux/utils/kernel
/hotplug/udev-FAQ)
For any udev vs devfs questions anyone might have, please see: kernel.org/
pub/linux/utils/kernel/hotplug/udev_vs_devfs (http://www.kernel.org/pub/
linux/utils/kernel/hotplug/udev_vs_devfs)
Lots of good bugfixes have happened since the 031 release, and some major
enhancements:
+ SELinux support is back in, thanks to Red Hat.
+ a new helper program, wait_for_sysfs, is installed as the first program
in the hotplug chain. If this program spits out any log messages,
please forward them to the email address it tells you to, and we will
fix the code.
+ scsi_id is updated to the latest version
+ volume_id now builds on Gentoo based systems.
Thanks to everyone who has send me patches for this release, a full list of
everyone, and their changes is below.
udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev
Daily snapshots of udev from the BitKeeper tree can be found at: http://
www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.
Half an hour later, he also said:
Ok, I finally broke down and created what has to be the simplest web page
ever for udev. It's available at: http://www.kernel.org/pub/linux/utils/
kernel/hotplug/udev.html
Thanks a lot to Kay Sievers for the udev image.
If anyone wants to clean up the page to make it all pretty looking, please
feel free to send me an updated version.
6. Some Issues Of Infiniband Patents
8 Oct - 11 Oct (20 posts) Archive Link: "InfiniBand incompatible with the
Linux kernel?"
Topics: Disks: IDE, Disks: SCSI, Microsoft, Patents, USB
People: Greg KH, Eric W. Biederman, Jeff Garzik, Roland Dreier, Alan Cox, Greg
KH , Francois Romieu
Greg KH said:
Enough people have been asking me about this lately, that I thought I would
just bring it up publicly here.
It seems that the Infiniband group (IBTA) has changed their licensing
agrement of the basic Infiniband spec. See: http://www.theinquirer.net/?
article=18922 for more info about this.
The main point that affects Linux is the fact that now, no non-member of
the IBTA can implement any working Infiniband code, otherwise they might
run into legal problems. As an anonymous member of a IBTA company told me:
If someone downloads the spec without joining the IBTA, and proceeds to
use the spec for an implementation of the IBTA spec, that person
(company) runs the risk of being a target of patent infringement claims
by IBTA members.
Another person, wanting to remain anonymous stated to me:
In justification for this position people say that they are just trying
to get more people to join the IBTA because they need the dues, which
by coincidence are $9500 per year, and point out that some other
commonly used specs are similarly made available for steep prices. I
don't know one way or the other about that but this sounds a lot like
the reason that we all gave ourselves for NOT including SDP in the
kernel[1].
So, even if a IBTA member company creates a Linux IB implementation, and
gets it into the kernel tree, any company who ships such a implementation,
who is not a IBTA member, could be the target of any patent infringement
claims[2].
So, OpenIB group, how to you plan to address this issue? Do you all have a
position as to how you think your code base can be accepted into the main
kernel tree given these recent events?
Eric W. Biederman replied:
Greg I see nothing to back up the idea that IBTA intends to go after
non-members. I simply see a disclaimer of warranty, and I see wording by
your anonymous source that restates a disclaimer of warranty.
Until I see something more to back this up I do not see a problem. In fact
I see infiniband prices dropping, and competition increasing. The drivers
off of openib.org look like they are a good start at making a sane linux
implementation.
Even the PCI-SIG requires you to pay for the spec.
I agree it would be suicidally insane for the infiniband trade association
to go after a linux stack, as it appears that a large portion of the
infiniband users are currently running linux.
Given the vendors I have seen working on hardware and the vendors who are a
part of the infiniband trade association there does appear to be a certain
amount of disconnect between the two. So this may be an attempt to bring
all of the interested parties together.
Jeff Garzik replied:
Well, let's not rely on anonymous sources and go straight to the web site,
shall we?
Ordering copies of the spec, for non-members: http://www.infinibandta.org/
specs/How_to_Order_IBTA_Specifications.pdf
Key note: use of spec is only granted for NON-COMMERCIAL use
Now, let's look at the membership agreement for IBTA: http://
www.infinibandta.org/meminfo/mem-agreement.pdf
Key note: The point is made repeatedly that there are no patent grants
simply by being a member.
Elsewhere, Roland Dreier remarked:
The increase in cost for the spec is rather unfortunate but I think it's
orthogonal to any IP issues. Since the Linux kernel contains a lot of code
written to specs available only under NDA (and even reverse-engineered code
where specs are completely unavailable), I don't think the expense should
be an issue.
As for IP, as far as I know, there has been no change to any of the bylaws
or other members agreements. If there is some specific provision that
concerns you, please bring it to our attention -- the IBTA in general and
the IBTA steering committee in general have been very supportive of the
OpenIB effort. In fact, most of the IBTA steering commitee companies
(Agilent, HP, IBM, InfiniCon, Intel, Mellanox, Sun, Topspin, and Voltaire)
have been active participants in OpenIB development. I would hope we can
resolve any issues relating to open source and the Linux kernel.
However, I would suspect that we'll find the USB, Firewire, Bluetooth,
etc., etc. standards bodies all have very similar IP language in their
bylaws and licenses.
Francois Romieu was dismayed to hear that some portions of the Linux kernel
were written under NDA restrictions regarding the underlying specs, and felt
this dealt a terrible blow to peer review. But Roland replied, "Yes and no.
Certainly people without specs can't review spec compliance, but review for
coding style, locking bugs, etc. is if anything more valuable."
Greg KH also pointed out to Roland that an agreement had changed: "The
"purchase a spec" agreement has changed, right?" To which Roland replied:
Good point. I think the right way to understand this is that the purchase
agreement and the $9500 cost is intended to discourage anyone from actually
buying the spec -- for the same money you can become a full IBTA member so
why shell out for the spec with more restrictions?
This might be counterproductive but I don't think there's anything sinister
behind it.
Jeff also pointed out to Roland that the member agreement "-explicitly- does
-not- require waiving of patent claims related to any implementation of IB.
That's different from ATA, SCSI, USB, the list goes on..." Roland replied:
Fair enough, but read the Bluetooth SIG patent agreement (https://
www.bluetooth.org/foundry/sitecontent/document/
Patent_and_Copyright_License_Agreement) . As far as I can tell, all it
requires is that other SIG members receive a patent license. Do we need to
do rm -rf net/bluetooth? IEEE only requires that patents be licensed under
RAND terms (http://standards.ieee.org/guides/bylaws/sect6-7.html#6) (it
does not even require royalty free licensing). Time for rm -rf drivers/
ieee1394?
The code that we have written so far is pretty standard driver code, so I
have a hard time believing that the IB drivers are any more at risk than
any other Linux code. There may be good and valid reasons not to merge IB
drivers upstream, but I'd be very disappointed if this FUD about patents is
what keeps them out.
Jeff replied, "If there is questionable code, that is _not_ a justification to
add more." But Roland said:
my point was not that the bluetooth stack is somehow questionable, but
rather that the IP policies of a standards bodies are really not a good
reason to keep code out of the kernel. If someone can name one patent that
the IB driver stack looks like it might possibly run into, then we would
have to take that very seriously. However, no one has done this here -- all
we have is FUD or guilt by association or whatever you want to call it.
The mere fact that the IBTA bylaws only require members license their
patents under RAND terms shouldn't be an issue. If nothing else, the fact
that there are hugely more non-IBTA member companies than member companies
who might have patents makes the IBTA bylaws almost a moot point.
For what its worth, I know of at least five companies shipping IB stacks
and the only patent licensing that I know of is the Microsoft SDP license,
and even that is really just CYA: all Microsoft says is that they _might_
have patents that cover SDP and that they will license them at no cost to
anyone who wants them; unfortunately this license is not GPL-compatible,
but for proprietary stacks the zero-cost terms look fine. There are people
who have looked at Microsoft's patents and concluded that none of them
actually apply to SDP as specified by the IBTA.
Alan Cox asked, "The big question seems to be about the standard itself. Are
the items at issue hardware or software ? We already deal with a lot of devices
that have hardware related patent pools and those by themselves don't seem to
cause problems." And Roland said:
As far as I know there are no items at issue. No one has suggested that
there actually are any patents to worry about. The big complaint is just
that the IBTA member companies haven't made enough promises about their
patents.
The OpenIB subversion repository can be checked out by anyone interested.
Anyone who wants to can look the code over and look for something patent
encumbered.
7. iswraid Going Into 2.4; Device Mapper Subsystem Too Invasive For Inclusion
9 Oct - 12 Oct (16 posts) Archive Link: "[Announce] "iswraid" (ICH5R/ICH6R
ataraid sub-driver) for 2.4.28-pre3"
Topics: Device Mapper, Disk Arrays: LVM, Disk Arrays: RAID, Disks: IDE, Disks:
SCSI, MAINTAINERS File, Serial ATA
People: Martins Krikis, Alan Cox, Marcelo Tosatti, Jeff Garzik, Bartlomiej,
Bartlomiej Zolnierkiewicz
Martins Krikis said:
Version 0.1.4.3 of the Intel Sofware RAID driver (iswraid) is now available
for the 2.4 series kernels at http://prdownloads.sourceforge.net/iswraid/
2.4.28-pre3-iswraid.patch.gz?download
It is an ataraid "subdriver" but uses the SCSI subsystem to find the RAID
member disks. It depends on the libata library, particularly the ata_piix
driver that enables the Serial ATA capabilities in ICH5/ICH6 chipsets.
Hence, for kernels older than 2.4.28, the libata patch by Jeff Garzik
should be applied before applying this patch. There is more information and
some ICH6R related patches at the project's home page at http://
iswraid.sourceforge.net/. The patch applies cleanly to 2.4.28-pre4 as well,
and hopefully can be applied to any 2.4 kernel without too much difficulty.
The changes WRT version 0.1.4 are the following:
+ Different buffer_head b_state bit used for IOs submitted to the mirror.
+ Disk sizing problem for disks with odd number of sectors fixed.
+ Entering degraded mode with many outstanding IOs fixed.
Please consider this driver for inclusion in the 2.4 kernel tree.
Driver documentation is included in Documentation/iswraid.txt, which is
part of the patch. The license is GPL. I have added myself to the
MAINTAINERS list, please feel free to throw me out if you don't think I
should have done that.
Please let me know if there is anything else I can do to make this driver
acceptable for the 2.4 kernel.
Alan Cox liked seeing this work, remarking, "This seems to make sense to me -
for 2.6 we have the DM layer, for 2.4 we've used the ataraid stuff."
But elsewhere, Bartlomiej Zolnierkiewicz asked why the DM layer couldn't be
merged into 2.4 instead. A patch already existed, and including the same
functionality in 2.4 and 2.6 would ease the upgrade path. Jeff Garzik felt this
new subsystem would introduce too great a change into a 'stable' series kernel;
but Bartlomiej quoted an email by Marcelo Tosatti, in which Marcelo had said,
"New drivers are OK, as long as they dont break existing setups, and if
substantial amount of users will benefit from it." Bartlomiej felt both
conditions were satisfied, but Jeff remarked that there was a big difference
between a driver and a full subsystem. They began arguing the various merits,
but Marcelo quickly weighed in with Jeff, saying:
We already have device mapper "like" functionality in v2.4 with RAID/LVM.
I dont think that merging device mapper is an option really, not in my
opinion.
It seems the general consensus is to merge iswraid, so I'm fine with it.
8. Linux 2.6.9-rc4 Released
10 Oct - 12 Oct (35 posts) Archive Link: "Linux 2.6.9-rc4 - pls test (and no
more patches)"
Topics: Kernel Release Announcement, Power Management: ACPI
People: Linus Torvalds
Linus Torvalds announced Linux 2.6.9-rc4, saying:
trying to make ready for the real 2.6.9 in a week or so, so please give
this a beating, and if you have pending patches, please hold on to them for
a bit longer, until after the 2.6.9 release. It would be good to have a
2.6.9 that doesn't need a dot-release immediately ;)
The appended shortlog gives a pretty good idea of what has been going on.
Mostly small stuff, with some architecture updates and an ACPI update
thrown in for good measure.
(The ACPI update fixes broken AML with implied returns, and in particular
the Compaq Evo notebook fan control. Yay! Guess who has one..)
We Hope You Enjoy Kernel Traffic
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.