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

Kernel Traffic #259 For 22 May 2004

By Zack Brown

Table Of Contents


My computer crashed recently, leaving me with none; and I'm now using a slow loaner. I'm very grateful for the loan, which came on short notice from the EFF, but I need a faster machine on a more permanent basis. At the moment I can't afford this at all, so if anyone is interested in donating a machine, please let me know.

Mailing List Stats For This Week

We looked at 1946 posts in 9742K.

There were 508 different contributors. 265 posted more than once. 172 posted last week too.

The top posters of the week were:

1. PXA255 LCD Driver

17 Mar 2004 - 25 Mar 2004 (13 posts) Archive Link: "[PATCH] PXA255 LCD Driver"

Topics: Framebuffer, I2C, MAINTAINERS File, Sound: i810, Version Control

People: Ian CampbellJames SimmonsGeert Uytterhoeven

Ian Campbell said, "Attached is a patch against the most recent BK tree which implements a driver for the on-chip LCD controller of the Xscale PXA255 processor. It is based on the SA1100 FB driver and has been hacked on by various people on the ARM mailing list." He added, "I posted it to the fbdev list @ (from MAINTAINERS) but that list seems to be pretty quiet and (also from MAINTAINERS) seems to be down -- is there a more appropriate place these days for framebuffer stuff?" James Simmons replied, "We are on the list. As for That has never been fixed. Some how that domain name is in limbo :-( The sf site is the main site for fbdev developement." Geert Uytterhoeven also said the fbdev list was active, and asked on a technical note, "why don't you use the standard modedb mode parameter style?" Ian replied, "I was trying too (I mostly copied the i810 driver). How wrong did I get it? I'm willing to rework it to make it the same as the standard." Geert recommended Ian take his lead from drivers/video/modedb.c and fb_find_mode(), and Ian replied:

Ah, I had seen that, but it doesn't seem to be very appropriate for an LCD controller in an embedded environment. TFT and STN (STN in particular) displays don't often fit into any of the standard mode definitions. There's also several settings which aren't in the DB, such as pixel clock polarity, dual vs. single panel STN etc.

I quite often get asked to make some arbitrary panel which a customer picked up somewhere dirt cheap to work, it is very useful to be able to give each of the parameters explicitly, even if they do not correspond to a mode listed in the DB.

I could make the code use the same XRESxYRES-DEPTH syntax though since the 2.4 version did (by copying the parsing code from fb_find_mode()), I just changed it to match i810fb for the 2.6 port.

I had considered extending the modedb stuff to support the requirements of embedded LCD controller drivers and to encompass a db of LCD panels by part number (Kconfig selectable, something like the NLS support perhaps) containing the extra options that you can have -- but I wasn't sure if it was something that would be useful only to me or to all embedded LCD driver authors.

James replied:

The way to handle different types of displays, LCD, CRT etc has improved greatly in the latest 2.6.X kernels. You don't need to lock yourself into the standard modedb database. Also modedb is used only for selecting a particular resolution. The structure used to define the display panels behavior is struct fb_monspecs. Take a look at it in fb.h. I'm interested if I got all the needed data from the EDID about a display panel.

Here is basically what you have to do to handle mode setting:

  1. Does the displaying hardware tell you data about itself? You have to ask yourself can I get display hardware information. If it does what format is it in. In most hardware today you can get data about the display hardware in a EDID block format. Usually that data is retrieved via i2c. Fbdev driver writers must write the code handling getting the display hardware's data. Once you have the EDID data block you can use already written functions to parse the EDID block.

    If you display hardware does not use EDID format then the driver writer must parse the data himself. What data needs to get generated? This is covered next.

  2. Attempt to generate the struct fb_monspecs data. Now it is not a absolute requirement but it sure does help. There is one per physical display. This means for cases like laptops you can have one framebuffer's data being displayed on two physical displays (attached CRT and the LCD panel). In this case you would have two struct fb_monspecs per struct fb_info. When you are going to change the video mode you would have to valid the new mode against BOTH physical displays. In fact you can get a bunch of crazy combo's. The important part is that use generate a fb_monospec if possible.

    Note that fb_monospec has a mode database in its data structure. Sometimes the display hardware will tell use what the "best" video modes are for it. Also some display hardware is limited in what it can be allow to display. SO those modes are the only ones that actually work.

    Now back to the EDID case. There is a global function that will get the monitor limits for you. This function will also build you your modedb for you!!!

    fb_get_monitor_limits(unsigned char *edid, struct fb_monspecs *specs)

    Again what if we don't use EDID. Well if you can get the display hardware information in some way it is in your best interest to create a struct fb_monspec and also the modedb attached to it. What if you can't get supported modes to build a database but you can get the monitor limits? Here are your options.

  3. Okay now we "might" have our monitor data and our modedb. If we have to ask ourselves does the hardware allow the change of the resolution? If it doesn't then why do we generate a fb_monospec or a modedb. Because that data can be very useful to userland :-) If this is the case you can call fb_find_mode on your modedb if you have one and return the default struct fb_var_screeninfo that we need. If you don't have a modedb you still need to supply a default struct fb_var_screeninfo that represents the display resolution. Also you could have the case where you swap about the display. In this case you might want to create a new fb_monospec and update your var data even if you don't change your resolution. Now we are done. If you hardware can change modes then continue on.
  4. Now what to do for when we want to set the graphics display. Before we consider the monitor we have to see if the new resolution request is complete. Not every fb_var_screeninfo request is complete. Often the user only is concern with xres, yres and bpp. That is it. Alot of data is missing. This is bug in many drivers that they don't fill in that data thus often when the user tried to change the resolution they ended up with a blank screen. So how do we deal with it?
  5. First we can use a modedb we have to find the best fit. If not use the function fb_get_mode in fbmon.c.
  6. Now that we have the purposed mode we call the function

    fb_validate_mode(const struct fb_var_screeninfo *var, struct fb_info *info)

    This tells us if the requested video mode is to much for our display hardware to handle.

  7. If the monitor can handle it we call the drivers xxxfb_check_var function to see if the graphics chip can handle the mode.

