gilgalad@caen.engin.umich.edu (Ralph Seguin) (10/03/90)
Hi. I am about to acquire a PLEXUS 68000 based UNIX box running Sys V.2 (yech, I know 8-). I have several questions. 1: Can I get something akin to DNET to compile on this beast? 2: Can I get an ethernet board for it? 3: It has 8 serial ports, so I'm hoping to get SLIP on it. 4: Any other info anybody may have about this box. I know that DNET won't compile since V.2 doesn't have sockets. Thanks, Ralph gilgalad@dip.eecs.umich.edu gilgalad@zip.eecs.umich.edu gilgalad@caen.engin.umich.edu Ralph_Seguin@ub.cc.umich.edu gilgalad@sparky.eecs.umich.edu USER6TUN@UMICHUB.BITNET Ralph Seguin | Drinking a pan-galactic gargle blaster is 536 South Forest | like being struck over the head by a large Apartment 915 | brick of gold with a lemon wrapped around it. Ann Arbor, MI 48104 | - Zaphod Beeblebrox (313) 662-4805
david@twg.com (David S. Herron) (10/06/90)
In article <1990Oct3.043213.18022@caen.engin.umich.edu> gilgalad@caen.engin.umich.edu (Ralph Seguin) writes: >Hi. I am about to acquire a PLEXUS 68000 based UNIX box running >Sys V.2 (yech, I know 8-). I have several questions. >1: Can I get something akin to DNET to compile on this beast? Not very likely .. the reason DNET requires sockets is so that it can avoid the "blocking" (i.e. hang-until-a-character-arrives) that normally happens on Unix. There normally isn't a way to specify that an I/O channel is able to do asynchronous reads or writes in Unix .. arguably a lack in its design. The way select() helps is that it lets the program check the port without hanging, or to hang for a little while, or to return when *any* I/O descriptor has characters or any reasonable combination of the above. System V has never had this, except through add-in packages from various vendors (ahem) add-in TCP/IP packages :-). System V r4 will (I think, haven't read the docs on it yet) have a socket interface in the native system. But that's neither here nor there .. SysVr2 simply didn't have anything similar. In r3+streams you have this system call which looks promising: poll(). But it only works on a "stream", and doesn't work on a real tty device even though the tty drivers had become streams based. The interface at the /dev/ttynn level had gotten the streams-isms stripped away, I suppose. Sigh.. The closest you get with r2 is to set the VTIM type parameters using stty (or ioctl() if you're speaking C at the OS). >2: Can I get an ethernet board for it? mebbe tho it might be a bit hard to find one since that machine probably isn't in production ... >3: It has 8 serial ports, so I'm hoping to get SLIP on it. Plan on porting TCP/IP on your own. If'n you do port it on your own you can maybe shove a real select() into it. On the other hand I've read through the source for TWG/TCP for 7300/3b1's (a SysVr2 box based on 68010, should be some similarity to your Plexus) .. All the code for doing select() on a tty is commented out -- I haven't read closely enough to see *why* but I suspect that some niggling detail in the kernel architecture on SysV doesn't support this. I would suggest working back and forth between Bach's book on SysV internals and Karels book on 4.3BSD internals ;-). Hope this helps ... [response is in public since I've seen other similar queries in the past] David -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Remember: On System V it's "tar xovf", not "tar xvf"!
filbo@gorn.santa-cruz.ca.us (Bela Lubkin) (10/08/90)
In <8032@gollum.twg.com> David S. Herron wrote in reply to Ralph Seguin:
[Difficult to port DNET to SysV UNIX because you need select() to poll a]
[serial port without hanging until the next character is received. ]
On SysV, you might fork a coprocess to read the serial port, then
communicate with it through a pipe opened with O_NDELAY. There are
probably about 5 other more-or-less reasonable ways to do it. This
should not be an insurmountable obstacle...
This is arguably not an Amiga topic, but if it will get DNET supported
under SysV, it will benefit a lot of Amiga users. I've redirected
discussion to comp.sys.amiga.tech since this has nothing to do with
hardware.
Bela Lubkin * * // filbo@gorn.santa-cruz.ca.us Why do I mention CI$??
@ * * // belal@sco.com ...ucbvax!ucscc!{gorn!filbo,sco!belal}
R Pentomino * \X/ Filbo @ Pyrzqxgl +1 408-476-4633, XBBS +1 408-476-4945dillon@overload.Berkeley.CA.US (Matthew Dillon) (10/10/90)
In article <227.filbo@gorn.santa-cruz.ca.us> filbo@gorn.santa-cruz.ca.us (Bela Lubkin) writes: >In <8032@gollum.twg.com> David S. Herron wrote in reply to Ralph Seguin: >[Difficult to port DNET to SysV UNIX because you need select() to poll a] >[serial port without hanging until the next character is received. ] > >On SysV, you might fork a coprocess to read the serial port, then >communicate with it through a pipe opened with O_NDELAY. There are >probably about 5 other more-or-less reasonable ways to do it. This >should not be an insurmountable obstacle... > >This is arguably not an Amiga topic, but if it will get DNET supported >under SysV, it will benefit a lot of Amiga users. I've redirected >discussion to comp.sys.amiga.tech since this has nothing to do with >hardware. > >Bela Lubkin * * // filbo@gorn.santa-cruz.ca.us Why do I mention CI$?? > @ * * // belal@sco.com ...ucbvax!ucscc!{gorn!filbo,sco!belal} >R Pentomino * \X/ Filbo @ Pyrzqxgl +1 408-476-4633, XBBS +1 408-476-4945 Well, I have no access to SysV so I can't port DNet myself, it is a question of finding a good programmer with access to a SysV box and an Amiga who wants to do it. One thing, O_NDELAY is cute but also a quick way to get lots of people angry at you if you use it in a poll loop. It is actually more useful in a non-polled algorithm... you still must have some kind of wait-for-event call, and simply means that the program can try to anticipate ready data or available write buffer space without having to make *two* system calls. DNet must be able to wait on the following events: * new connection on listen socket pending * read data ready on socket * write buffer space available on socket (actually, I think DNet just uses blocking writes for this right now) * read data ready on TTY (that the protocol is run over) With the current implementation of DNet, using the select() call (which, by the way, I hate with a passion but there is no other way to do it under BSD), the process itself takes minimal CPU ... 0 if the connection is idle in fact, which means that most people can get away with leaving themselves connected all day without the sysop noticing. Even under a full load @ 2400 baud the dnet process takes less than 10% of the CPU. I do admit to playing to the BSD schedular however, so in a loaded system DNet will generally get more CPU than other processes :-). It also recovers nicely from the infamous '20 second swap-out' that happens when the machine is totally overloaded with users (read: university running BSD 4.2/4.3 on a VAX 750). If anybody does intend to take on the job, a word of warning: DO NOT USE SIGNALS TO HANDLE IO ON A UNIX MACHINE. Originally I used the IO signal to read data from the tty running the protocol. This wound up using 50% + of the CPU. Using select() reduced it down to 10% or less. For one thing, using select(), if I know I have read a partial packet I can 'guess' how long it will take the rest of the packet to come in and wait that period of time before making the system call to read the data. Using select() to wait in this manner usually ups the schedular priority for your process (since you are waiting on IO and theoretically not taking any CPU to do it). Thus the better performance on a loaded machine. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA