Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!relay.nswc.navy.mil!oasys!mimsy!nocusuhs!nmrdc1!minixug!uwalt!waltje From: waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) Newsgroups: comp.os.minix Subject: Re: ka9q experiences on minix Message-ID: <9105201074@uwalt.nl.mugnet.org> Date: 20 May 91 14:16:39 GMT References: <1991Apr30.023133.15248@dragon.wpd.sgi.com> Organization: MicroWalt Corporation, for MINIX Software Development Lines: 93 des@basie.wpd.sgi.com (Des Young) wrote: > Hi, > way back on version 1.3 Minix I ported Ka9q to minix. I got it to > work with SLIP and Ethernet. The ethernet board I used was a National > Semiconductor demo board, though a WD card would have been easy since > it uses the National chipset. > I did my debugging by running against a DOS-constrained PC which was > running the latest version of the executable, obtainable many places. > I started with version 1.00 of ka9q (yes, there was one) because I > found the later versions all compiled to 200-300k of executable. Since > I run/ran PC Minix, I wanted <= 64K executable. It was a lot of work, > but I kept adding to my version until I had as much in it from later > versions as possible. I ran it interoperably on the main Ethernet at > my previous employer. The debugging display of packets was really > usefull at times. After a long, long time of "careful thinking", I opened a PTY to myself, and told myself to go ahead and port Phil's N/OS to our version of MINIX. It now runs as a separate process server ("INET") in user space using DynaLink. This module also takes care of the complete BSD Socket(2) interface, plus the usual net(3) library (which, I have to admit, I took from BSD 4.3RENO with a lot of help from James Revell of UUNET). I can now compile standard BSD network tools (like ftpd.tar.Z and ftp.tar.Z, gnaa :-) and run them. The only problem is the resolver- it uses bitfields in the third byte of the request header. Barf.... named will have to wait.. :-( To get SLIP running, I first went back to the kernel, and implemented a crude form of Serial Line Line (eh?) Disciplines. This allows me to switch between TTY, MOUSE, SLIP and (soon) AMOEBA operation modes on a single serial line. TTY is, of course, the default mode. Bert Laverman and I are now finishing up the new "mouse" interface for MINIX- it is, at the driver level, identical between ST and PC versions of MINIX. Watch this space for his announcement... Anyway, back to TCP/IP. The two largest problems I found with any TCP/IP implementation are: 1. Memory allocation. Server processes cannot do malloc() and free(), so the process has to do its own allocation stuff. Barf. N/OS used a scheme that allocates buffers of 128 bytes in a ring-fashion; I liked that enough to choose for N/OS as a porting base... Also, remember that drivers for Ethernet and SLIP need lots of buffer space too. Actually, this is what made BSD 2.11 so much larger than 2.10 :-) 2. Driver intercommunication. I wanted to create a driver-server interface that could be used by all network protocol servers in my OS image. So, the Ethernet drivers (yeah, I have two of them: 3C503 and WD8003) should be usable by both INET and Amoeba, and, in the near future, my Novell NetWare server. The same more or less goes for the SLIP driver- it has to be able to do any kind of packet I/O in a point-to-point comms link. Item (1) is now solved adequately. In the kernel, I created a new series of memory allocation routines, with a global kernel space of up to 64Kbytes. This can be used by ALL drives in the kernel who need temporary buffer space for their clients. On 16-bit machines (like mine :-), the actual space is limited to some 17Kbyte. Oh well.... The second item is not yet fully finished. Everytime I think I got it all complete, I think of a new protocol that could be added in the future (like the damned IPX/SPX from Novell :-), and most of these protocols have some demands towards the drivers they use. However, the fine 'Packet Driver Protocol Specification' used by the newer versions of KA9Q-N/OS (thanks, Russ Nelson!) was a _great_ help. For those of you who don't know: this spec is a generalization of a spec created by FTP Software, Inc (beep- no affiliation here!) to reduce the number of changes in their software each time a new Ethernet board came out. The spec now serves as a general packet driver interface for MS-DOS systems. The Ethernet driver(s) are loaded as TSR (Terminate and Stay Resident) programs; they simply hook themselves to one or more software interrupt vectors (a bit like we have our IPC hooked to INT 32). Any application program (usually NET.EXE) can them query those drivers by issuing software interrupts to those vectors. Easy! I sort of mimiced the 'function calls' defined by those drivers. System Servers in MINIX (i.e. INET, AMOEBA and in future, NOVELL) can then issue these calls by sending the specified driver a message. Hurray! The problem is: how to make things like multiple Ether drivers, SLIP lines and, soon, AX.25/KISS drivers, work like one... :-( Any ideas, anyone?? Fred. -- MicroWalt Corporation, for MINIX Development waltje@uwalt.nl.mugnet.org Tel (+31) 252 230 205, Hoefbladhof 27, 2215 DV VOORHOUT, The Netherlands "An Operating System is what the _USERS_ think of it- me"