Message-Id:	<199702091512.QAA11315@math.amu.edu.pl>
Comments:	Authenticated sender is <grendel AT ananke DOT amu DOT edu DOT pl>
From:	"Mark Habersack" <grendel AT ananke DOT amu DOT edu DOT pl>
Organization:	What? (Poznan, Poland)
To:	mharris AT blackwidow DOT saultc DOT on DOT ca
Date:	Sun, 9 Feb 1997 16:12:36 +0100
MIME-Version:	1.0
Subject:	Re: [opendos] OpenDOS + Win95 w/FAT32?
Reply-to:	grendel AT ananke DOT amu DOT edu DOT pl
CC:	OpenDOS Mailing List <opendos AT mail DOT tacoma DOT net>
References:	<19970204074928 DOT VX02648 AT hagbard DOT demon DOT co DOT uk>
In-reply-to:	<Pine.LNX.3.95.970206141318.4560O-100000@capslock.com>
Sender:	owner-opendos AT mail DOT tacoma DOT net

> > Hmm, there is an interesting question. If filesystem support is loaded
> > from CONFIG.SYS, and you want to have a 100% VFAT or even ext2fs
> > filesystem, how will DOS be able to read the filesystem to find CONFIG.SYS
> > so that it can load the file system driver that is required to read things
> > from the filesystem that CONFIG.SYS is held on....
> 
> The root filesystem type will HAVE to be compiled into the kernel
> directly, otherwise how can ANY files be read off of it? Other
> filesystems may either be "built in", or can be added via boot
> time commands or loaded on the fly with some kind of module
> loader. (Preferably one that resides in XMS :o)
Not quite so, IMHO. Think about how are IBMDOS.COM and IBMBIO.COM loaded at 
boot time? Neither MBR nor BR code knows anything about the file system. The 
physical location of these files on the disk is know at the format time and 
hard-coded into the BR code. To allow mounting *any* FS as the root *without 
the need to compile any driver into the kernel* one should only know location 
of the superblock on the disk. During the partition formatting, user selects 
which file systems may be used as root and the formatter allocates enough 
space in the superblock to store all the drivers, mount table (config file) 
and map of the driver modules stored in the superblock. Now, the code stored 
in BR reads the mount table and the map, finds which driver is to be loaded 
and then reads in and executes the system image (which might be stored in the 
superblock as well), Should the code be too big to fit in the BR, a system 
loader may be stored in the superblock.
In this setup user may shuffle the root FS changing between all the drivers 
stored in superblock. BTW. I think that superblock is a good idea to protect 
the kernel from a too inquisitive, yet unexperienced, user.

********************************************************
For when it comes down to it there's no use trying to
  pretend. For when it comes down to there's no one really
left to blame - blame it on me, you can blame it on me
We're just sugar mice on the rain.
----
Visit http://ananke.amu.edu.pl/~grendel

- Raw text -