Merge with 2.1.47. Some more cleanup and module fixes.

2 files changed, 64 insertions, 28 deletions

diff --git a/Documentation/filesystems/romfs.txt b/Documentation/filesystems/romfs.txt
index 5b8bafb46..32a14e68b 100644
--- a/Documentation/filesystems/romfs.txt
+++ b/Documentation/filesystems/romfs.txt
@@ -8,19 +8,18 @@ similar feature, and even the possibility of a small kernel, with a
 file system which doesn't take up useful memory from the router
 functions in the basement of your office.
 
-For comparison, both the older minix and xiafs filesystems (compiled
-as module) need more than 20000 bytes, while romfs is less than a
-page, about 4000 bytes (assuming ix86 code).  Under the same
-conditions, the msdos filesystem would need about 30K (and does not
-support device nodes or symlinks), while the nfs module with nfsroot
-is about 57K.  Furthermore, as a bit unfair comparison, an actual
-rescue disk used up 3202 blocks with ext2, while with romfs, it needed
-3079 blocks.
+For comparison, both the older minix and xiafs (the latter is now
+defunct) filesystems, compiled as module need more than 20000 bytes,
+while romfs is less than a page, about 4000 bytes (assuming i586
+code).  Under the same conditions, the msdos filesystem would need
+about 30K (and does not support device nodes or symlinks), while the
+nfs module with nfsroot is about 57K.  Furthermore, as a bit unfair
+comparison, an actual rescue disk used up 3202 blocks with ext2, while
+with romfs, it needed 3079 blocks.
 
 To create such a file system, you'll need a user program named
-genromfs.  It is (or will be shortly) available via ftp on
-sunsite.unc.edu and its mirrors, in the /pub/Linux/system/Filesystems/
-directory.
+genromfs.  It is available via anonymous ftp on sunsite.unc.edu and
+its mirrors, in the /pub/Linux/system/recovery/ directory.
 
 As the name suggests, romfs could be also used (space-efficiently) on
 various read-only medias, like (E)EPROM disks if someone will have the
@@ -61,7 +60,7 @@ offset	    content
 	+---+---+---+---+
   0	| - | r | o | m |  \
 	+---+---+---+---+	The ASCII representation of those bytes
-  4	| 1 | f | s | - |  /	(i.e. "-rom1fs-"
+  4	| 1 | f | s | - |  /	(i.e. "-rom1fs-")
 	+---+---+---+---+
   8	|   full size	|	The number of accessible bytes in this fs.
 	+---+---+---+---+
@@ -77,7 +76,7 @@ Every multi byte value (32 bit words, I'll use the longwords term from
 now on) must be in big endian order.
 
 The first eight bytes identify the filesystem, even for the casual
-reader.  After that in the 3rd longword, it contains the number of
+inspector.  After that, in the 3rd longword, it contains the number of
 bytes accessible from the start of this filesystem.  The 4th longword
 is the checksum of the first 512 bytes (or the number of bytes
 accessible, whichever is smallest).  The applied algorithm is the same
@@ -101,7 +100,7 @@ offset	    content
  12	|   checksum	|	Covering the meta data, including the file
 	+---+---+---+---+	  name, and padding
  16	| file name     |	The zero terminated name of the file,
-	:               :	padded to 16 byte boundary.
+	:               :	padded to 16 byte boundary
 	+---+---+---+---+
  xx	| file data	|
 	:		:
@@ -112,9 +111,10 @@ bits are used for the mode information.  Bits 0..2 specify the type of
 the file; while bit 4 shows if the file is executable or not.  The
 permissions are assumed to be world readable, if this bit is not set,
 and world executable if it is; except the character and block devices,
-they are readable only for the owner.  The owner of every file is user
-and group 0, this should never be a problem for the intended use.  The
-mapping of the 8 possible values to file types is the following:
+they are never accessible for other than owner.  The owner of every
+file is user and group 0, this should never be a problem for the
+intended use.  The mapping of the 8 possible values to file types is
+the following:
 
 	  mapping		spec.info means
  0	hard link	link destination [file header]
@@ -128,14 +128,14 @@ mapping of the 8 possible values to file types is the following:
 
 Note that hard links are specifically marked in this filesystem, but
 they will behave as you can expect (i.e. share the inode number).
-Note also that your responsibility to not create hard link loops, and
-creating all the . and .. links for directories.  This is normally
-done correctly by the genromfs program.  Please refrain from using the
-executable bits on the socket and fifo special files, they may have
-other uses in the future.  Additionally, please remember that only
-regular files, and symlinks are supposed to have a nonzero size field;
-they contain the number of bytes available directly after the (padded)
-file name.
+Note also that it is your responsibility to not create hard link
+loops, and creating all the . and .. links for directories.  This is
+normally done correctly by the genromfs program.  Please refrain from
+using the executable bits for special purposes on the socket and fifo
+special files, they may have other uses in the future.  Additionally,
+please remember that only regular files, and symlinks are supposed to
+have a nonzero size field; they contain the number of bytes available
+directly after the (padded) file name.
 
 Another thing to note is that romfs works on file headers and data
 aligned to 16 byte boundaries, but most hardware devices and the block
@@ -145,8 +145,44 @@ padded to an 1024 byte boundary.
 
 If you have any problems or suggestions concerning this file system,
 please contact me.  However, think twice before wanting me to add
-features and code, because the primary advantage of this file system
-is the small code.
+features and code, because the primary and most important advantage of
+this file system is the small code.  On the other hand, don't be
+alarmed, I'm not getting that much romfs related mail.  Now I can
+understand why Avery wrote poems in the arcnet docs to get some more
+feedback. :)
+
+romfs has also a mailing list, and to date, it hasn't received any
+traffic, so you are welcome to join it to discuss your ideas. :)
+
+It's run by ezmlm, so you can subscribe to it by sending a message
+to romfs-subscribe@shadow.banki.hu, the content is irrelevant.
+
+Pending issues:
+
+- Permissions and owner information are pretty essential features of a
+Un*x like system, but romfs does not provide the full possibilities.
+I have never found this limiting, but others might.
+
+- The file system is read only, so it can be very small, but in case
+one would want to write _anything_ to a file system, he still needs
+a writable file system, thus negating the size advantages.  Possible
+solutions: implement write access as a compile-time option, or a new,
+similarly small writable filesystem for ram disks.
+
+- Since the files are only required to have alignment on a 16 byte
+boundary, it is currently possibly suboptimal to read or execute files
+from the filesystem.  It might be resolved by reordering file data to
+have most of it (i.e. except the start and the end) laying at "natural"
+boundaries, thus it would be possible to directly map a big portion of
+the file contents to the mm subsystem.
+
+- Compression might be an useful feature, but memory is quite a
+limiting factor in my eyes.
+
+- Where it is used?
+
+- Does it work on other architectures than intel and motorola?
+
 
 Have fun,
 Janos Farkas <chexum@shadow.banki.hu>
diff --git a/Documentation/filesystems/smbfs.txt b/Documentation/filesystems/smbfs.txt
index ffef2d814..b707757e2 100644
--- a/Documentation/filesystems/smbfs.txt
+++ b/Documentation/filesystems/smbfs.txt
@@ -9,5 +9,5 @@ netbios name or share.
 
 To use smbfs, you need a special mount program, which can be found in
 the ksmbfs package, found on
-sunsite.unc.edu:/pub/Linux/system/Filesystems/smbfs.
 
+	sunsite.unc.edu:/pub/Linux/system/filesystems/smbfs