Kernel Traffic #304 by Zack Brown
[email protected] Sun, 03 Apr 2005 19:39:30 -0700
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #304 For 3 Apr
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 3 Mar - 19 Mar (20 Secure Digital (SD) Support For 2.6
posts)
2. 11 Mar - 17 Mar (38 New timeofday Core Subsystem
posts)
3. 14 Mar - 21 Mar (41 Status Of SquashFS
posts)
4. 16 Mar - 23 Mar (28 Linux 2.6.11-mm4 Released
posts)
5. 17 Mar - 19 Mar (13 Minimal Open Source BitKeeper Client
posts) Available
6. 17 Mar - 18 Mar (5 New VXEXT Filesystem Version 1.0 Announced
posts)
7. 18 Mar (9 New DM9000 Network Driver
posts)
8. 18 Mar - 20 Mar (4 Linux 2.6.11.5 Released; Trouble Identifying
posts) Authors
9. 20 Mar (6 Generating Kernel Command-Linux Documentation
posts) From Source
10. 23 Mar (2 USB Block Driver Maintainership; Yamaha PCI
posts) Sound Maintainership
Mailing List Stats For This Week
We looked at 1947 posts in 11MB.
There were 670 different contributers. 252 posted more than once. The average
length of each message was 94 lines.
The top posters of the week The top subjects of the week were:
were:
119 posts in 587KB by Andrew
Morton 57 posts in 388KB for "Real-Time Preemption and
51 posts in 385KB by RCU"
Johannes Stezenbach 54 posts in 222KB for "AGP bogosities"
46 posts in 211KB by Adrian 50 posts in 239KB for "[PATCH 1/5] freepgt:
Bunk free_pgtables use vma list"
42 posts in 328KB by Jesper 42 posts in 160KB for "Linux 2.6.11.2"
Juhl 30 posts in 125KB for "[PATCH] Xen/i386 cleanups -
40 posts in 118KB by Jan AGP bus/phys cleanups"
Engelhardt
Full Statistics generated by mboxstats version 2.2
1. Secure Digital (SD) Support For 2.6
3 Mar - 19 Mar (20 posts) Archive Link: "[PATCH][MMC] Secure Digital (SD)
support"
Topics: Backward Compatibility, FS: sysfs, Patents
People: Pierre Ossman, Marcel Holtmann, Russell King, Richard Purdie, Alan Cox
, Ian Molton, Pavel Machek
Pierre Ossman said:
Here are the patches for Secure Digital support that I've been sitting on
for a while. I tried to get some feedback on inclusion of this previously
but since I didn't get any I'll just submit the thing. It was originally
diffed against 2.6.10 but it applies to 2.6.11 just fine (only minor fuzz).
Change summary:
+ Detects if connected card is SD or MMC. Marks host as in SD mode if SD
is detected (since SD isn't a bus system).
+ Reads extra registers from SD cards (SCR) and parses CSD differently
depending on SD/MMC mode.
+ Support for 4-bit mode. This has been design to be fairly isolated from
the SD bit so that it can (hopefully) be reused with MMC.
+ New callback added for reading the read-only switch on SD cards.
Changed files:
mmc.c : SD detection and register parsing.
mmc_block.c : Checks read-only flag for cards (not SD-specific).
mmc_sysfs.c : Exposes SCR register.
card.h : Added flags to determine card type, RO and new register.
host.h : Added flags for bus width, RO test and mode (SD/MMC).
mmc.h : Added R6 define and new defines.
protocol.h : Added needed SD commands.
This patch is backwards compatible and only needs updated drivers to take
advantage of 4-bit bus and reading the RO switch (unmodified drivers will
default to 1-bit bus and write enable).
There might be new bugs that surface with this though. With my own drivers
I discovered that very small transfers (< 16 bytes) always failed. Testing
is needed but I do not have access to do it myself. MMC should not break
with this since MMC is detected before SD.
Pavel Machek was thrilled to see this work being doing. Marcel Holtmann asked,
"lately I got a request for the support of a Bluetooth SD card. These are using
SDIO and I think at the moment only memory cards are handled. Do you have any
plans for SDIO support?" Pierre replied, "I would if I had some hardware to
play with *hint* *hint* ;) The SDIO spec is publically available on the SD card
associations web page so it shouldn't be too difficult to get some basic
support. But I can't do much as long as I don't have any hardware to test it
with. I might also need specs for the card itself. I haven't looked too much at
SDIO at the moment." Marcel said he didn't have the hardware either, and asked
if anyone else did - but there was no response. Ian Molton said he'd also like
to work on this, if hardware were available.
Elsewhere, Russell King said to Pierre:
Can we please come to a consensus about GEN_FL_REMOVABLE. After talking to
other kernel developers, particularly in the block interface area, I am
convinced that it is fundamentally incorrect to set this flag for MMC/SD
devices.
Unfortunately, it appears that you're not convinced. This needs resolving
since it is an interface issue.
Pierre said, "Oh, sorry. That part wasn't supposed to be included in there. As
I haven't found any applications depending on any specific behaviour then I'm
quite content with your behaviour :) I can make a new patch or you can just
undo that line once you've applied the current one." Russell replied:
I'd rather not just apply this patch - there's rather a lot there to just
apply on top of what's already merged.
Is there any chance you can split it up into a smaller set of changes so
it's more obvious what's going on at each stage please?
We'll also need to run this by Linus first, explaining why you believe it's
now ok to merge this.
Pierre said he'd split up the patches; regarding whether it was OK to merge the
code, he added:
First of, I can't really back up the claim that it isn't ok. The SDA has a
paragraph about non-disclosure in their "IP Policy" (http://www.sdcard.org/
membership/images/ippolicy.pdf) but it also states that exceptions can be
granted.
Against this stands the new information that the SDA is changing its policy
and making the specs public. This information comes from some of the guys
at HP research and hasn't been confirmed by any public statement from SDA.
The SDA have, however, already released the SDIO specs. Presumably as part
of this new policy.
It was also pointed out in the previous thread by myself, Alan Cox and Ian
Molton that SD specs have been publically available from different
companies for quite some time. As such it is difficult for anyone to claim
that these are secret and can be regulated by a NDA. The only part that
hasn't been found in the wild is the spec for the 'secure' parts of the
cards. But that also means that it isn't included in this patch so it
shouldn't pose a problem.
As always, IANAL so I can't give any definite answer. But from my point of
view they would have a very weak case if they tried to claim that the
information in this patch is a trade secret.
Richard Purdie looked over the PDF Pierre linked to, and said, "That IP policy
covers their members and has no bearing on us as we have no agreements with
them. The code is "our" own so it isn't covered by any IP or copyright
restrictions other than the GPL. There aren't any patents relating to SD cards.
The simple sequences we use have been gleaned from various public documents
(intel's website, SD card manufacturer data sheets, etc.) so nobody can claim
we're using anything secret. I therefore can't see a problem with including the
code."
Later, Pierre broke the patch into smaller chunks, and resubmitted them.
2. New timeofday Core Subsystem
11 Mar - 17 Mar (38 posts) Archive Link: "[RFC][PATCH] new timeofday core
subsystem (v. A3)"
People: John Stultz
John Stultz said:
This patch implements the architecture independent portion of the time of
day subsystem. For a brief description on the rework, see here: http://
lwn.net/Articles/120850/ (Many thanks to the LWN team for that clear
writeup!)
The exciting new changes are ntp_scale() has been removed, speeding up
gettimeofday(), and the periodically run timekeeping code is now called via
soft-timer rather then at interrupt time. So timekeeping can now be done
every tick or every 10 ticks or whatever!
Included below is timeofday.c (which includes all the time of day
management and accessor functions), ntp.c (which includes the ntp scaling
calculation code, leapsecond processing, and ntp kernel state machine
code), timesource.c (for timesource specific management functions),
interface definition .h files, the example jiffies timesource (lowest
common denominator time source, mainly for use as example code) and minimal
hooks into arch independent code.
The patch does not function without minimal architecture specific hooks
(i386, x86-64, ppc32, ppc64, and ia64 examples to follow), and it should be
able to be applied to a tree without affecting the code.
New in this version:
+ ntp_scale has been removed from the gettimeofday fastpath
+ ntp_advance now pre-calculates the ntp scaling factor for the next
interval
+ timeofday_periodic_hook is now called by a soft-timer and runs outside
of interrupt context
+ comment cleanups
Items still on the TODO list:
+ cyc2ns needs better remainder code
+ Infrastructure for exporting time values for vsyscall/fsyscall
+ finer grianed ntp adjustments in ppb instead of ppm
+ more flexible timesource management interface
+ Testing, performance and cleanup work
3. Status Of SquashFS
14 Mar - 21 Mar (41 posts) Archive Link: "[PATCH][1/2] SquashFS"
Topics: Compression, FS: SquashFS, FS: ext2, FS: ramfs, Small Systems
People: Phillip Lougher, Pavel Machek, Willy Tarreau, Josh Boyer, Andrew Morton
, Paul Jackson
Phillip Lougher said:
Please apply the following two patches which adds SquashFS to the kernel.
SquashFS is self contained compressed filesystem, and it has been used by a
large amount of projects over the last few years without problems.
A number of people have started to ask me to submit it to the kernel.
Please consider adding it.
The SquashFS patch has been split into two. This email contains inode.c,
the next email contains everything else.
Andrew Morton and others offered some criticism of the patch. Elsewhere, under
the subject: Re: [PATCH][2/2] SquashFS (http://groups-beta.google.com/group/
fa.linux.kernel/msg/35a221306f883c3f) , Pavel Machek remarked, "So we are
replacing severely-limited cramfs with also-limited squashfs... For live DVDs
etc 4Gb filesystem size limit will hurt for sure, and 4Gb file size limit will
hurt, too. Can those be fixed?" Phillip thought it was unfair to compare
SquashFS and CramFS, saying, "Squashfs is significantly better than cramfs. The
main aim of Squashfs has been to achieve the best compression (using zlib of
course) of any filesystem under Linux - which it does, while also being the
fastest. Moving beyond the 4Gb limit has been a goal, but it has been a
secondary goal. For most applications 4Gb compressed (this equates to 8Gb or
more of uncompressed data in most usual cases) is ok." Regarding the 4G
file-size limitation, Phillip added, "I'm hoping to get greater than 4Gb
support this year, it all depends on how much free time I get."
Pavel agreed that SquashFS was significantly better than CramFS, and apologized
for the comparison, but he said, "having 2 different limited compressed
filesystems in kernel does not seem good to me." He also acknowledged that
SquashFS's 8G (uncompressed) filesize limitation was very useful, though he
said he'd prefer to see the size limitation go away entirely. Willy Tarreau
remarked:
squashfs is an *excellent* filesystem with very high compression ratios and
high speed on slow I/O devices such as CDs. I now use it to store my root
FS in initrd, and frankly, having a fully functionnal OS in an image as
small as 7 MB is "a good enough improvement over cramfs".
If the 4 GB limit goes away one day, I hope it will not increase overall
image size significantly, because *this* would then become a regression.
Perhaps it would simply need to be a different version and different format
(eg: squashfs v3) just as we had ext, then ext2, or jffs then jffs2, etc...
Phillip also pointed out that there was no reason to try to choose only one
compressed filesystem to include in the official tree, since there were plenty
of non-compressed filesystems, and no one seriously suggested choosing only
one. He also pointed out that there were already three compressed filesystems
in the main tree: JFFS2, zisoFS, and CramFS - no one complained when those were
accepted, Phillip said, so why complain about SquashFS now?
He added, "I'm asking for Squashfs to be put in the kernel _now_ because users
are asking me to do it _now_. If it doesn't go in, then they'll want to know
why the kernel clique has become so unreceptive to new pieces of work which
they consider a key piece of their Linux 'experience', and for that matter so
would I." Pavel replied, "Putting it into kernel because users want it is...
not a good reason. You should put it there if it is right thing to do. I
believe you should address those endianness issues and drop V1 support. If
breaking 4GB limit does not involve on-disk format change, it may be okay to
merge. After code is merged, doing format changes will be hard..."
Phillip ran out of patience at this point, and started haranguing. Josh Boyer,
however, spoke up for him, saying, "This is a useful, stable, and _maintained_
filesystem and I'm a bit surprised that there is this much resistance to it's
inclusion." At this point Andrew Morton stepped in, saying:
Although I've only been following things with half an eye, I don't think
there's a lot of resistance. It's just that squashfs's proponents are being
asked to explain the reasons why the kernel needs this filesystem. That's
something into which no effort was made in the initial patch release
(there's a lesson there).
Hopefully when the patches are reissued, all of these concerns will be
described and addressed within the covering email.
AFAICT the most substantial issue is the 4GB filesytem limit, and it seems
that the answer there is "this fs is for embedded systems and 4GB is
already insanely large". If that is indeed the argument then please, make
that argument and we'll dutifully evaluate it.
We shouldn't have to drag out such important and relevant information with
torture-via-email-thread. You guys are the squashfs exports. Tell us stuff.
Phillip said he had been more concerned with developing the code than 'selling'
it, and Paul Jackson replied:
It is not so much selling, in my view, as putting in context.
If one can simply explain to others what is before them, so that they can
quickly understand its purposes, scope, architecture, limitations,
alternatives, and such, then others can quickly evaluate what it is, and
whether such seems like a good idea.
It doesn't necessarily mean they buy it any quicker. Sometimes it just
means it gets shot down quicker ;). That's ok.
There's a _lot_ of stuff that flows by here ... be gentle and helpfully
informative to the poor reader ... as best you can.
The thread ended here.
4. Linux 2.6.11-mm4 Released
16 Mar - 23 Mar (28 posts) Archive Link: "2.6.11-mm4"
Topics: Framebuffer, Kernel Release Announcement
People: Andrew Morton, Adrian Bunk
Andrew Morton announced Linux 2.6.11-mm4, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/
2.6.11-mm4/
+ fbdev update
+ percfctr updates
+ Lots of ppc32/ppc64 things
+ Broken on some ia64 machines. We're still working through fallout from
the recent pagetable walking consolidation patches.
Benoit Boissinot reported that the dbdev update refused to compile under GCC
4.0 because of some static declarations; and Adrian Bunk replied, "That was my
fault: gcc 3.4 doesn't even warn about this, and I missed it while grep'ing."
5. Minimal Open Source BitKeeper Client Available
17 Mar - 19 Mar (13 posts) Archive Link: "BKCVS broken ?"
Topics: BSD, Version Control
People: Larry McVoy, Erik Andersen, Stelian Pop
In the course of debugging some problems with the BitKeeper-to-CVS gateway,
Larry McVoy mentioned:
take a look at this: http://www.bitkeeper.com/press/2005-03-17.html which
is a link to a very simple open source BK client. It doesn't do much except
track the head of the tree but it does that well. It's slightly better than
that, it puts all the checkin comments in BK/ChangeLog so you don't have to
go over the wire to get those.
It's intended for someone who just wants the latest and greatest snapshot,
knows how to do cp -rp and diff -Nur, it's pretty basic. It's not a CVS
gateway replacement but it does work for every tree on bkbits.net. Just to
be clear, we are not dropping the CVS gateway, this is "in addition to" not
"instead of".
He also mentioned that the BSD license would probably be the one selected for
that code. Erik Andersen replied, "Thanks! Its nice to finally have an open
source tool for sucking down the latest and greatest directly from bk. Thus far
the tool is working perfectly at fetching source trees and at updating them
when new patches are applied." Larry also said:
it's open source, I'm hoping that people will take that code and evolve it
do whatever they need. We're willing to do what we can on this end if
people need protocol changes to support new features, time permitting.
Think of that code as a prototype. It's really simple, you can hack it
trivially.
If you want us to distribute your changes then send a patch, if not that's
cool too. You can take that and evolve it to your heart's content. If you
need a different license to start hacking let me know what you want, I
really don't care, you can have that code as public domain if you like.
Stelian Pop requested that the client be made to work over HTTP, and Larry
replied, "I don't see why not," though he figured it would take a little while
to hack the support together.
6. New VXEXT Filesystem Version 1.0 Announced
17 Mar - 18 Mar (5 posts) Archive Link: "[PATCH 2.6.11.4 1/1] fs: new
filesystem implementation VXEXT1.0"
People: Jens Langner, Chris Wedgwood
Jens Langner said:
The following URL is link to a large patch for a possible integration of a
new filesystem implementation in the misc section of the kernel tree. It
features a reverse engineered implementation of the so called VXEXT1.0 DOS
filesystem which is commonly used on VxWorks RTOS systems from Wind River
Inc., where the "extended DOS filesystem" mode is enabled.
The VXEXT filesystem is more or less a FAT16 based filesystem which was
slightly modified by Wind River to allow the storage of more than 2GB data
on a partition, as well as storing filenames with a maximum of 40
characters length. To achieve that, VxWorks uses a dynamic cluster size
calculation which is based on the partition size where clusters can be
larger than 32K. In addition, it uses a slightly modified directroy entry
structure to allow to store filenames larger than 8+3 characters.
Please find the patch file accessible through the following URL: http://
www.jens-langner.de/vxext_fs/vxext_fs_1_0-linux-2.6.11.4.patch
In addition, refer the detailed technical documentation on my
implementation and the root directory of my distribution as well: http://
www.jens-langner.de/vxext_fs/Documentation/vxext.txt, http://
www.jens-langner.de/vxext_fs/
Please note that large portions of the implementation are based on the
already existing FAT16 (msdos) implementation in the kernel tree. However,
instead of patching/drilling the original FAT16 implementation, an
"outsourced" rework for developing the VEXT implementation was considered.
Chris Wedgwood asked if, since VXEXT was really FAT16-based, "Can this not then
be folded into the existing vfat filesystem?" Jens replied:
Sure it can. But I thought that as the VXEXT1.0 filesystem is per
definition not a vfat filesystem it might be better to have it separated
and not drill it into the IMHO anyway overly mixed up vfat/fat code already
in the linux kernel tree. Even if that means that some parts in the code of
the vxext filesystem are probably equal to the msdos implementation, please
note that large parts which were not needed by the vxext implementation was
dropped by me for clarifications.
So I still hope that my implementation is going to be considered for a
future kernel tree integration as it may be quite usefull for embeeded
systems wanting to access VxWorks partitions.
7. New DM9000 Network Driver
18 Mar (9 posts) Archive Link: "[PATCH] DM9000 network driver"
Topics: PCI
People: Sascha Hauer, Alan Cox, Ben Dooks
Sascha Hauer said, "This patch adds support for the davicom dm9000 network
driver. The dm9000 is found on some embedded arm boards such as the pimx1 or
the scb9328." Alan Cox replied, "Unless I'm missing something its just yet
another NE2000 (ie 8390) clone and can used the 8390 core or maybe even
ne2k-pci?" Ben Dooks replied:
Yes, you are missing something. The dm9000 is definetly not an ne2k
compatible, for a start it only uses two ports (address and data), manages
it's own transmit/receive queues, etc.
As the person who did the updates to Sacha's original driver port, he
should have really checked with me for up-to-date version first, and to
collect a Signed-off-by: line.
Signed-off-by: Ben Dooks <[email protected]>
Sascha replied, "Sorry, Ben. Of course I should have asked you first, but I had
this patch lying around for too long, and I felt I had to do something. Do you
still have updates to the driver? Then we should work them in before we go
ahead."
8. Linux 2.6.11.5 Released; Trouble Identifying Authors
18 Mar - 20 Mar (4 posts) Archive Link: "Linux 2.6.11.5"
People: Greg KH, Panagiotis Issaris
Greg KH announced Linux 2.6.11.5, saying, "As the -stable patch review cycle is
now over, I've released the 2.6.11.5 kernel in the normal kernel.org places.
One patch was deemed incorrect, so it was dropped. Another one was added,
within the review email thread. So it seems like the process is working so far,
which is refreshing :)" Panagiotis Issaris replied:
The changelog states that the patches for the AMD8111e and VIA-Rhine
originated from dilinger<at>debian.org although I was the one who they
originated from.
http://article.gmane.org/gmane.linux.kernel/282245
http://article.gmane.org/gmane.linux.kernel/282263
<dilinger:debian.org>>
+ Possible AMD8111e free irq issue
+ o Possible VIA-Rhine free irq issue
Greg replied, "Sorry about that. Trying to properly reference original authors
when patches are forwarded from different sources is a tough task. thanks for
being understanding about it."
9. Generating Kernel Command-Linux Documentation From Source
20 Mar (6 posts) Archive Link: "[PATCH 0/5] autoparam"
People: Magnus Damm
Magnus Damm said:
Here are a set of patches that makes it possible to autogenerate kernel
command line documentation from the source code. The approach is rather
straightforward - the parameter name, the type and the description are
stored in a section called __param_strings. After vmlinux is built this
section is extracted using objcopy and a script is used to generate a
primitive - but up to date - document.
Right now the section is left in the kernel binary. The document is
currently not generated from the Makefile, so the curious user should
perform:
$ objcopy -j __param_strings vmlinux -O binary foo
$ chmod a+x scripts/section2text.rb
$ cat foo | ./scripts/section2text.rb
And yeah, you need to install ruby to run the script.
The ruby script section2text.rb does some checks to see if MODULE_PARM_DESC
() is used without module_param(). You will find interesting typos.
Future work that extends this idea could include replacing __setup(name)
with __setup(name, descr). And storing the documentation somewhere to make
it easy for the end user to look up the generated parameter list from the
boot loader.
10. USB Block Driver Maintainership; Yamaha PCI Sound Maintainership
23 Mar (2 posts) Archive Link: "Add myself to MAINTAINERS"
Topics: MAINTAINERS File, PCI, USB
People: Pete Zaitcev, Jan Kasprzak, Greg KH
Pete Zaitcev said, "A Jan Kasprzak asked a few days ago to have a MAINTAINERS
entry for ub. This patch updates my entries in MAINTAINERS (ub & ymfpci)." Greg
KH accepted this patch.
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.