Mail Archives: opendos/1997/02/05/10:27:52
Apparently-To: opendos-list-out
>From owner-opendos AT mail DOT tacoma DOT net Tue Feb 4 20:21:22 1997
Date: Wed, 5 Feb 1997 02:10:22 +0100 (MET)
From: "Manuel J. Petit de Gabriel" <mpetit AT dit DOT upm DOT es>
To: OpenDOS List <opendos AT mail DOT tacoma DOT net>
Sender: owner-opendos AT mail DOT tacoma DOT net
> MS-DOS (or OpenDos) is able to read/write FAT because the FAT filesystem
> is built into the kernel... from the "superblock" it only gets the
> filesystem parameters
>
> Linux is able to read/write EXT2 because the EXT2 filesystem
> is built into the kernel... from the "superblock" it only gets the
> filesystem parameters.
>
> LILO is able to read EXT2 (and load Linux kernel from it) because
> the EXT2 filesystem is built into LILO... from the "superblock" it
> only gets the filesystem parameters.
>
> etc, etc, etc
>
> To do what you want EXT2, HPFS... should be built into the system
> (at least a "tiny" version to read them)
>
> So your DOS "kernel" either:
> i) will be big
> ii) you have a way to taylor it
> iii) you have different kernels with different level of support
>
> options (ii) and (iii) could be a real mess.
> For Linux it's similar but replace /boot by LILO
>
> Now tell me, how do you want OpenDos to be able to have read support
> for both HPF and EXT2 without having a huge IBMBIO and IBMDOS?
>
> One idea could be to have another stage in the boot process. Instead
> of reading directly IBMBIO, the boot sector (or maybe LILO) could search
> for a sector list. Perhaps sector 2 of track 0 (track 0 is typically unused
> except for the first sector which contains MBR and partition table)
> could hold sector list for partition 1, sector 3 for partition2 ...
> If such sector list is found the boot sector will load the refered
> sectors and start executing.
>
> The sectors in this list will be the sectors used by a file in the
> filesystem of that partition. That file (lets call it IFSBOOT) will
> contain a tiny implementation of the filesystem to load IBMBIO. IBMBIO
> will use the services of IFSBOOT to load IBMDOS. IBMDOS will use it
> also to load CONFIG.SYS and/or a suitable IFS for that filesystem.
> IFSBOOT is discarded from memory. The rest of IFS are read
> from disk.
>
> This model requires:
> i) modify IBMBIO & IBMDOS to use the IFSBOOT module, should be
> not hard... don't know
> ii) modify LILO to use the sector if found. Seems easy.
> iii) and IFSBOOT for each filesystem. If you are going to make
> a full implementation of the filesystem as IFS this should be
> a minor problem
> iv) a tool for each filesystem which will write the sector list
> of the corresponding IFSBOOT in the apropiate place
>
> This way you could have an OpenDos which will be ablee to
> run in HPFS only mode, EXT2 mode...
>
>
> Posible problems:
> i) the place suggested for the sector list is typically used
> by virus... you'd better have an emergency bootdisk with
> all required IFS in it
> ii) if anyone replaces the IFSBOOT file and doesn't run the
> apropiate tool to build up the new sector list... you'd better
> have an emergency bootdisk with all required IFS in it
> [ have anyone tried the following in a SunOS system:
>
> cp /boot /boot-
> mv /boot- /boot
>
> the same effect. Pretty annoying. After doing the above
> you MUST run a program named installboot to build
> up the sector list or the machine will not boot again
> ]
> iii) Same as above if the filesystem has a defrag tool
> iv) Others... yet to be discovered
>
>
> Comments???
>
> manuel,
>
> PD: my own opinion is that for hackers like most of us the model
> is good. For the general public... may be a bit overcomplex,
> why the hell should my father (a lawyer) or my sister (also a
> lawyer) want to have an EXT2 partition (maybe he/she could want
> HPFS if he installs OS/2 all.
Yeah. Why not just build a lilo equivilent? Seems *TOO* obvious to
me that that's what we really want. Build the OpenDOS kernel such that
it understand command line options, etc. like the Linux kernel, and have
the lilo (odlo?) load the kernel from there. The only thing we really
need that we don't have is a boot sector in the partition (you can't install
lilo on a FAT filesystem) -- obviously an EXT2 would work.
For those who don't know lilo -- here's the process:
1 - Build a kernel. There's still debate over whether we'd want to do this or
not, but it's still an option.
2 - Have a odlo.conf file to configure odlo, and have an entry pointing at
the kernel.
3 - Run odlo. Whatever type of FS you're currently running on, the OS
(OpenDOS) (or I suppose Linux could work!) *knows* how to read it.
odlo just records *physically* where the kernel is and stores the map.
odlo then stores itself and a pointer to the map in the boot sector.
4 - Reboot. odlo loads from the boot sector, reads its map, then loads the
OpenDOS kernel which takes over from there.
The beauty of this is that the boot loader can be dumb as rocks (and small),
but we still get the flexibility of booting on any type of FS.
So, you ask, what happens if the kernel doesn't know how to read ext2 and
this is an ext2 file system? How's it gonna read its config.sys, etc?
I'm glad you asked. Well -- 2 possible solutions:
1 - The Linux solution. Build a kernel that does.
2 - Enhance odlo and the kernel to have odlo load that driver at boot time
as an installable module. odlo would load the kernel, then whatever
modules are required to boot, and then kick off the kernel (and probably
tell the kernel what it did). odlo would obviously have to be a bit
less dumb, but I don't think that this should be *that* complicated.
Hell -- Now that I think about it, this sounds like a *great* thing
to do to the Linux kernel and lilo. Time to put on my thinking hat and go
back to my one *true* love (Linux).
Any thoughts? There's probably something very obvious that I'm missing, but...
Just my $.02 worth.
-Nick
--
+--------------------------------------+-------------------------------------+
| /`-_ Nicholas R LeRoy | Linux -- What *nix was meant to be. |
|{ }/ nick DOT leroy AT norland DOT com | gcc -- What C was meant to be. |
| \ * / Norland Corp +-------------------------------------+
| |___| W6340 Hackbarth Rd | Escape the Gates of Hell with |
| Fort Atkinson, WI 53538 | The choice of a GNU generation... |
+--------------------------------------+-------------------------------------+
| Hey -- These are my own ideas, not my employer's. Don't blame them... |
+--------------------------------------+-------------------------------------+
- Raw text -