TUHS

tuhs@tuhs.org

6420 discussions

by John Holden

Aaron J. Grier wrote :- > support for PDP-11 was added to gcc a few months ago. It's been around since 1991 as a patch, but it didn't keep up with the newer versions of gcc

22 years, 11 months

Re: [pups] screen 3.9.9 vs. 2.11BSD write() to fifo and/or select() on socket

by Steven M. Schultz

Hi - > From: David W Talmage <talmage(a)cmf.nrl.navy.mil> > I thought that I'd read in the FM that they do. I see now that I was > mistaken,perhaps delusional. I see now that <sys/stat.h> contains the gospel: > > #define S_IFIFO 0010000 /* named pipe (fifo) - Not used by 2.11BSD */ :) Adding FIFOs to the kernel would make an interesting project though - perhaps when I become inspired/motivated I'll give it a try. > Sounds like I'm in for some deep hacking if I continue with this. Will > overlays help me here? Overlays will help if the code comes out to more than 64KB. Alas, overlays will _not_ help the dataspace requirements. The last time I looked at 'screen' I saw things like "char buf[32768];' sprinkled thru the code. So you might be in for some serious hacking to trim back the sizes of arrays/buffers/etc. It probably would also be a good idea to 'string'ify the program (there are tools to assist doing this - take a look at how sendmail and lint are built). > I wonder if setitimer() will fare any better. alarm() is obsolete. The gospel according to /usr/src/lib/libc/gen/alarm.c says: /* * Backwards compatible alarm. */ #include <sys/time.h> #include <unistd.h> unsigned int alarm(secs) unsigned int secs; { struct itimerval it, oitv; register struct itimerval *itp = ⁢ timerclear(&itp->it_interval); itp->it_value.tv_sec = secs; itp->it_value.tv_usec = 0; if (setitimer(ITIMER_REAL, itp, &oitv) < 0) return (-1); if (oitv.it_value.tv_usec) oitv.it_value.tv_sec++; return (oitv.it_value.tv_sec); } <g> > I'll send a progress report if I decide to continue this project. Thanks for > your help, Mr. Schultz. What I think you're seeing is the race condition that fork() has - there is no guarantee which process (parent or child) runs first. The test program does the fork() and the child runs to completion before the parent enters the select(). At that point the parent will wait until the alarm goes off. One thing you might try is create two separate programs. One would create the socket and wait for the other program to connect and send a string. If that works it shows that the UNIX domainsockets are working as expected and that the fork() race is indeed the problem. IF the client/server tests fail then there is something wrong in the UNIX domain socket handling that needs to be addressed. Good Luck! Cheers, Steven Schultz

22 years, 11 months

Re: [pups] screen 3.9.9 vs. 2.11BSD write() to fifo and/or select() on socket

by Steven M. Schultz

Hi! > From: David W Talmage <talmage(a)cmf.nrl.navy.mil> > Would someone please advise me about fifos and sockets in 2.11BSD? Ok ;) Don't use fifos - they don't exist (as you probably have found out by now :)) > I'm having > trouble porting screen 3.9.9, the multiplexing terminal emulator, to 2.11BSD fifos and sockets are just the tip of the iceberg when it comes to 'screen'. Eons ago (when screen was a fairly new program) I made an attempt at porting it and ran into the address space problems - seems that screen wants to use lots of large buffers, has lots of strings (all the help, etc) and so on. > because of them. I'm running Mr. Schultz's 2.11BSD with all patches up to > #442 on Mr. Brandt's p11 emulator version 2.9. FWIW, I have INET in my kernel > but I've ifconfig-ed only lo0. Thanks for the "ownership" label but I think of it more as being a 'steward' and coordinator than anything else p11 2.9? Wow, I've an old patched/hacked 2.5 because I can't seem to find p11's home now - begemot.org doesn't mention anything about "p11". > The fifo test portion of the configure script fails when writing to the fifo. > The write() returns -1 and sets errno == 79, "Inappropriate file type or Right, FIFOs don't exist. One of those things I never could find the need or time for ;) > format". This happens when I run the test as root, as I must in order to use > mknod() to create the fifo. See fifotest.c, below. If 2.11's mknod can create fifos that is _news_ to me. I don't recall seeing (or adding) that capability. > screen can use sockets instead of fifos. That portion of the configure script > fails as well. It fails in that it does not return from the select() on the > socket until the alarm goes off. See socketstest.c, below. Now that is very strange. Unix domain sockets do work (syslogd uses them for example) so I'm at a loss to explain why the test program isn't working. One thing I did do is after running "./a.out&" was do an immediate 'ps'. That should see 2 a.out processes due to the 'fork()' call. I only say one. This tells me that the alarm was started (obviously since alarm(5) is the first thing executed) but the child process raced thru and exited before the parent got to the select() call. With the child exited the select() will block until interrupted by the alarm() call. Steven Schultz sms(a)2bsd.com

