It turns out we do want the puffs compat code in any kernel which
has built-in compat_50 regardless of whether the kernel also has
puffs.

Should finally fix PR kern/53943

try '&' instead of '&&'

Don't include puffs_compat in a kernel unless the filesystem is
selected along with COMPAT_50. Also, don't include puffs_compat
in the main puffs filesystem module; it is part of the compat_50
module.

Should address PR kern/53943

Merge the [pgoyette-compat] branch

branches: 1.6.18; 1.6.20;
Define filesystem attributes with vfs dependency.

branches: 1.5.18;
remember to add the new file to the build

branches: 1.4.18; 1.4.38; 1.4.40;
Part 2/n of extensive changes to request transport to/from userspace:

Rip the transport code completely out of puffs and generalize it
into an independent module which will be used for multiple purposes
in the future. This module is called the Pass-to-Userspace
Transporter (known as "putter" among friends).

This is very much work-in-progress and one dependency with puffs
remains: the request framing format.

The device name is still /dev/puffs, but that will change soon.

Users of puffs need the following in their kernel configs now:
pseudo-device putter

branches: 1.3.2; 1.3.4;
Split routines handling nodes from puffs_subr to puffs_node.
No functional change.

branches: 1.2.2; 1.2.4; 1.2.10; 1.2.22; 1.2.24; 1.2.26;
shuffle functions around a bit: move the transport (/dev/puffs) to
a different file from the messaging (request contents). no functional
change

branches: 1.1.2;
kernel portion of puffs - the Pass-to-Userspace Framework File System.
It contains the VFS attachment and userspace message-passing interface.

This work was initially started and completed for Google SoC 2005
and tweaked to work a bit better in the past few weeks. While
being far from complete, it is functional enough to be able and
stable to host a fairly general-purpose in-memory file system in
userspace. Even so, puffs should be considered experimental and
no binary compatibility for interfaces or crash-freedom or zero
security implications should be relied upon just yet.

The GSoC project was mentored by William Studenmund and the final
review for the code was done by Christos.