Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Kernel Traffic #304 For 3 Apr 2005

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1947 posts in 11MB. See the Full Statistics.

There were 670 different contributors. 252 posted more than once. The average length of each message was 94 lines.

The top posters of the week were: The top subjects of the week were:
119 posts in 587KB by Andrew Morton
51 posts in 385KB by Johannes Stezenbach
46 posts in 211KB by Adrian Bunk
42 posts in 328KB by Jesper Juhl
40 posts in 118KB by Jan Engelhardt
57 posts in 388KB for "Real-Time Preemption and RCU"
54 posts in 222KB for "AGP bogosities"
50 posts in 239KB for "[PATCH 1/5] freepgt: free_pgtables use vma list"
42 posts in 160KB for "Linux 2.6.11.2"
30 posts in 125KB for "[PATCH] Xen/i386 cleanups - AGP bus/phys cleanups"

These stats generated by mboxstats version 2.2

1. Secure Digital (SD) Support For 2.6

3 Mar 2005 - 19 Mar 2005 (20 posts) Archive Link: "[PATCH][MMC] Secure Digital (SD) support"

Topics: Backward Compatibility, FS: sysfs, Patents

People: Pierre OssmanMarcel HoltmannRussell KingRichard PurdieAlan CoxIan MoltonPavel 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:

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 2005 - 17 Mar 2005 (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:

Items still on the TODO list:

3. Status Of SquashFS

14 Mar 2005 - 21 Mar 2005 (41 posts) Archive Link: "[PATCH][1/2] SquashFS"

Topics: Compression, FS: SquashFS, FS: ext2, FS: ramfs, Small Systems

People: Phillip LougherPavel MachekWilly TarreauJosh BoyerAndrew MortonPaul 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, 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 2005 - 23 Mar 2005 (28 posts) Archive Link: "2.6.11-mm4"

Topics: Framebuffer, Kernel Release Announcement

People: Andrew MortonAdrian 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/

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 2005 - 19 Mar 2005 (13 posts) Archive Link: "BKCVS broken ?"

Topics: BSD, Version Control

People: Larry McVoyErik AndersenStelian 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 2005 - 18 Mar 2005 (5 posts) Archive Link: "[PATCH 2.6.11.4 1/1] fs: new filesystem implementation VXEXT1.0"

People: Jens LangnerChris 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 2005 (9 posts) Archive Link: "[PATCH] DM9000 network driver"

Topics: PCI

People: Sascha HauerAlan CoxBen 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 2005 - 20 Mar 2005 (4 posts) Archive Link: "Linux 2.6.11.5"

People: Greg KHPanagiotis 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>>

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 2005 (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 2005 (2 posts) Archive Link: "Add myself to MAINTAINERS"

Topics: MAINTAINERS File, PCI, USB

People: Pete ZaitcevJan KasprzakGreg 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.

 

 

 

 

 

 

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.