I hope that answers your question. Now that I wrote this I'm going to make it apart of the documenation in the kernel for a driver how to.

This didn't seem to be exactly what Ian needed, and the discussion petered out.

2. Abstract Data Type For nodemasks

18 Mar 2004 - 26 Mar 2004 (56 posts) Archive Link: "[PATCH] Introduce nodemask_t ADT [0/7]"

Topics: Hot-Plugging

People: Matthew DobsonMartin J. BlighPaul JacksonJesse BarnesWilliam Lee Irwin III

Matthew Dobson said that, based on William Lee Irwin III's cpumask_t code, "I've got a fairly good size patch set to implement an ADT (Abstract Data Type) for nodemasks, which follows the path blazed by wli with the cpumask_t code. The basic idea is to create a generic, platform/arch-agnostic nodemask data type, complete with operations to do most anything you'd want to do with a nodemask. This stops us from open-coding nodemask operations, allows non-consecutive node numbering (ie: nodes don't have to be numbered 0...numnodes-1), gets rid of numnodes entirely (replaced with num_online_nodes()), and will facilitate the hotplugging of whole nodes." Jesse Barnes was thrilled to hear about this, and asked for clarification regarding what a node actually was. Martin J. Bligh said, "I think the closest answer we have is that it's a grouping of cpus and memory, where either may be NULL. I/O isn't directly associated with a node, though it should fit into the topo infrastructure, to give distances from io buses to nodes (for which I think we currently use cpumasks, which is probably wrong in retrospect, but then life is tough and flawed ;-))" Matthew replied, "Yeah... We used cpumasks because that seemed like a good idea at the time. Nodemasks may be a better choice now... We can write a quicky inline function nodemask_to_cpumask() as well, to keep the current users happy." Elsewhere, he added, "There have been arguments about exactly what a node is since there has been a concept of a node at all. In the kernel, it isn't defined. A node doesn't *have* to have CPUs on it (see nr_cpus_node()), doesn't *have* to have memory, doesn't *have* to have I/O. It's supposed to be just a container for those 3 things, but the containers can be empty. This code doesn't get into what a node is, just makes sure they're used properly... ;)"

Elsewhere, Paul Jackson also replied to Matthew's original post, saying:

Your nodemask_t reminds me of something I posted to linux-ia64 last November 7, 2004, under the subject: "[PATCH preview] Adds nodemask_t for use in cpusets (NUMA memory placement)".

Chris Hellwig responded to it at the time asking why I didn't provide a single generic mask ADT, and make cpumask and nodemask instances of that.

I coded that up, but then got distracted. The remaining issue for which I didn't have a good answer was that my proposal would break the optimum handling for sparc64 or other systems that didn't handle passing structures on the stack efficiently.

Bill Irwin was a party to my discussions of that effort, so I presume that if he felt it had further merit, he would have mentioned it to you, Matthew.

Could one of you, Bill or Matthew, speak to why this generic mask ADT, underlying both cpumask and nodemask, should not be pursued further, instead of duplicating the various details of cpumask, after a global s/cpu/node/g change?

I am attaching the header file include/linux/mask.h for my current version of this mask.h, in case someone reading wants more specifics of what it is that I am referring to.

This version almost certainly does _not_ work on big endian 64 systems, due to my ignorance of how kernel bitmasks were layed out when I last worked on this mask.h header. Unlike the sparc64 performance issues with passing structs on the stack, I would hope that the big/little endian issues could be fixed without messing things up too much.

If this mask.h could actually be made to work, including on sparc64, then it would seem to be a much cleaner solution. With it, we would define cpumask_t and nodemask_t as simply:

  typedef __mask(NR_NODES) nodemask_t;
  typedef __mask(NR_CPUS) cpumask_t;

