So it seems that the 2.6.x geometry code breaks dual booting, since Windows wants "sane" CHS values. See the thread on slashdot, or http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00908.html

Although Fedora Core is current taking grief for this, it's really a 2.6.x kernel problem AFAICT.

Has anybody taken the time to hunt down the csets that cause this massive partition table breakage? If so, it will save me some time tracking this down.

I already wrote several many-page texts on this stuff. See, e.g., http://www.win.tue.nl/~aeb/linux/Large-Disk.html

Attempt at a brief summary:

1. Hardware:

   In the ancient past a disk (MFM or RLL) had a geometry describing how many sectors per track, how many tracks (cylinders), and how many heads the thing had.

   With the advent of IDE it no longer was true that a disk has a well-determined geometry: the ATA command INITIALIZE DRIVE PARAMETERS will tell the disk what geometry it is supposed to have today.

   An IDE disk can be accessed in CHS and in LBA mode, and the geometry specified, or read via the ATA IDENTIFY command, defines the meaning of a CHS command. With LBA access no geometry plays a role.

   SCSI disks never had this geometry nonsense.

   Linux uses LBA and does not need to concern itself with geometry.

2. DOS / Windows:

   The DOS disk interface used CHS. If the disk uses LBA the driver has to convert CHS to LBA and hence needs a geometry (at least H, S).

   Because DOS (BIOS INT 13) had 10 bits for C, and 6- bits for S, while ATA uses 4 bits for H, this scheme could address only somewhat less than 2^20 sectors. The 528 MB limit.

   All kinds of translation schemes were invented to give the BIOS interface a geometry different from that used at the ATA interface. The user chooses a translation scheme in the BIOS setup. The geometry is now unrelated to the disk, but is known to the BIOS.

   Various BIOS calls exist that report on various versions of the geometry.

