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 #286 For 30 Nov 2004

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1593 posts in 8801K.

There were 411 different contributors. 222 posted more than once. 167 posted last week too.

The top posters of the week were:

1. Some Policy Discussion Of #ifdefs In Kernel Code

8 Nov 2004 - 15 Nov 2004 (18 posts) Archive Link: "[PATCH] VM routine fixes"

Topics: Virtual Memory

People: Linus TorvaldsDavid HowellsAndrew Morton

David Howells posted some virtual memory fixes, and Andrew Morton noticed a small #ifdef for the benefit of uClinux. Only one line was guarded by the #ifdef, but Andrew asked what it was for. David replied that for uClinux, that particular line was unnecessary, and #ifdefing it out for uClinux would give a slight performance boost. Linus Torvalds said:

I don't think that is a valid argument.

If uClinux wants to be a different source-base, then go wild. But if you want to integrate into the standard kernel, there are other priorities. One of them is that it has to integrate cleanly. And that means that we don't do micro-optimizations that make the non-MMU case affect mainline code unless there is a damn good reason.

David replied, "So not having an MMU, page tables or PTEs or any requirement for operations that act upon them is not enough?" And Linus said:

No. It's a matter of abstraction. If you can _abstract_ the thing away, that's fine. I don't want more #ifdef's in source code, but you can have a totally different file that doesnt' do the things that aren't appropriate for non-MMU.

Yes, we've already got #ifdef's in code, but the point is that we don't add them unless there is serious _need_. And even then it's a sign of trouble. In this case, the sign of trouble is bigger than the need. uClinux might as well have a dummy "struct vm_operations", if only to make the damn thing look more like real Linux.

2. Darcs Version Control Mirror Of Kernel Source Repository

10 Nov 2004 - 12 Nov 2004 (5 posts) Archive Link: "[ANNOUNCE] darcs mirror of the linux kernel repository"

Topics: Version Control, Virtual Memory

People: David RoundyPavel MachekZack Brown

David Roundy said:

I am pleased to announce the availability of a darcs mirror of the linux kernel repository. Darcs is a fully distributed and simple to use revision control system. Instructions on accessing the repository are available at

http://darcs.net/linux.html

In brief, you can get a copy of the latest kernel (converted from the bkcvs branch) using

darcs get --partial http://darcs.net/linux

You can leave out the --partial, if you want to get the full history of the kernel repository (which obviously will take longer).

Be forewarned that darcs is a bit of a memory hog when run with large repositories, so the above command may take quite a while, and probably will require 700 or 800 megabytes of virtual memory. The actual working set of memory is under 300 megabytes. Work is underway to improve both the speed and memory usage of darcs. So far the emphasis in darcs development has been on correctness and stability.