and either use operations such as mask_and() on both, or if one insisted on keeping operations that specifically called out cpumask, add some 15 trivial defines such as:

  #define cpumask_and(dst, src1, src2) mask_and(dst, src1, src2)

Matthew confirmed that Bill had never mentioned that work to him; but Matthew added, "That is a better idea, if it can be made to work. My goal is to stop the proliferation of open-coded references to node details as soon as possible. If we we nip this behavior in the bud and convert all users of cpu/node data to cpumask_t/nodemask_t, we can (more) easily change the underlying details of how all the cpumask and nodemask functions work later. If the users all call our macros, then it's easy to find them ('grep -r "nodes_and" *' vs searching for every '&' in the kernel that may or may not be a node or cpu mask) and test them." Paul said this was a worthy goal, and folks discussed various technical issues.

3. Documenting KGDB

19 Mar 2004 - 31 Mar 2004 (10 posts) Archive Link: "Document hooks in kgdb"

Topics: Forward Port, Version Control

People: Tom RiniAmit S. KalePavel Machek

Tom Rinisaid:

This is an attempt to document the various architecture specific functions that are part of KGDB. There are a number of optional functions, depending on hardware setps, for which empty defaults are provided. There are also functions which must be implemented and for which no default is provided.

The required functions are:

int kgdb_arch_handle_exception(int vector, int signo, int err_code, char *InBuffer, char *outBuffer, struct pt_regs *regs)
This function MUST handle the 'c' and 's' command packets, as well packets to set / remove a hardware breakpoint, if used.

void regs_to_gdb_regs(unsigned long *gdb_regs, struct pt_regs *regs)
Convert the ptrace regs in regs into what GDB expects to see for registers, in gdb_regs.

void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, struct task_struct *p)
Like regs_to_gdb_regs, except that the process in p is sleeping, so we cannot get as much information.

void gdb_regs_to_regs(unsigned long *gdb_regs, struct pt_regs *regs)
Convert the GDB regs in gdb_regs into the ptrace regs pointed to in regs.

The optional functions are:

int kgdb_arch_init(void) :
This function will handle the initalization of any architecture specific hooks. If there is a suitable early output driver, kgdb_serial can be pointed at it now.

void kgdb_printexceptioninfo(int exceptionNo, int errorcode, char *buffer)
Write into buffer and information about the exception that has occured that can be gleaned from exceptionNo and errorcode.

void kgdb_disable_hw_debug(struct pt_regs *regs)
Disable hardware debugging while we are in kgdb.

void kgdb_correct_hw_break(void)
A hook to allow for changes to the hardware breakpoint, called after a single step (s) or continue (c) packet, and once we're about to let the kernel continue running.

void kgdb_post_master_code(struct pt_regs *regs, int eVector, int err_code)
Store the raw vector and error, for later retreival.

void kgdb_shadowinfo(struct pt_regs *regs, char *buffer, unsigned threadid)
struct task_struct *kgdb_get_shadow_thread(struct pt_regs *regs, int threadid)
struct pt_regs *kgdb_shadow_regs(struct pt_regs *regs, int threadid)
If we have a shadow thread (determined by setting kgdb_ops->shadowth = 1), these functions are required to return information about this thread.

Amit S. Kale was very encouraging about adding this information to the source, and also said, "An addition: shadow threads are needed to provide information not retrievable by gdb. e.g. Backtraces beyond interrupt entrypoints, that aren't retrievable in absence of debugging info for interrupt entrypoint code."

At some point, Pavel Machek asked, "Where can I get latest kgdb? The version on is still against 2.6.3, afaics. Or should I forward port it?" Tom replied, "CVS is against 2.6.4. Once 2.6.5 comes out, I'll move it forward again. Locally, I've got a series of patches vs 2.6.5-rc3 + some -mm bits for Andrew which I hope to post today, but might not make it until tomorrow." Pavel took a look and noticed that the CVS tree was actually against 2.6.4, but that it recorded itself as being against 2.6.3; he offered a patch to fix the discrepancy. Tom accepted it, and Amit added, "Yes. We have to keep that in mind. This has happened second time. Thanks, Pavel."

4. Entitlement-Based Scheduler Update

19 Mar 2004 - 25 Mar 2004 (5 posts) Archive Link: "[PATCH] O(1) Entitlement Based Scheduler v1.1"

Topics: Virtual Memory

People: John LeeAndi Kleen

John Lee said:

This patch is an update of the original Entitlement Based Scheduler announed a few weeks ago. The patch can be downloaded from

and applies to Linux 2.6.4.

The two main changes in this version are:

  1. Interactivity has been greatly improved, courtesy of "ramp-up" dampening being applied to newly forked tasks.
  2. Background tasks are now "almost background" tasks in that they are given periodic (but slow) promotion.

