Kernel Traffic #229 For 8�Sep�2003

There were 527 different contributors. 289 posted more than once. 211 posted last week too.

11�Aug�2003�-�14�Aug�2003 (27 posts) Subject: "[PATCH] CodingStyle fixes for drm_agpsupport"

Dave Jones posted some formatting changes to a file, to make it conform more closely to the CodingStyle document. Larry McVoy objected to the patch, in part because, "It's a formatting only patch. That screws over people who are using BK for debugging, now when I double click on these changes I'll get to your cleanup patch, not the patch that was the last substantive change." Jeff replied that in Linux development, CodingStyle patches were culturally acceptable, as long as the developer kept each individual patch small. Larry replied, "That ought to be balanced with "don't screw up the revision history, people use it". It's one thing to reformat code that is unreadable, for the most part this code didn't come close to unreadable." Eli Carter remarked, "perhaps the (revision control) tool is getting in the way of doing the job and should be fixed? :) Perhaps being able to flag a changeset as a 'formatting change', and have the option to hide it or make it 'transparent' in some fashion? Hmm... "Annotate only the changes that relate to feature X."" Larry said he'd thought about that and rejected it, and in fact, "we have a policy at BitMover where "formatting changes" are prohibited and we make people redo their changesets until they get them right." Philip Brown suggested, "You should allow for changes that are "formatting change only", with no actual code structural change. You could pass the results through stage 1 of gcc, and only allow it if the parsing tree is identical." Larry replied that BitKeeper was used for more than just GCC-compilable files. Eli asked, "I assume you can have content-specific validators run before a commit? (CVS can.) A validator could see that it was formatting only and mark it in someway perhaps?" Larry said yes, BitKeeper had triggers, which could do what Eli wanted.

11�Aug�2003�-�16�Aug�2003 (20 posts) Subject: "2.4.22-rc2 ext2 filesystem corruption"

Martin Maney reported, "I've got a very repeatable file corruption under 2.4.22-rc2 that does not manifest under 2.4.21. My repeatable test case only (so far?) causes the data in the file to be corrupted, but I suspect metadata can get hit as well, and I have seen some filesystem errors that were probably caused by this, but not so that I can say so with certainty." Stephan von Krawczynski suggested running memtest to confirm there were no problems with his RAM chips. And Marcelo Tosatti asked for a clear recipe to repeat the corruption. Martin said that copying any large file (perhaps 50M in size) across filesystems, and then umounting the destination filesystem would reproduce the corruption. After remounting, the data would have changed. Marcelo asked, "can you try to isolate the corruption. You said it didnt happen with 2.4.21 -- which pre shows up the problem?" Martin replied, "The problem appears only in rc2 (okay, assuming it's not a regression). With 2.4.21-rc1 the file corruption I've been seeing does not happen." ... "I will also try an rc2 with unnecessary features omitted from the build. So far I've stayed with the base config, but it's a config shared by most of the machines on the LAN and thus has plenty of extras."

Marcelo thought the problem might have something to do with the Promise driver, which changed in -rc2. He posted a patch to revert that change, but instead of this, Martin disabled his Promise chip entirely. After that, he no longer observed the corruption. Marcelo asked him to try again with the same hardware, and just that one patch reverted, so they could be sure where the problem was. Martin did this, and confirmed that the corruption could not be reproduced with the patch reverted.

Having located the problem, Alan Cox pointed out that it would still be necessary to audit the code in order to find a fix. There were a couple more posts, and the thread petered out.

12�Aug�2003�-�14�Aug�2003 (10 posts) Subject: "multibooting the linux kernel"

Nufarul Alb posted a patch that made it possible to pre-load modules before the kernel actually booted. Christoph Hellwig pointed out that Nufarul's patch was against 2.4, and so did not have much chance of being accepted. He suggested porting the work to 2.6-test and resubmitting it. He also suggested coding in the Linux style rather than the GNU style. Nufarul clarified, "Those are not my patches. They belong to a certain Christian Koenig. He doesn't mantain them any more and I'm searching for someone to mantain this project." H. Peter Anvin suggested just using initramfs instead.

Andrew Morton announced 2.6.0-test3-mm2, saying it included "zillions" of bugfixes, framebuffer updates, and some more CPU scheduler tweaking. Peter Osterlund posted "a fix for synaptics touchpads with "multi buttons". The patch comes from Hartwig Felger, who wrote the original multi button support patch (p00003_synaptics-multi-button.patch). The same bug fix has been included in the XFree86 driver for a few weeks, and seems to work fine. (That part of the X driver is only used for 2.4 kernels.)"

14�Aug�2003�-�18�Aug�2003 (16 posts) Subject: "[PATCH] Make modules work in Linus' tree on ARM"

This patch allows modules to work in Linus' tree for ARM, and is the one thing which prevents Linus' tree from building for any ARM machine.

