Kernel Traffic #232 For 20�Sep�2003

we're working with several vendors to try and get more bandwidth for bkbits.net. We think we have a line on a deal where we can get a full T1 just for bkbits.net for about $500/month. If we get that then we'll turn on the patch server feature so you can hit any URL and get a regular diff -Nur style patch for that changeset (or range of changesets).

We've avoiding turning on that feature in the past because we share the T1 line that bkbits.net lives on with all the rest of bitmover and we are partialy a distributed company. We do VOIP phones and when you guys clone a repo our phones don't work - that makes us look bad during a sales call. I'm not complaining, we get nice stress testing from bkbits so you should hammer on it all you want but I'd like it if we could really encourage that more. Turning on a patch server should do the trick.

ETA on this is a month.

I'm pleased to announce the release of the first patchset of power management changes for 2.6.0. The purpose of this release is to give people a chance to review and test the PM code before it's sent on to Linus.

These patches include a number of cleanups and fixes to the PM core code, the driver core PM code, and swsusp. I have verified that all suspend states (standby, suspend-to-ram, and suspend-to-disk) work on a number of personal systems using ACPI as the low-level power interface. However, this is with limited functionality (from a VGA console with minimal processes running).

These patches should restore suspend functionality for those that were able to successfully do it before -test3 and -test4. My apologies for the inconvenience my previous changes caused. These patches will probably not allow any more people to suspend/resume than before.

The net benefit of these, and the already committed ones, are a cleaner power management subsystem and the development of the proper framework for successfully suspending and resuming the entire system. There are still several rough edges, though we seem to be making headway on those relatively rapidly, and are my sole focus at the moment.

My main concerns right now are:

• Platform devices, and more generally, devices that may belong to more than one class. It's mainly a driver model problem, though it has PM implications that appear to be holding a few people up.
• Drivers
  Drivers have always been the main impedence to having a working PM core, though it's been difficult to make a lot of progress. I have a number of devices that I will verify work properly, and be in contact with the maintainers if necessary. (Though, I seem to be having more problems with IRQ routing at the moment.)
• Getting it work on more systems.
  Hopefully we will not run into any serious issues, though the PM code has traditionally been finicky. I have a wide array of test machines and willing testers, so this should move quickly.
• APM
  I unfortunately have not had a chance to look into the reported APM problems. But, I'm happy to say that I finally dug out an old laptop that has APM on it. I should make traction soon.

I encourage willing people to download the patch, test, and report any problems back to me and/or the list. I cannot guarantee definite or timely results for systems where PM simply doesn't work. However, the more systems we characterize, the easier this will become in the future. Please be patient.

In a continuing series of "Things we should have done 5 years ago, do they really need to be done before the release of 2.6.0", here's a prototype of splitting the kernel headers into stuff we want userspace to see and stuff we don't.

The basic principle is to put user headers in usr/include/linux and usr/include/asm-$(ARCH). Kernel headers may then include them as <user/foo.h> and <user-asm/foo.h>

This patch implents the 4 lines of Makefile magic necessary and converts cdrom.h to use this split. Note that we can convert headers as slowly as we care to with this scheme.

Header files intended for use by users should probably drop linux/types.h just include <stdint.h>,,, Then convert the types over to ISO C99 types.

s/__u8/uint8_t/g
s/__u16/uint16_t/g
s/__u32/uint32_t/g
s/__u64/uint64_t/g

s/__s8/int8_t/g
s/__s16/int16_t/g
s/__s32/int32_t/g
s/__s64/int64_t/g

I've been working on microstate acounting, and am interested in better metrics overall, for capacity planning and for accounting.

I think that SGI also have been doing some work -- see http://oss.sgi.com/projects/csa/

So the story so far..

• ATI grab 2.4.16's AGP driver.
• Working AGP3 support happens in 2.5
• ATI gets backported to 2.4 and 'munged'.
• Additional fixes go into 2.5
• ATI forwardport their trainwreck to 2.6.

It shouldn't have *any* need whatsoever to touch agpgart in 2.6.

The mind truly boggles.

They do some pretty evil stuff like..

+#ifdef STANDALONE_MODULE
 MODULE_LICENSE("GPL")
+#endif

Some of the folks at ATI really seem to be quite clued and 'get it' (Like those responsible for sorting out the Radeon IGP GART driver). On the other side of the coin the FireGL driver folks just get worse every time. If they actually *tried* to communicate with the community what they need from agpgart that its so obviously lacking, then there'd be no need for any of this nonsense.