22 years, 11 months

[pups] screen 3.9.9 vs. 2.11BSD write() to fifo and/or select() on socket

by David W Talmage

Would someone please advise me about fifos and sockets in 2.11BSD? I'm having trouble porting screen 3.9.9, the multiplexing terminal emulator, to 2.11BSD because of them. I'm running Mr. Schultz's 2.11BSD with all patches up to #442 on Mr. Brandt's p11 emulator version 2.9. FWIW, I have INET in my kernel but I've ifconfig-ed only lo0. screen's configure complains that it finds no usable fifo or socket. The fifo test portion of the configure script fails when writing to the fifo. The write() returns -1 and sets errno == 79, "Inappropriate file type or format". This happens when I run the test as root, as I must in order to use mknod() to create the fifo. See fifotest.c, below. screen can use sockets instead of fifos. That portion of the configure script fails as well. It fails in that it does not return from the select() on the socket until the alarm goes off. See socketstest.c, below. /* fifotest.c */ #include "confdefs.h" #include <sys/errno.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> /* #ifndef O_NONBLOCK #define O_NONBLOCK O_NDELAY #endif #ifndef S_IFIFO #define S_IFIFO 0010000 #endif */ char *fin = "/tmp/conftest254"; main() { struct stat stb; int f; (void)alarm(5); #ifdef POSIX if (mkfifo(fin, 0777)) { #else if (mknod(fin, S_IFIFO|0777, 0)) { #endif printf("mknod failed\n"); perror("mknod"); exit(1); } if (stat(fin, &stb) || (stb.st_mode & S_IFIFO) != S_IFIFO) { printf("stat failed\n"); exit(1); } close(0); #ifdef __386BSD__ /* * The next test fails under 386BSD, but screen works using fifos. * Fifos in O_RDWR mode are only used for the BROKEN_PIPE case and for * the select() configuration test. */ exit(0); #endif if (open(fin, O_RDONLY | O_NONBLOCK)) { printf("open #1 failed\n"); exit(1); } if (fork() == 0) { printf("f0\n"); close(0); if (open(fin, O_WRONLY | O_NONBLOCK)) { printf("f0 open #2 failed\n"); exit(1); } close(0); if (open(fin, O_WRONLY | O_NONBLOCK)) { printf("f0 open #3 failed\n"); exit(1); } if (write(0, "TEST", 4) == -1) { /* FAILS HERE */ printf("f0 write failed %d\n", errno); perror("write"); exit(1); } exit(0); } printf("f1\n"); f = 1; if (select(1, &f, 0, 0, 0) == -1) { printf("f1 select failed\n"); exit(1); } exit(0); } /* socketstest.c */ #include <sys/types.h> #include <sys/socket.h> #include <sys/un.h> #include <fcntl.h> char *son = "/tmp/conftest254"; main() { int s1, s2, s3, l; struct sockaddr_un a; (void)alarm(5); if ((s1 = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) { perror("socket"); exit(1); } a.sun_family = AF_UNIX; strcpy(a.sun_path, son); (void) unlink(son); if (bind(s1, (struct sockaddr *) &a, strlen(son)+2) == -1) { perror("bind"); exit(1); } if (listen(s1, 2)) { perror("listen"); exit(1); } if (fork() == 0) { if ((s2 = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) { perror("f0 socket"); kill(getppid(), 3); } (void)connect(s2, (struct sockaddr *)&a, strlen(son) + 2); if (write(s2, "HELLO", 5) == -1) { perror("f0 write"); kill(getppid(), 3); } exit(0); } l = sizeof(a); if (close(0) == -1) { perror("close"); } if (accept(s1, &a, &l)) { perror("accept"); exit(1); } l = 1; if (select(1, &l, 0, 0, 0) == -1) { /* DOESN'T RETURN BEFORE SIG_ALARM */ perror("select"); exit(1); } exit(0); } -- David Talmage (talmage(a)cmf.nrl.navy.mil) ITT Industries, Advanced Engineering & Sciences, Advanced Technology Group

