Re: [9fans] fs kernel: eagle

[Jakub Jermar <jj@comberg.cz>]

> I suppose I could remove them, I remove the dregs of other dead hardware
> when I find them. Hands up, who knows what this typedef in
fs/port/portdat.h
> was for:
> typedef struct Bit Bit;
> If you know, I pity you.

I don't know what purpose was 'typedef struct Bit Bit' for -- I guess
I was only ten or so when Plan 9 used to be proud of
the SGI Power multiprocessor servers...

But now I see that things like the Bit typedef, Eagle and Jaguar drivers
merely ARE
and their one and only task is silent being in the kernel. No doubts they
should
go.

Besides these fossils, there is another thing that I would like to point
out. Both fs and CPUterm kernels suffer mutual duplication of code.
I've done a private survey on this issue in both kernels and found the
following simillarities/duplicities:

all kinds of locks
pieces of scheduler including sleep() and wakeup()
clock and time planning
interrupt dispatching
PCI, CGA, keyboard, floppy
ethernets (etherlnk3, 82557, 2114x), ethernet generic interface
scsi (NCR53c8xx), scsi generic interface
IP protocols...

...and possibly many more.

The result of my survey brought me to thoughts like: "let's have only one
Plan 9 kernel".
For there are only kernel processes in the fs kernel and all of them
cooperate in the algorithm described in the File Server paper written by
Ken Thompson, it should be no problem to transfer the functionality of it
to the CPUterm kernel -- CPUterm kernel supports kernel processes,
and all the hardware that fs kernel needs + more.

With some #ifdefined'ing and a little (more or less) coding, we could
achieve the fully functional fileserver kernel from the CPUterm source.

One would be able to build different images from one source, depending on
whether he wanted to build a file server or a CPUterm server kernel . (I
also
believe that there could be a slight distinction between kernels intended
for
CPU servers and kernels meant for terminals. While enterprise CPU servers
are probably not going to need devices like VGA and sound, they should
be given the opportunity to be free of them, terminals, on the other hand,
might need some of the multimedia drivers.
The scheduler could also be optimised for compute-bound processes on CPU
kernels and for transput-bound processes on term kernels.)

Well, what do you think?

Jakub Jermar