Please don't use bk patches, they have turned out to be pretty much unusable.

Either make a (controlled) bk tree available for pulling, or just use old-fashioned patches.

BK won't let you accept a patch unless the receiving repository has the parent of the patch. In other words, this won't work:

bk clone bk://linux.bkbits.net/linux-2.5
<make some changes>
bk commit (or bk citool) # creates changeset 1.800
<make some changes>
bk commit (or bk citool) # creates changeset 1.801
 
# Now you want to send the second patch to Linus so you do a:
bk send -r+ - | mail linux-kernel@vger.kernel.org

That will fail when Linus tries to accept the patch, because he doesn't have your 1.800.

Current kernel preemption code opens a small window between the check for need_resched in schedule and the setting of preempt_count to zero in preempt_schedule. While this window is generally short (a few cycles) the resulting period of non-preemptibility could be as long as the next timer tick - much longer, in fact, if a lock is obtained in the interim.

This patch checks for need_resched in preempt_schedule after setting preempt_count back to zero, before returning. The overhead is negligible and it is crucial to never miss a preemption opportunity.

Two main reasons:

1. In 2.5, we have a kernel preemption model that makes the fully preemptible, subject to SMP locking constraints and a few other rules. Without this patch, we break this model and do not allow preemption when it is in fact legal.
2. Like I said, it may be awhile before we can preempt again. If we take a lock after return from schedule but before the next interrupt, it can be many tens (or hundreds) of milliseconds before we release the lock and subsequently preempt. If need_resched was set in response to an important real-time application, the wait can be detrimental. Servicing apps as soon as they become runnable is the point of preempt-kernel, anyhow.

It is not crucial in the sense we break anything; merely that we are working toward providing very efficient response and dispatch to interactive and real-time applications and we _must_ respond to them as soon as possible.

I am a member of a small team which is trying to port Linux to Infineon's TriCore processor. The gcc version that is available for the aforementioned processor is 2.8.1. On the other hand the aforementioned processor does not embed a MMU, so we are using the uClinux patch with the 2.4.x kernel.

I am wondering if with the 2.8.1 version we will be able to obtain a reliable 2.4.x kernel. According to the /Documentation/Changes file the gcc 2.95.3 is required...

Between the gcc version 2.8.1 and the 2.95.3 some extra flags and options have been added, but are all these requisite for ALL the processors ???

I have no official connection to the writing of this driver. It's a big company :) I'm most interested in this because I have an old ServeRAID card at home.

I know that none of the real authors is actively working on fixing this.

Can this be accepted as a band-aid until the maintainers decide to maintain a 2.5 driver, or are we pushing authors to rewrite drivers which don't use the new DMA scheme?

Quite frankly, since after several months of being broken, nobody has stepped up to actually fix it, I am most definitely going to accept the band-aid solutions to SCSI drivers that will thus only work on x86.

"Not acceptable" is when broken drivers means that people can't test the features they _care_ about. Apparently nobody seems to care about the SCSI driver itself..

This patch tries to split arch/i386 up into machine specific directories (similar to the way arch/arm is done). The idea is to separate out those machines which don't look like standard PCs (particularly from an SMP standpoint). For the current kernel, all it really does is to get the visws stuff into a separate directory (arch/i386/visws). I've also taken some files which aren't going to be used by non-pc SMP machines (mainly related to mpbios and ioapic) and placed them into arch/i386/generic.

The patch goes much further than visws needs, mainly because it now allows me to add my voyager stuff in a separate arch/i386/voyager directory with virtually no disturbance of the main line code. I'm afraid there are also still four VISWS defines in arch/i386/kernel/smpboot.c because it wasn't obvious to me how to get rid of them simply.

The 269k diff file (large because it has a lot of file moves) is at

http://www.hansenpartnership.com/voyager/files/arch-split-2.5.8.diff

There's also a bitkeeper repository with all this in at

http://linux-voyager.bkbits.net/arch-split-2.5

I haven't done anything about the other half of i386/arch reform which is splitting the PC directory up into bus types, but I believe Patrick Mochel is thinking about this.

A couple of comments.

• There is no way to build a generic kernel, that just needs a command line to select the architecture. Something that is important for installers. Even better would auto detection of the platform from firmware information, but you can't always do that.
• By just allowing redirecting setup_memory_region you don't allow for architectures that don't have the 384K memory hole.
• The hooks you add aren't used and are so generic it isn't obvious what they are supposed do from their names.
• setup_arch.h is nasty. What code it has depends on what it is defined when it is included. Couldn't 2 headers to this job better? Or better yet can't you just use function calls?

And of course you don't look at allowing different firmware implementations, but I'm doing that, so it is covered. :)

Not necessarily bus types, but close.

I've done three sets of cleanups in the arch/i386/kernel/ directory:

• x86 CPU
• mtrr
• PCI

Each one does similar things to those drivers: moves the support into subdirectories, and splits the monolithic files into platform-specific modules.

Doing this has several advantages:

• Only the code for your platform gets compiled in
• Resulting code has fewer conditional compilation constructs
• Resulting code is more extensible and modular
• Fewer confliciting changes in files with mulitple contributors.
• It's easier to figure out what the heck is going on

The main motivation behind this has been the PCI driver, especially with the numerous conflicting changes that I've seen both personally, and with the various ACPI and NUMA changes. I've been wanting to do something like this for about a year. About a month ago, I finally just sat down and did it.

The patches can all be found at

http://kernel.org/pub/linux/kernel/people/mochel/patches/

Unfortunately, maintaining these massive changes is time consuming, and conflicting with other goals and timelines. The only one I really care about is the PCI driver. I've had a chance to up-port it to 2.5.8, and should work for most people (though I've only tested it on single and dual x86 boxes w/o ACPI support)

The CPU cleanups are against ~2.5.6, and most likely won't apply to the current tree. Conflicts tend to be obvious, and easily fixable, if anyone is willing to up-port it.

Ditto for the mtrr driver, though it's pretty stale (~1 month old), and likely to have more conflicts.

If there is serious interest, I'll up-port them to the latest kernel and export BK trees.

In 2.5, there is the system call sched_setaffinity. It is rather new so your libraries do not support it - see example code and headers at:

ftp://ftp.kernel.org/pub/linux/kernel/people/rml/cpu-affinity

For 2.4, there is not yet such an interface. At the above URL, you can find a proc-based and a syscall-based interface for setting and retrieving affinity.