For some reason the ACPI people continue to make the mistake
of thinking that they are the root of the system.  Disabuse
them of that notion.

Clean up BSD accounting locking code..

The appended patch brings the fixes applied in 2.4 to shmem.c to 2.5.

In Detail:
- Add needed checks for shmem_file_write and shmem_symlink
- Add Documentation/filesystems/tmpfs.txt and adjust Config.help
- Add uid and gid mount options
- Make the error messages more user friendly

Pick up binfmt_elf.c SET_PERSONALITY() fix from 2.4.18.

That preempt_count really is supposed to be unconditional,
architectures please take note and add to your thread info.

into home.transmeta.com:/home/torvalds/v2.5/linux

If you could only review one of the 9 patches, this would be the one.

- removes acpitable.c vestiges
- adds ACPI IRQ routing support to PCI (disableable via pci=noacpi option)
- adds code to get a <1MB page for sleep, and ACPI boot to setup.c
- allocates another page in the fixmap for ACPI
- changes driverfs a little to work better with ACPI.

This patch removes arch/i386/kernel/acpitable.c. As mentioned previously,
the new ACPI code integrates this, so it's no longer needed.

This updates the Configure.help, both in arch/i386, and in drivers/acpi.

This removes the old OSPM code. It lived under drivers/acpi/ospm/*, but
the new code just lives in drivers/acpi, and removes some unnecessary
abstraction that this old code had.

This is the update to the core interpreter code.

This is the config.in and makefile changes for the latest code. The most
(only) interesting thing probably is ACPI is no longer flagged experimental.

This patch updates the acpi IA32 arch-specific files. Part of this is
taking what was acpitable.c and implementing it with better integration
with the rest of the ACPI code.

This patch adds in the new drivers.

- Support for driverfs
- File/code layout more in the Linux style
- improvements to battery, processor, and thermal support

This is the first of 9 patches. We did a complete rewrite of the
Linux-specific code, so we wait for things to stabilize before submitting.
There will be more updates, but *much* smaller.

#1 - this updates the header file.

The patch below eliminates a case of boot_cpu_data corruption
on SMP x86 machines. This was first observed on SMP Athlons,
but it also affects SMP Intel boxes in a less serious way.

When the secondary processors boot and execute head.S:checkCPUtype,
the code performs a 32-bit write of a small constant to the
byte-sized variable boot_cpu_data.x86 (X86 in head.S). Since the
write is 32-bit, it also writes zeros to the following 3 bytes,
which clobbers the x86_vendor, x86_model, and x86_mask fields
previously set up by check_bugs()'s call to identify_cpu().
Thus, after smp_init(), boot_cpu_data will _always_ identify
the CPU as an Intel (X86_VENDOR_INTEL == 0 in processor.h) with
model 0 and stepping 0.

The effect in standard kernels is not catastrophic, since:
(a) most SMP x86 boxes are Intel
(b) most uses of x86_vendor occur before smp_init() or reference
    the SMP cpu_data[] array
(c) most post-boot references to boot_cpu_data occur in the
    cpu_has_XXX macros which only read the x86_capability[] array
However, third-party extensions (like my x86 performance-monitoring
conters driver) can get seriously confused by this mis-identification.

Don't print out FAT superblock warnings if the IO failed.

Seperates qnx4_sb_info from struct super_block.

Seperates smb_sb_info from struct super_block.

Seperates msdos_sb_info from struct super_block for msdos and vfat.
Umsdos is terminally broken and is not included.

NR_IRQS should be 16 when the IO apic is not configured, as the 8259 PIC
cannot generate any more interrupts.  It also fixes a bug where the IDT
gets populated with random addresses, since only 16 entry stubs are
created. 

This changes the F00F bug workaround code to use the fixmap facilities
instead of touching the page tables directly.  It also removes the
assumption that only 686's don't have the bug.  I have confirmation that
the patch works on buggy pentiums. 

It needs the following patch

	In case if proc_pid_make_inode() steps on exiting task we do
iput() and return NULL.  Unfortunately, in that case inode->i_ino
doesn't look like inumber of a per-process inode and we take the
wrong path in proc_delete_inode().  I.e. do dput(PDE(inode)).  Which
is left uninitialized...

	We used to get out with that almost by accident - that code
worked only because we had zeroed out one field of union and that
guaranteed that another field would be NULL.  It worked, but broke
at the first occasion.

* introduces a new filesystem - nfsd.  No, it's not a typo.  It's a small
  tree with fixed topology defined by nfsd and IO on its files does what
  we used to do by hand in nfsctl.c.
* turns sys_nfsservctl() into a sequence of open()/write()/read()/close()
  It works as it used to - we don't need nfsd to be mounted anywhere, etc.
* nfsd_linkage ugliness is gone.
* getfs and getfh demonstrate (rather trivial) example of "descriptor as
  transaction descriptor" behaviour.
* we are fairly close to the situation when driver-defined filesystems can
  be done with practically zero code overhead.  We are still not there, but
  it's a matter of adding a couple of helpers for populating the tree.

	One thing we get immediately is a cleanup of sys_nfsservctl() -
it got _much_ better.  Moreover, we get an alternative interface that
uses normal file IO and can be used without magic syscalls.

Several exits in exp_export() forget to call path_release().  Fixed.

	Linus, I've taken a bunch of common methods into fs/libfs.c and
killed the (duplicated) instances in filesystems.  There will be more -
ideally I'd like to get a library that would make writing small filesystems
trivial.

into home.transmeta.com:/home/torvalds/v2.5/linux

As mentioned on May 11 on LKML, here is a patch to fix /proc/kcore for
architectures which do not have RAM located at physical address 0.

The following patch removes Alt-Sysrq-L and its associated hack to kill
of PID1, the init process.  This is a mis-feature.

If PID1 is killed, the kernel immediately enters an infinite loop in the
depths of do_exit() with interrupts disabled, completely locking the
machine.  Obviously you can only reach for the reset button or power
switch after this, leaving you with dirty filesystems.

There is a problem where the resource flags sometimes contain bits from
the address part of the PCI BAR, especially when you have the low address
bit set for an IO BAR.

(bit 3 of a PCI IO BAR is an address bit, and (bar & 0xf) propagates this
to res->flags).

This exists in Ivan Kokshaysky PCI patches, and so far hasn't made it into
the kernel.  It's required for IDE on certain ARM machines to even work.