22 years, 11 months

4.4BSD-Lite binaries for SPARC and PMAX

by Jochen Kunz

Hi. I plan to do a BSD exhibition at the VCFE. Main focus is 4.3BSD{,-Tahoe,-Reno} on VAXen. But I want to show 4.4BSD-Lite on HP300, SPARC and PMAX too. I have the 4.4BSD-Lite HP300 binaries, but nothing for SPARC and PMAX. Are there any binaries still around? I don't want to struggle with a SPARC and PMAX bootstrap... Ahh, and 4.2BSD-Reno for HP300 is missing too... -- tschüß, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/

22 years, 11 months

Re: FW: FW: Cancer (DO NOT DELETE A WORD OF THIS)

by Rahbynz1＠aol.com

Please read the following: http://urbanlegends.about.com/library/blamybruce.htm?terms=make+a+wish

22 years, 12 months

Re: [pups] Duh - how do you format an RX50?

by pete＠dunnington.u-net.com

On Feb 10, 17:23, Jay Jaeger wrote: > Rats. So it would seem. Forgot about that angle. Useful program -- just > not for floppies. > > Oh well. > > (Hmm. I wonder how "bzzzzt"s taste when you have to eat them with your > hat?) I suspect that they kind of tingle, eh? As far as I remember, yes. I've tried it a few times myself :-) -- Pete Peter Turnbull Network Manager University of York

22 years, 12 months

Re: [pups] Duh - how do you format an RX50?

by pete＠dunnington.u-net.com

On Feb 8, 8:31, Bill Gunshannon wrote: > RX50's came pre-formatted from DEC. There was never a way to > format them on PDP's or VAX as far as I knew. I do think it is > possible to create them using PUTR and an old PC with a proper > floppy controller and a 1.2M floppy drive configured the right > way. You can format them on a Rainbow, but not an -11 or VAX. > My understanding is they are 80 track, 96 tpi format but spin > at the slow spead of normal 5.25 disks and not the higher speed > used by IBM HD disks. Very similar low-level format to IBM floppies, except that, as Bill says, they're 80-track. The spec is 80-track, 96 tpi, single-side, double density (not HD), 10 sectors per track, 512 bytes/sector. DEC squeeze the extra sector in by shortening some of the gaps; even so the timing is a little tight and the drive speed has to be better-than-averagely accurate. It doesn't matter whether you write them at 300 rpm or 360, so long as the controller adjusts its data rate accordingly (250kbps or 300kbps). Which is what a PC does (uses 250kbps for 300rpm and 300kbps for 360 rpm). However, many HD-capable drives use pin 2 on the interface not only to change the speed but change the write current. Some such drives have jumpers to set the correct values. > As a curious note, I actually had (and may still have in the > attic somewhere) a real shugart 80 track 5.25 drive that would > have been the equivalent of an RX50, so it was not only DEC who > used that format. I had them on a TRS-80 and NewDOS-80 and > DOSPlus had no problems formatting and using the drive. This > was long before my first PDP, but I now wonder if they would > have been able to read and write (and maybe even format!) RX50's. If the controller it was attached to can write MFM (double-density), then it would work. Drives of that type were very common before PCs took over. In fact you can fudge one to look like half of an RX50 (a real RX50 plays funny tricks with the SideSelect and Track00 signals, and some DEC controllers use that to recognise an RX50). -- Pete Peter Turnbull Network Manager University of York

