16db0a480SMauro Carvalho Chehab.. SPDX-License-Identifier: GPL-2.0 26db0a480SMauro Carvalho Chehab 36db0a480SMauro Carvalho Chehab======================= 46db0a480SMauro Carvalho ChehabROMFS - ROM File System 56db0a480SMauro Carvalho Chehab======================= 66db0a480SMauro Carvalho Chehab 76db0a480SMauro Carvalho ChehabThis is a quite dumb, read only filesystem, mainly for initial RAM 86db0a480SMauro Carvalho Chehabdisks of installation disks. It has grown up by the need of having 96db0a480SMauro Carvalho Chehabmodules linked at boot time. Using this filesystem, you get a very 106db0a480SMauro Carvalho Chehabsimilar feature, and even the possibility of a small kernel, with a 116db0a480SMauro Carvalho Chehabfile system which doesn't take up useful memory from the router 126db0a480SMauro Carvalho Chehabfunctions in the basement of your office. 136db0a480SMauro Carvalho Chehab 146db0a480SMauro Carvalho ChehabFor comparison, both the older minix and xiafs (the latter is now 156db0a480SMauro Carvalho Chehabdefunct) filesystems, compiled as module need more than 20000 bytes, 166db0a480SMauro Carvalho Chehabwhile romfs is less than a page, about 4000 bytes (assuming i586 176db0a480SMauro Carvalho Chehabcode). Under the same conditions, the msdos filesystem would need 186db0a480SMauro Carvalho Chehababout 30K (and does not support device nodes or symlinks), while the 196db0a480SMauro Carvalho Chehabnfs module with nfsroot is about 57K. Furthermore, as a bit unfair 206db0a480SMauro Carvalho Chehabcomparison, an actual rescue disk used up 3202 blocks with ext2, while 216db0a480SMauro Carvalho Chehabwith romfs, it needed 3079 blocks. 226db0a480SMauro Carvalho Chehab 236db0a480SMauro Carvalho ChehabTo create such a file system, you'll need a user program named 246db0a480SMauro Carvalho Chehabgenromfs. It is available on http://romfs.sourceforge.net/ 256db0a480SMauro Carvalho Chehab 266db0a480SMauro Carvalho ChehabAs the name suggests, romfs could be also used (space-efficiently) on 276db0a480SMauro Carvalho Chehabvarious read-only media, like (E)EPROM disks if someone will have the 286db0a480SMauro Carvalho Chehabmotivation.. :) 296db0a480SMauro Carvalho Chehab 306db0a480SMauro Carvalho ChehabHowever, the main purpose of romfs is to have a very small kernel, 316db0a480SMauro Carvalho Chehabwhich has only this filesystem linked in, and then can load any module 326db0a480SMauro Carvalho Chehablater, with the current module utilities. It can also be used to run 336db0a480SMauro Carvalho Chehabsome program to decide if you need SCSI devices, and even IDE or 346db0a480SMauro Carvalho Chehabfloppy drives can be loaded later if you use the "initrd"--initial 356db0a480SMauro Carvalho ChehabRAM disk--feature of the kernel. This would not be really news 366db0a480SMauro Carvalho Chehabflash, but with romfs, you can even spare off your ext2 or minix or 376db0a480SMauro Carvalho Chehabmaybe even affs filesystem until you really know that you need it. 386db0a480SMauro Carvalho Chehab 396db0a480SMauro Carvalho ChehabFor example, a distribution boot disk can contain only the cd disk 406db0a480SMauro Carvalho Chehabdrivers (and possibly the SCSI drivers), and the ISO 9660 filesystem 416db0a480SMauro Carvalho Chehabmodule. The kernel can be small enough, since it doesn't have other 426db0a480SMauro Carvalho Chehabfilesystems, like the quite large ext2fs module, which can then be 436db0a480SMauro Carvalho Chehabloaded off the CD at a later stage of the installation. Another use 446db0a480SMauro Carvalho Chehabwould be for a recovery disk, when you are reinstalling a workstation 456db0a480SMauro Carvalho Chehabfrom the network, and you will have all the tools/modules available 466db0a480SMauro Carvalho Chehabfrom a nearby server, so you don't want to carry two disks for this 476db0a480SMauro Carvalho Chehabpurpose, just because it won't fit into ext2. 486db0a480SMauro Carvalho Chehab 496db0a480SMauro Carvalho Chehabromfs operates on block devices as you can expect, and the underlying 506db0a480SMauro Carvalho Chehabstructure is very simple. Every accessible structure begins on 16 516db0a480SMauro Carvalho Chehabbyte boundaries for fast access. The minimum space a file will take 526db0a480SMauro Carvalho Chehabis 32 bytes (this is an empty file, with a less than 16 character 536db0a480SMauro Carvalho Chehabname). The maximum overhead for any non-empty file is the header, and 546db0a480SMauro Carvalho Chehabthe 16 byte padding for the name and the contents, also 16+14+15 = 45 556db0a480SMauro Carvalho Chehabbytes. This is quite rare however, since most file names are longer 566db0a480SMauro Carvalho Chehabthan 3 bytes, and shorter than 15 bytes. 576db0a480SMauro Carvalho Chehab 586db0a480SMauro Carvalho ChehabThe layout of the filesystem is the following:: 596db0a480SMauro Carvalho Chehab 606db0a480SMauro Carvalho Chehab offset content 616db0a480SMauro Carvalho Chehab 626db0a480SMauro Carvalho Chehab +---+---+---+---+ 636db0a480SMauro Carvalho Chehab 0 | - | r | o | m | \ 646db0a480SMauro Carvalho Chehab +---+---+---+---+ The ASCII representation of those bytes 656db0a480SMauro Carvalho Chehab 4 | 1 | f | s | - | / (i.e. "-rom1fs-") 666db0a480SMauro Carvalho Chehab +---+---+---+---+ 676db0a480SMauro Carvalho Chehab 8 | full size | The number of accessible bytes in this fs. 686db0a480SMauro Carvalho Chehab +---+---+---+---+ 696db0a480SMauro Carvalho Chehab 12 | checksum | The checksum of the FIRST 512 BYTES. 706db0a480SMauro Carvalho Chehab +---+---+---+---+ 716db0a480SMauro Carvalho Chehab 16 | volume name | The zero terminated name of the volume, 726db0a480SMauro Carvalho Chehab : : padded to 16 byte boundary. 736db0a480SMauro Carvalho Chehab +---+---+---+---+ 746db0a480SMauro Carvalho Chehab xx | file | 756db0a480SMauro Carvalho Chehab : headers : 766db0a480SMauro Carvalho Chehab 776db0a480SMauro Carvalho ChehabEvery multi byte value (32 bit words, I'll use the longwords term from 786db0a480SMauro Carvalho Chehabnow on) must be in big endian order. 796db0a480SMauro Carvalho Chehab 806db0a480SMauro Carvalho ChehabThe first eight bytes identify the filesystem, even for the casual 816db0a480SMauro Carvalho Chehabinspector. After that, in the 3rd longword, it contains the number of 826db0a480SMauro Carvalho Chehabbytes accessible from the start of this filesystem. The 4th longword 836db0a480SMauro Carvalho Chehabis the checksum of the first 512 bytes (or the number of bytes 846db0a480SMauro Carvalho Chehabaccessible, whichever is smaller). The applied algorithm is the same 856db0a480SMauro Carvalho Chehabas in the AFFS filesystem, namely a simple sum of the longwords 866db0a480SMauro Carvalho Chehab(assuming bigendian quantities again). For details, please consult 876db0a480SMauro Carvalho Chehabthe source. This algorithm was chosen because although it's not quite 886db0a480SMauro Carvalho Chehabreliable, it does not require any tables, and it is very simple. 896db0a480SMauro Carvalho Chehab 906db0a480SMauro Carvalho ChehabThe following bytes are now part of the file system; each file header 916db0a480SMauro Carvalho Chehabmust begin on a 16 byte boundary:: 926db0a480SMauro Carvalho Chehab 936db0a480SMauro Carvalho Chehab offset content 946db0a480SMauro Carvalho Chehab 956db0a480SMauro Carvalho Chehab +---+---+---+---+ 966db0a480SMauro Carvalho Chehab 0 | next filehdr|X| The offset of the next file header 976db0a480SMauro Carvalho Chehab +---+---+---+---+ (zero if no more files) 986db0a480SMauro Carvalho Chehab 4 | spec.info | Info for directories/hard links/devices 996db0a480SMauro Carvalho Chehab +---+---+---+---+ 1006db0a480SMauro Carvalho Chehab 8 | size | The size of this file in bytes 1016db0a480SMauro Carvalho Chehab +---+---+---+---+ 1026db0a480SMauro Carvalho Chehab 12 | checksum | Covering the meta data, including the file 1036db0a480SMauro Carvalho Chehab +---+---+---+---+ name, and padding 1046db0a480SMauro Carvalho Chehab 16 | file name | The zero terminated name of the file, 1056db0a480SMauro Carvalho Chehab : : padded to 16 byte boundary 1066db0a480SMauro Carvalho Chehab +---+---+---+---+ 1076db0a480SMauro Carvalho Chehab xx | file data | 1086db0a480SMauro Carvalho Chehab : : 1096db0a480SMauro Carvalho Chehab 1106db0a480SMauro Carvalho ChehabSince the file headers begin always at a 16 byte boundary, the lowest 1116db0a480SMauro Carvalho Chehab4 bits would be always zero in the next filehdr pointer. These four 1126db0a480SMauro Carvalho Chehabbits are used for the mode information. Bits 0..2 specify the type of 1136db0a480SMauro Carvalho Chehabthe file; while bit 4 shows if the file is executable or not. The 1146db0a480SMauro Carvalho Chehabpermissions are assumed to be world readable, if this bit is not set, 1156db0a480SMauro Carvalho Chehaband world executable if it is; except the character and block devices, 1166db0a480SMauro Carvalho Chehabthey are never accessible for other than owner. The owner of every 1176db0a480SMauro Carvalho Chehabfile is user and group 0, this should never be a problem for the 1186db0a480SMauro Carvalho Chehabintended use. The mapping of the 8 possible values to file types is 1196db0a480SMauro Carvalho Chehabthe following: 1206db0a480SMauro Carvalho Chehab 1216db0a480SMauro Carvalho Chehab== =============== ============================================ 1226db0a480SMauro Carvalho Chehab mapping spec.info means 1236db0a480SMauro Carvalho Chehab== =============== ============================================ 1246db0a480SMauro Carvalho Chehab 0 hard link link destination [file header] 1256db0a480SMauro Carvalho Chehab 1 directory first file's header 1266db0a480SMauro Carvalho Chehab 2 regular file unused, must be zero [MBZ] 1276db0a480SMauro Carvalho Chehab 3 symbolic link unused, MBZ (file data is the link content) 1286db0a480SMauro Carvalho Chehab 4 block device 16/16 bits major/minor number 1296db0a480SMauro Carvalho Chehab 5 char device - " - 1306db0a480SMauro Carvalho Chehab 6 socket unused, MBZ 1316db0a480SMauro Carvalho Chehab 7 fifo unused, MBZ 1326db0a480SMauro Carvalho Chehab== =============== ============================================ 1336db0a480SMauro Carvalho Chehab 1346db0a480SMauro Carvalho ChehabNote that hard links are specifically marked in this filesystem, but 1356db0a480SMauro Carvalho Chehabthey will behave as you can expect (i.e. share the inode number). 1366db0a480SMauro Carvalho ChehabNote also that it is your responsibility to not create hard link 1376db0a480SMauro Carvalho Chehabloops, and creating all the . and .. links for directories. This is 1386db0a480SMauro Carvalho Chehabnormally done correctly by the genromfs program. Please refrain from 1396db0a480SMauro Carvalho Chehabusing the executable bits for special purposes on the socket and fifo 1406db0a480SMauro Carvalho Chehabspecial files, they may have other uses in the future. Additionally, 1416db0a480SMauro Carvalho Chehabplease remember that only regular files, and symlinks are supposed to 1426db0a480SMauro Carvalho Chehabhave a nonzero size field; they contain the number of bytes available 1436db0a480SMauro Carvalho Chehabdirectly after the (padded) file name. 1446db0a480SMauro Carvalho Chehab 1456db0a480SMauro Carvalho ChehabAnother thing to note is that romfs works on file headers and data 1466db0a480SMauro Carvalho Chehabaligned to 16 byte boundaries, but most hardware devices and the block 1476db0a480SMauro Carvalho Chehabdevice drivers are unable to cope with smaller than block-sized data. 1486db0a480SMauro Carvalho ChehabTo overcome this limitation, the whole size of the file system must be 1496db0a480SMauro Carvalho Chehabpadded to an 1024 byte boundary. 1506db0a480SMauro Carvalho Chehab 1516db0a480SMauro Carvalho ChehabIf you have any problems or suggestions concerning this file system, 1526db0a480SMauro Carvalho Chehabplease contact me. However, think twice before wanting me to add 1536db0a480SMauro Carvalho Chehabfeatures and code, because the primary and most important advantage of 1546db0a480SMauro Carvalho Chehabthis file system is the small code. On the other hand, don't be 1556db0a480SMauro Carvalho Chehabalarmed, I'm not getting that much romfs related mail. Now I can 1566db0a480SMauro Carvalho Chehabunderstand why Avery wrote poems in the ARCnet docs to get some more 1576db0a480SMauro Carvalho Chehabfeedback. :) 1586db0a480SMauro Carvalho Chehab 1596db0a480SMauro Carvalho Chehabromfs has also a mailing list, and to date, it hasn't received any 1606db0a480SMauro Carvalho Chehabtraffic, so you are welcome to join it to discuss your ideas. :) 1616db0a480SMauro Carvalho Chehab 1626db0a480SMauro Carvalho ChehabIt's run by ezmlm, so you can subscribe to it by sending a message 1636db0a480SMauro Carvalho Chehabto romfs-subscribe@shadow.banki.hu, the content is irrelevant. 1646db0a480SMauro Carvalho Chehab 1656db0a480SMauro Carvalho ChehabPending issues: 1666db0a480SMauro Carvalho Chehab 1676db0a480SMauro Carvalho Chehab- Permissions and owner information are pretty essential features of a 1686db0a480SMauro Carvalho Chehab Un*x like system, but romfs does not provide the full possibilities. 1696db0a480SMauro Carvalho Chehab I have never found this limiting, but others might. 1706db0a480SMauro Carvalho Chehab 1716db0a480SMauro Carvalho Chehab- The file system is read only, so it can be very small, but in case 1726db0a480SMauro Carvalho Chehab one would want to write _anything_ to a file system, he still needs 1736db0a480SMauro Carvalho Chehab a writable file system, thus negating the size advantages. Possible 1746db0a480SMauro Carvalho Chehab solutions: implement write access as a compile-time option, or a new, 1756db0a480SMauro Carvalho Chehab similarly small writable filesystem for RAM disks. 1766db0a480SMauro Carvalho Chehab 1776db0a480SMauro Carvalho Chehab- Since the files are only required to have alignment on a 16 byte 1786db0a480SMauro Carvalho Chehab boundary, it is currently possibly suboptimal to read or execute files 1796db0a480SMauro Carvalho Chehab from the filesystem. It might be resolved by reordering file data to 1806db0a480SMauro Carvalho Chehab have most of it (i.e. except the start and the end) laying at "natural" 1816db0a480SMauro Carvalho Chehab boundaries, thus it would be possible to directly map a big portion of 1826db0a480SMauro Carvalho Chehab the file contents to the mm subsystem. 1836db0a480SMauro Carvalho Chehab 1846db0a480SMauro Carvalho Chehab- Compression might be an useful feature, but memory is quite a 1856db0a480SMauro Carvalho Chehab limiting factor in my eyes. 1866db0a480SMauro Carvalho Chehab 1876db0a480SMauro Carvalho Chehab- Where it is used? 1886db0a480SMauro Carvalho Chehab 1896db0a480SMauro Carvalho Chehab- Does it work on other architectures than intel and motorola? 1906db0a480SMauro Carvalho Chehab 1916db0a480SMauro Carvalho Chehab 1926db0a480SMauro Carvalho ChehabHave fun, 1936db0a480SMauro Carvalho Chehab 1946db0a480SMauro Carvalho ChehabJanos Farkas <chexum@shadow.banki.hu> 195