Message-Id: <199702091512.QAA11315@math.amu.edu.pl> Comments: Authenticated sender is From: "Mark Habersack" 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 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: [opendos] OpenDOS + Win95 w/FAT32? Reply-to: grendel AT ananke DOT amu DOT edu DOT pl CC: OpenDOS Mailing List References: <19970204074928 DOT VX02648 AT hagbard DOT demon DOT co DOT uk> In-reply-to: Sender: owner-opendos AT mail DOT tacoma DOT net Precedence: bulk > > 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