3. Partition tables:

   A DOS-type partition table (see, e.g., http://www.win.tue.nl/~aeb/partitions/partition_tables.html) gives the location of a partition in two ways. One is the way used by Linux (the starting sector and length, both given in 32 bits). The other, used by DOS, given CHS for the first and for the last sector (both in 24 bits).

   Even when nobody cares about geometry any longer, is it still necessary to fill these CHS fields.

   If the filesystem living in the partition is a FAT filesystem, then the boot sector of the FAT filesystem again gives information on the size of the partition.

4. Linux:

   There is an ioctl HDIO_GETGEO that returns the geometry of a disk and the starting sector (offset) of a partition. There is an ioctl BLKGETSIZE that returns the size (in 512-byte sectors) of a block device in 32 bits. There is an ioctl BLKGETSIZE64 that returns the size (in bytes) of a block device in 64 bits.

   Clearly, BLKGETSIZE is obsolescent - it should be replaced by BLKGETSIZE64 everywhere. 2^41 B is 2 TB, and some RAIDs are larger.

   The HDIO_GETGEO ioctl gives heads, sectors and cylinders - fields of 1, 1, 2 bytes. On the one hand that is reasonable - no interface exists that can use more than 16 bits for the number of cylinders. On the other hand there is still some broken software that computes the size of a disk as C*H*S, and obtains C, H, S by HDIO_GETGEO. Of course this is broken, and introducing a new ioctl is no good - such software must be fixed to use BLKGETSIZE64.

5. Geometry use under Linux:

   Roughly speaking geometry was needed under Linux for two purposes: LILO (and similar bootloaders) and *fdisk. Of course, also programs that tried to emulate aspects of DOS/Windows are interested in a geometry.

   The LILO aspect has disappeared - with options like linear, or lba32, lilo uses linear sector numbers at install time, and converts them to CHS, when needed, at boot time.

   The fdisk aspect has also disappeared - after this geometry business had become infinitely complicated, nobody any longer tried to understand geometry, but just inferred from the partition table what geometry was used by the program that last wrote it.

   How did the kernel find a geometry? Mainly in three ways: (i) from boot parameters, (ii) by looking at the partition table, (iii) by asking the BIOS at boot time, before switching to protected mode.

   Information (i) - explicit specification - and (ii) - partition table - is also available to user space, no kernel needed. Remains the question whether (iii) is a good idea.

   It didnt always work, but often it worked. (And only on i386 of course.) Examples of failure: The code we had only asked the BIOS for info on the first two disks. An often-posed question was: I have two identical disks, how come they get different geometries? Also, the code we had failed when the system had SCSI disks. Also, the code we had assumed that the first two BIOS disks were hda and hdb. But there is no reason why that would be the case. For example, many people kept their large disks out of the BIOS since it would crash upon seeing big disks.

   So, this (iii) was a bit messy stuff with many problems, but OK for most people.

6. The present

   Linux no longer makes any attempt to invent a geometry. If someone needs a geometry, he is responsible himself for choosing one of the many concepts of geometry, and determining a value. What most software does is looking at the partition table, and that works.

   Maybe parted has not yet been updated to do this, that is why I conjectured that Fedora problems might be due to the use of parted.

   Was this a loss? I don't think so, but there is at least one use of the old situation that fails today: the installation of Windows systems from Linux media on a completely blank disk.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7-rc2/2.6.7-rc2-mm1/

• NFS server udpates
• md updates
• big x86 dmi_scan.c cleanup
• merged perfctr. No documentation though :(
• cris architecture update

Yes. Apparently gcc-2.95 doesn't like to dereference a "void *" even just inside of a "__typeof__". Which is a bit silly, since the result is a perfectly valid _type_. It's obviously been fixed since, so I never saw this.

(Aside - with anon unions also not working in older gcc's, I suspect we'll start requiring gcc-3+ in the 2.7.x timeframe. I know it's a lot slower, but apparently at least it now is starting to generate comparable code again).

Anyway, the easiest work-around would be to just avoid derefencing the pointer, but then you have to add strange modifiers (both "const" and "volatile" at the same time) to make sure that gcc won't complain about the assignment dropping any modifiers.

So the fix I'm going to check in is to just make "__chk_user_ptr()" be something that gcc never even sees, which allows us to simplify it for the sparse case too.

In other words, this should work for even old versions of gcc.. Just to be anal, you should probably test on gcc-2.95 ;)

we'd like to announce the availability of the following kernel patch:

http://redhat.com/~mingo/nx-patches/nx-2.6.7-rc2-bk2-AE

which makes use of the 'NX' x86 feature pioneered in AMD64 CPUs and for which support has also been announced by Intel. (other x86 CPU vendors, Transmeta and VIA announced support as well. Windows support for NX has also been announced by Microsoft, for their next service pack.) The NX feature is also being marketed as 'Enhanced Virus Protection'. This patch makes sure Linux has full support for this hardware feature on x86 too.

What does this patch do? The pagetable format of current x86 CPUs does not have an 'execute' bit. This means that even if an application maps a memory area without PROT_EXEC, the CPU will still allow code to be executed in this memory. This property is often abused by exploits when they manage to inject hostile code into this memory, for example via a buffer overflow.

The NX feature changes this and adds a 'dont execute' bit to the PAE pagetable format. But since the flag defaults to zero (for compatibility reasons), all pages are executable by default and the kernel has to be taught to make use of this bit.

If the NX feature is supported by the CPU then the patched kernel turns on NX and it will enforce userspace executability constraints such as a no-exec stack and no-exec mmap and data areas. This means less chance for stack overflows and buffer-overflows to cause exploits.

furthermore, the patch also implements 'NX protection' for kernelspace code: only the kernel code and modules are executable - so even kernel-space overflows are harder (in some cases, impossible) to exploit. Here is how kernel code that tries to execute off the stack is stopped:

 kernel tried to access NX-protected page - exploit attempt? (uid: 500)
 Unable to handle kernel paging request at virtual address f78d0f40
  printing eip:
 ...

The patch is based on a prototype NX patch written for 2.4 by Intel - special thanks go to Suresh Siddha and Jun Nakajima @ Intel. The existing NX support in the 64-bit x86_64 kernels has been written by Andi Kleen and this patch is modeled after his code.

Arjan van de Ven has also provided lots of feedback and he has integrated the patch into the Fedora Core 2 kernel. Test rpms are available for download at:

http://redhat.com/~arjanv/2.6/RPMS.kernel/

the kernel-2.6.6-1.411 rpms have the NX patch applied.

here's a quickstart to recompile the vanilla kernel from source with the NX patch:

http://redhat.com/~mingo/nx-patches/QuickStart-NX.txt

Just out of interest - how many legacy apps are broken by this? I assume it's a non-zero number, but wouldn't mind to be happily surprised.

And do we have some way of on a per-process basis say "avoid NX because this old version of Oracle/flash/whatever-binary-thing doesn't run with it"?

we have three mechanisms for this in Fedora:

1. the PT_GNU_STACK flag itself - you can turn executability on/off compile-time or even after the fact via the execstack(8) utility Jakub wrote. This only affects the stack's executability - if an application assumes a non-PROT_EXEC mmap() can be executed it might still break with NX - but based on experience with Fedora Core i'd say there's almost no such application.

   this method works in 2.6 too, since it supports PT_GNU_STACK. gcc's PT_GNU_STACK mechanism is very conservative - e.g. if an application does an asm() then gcc assumes that it might rely on stack executability and emits the X flag. [applications can then turn this off in the source if stack executability is not required.] Likewise, if gcc emits trampolines then the X flag is emitted too. (glibc knows about PT_GNU_STACK all across - so e.g. if a nonexec stack application dlopen()s a library that needs stack executability then glibc makes the stack executable on the fly via PROT_GROWSDOWN/GROWSUP.)

2. via a runtime method: via the i386 personality. So an application can trigger the 'legacy' Linux VM layout by e.g doing 'i386 java ./test.class'.

   this is a hack in Fedora - we wanted to have a finegrained runtime mechanism just in case. But it would be nice to have this upstream too - e.g. via a PERSONALITY_3G?

3. via a kernel boot parameter (exec-shield=0)

   with the NX patch this becomes noexec=off [the same flag works on x86_64 too]. This method is the most inflexible one, and is a last-resort thing. (Fedora also has a runtime global switch to turn off the VM layout changes.)

here's a list of applications that we had to fix/work around in Fedora when the VM layout changed:

• emacs _rebuild_. (it coredumps itself during build ... xemacs is OK.)
• some JDKs. Since they generate code and try to be as fast as possible they tend to rely more on VM details than normal applications.
• X's module loader assumed that brk was executable. (fixed)
• Wine. (it implements another OS so it's by definition very sensitive to layout changes.)

most of the breakages were unclean x86-only code that would have broken if ported over to 64-bit anyway.

old, legacy applications dont have the PT_GNU_STACK flag so they all work fine.

i've attached a patch that provides a cleaner solution. It does 3 changes:

• it adds a ADDR_SPACE_EXECUTABLE bit to the personality 'bug bits' section. This bit if set will make the stack executable. (if in the future we decide to make the malloc() heap non-exec [which i definitely think we should], that property will also listen to this bit.)
• in elf.h, it changes the x86 personality inheritance code to match that of x86_64 - which is a much saner method. This means if a complex app that does exec()s will all run with the personality of the parent(s).
• in exec.c, since address-space executability is a security-relevant item, we must clear the personality when we exec a setuid binary. I believe this is also a (small) security robustness fix for current 64-bit architectures.

(the patch also adds a break to the elf_ex.e_phnum loop - there can only be one STACK header in the binary and once we found it we should not iterate through the remaining program headers (if any).)

we didnt want to add a non-standard personality flag to Fedora so we abused PER_LINUX32 as the compatibility flag - but this only works on x86. With the ADDR_SPACE_EXECUTABLE flag there would be a standard method to fall back to 'legacy' executability assumptions Linux applications might make.

The whole point of NX, though, is that it prevents certain classes of exploits. If a setuid binary is vulnerable to one of these, then Ingo's patch "fixes" it. Your approach breaks that.

I don't like Ingo's fix either, though. At least it should check CAP_PTRACE or some such. A better fix would be for LSM to pass down a flag indicating a change of security context. I'll throw that in to my caps/apply_creds cleanup, in case that ever gets applied.

Let's not do this at all.

Anything that changes subtle behaviour at suid-execute time is just wrong. Imagine an app that has been tested in normal use, and then has a subtle bug when executed set-uid, simply because the address space layout changes. Or something that mysteriously works when you're root, but not when you're anything else. Ouch.

I think we should just look at the executable itself, not whether it is suid. If the executable says it is "NX-approved", then it's NX-approved. End of story - just try to make sure that as many executables as possible get compiled with the newer compiler suite that enables it.

Add a tool to let people turn on/off the NX bit on an executable if it turns out the executable can't work with it (let's say it was compiled and tested on a CPU without NX support), and everybody should be happy. You can have a trivial script that turns on the NX bit on all the legacy apps too, and then if testing shows iot wasn't a good idea, you can turn it off again on a per-executable basis.

Just for fun, can somebody that has the required hardware just test old apps with NX turned on?

I know we used to put the signal handler trampoline on the stack, but these days that should all be handled with the magic executable syscall page, so _normally_ I don't think an old application should even really care.

In fact, it would be interesting to just hear somebody running an older distribution with a new CPU and a new kernel, and see just how many programs need to be marked non-NX in "normal running".

If things are really that good, why are we even worrying about this?

It sounds like we should just have NX on by default even for executables that don't have any NX info records, and have some way of marking the (very few) executables that don't want it. Maybe have the NX fault print a warning when it happens for an executable that defaulted to NX on.

I think most people have seen the security disaster that causes most of the emails on the net to be spam. So this should be _trivial_ to explain to people when they complain about default behaviour breaking their strange legacy app. Especially if there's a trivial tool to add an elf section to make it work again.

So instead of having complex things to try to turn NX on for suid, we should aim to turn ot on as widely as possible, _even_if_ that means that people who upgrade hardware might have to do some trivial MIS stuff.

Make a kernel bootup option to default to legacy mode if somebody literally has trouble booting and fixing their thing due to "init" or similar being one of the problematic cases. Together with a printk() that says which executable triggered, it should be trivial to clean up a system.

Here's the latest exec-shield patch for 2.6.7-rc2-bk2, integrated with the 'NX' feature (see the announcement from earlier today):

http://redhat.com/~mingo/exec-shield/exec-shield-on-nx-2.6.7-rc2-bk2-A7

you first have to apply the NX patch, which can be found at:

http://redhat.com/~mingo/nx-patches/nx-2.6.7-rc2-bk2-AE

prebuild kernel RPMs for Fedora Core 2, with this latest version of exec-shield, are available at:

http://redhat.com/~arjanv/2.6/RPMS.kernel/

(kernel-2.6.6-1.411 has this latest, NX-aware exec-shield.)

if the CPU supports NX (and the kernel has been compiled with CONFIG_HIGHMEM64G) then exec-shield will use NX to provide page-level finegrained control over execution. On legacy CPUs that dont support NX the segment-limit method is used to control execution (in a coarser way). In the NX case the segment-limit is turned off altogether.

e.g. on an Athlon64 box the boot message looks:

NX (Execute Disable) protection: active

on a CPU without NX the boot message is:

NX (Execute Disable) protection: not present!
Using x86 segment limits to approximate NX protection

note: the NX patch will also protect against kernel-space code injection.

all the other components of exec-shield are identical between NX and non-NX: the brk area is non-executable, libraries and PIE binaries are moved into the ascii-shield as much as possible, and all aspects of the address space are randomized.

LTP-20040603

• Minor corrections to the NUM_PROCS patch
• Added the ability to pass NUM_PROCS to the -c option for runalltests.sh
• Fix genload in runalltests.sh, it was trying to run it in all caps, but the binary is all lower case. Should actually run genload now.
• Patch from Alastair McKinstry to allow LTP to build on Linux/HPPA
• Changes for parameters passed to aio-sparse for correct offsets and restrictions on sizes.
• Add new security tests to syscalls testsuite
• In acl_file_test.c and acl_link_test.c syscalls regarding xattrs are still done via syscall, although libc functions are available. Furthermore I found out that on older distros for non-intel architectures both attr/xattr.h and constants like __NR_getxattr are not available, so in this case the these testcases are not built.
• Updates for the DMPAI testsuite ppc64 support.
• Fix failure on rwtest versions rwtest03 and rwtest04 due to mmap running out of resources.
• Made changes to get thread ID vs get PID for NPTL threads for unique filenames where child/parent PIDs are the same.
• Changes to diotest5 and diotest_routines to eliminate random/intermitant failures on data compare.
• Fixed memory leak in mmstress testcase.
• Changed clone02 to use tid instead of pid to eliminate failures on NPTL threads(same PIDs for parent/child)
• Changed fcntl15 getpid to gettid (syscall(gettid)) to get unique thread ID vs common PID in NPTL threads.
• Added adp testcases.

The correct URL still is: http://www.ia64-linux.org/

Please update the URL.

grundler <512>host www.ia64-linux.org
www.ia64-linux.org has address 192.25.206.7

192.25.206.7 also hosted parisc-linux.org. But recently all the parisc-linux services migrated to another box. I'm not sure when/why the "old" box was disconnected or if it just crashed.

In any case, despite being at gcc-summit conf, willy did find time to migrate ia64-linux.org to the same host as parisc-linux.org. IIRC, that was yesterday. The DNS just hasn't propagated yet but ISTR willy said it would today at some point.

The entire ia64-linux web site is available via anon CVS. See cvs.parisc-linux.org but use "ia64-web" instead as the repository.

I've checked out a snapshot anyone can access for now on http://iou.parisc-linux.org/ia64-web/

The patch below adds EFI support to the SMBIOS driver. Since EFI already knows the address of the SMBIOS, this avoids having to scan for the table. It also enables use of the driver on ia64 machines. The patch also adds code to handle the case where the SMBIOS table resides in memory, which is the case at least for HP's zx1-based ia64 machines. If CONFIG_EFI is off, the resulting code should be unchanged (except for replacing a readb() loop into a memcpy_fromio()).

One observation: I believe find_table_max_address() is missing some readb() calls (it's dereferencing ioremap'pped addresses directly). I didn't try to fix that since I wasn't sure why it wasn't done in the first place.

Man, talk about going in circles!

If folks are serious about discouraging /dev/mem, then the SMBIOS driver makes tons of sense.

I was the original submitter. Somebody kindly pointed out to me (offline) the error of my ways, and I was able to get my userspace lib to work just fine using mmap() instead of read(). This takes care of two out of three of the main reasons I orignally submitted this driver.

Since my library was the only user of this lib, and I no longer need it, I asked several people if it would make sense to continue to support it or to pull it. The consensus was not to "bloat" the kernel with extra stuff if it can be done via /dev/mem.

If there are strong sentiments the other way, the code is still out there if somebody else wants to take over. I looked at what it would take to add EFI support for this, and it would be trivial. I just didn't want to become yet another absentee-maintainer if I no longer need the code.

Currently mousedev combines all hardware motion data that arrivers since last time userspace read data into one cooked PS/2 packet. The problem is that under heavy or even moderate load, when userspace can't read data quickly enough, we start loosing valuable data which manifests in:

• ignoring buton presses as by the time userspace gets to read the data button has already been released;
• click starts in wrong place - by the time userspace got aroungd and read the packet mouse moved half way across the screen.

The patch below corrects the issue - it will start accumulating new packet every time userspace is behind and button set changes. Size of the buffer is 16 packets, i.e. up to 8 pairs of press/release events which should be more than enough.

The patch is against Vojtech's tree and shuld apply to -mm. I also have cumulative mousedev patch done against 2.6.7-pre2 at:

http://www.geocities.com/dt_or/input/misc/mousedev-2.6.7-rc2-cumulative.patch.gz

a new version of the uClinux cross-compiler toolchain based on GCC 3.4 is available here:

http://www.uclinux.org/pub/uClinux/uclinux-elf-tools/gcc-3/

This release adds preliminary ARM support and includes binaries for Linux (both glibc23 and glibc22 distros) and Cygwin.

Many other things have been changed since the last public announcement:

Changes in release 20040605:

• Preliminary GCC 3.5 support.
• Add some GCC 3.4 patches by Peter Barada.
• Add support for GDB 6.1.
• Update m68k-bdm to 1.3.0 and use GDB patches distributed with it.
• Integrate preliminary ARM support. (Contributed by Steve Miller <steve.miller@st.com>).
• Fix genromfs patch for CygWin. (Reported by Jens Heilig <jens@familie-heilig.net>).

Changes in release 20040425:

• Update GCC 3.4 to the official 3.4.0 release.
• Update m68k-bdm to 1.2.0.

Changes in release 20040323:

• Update GCC 3.4 to the 20040317 snapshot.
• Update binutils to 2.15.90.0.1.1, which already contains all the required uClinux patches.
• Backport argument pointer corruption fix to GCC 3.3.3

Changes in release 20040309:

• Drop Insight support (DDD is better anyway) and install GDB in $PREFIX.
• Rename "interrupt" attribute to "interrupt_handler" in 3.3.x patches to match GCC 3.4.

Changes in release 20040112:

• Update GCC 3.4 to 3.4-20040114.
• Update uClibc to 0.9.26.
• Update binutils to 2.14.90.0.8 (and drop some integrated patches).
• Cleanup support for backwards compatibility links to m68k-elf- tools.
• Correctly detect GCC version for interim releases.
• Apply a couple of rogue patches to GCC 3.4.
• Fix build with gcc-java, but don't expect it to work right now.

Changes in release 20031230:

• Switch to m68k-uclinux for all components of the GCC 3.4 toolchain.
• GCC's compiler driver now adds required linker flags when building executables with -mid-shared-libary.
• Update uClibc to 0.9.24.
• Update m68k-bdm to 20031207 and import latest GDB patches.
• Update GCC 3.4 to 3.4-20031222.
• Update GCC 3.3.x to 3.3-20031222.
• Merge-in patches by Andrea Tarani for uClibc 0.9.23 and m68k-bdm.

iBCS ceased when I decided that "enough" vendors were targetting Linux as a Tier-1 platform and what was left was legacy proprietry stuff that either worked or would be painful to fix. iBCS then became linux-abi which ported to newer kernels and added UnixWare support. I guess there just isn't enough SYSV stuff left to keep any momentum behind linux-abi anymore either...

SCO stated a long time ago that they saw nothing in linux-abi to worry them.

Which is kind of interesting because iBCS started life pretty much as a way for Eric Youngdale to test his ELF loader code, which subsequently moved into the main kernel.

(iBCS CVS is still available on http://sf.net/projects/ibcs even if nothing else is. It doesn't go back quite to the start - I think my initial import was 1993...)

Ok, let's calm down for a while before the final 2.6.7.

-rc3 does a lot of sparse type cleanup, mainly thanks to Al Viro (but his work ended up getting some other people involved too, since the list of sparse warnings isn't as daunting any more). Some of that has unearthed real bugs which Al fixed.

But there are DRM, AGP, cpufreq, sparc64, and input updates there too.

I've released the 026 version of udev. It can be found at:

kernel.org/pub/linux/utils/kernel/hotplug/udev-026.tar.gz

(yes, there was a 025 release, I just forgot to announce it, full changelog is below)

kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ

For any udev vs devfs questions anyone might have, please see:

kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs

Major changes since 024:

• lots of minor bugfixes
• added udev_volume_id from Kay Sievers which is an excellent way to read block volume ids to create udev rules.
• deleted the dbus and selinux programs as they were not the way to integrate udev with those packages. DBUS integration with udev is now handled by the HAL project using the /etc/dev.d/ notifiers.
• update documentation. Thanks to Daniel Drake for this.

Thanks to everyone who has send me patches for this release, a full list of everyone, and their changes is below.

udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev

Daily snapshots of udev from the BitKeeper tree can be found at:
http://www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.

Released a new version of bridge utilities that supports both new 2.6.7 interface and older 2.6/2.4 releases. The only changes since 1.0 were internal to fix compatibility issues.

The tarball can be downloaded from:

http://prdownloads.sourceforge.net/bridge

Getting full functionality requires a build system with:

• libsysfs from the sysfsutils package
  http://linux-diag.sourceforge.net/Sysfsutils.html
• kernel (and headers) from 2.6.7-rc1 or later

Note: libsysfs has not been fully integrated by the main linux vendors. So producing a full functional package is not possible with the default spec file.

The utilities will build (and run) on earlier systems it will just default to the old interface and which doesn't have 32/64 bit compatibility.

Available at http://ep09.pld-linux.org/~mmazur/linux-libc-headers/

Changes:

• updated to 2.6.6 kernel
• readded allmost all of the sound/* headers; some of those contain driver specific definitions that might be used in userland apps to control various hardware features
• added scsi headers - more on that below
• fixed macros in byteorder/swab.h - now hdparm on big endian machines really builds
• other fixes (eg. frottle should build)
• I've made linux/audit.h parse out of the box; if I understand correctly this is supposed to be a "kernel talks to userland" thing

First of all sorry for the long delay - this version should be here three weeks ago, but I've been kind of busy. This shouldn't happen anymore and new version should be released no more than a week after the kernel. (yes, I know 2.6.7 will probably be here in a week or so :)

As for the addition of sanitized scsi headers - I've had some requests for it. Up until now I've encountered only one app that wanted something more than glibc had to offer and am not entirely sure if using these headers instead of glibc's won't break more things than it fixes. Test it if you like and do send a bugreport if you find that it breaks something.