6 ms·

Well, both Syslinux and Lilo access the file system, from the (scarce and IMHO also inaccurate/confusing) info this thingy here accesses the kernel as a sequenc

by jaclaz 4y ago

Well, both Syslinux and Lilo access the file system, from the (scarce and IMHO also inaccurate/confusing) info this thingy here accesses the kernel as a sequence of RAW sectors starting from sector 1. I.e. it is not a replacement for Syslinuz or Lilo, or any other kernel loader, though it can be used/useful in specific scenarios it is something else, there is little sense in comapring sizes if the features/possibilities are not comparable.

peter_d_sherman 4y ago
"This thing" -- does an "Old School" boot... Old School boots -- are basically: 1) Load and start executing the boot sector (first 512 bytes of boot device) in 16-bit x86 real mode. 2) Read in the next X contiguous sectors (also called 'blocks') from that device into memory. Note that there is no filesystem at this point; the size of what is to be loaded is determined or presumed to be known by the boot block code... 3) Hand off execution to the program (usually the OS, but could be a second stage bootloader) that was read into memory in Step #2. This bootloader additionally performs a protected-mode switch, which means that the OS doesn't need to do that -- which significantly simplifies writing OS initialization code (no need to use an Assembler or C compiler which emits mixed-mode (16/32bit) code). A "file system" -- is an abstraction -- on top of lower-level hardware... Below file systems -- only blocks exist... If someone likes and appreciates the file system abstraction provided to them by whatever file system they like, from whatever vendor they like -- then, hey, I'm not stopping them from using Syslinux or Lilo! But if they are doing an "Old School" boot -- that is, if they want to understand and control their computing hardware at a lower level than what's provided to them by Syslinux or Lilo (and in less lines of code too!) -- then they may want something like what this code has to offer! >"Well, both Syslinux and Lilo access the file system, from the (scarce and IMHO also inaccurate/confusing) info this thingy here accesses the kernel as a sequence of RAW sectors starting from sector 1" The documentation may very well be scarce/inaccurate/confusing if someone doesn't understand x86 Assembler and/or boot sectors and/or the reasons for doing what this boot sector code does -- all of that may be true -- but I have yet in my travels to see what I believe is a simpler x86 boot sector code that switches to protected mode and loads an OS... Still, to each their own -- if other people want to use Syslinux and/or Lilo, I have nothing against them using those tools...
- jaclaz 4y ago
  What is not clear (to those that do not understand x86 assembler and/or boot sectors) is that the floppy won't have a filesystem, as if the sectors from 1 onwards are directly occupied by the kernel file, there won't be space for the FAT12 tables or the ext2 structures (though most probably this could be worked around and have some space available inside a filesystem created after the extents occupied by kernel (+ embedded initrd). AFAIK/AFAICR, in the good ol'times you could directly dd the zimage or bzimage to floppy: https://www.linux.it/~rubini/docs/boot/boot.html https://www.linux.it/~rubini/docs/boot/boot.html The critique was anyway mainly about comparing size of very different programs with very different features, maybe wrongly, I read that statement as "I am tired of the weight of Porsches and Ferraris, here is my soapbox, and it is much lighter".
  - peter_d_sherman 4y ago
    >What is not clear (to those that do not understand x86 assembler and/or boot sectors) is that the floppy won't have a filesystem, as if the sectors from 1 onwards are directly occupied by the kernel file, there won't be space for the FAT12 tables or the ext2 structures. There is no requirement for a given OS -- to use the filesystem of other OS'es... If I am using DOS -- then DOS will not see nor use an ext2 filesystem on the same disk. If I am using Linux -- then typically Linux will NOT see nor use a Novell, BeOS or Amiga filesystem(!) -- at least not without loading a specialized driver... Every filesystem that ever is or was or could ever be -- is implemented as a highly specialized data structure, a pattern of data -- on the storage device. This data structure, this pattern of data -- will have different rules (which will be completely different in two different filesystems) for "what data is supposed to go where" -- in that data structure... Some filesystems -- may use the boot sector to store information about the filesystem in the boot sector. This is the case with DOS/MBR -- but may not be the case with other file systems! (There's nothing preventing a given filesystem from storing information about that filesystem on the last block of a storage device, or the middle block -- or any other block or blocks!) The Starman's Realm, an ancient website (apparently) hosted on Geocities from 1998 - 2009 -- does a much better job of explaining all of this than I can: https://thestarman.pcministry.com/asm/mbr/STDMBR.htm https://thestarman.pcministry.com/asm/mbr/STDMBR.htm "The first 139 bytes (00h through 8Ah) of the 512-byte sector are executable code, and the next 80 bytes (8Bh through DAh) contain error messages. The last 66 bytes of the sector contain the 64-byte Partition Table (1BEh through 1FDh); data in the Table area will depend upon the size, structure and file systems on each hard disk." Again, that's for old-style DOS/MBR partition tables. When an OS is loaded -- it could look at the data on a storage device in any way it wishes, any way that it is programmed to do so. It may honor the pattern of data that implements a file system on that storage device, or it may not. All file systems are software/algorithm/code-created abstractions -- on top of a simpler block-based (send/receive n bytes at time, where n typically equals one of the following: 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536 -- bytes at time) storage device. At the absolute lowest level, that interface looks something like this: ReadBlock(BlockID, PointerToMemoryLocationWhereTheBlockDataShouldBeCopiedTo); WriteBlock(PointerToMemoryLocationWhereTheBlockDataShouldBeCopiedFrom, BlockID); BlockID is just an Integer from 0 (first block, typically boot block) to some high integer -- which is the storage space of the storage device in bytes, divided by the block size. ReadBlock() and WriteBlock() exist as things that the hardware can do -- even before any operating system is loaded -- whether that operating system respects any given filesystem (patterning) on the physical hardware device... All filesystems are subsequently "created" -- by software, data structures, rules, algorithms, and abstraction... on top of this lower level... Also, the first couple of pages of the following are good: https://pages.cs.wisc.edu/~remzi/OSTEP/file-implementation.pdf https://pages.cs.wisc.edu/~remzi/OSTEP/file-implementation.p... Last -- any data, any data -- can exist "inside" of a filesystem (the filesystem knows that it is there as a file, the OS recognizes it, etc.) -- but that data can also exist "outside" of that filesystem -- that is, as a series of blocks on that storage device. If inside of a filesystem -- then the OS typically knows how to open, read, write and close the data -- as a file. If outside of the filesystem -- then some other mechanism needs to know how to read that data. In the case of a kernel, for example, the Linux kernel, the Linux kernel can exist inside of a filesystem -- everyone is familiar with that; it's just a file with a filename... But it can also exist outside of a filesystem, as a series of (usually contiguous!) blocks on a storage device. If a kernel (or any other data) needed at boot time exists in this manner -- then it is typically the responsibility of the boot block (or the boot sequence, since the boot block may load additional code) -- to know about that sequence of blocks -- and to load them into memory in a manner similar to what an OS would do with a file -- but since there's no OS running, there is no file system, and thus, the boot sector code -- needs to know the block range for kernel such that it can do a direct load of those blocks into memory...