As before, when using this patch X should be reniced to -15.

Andi Kleen reported good success with this patch, but added, "There seem to be still small issues, but I wasn't able to pinpoint them to a scenario (I'm not even 100% sure they are related to the CPU scheduler, could be IO elevator or VM too). Just thought I would mention them. Occassionally (very seldom, saw it two times yesterday) I have visible stalls (2-3s) of my xterms. It doesn't seem to be related to direct visible background load (but i wasn't able yet to get a top up during such a stall) I don't remember these stalls from the non Entitlement kernel. They only happen very rarely so it could be something unrelated too. I know the report is probably too vague to be useful." John said all reports were useful, and added that Andi's problem almost certainly had to do with John's scheduler patch, as no one else had reported any similar problems with the stock kernel.

5. cmpci.c Updates; Preferred Patch Submission Policy

22 Mar 2004 - 25 Mar 2004 (3 posts) Archive Link: "ANN: cmpci 6.64 released"

People: C. L. TienJeff GarzikAndrew Morton

C. L. Tien said:

I made many changes for cmpci.c since last release. Changes are made as follows:

  1. Fix the S/PDIF out programming bug appeared in 6.16.
  2. Support 8338 4-channel playback.
  3. S/PDIF loop can be used after AC3 playback.
  4. Legacy devices (FM, MPU401 and gameport) are served by other modules. Now the code is thinner.
  5. Remove parameters setting from kernel configure menu, they can be set easily when loading the module.
  6. Add spdif_out to output 44.1K/48K 16-bit stereo to S/PDIF out.
  7. Add hw_copy to duplicate audio of front speakers to surround speakers.
  8. Change code to minimum patch for kernel 2.6.

The attached cmpci.c in cmpci-6.64.tar.bz2 is the updated driver, and 46.diff is the patch file that needed for kernel 2.6.

The cmpci-patch-2.4.25.tar.bz2 and cmpci-patch-2.6.4.tar.bz2 are patches for kernel 2.4.25/2.6.4 tree patch, they are needed to support legacy +devices, otherwise you may ignore them.

The cmi8738.tar.bz2 contains CMI8738, which is modified from CMI8338. It describe the parameters cmi8738 can support.

Jeff Garzik replied:

The driver looks pretty good, for both 2.4 and 2.6. And the listed changes above sound OK. I see the driver is smaller now.

May I respectfully request that you submit your driver update in the form of multiple patches, one patch per email? This is the normal method of submitting changes to the Linux kernel. For example, create and send 8 patches to Andrew Morton for inclusion in the 2.6.x kernel. Each patch is applied after the last one, in succeeding order. Typical email subjects would look like

[PATCH 1/8] cmpci: fix s/pdif out
[PATCH 2/8] cmpci: support 8338 4-channel
[PATCH 3/8] cmpci: s/pdif loop

Splitting up changes in this manner allows for better verification, and makes it easier to narrow down bugs to a specific change. Large "one big patch" updates often solve many bugs, and then add a few new bugs.

6. Linux 2.6.5-rc2-mm2 Released

23 Mar 2004 - 1 Apr 2004 (26 posts) Archive Link: "2.6.5-rc2-mm2"

Topics: Kernel Release Announcement

People: Andrew Morton

Andrew Morton announced 2.6.5-rc2-mm2, saying:

Martin Zwickel reported that he was completely unable to get his X server running, with the nvidia 5336 module. Andrew replied, "-mm kernels currently are using 4k kernel stacks. The nvidia driver doesn't have a hope of running in that environment."

7. The Future Of dnotify

24 Mar 2004 - 26 Mar 2004 (11 posts) Subject: "[RFC,PATCH] dnotify: enhance or replace?"

Topics: Backward Compatibility, Security

People: Rudiger KlaehnAlexander LarssonJohn McCutchanAlexander Viro

Rudiger Klaehn siad:

I have been working on a dnotify enhancement to let it work recursively and to store information about what exactly has changed.

My current code can be found here: <>

From reading the list, I got the impression that there is a general consensus that the current dnotify mechanism is less than optimal, and that something should be done about it. Is that correct?

My current implementation enhances the dnotify mechanism, but is backwards compatible to the old mechanism. This is obviously the least intrusive approach, but it is also less than optimal. For example it still requires an open file handle to watch for changes in a tree, so it will create problems when unmounting a device.

In an offline discussion, the issue came up wether it would not be better to replace dnotify with a completely new mechanism like e.g. a special netlink socket. Since most userspace programs (e.g. KDE and gnome) do not use dnotify directly, but through the fam daemon, the required changes in user space applications would not be that great.

So what is your take on this? Enhance or replace?

Alexander Larsson replied:

I think everyone agrees that dnotify is a POS that needs replacement, however coming up with a good new API and implementation seems to be hard (or at least uninteresting to kernel developers).

