netnews@wnuxb.UUCP (Heiby) (05/01/85)
Unix Technical Digest Wed, 1 May 85 Volume 1 : Issue 55 Today's Topics: File system limit in 4.2 BSD (followup) malloc/calloc and portable software? Safe version of system(3) call. (2 msgs) SVR2 termio(7) common misunderstanding Which IPC for passing control? ---------------------------------------------------------------------- Date: 29 Apr 85 13:15:12 GMT From: dhb@rayssd.UUCP Subject: File system limit in 4.2 BSD (followup) Thanks to all who replied to my request for a way to mount more than fifteen file systems in 4.2 BSD. There is indeed something besides the size of the fields in the core map that needs to be changed and it CAN cause weird swapping problems or other random behaviour. In locore.s there is a routine called "Fastreclaim" which "knows" about the core map structure. What it knows is the size of the structure and the location of two one-bit fields within it. Therefore if you make any changes to this structure you have to change the code in locore.s. One suggestion that was made was to make the size of the structure and the offsets to these fields #defines in the cmap.h file. I hope that the people at Berkeley take this suggestion and put it in the next release. What I did to solve the problem was to increase the size of the "mdev" field in the core map structure and move the field that followed it to the end of the structure. This way the offsets to the two other fields remained constant and I only had to change one line in locore.s. If you want to know the specific changes that I made, send me mail and I will send you a diff listing. If I get enough requests I will post it to the net. -- Dave Brierley Raytheon Co.; Portsmouth RI; (401)-847-8000 x4073 ...!decvax!brunix!rayssd!dhb ...!allegra!rayssd!dhb ...!linus!rayssd!dhb ------------------------------ Date: Mon, 29 Apr 85 13:42:19 est From: seismo!hadron!jsdy (Joseph S. D. Yao) Subject: malloc/calloc and portable software? > The question is: does it hold that calls to {c,m,re}alloc can be > safely intermixed on other Unix systems (S5, 4.1, v7, whatever). I seem > to remember getting into trouble with stuff like this on v6. The answer is: yes and no. All versions of calloc() that I have seen after V6.X call malloc(). But I don't remember any guarantee anywhere that they will continue to do so, especially on non-UNIX systems. Joe Yao hadron!jsdy@seismo.{ARPA,UUCP} ------------------------------ Date: Mon, 29 Apr 85 13:36:32 est From: seismo!hadron!jsdy (Joseph S. D. Yao) Subject: Safe version of system(3) call. It may be secure. It will not do what you expect. Whenever you use fork(), etc. you should always check for errors. You should also exit at the end of your fork'd activities. E.g.: { register int pid; int status; switch (pid = fork()) { case 0: /* child */ setgid(getgid()); setuid(getuid()); exit(system(string)); case ERROR: /* error, -1 */ fprintf(stderr, "Can't Fork or Whatever\n"); return(ERROR); default: /* parent, waits up for child. */ while ((wret = wait(&status)) != pid) { if (wret == ERROR) return(ERROR); } break; } return(status); } Incidentally, this creates a second, intermediate sub-process. If you don't want this, you are better off modifying system() itself. Joe Yao hadron!jsdy@seismo.{ARPA,UUCP} ------------------------------ Date: 29 Apr 85 12:50:16 CDT (Mon) From: ihnp4!oliveb!jerry Subject: Safe version of system(3) call. [The originally posted routine] should also do a setgid(getgid()) before the setuid so that set group ID programs are also protected. This also is inefficient in that an extra fork is done. Doing the code inline instead of calling system(3) would be more efficient. With access to the system(3) source you could easily make a copy differing only in name and the setgid() and setuid() calls. Jerry Aguirre @ Olivetti ATC {hplabs|fortune|idi|ihnp4|tolerant|allegra|tymix}!oliveb!jerry ------------------------------ Date: 27 Apr 85 21:19:08 CST (Sat) From: ihnp4!lzwi!psc Subject: SVR2 termio(7) common misunderstanding > OK, I give. I have been trying to get Hack 1.0.2 running on a 3B20 > w/ SVR2. The program appears to start ok, but you must enter > exactly four commands to get any response. > .... > Then to get any more action, you have to enter four more > commands, and until you do, there is no output to your terminal. > .... It's always four, as near as I can tell. > ..... The input appears to be read OK, just in these weird four > command chunks. Oh, I've seen *this* one before! Since Unix System III, the termio(7) structure has had an array of user definable control characters, e.g., character erase (# by default, but usually ^H). The problem is, two of these entries are overloaded. They mean EOF and <something else> when canonical processing (e.g., treating the number sign or backspace as somthing special), and and time and character counts when canonical processing is off. So hack turns off canonical processing, and the next read(2) from the terminal waits until it gets four characters, because c_cc[VMIN] = c_cc[EOF] = cntl(D) = 4. If you'd redefined the EOF character to ^Z, you'd need to type 26 commands before hack saw any of them. Got it? The fix is to find where canonical processing is turned off, and make sure c_cc[VMIN] is set to 1 (and c_cc[VTIME] is set to 0, which means no timeout when c_cc[VMIN] > 0). [Ed note: RTFM! :-) RWH.] ------------------------------ Date: Sun, 28 Apr 85 20:09:28 EST From: Doug Gwyn <ucbvax!gwyn@BRL.ARPA> Subject: Which IPC for passing control? Joe Yao said that pipes are slow because they use disk. This is a common misconception; in fact, the 4.2BSD socketpair pipes ("no disk") have been measured as having less throughput than real pipes/FIFOs. If the block I/O system has sufficient block buffers configured, then pipe traffic will seldom result in real disk read/writes but rather will run out of the block buffers in the kernel. The problem with using signals for IPC is that they do not have bulletproof semantics. For example, there is a timing window between the time that a process is switched to its signal handler and the earliest moment that the process can arrange to have a subsequent signal of the same type trapped or ignored. The 4.2BSD redesign of signals solves a lot of these problems at the cost of compatibility with other versions of UNIX. ------------------------------ End of Unix Technical Digest ****************************** -- Ronald W. Heiby / netnews@wnuxb.UUCP | unix-request@cbosgd.UUCP AT&T Information Systems, Inc., Lisle, IL (CU-D21)