After reviewing the /proc/kcore and kclist issues, I've decided that I'm no longer prepared to even _think_ about supporting /proc/kcore on ARM - it just gets too ugly, and adds too much code to make it worth the effort, the time or the energy to implement a solution to that problem. This is especially true since most people use kgdb or similar rather than /proc/kcore anyway. /proc/kcore is a "wouldn't it be nice" feature.

The reasons that I'm going with this solution rather than fixing /proc/kcore is that:

to add a kclist entry for each module would mean hacking the kclist structure into vm_struct's ->page pointer with disgusting hacks. I think we can all agree that this isn't the way to go. The alternative is to create Yet Another Memory Allocator, and this isn't something I want to see in what is now an embedded architecture.
we'd need to find some way to dynamically reserve the virtual mapped memory regions for the kernel direct mapped RAM. Since ARM uses a generic memory initialisation implementation which handles contiguous and discontiguous memory, it doesn't lend itself well to the kclist approach, and I'm not about to add extra callbacks from init/main.c (so we have kmalloc available) just to support this.

If someone _else_ wants to put the effort into fixing ARM modules to work nicely with /proc/kcore, be my guest - I'm just no longer interested in this problem space.

Maybe in 2.7 a generic "reserve an area of memory in this region" function like __get_vm_area below is in order?

Therefore, I'm providing a patch which adds the necessary changes to the core kernel code to make the current modules solution work for ARM.

Linus Torvalds suggested just removing /proc/kcore entirely. He said, "Does anybody actually _use_ /proc/kcore? It was one of those "cool feature" things, but I certainly haven't ever used it myself except for testing, and it's historically often been broken after various kernel infrastructure updates, and people haven't complained.."

John Bradford said he'd used it on a few rare occassions, to recover files that had been in RAM when its application had crashed. Daniel Jacobowitz also said he used /proc/kcore for debugging, though he said he'd much rather have kgdb in the kernel. And Tony Luck from Intel disclaimed:

I only fixed it up because someone at SGI complained that my ia64 kernel virtual space re-arrangements had broken it (even more ... it had never been right for ia64).

Even now, it's still full of races (e.g. if you start gdb to look at /proc/kcore, then load or unload modules).

Plus gdb doesn't really understand that kcore is a special file, so it caches values (read "jiffies" twice and notice that it doesn't change ... because gdb cached the read).

So don't mistake my recent activity fixing kcore for interest in its continued existence.

Alan Cox urged Linus to put kgdb in the kernel, and added that he wouldn't mind seeing /proc/kcore become arch-specific, or even go away altogether. Eli Carter also said he'd like to see kgdb in the kernel.

John Levon said that /proc/kcore was the only way to figure out the kernel pointer size from user-space, and he pointed out that all suggestions for how to do it had objections listed in an earlier linux-kernel discussion. Russell summarized, "oprofile requires /proc/kcore support" . Linus said, "Why not just fix the oprofile interfaces to contain that information? You already have to export CPU type, buffer size etc.." John said he'd be happy to do that, but he'd been under the impression that such a patch would be rejected as unnecessary bloat. He whipped up a patch and posted it.

18�Aug�2003 (12 posts) Subject: "Re: Fix up riscom8 driver to use work queues instead of task queueing."

In the course of discussion, Russell King suggested that for older serial drivers, the "correct approach is for someone to convert them to use the new serial driver core (and fix the driver core interface to allow them to work with it.)" He didn't have any of that hardware, but he'd been hoping for someone who did to step up and fix them. Linus replied:

Hey, I'm all for that for 2.7.x. In the meantime, they've been broken for a year, so let's just try to fix them up into a "limping along" state.

I don't have the hardware either, but at least now they should be testable on UP configurations (SMP is generally still broken due to the drivers expecting to be able to disable all interrups globally instead of using proper locking).

I'd be interested to hear whether the dang things work. Of course, there probably aren't that many people around with the hardware any more. I could just have added them to the BROKEN list, but since they _might_ work it seemed like a better idea to be hugely optimistic instead ;)

Russell replied, "True. However, there is the opposite point of view which is equally valid. There aren't many people with the hardware, and the people that there are aren't interested in development kernel series, so even if we did convert them during 2.7, we wouldn't hear about it until 2.8." And Linus said:

Yes. However, what worries me more is that there are people who have the hardware, but because the driver won't even compile for them, they just go "oh, well, I'll try it again when the _real_ 2.6.0 hits the streets".

Which obviously won't work.

So I'm trying to make sure that all the broken drivers are gotten to a working state. Right now, considering how long they've been broken, that means "it must compile" so that people can test them.

The "leave it broken, so that somebody will fix it properly some day" approach is a fine one for early development series. But right now I'd prefer to see patches to make drivers compile cleanly, even if people can't test them on real hardware.