I for sure would welcome a sane file change notification API, i.e. one that doesn't require the use of signals. However, I don't really care about recursive monitors, and I'm actually unsure if you really want the DN_EXTENDED functionallity in the kernel. It seems like a great way to make the kernel use a lot of unswappable memory, unless you limit the event queues, and if you do that you need to stat all files in userspace anyway so you can correctly handle queue overflows.

I think the most important properties for a good dnotify replacement is:

Rudiger replied:

About recursive notification:

Some way to watch for changes on a whole file system is a must. Otherwise there is really no need to replace dnotify. When I start up KDE it watches for 256 different directories in my /home directory. It would probably watch even more directories if it could. With recursive watching it would only need to watch two or three directories recursively.

About the buffer memory usage problem:

I have been testing the current approach for a few days continuously now, and I don't get event buffer overflows even if I watch for all events on "/index.html". Of course the event buffer size should be limited. The current implementation uses 10*4096 bytes, but in most cases starting with a single 4096 byte page should be enough.

Note that the most common events (read and write) are quite small. Currently they are 32 bytes, but it would not be that hard to get them even smaller if nessecary. This is quite good compared to libraries like dazuko that report the complete path for each change.

Extended information about the type of change has been requested by many persons, and it is nessecary for many applications. People have been writing ugly syscall table hacks for this, so they must be really desperate to get this information...

It should be optional though.

John McCutchan also replied to Alexander, saying:

Maybe adding a rate limiter on these write events would be a better idea, live updates are usefull for the desktop. Also with a netlink socket I think the overhead of many events would drop siginificantly.

Also a couple other items I think need to be on the list of features,

Rudiger said of the second item, "I had this for a short time, but I threw it away since I wanted to concentrate on the event dispatch infrastructure first. It would not be a big problem to add this again." John added:

One of the big requirements for a dnotify replacement is this

I wanted to get some possible ideas from kernel hackers about how this could be done. Inode numbers are not unique, but is there any way to get a unique identifier on a file without using an open file? I have come up with a few ideas.. I don't think they are very good, but here is goes,

Both of these ideas are similar, does anyone have a better idea?

At this point Alexander Viro came in decisively, with:

"Doctor, It Hurts When I Do It"

Seriously, dnotify sucks in a lot of ways, starting with the basic premise - that userland can do notification-based maintainig of directory tree image. It's racy by definition, so any attempts to use it for "security improvements" are scam. Which leaves us with file manglers and their ilk.

Note that any attempts to trace "aliases" in userland are hopelessly racy; that mounting/unmounting doesn't even show on the radar; that different users can see different parts of tree or, while we are at it, completely different trees; that this crap is a DDoS on a server that exports any sort of network filesystem to many clients - *especially* if you want notifications on the entire tree.

IOW, idea is fundamentally flawed and IMO the real fix is to try and figure out a decent UI that would provide what file managers are really used for.

Rudiger replied, "File managers are just one application of an enhanced file change notification mechanism. There are many much more interesting applications. For file managers the current dnotify mechanism is OK." But there was no further discussion.

8. Linux 2.4.26-pre6 Released

24 Mar 2004 - 25 Mar 2004 (3 posts) Archive Link: "Linux 2.4.26-pre6"

Topics: Power Management: ACPI

People: Marcelo Tosatti

Marcelo Tosatti announced 2.4.26-pre6, saying:

Here goes the last -pre of 2.4.26 series.

It contains an ACPI update, SPARC/m68k/x86-64 (the latter adding basic support for Intel IA32e), amongst others.

9. New MD Version 0.8.0 Released

25 Mar 2004 (1 post) Subject: ""Enhanced" MD version 0.8.0 now available"

Topics: BSD: FreeBSD, Disk Arrays: RAID

People: Justin T. Gibbs

Justin T. Gibbs announced:

An updated snapshot of the Enahanced MD project is now available here:

and as diffs relative to the current 2.6 MD implementation:

A version of "emdadm" is also avaible to for this driver:

This snapshot includes support for RAID0, RAID1, and the Adaptec ASR and DDF meta-data formats. Additional RAID personalities and support for the Super90 and Super 1 meta-data formats will be added in the coming weeks, the end goal being to provide a superset of the functionality in the current MD.

This drop adds the ability to create, delete, and monitor DDF and Adaptec ASR meta-data based arrays from emdadm in addition to including several bug fixes.

This release is still structured as an MD replacement. While this makes the diffs supplied above more relevant from a review standpoint, we believe that it makes more sense at this stage in EMD development to provide it as a separate driver. This change will be reflected in our next release. The hope is for EMD and MD to merge as EMD is reviewed and altered to suite the communities needs.

10. Status Of Serial ATA (SATA)

25 Mar 2004 (2 posts) Archive Link: "Serial ATA status"

Topics: Disks: IDE, Serial ATA

People: Jeff Garzik

Fabian Fenaut asked about the status of the libata driver, specifically whether it was still considered ALPHA code; and Jeff Garzik said:

