Re: Various things

[nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) writes:]

>I guess this still uses DOS to boot? I've done a little work on a VSTa
>boot floppy. I think I've figured out how to build the boot image (ie.
>how to lay it out, and how to pass parameters, the basic boot cycle,
>etc.) This is all pretty simple, we just emulate what boot.exe does.

Yes, the "standalone" boot floppy still uses DOS. I will cheerfully
integrate a true standalone boot into the source tree, although I
suspect that a DOS-based boot will continue to be available.

>Having a debugger will be a big help. One idea I liked a lot in plan9
>was the /proc file system. For those who don't know what it is, it's a
>filesystem containing stuff related to the processes. Use /proc, you
>can read process memory, set breakpoints, etc. etc. From what I've
>seen, in plan 9, when a process breaks, it hangs around, rather than
>dumping core. The debugger then attaches itself to /proc to see what's
>up. I think /proc would be useful. Once the debuggin hooks are in,
>it'd be a good project for someone.

Yes, I like parts of Plan9 as well--especially the avoidance of core
files. When you consider exactly how nebulous a filesystem can be in
VSTa, it makes even more sense.

I've been thinking about /proc, and I think I am starting to get a clue
how to do it. Rather than dump all that code into the kernel, I think
the kernel should offer a process-status syscall, and a debugger syscall.
These are binary interfaces, not messaging, with no insulation from the
endianness of the machine or such. The /proc server, then, drives this
binary interface in one direction, and serves connections out to the
rest of the world in the other direction. He provides a machine-independent
interface, handles string massaging, byte swapping, and so forth.

I have the machine-independent part of the debugger written. Last night
I was reviewing the i386 debug registers and the T-bit. It looks like I
should have the kernel part written in another day--then I have to throw
together an assembly-oriented debugger so I can exercise it. I can steal
the symbol table handling stuff from dbsym.c, which should help.

                                                Andy
Received on Mon Nov 29 08:22:24 1993