The intersection of people who have the hardware, and people who have the time/knowledge to convert a driver, may be empty. Expecially for odd hardware. So let's get those drivers compiling, even if we can't test them, so that others _can_ test them.

20�Aug�2003 (1 post) Subject: "[ANNOUNCE] Supporting asynchronous events in Linux with AEM"

I'd like to announce the availability of AEM (async. event mech.). This project is an attempt to provide a generic and native support for asynchronous events in the Linux kernel.

See below for an overview of AEM. More information can be found here http://aem.sourceforge.net

Your comments are valuable and I will be pleased to get any feedback from you.

Overview

The primary objective of AEM is to provide a native kernel mechanism, which doesn't make use of other techniques to support the semantic. The reason behind this is to be able to handle a very huge number of events in a scalable and responsive way.

Basically, AEM allows an application to register to system events by supplying user-space event handlers during registration. When an event occurs in the kernel the corresponding event handler is executed with the data in parameter.

AEM is a communication mechanism more than a notification mechanism in the sense the main goal is really to pass information quickly from the kernel to the user space applications, both ways. This means the data can be modified by event handlers and be re-interpreted when back into the kernel.

The second goal behind AEM is to provide the atomic execution of user space handlers directly in reaction to events. Priorities can be associated with events to give high priority events the possibility to boost their corresponding processes. As opposed to other styles of event monitoring mechanisms AEM is working bottom-up, i.e user processes are executed/created by system events.

Generally, we assume that event handlers are short lived executing quickly in the same execution context as the calling process. But if necessary an event handler can also be executed inside a new process context permitting its execution in parallel with the main thread of execution. In this case, processes are created on the fly.

I'm taking special care to integrate AEM with existing mechanisms providing similar, although different, functionalities. I want to stress the fact that the goal of AEM is not to replace what already exist but to provide a complementary support in Linux.

I'm conscious the current implementation is not perfect and a lot of work is still to be done. Any suggestion for improvement is welcome.

Current status

Specific structures and activation points for events must be present in the kernel. This is implemented by a patch supplying this basic infrastructure.

The whole implementation is provided by independent kernel modules. One module supplies the core functionalities while the other modules supply specific implementations of event handling mechanisms (fetching and handling of data). Also, definitions of the calling APIs are implemented by modules.

This architecture is very flexible. Different implementations can coexist in the same time. This gives the possibility to stay compatible in case of a change of API or semantics.

AEM is currently supported on Linux kernels 2.6.0-test1 and 2.4.20.

20�Aug�2003�-�21�Aug�2003 (2 posts) Subject: "[ANNOUNCE] FUSD v1.10 now available"

We're happy to announce release 1.10 of FUSD, the Linux Framework for User-Space Devices.

If you have a Linux 2.4 kernel running devfs, FUSD is a combination of Linux kernel module and userspace library that lets you write userspace programs that can act as character device drivers for files under /dev. Your program reigsters the device with the kernel module; then, it proxies system calls (e.g., open(), read()...) to your program. Your userspace program can respond to these system calls as a kernel module would. Strict error checking at the user/kernel boundary prevents such userspace drivers from corrupting each other, the kernel, or even the processes using the devices they manage.

v1.10 has a number of enhancements, including:

Now safe for SMP and preemptible kernels
Includes both C and Python bindings
/dev/fusd/status device shows a summary of devices registered and in use
Updated documentation and various other bugfixes

Unfortunately, FUSD does NOT work under later 2.5 or any 2.6 kernels. The recent changes to the devfs API break FUSD in a way that we haven't yet looked into fixing.

�
Kernel Traffic Latest�\|�Archives�\|�People�\|�Topics	Wine Latest�\|�Archives�\|�People�\|�Topics	GNUe Latest�\|�Archives�\|�People�\|�Topics
Czech

1.	11�Aug�2003�-�14�Aug�2003	(27 posts)	Code-Formatting Patches And BitKeeper Revision History
2.	11�Aug�2003�-�16�Aug�2003	(20 posts)	ext2 Corruption In 2.4.22-rc2
3.	12�Aug�2003�-�14�Aug�2003	(10 posts)	Pre-Loading Modules Before Bootup
4.	13�Aug�2003�-�17�Aug�2003	(18 posts)	Linux 2.6.0-test3-mm2 Released
5.	14�Aug�2003�-�18�Aug�2003	(16 posts)	/proc/kcore May Be Going Away
6.	18�Aug�2003	(12 posts)	Development Strategy For Unmaintained Drivers
7.	20�Aug�2003	(1 post)	New AEM (Asynchronous Event Mechanism) For Linux
8.	20�Aug�2003�-�21�Aug�2003	(2 posts)	FUSD v1.10 Released

Kernel Traffic #229 For 8�Sep�2003

By Zack Brown