The darcs kernel mirror is sponsored by Aktiom Networks (http://aktiom.net). Aktiom specializes in Linux Virtual Private Servers (VPS) for technology professionals and consultants.

Pavel Machek asked, "Would it be possible to get data from www.bkbits.net so that complete history is preserved?" David replied:

Full history could be preserved, but I don't think that getting it from the web interface would be polite, and I can't run bk myself (for obvious reasons).

I could hack up a sketch of how I'd go about getting the full history. Crudely speaking, I'd just need a couple of functions: one telling me the parents of a given version, and one fetching a given version. And of course, finding the author/date/comments for each version. If someone else were willing to implement those two functions, I could sketch out the darcs side of things. Obviously renames wouldn't be preserved with just those functions, but that's not a huge loss. And also, the conversion process would be painfully slow.

At one point in the discussion, Pavel said, "Larry said that we are welcome to get metadata in open format and cited getting it from bkbits.net as one of possible ways. I believe they have faster connection these days."

(ed. [Zack Brown] This is excellent news. Linux kernel development activity is so fast and so huge, it is the ideal testing ground for any version control system. If darcs can handle kernel development, it can handle anything. Hopefully some of the kernel folks will give David some feedback on how best to rise to the challenge.)

3. New sk98lin Driver Released In Many Patches

10 Nov 2004 - 11 Nov 2004 (4 posts) Archive Link: "new sk98lin driver"

People: Michael HeyseJeff GarzikStephen Hemminger

Michael Heyse asked, "there's a new sk98lin driver available from http://www.syskonnect.com/syskonnect/support/driver/zip/linux/install-7_09.tar.bz2 (now with ethtool support) dated Oct 20. It's not in 2.6.10-rc1, will it be included in 2.6.10?" Jeff Garzik replied, "I think Stephen Hemminger volunteered to split up the changes into separate patches." Michael was happy to hear this, though he guessed the project would take a long time, since the patch was so big. Elsewhere, Stephen Hemminger also said:

This is the first set of patches to merge some of the new SysKonnect code with existing 2.6 driver and fix several bugs.

  1. Remove explicit module refcounting (bug)
  2. Make OnesHash table local constant.
  3. proc print interface cleanup
  4. Use netdev_priv
  5. Use module_param_array instead of deprecated MODULE_PARM
  6. Add netpoll controller support
  7. Basic ethtool support
  8. Ethtool support for LED blinking
  9. Ethtool pause param support
  10. Cleanup
  11. Fix boards_found count
  12. Add MODULE_VERSION
  13. Handle ring full condition properly (bug)
  14. Get rid of obfuscation irqreturn_t
  15. Rearrange functions to match SysKonnect code
  16. More efficient OsGetTime
  17. Enable high dma and lockless transmit
  18. reorganize pci_device table
  19. Do initialization better
  20. Ethtool tx & receive checksum efficiently
  21. Tx ring management improvements
  22. Cleanup the code under DIAG_SUPPORT
  23. Eliminate Pnmi scratchpad common

To spare people's mailbox the individual patches won't go to LKML just to netdev.

4. Linux 2.4.28-rc3 Released

12 Nov 2004 - 15 Nov 2004 (9 posts) Archive Link: "Linux 2.4.28-rc3"

Topics: FS: NFS, FS: smbfs, Power Management: ACPI

People: Marcelo TosattiAndrey MelnikoffAdrian BunkDavid S. MillerOzkan Sezer

Marcelo Tosatti announced Linux 2.4.28-rc3, saying, "It contains a v2.6 backport of the binfmt_elf potential vulnerabilities disclosed this week, an enhanced smbfs client overflow fix, an ACPI update fixing a couple of nasty bugs, a NFS client bugfix and a network update from Davem." Andrey Melnikoff posted a patch to "Prevent NMI oopser kill kernel thread when megearid2 driver wating abort or reset command completion." He asked if this could make it into the source in time for 2.4.28, but Marcelo replied:

I talked to Atul and Arjan about this one - the correct thing to do is to replace mdelay() with CPU yielding msleep().

We should backport msleep() in 2.4.29-pre1.

Elsewhere, Adrian Bunk reported:

I'm getting the following error:

<-- snip -->

depmod: *** Unresolved symbols in
/lib/modules/2.4.28-rc3/kernel/net/decnet/decnet.o
depmod: neigh_for_each

<-- snip -->

This was caused by Harald's backport of the neighbour scalability fixes from 2.6 .

neigh_for_each must be EXPORT_SYMBOL'ed (as it is in 2.6)

David S. Miller said, "Good catch," and applied Adrian's patch to his tree, en route to Marcelo. Ozkan Sezer noticed that "A similar export should also be needed for __neigh_for_each_release" David thanked him, and Adrian posted an updated patch including Ozkan's contribution.

5. Intel Thermal Monitor Approaching Completion For x86_64

13 Nov 2004 - 17 Nov 2004 (5 posts) Archive Link: "[PATCH] Intel thermal monitor for x86_64"

People: Zwane MwaikamboAndi Kleen

Zwane Mwaikambo, working on Intel-donated hardware, posted a patch that "adds support for notification of overheating conditions on intel x86_64 processors. Tested on EM64T, test booted on AMD64." Andi Kleen asked if the code had been tested in actual overheating conditions, and Zwane replied that no, he'd only just forced the event to trigger. Andi also had some pretty invasive criticisms about the patch, with the overall sense that a different approach might be better. He remarked, "sorry for telling you late, but I also only realized it later" . They talked about deep dark magic for a few posts, and Zwane went off to rework his patch.

6. New ADMA Driver

16 Nov 2004 (2 posts) Archive Link: "[IDE] new driver: ADMA"

Topics: Disks: IDE, Serial ATA

People: Jeff Garzik

Jeff Garzik said:

Pacific Digital (and others?) have some PATA and SATA controllers which conform to the public "ADMA" specification found at

http://www.t13.org/project/d1510r1-Host-Adapter.pdf

In terms of standard IDE BMDMA controllers, ADMA is fairly advanced, allowing all commands (including non-DMA) to be transferred using DMA and a scatter-gather table. Rather than a DMA ring, each port has a linked list of commands to execute.

In terms of modern SATA controllers, the ADMA design is showing its age just a tad, but is still a reasonable design. Since the hardware ref is public, and since the driver was quick and easy, I took a couple hours out of the "post-work" evening to write the first draft of the ADMA driver.

This driver conforms to Linus Confidence Level 2:

It looks right
X It builds
It works
It passes stress tests

The error handling is severely lacking, but this should be basically right.

The driver is built against 2.6.10-rc2 libata.

He also replied to himself to add, "a quick data point: ata_adma.c is a non-queueing driver (for now)."

 

 

 

 

 

 

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.