Ted,
I am looking at these sources as well. One thing I went back and looked
at was related to a comment from Mike G. I believe regarding drivers
conflicts with int 0x13 requests potentially hosing the IDE driver. In
MANOS, since DOS is resident underneath the OS, I instrumented the code
a lot like was done in earlier versions of Windows and NT. I hook the
MSDOS disk interrupts and reprogram the PIC to move the first PIC
interrupt mappings to start at entry 0x28
in the IDT tables instead of overlaying the first 16 exception entries
which is how DOS leaves them by default. When I call into DOS, I
restore the previous PIC1 mappings to their previous DOS settings and
restore the DOS IVT to allow the DOS BIOS drivers to service the disk.
In the MANOS case, DOS has enough smarts to reset the IDE chipset to
it's default values. I am looking over the BIOS int 0x13 code, and it
looks like it may be possible to co-host an int 0x13 ext2 driver and the
Linux IDE driver as is done in NetWare today. I know this is possible
because I do it in MANOS now, and NetWare also supports mutiple IDE
drivers (DOS and NetWare) to share the chipset.
:-)
Jeff
"Theodore Y. Ts'o" wrote:
>
> Date: Mon, 11 Sep 2000 17:51:20 -0600
> From: "Jeff V. Merkey" <jmerkey@timpanogas.com>
>
> I support source level in the kernel. Based on Andi Klein's review, I
> have grabbed ext2utils and am looking at a minimal int 0x13 interface to
> load files into memory. hardest problem here for Linux is having a tiny
> FS that won't deadlock to load source files.
>
> You may also want to take a look at libext2fs which is part of
> e2fsprogs. It has a I/O abstraction which isolates the raw disk I/O
> from the rest of the library. (There's a unix_io.c and an nt_io.c; in
> fact, there's even a dos_io.c which uses the int 0x13 interface,
> although it'll probably require some reworking of the code to translate
> it away from TurboC.)
>
> In libext2fs, look at the fileio.c module; once you open the ext2
> filesystem, you open, read, seek, etc. individual ext2 files in the ext2
> filesystem. I'm not sure the file write code works if it needs to
> extend the file; and it's been the least tested of all of the functions,
> but you wouldn't need this for a kernel debugger anyway.
>
> - Ted
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:18 EST