Restore backward compatibility of UFS2 with previous NetBSD releases by
disabling support in UFS2 for extended attributes (including ACLs).
Add a new variant of UFS2 called "UFS2ea" that does support extended attributes.
Add new fsck_ffs operations "-c ea" and "-c no-ea" to convert file systems
from UFS2 to UFS2ea and vice-versa (both of which delete all existing extended
attributes in the process).

add bi-endian support to the libsa ufs reader and enable it in efiboot.

ffs frontends to "ufs.c" now also define ufs_dinode_swap, ufs_indp_swap,
and FS_MAGIC (moved from ufs.c #if segments.) these are used to call
the right (32/64 bit) ffsv1/v2 version.

ufs.c 'struct file' gains f_swapped member. accessors for d_magic,
d_reclen, and d_ino are introduced (they need to be swapped.) sfter
reading an inode from disk, read_inode() may call ufs_dinode_swap().
indirect block number and caches may be swapped.

error handling in ffs_find_superblock() is cleaned up. (size is slightly
reduced on some ports with this part.)

defaults for new defines added to ufs.c. (XXX: we build ufs.c but i think
all the consumers don't use it, and we can stop building it.)

LFS support is not included.

add a cut-down copy of ffs_bswap.c from the kernel.

also enable bi-endian disklabel support in efiboot.

most ports build and sizes compared for platforms that don't enable this
code and all but one saw reduced code size. booted several platforms with
new boot code.

branches: 1.14.34; 1.14.36;
Hack up dinode usage to be 64 vs. 32 as needed. Part 1.

(This part changes the native lfs code; the ufs-derived code already
has 64 vs. 32 logic, but as aspects of it are unsafe, and don't
entirely interoperate cleanly with the lfs 64/32 stuff, pass 2 will be
rehashing that.)

Add IFILE32 and IFILE64 structures for the on-disk ifile entries.
Add and use accessors. There are also a bunch of places that cast and
I hope I've found them all...

Add a (draft) 64-bit superblock. Make things build again.

Add pieces of support for using both superblock types where
convenient, and specifically to the superblock accessors, but don't
actually enable it anywhere.

First substantive step on PR 50000.

Switch to accessor functions for elements of the LFS on-disk
superblock. This will allow switching between 32/64 bit forms on the
fly; it will also allow handling LFS_EI reasonably tidily. (That
currently doesn't work on the superblock.)

It also gets rid of cpp abuse in the form of fake structure member
macros.

Also, instead of doing sleep/wakeup on &lfs_avail and &lfs_nextseg
inside the on-disk superblock, add extra elements to the in-memory
struct lfs for this. (XXX: these should be changed to condvars, but
not right now)

XXX: this migrates a structure needed by the lfs code in libsa (struct
salfs) into lfs.h, where it doesn't belong, but for the time being
this is necessary in order to allow the accessors (and the various
lfs macros and other goop that relies on them) to compile.

Rearrange the structures in the lfs bootbollocks slightly.
This generates the same output (at least on amd64) but will be more
robust until we're ready to deploy lfs64 bootblocks too.

XXX: I don't think these actually work right now, and the logic for
picking between v1 and v2 lfs formats (which is not related to ffsv1
vs. ffsv2) is definitely broken. But I haven't made it any worse.

branches: 1.9.10;
Stick ffs_, ext2_, chfs_, filecore_, cd9660_, or mfs_ in front of
the following symbols so as to disambiguate fully. (Christos already
did the lfs ones.)

lblkno
lblktosize
lfragtosize
numfrags
blkroundup
fragroundup

Rename ambiguous macros:
MAXDIRSIZE -> UFS_MAXDIRSIZE or LFS_MAXDIRSIZE
NINDIR -> FFS_NINDIR, EXT2_NINDIR, LFS_NINDIR, or MFS_NINDIR
INOPB -> FFS_INOPB, LFS_INOPB
INOPF -> FFS_INOPF, LFS_INOPF
blksize -> ffs_blksize, ext2_blksize, or lfs_blksize
sblksize -> ffs_blksize

These are not the only ambiguously defined filesystem macros, of
course, there's a pile more. I may not have found all the ambiguous
definitions of blksize(), too, as there are a lot of other things
called 'blksize' in the system.

Prefix most of the cpp macros with lfs_ and LFS_ to avoid conflicts with ffs.
This was done so that boot blocks that want to compile both FFS and LFS in
the same file work.

Build properly against the lfs changes.

branches: 1.5.2;
Remove the code that tries to load the "ffs" kernel module during boot.
This is in line with the core decision than even modular kernels should
contain the ffs code.
I've left in the code that tries to load "nfs" and "ext2fs", but it
isn't clear that is necessary.
Removes a warning message that (usually) flashes past to fast to read.
AFAICT all the relevant kernels contain ffs (and nfs for that matter).

branches: 1.4.2;
Apply the following patch submitted by Evgeniy Ivanov:
http://mail-index.NetBSD.org/tech-kern/2011/12/15/msg012226.html
http://mail-index.NetBSD.org/tech-kern/2011/12/17/msg012229.html

- add 'ls' op to struct fs_ops to support ls command on each fs,
enabled by -DLIBSA_ENABLE_LS_OP and SAMISCMAKEFLAGS+="SA_ENABLE_LS_OP=yes"
in libsa
- split sys/lib/libsa/ufs_ls.c into UFS specific part and MI part (ls.c)
that opens the target fs and calls fs-depedent XXX_ls() functions
- add a ls op for ext2fs
(all other fs than ufs and ext2fs don't have actual ls ops yet)
- replace existing MD ufs_ls() calls with this new MI ls()

The original patch was written for i386 and ext2fs.
zaurus zboot has been tested by nonaka@.
ews4800mips and x68k loaders have been tested by me (with several fixes).
landisk might be okay since it was almost copied from i386.

XXX1: "ls" op in fs_ops looks a bit inconsistent, but we will be able to
replace it with real fs ops like readdir if it's really worth
XXX2: someone might have to check sys/arch/ia64/stand/efi/libefi/efifs_ls.c

branches: 1.3.16; 1.3.20;
For the x86 boot loader, autoload a kernel module corresponding to the
root file system type.

branches: 1.2.100; 1.2.104; 1.2.110; 1.2.114;
Use common ffs/lfs file ufs.c instead of lfs specific version.

Add support for LFSv2 filesystems. From a libsa standpoint, LFSv1 and
LFSv2 are treated as separate filesystem types for size considerations.