Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!ogicse!plains!overby From: overby@plains.UUCP (Glen Overby) Newsgroups: comp.os.minix Subject: Re: Minix TCP/IP Summary: How to add More Server Message-ID: <4478@plains.UUCP> Date: 3 May 90 16:18:21 GMT References: Organization: North Dakota State University, Fargo Lines: 63 In article alnitak@tardis.computer-science.edinburgh.ac.uk writes: [ a description of how to impliment TCP/IP under Minix as a server process ] The Berkeley socketts are file descriptors, and can be manipulated the same as any other type of file. To do the same under Minix, there must be a sockett "hook" in the File System. If you're going to do something like this, read Maruice Bach's "Design of the Unix Operating System" book's chapter (near the back) that talks about the SysV File System Switch (this first came about in V8, and there is an abstract of a paper on it in a older (1985-6?) Usenix conference proceedings). A "switch" like this could potentially allow other types of file systems to be mounted, as well as remote filesystems. Jeff Hernes started on this for his MS thesis here at NDSU. It didn't work well though. The other way I see of doing this is to make the IP server look like a device driver to the FS and use ioctls for everything. I don't like putting this in the library, since it will reqire recompiling every single user program that wants to use the networking (the Newcastle Connection did something like this with remote filesystems). I agree that the networking code should be implimented as a server process, but because it does not belong in the Kernel because of size (the kernel is already large enough) and because device drivers are non-preemptable and the networking code does not (or should not) require this. There isn't a good way to add more server processes to Minix. This is because of how ingrained the number of servers is in the system. You will find a constant, LOW_USER (include/minix/const.h), for defining the "first user not part of operating system". First glance will say "just increase this number", and that is a good first step. Next you will have to find all the places that know about *THREE* server processes (FS, MM, Init): * the _sizes area at the start of Kernel data (start.x), which is patched by build (or ShoeLace). This contains the sizes (or is it start addresses?) of each piece of the pre-loaded OS. * the File System and Memory Manager, which have a similar area at the beginning of their data areas. I'm not sure if all of them use it. A nicer way to do this (which I started working on in my "new bootstrap" program of about a year ago, and ShoeLace does about the same thing) is to allow each piece of the OS to be loaded from a separate a.out file. I passed a 'struct proc' into the kernel (ShoeLace just did a build-like binary patch), which would allow me to theoretically pre-load as many processes as I wanted. While making radical changes like this, why not go the rest of the way and split all the device drivers into separate executables? To break the devices into separate programs, several changes to the kernel need to be made: hook into "umap" that can be called only by device drivers to translate a virtual address into a real address, fix things up so alarms can be delivered to devices (in 1.3 there was an alarm-like way to have a function called after so much time) and interrupt handling will have to be distributed into each driver program. There are probably a few other things I haven't thought of, too... I don't think the IP, ICMP, TCP and UCP protocols alone (along with buffers) will blow the 64K limit. If you start putting SMTP and Telnet servers in with it, you certainly will. -- Glen Overby uunet!plains!overby (UUCP) overby@plains (Bitnet)