by jaclaz 4y ago

peter_d_sherman 4y ago

"This thing" -- does an "Old School" boot... Old School boots -- are basically: 1) Load and start executing the boot sector (first 512 bytes of boot device) in 16-bit x86 real mode. 2) Read in the next X contiguous sectors (also called 'blocks') from that device into memory. Note that there is no filesystem at this point; the size of what is to be loaded is determined or presumed to be known by the boot block code... 3) Hand off execution to the program (usually the OS, but could be a second stage bootloader) that was read into memory in Step #2. This bootloader additionally performs a protected-mode switch, which means that the OS doesn't need to do that -- which significantly simplifies writing OS initialization code (no need to use an Assembler or C compiler which emits mixed-mode (16/32bit) code). A "file system" -- is an abstraction -- on top of lower-level hardware... Below file systems -- only blocks exist... If someone likes and appreciates the file system abstraction provided to them by whatever file system they like, from whatever vendor they like -- then, hey, I'm not stopping them from using Syslinux or Lilo! But if they are doing an "Old School" boot -- that is, if they want to understand and control their computing hardware at a lower level than what's provided to them by Syslinux or Lilo (and in less lines of code too!) -- then they may want something like what this code has to offer! >"Well, both Syslinux and Lilo access the file system, from the (scarce and IMHO also inaccurate/confusing) info this thingy here accesses the kernel as a sequence of RAW sectors starting from sector 1" The documentation may very well be scarce/inaccurate/confusing if someone doesn't understand x86 Assembler and/or boot sectors and/or the reasons for doing what this boot sector code does -- all of that may be true -- but I have yet in my travels to see what I believe is a simpler x86 boot sector code that switches to protected mode and loads an OS... Still, to each their own -- if other people want to use Syslinux and/or Lilo, I have nothing against them using those tools...