I actually think this is degrading the code rather then improving it. Right now the various macros are located in the include/asm-<foo> directory next to the items where they are used. Moving it all into one big catch-all assembly file makes it a lot harder to read things and debug the code. I already took a look at the changes that went into the ia64 part of the tree and I really think that was a step backwards.

In terms of compiling the Linux kernel, I will argue that the Intel compiler is broken if it cannot handle inline assembly. Inline assembly is just too fundamental a feature for the kernel. This is totally ignoring the question of whether one should be compiling the kernel with non-GCC in the first place.

I might agree, but "compiler.h" is getting increasingly messy, and this just makes it worse (and sets the stage for making it even worse in the future).

Is somebody willing to split up compiler.h into a per-compiler file (and yes, I think "gcc-2.95" is a different compiler from "gcc-3.2" in this case, since that is what most of the compiler.h #ifdef's are all about).

Then, have a config-time "set the right symbolic link" the same way we do for "include/asm/", so that we can have a set of _clean_ compiler-dependent abstractions.

At that point, we can look at adding support for non-gcc compilers without horrible problems. At least as long as the compiler otherwise is "sufficiently good" (which clearly right now includes support for inline assembly on most architectures).

Here is the next round of power management updates. BK users can get the changesets listed below from

bk://kernel.bkbits.net:/home/mochel/linux-2.5-power

A patch against 2.6.0-test5 can be found at

http://developer.osdl.org/~mochel/patches/test5-pm1/test5-pm1.diff.bz2

The patches for each individual changeset can be found in that directory.

The changesets there, and listed below, are cumulative, meaning they include all of the patches I posted last week. The highlights from this release are the following:

• Fixed suspend-to-disk support with preempt and SMP enabled.

  Suspend-to-disk will work on a UP system with SMP enabled, though it will definitely not on an SMP system. This is on the TODO list, albeit at low priority.

• Several small bug fixes.
• swsusp has been forked into two workable trees.

The code base of swsusp itself has been reverted to its state around 2.6.0-test3. A suspend-to-disk implementation called 'pmdisk' has been created in kernel/power/pmdisk.c that offers (for now) identical functionality, and an almost identical code base. That will change in the near future, as I submit more cleanups to it.

The pmdisk implementation is accessible via the sysfs interface:

echo -n disk > /sys/power/state

While swsusp is accessible via the /proc/acpi/sleep interface. It is possible to tie swsusp into the sysfs interface, and will entertain patches to do such a thing.

Note the new config menu options for pmdisk when building the kernel.

There is still a lot to do, including fixing the random crashes that some people are experiencing. I appreciate the testing people have done, and will appreciate any feedback concerning the patches or the functionality the patches implement.

I've made one or two attempts at beginning to use BK for my kernel development work, but each time I've been stuck by the licensing code. I use it for a little while, and then get a message about not being allowed to commit because of logging (or something to that effect). Can someone give me info on how to set up BK so that you don't get these issues? (I'm assuming I don't need to buy it to use it for kernel development). I should add that I'm doing 99% of my work disconnected from the internet.

Can I also suggest that info on this be added to Documentation/BK-Usage?

Read the license. The free use requires that you connect periodically to log what it is you are doing. Those are the terms of use. If that doesn't work for you there is the CVS gateway and the SVN gateway.

If you are having problems with BK you might try [email protected] or [email protected].

Thanks to Stephen Hemminger for pointing out how obsolete modules.txt is.

modules.txt contains mainly ancient information which is replicated in the kconfig help message, README, makefile.txt or the modprobe manual page. The only part which is not covered elsewhere is the "building external modules" which is still being debated (and belongs under the kbuild docs). kmod.txt reference removed from index, too.

Please sent patches to update Kconfig files which referred to modules.txt in small pieces to trivial at rustcorp.com.au. Please abbreviate wording, too, as follows:

 -        To compile this driver as a module ( = code which can be inserted in
 -        and removed from the running kernel whenever you want), say M here
 -        and read <file:Documentation/modules.txt>. The module will be called
 -        apm.
 +        To compile this driver as a module, say M here: the
 +        module will be called apm.

I found another such gem in Documentation/smp.tex, which was last updated more than five years ago. Favorite quote:

"A single lock is maintained across all processors. This lock is required to access the kernel space."

The whole file has only historic value and should probably be removed or have a comment that it does not apply to the current code.