From: drew@anchor.cs.colorado.edu (Drew Eckhardt) Subject: Re: Deadline for 0.13 Date: 6 Feb 1992 06:58:35 GMT
In article <Feb.4.23.07.37.1992.28814@dumas.rutgers.edu> hedrick@dumas.rutgers.edu (Charles Hedrick) writes:
>I agree with keeping the kernel small. I've ported several things,
>and had little trouble with missing kernel facilities. I'd just as
>soon not have things like System V semaphores, shared memory, etc.
Implementing SYSV shared memory on top of what we have would be
incidental. It is definately the trend - even BSD4.4 will implement
the sunos / sysV like shared memory, using sun syntax.
Semaphore and shared memory ARE also neat to play with :)
>Non-blocking tty I/O is essential to several kinds of applications,
>and there will probably be a few other features like that, but I agree
>that it's a mistake to put much more in the kernel.
>
>The challenge is going to be to provide some basis for networking
>without doubling the size of the kernel. Is there any chance you can
>come up with a way to write TCP outside the kernel without losing
>performance badly? There's a version of KA9Q that is designed to run
>as a set of programs outside the kernel. There's a single server that
>acts as a protocol engine. Applications talk to it rather than making
>system calls. It uses System V shared memory and semaphores to talk
>between the processes. If you could come up with a way to keep the
>performance penalty of this down, it might be worth looking at.
I think that networking DEFINATELY belongs in the kernel.
However, we also need GOOD isolation of code (I was complaining earlier
about having to put scsi / hard drive / floppy drive / console code
in the scheduler because of a lack of support for the kind of
timer - interrupt driven timeouts we needed elsewhere, and
a configuration file so that uneccessary stuff is not compiled in -
like on our HP's, we don't have the imp support on.
>I'd like to see priority in 0.13 (and maybe 0.14) put on completing
>libc. In the ports I've done, the main area I've found lacking is in
>that area: floating point support in the library (gcc compiles calls
>to helper routines that don't exist), and various other random things
>like alloca, bcopy/bcmp/bzero, regex, etc. I suspect we've identified
>most of the missing stuff by now, and people have come up with them as
>part of the source to various programs they've ported.
bcopy, etc : these can simply be memcpy, etc renamed. No problem there.
The math : that's missing in the KERNEL. The 387 emulation is only
half way there, and our version of gcc doesn't support soft float.