Kernel Traffic #259 by Zack Brown
[email protected] Sat, 22 May 2004 09:56:20 -0700
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #259 For 22 May
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Introduction
* Mailing List Stats For This Week
* Threads Covered
1. 17 Mar - 25 Mar (13 PXA255 LCD Driver
posts)
2. 18 Mar - 26 Mar (56 Abstract Data Type For nodemasks
posts)
3. 19 Mar - 31 Mar (10 Documenting KGDB
posts)
4. 19 Mar - 25 Mar (5 posts) Entitlement-Based Scheduler Update
5. 22 Mar - 25 Mar (3 posts) cmpci.c Updates; Preferred Patch Submission
Policy
6. 23 Mar - 1 Apr (26 Linux 2.6.5-rc2-mm2 Released
posts)
7. 24 Mar - 26 Mar (11 The Future Of dnotify
posts)
8. 24 Mar - 25 Mar (3 posts) Linux 2.4.26-pre6 Released
9. 25 Mar (1 post) New MD Version 0.8.0 Released
10. 25 Mar (2 posts) Status Of Serial ATA (SATA)
11. 25 Mar - 29 Mar (10 Consolidating Redundant msecs And jiffies
posts) Code
12. 25 Mar - 30 Mar (20 RNDIS USB Gadget Driver Released For 2.4
posts)
13. 26 Mar - 29 Mar (11 Linux 2.6.5-rc2-mm4 Released
posts)
14. 26 Mar - 31 Mar (21 libata Update
posts)
15. 27 Mar - 31 Mar (31 Linux 2.4.26-rc1 Released
posts)
16. 28 Mar (1 post) linux-libc-headers (llh) Updated
17. 29 Mar - 30 Mar (8 posts) Linux 2.6.5-rc2-mm5 Released
18. 29 Mar (1 post) Hotplug Scripts Updated
19. 29 Mar - 31 Mar (15 Linux 2.6.5-rc3 Released
posts)
20. 30 Mar - 31 Mar (20 Linux 2.6.5-rc3-mm1 Released
posts)
21. 30 Mar libata Update
22. 31 Mar (1 post) libsysfs Version 1.1.0 Released
23. 31 Mar (9 posts) ibmvscsi Updated
24. 1 Apr (1 post) Umbrella 0.3 Released For 2.6 Kernels
Introduction
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
(http://www.eff.org) , 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 (mailto:[email protected]) .
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:
* 71 posts in 404K by Paul Jackson
* 67 posts in 321K by Andrew Morton
* 65 posts in 232K by Jeff Garzik
* 46 posts in 192K by Andrea Arcangeli
* 37 posts in 120K by Pavel Machek
* Full Stats
1. PXA255 LCD Driver
17 Mar - 25 Mar (13 posts) Archive Link: "[PATCH] PXA255 LCD Driver"
Topics: Framebuffer, Sound: i810
People: Ian Campbell, James Simmons, Geert 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 @ sf.net (from MAINTAINERS) but that list seems to be pretty quiet and
www.linux-fbdev.org (http://www.linux-fbdev.org) (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 www.linux-fbdev.org.
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 - 26 Mar (56 posts) Archive Link: "[PATCH] Introduce nodemask_t ADT [0
/7]"
Topics: Hot-Plugging
People: Matthew Dobson, Martin J. Bligh, Paul Jackson, Jesse Barnes, William
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) (http://www.gelato.unsw.edu.au/
linux-ia64/0311/7438.html) ".
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 - 31 Mar (10 posts) Archive Link: "Document hooks in kgdb"
Topics: Version Control
People: Tom Rini, Amit S. Kale, Pavel 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
kgdb.sf.net 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 - 25 Mar (5 posts) Archive Link: "[PATCH] O(1) Entitlement Based
Scheduler v1.1"
Topics: Virtual Memory
People: John Lee, Andi 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
http://sourceforge.net/projects/ebs-linux/
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 - 25 Mar (3 posts) Archive Link: "ANN: cmpci 6.64 released"
People: C. L. Tien, Jeff Garzik, Andrew 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
etc.
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 - 1 Apr (26 posts) Archive Link: "2.6.5-rc2-mm2"
People: Andrew Morton
Andrew Morton announced 2.6.5-rc2-mm2, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.5-rc2/
2.6.5-rc2-mm2/
+ Fixed the memory leak which 2.6.5-rc2-mm1 suffered from.
+ More writeback changes - correctness and performance fixes.
+ Various random fixes
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 - 26 Mar (11 posts) Subject: "[RFC,PATCH] dnotify: enhance or replace?
"
Topics: Backward Compatibility, Security
People: Rudiger Klaehn, Alexander Larsson, John McCutchan, Alexander 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: <http://www.lambda-computing.com/~rudi/
dnotify/>
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:
+ Don't use signals or any other global resource that makes it impossible
to use the API in a library thats supposed to be used by all sorts of
applications.
+ Get sane semantics. i.e. if a hardlink changes notify a file change in
all directories the file is in. (This is hard though, it needs
backlinks from the inodes to the directories, at least for the
directories with a monitor, something i guess we don't have today.)
+ Some way to get an event when the last open fd to the file is closed
after a file change. This means you won't get hundreds of write events
for a single file change. (Of course, you won't catch writes to e.g.
logs which aren't closed, so this has to be optional. But for a
desktop, this is often what you want.)
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 "/
". 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,
+ Some way to not have an open file descriptor for each directory you are
monitoring. This causes so many problems when unmounting, and this is
really the most noticable problem for the user.
+ Better event vocabulary, we should fire events for all VFS ops. I think
right now it is limited to delete,create,written to. It would be good
to tell the listener exactly what happened, moved,renamed, etc.
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
+ Some way to not have an open file descriptor for each directory you are
monitoring. This causes so many problems when unmounting, and this is
really the most noticable problem for the user.
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,
+ When user passes fd to kernel to watch, the kernel takes over this fd,
making it invalid in user space ( I know this is a terrible hack) then
when a volume is unmounted, the kernel can walk the list of open fd's
using for notifacation and close them, before attempting to unmount.
+ The user passes a path to the kernel, the kernel does some work so that
it can track anything to do with that path, and again when an unmount
is called the kernel cleans up anything used for notification.
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 - 25 Mar (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 (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:
http://people.freebsd.org/~gibbs/linux/SRC/emd-0.8.0-tar.gz
and as diffs relative to the current 2.6 MD implementation:
http://people.freebsd.org/~gibbs/linux/SRC/emd-2.6-20040425-diffs.gz
A version of "emdadm" is also avaible to for this driver:
http://people.freebsd.org/~gibbs/linux/SRC/emdadm-0.00.1.tgz
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 (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 - 29 Mar (10 posts) Archive Link: "[PATCH] Consolidate multiple
implementations of jiffies-msecs"
People: Sridhar Samudrala, David S. Miller, Jeff Garzik, Andrew Morton, Linus
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 - 30 Mar (20 posts) Archive Link: "[ANNOUNCE] RNDIS Gadget Driver"
Topics: Microsoft, Networking, USB
People: Robert Schwebel, David Brownell, David Woodhouse, Don 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 - 29 Mar (11 posts) Archive Link: "2.6.5-rc2-mm4"
Topics: SMP
People: Andrew Morton
Andrew Morton announced Linux 2.6.5-rc2-mm4, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.5-rc2/
2.6.5-rc2-mm4/
+ CPU scheduler updates. We're heading into another big round of testing,
measuring and tuning of the SMP/SMT/NUMA features in the CPU scheduler.
Nick and Ingo are driving this - thanks to the people who are working
with them. We really need to get this wrapped up.
+ A significant number of changes to laptop-mode. If you're using this,
please grab the updated startup script from Documentation/
laptop-mode.txt.
+ A few more tweaks to the page reclaim logic. Needs careful testing. I
have one workload which seems to run faster in laptop mode (minus the
readahead size increase), which is a little odd.
14. libata Update
26 Mar - 31 Mar (21 posts) Archive Link: "[sata] libata update"
Topics: Serial ATA
People: Jeff Garzik
Jeff Garzik said:
More work on libata... human-readable summary:
+ scsi portion of command submission path now a lot more lightweight.
Should reduce CPU usage a bit.
+ improved documentation (see below)
+ New SiS SATA driver.
+ Promise: minor improvements in locking, error handling, and
initialization. Promise users, please test.
+ Intel ICH5: minor improvements in probing and combined mode handling.
Intel users, please test.
This is going to Linus after 2.6.5 is released.
BK repositories:
http://gkernel.bkbits.net/libata-2.[46]
Patches:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/
2.4.25-libata15.patch.bz2
http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/
2.6.5-rc2-bk6-libata2.patch.bz2
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
http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/libata.pdf
15. Linux 2.4.26-rc1 Released
27 Mar - 31 Mar (31 posts) Archive Link: "Linux 2.4.26-rc1"
Topics: Power Management: ACPI
People: Marcelo Tosatti, Willy 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 (1 post) Archive Link: "[ANNOUNCE] linux-libc-headers 2.6.4.0"
People: Mariusz Mazur
Mariusz Mazur announced:
Available at http://ep09.pld-linux.org/~mmazur/linux-libc-headers/
Changes:
+ updated to 2.6.4
+ added documentation (readme, changelog, license, authors)
+ linux/hdreg.h - 2.4 stuff
+ linux/major.h - 2.4 definitions
+ minor changes
README file follows:
The linux-libc-headers (llh) package (available at http://
ep09.pld-linux.org/~mmazur/linux-libc-headers/) 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 - 30 Mar (8 posts) Archive Link: "2.6.5-rc2-mm5"
Topics: FS: NFS, Ioctls, SMP
People: Andrew Morton
Andrew Morton announced Linux 2.6.5-rc2-mm5, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.5-rc2/
2.6.5-rc2-mm5/
+ A fairly small update. Mainly attempting to stabilise the CPU scheduler
changes.
+ A patch here which will hopefully fix the oopses which a few people
have seen in the NFS server code.
+ The pestiferous SMP oops in vt_ioctl() is back, and I really fixed it
this time. I've a suspicion that the kernel used to have the right
locking in place, but someone removed it because of some deadlock. If
your kernel does appear to deadlock, please include a sysrq-T trace in
the report.
18. Hotplug Scripts Updated
29 Mar (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:
http://sourceforge.net/project/showfiles.php?group_id=17679
Or from your favorite kernel.org mirror at:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_03_29.tar.gz (http:/
/www.kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_03_29.tar.gz)
or for those who like bz2 packages:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_03_29.tar.bz2 (http:
//www.kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_03_29.tar.bz2)
I've also packaged up some pre-built (and signed) Red Hat FC 2-test based
rpms:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_03_29-1.noarch.rpm (
http://www.kernel.org/pub/linux/utils/kernel/hotplug/
hotplug-2004_03_29-1.noarch.rpm)
kernel.org/pub/linux/utils/kernel/hotplug/
hotplug-base-2004_03_29-1.noarch.rpm (http://www.kernel.org/pub/linux/utils
/kernel/hotplug/hotplug-base-2004_03_29-1.noarch.rpm)
The source rpm is available if you want to rebuild it for other distros or
versions of Red Hat at:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_03_29-1.src.rpm (
http://www.kernel.org/pub/linux/utils/kernel/hotplug/
hotplug-2004_03_29-1.src.rpm)
The main web site for the linux-hotplug project can be found at:
http://linux-hotplug.sf.net/ 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 - 31 Mar (15 posts) Archive Link: "Linux 2.6.5-rc3"
Topics: 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 - 31 Mar (20 posts) Archive Link: "2.6.5-rc3-mm1"
Topics: FS: devfs, FS: sysfs
People: Andrew Morton, Greg KH, Russell King
Andrew Morton announced Linux 2.6.5-rc3-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.5-rc3/
2.6.5-rc3-mm1/
+ Dropped the tty locking fix. As predicted, it deadlocked. I also
reverted the patch from bk-driver-core.patch which is causing this race
to trigger more frequently.
+ Added the rest of Ingo's recent CPU scheduler work. This is for people
to compare with 2.6.5-rc2-mm5.
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 Archive Link: "[sata] libata update"
Topics: Serial ATA
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
+ lba48 (large transfer) requests
+ splitting up Promise driver into sata_promise (tx2/tx4) and sata_sx4
(sx4) drivers.
+ adding better flush-cache / writeback caching support
The above are all experimental patches I have locally.
Finally, per user requests, I have started posting the associated changelog
as well.
BK repositories:
http://gkernel.bkbits.net/libata-2.[46]
2.6.x patch and changelog:
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/
2.6.5-rc3-libata1.patch.bz2
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/
2.6.5-rc3-libata1.log
2.4.x patch and changelog:
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/
2.4.26-rc1-libata2.patch.bz2
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/
2.4.26-rc1-libata2.log
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 (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
http://linux-diag.sourceforge.net
Libsysfs provides a simple API to access the sysfs filesystem.
Changes in this release include:
+ Lots of security auditing for buffer overflows.
+ C++ compatibility fixes.
+ Remove check for installed libsysfs during build.
Thanks to everyone who have been providing patches and valuable feedback.
23. ibmvscsi Updated
31 Mar (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 (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: http://
cvs.sourceforge.net/viewcvs.py/*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: http://
umbrella.sourceforge.net and on the project site http://www.sourceforge.net
/projects/umbrella
--- Download Umbrella 0.3 ---
The Umbrella 0.3 kernel patch together with a user space example can be
directly downloaded here: http://prdownloads.sourceforge.net/umbrella/
umbrella-0.3.tar.bz2?download
--- Comments, Questions and Contributions ---
Comments, questions and contributions are most welcome! The development
team can be contacted on [email protected] or in the SourceForge forums,
found here: http://sourceforge.net/forum/?group_id=101217
We Hope You Enjoy Kernel Traffic
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.