patch-2.1.47 linux/Documentation/filesystems/romfs.txt

• Lines: 141
• Date: Wed Jul 23 10:38:24 1997
• Orig file: v2.1.46/linux/Documentation/filesystems/romfs.txt
• Orig date: Fri Jan 3 03:03:41 1997

diff -u --recursive --new-file v2.1.46/linux/Documentation/filesystems/romfs.txt linux/Documentation/filesystems/romfs.txt
@@ -8,19 +8,18 @@
 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 @@
 	+---+---+---+---+
   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 @@
 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 @@
  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 @@
 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 @@
 
 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 @@
 
 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>