Given my recent work in bug fixing, and in isolating some problems to the platform rather than libata, the Silicon Image driver will be moving to beta, and the CONFIG_BROKEN marker removed, as soon as 2.6.5 kernel is out.

With the latest patches, I would say status of sata_sil is now "beta".

11. Consolidating Redundant msecs And jiffies Code

25 Mar 2004 - 29 Mar 2004 (10 posts) Archive Link: "[PATCH] Consolidate multiple implementations of jiffies-msecs"

People: Sridhar SamudralaDavid S. MillerJeff GarzikAndrew MortonLinus Torvalds

Sridhar Samudrala said, "The following patch to 2.6.5-rc2 consolidates 6 different implementations of msecs to jiffies and 3 different implementation of jiffies to msecs. All of them now use the generic msecs_to_jiffies() and jiffies_to_msecs() that are added to include/linux/time.h" . David S. Miller and Jeff Garzik liked this patch, and pushed it upstream to Linus Torvalds and Andrew Morton.

12. RNDIS USB Gadget Driver Released For 2.4

25 Mar 2004 - 30 Mar 2004 (20 posts) Archive Link: "[ANNOUNCE] RNDIS Gadget Driver"

Topics: Microsoft, Networking, USB, Version Control

People: Robert SchwebelDavid BrownellDavid WoodhouseDon Reid

Robert Schwebel said:

finally, here is our RNDIS USB Gadget Driver - see the attached patch against the gadget-2.4 BK tree as of now. It shouldn't be too difficult to port this to 2.6.

The patch adds support for Microsoft's RNDIS protocol to the standard g_ether driver. This makes it possible to connect a Linux USB gadget to any standard Windows machine and <*PALIM!*> there is a new USB network interface on the Windows side on which you can speak TCP/IP :-)

Unfortunately, although it works with the original Microsoft driver, you need an inf file on the windows side; you can download the template for that directly from M$.

Thanks to Auerswald GmbH for sponsoring this work!

David Brownell kicked up his heels and said he was pleased as punch to see this. He added, "I personally would prefer that Microsoft adopt vendor-neutral protocols, instead of pushing the rest of the industry to adopt things that are MSFT-biased ... for some reason, they haven't listened to almost anyone on such topics. Oh well. ;)" David Woodhouse asked, "have they (or has anyone else) invented a 'file system' USB device yet? For exporting some file systems, pretending to be a block device really isn't very useful." David replied:

There's a file system protocol used by many digital still cameras, which isn't actually camera-specific. Not MSFT-specific either.

Originally called "Picture Transfer Protocol" (PTP) it's actually more of a remote hierarchical filesystem protocol ... with an event channel (handy for "new picture" or "inserted new flash memory") and some built-in search capabilities ("what JPGs do you have"). The strangest capability was a file type tag, which isn't actually that bizarre.

As with RNDIS, and USB Mass Storage, I understand that support for PTP is part of MS-Windows since about Win2K. So a PTP gadget driver would probably be a useful contribution to Linux.

Don Reid said:

A host driver "USB PTP Storage" would be really nice too. First as a generic camera interface, second to access a gadget with the PTP interface.

(Please embarrass me by saying there already is one, I'll be so happy I won't care :-) ).

I have a PTP camera and would certainly be happy to test such a driver. Time to write it is a different matter.

David said, "There isn't one. There are two. No need to be embarrassed ... ;) They're both user-mode drivers. "gPhoto2", and "jPhoto". The author of jPhoto (moi) hasn't had time to update that code in ages." But Don replied:

These are applications, not file system interfaces like USB Mass Storage. I want to mount the camera or gadget file system and access it from any program, not run a separate app to fetch files like Mass Stor. mounts a memory device.

Why create a dedicated app like a camera interface instead of using your favorite image browser on some files?

David replied, "I think the basic answer to your question is probably just that nobody's yet written, or at least submitted, PTP client or server kernel code for Linux."

13. Linux 2.6.5-rc2-mm4 Released

26 Mar 2004 - 29 Mar 2004 (11 posts) Archive Link: "2.6.5-rc2-mm4"

Topics: Kernel Release Announcement, SMP

People: Andrew Morton

Andrew Morton announced Linux 2.6.5-rc2-mm4, saying:

14. libata Update

26 Mar 2004 - 31 Mar 2004 (21 posts) Archive Link: "[sata] libata update"

Topics: Serial ATA, Version Control

People: Jeff Garzik

Jeff Garzik said:

More work on libata... human-readable summary:

This is going to Linus after 2.6.5 is released.

BK repositories:[46]


And also, there are some PDF docs generated from the source code. Although this is always available via "make pdfdocs", I also post this document at

15. Linux 2.4.26-rc1 Released

27 Mar 2004 - 31 Mar 2004 (31 posts) Archive Link: "Linux 2.4.26-rc1"

