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.

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.

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 ;)

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.

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.

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.

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.