jaclaz 4y ago
What is not clear (to those that do not understand x86 assembler and/or boot sectors) is that the floppy won't have a filesystem, as if the sectors from 1 onwards are directly occupied by the kernel file, there won't be space for the FAT12 tables or the ext2 structures (though most probably this could be worked around and have some space available inside a filesystem created after the extents occupied by kernel (+ embedded initrd). AFAIK/AFAICR, in the good ol'times you could directly dd the zimage or bzimage to floppy: https://www.linux.it/~rubini/docs/boot/boot.html https://www.linux.it/~rubini/docs/boot/boot.html The critique was anyway mainly about comparing size of very different programs with very different features, maybe wrongly, I read that statement as "I am tired of the weight of Porsches and Ferraris, here is my soapbox, and it is much lighter".
- peter_d_sherman 4y ago
  >What is not clear (to those that do not understand x86 assembler and/or boot sectors) is that the floppy won't have a filesystem, as if the sectors from 1 onwards are directly occupied by the kernel file, there won't be space for the FAT12 tables or the ext2 structures. There is no requirement for a given OS -- to use the filesystem of other OS'es... If I am using DOS -- then DOS will not see nor use an ext2 filesystem on the same disk. If I am using Linux -- then typically Linux will NOT see nor use a Novell, BeOS or Amiga filesystem(!) -- at least not without loading a specialized driver... Every filesystem that ever is or was or could ever be -- is implemented as a highly specialized data structure, a pattern of data -- on the storage device. This data structure, this pattern of data -- will have different rules (which will be completely different in two different filesystems) for "what data is supposed to go where" -- in that data structure... Some filesystems -- may use the boot sector to store information about the filesystem in the boot sector. This is the case with DOS/MBR -- but may not be the case with other file systems! (There's nothing preventing a given filesystem from storing information about that filesystem on the last block of a storage device, or the middle block -- or any other block or blocks!) The Starman's Realm, an ancient website (apparently) hosted on Geocities from 1998 - 2009 -- does a much better job of explaining all of this than I can: https://thestarman.pcministry.com/asm/mbr/STDMBR.htm https://thestarman.pcministry.com/asm/mbr/STDMBR.htm "The first 139 bytes (00h through 8Ah) of the 512-byte sector are executable code, and the next 80 bytes (8Bh through DAh) contain error messages. The last 66 bytes of the sector contain the 64-byte Partition Table (1BEh through 1FDh); data in the Table area will depend upon the size, structure and file systems on each hard disk." Again, that's for old-style DOS/MBR partition tables. When an OS is loaded -- it could look at the data on a storage device in any way it wishes, any way that it is programmed to do so. It may honor the pattern of data that implements a file system on that storage device, or it may not. All file systems are software/algorithm/code-created abstractions -- on top of a simpler block-based (send/receive n bytes at time, where n typically equals one of the following: 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536 -- bytes at time) storage device. At the absolute lowest level, that interface looks something like this: ReadBlock(BlockID, PointerToMemoryLocationWhereTheBlockDataShouldBeCopiedTo); WriteBlock(PointerToMemoryLocationWhereTheBlockDataShouldBeCopiedFrom, BlockID); BlockID is just an Integer from 0 (first block, typically boot block) to some high integer -- which is the storage space of the storage device in bytes, divided by the block size. ReadBlock() and WriteBlock() exist as things that the hardware can do -- even before any operating system is loaded -- whether that operating system respects any given filesystem (patterning) on the physical hardware device... All filesystems are subsequently "created" -- by software, data structures, rules, algorithms, and abstraction... on top of this lower level... Also, the first couple of pages of the following are good: https://pages.cs.wisc.edu/~remzi/OSTEP/file-implementation.pdf https://pages.cs.wisc.edu/~remzi/OSTEP/file-implementation.p... Last -- any data, any data -- can exist "inside" of a filesystem (the filesystem knows that it is there as a file, the OS recognizes it, etc.) -- but that data can also exist "outside" of that filesystem -- that is, as a series of blocks on that storage device. If inside of a filesystem -- then the OS typically knows how to open, read, write and close the data -- as a file. If outside of the filesystem -- then some other mechanism needs to know how to read that data. In the case of a kernel, for example, the Linux kernel, the Linux kernel can exist inside of a filesystem -- everyone is familiar with that; it's just a file with a filename... But it can also exist outside of a filesystem, as a series of (usually contiguous!) blocks on a storage device. If a kernel (or any other data) needed at boot time exists in this manner -- then it is typically the responsibility of the boot block (or the boot sequence, since the boot block may load additional code) -- to know about that sequence of blocks -- and to load them into memory in a manner similar to what an OS would do with a file -- but since there's no OS running, there is no file system, and thus, the boot sector code -- needs to know the block range for kernel such that it can do a direct load of those blocks into memory...