Topics: Power Management: ACPI

People: Marcelo TosattiWilly Tarreau

Marcelo Tosatti announced 2.4.26-rc1, saying, "The first -rc contains an ACPI update, networking fixes, amongst others." Willy Tarreau replied, "It's OK here on dual athlon, alpha is compiling. I identified a few warnings during the compilation. I'll send a few patches to fix them. The biggest one is on agpgart, when the agp_generic_* functions are not used, but fixing this needs a lot of #if and I feel like lazy right now :-)" Later, he said, "drivers/char/agp/agpgart_be.c defines several agp_generic_* functions for chipsets which do not need a specific one. Unfortunately, a lot of chipsets don't use them all, so in most cases, some of them are defined but not used. This makes gcc print warnings and adds useless code. This afternoon, I felt brave and added all the #ifdef needed depending on what the chipsets use. I did it carefully, so I think I did not miss any, but a second check might be useful. An interesting side effect is that it reduced the driver by about 2 kB for a VIA chipset. Here is the patch against 2.4.26-rc1. I don't know if it's too late for 2.4.26, but at least it could be reviewed."

16. linux-libc-headers (llh) Updated

28 Mar 2004 (1 post) Archive Link: "[ANNOUNCE] linux-libc-headers"

People: Mariusz Mazur

Mariusz Mazur announced:

Available at


README file follows:

The linux-libc-headers (llh) package (available at contains headers that export linux abi to userspace. These headers are a heavily modified and cleaned up version of what comes with original linux tarball. The first three digits of llh's version tag correspond to the version of linux kernel of which abi is exported, but keep in mind there are lots of 2.4 kernel compatibilities included.

Userland usefulness is achieved by removing kernel only parts (which often generate errors) and using code provided by libc where possible (this allows to avoid collisions when both linux and libc headers define the same structure or constant). Unfortunately libc dependency might result in functionality loss since libcs aren't always in sync with what kernel provides. If such a case occurs please send a bug report to the maintainer (see AUTHORS file) and, if possible, a workaround will be added. Do note that since llh is primarily for 2.6 based kernels we assume glibc to be at least version 2.3.3 (as far as I know this version wasn't released officially but is being used by many current linux distributions). Glibc is not a requirement though - llh is known to work with other implementations of standard C library - but obviously is a priority, so be prepared to send a bugreport if using something else. In case you're wondering why take such an approach if it's obvious that it might generate problems. Well, according to my knowledge there is consensus among kernel hackers as to how userland headers should look like, but unfortunately proper implementation (and wider adoption) will take time and something that just plain works (in most cases anyway) is needed now.

17. Linux 2.6.5-rc2-mm5 Released

29 Mar 2004 - 30 Mar 2004 (8 posts) Archive Link: "2.6.5-rc2-mm5"

Topics: FS: NFS, Ioctls, Kernel Release Announcement, SMP

People: Andrew Morton

Andrew Morton announced Linux 2.6.5-rc2-mm5, saying:

18. Hotplug Scripts Updated

29 Mar 2004 (1 post) Archive Link: "[ANNOUNCE] 2004-03-29 release of hotplug scripts"

Topics: Backward Compatibility, Hot-Plugging

People: Greg KH

Greg KH announced:

I've just packaged up the latest Linux hotplug scripts into a release, which can be found at:

Or from your favorite mirror at:
or for those who like bz2 packages:

I've also packaged up some pre-built (and signed) Red Hat FC 2-test based rpms:

The source rpm is available if you want to rebuild it for other distros or versions of Red Hat at:

The main web site for the linux-hotplug project can be found at: which contains lots of documentation on the whole linux-hotplug process.

This release is recommended for _anyone_ using older versions of the hotplug scripts (especially the last development snapshot) as lots of bugs have been fixed. Especially for any scsi or usb-storage users, now the proper drivers should be automatically loaded when a device is plugged in.

The release is still backwards compatible with 2.4, so there is no need to worry about upgrading.

The full ChangeLog extract since the last release is included below for those who want to know everything that's been changed, and who to blame for them :)

Many thanks to everyone who has send in patches for this release, without these submissions, this release would still contain lots of issues...

19. Linux 2.6.5-rc3 Released

29 Mar 2004 - 31 Mar 2004 (15 posts) Archive Link: "Linux 2.6.5-rc3"

Topics: Kernel Release Announcement, Networking

People: Linus Torvalds

Linus Torvalds announced Linux 2.6.5-rc3, saying:

x86-64, arm, ppc64, ia64, s390 updates.

And agp, acpi, ISDN and watchdog.

Nothing earth-shattering, in other words.

20. Linux 2.6.5-rc3-mm1 Released

30 Mar 2004 - 31 Mar 2004 (20 posts) Archive Link: "2.6.5-rc3-mm1"

Topics: FS: devfs, FS: sysfs, Kernel Release Announcement, Version Control