22 years, 12 months

Re: [pups] Duh - how do you format an RX50?

by pete＠dunnington.u-net.com

On Feb 9, 8:37, Jay Jaeger wrote: > Um, bzzzzt. Wrong. I have a floppy labeled: BL-FN7AP-MC CZFNAP0 M-11 > FORMTR RX50 . This is a formatter program for a Micro PDP-11. > > It is a *diagnostic* program (not a user program) for formatting these > beasties. Mine is for the -11, I would imagine that there is one for the > MicroVAX as well. Jay, I just checked on that. It's not an RX50 formatter, it's the XXDP V2 formatting and diagnostics routines for an RXDX3. IIRC it will format RD5x hard drives, and RX33, but not an RX50. Can you get a directory listing of the disk? -- Pete Peter Turnbull Network Manager University of York

22 years, 12 months

Re: [pups] Duh - how do you format an RX50?

by pete＠dunnington.u-net.com

On Feb 9, 12:14, Bill Gunshannon wrote: > On Sat, 9 Feb 2002, Jay Jaeger wrote: > > > Um, bzzzzt. Wrong. I have a floppy labeled: BL-FN7AP-MC CZFNAP0 M-11 > > FORMTR RX50 . This is a formatter program for a Micro PDP-11. > I guess this constitutes the last straw for this myth. Or was it merely > a business decision intended to promote the sale of pre-formatted RX-50 > diskettes. (A practice not uncommon in those days. For example, at one > place where I worked we were responsible for maintaining Terak Micros, a > LSI-11 based system. Any time we reported a floppy problem the first > question was, "Are you using Terak brand diskettes??" Of course, everyone > at that time knew there were only 3 manufacturers of platens and everybody > else just supplied labels!!) > > Other arguments: I have an Andromeda Disk Controller. I know one of the > supported floppy formats is RX50. I'll bet the their formatting program > won't care what drive is there and will happily format diskettes for use > in this and other RX-50's. I expect it would. It's not hard to write a formatter program. I wrote one for my Acorn Archimedes, and an RX50 copier program as well. > I wonder if there is anyone who could be contacted about releasing it?? > Maybe even the VMS version, too. Or even, the source?? Somehow, I doubt > that Compaq still sells many pre-formatted RX50's. I seem to recall that DEC let people copy XXDP between machines without too much excitement. > And while we're on the subject, what about this supposed problem using > anything put certain kinds of diskettes?? I used my 80 track 96tpi drive > all the time with the same diskettes I used in my other SS/SD, DS/SD drives > all the time and never had a problem. Is this perhaps another myth intended > to foster the sale of pre-formatted diskettes?? So long as they're labelled SD or DD and not HD, they have the right coercivity. Some people argue that the fineness of the emulsion may be a factor, but actually you'd have to be incredibly unlucky to have a flaw on a disk that would allow it to be perfect for SD but not DD. Some people have likewise argued that the disk head gap is only about half as wide for 80-track as it is for 40-track, but that's irrelevant: even if the gap is a third of the track pitch, thats around 1/300", the resulting bit density (300 bpi) on the radius of the disk is still much coarser than the bit density around the circumference (about 3300 bpi for single density). I do have a few very old S/S floppies with flaws on the second side, and which therefore aren't good to use as D/S (I value my data!) but I have hundreds more sold as S/S that are work fine as D/S. They just weren't certified that way; they probably just weren't tested, in the days when lots of disks didn't need to be. -- Pete Peter Turnbull Network Manager University of York

22 years, 12 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS