1*6db0a480SMauro Carvalho Chehab.. SPDX-License-Identifier: GPL-2.0 2*6db0a480SMauro Carvalho Chehab 3*6db0a480SMauro Carvalho Chehab======================= 4*6db0a480SMauro Carvalho ChehabROMFS - ROM File System 5*6db0a480SMauro Carvalho Chehab======================= 6*6db0a480SMauro Carvalho Chehab 7*6db0a480SMauro Carvalho ChehabThis is a quite dumb, read only filesystem, mainly for initial RAM 8*6db0a480SMauro Carvalho Chehabdisks of installation disks. It has grown up by the need of having 9*6db0a480SMauro Carvalho Chehabmodules linked at boot time. Using this filesystem, you get a very 10*6db0a480SMauro Carvalho Chehabsimilar feature, and even the possibility of a small kernel, with a 11*6db0a480SMauro Carvalho Chehabfile system which doesn't take up useful memory from the router 12*6db0a480SMauro Carvalho Chehabfunctions in the basement of your office. 13*6db0a480SMauro Carvalho Chehab 14*6db0a480SMauro Carvalho ChehabFor comparison, both the older minix and xiafs (the latter is now 15*6db0a480SMauro Carvalho Chehabdefunct) filesystems, compiled as module need more than 20000 bytes, 16*6db0a480SMauro Carvalho Chehabwhile romfs is less than a page, about 4000 bytes (assuming i586 17*6db0a480SMauro Carvalho Chehabcode). Under the same conditions, the msdos filesystem would need 18*6db0a480SMauro Carvalho Chehababout 30K (and does not support device nodes or symlinks), while the 19*6db0a480SMauro Carvalho Chehabnfs module with nfsroot is about 57K. Furthermore, as a bit unfair 20*6db0a480SMauro Carvalho Chehabcomparison, an actual rescue disk used up 3202 blocks with ext2, while 21*6db0a480SMauro Carvalho Chehabwith romfs, it needed 3079 blocks. 22*6db0a480SMauro Carvalho Chehab 23*6db0a480SMauro Carvalho ChehabTo create such a file system, you'll need a user program named 24*6db0a480SMauro Carvalho Chehabgenromfs. It is available on http://romfs.sourceforge.net/ 25*6db0a480SMauro Carvalho Chehab 26*6db0a480SMauro Carvalho ChehabAs the name suggests, romfs could be also used (space-efficiently) on 27*6db0a480SMauro Carvalho Chehabvarious read-only media, like (E)EPROM disks if someone will have the 28*6db0a480SMauro Carvalho Chehabmotivation.. :) 29*6db0a480SMauro Carvalho Chehab 30*6db0a480SMauro Carvalho ChehabHowever, the main purpose of romfs is to have a very small kernel, 31*6db0a480SMauro Carvalho Chehabwhich has only this filesystem linked in, and then can load any module 32*6db0a480SMauro Carvalho Chehablater, with the current module utilities. It can also be used to run 33*6db0a480SMauro Carvalho Chehabsome program to decide if you need SCSI devices, and even IDE or 34*6db0a480SMauro Carvalho Chehabfloppy drives can be loaded later if you use the "initrd"--initial 35*6db0a480SMauro Carvalho ChehabRAM disk--feature of the kernel. This would not be really news 36*6db0a480SMauro Carvalho Chehabflash, but with romfs, you can even spare off your ext2 or minix or 37*6db0a480SMauro Carvalho Chehabmaybe even affs filesystem until you really know that you need it. 38*6db0a480SMauro Carvalho Chehab 39*6db0a480SMauro Carvalho ChehabFor example, a distribution boot disk can contain only the cd disk 40*6db0a480SMauro Carvalho Chehabdrivers (and possibly the SCSI drivers), and the ISO 9660 filesystem 41*6db0a480SMauro Carvalho Chehabmodule. The kernel can be small enough, since it doesn't have other 42*6db0a480SMauro Carvalho Chehabfilesystems, like the quite large ext2fs module, which can then be 43*6db0a480SMauro Carvalho Chehabloaded off the CD at a later stage of the installation. Another use 44*6db0a480SMauro Carvalho Chehabwould be for a recovery disk, when you are reinstalling a workstation 45*6db0a480SMauro Carvalho Chehabfrom the network, and you will have all the tools/modules available 46*6db0a480SMauro Carvalho Chehabfrom a nearby server, so you don't want to carry two disks for this 47*6db0a480SMauro Carvalho Chehabpurpose, just because it won't fit into ext2. 48*6db0a480SMauro Carvalho Chehab 49*6db0a480SMauro Carvalho Chehabromfs operates on block devices as you can expect, and the underlying 50*6db0a480SMauro Carvalho Chehabstructure is very simple. Every accessible structure begins on 16 51*6db0a480SMauro Carvalho Chehabbyte boundaries for fast access. The minimum space a file will take 52*6db0a480SMauro Carvalho Chehabis 32 bytes (this is an empty file, with a less than 16 character 53*6db0a480SMauro Carvalho Chehabname). The maximum overhead for any non-empty file is the header, and 54*6db0a480SMauro Carvalho Chehabthe 16 byte padding for the name and the contents, also 16+14+15 = 45 55*6db0a480SMauro Carvalho Chehabbytes. This is quite rare however, since most file names are longer 56*6db0a480SMauro Carvalho Chehabthan 3 bytes, and shorter than 15 bytes. 57*6db0a480SMauro Carvalho Chehab 58*6db0a480SMauro Carvalho ChehabThe layout of the filesystem is the following:: 59*6db0a480SMauro Carvalho Chehab 60*6db0a480SMauro Carvalho Chehab offset content 61*6db0a480SMauro Carvalho Chehab 62*6db0a480SMauro Carvalho Chehab +---+---+---+---+ 63*6db0a480SMauro Carvalho Chehab 0 | - | r | o | m | \ 64*6db0a480SMauro Carvalho Chehab +---+---+---+---+ The ASCII representation of those bytes 65*6db0a480SMauro Carvalho Chehab 4 | 1 | f | s | - | / (i.e. "-rom1fs-") 66*6db0a480SMauro Carvalho Chehab +---+---+---+---+ 67*6db0a480SMauro Carvalho Chehab 8 | full size | The number of accessible bytes in this fs. 68*6db0a480SMauro Carvalho Chehab +---+---+---+---+ 69*6db0a480SMauro Carvalho Chehab 12 | checksum | The checksum of the FIRST 512 BYTES. 70*6db0a480SMauro Carvalho Chehab +---+---+---+---+ 71*6db0a480SMauro Carvalho Chehab 16 | volume name | The zero terminated name of the volume, 72*6db0a480SMauro Carvalho Chehab : : padded to 16 byte boundary. 73*6db0a480SMauro Carvalho Chehab +---+---+---+---+ 74*6db0a480SMauro Carvalho Chehab xx | file | 75*6db0a480SMauro Carvalho Chehab : headers : 76*6db0a480SMauro Carvalho Chehab 77*6db0a480SMauro Carvalho ChehabEvery multi byte value (32 bit words, I'll use the longwords term from 78*6db0a480SMauro Carvalho Chehabnow on) must be in big endian order. 79*6db0a480SMauro Carvalho Chehab 80*6db0a480SMauro Carvalho ChehabThe first eight bytes identify the filesystem, even for the casual 81*6db0a480SMauro Carvalho Chehabinspector. After that, in the 3rd longword, it contains the number of 82*6db0a480SMauro Carvalho Chehabbytes accessible from the start of this filesystem. The 4th longword 83*6db0a480SMauro Carvalho Chehabis the checksum of the first 512 bytes (or the number of bytes 84*6db0a480SMauro Carvalho Chehabaccessible, whichever is smaller). The applied algorithm is the same 85*6db0a480SMauro Carvalho Chehabas in the AFFS filesystem, namely a simple sum of the longwords 86*6db0a480SMauro Carvalho Chehab(assuming bigendian quantities again). For details, please consult 87*6db0a480SMauro Carvalho Chehabthe source. This algorithm was chosen because although it's not quite 88*6db0a480SMauro Carvalho Chehabreliable, it does not require any tables, and it is very simple. 89*6db0a480SMauro Carvalho Chehab 90*6db0a480SMauro Carvalho ChehabThe following bytes are now part of the file system; each file header 91*6db0a480SMauro Carvalho Chehabmust begin on a 16 byte boundary:: 92*6db0a480SMauro Carvalho Chehab 93*6db0a480SMauro Carvalho Chehab offset content 94*6db0a480SMauro Carvalho Chehab 95*6db0a480SMauro Carvalho Chehab +---+---+---+---+ 96*6db0a480SMauro Carvalho Chehab 0 | next filehdr|X| The offset of the next file header 97*6db0a480SMauro Carvalho Chehab +---+---+---+---+ (zero if no more files) 98*6db0a480SMauro Carvalho Chehab 4 | spec.info | Info for directories/hard links/devices 99*6db0a480SMauro Carvalho Chehab +---+---+---+---+ 100*6db0a480SMauro Carvalho Chehab 8 | size | The size of this file in bytes 101*6db0a480SMauro Carvalho Chehab +---+---+---+---+ 102*6db0a480SMauro Carvalho Chehab 12 | checksum | Covering the meta data, including the file 103*6db0a480SMauro Carvalho Chehab +---+---+---+---+ name, and padding 104*6db0a480SMauro Carvalho Chehab 16 | file name | The zero terminated name of the file, 105*6db0a480SMauro Carvalho Chehab : : padded to 16 byte boundary 106*6db0a480SMauro Carvalho Chehab +---+---+---+---+ 107*6db0a480SMauro Carvalho Chehab xx | file data | 108*6db0a480SMauro Carvalho Chehab : : 109*6db0a480SMauro Carvalho Chehab 110*6db0a480SMauro Carvalho ChehabSince the file headers begin always at a 16 byte boundary, the lowest 111*6db0a480SMauro Carvalho Chehab4 bits would be always zero in the next filehdr pointer. These four 112*6db0a480SMauro Carvalho Chehabbits are used for the mode information. Bits 0..2 specify the type of 113*6db0a480SMauro Carvalho Chehabthe file; while bit 4 shows if the file is executable or not. The 114*6db0a480SMauro Carvalho Chehabpermissions are assumed to be world readable, if this bit is not set, 115*6db0a480SMauro Carvalho Chehaband world executable if it is; except the character and block devices, 116*6db0a480SMauro Carvalho Chehabthey are never accessible for other than owner. The owner of every 117*6db0a480SMauro Carvalho Chehabfile is user and group 0, this should never be a problem for the 118*6db0a480SMauro Carvalho Chehabintended use. The mapping of the 8 possible values to file types is 119*6db0a480SMauro Carvalho Chehabthe following: 120*6db0a480SMauro Carvalho Chehab 121*6db0a480SMauro Carvalho Chehab== =============== ============================================ 122*6db0a480SMauro Carvalho Chehab mapping spec.info means 123*6db0a480SMauro Carvalho Chehab== =============== ============================================ 124*6db0a480SMauro Carvalho Chehab 0 hard link link destination [file header] 125*6db0a480SMauro Carvalho Chehab 1 directory first file's header 126*6db0a480SMauro Carvalho Chehab 2 regular file unused, must be zero [MBZ] 127*6db0a480SMauro Carvalho Chehab 3 symbolic link unused, MBZ (file data is the link content) 128*6db0a480SMauro Carvalho Chehab 4 block device 16/16 bits major/minor number 129*6db0a480SMauro Carvalho Chehab 5 char device - " - 130*6db0a480SMauro Carvalho Chehab 6 socket unused, MBZ 131*6db0a480SMauro Carvalho Chehab 7 fifo unused, MBZ 132*6db0a480SMauro Carvalho Chehab== =============== ============================================ 133*6db0a480SMauro Carvalho Chehab 134*6db0a480SMauro Carvalho ChehabNote that hard links are specifically marked in this filesystem, but 135*6db0a480SMauro Carvalho Chehabthey will behave as you can expect (i.e. share the inode number). 136*6db0a480SMauro Carvalho ChehabNote also that it is your responsibility to not create hard link 137*6db0a480SMauro Carvalho Chehabloops, and creating all the . and .. links for directories. This is 138*6db0a480SMauro Carvalho Chehabnormally done correctly by the genromfs program. Please refrain from 139*6db0a480SMauro Carvalho Chehabusing the executable bits for special purposes on the socket and fifo 140*6db0a480SMauro Carvalho Chehabspecial files, they may have other uses in the future. Additionally, 141*6db0a480SMauro Carvalho Chehabplease remember that only regular files, and symlinks are supposed to 142*6db0a480SMauro Carvalho Chehabhave a nonzero size field; they contain the number of bytes available 143*6db0a480SMauro Carvalho Chehabdirectly after the (padded) file name. 144*6db0a480SMauro Carvalho Chehab 145*6db0a480SMauro Carvalho ChehabAnother thing to note is that romfs works on file headers and data 146*6db0a480SMauro Carvalho Chehabaligned to 16 byte boundaries, but most hardware devices and the block 147*6db0a480SMauro Carvalho Chehabdevice drivers are unable to cope with smaller than block-sized data. 148*6db0a480SMauro Carvalho ChehabTo overcome this limitation, the whole size of the file system must be 149*6db0a480SMauro Carvalho Chehabpadded to an 1024 byte boundary. 150*6db0a480SMauro Carvalho Chehab 151*6db0a480SMauro Carvalho ChehabIf you have any problems or suggestions concerning this file system, 152*6db0a480SMauro Carvalho Chehabplease contact me. However, think twice before wanting me to add 153*6db0a480SMauro Carvalho Chehabfeatures and code, because the primary and most important advantage of 154*6db0a480SMauro Carvalho Chehabthis file system is the small code. On the other hand, don't be 155*6db0a480SMauro Carvalho Chehabalarmed, I'm not getting that much romfs related mail. Now I can 156*6db0a480SMauro Carvalho Chehabunderstand why Avery wrote poems in the ARCnet docs to get some more 157*6db0a480SMauro Carvalho Chehabfeedback. :) 158*6db0a480SMauro Carvalho Chehab 159*6db0a480SMauro Carvalho Chehabromfs has also a mailing list, and to date, it hasn't received any 160*6db0a480SMauro Carvalho Chehabtraffic, so you are welcome to join it to discuss your ideas. :) 161*6db0a480SMauro Carvalho Chehab 162*6db0a480SMauro Carvalho ChehabIt's run by ezmlm, so you can subscribe to it by sending a message 163*6db0a480SMauro Carvalho Chehabto romfs-subscribe@shadow.banki.hu, the content is irrelevant. 164*6db0a480SMauro Carvalho Chehab 165*6db0a480SMauro Carvalho ChehabPending issues: 166*6db0a480SMauro Carvalho Chehab 167*6db0a480SMauro Carvalho Chehab- Permissions and owner information are pretty essential features of a 168*6db0a480SMauro Carvalho Chehab Un*x like system, but romfs does not provide the full possibilities. 169*6db0a480SMauro Carvalho Chehab I have never found this limiting, but others might. 170*6db0a480SMauro Carvalho Chehab 171*6db0a480SMauro Carvalho Chehab- The file system is read only, so it can be very small, but in case 172*6db0a480SMauro Carvalho Chehab one would want to write _anything_ to a file system, he still needs 173*6db0a480SMauro Carvalho Chehab a writable file system, thus negating the size advantages. Possible 174*6db0a480SMauro Carvalho Chehab solutions: implement write access as a compile-time option, or a new, 175*6db0a480SMauro Carvalho Chehab similarly small writable filesystem for RAM disks. 176*6db0a480SMauro Carvalho Chehab 177*6db0a480SMauro Carvalho Chehab- Since the files are only required to have alignment on a 16 byte 178*6db0a480SMauro Carvalho Chehab boundary, it is currently possibly suboptimal to read or execute files 179*6db0a480SMauro Carvalho Chehab from the filesystem. It might be resolved by reordering file data to 180*6db0a480SMauro Carvalho Chehab have most of it (i.e. except the start and the end) laying at "natural" 181*6db0a480SMauro Carvalho Chehab boundaries, thus it would be possible to directly map a big portion of 182*6db0a480SMauro Carvalho Chehab the file contents to the mm subsystem. 183*6db0a480SMauro Carvalho Chehab 184*6db0a480SMauro Carvalho Chehab- Compression might be an useful feature, but memory is quite a 185*6db0a480SMauro Carvalho Chehab limiting factor in my eyes. 186*6db0a480SMauro Carvalho Chehab 187*6db0a480SMauro Carvalho Chehab- Where it is used? 188*6db0a480SMauro Carvalho Chehab 189*6db0a480SMauro Carvalho Chehab- Does it work on other architectures than intel and motorola? 190*6db0a480SMauro Carvalho Chehab 191*6db0a480SMauro Carvalho Chehab 192*6db0a480SMauro Carvalho ChehabHave fun, 193*6db0a480SMauro Carvalho Chehab 194*6db0a480SMauro Carvalho ChehabJanos Farkas <chexum@shadow.banki.hu> 195