People: Andrew MortonGreg KHRussell King

Andrew Morton announced Linux 2.6.5-rc3-mm1, saying:

Greg KH replied, "Argh, so the only way I'm going to be able to get my little, tiny, simple vc class patch is by fixing all of the tty layer locking code? Ugh, that's so mean... :)" Andrew replied, "Well the good news is that my test box now oopses on about 2-out-of-3 boot attempts. But that gets tiresome." Later that day he posted a patch, and Russell King replied, "I suspect you may just be able to get away with this for serial drivers using serial_core. However, I suspect it'll break non-serial_core using serial drivers. The serial drivers track the tty count themselves, so that they know when to do the final close processing (why you may ask - because of the blocking for DCD in the open code.) I wouldn't like to say what would happen if ->open were called for a different tty structure for the same port while ->close was in progress." Andrew replied:

You cannot defeat me that easily!

Actually the race+oops _was_ fixed in Linus's tree a week ago, sort-of. If the race happens we end up running vcs_devfs_add() and vcs_devfs_remove() against the tty concurrently, leaving it in indeterminate state. This will cause devfs warnings and missing devfs/sysfs stuff, but no oops.

The con_open-speedup.patch in -mm reintroduces the oops by not bogusly overwriting tty->driver_data when tty->count > 1. Fun.

This rather nasty patch fixes things up again.

21. libata Update

30 Mar 2004 Archive Link: "[sata] libata update"

Topics: Serial ATA, Version Control

People: Jeff Garzik

Jeff Garzik said:

A ton of SATA work in the past few weeks, but not a lot terribly new in this update. The update is mainly to rediff against the latest 2.4 and 2.6 kernels. Note that this does not include experimental patches. Notably absent are

The above are all experimental patches I have locally.

Finally, per user requests, I have started posting the associated changelog as well.

BK repositories:[46]

2.6.x patch and changelog:

2.4.x patch and changelog:

Drivers for SATA-2 controllers have been in development, and should be making their appearance soon.

22. libsysfs Version 1.1.0 Released

31 Mar 2004 (1 post) Archive Link: "[ANNOUNCE] Libsysfs v1.1.0 release"

Topics: FS: sysfs, Security

People: Ananth N Mavinakayanahalli

Ananth N Mavinakayanahalli said:

Version 1.1.0 of libsysfs, shipped as part of the sysfsutils package is now available at

Libsysfs provides a simple API to access the sysfs filesystem.

Changes in this release include:

Thanks to everyone who have been providing patches and valuable feedback.

23. ibmvscsi Updated

31 Mar 2004 (9 posts) Archive Link: "[PATCH] ibmvscsi driver - sixth version"

People: Dave Boutcher

Dave Boutcher said:

Here is the next version of the ibmvscsi lldd. I know you were waiting for the fix that correctly checks for errors on the dma_map_foo calls, which is included. The other functional changes are to implement device_reset, and to surface a bunch of adapter attributes through shost_attrs.

This driver has been under test for the last couple of months, and is scheduled to ship in a couple of distributions shortly. There are a few bug fixes included in this patch as well, mostly in the area of abort processing and correctly handling edge conditions (freeing buffers in error paths etc.)

Comments always welcomed. I would like to get this upstream if I can, since the linux distributors are complaining slightly that it is not.

There was some technical discussion, but nothing about getting the code upstream.

24. Umbrella 0.3 Released For 2.6 Kernels

1 Apr 2004 (1 post) Subject: "[ANNOUNCE] Umbrella-0.3 released"

People: Kristian Sorensen

Kristian Sorensen announced:

After three weeks of development, we proudly present Umbrella version 0.3 for Linux 2.6.x kernels.

--- Short version ---

Umbrella for implements a combination of process based mandatory access control (MAC) and authentication of files for Linux on top of the Linux Security Modules framework. The MAC scheme is enforced by a set of restrictions for each process.

--- What's new? ---

This release rounds up the implementation of process based restrictions. To increase performance and to make the use of Umbrella even smoother for programmers, restrictions have been devided into two levels.

Level 1 is a static set of restrictions, which is provided by The Umbrella Team. At present these is aimed at protecting a Linux system on a HP iPAQ. Level 2 is restrictions is purely defined by the programmer and applies only to the process and sub-processes that the restricted program spawns.

A short simple example of the use of this may be found in the user space program in the Umbrella 0.3 release or directly in cvs at:*checkout*/umbrella/umbrella-devel/userspace/src/umb_user.c?rev=1.3

Furthermore a hash table is implemented to increase flexibility and speed of the lookup of restrictions.

More details is given on the Umbrella web site: and on the project site

--- Download Umbrella 0.3 ---

The Umbrella 0.3 kernel patch together with a user space example can be directly downloaded here:

--- Comments, Questions and Contributions ---

Comments, questions and contributions are most welcome! The development team can be contacted on or in the SourceForge forums, found here:







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.