On Thu, 3 Jun 1999, Alan Cox wrote:
> > In addition, the minix filesystem *must* support files > 512k, something it
>doesn't do
> > now. The libc.a file is > 512k so you can't even link anything on ELKS. This
> > requires supporting > 7 indirect blocks.
>
> Umm it used to. What happened ?
>
> > : Networking.
> >
> > I think we need ELKS DLL's for this, so that we can run the kernel and
> > any user programs with separate code and data segments to keep the link
>
> Keep networking mostly in user space. That btw is also the model things like
> the early networking work on V7 unix took.
The networking text file in the Documentation dir says:
Cut here 8<------------------------------------------------------------
Notes on networking code
------------------------
Current development model is based around using a user process to be the
actual TCP/IP stack with socket file descriptors and device drivers dealt with
by the kernel. The diagram below show how things should work.
___________________ ____________________
| | | |
|Network Application| |TCP/IP stack process|
|___________________| |____________________|
| / |
| / |
_________________|_____________/_____________|________________
| | / | |
| KERNEL | / | |
| _____|__________/_ __________|________ |
| | | | | |
| | Socket code | | RAW Driver | |
| |__________________| |___________________| |
| | |
| | |
|_____________________________________________|________________|
|
__________|________
| |
| Network Hardware |
|___________________|
The Network Application uses the standard BSD socket interface to open and
read and write to sockets. The socket code passes the data on to the TCP/IP
stack process, through a file descriptor. (char device or socket).
The TCP/IP stack process then constructs TCP/IP packets and writes them to
the network device driver including all the necessary hardware headers.
Cut here 8<------------------------------------------------------------
This seems sane. If we have a /dev/ip to communicate with the tcp/ip stack
process from the inet_ functions, then virtually everything sits outside
the kernel. I don't know much about the userspace device drivers yet, but
these could potentially be used for network drivers, and if not a network
driver wouldn't take up too much memory.
So the user space tcp/ip stack would just take the data, slap in in a
cutesy little packet, and shove it out to the network driver (and the
same but backwards).
Something that shouldn't be as hard to do from userspace.
I'll link my inet_ functions up to a device driver for now.
Any comments?
Lukeboo Farrar.
