microkernel + filesystem

[be]

If we want to make a microkernel, we assume that the filesystems services located in some external daemon, like any other non-critical... if I understand "microkernel" term right... But HOW we should boot and load everything, if our microkernel doesn't have any filesystem services? ???

[Pype.Clicker]

my approach was to have a trivial file system service provider in the bootloader itself. Basically, it loads the "boot" directory at once in memory and then the microkernel can start basic stuff (including the *real* filesystem) from that area. Once the real filesystem is up and running, it takes over the trivial one.

The "small File System" just provides the following stuff :
- map a whole file in memory given its name.
- filenames are limitted to 8 bytes
- there's only one directory (named "." ... how original).
- the filesystem is read-only.

there are other microkernel i know that do the same (with the Andrew File System).

The reason i put the filesystem in the bootloader is that it's more a booting issue. It could be obtained from a network or a flash rom without the microkernel notices anything.

[be]

But there is obvious great portability and flexibility loss.
This is why I asked about incremental link... We could release kernel as library with some default startup loader which boots our filesystem daemon ands starts init processes, but user always can make his own startup module, which will, for example, boot kernel from FLASH ROM, link kernel to desired format and boot it some way

[Pype.Clicker]

there will be neither flexibility nor portability loss if both the sfs provider and the microkernel are made independent. All the kernel will require is to receive a "standard" list of function pointers (like map, close and possibly commit) that it can call to access the "bootdisk" image in memory.

Once another service provider is available, it will naturally override the boot service by replacing function pointers.

[be]

By the way, we're talking about the same things But let's say your kernel have to boot from the SCSI adapter.. What to do then?

[Pype.Clicker]

1. i assume that the BIOS is able to access the boot device (if not, we're doomed anyway). If your boot device is a SCSI disk, then the BIOS int13 must be able to access that SCSI disk.

2. the BIOS will activate your bootsector (i assume SCSI boot happens to be similar to IDE or floppy boot: first sector loaded at 0x7C00 and BIOS drive number located in the DL register). If someone has the evidence this is not how things work, please correct me.

3. from the bootsector, you'll read the boot device for your microkernel and initial set of services. Among these services, you *must* have a SCSI driver for your OS, just as you must have had a SCSI driver within your kernel if you were in a monolithic approach.

The only thing that bugs me is that i'm unsure about the sector size on a SCSI drive ... and thus how large is your bootsector ... maybe the BIOS interrupt makes fake sectors of 512 bytes on top of larger SCSI physical sectors.

[Solar]

The only thing that bugs me is that i'm unsure about the sector size on a SCSI drive ... and thus how large is your bootsector ... maybe the BIOS interrupt makes fake sectors of 512 bytes on top of larger SCSI physical sectors.

The Quantum Fireball on my Amiga was 512 bytes / sector by default, as is the 60 GByte Seagate currently in my tower.

AFAIK, larger sector sizes are possible but optional, and I don't know if the IBM PC architecture supports them at all.

If you want me to run some tests on a real-live U2W SCSI PC, drop me the binary. (That's an exclusive Pype offer, I won't run just anybody's binary on my system. )

[Tim]

NEC PC98 machines use 2048 bytes per cluster. However, this standard is odd in other ways, too. I don't think PC98 machines are available outside Japan.