From owner-freebsd-hackers Sun Feb 9 00:14:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA06413 for hackers-outgoing; Sun, 9 Feb 1997 00:14:40 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA06408 for ; Sun, 9 Feb 1997 00:14:29 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id IAA10507 for hackers@freebsd.org; Sun, 9 Feb 1997 08:27:24 +0100 From: Luigi Rizzo Message-Id: <199702090727.IAA10507@labinfo.iet.unipi.it> Subject: How to get all ip addresses of a system ? To: hackers@freebsd.org Date: Sun, 9 Feb 1997 08:27:23 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I was wondering, is there a system call (possibly portable to different OS's) to get all the addresses associated with a system ? Ideally, I would like something to scan the "in_ifaddr" list in the kernel. I can probably hack something using kvm_read, but would prefer a better (and more portable) way if possible. Any ideas ? Thanks Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Sun Feb 9 00:47:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA07452 for hackers-outgoing; Sun, 9 Feb 1997 00:47:31 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA07447; Sun, 9 Feb 1997 00:47:26 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id JAA09958; Sun, 9 Feb 1997 09:42:13 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id JAA14311; Sun, 9 Feb 1997 09:45:38 +0100 (MET) Message-Id: <3.0.32.19970209094538.00bb6cd0@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 09 Feb 1997 09:45:40 +0100 To: Bruce Evans From: Eivind Eklund Subject: Re: Proposed change to dump/restore Cc: current@freebsd.org, hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 07:34 AM 2/9/97 +1100, Bruce Evans wrote: >>The suid capability of dump is only used for remote backups. >> >>dump have been known for security holes in the past, and is not a user >>level program. I propose a change of default mode and owner for this >>program to >>-r-sr-x--- root:operator /sbin/dump > >It should be at least -r-sr-xr--. > >>which will disallow anybody not in the operator group from making backups >>using dump (which is not too bad a thing, as only members of wheel can >>access the harddisks directly, which is needed to be able to use dump >>anyway), and only leave dump vulnerable to attacks from an operator :) > >Don't forget device independence. If you somehow have a ufs file system >image in a file, then dump will work on it, and dump/restore is one way >to list its contents. If dump is world readable, then anyone can run a >nonsetuid copy of it to do this, but it's annoying to have to copy it. How about saying that remote backups must be done by root or by explictly setting dump/restore setuid until we can find the time to make dump/restore pipe to rsh? Removing setuid would let everybody execute it for normal operation, and doesn't throw too many wrenches in the machinery for a sysadmin - after all, # chmod 6555 /sbin/dump /sbin/restore isn't too major an operation if one really really want to run them to setuid. >Hard disks are not accessible by members of group wheel. However, they >are readable by group operator. Most of mine were - probably an operating error on my part. >Why do dump and restore currently have group tty? dump plays the wall(1) game. Command entry from the man page: n Whenever dump requires operator attention, notify all operators in the group ``operator'' by means similar to a wall(1). which is actually incorrect - it notifies all operators not on a dialup. It looks like the code can be changed to run write(1) instead of being setgid tty fairly easily. (Peter Wemm's suggestion) As far as I can tell, there is no reason for restore to be setgid tty - the only reference to ttys there is is in the source is to _PATH_TTY (/dev/tty), and that isn't owned by group tty anyway. Probably the permission was carried over from dump. Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/ eivind@freebsd.org From owner-freebsd-hackers Sun Feb 9 02:52:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA11344 for hackers-outgoing; Sun, 9 Feb 1997 02:52:54 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA11337 for ; Sun, 9 Feb 1997 02:52:47 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id VAA21349; Sun, 9 Feb 1997 21:55:15 +1100 (EST) Date: Sun, 9 Feb 1997 21:55:14 +1100 (EST) From: "Daniel O'Callaghan" To: hackers@freebsd.org Subject: Chalmers.com.au mysterious problem. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm sure lots of people remember Robert Chalmers' problem with his Annex and TCP RFC1323 extensions. Well, with the Annex out of the circuit, there are still problems. I could connect to www.chalmers.com.au from my home CSLIP-connected machine, but not from any office machine. When Bob dropped his MTU/MRU to 296, matching my CSLIP connection, all worked. Jim Shankland kindly posted an analysis of tcpdump when fetching a WWW document. Below, is output of what Robert Chalmers saw when I tried to fetch a doc before he changed the MTU/MRU. Could some kind soul with more experience than I please translate it into English. Jim found that packet number 1 never reached him, although packet 2 did. Perhaps the trace below will help us to work out why. Thanks, Danny ---------- Forwarded message ---------- Date: Sun, 9 Feb 1997 16:05:52 +1000 (EST) From: Robert Chalmers To: Daniel O'Callaghan Subject: Re: 19.log Hi Danny, the log from X.19 15:16:23.211557 skylark.hilink.com.au.3634 > nanguo.chalmers.com.au.http: S 1706172429:1706172429(0) win 16384 (DF) [tos 0x10] 15:16:23.211830 nanguo.chalmers.com.au.http > skylark.hilink.com.au.3634: S 3108632207:3108632207(0) ack 1706172430 win 17520 (DF) 15:16:25.959225 skylark.hilink.com.au.3634 > nanguo.chalmers.com.au.http: S 1706172429:1706172429(0) win 16384 (DF) [tos 0x10] 15:16:25.959375 nanguo.chalmers.com.au.http > skylark.hilink.com.au.3634: . ack 1 win 17520 (DF) 15:16:25.966115 nanguo.chalmers.com.au.http > skylark.hilink.com.au.3634: S 3108632207:3108632207(0) ack 1706172430 win 17520 (DF) 15:16:30.610414 skylark.hilink.com.au.3634 > nanguo.chalmers.com.au.http: . ack 1 win 17520 (DF) [tos 0x10] 15:16:36.453179 skylark.hilink.com.au.3634 > nanguo.chalmers.com.au.http: P 1:17(16) ack 1 win 17520 (DF) [tos 0x10] 15:16:36.566078 nanguo.chalmers.com.au.http > skylark.hilink.com.au.3634: . ack 17 win 17520 (DF) 15:16:37.285363 skylark.hilink.com.au.3634 > nanguo.chalmers.com.au.http: P 17:19(2) ack 1 win 17520 (DF) [tos 0x10] 15:16:37.291580 nanguo.chalmers.com.au.http > skylark.hilink.com.au.3634: . 1:1461(1460) ack 19 win 17520 (DF) 15:16:37.291932 nanguo.chalmers.com.au.http > skylark.hilink.com.au.3634: P 1461:2049(588) ack 19 win 17520 (DF) 15:16:42.272834 skylark.hilink.com.au.3634 > nanguo.chalmers.com.au.http: P 1:19(18) ack 1 win 17520 (DF) [tos 0x10] 15:16:42.273337 nanguo.chalmers.com.au.http > skylark.hilink.com.au.3634: . 2049:2921(872) ack 19 win 17520 (DF) 15:16:42.966753 nanguo.chalmers.com.au.http > skylark.hilink.com.au.3634: . 1:1461(1460) ack 19 win 17520 (DF) 15:16:53.604487 nanguo.chalmers.com.au.http > skylark.hilink.com.au.3634: . 1:1460(1459) ack 19 win 17520 (DF) 15:16:53.604550 nanguo.chalmers.com.au.http > skylark.hilink.com.au.3634: . 1460:1461(1) ack 19 win 17520 (DF) 15:16:53.840077 skylark.hilink.com.au.3634 > nanguo.chalmers.com.au.http: . ack 1 win 17520 (DF) [tos 0x10] 15:16:54.966751 nanguo.chalmers.com.au.http > skylark.hilink.com.au.3634: . 1:1460(1459) ack 19 win 17520 (DF) 15:16:58.064670 skylark.hilink.com.au.3634 > nanguo.chalmers.com.au.http: . ack 1 win 17520 (DF) [tos 0x10] 15:17:05.622246 skylark.hilink.com.au.3634 > nanguo.chalmers.com.au.http: . ack 1 win 17520 (DF) [tos 0x10] 15:17:18.966844 nanguo.chalmers.com.au.http > skylark.hilink.com.au.3634: . 1:1460(1459) ack 19 win 17520 (DF) 15:17:31.354969 skylark.hilink.com.au.3634 > nanguo.chalmers.com.au.http: P 19:27(8) ack 1 win 17520 (DF) [tos 0x10] 15:17:31.355154 nanguo.chalmers.com.au.http > skylark.hilink.com.au.3634: R 3108632208:3108632208(0) win 0 15:17:35.328240 skylark.hilink.com.au.3634 > nanguo.chalmers.com.au.http: F 27:27(0) ack 1 win 17520 (DF) [tos 0x10] 15:17:35.328347 nanguo.chalmers.com.au.http > skylark.hilink.com.au.3634: R 3108632208:3108632208(0) win 16384 -- chalmers.com.au: P.O. Box 2003. Mackay. 4740 +61-0412-079025 robert@chalmers.com.au for Whirled Peas http://www.chalmers.com.au Location: The Great Australian Content Site. 21'7" S, 149'14" E. From owner-freebsd-hackers Sun Feb 9 02:55:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA11416 for hackers-outgoing; Sun, 9 Feb 1997 02:55:05 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA11406 for ; Sun, 9 Feb 1997 02:54:56 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id VAA21361; Sun, 9 Feb 1997 21:57:04 +1100 (EST) Date: Sun, 9 Feb 1997 21:57:03 +1100 (EST) From: "Daniel O'Callaghan" To: Luigi Rizzo cc: hackers@freebsd.org Subject: Re: How to get all ip addresses of a system ? In-Reply-To: <199702090727.IAA10507@labinfo.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Feb 1997, Luigi Rizzo wrote: > I was wondering, is there a system call (possibly portable to different > OS's) to get all the addresses associated with a system ? Ideally, I > would like something to scan the "in_ifaddr" list in the kernel. I can > probably hack something using kvm_read, but would prefer a better (and > more portable) way if possible. What about the calls used by 'netstat -ain'? Danny From owner-freebsd-hackers Sun Feb 9 03:34:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA12426 for hackers-outgoing; Sun, 9 Feb 1997 03:34:12 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA12418 for ; Sun, 9 Feb 1997 03:34:07 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id MAA02310 for ; Sun, 9 Feb 1997 12:33:57 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.4/8.6.12) with UUCP id MAA28808 for hackers@freebsd.org; Sun, 9 Feb 1997 12:33:49 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.5/keltia-uucp-2.9) id LAA24234; Sun, 9 Feb 1997 11:39:53 +0100 (CET) Message-ID: <19970209113953.BN54628@keltia.freenix.fr> Date: Sun, 9 Feb 1997 11:39:53 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: hackers@freebsd.org Subject: Re: Proposed change to dump/restore References: <3.0.32.19970208155420.00aaf720@dimaga.com> X-Mailer: Mutt 0.60,1-3,9 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2999 In-Reply-To: ; from J Wunsch on Feb 8, 1997 17:16:21 +0100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to J Wunsch: > As Eivind Eklund wrote: > >> Does anybody object to the change? If not, it'll go into 2.1.7 and -current. > > Go for it! You've also got the blessing to do this in RELENG_2_2. And can it be done the Right Way(tm) for 3.0-CURRENT (non setuid + call to rsh/ssh if run by non-root) as discussed on committers ? -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #39: Sun Feb 2 22:12:44 CET 1997 From owner-freebsd-hackers Sun Feb 9 03:51:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA12765 for hackers-outgoing; Sun, 9 Feb 1997 03:51:07 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA12759 for ; Sun, 9 Feb 1997 03:50:59 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id MAA18594 for hackers@freebsd.org; Sun, 9 Feb 1997 12:50:57 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id MAA12726; Sun, 9 Feb 1997 12:28:02 +0100 (MET) Message-ID: Date: Sun, 9 Feb 1997 12:28:02 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@freebsd.org Subject: Re: should permissions of /usr/bin/login be changed to 0100 ??? References: <19970208135454.ZJ37734@klemm.gtn.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <19970208135454.ZJ37734@klemm.gtn.com>; from Andreas Klemm on Feb 8, 1997 13:54:54 +0100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Andreas Klemm wrote: > While an almost universal "feature", most people remain unaware that > an intruder can log into a system, then log in again by running the "login" > command from a shell. Because the second login is from the local host, the > utmp entry will not show a remote login host anymore. But still, it will have to reuse the same tty, and it required a previous login. So sure, you are able to track him in wtmp (unless he's going to hack wtmp, but you're lost in this case anyway). I sometimes love to have this feature. E.g., i log in via modem, setup or fixup a PPP account, and then exec login to the PPP account. Doing this all from inside the `term' command of PPP allows me to try the PPP session directly. I'm not sure whether exec su -l pppaccount will also work here. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Feb 9 05:50:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA16565 for hackers-outgoing; Sun, 9 Feb 1997 05:50:20 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA16555 for ; Sun, 9 Feb 1997 05:50:17 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id OAA21194 for freebsd-hackers@freefall.freebsd.org; Sun, 9 Feb 1997 14:50:16 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id OAA13066; Sun, 9 Feb 1997 14:47:04 +0100 (MET) Message-ID: Date: Sun, 9 Feb 1997 14:47:04 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freefall.freebsd.org Subject: Re: Thoughts on upgrade process References: X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Robert N Watson on Feb 9, 1997 01:34:34 -0500 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Robert N Watson wrote: > E.g, kern.warnoldbin or options="WARNOLDBIN". On exec of an old-linked > (compat linked?) binary, a warning would display. > > Alternatively, there may already be a mechanism for doing this :) There used to be a Tcl script to find those suckers using stale libraries. /usr/src/tools/LibraryReport/LibraryReport.tcl Maybe that's what you want? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Feb 9 06:03:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA17045 for hackers-outgoing; Sun, 9 Feb 1997 06:03:50 -0800 (PST) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA17034 for ; Sun, 9 Feb 1997 06:03:40 -0800 (PST) Received: (from davidn@localhost) by labs.usn.blaze.net.au (8.8.5/8.8.5) id BAA01064; Mon, 10 Feb 1997 01:03:26 +1100 (EST) Message-ID: <19970210010326.55168@usn.blaze.net.au> Date: Mon, 10 Feb 1997 01:03:26 +1100 From: David Nugent To: Andreas Klemm Cc: freebsd-hackers@freebsd.org Subject: Re: should permissions of /usr/bin/login be changed to 0100 ??? References: <19970208135454.ZJ37734@klemm.gtn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61 In-Reply-To: <19970208135454.ZJ37734@klemm.gtn.com>; from Andreas Klemm on Feb 02, 1997 at 01:54:54PM Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Feb 02, 1997 at 01:54:54PM, Andreas Klemm wrote: > >From the OPIE README file: > [...] > While an almost universal "feature", most people remain unaware that > an intruder can log into a system, then log in again by running the "login" > command from a shell. Because the second login is from the local host, the > utmp entry will not show a remote login host anymore. The OPIE replacement > for /bin/login currently carries on this behavior for compatibility reasons. Compatibility that is broken, imho. It breaks wtmp (and therefore last(1)), for example, by having a login record (the original) with no logout record. > If you would like to prevent this from happening, you should change the > permissions of /bin/login to 0100, thus preventing unprivileged users from > executing it. This fix should work on non-OPIE /bin/login programs as well. Actually, imho, NO user should be able to execute it. login should not be setuid. I see no functionality that su(1) doesn't already take care of. > Our /usr/bin/login program has the following permissions: > -r-sr-xr-x 1 root bin 24576 6 Feb 01:28 /usr/bin/login > > Would it be useful to change permissions to 0100 ? Just removing the setuid bit makes it harmless, but 0100 will prevent anyone but root trying, anyway. I'm all for it. Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-hackers Sun Feb 9 06:07:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA17182 for hackers-outgoing; Sun, 9 Feb 1997 06:07:07 -0800 (PST) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA17174 for ; Sun, 9 Feb 1997 06:07:01 -0800 (PST) Received: (from davidn@localhost) by labs.usn.blaze.net.au (8.8.5/8.8.5) id BAA01077; Mon, 10 Feb 1997 01:06:39 +1100 (EST) Message-ID: <19970210010639.44033@usn.blaze.net.au> Date: Mon, 10 Feb 1997 01:06:39 +1100 From: David Nugent To: Joerg Wunsch Cc: hackers@freebsd.org Subject: Re: should permissions of /usr/bin/login be changed to 0100 ??? References: <19970208135454.ZJ37734@klemm.gtn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61 In-Reply-To: ; from J Wunsch on Feb 02, 1997 at 12:28:02PM Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Feb 02, 1997 at 12:28:02PM, J Wunsch wrote: > I sometimes love to have this feature. E.g., i log in via modem, > setup or fixup a PPP account, and then exec login to the PPP account. > Doing this all from inside the `term' command of PPP allows me to try > the PPP session directly. I'm not sure whether exec su -l pppaccount > will also work here. I don't see why not. The only difference is that su(1) doesn't call setlogin(), so the session remains "owned" by the original login, and wtmp is no longer involved (which is a Good Thing). Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-hackers Sun Feb 9 07:27:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA20373 for hackers-outgoing; Sun, 9 Feb 1997 07:27:10 -0800 (PST) Received: from burka.carrier.kiev.ua (snar@burka.carrier.kiev.ua [193.193.193.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA20269 for ; Sun, 9 Feb 1997 07:26:28 -0800 (PST) Received: (from snar@localhost) by burka.carrier.kiev.ua (8.8.4/8.who.cares.1) id RAA05048; Sun, 9 Feb 1997 17:25:44 +0200 (EET) From: Alexander Snarskii Message-Id: <199702091525.RAA05048@burka.carrier.kiev.ua> Subject: Increasing overall security.... To: freebsd-hackers@freebsd.org Date: Sun, 9 Feb 1997 17:25:43 +0200 (EET) Content-type: text/plain; charset=koi8-r X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I want to contribute patch to libc to made FreeBSD unexploitable with standard 'stack overflow' attacks. All i wanted, is to made my FreeBSD-based host as secure as possible. And i havent found no such man as Theo de Raadt in FreeBSD project, so the source tree still contains some exploitable 'stack overflow' security holes. Most of which is based on using some 'insecure' functions like 'strcpy', 'sprintf' and so in setuid programs. 'Why don't rewrite that functions to check the stack integrity before return?' says Oleg Panaschenko sometimes ago, and after some reflections i found that that is not so bad idea. Yes, we're getting some overhead with using these functions rather than with standard ones, but, as for me, this overhead is not so big and a reason, that i can sleep without nightmares about another stack overflow exploits is much important for me. Well, that is not panacea, though. I still will have problems with other variants of security holes ( with creating temporary files, for example ). I apologise, that i used libc from 2.1.5-RELEASE for make that patch, but i have no free computer for run -current. I tested it with -current libc and it applied well. IDEA NOTES: There are two new functions: checkframe__(char* a,char* b), which checks that we have no stack frames (generated by call _func) in memory region [a,b], and insane__(char* function-name,char* buffer), which are just performs kill(SIGSEGV,getpid()) (because program will got this signal while 'ret' to junk address in stack anyway but exploited) and after exit(1) (for cases like signal(SIG_SEGV,SIG_IGN) :) ). And most functions, which can be used for stack exploiting, patched to check the changed memory region to avoid stack violation. These functions are: strcpy,strcat,sprintf ( well, 90% of such exploits used it ), gets (historical reasons :) ) and memcpy (some things, like scanf and so uses it). INSTALLATION NOTES: there are not just patch to existing functions, there are three new files to libc, which are attached as uuencoded .tgz to this letter. You need to extract it with `pwd`=/usr/src/lib . You also need to cd /usr/src/lib/libc/i386/string/ mv strcpy.S strcpy.S.orig mv strcat.S strcat.S.orig ( or just remove these files ) Sorry for my english. diff -r -c libc-old/i386/string/Makefile.inc libc/i386/string/Makefile.inc *** libc-old/i386/string/Makefile.inc Mon Jan 23 03:28:45 1995 --- libc/i386/string/Makefile.inc Tue Feb 4 18:13:03 1997 *************** *** 3,8 **** SRCS+= bcmp.S bcopy.S bzero.S ffs.S index.S memchr.S memcmp.S \ memmove.S memset.S \ ! rindex.S strcat.S strchr.S strcmp.S strcpy.S strcspn.c \ strlen.S strncat.c strncmp.S strncpy.c strpbrk.c strsep.c \ ! strspn.c strrchr.S strstr.c swab.S --- 3,8 ---- SRCS+= bcmp.S bcopy.S bzero.S ffs.S index.S memchr.S memcmp.S \ memmove.S memset.S \ ! rindex.S strchr.S strcmp.S strcspn.c \ strlen.S strncat.c strncmp.S strncpy.c strpbrk.c strsep.c \ ! strspn.c strrchr.S strstr.c swab.S checkframe.S insane.c diff -r -c libc-old/i386/string/memmove.S libc/i386/string/memmove.S *** libc-old/i386/string/memmove.S Wed Jun 5 05:47:35 1996 --- libc/i386/string/memmove.S Sat Feb 8 22:16:28 1997 *************** *** 46,53 **** * (ov)bcopy (src,dst,cnt) * ws@tools.de (Wolfgang Solfrank, TooLs GmbH) +49-228-985800 */ ! ALTENTRY(memcpy) ENTRY(memmove) pushl %esi pushl %edi --- 46,54 ---- * (ov)bcopy (src,dst,cnt) * ws@tools.de (Wolfgang Solfrank, TooLs GmbH) +49-228-985800 */ ! /* ALTENTRY(memcpy) + */ ENTRY(memmove) pushl %esi pushl %edi diff -r -c libc-old/stdio/gets.c libc/stdio/gets.c *** libc-old/stdio/gets.c Wed Jun 5 05:49:43 1996 --- libc/stdio/gets.c Sun Feb 9 17:05:33 1997 *************** *** 64,68 **** --- 64,69 ---- else *s++ = c; *s = 0; + if(checkframe__(buf,s)) insane__((char*)"gets",buf); return (buf); } diff -r -c libc-old/stdio/sprintf.c libc/stdio/sprintf.c *** libc-old/stdio/sprintf.c Wed Jun 5 05:49:52 1996 --- libc/stdio/sprintf.c Sun Feb 9 14:42:52 1997 *************** *** 71,75 **** --- 71,76 ---- ret = vfprintf(&f, fmt, ap); va_end(ap); *f._p = 0; + if(checkframe__(str,f._p)) insane__((char*)"sprintf",str); return (ret); } diff -r -c libc-old/string/Makefile.inc libc/string/Makefile.inc *** libc-old/string/Makefile.inc Wed Jun 5 05:50:30 1996 --- libc/string/Makefile.inc Sat Feb 8 22:15:28 1997 *************** *** 5,11 **** CFLAGS += -I${.CURDIR}/locale # machine-independent string sources SRCS+= memccpy.c strcasecmp.c strcoll.c strdup.c strerror.c \ ! strmode.c strtok.c strxfrm.c # machine-dependent string sources .include "${.CURDIR}/${MACHINE}/string/Makefile.inc" --- 5,11 ---- CFLAGS += -I${.CURDIR}/locale # machine-independent string sources SRCS+= memccpy.c strcasecmp.c strcoll.c strdup.c strerror.c \ ! strmode.c strtok.c strxfrm.c strcpy.c strcat.c memcpy.c # machine-dependent string sources .include "${.CURDIR}/${MACHINE}/string/Makefile.inc" diff -r -c libc-old/string/strcat.c libc/string/strcat.c *** libc-old/string/strcat.c Fri May 27 07:57:55 1994 --- libc/string/strcat.c Sat Feb 8 21:53:58 1997 *************** *** 43,50 **** --- 43,52 ---- register const char *append; { char *save = s; + char *funct="strcat"; for (; *s; ++s); while (*s++ = *append++); + if(checkframe__(save,s)) insane__(funct,save); return(save); } diff -r -c libc-old/string/strcpy.c libc/string/strcpy.c *** libc-old/string/strcpy.c Fri May 27 07:57:55 1994 --- libc/string/strcpy.c Sat Feb 8 21:54:40 1997 *************** *** 44,50 **** --- 44,52 ---- register const char *from; { char *save = to; + char *func="strcpy"; for (; *to = *from; ++from, ++to); + if(checkframe__(save,to)) insane__(func, save); return(save); } begin 644 tarball.tgz M'XL(`````````^U9;7/;-A+.5^E7[#E-*]JT7FS'L>,X$YJB;=[0HHZD['HZ M'9N'6J-?W]_;@%5"K/_H%V-O;WP'8WWGWKK'?P'\`C=W&V_U7 M4']I1YYK8YF'&<"K3(C\S_3N^HPE7\.AK]MJFV78!%.,IAGO]7.H1!HT#@\. M=/S_@A3C+&)JY):G838%Q!M*'>YXW@>1 MJ5\QS@EE*&+>Y5%(&#J$&8,1RX8\SUD,HTQ,>(R=O!_FRM.N2!)QAYL;(I'& MG"9)0J%Y0Y:_IWZC^L@U%>?,ITC$J(F;!,/)0_254,-;,2'1C#0"P9:*G$=, M1PTN(4$\@EF:5>$]]`F-1DG(ARPCCF#GJ2-H<(61N2,89SQ&Y_X[OD`1Y0PI M%M%XB(L?SA>MANLA4)[!,,Q9QL-$+HE7"T;`JV&HX':K:F^$,>ZX=6C9:7NH+8=!2-'-[W#99FXI)M#(*`FGCR()HT$J[A(6]QCA MOB\V,5=>(FTYQAY6UVDD".6$3G"*=R.F`9G:"T.$M2SA:-Y@3GM@^^ M>QI<&9X%V&][[J7=M)IPC[\\HOAXX0? M?B`101FM:[!^;'N6[X/K@7W1=FS$06#/:`6VY>M@MTRGT[1;9\AR)X"6&X!C M7]@!J@6N3O8(Z.E,<$_APO+,)JVK[I&/:%U<0<9K?0,%B7&!;XYX;C/(@3D1Z$>6*AB\:)H["4 M'0RS:7N6&5`\RYZ)K*%WC@Y^VS)MZE@_6AB*X5WK,UC?^E<'E5!(:$WCPCC# MX"I?H`67Q.QXU@4YC$3XG1,_L(-.8,&9ZS9]@D)XW_(N;=/RC\!Q?<58Q[=T M-!(8RCRB(%THQOY)Q[<5<78KL#ROTPYLMZ41T+E[A<*M8,XL)']LR`T%8TT2KR&:P$"RWKS+&1==,BJ4M` M5[9O:;ADMD\*=F'YRKA6,794^+18Z%O17=F\NEI2L$_!:%[:Y/Q,&3>";\\V MC7M*2'['/)^Q3^>@5BZ_YET\7%V>LKCBV"?FC6^:O@;??P__F`\G/,VULJ1, M&4'4QZI"1I'D\4\_PS%L?*J\UC`EJ@*K=%!M0&6>1C38K^W5#G2)XC.>XJ.PJN=!5 M9M`A8:E6+F6LAVD:DY3R=C,71ZMC^)[(9Q*:A#+)?V,W.4T^*G\NETBV"3*< ML&,UM7CNCM/H>*.PB"&5>+<2]5DTZ&:8YFYNR(E<;"'&=D/3,!?+,*5AFH8" M[:BLIJ#:1[*J*,:'#_1`LW#.9RB72HAQK!PIE91H_G#7YPFK$/RV1B%M;Q\K M][>W4?H[L`0SYV>`9S2WM@K-K2W2)";P1916*L3AID9AHG._E__7%=O+MH3J M?[Y[L#__"%BN5=5_(1M?JO_K;_>+^G_W;;VQ1_7_WMY.8UW_?XWVI/XWJ?X_ M?$\P^6!_Y6(+*`>>86[#W*1E'@VDU9?G'=<6_KOC_I.+_HR(X'./J M9D\+X#"=HL_;_U']XEG2,\D7NO?+?K34 M"^_U0J:>#RHT25N%:NPLQFA:-!PIL)G*KSV&^>D^/R7?'DBCF=29<)%@QHO+ M"[WW,^@Z(=]K,P?D^#:![^JSIU]_PUTU^"OV=O`9Q4MMQ)M;5F84'FHXC?)R MTD)CYP\T%@J-APJE:ICP7@H[>OW^L%YV&J@X$J,YW0G#TE>5P]]8[;MNS]3_ MQ0?9B_X1X(OU_VYC4?_7=][2_?]^8W==_W^-]I?K?U)T$]:#=IB&$K-].A#P MH<^2WJ<\G%0'G$VJXW#]H;#^4/B[?RBL5L[K+X3U%\(W_86PO(T>IWC>XT-T>#4!]?T@H"F%U7M%'NMM#W?K"2/`4,YE6ICMG,6(I M^E/9*"9MZ(Y[=M-J6HYQ_6_JMG'Q7:_HVDWU2[M4J2''GD97Z"JD"@T9CN4% M^H:O/%RX5N3)N1_P1D)%>0]O1MJ&OO!O[AA=NR=",@)5=^=$1L6WSWSK[%+O ML7S$XXI&:LA6)\U8&/7Y;8+Y'TD:"KKA1Z8DK5F)W?.\TM#@"+ZY:^YU6[=U /6[=U>]3^`W%P;-0`*``` ` end -- Alexander Snarskii the source code is included. From owner-freebsd-hackers Sun Feb 9 08:21:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA22609 for hackers-outgoing; Sun, 9 Feb 1997 08:21:52 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id IAA22602 for ; Sun, 9 Feb 1997 08:21:41 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id RAA23960; Sun, 9 Feb 1997 17:21:38 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id RAA14010; Sun, 9 Feb 1997 17:13:29 +0100 (MET) Message-ID: Date: Sun, 9 Feb 1997 17:13:29 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Cc: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers) Subject: Re: Copious information on panic: ffs_valloc: dup alloc - IDEAS??? References: <199702090226.VAA22081@lakes.water.net> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702090226.VAA22081@lakes.water.net>; from Thomas David Rivers on Feb 8, 1997 21:26:35 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Thomas David Rivers wrote: > Another interesting item I've discovered is that the fs->cgmask is > 0xffffffff, rendering most of the macro below unused... here's the logic > I've evaluated. These macros are in /sys/ufs/ffs/fs.h: > Now - here's a strangeness - fs->cgmask (as evidenced by my printf()s), > is 0xfffffff, the logical compliment of that is 0; giving: > > (fs->fs_fpg) + fs->fs_iblkno; Bingo! You can also see this on any actual filesystem by using dumpfs. If you look into newfs's mkfs.c, you'll notice that there's ``no such thing like a filesystem with only one track (head)'' in newfs' opinion. This causes the 0xffffffff cgmask calculation, since our newfs basically creates only filesystems with 1 track (heads) and 4096 sectors per track, unless directed otherwise. I've hacked up my /sbin/newfs to fake 2 tracks in my personal mfs case, and i was immediately able to beat the hell out of it. Previously, this mfs on my (diskless booting) scratchbox was fragile like a FreeBSD coffee-mug. Right now, i was able to compile inside the mfs, extract huge tar files, run big cmp(1) jobs (which includes mmapping), run it ouf of i-nodes, run it out of space. Well, sorta for the latter, but only since the machine ran out of swap before the mfs filled up. Yet, it didn't panic with bad dirs, mangled entries etc. like it used to do before whenever doing ``something serious'' in the mfs. So either something is wrong with the filesystem code here, or it simply couldn't grok a filesystem with only one head. As a stop-gap measure, i suggest we bump the 1*4096 faked number in newfs to 2*2048. Speaking about newfs, i've got local patches that allow to mount an mfs ``from /dev/null'', so you can use it at all on a diskless machine where you don't have a useful and/or valid template filesystem to mount the mfs above. I've always held my horse back due to the mentioned panics, but now that it looks like a different problem, does anybody mind me committing them? Basically, the /tmp line in my diskless scratchbox looks like: /dev/null /tmp mfs rw,-s50000,-i50000,-f512,-b4096 0 0 (where the 50000 blocks is overkill since the machine has only 20 MB of NFS swap allowed). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Feb 9 08:38:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA23287 for hackers-outgoing; Sun, 9 Feb 1997 08:38:59 -0800 (PST) Received: from main.gbdata.com (tel_ppp0022.livingston.net [207.22.211.31]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA23276 for ; Sun, 9 Feb 1997 08:38:48 -0800 (PST) Received: (from gclarkii@localhost) by main.gbdata.com (8.8.5/8.6.9) id KAA08048; Sun, 9 Feb 1997 10:39:28 -0600 (CST) From: Gary Clark II Message-Id: <199702091639.KAA08048@main.gbdata.com> Subject: Re: Chalmers.com.au mysterious problem. To: danny@panda.hilink.com.au (Daniel O'Callaghan) Date: Sun, 9 Feb 1997 10:39:27 -0600 (CST) Cc: hackers@freebsd.org In-Reply-To: from Daniel O'Callaghan at "Feb 9, 97 09:55:14 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Daniel O'Callaghan wrote: > > I'm sure lots of people remember Robert Chalmers' problem with his Annex > and TCP RFC1323 extensions. Well, with the Annex out of the circuit, > there are still problems. I could connect to www.chalmers.com.au from my > home CSLIP-connected machine, but not from any office machine. When Bob > dropped his MTU/MRU to 296, matching my CSLIP connection, all worked. > > Hello, Check the routers around this machine. I had a customer once that had a problem REAL close to this. The cisco router's RTU was setup incorrectly. Gary -- Gary Clark II (N5VMF) | I speak only for myself and "maybe" my company gclarkii@GBData.COM | Member of the FreeBSD Doc Team Providing Internet and ISP startups mail info@GBData.COM for information FreeBSD FAQ at ftp://ftp.FreeBSD.ORG/pub/FreeBSD/docs/freebsd-faq.ascii From owner-freebsd-hackers Sun Feb 9 09:25:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA24833 for hackers-outgoing; Sun, 9 Feb 1997 09:25:24 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [194.77.0.15]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA24828; Sun, 9 Feb 1997 09:25:21 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id SAA13068; Sun, 9 Feb 1997 18:15:36 +0100 (MET) Received: (from andreas@localhost) by klemm.gtn.com (8.8.5/8.8.2) id RAA02064; Sun, 9 Feb 1997 17:16:49 +0100 (MET) Message-ID: <19970209171649.EU26961@klemm.gtn.com> Date: Sun, 9 Feb 1997 17:16:49 +0100 From: andreas@klemm.gtn.com (Andreas Klemm) To: davidn@labs.usn.blaze.net.au (David Nugent) Cc: freebsd-hackers@freebsd.org, current@freebsd.org Subject: Re: should permissions of /usr/bin/login be changed to 0100 ??? References: <19970208135454.ZJ37734@klemm.gtn.com> <19970210010326.55168@usn.blaze.net.au> X-Mailer: Mutt 0.60-PL0 Mime-Version: 1.0 In-Reply-To: <19970210010326.55168@usn.blaze.net.au>; from "David Nugent" on Feb 10, 1997 01:03:26 +1100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk David Nugent writes: > On Feb 02, 1997 at 01:54:54PM, Andreas Klemm wrote: > > >From the OPIE README file: > > [...] > > While an almost universal "feature", most people remain unaware that > > an intruder can log into a system, then log in again by running the "login" > > command from a shell. Because the second login is from the local host, the > > utmp entry will not show a remote login host anymore. The OPIE replacement > > for /bin/login currently carries on this behavior for compatibility reasons. > > Compatibility that is broken, imho. It breaks wtmp (and therefore > last(1)), for example, by having a login record (the original) with > no logout record. > > > > If you would like to prevent this from happening, you should change the > > permissions of /bin/login to 0100, thus preventing unprivileged users from > > executing it. This fix should work on non-OPIE /bin/login programs as well. > > Actually, imho, NO user should be able to execute it. login should > not be setuid. I see no functionality that su(1) doesn't already > take care of. > > > > Our /usr/bin/login program has the following permissions: > > -r-sr-xr-x 1 root bin 24576 6 Feb 01:28 /usr/bin/login > > > > Would it be useful to change permissions to 0100 ? > > Just removing the setuid bit makes it harmless, but 0100 will > prevent anyone but root trying, anyway. I'm all for it. So would it be ok, to install "login" with 0100 permissions ? If nobody is against it, I'd do the change in -current. Wouldn't that be additionally something for 2.2 and 2.1.7 ? After the whole security debate ?! -- andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-hackers Sun Feb 9 09:54:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA25873 for hackers-outgoing; Sun, 9 Feb 1997 09:54:59 -0800 (PST) Received: from kodiak.ucla.edu (kodiak.ucla.edu [164.67.128.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA25867; Sun, 9 Feb 1997 09:54:55 -0800 (PST) Received: from quark.cns.ucla.edu (quark.cns.ucla.edu [164.67.62.18]) by kodiak.ucla.edu (8.8.5/8.6.9) with SMTP id RAA21232; Sun, 9 Feb 1997 17:54:53 GMT Date: Sun, 9 Feb 1997 09:54:53 -0800 (PST) From: Mike Tsirulnikov X-Sender: mt@quark.cns.ucla.edu To: questions@freebsd.org, hackers@freebsd.org cc: scott@ctns.ucla.edu Subject: IPXrouted[64]: socket: Protocol not supported Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk What does this syslog message mean? It comes from a FreeBSD 2.2 snap Pentium 180 MHz Pro machine. Thanks. --- Mike Tsirulnikov UCLA Campus Telecomunications and Network Services mt@cns.ucla.edu (310) 825-8045 From owner-freebsd-hackers Sun Feb 9 10:23:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA27787 for hackers-outgoing; Sun, 9 Feb 1997 10:23:54 -0800 (PST) Received: from po7.andrew.cmu.edu (PO7.ANDREW.CMU.EDU [128.2.10.107]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA27782 for ; Sun, 9 Feb 1997 10:23:48 -0800 (PST) Received: (from postman@localhost) by po7.andrew.cmu.edu (8.8.2/8.8.2) id NAA03931 for freebsd-hackers@freefall.FreeBSD.org; Sun, 9 Feb 1997 13:23:32 -0500 Received: via switchmail; Sun, 9 Feb 1997 13:23:25 -0500 (EST) Received: from apriori.cc.cmu.edu via qmail ID ; Sun, 9 Feb 1997 13:22:45 -0500 (EST) Received: from apriori.cc.cmu.edu via qmail ID ; Sun, 9 Feb 1997 13:22:44 -0500 (EST) Received: from mms.4.60.Jun.27.1996.03.05.56.sun4.41.EzMail.2.0.CUILIB.3.45.SNAP.NOT.LINKED.apriori.cc.cmu.edu.sun4m.412 via MS.5.6.apriori.cc.cmu.edu.sun4_41; Sun, 9 Feb 1997 13:22:43 -0500 (EST) Message-ID: Date: Sun, 9 Feb 1997 13:22:43 -0500 (EST) From: Robert N Watson To: freebsd-hackers@freefall.FreeBSD.org Subject: Ownership -- ports, packages + cdrom under 2.1.5 (+6) Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This may be correct under 2.2, 3.0-SNAP (I couldn't find any instances in the 3.0 packages I installed.) Under 2.1.5, when I installed packages, I would find them owned by arbitrary (but common) uid's other than ones that exist on my system. Often they would be user id's like 2035 or 278, and often with seemingly arbitrary group id's (like 137.) On the CD-ROM's, many files are owned by 2035 (Jordan? :). Would it be possible to ship out CD's + ports owned by standard users? It was an uncomfortable experience when I created a user and found they owned the whole xemacs tree (installed as a package), etc. With the dore port, etc, I've had the same problem with installed binaries. Also, under 2.1.5, I've suffered from running sysinstall/package management programs and using a umask other than 0 -- the packages tend to get installed readable ownly by owner. Again, this may be corrected, but it would be nice if sysinstall set the umask to 0 for the course of its installation, or warned the user about the problem. I don't think I've had this experience under 3.0, so I assume that's fixed. I realize I've been a source of complaints for the last day or so, but having discovered that freebsd-hackers is an accessible list despite undergoing n-hundred posts a day, I'm suffering a bout of report-stuff syndrome. :) Once I get my 3.0-SNAP system running with a bigger drive, I'll get the source going and do something more constructive, assuming that's desirable. :) Thanks, Robert Watson From owner-freebsd-hackers Sun Feb 9 10:26:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA28117 for hackers-outgoing; Sun, 9 Feb 1997 10:26:44 -0800 (PST) Received: from po9.andrew.cmu.edu (PO9.ANDREW.CMU.EDU [128.2.10.109]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA28112 for ; Sun, 9 Feb 1997 10:26:39 -0800 (PST) Received: (from postman@localhost) by po9.andrew.cmu.edu (8.8.2/8.8.2) id NAA04228; Sun, 9 Feb 1997 13:26:25 -0500 Received: via switchmail; Sun, 9 Feb 1997 13:26:25 -0500 (EST) Received: from apriori.cc.cmu.edu via qmail ID ; Sun, 9 Feb 1997 13:24:34 -0500 (EST) Received: from apriori.cc.cmu.edu via qmail ID ; Sun, 9 Feb 1997 13:24:34 -0500 (EST) Received: from mms.4.60.Jun.27.1996.03.05.56.sun4.41.EzMail.2.0.CUILIB.3.45.SNAP.NOT.LINKED.apriori.cc.cmu.edu.sun4m.412 via MS.5.6.apriori.cc.cmu.edu.sun4_41; Sun, 9 Feb 1997 13:24:34 -0500 (EST) Message-ID: Date: Sun, 9 Feb 1997 13:24:34 -0500 (EST) From: Robert N Watson To: freebsd-hackers@freefall.FreeBSD.org, joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: Thoughts on upgrade process In-Reply-To: References: Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Excerpts from internet.computing.freebsd-hackers: 9-Feb-97 Re: Thoughts on upgrade pro.. by J Wunsch@uriah.heep.sax. >> E.g, kern.warnoldbin or options="WARNOLDBIN". On exec of an old-linked >> (compat linked?) binary, a warning would display. >> >> Alternatively, there may already be a mechanism for doing this :) > >There used to be a Tcl script to find those suckers using stale >libraries. > >/usr/src/tools/LibraryReport/LibraryReport.tcl I wasn't able to find this on the 2.1.5R or 2.1.6R CD-ROM's. I haven't checked the 2.1.0 or earlier CD's though. :) I'll go browse CVS on the web and see if I can find it. Thanks again, Robert Watson From owner-freebsd-hackers Sun Feb 9 10:40:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA29235 for hackers-outgoing; Sun, 9 Feb 1997 10:40:50 -0800 (PST) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA29230; Sun, 9 Feb 1997 10:40:34 -0800 (PST) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.8.5/8.8.5) id UAA13916; Sun, 9 Feb 1997 20:40:13 +0200 (SAT) From: John Hay Message-Id: <199702091840.UAA13916@zibbi.mikom.csir.co.za> Subject: Re: IPXrouted[64]: socket: Protocol not supported In-Reply-To: from Mike Tsirulnikov at "Feb 9, 97 09:54:53 am" To: mt@CNS.UCLA.EDU (Mike Tsirulnikov) Date: Sun, 9 Feb 1997 20:40:13 +0200 (SAT) Cc: questions@FreeBSD.ORG, hackers@FreeBSD.ORG, scott@ctns.ucla.edu X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > What does this syslog message mean? > > It comes from a FreeBSD 2.2 snap Pentium 180 MHz Pro machine. > Well I would guess you trying to use IPX with a kernel without IPX support. You need to build a kernel with options IPX in the kernel config file. John -- John Hay -- John.Hay@mikom.csir.co.za From owner-freebsd-hackers Sun Feb 9 11:21:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA01620 for hackers-outgoing; Sun, 9 Feb 1997 11:21:08 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA01611 for ; Sun, 9 Feb 1997 11:20:58 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA09021; Sun, 9 Feb 1997 14:20:24 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Sun, 9 Feb 1997 14:20 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id NAA01090 for ; Sun, 9 Feb 1997 13:15:55 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id NAA23758 for freebsd-hackers@freefall.cdrom.com; Sun, 9 Feb 1997 13:20:18 -0500 (EST) Date: Sun, 9 Feb 1997 13:20:18 -0500 (EST) From: Thomas David Rivers Message-Id: <199702091820.NAA23758@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: Re: Copious information on panic: ffs_valloc: dup alloc - IDEAS??? Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk J Wunsch writes: > > As Thomas David Rivers wrote: > > > Another interesting item I've discovered is that the fs->cgmask is > > 0xffffffff, rendering most of the macro below unused... here's the logic > > I've evaluated. These macros are in /sys/ufs/ffs/fs.h: > > > Now - here's a strangeness - fs->cgmask (as evidenced by my printf()s), > > is 0xfffffff, the logical compliment of that is 0; giving: > > > > (fs->fs_fpg) + fs->fs_iblkno; > > Bingo! > > You can also see this on any actual filesystem by using dumpfs. If > you look into newfs's mkfs.c, you'll notice that there's ``no such > thing like a filesystem with only one track (head)'' in newfs' > opinion. This causes the 0xffffffff cgmask calculation, since our > newfs basically creates only filesystems with 1 track (heads) and 4096 > sectors per track, unless directed otherwise. > > I've hacked up my /sbin/newfs to fake 2 tracks in my personal mfs > case, and i was immediately able to beat the hell out of it. > Previously, this mfs on my (diskless booting) scratchbox was fragile > like a FreeBSD coffee-mug. Right now, i was able to compile inside > the mfs, extract huge tar files, run big cmp(1) jobs (which includes > mmapping), run it ouf of i-nodes, run it out of space. Well, sorta > for the latter, but only since the machine ran out of swap before the > mfs filled up. Yet, it didn't panic with bad dirs, mangled entries > etc. like it used to do before whenever doing ``something serious'' in > the mfs. > > So either something is wrong with the filesystem code here, or it > simply couldn't grok a filesystem with only one head. As a stop-gap > measure, i suggest we bump the 1*4096 faked number in newfs to 2*2048. > ... Let me just echo back what you're saying, so I'm sure I have a clear understanding: You're saying the code in newfs.c that sets NTRACKS to 1 and NSECTORS to 4096 would be changed. The comment there: /* * About the same time as the above, we knew what went where on the disks. * no longer so, so kill the code which finds the different platters too... * We do this by saying one head, with a lot of sectors on it. * The number of sectors are used to determine the size of a cyl-group. * Kirk suggested one or two meg per "cylinder" so we say two. */ The value of 1 causes the fs_cgmask to be set to 0xffffff, as it is computed by: for (sblock.fs_cgmask = 0xffffffff, i = sblock.fs_ntrak; i > 1; i >>= 1) sblock.fs_cgmask <<= 1; making it unused in the disk block calculation. If this is so, doesn't that mean that everyone is using a file system that is questionable. Aren't inode reads/writes going to the wrong places (albeit consistently?) What I'm getting at, and I'm willing to believe it; is that we are very lucky that the file system works at all, if we're calculating block offsets incorrectly. I'll try a new version of newfs and report back. - Dave Rivers - --NAA23741.855512336/lakes.water.net-- From owner-freebsd-hackers Sun Feb 9 11:21:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA01676 for hackers-outgoing; Sun, 9 Feb 1997 11:21:34 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA01656 for ; Sun, 9 Feb 1997 11:21:24 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA09105; Sun, 9 Feb 1997 14:20:52 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Sun, 9 Feb 1997 14:20 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id NAA02648; Sun, 9 Feb 1997 13:49:10 -0500 (EST) Received: (from root@localhost) by lakes.water.net (8.8.3/8.6.9) id NAA24339; Sun, 9 Feb 1997 13:53:34 -0500 (EST) Date: Sun, 9 Feb 1997 13:53:34 -0500 (EST) From: Thomas David Rivers Message-Id: <199702091853.NAA24339@lakes.water.net> To: ponds!root.com!dg, ponds!freefall.cdrom.com!freebsd-hackers, ponds!uriah.heep.sax.de!joerg_wunsch, ponds!lambert.org!terry Subject: daily panics, ffs_valloc: dup alloc - Good news! Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As I said before; I would test our Joerg's supposition. I'm happy to report it seems to be right on the money! (Good work!) I built a new "newfs", with NTRACKS bumped to 2 and NSECTORS dropped to 2048. It worked like a champ! No more panic: ffs_valloc: dup alloc. I'd say the problem is that the underlying code can't handle one track (head). We should probably go ahead and use this work-around in 2.1.7 and 2.2. Perhaps, if we're so inclined, we can determine what a better fix would be to keep the 1 track idea. [It could possibly be simply setting fs->fs_cgmask to 0 if the number of tracks is 1; but I'm not sure.] That investigation could wait until after 2.2 and 2.1.7. Thanks to everyone for sticking with me on this! [Now, the question becomes how to adjust an existing file system; which I don't think can be done :-) ] Here's my (simple) patch to newfs.c... - Dave Rivers - *** newfs.c.ori Sun Sep 17 05:56:20 1995 --- newfs.c Sun Feb 9 13:51:46 1997 *************** *** 150,160 **** * We do this by saying one head, with a lot of sectors on it. * The number of sectors are used to determine the size of a cyl-group. * Kirk suggested one or two meg per "cylinder" so we say two. */ ! #define NTRACKS 1 /* number of heads */ ! #define NSECTORS 4096 /* number of sectors */ int mfs; /* run as the memory based filesystem */ int Nflag; /* run without writing file system */ --- 150,166 ---- * We do this by saying one head, with a lot of sectors on it. * The number of sectors are used to determine the size of a cyl-group. * Kirk suggested one or two meg per "cylinder" so we say two. + * + * NB: Although it's tempting to make NTRACKS 1; the underlying file + * system code will then receive an fs_cgmask of 0xffffffff which + * will make for ino<->block calculations; causing "dup alloc" and + * other panics. Until that problem is addressed, we pretend to have + * two heads (two heads are better than one :-) .) */ ! #define NTRACKS 2 /* number of heads */ ! #define NSECTORS 2048 /* number of sectors */ int mfs; /* run as the memory based filesystem */ int Nflag; /* run without writing file system */ From owner-freebsd-hackers Sun Feb 9 11:24:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA02037 for hackers-outgoing; Sun, 9 Feb 1997 11:24:11 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA01935 for ; Sun, 9 Feb 1997 11:23:29 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id UAA14931; Sun, 9 Feb 1997 20:21:34 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id UAA03469; Sun, 9 Feb 1997 20:22:23 +0100 (MET) Message-Id: <3.0.32.19970209202223.00a9c9e0@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 09 Feb 1997 20:22:44 +0100 To: roberto@keltia.freenix.fr (Ollivier Robert) From: Eivind Eklund Subject: Re: Proposed change to dump/restore Cc: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 11:39 AM 2/9/97 +0100, Ollivier Robert wrote: >According to J Wunsch: >> As Eivind Eklund wrote: >> >>> Does anybody object to the change? If not, it'll go into 2.1.7 and -current. >> >> Go for it! You've also got the blessing to do this in RELENG_2_2. > >And can it be done the Right Way(tm) for 3.0-CURRENT (non setuid + call to >rsh/ssh if run by non-root) as discussed on committers ? It will. Temporarily, I've just removed the setuid bits, as changing it to group operator is not feasible - it needs to be setgid tty. I'll fix it and get it in as soon as 2.1.7 is out the door - until that happens, I'd rather just focus on security even if it means loosing some features for a while. Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/ eivind@freebsd.org From owner-freebsd-hackers Sun Feb 9 11:36:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA03217 for hackers-outgoing; Sun, 9 Feb 1997 11:36:27 -0800 (PST) Received: from gdi.uoregon.edu (gdi.uoregon.edu [128.223.170.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA03212 for ; Sun, 9 Feb 1997 11:36:22 -0800 (PST) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.5/8.6.12) with SMTP id LAA04261; Sun, 9 Feb 1997 11:36:15 -0800 (PST) Date: Sun, 9 Feb 1997 11:36:15 -0800 (PST) From: Doug White X-Sender: dwhite@localhost Reply-To: Doug White To: Joerg Wunsch cc: FreeBSD hackers Subject: Re: ASUS MB panics In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 8 Feb 1997, J Wunsch wrote: > As John-Mark Gurney wrote: > > > basicly it seems that the call to ttyclose at the end of spec_close > > manages to overrun the stack... so upon return of spec_close it tries to > > "return" to the previous function.. but that return value was overwriten > > and so it jumps to the null pointer... > > A quick glance over the sources yields the clist stuff there as the > most likely culprit. Maybe Bruce has some more suggestions... One note, this blows up under DOS too -- screen blacks out after 'Starting MS-DOS' appears, so I'm suspecting a faulty MB. I'll return it Monday. Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major From owner-freebsd-hackers Sun Feb 9 11:51:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA04080 for hackers-outgoing; Sun, 9 Feb 1997 11:51:37 -0800 (PST) Received: from inetsrv.wtrt.net (inetsrv.wtrt.net [205.231.181.67]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA04075; Sun, 9 Feb 1997 11:51:30 -0800 (PST) Received: from allenh (ppp33.wtrt.net [205.231.181.103]) by inetsrv.wtrt.net (8.8.3/8.8.3) with SMTP id NAA15330; Sun, 9 Feb 1997 13:52:44 -0600 (CST) Message-Id: <3.0.1.32.19970209134902.0071a154@wtrt.net> X-Sender: allenh@wtrt.net X-Mailer: Windows Eudora Pro Version 3.0.1 beta 12 (32) Date: Sun, 09 Feb 1997 13:49:02 -0600 To: Mike Tsirulnikov , questions@freebsd.org, hackers@freebsd.org From: Allen Hyer Subject: Re: IPXrouted[64]: socket: Protocol not supported Cc: scott@ctns.ucla.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 09:54 AM 2/9/97 -0800, Mike Tsirulnikov wrote: >What does this syslog message mean? > >It comes from a FreeBSD 2.2 snap Pentium 180 MHz Pro machine. If you do not want IPX routing, add these lines to /etc/sysconfig ipxgateway=NO ipxrouted=NO and then restart. If you want IPX routing, someone else will have to help. I am not familiar with IPX routing. Hope that helps, Allen Hyer System Administrator West Texas Rural Telephone From owner-freebsd-hackers Sun Feb 9 12:36:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA06510 for hackers-outgoing; Sun, 9 Feb 1997 12:36:26 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA06381 for ; Sun, 9 Feb 1997 12:35:33 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA25138; Sun, 9 Feb 1997 13:30:29 -0700 From: Terry Lambert Message-Id: <199702092030.NAA25138@phaeton.artisoft.com> Subject: Re: DOS partition trouble To: bde@zeta.org.au (Bruce Evans) Date: Sun, 9 Feb 1997 13:30:29 -0700 (MST) Cc: bde@zeta.org.au, terry@lambert.org, durham@w2xo.pgh.pa.us, hackers@freebsd.org In-Reply-To: <199702062140.IAA05338@godzilla.zeta.org.au> from "Bruce Evans" at Feb 7, 97 08:40:19 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >I was under the impression that fictitious geometry was *always* > >an artifact of the BIOS's idea of geometry, not the oter way around. > > That would usually fail for disks partitioned under another BIOS, > especially under an old BIOS with a limited number of defaults. Ugh. So NCR has "clevered us up the butt". 8-(. When will we start using LBA's in the boot code, and ignoring the C/H/S portion of the partition table? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Feb 9 12:41:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA07101 for hackers-outgoing; Sun, 9 Feb 1997 12:41:50 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA07083 for ; Sun, 9 Feb 1997 12:41:34 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA25176; Sun, 9 Feb 1997 13:35:54 -0700 From: Terry Lambert Message-Id: <199702092035.NAA25176@phaeton.artisoft.com> Subject: Re: Audible ping response changes to ping.c To: karpen@ocean.campus.luth.se (Mikael Karpberg) Date: Sun, 9 Feb 1997 13:35:54 -0700 (MST) Cc: danny@panda.hilink.com.au, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199702070720.IAA13734@ocean.campus.luth.se> from "Mikael Karpberg" at Feb 7, 97 08:20:35 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Ok, so it's a nice idea to build functionality from small bits, but > this is ridiculous! :-) We're talking excanging about three lines of > C code with a big script. This is just a way too small change not to > be well jusified to go into ping as an option. The latest patch for ping > seemed just fine, although I'd think '-b' would be more logical. > You think "Hmm... now, what option was it that ping beep? Hmm..." and try > "-b". You don't think "What made ping audiable?". :-P Except that most people wouldn't ever use the option, and some of us are posting these scripts and things because we don't think this one adulteration of 'ping' is generally useful in a general purpose OS. If the point were to get beeps when you are ducked down behind a machine half a lab away futzing with calble, or sitting in front of the same machine futzing with network settings, etc., then Peter's "sed" script is better, since all you want is beeps, not the value of the RTT. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Feb 9 12:42:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA07179 for hackers-outgoing; Sun, 9 Feb 1997 12:42:48 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA07156 for ; Sun, 9 Feb 1997 12:42:37 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA25201; Sun, 9 Feb 1997 13:38:16 -0700 From: Terry Lambert Message-Id: <199702092038.NAA25201@phaeton.artisoft.com> Subject: Re: NIS/uids To: W.Belgers@nl.cis.philips.com (Walter Belgers) Date: Sun, 9 Feb 1997 13:38:16 -0700 (MST) Cc: terry@lambert.org, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199702071015.LAA03051@giga.lss.cp.philips.com> from "Walter Belgers" at Feb 7, 97 11:15:52 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > I have no "+" in my password file, only "+user", so you can only hack > > > those users, not the users that are only locally in my password file. So > > > it does give the desired protection. > > > > Do you do "+group" in the group file, as well? I suppose you have to... > > No, I don't mind wether or not all gids are in the group file. If a NIS > user is in group 999 which doesn't locally exists, so be it. What about groups 0 ("can su to root"), 2 ("can grope kernel memory"), or 4 ("can grope tty input"). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Feb 9 12:47:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA07478 for hackers-outgoing; Sun, 9 Feb 1997 12:47:21 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA07466 for ; Sun, 9 Feb 1997 12:47:10 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA25249; Sun, 9 Feb 1997 13:40:18 -0700 From: Terry Lambert Message-Id: <199702092040.NAA25249@phaeton.artisoft.com> Subject: Re: X.25 To: avianet@minas.rosmail.com (ðÁÞËÕÒÉÑ) Date: Sun, 9 Feb 1997 13:40:18 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: <970207-161823-00600@minas.rosmail.com> from "ðÁÞËÕÒÉÑ" at Feb 7, 97 04:18:23 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Have FreeBSD any support for protocol X.25, for example, > a driver for Eicon-card. We have a telematics Swich, and the clients > X.28 incomming havent E-mail access. What to do? Eicon, the Canadian company that makes X.25 boards? Check the -hackers list archives. I remember someone posting that they had a driver. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Feb 9 12:52:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA07836 for hackers-outgoing; Sun, 9 Feb 1997 12:52:26 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA07821 for ; Sun, 9 Feb 1997 12:52:07 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA00981 for freebsd-hackers@FreeBSD.ORG; Sun, 9 Feb 1997 21:51:57 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id VAA15499; Sun, 9 Feb 1997 21:50:20 +0100 (MET) Message-ID: Date: Sun, 9 Feb 1997 21:50:20 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: should permissions of /usr/bin/login be changed to 0100 ??? References: <19970208135454.ZJ37734@klemm.gtn.com> <19970210010326.55168@usn.blaze.net.au> <19970209171649.EU26961@klemm.gtn.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <19970209171649.EU26961@klemm.gtn.com>; from Andreas Klemm on Feb 9, 1997 17:16:49 +0100 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Andreas Klemm wrote: > So would it be ok, to install "login" with 0100 permissions ? If > nobody is against it, I'd do the change in -current. No, install it 555. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Feb 9 13:53:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA11823 for hackers-outgoing; Sun, 9 Feb 1997 13:53:52 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA11817 for ; Sun, 9 Feb 1997 13:53:45 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id IAA23815; Mon, 10 Feb 1997 08:27:43 +1100 (EST) Date: Mon, 10 Feb 1997 08:27:43 +1100 (EST) From: "Daniel O'Callaghan" To: Gary Clark II cc: hackers@freebsd.org, robert@chalmers.com.au Subject: Re: Chalmers.com.au mysterious problem. In-Reply-To: <199702091639.KAA08048@main.gbdata.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Feb 1997, Gary Clark II wrote: > Daniel O'Callaghan wrote: > > > > I'm sure lots of people remember Robert Chalmers' problem with his Annex > > and TCP RFC1323 extensions. Well, with the Annex out of the circuit, > > there are still problems. I could connect to www.chalmers.com.au from my > > home CSLIP-connected machine, but not from any office machine. When Bob > > dropped his MTU/MRU to 296, matching my CSLIP connection, all worked. > > Check the routers around this machine. I had a customer once that had > a problem REAL close to this. The cisco router's RTU was setup > incorrectly. OK. The backbone ISP common to Robert and me is Access One, who are exclusively Ascend, using Radius authentication and configuration. I'll get Robert to get the Access One folks to check his Max setup. Danny From owner-freebsd-hackers Sun Feb 9 13:54:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA11888 for hackers-outgoing; Sun, 9 Feb 1997 13:54:32 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA11878; Sun, 9 Feb 1997 13:54:21 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id IAA23848; Mon, 10 Feb 1997 08:35:45 +1100 (EST) Date: Mon, 10 Feb 1997 08:35:44 +1100 (EST) From: "Daniel O'Callaghan" To: Andreas Klemm cc: David Nugent , freebsd-hackers@freebsd.org, current@freebsd.org Subject: Re: should permissions of /usr/bin/login be changed to 0100 ??? In-Reply-To: <19970209171649.EU26961@klemm.gtn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Feb 1997, Andreas Klemm wrote: > > > Our /usr/bin/login program has the following permissions: > > > -r-sr-xr-x 1 root bin 24576 6 Feb 01:28 /usr/bin/login > > > > > > Would it be useful to change permissions to 0100 ? > > > > Just removing the setuid bit makes it harmless, but 0100 will > > prevent anyone but root trying, anyway. I'm all for it. > > So would it be ok, to install "login" with 0100 permissions ? If > nobody is against it, I'd do the change in -current. > > Wouldn't that be additionally something for 2.2 and 2.1.7 ? > After the whole security debate ?! I still don't see why you can't do as I suggested, and make it optional, dependent on the perm settings, as per my previous message on this topic. Danny From owner-freebsd-hackers Sun Feb 9 15:13:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA16619 for hackers-outgoing; Sun, 9 Feb 1997 15:13:04 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA16614 for ; Sun, 9 Feb 1997 15:12:59 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA03763; Mon, 10 Feb 1997 00:12:57 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id WAA15562; Sun, 9 Feb 1997 22:02:22 +0100 (MET) Message-ID: Date: Sun, 9 Feb 1997 22:02:22 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Cc: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers) Subject: Re: Copious information on panic: ffs_valloc: dup alloc - IDEAS??? References: <199702091818.NAA23739@lakes.water.net> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702091818.NAA23739@lakes.water.net>; from Thomas David Rivers on Feb 9, 1997 13:18:54 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Thomas David Rivers wrote: > You're saying the code in newfs.c that sets NTRACKS to 1 and > NSECTORS to 4096 would be changed. Yes, to e.g. 2 * 2048 instead. It's a mileage number only anyway, since Poul found out (experimentally) that it just works better than any (un)real number on today's zone-bit recorded and large cache disks. > If this is so, doesn't that mean that everyone is using a file system > that is questionable. Aren't inode reads/writes going to the wrong > places (albeit consistently?) I'm no filesystem expert at all, but this seems to be the case. The failure picture matches consistently with the reported MFS troubles (including mine), and it's probably also responsible for some other panic PRs you could find in the GNATS database. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Feb 9 15:13:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA16657 for hackers-outgoing; Sun, 9 Feb 1997 15:13:32 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA16650 for ; Sun, 9 Feb 1997 15:13:27 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA03781; Mon, 10 Feb 1997 00:13:25 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id WAA15603; Sun, 9 Feb 1997 22:10:10 +0100 (MET) Message-ID: Date: Sun, 9 Feb 1997 22:10:10 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Cc: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers) Subject: Re: daily panics, ffs_valloc: dup alloc - Good news! References: <199702091853.NAA24339@lakes.water.net> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702091853.NAA24339@lakes.water.net>; from Thomas David Rivers on Feb 9, 1997 13:53:34 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Thomas David Rivers wrote: > As I said before; I would test our Joerg's supposition. I'm happy to > report it seems to be right on the money! (Good work!) > I built a new "newfs", with NTRACKS bumped to 2 and NSECTORS dropped > to 2048. Great to hear! The `Good work' is your flowers: you've done the major part here. > We should probably go ahead and use this work-around in 2.1.7 and > 2.2. I'm also for it. What do other people think? > [Now, the question becomes how to adjust an existing file system; which > I don't think can be done :-) ] I think you could modify tunefs(8) to do just this. Remember to umount the filesystem before, since the umount might update that part of the superblocks (i'm not sure). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Feb 9 15:17:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA16804 for hackers-outgoing; Sun, 9 Feb 1997 15:17:18 -0800 (PST) Received: from hamby1 (hamby1.lightside.net [207.67.176.17]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA16792 for ; Sun, 9 Feb 1997 15:17:08 -0800 (PST) Received: from hamby1 by hamby1 (SMI-8.6/SMI-SVR4) id PAA00894; Sun, 9 Feb 1997 15:17:21 -0800 Message-ID: <32FE5AFF.5D48@lightside.com> Date: Sun, 09 Feb 1997 15:17:19 -0800 From: Jake Hamby Organization: Jet Propulsion Laboratory X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5 i86pc) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Year 2000 UNIX info (from Sun) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Here is a list of some known Year 2000 problems with Solaris, courtesy of the Solaris FAQ (http://www.fwi.uva.nl/pub/solaris/solaris2). I'm sure FreeBSD shares a few of these problems, at least in the areas where both OS's derive from the same source base. Enjoy! -- Jake Hamby A year 2000 project at Sun (http://www.sun.com/y2000/) plans to review all libraries, unbundled software, and some 3rd party apps in search of potential year 2000 problems, so that they are resolved well before the big day. Sun-maintained Solaris applications with known year-2000 problems as of Solaris 2.5.1 include the following; these problems should be fixed in Solaris 2.6. * SCCS files store only the last two digits of the year, so SCCS stops working after 1999. Fixing this requires coordination with other SCCS vendors. * The Solaris 1 `date' command can't set the clock past 1999. This bug is partly fixed in Solaris 2 `date', which supports both 2-digit and 4-digit years; however, in Solaris 2 you should use 4-digit years when setting the date, to avoid some remaining bugs with 2-digit year handling. * The following programs are known to have minor bugs related to using year-1900 instead of year modulo 100 when generating diagnostics, temporary file names, and the like: atq fsck listen passwd sar timex ufsdump uucico uustat uuxqt xterm * The -me, -mm, and -ms troff macro packages all assume that the current date is before January 1, 2000. * `sortbib' mishandles bibliographies containing 2-digit years that span the year-2000 boundary. * `ckdate' rejects years after 1999. * Problems have been reported with installing Solaris on machines whose hardware date is past 1999. * The filemgr `find after' and `find before' operations have only 2-digit inputs for years, and mishandle dates after 1999. * cm (the calendar manager) mishandles dates after 2000-02-29. * In Openstep, NSCalendarDate, NSDate*, Mail, and Prefrence need enhancements and fixes for years past 1999. In addition, user applications that invoke `getdate' and `strptime' on 2-digit years are advised to check their assumptions carefully. From owner-freebsd-hackers Sun Feb 9 15:51:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA19795 for hackers-outgoing; Sun, 9 Feb 1997 15:51:11 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA19785 for ; Sun, 9 Feb 1997 15:50:57 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA04469 for hackers@freebsd.org; Mon, 10 Feb 1997 00:50:54 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id AAA15983; Mon, 10 Feb 1997 00:21:59 +0100 (MET) Message-ID: Date: Mon, 10 Feb 1997 00:21:59 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@freebsd.org Subject: Re: DOS partition trouble References: <199702062140.IAA05338@godzilla.zeta.org.au> <199702092030.NAA25138@phaeton.artisoft.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702092030.NAA25138@phaeton.artisoft.com>; from Terry Lambert on Feb 9, 1997 13:30:29 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > When will we start using LBA's in the boot code, and ignoring the > C/H/S portion of the partition table? You can't, as long you're stuck with a BIOS that wants C/H/S in its int 0x13 calls. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Feb 9 16:46:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA23557 for hackers-outgoing; Sun, 9 Feb 1997 16:46:52 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA23552 for ; Sun, 9 Feb 1997 16:46:48 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id QAA17877; Sun, 9 Feb 1997 16:46:09 -0800 (PST) Received: from alpo.whistle.com(207.76.205.1) by whistle.com via smap (V1.3) id smaa17871; Sun Feb 9 16:46:00 1997 Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.5/8.8.4) with SMTP id QAA12670; Sun, 9 Feb 1997 16:44:41 -0800 (PST) Message-ID: <32FE6F05.237C228A@whistle.com> Date: Sun, 09 Feb 1997 16:42:46 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Joerg Wunsch CC: FreeBSD hackers , Thomas David Rivers Subject: Re: daily panics, ffs_valloc: dup alloc - Good news! References: <199702091853.NAA24339@lakes.water.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: > > As Thomas David Rivers wrote: > > > As I said before; I would test our Joerg's supposition. I'm happy to > > report it seems to be right on the money! (Good work!) > can you guys explain the problem in a couple of sinple sentences? From owner-freebsd-hackers Sun Feb 9 16:48:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA23646 for hackers-outgoing; Sun, 9 Feb 1997 16:48:42 -0800 (PST) Received: from darkstar (ras583.srv.net [205.180.127.83]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA23640 for ; Sun, 9 Feb 1997 16:48:37 -0800 (PST) Received: (from cmott@localhost) by darkstar (8.6.12/8.6.12) id RAA03672; Sun, 9 Feb 1997 17:48:32 -0700 Date: Sun, 9 Feb 1997 17:48:27 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar To: freebsd-hackers@freebsd.org Subject: Bus Errors Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk What does "Bus error" mean? From owner-freebsd-hackers Sun Feb 9 16:51:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA24150 for hackers-outgoing; Sun, 9 Feb 1997 16:51:46 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA24139 for ; Sun, 9 Feb 1997 16:51:41 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id QAA17889; Sun, 9 Feb 1997 16:51:09 -0800 (PST) Received: from alpo.whistle.com(207.76.205.1) by whistle.com via smap (V1.3) id sma017887; Sun Feb 9 16:50:48 1997 Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.5/8.8.4) with SMTP id QAA12738; Sun, 9 Feb 1997 16:49:13 -0800 (PST) Message-ID: <32FE7015.2F1CF0FB@whistle.com> Date: Sun, 09 Feb 1997 16:47:17 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Joerg Wunsch CC: FreeBSD hackers , Thomas David Rivers Subject: Re: Copious information on panic: ffs_valloc: dup alloc - IDEAS??? References: <199702091818.NAA23739@lakes.water.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: > > As Thomas David Rivers wrote: > > > You're saying the code in newfs.c that sets NTRACKS to 1 and > > NSECTORS to 4096 would be changed. > > Yes, to e.g. 2 * 2048 instead. It's a mileage number only anyway, > since Poul found out (experimentally) that it just works better than > any (un)real number on today's zone-bit recorded and large cache > disks. > > > If this is so, doesn't that mean that everyone is using a file system > > that is questionable. Aren't inode reads/writes going to the wrong > > places (albeit consistently?) > > I'm no filesystem expert at all, but this seems to be the case. The > failure picture matches consistently with the reported MFS troubles > (including mine), and it's probably also responsible for some other > panic PRs you could find in the GNATS database. > > -- > Kirk suggested setting the number of heads to 1 to turn off the "selelct a nearby head" code.. if you make it have 2 heads, this code will be enabled again and we'll lose the effect.. it pessimise the accesses by switching to a differnt head that it thinks has a nearby free block.. in the case of 2 heads (as suggested) this is actually likely to be "NOT NEARBY" and we will lose you could HEAR the difference when we went to 1 head.. From owner-freebsd-hackers Sun Feb 9 17:14:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA25897 for hackers-outgoing; Sun, 9 Feb 1997 17:14:36 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA25888 for ; Sun, 9 Feb 1997 17:14:24 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id LAA20190; Mon, 10 Feb 1997 11:44:11 +1030 (CST) From: Michael Smith Message-Id: <199702100114.LAA20190@genesis.atrad.adelaide.edu.au> Subject: Re: Thoughts on upgrade process In-Reply-To: from Robert N Watson at "Feb 9, 97 01:24:34 pm" To: rnw+@andrew.cmu.edu (Robert N Watson) Date: Mon, 10 Feb 1997 11:44:10 +1030 (CST) Cc: freebsd-hackers@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Robert N Watson stands accused of saying: > on upgrade pro.. by J Wunsch@uriah.heep.sax. > >> E.g, kern.warnoldbin or options="WARNOLDBIN". On exec of an old-linked > >> (compat linked?) binary, a warning would display. > >> > >> Alternatively, there may already be a mechanism for doing this :) > > > >There used to be a Tcl script to find those suckers using stale > >libraries. > > > >/usr/src/tools/LibraryReport/LibraryReport.tcl > > I wasn't able to find this on the 2.1.5R or 2.1.6R CD-ROM's. I haven't > checked the 2.1.0 or earlier CD's though. :) I'll go browse CVS on the > web and see if I can find it. It's not on any of the CD's; you'll need to hit a -current FTP repository, and you'll need Tcl installed. What it'll give you is basically a list of who uses what, wrt. shared libraries. You can use this information to decide which libraries/binaries fit your definition of 'stale'. It works OK with 2.1* strains as well as -current. > Robert Watson -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Sun Feb 9 17:31:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA26679 for hackers-outgoing; Sun, 9 Feb 1997 17:31:42 -0800 (PST) Received: from tyger.inna.net (root@tyger.inna.net [206.151.66.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA26647 for ; Sun, 9 Feb 1997 17:31:09 -0800 (PST) Received: from dolphin.inna.net (jamie@dolphin.inna.net [206.151.66.2]) by tyger.inna.net (8.8.3/8.7.3) with SMTP id UAA06336; Sun, 9 Feb 1997 20:31:52 -0500 (EST) Date: Sun, 9 Feb 1997 20:31:00 -0500 (EST) From: Jamie Bowden To: Charles Mott cc: freebsd-hackers@freebsd.org Subject: Re: Bus Errors In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Feb 1997, Charles Mott wrote: > What does "Bus error" mean? > Amazingly enough, a buss error is a memory allocation error. At least it was under SunOS. I am guessing FreeBSD is the same on this. Jamie Bowden Network Administrator, TBI Ltd. From owner-freebsd-hackers Sun Feb 9 17:38:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA27219 for hackers-outgoing; Sun, 9 Feb 1997 17:38:57 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA27212 for ; Sun, 9 Feb 1997 17:38:52 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id BAA19456; Mon, 10 Feb 1997 01:38:08 GMT Date: Mon, 10 Feb 1997 10:38:07 +0900 (JST) From: Michael Hancock To: Alexander Snarskii cc: freebsd-hackers@freebsd.org Subject: Re: Increasing overall security.... In-Reply-To: <199702091525.RAA05048@burka.carrier.kiev.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Feb 1997, Alexander Snarskii wrote: > I want to contribute patch to libc to made FreeBSD unexploitable > with standard 'stack overflow' attacks. > > All i wanted, is to made my FreeBSD-based host as secure as possible. > And i havent found no such man as Theo de Raadt in FreeBSD project, > so the source tree still contains some exploitable 'stack overflow' > security holes. Most of which is based on using some 'insecure' > functions like 'strcpy', 'sprintf' and so in setuid programs. Look in the cvs logs for recent commits by imp for example rlogind, rshd, etc. Mike Hancock From owner-freebsd-hackers Sun Feb 9 18:46:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA02374 for hackers-outgoing; Sun, 9 Feb 1997 18:46:45 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA02369 for ; Sun, 9 Feb 1997 18:46:39 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id NAA25217; Mon, 10 Feb 1997 13:49:37 +1100 (EST) Date: Mon, 10 Feb 1997 13:49:36 +1100 (EST) From: "Daniel O'Callaghan" To: hackers@freebsd.org Subject: ipfw command line - opinions wanted. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I was about to commit patches to ipfw.c to add a '-q' (quiet) option. This will prevent the "Flushed all rules" message from appearing, but in its present version still presents the question "Are you sure?" if the '-f' flag is not present. Question: Should '-q' imply '-f' and prevent the "Are you sure?" prompt on a flush? Thanks, Danny From owner-freebsd-hackers Sun Feb 9 18:58:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA02852 for hackers-outgoing; Sun, 9 Feb 1997 18:58:04 -0800 (PST) Received: from darkstar (ras614.srv.net [205.180.127.114]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA02847 for ; Sun, 9 Feb 1997 18:57:58 -0800 (PST) Received: (from cmott@localhost) by darkstar (8.6.12/8.6.12) id TAA03868; Sun, 9 Feb 1997 19:57:41 -0700 Date: Sun, 9 Feb 1997 19:57:39 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar To: Jamie Bowden cc: freebsd-hackers@freebsd.org Subject: Re: Bus Errors In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Feb 1997, Jamie Bowden wrote: > On Sun, 9 Feb 1997, Charles Mott wrote: > > > What does "Bus error" mean? > > > > Amazingly enough, a buss error is a memory allocation error. At least it > was under SunOS. I am guessing FreeBSD is the same on this. > > Jamie Bowden > > Network Administrator, TBI Ltd. I've seen it a few times with the ppp+pktAlias1.9. It doesn't appear to be getting malloc() errors, though. I see the problem with an ISP connection that is really unreliable. Is anyone working on lqr for ppp? Is this type of post too off-target for -hackers? From owner-freebsd-hackers Sun Feb 9 19:32:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA04307 for hackers-outgoing; Sun, 9 Feb 1997 19:32:59 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA04301 for ; Sun, 9 Feb 1997 19:32:51 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id UAA08115; Sun, 9 Feb 1997 20:32:39 -0700 (MST) Date: Sun, 9 Feb 1997 20:32:39 -0700 (MST) Message-Id: <199702100332.UAA08115@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Daniel O'Callaghan" Cc: hackers@freebsd.org Subject: Re: ipfw command line - opinions wanted. In-Reply-To: References: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I was about to commit patches to ipfw.c to add a '-q' (quiet) option. > This will prevent the "Flushed all rules" message from appearing, but in > its present version still presents the question "Are you sure?" if the > '-f' flag is not present. > > Question: Should '-q' imply '-f' and prevent the "Are you sure?" prompt > on a flush? Yes. From owner-freebsd-hackers Sun Feb 9 20:10:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA05908 for hackers-outgoing; Sun, 9 Feb 1997 20:10:25 -0800 (PST) Received: from icicle.winternet.com (adm@icicle.winternet.com [198.174.169.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA05841; Sun, 9 Feb 1997 20:10:01 -0800 (PST) Received: (from adm@localhost) by icicle.winternet.com (8.7.5/8.7.5) id WAA16268; Sun, 9 Feb 1997 22:09:48 -0600 (CST) Posted-Date: Sun, 9 Feb 1997 22:09:48 -0600 (CST) Received: from chaos.ecpnet.com(204.246.64.13) by icicle.winternet.com via smap (V2.0beta) id xma016228; Sun, 9 Feb 97 22:09:26 -0600 Received: from localhost (raistlin@localhost) by chaos.ecpnet.com (8.8.5/8.8.3) with SMTP id WAA02546; Sun, 9 Feb 1997 22:12:23 -0600 (CST) Date: Sun, 9 Feb 1997 22:12:22 -0600 (CST) From: Justen Stepka To: David Nugent cc: Zach Heilig , Leonard Chua , freebsd-bugs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: moused and X11R6 In-Reply-To: <19970208165555.12961@usn.blaze.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > /dev/cuaa0 -> moused > | > /dev/mouse > | > +-- vidcontrol > | > +-- xfree This config didn't work for me, I have tried the reverse version also. This kernel/system is 3.0-Current. Justen Stepka raistlin@ecpnet.com From owner-freebsd-hackers Sun Feb 9 22:21:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA10278 for hackers-outgoing; Sun, 9 Feb 1997 22:21:48 -0800 (PST) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA10258 for ; Sun, 9 Feb 1997 22:21:38 -0800 (PST) Received: (from davidn@localhost) by labs.usn.blaze.net.au (8.8.5/8.8.5) id RAA01170; Mon, 10 Feb 1997 17:20:06 +1100 (EST) Message-ID: <19970210172005.37792@usn.blaze.net.au> Date: Mon, 10 Feb 1997 17:20:05 +1100 From: David Nugent To: Justen Stepka Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: moused and X11R6 References: <19970208165555.12961@usn.blaze.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61 In-Reply-To: ; from Justen Stepka on Feb 02, 1997 at 10:12:22PM Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Feb 02, 1997 at 10:12:22PM, Justen Stepka wrote: > > /dev/cuaa0 -> moused > > | > > /dev/mouse > > | > > +-- vidcontrol > > | > > +-- xfree > > > This config didn't work for me, I have tried the reverse version also. > This kernel/system is 3.0-Current. Try '/dev/sysmouse' instead of '/dev/mouse' and see how you go. If that doesn't work, quote the relevent lines from /etc/sysconfig and /etc/XF86Config. Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-hackers Sun Feb 9 22:43:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA12042 for hackers-outgoing; Sun, 9 Feb 1997 22:43:00 -0800 (PST) Received: from obie.softweyr.ml.org ([199.104.124.49]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA12035 for ; Sun, 9 Feb 1997 22:42:53 -0800 (PST) Received: (from wes@localhost) by obie.softweyr.ml.org (8.7.5/8.6.12) id XAA06827; Sun, 9 Feb 1997 23:46:11 -0700 (MST) Date: Sun, 9 Feb 1997 23:46:11 -0700 (MST) Message-Id: <199702100646.XAA06827@obie.softweyr.ml.org> From: Wes Peters To: hackers@freebsd.org Subject: 'nologin' program for disabling user accounts Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A few days ago a user on the -questions mailing list was asking for a secure way to disable a user account. I once wrote a simple program to do this years ago as a part of Security Toolkit, so I stirred the old grey matter a little bit and put this together for him. Since others may want to do this as well, I'm sending it to the hackers forum for nitpicking and consideration to be included in the next release(s). The purpose of the program is to provide a login shell that simply logs the attempted access and exits, leaving the user with no system access. This program is provided under a bsd-like copyright. Please feel free to use as you wish, as long as the copyright is obeyed. ~~~~~~~~~~ nologin.c ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /* * nologin.c - a login shell for disabling users. * * Copyright (c) 1997 Softweyr LLC, South Jordan, Utah USA. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * * This product includes software developed by Softweyr LLC * * 4. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * This software is provided by Softweyr LLC ``as is'' and any express or * implied warranties, including, but not limited to, the implied warranties * of merchantability and fitness for a particular purpose are disclaimed. * In no event shall Softweyr LLC or any contributors be liable for any * direct, indirect, incidental, special, exemplary, or consequential * damages (including, but not limited to, procurement of substitute goods * or services; loss of use, data, or profits; or business interruption) * however caused and on any theory of liability, whether in contract, * strict liability, or tort (including negligence or otherwise) arising in * any way out of the use of this software, even if advised of the * possibility of such damage. * * Author: Wes Peters * Date: Tue Jan 28 21:30:06 MST 1997 */ #include #include #include int main(int argc, char *argv[]) { char *user, *device; if ((user = getlogin()) == NULL) user = "UNKNOWN"; if ((device = ttyname(0)) == NULL) device = "UNKNOWN"; openlog("nologin", LOG_CONS, LOG_AUTH); syslog(LOG_CRIT, "%s on %s", user, device); closelog(); return 0; } ~~~~~~~~~~ nologin.1 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" nologin.1 - a login shell for disabling users. .\" .\" Copyright (c) 1997 Softweyr LLC, South Jordan, Utah USA. .\" All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" .\" 3. All advertising materials mentioning features or use of this software .\" must display the following acknowledgement: .\" .\" This product includes software developed by Softweyr LLC .\" .\" 4. Neither the name of the University nor the names of its contributors .\" may be used to endorse or promote products derived from this software .\" without specific prior written permission. .\" .\" This software is provided by Softweyr LLC ``as is'' and any express or .\" implied warranties, including, but not limited to, the implied warranties .\" of merchantability and fitness for a particular purpose are disclaimed. .\" In no event shall Softweyr LLC or any contributors be liable for any .\" direct, indirect, incidental, special, exemplary, or consequential .\" damages (including, but not limited to, procurement of substitute goods .\" or services; loss of use, data, or profits; or business interruption) .\" however caused and on any theory of liability, whether in contract, .\" strict liability, or tort (including negligence or otherwise) arising in .\" any way out of the use of this software, even if advised of the .\" possibility of such damage. .\" .\" Author: Wes Peters .\" Date: Tue Jan 28 21:30:06 MST 1997 .Dd January 28, 1997 .Dt nologin 1 .Os BSD 4 .Sh NAME .Nm nologin .Nd a login shell for disabled users .Sh SYNOPSIS .Nm nologin .Sh DESCRIPTION .Nm nologin is a login shell for user accounts that have been disabled. It logs the attempted login via the syslog 3 mechanism, with an .Ar ident of "nologin" and a .Ar facility of .Dv LOG_AUTH . Log entries will appear in the system log as: .Dl Jan 28 21:36:54 hostname nologin: user on /dev/ttypX .Pp Please note that you should .Em not add the .Nm nologin program to the .Pa /etc/shells file, as you do not want users to accidentally set their shell to .Nm nologin. .Sh AUTHOR Wes Peters, Softweyr LLC: softweyr@xmission.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If somebody decides to incorporate this into a FreeBSD release, I'd like an email to confirm this (just for posterity). If, on the other hand, somebody comes up with a glaring hole in this, I'd certainly like to hear about it. I've never encountered any really bloody hangs in syslog or anything like that, but am perfectly willing to believe they could happen. I believe the original started off by closing stdin, stdout, and stderr, but I don't remember the reasoning why. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com From owner-freebsd-hackers Sun Feb 9 22:54:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA13571 for hackers-outgoing; Sun, 9 Feb 1997 22:54:32 -0800 (PST) Received: from www.trifecta.com (www.trifecta.com [206.245.150.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA13559 for ; Sun, 9 Feb 1997 22:54:24 -0800 (PST) Received: (from dev@localhost) by www.trifecta.com (8.7.5/8.6.12) id BAA04771; Mon, 10 Feb 1997 01:55:29 -0500 (EST) Date: Mon, 10 Feb 1997 01:55:29 -0500 (EST) From: Dev Chanchani To: Charles Mott cc: freebsd-hackers@freebsd.org Subject: Re: Bus Errors In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk You will usually get segmentation faults when you try to reference memory you are not allowed to (eg. trying to follow a pointer with an invalid address). The bus error usually occurs when you try to return from a function to an invalid address (usually meaing you clobbered your saved stack pointer).. On Sun, 9 Feb 1997, Charles Mott wrote: > What does "Bus error" mean? > From owner-freebsd-hackers Sun Feb 9 23:07:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA14641 for hackers-outgoing; Sun, 9 Feb 1997 23:07:52 -0800 (PST) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id XAA14632 for ; Sun, 9 Feb 1997 23:07:45 -0800 (PST) Received: from misery.sdf.com [204.244.213.33] by misery.sdf.com with smtp (Exim 1.59 #1) id 0vti5Y-0000eR-00; Sun, 9 Feb 1997 14:51:12 -0800 Date: Sun, 9 Feb 1997 14:51:12 -0800 (PST) From: Tom Samplonius To: Wes Peters cc: hackers@freebsd.org Subject: Re: 'nologin' program for disabling user accounts In-Reply-To: <199702100646.XAA06827@obie.softweyr.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Feb 1997, Wes Peters wrote: > A few days ago a user on the -questions mailing list was asking for a > secure way to disable a user account. I once wrote a simple program to > do this years ago as a part of Security Toolkit, so I stirred the old > grey matter a little bit and put this together for him. Since others > may want to do this as well, I'm sending it to the hackers forum for > nitpicking and consideration to be included in the next release(s). Why? It seems that all BSD4.4 systems already have a nologin. See "man nologin" Tom From owner-freebsd-hackers Mon Feb 10 00:05:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA17212 for hackers-outgoing; Mon, 10 Feb 1997 00:05:16 -0800 (PST) Received: from bofh.cybercity.dk (bofh.cybercity.dk [195.8.128.254]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA17177; Mon, 10 Feb 1997 00:05:03 -0800 (PST) Received: from critter.dk.tfs.com ([140.145.230.252]) by bofh.cybercity.dk (8.8.3/8.7.3) with ESMTP id JAA14962; Mon, 10 Feb 1997 09:06:53 +0100 (MET) Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.2/8.8.2) with ESMTP id IAA11992; Mon, 10 Feb 1997 08:47:40 +0100 (MET) To: Thomas David Rivers cc: dg@root.com, hackers@freebsd.org, joerg@freebsd.org Subject: Re: daily panics, ffs_valloc: dup alloc - Good news! In-reply-to: Your message of "Sun, 09 Feb 1997 13:53:34 EST." <199702091853.NAA24339@lakes.water.net> Date: Mon, 10 Feb 1997 08:47:39 +0100 Message-ID: <11990.855560859@critter.dk.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199702091853.NAA24339@lakes.water.net>, Thomas David Rivers writes: > >I built a new "newfs", with NTRACKS bumped to 2 and NSECTORS dropped >to 2048. > >It worked like a champ! No more panic: ffs_valloc: dup alloc. > >I'd say the problem is that the underlying code can't handle one >track (head). > >We should probably go ahead and use this work-around in 2.1.7 and >2.2. Perhaps, if we're so inclined, we can determine what a >better fix would be to keep the 1 track idea. [It could possibly >be simply setting fs->fs_cgmask to 0 if the number of tracks is 1; but >I'm not sure.] That investigation could wait until after 2.2 and >2.1.7. I've looked at the code, and I cannot see how it could be because of fs_cgmask being 0xffffffff. There must be some other explanation. Do you have the first couple of hundred lines from a dumpfs on the filesystem (when made with heads=1 ?) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-hackers Mon Feb 10 00:50:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA19439 for hackers-outgoing; Mon, 10 Feb 1997 00:50:41 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA19434 for ; Mon, 10 Feb 1997 00:50:38 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA11670 for freebsd-hackers@freebsd.org; Mon, 10 Feb 1997 09:50:35 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id JAA18664; Mon, 10 Feb 1997 09:29:05 +0100 (MET) Message-ID: Date: Mon, 10 Feb 1997 09:29:04 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Re: Copious information on panic: ffs_valloc: dup alloc - IDEAS??? References: <199702091818.NAA23739@lakes.water.net> <32FE7015.2F1CF0FB@whistle.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <32FE7015.2F1CF0FB@whistle.com>; from Julian Elischer on Feb 9, 1997 16:47:17 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Julian Elischer wrote: > if you make it have 2 heads, this code will be enabled > again and we'll lose the effect.. > you could HEAR the difference when we went to 1 head.. But unfortunately, you could also _see_ the panics afterwards. :-( Go and re-read Thomas's original article. It's not simply summarizable in three sentences, sorry. The only summary is this: ntracks == 1 causes cgmask = 0xffffffff. The latter seems to cause block miscalculations in the filesystem code. As for the exact chain of miscalculations, refer to Message-ID <199702090226.VAA22081@lakes.water.net>. If you need something to prove this, setup a small MFS, and beat upon it. I can send you my ``mount /dev/null for MFS'' patches, or maybe, i simply commit them. They are basically required anyway to create a MFS on a diskless station (where you don't have a swap partition to template the MFS parameters from). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Feb 10 00:52:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA19561 for hackers-outgoing; Mon, 10 Feb 1997 00:52:07 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA19555 for ; Mon, 10 Feb 1997 00:52:03 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA11692 for freebsd-hackers@freebsd.org; Mon, 10 Feb 1997 09:52:01 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id JAA18724; Mon, 10 Feb 1997 09:41:31 +0100 (MET) Message-ID: Date: Mon, 10 Feb 1997 09:41:31 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Fwd: daily insecurity output X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Btw., running /usr/bin/login manually causes enough traces in the logs. :-) -----Forwarded message from root (Charlie Root)----- From: Charlie Root Subject: daily insecurity output checking auth info: Feb 9 12:23:46 uriah login: login on ttyp2 as j -----End of forwarded message----- Sure, there's no hostname mentioned, but since you can't login on a pty without either getting there from a remote host, or from a previous session, that should be simple to track. I don't think it's a major security issue. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Feb 10 00:52:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA19595 for hackers-outgoing; Mon, 10 Feb 1997 00:52:52 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA19589 for ; Mon, 10 Feb 1997 00:52:48 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA11694; Mon, 10 Feb 1997 09:52:06 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id JAA18736; Mon, 10 Feb 1997 09:46:22 +0100 (MET) Message-ID: Date: Mon, 10 Feb 1997 09:46:22 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: cmott@srv.net (Charles Mott) Cc: freebsd-hackers@freebsd.org Subject: Re: Bus Errors References: X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Charles Mott on Feb 9, 1997 17:48:27 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Charles Mott wrote: > What does "Bus error" mean? UTSL :-) Various possible reasons. What quickly comes to mind are various access violations, like trying to do direct port IO from an unprivileged program, or messing up the (uh!) segment registers so you get a GPF. Also, there's something with access violations on a mapped region vs. touching unmapped memory, that is currently differentiated between SIGBUS vs. SIGSEGV. We've been recently discussing this (in -core) since it confuses our Linuxulator, and is also inconsisten with other systems. It's likely that somebody will be changed there in the future. I think an unaligned access on a 486+ with the AC flag set causes a SIGBUS, too. On the PDP-11, unaligned access and access to bus addresses that were not existent (and thus timed out in the bus controller) were the original reasons for a SIGBUS. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Feb 10 01:11:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA20409 for hackers-outgoing; Mon, 10 Feb 1997 01:11:43 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA20299 for ; Mon, 10 Feb 1997 01:08:41 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA11944; Mon, 10 Feb 1997 10:07:10 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id JAA18909; Mon, 10 Feb 1997 09:59:33 +0100 (MET) Message-ID: Date: Mon, 10 Feb 1997 09:59:33 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: cmott@srv.net (Charles Mott) Cc: jamie@inna.net (Jamie Bowden), freebsd-hackers@FreeBSD.ORG Subject: Re: Bus Errors References: X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Charles Mott on Feb 9, 1997 19:57:39 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Charles Mott wrote: > Is this type of post too off-target for -hackers? Not at all! -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Feb 10 01:13:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA20547 for hackers-outgoing; Mon, 10 Feb 1997 01:13:18 -0800 (PST) Received: from news.IAEhv.nl (root@news.IAEhv.nl [194.151.64.4]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA20514 for ; Mon, 10 Feb 1997 01:12:51 -0800 (PST) Received: from truk.brandinnovators.com (uucp@localhost) by news.IAEhv.nl (8.6.13/1.63) with IAEhv.nl; pid 9408 on Mon, 10 Feb 1997 10:11:59 +0100; id KAA09408 efrom: hans@truk.brandinnovators.com; eto: UNKNOWN Received: by truk.brandinnovators.com (8.7.5/BI96070101) for <> id JAA22878; Mon, 10 Feb 1997 09:48:16 +0100 (MET) Message-Id: <199702100848.JAA22878@truk.brandinnovators.com> From: hans@brandinnovators.com (Hans Zuidam) Subject: Re: Bus Errors To: freebsd-hackers@freebsd.org Date: Mon, 10 Feb 1997 09:48:15 +0100 (MET) Cc: cmott@srv.net In-Reply-To: from Jamie Bowden at "Feb 9, 97 08:31:00 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Jamie Bowden wrote: > On Sun, 9 Feb 1997, Charles Mott wrote: > > > What does "Bus error" mean? > Amazingly enough, a buss error is a memory allocation error. At least it > was under SunOS. I am guessing FreeBSD is the same on this. The term "Bus error" originated from the Motorola M68K where this is a signal line which is raised when the CPU tries to access (for example) unaligned data. The early Suns (Sun/2, Sun/3) were M68K based machines. Custom had it that you would shout "buzz, buzz!" when one would happen :-) Hans -- H. Zuidam E-Mail: hans@brandinnovators.com Brand Innovators B.V. P-Mail: P.O. Box 1377 de Pinckart 54 5602 BJ Eindhoven, The Netherlands 5674 CC Nuenen Tel. +31 40 2631134, Fax. +31 40 2831138 From owner-freebsd-hackers Mon Feb 10 04:27:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA29775 for hackers-outgoing; Mon, 10 Feb 1997 04:27:25 -0800 (PST) Received: from kremvax.demos.su (kremvax.demos.su [194.87.0.20]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id EAA29768 for ; Mon, 10 Feb 1997 04:27:19 -0800 (PST) Received: by kremvax.demos.su (8.6.13/D) from 0@sinbin.demos.su [194.87.2.95] with ESMTP id PAA02534; Mon, 10 Feb 1997 15:26:06 +0300 Received: by sinbin.demos.su id PAA27484; (8.6.12/D) Mon, 10 Feb 1997 15:25:17 +0300 From: bag@sinbin.demos.su (Alex G. Bulushev) Message-Id: <199702101225.PAA27484@sinbin.demos.su> Subject: Re: ipip for FreeBSD To: andrew@why.whine.com (Andrew Herdman) Date: Mon, 10 Feb 1997 15:25:17 +0300 (MSK) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "Andrew Herdman" at Feb 7, 97 10:55:34 pm X-Mailer: ELM [version 2.4 PL24 ME7a] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > this is port from bsd to linux with original ... > > it works fine, i test it under fbsd 2.1.0 & 2.1.5 between two PC > > and between PC and cisco ... > > > > Alex. > > > > I grabbed this package and have found the documentation sparse. I am > trying to build a tunnel between my freebsd box and a cisco router. I've > spent a lot of time building ipip tunnels between cisco routers, but for > the life of me cannot figure out what to do with the ipip program to get > one working. I have the tun drivers installed in my kernel. > > Any suggestions would be appreciated. u need tunnel type NOS compatible on cisco router ... Alex. > > Thanks > Andrew > > > From owner-freebsd-hackers Mon Feb 10 05:20:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA01952 for hackers-outgoing; Mon, 10 Feb 1997 05:20:47 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA01942 for ; Mon, 10 Feb 1997 05:20:41 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA24673; Mon, 10 Feb 1997 08:20:04 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 10 Feb 1997 08:20 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id HAA29942; Mon, 10 Feb 1997 07:35:56 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id HAA25989; Mon, 10 Feb 1997 07:40:22 -0500 (EST) Date: Mon, 10 Feb 1997 07:40:22 -0500 (EST) From: Thomas David Rivers Message-Id: <199702101240.HAA25989@lakes.water.net> To: ponds!uriah.heep.sax.de!joerg_wunsch, ponds!whistle.com!julian Subject: Re: Copious information on panic: ffs_valloc: dup alloc - IDEAS??? Cc: ponds!freebsd.org!freebsd-hackers, ponds!lakes.water.net!rivers Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Julian Elischer wrote: > > J Wunsch wrote: > > > > As Thomas David Rivers wrote: > > > > > You're saying the code in newfs.c that sets NTRACKS to 1 and > > > NSECTORS to 4096 would be changed. > > > > Yes, to e.g. 2 * 2048 instead. It's a mileage number only anyway, > > since Poul found out (experimentally) that it just works better than > > any (un)real number on today's zone-bit recorded and large cache > > disks. > > > > > If this is so, doesn't that mean that everyone is using a file system > > > that is questionable. Aren't inode reads/writes going to the wrong > > > places (albeit consistently?) > > > > I'm no filesystem expert at all, but this seems to be the case. The > > failure picture matches consistently with the reported MFS troubles > > (including mine), and it's probably also responsible for some other > > panic PRs you could find in the GNATS database. > > > > -- > > > Kirk suggested setting the number of heads to 1 to > turn off the "selelct a nearby head" code.. > > if you make it have 2 heads, this code will be enabled > again and we'll lose the effect.. > it pessimise the accesses by switching to a differnt head that it > thinks has a nearby free block.. in the case of 2 heads (as suggested) > this is actually likely to be "NOT NEARBY" and we will lose > > you could HEAR the difference when we went to 1 head.. > > Hmmm... well, that's certainly not the best news. But I would assert that the file system isn't working properly without this problem corrected. An alternative I was considering was to set the file system's fs_cgmask to 0 if the number of tracks is 1. (Instead of it's current, problematic 0xffffffff). But, it's just a guess from my point of view; I'm no filesystem expert. I'll try that out and report back. If that works, then we can return to having NTRACKS be 1. - Dave Rivers - From owner-freebsd-hackers Mon Feb 10 05:21:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA01977 for hackers-outgoing; Mon, 10 Feb 1997 05:21:01 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA01951 for ; Mon, 10 Feb 1997 05:20:46 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA24719; Mon, 10 Feb 1997 08:20:08 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 10 Feb 1997 08:20 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id HAA00407; Mon, 10 Feb 1997 07:46:03 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id HAA26033; Mon, 10 Feb 1997 07:50:29 -0500 (EST) Date: Mon, 10 Feb 1997 07:50:29 -0500 (EST) From: Thomas David Rivers Message-Id: <199702101250.HAA26033@lakes.water.net> To: ponds!critter.dk.tfs.com!phk Subject: Re: daily panics, ffs_valloc: dup alloc - Good news! Cc: ponds!root.com!dg, ponds!freebsd.org!hackers, ponds!freebsd.org!joerg Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp > > In message <199702091853.NAA24339@lakes.water.net>, Thomas David Rivers writes: > > > >I built a new "newfs", with NTRACKS bumped to 2 and NSECTORS dropped > >to 2048. > > > >It worked like a champ! No more panic: ffs_valloc: dup alloc. > > > >I'd say the problem is that the underlying code can't handle one > >track (head). > > > >We should probably go ahead and use this work-around in 2.1.7 and > >2.2. Perhaps, if we're so inclined, we can determine what a > >better fix would be to keep the 1 track idea. [It could possibly > >be simply setting fs->fs_cgmask to 0 if the number of tracks is 1; but > >I'm not sure.] That investigation could wait until after 2.2 and > >2.1.7. > > I've looked at the code, and I cannot see how it could be because > of fs_cgmask being 0xffffffff. > > There must be some other explanation. > > Do you have the first couple of hundred lines from a dumpfs on the > filesystem (when made with heads=1 ?) > I'll try getting it with a fixit floppy. But, if you'll read my previous writeup; you'll see that a fs_cgmask of 0xffffffff causes a problem in the cgstart macro: #define cgstart(fs, c) \ (cgbase(fs, c) + (fs)->fs_cgoffset * ((c) & ~((fs)->fs_cgmask))) effectively eliminating the fs_cgoffset value. This is what we're guessing is the problem. > -- > Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. From owner-freebsd-hackers Mon Feb 10 05:21:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA02003 for hackers-outgoing; Mon, 10 Feb 1997 05:21:17 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA01945 for ; Mon, 10 Feb 1997 05:20:43 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA24702; Mon, 10 Feb 1997 08:20:07 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 10 Feb 1997 08:20 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id HAA00236; Mon, 10 Feb 1997 07:41:07 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id HAA26005; Mon, 10 Feb 1997 07:45:34 -0500 (EST) Date: Mon, 10 Feb 1997 07:45:34 -0500 (EST) From: Thomas David Rivers Message-Id: <199702101245.HAA26005@lakes.water.net> To: ponds!uriah.heep.sax.de!joerg_wunsch, ponds!whistle.com!julian Subject: Re: daily panics, ffs_valloc: dup alloc - Good news! Cc: ponds!freebsd.org!freebsd-hackers, ponds!lakes.water.net!rivers Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > J Wunsch wrote: > > > > As Thomas David Rivers wrote: > > > > > As I said before; I would test our Joerg's supposition. I'm happy to > > > report it seems to be right on the money! (Good work!) > > > can you guys explain the problem in a couple of sinple sentences? > Sure; The code in newfs; when the number of tracks is set to 1; sets the fs_cgmask to 0xffffffff. Later in ffs_valloc.c:ffs_vget (and other places) that value is logically negated, and anded with another value in the physical block offset calculation. Since 0xffffffff negated is 0, and that anded with anything is 0; it has the effect of eliminating some of the computation. Thus, physical block offset offset calculation to read blocks of the file system actually are incorrect. The incorrect block can sometimes have other information; causing panic's; etc... My previous mail details the ffs: dup alloc panic problem, in that the inode is allocated. Then, a incorrect block is read from the disk; causing the panic. This appears to happen on rather full file systems (since the probability of reading a different/allocated inode block increases) and when dealing with inodes that are close to the inode-per-group boundary. - Dave Rivers - From owner-freebsd-hackers Mon Feb 10 05:26:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA02251 for hackers-outgoing; Mon, 10 Feb 1997 05:26:16 -0800 (PST) Received: from bofh.cybercity.dk (bofh.cybercity.dk [195.8.128.254]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA02246; Mon, 10 Feb 1997 05:26:08 -0800 (PST) Received: from critter.dk.tfs.com ([140.145.230.252]) by bofh.cybercity.dk (8.8.3/8.7.3) with ESMTP id OAA02888; Mon, 10 Feb 1997 14:28:18 +0100 (MET) Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.2/8.8.2) with ESMTP id OAA12737; Mon, 10 Feb 1997 14:28:06 +0100 (MET) To: Thomas David Rivers cc: dg@freebsd.org, hackers@freebsd.org, joerg@freebsd.org Subject: Re: daily panics, ffs_valloc: dup alloc - Good news! In-reply-to: Your message of "Mon, 10 Feb 1997 07:50:29 EST." <199702101250.HAA26033@lakes.water.net> Date: Mon, 10 Feb 1997 14:28:06 +0100 Message-ID: <12735.855581286@critter.dk.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I'll try getting it with a fixit floppy. please, it's rather crucial for debugging this. > But, if you'll read my previous writeup; you'll see that a fs_cgmask >of 0xffffffff causes a problem in the cgstart macro: > >#define cgstart(fs, c) \ > (cgbase(fs, c) + (fs)->fs_cgoffset * ((c) & ~((fs)->fs_cgmask))) > >effectively eliminating the fs_cgoffset value. This is what we're >guessing is the problem. The cgoffset is only there to make sure that all of the superblock copies are not on the same head. Since we only have one head that field (correctly) doesn't apply. I must admit that I don't really know what to look for, but if I get the data on the filesystem, at least I can start to dig through the code looking for trouble. I'm actually thinking about making a version of ufs that has all this head/track/sector knowledge pulled out, it really obfuscates the code a lot. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-hackers Mon Feb 10 05:48:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA03312 for hackers-outgoing; Mon, 10 Feb 1997 05:48:28 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA03227 for ; Mon, 10 Feb 1997 05:47:38 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id OAA25403; Mon, 10 Feb 1997 14:46:03 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id OAA12169; Mon, 10 Feb 1997 14:36:21 +0100 (MET) Message-Id: <3.0.32.19970210143621.00b00c10@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 10 Feb 1997 14:36:23 +0100 To: Charles Mott From: Eivind Eklund Subject: Re: Bus Errors Cc: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 07:57 PM 2/9/97 -0700, you wrote: >On Sun, 9 Feb 1997, Jamie Bowden wrote: > >> On Sun, 9 Feb 1997, Charles Mott wrote: >> >> > What does "Bus error" mean? A 'bus error' is when a CPU tries to access something that is outside the bus specs. This usually involve some sort of illegal address; eg, on 68000 and 68010 processors, accessing a word or long (16- or 32-bit value) on an odd address could cause this. Under FreeBSD, I don't know what would cause this instead of a segmentation fault - the 486 (at least) hasn't got any such thing as a bus error. I would guess a stack overrun somewhere causing very very wrong code to be executed. >> Amazingly enough, a buss error is a memory allocation error. At least it >> was under SunOS. I am guessing FreeBSD is the same on this. >> >> Jamie Bowden > >I've seen it a few times with the ppp+pktAlias1.9. It doesn't appear to >be getting malloc() errors, though. I see the problem with an ISP >connection that is really unreliable. Is anyone working on lqr for ppp? I haven't been having any problems with the 1.9 version at all. I'm running with all extra options turned off, though - no use_sockets, no same_ports. Could you give me a core dump of this (you'll have to run the program as root, turning the setuid bit off, otherwise it won't dump core) with the corresponding executable (compiled with -g, and not stripped)? >Is this type of post too off-target for -hackers? Well, usually people like to get some more information right away, as that make it easier to give specific help at once. Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/ eivind@freebsd.org From owner-freebsd-hackers Mon Feb 10 06:02:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA03930 for hackers-outgoing; Mon, 10 Feb 1997 06:02:47 -0800 (PST) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA03921 for ; Mon, 10 Feb 1997 06:02:44 -0800 (PST) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id PAA18750 for ; Mon, 10 Feb 1997 15:03:02 +0100 (MET) Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.8.4/8.6.9) id PAA18523 for freebsd-hackers@freefall.cdrom.com; Mon, 10 Feb 1997 15:06:16 +0100 (MET) Date: Mon, 10 Feb 1997 15:06:16 +0100 (MET) From: Christoph Kukulies Message-Id: <199702101406.PAA18523@gilberto.physik.rwth-aachen.de> To: freebsd-hackers@freefall.FreeBSD.org Subject: Freewin95 - just fyi Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Don't know whether I should smile or whine upon this, but maybe someone could tell this whiz that the grounds are laid already :-) http://www.geocities.com/SiliconValley/7519/ --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Mon Feb 10 07:12:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA06303 for hackers-outgoing; Mon, 10 Feb 1997 07:12:18 -0800 (PST) Received: from ami.tom.computerworks.net (root@AMI.RES.CMU.EDU [128.2.95.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA06298 for ; Mon, 10 Feb 1997 07:12:14 -0800 (PST) Received: from bonkers.taronga.com by ami.tom.computerworks.net with smtp (Smail3.1.29.1 #1) id m0vtxOs-0021nkC; Mon, 10 Feb 97 10:12 EST Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id JAA11752; Mon, 10 Feb 1997 09:01:31 -0600 Date: Mon, 10 Feb 1997 09:01:31 -0600 From: peter@taronga.com (Peter da Silva) Message-Id: <199702101501.JAA11752@bonkers.taronga.com> To: hackers@freebsd.org Subject: Re: number of lines in a file, given its size Newsgroups: taronga.freebsd.hackers In-Reply-To: <199701122149.OAA26408@phaeton.artisoft.com> References: Organization: none Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hey, I've got a really hoopy idea. Many years ago I wrote a safe mkargv() function, that takes a string and returns a pointer to an argv list based on the string, dynamically allocating and reallocating the list as it grows, using any terminator you want. How about I donate it, and a bunch of similar routines, to FreeBSD. Let me dig it up and prettify it. It's just what the doctor ordered. From owner-freebsd-hackers Mon Feb 10 07:20:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA06766 for hackers-outgoing; Mon, 10 Feb 1997 07:20:47 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA06751 for ; Mon, 10 Feb 1997 07:20:36 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA03056; Mon, 10 Feb 1997 10:20:04 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 10 Feb 1997 10:20 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id JAA05644; Mon, 10 Feb 1997 09:59:50 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id KAA26752; Mon, 10 Feb 1997 10:04:17 -0500 (EST) Date: Mon, 10 Feb 1997 10:04:17 -0500 (EST) From: Thomas David Rivers Message-Id: <199702101504.KAA26752@lakes.water.net> To: ponds!critter.dk.tfs.com!phk, ponds!lakes.water.net!rivers Subject: Re: daily panics, ffs_valloc: dup alloc - Good news! Cc: ponds!freebsd.org!dg, ponds!freebsd.org!hackers, ponds!freebsd.org!joerg Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > I'll try getting it with a fixit floppy. > > please, it's rather crucial for debugging this. Ok - here you go. I can't really get the file system up-and-running from the boot floppy (with an unaltered newfs); so what I did was: 1) Boot up a fixit floppy. 2) Not altering the partition/disklabel I executed the following: newfs -b 8192 -f 1024 3) Then, I ifconfig'd ed0; grabbed a working dumpfs and go this output. I notice that the cgmask is 0xffffffff; so I _think_ this file system would have the same problems. (ignore the time there; I haven't got the CMOS clock set right.) magic 11954 time Tue Feb 4 18:34:10 1997 cylgrp dynamic inodes 4.4BSD nbfree 12308 ndir 1 nifree 30717 nffree 14 ncg 4 ncyl 50 size 102400 blocks 98479 bsize 8192 shift 13 mask 0xffffe000 fsize 1024 shift 10 mask 0xfffffc00 frag 8 shift 3 fsbtodb 1 cpg 16 bpg 4096 fpg 32768 ipg 7680 minfree 8% optim time maxcontig 7 maxbpg 2048 rotdelay 0ms headswitch 0us trackseek 0us rps 60 ntrak 1 nsect 4096 npsect 4096 spc 4096 symlinklen 60 trackskew 0 interleave 1 contigsumsize 7 nindir 2048 inopb 64 nspf 2 sblkno 16 cblkno 24 iblkno 32 dblkno 992 sbsize 2048 cgsize 6144 cgoffset 2048 cgmask 0xffffffff csaddr 992 cssize 1024 shift 9 mask 0xfffffe00 cgrotor 0 fmod 0 ronly 0 clean 1 (no rotational position table) cs[].cs_(nbfree,ndir,nifree,nffree): (3970,1,7677,14) (3974,0,7680,0) (3974,0,7680,0) (390,0,7680,0) cylinders in last group 2 blocks in last group 512 cg 0: magic 90255 tell 6000 time Tue Feb 4 18:34:10 1997 cgx 0 ncyl 16 niblk 7680 ndblk 32768 nbfree 3970 ndir 1 nifree 7677 nffree 14 rotor 0 irotor 0 frotor 0 frsum 0 0 0 0 0 0 2 sum of frsum: 14 clusters 1-6: 0 0 0 0 0 0 clusters size 7 and over: 1 clusters free: 126-4095 iused: 0-2 free: 993-999, 1001-32767 b: c0: (130) 130 c1: (256) 256 c2: (256) 256 c3: (256) 256 c4: (256) 256 c5: (256) 256 c6: (256) 256 c7: (256) 256 c8: (256) 256 c9: (256) 256 c10: (256) 256 c11: (256) 256 c12: (256) 256 c13: (256) 256 c14: (256) 256 c15: (256) 256 cg 1: magic 90255 tell 2006000 time Tue Feb 4 18:34:10 1997 cgx 1 ncyl 16 niblk 7680 ndblk 32768 nbfree 3974 ndir 0 nifree 7680 nffree 0 rotor 0 irotor 0 frotor 0 frsum 0 0 0 0 0 0 0 sum of frsum: 0 clusters 1-6: 0 1 0 0 0 0 clusters size 7 and over: 1 clusters free: 0-1, 124-4095 iused: free: 0-15, 992-32767 b: c0: (134) 134 c1: (256) 256 c2: (256) 256 c3: (256) 256 c4: (256) 256 c5: (256) 256 c6: (256) 256 c7: (256) 256 c8: (256) 256 c9: (256) 256 c10: (256) 256 c11: (256) 256 c12: (256) 256 c13: (256) 256 c14: (256) 256 c15: (256) 256 cg 2: magic 90255 tell 4006000 time Tue Feb 4 18:34:10 1997 cgx 2 ncyl 16 niblk 7680 ndblk 32768 nbfree 3974 ndir 0 nifree 7680 nffree 0 rotor 0 irotor 0 frotor 0 frsum 0 0 0 0 0 0 0 sum of frsum: 0 clusters 1-6: 0 1 0 0 0 0 clusters size 7 and over: 1 clusters free: 0-1, 124-4095 iused: free: 0-15, 992-32767 b: c0: (134) 134 c1: (256) 256 c2: (256) 256 c3: (256) 256 c4: (256) 256 c5: (256) 256 c6: (256) 256 c7: (256) 256 c8: (256) 256 c9: (256) 256 c10: (256) 256 c11: (256) 256 c12: (256) 256 c13: (256) 256 c14: (256) 256 c15: (256) 256 cg 3: magic 90255 tell 6006000 time Tue Feb 4 18:34:10 1997 cgx 3 ncyl 2 niblk 7680 ndblk 4096 nbfree 390 ndir 0 nifree 7680 nffree 0 rotor 0 irotor 0 frotor 0 frsum 0 0 0 0 0 0 0 sum of frsum: 0 clusters 1-6: 0 1 0 0 0 0 clusters size 7 and over: 1 clusters free: 0-1, 124-511 iused: free: 0-15, 992-4095 b: c0: (134) 134 c1: (256) 256 From owner-freebsd-hackers Mon Feb 10 07:30:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA07326 for hackers-outgoing; Mon, 10 Feb 1997 07:30:12 -0800 (PST) Received: from bofh.cybercity.dk (bofh.cybercity.dk [195.8.128.254]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA07279; Mon, 10 Feb 1997 07:29:54 -0800 (PST) Received: from critter.dk.tfs.com ([140.145.230.252]) by bofh.cybercity.dk (8.8.3/8.7.3) with ESMTP id QAA09699; Mon, 10 Feb 1997 16:32:04 +0100 (MET) Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.2/8.8.2) with ESMTP id QAA12981; Mon, 10 Feb 1997 16:31:46 +0100 (MET) To: Thomas David Rivers cc: dg@freebsd.org, hackers@freebsd.org, joerg@freebsd.org Subject: Re: daily panics, ffs_valloc: dup alloc - Good news! In-reply-to: Your message of "Mon, 10 Feb 1997 10:04:17 EST." <199702101504.KAA26752@lakes.water.net> Date: Mon, 10 Feb 1997 16:31:45 +0100 Message-ID: <12979.855588705@critter.dk.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199702101504.KAA26752@lakes.water.net>, Thomas David Rivers writes: >> >> > I'll try getting it with a fixit floppy. >> >> please, it's rather crucial for debugging this. > > > Ok - here you go. Thanks a lot. > 3) Then, I ifconfig'd ed0; grabbed a working dumpfs and > go this output. > I notice that the cgmask is 0xffffffff; so I _think_ > this file system would have the same problems. > (ignore the time there; I haven't got the CMOS clock set right.) I still can't see how you can possibly have reached the conclusion that cgmask is the cause of this (as oposed to some other magic somewhere in the code)... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-hackers Mon Feb 10 08:14:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA09643 for hackers-outgoing; Mon, 10 Feb 1997 08:14:53 -0800 (PST) Received: from burka.carrier.kiev.ua (snar@burka.carrier.kiev.ua [193.193.193.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA09623 for ; Mon, 10 Feb 1997 08:14:25 -0800 (PST) Received: (from snar@localhost) by burka.carrier.kiev.ua (8.8.4/8.who.cares.1) id SAA08033; Mon, 10 Feb 1997 18:06:23 +0200 (EET) From: Alexander Snarskii Message-Id: <199702101606.SAA08033@burka.carrier.kiev.ua> Subject: Re: Increasing overall security.... To: michaelh@cet.co.jp (Michael Hancock) Date: Mon, 10 Feb 1997 18:06:21 +0200 (EET) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "Michael Hancock" at Feb 10, 97 10:38:07 am Content-type: text/plain; charset=koi8-r X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > On Sun, 9 Feb 1997, Alexander Snarskii wrote: > > > I want to contribute patch to libc to made FreeBSD unexploitable > > with standard 'stack overflow' attacks. > > > > All i wanted, is to made my FreeBSD-based host as secure as possible. > > And i havent found no such man as Theo de Raadt in FreeBSD project, > > so the source tree still contains some exploitable 'stack overflow' > > security holes. Most of which is based on using some 'insecure' > > functions like 'strcpy', 'sprintf' and so in setuid programs. > > Look in the cvs logs for recent commits by imp for example rlogind, rshd, > etc. Well, i saw that changes. But, my reasons to ask to commit these patches is: 1) Any usage of strcpy and so in any program is a 'Bad Thing' (tm). Because if the program is even running with (euid==uid)&&(euid!=0), dumping of they're core is abnormaal situation. Program, which dumps his core because it uses strcpy or so, is not working with all set of paramertres/enviroinment/input and so, so it has some incorrectness inside. 2) Programs, which uses strcpy or so, when running with euid=0 is a 'Worst thing' (tm), because more than 75% of security problems of last year was based on incorrect usage of strcpy or so. 3) Well, rlogind, rshd and so is under FreeBSD team responsibility, his code is checked and have no this problems any more. But, there are so many other programs, which are running as root, and are out from FreeBSD team responsibility. ( sendmail, f.e :) ). And this programs can be used to break into your computer also! Last reason: Look to the /usr/src/lib/libc/stdio/gets.c - you'll see the warning about this function, which are printed everytime, when working programm calls this function first time. -- Alexander Snarskii the source code is included. From owner-freebsd-hackers Mon Feb 10 09:20:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA12913 for hackers-outgoing; Mon, 10 Feb 1997 09:20:31 -0800 (PST) Received: from usr11.primenet.com (root@usr11.primenet.com [206.165.5.111]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA12908 for ; Mon, 10 Feb 1997 09:20:28 -0800 (PST) Received: from primenet.com (root@mailhost01.primenet.com [206.165.5.52]) by usr11.primenet.com (8.8.5/8.8.5) with ESMTP id KAA07772 for ; Mon, 10 Feb 1997 10:20:27 -0700 (MST) Received: from conceptual.com (consys.com [207.218.17.187]) by primenet.com (8.8.5/8.8.5) with ESMTP id KAA15516 for ; Mon, 10 Feb 1997 10:20:19 -0700 (MST) Received: from conceptual.com (localhost [127.0.0.1]) by conceptual.com (8.8.5/8.6.9) with ESMTP id KAA00950 for ; Mon, 10 Feb 1997 10:20:17 -0700 (MST) Message-Id: <199702101720.KAA00950@conceptual.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: hackers@freebsd.org Subject: cool RSA Challenge project, friendly to FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Feb 1997 10:20:17 -0700 From: "Russell L. Carter" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Those that don't mind hosting a possibly innocuous, polite, cpu-cycle parasite might have a look at http://www.ee.ethz.ch/~rsa_clng/ Very comprehensive support for free OSs, including FreeBSD. Cheers, Russell (I have no connection whatsoever to these people) From owner-freebsd-hackers Mon Feb 10 09:50:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA14501 for hackers-outgoing; Mon, 10 Feb 1997 09:50:59 -0800 (PST) Received: from gdi.uoregon.edu (gdi.uoregon.edu [128.223.170.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA14491 for ; Mon, 10 Feb 1997 09:50:51 -0800 (PST) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.5/8.6.12) with SMTP id JAA00221; Mon, 10 Feb 1997 09:50:49 -0800 (PST) Date: Mon, 10 Feb 1997 09:50:49 -0800 (PST) From: Doug White X-Sender: dwhite@localhost Reply-To: Doug White To: hackers@freebsd.org cc: henryt2@ix.netcom.com Subject: BSD216-syscall (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This belongs over here. Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major ---------- Forwarded message ---------- Date: Mon, 10 Feb 1997 00:10:01 -0800 From: Tsang Shing To: freebsd-questions@FreeBSD.ORG Subject: BSD216-syscall Hi, I have a project that using BSD 2.1.6 to implement a syscall. I need to add a new mapping from syscall number to kernel handler function. For instance, I need to map syscall number 151 to a function called foo(). I undestand I need to edit the file, syscall.master line 151, change that line from 151 UNIMPL 0 NOHIDE nosys to: 151 STD 2 BSD semaphore Then I need to run makesyscalls.sh. This generatess syscalls.c. But I don't know how to run the makesyscalls.sh ? Then also , I need to define a syscall handler for this in the kern directory. But I don't know how to do this. Some people told me to look at other syscall handlers(i.e. vfs_syscalls.c) to get some idea of function declaration, but the file is too big, I can't figure out what can I get from other files! Then I need to re-configure and re-make kernel and in the end, after reboot, I can access my syscall with syscall(151,arg1,arg2) If someone knows all those stuff, understand those things, please email me back! Would you also give me an example that the function foo() need to use the args? Also, is that true that those arguments are only for another funtion-- the syscall handler? I just so confused about all these things, please give me one simple example, one simple example of this implementation. Thanks. From owner-freebsd-hackers Mon Feb 10 10:48:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA17411 for hackers-outgoing; Mon, 10 Feb 1997 10:48:00 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA17400 for ; Mon, 10 Feb 1997 10:47:51 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA27053; Mon, 10 Feb 1997 11:42:57 -0700 From: Terry Lambert Message-Id: <199702101842.LAA27053@phaeton.artisoft.com> Subject: Re: DOS partition trouble To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 10 Feb 1997 11:42:57 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: from "J Wunsch" at Feb 10, 97 00:21:59 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > When will we start using LBA's in the boot code, and ignoring the > > C/H/S portion of the partition table? > > You can't, as long you're stuck with a BIOS that wants C/H/S in its > int 0x13 calls. The BIOS-using code can internally translate LBA using the C/H/S geometry if the BIOS only supports C/H/S (the C/H/S geometry is known to the BIOS at this point, allowing it to fall back, if it has to). The interface presented to the BIOS-using code can be generically LBA. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Feb 10 10:50:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA17594 for hackers-outgoing; Mon, 10 Feb 1997 10:50:42 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA17586 for ; Mon, 10 Feb 1997 10:50:34 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA27070; Mon, 10 Feb 1997 11:45:50 -0700 From: Terry Lambert Message-Id: <199702101845.LAA27070@phaeton.artisoft.com> Subject: Re: Bus Errors To: cmott@srv.net (Charles Mott) Date: Mon, 10 Feb 1997 11:45:50 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Charles Mott" at Feb 9, 97 05:48:27 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > What does "Bus error" mean? "The memory bus reference was out of allowable address space" In general, since page 0 is not mapped, it will typically mean that you have dereferenced a null pointer. Probably by relying on the historical behaviour of strcat/strcpy/etc.. In all cases, it's a pointer error of one kind or another, though it could just as easily result from stack or array bounds based corruption of a pointer value, as it could from some error with the pointer usage itself. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Feb 10 12:16:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA22447 for hackers-outgoing; Mon, 10 Feb 1997 12:16:28 -0800 (PST) Received: from gateway.skipstone.com (root@GATEWAY.SKIPSTONE.COM [198.214.10.129]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA22441 for ; Mon, 10 Feb 1997 12:16:24 -0800 (PST) Received: from [204.69.236.50] (hotapplepie.skipstone.com [204.69.236.50]) by gateway.skipstone.com (8.7.4/8.6.9) with SMTP id OAA16828; Mon, 10 Feb 1997 14:16:02 -0600 Date: 10 Feb 97 14:16:16 -0600 Subject: Re: cool RSA Challenge project, friendly to FreeBSD From: "Richard Wackerbarth" To: "Russell L. Carter" Cc: hackers@freebsd.org X-Mailer: Cyberdog/2.0a2 MIME-Version: 1.0 Message-Id: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, Feb 10, 1997 11:20 AM, Russell L. Carter wrote: > >Those that don't mind hosting a possibly innocuous, polite, >cpu-cycle parasite might have a look at [snip] >(I have no connection whatsoever to these people) As an alternative, you might consider .... (I DO have a connection to THESE people ;-) >From a recent news release... NFSNET, a group of people who factor large numbers using the Number Field Sieve algorithm, announces a record factorization: On Tuesday, 4 February 1997, we completed the factorization of a composite number of 167 digits, one of the `More Wanted' factorizations of the Cunningham Project. It is: 3,349- = (3^349 - 1)/2 = c167 = p80 * p87 where p80 = 940428508899845109982891523204385417985320180216539562\ 83741193211654025280185459 p87 = 174165493740875256464746388999480533990944334266849687\ 054611524922878840708206608860499 [snip] The penultimate prime factor has 80 digits, a record. The 167-digit number is also the largest number ever factored by the Number Field Sieve. [snip] NFSNET is a collaborative effort to factor numbers by the Number Field Sieve. It relies on volunteers from around the world who contribute the "spare time" of a large number of workstations to perform the sieving. The organizers and principal researchers: Marije Elkenbracht-Huizing, Peter Montgomery, Bob Silverman, Richard Wackerbarth, Sam Wagstaff, Jr. [snip] If you would like to volunteer the services of your workstation to help factor large numbers, please email rkw@factoring.dataplex.net to learn how to join NFSNET. From owner-freebsd-hackers Mon Feb 10 13:44:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA27250 for hackers-outgoing; Mon, 10 Feb 1997 13:44:46 -0800 (PST) Received: from xmission.xmission.com (xmission.xmission.com [198.60.22.2]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA27071 for ; Mon, 10 Feb 1997 13:41:14 -0800 (PST) Received: (from softweyr@localhost) by xmission.xmission.com (8.8.5/8.7.5) id OAA05879; Mon, 10 Feb 1997 14:40:30 -0700 (MST) From: Softweyr LLC Message-Id: <199702102140.OAA05879@xmission.xmission.com> Subject: Re: 'nologin' program for disabling user accounts To: tom@sdf.com (Tom Samplonius) Date: Mon, 10 Feb 1997 14:40:29 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: from "Tom Samplonius" at Feb 9, 97 02:51:12 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Tom Samplonious asked, with respect to my recently posted nologin program: > Why? It seems that all BSD4.4 systems already have a nologin. See "man > nologin" Security and logging. The BSD4.4 nologin program is a shell script, which is rarely a good idea to use for a login shell due to the ability of the user to INTR and get a shell, if he's fast enough. Also, the standard nologin.sh doesn't log the attempted access, which means the system administrator doesn't know that somebody has been trying to use the disabled account. The original program I wrote years ago for SunOS and Ultrix, which had *no* secure way of disabling user accounts. This one may still have a few holes, such as ftpd and tftpd. Some ftp daemons refuse to allow access if the user's shell is not listed in /etc/shells, another reason to *not* list nologin in /etc/shells. (See the nologin man page for the original reason.) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com From owner-freebsd-hackers Mon Feb 10 13:52:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA27622 for hackers-outgoing; Mon, 10 Feb 1997 13:52:29 -0800 (PST) Received: from freebee.tu-graz.ac.at (root@freebee.tu-graz.ac.at [129.27.193.128]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA27608; Mon, 10 Feb 1997 13:52:13 -0800 (PST) Received: from dwarf.tu-graz.ac.at (isdn052.tu-graz.ac.at [129.27.240.52]) by freebee.tu-graz.ac.at (8.6.11/8.6.9) with ESMTP id WAA08696; Mon, 10 Feb 1997 22:52:06 +0100 Received: (from rmike@localhost) by dwarf.tu-graz.ac.at (8.7.5/8.7.3) id WAA00284; Mon, 10 Feb 1997 22:50:34 +0100 (MET) Date: Mon, 10 Feb 1997 22:50:34 +0100 (MET) From: Michael Ranner Reply-To: rmike@sbox.tu-graz.ac.at To: freebsd-scsi@freebsd.org, freebsd-hardware@freebsd.org, freebsd-hackers@freebsd.org Subject: Adaptec 2920 PCI driver (TMC18c30) - need persons to test! Message-ID: Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi there! This afternoon I have written the necessary code to get the Adaptec 2920 running under FreeBSD! It is based on parts of the latest PAO release and it's developed under FreeBSD 2.1.5. It was only necessary to write the PCI stuff! Now I need some persons to test the driver more accurate. Regards, /\/\ike /\/\ichael Ranner - rmike@sbox.tu-graz.ac.at http://www.sbox.tu.graz.ac.at/home/rmike/ --- end of message - non-sense follows --- ________ .' `. / \ |_____ _____| (_____><_____) \ /\ / \ oo / Grey-type ASCII encounter ... \ __ / `----' From owner-freebsd-hackers Mon Feb 10 14:09:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA28443 for hackers-outgoing; Mon, 10 Feb 1997 14:09:17 -0800 (PST) Received: from ami.tom.computerworks.net (root@AMI.RES.CMU.EDU [128.2.95.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA28438 for ; Mon, 10 Feb 1997 14:09:13 -0800 (PST) Received: from bonkers.taronga.com by ami.tom.computerworks.net with smtp (Smail3.1.29.1 #1) id m0vu3tT-0021UoC; Mon, 10 Feb 97 17:08 EST Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id JAA11865 for hackers@freebsd.org; Mon, 10 Feb 1997 09:07:12 -0600 Date: Mon, 10 Feb 1997 09:07:12 -0600 From: peter@taronga.com (Peter da Silva) Message-Id: <199702101507.JAA11865@bonkers.taronga.com> To: hackers@freebsd.org Subject: Utility routines: variable length strings, checked malloc, argv building, symbol table, and file scanning... Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Look in ~pds/utilib.shar on freefall. These should be useful, especially in setuid programs that need to do a bunch of this sort of thing dynamically. From owner-freebsd-hackers Mon Feb 10 15:38:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA02827 for hackers-outgoing; Mon, 10 Feb 1997 15:38:36 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA02822 for ; Mon, 10 Feb 1997 15:38:31 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id XAA25487; Mon, 10 Feb 1997 23:36:47 GMT Date: Tue, 11 Feb 1997 08:36:47 +0900 (JST) From: Michael Hancock To: Alexander Snarskii cc: freebsd-hackers@freebsd.org Subject: Re: Increasing overall security.... In-Reply-To: <199702101606.SAA08033@burka.carrier.kiev.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 10 Feb 1997, Alexander Snarskii wrote: > > Look in the cvs logs for recent commits by imp for example rlogind, rshd, > > etc. > > Well, i saw that changes. But, my reasons to ask to commit these patches > is: > 1) Any usage of strcpy and so in any program is a 'Bad Thing' (tm). Unless the caller can be trusted to check parameters from it's own callers and to pass parameters correctly. > Last reason: > Look to the /usr/src/lib/libc/stdio/gets.c - you'll see > the warning about this function, which are printed everytime, > when working programm calls this function first time. gets shouldn't be used at all. Warner Losh (imp) is committing Theos' buffer overflow fixes to all exploitable or likely exploitable cases. Mike Hancock From owner-freebsd-hackers Mon Feb 10 16:22:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA05502 for hackers-outgoing; Mon, 10 Feb 1997 16:22:46 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA05492 for ; Mon, 10 Feb 1997 16:22:28 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA29414 for hackers@freebsd.org; Tue, 11 Feb 1997 01:21:26 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id BAA21033; Tue, 11 Feb 1997 01:20:44 +0100 (MET) Message-ID: Date: Tue, 11 Feb 1997 01:20:44 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@freebsd.org Subject: Re: 'nologin' program for disabling user accounts References: <199702102140.OAA05879@xmission.xmission.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702102140.OAA05879@xmission.xmission.com>; from Softweyr LLC on Feb 10, 1997 14:40:29 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Softweyr LLC wrote: > Security and logging. The BSD4.4 nologin program is a shell script, > which is rarely a good idea to use for a login shell due to the ability > of the user to INTR and get a shell, if he's fast enough. No, he can't. If he interrupts it, he's logged off again, since he killed his login `shell'. > Also, the > standard nologin.sh doesn't log the attempted access, which means the > system administrator doesn't know that somebody has been trying to use > the disabled account. But that's easy to add (and probably a useful addition anyway), since there's always logger(1). The only known security pitfall for a #!/bin/sh executable as a login shell is that you can export ENV to /etc/shells in a telnet session. In this case, the shells there will be executed, but it goes into a $ENV loop until the user runs out of processes. This has been fixed later by merging the -p option idea from ksh, and using this option in /sbin/nologin. I've just asked the 2.1.x maintainers to merge this change, too. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Feb 10 17:19:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA00859 for hackers-outgoing; Mon, 10 Feb 1997 17:19:21 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA00834 for ; Mon, 10 Feb 1997 17:19:15 -0800 (PST) Received: from mailbox.tia.net (mailbox.tia.net [206.174.9.12]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id QAA29223 for ; Mon, 10 Feb 1997 16:47:24 -0800 (PST) Received: from localhost (jo295@localhost) by mailbox.tia.net (8.8.5/8.6.12) with SMTP id TAA24013 for ; Mon, 10 Feb 1997 19:45:13 -0500 (EST) Posted-Date: Mon Feb 10 19:45:13 1997 Date: Mon, 10 Feb 1997 19:45:13 -0500 (EST) From: "Joseph D. Orthoefer" To: hackers@FreeBSD.org Subject: Modifcation to user mode ppp Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I've added a few lines of code to modem.c to allow user mode ppp to start up a shell hanging off a pty (using forkpty() from libutil), and to use the master half of the pty as its modem device, this allows me to use the "term" command whilst running ppp and establish an 8 bit clean connection, like rsh or secure shell, and utilize ppp over that. Right now I have it execle'ing /usr/bin/login instead of /bin/sh since, for some reason, simply setuid()'ing the forked child back to a normal user right before exec'ing a shell results in the shell not working. Not setuid()'ing before execing results in a root shell. Here's the bit I can't get to work if I just have it exec a sh. OpenPtyChild() { int fdm; pid_t pid; char slave_name[20]; fdm = NULL; pid = forkpty(&fdm, slave_name, NULL, NULL); if (pid == 0) { /* child */ /* why don't I work */ setreuid(getuid,getuid); execle("/bin/sh", "sh", "-i", NULL); } return(fdm); } Plus two or three lines down in OpenModem() (in modem.c) to get it to recognize "pty" as a device type, and call the previous function. From owner-freebsd-hackers Mon Feb 10 17:21:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA01225 for hackers-outgoing; Mon, 10 Feb 1997 17:21:44 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA01216 for ; Mon, 10 Feb 1997 17:21:37 -0800 (PST) Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.8.3/8.6.9) with SMTP id UAA18953 for ; Mon, 10 Feb 1997 20:25:07 -0500 (EST) Message-Id: <3.0.32.19970210202049.00a28320@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 10 Feb 1997 20:20:52 -0500 To: hackers@freebsd.org From: dennis Subject: 2.1.7R - soon? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is this within a day of happening? Gotta make some decisions. Dennis From owner-freebsd-hackers Mon Feb 10 17:54:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA02581 for hackers-outgoing; Mon, 10 Feb 1997 17:54:11 -0800 (PST) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id RAA02576 for ; Mon, 10 Feb 1997 17:54:09 -0800 (PST) Received: from misery.sdf.com [204.244.213.33] by misery.sdf.com with smtp (Exim 1.59 #1) id 0vtzfH-0003vV-00; Mon, 10 Feb 1997 09:37:15 -0800 Date: Mon, 10 Feb 1997 09:37:14 -0800 (PST) From: Tom Samplonius To: Softweyr LLC cc: hackers@freebsd.org Subject: Re: 'nologin' program for disabling user accounts In-Reply-To: <199702102140.OAA05879@xmission.xmission.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 10 Feb 1997, Softweyr LLC wrote: > Tom Samplonious asked, with respect to my recently posted nologin > program: > > > Why? It seems that all BSD4.4 systems already have a nologin. See "man > > nologin" > > Security and logging. The BSD4.4 nologin program is a shell script, > which is rarely a good idea to use for a login shell due to the ability > of the user to INTR and get a shell, if he's fast enough. Also, the No. He can't get a shell, becase nologin is the shell. Tom From owner-freebsd-hackers Mon Feb 10 18:06:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA03191 for hackers-outgoing; Mon, 10 Feb 1997 18:06:06 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA03178 for ; Mon, 10 Feb 1997 18:06:00 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id SAA14541 for ; Mon, 10 Feb 1997 18:06:06 -0800 (PST) Message-Id: <199702110206.SAA14541@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: mrouted bug? Date: Mon, 10 Feb 1997 18:06:05 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk mrouted -D 3 usage: mrouted [-p] [-c configfile] [-d [debug_level]] mrouted -d 3 debug level 3 18:04:01.871 mrouted version 3.8a 18:04:01.901 Getting vifs from kernel interfaces 18:04:01.903 installing ed0 (204.188.121.18 on subnet 204.188.121.16/29) as vif #0 - rate=0 18:04:01.903 Getting vifs from /etc/mrouted.conf 18:04:01.905 installing tunnel from 204.188.121.18 to 140.174.2.1 as vif #1 - rate=500 18:04:01.905 Installing vifs in mrouted... 18:04:01.905 vif #0, phyint 204.188.121.18 18:04:01.906 SENT membership query from 204.188.121.18 to 224.0.0.1 18:04:01.906 SENT neighbor probe from 204.188.121.18 to 224.0.0.4 18:04:01.906 vif #1, tunnel 204.188.121.18 -> 140.174.2.1 18:04:01.906 SENT neighbor probe from 204.188.121.18 to 140.174.2.1 pruning on 18:04:01.934 Installing vifs in kernel... 18:04:01.936 vif #0, phyint 204.188.121.18 18:04:01.936 setsockopt MRT_ADD_VIF: File too large My mrouted was working fine last week till I upgraded to FreeBSD-current late last week. Does anyone have a clue as to what is going on here?? Tnks, Amancio From owner-freebsd-hackers Mon Feb 10 19:31:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA08048 for hackers-outgoing; Mon, 10 Feb 1997 19:31:26 -0800 (PST) Received: from ami.tom.computerworks.net (root@AMI.RES.CMU.EDU [128.2.95.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA08031 for ; Mon, 10 Feb 1997 19:31:16 -0800 (PST) Received: from bonkers.taronga.com by ami.tom.computerworks.net with smtp (Smail3.1.29.1 #1) id m0vu8w5-0021VZC; Mon, 10 Feb 97 22:31 EST Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id VAA22595; Mon, 10 Feb 1997 21:20:46 -0600 Date: Mon, 10 Feb 1997 21:20:46 -0600 From: peter@taronga.com (Peter da Silva) Message-Id: <199702110320.VAA22595@bonkers.taronga.com> To: hackers@freebsd.org Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) Newsgroups: taronga.freebsd.hackers In-Reply-To: <199701301550.IAA22016@phaeton.artisoft.com> References: <199701300259.NAA25266@genesis.atrad.adelaide.edu.au> Organization: none Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199701301550.IAA22016@phaeton.artisoft.com>, Terry Lambert wrote: >Ah... but what if you *are* a bllody genius, only you aren't aware of it? Wash the wound, and apply antiseptics. If bleeding persists, apply gentle pressure, seek expert help. Use common sense, don't put a torniquet around the neck. From owner-freebsd-hackers Mon Feb 10 21:00:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA12526 for hackers-outgoing; Mon, 10 Feb 1997 21:00:09 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA12477 for ; Mon, 10 Feb 1997 20:59:56 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id UAA00339 for ; Mon, 10 Feb 1997 20:59:44 -0800 (PST) Message-Id: <199702110459.UAA00339@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: ip_mroute.c Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Feb 1997 20:59:44 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Could someone review the above file? There are a couple of places where it calls if_allmulti and it does not set or reset the error flag. At any rate, I fix the references to if_allmulti . And right now mrouted is up and running. Amancio From owner-freebsd-hackers Mon Feb 10 21:09:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA12842 for hackers-outgoing; Mon, 10 Feb 1997 21:09:29 -0800 (PST) Received: from nexgen.ampr.org (max1-125.HiWAAY.net [208.147.145.125]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA12836 for ; Mon, 10 Feb 1997 21:09:20 -0800 (PST) Received: from nexgen (localhost [127.0.0.1]) by nexgen.ampr.org (8.8.5/8.8.4) with ESMTP id XAA18146; Mon, 10 Feb 1997 23:08:32 -0600 (CST) Message-Id: <199702110508.XAA18146@nexgen.ampr.org> X-Mailer: exmh version 1.6.9 8/22/96 To: Christoph Kukulies cc: freebsd-hackers@freefall.freebsd.org From: dkelly@hiwaay.net Subject: Re: Freewin95 - just fyi In-reply-to: Message from Christoph Kukulies of "Mon, 10 Feb 1997 15:06:16 +0100." <199702101406.PAA18523@gilberto.physik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Feb 1997 23:08:31 -0600 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Christoph Kukulies writes: > > Don't know whether I should smile or whine upon this, but > maybe someone could tell this whiz that the grounds are laid already :-) > > http://www.geocities.com/SiliconValley/7519/ I'm pretty sure its not April 1, yet. They said on the referenced page: > Did you know... > ...that the average Freedows '98 Member computer system runs at > 97.42 MHZ, has 25.25 MB RAM and has a 1.65 MB Video Card? This > is somewhat equivalent to a Pentium 90 with 24 MB of RAM and a > 2MB Video Card! Additionally, 53% use Intel Pentium Machines... Am wondering if it isn't April 1, 2000 already, somewhere in the world. :-) -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-hackers Mon Feb 10 22:05:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA00910 for hackers-outgoing; Mon, 10 Feb 1997 22:05:12 -0800 (PST) Received: from minor.stranger.com (stranger.vip.best.com [204.156.129.250]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id WAA00891 for ; Mon, 10 Feb 1997 22:04:39 -0800 (PST) Received: from dog.farm.org (dog.farm.org [207.111.140.47]) by minor.stranger.com (8.6.12/8.6.12) with ESMTP id WAA29989; Mon, 10 Feb 1997 22:13:29 -0800 Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id WAA14933; Mon, 10 Feb 1997 22:04:47 -0800 (PST) Date: Mon, 10 Feb 1997 22:04:47 -0800 (PST) From: Dmitry Kohmanyuk Message-Id: <199702110604.WAA14933@dog.farm.org> To: snar@lucky.net (Alexander Snarskii) Cc: freebsd-hackers@freebsd.org Subject: Re: Increasing overall security.... Newsgroups: cs-monolit.gated.lists.freebsd.hackers Organization: FARM Computing Association Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199702091525.RAA05048@burka.carrier.kiev.ua> you wrote: > 'Why don't rewrite that functions to check the stack integrity > before return?' says Oleg Panaschenko sometimes ago, and after > some reflections i found that that is not so bad idea. Yes, we're > getting some overhead with using these functions rather than > with standard ones, but, as for me, this overhead is not so big > and a reason, that i can sleep without nightmares about another > stack overflow exploits is much important for me. that's very good idea. I don't understand the reasons from other people responding to this negatively. Having someone looking for holes is very good, indeed; but, having computer used for detecting possible security holes at runtime seems like a good idea for me... also, for anyone concerned with performance hits when using these patches: well, maybe the best thing would to have an option when building libraries and static binaries, so you can make your world with -DPARANOID_LIBC if you feel like it. (editing your make.conf or ) it's on the similar scale with phkmalloc's runtime checks - can be a good thing to stress-test existing programs while not necessary a good thing for everyone. This also puts a suggestion for adding syslog() or at least fprintf(stderr) into these mods... > IDEA NOTES: > There are two new functions: checkframe__(char* a,char* b), which > checks that we have no stack frames (generated by call _func) > in memory region [a,b], and insane__(char* function-name,char* buffer), > which are just performs kill(SIGSEGV,getpid()) (because program > will got this signal while 'ret' to junk address in stack anyway > but exploited) and after exit(1) (for cases like signal(SIG_SEGV,SIG_IGN) > :) ). And most functions, which can be used for stack exploiting, > patched to check the changed memory region to avoid stack violation. > These functions are: strcpy,strcat,sprintf ( well, 90% of such exploits > used it ), gets (historical reasons :) ) and memcpy (some things, like > scanf and so uses it). -- Don't take life too seriously. You'll never get out of it alive. From owner-freebsd-hackers Mon Feb 10 23:47:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA06059 for hackers-outgoing; Mon, 10 Feb 1997 23:47:25 -0800 (PST) Received: from nlanr.net (oceana.sdsc.edu [132.249.40.200]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA06054 for ; Mon, 10 Feb 1997 23:47:22 -0800 (PST) Received: (from tony@localhost) by nlanr.net (8.7.3/8.7.3) id XAA23618 for hackers@freebsd.org; Mon, 10 Feb 1997 23:47:16 -0800 (PST) From: Tony Sterrett Message-Id: <199702110747.XAA23618@nlanr.net> Subject: Kernel to user memory space To: hackers@freebsd.org Date: Mon, 10 Feb 1997 23:47:16 -0800 (PST) X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi all Does anyone know a way of reading (i only need readonly) kernel memory given address? I need a cheap way of reading /mem/kmem that does not involve copying. I know there are issue with this question. At present I plan to use the kvm interface kvm_open() and kvm_read(). Thanks Cheers, Tony From owner-freebsd-hackers Tue Feb 11 01:08:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA09566 for hackers-outgoing; Tue, 11 Feb 1997 01:08:38 -0800 (PST) Received: from alcatel.fr (mail.alcatel.fr [194.133.58.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA09556 for ; Tue, 11 Feb 1997 01:08:23 -0800 (PST) Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.244]) by mailgate.alcatel.fr (8.8.5/8.8.5) with ESMTP id LAA11607 for ; Tue, 11 Feb 1997 11:13:36 +0100 Received: from dnscit.cit.alcatel.fr (dnscit.cit.alcatel.fr [139.54.100.2]) by nsfhh5.alcatel.fr (8.7.3/8.7.3) with SMTP id KAA26600 for ; Tue, 11 Feb 1997 10:08:12 +0100 (MET) Received: from dnsvz.vz.cit.alcatel.fr by dnscit.cit.alcatel.fr (SMI-8.6/SMI-SVR4) id KAA23366; Tue, 11 Feb 1997 10:10:22 +0100 Received: from bcv64s3e.vz.cit.alcatel.fr by dnsvz.vz.cit.alcatel.fr (SMI-8.6/SMI-SVR4) id JAA05577; Tue, 11 Feb 1997 09:54:33 +0100 Received: from bcv64wc1.velizy by bcv64s3e.vz.cit.alcatel.fr (SMI-8.6/SMI-SVR4) id KAA14700; Tue, 11 Feb 1997 10:06:47 +0100 From: luc.lewy@vz.cit.alcatel.fr (Luc.LEWY) Message-Id: <199702110906.KAA14700@bcv64s3e.vz.cit.alcatel.fr> Subject: mail.local & quotas... To: hackers@freebsd.org Date: Tue, 11 Feb 1997 10:06:46 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 'lo all.. Well, while looking at source code of mail.local, I found a little bug... (I'm currently using a FreeBSD 2.1.5 R) When quotas are set, mail.local could be used to overwrite these quotas.. as mail.local is setuid root... mail.local -f fill_it user1 user2 < /kernel.uu I think, we should change mail.local to: 1) fork and wait for its child to die before continue (it'll fork for each destination user, but one at a time.. ) 2) each child *must* change it's uid to the owner of the destination mailbox... This was maybe known and corrected since months, but I never see references to this... This is not really a security risk, but an entiere filesystem could be filled in this way.. (+ the 3% of the UFS since it's root who write these datas.. ) fifi... -- Guezou "fifi..." Philippe email: guezou_p@epita.fr pguezou@iway.fr luc.lewy@vz.cit.alcatel.fr From owner-freebsd-hackers Tue Feb 11 05:49:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA20669 for hackers-outgoing; Tue, 11 Feb 1997 05:49:43 -0800 (PST) Received: from po1.glue.umd.edu (root@po1.glue.umd.edu [129.2.128.44]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA20664 for ; Tue, 11 Feb 1997 05:49:41 -0800 (PST) Received: from fiber.eng.umd.edu (fiber.eng.umd.edu [129.2.98.185]) by po1.glue.umd.edu (8.8.5/8.8.5) with ESMTP id IAA13239; Tue, 11 Feb 1997 08:49:34 -0500 (EST) Received: from localhost (chuckr@localhost) by fiber.eng.umd.edu (8.8.5/8.7.3) with SMTP id IAA01442; Tue, 11 Feb 1997 08:49:34 -0500 (EST) X-Authentication-Warning: fiber.eng.umd.edu: chuckr owned process doing -bs Date: Tue, 11 Feb 1997 08:49:33 -0500 (EST) From: Chuck Robey X-Sender: chuckr@fiber.eng.umd.edu To: dkelly@hiwaay.net cc: Christoph Kukulies , freebsd-hackers@freefall.freebsd.org Subject: Re: Freewin95 - just fyi In-Reply-To: <199702110508.XAA18146@nexgen.ampr.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 10 Feb 1997 dkelly@hiwaay.net wrote: > Christoph Kukulies writes: > > > > Don't know whether I should smile or whine upon this, but > > maybe someone could tell this whiz that the grounds are laid already :-) > > > > http://www.geocities.com/SiliconValley/7519/ > > I'm pretty sure its not April 1, yet. > > They said on the referenced page: > > Did you know... > > ...that the average Freedows '98 Member computer system runs at > > 97.42 MHZ, has 25.25 MB RAM and has a 1.65 MB Video Card? This > > is somewhat equivalent to a Pentium 90 with 24 MB of RAM and a > > 2MB Video Card! Additionally, 53% use Intel Pentium Machines... > > Am wondering if it isn't April 1, 2000 already, somewhere in the world. :-) I know the posting is from berkeley, but I have to be just a little skeptical about publicity from a project that isn't even started yet, on a project so large that you _know_ it can't be done quickly. Shows that commercial firms have no monopoly on vaporware. Maybe it'll become real, but the announcements, coming so early, seem in poor taste. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Tue Feb 11 05:51:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA20744 for hackers-outgoing; Tue, 11 Feb 1997 05:51:07 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA20738 for ; Tue, 11 Feb 1997 05:51:04 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA22048; Tue, 11 Feb 1997 08:50:03 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Tue, 11 Feb 1997 08:50 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id HAA23438; Tue, 11 Feb 1997 07:10:03 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id HAA02075; Tue, 11 Feb 1997 07:14:20 -0500 (EST) Date: Tue, 11 Feb 1997 07:14:20 -0500 (EST) From: Thomas David Rivers Message-Id: <199702111214.HAA02075@lakes.water.net> To: ponds!critter.dk.tfs.com!phk Subject: Re: daily panics, ffs_valloc: dup alloc - Good news! Cc: ponds!freebsd.org!dg, ponds!freebsd.org!hackers, ponds!freebsd.org!joerg Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Poul-Henning writes: > > In message <199702101504.KAA26752@lakes.water.net>, Thomas David Rivers writes: > >> > >> > I'll try getting it with a fixit floppy. > >> > >> please, it's rather crucial for debugging this. > > > > > > Ok - here you go. > > Thanks a lot. > > > 3) Then, I ifconfig'd ed0; grabbed a working dumpfs and > > go this output. > > I notice that the cgmask is 0xffffffff; so I _think_ > > this file system would have the same problems. > > (ignore the time there; I haven't got the CMOS clock set right.) > > I still can't see how you can possibly have reached the conclusion > that cgmask is the cause of this (as oposed to some other magic somewhere > in the code)... Well; given your statement that 0xffffffff is the correct cgmask - I'd have to retract my assertion. It was simply the only "strange-looking" thing I stumbled into when I was determining just how the disk block offset was calculated. I'm no filesystem guru; I do compilers :-) However; I'm certain that the problem is disk block calculation, somewhere. Since the panic occurs in ffs_alloc.c:ffs_vget(), on a brand new file system; on the first allocation of an inode that just happens to be the same as the # inodes/group. We do the malloc(), bzero() of this data; then the bread() and we're toast. Did the dumpfs I sent you point to any strangeness? - Dave Rivers - From owner-freebsd-hackers Tue Feb 11 05:59:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA21139 for hackers-outgoing; Tue, 11 Feb 1997 05:59:58 -0800 (PST) Received: from shell.monmouth.com (pechter@shell.monmouth.com [205.164.220.9]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA21127; Tue, 11 Feb 1997 05:59:32 -0800 (PST) Received: (from pechter@localhost) by shell.monmouth.com (8.8.4/8.7.3) id IAA28740; Tue, 11 Feb 1997 08:59:00 -0500 (EST) From: Bill/Carolyn Pechter Message-Id: <199702111359.IAA28740@shell.monmouth.com> Subject: 2.2-BETA-->2.2GAMMA fails To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Date: Tue, 11 Feb 1997 08:58:59 -0500 (EST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Anyone ever see this failure in make world. I'm going from -BETA (built clean) to -GAMMA and this was the only failure. archive.c did not change -- did the system includes...? cc -O2 -m486 -pipe -I/usr/src/gnu/usr.bin/gdb/bfd/. -I/usr/src/gnu/usr.bin/gdb/bfd/../gdb/. -DDEFAULT_VECTOR=i386freebsd_vec -DSELECT_VECS='&i386freebsd_vec,&i386bsd_vec' -DSELECT_ARCHITECTURES='&bfd_i386_arch' -DTRAD_CORE -I/usr/src/gnu/usr.bin/gdb/bfd/../../../../contrib/gdb/include/. -I/usr/src/gnu/usr.bin/gdb/bfd/../../../../contrib/gdb/gdb/. -I/usr/src/gnu/usr.bin/gdb/bfd/../../../../contrib/gdb/bfd/. -I/usr/src/gnu/usr.bin/gdb/bfd/../../../../contrib/gdb/libiberty/. -I/usr/src/gnu/usr.bin/gdb/bfd/../../../../contrib/gdb/gdb/config/. -DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/gdb/bfd/../../../../contrib/gdb/include/. -I/usr/src/gnu/usr.bin/gdb/bfd/../../../../contrib/gdb/gdb/. -I/usr/src/gnu/usr.bin/gdb/bfd/../../../../contrib/gdb/bfd/. -I/usr/src/gnu/usr.bin/gdb/bfd/../../../../contrib/gdb/libiberty/. -I/usr/src/gnu/usr.bin/gdb/bfd/../../../../contrib/gdb/gdb/config/. -DHAVE_CONFIG_H -c archive.c -o archive.o In file included from archive.c:130: libbfd.h:366: warning: duplicate `const' libbfd.h:371: warning: duplicate `const' archive.c:562: parse error before `->' archive.c:564: `index' redeclared as different kind of symbol /usr/include/string.h:81: previous declaration of `index' archive.c:565: parse error before `{' archive.c:568: `abfd' undeclared here (not in a function) archive.c:569: parse error before `return' *** Error code 1 Stop. *** Error code 1 Stop. +---------------------------------------------------------------------------+ | Bill/Carolyn Pechter | 17 Meredith Drive | Tinton Falls, New Jersey 07724 | | 908-389-3592 | Save computing history, give an old geek old hardware. | | pechter@shell.monmouth.com | +---------------------------------------------------------------------------+ | This message brought to you by the letters PDP and the number 11. | +---------------------------------------------------------------------------+ From owner-freebsd-hackers Tue Feb 11 06:19:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA21863 for hackers-outgoing; Tue, 11 Feb 1997 06:19:44 -0800 (PST) Received: from burka.carrier.kiev.ua (snar@burka.carrier.kiev.ua [193.193.193.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA21851 for ; Tue, 11 Feb 1997 06:19:32 -0800 (PST) Received: (from snar@localhost) by burka.carrier.kiev.ua (8.8.4/8.who.cares.1) id QAA06995; Tue, 11 Feb 1997 16:18:20 +0200 (EET) From: Alexander Snarskii Message-Id: <199702111418.QAA06995@burka.carrier.kiev.ua> Subject: Re: Increasing overall security.... To: michaelh@cet.co.jp (Michael Hancock) Date: Tue, 11 Feb 1997 16:18:19 +0200 (EET) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "Michael Hancock" at Feb 11, 97 08:36:47 am Content-type: text/plain; charset=koi8-r X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Last reason: > > Look to the /usr/src/lib/libc/stdio/gets.c - you'll see > > the warning about this function, which are printed everytime, > > when working programm calls this function first time. > > gets shouldn't be used at all. > > Warner Losh (imp) is committing Theos' buffer overflow fixes to all > exploitable or likely exploitable cases. To all exploitable or likely exploitable cases in the _FreeBSD_ source tree, may be this is a more correct definition. But do Theo checks every new sendmail distribution ? Or did he checked all the FreeBSD packages/ports which can use this functions and have enough privileges to destroy your system if exploited? Or did anybody checks it and published patches to ones (if the holes are found) ? Well, i did'nt saw any security risk in using of qpopper, but i have'nt a time to check radius/tacacs+ daemons and so many other packages, which are installed on my computer, and my patches is 'fast-and-dirty way' to increase securityness of _all_ dynamically linked executables. Even without recompiling ones. Even without source code of ones. Well, no one wants it, so let it be. -- Alexander Snarskii the source code is included. From owner-freebsd-hackers Tue Feb 11 07:31:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA27256 for hackers-outgoing; Tue, 11 Feb 1997 07:31:13 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA27246 for ; Tue, 11 Feb 1997 07:31:09 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vuKAU-0006P6-00; Tue, 11 Feb 1997 08:30:50 -0700 To: dkelly@hiwaay.net Subject: Re: Freewin95 - just fyi Cc: Christoph Kukulies , freebsd-hackers@freefall.freebsd.org In-reply-to: Your message of "Mon, 10 Feb 1997 23:08:31 CST." <199702110508.XAA18146@nexgen.ampr.org> References: <199702110508.XAA18146@nexgen.ampr.org> Date: Tue, 11 Feb 1997 08:30:50 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199702110508.XAA18146@nexgen.ampr.org> dkelly@hiwaay.net writes: : Am wondering if it isn't April 1, 2000 already, somewhere in the world. :-) It looked really good until I read the part of about him losing his head of something or other before coding had begun due to a personality dispute... Warner From owner-freebsd-hackers Tue Feb 11 07:46:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA29396 for hackers-outgoing; Tue, 11 Feb 1997 07:46:21 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA29377 for ; Tue, 11 Feb 1997 07:46:17 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vuKJn-0006Ph-00; Tue, 11 Feb 1997 08:40:27 -0700 To: Alexander Snarskii Subject: Re: Increasing overall security.... Cc: michaelh@cet.co.jp (Michael Hancock), freebsd-hackers@freebsd.org In-reply-to: Your message of "Tue, 11 Feb 1997 16:18:19 +0200." <199702111418.QAA06995@burka.carrier.kiev.ua> References: <199702111418.QAA06995@burka.carrier.kiev.ua> Date: Tue, 11 Feb 1997 08:40:27 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199702111418.QAA06995@burka.carrier.kiev.ua> Alexander Snarskii writes: : But do Theo checks : every new sendmail distribution ? Yes. He does. And he routinely applies additional tweaks the sources in OpenBSD from what I can tell. : Or did he checked all the FreeBSD : packages/ports which can use this functions and have enough privileges : to destroy your system if exploited? No. He hasn't. That's a FreeBSD thing :-). However, now that ports are part of the OpenBSD system (or at least supported), I think this may change. : Or did anybody checks it and : published patches to ones (if the holes are found) ? Often time Theo is behind the scenes and knows about these before the great unwashed masses know about them. And he fixes those problems in OpenBSD that are present. Keep in mind, as was recently pointed out to me, that just bringing in the OpenBSD patches will not make FreeBSD secure. For that a top to bottom audit of code running at elevated priviledge must be completed. The patches will tend to make FreeBSD more secure, but you won't know until after you've audited if you've grabbed everything or not. Warner From owner-freebsd-hackers Tue Feb 11 09:55:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA07673 for hackers-outgoing; Tue, 11 Feb 1997 09:55:59 -0800 (PST) Received: from gatekeeper.ctron.com (ctron.com [134.141.197.25]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA07667 for ; Tue, 11 Feb 1997 09:55:54 -0800 (PST) Received: (from news@localhost) by gatekeeper.ctron.com (8.6.12/8.6.9) id MAA06334 for ; Tue, 11 Feb 1997 12:55:46 -0500 Received: from stealth.ctron.com(134.141.5.107) by gatekeeper via smap (V1.3mjr) id sma006288; Tue Feb 11 12:55:00 1997 Received: from dur-mail.ctron.com by stealth.ctron.com (4.1/SMI-4.1) id AA02889; Tue, 11 Feb 97 13:00:55 EST Received: from thoth.ctron (thoth.ctron.com [134.141.65.91]) by dur-mail.ctron.com (8.6.12/8.6.9) with ESMTP id MAA14796 for ; Tue, 11 Feb 1997 12:58:18 -0500 Received: from thoth by thoth.ctron (SMI-8.6/SMI-SVR4) id MAA28040; Tue, 11 Feb 1997 12:56:50 -0500 Message-Id: <3300B2E0.678F@ctron.com> Date: Tue, 11 Feb 1997 12:56:48 -0500 From: Alexander Seth Jones Organization: Cabletron Systems, Inc. X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.5.1 sun4m) Mime-Version: 1.0 To: hackers@freefall.freebsd.org Subject: ilogb w/FPU croaking Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I just built the libmsun library with the HAVE_FPU and _IEEE_LIBM macros and am getting a memory error when using the ilogb function. I don't think I built it incorrectly because all of the other functions work. Is this a known error, or should I investigate more? I'm running 2.1.5-RELEASE on a 486-66. Here's a test program that illustrates the error: #include int main() { int i = ilogb( 2938472389.2374 ); } -- Alex Jones | ajones@ctron.com Cabletron Systems, Inc. Durham, NH USA 03824 From owner-freebsd-hackers Tue Feb 11 10:09:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA08284 for hackers-outgoing; Tue, 11 Feb 1997 10:09:12 -0800 (PST) Received: from burka.carrier.kiev.ua (snar@burka.carrier.kiev.ua [193.193.193.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA08262 for ; Tue, 11 Feb 1997 10:08:47 -0800 (PST) Received: (from snar@localhost) by burka.carrier.kiev.ua (8.8.4/8.who.cares.1) id UAA13517; Tue, 11 Feb 1997 20:07:12 +0200 (EET) From: Alexander Snarskii Message-Id: <199702111807.UAA13517@burka.carrier.kiev.ua> Subject: Re: Increasing overall security.... To: imp@village.org (Warner Losh) Date: Tue, 11 Feb 1997 20:07:00 +0200 (EET) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "Warner Losh" at Feb 11, 97 08:40:27 am Content-type: text/plain; charset=koi8-r X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > : Or did he checked all the FreeBSD > : packages/ports which can use this functions and have enough privileges > : to destroy your system if exploited? > > No. He hasn't. That's a FreeBSD thing :-). However, now that ports > are part of the OpenBSD system (or at least supported), I think this > may change. Well, that's not his problems. > > : Or did anybody checks it and > : published patches to ones (if the holes are found) ? > > Often time Theo is behind the scenes and knows about these before the > great unwashed masses know about them. And he fixes those problems in > OpenBSD that are present. Well, but now any 'hidden security violation' ( 'hidden' just because noone knows that there are one) have these stages of evolution: 1. somebody ( often time original author ) places to his program some code, which can be used to violate security. 2. that part of code are used in normal purposes, just because noone knew, that there are ones. 3. somebody ( often time Theo de Raadt or original author of the code founds some 'bad things' ( buffer overruns, f.e. ) in the code, and patches the program, or writing exploit to get additional privleges with the one part of code, or notifies author about that disfuncionality or something else. 4. author or security-officer of the project applied these patches, and we are again on the step 1 ... ( and on the step 2 and 3 for some another bugs ). Just an example of such violation: user-level ppp was written sometimes ago. And, in the first FreeBSD-release that i seen ( 2.1.0 ) it has next string: strcpy(buffer,getenv("HOME")) ( or something like that, there were an exploit ). About three months ago, when ppp on my computer tells me, that it can't recognise any of tun* device, i saw the sources and found these strings. And notified security-officer@freebsd.org about possibility of exploit. And Paul Triana answers me, that seurity advisory is pending. And it was FreeBSD security advisory. Well, but i did'nt verified _all_ ppp code to avoid all these bugs ! I just found one of principal exploits in, and i have no time to read _all_ the ppp code... As for me, fast-and-dirty way to avoid the _class_ of problems is to rewrite the strcpy(2) function, to let it _itself_ verify, did it overwrite any stack frame or not! F.e. in the example above, if the somebody wants to get the euid=0, he just executing ppp with the HOME='exploit-code', and strcpy, in time of copying 'exploit-code' to 'buffer' overwrites stack, and did not care about it. As a result, after returning from functions, hacker gets his euid=0... But, in libc with my patches to, strcpy calling checkframe functions, which checks, _did_ _that_ _function_ _overwrited_ _any_ _stack_ _frame_. And calling kill(SIGSEGV,getpid()) if so, just because we will not take segmentation violation only in case of exploiting some hole. So, _noone_ of holes, which were found by anybody and uses strcpy as 'exploit-function' will not work with that libc. More than, noone of _yet not founded_ exploits, based on stack-smashing technology and which uses strcpy(2) _will not_ work. Just because strcpy(2) will generate SIGSEGV to the program _before_ the stack got to be executed. > > Keep in mind, as was recently pointed out to me, that just bringing in > the OpenBSD patches will not make FreeBSD secure. For that a top to That's not OpenBSD patches. That is original patches. More that, these patches based on original idea, and i did'nt heard anything like it. > bottom audit of code running at elevated priviledge must be > completed. The patches will tend to make FreeBSD more secure, but you > won't know until after you've audited if you've grabbed everything or > not. I'm absolutely sure, that my patches is not an panacea from all classes of exploits. But, with that patches, _noone_ stack-smashed attack, which uses strcpy, strcat, sprintf and some other functions will not work. So, FreeBSD with that patches have one exploits class less that any other PC-based UNIX (Including OpenBSD). -- Alexander Snarskii the source code is included. From owner-freebsd-hackers Tue Feb 11 10:23:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA08903 for hackers-outgoing; Tue, 11 Feb 1997 10:23:49 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA08897 for ; Tue, 11 Feb 1997 10:23:46 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id TAA13718; Tue, 11 Feb 1997 19:21:34 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id TAA12192; Tue, 11 Feb 1997 19:14:51 +0100 (MET) Message-Id: <3.0.32.19970211191451.00b80ec0@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 11 Feb 1997 19:14:52 +0100 To: Warner Losh From: Eivind Eklund Subject: Re: Increasing overall security.... Cc: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 08:40 AM 2/11/97 -0700, Warner Losh wrote: >Keep in mind, as was recently pointed out to me, that just bringing in >the OpenBSD patches will not make FreeBSD secure. For that a top to >bottom audit of code running at elevated priviledge must be >completed. The patches will tend to make FreeBSD more secure, but you >won't know until after you've audited if you've grabbed everything or >not. You won't ever know. I do not believe FreeBSD (or any other major OS written in C) will ever be 100% secure - there are too many pitfalls, and too easy to write unsafe code. However, we can always strive towards it, and removing just *one* more of the easy breakins make it just that little bit harder for the hackers. A nice thing I've been noticing lately is that when I do security audits for selected parts of the 2.1.6 code and find exploits, they tend to be fixed in -current already. That at least show that the obvious stuff is going away. Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/ eivind@freebsd.org From owner-freebsd-hackers Tue Feb 11 10:46:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA10053 for hackers-outgoing; Tue, 11 Feb 1997 10:46:59 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA10045 for ; Tue, 11 Feb 1997 10:46:45 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id FAA08190; Wed, 12 Feb 1997 05:42:13 +1100 Date: Wed, 12 Feb 1997 05:42:13 +1100 From: Bruce Evans Message-Id: <199702111842.FAA08190@godzilla.zeta.org.au> To: ajones@ctron.com, hackers@freefall.freebsd.org Subject: Re: ilogb w/FPU croaking Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I just built the libmsun library with the HAVE_FPU and _IEEE_LIBM >macros and am getting a memory error when using the ilogb function. > > I don't think I built it incorrectly because all of the other >functions work. Is this a known error, or should I investigate more? > > I'm running 2.1.5-RELEASE on a 486-66. ilogb() was broken in 2.1.0-RELEASE but was fixed in 2.1.5-RELEASE according to the cvs tags. However, the HAVE_FPU versions of some other functions are broken in 2.1.5 and 2.1.6. Bruce From owner-freebsd-hackers Tue Feb 11 11:07:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA11279 for hackers-outgoing; Tue, 11 Feb 1997 11:07:28 -0800 (PST) Received: from mwunix.mitre.org (mwunix.mitre.org [128.29.154.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA11254; Tue, 11 Feb 1997 11:07:08 -0800 (PST) Received: from maestro.mitre.org (maestro.mitre.org [128.29.45.1]) by mwunix.mitre.org (8.8.5/8.8.4/mitre.0) with SMTP id OAA00856; Tue, 11 Feb 1997 14:04:37 -0500 (EST) Received: from postman.mitre.org by maestro.mitre.org (4.1/SMI-4.1) id AA10527; Tue, 11 Feb 97 14:04:36 EST Received: from [128.29.114.90] by postman.mitre.org (SMI-8.6/SMI-SVR4) id OAA16578; Tue, 11 Feb 1997 14:09:16 -0500 Date: Tue, 11 Feb 1997 14:09:16 -0500 X-Sender: guhl@postman.mitre.org Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: freebsd-hackers@FreeBSD.org From: guhl@mitre.org (George Uhl) Subject: Fix to Interrupt/Terminate Signal causes page fault in kernel mode Cc: freebsd-bugs@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I posted the following to freebsd-hackers and freebsd-bugs a couple of days ago. I have fixed the problem, not by making any code changes, but by compiling the kernel unoptimized! compiler: GNU gcc version 2.6.3 I question the wisdom of allowing the COPTFLAGS option in /sys/386/conf/Makefile.i386 to enable optimization when this may cause unpredictable and erroneous kernel behavior. Any opinions? BEGIN previous message: I'm porting a version of OSI and X.25 from a heavily modified BSDI ver1.1 to FreeBSD 2.1.6. I'm running an application with a TP4 socket (OSI's version of a reliable, connection-oriented transport- layer socket) that is causing the kernel to crash when it is interrupted/killed by a signal (control-c, kill -9, etc.). The application is waiting for comm traffic (e.g., is listening for a connect, or is connected and waiting for data) and it receives the signal. Then the kernel crashes with: Fatal trap 12: page fault while in kernel mode Fault virtual address = 0x8 Fault code = supervisor read, page not present Instruction pointer = 0x8:0xf010d620 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32, 1, gran 1 processor eflags = Interrupt enabled, resume, IOPL = 0 current process = 259 (tisink) interrupt mask = kernel: type 12 trap. code=0 Stopped at _exit1+0xc4 [/sys/compile/PORT1/:163]: movl 0x8(%ebp),%esi The source code statement (line 163 in /sys/kern/kern_exit.c) from the kernel is: if (SESS_LEADER(p)) { which translates to: if (p->p_session->s_leader == p) { At this point register %ebp is NULL. p is the pointer to the process descriptor for the application. I've use ddb to examine the registers, when the fdfree function is called from exit1 the ebp register contains a pointer to the kernel stack plus some offset. Just prior to leaving fdfree and returning to exit1, ebp is set to zero. The fdfree function does a closef on the socket fd which in turn calls a detach function in the OSI TP code. If I hack the exit1 function and put a statement like a printf or an if(0); prior to the call to untimeout or fdfree, the kernel doesn't crash. This seems like a timing problem to me, but I'm not sure who or what is messing around with my process descriptor pointer. The OSI TP detach function releases OSI protocol data strcutures (like the TP4 and CLNP protocol control blocks) and frees the socket. I don't think the problem is in the detach code. Does anyone have any ideas? END previous message ---- George Uhl The MITRE Corporation From owner-freebsd-hackers Tue Feb 11 11:48:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA13727 for hackers-outgoing; Tue, 11 Feb 1997 11:48:06 -0800 (PST) Received: from agisgate.agis.net (agisgate.agis.net [205.137.48.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA13613; Tue, 11 Feb 1997 11:47:13 -0800 (PST) Received: from radio (radio.agis.net [205.137.48.54]) by agisgate.agis.net (8.8.5/8.7.3) with SMTP id OAA04803; Tue, 11 Feb 1997 14:47:02 -0500 (EST) Message-Id: <3.0.32.19970211144703.009967e0@agisgate.agis.net> X-Sender: markl@agisgate.agis.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 11 Feb 1997 14:47:03 -0500 To: freebsd-hardware@freebsd.org, freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org From: Mark E Larson Subject: DEC 21140-AC chipset incompatibility Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hey There! I have recently recieved new SMC 10/100 cards that contain the DEC 21140-AC chips instead of the DEC 21140-AB chips. They are reconized by FreeBSD but do NOT correctly configure, and therefore do not transport any data. I am currently running 2.1.5 but I have tried the 2.2 boot-flp and the driver on there does not work either. Does anyone have any suggestions or fixes for this. I am running short on AB chips and need to use the cards. Thanx Mark E Larson Internet Engineer From owner-freebsd-hackers Tue Feb 11 11:50:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA13930 for hackers-outgoing; Tue, 11 Feb 1997 11:50:37 -0800 (PST) Received: from super-g.inch.com (super-g.com [204.178.32.161]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA13925 for ; Tue, 11 Feb 1997 11:50:33 -0800 (PST) Received: from localhost (spork@localhost) by super-g.inch.com (8.8.5/8.6.9) with SMTP id OAA01600; Tue, 11 Feb 1997 14:55:26 -0500 (EST) Date: Tue, 11 Feb 1997 14:55:25 -0500 (EST) From: spork X-Sender: spork@super-g.inch.com To: dennis cc: hackers@freebsd.org Subject: Re: 2.1.7R - soon? In-Reply-To: <3.0.32.19970210202049.00a28320@etinc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I cvsupped -stable today on four machines (GAMMA made my brain hurt too much) with no troubles; really convenient method of updating everything. The sup took about 10 minutes, then a new kernel and a make world with *absolutely* no troubles. A uname -a shows this: FreeBSD oscar.inch.com 2.1.7-RELEASE FreeBSD 2.1.7-RELEASE #0: Tue Feb 11 12:37:47 EST 1997 spork@oscar.inch.com:/usr/src/sys/compile/OSCAR i386 ps- grab the cvsup bins on freefall; the mod-3 libs take quite some time to compile... Also, someone put a really nice cvsup entry in the handbook that was a great help in doing this so quickly. Charles On Mon, 10 Feb 1997, dennis wrote: > > Is this within a day of happening? Gotta make some decisions. > > Dennis > From owner-freebsd-hackers Tue Feb 11 11:57:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA14432 for hackers-outgoing; Tue, 11 Feb 1997 11:57:31 -0800 (PST) Received: from dicsmss1.jrc.it (dicsmss1.jrc.it [139.191.1.65]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA14426 for ; Tue, 11 Feb 1997 11:57:28 -0800 (PST) Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA02307; Tue, 11 Feb 97 21:03:22 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA04876; Tue, 11 Feb 1997 20:56:46 +0100 Date: Tue, 11 Feb 1997 20:56:46 +0100 From: "Dirk.vanGulik" Message-Id: <9702111956.AA04876@ jrc.it> To: hackers@freebsd.org Subject: IRda X-Sun-Charset: US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Anyone working on an IRda implementation ? (Infrared stuff portables have). I am at the moment; about midway with a device to do things up to lapm/frame level. Anyone have a device number for that ? Tha ! Dw. From owner-freebsd-hackers Tue Feb 11 12:23:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA15777 for hackers-outgoing; Tue, 11 Feb 1997 12:23:07 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA15767; Tue, 11 Feb 1997 12:23:00 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65v3.2/1.1.8.2/19Aug95-0530PM) id AA13751; Tue, 11 Feb 1997 15:22:52 -0500 Date: Tue, 11 Feb 1997 15:22:52 -0500 From: Garrett Wollman Message-Id: <9702112022.AA13751@halloran-eldar.lcs.mit.edu> To: guhl@mitre.org (George Uhl) Cc: freebsd-hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Fix to Interrupt/Terminate Signal causes page fault in kernel mode In-Reply-To: References: Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk < I posted the following to freebsd-hackers and freebsd-bugs a couple > of days ago. I have fixed the problem, not by making any code > changes, but by compiling the kernel unoptimized! Your code is almost certainly broken. It probably has automatic variable initialization problems. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-hackers Tue Feb 11 13:00:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA18142 for hackers-outgoing; Tue, 11 Feb 1997 13:00:45 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA18128 for ; Tue, 11 Feb 1997 13:00:30 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.7.3) with ESMTP id UAA12501; Tue, 11 Feb 1997 20:57:41 GMT Message-Id: <199702112057.UAA12501@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: "Joseph D. Orthoefer" cc: hackers@FreeBSD.ORG Subject: Re: Modifcation to user mode ppp In-reply-to: Your message of "Mon, 10 Feb 1997 19:45:13 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Feb 1997 20:57:41 +0000 From: Brian Somers Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I've added a few lines of code to modem.c to allow user mode ppp to start > up a shell hanging off a pty (using forkpty() from libutil), and to use > the master half of the pty as its modem device, this allows me to use the > "term" command whilst running ppp and establish an 8 bit clean connection, > like rsh or secure shell, and utilize ppp over that. Right now I have it > execle'ing /usr/bin/login instead of /bin/sh since, for some reason, > simply setuid()'ing the forked child back to a normal user right before > exec'ing a shell results in the shell not working. Not setuid()'ing > before execing results in a root shell. > > Here's the bit I can't get to work if I just have it exec a sh. > > OpenPtyChild() > { > int fdm; > pid_t pid; > char slave_name[20]; > > fdm = NULL; > pid = forkpty(&fdm, slave_name, NULL, NULL); > if (pid == 0) { /* child */ > /* why don't I work */ > setreuid(getuid,getuid); > execle("/bin/sh", "sh", "-i", NULL); > } > return(fdm); > } > > Plus two or three lines down in OpenModem() (in modem.c) to get it > to recognize "pty" as a device type, and call the previous function. > > I suspect the problem is that getuid is a function.... Why is all this necessary ? Are you trying to do something smarter than chat can handle ? -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Tue Feb 11 13:15:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA18854 for hackers-outgoing; Tue, 11 Feb 1997 13:15:11 -0800 (PST) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA18842 for ; Tue, 11 Feb 1997 13:15:00 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by mail.crl.com with SMTP id AA19497 (5.65c/IDA-1.5 for ); Tue, 11 Feb 1997 13:13:42 -0800 Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id OAA15930 for freebsd-hackers@freebsd.org; Tue, 11 Feb 1997 14:10:38 -0800 (PST) Message-Id: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit Mime-Version: 1.0 Date: Tue, 11 Feb 1997 13:38:03 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: freebsd-hackers@freebsd.org Subject: Raw I/O Question Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Can someone take a moment and describe briefly the execution path of a lseek/read/write system call to a raw (character) SCSI partition? We are very interested in the most optimal, shortest path to I/O on a large number of disks. We performed some measurements and see some results we would like to understand; For example, we did READ and WRITE to random records in a block device. The test was run several times, each using a different block size (starting at 512 bytes and ending with 128KB). All our measurements are in I/O Transfers/Sec. We see a depression in READ and WRITE performance, until block size reaches 2K. At this point performance picks up and levels off until block size reaches 8KB. At this point it starts gradual, linear decline. What we see is a flat WRITE response until 2K. then it starts a linear decline until it reaches 8K block size. At this point it converges with READ performance. The initial WRITE performance, for small blocks is quite poor compared to READ. We attribute it to the need to do read-modify-write when blocks are smaller than a certain ``natural block size (page?). Another attribute of performance loss, we think to be the lack of O_SYNC) option to the write(2) system call. This forces the application to do an fsync after EVERY WRITE. We have to do that for many good reasons. The READ performance is even more peculiar. It starts higher than WRITE, declines rapidly until block size reaches 2K. It peaks at 4K blocks and starts a linear decline from that point on (as block size increases). We intend to use the RAW (character) device with the mpool buffering system and would like to understand its behavior without reading the WHOLE kernel source :-) We are very interested in the flow of control and flow of data. How do synchronous WRITE operations pass through? We need this to guarantee transaction completion (commits) There are several problems here we want to understand: How does the system call logic transfer control to the SCSI layer? All we see is the condtruction of a struct buf and a call to scsi_scsi_cmd. How is the SCSI FLUSH CACHE passed down? We may need to trap it in the HBA driver, so the HBA can flush its buffers too. What block size I/O do we need so that we do not ever do read-modify-write? This sort of questions... Easy stuf... I hope this community (which has welcomed me very warmly and has been so helpful, will find these questions useful. Maybe when one of us is older and has more time on their hands {s}he will write``FreeBSD Internals'' book and all will be well in Zion... Simon From owner-freebsd-hackers Tue Feb 11 13:57:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA21974 for hackers-outgoing; Tue, 11 Feb 1997 13:57:38 -0800 (PST) Received: from relay-7.mail.demon.net (relay-7.mail.demon.net [194.217.242.9]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA21969 for ; Tue, 11 Feb 1997 13:57:35 -0800 (PST) Received: from awfulhak.demon.co.uk ([158.152.17.1]) by relay-5.mail.demon.net id aa507880; 11 Feb 97 20:58 GMT Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.7.3) with ESMTP id UAA12481; Tue, 11 Feb 1997 20:50:25 GMT Message-Id: <199702112050.UAA12481@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Charles Mott cc: Jamie Bowden , freebsd-hackers@freebsd.org Subject: Re: Bus Errors In-reply-to: Your message of "Sun, 09 Feb 1997 19:57:39 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Feb 1997 20:50:25 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I've seen it a few times with the ppp+pktAlias1.9. It doesn't appear to > be getting malloc() errors, though. I see the problem with an ISP > connection that is really unreliable. Is anyone working on lqr for ppp? > > Is this type of post too off-target for -hackers? I'll approach the lqr problems as soon as I get a reliable phone line.... or maybe I'll start with a ppp link to another FreeBSD box. The malloc() problem is top of my list now - not much work really, it's just a matter (as Joerg also pointed out) of calling all the signal handlers from the top-level loop (rather than just the SIGALRM one). -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Tue Feb 11 14:13:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA23054 for hackers-outgoing; Tue, 11 Feb 1997 14:13:15 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA23049 for ; Tue, 11 Feb 1997 14:13:13 -0800 (PST) Received: from vdp01.vailsystems.com (root@vdp01.vailsystems.com [207.152.98.18]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id OAA01836 for ; Tue, 11 Feb 1997 14:13:09 -0800 (PST) Received: from crocodile.vale.com (crocodile [204.117.217.147]) by vdp01.vailsystems.com (8.8.3/8.7.3) with ESMTP id QAA05020; Tue, 11 Feb 1997 16:13:01 -0600 (CST) Received: from jaguar (jaguar.vale.com [204.117.217.146]) by crocodile.vale.com (8.8.3/8.7.3) with SMTP id QAA01054; Tue, 11 Feb 1997 16:13:00 -0600 (CST) Message-ID: <3300EEED.6DE8@vailsys.com> Date: Tue, 11 Feb 1997 16:13:01 -0600 From: Hal Snyder Reply-To: hal@vailsys.com Organization: Vail Systems, Inc. X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: Peter da Silva CC: hackers@freebsd.org Subject: Re: Utility routines: variable length strings, checked malloc, argv building, symbol table, and file scanning... References: <199702101507.JAA11865@bonkers.taronga.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Peter da Silva wrote: > Look in ~pds/utilib.shar on freefall. These should be useful, especially in > setuid programs that need to do a bunch of this sort of thing dynamically. Where? Couldn't find it. How do they compare with obstacks? http://www.cs.utah.edu/csinfo/texinfo/glibc-manual-0.02/library_3.html#SEC33 From owner-freebsd-hackers Tue Feb 11 14:44:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA25932 for hackers-outgoing; Tue, 11 Feb 1997 14:44:17 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA25846 for ; Tue, 11 Feb 1997 14:44:02 -0800 (PST) Received: from dialup-usr11.etinc.com (dialup-usr11.etinc.com [204.141.95.132]) by etinc.com (8.8.3/8.6.9) with SMTP id RAA26261 for ; Tue, 11 Feb 1997 17:47:17 -0500 (EST) Message-Id: <3.0.32.19970211174133.00ab1934@etinc.com> X-Sender: dennis@etinc.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 11 Feb 1997 17:41:37 -0500 To: hackers@freebsd.org From: dennis Subject: de0 - 100Mb setup Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk We have an auto-sense 10/100 card with the de0 driver that come up at 100Mbs on a 10Mb/s network on boot. 1) is there a flag to force this to 10Mbs 2) using the generic boot installation floppy, is there a way to force it to 10mbs? Thanks, dennis From owner-freebsd-hackers Tue Feb 11 14:49:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA26236 for hackers-outgoing; Tue, 11 Feb 1997 14:49:23 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA26223 for ; Tue, 11 Feb 1997 14:49:12 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA29164; Tue, 11 Feb 1997 15:44:05 -0700 From: Terry Lambert Message-Id: <199702112244.PAA29164@phaeton.artisoft.com> Subject: Re: Raw I/O Question To: Shimon@i-Connect.Net (Simon Shapiro) Date: Tue, 11 Feb 1997 15:44:04 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "Simon Shapiro" at Feb 11, 97 01:38:03 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Can someone take a moment and describe briefly the execution path of a > lseek/read/write system call to a raw (character) SCSI partition? You skipped a specification step: the FS layout on that partition. I will assume FFS with 8k block size (the default). I will also assume your lseek is absolute or relative to the start of the file (no VOP_GETATTR needed to find the current end of the file). I will take a gross stab at this; clearly, I can't include everything, and the Lite2 changes aren't reflected. I expect I will be corrected wherever I have erred. lseek -> lseek syscall -> set offset in fdesc -> return( 0); (one could argue that there should be a VOP_LSEEK at this point to allow for predictive read-ahead using the lseek offset -- there is not) read -> read syscall -> fill out uio struct -> call VOP_READ using bogus fileops struct dereference which is there because named pipes and UNIX domain sockets aren't in the VFS like they should be -> ffs_read (/sys/ufs/ufs/ufs_readwrite.c:READ) -> (called iteratively) bread -> getblk (in cache? No?) -> vfs_busy_pages VOP_STRATEGY -> VCALL strategy routine for device vnode -> spec_strategy (/sys/miscfs/specfs/spec_vnops.c) -> call device strategy through bdevsw[] -> generic scsi (scbus [bus interface]/sd [disk interface] -> actual controller requests biowait uiomove -> copyout write -> write syscall -> fill out uio struct -> call VOP_WRITE using bogus fileops struct dereference which is there because named pipes and UNIX domain sockets aren't in the VFS like they should be -> ffs_write (/sys/ufs/ufs/ufs_readwrite.c:WRITE) -> (called iteratively) (partial FS block? !!!CALL READ!!! -> fill in modified areas of partial FS block (uiomove) -> copyin bwrite ... > We are very interested in the most optimal, shortest path to I/O on > a large number of disks. o Write in the FS block size, not the disk block size to avoid causing a read before the write can be done o Do all I/O on FS block boundries o Use the largest FS block size you can o Used CCD to implement striping o Use a controller that supports tagged command queueing o Use disk drives with tack write caching (they use the rotational speed of the disk to power writes after a power failure, so writes can be immediately ack'ed even though they haven't really bee written). > > We performed some measurements and see some results we would like to > understand; > > For example, we did READ and WRITE to random records in a block device. > The test was run several times, each using a different block size > (starting at 512 bytes and ending with 128KB). All our measurements > are in I/O Transfers/Sec. DEFINITION: Random reads/writes: "please remove any cache effects from my testing, I believe my app will be a cache-killer, so I don't want cache to count for anything because I have zero locality of reference". > We see a depression in READ and WRITE performance, until block size > reaches 2K. At this point performance picks up and levels off until > block size reaches 8KB. At this point it starts gradual, linear > decline. The FS block size is 8k. The OS page size is 4k. Your random access (zero locality of reference: a hard thing to find in the real world) prevent the read-ahead from being invoked. The best speed will be at FS block size, since all reads and writes are in terms of chunks in FS block size, some multiple of the page size (in general, assuming you want it to be fast). The smaller your block size, the more data you have to read of of disk for your write. The VM system has an 8 bit bitmap, one bit per 512b (physical disk block) in a 4k (VM page size) page. This bitmap is, unfortunately, not used for read/write, or your aligned 512b blocks would not have to actually read 4k of data off the disk to write the 512b you want to write. The problem here is that you can not insure write fault granularity to better than your page size. The funny thing is, the i386 will not write fault a modification from protected mode (kernel code), so it has to fake this anyway -- so it's *possible* to fake it, and it would, in general, be a win for writes on disk block boundries for some multiple of disk block size (usually 512b for disks, 1k for writeable optical media). Talk to John Dyson about this optimization. Don't expect an enthusiastic response: real work utilization is seldom well aligned... this is a "benchmark optimization". > What we see is a flat WRITE response until 2K. then it starts a linear > decline until it reaches 8K block size. At this point it converges > with READ performance. The initial WRITE performance, for small blocks > is quite poor compared to READ. We attribute it to the need to do > read-modify-write when blocks are smaller than a certain ``natural block > size (page?). Yes. But the FS block size s 8k, not pagesize (4k). > Another attribute of performance loss, we think to be the > lack of O_SYNC) option to the write(2) system call. This forces the > application to do an fsync after EVERY WRITE. We have to do that for > many good reasons. There is an option O_WRITESYNC. Use it, or fcntl() it on. You will take a big hit for using it, however; the only overhead difference will be the system call overhead for implementing the protection domain crossing for the fsync() call. Most likely, you do not really need this, or you are poorly implementing the two stage commit process typical of most modern database design. > The READ performance is even more peculiar. It starts higher than > WRITE, declines rapidly until block size reaches 2K. It peaks at 4K > blocks and starts a linear decline from that point on (as block size > increases). This is because of precache effects. Your "random" reads are not "random" enough to get rid of cache effects, it seems. If they were, the 4k numbers would be worse, and the peak would be the FS block size. > We intend to use the RAW (character) device with the mpool buffering > system and would like to understand its behavior without reading the > WHOLE kernel source :-) The VM and buffer cache have been unified. bread/bwrite are, in fact, page fault operations. Again, talk to John Dyson about the bitmap optimization for representing partially resident pages at this level; otherwise, you *must* fault the data in and out on page boundries, and the fault will be in page groups of FS blocksize in size. > We are very interested in the flow of control and flow of data. Jorg, Julian, and the specific SCSI driver authors are probably your best resource below the bdevsw[] layer. > > How do synchronous WRITE operations pass through? We need this to > guarantee transaction completion (commits) They are written using a write operation which block until the data has been committed. Per the definition of O_WRITESYNC. > There are several problems here we want to understand: > > How does the system call logic transfer control to the SCSI layer? See above. > All we see is the condtruction of a struct buf and a call to > scsi_scsi_cmd. How is the SCSI FLUSH CACHE passed down? We may need > to trap it in the HBA driver, so the HBA can flush its buffers too. I believe this is handled automatically in all but one cae (there is a debug sysctl in the ufs code for this case, actually). > What block size I/O do we need so that we do not ever do > read-modify-write? FS block size -- 8k by default, differentif you installed with non-default values. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Feb 11 14:59:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA26962 for hackers-outgoing; Tue, 11 Feb 1997 14:59:24 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA26957 for ; Tue, 11 Feb 1997 14:59:21 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id XAA17582; Tue, 11 Feb 1997 23:12:58 +0100 From: Luigi Rizzo Message-Id: <199702112212.XAA17582@labinfo.iet.unipi.it> Subject: Re: IRda To: Dirk.vanGulik@jrc.it (Dirk.vanGulik) Date: Tue, 11 Feb 1997 23:12:58 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <9702111956.AA04876@ jrc.it> from "Dirk.vanGulik" at Feb 11, 97 08:56:27 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Anyone working on an IRda implementation ? (Infrared stuff > portables have). > > I am at the moment; about midway with a device to do things > up to lapm/frame level. since you mention this: do you know of any infrared transceiver on the market that can be connected to a serial port ? Thanks Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Tue Feb 11 15:21:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA28041 for hackers-outgoing; Tue, 11 Feb 1997 15:21:38 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA28031 for ; Tue, 11 Feb 1997 15:21:34 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA22615 for freebsd-hackers@FreeBSD.ORG; Wed, 12 Feb 1997 00:21:27 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id AAA26360; Wed, 12 Feb 1997 00:04:37 +0100 (MET) Message-ID: Date: Wed, 12 Feb 1997 00:04:37 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: Raw I/O Question References: X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Simon Shapiro on Feb 11, 1997 13:38:03 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Simon Shapiro wrote: > Can someone take a moment and describe briefly the execution path of a > lseek/read/write system call to a raw (character) SCSI partition? I can't explain your observed behaviour, but here's the rough picture: . every call has to walk down through the upper VFS layers, until it eventually will arrive in specfs_vfsops (that's where the operations to /dev nodes end up) . lseek()'s are no-ops wrt. the drive operation, they are just noted by the VFS layers to later setup the request . read and write ops are finally being handed off to rawread(9) or rawrite(9), which will in turn call physio(9) (actually writing these man pages is left as an exercise to you :-) . physio will setup a buffer header for the request, call the device strategy routine, and wait for completion . the SCSI drivers attempt to issue the READ or WRITE commands for the full range as specified by the buffer header at once; since these commands take both, offset and length parameters, no separate SCSI operation is required to formulate the seek operation -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Tue Feb 11 15:22:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA28084 for hackers-outgoing; Tue, 11 Feb 1997 15:22:21 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA28077 for ; Tue, 11 Feb 1997 15:22:13 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id PAA02106 for ; Tue, 11 Feb 1997 15:20:50 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA21148; Tue, 11 Feb 1997 18:20:02 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Tue, 11 Feb 1997 18:20 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id QAA10203; Tue, 11 Feb 1997 16:55:48 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id RAA03232; Tue, 11 Feb 1997 17:00:19 -0500 (EST) Date: Tue, 11 Feb 1997 17:00:19 -0500 (EST) From: Thomas David Rivers Message-Id: <199702112200.RAA03232@lakes.water.net> To: ponds!FreeBSD.org!freebsd-hackers@ucbvax.Berkeley.EDU, ponds!mitre.org!guhl@ucbvax.Berkeley.EDU Subject: Re: Fix to Interrupt/Terminate Signal causes page fault in kernel mode Cc: ponds!FreeBSD.org!freebsd-bugs@ucbvax.Berkeley.EDU Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I posted the following to freebsd-hackers and freebsd-bugs a couple > of days ago. I have fixed the problem, not by making any code > changes, but by compiling the kernel unoptimized! > > compiler: GNU gcc version 2.6.3 > > I question the wisdom of allowing the COPTFLAGS option in > /sys/386/conf/Makefile.i386 to enable optimization when > this may cause unpredictable and erroneous kernel behavior. > > Any opinions? > Yep - As a compiler writer, I "hear" this all the time. There are several situations where erroneous C code can behave this way. Usually, these involve taking the address of an automatic variable, and saving that after the routine has ended. Also, in this situation, a common occurrence is to overwrite the end of an automatic array, or other variable. When compiled optimized, the frame is frequently reordered, or the function has fewer temporaries; so you are more likely to write over other "meaningful" data. Only after I have eliminated those two possibilities do I begin to investigate compiler bugs. - Dave Rivers - From owner-freebsd-hackers Tue Feb 11 15:29:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA28477 for hackers-outgoing; Tue, 11 Feb 1997 15:29:28 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA28471 for ; Tue, 11 Feb 1997 15:29:26 -0800 (PST) Received: from terminator.informatik.ba-stuttgart.de (terminator.informatik.ba-stuttgart.de [141.31.1.21]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id PAA02157 for ; Tue, 11 Feb 1997 15:29:22 -0800 (PST) Received: from helbig.informatik.ba-stuttgart.de (helbig.informatik.ba-stuttgart.de [141.31.166.22]) by terminator.informatik.ba-stuttgart.de (8.7.6/8.7.3) with ESMTP id XAA18681 for ; Tue, 11 Feb 1997 23:28:39 +0100 Received: (from helbig@localhost) by helbig.informatik.ba-stuttgart.de (8.8.5/8.8.5) id XAA01704 for hackers@freebsd.org; Tue, 11 Feb 1997 23:57:45 +0100 (MET) From: Wolfgang Helbig Message-Id: <199702112257.XAA01704@helbig.informatik.ba-stuttgart.de> Subject: CMD640b workaround - final(?) version To: hackers@freebsd.org Date: Tue, 11 Feb 1997 23:57:44 +0100 (MET) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, this is my final patch to work around the CMD640b hardware bug. This bug does not allow you to use the primary and secondary IDE-channel simultaneously, since there is only one hardware buffer for both channels. Other known bugs of the CMD640-series and the RZ1000-IDE-Chip are not addressed by this patch. Those bugs (bad prefetch buffer handling and problems resulting from interference with the floppy-controller) apparently did not occure on my system. The workaround consists mainly in serializing access to the two ide- channels. This job is done very similar to the serializing of master and slave device of one channel. It is tested by Jason and Nadav. Jason provided a version for FreeBSD 2.1.5 for the test. Thanx!!! This final version detects the presence of the CMD640-chip and enables accordingly the workaround code. This detection takes place in the pci.c file and the result is communicated to the wd.c file by the global external variable cmd640_detected. (I know this is dirty, but better ways that are still easier did not come to my mind, sorry!) For all this to take place, you still have to add the options "CMD640" line to the kernel configuration file. Without this option, the old code in wd.c and pci.c is active. With this option, the detection is made, and -- if the chip is detected -- the serialization of primary and secondary channel takes place. If you use the options "CMD640" you also *have* to put controller pci0 into your configuration file! Maybe someone can put the right clauses in /sys/conf/files to automaticly resoving this (ugly) dependency! This code is tested with the GENERIC- and a customized kernel, but it might need more testing, before it is committed to -current. I think it is too late for FreeBSD 2.2 Have fun! Wolfgang Helbig helbig@ba-stuttgart.de Following are the patches of wd.c and pci.c Index: wd.c =================================================================== RCS file: /usr/cvsroot/src/sys/i386/isa/wd.c,v retrieving revision 1.122 diff -c -r1.122 wd.c *** wd.c 1997/01/14 06:41:40 1.122 --- wd.c 1997/02/11 20:57:49 *************** *** 128,133 **** --- 128,135 ---- #define RECAL 2 /* doing restore */ #define OPEN 3 /* done with open */ + #define PRIMARY 0 + /* * Disk geometry. A small part of struct disklabel. * XXX disklabel.5 contains an old clone of disklabel.h. *************** *** 238,243 **** --- 240,250 ---- { wdopen, wdclose, wdstrategy, wdioctl, /*0*/ wddump, wdsize, 0, "wd", &wd_cdevsw, -1 }; + #ifdef CMD640 + static int atapictrlr; + extern int cmd640_detected; /* defined in pci.c */ + #endif + /* * Probe for controller. */ *************** *** 360,366 **** --- 367,384 ---- if (dvp->id_unit >= NWDC) return (0); + #ifdef CMD640 + if (cmd640_detected) { + if (dvp->id_unit == PRIMARY) { + printf("wdc0: CMD640b workaround enabled\n"); + TAILQ_INIT( &wdtab[PRIMARY].controller_queue); + } + } else + TAILQ_INIT( &wdtab[dvp->id_unit].controller_queue); + + #else TAILQ_INIT( &wdtab[dvp->id_unit].controller_queue); + #endif for (wdup = isa_biotab_wdc; wdup->id_driver != 0; wdup++) { if (wdup->id_iobase != dvp->id_iobase) *************** *** 467,480 **** if (wddrives[lunit]->dk_ctrlr == dvp->id_unit && wddrives[lunit]->dk_unit == unit) goto next; ! atapi_attach (dvp->id_unit, unit, dvp->id_iobase); next: } #endif /* * Discard any interrupts generated by wdgetctlr(). wdflushirq() * doesn't work now because the ambient ipl is too high. */ wdtab[dvp->id_unit].b_active = 2; return (1); } --- 485,510 ---- if (wddrives[lunit]->dk_ctrlr == dvp->id_unit && wddrives[lunit]->dk_unit == unit) goto next; ! if (atapi_attach (dvp->id_unit, unit, dvp->id_iobase)) { ! #ifdef CMD640 ! if (cmd640_detected) ! atapictrlr = dvp->id_unit; ! #endif ! } next: } #endif /* * Discard any interrupts generated by wdgetctlr(). wdflushirq() * doesn't work now because the ambient ipl is too high. */ + #ifdef CMD640 + if (cmd640_detected) + wdtab[PRIMARY].b_active = 2; + else + wdtab[dvp->id_unit].b_active = 2; + #else wdtab[dvp->id_unit].b_active = 2; + #endif return (1); } *************** *** 490,495 **** --- 520,528 ---- struct disk *du; int lunit = dkunit(bp->b_dev); int s; + #ifdef CMD640 + int ctrlr; + #endif /* valid unit, controller, and request? */ if (lunit >= NWD || bp->b_blkno < 0 || (du = wddrives[lunit]) == NULL *************** *** 548,555 **** --- 581,598 ---- wdsleep(du->dk_ctrlr, "wdlab"); du->dk_state = WANTOPEN; } + #ifdef CMD640 + if (cmd640_detected) + ctrlr = PRIMARY; + else + ctrlr = du ->dk_ctrlr; + #endif + #ifdef CMD640 + if (wdtab[ctrlr].b_active == 0) + #else if (wdtab[du->dk_ctrlr].b_active == 0) + #endif wdstart(du->dk_ctrlr); /* start controller */ if (du->dk_dkunit >= 0) { *************** *** 611,617 **** --- 654,669 ---- TAILQ_REMOVE( &drive_queue[du->dk_lunit], bp, b_act); /* link onto controller queue */ + #ifdef CMD640 + if (cmd640_detected) { + TAILQ_INSERT_TAIL( &wdtab[PRIMARY].controller_queue, bp, b_act); + } else { + TAILQ_INSERT_TAIL( &wdtab[ctrlr].controller_queue, bp, b_act); + } + + #else TAILQ_INSERT_TAIL( &wdtab[ctrlr].controller_queue, bp, b_act); + #endif /* mark the drive unit as busy */ wdutab[du->dk_lunit].b_active = 1; *************** *** 636,655 **** int lunit; int count; #ifdef ATAPI if (wdtab[ctrlr].b_active == 2) wdtab[ctrlr].b_active = 0; if (wdtab[ctrlr].b_active) return; - #endif /* is there a drive for the controller to do a transfer with? */ bp = wdtab[ctrlr].controller_queue.tqh_first; if (bp == NULL) { #ifdef ATAPI ! if (atapi_start && atapi_start (ctrlr)) /* mark controller active in ATAPI mode */ wdtab[ctrlr].b_active = 3; #endif return; } --- 688,737 ---- int lunit; int count; + #ifdef CMD640 + int c; + + if (cmd640_detected) + c = PRIMARY; + else + c = ctrlr; + #endif + #ifdef ATAPI + #ifdef CMD640 + if (wdtab[c].b_active == 2) + wdtab[c].b_active = 0; + if (wdtab[c].b_active) + return; + #else if (wdtab[ctrlr].b_active == 2) wdtab[ctrlr].b_active = 0; if (wdtab[ctrlr].b_active) return; /* is there a drive for the controller to do a transfer with? */ + #endif + #endif + #ifdef CMD640 + bp = wdtab[c].controller_queue.tqh_first; + #else bp = wdtab[ctrlr].controller_queue.tqh_first; + #endif if (bp == NULL) { #ifdef ATAPI ! #ifdef CMD640 ! if (cmd640_detected) { ! if (atapi_start && atapi_start (atapictrlr)) ! wdtab[c].b_active = 3; ! } else { ! if (atapi_start && atapi_start (ctrlr)) ! wdtab[ctrlr].b_active = 3; ! } ! #else /* mark controller active in ATAPI mode */ + if (atapi_start && atapi_start (ctrlr)) wdtab[ctrlr].b_active = 3; #endif + #endif return; } *************** *** 705,711 **** --- 787,797 ---- blknum - ds_offset) + ds_offset; } + #ifdef CMD640 + wdtab[c].b_active = 1; /* mark controller active */ + #else wdtab[ctrlr].b_active = 1; /* mark controller active */ + #endif /* if starting a multisector transfer, or doing single transfers */ if (du->dk_skip == 0 || (du->dk_flags & DKFL_SINGLE)) { *************** *** 717,723 **** --- 803,813 ---- head = (blknum % secpercyl) / secpertrk; sector = blknum % secpertrk; + #ifdef CDM640 + if (wdtab[c].b_errcnt && (bp->b_flags & B_READ) == 0) + #else if (wdtab[ctrlr].b_errcnt && (bp->b_flags & B_READ) == 0) + #endif du->dk_bc += DEV_BSIZE; count = howmany( du->dk_bc, DEV_BSIZE); *************** *** 863,872 **** --- 953,973 ---- { register struct disk *du; register struct buf *bp; + #ifdef CMD640 + int c ; + if (cmd640_detected) + c = PRIMARY; + else + c = unit; + if (wdtab[c].b_active == 2) + return; /* intr in wdflushirq() */ + if (!wdtab[c].b_active) { + #else if (wdtab[unit].b_active == 2) return; /* intr in wdflushirq() */ if (!wdtab[unit].b_active) { + #endif #ifdef WDDEBUG /* * These happen mostly because the power-mgt part of the *************** *** 878,895 **** --- 979,1020 ---- return; } #ifdef ATAPI + #ifdef CMD640 + if (wdtab[c].b_active == 3) { + #else if (wdtab[unit].b_active == 3) { + #endif /* process an ATAPI interrupt */ + #ifdef CMD640 + if (cmd640_detected) { + if (atapi_intr && atapi_intr (atapictrlr)) + /* ATAPI op continues */ + return; + } else { + if (atapi_intr && atapi_intr (unit)) + /* ATAPI op continues */ + return; + } + #else if (atapi_intr && atapi_intr (unit)) /* ATAPI op continues */ return; + #endif /* controller is free, start new op */ + #ifdef CMD640 + wdtab[c].b_active = 0; + #else wdtab[unit].b_active = 0; + #endif wdstart (unit); return; } #endif + #ifdef CMD640 + bp = wdtab[c].controller_queue.tqh_first; + #else bp = wdtab[unit].controller_queue.tqh_first; + #endif du = wddrives[dkunit(bp->b_dev)]; du->dk_timeout = 0; *************** *** 900,906 **** --- 1025,1035 ---- /* is it not a transfer, but a control operation? */ if (du->dk_state < OPEN) { + #ifdef CMD640 + wdtab[c].b_active = 0; + #else wdtab[unit].b_active = 0; + #endif switch (wdcontrol(bp)) { case 0: return; *************** *** 942,949 **** --- 1071,1083 ---- bp->b_error = EIO; bp->b_flags |= B_ERROR; } else if (du->dk_status & WDCS_ERR) { + #ifdef CMD640 + if (++wdtab[c].b_errcnt < RETRIES) { + wdtab[c].b_active = 0; + #else if (++wdtab[unit].b_errcnt < RETRIES) { wdtab[unit].b_active = 0; + #endif } else { wderror(bp, du, "hard error"); bp->b_error = EIO; *************** *** 957,963 **** --- 1091,1101 ---- * If this was a successful read operation, fetch the data. */ if (((bp->b_flags & (B_READ | B_ERROR)) == B_READ) + #ifdef CMD640 + && wdtab[c].b_active) { + #else && wdtab[unit].b_active) { + #endif int chk, dummy, multisize; multisize = chk = du->dk_currentiosize * DEV_BSIZE; if( du->dk_bc < chk) { *************** *** 999,1016 **** --- 1137,1168 ---- } outt: + #ifdef CMD640 + if (wdtab[c].b_active) { + #else if (wdtab[unit].b_active) { + #endif if ((bp->b_flags & B_ERROR) == 0) { du->dk_skip += du->dk_currentiosize;/* add to successful sectors */ + #ifdef CMD640 + if (wdtab[c].b_errcnt) + wderror(bp, du, "soft error"); + wdtab[c].b_errcnt = 0; + #else if (wdtab[unit].b_errcnt) wderror(bp, du, "soft error"); wdtab[unit].b_errcnt = 0; + #endif /* see if more to transfer */ if (du->dk_bc > 0 && (du->dk_flags & DKFL_ERROR) == 0) { if( (du->dk_flags & DKFL_SINGLE) || ((bp->b_flags & B_READ) == 0)) { + #ifdef CMD640 + wdtab[c].b_active = 0; + #else wdtab[unit].b_active = 0; + #endif wdstart(unit); } else { du->dk_timeout = 1 + 3; *************** *** 1021,1027 **** --- 1173,1183 ---- du->dk_skip = 0; du->dk_flags &= ~DKFL_ERROR; du->dk_flags |= DKFL_SINGLE; + #ifdef CMD640 + wdtab[c].b_active = 0; + #else wdtab[unit].b_active = 0; + #endif wdstart(unit); return; /* redo xfer sector by sector */ } *************** *** 1030,1037 **** --- 1186,1198 ---- done: ; /* done with this transfer, with or without error */ du->dk_flags &= ~DKFL_SINGLE; + #ifdef CMD640 + TAILQ_REMOVE(&wdtab[c].controller_queue, bp, b_act); + wdtab[c].b_errcnt = 0; + #else TAILQ_REMOVE(&wdtab[unit].controller_queue, bp, b_act); wdtab[unit].b_errcnt = 0; + #endif bp->b_resid = bp->b_bcount - du->dk_skip * DEV_BSIZE; wdutab[du->dk_lunit].b_active = 0; wdutab[du->dk_lunit].b_errcnt = 0; *************** *** 1044,1057 **** --- 1205,1226 ---- } /* controller idle */ + #ifdef CMD640 + wdtab[c].b_active = 0; + #else wdtab[unit].b_active = 0; + #endif /* anything more on drive queue? */ wdustart(du); /* anything more for controller to do? */ #ifndef ATAPI /* This is not valid in ATAPI mode. */ + #ifdef CMD640 + if (wdtab[c].controller_queue.tqh_first) + #else if (wdtab[unit].controller_queue.tqh_first) + #endif #endif wdstart(unit); } *************** *** 1065,1070 **** --- 1234,1242 ---- register unsigned int lunit; register struct disk *du; int error; + #ifdef CMD640 + int c; + #endif lunit = dkunit(dev); if (lunit >= NWD || dktype(dev) != 0) *************** *** 1074,1081 **** --- 1246,1263 ---- return (ENXIO); /* Finish flushing IRQs left over from wdattach(). */ + #ifdef CMD640 + if (cmd640_detected) + c = PRIMARY; + else + c = du->dk_ctrlr; + + if (wdtab[c].b_active == 2) + wdtab[c].b_active = 0; + #else if (wdtab[du->dk_ctrlr].b_active == 2) wdtab[du->dk_ctrlr].b_active = 0; + #endif du->dk_flags &= ~DKFL_BADSCAN; *************** *** 1238,1251 **** --- 1420,1446 ---- { register struct disk *du; int ctrlr; + #ifdef CMD640 + int c; + #endif du = wddrives[dkunit(bp->b_dev)]; ctrlr = du->dk_ctrlr; + #ifdef CMD640 + if (cmd640_detected) + c = PRIMARY; + else + c = ctrlr; + #endif switch (du->dk_state) { case WANTOPEN: tryagainrecal: + #ifdef CMD640 + wdtab[c].b_active = 1; + #else wdtab[ctrlr].b_active = 1; + #endif if (wdcommand(du, 0, 0, 0, 0, WDCC_RESTORE | WD_STEP) != 0) { wderror(bp, du, "wdcontrol: wdcommand failed"); goto maybe_retry; *************** *** 1259,1271 **** --- 1454,1474 ---- if (du->dk_status & WDCS_ERR) wdunwedge(du); du->dk_state = WANTOPEN; + #ifdef CMD640 + if (++wdtab[c].b_errcnt < RETRIES) + #else if (++wdtab[ctrlr].b_errcnt < RETRIES) + #endif goto tryagainrecal; bp->b_error = ENXIO; /* XXX needs translation */ bp->b_flags |= B_ERROR; return (2); } + #ifdef CMD640 + wdtab[c].b_errcnt = 0; + #else wdtab[ctrlr].b_errcnt = 0; + #endif du->dk_state = OPEN; /* * The rest of the initialization can be done by normal *************** *** 1373,1379 **** --- 1576,1589 ---- error = 1; } if (error) { + #ifdef CMD640 + if (cmd640_detected) + wdtab[PRIMARY].b_errcnt += RETRIES; + else + wdtab[du->dk_ctrlr].b_errcnt += RETRIES; + #else wdtab[du->dk_ctrlr].b_errcnt += RETRIES; + #endif return (1); } if (wdcommand(du, du->dk_dd.d_ncylinders, du->dk_dd.d_ntracks - 1, 0, *************** *** 1750,1759 **** if (wddoingadump) return (EFAULT); - #if 0 - /* Mark controller active for if we panic during the dump. */ - wdtab[du->dk_ctrlr].b_active = 1; - #endif wddoingadump = 1; /* Recalibrate the drive. */ --- 1960,1965 ---- *************** *** 1900,1909 **** --- 2106,2125 ---- static void wdflushirq(struct disk *du, int old_ipl) { + #ifdef CMD640 + int c = du->dk_ctrlr; + if (cmd640_detected) + c = PRIMARY; + wdtab[c].b_active = 2; + splx(old_ipl); + (void)splbio(); + wdtab[c].b_active = 0; + #else wdtab[du->dk_ctrlr].b_active = 2; splx(old_ipl); (void)splbio(); wdtab[du->dk_ctrlr].b_active = 0; + #endif } /* *************** *** 1943,1950 **** --- 2159,2175 ---- wdsleep(int ctrlr, char *wmesg) { int s = splbio(); + #ifdef CMD640 + int c = ctrlr; + + if (cmd640_detected) + c = PRIMARY; + while (wdtab[c].b_active) + tsleep((caddr_t)&wdtab[PRIMARY].b_active, PZERO - 1, wmesg, 1); + #else while (wdtab[ctrlr].b_active) tsleep((caddr_t)&wdtab[ctrlr].b_active, PZERO - 1, wmesg, 1); + #endif splx(s); } ----------------------------------------------------------------------------- Index: pci.c =================================================================== RCS file: /usr/cvsroot/src/sys/pci/pci.c,v retrieving revision 1.65 diff -c -r1.65 pci.c *** pci.c 1997/02/05 07:23:56 1.65 --- pci.c 1997/02/11 20:27:40 *************** *** 148,153 **** --- 148,156 ---- * for the Orion host to PCI bridge * UGLY hack ... :( Will be changed :) */ + #ifdef CMD640 + int cmd640_detected = 0; + #endif /*-------------------------------------------------------- ** ** Local variables. *************** *** 728,733 **** --- 731,740 ---- if ((!type) || (type==0xfffffffful)) continue; + #ifdef CMD640 + if (type == 0x06401095) + cmd640_detected = 1; + #endif /* ** lookup device in ioconfiguration: */ From owner-freebsd-hackers Tue Feb 11 15:38:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA29211 for hackers-outgoing; Tue, 11 Feb 1997 15:38:20 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA29206 for ; Tue, 11 Feb 1997 15:38:12 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id KAA08552; Wed, 12 Feb 1997 10:07:45 +1030 (CST) From: Michael Smith Message-Id: <199702112337.KAA08552@genesis.atrad.adelaide.edu.au> Subject: Re: Freewin95 - just fyi In-Reply-To: from Warner Losh at "Feb 11, 97 08:30:50 am" To: imp@village.org (Warner Losh) Date: Wed, 12 Feb 1997 10:07:44 +1030 (CST) Cc: dkelly@hiwaay.net, kuku@gilberto.physik.rwth-aachen.de, freebsd-hackers@freefall.freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Warner Losh stands accused of saying: > In message <199702110508.XAA18146@nexgen.ampr.org> dkelly@hiwaay.net writes: > : Am wondering if it isn't April 1, 2000 already, somewhere in the world. :-) > > It looked really good until I read the part of about him losing his > head of something or other before coding had begun due to a > personality dispute... Does this remind anyone of the old 'Apple product design process' flowchart? The one that started "Announce product", "Print T-shirts", etc.? > Warner -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Tue Feb 11 16:18:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA01507 for hackers-outgoing; Tue, 11 Feb 1997 16:18:17 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA01498 for ; Tue, 11 Feb 1997 16:18:12 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id QAA23787; Tue, 11 Feb 1997 16:17:52 -0800 (PST) Message-Id: <199702120017.QAA23787@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: "Dirk.vanGulik" cc: hackers@FreeBSD.ORG Subject: Re: IRda In-reply-to: Your message of "Tue, 11 Feb 1997 20:56:46 +0100." <9702111956.AA04876@ jrc.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Feb 1997 16:17:52 -0800 From: Amancio Hasty Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Check out the multimedia web page on http://www.freebsd.org and or post on the multimedia mailing list all the crazy multimedia guys including me hang out over there. Regards, Amancio >From The Desk Of "Dirk.vanGulik" : > Anyone working on an IRda implementation ? (Infrared stuff > portables have). > > I am at the moment; about midway with a device to do things > up to lapm/frame level. > > Anyone have a device number for that ? > > Tha ! > > Dw. > From owner-freebsd-hackers Tue Feb 11 17:04:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA05055 for hackers-outgoing; Tue, 11 Feb 1997 17:04:47 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA05050 for ; Tue, 11 Feb 1997 17:04:45 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id RAA02561 for ; Tue, 11 Feb 1997 17:03:11 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id LAA09409 for hackers@freebsd.org; Wed, 12 Feb 1997 11:32:14 +1030 (CST) From: Michael Smith Message-Id: <199702120102.LAA09409@genesis.atrad.adelaide.edu.au> Subject: mdoc help? To: hackers@freebsd.org Date: Wed, 12 Feb 1997 11:32:13 +1030 (CST) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Rrrg. Manpages. 8( I'm trying to write some mdoc that will produce output looking like : txpulse tdelay dpgap [blen nbaud deex trse pwcal] Configures transmitter pulse control signals from the Transmitter Control module. ... I'm using code that looks like : .Bl -tag -width 5n ... .It Ic txpulse Ar tdelay dpgap Op Ar blen nbaud deex trse pwcal Configures transmitter pulse control signals from the Transmitter Control module. Unfortunately, that's too many arguments for the .Ic macro 8( If I try to split it over several lines, I get the sections on following lines seperated from the list tag, and they get associated with the paragraph instead. Any *roff wizards have any ideas on this one? It's bugging me something fierce 8( -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Tue Feb 11 17:09:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA05343 for hackers-outgoing; Tue, 11 Feb 1997 17:09:29 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA05338 for ; Tue, 11 Feb 1997 17:09:24 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id BAA05237; Wed, 12 Feb 1997 01:08:34 GMT Date: Wed, 12 Feb 1997 10:08:34 +0900 (JST) From: Michael Hancock To: dennis cc: hackers@FreeBSD.ORG Subject: Re: de0 - 100Mb setup In-Reply-To: <3.0.32.19970211174133.00ab1934@etinc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk link2 Mike On Tue, 11 Feb 1997, dennis wrote: > > We have an auto-sense 10/100 card with the de0 driver that come up > at 100Mbs on a 10Mb/s network on boot. > > 1) is there a flag to force this to 10Mbs > 2) using the generic boot installation floppy, is there a way to > force it to 10mbs? > > Thanks, > > dennis From owner-freebsd-hackers Tue Feb 11 18:31:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA11574 for hackers-outgoing; Tue, 11 Feb 1997 18:31:50 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA11569 for ; Tue, 11 Feb 1997 18:31:46 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id SAA03327 for ; Tue, 11 Feb 1997 18:31:35 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id CAA06559; Wed, 12 Feb 1997 02:28:25 GMT Date: Wed, 12 Feb 1997 11:28:24 +0900 (JST) From: Michael Hancock To: dk+@ua.net cc: Alexander Snarskii , freebsd-hackers@FreeBSD.org Subject: Re: Increasing overall security.... In-Reply-To: <199702110604.WAA14933@dog.farm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 10 Feb 1997, Dmitry Kohmanyuk wrote: > In article <199702091525.RAA05048@burka.carrier.kiev.ua> you wrote: > > 'Why don't rewrite that functions to check the stack integrity > > before return?' says Oleg Panaschenko sometimes ago, and after > > some reflections i found that that is not so bad idea. Yes, we're > > getting some overhead with using these functions rather than > > with standard ones, but, as for me, this overhead is not so big > > and a reason, that i can sleep without nightmares about another > > stack overflow exploits is much important for me. > > that's very good idea. I don't understand the reasons from other people > responding to this negatively. Speaking for myself. The author's original argument for this patch seemed to be because there was no "Theo" in the FreeBSD group. He was unaware of the current situation and I informed him. To play devil's advocate... 1) It requires assembler which is harder to understand. Less people are qualified to review it. Relying on something harder to understand for security is questionable. 2) We don't know if it operates correctly. Sendmail 8.8.5 has around 106 strcpy's in it and we don't know what the patch's effect will be in a production environment. The author should probably instead try to get people to apply it in their own environments and test it for him. If there is enough popular demand then people might make more effort to commit it. Just out of curiosity has this patch been submitted to OpenBSD? Maybe future posts should be directed to security. Regards, Mike Hancock From owner-freebsd-hackers Tue Feb 11 19:13:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA14364 for hackers-outgoing; Tue, 11 Feb 1997 19:13:35 -0800 (PST) Received: from werple.net.au (melb.werple.net.au [203.9.190.18]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA14311 for ; Tue, 11 Feb 1997 19:10:54 -0800 (PST) Received: (qmail 21899 invoked by uid 5); 12 Feb 1997 03:10:25 -0000 MBOX-Line: From jb@freebsd1.cimlogic.com.au Wed Feb 12 14:10:36 1997 Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.7.5/8.7.3) id OAA08085 for hackers@freebsd.org; Wed, 12 Feb 1997 14:10:36 +1100 (EST) From: John Birrell Message-Id: <199702120310.OAA08085@freebsd1.cimlogic.com.au> Subject: MIME applications for FreeBSD To: hackers@freebsd.org Date: Wed, 12 Feb 1997 14:10:35 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk G'day, I'm curious about what people regard as typical MIME applications that a site is expected to support. The volume of business email containing MIME "application/msword" has now exceeded my level of tolerance. When I consider changing ISPs and they send the application form MIME encoded for an application I do not have... When I receive support updates from a company we _pay_ for support and they send them MIME encoded... Grrr. Enough! Opinions? Regards, -- John Birrell - jb@cimlogic.com.au; jb@netbsd.org CIMlogic Pty Ltd, 119 Cecil Street, South Melbourne Vic 3205, Australia Tel +61 3 9690 6900 Fax +61 3 9690 6650 Mob +61 418 353 137 From owner-freebsd-hackers Tue Feb 11 20:39:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA24293 for hackers-outgoing; Tue, 11 Feb 1997 20:39:42 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA24269 for ; Tue, 11 Feb 1997 20:39:27 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id PAA30454; Wed, 12 Feb 1997 15:34:42 +1100 Date: Wed, 12 Feb 1997 15:34:42 +1100 From: Bruce Evans Message-Id: <199702120434.PAA30454@godzilla.zeta.org.au> To: freebsd-hackers@freebsd.org, Shimon@i-Connect.Net Subject: Re: Raw I/O Question Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >For example, we did READ and WRITE to random records in a block device. It's usually a mistake to use the block device . It is not raw. It has a braindamaged default block size (BLKDEV_IOSIZE = 2048). Write errors on it can't be reported to the application. Benchmarks on it aren't interesting. >We see a depression in READ and WRITE performance, until block size >reaches 2K. At this point performance picks up and levels off until >block size reaches 8KB. At this point it starts gradual, linear >decline. 2K is magic (see above). I would expect read and write performance to increase with the size below 2K too. I would expect performance to be abysmal for all sizes unless the controller and drive very low command overhead and/or very effective caching. Bruce From owner-freebsd-hackers Tue Feb 11 20:47:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA25238 for hackers-outgoing; Tue, 11 Feb 1997 20:47:05 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA25231 for ; Tue, 11 Feb 1997 20:47:02 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id UAA12364 for ; Tue, 11 Feb 1997 20:47:00 -0800 (PST) To: hackers@freebsd.org Subject: Security Advisory - Recent compromise of freefall.freebsd.org Date: Tue, 11 Feb 1997 20:47:00 -0800 Message-ID: <12361.855722820@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Overview: The following advisory documents a recent security compromise on freefall.freebsd.org, the FreeBSD Project's master source repository machine, discussing some of the potential ramifications of the event and the recovery measures which are being carried out in its aftermath. Since investigation is still ongoing and at least one law enforcement agency is currently involved, some details will, of necessity, need to be deliberately vague or even omitted entirely for now. We apologize for this and promise to keep everyone as up-to-date as possible on events as the situation progresses, releasing information as we're allowed and deem it prudent. Anyone with an account on freefall.freebsd.org is strongly advised to *CHANGE THEIR PASSWORD*, both on freefall and on any other machines where the same password is used. Based on the Trojan horses we found, you should assume that your password was grabbed and transmitted to a hostile 3rd party if you logged in at any time on or after January 18th, 1997. It does not matter if you logged in with ssh or with telnet, you should assume that your password has been collected. Furthermore, if you used ssh, rlogin or telnet on freefall to go *out* to other machines then you should assume that password information given to these programs was also compromised. Details: The break-ins occurred on at least 2 cdrom.com machines, root being compromised in both instances, and numerous system binaries had Trojan horses inserted for the purpose of gathering and sending back password information. The method of entry used by the attacker(s) is not so important given that both systems were vulnerable to several significant, now known, security exploits at the time and any one of them could have been used to gain entry & root privilege. What is more interesting about this attack is the sophistication of the Trojan horses left behind, assembled as they were from a rather sophisticated "kit" put together by someone who clearly knew their way around a BSD system. This told us that we should not take this attack as just another incident of juvenille pranksterism but as something rather more serious. Since the CVS master repository machine was attacked, it would also be an immediate and obvious concern that the intruder may have taken advantage of their temporary root privileges to make modifications to the FreeBSD master source repository, possibly to introduce back-doors for later use or cause deliberate embarrassment by introducing catastrophic failure modes. Fortunately, neither scenario is as fearsome as it might seem. For one thing, the CVS repository is replicated on hundreds of machines now, all syncing up with varying degrees of (deliberate) latency, and "CTM deltas" are also made continuously from this repository. These streams of CTM information can show exactly what changed from moment to moment in the source tree, entirely independently of the CVS mechanisms (which might be compromised) for doing so. There is also the fact that there are many, many eyes on the FreeBSD source tree right now, more than most of us probably ever thought possible in the beginning, and it's hard to believe that someone would be able to slip a significant attack past the eyes of that many people, watching their daily CTM deltas come by and reviewing, as they do, each change with heavy skepticism before bringing it into their own source trees. To date, no reports of anything suspicious have been received. In summary: We will continue to review our CTM deltas and we will look for signs of skullduggery, but we frankly feel that the real dangers here lie not so much in recently introduced changes, which are easily reviewed for and caught, but in those accidental security holes which have been buried in the BSD code for months or possibly years. Since security seems to have become the theme of the month, and many people have volunteered (in light of our recent 2.1.6 security fracas) to begin a much more serious and comprehensive security audit, we will take advantage of this opportunity to see that all code in the FreeBSD source tree, old and new alike, is reviewed line by line for buffer overflows, unguarded copies, back doors, whatever. We may not make it through every last byte, but we can certainly focus on the "hot spots" (suid programs and system utilities) and do our best to prevent problems like those which caused our recent headaches from reoccuring. This advisory is simply to inform those people who have used freefall in the last 40 days or so that they should change their passwords and to explain to people that yes, there was a break-in to freefall.freebsd.org and yes, we're aware of the issues this raises, both now and in the immediate future, and that we will be exerting significant effort over the next few weeks in dealing aggressively with security issues, both in FreeBSD and on the FreeBSD project machines. FreeBSD Auditing Project: Those interested in participating in "The Great Code Sweep", more officially known as the FreeBSD Auditing Project, should also send mail to me . I'll be working over the next 2 days on dividing /usr/src into reasonable, prioritized, chunks (there, I used "prioritized" in a sentence - I've always wanted to do that) and talking with the volunteer auditors about how to split the work up amongst everyone. Then we'll dive in and go to work! I'll be posting more details on just what it is we're looking for, and how to communicate changes back if you don't have commit access, in the coming days on the current@freebsd.org mailing list. Highlights will also be sent to announce@freebsd.org, including a second call for auditors and full instructions on how to participate, so hopefully no one should miss it. Thanks. Jordan From owner-freebsd-hackers Tue Feb 11 21:22:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA29776 for hackers-outgoing; Tue, 11 Feb 1997 21:22:19 -0800 (PST) Received: from ns.newreach.net (root@ns.newreach.net [206.25.170.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA29769 for ; Tue, 11 Feb 1997 21:22:13 -0800 (PST) Received: from phoenix.aristar.com (ip80.akron.newreach.net [206.25.171.80]) by ns.newreach.net (8.8.4/8.6.9) with SMTP id AAA12473; Wed, 12 Feb 1997 00:21:53 -0500 (EST) Message-ID: <33015378.7DE14518@aristar.com> Date: Wed, 12 Feb 1997 00:22:00 -0500 From: "Matthew A. Gessner" Organization: Aristar, Inc. X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.1.0-RELEASE i386) MIME-Version: 1.0 To: Luigi Rizzo CC: "Dirk.vanGulik" , hackers@FreeBSD.ORG Subject: Re: IRda References: <199702112212.XAA17582@labinfo.iet.unipi.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo wrote: > > > Anyone working on an IRda implementation ? (Infrared stuff > > portables have). > > > > I am at the moment; about midway with a device to do things > > up to lapm/frame level. > > since you mention this: do you know of any infrared transceiver on the > market that can be connected to a serial port ? > > Thanks > Luigi > -----------------------------+-------------------------------------- > Luigi Rizzo | Dip. di Ingegneria dell'Informazione > email: luigi@iet.unipi.it | Universita' di Pisa > tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) > fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ > _____________________________|______________________________________ AAMOF: Red Eye by Belden. About $50 US. There are others. Check out the IRDa home page at: http://www.irda.org -- Matthew Gessner, Computer Scientist, Aristar, Inc. 302 N. Cleveland-Massillon Rd. Akron, OH 44333 Voice (330) 668-2267, Fax (330) 668-2961 From owner-freebsd-hackers Tue Feb 11 22:34:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA06877 for hackers-outgoing; Tue, 11 Feb 1997 22:34:25 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA06867 for ; Tue, 11 Feb 1997 22:34:16 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id XAA21000; Tue, 11 Feb 1997 23:32:50 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199702112244.PAA29164@phaeton.artisoft.com> Date: Tue, 11 Feb 1997 22:49:46 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: Terry Lambert Subject: Re: Raw I/O Question Cc: freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Terry Lambert; On 11-Feb-97 you wrote: > > Can someone take a moment and describe briefly the execution path of a > > lseek/read/write system call to a raw (character) SCSI partition? > > You skipped a specification step: the FS layout on that partition. > I will assume FFS with 8k block size (the default). I skipped nothing :-) there is NO file system on the partition. Just a simple file (partitions are files. not in a file system, but files. Right? :-) > I will also assume your lseek is absolute or relative to the start > of the file (no VOP_GETATTR needed to find the current end of the > file). Yes. > I will take a gross stab at this; clearly, I can't include everything, > and the Lite2 changes aren't reflected. I expect I will be corrected > wherever I have erred. > > lseek > -> lseek syscall > -> set offset in fdesc > -> return( 0); > > (one could argue that there should be a VOP_LSEEK at > this point to allow for predictive read-ahead using > the lseek offset -- there is not) > > read > -> read syscall > -> fill out uio struct > -> call VOP_READ using bogus fileops struct dereference > which is there because named pipes and UNIX domain > sockets aren't in the VFS like they should be > -> ffs_read (/sys/ufs/ufs/ufs_readwrite.c:READ) > -> (called iteratively) > bread > -> getblk > (in cache? No?) > -> vfs_busy_pages > VOP_STRATEGY > -> VCALL strategy routine for device vnode > -> spec_strategy (/sys/miscfs/specfs/spec_vnops.c) > -> call device strategy through bdevsw[] > -> generic scsi (scbus [bus interface]/sd [disk > interface] > -> actual controller requests > biowait > uiomove > -> copyout > > write > -> write syscall > -> fill out uio struct > -> call VOP_WRITE using bogus fileops struct dereference > which is there because named pipes and UNIX domain > sockets aren't in the VFS like they should be > -> ffs_write (/sys/ufs/ufs/ufs_readwrite.c:WRITE) > -> (called iteratively) > (partial FS block? !!!CALL READ!!! > -> fill in modified areas of partial FS block > (uiomove) > -> copyin > bwrite > ... Excellet! Thank you very much! I leave it here so those who missed it get a second chance. > > We are very interested in the most optimal, shortest path to I/O on > > a large number of disks. > > o Write in the FS block size, not the disk block size to > avoid causing a read before the write can be done No file system. See above. What is the block size used then? > o Do all I/O on FS block boundries > o Use the largest FS block size you can > o Used CCD to implement striping > o Use a controller that supports tagged command queueing > o Use disk drives with tack write caching (they use the > rotational speed of the disk to power writes after a > power failure, so writes can be immediately ack'ed even > though they haven't really bee written). All these, stripping off the file system pointers, as they do not apply) are good and valid, except: 1. We have to guarantee transactions. This means that system failure, at ANY time cannot ``undo'' what is said to be done. IOW, a WRITE call that returns positively, is known to have been recorded, on error/failure resistant medium. We will be using DPT RAID controlles for a mix of RAID-1 and RAID-5, as the case justifies. 2. Our basic recorded unit is less than 512 bytes long. We compromise and round it (way) up to 512v since nobody makes fast disk drives with sectors smaller than that anymore. Yes, SCSI being what it is, even 512 is way small. We know... 3. In case of system failure (most common reason today == O/S crash) we must be back in operation within less than 10 seconds. We do that by sharing the disks with another sytem, which is already up. 4. We need to process very large number of interrupts. In fact, so many that one FreeBSD CPU cannot keep up. So, we are back to shared disks. 5. Because disks are shared, the write state must be very deterministic at all times. As O/S have caches, RAID controllers have caches, disks have caches, we have to have some sense of who has what in which cache when. Considering the O/S to be the most lossy element in the system, we have to keep the amount of WRITE caches to a minimum. (I do not intend to start a war. I am quoting my management who has collected some impressive statistics in this manner. Using some commercial O/S's which will not be named here) ... > DEFINITION: Random reads/writes: "please remove any cache > effects from my testing, I believe my app will > be a cache-killer, so I don't want cache to > count for anything because I have zero locality > of reference". Almost, but not quite :-) Each FreeBSD system will have 50GB of database on it. Although the 90/10 rules proabably apply, it is impossible to predict, or force, the locality. Having 90% cache hit rate has some cooling problems associated with it :-) Not only system cooling but management cooling as well. They do not see a systme with that much RAM as amusing, nor exciting. ... Something got garbled here... > (zero locality of reference: a hard thing to find in the real world) > prevent the read-ahead from being invoked. Ah! there is a read-ahead on raw devices? How do we shut it down? > The best speed will be at FS block size, since all reads and writes > are in terms of chunks in FS block size, some multiple of the page > size (in general, assuming you want it to be fast). > > The smaller your block size, the more data you have to read of of disk > for your write. > > The VM system has an 8 bit bitmap, one bit per 512b (physical disk > block) in a 4k (VM page size) page. This bitmap is, unfortunately, > not used for read/write, or your aligned 512b blocks would not have > to actually read 4k of data off the disk to write the 512b you want > to write. > > The problem here is that you can not insure write fault granularity > to better than your page size. The funny thing is, the i386 will > not write fault a modification from protected mode (kernel code), > so it has to fake this anyway -- so it's *possible* to fake it, > and it would, in general, be a win for writes on disk block boundries > for some multiple of disk block size (usually 512b for disks, 1k for > writeable optical media). How does all this relate to raw/character devices? > Talk to John Dyson about this optimization. Don't expect an enthusiastic > response: real work utilization is seldom well aligned... this is a > "benchmark optimization". John Dyson, Sory but I do not have your email address... I made sure it is actually a fit. We made all the data records (that require this performance/reliability) be exactly 512 bytes. It is very ``wasteful'' in terms of storage, but when compared to the speed/cost benefits, it is very cheap. Also, consider the number of spindles required for our transaction rate and we ended up with more disk space than we need, so... > > What we see is a flat WRITE response until 2K. then it starts a linear > > decline until it reaches 8K block size. At this point it converges > > with READ performance. The initial WRITE performance, for small blocks > > is quite poor compared to READ. We attribute it to the need to do > > read-modify-write when blocks are smaller than a certain ``natural block > > size (page?). > > Yes. But the FS block size s 8k, not pagesize (4k). We were not using a filesystem. That's the point. > > Another attribute of performance loss, we think to be the > > lack of O_SYNC) option to the write(2) system call. This forces the > > application to do an fsync after EVERY WRITE. We have to do that for > > many good reasons. > > There is an option O_WRITESYNC. Use it, or fcntl() it on. You will > take a big hit for using it, however; the only overhead difference > will be the system call overhead for implementing the protection > domain crossing for the fsync() call. O_WRITESYNC! This is an open(2) option that says that all write's are synchronous (do not return until actually done). Right? And it applies to block devices, as well as filesystem files. Right? The ``only'' difference is additional 200 system calls per second? How many of these can a Pentium-Pro, 512K cache, 128MB RAM, etc. can do in one second. We are always in the 1,000+ in our budget. 20% increase is a lot to us. > Most likely, you do not really need this, or you are poorly implementing > the two stage commit process typical of most modern database design. Assumptions, assumptions... :-) There is no database, there is no 2phase commit here. Wish I could share more details in this forum, but I am already stretching it :-( > > The READ performance is even more peculiar. It starts higher than > > WRITE, declines rapidly until block size reaches 2K. It peaks at 4K > > blocks and starts a linear decline from that point on (as block size > > increases). > > This is because of precache effects. Your "random" reads are not > "random" enough to get rid of cache effects, it seems. If they were, > the 4k numbers would be worse, and the peak would be the FS block size. On a block device? Which filesystem? > > We intend to use the RAW (character) device with the mpool buffering > > system and would like to understand its behavior without reading the > > WHOLE kernel source :-) > > The VM and buffer cache have been unified. bread/bwrite are, in fact, > page fault operations. Again, talk to John Dyson about the bitmap > optimization for representing partially resident pages at this level; > otherwise, you *must* fault the data in and out on page boundries, > and the fault will be in page groups of FS blocksize in size. Hmmm... We are going back to this decades old argument. One of the few things I did agree with while at Oracle, was that not ALL disk I/O in a system is composed of page faults and emacs sessions. Sometimes I/O needs to be performed in manners which defy any preplanning on the O/S architect part. This is where raw devices are so crucially important. The same tests described here were run on a well known commercial OS. It exhibits totally flat response from 512 bytes to 4Kb blocks. What happened at 8K blocks and larger? The process will totally hang if you did read + (O_SYNC) write on the same file at the same time. Cute. ... > Jorg, Julian, and the specific SCSI driver authors are probably > your best resource below the bdevsw[] layer. I appreciate that. I have not seen anything in the SCSI layer that really ``cares'' about the type of I/O done. It all appears the same. > They are written using a write operation which block until the data > has been committed. Per the definition of O_WRITESYNC. Thanx! ... Simon From owner-freebsd-hackers Tue Feb 11 22:35:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA07000 for hackers-outgoing; Tue, 11 Feb 1997 22:35:40 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA06982 for ; Tue, 11 Feb 1997 22:35:28 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.5/8.8.4) with SMTP id WAA06201; Tue, 11 Feb 1997 22:30:33 -0800 (PST) Message-ID: <33016316.41C67EA6@whistle.com> Date: Tue, 11 Feb 1997 22:28:38 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Terry Lambert CC: Simon Shapiro , freebsd-hackers@freebsd.org Subject: Re: Raw I/O Question References: <199702112244.PAA29164@phaeton.artisoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > > > Can someone take a moment and describe briefly the execution path of a > > lseek/read/write system call to a raw (character) SCSI partition? > > You skipped a specification step: the FS layout on that partition. > I will assume FFS with 8k block size (the default). Terry, in your description you forget he's asking for RAW devices.. > > -> read syscall > -> fill out uio struct > -> call VOP_READ using bogus fileops struct dereference > which is there because named pipes and UNIX domain > sockets aren't in the VFS like they should be > -> ffs_read (/sys/ufs/ufs/ufs_readwrite.c:READ) > -> (called iteratively) > bread > -> getblk > (in cache? No?) > -> vfs_busy_pages > VOP_STRATEGY > -> VCALL strategy routine for device vnode > -> spec_strategy (/sys/miscfs/specfs/spec_vnops.c) > -> call device strategy through bdevsw[] > -> generic scsi (scbus [bus interface]/sd [disk > interface] > -> actual controller requests > biowait > uiomove > -> copyout > for a raw device.. raw_read() calls physio, which faults in and wires down pages in the user space for the buffer (in case they are out) then it takes the phyical addresses and applies them to a reerved section of kernel VM space. it then calls the strategy routine for the device which gets the kv region, and extracts the phyical addresses again and sets up the DMA and then waits DMA is directly into the users pages.. > write > -> write syscall > -> fill out uio struct > -> call VOP_WRITE using bogus fileops struct dereference > which is there because named pipes and UNIX domain > sockets aren't in the VFS like they should be > -> ffs_write (/sys/ufs/ufs/ufs_readwrite.c:WRITE) > -> (called iteratively) > (partial FS block? !!!CALL READ!!! > -> fill in modified areas of partial FS block > (uiomove) > -> copyin nope.. not in raw devices. > bwrite > ... d From owner-freebsd-hackers Tue Feb 11 22:53:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA08982 for hackers-outgoing; Tue, 11 Feb 1997 22:53:39 -0800 (PST) Received: from gdi.uoregon.edu (gdi.uoregon.edu [128.223.170.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA08961 for ; Tue, 11 Feb 1997 22:53:17 -0800 (PST) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.5/8.6.12) with SMTP id WAA00260 for ; Tue, 11 Feb 1997 22:53:04 -0800 (PST) Date: Tue, 11 Feb 1997 22:53:04 -0800 (PST) From: Doug White X-Sender: dwhite@localhost Reply-To: Doug White To: hackers@freebsd.org Subject: Need definitive answer on de 21140-AC driver Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just got ahold of a Kingston card with this chip on it. I konw that the Digital/de-driven cards have gone through a renaissance as of late and FreeBSD's been slow to catch up. But I do need to know -- will this card work with 2.2-GAMMA or 3.0-CURRENT. Tests show no good on 2.2 -- FreeBSD thinks it's a 21140A and promptly enables 100bTX on a 10MB net. A quick poke through if_de.c doesn't show any references to the -AC. Is there a new driver in the works? If not, I'll gladly donate this card for a while if it's a matter of just getting the card to the right person. Thanks for any insight. Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major From owner-freebsd-hackers Tue Feb 11 23:00:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA10021 for hackers-outgoing; Tue, 11 Feb 1997 23:00:17 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA10015 for ; Tue, 11 Feb 1997 23:00:10 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id SAA07054; Wed, 12 Feb 1997 18:04:59 +1100 (EST) Date: Wed, 12 Feb 1997 18:04:59 +1100 (EST) From: "Daniel O'Callaghan" To: hackers@freebsd.org Subject: strlen() question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Below is the code for strlen() from libc. It is extremely simple, and fast. Is it really safe to assume that strlen() will never exceed process memory bounds before striking a '\0'? Or should there be a strnlen() function in libc for checking the length of suspicious strings? Danny size_t strlen(str) const char *str; { register const char *s; for (s = str; *s; ++s); return(s - str); } From owner-freebsd-hackers Tue Feb 11 23:18:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA11238 for hackers-outgoing; Tue, 11 Feb 1997 23:18:05 -0800 (PST) Received: from agni.nuko.com ([207.82.229.31]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA11220; Tue, 11 Feb 1997 23:18:00 -0800 (PST) Received: (from vinay@localhost) by agni.nuko.com (8.7.5/8.6.12) id XAA10661; Tue, 11 Feb 1997 23:17:46 -0800 (PST) From: Vinay Kumar Message-Id: <199702120717.XAA10661@agni.nuko.com> Subject: Need a packet capture and playback utility To: freebsd-hackers@freebsd.org Date: Tue, 11 Feb 1997 23:17:46 -0800 (PST) Cc: freebsd-isp@freebsd.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi folks, I have been looking for a packet capture and playback utility. tcpdump does not suit my requirements. I am in the middle of some experimentation with network traffic simulations. I think it will be better if I describe what I am looking for. I need a IP packet capture utility which can store the entire IP packet. I also want a utility that can playback the stored packets (meaning sending it out on the network) honoring the time intervals. Meaning if there was a gap of 2.5 seconds between two consecutive IP packets, then it should playback the packets with the same gap. I tried checking the ftp.ee.lbl.gov and the Internet traffic archive but could not find a exact match for my requirements. Before I go off writing such a tool, I would like to find out if anyone know of such a tool? I appreciate any help. If anyone is interested in knowing what exactly I am doing, I will be more than glad to fill in the details. Thanks for any help. Vinay -- Vinay Bannai E-mail: vinay@agni.nuko.com (408)-526-0280 x 275 (Work) http://agni.nuko.com/~vinay From owner-freebsd-hackers Wed Feb 12 00:28:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA15639 for hackers-outgoing; Wed, 12 Feb 1997 00:28:11 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA15634 for ; Wed, 12 Feb 1997 00:28:08 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id TAA06992; Wed, 12 Feb 1997 19:22:17 +1100 Date: Wed, 12 Feb 1997 19:22:17 +1100 From: Bruce Evans Message-Id: <199702120822.TAA06992@godzilla.zeta.org.au> To: julian@whistle.com, terry@lambert.org Subject: Re: Raw I/O Question Cc: freebsd-hackers@freebsd.org, Shimon@i-Connect.Net Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >it then calls the strategy routine for the device >which gets the kv region, >and extracts the phyical addresses again and >sets up the DMA >and then waits > >DMA is directly into the users pages.. Only for devices and device drivers that support and use DMA. Bruce From owner-freebsd-hackers Wed Feb 12 00:53:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA16713 for hackers-outgoing; Wed, 12 Feb 1997 00:53:24 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA16707 for ; Wed, 12 Feb 1997 00:53:20 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA29441; Wed, 12 Feb 1997 09:53:05 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id JAA29223; Wed, 12 Feb 1997 09:38:21 +0100 (MET) Message-ID: Date: Wed, 12 Feb 1997 09:38:20 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: hackers@freebsd.org Subject: Re: mdoc help? References: <199702120102.LAA09409@genesis.atrad.adelaide.edu.au> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702120102.LAA09409@genesis.atrad.adelaide.edu.au>; from Michael Smith on Feb 12, 1997 11:32:13 +1030 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Michael Smith wrote: > Unfortunately, that's too many arguments for the .Ic macro 8( If I try Read the sections ``Passing Space Characters in an Argument'' in mdoc.samples(7), and see if this would solve your problem. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed Feb 12 00:53:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA16767 for hackers-outgoing; Wed, 12 Feb 1997 00:53:45 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA16758 for ; Wed, 12 Feb 1997 00:53:42 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA29450; Wed, 12 Feb 1997 09:53:34 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id JAA29275; Wed, 12 Feb 1997 09:50:13 +0100 (MET) Message-ID: Date: Wed, 12 Feb 1997 09:50:13 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: dwhite@resnet.uoregon.edu (Doug White) Cc: hackers@FreeBSD.ORG Subject: Re: Need definitive answer on de 21140-AC driver References: X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Doug White on Feb 11, 1997 22:53:04 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Doug White wrote: > Is there a new driver in the works? I think NetBSD has one. Give it a try, if you want, and send us the diffs for inclusion. ;-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed Feb 12 00:57:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA16928 for hackers-outgoing; Wed, 12 Feb 1997 00:57:15 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA16923 for ; Wed, 12 Feb 1997 00:57:10 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id TAA07979; Wed, 12 Feb 1997 19:55:45 +1100 Date: Wed, 12 Feb 1997 19:55:45 +1100 From: Bruce Evans Message-Id: <199702120855.TAA07979@godzilla.zeta.org.au> To: danny@panda.hilink.com.au, hackers@freebsd.org Subject: Re: strlen() question Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Below is the code for strlen() from libc. It is extremely simple, and >fast. Is it really safe to assume that strlen() will never exceed process >memory bounds before striking a '\0'? Or should there be a strnlen() >function in libc for checking the length of suspicious strings? The i386 version is actually in strlen.S. Strings are nul-terminated by definition. strlen() is only required to work if its arg points to the first character of a string (this is a bit different from strncpy(), which is required to work if its args point to suitably large (non necessarily null terminated) character arrays). If strlen()'s arg points to a non-terminated string, the behaviour is undefined. In systems with vm, the actual behaviour is probably to cause a SIGSEGV or SIGBUS. However, most improperly terminated strings are usually terminated by a nul in garbage beyond them before the end of the process's address space. Some fancy implementations of strlen() access memory a word at a time. They have to worry about accessing beyond the end of the string and hitting the end of the address space. On many systems, it is harmless to access beyond the end provided that accesses are word aligned and the first byte of the word is in the string. There probably shouldn't be a strnlen() because suspicious strings don't occur naturally. Bruce From owner-freebsd-hackers Wed Feb 12 01:21:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA17905 for hackers-outgoing; Wed, 12 Feb 1997 01:21:09 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA17900 for ; Wed, 12 Feb 1997 01:21:06 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA29855; Wed, 12 Feb 1997 10:20:56 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id JAA29311; Wed, 12 Feb 1997 09:54:52 +0100 (MET) Message-ID: Date: Wed, 12 Feb 1997 09:54:52 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: danny@panda.hilink.com.au (Daniel O'Callaghan) Cc: hackers@freebsd.org Subject: Re: strlen() question References: X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Daniel O'Callaghan on Feb 12, 1997 18:04:59 +1100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Daniel O'Callaghan wrote: > Below is the code for strlen() from libc. It is extremely simple, and > fast. Is it really safe to assume that strlen() will never exceed process > memory bounds before striking a '\0'? Or should there be a strnlen() > function in libc for checking the length of suspicious strings? Why? The worst that would happen by touching off the end of your address space is a SIGSEGV. The problem with str*cpy() touching beyond the bounds of their arrays is that they can _modify_ the stack then, but that can't happen with strlen() since it doesn't modify anything. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed Feb 12 01:37:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA18562 for hackers-outgoing; Wed, 12 Feb 1997 01:37:48 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA18553 for ; Wed, 12 Feb 1997 01:37:42 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id UAA07696; Wed, 12 Feb 1997 20:42:26 +1100 (EST) Date: Wed, 12 Feb 1997 20:42:25 +1100 (EST) From: "Daniel O'Callaghan" To: Joerg Wunsch cc: hackers@freebsd.org Subject: Re: strlen() question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 12 Feb 1997, J Wunsch wrote: > As Daniel O'Callaghan wrote: > > > Below is the code for strlen() from libc. It is extremely simple, and > > fast. Is it really safe to assume that strlen() will never exceed process > > memory bounds before striking a '\0'? Or should there be a strnlen() > > function in libc for checking the length of suspicious strings? > > Why? The worst that would happen by touching off the end of your > address space is a SIGSEGV. The problem with str*cpy() touching > beyond the bounds of their arrays is that they can _modify_ the stack > then, but that can't happen with strlen() since it doesn't modify > anything. I was thinking of bounds checking w/o a copy. Danny From owner-freebsd-hackers Wed Feb 12 01:45:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA18905 for hackers-outgoing; Wed, 12 Feb 1997 01:45:34 -0800 (PST) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA18900 for ; Wed, 12 Feb 1997 01:45:29 -0800 (PST) Received: (from davidn@localhost) by labs.usn.blaze.net.au (8.8.5/8.8.5) id UAA16166; Wed, 12 Feb 1997 20:45:17 +1100 (EST) Message-ID: <19970212204517.26504@usn.blaze.net.au> Date: Wed, 12 Feb 1997 20:45:17 +1100 From: David Nugent To: "Daniel O'Callaghan" Cc: hackers@freebsd.org Subject: Re: strlen() question References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61 In-Reply-To: ; from Daniel O'Callaghan on Feb 02, 1997 at 06:04:59PM Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Feb 02, 1997 at 06:04:59PM, Daniel O'Callaghan wrote: > Below is the code for strlen() from libc. It is extremely simple, and > fast. Is it really safe to assume that strlen() will never exceed process > memory bounds before striking a '\0'? This is the programmer's responsibility. > Or should there be a strnlen() function in libc for checking the > length of suspicious strings? No. FWIW, you can use memchr(3) for that. Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-hackers Wed Feb 12 02:32:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA20928 for hackers-outgoing; Wed, 12 Feb 1997 02:32:49 -0800 (PST) Received: from hda.hda.com (ip51-max1-fitch.ziplink.net [199.232.245.51]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id CAA20921 for ; Wed, 12 Feb 1997 02:32:44 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.6.12/8.6.12) id FAA11921; Wed, 12 Feb 1997 05:26:00 -0500 From: Peter Dufault Message-Id: <199702121026.FAA11921@hda.hda.com> Subject: Re: Raw I/O Question In-Reply-To: from Simon Shapiro at "Feb 11, 97 10:49:46 pm" To: Shimon@i-Connect.Net (Simon Shapiro) Date: Wed, 12 Feb 1997 05:25:59 -0500 (EST) Cc: terry@lambert.org, freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As has been already noted, if you're using the raw device don't look at the block device. > No file system. See above. What is the block size used then? I'm assuming you will hack your driver as needed. The answer in that case is the size you request that must be a multiple of the sector size up to 64K. The optimal I/O chunk is probably a full track striped across all disks, but then your I/O size will vary with cylinder offset and you'll really waste space, so forget that. > All these, stripping off the file system pointers, as they do not apply) > are good and valid, except: > > 1. We have to guarantee transactions. This means that system failure, > at ANY time cannot ``undo'' what is said to be done. IOW, a WRITE > call that returns positively, is known to have been recorded, on > error/failure resistant medium. We will be using DPT RAID > controlles for a mix of RAID-1 and RAID-5, as the case justifies. You will have to have your driver issue the calls to flush the device disk cache at the correct points or turn off cacheing on the drives. > 2. Our basic recorded unit is less than 512 bytes long. We compromise > and round it (way) up to 512v since nobody makes fast disk drives > with sectors smaller than that anymore. Yes, SCSI being what it > is, even 512 is way small. We know... You can reformat the drive to a smaller sector size. > 3. In case of system failure (most common reason today == O/S crash) we > must be back in operation within less than 10 seconds. We do that by > sharing the disks with another sytem, which is already up. > > 4. We need to process very large number of interrupts. In fact, so > many that one FreeBSD CPU cannot keep up. So, we are back to shared > disks. State what that large number is. There may be too much going on in the interrupt, but that is a fixable problem especially for a single controller. I'm skeptical that with things balanced properly you will run out of CPU before memory bandwidth, especially given that you seem to be able to use large transfers. > 5. Because disks are shared, the write state must be very deterministic > at all times. As O/S have caches, RAID controllers have caches, > disks have caches, we have to have some sense of who has what in > which cache when. Considering the O/S to be the most lossy element > in the system, we have to keep the amount of WRITE caches to a > minimum. > > (I do not intend to start a war. I am quoting my management who has > collected some impressive statistics in this manner. Using some > commercial O/S's which will not be named here) The raw I/O system doesn't have a cache. It is transferring the data directly from your user process to the device. From then on you are at the mercy of the RAID setup and the corresponding disk setup, which may be specified by the RAID controller manufacturer. (...) > Ah! there is a read-ahead on raw devices? How do we shut it down? There will be read ahead on the raw device itself and not in the system. A disk will have a cache and the performance is specified in the cache page (page 8). The RAID controller probably also has a cache and you must look to the manufacturer find out what you must / can do to tune it. > (...) > > How does all this relate to raw/character devices? It doesn't. (...) > > Most likely, you do not really need this, or you are poorly implementing > > the two stage commit process typical of most modern database design. > > Assumptions, assumptions... :-) There is no database, there is no 2phase > commit here. Wish I could share more details in this forum, but I am > already stretching it :-( Hmm. I'm from Missouri (For non-Americans: The show-me state, indicating healthy skepticism about claims until demonstrated). > > They are written using a write operation which block until the data > > has been committed. Per the definition of O_WRITESYNC. Again, they aren't. They are doing a WRITE and however the RAID controller or SCSI disk respond to a WRITE is what the drivers are doing. The RAID controller manufacturer has hopefully spent time figuring out how to configure the disks to ensure no spurious "writes claimed finished when not". They need that to guarantee fault tolerance. Go over your questions with them. I would evaluate writing a raw device driver from scratch specifically for this application and use any existing drivers as maintenance devices. This lets you address issues such as interrupt overhead, etc, separately and from a clean slate, and will make it a lot easier to be sure you are extracting the performance you want. I expect you won't fully "get your head around the problem" otherwise. Peter -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 From owner-freebsd-hackers Wed Feb 12 02:52:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA21802 for hackers-outgoing; Wed, 12 Feb 1997 02:52:45 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA21793 for ; Wed, 12 Feb 1997 02:52:39 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id VAA13568; Wed, 12 Feb 1997 21:22:25 +1030 (CST) From: Michael Smith Message-Id: <199702121052.VAA13568@genesis.atrad.adelaide.edu.au> Subject: Re: mdoc help? In-Reply-To: from J Wunsch at "Feb 12, 97 09:38:20 am" To: joerg_wunsch@uriah.heep.sax.de Date: Wed, 12 Feb 1997 21:22:24 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch stands accused of saying: > As Michael Smith wrote: > > > Unfortunately, that's too many arguments for the .Ic macro 8( If I try > > Read the sections ``Passing Space Characters in an Argument'' in > mdoc.samples(7), and see if this would solve your problem. I was eventually saved by the Xo/Xc macros. *roff is frightening 8( > cheers, J"org -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Feb 12 03:21:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA22877 for hackers-outgoing; Wed, 12 Feb 1997 03:21:06 -0800 (PST) Received: from kremvax.demos.su (kremvax.demos.su [194.87.0.20]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA22870; Wed, 12 Feb 1997 03:20:59 -0800 (PST) Received: by kremvax.demos.su (8.6.13/D) from 0@megillah.demos.su [194.87.0.21] with ESMTP id OAA27785; Wed, 12 Feb 1997 14:20:35 +0300 Received: by megillah.demos.su id OAA13512; (8.8.3/D) Wed, 12 Feb 1997 14:21:37 +0300 (MSK) Message-Id: <199702121121.OAA13512@megillah.demos.su> Subject: upcoming version suggestions To: hackers@freebsd.org Date: Wed, 12 Feb 1997 14:21:37 +0300 (MSK) Cc: bag@demos.su (Alex G. Bulushev), current@freebsd.org, ache@nagual.ru (Andrey A. Chernov) From: "Mikhail A. Sokolov" X-Class: Fast Organization: Demos Company, Ltd. Reply-To: mishania@demos.su X-Mailer: ELM [version 2.4 PL24 ME7a] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, Don't know what version will it be applicable to now, either it is 2.1.7 or 2.2, but since FreeBSD is known to be more like server-used OS, than user worskstations, here're suggestions to redifine defaults: There's really need to set FDSETSIZE (/sys/sys/types.h, afair) default to something like 1024, - then you don't need to recompile kernel as soon as you start news server and/or ftp/www, like, loaded one. Example: you won't get any improvements rearranging MAXOPEN value, before you rearrange FDSETSIZE. Another idea is to enlarge default for SOMAXCONN (/sys/socket.h). When you have something running for it to be available to have more open passive tcp connections sumaltaneously. Example is Squid proxy cache{d} which uses this include in the listen(). Comments are definetely appreciated. Thanks, -mishania From owner-freebsd-hackers Wed Feb 12 04:01:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA24083 for hackers-outgoing; Wed, 12 Feb 1997 04:01:14 -0800 (PST) Received: from kremvax.demos.su (kremvax.demos.su [194.87.0.20]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id EAA24076; Wed, 12 Feb 1997 04:01:05 -0800 (PST) Received: by kremvax.demos.su (8.6.13/D) from 0@megillah.demos.su [194.87.0.21] with ESMTP id PAA10422; Wed, 12 Feb 1997 15:00:23 +0300 Received: by megillah.demos.su id PAA21822; (8.8.3/D) Wed, 12 Feb 1997 15:00:40 +0300 (MSK) Message-Id: <199702121200.PAA21822@megillah.demos.su> Subject: Re: upcoming version suggestions To: mishania@demos.su Date: Wed, 12 Feb 1997 15:00:40 +0300 (MSK) Cc: hackers@FreeBSD.ORG, bag@demos.su, current@FreeBSD.ORG, ache@nagual.ru In-Reply-To: <199702121121.OAA13512@megillah.demos.su> from "Mikhail A. Sokolov" at Feb 12, 97 02:21:37 pm From: "Mikhail A. Sokolov" X-Class: Fast Organization: Demos Company, Ltd. Reply-To: mishania@demos.su X-Mailer: ELM [version 2.4 PL24 ME7a] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > to something like 1024, - then you don't need to recompile kernel as ^^^^^^ binaries I meant. -mishania From owner-freebsd-hackers Wed Feb 12 04:55:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA26422 for hackers-outgoing; Wed, 12 Feb 1997 04:55:00 -0800 (PST) Received: from smyrno.sol.net (smyrno.sol.net [206.55.64.117]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA26417 for ; Wed, 12 Feb 1997 04:54:57 -0800 (PST) Received: from solaria.sol.net (solaria.sol.net [206.55.65.75]) by smyrno.sol.net (8.8.3/8.8.3) with SMTP id GAA09666; Wed, 12 Feb 1997 06:54:16 -0600 (CST) Received: from localhost by solaria.sol.net (8.5/8.5) id GAA25336; Wed, 12 Feb 1997 06:54:51 -0600 From: Joe Greco Message-Id: <199702121254.GAA25336@solaria.sol.net> Subject: Re: Need definitive answer on de 21140-AC driver To: dwhite@resnet.uoregon.edu Date: Wed, 12 Feb 97 6:54:47 CST Cc: hackers@freebsd.org In-Reply-To: from "Doug White" at Feb 11, 97 10:53:04 pm X-Mailer: ELM [version 2.4dev PL65] MIME-Version: 1.0 Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I just got ahold of a Kingston card with this chip on it. I konw that the Nice cards; priced around $70 (wholesale, Rod), but even the SMC version of the card is very reasonable. > Digital/de-driven cards have gone through a renaissance as of late and > FreeBSD's been slow to catch up. But I do need to know -- will this card > work with 2.2-GAMMA or 3.0-CURRENT. Tests show no good on 2.2 -- FreeBSD > thinks it's a 21140A and promptly enables 100bTX on a 10MB net. A quick > poke through if_de.c doesn't show any references to the -AC. When I talked to Matt Thomas, several months ago, he provided me a prototype driver that compiled under 2.1.6R. I beat the snot out of it and have since been using it in production, mostly with the SMC dual port 10/100's, but also a few other -AC cards like the Kingston. There are a few bugs in the driver, none of which affect the usability of the cards. > Is there a new driver in the works? If not, I'll gladly donate this card > for a while if it's a matter of just getting the card to the right person. Offered to do that too :-) Matt seems to have what needs doing nailed down pretty well. I've hinted to him several times I'd like a 2.2* driver but so far I haven't seen one. That's too bad because the de driver is a really cool thing to have, and if we only support old 100mbps cards that are no longer made, well, yuck. I suspect it's mainly a matter of getting Matt to release a version of his code. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Wed Feb 12 04:55:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA26451 for hackers-outgoing; Wed, 12 Feb 1997 04:55:09 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA26441; Wed, 12 Feb 1997 04:55:03 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id XAA16078; Wed, 12 Feb 1997 23:41:50 +1100 Date: Wed, 12 Feb 1997 23:41:50 +1100 From: Bruce Evans Message-Id: <199702121241.XAA16078@godzilla.zeta.org.au> To: hackers@freebsd.org, mishania@demos.su Subject: Re: upcoming version suggestions Cc: ache@nagual.ru, bag@demos.su, current@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >There's really need to set FDSETSIZE (/sys/sys/types.h, afair) default >to something like 1024, - then you don't need to recompile kernel as >soon as you start news server and/or ftp/www, like, loaded one. Example: >you won't get any improvements rearranging MAXOPEN value, before you >rearrange FDSETSIZE. There hasn't been any need to recompile the kernel since the kernel select size was made dynamic 6 months ago in -current. You can increase the number of fd's up to the hard resource limit using setrlimit() and root can increase the hard resource limit using `sysctl -w kern.maxfiles=nnnn' (this has been possible since FreeBSD-2.0, except for bugs) and /etc/login.conf (this has only become available recently). No particular value of FDSETSIZE works unless the resource limit is restricted to the old value of FDSETSIZE (256). This can't be fixed without breaking binary compatibility :-(. Bruce From owner-freebsd-hackers Wed Feb 12 05:45:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA28628 for hackers-outgoing; Wed, 12 Feb 1997 05:45:03 -0800 (PST) Received: from kremvax.demos.su (kremvax.demos.su [194.87.0.20]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA28572; Wed, 12 Feb 1997 05:44:12 -0800 (PST) Received: by kremvax.demos.su (8.6.13/D) from 0@megillah.demos.su [194.87.0.21] with ESMTP id QAA12642; Wed, 12 Feb 1997 16:43:26 +0300 Received: by megillah.demos.su id QAA18384; (8.8.3/D) Wed, 12 Feb 1997 16:44:07 +0300 (MSK) Message-Id: <199702121344.QAA18384@megillah.demos.su> Subject: Re: upcoming version suggestions To: bde@zeta.org.au (Bruce Evans) Date: Wed, 12 Feb 1997 16:44:07 +0300 (MSK) Cc: hackers@freebsd.org, mishania@demos.su, ache@nagual.ru, bag@demos.su, current@freebsd.org In-Reply-To: <199702121241.XAA16078@godzilla.zeta.org.au> from "Bruce Evans" at Feb 12, 97 11:41:50 pm From: "Mikhail A. Sokolov" X-Class: Fast Organization: Demos Company, Ltd. Reply-To: mishania@demos.su X-Mailer: ELM [version 2.4 PL24 ME7a] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >to something like 1024, - then you don't need to recompile kernel as It was kind of a typo, - I Re:'d myself in a while. What I mean is that any change of default FDSETSIZE in kernel means us to recompile user binaries. > restricted to the old value of FDSETSIZE (256). This can't be fixed > without breaking binary compatibility :-(. What I suggest is to check if there is a possibility to set fdsetsize to 1024 in distributions, and, of course, have binaries of the system to know about that 1024. > Bruce -mishania From owner-freebsd-hackers Wed Feb 12 06:00:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA29465 for hackers-outgoing; Wed, 12 Feb 1997 06:00:23 -0800 (PST) Received: from deepo.prosa.dk ([193.89.187.27]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA29460 for ; Wed, 12 Feb 1997 06:00:18 -0800 (PST) Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.5/8.8.4/prosa-1.1) id OAA01397; Wed, 12 Feb 1997 14:59:15 +0100 (CET) Message-ID: Date: Wed, 12 Feb 1997 14:59:14 +0100 From: regnauld@deepo.prosa.dk (Philippe Regnauld) To: michaelh@cet.co.jp (Michael Hancock) Cc: freebsd-hackers@freebsd.org Subject: Re: Increasing overall security.... References: <199702110604.WAA14933@dog.farm.org> X-Mailer: Mutt 0.58 Mime-Version: 1.0 X-Operating-System: FreeBSD 2.2-BETA_A i386 In-Reply-To: ; from Michael Hancock on Feb 12, 1997 11:28:24 +0900 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Michael Hancock (michaelh) ecrit/writes: > > 2) We don't know if it operates correctly. Sendmail 8.8.5 has around 106 > strcpy's in it and we don't know what the patch's effect will be in a > production environment. 107 explicit. Until you check: #define newstr(s) strcpy(xalloc(strlen(s) + 1), s) ... of which there are _many_. Anyway sendmail has a category of its own: "Lots of bugs, lots of people looking at it". -- -- Phil -[ Philippe Regnauld / Systems Administrator / regnauld@prosa.dk ]- -[ Location.: +55.4N +11.3E PGP Key: finger regnauld@deepo.prosa.dk ]- From owner-freebsd-hackers Wed Feb 12 07:42:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA04825 for hackers-outgoing; Wed, 12 Feb 1997 07:42:33 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA04797; Wed, 12 Feb 1997 07:42:15 -0800 (PST) Received: by sovcom.kiae.su id AA13803 (5.65.kiae-1 ); Wed, 12 Feb 1997 18:13:33 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Wed, 12 Feb 97 18:13:33 +0300 Received: (from ache@localhost) by nagual.ru (8.8.5/8.8.5) id SAA00491; Wed, 12 Feb 1997 18:10:03 +0300 (MSK) Date: Wed, 12 Feb 1997 18:09:57 +0300 (MSK) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: "Mikhail A. Sokolov" Cc: hackers@freebsd.org, "Alex G. Bulushev" , current@freebsd.org Subject: Re: upcoming version suggestions In-Reply-To: <199702121121.OAA13512@megillah.demos.su> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 12 Feb 1997, Mikhail A. Sokolov wrote: > There's really need to set FDSETSIZE (/sys/sys/types.h, afair) default > to something like 1024, - then you don't need to recompile kernel as ^^^^^^ maybe you mean binaries instead? -current kernel works without recompiling with any value. > soon as you start news server and/or ftp/www, like, loaded one. Example: > you won't get any improvements rearranging MAXOPEN value, before you > rearrange FDSETSIZE. I agree that we need to bump it, 256 is too low nowdays. We need to check what other modern systems have, f.e. SunOS 5.5.1 have FD_SETSIZE == 1024 > Another idea is to enlarge default for SOMAXCONN (/sys/socket.h). > When you have something running for it to be available to have more > open passive tcp connections sumaltaneously. Example is Squid proxy cache{d} > which uses this include in the listen(). > > Comments are definetely appreciated. Another idea is to increase max ptys number from 256 to 512 or 1024 -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-hackers Wed Feb 12 09:21:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA12152 for hackers-outgoing; Wed, 12 Feb 1997 09:21:17 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA12145 for ; Wed, 12 Feb 1997 09:21:12 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA00715; Wed, 12 Feb 1997 10:15:47 -0700 From: Terry Lambert Message-Id: <199702121715.KAA00715@phaeton.artisoft.com> Subject: Re: MIME applications for FreeBSD To: jb@cimlogic.com.au (John Birrell) Date: Wed, 12 Feb 1997 10:15:47 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: <199702120310.OAA08085@freebsd1.cimlogic.com.au> from "John Birrell" at Feb 12, 97 02:10:35 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I'm curious about what people regard as typical MIME applications > that a site is expected to support. The volume of business email > containing MIME "application/msword" has now exceeded my level of > tolerance. When I consider changing ISPs and they send the > application form MIME encoded for an application I do not have... > When I receive support updates from a company we _pay_ for support > and they send them MIME encoded... Grrr. Enough! > > Opinions? 1) Boundry identification 2) Multile logical message bodies seperated by boundry identifiers 3) Content transfer encoding for binary data As to what binary data is permitted to be encoded: 1) Any binary data the sender and the recipient can agree upon Though I'd be perfectly happy to see this limited to binary data for which public source reference implementations exist (ie: no more Word documents unless Microsoft publically documents Word file format, no PDF documents unless Adobe documents their "encryption" preventing the use of non-Adobe readers, but not preventing any Adobe reader from decoding the document, etc., etc.). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Feb 12 09:21:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA12186 for hackers-outgoing; Wed, 12 Feb 1997 09:21:39 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA12175 for ; Wed, 12 Feb 1997 09:21:31 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA00703; Wed, 12 Feb 1997 10:10:20 -0700 From: Terry Lambert Message-Id: <199702121710.KAA00703@phaeton.artisoft.com> Subject: Re: Increasing overall security.... To: michaelh@cet.co.jp (Michael Hancock) Date: Wed, 12 Feb 1997 10:10:19 -0700 (MST) Cc: dk+@ua.net, snar@lucky.net, freebsd-hackers@freebsd.org In-Reply-To: from "Michael Hancock" at Feb 12, 97 11:28:24 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ ... stack checking ... ] Not that I believe it is necessary to implement at this level, or that this level would be valid on another architecture, such as SPARC, but... > To play devil's advocate... > > 1) It requires assembler which is harder to understand. Less people are > qualified to review it. Relying on something harder to understand for > security is questionable. This is not a "security through obscurity" issue. The code is hard to understand because of the people trying to understand it, not because the difficulty in understanding it is one of the intentional effects. > 2) We don't know if it operates correctly. Sendmail 8.8.5 has around 106 > strcpy's in it and we don't know what the patch's effect will be in a > production environment. I can tell you what the effect will be: (a) It will be a performance hit because of the extra runtime overhead (b) It will be relied upon, such that programs which are "secure" in a BSD environment because of it will suddenly become "insecure' when moved to another environment In general, this type of change is useful for a "debug" library, like those used by "Purify" and similar tools, but less useful as a general security precaution because of its limited scope (ie: it makes things safe on BSD on Intel, where the code in general is not repaired. I would advocate changing sensitive code to be secure in any environment, regardless of stack protections. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Feb 12 09:25:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA12383 for hackers-outgoing; Wed, 12 Feb 1997 09:25:32 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA12376 for ; Wed, 12 Feb 1997 09:25:24 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA00730; Wed, 12 Feb 1997 10:19:44 -0700 From: Terry Lambert Message-Id: <199702121719.KAA00730@phaeton.artisoft.com> Subject: Re: Raw I/O Question To: bde@zeta.org.au (Bruce Evans) Date: Wed, 12 Feb 1997 10:19:44 -0700 (MST) Cc: julian@whistle.com, terry@lambert.org, freebsd-hackers@freebsd.org, Shimon@i-Connect.Net In-Reply-To: <199702120822.TAA06992@godzilla.zeta.org.au> from "Bruce Evans" at Feb 12, 97 07:22:17 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >it then calls the strategy routine for the device > >which gets the kv region, > >and extracts the phyical addresses again and > >sets up the DMA > >and then waits > > > >DMA is directly into the users pages.. > > Only for devices and device drivers that support and use DMA. And are not limited to 24 bit ISA I/O when the physical memory target of the DMA is not above 16M. These will be bounced and then copied to the users pages. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Feb 12 09:31:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA12826 for hackers-outgoing; Wed, 12 Feb 1997 09:31:39 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA12814 for ; Wed, 12 Feb 1997 09:31:35 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA00750; Wed, 12 Feb 1997 10:25:31 -0700 From: Terry Lambert Message-Id: <199702121725.KAA00750@phaeton.artisoft.com> Subject: Re: strlen() question To: danny@panda.hilink.com.au (Daniel O'Callaghan) Date: Wed, 12 Feb 1997 10:25:31 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: from "Daniel O'Callaghan" at Feb 12, 97 06:04:59 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Below is the code for strlen() from libc. It is extremely simple, and > fast. Is it really safe to assume that strlen() will never exceed process > memory bounds before striking a '\0'? Or should there be a strnlen() > function in libc for checking the length of suspicious strings? [ ... code elided ... ] Yes. It is safe. If the string travels beyond the address space of the process, the process will fail in a deterministic manner. PS: You are required to pass only NULL terminated strings to strlen(); that is the definition of its interface. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Feb 12 10:26:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA17898 for hackers-outgoing; Wed, 12 Feb 1997 10:26:11 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA17891 for ; Wed, 12 Feb 1997 10:26:06 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA00856; Wed, 12 Feb 1997 11:20:31 -0700 From: Terry Lambert Message-Id: <199702121820.LAA00856@phaeton.artisoft.com> Subject: Re: Raw I/O Question To: Shimon@i-Connect.Net (Simon Shapiro) Date: Wed, 12 Feb 1997 11:20:31 -0700 (MST) Cc: terry@lambert.org, freebsd-hackers@freebsd.org In-Reply-To: from "Simon Shapiro" at Feb 11, 97 10:49:46 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Can someone take a moment and describe briefly the execution path of a > > > lseek/read/write system call to a raw (character) SCSI partition? > > > > You skipped a specification step: the FS layout on that partition. > > I will assume FFS with 8k block size (the default). > > I skipped nothing :-) there is NO file system on the partition. > Just a simple file (partitions are files. not in a file system, > but files. Right? :-) So you are writing a user space FS to use the partition. My previous posting referred only to FS-formatted block devices; I interpreted "raw" to mean something other than "raw device" because when I heard hoofbeats, I thought "horses". Do you work for Oracle? 8-). I think the problem comes down to how you handle your commits, and exactly what your on disk structure looks like, and exactly what you plan to do to your device driver to support your user space FS. The "lseek" is basically the same, but the "read" and the "write" are not. They go through the struct fileops and into the ops defined by specfs for character devices, and through there, directly to the strategy routines through cdevsw reference. I profoundly believe you should not use character devices for this. I also believe the FS should be in the kernel, not in user space, to avoid unnecessary protection domain crossing, and the resulting context switching that will cause. We can squeeze some additional code path out of there by eliminating struct fileops; it's not that hard to do; it's the result of a partial integration of vnode ops into the VFS framework (the VFS framework was a rush job -- USL attempted to cripple the ability to make a bootable OS by surgically claiming 6 pieces of the kernel, which really funneled down to 5 critical subsystems. The new VFS code was a workaround for the consent decree for one of those (IMO). > > > We are very interested in the most optimal, shortest path to I/O on > > > a large number of disks. > > > > o Write in the FS block size, not the disk block size to > > avoid causing a read before the write can be done > > No file system. See above. What is the block size used then? This is dependent on the device and the device driver. For disk devices, the block size is 512b. This only really applies well if you are using the block device, not the character device, which I recommend you do. > All these, stripping off the file system pointers, as they do not apply) > are good and valid, except: > > 1. We have to guarantee transactions. This means that system failure, > at ANY time cannot ``undo'' what is said to be done. IOW, a WRITE > call that returns positively, is known to have been recorded, on > error/failure resistant medium. We will be using DPT RAID > controlles for a mix of RAID-1 and RAID-5, as the case justifies. Are you using a journal, a log, or some other method to handle implied state across domains? For example, say I have an index and a bunch of records pointed to by that index. In order to do the transaction, I need a two stage commit: I allocate a new record, I write it, and I then rewrite the index. In practical terms, this is: i) alloc new record ii) write new record iii) commit new record iv) write new index v) deallocate old record ...in other words, a standard two stage commit process across two files. If you are using a log, in case of failure, you can "undo" any partially complete transactions (in the commit order above, you can recover by back-out only... allocated records without indices on next startup are deallocated). In the general case, you can roll your transaction forward if you add: .) start transaction with "intent" record i) alloc new record ii) write new record .) write "record data valid" -- this replaces "commit" XXX failure after this point can be rolled forward using "intent" record. iv) write new index v) deallocate old record .) mark transaction complete Note: THIS DOES NOT REQUIRE COMMIT TO DISK EXCEPT FOR THE LOG. You must guarantee order of actual write operation, but not that each write operation has actually taken place before you start the next operation. So basically, what you have to commit vs. what you have to order can save you a hell of a lot of waiting. > 2. Our basic recorded unit is less than 512 bytes long. We compromise > and round it (way) up to 512v since nobody makes fast disk drives > with sectors smaller than that anymore. Yes, SCSI being what it > is, even 512 is way small. We know... Then this must be for write transaction unit. It is too bad you are not using a RAID 4 stripe set and writing exactly a full stripe at a time using spindle sync. > 3. In case of system failure (most common reason today == O/S crash) we > must be back in operation within less than 10 seconds. We do that by > sharing the disks with another sytem, which is already up. ??? You mean sharing the physical drives, or you mean a network share? I'm guessing physical sharing? There are some not very general things you can do to make an OS boot nearly instantly (I keep wanting them for private APM modes and for system install). For one, you could keep a log of system state, and restore system state from the log, rather than booting normally. This requires the cooperation of the device drivers and certain parts of the boot process. > 4. We need to process very large number of interrupts. In fact, so > many that one FreeBSD CPU cannot keep up. So, we are back to shared > disks. I suspect you are using PCI controllers. PCI does not support "fast interrupts". Contact Bruce Evans for details on how you can fix this. > 5. Because disks are shared, the write state must be very deterministic > at all times. As O/S have caches, RAID controllers have caches, > disks have caches, we have to have some sense of who has what in > which cache when. Considering the O/S to be the most lossy element > in the system, we have to keep the amount of WRITE caches to a > minimum. Unless they are non-volatile, anyway. > > (zero locality of reference: a hard thing to find in the real world) > > prevent the read-ahead from being invoked. > > Ah! there is a read-ahead on raw devices? How do we shut it down? There is read-ahead for any device which is sequentially accessed. If you do not sequentially acces, you will not trigger read-ahead. This is a non-problem (I think). [ ... block size ... ] > How does all this relate to raw/character devices? It doesn't (see up top; I didn't think you really meant character devices when you said "raw"). But neither does the original question, then, since block size is largely irrelevent above device block size granularity. It will depend on the disk diver, and the controller cache size, and whether or not the disk supports track write caching itself. > > > What we see is a flat WRITE response until 2K. then it starts a linear > > > decline until it reaches 8K block size. At this point it converges > > > with READ performance. The initial WRITE performance, for small blocks > > > is quite poor compared to READ. We attribute it to the need to do > > > read-modify-write when blocks are smaller than a certain ``natural block > > > size (page?). > > > > Yes. But the FS block size s 8k, not pagesize (4k). > > We were not using a filesystem. That's the point. Then it's undefined, and it's relative to the controller/disk combination only. > O_WRITESYNC! This is an open(2) option that says that all write's are > synchronous (do not return until actually done). Right? And it applies > to block devices, as well as filesystem files. Right? Yes. It internally does the same thing you are doing, without the additional transition out then back in across the protection domain, with the accompanying possibility of context switch. > The ``only'' difference is additional 200 system calls per second? How many > of these can a Pentium-Pro, 512K cache, 128MB RAM, etc. can do in one > second. > We are always in the 1,000+ in our budget. 20% increase is a lot to us. It depends on where you are bound up. If all writes are synchronus, you are bound up in disk I/O, not system call overhead. If writes are being guaranteed, and you don't force synchronicity to imply idempotence acoss disk operations that aren't themselves atomic (ie: index/data releationships), then you may see the system call overhead. I know I have been on projects where this is important enough that we defined our own system calls to combine write-then-read operations on networks, I/O and stat operations, and pattern matching in the kernel so that irrelevent data is not pushed back over the getdents interface, etc.. > > Most likely, you do not really need this, or you are poorly implementing > > the two stage commit process typical of most modern database design. > > Assumptions, assumptions... :-) There is no database, there is no 2phase > commit here. Wish I could share more details in this forum, but I am > already stretching it :-( I'd have to say your synchronicity requirements are probably specious, then. What you really have are transaction ordering requirements, and, as noted above, you don't have to have synchronicity to implement them. > > > The READ performance is even more peculiar. It starts higher than > > > WRITE, declines rapidly until block size reaches 2K. It peaks at 4K > > > blocks and starts a linear decline from that point on (as block size > > > increases). > > > > This is because of precache effects. Your "random" reads are not > > "random" enough to get rid of cache effects, it seems. If they were, > > the 4k numbers would be worse, and the peak would be the FS block size. > > On a block device? Which filesystem? Well, disk block size, then. > The same tests described here were run on a well known commercial OS. It > exhibits totally flat response from 512 bytes to 4Kb blocks. What happened > at 8K blocks and larger? The process will totally hang if you did > read + (O_SYNC) write on the same file at the same time. Cute. Sounds like they have a single queue for locking operations on vnodes. If I had to guess, your commercial OS was Solaris 2.x, x>=3. I really disagree with the way Solaris implements its SMP locking; it doesn't scale well, it's not as concurrent as they'd like you to believe, and it's hard for third parties to use. I wish you could try it on a Unisys 6000/50 SVR4.0.2 ES/MP system; I believe they did vnode locking correctly. > > Jorg, Julian, and the specific SCSI driver authors are probably > > your best resource below the bdevsw[] layer. > > I appreciate that. I have not seen anything in the SCSI layer that really > ``cares'' about the type of I/O done. It all appears the same. In general, it's not supposed to care. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Feb 12 11:17:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA20944 for hackers-outgoing; Wed, 12 Feb 1997 11:17:34 -0800 (PST) Received: from agisgate.agis.net (agisgate.agis.net [205.137.48.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA20928 for ; Wed, 12 Feb 1997 11:17:17 -0800 (PST) Received: from radio (radio.agis.net [205.137.48.54]) by agisgate.agis.net (8.8.5/8.7.3) with SMTP id OAA24311 for ; Wed, 12 Feb 1997 14:17:34 -0500 (EST) Message-Id: <3.0.32.19970212141736.00a13dd0@agisgate.agis.net> X-Sender: markl@agisgate.agis.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 12 Feb 1997 14:17:36 -0500 To: hackers@FreeBSD.ORG From: Mark E Larson Subject: Re: Need definitive answer on de 21140-AC driver Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I have the exact same problem. And so far 2.2 hasn't worked for me either. At 10:53 PM 2/11/97 -0800, Doug White wrote: > >I just got ahold of a Kingston card with this chip on it. I konw that the >Digital/de-driven cards have gone through a renaissance as of late and >FreeBSD's been slow to catch up. But I do need to know -- will this card >work with 2.2-GAMMA or 3.0-CURRENT. Tests show no good on 2.2 -- FreeBSD >thinks it's a 21140A and promptly enables 100bTX on a 10MB net. A quick >poke through if_de.c doesn't show any references to the -AC. > >Is there a new driver in the works? If not, I'll gladly donate this card >for a while if it's a matter of just getting the card to the right person. > >Thanks for any insight. > >Doug White | University of Oregon >Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant >http://gladstone.uoregon.edu/~dwhite | Computer Science Major > > > > ################################################################### A P E X G L O B A L I N F O R M A T I O N S E R V I C E S ################################################################### Network Operations Center 313-730-5151 noc@agis.net News Administration 313-730-5151 news@agis.net Business Office/Sales 313-730-1130 sales@agis.net Visit our Web Page: http://www.agis.net Network News Information: http://agisgate.agis.net/netnews/netnews.htm From owner-freebsd-hackers Wed Feb 12 12:06:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA23333 for hackers-outgoing; Wed, 12 Feb 1997 12:06:43 -0800 (PST) Received: from aries.bb.cc.wa.us (root@[208.8.136.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA23325 for ; Wed, 12 Feb 1997 12:06:39 -0800 (PST) Received: from localhost (chris@localhost) by aries.bb.cc.wa.us (8.8.3/8.6.9) with SMTP id MAA00691 for ; Wed, 12 Feb 1997 12:01:31 -0800 (PST) Date: Wed, 12 Feb 1997 12:01:31 -0800 (PST) From: Chris Coleman To: hackers@freebsd.org Subject: handbook in sgml Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Where can i get a copy of the handbook in sgml form? I had one once, but I forgot where I got it. thanks Christopher J. Coleman (chris@aries.bb.cc.wa.us) Computer Support Technician I (509)-766-8873 Big Bend Community College Internet Instructor FreeBSD Book Project: http://www.bb.cc.wa.us/~chris/book.html I may Be inaffective, but atleast I am good at it. From owner-freebsd-hackers Wed Feb 12 12:30:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA24568 for hackers-outgoing; Wed, 12 Feb 1997 12:30:52 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA24563 for ; Wed, 12 Feb 1997 12:30:50 -0800 (PST) Received: from burka.carrier.kiev.ua (snar@burka.carrier.kiev.ua [193.193.193.100]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id MAA07839 for ; Wed, 12 Feb 1997 12:30:32 -0800 (PST) Received: (from snar@localhost) by burka.carrier.kiev.ua (8.8.4/8.who.cares.1) id WAA21544; Wed, 12 Feb 1997 22:23:15 +0200 (EET) From: Alexander Snarskii Message-Id: <199702122023.WAA21544@burka.carrier.kiev.ua> Subject: Re: Increasing overall security.... To: michaelh@cet.co.jp (Michael Hancock) Date: Wed, 12 Feb 1997 22:23:14 +0200 (EET) Cc: dk+@ua.net, snar@lucky.net, freebsd-hackers@FreeBSD.org In-Reply-To: from "Michael Hancock" at Feb 12, 97 11:28:24 am Content-type: text/plain; charset=koi8-r X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > On Mon, 10 Feb 1997, Dmitry Kohmanyuk wrote: > > > 'Why don't rewrite that functions to check the stack integrity > > > before return?' says Oleg Panaschenko sometimes ago, and after > > > some reflections i found that that is not so bad idea. Yes, we're > > > getting some overhead with using these functions rather than > > > with standard ones, but, as for me, this overhead is not so big > > > and a reason, that i can sleep without nightmares about another > > > stack overflow exploits is much important for me. > > > > that's very good idea. I don't understand the reasons from other people > > responding to this negatively. > > Speaking for myself. The author's original argument for this patch seemed > to be because there was no "Theo" in the FreeBSD group. He was unaware of > the current situation and I informed him. The fact that "Theo" is not in the FreeBSD-team was just one of my arguments :) > > To play devil's advocate... > > 1) It requires assembler which is harder to understand. Less people are > qualified to review it. Relying on something harder to understand for > security is questionable. Yes, it is. But there are about 51 functions in standard libc, realized on assembler, so, i think there are someone, who wrote it, and knew assembler well to review .... > > 2) We don't know if it operates correctly. Sendmail 8.8.5 has around 106 > strcpy's in it and we don't know what the patch's effect will be in a > production environment. Mike, do you think that i published this patches without correct check of working ? These patches are applied on my main computers about week or so, and i have no problems with... ( Well, sendmail 8.8.5 - no problems, too... ) > > The author should probably instead try to get people to apply it in their > own environments and test it for him. If there is enough popular demand > then people might make more effort to commit it. > > Just out of curiosity has this patch been submitted to OpenBSD? Not. Right now i have no time, but on the next week i'll port it to OpenBSD/i386. -- Alexander Snarskii the source code is included. From owner-freebsd-hackers Wed Feb 12 12:34:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA24780 for hackers-outgoing; Wed, 12 Feb 1997 12:34:15 -0800 (PST) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA24771 for ; Wed, 12 Feb 1997 12:34:10 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr2-38.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA06699 (5.67b/IDA-1.5 for ); Wed, 12 Feb 1997 21:34:04 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.5/8.6.9) id VAA04184; Wed, 12 Feb 1997 21:33:18 +0100 (CET) Message-Id: <19970212213157.YA20116@x14.mi.uni-koeln.de> Date: Wed, 12 Feb 1997 21:31:57 +0100 From: se@freebsd.org (Stefan Esser) To: helbig@mx.ba-stuttgart.de (Wolfgang Helbig) Cc: hackers@freebsd.org Subject: Re: CMD640b workaround - final(?) version References: <199702112257.XAA01704@helbig.informatik.ba-stuttgart.de> X-Mailer: Mutt 0.60-PL0 Mime-Version: 1.0 In-Reply-To: <199702112257.XAA01704@helbig.informatik.ba-stuttgart.de>; from Wolfgang Helbig on Feb 11, 1997 23:57:44 +0100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Feb 11, helbig@MX.BA-Stuttgart.De (Wolfgang Helbig) wrote: > If you use the > options "CMD640" > you also *have* to put > controller pci0 > into your configuration file! Maybe someone can put the right clauses > in /sys/conf/files to automaticly resoving this (ugly) dependency! Ahemm ? The CMD640 option obviously makes no sense on a system without a PCI bus. But I agree, that it violates the principle of least surprise, if this option causes a kernel build to fail for a non-PCI system (without the controller pci0 line). There are 2 possible workarounds: 1) Include pci.h into the wd driver, and #undef CMD640, if NCPI == 0. 2) Move the definition of "cmd640_detected" into wd.c, and make the PCI probe code use it as an *external* variable only if CMD640 is defined. BTW: I do heavily dislike the way you introduced the PCI ID of the CMD640 into pci.c, and will not accept it! There is NO device specific code in pci.c for a reason! Please take a look at if_ed_p.c for a trivial PCI probe and attach example. In fact, your atatch code will just be "return wd_attach (.., .., /* cmd640_present = */ 1)" and you will have to modify the attach function in wd.c to accept that additional parameter ... (In fact, I'd rather make it an "eide_implementation" parameter, which is an enumeration of all the chips that may be supported by this mechanism at a time :) Regards, STefan From owner-freebsd-hackers Wed Feb 12 13:09:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA26228 for hackers-outgoing; Wed, 12 Feb 1997 13:09:52 -0800 (PST) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA26212 for ; Wed, 12 Feb 1997 13:09:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hydrogen.nike.efn.org (8.8.4/8.8.4) with SMTP id NAA21341; Wed, 12 Feb 1997 13:08:22 -0800 (PST) Date: Wed, 12 Feb 1997 13:07:56 -0800 (PST) From: John-Mark Gurney Reply-To: John-Mark Gurney To: Chris Coleman cc: hackers@freebsd.org Subject: Re: handbook in sgml In-Reply-To: Message-ID: X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 12 Feb 1997, Chris Coleman wrote: > Where can i get a copy of the handbook in sgml form? > I had one once, but I forgot where I got it. ftp://ftp.cdrom.com/pub/FreeBSD/FreeBSD-current/src/share/doc/handbook/* that should do it... ttyl.. John-Mark gurney_j@efn.org http://resnet.uoregon.edu/~gurney_j/ Modem/FAX: (541) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) From owner-freebsd-hackers Wed Feb 12 13:40:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA27662 for hackers-outgoing; Wed, 12 Feb 1997 13:40:56 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA27657 for ; Wed, 12 Feb 1997 13:40:54 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id NAA27466 for ; Wed, 12 Feb 1997 13:42:07 -0800 (PST) Received: (qmail 14196 invoked by uid 110); 12 Feb 1997 21:39:54 -0000 Message-ID: <19970212213953.14194.qmail@suburbia.net> Subject: Re: Increasing overall security.... In-Reply-To: from Philippe Regnauld at "Feb 12, 97 02:59:14 pm" To: regnauld@deepo.prosa.dk (Philippe Regnauld) Date: Thu, 13 Feb 1997 08:39:53 +1100 (EST) Cc: michaelh@cet.co.jp, freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Michael Hancock (michaelh) ecrit/writes: > > > > 2) We don't know if it operates correctly. Sendmail 8.8.5 has around 106 > > strcpy's in it and we don't know what the patch's effect will be in a > > production environment. > > 107 explicit. Until you check: > > #define newstr(s) strcpy(xalloc(strlen(s) + 1), s) > > ... of which there are _many_. And of which none can ever fail. -- Prof. Julian Assange |If you want to build a ship, don't drum up people |together to collect wood and don't assign them tasks proff@iq.org |and work, but rather teach them to long for the endless proff@gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery From owner-freebsd-hackers Wed Feb 12 13:46:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA27955 for hackers-outgoing; Wed, 12 Feb 1997 13:46:26 -0800 (PST) Received: from aries.bb.cc.wa.us (root@[208.8.136.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA27946 for ; Wed, 12 Feb 1997 13:46:23 -0800 (PST) Received: from localhost (chris@localhost) by aries.bb.cc.wa.us (8.8.3/8.6.9) with SMTP id NAA07043; Wed, 12 Feb 1997 13:40:49 -0800 (PST) Date: Wed, 12 Feb 1997 13:40:49 -0800 (PST) From: Chris Coleman To: John-Mark Gurney cc: hackers@freebsd.org Subject: Re: handbook in sgml In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thanks. Christopher J. Coleman (chris@aries.bb.cc.wa.us) Computer Support Technician I (509)-766-8873 Big Bend Community College Internet Instructor FreeBSD Book Project: http://www.bb.cc.wa.us/~chris/book.html I may Be inaffective, but atleast I am good at it. On Wed, 12 Feb 1997, John-Mark Gurney wrote: > On Wed, 12 Feb 1997, Chris Coleman wrote: > > > Where can i get a copy of the handbook in sgml form? > > I had one once, but I forgot where I got it. > > ftp://ftp.cdrom.com/pub/FreeBSD/FreeBSD-current/src/share/doc/handbook/* > > that should do it... ttyl.. > > John-Mark > > gurney_j@efn.org > http://resnet.uoregon.edu/~gurney_j/ > Modem/FAX: (541) 683-6954 (FreeBSD Box) > > Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) > > From owner-freebsd-hackers Wed Feb 12 14:11:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA29201 for hackers-outgoing; Wed, 12 Feb 1997 14:11:58 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA29188 for ; Wed, 12 Feb 1997 14:11:50 -0800 (PST) Received: (from jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) id OAA00497; Wed, 12 Feb 1997 14:11:42 -0800 (PST) To: freebsd-hackers@freebsd.org Path: not-for-mail From: jdp@polstra.com (John Polstra) Newsgroups: polstra.freebsd.hackers Subject: Re: handbook in sgml Date: 12 Feb 1997 14:11:42 -0800 Organization: Polstra & Co., Seattle, WA Lines: 12 Distribution: local Message-ID: <5dtf6u$fe@austin.polstra.com> References: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article , Chris Coleman wrote: > Where can i get a copy of the handbook in sgml form? > I had one once, but I forgot where I got it. /usr/src/share/doc/handbook John P. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Wed Feb 12 14:44:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA00881 for hackers-outgoing; Wed, 12 Feb 1997 14:44:30 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA00874 for ; Wed, 12 Feb 1997 14:44:22 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id WAA12301; Wed, 12 Feb 1997 22:41:14 GMT Date: Thu, 13 Feb 1997 07:41:13 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: dk+@ua.net, snar@lucky.net, freebsd-hackers@freebsd.org Subject: Re: Increasing overall security.... In-Reply-To: <199702121710.KAA00703@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 12 Feb 1997, Terry Lambert wrote: > > To play devil's advocate... > > > > 1) It requires assembler which is harder to understand. Less people are > > qualified to review it. Relying on something harder to understand for > > security is questionable. > > This is not a "security through obscurity" issue. The code is hard to > understand because of the people trying to understand it, not because > the difficulty in understanding it is one of the intentional effects. I didn't say it was "security through obscurity". Look at TIS's FWTK for the philosophy I'm talking about. Mike Hancock From owner-freebsd-hackers Wed Feb 12 14:51:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA01214 for hackers-outgoing; Wed, 12 Feb 1997 14:51:36 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA01206 for ; Wed, 12 Feb 1997 14:51:30 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id WAA12342; Wed, 12 Feb 1997 22:49:33 GMT Date: Thu, 13 Feb 1997 07:49:33 +0900 (JST) From: Michael Hancock To: Alexander Snarskii cc: dk+@ua.net, freebsd-hackers@FreeBSD.org Subject: Re: Increasing overall security.... In-Reply-To: <199702122023.WAA21544@burka.carrier.kiev.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 12 Feb 1997, Alexander Snarskii wrote: > > To play devil's advocate... > > > > 1) It requires assembler which is harder to understand. Less people are > > qualified to review it. Relying on something harder to understand for > > security is questionable. > > Yes, it is. But there are about 51 functions in standard libc, realized > on assembler, so, i think there are someone, who wrote it, and knew > assembler well to review .... The intention of those functions is not security. > > > > 2) We don't know if it operates correctly. Sendmail 8.8.5 has around 106 > > strcpy's in it and we don't know what the patch's effect will be in a > > production environment. > > Mike, do you think that i published this patches without correct > check of working ? These patches are applied on my main computers > about week or so, and i have no problems with... > ( Well, sendmail 8.8.5 - no problems, too... ) I'm sure you checked it. You have to understand that skepticism is a natural thing. Regards, Mike Hancock From owner-freebsd-hackers Wed Feb 12 15:03:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA01664 for hackers-outgoing; Wed, 12 Feb 1997 15:03:06 -0800 (PST) Received: from terminator.informatik.ba-stuttgart.de (terminator.informatik.ba-stuttgart.de [141.31.1.21]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA01659; Wed, 12 Feb 1997 15:02:48 -0800 (PST) Received: from helbig.informatik.ba-stuttgart.de (helbig.informatik.ba-stuttgart.de [141.31.166.22]) by terminator.informatik.ba-stuttgart.de (8.7.6/8.7.3) with ESMTP id XAA21625; Wed, 12 Feb 1997 23:02:04 +0100 Received: (from helbig@localhost) by helbig.informatik.ba-stuttgart.de (8.8.5/8.8.5) id AAA00343; Thu, 13 Feb 1997 00:02:35 +0100 (MET) From: Wolfgang Helbig Message-Id: <199702122302.AAA00343@helbig.informatik.ba-stuttgart.de> Subject: Re: CMD640b workaround - final(?) version In-Reply-To: <19970212213157.YA20116@x14.mi.uni-koeln.de> from Stefan Esser at "Feb 12, 97 09:31:57 pm" To: se@freebsd.org (Stefan Esser) Date: Thu, 13 Feb 1997 00:02:34 +0100 (MET) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Stefan Esser wrote > On Feb 11, helbig@MX.BA-Stuttgart.De (Wolfgang Helbig) wrote: > > If you use the > > options "CMD640" > > you also *have* to put > > controller pci0 > > into your configuration file! Maybe someone can put the right clauses > > in /sys/conf/files to automaticly resoving this (ugly) dependency! > > Ahemm ? > What I wanted to be achieved by changing /sys/conf/files is: If you put options "CMD640" in your kernel configuration file you will automatically get the pci-code included and started in the kernel, even if you don't put the controller pci0 line in the configuration file. Since I do not grasp the workings of /sys/conf/files and /sys/i386/conf/files.i386, I don't know whether this is possible. Now suppose a newbie has installed successfully FreeBSD on a machine with the CMD640b-controller, (because the generic kernel does have options "CMD640" and controller pci0). He does not even know, that he has something special, because he used the same machine with Windos and LINUX before and didn't have any trouble. (ok, the newbie is me :-) ) Now he want's to build a customized kernel. He will find out that he needs the CMD640b option (as I would have found out) and that he does not need the pci-controller code, because it does not do any good. (That is the way I proceeded. I did not have the pci-code in my kernel.) So now if you leave the definition of cmd640_detected in pci.c our newbie will get a link error. If you put this definition in wd.c, our newbie will not get a link error but the kernel will freeze after the first attempt to use both ide-channels simultaneously. I believe the second perspective is worse, because it is harder to recover and early detected errors are less harmful in general. > The CMD640 option obviously makes no sense on a system > without a PCI bus. But I agree, that it violates the But a kernel w/o pci-support *does* make sense on a system with PCI bus, because the pci-code is simply overhead if no pci-drivers get installed. > principle of least surprise, if this option causes a > kernel build to fail for a non-PCI system (without the > controller pci0 line). > > > There are 2 possible workarounds: > > 1) Include pci.h into the wd driver, and #undef CMD640, > if NCPI == 0. > > 2) Move the definition of "cmd640_detected" into wd.c, > and make the PCI probe code use it as an *external* > variable only if CMD640 is defined. > > > BTW: I do heavily dislike the way you introduced the PCI > ID of the CMD640 into pci.c, and will not accept it! > > There is NO device specific code in pci.c for a reason! BTW: My solution is simpler. For a reason! I do heavily dislike complicated code if there is a simpler way! Do whatever you want with it, I will accept it! Wolfgang Helbig. From owner-freebsd-hackers Wed Feb 12 15:19:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA02358 for hackers-outgoing; Wed, 12 Feb 1997 15:19:59 -0800 (PST) Received: from mole.mole.org (marmot.mole.org [204.216.57.191]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA02353 for ; Wed, 12 Feb 1997 15:19:56 -0800 (PST) Received: (from mail@localhost) by mole.mole.org (8.6.12/8.6.12) id XAA02255; Wed, 12 Feb 1997 23:20:17 GMT Received: from meerkat.mole.org(206.197.192.110) by mole.mole.org via smap (V1.3) id sma002249; Wed Feb 12 23:19:56 1997 Received: (from mrm@localhost) by meerkat.mole.org (8.6.11/8.6.9) id PAA10596; Wed, 12 Feb 1997 15:19:04 -0800 Date: Wed, 12 Feb 1997 15:19:04 -0800 From: "M.R.Murphy" Message-Id: <199702122319.PAA10596@meerkat.mole.org> To: michaelh@cet.co.jp, snar@lucky.net Subject: Re: Increasing overall security.... Cc: dk+@ua.net, freebsd-hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Mike, do you think that i published this patches without correct > > check of working ? These patches are applied on my main computers > > about week or so, and i have no problems with... > > ( Well, sendmail 8.8.5 - no problems, too... ) > > I'm sure you checked it. You have to understand that skepticism is a > natural thing. > Were the patches checked WRT denial of service attack? ;-) And all that can lead to...? -- Mike Murphy mrm@Mole.ORG +1 619 598 5874 Better is the enemy of Good From owner-freebsd-hackers Wed Feb 12 15:44:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA03482 for hackers-outgoing; Wed, 12 Feb 1997 15:44:05 -0800 (PST) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA03422; Wed, 12 Feb 1997 15:43:46 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr3-11.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA08283 (5.67b/IDA-1.5); Thu, 13 Feb 1997 00:43:37 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.5/8.6.9) id AAA09275; Thu, 13 Feb 1997 00:42:52 +0100 (CET) Message-Id: <19970213004131.DV50639@x14.mi.uni-koeln.de> Date: Thu, 13 Feb 1997 00:41:31 +0100 From: se@freebsd.org (Stefan Esser) To: helbig@mx.ba-stuttgart.de (Wolfgang Helbig) Cc: se@freebsd.org (Stefan Esser), hackers@freebsd.org Subject: Re: CMD640b workaround - final(?) version References: <19970212213157.YA20116@x14.mi.uni-koeln.de> <199702122302.AAA00343@helbig.informatik.ba-stuttgart.de> X-Mailer: Mutt 0.60-PL0 Mime-Version: 1.0 In-Reply-To: <199702122302.AAA00343@helbig.informatik.ba-stuttgart.de>; from Wolfgang Helbig on Feb 13, 1997 00:02:34 +0100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Feb 13, helbig@MX.BA-Stuttgart.De (Wolfgang Helbig) wrote: > What I wanted to be achieved by changing /sys/conf/files is: > If you put > options "CMD640" > in your kernel configuration file you will automatically get the pci-code > included and started in the kernel, even if you don't put the > controller pci0 > line in the configuration file. > Since I do not grasp the workings of /sys/conf/files and > /sys/i386/conf/files.i386, I don't know whether this is possible. No. The "options" lines just generate #defines, which will be put into some opt_xxx.h file (prefered method) or just be made part of the kernel Makefile (as -Dxxx). > Now suppose a newbie has installed successfully FreeBSD on a machine > with the CMD640b-controller, (because the generic kernel does have > options "CMD640" and controller pci0). He does not even know, that > he has something special, because he used the same machine with Windos > and LINUX before and didn't have any trouble. (ok, the newbie is me :-) ) > > Now he want's to build a customized kernel. He will find out that he needs > the CMD640b option (as I would have found out) and that he does not need > the pci-controller code, because it does not do any good. (That is the > way I proceeded. I did not have the pci-code in my kernel.) You have PCI chips in your system (at least the chip-set, and most probably your VGA card) and should not expect the kernel to work at all, unless "pci0" is included in the kernel config file. > So now if you leave the definition of cmd640_detected in pci.c our newbie > will get a link error. Yes. This is expected behaviour. He will learn something, this way :) > If you put this definition in wd.c, our newbie will not get a link > error but the kernel will freeze after the first attempt to use both > ide-channels simultaneously. Well, it will just behave like the kernel without that option, since there is no way, the driver will find out about the CMD 640 chip, if the PCI probe is not there. > I believe the second perspective is worse, because it is harder to > recover and early detected errors are less harmful in general. Its true, that an error should be signaled as early as possible, but this does not make the second workaround "worse", IMHO. This EIDE controller is just broken, and it is possible to work around (some of) its hardware defeciencies. > > The CMD640 option obviously makes no sense on a system > > without a PCI bus. But I agree, that it violates the > > But a kernel w/o pci-support *does* make sense on a system with PCI bus, > because the pci-code is simply overhead if no pci-drivers get installed. How about your VGA card ? The PCI code is very little overhead, and you just should not expect your PCI system to work at all, if you do not have pci0 defined. > > BTW: I do heavily dislike the way you introduced the PCI > > ID of the CMD640 into pci.c, and will not accept it! > > > > There is NO device specific code in pci.c for a reason! > > BTW: My solution is simpler. For a reason! > I do heavily dislike complicated code if there is a simpler way! Well, and believe in layering, to make it easy to deal with complex situations. (The world happens to be complex at times.) For that reason, there will not be a test for a particular PCI device ID in the device independent PCI code. > Do whatever you want with it, I will accept it! Well, I don't have any way to test the WD driver, since I do not own any (E)IDE drives. It is trivial to add a clean CMD640 probe/attach, and it will add only a few instructions over the code you suggested. I still prefer my second suggested way to deal with the CMD640 option, and you just have to understand, that the option will have no effect, if you did not include the PCI bus code into the kernel, and thus prevented the detection of the CMD 640 chip ... Since just about every EIDE chip currently used seems to have severe bugs, we should just have one probe, that calls into the WD driver with an appropriate chip ID param, IMHO. This should also be done in order to allow to add support for EIDE DMA transfer modes, which may need chip specific driver support. Gruss, STefan From owner-freebsd-hackers Wed Feb 12 16:35:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA06046 for hackers-outgoing; Wed, 12 Feb 1997 16:35:07 -0800 (PST) Received: from oneway.com (oneway.com [198.80.68.27]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA06010; Wed, 12 Feb 1997 16:34:48 -0800 (PST) Received: from localhost (jaykuri@localhost) by oneway.com (8.8.3/8.8.3) with SMTP id SAA23679; Wed, 12 Feb 1997 18:29:59 -0600 (CST) Date: Wed, 12 Feb 1997 18:29:59 -0600 (CST) From: Jay Kuri Reply-To: Jay Kuri To: hackers@freebsd.org, questions@freebsd.org cc: Wes Peters Subject: Max open files per process, changing param.c Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, I'm working on some programs that require very large numbers of files open per process. 200-500 easily. I've done some research, and came to /usr/src/sys/conf/param.c... I notice that the system-wide-limit for open files is the same as the per-process-limit for open files. My main question is this: What, if any, ramifications will changing 'maxfiles' in param.c to increase max open files system-wide? If 'maxfilesperproc' is different from 'maxfiles' will that cause any problems? Additionally, Will I run into other problems with regard to high file descriptor numbers? I know that on Solaris (2.5 anyway) even though you can kick the max-open-files per process up to 2048, the FILE structure limits the file descriptor number to 1 byte, to 256 total. Will I run into similar problems with FreeBSD? Any Help would be appreciated, Jay --- Everyone can be taught to sculpt: Michelangelo would have had to be taught how not to. So it is with the great programmers. From owner-freebsd-hackers Wed Feb 12 17:38:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA09448 for hackers-outgoing; Wed, 12 Feb 1997 17:38:33 -0800 (PST) Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA09441 for ; Wed, 12 Feb 1997 17:38:29 -0800 (PST) Received: (from asami@localhost) by vader.cs.berkeley.edu (8.8.4/8.7.3) id RAA16421; Wed, 12 Feb 1997 17:37:05 -0800 (PST) Date: Wed, 12 Feb 1997 17:37:05 -0800 (PST) Message-Id: <199702130137.RAA16421@vader.cs.berkeley.edu> To: terry@lambert.org CC: danny@panda.hilink.com.au, hackers@freebsd.org In-reply-to: <199702121725.KAA00750@phaeton.artisoft.com> (message from Terry Lambert on Wed, 12 Feb 1997 10:25:31 -0700 (MST)) Subject: Re: strlen() question From: asami@vader.cs.berkeley.edu (Satoshi Asami) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * PS: You are required to pass only NULL terminated strings to strlen(); That's "NUL". Satoshi From owner-freebsd-hackers Wed Feb 12 17:44:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA09907 for hackers-outgoing; Wed, 12 Feb 1997 17:44:45 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA09882; Wed, 12 Feb 1997 17:44:35 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id MAA08127; Thu, 13 Feb 1997 12:36:55 +1100 Date: Thu, 13 Feb 1997 12:36:55 +1100 From: Bruce Evans Message-Id: <199702130136.MAA08127@godzilla.zeta.org.au> To: hackers@freebsd.org, jaykuri@oneway.com, questions@freebsd.org Subject: Re: Max open files per process, changing param.c Cc: softweyr@xmission.com Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > What, if any, ramifications will changing 'maxfiles' in param.c to >increase max open files system-wide? Don't change it in param.c. Change it in /etc/rc.local using `sysctl -w kern.maxfiles=nnnn'. This shouldn't cause any problems except increased memory usage. You may want to increase kern.maxvnodes too. Setting of these is broken in some old versions of FreeBSD-current. >If 'maxfilesperproc' is different >from 'maxfiles' will that cause any problems? None that can't be caused in other ways (except if it is too small, it limits what can be done using setrlimit()). maxfilesperproc will go away soon. login.conf handles limits better. >Additionally, Will I run into other problems with regard to high file >descriptor numbers? I know that on Solaris (2.5 anyway) even though you Yes, select() will break for fd's >= FD_SETSIZE (default 256). The kernel handles any number of fd's, but applications only handle ones up to the value of FD_SETSIZE that they were compiled with. Don't expect to use standard or old applications if you set maxfilesperproc > 256). The default may be increased to 1024 in future releases. >can kick the max-open-files per process up to 2048, the FILE structure >limits the file descriptor number to 1 byte, to 256 total. Will I run >into similar problems with FreeBSD? Not that one. Bruce From owner-freebsd-hackers Wed Feb 12 18:11:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA11522 for hackers-outgoing; Wed, 12 Feb 1997 18:11:01 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA11517 for ; Wed, 12 Feb 1997 18:10:56 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA01285; Wed, 12 Feb 1997 19:04:08 -0700 From: Terry Lambert Message-Id: <199702130204.TAA01285@phaeton.artisoft.com> Subject: Re: strlen() question To: asami@vader.cs.berkeley.edu (Satoshi Asami) Date: Wed, 12 Feb 1997 19:04:08 -0700 (MST) Cc: terry@lambert.org, danny@panda.hilink.com.au, hackers@freebsd.org In-Reply-To: <199702130137.RAA16421@vader.cs.berkeley.edu> from "Satoshi Asami" at Feb 12, 97 05:37:05 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > * PS: You are required to pass only NULL terminated strings to strlen(); > > That's "NUL". Heh. You and Sean. "NULL" is an untyped 0. Actually, it's a 0 terminated string. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Feb 12 18:22:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA12056 for hackers-outgoing; Wed, 12 Feb 1997 18:22:52 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA12051 for ; Wed, 12 Feb 1997 18:22:50 -0800 (PST) Received: from bios-nt.sunbeach.net (MAIL.SUNBEACH.NET [205.214.199.134]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id SAA08396 for ; Wed, 12 Feb 1997 18:22:40 -0800 (PST) Received: from bios-nt.sunbeach.net by bios-nt.sunbeach.net (NTMail 3.02.11) with ESMTP id wa122248 for ; Wed, 12 Feb 1997 22:22:44 -0400 Message-ID: <33027AD6.41C67EA6@sunbeach.net> Date: Wed, 12 Feb 1997 22:22:14 -0400 From: Sean Batson X-Mailer: Mozilla 3.0 (X11; I; BSDI BSD/OS 2.1.5-RELEASE i386) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk unsubscribe From owner-freebsd-hackers Wed Feb 12 18:24:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA12254 for hackers-outgoing; Wed, 12 Feb 1997 18:24:09 -0800 (PST) Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA12248 for ; Wed, 12 Feb 1997 18:24:05 -0800 (PST) Received: (from asami@localhost) by vader.cs.berkeley.edu (8.8.4/8.7.3) id SAA16536; Wed, 12 Feb 1997 18:22:43 -0800 (PST) Date: Wed, 12 Feb 1997 18:22:43 -0800 (PST) Message-Id: <199702130222.SAA16536@vader.cs.berkeley.edu> To: terry@lambert.org CC: terry@lambert.org, danny@panda.hilink.com.au, hackers@freebsd.org In-reply-to: <199702130204.TAA01285@phaeton.artisoft.com> (message from Terry Lambert on Wed, 12 Feb 1997 19:04:08 -0700 (MST)) Subject: Re: strlen() question From: asami@vader.cs.berkeley.edu (Satoshi Asami) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * Heh. You and Sean. "NULL" is an untyped 0. Actually, it's a 0 * terminated string. man 9 style Satoshi From owner-freebsd-hackers Wed Feb 12 18:36:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA12991 for hackers-outgoing; Wed, 12 Feb 1997 18:36:16 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA12981 for ; Wed, 12 Feb 1997 18:36:11 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id NAA16781 for hackers@freebsd.org; Thu, 13 Feb 1997 13:06:00 +1030 (CST) From: Michael Smith Message-Id: <199702130236.NAA16781@genesis.atrad.adelaide.edu.au> Subject: _big_ IDE disks? To: hackers@freebsd.org Date: Thu, 13 Feb 1997 13:06:00 +1030 (CST) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ok, those of you that follow -hardware will know that I've been forced to buy IDE disks for a couple of systems that I would much rather have gone SCSI for. No turning back now. These are the 5GB Maxtor 'DiamondMax' disks we're talking about here, talking to a Tekram P5H30WS motherboard (current Award BIOS). The problem set looks something like this : - during probe, the disk is reported thus : a8tor 85120 A8 ->: < wd0: 633MB (9685824 sectors), 9224 cylinders, 16 heads, 61 S/T, 512 B/S Yes, that's garbage in the probe message. The sizing is a shade screwed too. The geometry is one that I put onto the disk forcibly using the FreeBSD installer, but _not_ that configured into the BIOS. - While installing, the installer seems to write the partition table OK, but can't write the label or swap on the disk. Briefly, has anyone done anything with one of these disks before? I get the impression I'm walking in unknown territory here 8) -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Feb 12 18:59:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA13777 for hackers-outgoing; Wed, 12 Feb 1997 18:59:20 -0800 (PST) Received: from kithrup.com (kithrup.com [205.179.156.40]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA13770 for ; Wed, 12 Feb 1997 18:59:15 -0800 (PST) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id SAA04282; Wed, 12 Feb 1997 18:57:29 -0800 Date: Wed, 12 Feb 1997 18:57:29 -0800 From: Sean Eric Fagan Message-Id: <199702130257.SAA04282@kithrup.com> To: terry@lambert.org Subject: Re: strlen() question Newsgroups: kithrup.freebsd.hackers In-Reply-To: <199702130204.TAA01285.kithrup.freebsd.hackers@phaeton.artisoft.com> References: <199702130137.RAA16421@vader.cs.berkeley.edu> from "Satoshi Asami" at Feb 12, 97 05:37:05 pm Organization: Kithrup Enterprises, Ltd. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199702130204.TAA01285.kithrup.freebsd.hackers@phaeton.artisoft.com> you write: >Heh. You and Sean. "NULL" is an untyped 0. Actually, it's a 0 >terminated string. NO NO NO! ptr = 0; and ptr = NULL; are the equivalent. That does *not* mean that NULL is 0. NULL is allowed to be other things -- on one system, it was 0xffff:0x0000. And char need not be only 7 bits. "NUL" is the ASCII name for the octet of all zero bits. NULL is something completely different. (Note that I wouldn't be this pedantic normally, but this is *Terry* saying this, so I felt kinda obligated ;).) Sean. From owner-freebsd-hackers Wed Feb 12 19:20:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA14596 for hackers-outgoing; Wed, 12 Feb 1997 19:20:51 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA14587 for ; Wed, 12 Feb 1997 19:20:42 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id NAA17080; Thu, 13 Feb 1997 13:50:32 +1030 (CST) From: Michael Smith Message-Id: <199702130320.NAA17080@genesis.atrad.adelaide.edu.au> Subject: Re: _big_ IDE disks? In-Reply-To: <199702130236.NAA16781@genesis.atrad.adelaide.edu.au> from Michael Smith at "Feb 13, 97 01:06:00 pm" To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Thu, 13 Feb 1997 13:50:31 +1030 (CST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Some more information : Michael Smith stands accused of saying: > These are the 5GB Maxtor 'DiamondMax' disks we're talking about here, > talking to a Tekram P5H30WS motherboard (current Award BIOS). > > The problem set looks something like this : > > - during probe, the disk is reported thus : > > a8tor 85120 A8 ->: < This apears to be about right; DM (Maxtor's "MaxBlast" software) reports the same ID. Weird. Anyone have any contacts at Maxtor I should be bugging about this? > wd0: 633MB (9685824 sectors), 9224 cylinders, 16 heads, 61 S/T, 512 B/S The '633MB' is due to bad arithmetic in wd.c, where an intermediate is set to the number of bytes on the disk : du->dk_dd.d_secperunit * du->dk_dd.d_secsize / (1024 * 1024), I propose to change this to : (long)((long long)du->dk_dd.d_secperunit * du->dk_dd.d_secsize / (1024 * 1024)), in order to force the intermediate values to 'long long'. An alternative would be to use the approach that sd.c does : dp->disksize / ((1024L * 1024L) / dp->secsiz) which loses some precision but avoids playing type games. Comments? > - While installing, the installer seems to write the partition table OK, > but can't write the label or swap on the disk. This appears to be because I can't make a single partition bigger than 4GB. I'll try installing to the Jaz in this box so that I can get it onto our network. Soren, if you're playing ATA god, I'd really appreciate any input you may have here. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Feb 12 20:11:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA16432 for hackers-outgoing; Wed, 12 Feb 1997 20:11:11 -0800 (PST) Received: from wong.rogerswave.ca (a17b32.rogerswave.ca [204.92.17.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA16426 for ; Wed, 12 Feb 1997 20:11:07 -0800 (PST) Received: (from wong@localhost) by wong.rogerswave.ca (8.8.5/8.7.3) id XAA00379; Wed, 12 Feb 1997 23:11:06 -0500 (EST) Date: Wed, 12 Feb 1997 23:11:01 -0500 (EST) From: Ken Wong X-Sender: wong@wong.rogerswave.ca Reply-To: wong@rogerswave.ca To: Joerg Wunsch cc: "Daniel O'Callaghan" , hackers@freebsd.org Subject: Re: strlen() question, maybe str*cpy In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 12 Feb 1997, J Wunsch wrote: > Why? The worst that would happen by touching off the end of your > address space is a SIGSEGV. The problem with str*cpy() touching > beyond the bounds of their arrays is that they can _modify_ the stack > then, but that can't happen with strlen() since it doesn't modify > anything. why isn't the str*cpy check the BP (base pointer?) register and use it to gaurd against stack over right? Ken From owner-freebsd-hackers Wed Feb 12 20:37:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA17235 for hackers-outgoing; Wed, 12 Feb 1997 20:37:04 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA17227 for ; Wed, 12 Feb 1997 20:36:58 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id EAA14539; Thu, 13 Feb 1997 04:29:49 GMT Date: Thu, 13 Feb 1997 13:29:48 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: Terry Lambert cc: dk+@ua.net, snar@lucky.net, freebsd-hackers@FreeBSD.org Subject: Re: Increasing overall security.... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk [I guess I should supply a better punch line.] On Thu, 13 Feb 1997, Michael Hancock wrote: > On Wed, 12 Feb 1997, Terry Lambert wrote: > > > > To play devil's advocate... > > > > > > 1) It requires assembler which is harder to understand. Less people are > > > qualified to review it. Relying on something harder to understand for > > > security is questionable. > > > > This is not a "security through obscurity" issue. The code is hard to > > understand because of the people trying to understand it, not because > > the difficulty in understanding it is one of the intentional effects. > > I didn't say it was "security through obscurity". Look at TIS's FWTK for > the philosophy I'm talking about. > > Mike Hancock It's about the degree to which the code can be publically verified to be secure and maintained to be secure. I wrote a graphics device driver 13 years ago in 286 assembler when working parttime because I had to make it fast. I enjoyed writing it at the time, but I didn't enjoy going back to make changes. And I would definitely not enjoy maintaining someone else's assembler. Cheswick & Bellovin, "Firewalls and Internet Security", explain the mindset you need pretty well. O'Reilly's Firewall book talks about Internet security in more practical terms, i.e. they recognize sendmail as being in the "lots of bugs, lots of people looking at it" category Philippe mentioned earlier. Regards, Mike Hancock From owner-freebsd-hackers Wed Feb 12 20:41:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA17467 for hackers-outgoing; Wed, 12 Feb 1997 20:41:25 -0800 (PST) Received: from gdi.uoregon.edu (gdi.uoregon.edu [128.223.170.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA17462 for ; Wed, 12 Feb 1997 20:41:22 -0800 (PST) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.5/8.6.12) with SMTP id UAA00476; Wed, 12 Feb 1997 20:39:54 -0800 (PST) Date: Wed, 12 Feb 1997 20:39:54 -0800 (PST) From: Doug White X-Sender: dwhite@localhost Reply-To: Doug White To: Joe Greco cc: hackers@freebsd.org Subject: Re: Need definitive answer on de 21140-AC driver In-Reply-To: <199702121254.GAA25336@solaria.sol.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 12 Feb 1997, Joe Greco wrote: > When I talked to Matt Thomas, several months ago, he provided me a prototype > driver that compiled under 2.1.6R. I beat the snot out of it and have since > been using it in production, mostly with the SMC dual port 10/100's, but > also a few other -AC cards like the Kingston. There are a few bugs in the > driver, none of which affect the usability of the cards. > > > Is there a new driver in the works? If not, I'll gladly donate this card > > for a while if it's a matter of just getting the card to the right person. > > Offered to do that too :-) Matt seems to have what needs doing nailed > down pretty well. I've hinted to him several times I'd like a 2.2* driver > but so far I haven't seen one. Well, shall I bother him again? > That's too bad because the de driver is a really cool thing to have, and > if we only support old 100mbps cards that are no longer made, well, yuck. It's not that I need 100mbps (we _JUST_ installed this 10mb network not two years ago), but I'd like the Kingston to work so I can return this crummy 3c900. 3k for input buffers, what were they thinking?!? Name Mtu Network Address Ipkts Ierrs Opkts Oerrs vx0 1500 00.a0.24.ba.13.f8 258480 244083 6868 0 vx0 1500 128.223.170/2 gdi 258480 244083 6868 0 (hm, the errors caught up, it doesn't seem to affect multicast.) > I suspect it's mainly a matter of getting Matt to release a version of his > code. According to the current if_de.c, his email is matt@3am-software.com -- I shall fire off an inquisitive email following this. Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major From owner-freebsd-hackers Wed Feb 12 20:58:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA17901 for hackers-outgoing; Wed, 12 Feb 1997 20:58:09 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA17896 for ; Wed, 12 Feb 1997 20:58:08 -0800 (PST) Received: from lightside.com (hamby1.lightside.net [207.67.176.17]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id UAA08638 for ; Wed, 12 Feb 1997 20:58:01 -0800 (PST) Received: by lightside.com (SMI-8.6/SMI-SVR4) id UAA01601; Wed, 12 Feb 1997 20:50:59 -0800 Date: Wed, 12 Feb 1997 20:50:59 -0800 From: jehamby@lightside.com (Jake Hamby) Message-Id: <199702130450.UAA01601@lightside.com> To: jb@cimlogic.com.au, terry@lambert.org Subject: Re: MIME applications for FreeBSD Cc: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: wIvODx8KA6q2hZ5UNMSFgA== Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert writes: > As to what binary data is permitted to be encoded: > > 1) Any binary data the sender and the recipient can agree upon > > > Though I'd be perfectly happy to see this limited to binary data for > which public source reference implementations exist (ie: no more Word > documents unless Microsoft publically documents Word file format, no > PDF documents unless Adobe documents their "encryption" preventing > the use of non-Adobe readers, but not preventing any Adobe reader from > decoding the document, etc., etc.). Absolutely! Although figuring out the lowest common denomintor for, e.g. rich text, often leads to all sorts of oddities. For example, I just received a price quote for a Micron PC by E-Mail, in of all things, UUENCODED RTF format! As I happily uudecoded it, and imported it into WordPerfect 6.0 for UNIX on my SPARCstation, I couldn't help but wonder about the poor PC lusers running Eudora, etc., and trying to figure THAT out. Hmm, now that I think of it, Netscape does automagically decode UUencoded pictures from USENET (hmm, wonder what Netscape programmer was reading alt.binaries.pictures.erotica when he thought of adding that feature ;), maybe it does the same thing for E-Mail? Oh well.. Another comment on this dangerously off-topic thread: There is now commercial gateway software designed specifically to look at MIME attachments and convert them into a format friendly to the recipient. They even go so far as to add an appropriate resource fork if the recipient is a Mac user, or add the 3-character extension if the recipient is a PC user. Wonder what happens if the recipient's using UNIX? :) Anyway, I used to get really upset when PC/Mac users at work sent me MS Office documents as attachments, but now that WABI is fast enough for me, I just use that. Now that I have a decent version of WABI at home (Solaris/x86), it looks like that won't be a problem with my personal mailbox either, but of course, if somebody sent me a Word document in my private mailbox, I'd probably delete it as a matter of principle... :). -- Jake From owner-freebsd-hackers Wed Feb 12 21:05:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA18266 for hackers-outgoing; Wed, 12 Feb 1997 21:05:16 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA18248 for ; Wed, 12 Feb 1997 21:05:12 -0800 (PST) Received: from murkwood.gaffaneys.com (dialup4.gaffaneys.com [134.129.252.23]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id VAA08678 for ; Wed, 12 Feb 1997 21:05:10 -0800 (PST) Received: (from zach@localhost) by murkwood.gaffaneys.com (8.8.5/8.8.5) id WAA10038; Wed, 12 Feb 1997 22:59:52 -0600 (CST) To: wong@rogerswave.ca Cc: hackers@freebsd.org Subject: Re: strlen() question, maybe str*cpy References: Mime-Version: 1.0 (generated by tm-edit 7.89) Content-Type: text/plain; charset=US-ASCII From: Zach Heilig Date: 12 Feb 1997 22:59:51 -0600 In-Reply-To: Ken Wong's message of Wed, 12 Feb 1997 23:11:01 -0500 (EST) Message-ID: <87iv3xl2rc.fsf@murkwood.gaffaneys.com> Lines: 13 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ken Wong writes: > why isn't the str*cpy check the BP (base pointer?) register > and use it to gaurd against stack over right? Are you certain that all strings are allocated on the stack? I'm pretty sure there are some in the bss and others that are malloc()'d as well... -- Zach Heilig (zach@blizzard.gaffaneys.com) | ALL unsolicited commercial email Support bacteria -- it's the only | is unwelcome. I avoid dealing form of culture some people have! | with companies that email ads. From owner-freebsd-hackers Wed Feb 12 23:33:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA24003 for hackers-outgoing; Wed, 12 Feb 1997 23:33:49 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA23997 for ; Wed, 12 Feb 1997 23:33:45 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id SAA18797 for hackers@freebsd.org; Thu, 13 Feb 1997 18:03:43 +1030 (CST) From: Michael Smith Message-Id: <199702130733.SAA18797@genesis.atrad.adelaide.edu.au> Subject: Big disks To: hackers@freebsd.org Date: Thu, 13 Feb 1997 18:03:42 +1030 (CST) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ... just to follow on my previous posting; having killed myself in the transfinite loop of trying to get DOS onto the disk so that I could install the Jaz software to unlock the &*$&^$&6 Jaz disk and so forth, I put the machine aside and moved to its twin. And lo and behold it works perfectly, as expected. So the former has either a screwed IDE cable, disk or motherboard, and FreeBSD works flawlessly (modulo the size calculation bug) with the Maxtor 5GB disk. Just FYI. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Thu Feb 13 00:11:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA25560 for hackers-outgoing; Thu, 13 Feb 1997 00:11:26 -0800 (PST) Received: from zapata.omniset.com (codix1.codix.fr [194.98.13.101]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA25554 for ; Thu, 13 Feb 1997 00:11:19 -0800 (PST) Received: from localhost (hackers@localhost) by zapata.omniset.com (8.6.12/8.6.9) with SMTP id JAA05854 for ; Thu, 13 Feb 1997 09:12:21 +0100 Date: Thu, 13 Feb 1997 09:12:20 +0100 (MET) From: "hackers@omnix.fr.org" To: hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk unsubscribe freebsd-hackers From owner-freebsd-hackers Thu Feb 13 00:40:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA27056 for hackers-outgoing; Thu, 13 Feb 1997 00:40:20 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA27049 for ; Thu, 13 Feb 1997 00:40:13 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.5/8.7.3) id JAA27792; Thu, 13 Feb 1997 09:41:53 +0100 (MET) From: Søren Schmidt Message-Id: <199702130841.JAA27792@ravenock.cybercity.dk> Subject: Re: _big_ IDE disks? In-Reply-To: <199702130320.NAA17080@genesis.atrad.adelaide.edu.au> from Michael Smith at "Feb 13, 97 01:50:31 pm" To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Thu, 13 Feb 1997 09:41:43 +0100 (MET) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply to Michael Smith who wrote: > Some more information : > > Michael Smith stands accused of saying: > > These are the 5GB Maxtor 'DiamondMax' disks we're talking about here, > > talking to a Tekram P5H30WS motherboard (current Award BIOS). > > > > The problem set looks something like this : > > > > - during probe, the disk is reported thus : > > > > a8tor 85120 A8 ->: < > > This apears to be about right; DM (Maxtor's "MaxBlast" software) reports the > same ID. Weird. Anyone have any contacts at Maxtor I should be bugging > about this? Try maxtor directly, they have provided me with some info in the past (allthough that was long ago) > > wd0: 633MB (9685824 sectors), 9224 cylinders, 16 heads, 61 S/T, 512 B/S > > The '633MB' is due to bad arithmetic in wd.c, where an intermediate is > set to the number of bytes on the disk : > > du->dk_dd.d_secperunit > * du->dk_dd.d_secsize / (1024 * 1024), > > I propose to change this to : > > (long)((long long)du->dk_dd.d_secperunit > * du->dk_dd.d_secsize / (1024 * 1024)), > > in order to force the intermediate values to 'long long'. An alternative > would be to use the approach that sd.c does : > > dp->disksize / ((1024L * 1024L) / dp->secsiz) > > which loses some precision but avoids playing type games. Comments? I'm easy on this one, the sd.c approach looks a bit prettier though... > > - While installing, the installer seems to write the partition table OK, > > but can't write the label or swap on the disk. > > This appears to be because I can't make a single partition bigger than 4GB. > I'll try installing to the Jaz in this box so that I can get it onto our > network. Soren, if you're playing ATA god, I'd really appreciate any > input you may have here. Hmm, this is exactly one of the drives I'm planning to buy for my ATA project (which I think I told you right?), just a wee bit short of cash yet, but if this is important enough, I'll try find a solution to that. We are likely to have to change a fair bit of arithmetic here and there it seems, to have this working for wd/ata/ide devices :( -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Thu Feb 13 01:03:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA28448 for hackers-outgoing; Thu, 13 Feb 1997 01:03:10 -0800 (PST) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA28443 for ; Thu, 13 Feb 1997 01:03:06 -0800 (PST) Received: from terminator.informatik.ba-stuttgart.de by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0vux4F-0008xeC; Thu, 13 Feb 97 01:02 PST Received: from helbig.informatik.ba-stuttgart.de (helbig.informatik.ba-stuttgart.de [141.31.166.22]) by terminator.informatik.ba-stuttgart.de (8.7.6/8.7.3) with ESMTP id IAA22775 for ; Thu, 13 Feb 1997 08:15:25 +0100 Received: (from helbig@localhost) by helbig.informatik.ba-stuttgart.de (8.8.5/8.8.5) id JAA00203 for hackers@freebsd.org; Thu, 13 Feb 1997 09:15:55 +0100 (MET) From: Wolfgang Helbig Message-Id: <199702130815.JAA00203@helbig.informatik.ba-stuttgart.de> Subject: Re: CMD640b workaround - final(?) version To: hackers@freebsd.org Date: Thu, 13 Feb 1997 09:15:54 +0100 (MET) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ----- Forwarded message from helbig ----- >From helbig Thu Feb 13 09:11:58 1997 Subject: Re: CMD640b workaround - final(?) version In-Reply-To: <19970213004131.DV50639@x14.mi.uni-koeln.de> from Stefan Esser at "Feb 13, 97 00:41:31 am" To: se@freebsd.org (Stefan Esser) Date: Thu, 13 Feb 1997 09:11:58 +0100 (MET) X-Mailer: ELM [version 2.4ME+ PL30 (25)] Content-Length: 1259 Stefan Esser wrote > > > > BTW: I do heavily dislike the way you introduced the PCI > > > ID of the CMD640 into pci.c, and will not accept it! > > > > > > There is NO device specific code in pci.c for a reason! > > > > BTW: My solution is simpler. For a reason! > > I do heavily dislike complicated code if there is a simpler way! > > Well, and believe in layering, to make it easy to deal with > complex situations. (The world happens to be complex at times.) > > For that reason, there will not be a test for a particular > PCI device ID in the device independent PCI code. > > > Do whatever you want with it, I will accept it! > > Well, I don't have any way to test the WD driver, since I > do not own any (E)IDE drives. It is trivial to add a clean > CMD640 probe/attach, and it will add only a few instructions > over the code you suggested. Ok, I will try to understand the way you want the change to be made and then try to implement it. In the meantime I do hope someone will test my "final" version. What still needs to be tested is the case where you have pci and IDE devices on both channels and *no* CMD640b chip, with and w/o the options "CMD640" - line in the kernel configuration file. Preferably in the GENERIC kernel. Thanx!! ----- End of forwarded message from helbig ----- From owner-freebsd-hackers Thu Feb 13 01:26:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA29895 for hackers-outgoing; Thu, 13 Feb 1997 01:26:04 -0800 (PST) Received: from werple.net.au (melb.werple.net.au [203.9.190.18]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA29808 for ; Thu, 13 Feb 1997 01:24:37 -0800 (PST) Received: (qmail 12277 invoked by uid 5); 13 Feb 1997 09:24:33 -0000 MBOX-Line: From jb@freebsd1.cimlogic.com.au Thu Feb 13 19:25:42 1997 Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.7.5/8.7.3) id TAA00414; Thu, 13 Feb 1997 19:25:42 +1100 (EST) From: John Birrell Message-Id: <199702130825.TAA00414@freebsd1.cimlogic.com.au> Subject: Re: MIME applications for FreeBSD To: jehamby@lightside.com (Jake Hamby) Date: Thu, 13 Feb 1997 19:25:41 +1100 (EST) Cc: jb@cimlogic.com.au, terry@lambert.org, hackers@freebsd.org In-Reply-To: <199702130450.UAA01601@lightside.com> from Jake Hamby at "Feb 12, 97 08:50:59 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jake Hamby wrote: > Another comment on this dangerously off-topic thread: There is now > commercial gateway software designed specifically to look at MIME > attachments and convert them into a format friendly to the recipient. They > even go so far as to add an appropriate resource fork if the recipient is a > Mac user, or add the 3-character extension if the recipient is a PC user. > Wonder what happens if the recipient's using UNIX? :) Try sending a uuencoded _binary_ (for SysV... oops, I mean FreeBSD ;-) to a MS mail user. Last time I did that, msmail uudecoded it automatically and replaced all chars with (or something like that). The client complained that the program was core dumping. Duh. I tried to explain that it was Microsoft's attempt at auto-virus generation for UNIX, but the client didn't believe me 8-). > > -- Jake > Regards, -- John Birrell - jb@cimlogic.com.au; jb@netbsd.org CIMlogic Pty Ltd, 119 Cecil Street, South Melbourne Vic 3205, Australia Tel +61 3 9690 6900 Fax +61 3 9690 6650 Mob +61 418 353 137 From owner-freebsd-hackers Thu Feb 13 01:26:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA29901 for hackers-outgoing; Thu, 13 Feb 1997 01:26:05 -0800 (PST) Received: from werple.net.au (melb.werple.net.au [203.9.190.18]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA29810 for ; Thu, 13 Feb 1997 01:24:38 -0800 (PST) Received: (qmail 12282 invoked by uid 5); 13 Feb 1997 09:24:34 -0000 MBOX-Line: From jb@freebsd1.cimlogic.com.au Thu Feb 13 19:39:00 1997 Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.7.5/8.7.3) id TAA00435; Thu, 13 Feb 1997 19:39:00 +1100 (EST) From: John Birrell Message-Id: <199702130839.TAA00435@freebsd1.cimlogic.com.au> Subject: Re: MIME applications for FreeBSD To: terry@lambert.org (Terry Lambert) Date: Thu, 13 Feb 1997 19:38:59 +1100 (EST) Cc: hackers@freebsd.org In-Reply-To: <199702121715.KAA00715@phaeton.artisoft.com> from Terry Lambert at "Feb 12, 97 10:15:47 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > 1) Boundry identification > 2) Multile logical message bodies seperated by boundry identifiers > 3) Content transfer encoding for binary data > > As to what binary data is permitted to be encoded: > > 1) Any binary data the sender and the recipient can agree upon > > > Though I'd be perfectly happy to see this limited to binary data for > which public source reference implementations exist (ie: no more Word > documents unless Microsoft publically documents Word file format, no > PDF documents unless Adobe documents their "encryption" preventing > the use of non-Adobe readers, but not preventing any Adobe reader from > decoding the document, etc., etc.). But what do we do if "MIME application/msword" takes over 90 percent of email traffic (like msword has done with wp)? Imagine what this list would be like... Ugh. We are prevented from reverse engineering by the licence for msword (I guess, since other MS products have that clause). MS is unlikely to publicly document Word file format. Hmmm, seems we need a killer application (that is also available for windows) that will get everyone to jump away from msword. The sort of publicity that JAVA gets might do the trick.... now what would make that application really special? > Regards, > Terry Lambert > Regards, -- John Birrell - jb@cimlogic.com.au; jb@netbsd.org CIMlogic Pty Ltd, 119 Cecil Street, South Melbourne Vic 3205, Australia Tel +61 3 9690 6900 Fax +61 3 9690 6650 Mob +61 418 353 137 From owner-freebsd-hackers Thu Feb 13 02:35:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA02561 for hackers-outgoing; Thu, 13 Feb 1997 02:35:51 -0800 (PST) Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA02556 for ; Thu, 13 Feb 1997 02:35:47 -0800 (PST) Received: (from joe@localhost) by florence.pavilion.net (8.8.5/8.8.5) id KAA16615; Thu, 13 Feb 1997 10:35:15 GMT Message-ID: Date: Thu, 13 Feb 1997 10:35:15 +0000 From: joe@pavilion.net (Josef Karthauser) To: hackers@freebsd.org Subject: additions to /etc/netstart X-Mailer: Mutt 0.58.1 Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary=WXdDmUznG2R74hYJ Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk --WXdDmUznG2R74hYJ Hiya, I've got a sugestion for an addition to /etc/netstart for handling ip aliases. Perhaps this isn't the best place to send it, but it's most likely to end up in the core if one f you guys likes it :) This is the addition: # Set up all the network interfaces, calling startup scripts if needed for ifn in ${network_interfaces}; do if [ -e /etc/start_if.${ifn} ]; then . /etc/start_if.${ifn} ${ifn} fi eval ifconfig_args=\$ifconfig_${ifn} ifconfig ${ifn} ${ifconfig_args} ifconfig ${ifn} # joe/pavilion/19961121: added alias code eval network_aliases=\$network_aliases_${ifn} echo network_aliases=$network_aliases for ifna in ${network_aliases}; do echo ifconfig ${ifn} inet alias ${ifna} netmask 255.255.255.255 ifconfig ${ifn} inet alias ${ifna} netmask 255.255.255.255 done done The following can then be added to /etc/sysconfig: ifconfig_de0="inet 194.242.128.25 -link2 netmask 255.255.255.192" ifconfig_lo0="inet localhost" # joe/pavilion/19961121: IP alias addresses for each interface # Multiple is allowed: network_aliases_XXX="194.193.24.2 194.193.24.4" # XXX is replaced by the interface name, eg de0 # # joe/pavilion/19970203: This machine is now the primary DNS. # network_aliases_de0="194.242.128.1" Whatcha think? Joe. -- Josef Karthauser Technical Manager Email: joe@pavilion.net Pavilion Internet plc. [Tel: +44 1273 607072 Fax: +44 1273 607073] --WXdDmUznG2R74hYJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia iQB1AwUBMwLuYg7sAx9+veyxAQFtsAL/Xeo7kDq3MFHO64pvlX2pHvvxylT7+vY7 9z+txXU8YS7JK05FRYUdRZPhUFN46X2U0ANYRDzY9kKacMvq5RvO7tM+wp19fwph K6S5CI8z9L/SeNHKMxOpz1wGpGkd1RSo =Y9tx -----END PGP SIGNATURE----- --WXdDmUznG2R74hYJ-- From owner-freebsd-hackers Thu Feb 13 03:37:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA04580 for hackers-outgoing; Thu, 13 Feb 1997 03:37:41 -0800 (PST) Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA04538 for ; Thu, 13 Feb 1997 03:36:18 -0800 (PST) Received: from gid.co.uk (uucp@localhost) by isbalham.ist.co.uk (8.8.4/8.8.4) with UUCP id LAA14582; Thu, 13 Feb 1997 11:30:50 GMT Date: Thu, 13 Feb 1997 11:32:49 GMT Received: from [194.32.164.2] by seagoon.gid.co.uk; Thu, 13 Feb 1997 11:32:49 GMT X-Sender: rb@194.32.164.1 Message-Id: In-Reply-To: <199702130839.TAA00435@freebsd1.cimlogic.com.au> References: <199702121715.KAA00715@phaeton.artisoft.com> from Terry Lambert at "Feb 12, 97 10:15:47 am" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: John Birrell From: Bob Bishop Subject: Re: MIME applications for FreeBSD Cc: hackers@FreeBSD.ORG, terry@lambert.org (Terry Lambert) Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 8:38 am -0000 13/2/97, John Birrell wrote: >[...] >We are prevented from reverse engineering by the licence for msword >(I guess, since other MS products have that clause). MS is unlikely >to publicly document Word file format. [etc] They certainly don't seem to. Maybe reverse engineering is unnecessary: WordPad groks Word 6 format, and the source is in among the samples on the MSVC4.2 CD. Also 3rd-party converters between Word6 and are available (and referenced in MS developer materials). Maybe the developers had to pay a fat licence fee. -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK From owner-freebsd-hackers Thu Feb 13 03:45:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA04874 for hackers-outgoing; Thu, 13 Feb 1997 03:45:33 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA04869 for ; Thu, 13 Feb 1997 03:45:27 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id WAA13961; Thu, 13 Feb 1997 22:51:06 +1100 (EST) Date: Thu, 13 Feb 1997 22:51:06 +1100 (EST) From: "Daniel O'Callaghan" To: Josef Karthauser cc: hackers@freebsd.org Subject: Re: additions to /etc/netstart In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 13 Feb 1997, Josef Karthauser wrote: > The following can then be added to /etc/sysconfig: > ifconfig_de0="inet 194.242.128.25 -link2 netmask 255.255.255.192" > ifconfig_lo0="inet localhost" > > # joe/pavilion/19961121: IP alias addresses for each interface > # Multiple is allowed: network_aliases_XXX="194.193.24.2 194.193.24.4" > # XXX is replaced by the interface name, eg de0 > # > # joe/pavilion/19970203: This machine is now the primary DNS. > # > network_aliases_de0="194.242.128.1" Well, it does not seem to cater for people like me who have an entire Class C network aliased onto lo0. I'm sure there are plenty of other ISPs running lots of VWS on a single machine. Even when I exhaust the current class C net, I won't be putting in a new machine for the next lot, I'll just have 508 aliases instead of 254. I certainly don't fancy a line network_aliases_lo0="{insert many lines of IP addresses here} " in /etc/sysconfig. How about a scheme whereby the aliases are read from /etc/ip.aliases.lo0 Danny From owner-freebsd-hackers Thu Feb 13 03:49:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA04988 for hackers-outgoing; Thu, 13 Feb 1997 03:49:50 -0800 (PST) Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA04978 for ; Thu, 13 Feb 1997 03:49:46 -0800 (PST) Received: (from joe@localhost) by florence.pavilion.net (8.8.5/8.8.5) id LAA19400; Thu, 13 Feb 1997 11:48:32 GMT Message-ID: Date: Thu, 13 Feb 1997 11:48:32 +0000 From: joe@pavilion.net (Josef Karthauser) To: danny@panda.hilink.com.au (Daniel O'Callaghan) Cc: joe@pavilion.net (Josef Karthauser), hackers@freebsd.org Subject: Re: additions to /etc/netstart References: X-Mailer: Mutt 0.58.1 Mime-Version: 1.0 In-Reply-To: ; from Daniel O'Callaghan on Feb 13, 1997 22:51:06 +1100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Daniel O'Callaghan writes: > > Well, it does not seem to cater for people like me who have an entire > Class C network aliased onto lo0. I'm sure there are plenty of other > ISPs running lots of VWS on a single machine. Even when I exhaust the > current class C net, I won't be putting in a new machine for the next > lot, I'll just have 508 aliases instead of 254. I certainly don't fancy > a line > network_aliases_lo0="{insert many lines of IP addresses here} " > > in /etc/sysconfig. > > How about a scheme whereby the aliases are read from /etc/ip.aliases.lo0 > That's a better idea. -- Josef Karthauser Technical Manager Email: joe@pavilion.net Pavilion Internet plc. [Tel: +44 1273 607072 Fax: +44 1273 607073] From owner-freebsd-hackers Thu Feb 13 04:30:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA07574 for hackers-outgoing; Thu, 13 Feb 1997 04:30:09 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA07553 for ; Thu, 13 Feb 1997 04:30:02 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id WAA19434; Thu, 13 Feb 1997 22:59:28 +1030 (CST) From: Michael Smith Message-Id: <199702131229.WAA19434@genesis.atrad.adelaide.edu.au> Subject: Re: _big_ IDE disks? In-Reply-To: <199702130841.JAA27792@ravenock.cybercity.dk> from =?ISO-8859-1?Q?S=F8ren_Schmidt?= at "Feb 13, 97 09:41:43 am" To: sos@ravenock.cybercity.dk (Søren Schmidt) Date: Thu, 13 Feb 1997 22:59:27 +1030 (CST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Søren Schmidt stands accused of saying: > (re: maxtor 5GB IDE) > Hmm, this is exactly one of the drives I'm planning to buy for my ATA > project (which I think I told you right?), just a wee bit short of cash > yet, but if this is important enough, I'll try find a solution to that. > We are likely to have to change a fair bit of arithmetic here and > there it seems, to have this working for wd/ata/ide devices :( Sorry for the false alarm, and perhaps more happiness; it looks like _no_ work other than the cosmetic during the probe is actually required. FWIW, when the disk is working, it looks like this : wdc0: unit 0 (wd0): wd0: 788MB (10003392 sectors), 9924 cyls, 16 heads, 63 S/T, 512 B/S (I forgot to turn on the 32bit/multi-block stuff on this one...) They actually seem to perform alright (though I'm not doing anything terribly heavy on it, and they're _very_ quiet. > Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Thu Feb 13 04:33:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA07843 for hackers-outgoing; Thu, 13 Feb 1997 04:33:29 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA07827 for ; Thu, 13 Feb 1997 04:33:23 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.5/8.7.3) id NAA28350; Thu, 13 Feb 1997 13:35:06 +0100 (MET) From: Søren Schmidt Message-Id: <199702131235.NAA28350@ravenock.cybercity.dk> Subject: Re: _big_ IDE disks? In-Reply-To: <199702131229.WAA19434@genesis.atrad.adelaide.edu.au> from Michael Smith at "Feb 13, 97 10:59:27 pm" To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Thu, 13 Feb 1997 13:35:06 +0100 (MET) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply to Michael Smith who wrote: > > FWIW, when the disk is working, it looks like this : > > wdc0: unit 0 (wd0): > wd0: 788MB (10003392 sectors), 9924 cyls, 16 heads, 63 S/T, 512 B/S > > (I forgot to turn on the 32bit/multi-block stuff on this one...) > > They actually seem to perform alright (though I'm not doing anything > terribly heavy on it, and they're _very_ quiet. Sounds good, especially the quiet bit, I plan to use one for a workstation, and I'm very picky about noise... You have an iozone result or some such, just for the fun of it ?? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Thu Feb 13 04:45:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA08366 for hackers-outgoing; Thu, 13 Feb 1997 04:45:17 -0800 (PST) Received: from barpm5-10.caribsurf.com ([205.214.193.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA08360 for ; Thu, 13 Feb 1997 04:45:10 -0800 (PST) Received: (from seanb012@localhost) by barpm5-10.caribsurf.com (8.7.5/8.7.3) id IAA00213 for freebsd-hackers@freebsd.org; Thu, 13 Feb 1997 08:45:54 -0400 (AST) Date: Thu, 13 Feb 1997 08:45:54 -0400 (AST) From: Sean Batson Message-Id: <199702131245.IAA00213@barpm5-10.caribsurf.com> To: freebsd-hackers@freebsd.org Subject: unsubscribe Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk From owner-freebsd-hackers Thu Feb 13 04:57:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA08942 for hackers-outgoing; Thu, 13 Feb 1997 04:57:59 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA08937 for ; Thu, 13 Feb 1997 04:57:55 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id XAA19503; Thu, 13 Feb 1997 23:27:44 +1030 (CST) From: Michael Smith Message-Id: <199702131257.XAA19503@genesis.atrad.adelaide.edu.au> Subject: Re: _big_ IDE disks? In-Reply-To: <199702131235.NAA28350@ravenock.cybercity.dk> from =?ISO-8859-1?Q?S=F8ren_Schmidt?= at "Feb 13, 97 01:35:06 pm" To: sos@ravenock.cybercity.dk (Søren Schmidt) Date: Thu, 13 Feb 1997 23:27:44 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Søren Schmidt stands accused of saying: > > > > They actually seem to perform alright (though I'm not doing anything > > terribly heavy on it, and they're _very_ quiet. > > Sounds good, especially the quiet bit, I plan to use one for a > workstation, and I'm very picky about noise... Well, I'll pull the power on the front blower in the chassis and check again, but my gut feeling is that they're quieter than the Hawk 2XLs that we used in our last batch. > You have an iozone result or some such, just for the fun of it ?? I'll run one up for you tomorrow, and send it to -hardware. > Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Thu Feb 13 06:13:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA12761 for hackers-outgoing; Thu, 13 Feb 1997 06:13:54 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA12754 for ; Thu, 13 Feb 1997 06:13:44 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id OAA22041; Thu, 13 Feb 1997 14:27:07 +0100 From: Luigi Rizzo Message-Id: <199702131327.OAA22041@labinfo.iet.unipi.it> Subject: Status of 21140AC driver ? To: hackers@freebsd.org Date: Thu, 13 Feb 1997 14:27:07 +0100 (MET) Cc: tim@futuresouth.com, jgreco@solaria.sol.net, thorpej@nas.nasa.gov X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, what is the status of the 21140-AC driver ? I have a lab of brand new diskless machines, running 2.1.6 -- The machines with the 21140-AB work fine with the stock 2.1.6 if_de.c , the ones with 21140-AC do not. I have remade a kernel with the if_de.c taken from netbsd; now the old cards seem not to work, and the new cards work fine up to the point where I try to access the nfs-mounted filesystem (as also Tim Tsai experienced. The machine is not completely dead though, it receives and responds properly to pings, arp requests etc. Maybe there is some mismatch with packet sizes (nfs might use maximum-sized packets) ? Also, a problem still remains in that I am unable to use the same driver for both the -AB and the -AC ... Help/comments appreciated Thanks Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Thu Feb 13 06:27:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA13354 for hackers-outgoing; Thu, 13 Feb 1997 06:27:44 -0800 (PST) Received: from llaic.univ-bpclermont.fr (llaic.univ-bpclermont.fr [192.54.142.163]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA13345 for ; Thu, 13 Feb 1997 06:27:39 -0800 (PST) Message-Id: <199702131427.GAA13345@freefall.freebsd.org> Received: by llaic.univ-bpclermont.fr (1.38.193.4/16.2) id AA04723; Thu, 13 Feb 1997 15:27:21 +0100 From: Roger Espel Llima Subject: Re: strlen() question, maybe str*cpy To: hackers@freefall.freebsd.org Date: Thu, 13 Feb 1997 15:27:21 +0100 (MET) In-Reply-To: <199702130437.UAA17244@freefall.freebsd.org> from "owner-hackers-digest@freefall.freebsd.org" at Feb 12, 97 08:37:06 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ken Wong wrote: > On Wed, 12 Feb 1997, J Wunsch wrote: > > Why? The worst that would happen by touching off the end of your > > address space is a SIGSEGV. The problem with str*cpy() touching > > beyond the bounds of their arrays is that they can _modify_ the stack > > then, but that can't happen with strlen() since it doesn't modify > > anything. Agreement. > why isn't the str*cpy check the BP (base pointer?) register > and use it to gaurd against stack over right? Because it's not its job. str*cpy() assumes that the string fits in the buffer where it is being copied, and is defined to just copy it. This kind of checks belong in a special debugging version of libc, if anywhere at all. Production code shouldn't be slowed down by more run-time checks than the language requires. The right solution is to secure sensitive programs (either setuid, or run by root/bin/whatever with untrusted arguments or data) at the source level. Roger -- e-mail: roger.espel.llima@ens.fr WWW page & PGP key: http://www.eleves.ens.fr:8080/home/espel/index.html From owner-freebsd-hackers Thu Feb 13 06:47:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA14262 for hackers-outgoing; Thu, 13 Feb 1997 06:47:16 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA14196 for ; Thu, 13 Feb 1997 06:45:52 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id BAA19701; Fri, 14 Feb 1997 01:14:17 +1030 (CST) From: Michael Smith Message-Id: <199702131444.BAA19701@genesis.atrad.adelaide.edu.au> Subject: Re: MIME applications for FreeBSD In-Reply-To: from Bob Bishop at "Feb 13, 97 11:32:49 am" To: rb@gid.co.uk (Bob Bishop) Date: Fri, 14 Feb 1997 01:14:16 +1030 (CST) Cc: jb@cimlogic.com.au, hackers@FreeBSD.ORG, terry@lambert.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bob Bishop stands accused of saying: > > They certainly don't seem to. Maybe reverse engineering is unnecessary: > WordPad groks Word 6 format, and the source is in among the samples on the > MSVC4.2 CD. Hmm! Not that I'm too enamoured of WordPad, but is this source in anything like a distributable form? If someone with a Willows Twin/XPDK license were to cut a set of binaries, could they distributethem? > Also 3rd-party converters between Word6 and are available > (and referenced in MS developer materials). Maybe the developers had to pay > a fat licence fee. Applixware claims to support MSWord format, and appears to be on a runout special for US$189 (US$69 student price). http://www.linuxmall.com > Bob Bishop (0118) 977 4017 international code +44 118 -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Thu Feb 13 06:53:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA14932 for hackers-outgoing; Thu, 13 Feb 1997 06:53:47 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA14647 for ; Thu, 13 Feb 1997 06:51:01 -0800 (PST) Received: from whale.gu.kiev.ua (whale.gu.net [194.93.190.4]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id GAA09529 for ; Thu, 13 Feb 1997 06:24:30 -0800 (PST) Received: from trifork.gu.net (trifork.gu.net [194.93.190.194]) by whale.gu.kiev.ua (8.8.5/8.7.3) with SMTP id QAA38510; Thu, 13 Feb 1997 16:22:46 +0200 Date: Thu, 13 Feb 1997 18:22:02 +0200 (EET) From: Andrew Stesin Reply-To: stesin@gu.net To: Jake Hamby cc: jb@cimlogic.com.au, terry@lambert.org, hackers@FreeBSD.ORG Subject: Re: MIME applications for FreeBSD In-Reply-To: <199702130450.UAA01601@lightside.com> Message-ID: X-NCC-RegID: ua.gu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 12 Feb 1997, Jake Hamby wrote: > out. Hmm, now that I think of it, Netscape does automagically decode > UUencoded pictures from USENET (hmm, wonder what Netscape programmer was ...but it can't handle UUENCODEs splitted into several messages. No big harm, though. > (Solaris/x86), it looks like that won't be a problem with my personal > mailbox either, but of course, if somebody sent me a Word document in my > private mailbox, I'd probably delete it as a matter of principle... :). Bad news. Monstersoft office'97 uses different internal format and your old msword-4-winflows on top of WABI won't always recognize them. Best regards, Andrew Stesin nic-hdl: ST73-RIPE From owner-freebsd-hackers Thu Feb 13 07:21:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA17067 for hackers-outgoing; Thu, 13 Feb 1997 07:21:18 -0800 (PST) Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA16894 for ; Thu, 13 Feb 1997 07:18:34 -0800 (PST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id PAA21404 for ; Thu, 13 Feb 1997 15:16:48 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Thu, 13 Feb 1997 15:17:28 +0000 Received: from tees.elsevier.co.uk (tees.elsevier.co.uk [193.131.197.60]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id PAA25999; Thu, 13 Feb 1997 15:15:55 GMT Received: (from dpr@localhost) by tees.elsevier.co.uk (8.8.3/8.8.3) id PAA05479; Thu, 13 Feb 1997 15:14:14 GMT To: jehamby@lightside.com (Jake Hamby) Cc: jb@cimlogic.com.au, terry@lambert.org, hackers@freebsd.org Subject: Re: MIME applications for FreeBSD References: <199702130450.UAA01601@lightside.com> From: Paul Richards Date: 13 Feb 1997 15:14:12 +0000 In-Reply-To: jehamby@lightside.com's message of Wed, 12 Feb 1997 20:50:59 -0800 Message-ID: <5720akybzv.fsf@tees.elsevier.co.uk> Lines: 19 X-Mailer: Gnus v5.3/Emacs 19.30 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk jehamby@lightside.com (Jake Hamby) writes: > Absolutely! Although figuring out the lowest common denomintor for, e.g. > rich text, often leads to all sorts of oddities. For example, I just > received a price quote for a Micron PC by E-Mail, in of all things, > UUENCODED RTF format! As I happily uudecoded it, and imported it into > WordPerfect 6.0 for UNIX on my SPARCstation, I couldn't help but wonder All my mail in work that comes from Groupwise accounts i.e. most of it, arrives as uuencoded wp files. I think Groupwise does the uuencoding at some point, possibly at the smtp gateway although it may do it for all mail and transparently uudecodes it upon receipt. I stay away from the internal mechanics of groupwise whenever possible :-) -- Dr Paul Richards. Originative Solutions Ltd. (Netcraft Ltd. contractor) Elsevier Science TIS online journal project. Email: p.richards@elsevier.co.uk Phone: 0370 462071 (Mobile), +44 (0)1865 843155 From owner-freebsd-hackers Thu Feb 13 08:30:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA21897 for hackers-outgoing; Thu, 13 Feb 1997 08:30:01 -0800 (PST) Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA21858 for ; Thu, 13 Feb 1997 08:29:59 -0800 (PST) Received: from aduxb.fnal.gov ("port 35372"@aduxb.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IFD4BQSQEM001PIT@FNAL.FNAL.GOV> for hackers@freefall.freebsd.org; Thu, 13 Feb 1997 10:29:57 -0600 Received: from localhost by aduxb.fnal.gov (5.x/SMI-SVR4) id AA11729; Thu, 13 Feb 1997 10:29:59 -0600 Date: Thu, 13 Feb 1997 10:29:58 -0600 (CST) From: Richard Neswold Subject: Re: strlen() question, maybe str*cpy In-reply-to: <199702130437.UAA17244@freefall.freebsd.org> To: hackers@freefall.freebsd.org Reply-to: neswold@FNAL.GOV Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > From: Ken Wong > > On Wed, 12 Feb 1997, J Wunsch wrote: > > Why? The worst that would happen by touching off the end of your > > address space is a SIGSEGV. The problem with str*cpy() touching > > beyond the bounds of their arrays is that they can _modify_ the stack > > then, but that can't happen with strlen() since it doesn't modify > > anything. > > why isn't the str*cpy check the BP (base pointer?) register > and use it to gaurd against stack over right? Because it slows down the routine. Because it would make it i386-specific (which would be a hassle for people planning on porting FreeBSD to other platforms.) Because it doesn't protect against all types of range errors, like void func(char const *str) { static char buf[100]; strcpy(buf, str); } In the above example, the copying might not reach the BP register but still could overrun the static buffer and destroy other variables. Rich ======================================================================== Richard Neswold, Accelerator Div./Controls Dept | neswold@fnal.gov Fermilab, PO Box 500, MS 347, Batavia, IL 60510 | voice (630) 840-3454 'finger neswold@aduxb.fnal.gov' for PGP key | fax (630) 840-3093 From owner-freebsd-hackers Thu Feb 13 09:15:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA24290 for hackers-outgoing; Thu, 13 Feb 1997 09:15:05 -0800 (PST) Received: from george.lbl.gov (george.lbl.gov [128.3.196.93]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA24283 for ; Thu, 13 Feb 1997 09:15:02 -0800 (PST) Received: (jin@localhost) by george.lbl.gov (8.6.10/8.6.5) id JAA02955 for hackers@freebsd.org; Thu, 13 Feb 1997 09:11:51 -0800 Date: Thu, 13 Feb 1997 09:11:51 -0800 From: "Jin Guojun[ITG]" Message-Id: <199702131711.JAA02955@george.lbl.gov> To: hackers@freebsd.org Subject: LKM for bpf Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A few separated questions for LKM and bpf. Situations: bpf has been updated to add tcp_wrapper into the kernel in LBL. (1) who is currently import the bpf into the FreeBSD and doing maintenance? Would this person will updated this new bpf feature in FreeBSD? If yes, what is the approximate time frame? (2) regardless Q (1), we are trying to make a loadable kernel module for bpf. There are some technical issues -- <1> At which booting phase, the LKM can be started. That is, can LKM start in the middle of the booting process? or will LKM be started at the end of the booting process? <2> If the answer it that LKM has to be stared at the end of the booting process, then, can LKM replace an existing kernel function? Thanks in advance for providing any information on helping this, /-------------- Jin Guojun ------------ v -- Internet: j_guojun@lbl.gov ---\ | Imaging & Distributed Computing | Usenet: ucbvax!j_guojun@lbl.gov | | Lawrence Berkeley Laboratory | Bitnet: -- | | 50B-2239, Berkeley, CA 94720 - jin%george.lbl.gov@Csa3.LBL.Gov | \--Ph#:(510) 486-7531 + Fax: 486-6363 --^--http://www-itg.lbl.gov/ITG.html-/ From owner-freebsd-hackers Thu Feb 13 09:15:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA24317 for hackers-outgoing; Thu, 13 Feb 1997 09:15:37 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA24210 for ; Thu, 13 Feb 1997 09:14:13 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA02061 for hackers@freebsd.org; Thu, 13 Feb 1997 10:08:27 -0700 From: Terry Lambert Message-Id: <199702131708.KAA02061@phaeton.artisoft.com> Subject: List problems? To: hackers@freebsd.org Date: Thu, 13 Feb 1997 10:08:27 -0700 (MST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Are there list problems? I am only getting hackers list mail which has been cc'ed to me. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Feb 13 09:17:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA24433 for hackers-outgoing; Thu, 13 Feb 1997 09:17:09 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA24324 for ; Thu, 13 Feb 1997 09:15:43 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA02021; Thu, 13 Feb 1997 10:04:41 -0700 From: Terry Lambert Message-Id: <199702131704.KAA02021@phaeton.artisoft.com> Subject: Re: strlen() question To: asami@vader.cs.berkeley.edu (Satoshi Asami) Date: Thu, 13 Feb 1997 10:04:40 -0700 (MST) Cc: terry@lambert.org, danny@panda.hilink.com.au, hackers@freebsd.org In-Reply-To: <199702130222.SAA16536@vader.cs.berkeley.edu> from "Satoshi Asami" at Feb 12, 97 06:22:43 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > * Heh. You and Sean. "NULL" is an untyped 0. Actually, it's a 0 > * terminated string. > > man 9 style % man 9 style No entry for style in section 9 of the manual Just for good measure, I tried: % man 9 political_correctness No entry for political_correctness in section 9 of the manual Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Feb 13 09:43:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA26028 for hackers-outgoing; Thu, 13 Feb 1997 09:43:56 -0800 (PST) Received: from lightside.com (hamby1.lightside.net [207.67.176.17]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA26023 for ; Thu, 13 Feb 1997 09:43:52 -0800 (PST) Received: by lightside.com (SMI-8.6/SMI-SVR4) id JAA11744; Thu, 13 Feb 1997 09:44:27 -0800 Date: Thu, 13 Feb 1997 09:44:27 -0800 From: jehamby@lightside.com (Jake Hamby) Message-Id: <199702131744.JAA11744@lightside.com> To: hackers@freebsd.org Subject: Speaking of Insure++ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: r7y6AQKjQ2s03m9AJ5eEYQ== Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk While investigating development tools for a Windows programming project at work, I came across this comparison of BoundsChecker Pro (which uses the same technology as Insure++), HeapAgent, and Purify NT. It was written by the authors of HeapAgent, so it is a little biased, but it does present a fair comparison of what each product is good for (their conclusion was that Purify or BoundsChecker are the best tools for final testing, but they slow down the program far too much to be used during the development phase, a conclusion I tend to agree with from my experience). Anyway, since there was mention of asking ParaSoft to port Insure++ to FreeBSD, this should be interesting reading if you want to know its strengths and weaknesses compared to Purify or HeapAgent. http://www.microquill.com/prod_ha/ha_comp.htm -- Jake From owner-freebsd-hackers Thu Feb 13 09:47:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA26273 for hackers-outgoing; Thu, 13 Feb 1997 09:47:59 -0800 (PST) Received: from lightside.com (hamby1.lightside.net [207.67.176.17]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA26212 for ; Thu, 13 Feb 1997 09:46:32 -0800 (PST) Received: by lightside.com (SMI-8.6/SMI-SVR4) id JAA11713; Thu, 13 Feb 1997 09:36:12 -0800 Date: Thu, 13 Feb 1997 09:36:12 -0800 From: jehamby@lightside.com (Jake Hamby) Message-Id: <199702131736.JAA11713@lightside.com> To: rb@gid.co.uk, msmith@atrad.adelaide.edu.au Subject: Re: MIME applications for FreeBSD Cc: jb@cimlogic.com.au, hackers@FreeBSD.ORG, terry@lambert.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: gyOrnT5uEiDT/3SH0+LN/Q== Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Michael Smith says: > Bob Bishop stands accused of saying: > > > > They certainly don't seem to. Maybe reverse engineering is unnecessary: > > WordPad groks Word 6 format, and the source is in among the samples on the > > MSVC4.2 CD. > > Hmm! Not that I'm too enamoured of WordPad, but is this source in anything > like a distributable form? If someone with a Willows Twin/XPDK license > were to cut a set of binaries, could they distributethem? Probably not. I believe Microsoft sample source is licensed under the condition that you must add "substantial value" to it before you can distribute it as your own. In other words, they probably wouldn't mind if you used the guts of WordPad as some other program, but if they found out you were redistributing a recompiled copy of WordPad itself, they could probably sue. BTW, Microsoft has freely distributable Word Viewer and Powerpoint Viewer binaries whose sole purpose is to view those types of documents. I'm sure they run under WABI, and probably WINE too. I would hope that MS updates these to recognize the Office 97 formats, and still supports the 16-bit versions (at least until WINE and WABI can run Win32 apps reliably). Of course if somebody sends you a fill-out form as an office document, you're still screwed. And if you can get WordPad going, you'll probably be screwed on complex documents (esp. those with embedded OLE). > > Also 3rd-party converters between Word6 and are available > > (and referenced in MS developer materials). Maybe the developers had to pay > > a fat licence fee. > > Applixware claims to support MSWord format, and appears to be on a > runout special for US$189 (US$69 student > price). http://www.linuxmall.com Perhaps they had to pay a fee, perhaps they simply reverse engineered it? My copy of WordPerfect 6 for UNIX does a _lousy_ job of importing Word 6 documents (it won't even recognize most of them), and that's only because I downloaded a newer converter from their FTP site (the original one didn't even try!). Hmm, I'd forgotten about Applixware, or for that matter StarOffice, which had a free beta version of their office suite available from SunSite the last I checked. StarOffice also makes Windows, OS/2 (and soon PowerMac and Solaris) versions, I believe. Their Web site is: http://www.stardiv.de/ but it's completely in German! -- Jake From owner-freebsd-hackers Thu Feb 13 10:53:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA00847 for hackers-outgoing; Thu, 13 Feb 1997 10:53:57 -0800 (PST) Received: from mail.futuresouth.com (mail.futuresouth.com [207.141.254.21]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA00842 for ; Thu, 13 Feb 1997 10:53:54 -0800 (PST) Received: from shell.futuresouth.com (shell.futuresouth.com [207.141.254.20]) by mail.futuresouth.com (8.8.5/8.8.5) with ESMTP id MAA17657; Thu, 13 Feb 1997 12:53:19 -0600 (CST) From: Tim Tsai Received: (from tim@localhost) by shell.futuresouth.com (8.8.3/8.8.3) id MAA23776; Thu, 13 Feb 1997 12:53:18 -0600 (CST) Message-Id: <199702131853.MAA23776@shell.futuresouth.com> Subject: Re: Status of 21140AC driver ? To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Thu, 13 Feb 1997 12:53:18 -0600 (CST) Cc: hackers@freebsd.org In-Reply-To: <199702131327.OAA22041@labinfo.iet.unipi.it> from Luigi Rizzo at "Feb 13, 97 02:27:07 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > what is the status of the 21140-AC driver ? I have a lab of brand > new diskless machines, running 2.1.6 -- The machines with the > 21140-AB work fine with the stock 2.1.6 if_de.c , the ones with > 21140-AC do not. I have remade a kernel with the if_de.c taken from > netbsd; now the old cards seem not to work, and the new cards work fine > up to the point where I try to access the nfs-mounted filesystem (as > also Tim Tsai experienced. I've tried limiting the r/w size to 1024 as suggsted by the handbook and that seems to have solved the locked up problem but performance was terrible so I went back to the ISA NE2000 cards. Tim From owner-freebsd-hackers Thu Feb 13 10:59:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA00989 for hackers-outgoing; Thu, 13 Feb 1997 10:59:13 -0800 (PST) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA00962 for ; Thu, 13 Feb 1997 10:59:03 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com) by mail.crl.com with SMTP id AA11114 (5.65c/IDA-1.5 for ); Thu, 13 Feb 1997 10:58:13 -0800 Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.8.3/8.6.9) with SMTP id NAA12268; Thu, 13 Feb 1997 13:58:20 -0500 (EST) Message-Id: <3.0.32.19970213135323.00c0aa90@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 13 Feb 1997 13:53:25 -0500 To: Luigi Rizzo , hackers@FreeBSD.ORG From: dennis Subject: Re: Status of 21140AC driver ? Cc: tim@futuresouth.com, jgreco@solaria.sol.net, thorpej@nas.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 02:27 PM 2/13/97 +0100, Luigi Rizzo wrote: >Hi, > >what is the status of the 21140-AC driver ? I have a lab of brand >new diskless machines, running 2.1.6 -- The machines with the >21140-AB work fine with the stock 2.1.6 if_de.c , the ones with >21140-AC do not. I have remade a kernel with the if_de.c taken from >netbsd; now the old cards seem not to work, and the new cards work fine >up to the point where I try to access the nfs-mounted filesystem (as >also Tim Tsai experienced. > >The machine is not completely dead though, it receives and responds >properly to pings, arp requests etc. Maybe there is some mismatch with >packet sizes (nfs might use maximum-sized packets) ? > >Also, a problem still remains in that I am unable to use the same >driver for both the -AB and the -AC ... > >Help/comments appreciated Yes...this is a big problem. Our supplier has started shipping the -AC chips, and they dont work. Dennis From owner-freebsd-hackers Thu Feb 13 11:07:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA01490 for hackers-outgoing; Thu, 13 Feb 1997 11:07:20 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA01484 for ; Thu, 13 Feb 1997 11:07:13 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id TAA22913; Thu, 13 Feb 1997 19:20:54 +0100 From: Luigi Rizzo Message-Id: <199702131820.TAA22913@labinfo.iet.unipi.it> Subject: Re: Status of 21140AC driver ? To: tim@futuresouth.com (Tim Tsai) Date: Thu, 13 Feb 1997 19:20:54 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <199702131853.MAA23776@shell.futuresouth.com> from "Tim Tsai" at Feb 13, 97 12:52:59 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > what is the status of the 21140-AC driver ? I have a lab of brand > > new diskless machines, running 2.1.6 -- The machines with the > > 21140-AB work fine with the stock 2.1.6 if_de.c , the ones with > > 21140-AC do not. I have remade a kernel with the if_de.c taken from > > netbsd; now the old cards seem not to work, and the new cards work fine > > up to the point where I try to access the nfs-mounted filesystem (as > > also Tim Tsai experienced. > > I've tried limiting the r/w size to 1024 as suggsted by the handbook was that a suggestion specific to the if_de driver or a general thing with low-performance boards (which the 21140-AC is not!) ? Anyways this make me suspect either some MTU mismatch (but that seems unlikely, since the relevant code in the two drivers looks the same) or some buffer-management problems in the new (netbsd-derived) driver. I cannot try this now, but if someone has a machine alive with a 21140-AC, can s/he try pinging the machine with large (~1500 bytes and more) packets and see when/if it stops responding, possibly using tcpdump and taking a note of the offending packet size ? That could give some insight to track down the bug. Thanks Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Thu Feb 13 11:11:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA01668 for hackers-outgoing; Thu, 13 Feb 1997 11:11:41 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA01467; Thu, 13 Feb 1997 11:06:32 -0800 (PST) Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.8.3/8.6.9) with SMTP id OAA12334; Thu, 13 Feb 1997 14:09:21 -0500 (EST) Message-Id: <3.0.32.19970213140425.00c16c70@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 13 Feb 1997 14:04:28 -0500 To: freebsd-isp@freebsd.org From: dennis Subject: ET users Lists Cc: hackers@freebsd.org, linuxisp@lightning.com, inet-access@earth.com, bsdi-users@bsdi.com, bsdi-isps@bsdi.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Our list is back online, but you have to re-subscribe. We dont run it, so we're not sure what happened. Sorry of the inconvenience. See http://www.etinc.com/etlist.htm for details. Dennis From owner-freebsd-hackers Thu Feb 13 11:38:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA02999 for hackers-outgoing; Thu, 13 Feb 1997 11:38:26 -0800 (PST) Received: from kalypso.iqm.unicamp.br (kalypso.iqm.unicamp.br [143.106.13.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA02976 for ; Thu, 13 Feb 1997 11:38:04 -0800 (PST) Received: (from vazquez@localhost) by kalypso.iqm.unicamp.br (8.8.5/8.7.3/FreeBSD/2.1.5) id RAA15101; Thu, 13 Feb 1997 17:35:05 -0300 (EST) From: Pedro A M Vazquez Message-Id: <199702132035.RAA15101@kalypso.iqm.unicamp.br> Subject: Re: Status of 21140AC driver ? To: tim@futuresouth.com (Tim Tsai) Date: Thu, 13 Feb 1997 17:35:05 -0300 (EST) Cc: luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG In-Reply-To: <199702131853.MAA23776@shell.futuresouth.com> from "Tim Tsai" at Feb 13, 97 12:53:18 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tim Tsai said: > > > what is the status of the 21140-AC driver ? I have a lab of brand > > new diskless machines, running 2.1.6 -- The machines with the > > 21140-AB work fine with the stock 2.1.6 if_de.c , the ones with > > 21140-AC do not. I have remade a kernel with the if_de.c taken from > > netbsd; now the old cards seem not to work, and the new cards work fine > > up to the point where I try to access the nfs-mounted filesystem (as > > also Tim Tsai experienced. > > I've tried limiting the r/w size to 1024 as suggsted by the handbook > and that seems to have solved the locked up problem but performance was > terrible so I went back to the ISA NE2000 cards. > Just to add a point to the curve: the Compex cards with -AC chips work fine at 10Mbps under 2.1.0 and 2.1.5 but don't work at 100Mbps. I've not tried these cards under 2.1.6 or later releases. Pedro From owner-freebsd-hackers Thu Feb 13 11:47:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA03669 for hackers-outgoing; Thu, 13 Feb 1997 11:47:25 -0800 (PST) Received: from aris (aris.jpl.nasa.gov [137.78.161.113]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA03658 for ; Thu, 13 Feb 1997 11:47:17 -0800 (PST) Received: from localhost by aris (SMI-8.6/SMI-SVR4) id LAA09645; Thu, 13 Feb 1997 11:46:52 -0800 Date: Thu, 13 Feb 1997 11:46:52 -0800 (PST) From: Jake Hamby X-Sender: hamby@aris To: hackers@freebsd.org Subject: Sun Workshop compiler vs. GCC? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just downloaded a 30-day trial of the newest version of Sun's C++ compiler (ProCompiler 4.2), which is supposed to offer much better optimization than previous versions. With the -fast option (which turns on full optimization, plus 486, Pentium, or PPro optimization as appropriate), it does seem to take about 3 times as long to compile anything as GCC (on my 486DX4/100), and so I would hope that the generated code is much better. Can anyone come up with a good realistic test program for me to compare Sun's compiler and GCC? In order to make this topic even marginally related to FreeBSD, I'd like to try comparing benchmarks between Solaris/x86 with Sun's compiler, Solaris with GCC, and FreeBSD with GCC. Also, if anyone has any libm-intensive benchmarks, it should be instructive to compare FreeBSD and Solaris's libm (since they both have a common ancestor, the SunPro libm), since people have complained about FreeBSD's libm (compared to Linux) in the past. Unfortunately, I only have a 486, and I expect the results would be quite different, and probably even more in Sun's favor, with a Pentium (unless one used pgcc?). I intend to build myself a Pentium soon, for various reasons it's now obvious that my 486 is a dead-end and buying another PowerPC system (I currently own a BeBox, which is now a collector's item since Be did a NeXT and moved to a software-only company!) becomes less politically viable (rumour has it that BeOS will be ported to Intel soon ;). But by the time I pay my taxes, and save up for my dream system, my Sun try-and-buy will be expired, so I wanted to do as much testing of it as I can now. In broader terms, it's good to see that Sun has put so much effort into creating a highly optimizing x86 compiler, because previous versions had very limited x86 optimizations. It's also interesting to see that various Pentium and PPro optimizations are supported, something we don't have in the core GCC. Of course Sun wants $995 for their compiler (or $3495 for the whole workshop, which includes an IDE, debugger, Motif GUI builder, etc.), so I'm only considering buying it because I'm expecting a massive educational discount. But my point is, if Sun (or anyone else) now offers a significantly better compiler than GCC (which is what I'm trying to prove or disprove), then it becomes *very* worthwhile (at least for scientific/computational applications of FreeBSD) to import the SVR4 emulation from NetBSD (after the Lite/2 shakeout finishes of course). Will the Lite/2 changes make it easier to import the SVR4 module from NetBSD, more difficult, or the same as before? One final observation: Isn't it scary that merely by recompiling their OS with the new compiler, the next version of Solaris/x86 (2.6) should be significantly faster than the previous version, making it an even bigger threat to the free UNIX's for commercial users, and ESPECIALLY the education market? While FreeBSD and Linux have an advantage by being relatively small (and free, obviously :), even a bloated SVR4 like Solaris can become "fast enough" just by throwing a lot of money into performance tuning. If they improve x86-specific support (adding Plug-and-Play, PCMCIA, power management, etc., as rumored), and Sun's advertising convinces corporate users that Solaris is superior for Internet and Java uses (which might even be true in Solaris 2.6, if their TCP/IP performance claims are true), and if you don't want to buy a Netra, maybe you'd buy Solaris/x86 (if you have lots of money). As for education, while a lot of students get all excited about Linux, if they discover that Solaris (about $200 educational) costs less than Linux + CDE + AcceleratedX + WABI, supports more Java tools, and ESPECIALLY if they are using Suns or Solaris at school, it can only gain in popularity. For that matter, SCO's going to release UnixWare for FREE in a few months (for non-commercial use), so that makes SVR4 support even more useful. In other words, and I'm sure Terry will agree :-), we need to cast our lot in with either Linux or SVR4, in order to have a big enough market to attract commercial apps. Considering what I've said above, AND Linux's continuing lack of a stable API for future growth without sacrificing backwards compatibility (e.g. GNU libc), I'd be inclined to say SVR4... ------------------------------------------------------------------------------ |Jake Hamby| APT Engineer at JPL, CS student at Cal Poly, and BeOS developer!| ------------------------------------------------------------------------------ "Life is hard..." From owner-freebsd-hackers Thu Feb 13 12:00:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA04534 for hackers-outgoing; Thu, 13 Feb 1997 12:00:55 -0800 (PST) Received: from werple.net.au (melb.werple.net.au [203.9.190.18]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA04382 for ; Thu, 13 Feb 1997 11:59:27 -0800 (PST) Received: (qmail 23150 invoked by uid 5); 13 Feb 1997 19:59:24 -0000 MBOX-Line: From jb@freebsd1.cimlogic.com.au Fri Feb 14 06:33:01 1997 Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.7.5/8.7.3) id GAA01212; Fri, 14 Feb 1997 06:33:01 +1100 (EST) From: John Birrell Message-Id: <199702131933.GAA01212@freebsd1.cimlogic.com.au> Subject: Re: MIME applications for FreeBSD To: rb@gid.co.uk (Bob Bishop) Date: Fri, 14 Feb 1997 06:33:00 +1100 (EST) Cc: jb@cimlogic.com.au, hackers@FreeBSD.ORG, terry@lambert.org In-Reply-To: from Bob Bishop at "Feb 13, 97 11:32:49 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bob Bishop wrote: > At 8:38 am -0000 13/2/97, John Birrell wrote: > >[...] > >We are prevented from reverse engineering by the licence for msword > >(I guess, since other MS products have that clause). MS is unlikely > >to publicly document Word file format. [etc] > > They certainly don't seem to. Maybe reverse engineering is unnecessary: > WordPad groks Word 6 format, and the source is in among the samples on the > MSVC4.2 CD. What are the licence restrictions on that source and things derived from it? > Bob Bishop (0118) 977 4017 international code +44 118 > rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK -- John Birrell - jb@cimlogic.com.au; jb@netbsd.org CIMlogic Pty Ltd, 119 Cecil Street, South Melbourne Vic 3205, Australia Tel +61 3 9690 6900 Fax +61 3 9690 6650 Mob +61 418 353 137 From owner-freebsd-hackers Thu Feb 13 12:07:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA04826 for hackers-outgoing; Thu, 13 Feb 1997 12:07:21 -0800 (PST) Received: from hemi.com (hemi.com [204.132.158.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA04769 for ; Thu, 13 Feb 1997 12:05:54 -0800 (PST) Received: (from mbarkah@localhost) by hemi.com (8.8.5/8.7.3) id NAA17798; Thu, 13 Feb 1997 13:04:10 -0700 (MST) From: Ade Barkah Message-Id: <199702132004.NAA17798@hemi.com> Subject: Re: strlen() question To: terry@lambert.org (Terry Lambert) Date: Thu, 13 Feb 1997 13:04:10 -0700 (MST) Cc: asami@vader.cs.berkeley.edu, terry@lambert.org, danny@panda.hilink.com.au, hackers@FreeBSD.ORG In-Reply-To: <199702131704.KAA02021@phaeton.artisoft.com> from Terry Lambert at "Feb 13, 97 10:04:40 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > > % man 9 style > No entry for style in section 9 of the manual Upgrade ? =-) Fortunately there have been numerous additions to section 9. | style(9) - Kernel source file style guide Regards, -Ade ------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - ------------------------------------------------------------------- From owner-freebsd-hackers Thu Feb 13 12:27:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA05798 for hackers-outgoing; Thu, 13 Feb 1997 12:27:33 -0800 (PST) Received: from bofh.cybercity.dk (relay.cybercity.dk [195.8.128.254]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA05791 for ; Thu, 13 Feb 1997 12:27:29 -0800 (PST) Received: from critter.dk.tfs.com (phk.cybercity.dk [195.8.133.247]) by bofh.cybercity.dk (8.8.3/8.7.3) with ESMTP id VAA02001 for ; Thu, 13 Feb 1997 21:30:06 +0100 (MET) Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.2/8.8.2) with ESMTP id VAA06540 for ; Thu, 13 Feb 1997 21:29:54 +0100 (MET) To: hackers@freebsd.org Subject: RFC2075 support Reply-to: phk@freebsd.org Date: Thu, 13 Feb 1997 21:29:54 +0100 Message-ID: <6538.855865794@critter.dk.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I would love to be able to say: ifconfig ed1 10.0.0.4 -rfc2075 Any takers ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-hackers Thu Feb 13 12:38:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA06515 for hackers-outgoing; Thu, 13 Feb 1997 12:38:21 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA06507 for ; Thu, 13 Feb 1997 12:38:18 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id MAA20610; Thu, 13 Feb 1997 12:38:10 -0800 (PST) To: joe@pavilion.net (Josef Karthauser) cc: hackers@freebsd.org Subject: Re: additions to /etc/netstart In-reply-to: Your message of "Thu, 13 Feb 1997 10:35:15 GMT." Date: Thu, 13 Feb 1997 12:38:09 -0800 Message-ID: <20606.855866289@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I've got a sugestion for an addition to /etc/netstart for handling > ip aliases. Perhaps this isn't the best place to send it, but it's > most likely to end up in the core if one f you guys likes it :) And how is this different than the additions which are already there? Please check with -current, folks. :-) Jordan From owner-freebsd-hackers Thu Feb 13 12:41:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA06749 for hackers-outgoing; Thu, 13 Feb 1997 12:41:32 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA06739 for ; Thu, 13 Feb 1997 12:41:29 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA00703; Thu, 13 Feb 1997 13:41:03 -0700 From: Terry Lambert Message-Id: <199702132041.NAA00703@phaeton.artisoft.com> Subject: Re: MIME applications for FreeBSD To: jb@cimlogic.com.au (John Birrell) Date: Thu, 13 Feb 1997 13:41:02 -0700 (MST) Cc: terry@lambert.org, hackers@FreeBSD.ORG In-Reply-To: <199702130839.TAA00435@freebsd1.cimlogic.com.au> from "John Birrell" at Feb 13, 97 07:38:59 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > But what do we do if "MIME application/msword" takes over 90 percent of > email traffic (like msword has done with wp)? Imagine what this > list would be like... Ugh. So make the list manager "MIME aware" so it decodes and reencodes mail coming through it, stripping attachments that it doesn't like. > We are prevented from reverse engineering by the licence for msword > (I guess, since other MS products have that clause). MS is unlikely > to publicly document Word file format. "We" is very broad here. Most Europeans, especially Germans, are not prevented from reverse engineering file formats or other interfaces. The US agreed to this when the US became a Berne signatory. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Feb 13 12:51:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA07257 for hackers-outgoing; Thu, 13 Feb 1997 12:51:31 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA07249 for ; Thu, 13 Feb 1997 12:51:21 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA08111 for hackers@FreeBSD.ORG; Thu, 13 Feb 1997 21:51:18 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id UAA05057; Thu, 13 Feb 1997 20:54:01 +0100 (MET) Message-ID: Date: Thu, 13 Feb 1997 20:54:01 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: strlen() question References: <199702130222.SAA16536@vader.cs.berkeley.edu> <199702131704.KAA02021@phaeton.artisoft.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702131704.KAA02021@phaeton.artisoft.com>; from Terry Lambert on Feb 13, 1997 10:04:40 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > % man 9 style > No entry for style in section 9 of the manual Read the section about ``How to stay -current with FreeBSD'' in the handbook, please. style(9) is actually the page that opened up section 9 in FreeBSD's manual. Right now, there are more than 50 entries there (including the linked ones). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Feb 13 12:57:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA07624 for hackers-outgoing; Thu, 13 Feb 1997 12:57:43 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA07618 for ; Thu, 13 Feb 1997 12:57:39 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA00955; Thu, 13 Feb 1997 13:55:16 -0700 From: Terry Lambert Message-Id: <199702132055.NAA00955@phaeton.artisoft.com> Subject: Re: strlen() question To: mbarkah@hemi.com (Ade Barkah) Date: Thu, 13 Feb 1997 13:55:16 -0700 (MST) Cc: terry@lambert.org, asami@vader.cs.berkeley.edu, danny@panda.hilink.com.au, hackers@FreeBSD.ORG In-Reply-To: <199702132004.NAA17798@hemi.com> from "Ade Barkah" at Feb 13, 97 01:04:10 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > % man 9 style > > No entry for style in section 9 of the manual > > Upgrade ? =-) Fortunately there have been numerous additions > to section 9. > > | style(9) - Kernel source file style guide See, there's the problem: libc is a user space library, not a kernel source file. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Feb 13 12:58:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA07713 for hackers-outgoing; Thu, 13 Feb 1997 12:58:17 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA07687 for ; Thu, 13 Feb 1997 12:58:09 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id NAA14808; Thu, 13 Feb 1997 13:55:50 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199702121719.KAA00730@phaeton.artisoft.com> Date: Thu, 13 Feb 1997 13:40:41 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: Terry Lambert Subject: Re: Raw I/O Question Cc: freebsd-hackers@freebsd.org, julian@whistle.com, (Bruce Evans) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Terry Lambert; On 12-Feb-97 you wrote: > > >it then calls the strategy routine for the device > > >which gets the kv region, > > >and extracts the phyical addresses again and > > >sets up the DMA > > >and then waits > > > > > >DMA is directly into the users pages.. > > > > Only for devices and device drivers that support and use DMA. > > And are not limited to 24 bit ISA I/O when the physical memory > target of the DMA is not above 16M. These will be bounced and > then copied to the users pages. Perfect. We will be using only the PCI version of the HBA's, and it does DMA on everything, command, status, data, etc. It supports Scatterr/Gather well in excess of what we understand FreeBSD to be able to utilize (up to 8192 segments per dma command, 32bit counters everywhere, bus mastering, etc. Not a problem. I cannot wait to see it work. Simon From owner-freebsd-hackers Thu Feb 13 13:06:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA08221 for hackers-outgoing; Thu, 13 Feb 1997 13:06:27 -0800 (PST) Received: from shadows.aeon.net (shadows.aeon.net [194.100.41.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA08180; Thu, 13 Feb 1997 13:05:15 -0800 (PST) Received: (from bsdcur@localhost) by shadows.aeon.net (8.8.5/8.8.3) id XAA07991; Thu, 13 Feb 1997 23:02:43 +0200 (EET) From: mika ruohotie Message-Id: <199702132102.XAA07991@shadows.aeon.net> Subject: undocumented kernel options... To: freebsd-current@freebsd.org Date: Thu, 13 Feb 1997 23:02:43 +0200 (EET) Cc: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk could anyone comment anything about those undocumented kernel options in the end of the LINT? which ones to use for which purpose... i mean, i dont expect to see full details, just about one line, or even only "if you use your machine on a fullmoon, set this on" just a basic idea what those are about, and lot of people would be slightly more happier... (i assume many would looove to know) thanx. mickey From owner-freebsd-hackers Thu Feb 13 13:21:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA09479 for hackers-outgoing; Thu, 13 Feb 1997 13:21:25 -0800 (PST) Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA09471 for ; Thu, 13 Feb 1997 13:21:21 -0800 (PST) Received: from gid.co.uk (uucp@localhost) by isbalham.ist.co.uk (8.8.4/8.8.4) with UUCP id VAA06885; Thu, 13 Feb 1997 21:15:50 GMT Date: Thu, 13 Feb 1997 21:09:12 GMT Received: from [194.32.164.2] by seagoon.gid.co.uk; Thu, 13 Feb 1997 21:09:12 GMT X-Sender: rb@194.32.164.1 Message-Id: In-Reply-To: <199702131933.GAA01212@freebsd1.cimlogic.com.au> References: from Bob Bishop at "Feb 13, 97 11:32:49 am" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: John Birrell From: Bob Bishop Subject: Re: MIME applications for FreeBSD Cc: hackers@FreeBSD.ORG, terry@lambert.org Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 7:32 pm -0000 13/2/97, John Birrell wrote: >Bob Bishop wrote: >> At 8:38 am -0000 13/2/97, John Birrell wrote: >> >[...] >> >We are prevented from reverse engineering by the licence for msword >> >(I guess, since other MS products have that clause). MS is unlikely >> >to publicly document Word file format. [etc] >> >> They certainly don't seem to. Maybe reverse engineering is unnecessary: >> WordPad groks Word 6 format, and the source is in among the samples on the >> MSVC4.2 CD. > >What are the licence restrictions on that source... Can't distribute > ...and things derived from it? Can redistribute objects derived from (possibly modified) sample code and MFC source. -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK From owner-freebsd-hackers Thu Feb 13 13:26:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA09844 for hackers-outgoing; Thu, 13 Feb 1997 13:26:38 -0800 (PST) Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA09834 for ; Thu, 13 Feb 1997 13:26:35 -0800 (PST) Received: (from asami@localhost) by vader.cs.berkeley.edu (8.8.4/8.7.3) id NAA18583; Thu, 13 Feb 1997 13:25:59 -0800 (PST) Date: Thu, 13 Feb 1997 13:25:59 -0800 (PST) Message-Id: <199702132125.NAA18583@vader.cs.berkeley.edu> To: hamby@aris.jpl.nasa.gov CC: hackers@FreeBSD.ORG In-reply-to: (message from Jake Hamby on Thu, 13 Feb 1997 11:46:52 -0800 (PST)) Subject: Re: Sun Workshop compiler vs. GCC? From: asami@vader.cs.berkeley.edu (Satoshi Asami) Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk * optimization than previous versions. With the -fast option (which turns * on full optimization, plus 486, Pentium, or PPro optimization as * appropriate), it does seem to take about 3 times as long to compile * anything as GCC (on my 486DX4/100), and so I would hope that the generated * code is much better. Well, I don't think so. Compiler optimizations are generally the best examples of "law of dimishing returns". ;) * Can anyone come up with a good realistic test program for me to compare * Sun's compiler and GCC? In order to make this topic even marginally Compile a little loop (daxpy?) and compare the assembly languge output. You'll be astonished how stupid compilers are. * One final observation: Isn't it scary that merely by recompiling their OS * with the new compiler, the next version of Solaris/x86 (2.6) should be * significantly faster than the previous version, making it an even bigger * threat to the free UNIX's for commercial users, and ESPECIALLY the * education market? While FreeBSD and Linux have an advantage by being I'm optimistic about this. My understanding is that the slowness and number of bugs of Solaris is intrinsic to its complexity of design (and also the fact that it was designed for workstations in mind, initially). You just can't make a huge mammoth run fast, no matter how much cash you sink into the compiler. Compiler optimization is no cure for bad design. Besides, Solaris x86 is such a festering piece of crap I can't believe anyone actually using it for "serious" work. I'm now having sooooo much fun trying to connect a bunch of disks to it (I need to yank and reinsert cables at the right moment during boot, can't have an IDE disk in the system if there is a SCSI disk with ID > 7, can't have three SCSI adapters active at the same time or the system will hang, etc.). FreeBSD beats Solaris hands down in every aspect (reliability, ease of configuration (/devices/pci@0,0/pci1011,1@f/pci9004,7278@4/cmdk@0,0:q,raw is not my idea of simplicity), performance). Satoshi From owner-freebsd-hackers Thu Feb 13 13:58:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA11825 for hackers-outgoing; Thu, 13 Feb 1997 13:58:12 -0800 (PST) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA11818 for ; Thu, 13 Feb 1997 13:58:07 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr3-18.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA27858 (5.67b/IDA-1.5 for ); Thu, 13 Feb 1997 22:57:51 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.5/8.6.9) id WAA15623; Thu, 13 Feb 1997 22:57:45 +0100 (CET) Message-Id: <19970213225745.YE06273@x14.mi.uni-koeln.de> Date: Thu, 13 Feb 1997 22:57:45 +0100 From: se@freebsd.org (Stefan Esser) To: terry@lambert.org (Terry Lambert) Cc: jb@cimlogic.com.au (John Birrell), hackers@freebsd.org Subject: Re: MIME applications for FreeBSD References: <199702130839.TAA00435@freebsd1.cimlogic.com.au> <199702132041.NAA00703@phaeton.artisoft.com> X-Mailer: Mutt 0.60-PL0 Mime-Version: 1.0 In-Reply-To: <199702132041.NAA00703@phaeton.artisoft.com>; from Terry Lambert on Feb 13, 1997 13:41:02 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Feb 13, terry@lambert.org (Terry Lambert) wrote: > "We" is very broad here. Most Europeans, especially Germans, are > not prevented from reverse engineering file formats or other > interfaces. This is not true, actually! There are strict restrictions, with only few exceptions. Looking at the machine code of program binaries is not allowed (and will be prosecuted) in general, for example. Interfaces may be reverse engineered ONLY for the purpose of adding value to a product, which you then may sell. But publishing the results (eg. in the form of source code that uses that interface) is prohibited. Regards, STefan From owner-freebsd-hackers Thu Feb 13 14:15:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA12927 for hackers-outgoing; Thu, 13 Feb 1997 14:15:40 -0800 (PST) Received: (from jmb@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA12899; Thu, 13 Feb 1997 14:15:18 -0800 (PST) From: "Jonathan M. Bresler" Message-Id: <199702132215.OAA12899@freefall.freebsd.org> Subject: Re: Sun Workshop compiler vs. GCC? To: asami@vader.cs.berkeley.edu (Satoshi Asami) Date: Thu, 13 Feb 1997 14:15:17 -0800 (PST) Cc: hamby@aris.jpl.nasa.gov, hackers@freebsd.org In-Reply-To: <199702132125.NAA18583@vader.cs.berkeley.edu> from "Satoshi Asami" at Feb 13, 97 01:25:59 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Satoshi Asami wrote: > > * optimization than previous versions. With the -fast option (which turns > * on full optimization, plus 486, Pentium, or PPro optimization as > * appropriate), it does seem to take about 3 times as long to compile > * anything as GCC (on my 486DX4/100), and so I would hope that the generated > * code is much better. > > Well, I don't think so. Compiler optimizations are generally the best > examples of "law of dimishing returns". ;) well, options make a huge difference on sun's compiler (SC4.0 18 Oct 1995 C 4.0) compare the numbers vs the options listed below 6009606.087651: -O5 -dalign -native -xautopar <== strange 6051658.950850: -xO5 -dalign -native 3290361.568528: -xO5 -dalign 3274313.272930: -xO5 jmb From owner-freebsd-hackers Thu Feb 13 14:17:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA13109 for hackers-outgoing; Thu, 13 Feb 1997 14:17:57 -0800 (PST) Received: from fog.xinside.com (fog.xinside.com [199.164.187.39]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA13104 for ; Thu, 13 Feb 1997 14:17:52 -0800 (PST) Received: (from smap@localhost) by fog.xinside.com (8.8.3/8.7.3) id PAA16428 for ; Thu, 13 Feb 1997 15:16:32 -0700 (MST) X-Authentication-Warning: fog.xinside.com: smap set sender to using -f Received: from chon.xinside.com(199.164.187.134) by fog.xinside.com via smap (V1.3) id sma016425; Thu Feb 13 15:16:29 1997 Received: (from patrick@localhost) by chon.xinside.com (8.7.5/8.6.12) id PAA02367; Thu, 13 Feb 1997 15:16:27 -0700 (MST) Date: Thu, 13 Feb 1997 15:16:27 -0700 (MST) Message-Id: <199702132216.PAA02367@chon.xinside.com> From: Patrick Giagnocavo To: hackers@freebsd.org Subject: Re: Sun Workshop compiler vs. GCC? In-Reply-To: <199702132125.NAA18583@vader.cs.berkeley.edu> References: <199702132125.NAA18583@vader.cs.berkeley.edu> Reply-To: patrick@xinside.com Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Satoshi Asami writes: > * One final observation: Isn't it scary that merely by recompiling their OS > * with the new compiler, the next version of Solaris/x86 (2.6) should be > * significantly faster than the previous version, making it an even bigger > * threat to the free UNIX's for commercial users, and ESPECIALLY the > * education market? While FreeBSD and Linux have an advantage by being > > I'm optimistic about this. My understanding is that the slowness and > number of bugs of Solaris is intrinsic to its complexity of design > (and also the fact that it was designed for workstations in mind, > initially). You just can't make a huge mammoth run fast, no matter > how much cash you sink into the compiler. Compiler optimization is no > cure for bad design. I tried to get Solaris x86 up on two different machines. No go. Can however install Linux FreeBSD etc. on these systems no problem. System A - it didn't properly detect my Adaptec 1542B. System B - couldn't install the boot blocks properly on an IDE (not EIDE) drive. Solaris won't capture the market, because they don't have a good installation program. Maybe this isn't a very technical problem, but it is a very real consideration when dealing with people who are just trying to get things to work... I'd plunk down the money for Solaris x86 if it would install easier - but it doesn't. cordially --Patrick From owner-freebsd-hackers Thu Feb 13 14:21:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA13332 for hackers-outgoing; Thu, 13 Feb 1997 14:21:15 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA13321 for ; Thu, 13 Feb 1997 14:21:07 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA10712 for hackers@FreeBSD.ORG; Thu, 13 Feb 1997 23:21:04 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id XAA05918; Thu, 13 Feb 1997 23:04:50 +0100 (MET) Message-ID: Date: Thu, 13 Feb 1997 23:04:49 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: strlen() question References: <199702132004.NAA17798@hemi.com> <199702132055.NAA00955@phaeton.artisoft.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702132055.NAA00955@phaeton.artisoft.com>; from Terry Lambert on Feb 13, 1997 13:55:16 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > | style(9) - Kernel source file style guide > > See, there's the problem: libc is a user space library, not > a kernel source file. But that wasn't what you claimed being your original problem, right? I wonder when you ever admit being wrong for the first time... The title line of style(9) is slightly misleading. If you have had looked into it instead of just mumbling about it, you would have noticed that it covers several userland style issues as well. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Feb 13 14:43:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA14797 for hackers-outgoing; Thu, 13 Feb 1997 14:43:27 -0800 (PST) Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA14784 for ; Thu, 13 Feb 1997 14:43:24 -0800 (PST) Received: (from asami@localhost) by vader.cs.berkeley.edu (8.8.4/8.7.3) id OAA18747; Thu, 13 Feb 1997 14:43:13 -0800 (PST) Date: Thu, 13 Feb 1997 14:43:13 -0800 (PST) Message-Id: <199702132243.OAA18747@vader.cs.berkeley.edu> To: jmb@freefall.freebsd.org CC: hamby@aris.jpl.nasa.gov, hackers@freebsd.org In-reply-to: <199702132215.OAA12899@freefall.freebsd.org> (jmb@freefall.freebsd.org) Subject: Re: Sun Workshop compiler vs. GCC? From: asami@vader.cs.berkeley.edu (Satoshi Asami) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * well, options make a huge difference on sun's compiler * (SC4.0 18 Oct 1995 C 4.0) * * compare the numbers vs the options listed below * * 6009606.087651: -O5 -dalign -native -xautopar <== strange * 6051658.950850: -xO5 -dalign -native * 3290361.568528: -xO5 -dalign * 3274313.272930: -xO5 I'm not saying options don't make a huge difference, I know I can make my compiler do totally stupid things (like if I take out -O :). I don't know what the -native option does, but what I'm saying is that once the "simple" optimizations are covered, adding more and more complex optimizations (as suggested by the "taking 3 times more to compile" comment) is not going to give you much difference. Of course, if the original Sun compiler was very brain damaged, you could see a big improvement. Maybe it was running in 386 mode without -native or something? :) Satoshi From owner-freebsd-hackers Thu Feb 13 14:43:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA14801 for hackers-outgoing; Thu, 13 Feb 1997 14:43:28 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA14782; Thu, 13 Feb 1997 14:43:23 -0800 (PST) Received: from www.sdsp.mc.xerox.com ([13.231.132.18]) by alpha.xerox.com with SMTP id <15646(8)>; Thu, 13 Feb 1997 14:42:45 PST Received: from gnu.sdsp.mc.xerox.com (gnu.sdsp.mc.xerox.com [13.231.133.90]) by www.sdsp.mc.xerox.com (8.8.5/8.8.5) with SMTP id RAA22749; Thu, 13 Feb 1997 17:44:15 -0500 (EST) Received: by gnu.sdsp.mc.xerox.com (4.1/client-1.3) id AA17459; Thu, 13 Feb 97 17:44:02 EST Message-Id: <9702132244.AA17459@gnu.sdsp.mc.xerox.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: mika ruohotie Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: undocumented kernel options... In-Reply-To: Your message of "Thu, 13 Feb 1997 13:02:43 PST." <199702132102.XAA07991@shadows.aeon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Feb 1997 14:43:52 PST From: "Marty Leisner" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > could anyone comment anything about those undocumented kernel options > in the end of the LINT? > > which ones to use for which purpose... > > i mean, i dont expect to see full details, just about one line, or even > only "if you use your machine on a fullmoon, set this on" > > just a basic idea what those are about, and lot of people would be slightly > more happier... (i assume many would looove to know) > > I have the same opinion...I don't want to have to UTSL. Linux kernel configuration has become much nicer with a tk tool, shouldn't freebsd have one too? -- marty leisner@sdsp.mc.xerox.com Member of the League for Programming Freedom From owner-freebsd-hackers Thu Feb 13 14:53:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA15855 for hackers-outgoing; Thu, 13 Feb 1997 14:53:37 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA15841 for ; Thu, 13 Feb 1997 14:53:30 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA01765; Thu, 13 Feb 1997 15:52:59 -0700 From: Terry Lambert Message-Id: <199702132252.PAA01765@phaeton.artisoft.com> Subject: Re: strlen() question To: joerg_wunsch@uriah.heep.sax.de Date: Thu, 13 Feb 1997 15:52:59 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: from "J Wunsch" at Feb 13, 97 11:04:49 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > | style(9) - Kernel source file style guide > > > > See, there's the problem: libc is a user space library, not > > a kernel source file. > > But that wasn't what you claimed being your original problem, right? > I wonder when you ever admit being wrong for the first time... I said that strlen() took a NULL terminated string. I corrected it to 0 terminated string to make the nit-pickers happy. "NUL" with one "L" is the invention of a Pascal programmer with nothing better to do than to make noises about sign-extension on non-two's complement hardware for type demotion of 0 to character. > The title line of style(9) is slightly misleading. If you have had > looked into it instead of just mumbling about it, you would have > noticed that it covers several userland style issues as well. Ah. So you are saying it is out of date. PS: A style guide is not going to dictate to me anything about user land coding style for a given platform. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Feb 13 15:29:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA18029 for hackers-outgoing; Thu, 13 Feb 1997 15:29:49 -0800 (PST) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA18023 for ; Thu, 13 Feb 1997 15:29:42 -0800 (PST) Received: by iafnl.es.iaf.nl with UUCP id AA04859 (5.67b/IDA-1.5 for hackers@FreeBSD.ORG); Fri, 14 Feb 1997 00:29:34 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.7.5/8.6.12) id XAA02823; Thu, 13 Feb 1997 23:22:12 +0100 (MET) From: Wilko Bulte Message-Id: <199702132222.XAA02823@yedi.iaf.nl> Subject: Re: MIME applications for FreeBSD To: terry@lambert.org (Terry Lambert) Date: Thu, 13 Feb 1997 23:22:12 +0100 (MET) Cc: jb@cimlogic.com.au, terry@lambert.org, hackers@FreeBSD.ORG In-Reply-To: <199702132041.NAA00703@phaeton.artisoft.com> from "Terry Lambert" at Feb 13, 97 01:41:02 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote... > "We" is very broad here. Most Europeans, especially Germans, are > not prevented from reverse engineering file formats or other > interfaces. The US agreed to this when the US became a Berne > signatory. Which implies either Joerg needs to enter the evil M$ empire or Terry should apply for the German citizenship ;-) > Terry Lambert Wilko _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl - Arnhem, The Netherlands |/|/ / / /( (_) Do, or do not. There is no 'try' - Yoda -------------------------------------------------------------------------- From owner-freebsd-hackers Thu Feb 13 15:49:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA19140 for hackers-outgoing; Thu, 13 Feb 1997 15:49:17 -0800 (PST) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA19116; Thu, 13 Feb 1997 15:48:53 -0800 (PST) Received: (from karpen@localhost) by ocean.campus.luth.se (8.7.5/8.7.3) id AAA03462; Fri, 14 Feb 1997 00:46:24 +0100 (MET) From: Mikael Karpberg Message-Id: <199702132346.AAA03462@ocean.campus.luth.se> Subject: Re: MIME applications for FreeBSD To: se@freebsd.org (Stefan Esser) Date: Fri, 14 Feb 1997 00:46:23 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <19970213225745.YE06273@x14.mi.uni-koeln.de> from Stefan Esser at "Feb 13, 97 10:57:45 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Stefan Esser: > On Feb 13, terry@lambert.org (Terry Lambert) wrote: > > "We" is very broad here. Most Europeans, especially Germans, are > > not prevented from reverse engineering file formats or other > > interfaces. > > This is not true, actually! > > There are strict restrictions, with only few exceptions. > > Looking at the machine code of program binaries is not > allowed (and will be prosecuted) in general, for example. > > Interfaces may be reverse engineered ONLY for the purpose > of adding value to a product, which you then may sell. > > But publishing the results (eg. in the form of source code > that uses that interface) is prohibited. Well... One could always make someone documment the format by reverese enginering, or looking at the MS example code. No code, just the format of the files. Then just sending the documentation of the format to some other people, ought to make receipents "clean" enough to be able to write a BSD-licenced source from that, which can grok the format, and output ascii/ps/pdf files. No? /Mikael From owner-freebsd-hackers Thu Feb 13 16:04:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA20083 for hackers-outgoing; Thu, 13 Feb 1997 16:04:14 -0800 (PST) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA20076 for ; Thu, 13 Feb 1997 16:04:07 -0800 (PST) Received: (from karpen@localhost) by ocean.campus.luth.se (8.7.5/8.7.3) id BAA03489; Fri, 14 Feb 1997 01:04:54 +0100 (MET) From: Mikael Karpberg Message-Id: <199702140004.BAA03489@ocean.campus.luth.se> Subject: Re: Sun Workshop compiler vs. GCC? To: hamby@aris.jpl.nasa.gov (Jake Hamby) Date: Fri, 14 Feb 1997 01:04:54 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: from Jake Hamby at "Feb 13, 97 11:46:52 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Jake Hamby: > I just downloaded a 30-day trial of the newest version of Sun's C++ > compiler (ProCompiler 4.2), which is supposed to offer much better > optimization than previous versions. With the -fast option (which turns > on full optimization, plus 486, Pentium, or PPro optimization as > appropriate), it does seem to take about 3 times as long to compile > anything as GCC (on my 486DX4/100), and so I would hope that the generated > code is much better. [... lots removed ...] I seem to remember 4.2 autogenerating some kind of profiler info, so that if you compile something, and just run it once, and then recompile, the compiler will see what took most time, and go heavy on optimisations there. Neat feature. Don't know how well it works, though... Waiting for it to pop up in g++ too. Speaking of CC and g++... At work we use CC, and I'm getting fairly used to templates, WORKING exceptions (WOW! Who ever heard of such a thing?), and all the thread thingies, like mutexes, etc, default Just Working. So... Does anyone know when g++ will handle this? Would be SO nice to have at home too, for the pet projects. Last time I tried g++ on one of the files written at work, it barfed even PARSING the throw clauses in the function declaration. :( And catching a subclass with a catch clause for a baseclass? Forget it... *sigh* I'd really like a status report on this. Also, does templates work as they should in g++ (Template database, or so)? If not, what's the status on that? Lastly... with 2.2-RELEASE and onward... will the libc_r be replacing the standard libc, or what's the deal with that? I don't really understand how one would handle two libcs. /Mikael From owner-freebsd-hackers Thu Feb 13 16:06:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA20216 for hackers-outgoing; Thu, 13 Feb 1997 16:06:06 -0800 (PST) Received: from aris (aris.jpl.nasa.gov [137.78.161.113]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA20209 for ; Thu, 13 Feb 1997 16:05:56 -0800 (PST) Received: from localhost by aris (SMI-8.6/SMI-SVR4) id QAA10314; Thu, 13 Feb 1997 16:05:32 -0800 Date: Thu, 13 Feb 1997 16:05:31 -0800 (PST) From: Jake Hamby X-Sender: hamby@aris To: Satoshi Asami cc: jmb@freefall.freebsd.org, hackers@freebsd.org Subject: Re: Sun Workshop compiler vs. GCC? In-Reply-To: <199702132243.OAA18747@vader.cs.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 13 Feb 1997, Satoshi Asami wrote: > I'm not saying options don't make a huge difference, I know I can make > my compiler do totally stupid things (like if I take out -O :). > > I don't know what the -native option does, but what I'm saying is that > once the "simple" optimizations are covered, adding more and more > complex optimizations (as suggested by the "taking 3 times more to > compile" comment) is not going to give you much difference. -native causes it to optimize for whatever CPU is one the machine you're using to compile (e.g. 486, Pentium, PPro, sun4c, sun4m, sun4u, etc.) It will generate code that's compatible with the other processors, though (you can choose some other options and generate code that ONLY runs on UltraSPARC or PPro). -fast includes -xO4 and -native. As for "not making much difference", I'd be inclined to disagree. Here's what the Sun compiler does at the different levels (for x86): -xO1 Preloads arguments from memory, cross jump- ing (tail merging), as well as the single pass of the default optimization. -xO2 Schedules both high- and low-level instruc- tions and performs improved spill analysis, loop memory-reference elimination, register lifetime analysis, enhanced register alloca- tion, and elimination of global common subex- pression. -xO3 Performs loop strength reduction, induction variable elimination, as well as the optimi- zation done by level 2. -xO4 Performs loop unrolling, avoids creating stack frames when possible, and automatically inlines functions contained in the same file, as well as the optimization done by levels 2 and 3. Note that this optimization level can cause stack traces from adb and dbx to be incorrect. -xO5 Generates the highest level of optimization. Uses optimization algorithms that take more compilation time or that do not have as high a certainty of improving execution time. Some of these include generating local calling convention entry points for exported func- tions, further optimizing spill code, and added analysis to improve instruction scheduling. Your argument probably applies to -xO5, but it sounds like -xO4 performs some very useful optimizations indeed. I routinely run the Metrowerks compiler at -O7 (it has four levels of optimization, plus peephole optimization plus code scheduling), so either of these compilers sounds a lot more sophisticated than GCC, if for no other reason than the granularity of choices available. > Of course, if the original Sun compiler was very brain damaged, you > could see a big improvement. Maybe it was running in 386 mode without > -native or something? :) If you read the man page for the 4.0 ProCompiler, it sounds much less sophisticated than what I've just excerpted, at least for x86. It also didn't support PPro optimization. BTW, Sun is dropping support for the 386 as of Solaris 2.6, so one would presume that they'll recompile with optimizations for best performance across 486/Pentium/PPro, with perhaps separate versions of bcopy() or other speed-critical functions (they already do this on UltraSPARC). ------------------------------------------------------------------------------ |Jake Hamby| APT Engineer at JPL, CS student at Cal Poly, and BeOS developer!| ------------------------------------------------------------------------------ "Life is hard..." From owner-freebsd-hackers Thu Feb 13 16:35:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA22520 for hackers-outgoing; Thu, 13 Feb 1997 16:35:56 -0800 (PST) Received: from aris (aris.jpl.nasa.gov [137.78.161.113]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA22515 for ; Thu, 13 Feb 1997 16:35:52 -0800 (PST) Received: from localhost by aris (SMI-8.6/SMI-SVR4) id QAA10383; Thu, 13 Feb 1997 16:35:45 -0800 Date: Thu, 13 Feb 1997 16:35:45 -0800 (PST) From: Jake Hamby X-Sender: hamby@aris To: Satoshi Asami cc: hackers@FreeBSD.ORG Subject: Re: Sun Workshop compiler vs. GCC? In-Reply-To: <199702132125.NAA18583@vader.cs.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 13 Feb 1997, Satoshi Asami wrote: > I'm optimistic about this. My understanding is that the slowness and > number of bugs of Solaris is intrinsic to its complexity of design > (and also the fact that it was designed for workstations in mind, > initially). You just can't make a huge mammoth run fast, no matter > how much cash you sink into the compiler. Compiler optimization is no > cure for bad design. I didn't mean to imply that Sun is *only* tuning the compiler. The biggest improvements I know of will come through extensive use of "doors" (an IPC mechanism from Spring, their concept OS, and much faster than SYSV messaging, pipes, RPC, or any other UNIX IPC), which can pass messages in a couple of microseconds, and kernel sockets (and other TCP/IP improvements bringing the API in compliance with 4.3BSD), which provides up to 25% better Web server performance, or up to 2-3X improvement with tuning. Furthermore, they're planning to release their own Webserver for free, which should be multithreaded and VERY performance tuned, since they have Apache and Netscape server to learn from. I don't want to sound like an advertisement for Sun, it's just that they're so Buzzword Enriched, they will make people believe they have the best server platform. And it actually benefits them that the current version of Solaris has relatively nasty TCP/IP performance, because Solaris 2.6 will just look that much better in comparison. > Besides, Solaris x86 is such a festering piece of crap I can't believe > anyone actually using it for "serious" work. I'm now having sooooo > much fun trying to connect a bunch of disks to it (I need to yank and > reinsert cables at the right moment during boot, can't have an IDE disk > in the system if there is a SCSI disk with ID > 7, can't have three > SCSI adapters active at the same time or the system will hang, etc.). Solaris x86 is a piece of crap for device configuration, I agree. The autotuning kernel is a wonderful concept, but non-Plug-and-Play hardware completely thwarts it. I had the worst time getting an NE2000 card to be recognized, but that's probably the _worst_ card to detect so I can cut them a little slack. Again, *if* Solaris 2.6 gets this area fixed, a lot of people are going to give it a second look, especially if they combine it with a big ad campaign. > FreeBSD beats Solaris hands down in every aspect (reliability, ease of > configuration (/devices/pci@0,0/pci1011,1@f/pci9004,7278@4/cmdk@0,0:q,raw > is not my idea of simplicity), performance). I'd say Solaris is potentially more reliable because Sun has been working on it for 14 years (if you include time spent developing SunOS). You just wouldn't know that if you have buggy x86 drivers. I know there are SPARCs with uptimes in the _years_. Solaris is *potentially* easier to configure if you have all Plug-and-Play hardware, again the x86 version needs lots of improvement. Also, the Netra systems are prebundled with Web server, POP/IMAP, etc., although that's not available for x86, it shows the direction they'll be moving. Finally, there are a few areas where Solaris beats FreeBSD in performance, and vice versa, depending on who you talk to (for example, I remember on the NetBSD list, some users said NetBSD/SPARC was twice as fast as Solaris on certain math computations because of some register window effects, while Solaris had a significantly faster filesystem). Obviously, you should choose whichever OS best fits your needs. I didn't bring up Solaris to start a flamewar, just to point out that it offers some compelling advantages for an academic user, such as myself, who uses Suns at work and school, and their new compiler sounded intriguing. They are definitely the UNIX vendor to beat. Also, both FreeBSD and Linux have _lousy_ Java support (actually FreeBSD is better than Linux because we have a working JDK 1.0.2 that doesn't require shared library hell to set up), compared to Solaris, obviously. That's why it'd be nice if we could get SVR4 emulation support some day. ------------------------------------------------------------------------------ |Jake Hamby| APT Engineer at JPL, CS student at Cal Poly, and BeOS developer!| ------------------------------------------------------------------------------ "Life is hard..." From owner-freebsd-hackers Thu Feb 13 16:44:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA23076 for hackers-outgoing; Thu, 13 Feb 1997 16:44:47 -0800 (PST) Received: from aris (aris.jpl.nasa.gov [137.78.161.113]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA23061 for ; Thu, 13 Feb 1997 16:44:35 -0800 (PST) Received: from localhost by aris (SMI-8.6/SMI-SVR4) id QAA10418; Thu, 13 Feb 1997 16:44:21 -0800 Date: Thu, 13 Feb 1997 16:44:21 -0800 (PST) From: Jake Hamby X-Sender: hamby@aris To: Mikael Karpberg cc: hackers@freebsd.org Subject: Re: Sun Workshop compiler vs. GCC? In-Reply-To: <199702140004.BAA03489@ocean.campus.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 14 Feb 1997, Mikael Karpberg wrote: > I seem to remember 4.2 autogenerating some kind of profiler info, so that if > you compile something, and just run it once, and then recompile, the compiler > will see what took most time, and go heavy on optimisations there. Neat > feature. Don't know how well it works, though... Waiting for it to pop > up in g++ too. Actually, the profiling info shows which functions call the other functions most often, and it is the LINKER that moves those functions closer to each other, ideally into the same page. That way the program has a smaller effective working set size, and is more likely to fit into the CPU cache. All of Sun's shared libraries are optimized this way. > Speaking of CC and g++... At work we use CC, and I'm getting fairly used > to templates, WORKING exceptions (WOW! Who ever heard of such a thing?), > and all the thread thingies, like mutexes, etc, default Just Working. > So... Does anyone know when g++ will handle this? Would be SO nice to have > at home too, for the pet projects. Last time I tried g++ on one of the > files written at work, it barfed even PARSING the throw clauses in the > function declaration. :( And catching a subclass with a catch clause for > a baseclass? Forget it... *sigh* I'd really like a status report on this. > > Also, does templates work as they should in g++ (Template database, or so)? > If not, what's the status on that? Hmm, I thought g++ was pretty good in this area. Codewarrior is particularly lousy in some of the newer areas, but they're improving (thinking of BeOS), but I'd never had trouble with g++, using the libg++ STL (which, come to think of it, has probably been hacked to work around some of g++'s weaknesses). At any rate, I stay FAR away from the newer areas of the C++ standard, so I'm not the person to ask. I do know that Sun claims to be tracking the standard very closely (the same with MS Visual C++), but Sun includes tools.h++ instead of the STL. But I believe the latest version of tools.h++ is _based on_ the STL, so I dunno. I'll have to try some of the examples from the STL Tutorial and Reference Guide and see if they work on CC, and if so, do they need to be linked with tools.h++? > Lastly... with 2.2-RELEASE and onward... will the libc_r be replacing the > standard libc, or what's the deal with that? I don't really understand > how one would handle two libcs. I agree that two libc's is pretty foolish. I want the regular C library to be thread-safe, although you'd probably have to define _REENTRANT to use some of the features (like the _r() and pthreads functions) when you compile to pick up the function prototypes. ------------------------------------------------------------------------------ |Jake Hamby| APT Engineer at JPL, CS student at Cal Poly, and BeOS developer!| ------------------------------------------------------------------------------ "Life is hard..." From owner-freebsd-hackers Thu Feb 13 17:03:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA24142 for hackers-outgoing; Thu, 13 Feb 1997 17:03:04 -0800 (PST) Received: from white.dogwood.com (dave@white.dogwood.com [140.174.96.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA24122 for ; Thu, 13 Feb 1997 17:02:57 -0800 (PST) Received: (from dave@localhost) by white.dogwood.com (8.8.5/8.8.5) id RAA15071; Thu, 13 Feb 1997 17:02:35 -0800 (PST) From: Dave Cornejo Message-Id: <199702140102.RAA15071@white.dogwood.com> Subject: Re: MIME applications for FreeBSD In-Reply-To: <199702131933.GAA01212@freebsd1.cimlogic.com.au> from John Birrell at "Feb 14, 97 06:33:00 am" To: jb@cimlogic.com.au (John Birrell) Date: Thu, 13 Feb 1997 17:02:35 -0800 (PST) Cc: rb@gid.co.uk, jb@cimlogic.com.au, hackers@FreeBSD.ORG, terry@lambert.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk John Birrell wrote: > Bob Bishop wrote: > > At 8:38 am -0000 13/2/97, John Birrell wrote: > > >[...] > > >We are prevented from reverse engineering by the licence for msword > > >(I guess, since other MS products have that clause). MS is unlikely > > >to publicly document Word file format. [etc] > > > > They certainly don't seem to. Maybe reverse engineering is unnecessary: > > WordPad groks Word 6 format, and the source is in among the samples on the > > MSVC4.2 CD. > > What are the licence restrictions on that source and things derived > from it? WordPad is a demo program for the "power" of MFC - so you'd have to port MFC to whatever to get it running. I think that they also supply those on the 4.2 CD (I don't have mine here so can't check) but I'd expect that all those sources are meant for reference use by licensees of VC++ only... -- Dave Cornejo - Dogwood Media, Fremont, California From owner-freebsd-hackers Thu Feb 13 17:31:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA25709 for hackers-outgoing; Thu, 13 Feb 1997 17:31:29 -0800 (PST) Received: from lightside.com (hamby1.lightside.net [207.67.176.17]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id RAA25694 for ; Thu, 13 Feb 1997 17:31:12 -0800 (PST) Received: by lightside.com (SMI-8.6/SMI-SVR4) id RAA03400; Thu, 13 Feb 1997 17:31:21 -0800 Date: Thu, 13 Feb 1997 17:31:21 -0800 From: jehamby@lightside.com (Jake Hamby) Message-Id: <199702140131.RAA03400@lightside.com> To: hackers@freebsd.org, patrick@xinside.com Subject: Re: Sun Workshop compiler vs. GCC? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: Qdu+gZ2OoegF7CwJcoiLMQ== Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Patrick at XInside writes: > > I tried to get Solaris x86 up on two different machines. No go. Can > however install Linux FreeBSD etc. on these systems no problem. > System A - it didn't properly detect my Adaptec 1542B. > > System B - couldn't install the boot blocks properly on an IDE (not > EIDE) drive. > > Solaris won't capture the market, because they don't have a good > installation program. Maybe this isn't a very technical problem, but > it is a very real consideration when dealing with people who are just > trying to get things to work... I'd plunk down the money for Solaris > x86 if it would install easier - but it doesn't. I agree that Solaris installation is often a hit-or-miss business. Hell, the first time I installed it, it trashed my hard drive! The most recent time I installed it, I disconnected the other hard drive (with my DOS partition) to prevent such shenanigans (you have to trick the installer if you want to put the root partition on the second HD, and you need something like BootEasy, but I did get it to work). I do have a few suggestions for you: Go to http://access1.sun.com and get the latest Driver Update disks. They are up to DU7 now (it works on Solaris 2.5 and 2.5.1). They extract to floppies and are set up so that the new drivers get loaded when you boot to install the system, and are then loaded onto the hard drive as patches (so they can be individually backed out or upgraded later). Pretty slick, but Sun has the SLOWEST patch installation mechanism I've seen (it's a big shell script interfaced to the SVR4 package commands). If you still have trouble, even with the latest DU (and be sure to read the PostScript "x86 Device Configuration Guide" from the same Web site), I'm sorry. I can only presume Solaris 2.6 will be "Plug and Play" and much nicer all around. But I agree, this is the weakest part of Solaris/x86 right now. >From the access1 Web site, you can also get the latest hardware compatibility list, and there are companies (the most well-known is EIS, www.eis.com) which sell PC's specifically configured for Solaris. P.S. Were you planning to port AcceleratedX to Solaris/x86? :-) It already supports XFree86, though I prefer to use OpenWindows, because even though it's deadly slow, it has Display PostScript and works well with CDE. They do support Matrox Millenium, which is pretty cool, but I use a lowly S3 805 card on my 486 (it's actually a "JAX 8241" but I told Solaris it was an "Orchid Fahrenheit 1280 Plus", which uses the same chipset). -- Jake From owner-freebsd-hackers Thu Feb 13 17:51:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA26651 for hackers-outgoing; Thu, 13 Feb 1997 17:51:56 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA26641 for ; Thu, 13 Feb 1997 17:51:48 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id MAA22743; Fri, 14 Feb 1997 12:21:29 +1030 (CST) From: Michael Smith Message-Id: <199702140151.MAA22743@genesis.atrad.adelaide.edu.au> Subject: Re: MIME applications for FreeBSD In-Reply-To: <199702140102.RAA15071@white.dogwood.com> from Dave Cornejo at "Feb 13, 97 05:02:35 pm" To: dave@dogwood.com (Dave Cornejo) Date: Fri, 14 Feb 1997 12:21:28 +1030 (CST) Cc: jb@cimlogic.com.au, rb@gid.co.uk, hackers@FreeBSD.ORG, terry@lambert.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Dave Cornejo stands accused of saying: > > > > > > They certainly don't seem to. Maybe reverse engineering is unnecessary: > > > WordPad groks Word 6 format, and the source is in among the samples on the > > > MSVC4.2 CD. > > > > What are the licence restrictions on that source and things derived > > from it? > > WordPad is a demo program for the "power" of MFC - so you'd have to > port MFC to whatever to get it running. I think that they also supply > those on the 4.2 CD (I don't have mine here so can't check) but I'd > expect that all those sources are meant for reference use by licensees > of VC++ only... I wouldn't really care if I were going to be serious about it; I'd take the guts of the program and use a native X GUI (probably Tk in my case), or go to someone like Willows or Bristol Softworks (?) and use their MFC-for-X libraries. The Twin XPDK actually looked pretty neat back when it was easily available; these days it's too expensive for me to take it seriously. 8( > Dave Cornejo - Dogwood Media, Fremont, California -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Thu Feb 13 18:18:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA28402 for hackers-outgoing; Thu, 13 Feb 1997 18:18:44 -0800 (PST) Received: from werple.net.au (melb.werple.net.au [203.9.190.18]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA28397 for ; Thu, 13 Feb 1997 18:18:40 -0800 (PST) Received: (qmail 29150 invoked by uid 5); 14 Feb 1997 02:18:28 -0000 MBOX-Line: From jb@freebsd1.cimlogic.com.au Fri Feb 14 13:18:49 1997 Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.7.5/8.7.3) id NAA01884; Fri, 14 Feb 1997 13:18:49 +1100 (EST) From: John Birrell Message-Id: <199702140218.NAA01884@freebsd1.cimlogic.com.au> Subject: Re: MIME applications for FreeBSD To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Fri, 14 Feb 1997 13:18:48 +1100 (EST) Cc: dave@dogwood.com, jb@cimlogic.com.au, rb@gid.co.uk, hackers@FreeBSD.ORG, terry@lambert.org In-Reply-To: <199702140151.MAA22743@genesis.atrad.adelaide.edu.au> from Michael Smith at "Feb 14, 97 12:21:28 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Michael Smith wrote: > I wouldn't really care if I were going to be serious about it; I'd > take the guts of the program and use a native X GUI (probably Tk in my > case), or go to someone like Willows or Bristol Softworks (?) and use > their MFC-for-X libraries. The Twin XPDK actually looked pretty neat > back when it was easily available; these days it's too expensive for > me to take it seriously. 8( I'd just like to see a program to convert msword to dvi. Then [getting back to FreeBSD 8-)] I could have a MIME application/msword defined on my FreeBSD machine that runs the conversion program and then xdvi (or whatever). I don't care about converting _to_ msword, or editing msword. Oh well, I suppose I'd better get out that VC++ CD since I had do delete the installed version because VB would not work, but that's another story! [Note to Australians: I mean Visual Basic, not Victoria Bitter. The latter being far more palatable than the former IMHO. 8-)]. > ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ -- John Birrell - jb@cimlogic.com.au; jb@netbsd.org CIMlogic Pty Ltd, 119 Cecil Street, South Melbourne Vic 3205, Australia Tel +61 3 9690 6900 Fax +61 3 9690 6650 Mob +61 418 353 137 From owner-freebsd-hackers Thu Feb 13 18:42:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA29417 for hackers-outgoing; Thu, 13 Feb 1997 18:42:39 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA29411 for ; Thu, 13 Feb 1997 18:42:36 -0800 (PST) Received: from caipfs.rutgers.edu (root@caipfs.rutgers.edu [128.6.155.100]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id SAA10593 for ; Thu, 13 Feb 1997 18:42:30 -0800 (PST) Received: from jenolan.caipgeneral (jenolan.rutgers.edu [128.6.111.5]) by caipfs.rutgers.edu (8.8.5/8.8.5) with SMTP id VAA10953; Thu, 13 Feb 1997 21:39:31 -0500 (EST) Received: by jenolan.caipgeneral (SMI-8.6/SMI-SVR4) id VAA04018; Thu, 13 Feb 1997 21:39:15 -0500 Date: Thu, 13 Feb 1997 21:39:15 -0500 Message-Id: <199702140239.VAA04018@jenolan.caipgeneral> From: "David S. Miller" To: karpen@ocean.campus.luth.se CC: hamby@aris.jpl.nasa.gov, hackers@freebsd.org In-reply-to: <199702140004.BAA03489@ocean.campus.luth.se> (message from Mikael Karpberg on Fri, 14 Feb 1997 01:04:54 +0100 (MET)) Subject: Re: Sun Workshop compiler vs. GCC? Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk From: Mikael Karpberg Date: Fri, 14 Feb 1997 01:04:54 +0100 (MET) Speaking of CC and g++... At work we use CC, and I'm getting fairly used to templates, WORKING exceptions (WOW! Who ever heard of such a thing?), and all the thread thingies, like mutexes, etc, default Just Working. So... Does anyone know when g++ will handle this? Would be SO nice to have at home too, for the pet projects. 2.8.0 will have what you describe. In fact completely generic exception code generation has been added to gcc's backend. This means the target specific code for exception generation can be shared between the ADA and C++ frontends. In fact the new exception mechanism allows you to compile a normal C library which is exception aware. For example, this lets a throw propagate properly back through a call to qsort() in libc. ---------------------------------------------//// Yow! 11.26 MB/s remote host TCP bandwidth & //// 199 usec remote TCP latency over 100Mb/s //// ethernet. Beat that! //// -----------------------------------------////__________ o David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ >< From owner-freebsd-hackers Thu Feb 13 18:44:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA29545 for hackers-outgoing; Thu, 13 Feb 1997 18:44:07 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA29537 for ; Thu, 13 Feb 1997 18:44:04 -0800 (PST) Received: from caipfs.rutgers.edu (root@caipfs.rutgers.edu [128.6.155.100]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id SAA10602 for ; Thu, 13 Feb 1997 18:43:47 -0800 (PST) Received: from jenolan.caipgeneral (jenolan.rutgers.edu [128.6.111.5]) by caipfs.rutgers.edu (8.8.5/8.8.5) with SMTP id VAA11143; Thu, 13 Feb 1997 21:42:13 -0500 (EST) Received: by jenolan.caipgeneral (SMI-8.6/SMI-SVR4) id VAA04024; Thu, 13 Feb 1997 21:41:56 -0500 Date: Thu, 13 Feb 1997 21:41:56 -0500 Message-Id: <199702140241.VAA04024@jenolan.caipgeneral> From: "David S. Miller" To: hamby@aris.jpl.nasa.gov CC: asami@vader.cs.berkeley.edu, jmb@freefall.freebsd.org, hackers@FreeBSD.ORG In-reply-to: (message from Jake Hamby on Thu, 13 Feb 1997 16:05:31 -0800 (PST)) Subject: Re: Sun Workshop compiler vs. GCC? Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Date: Thu, 13 Feb 1997 16:05:31 -0800 (PST) From: Jake Hamby Your argument probably applies to -xO5, but it sounds like -xO4 performs some very useful optimizations indeed. I routinely run the Metrowerks compiler at -O7 (it has four levels of optimization, plus peephole optimization plus code scheduling), so either of these compilers sounds a lot more sophisticated than GCC, if for no other reason than the granularity of choices available. GCC has more than 20 or so specific -f* options which allow you to selectively enable and disable any specific optimization pass it has. How much more granularity would you like to have? These are all completely explained in gcc's documentation. ---------------------------------------------//// Yow! 11.26 MB/s remote host TCP bandwidth & //// 199 usec remote TCP latency over 100Mb/s //// ethernet. Beat that! //// -----------------------------------------////__________ o David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ >< From owner-freebsd-hackers Thu Feb 13 20:20:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA04541 for hackers-outgoing; Thu, 13 Feb 1997 20:20:10 -0800 (PST) Received: from aris (aris.jpl.nasa.gov [137.78.161.113]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id UAA04514 for ; Thu, 13 Feb 1997 20:20:01 -0800 (PST) Received: from localhost by aris (SMI-8.6/SMI-SVR4) id UAA10722; Thu, 13 Feb 1997 20:17:39 -0800 Date: Thu, 13 Feb 1997 20:17:38 -0800 (PST) From: Jake Hamby X-Sender: hamby@aris To: "David S. Miller" cc: asami@vader.cs.berkeley.edu, jmb@freefall.freebsd.org, hackers@FreeBSD.ORG Subject: Re: Sun Workshop compiler vs. GCC? In-Reply-To: <199702140241.VAA04024@jenolan.caipgeneral> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 13 Feb 1997, David S. Miller wrote: > GCC has more than 20 or so specific -f* options which allow you to > selectively enable and disable any specific optimization pass it has. > How much more granularity would you like to have? These are all > completely explained in gcc's documentation. Hmm, good point. I guess I meant that the commercial compilers seem to have MORE kinds of optimizations than GCC, and because they support relatively few targets, they can devote more time to optimizing each code generation back-end. Also, the various optimizer bugs in GCC in the past have led people to be wary to use -O2 optimization, much less try additional optimization flags. ------------------------------------------------------------------------------ |Jake Hamby| APT Engineer at JPL, CS student at Cal Poly, and BeOS developer!| ------------------------------------------------------------------------------ "Life is hard..." From owner-freebsd-hackers Thu Feb 13 20:48:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA05544 for hackers-outgoing; Thu, 13 Feb 1997 20:48:52 -0800 (PST) Received: from caipfs.rutgers.edu (root@caipfs.rutgers.edu [128.6.155.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA05537 for ; Thu, 13 Feb 1997 20:48:46 -0800 (PST) Received: from jenolan.caipgeneral (jenolan.rutgers.edu [128.6.111.5]) by caipfs.rutgers.edu (8.8.5/8.8.5) with SMTP id XAA16062; Thu, 13 Feb 1997 23:48:22 -0500 (EST) Received: by jenolan.caipgeneral (SMI-8.6/SMI-SVR4) id XAA18687; Thu, 13 Feb 1997 23:48:07 -0500 Date: Thu, 13 Feb 1997 23:48:07 -0500 Message-Id: <199702140448.XAA18687@jenolan.caipgeneral> From: "David S. Miller" To: hamby@aris.jpl.nasa.gov CC: asami@vader.cs.berkeley.edu, jmb@freefall.freebsd.org, hackers@FreeBSD.ORG In-reply-to: (message from Jake Hamby on Thu, 13 Feb 1997 20:17:38 -0800 (PST)) Subject: Re: Sun Workshop compiler vs. GCC? Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Date: Thu, 13 Feb 1997 20:17:38 -0800 (PST) From: Jake Hamby Hmm, good point. I guess I meant that the commercial compilers seem to have MORE kinds of optimizations than GCC, and because they support relatively few targets, they can devote more time to optimizing each code generation back-end. I have been in fact been working with some people to encourage further work in this area, in particular: 1) Jakub Jelinek and myself have worked on what is termed "tail call" optimization, we call them sibling calls in the gcc implementation. This one is a huge win for many code sets which have a moderate to large stack call depth. It can eliminate entire local stack frames. As an easy example on the Sparc: extern int foo(int a); extern int bar(int b); static __inline__ int baz(int a, int b) { (void) foo(a); return bar(b); } static int func(int a, int b) { return baz(a, b); } gets turned into func: save %sp,-112,%sp call foo,0 mov %i0,%o0 call bar,0 restore %g0,%i1,%o0 (for those unfamiliar with Sparc, "save" allocates a register window and a stack frame, "restore" gives it back, Sparc also has branch/call delay slots) In that example the entire stack frame is given up in the delay slot of the call to bar(). If people think this is useless and cheezy, think again. Walk though your average kernel subsystem and see how many functions go: { if(args_invalid(args)) return -EFAULT; /* whatever */ if((file = file_from_fd(args)) == NULL) return -EBADF; inode = inode_from_file(file); return file->f_op->frobnicate(areg); } Also, networking stacks where layer upon layer gets called via a function ptr dereference as each packet walks up the various layers. Nine times out of ten this is the last thing the function in question does, and thus is subject to the optimizations just described as well. For example, in the Linux kernel sibling call optimization was shown to be applied over 1,000 times, approximately 186 of which were found to be in critical code paths. This was on the Sparc platform. Currently only the Sparc backend support for sibling calls are fully tested and working well in our patches, Intel, Alpha, and MIPS support for siblings calls are mostly done and should be ready soon. We are rather confident that this work will go all be in gcc-2.8.0. 2) I'm sure some people here know this, but there are people who have taken all of the Pentium optimization work on gcc done by the Intel compiler people way back, and are working on improving it. They are actively maintaining those changes, fixing bugs, and adding new optimizations as well. Also, one of the larger reasons that these changes never made it into the FSF gcc sources is that numerous generic changes were made to GCC which were not pretty at all. Cygnus and others are working on revamping some of the front end to back end architecture of GCC so that the types of things the Pentium optimizations needed are there, and are implemented cleanly. Also, the various optimizer bugs in GCC in the past have led people to be wary to use -O2 optimization, much less try additional optimization flags. I know about them, just about all of them are in the strength reduction pass. I am very familiar with the problematic bugs this layer has, and I have been actively trying to get people on the GCC development team to fix them. Almost all of these problems have to do with when a pointer comparison is converted into an integer invariant comparison, and vice versa. GCC in certain circumstances does not notice the change in signed'ness and thus produces incorrect code. In gcc-2.7.2.1, the strength reduction transformations that were known to lead to this situation were disabled entirely and in fact this fix was the entire reason for that release of gcc. ---------------------------------------------//// Yow! 11.26 MB/s remote host TCP bandwidth & //// 199 usec remote TCP latency over 100Mb/s //// ethernet. Beat that! //// -----------------------------------------////__________ o David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ >< From owner-freebsd-hackers Thu Feb 13 20:53:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA05721 for hackers-outgoing; Thu, 13 Feb 1997 20:53:29 -0800 (PST) Received: from fallout.campusview.indiana.edu (fallout.campusview.indiana.edu [149.159.1.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA05716 for ; Thu, 13 Feb 1997 20:53:21 -0800 (PST) Received: from localhost (jfieber@localhost) by fallout.campusview.indiana.edu (8.8.5/8.8.5) with SMTP id XAA12128; Thu, 13 Feb 1997 23:53:34 -0500 (EST) Date: Thu, 13 Feb 1997 23:53:33 -0500 (EST) From: John Fieber To: Jake Hamby cc: hackers@FreeBSD.ORG Subject: Re: Sun Workshop compiler vs. GCC? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 13 Feb 1997, Jake Hamby wrote: > I don't want to sound like an advertisement for Sun, it's just that > they're so Buzzword Enriched, they will make people believe they have the > best server platform. On the whole, I think we would be better off having people believe Sun's hype about Solaris than believing Microsoft's hype about NT. FreeBSD would have a much greater chance of successfully infiltrating a solaris environment than it would an NT environment. :) -john From owner-freebsd-hackers Thu Feb 13 20:56:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA05875 for hackers-outgoing; Thu, 13 Feb 1997 20:56:29 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA05868 for ; Thu, 13 Feb 1997 20:56:27 -0800 (PST) Received: from marvin (root@ts149.slip.ksu.edu [129.130.231.149]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id UAA10810 for ; Thu, 13 Feb 1997 20:56:25 -0800 (PST) Received: (from joed@localhost) by marvin (8.8.4/8.8.2) id WAA01658; Thu, 13 Feb 1997 22:54:53 -0600 (CST) Message-ID: Date: Thu, 13 Feb 1997 22:53:51 -0600 From: joed@ksu.edu (Joe Diehl) To: freebsd-hackers@freebsd.org Subject: user-level ppp mtu problems X-Mailer: Mutt 0.55 Mime-Version: 1.0 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Greetings, For the past several months I've been having interesting problems with my internet link via the user level ppp program. Essentially any connection in which I attempted to send large quantities of data (ie more than what's generated by an interactive shell) would hang and enter a state of FIN_WAIT_1. I spent a little bit of time digging through the code, and came accross the `set mtu` command. I assumed then that this command would override the MTU setting. But to no avail, the connections didn't work. In the end my problems are mostly a problem with our ciscos; however, there seems to be a logic problem in so far as I couldn't overload the MTU setting to something other than the MRU reported by the ppp server. As much as I'd like to spend sometime digging through the source code to fix it myself, I simply don't have the time right now. For the time being a simple hack to one of the header files resetting the MAX_MRU and DEF_MRU to 552 has solved my problem. Danke --- Joe Diehl PGP Key: finger joed@unix.ksu.edu From owner-freebsd-hackers Thu Feb 13 21:44:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA08564 for hackers-outgoing; Thu, 13 Feb 1997 21:44:08 -0800 (PST) Received: from darkstar (ras523.srv.net [205.180.127.23]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id VAA08541 for ; Thu, 13 Feb 1997 21:44:03 -0800 (PST) Received: (from cmott@localhost) by darkstar (8.6.12/8.6.12) id WAA07217; Thu, 13 Feb 1997 22:43:47 -0700 Date: Thu, 13 Feb 1997 22:43:42 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar To: Joe Diehl cc: freebsd-hackers@freebsd.org Subject: Re: user-level ppp mtu problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I spent a little bit of time digging through the code, and came accross > the `set mtu` command. I assumed then that this command would override > the MTU setting. But to no avail, the connections didn't work. I have had the same experience. Charles Mott From owner-freebsd-hackers Thu Feb 13 21:47:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA08774 for hackers-outgoing; Thu, 13 Feb 1997 21:47:13 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id VAA08768 for ; Thu, 13 Feb 1997 21:47:06 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vvGU1-0001xO-00; Thu, 13 Feb 1997 22:46:53 -0700 To: Terry Lambert Subject: Re: strlen() question Cc: joerg_wunsch@uriah.heep.sax.de, hackers@freebsd.org In-reply-to: Your message of "Thu, 13 Feb 1997 15:52:59 MST." <199702132252.PAA01765@phaeton.artisoft.com> References: <199702132252.PAA01765@phaeton.artisoft.com> Date: Thu, 13 Feb 1997 22:46:52 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199702132252.PAA01765@phaeton.artisoft.com> Terry Lambert writes: : "NUL" : with one "L" is the invention of a Pascal programmer with nothing : better to do than to make noises about sign-extension on non-two's : complement hardware for type demotion of 0 to character. Ummm, no that's nil. NUL is listed in the ASCII standard as being the official mnemonic for the character occupying the 0th slot. Just like dc1 is control S and dc3 is control Q (for Device Control). This nit pickers corner brought to you by: Warner From owner-freebsd-hackers Thu Feb 13 22:12:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA09920 for hackers-outgoing; Thu, 13 Feb 1997 22:12:11 -0800 (PST) Received: from monk.via.net (monk.via.net [140.174.204.10]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id WAA09915 for ; Thu, 13 Feb 1997 22:12:02 -0800 (PST) Received: (from joe@localhost) by monk.via.net (8.6.11/8.6.12) id WAA22731 for hackers@freebsd.org; Thu, 13 Feb 1997 22:04:19 -0800 Date: Thu, 13 Feb 1997 22:04:19 -0800 From: Joe McGuckin Message-Id: <199702140604.WAA22731@monk.via.net> To: hackers@freebsd.org Subject: Re: Sun Workshop compiler vs. GCC? X-Sun-Charset: US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I'd say Solaris is potentially more reliable because Sun has been working >on it for 14 years (if you include time spent developing SunOS). You just This is not correct. Solaris 2.0 was a completely different implementation than SunOS. Solaris 2.5.1 is the first version that is comparable to SunOS 4.1.3 in speed, stability or any other metric you care to use. Hmm, it's only taken them what - four, five years to whip Solaris into share. Now I suppose it's time to drop Solaris in favor of Spring or JavaOS. -joe From owner-freebsd-hackers Thu Feb 13 22:22:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA10281 for hackers-outgoing; Thu, 13 Feb 1997 22:22:55 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA10264; Thu, 13 Feb 1997 22:22:45 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id XAA14590; Thu, 13 Feb 1997 23:21:05 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Thu, 13 Feb 1997 22:44:46 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: freebsd-hackers@freebsd.org, freebsd-scsi@freebsd.org Subject: Software Interrupts Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have dug into the software interrupts a bit and would like to confirm the best approach. Problem Description: I would like to trigger an interrupt, from within a device driver. The reason for doing so (may not be so good :-): I would like to de-couple queueing SCSI commands from the calling layer on one side and results analysis and error handling from the interrupt handler on the other side. Let me be more specific: when the SCSI code calls my driver's xxx_scsi_cmd entry point, I take the command, tweak it to the hardware vendor's content, put the request in a queue. At this point i would like to evoke an interrupt and return QUEUED_SUCCESSFULLY. The interrupt routine then will go to the queue and negotiate with the device all these wonderful inb, outb and such. The calling process is not bound by hardware delays. When a hardware interrupt, from the HBA, occurs, I want to be able to, in the interrupt service routine to just capture the hardware state (it takes only two inb's (can be reduced to one) one indirect dereferencing and a 24 bytes bcopy) into the request's CCB, move the request to the ``complete'' queue, schedule a software interrupt and schedule another software interrupt. This one will process however many requests there are in the ``completed'' queue. In this fasion, the interrupt routine will remain very short, consume very little time. The device we are interfacing to can give us SCSI command completion in less than 1ms. Much less in fact. Now, if you nice people know of a better way (than software interrupts) to do this, i will be happy to hear about it. Just as an intelectual excercise, please help me understand the software interrupts business. I have noticed that the Inet code that uses them, boils down to calling setbits (an inline defined in i386/include/cpufunc.h). Setbits takes the address of an unsigned and a u_int called bits. Different purposes in the kernel call setbits with different arguments. The argument is always the address of either ipending or of idelayed. These appear to be global bitmaps describing which interrupts are pending or delayed. What I cannot find is how to register a software interrupt. They appear, as if by magic. So, after all this, i am asking for a way to schedule two software interrupts. I really do not care what arguments will be passed to these functions, what value they return, or what. Just so they get invoked at some known priority, without fighting for CPU with the splbio guys. At the context of a true SMP machine, this scheme makes even more sense. But it may improve our responsiveness quite a bit, at some cost of increased overhead. the old game of latency vs. throughput. Thanx a million. Simon From owner-freebsd-hackers Thu Feb 13 22:28:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA10538 for hackers-outgoing; Thu, 13 Feb 1997 22:28:02 -0800 (PST) Received: from bofh.cybercity.dk (relay.cybercity.dk [195.8.128.254]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA10494; Thu, 13 Feb 1997 22:27:53 -0800 (PST) Received: from critter.dk.tfs.com (phk.cybercity.dk [195.8.133.247]) by bofh.cybercity.dk (8.8.3/8.7.3) with ESMTP id HAA01894; Fri, 14 Feb 1997 07:30:28 +0100 (MET) Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.2/8.8.2) with ESMTP id HAA07648; Fri, 14 Feb 1997 07:29:52 +0100 (MET) To: "Marty Leisner" cc: mika ruohotie , freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: undocumented kernel options... In-reply-to: Your message of "Thu, 13 Feb 1997 14:43:52 PST." <9702132244.AA17459@gnu.sdsp.mc.xerox.com> Date: Fri, 14 Feb 1997 07:29:51 +0100 Message-ID: <7646.855901791@critter.dk.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <9702132244.AA17459@gnu.sdsp.mc.xerox.com>, "Marty Leisner" writes: >> could anyone comment anything about those undocumented kernel options >> in the end of the LINT? >> >> which ones to use for which purpose... >> >> i mean, i dont expect to see full details, just about one line, or even >> only "if you use your machine on a fullmoon, set this on" >> >> just a basic idea what those are about, and lot of people would be slightly >> more happier... (i assume many would looove to know) >> >> >I have the same opinion...I don't want to have to UTSL. Linux kernel >configuration has become much nicer with a tk tool, shouldn't freebsd have >one too? Sure! When will you have it done ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-hackers Thu Feb 13 22:41:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA11409 for hackers-outgoing; Thu, 13 Feb 1997 22:41:05 -0800 (PST) Received: from gdi.uoregon.edu (gdi.uoregon.edu [128.223.170.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA11404 for ; Thu, 13 Feb 1997 22:41:01 -0800 (PST) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.5/8.6.12) with SMTP id WAA00664 for ; Thu, 13 Feb 1997 22:40:55 -0800 (PST) Date: Thu, 13 Feb 1997 22:40:55 -0800 (PST) From: Doug White X-Sender: dwhite@localhost Reply-To: Doug White To: hackers@freebsd.org Subject: mfs & swap relationship Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello! What's significant about mounting mfs's on the same partition as a system swap partition? The mount_mfs(8) man page hints that this partition is used for any spillover, but that doesn't make sense. Why isolate it to a specific swap partition? And can you make an mfs that's attached to a different partition? Thanks for any info. Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major From owner-freebsd-hackers Thu Feb 13 23:03:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA12789 for hackers-outgoing; Thu, 13 Feb 1997 23:03:08 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA12748; Thu, 13 Feb 1997 23:02:18 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id RAA25364; Fri, 14 Feb 1997 17:29:31 +1030 (CST) From: Michael Smith Message-Id: <199702140659.RAA25364@genesis.atrad.adelaide.edu.au> Subject: Re: undocumented kernel options... In-Reply-To: <7646.855901791@critter.dk.tfs.com> from Poul-Henning Kamp at "Feb 14, 97 07:29:51 am" To: phk@critter.dk.tfs.com (Poul-Henning Kamp) Date: Fri, 14 Feb 1997 17:29:31 +1030 (CST) Cc: leisner@sdsp.mc.xerox.com, bsdcur@shadows.aeon.net, freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp stands accused of saying: > >I have the same opinion...I don't want to have to UTSL. Linux kernel > >configuration has become much nicer with a tk tool, shouldn't freebsd have > >one too? Questions like this really annoy me. Why aren't these people talking on the freebsd-config list? Do Jordan and I have to contribute _all_ the content? I hardly have time to _sneeze_, let alone design the monstrosity we need. > Sure! > > When will you have it done ? I have the parser and the data structures and some of the interactive code written. I have about half of a GUI frontend to 'pw' done as well. I suspect that Tix will be required for both. > Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Fri Feb 14 00:08:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA16764 for hackers-outgoing; Fri, 14 Feb 1997 00:08:27 -0800 (PST) Received: from shadows.aeon.net (bsdcur@shadows.aeon.net [194.100.41.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA16704; Fri, 14 Feb 1997 00:08:00 -0800 (PST) Received: (from bsdcur@localhost) by shadows.aeon.net (8.8.5/8.8.3) id KAA11779; Fri, 14 Feb 1997 10:03:08 +0200 (EET) From: mika ruohotie Message-Id: <199702140803.KAA11779@shadows.aeon.net> Subject: Re: undocumented kernel options... To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Fri, 14 Feb 1997 10:03:08 +0200 (EET) Cc: phk@critter.dk.tfs.com, leisner@sdsp.mc.xerox.com, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org In-Reply-To: <199702140659.RAA25364@genesis.atrad.adelaide.edu.au> from Michael Smith at "Feb 14, 97 05:29:31 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Questions like this really annoy me. Why aren't these people talking > on the freebsd-config list? Do Jordan and I have to contribute _all_ pardon me, i did not know such list, should've rtfm:ed myself better. so, i'll shut up and subscribe. mickey From owner-freebsd-hackers Fri Feb 14 00:15:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA17289 for hackers-outgoing; Fri, 14 Feb 1997 00:15:05 -0800 (PST) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA17284; Fri, 14 Feb 1997 00:15:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.7.5/8.6.12) with SMTP id AAA14402; Fri, 14 Feb 1997 00:07:59 -0800 (PST) Message-Id: <199702140807.AAA14402@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: Host localhost [127.0.0.1] didn't use HELO protocol To: Michael Smith Cc: phk@critter.dk.tfs.com (Poul-Henning Kamp), leisner@sdsp.mc.xerox.com, bsdcur@shadows.aeon.net, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: undocumented kernel options... Reply-To: Jason Thorpe From: Jason Thorpe Date: Fri, 14 Feb 1997 00:07:58 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Poul-Henning Kamp stands accused of saying: > > >I have the same opinion...I don't want to have to UTSL. Linux kernel > > >configuration has become much nicer with a tk tool, shouldn't freebsd have > > >one too? [ sorry I missed Poul's original post... ] So, we over at NetBSD have resisted the "GUI kernel config frob" mostly because: - bloat-ware (if you ship a GUI tool, you are basically required to ship X, etc... I'm not about to force X on my users... :-) - maintenance nightmare In our world, config(8) is simply too flexible, and having to update the GUI to deal each time would .. suck. OTOH, this was a win for Linux, because their previous kernel configuration mechansim (a sort of 20,000-questions game) _really_ sucked... _anything_ would have been an improvement :-) Documentation on how to edit a kernel configuration file is loads better IMO than having a rigid GUI (so, you update config to deal with new syntax, and how you have to update the GUI, as well...) (So, if you've ever used HP's SAM, you'll understand just how frustrating using a GUI to configure your kernel can be, if you've previously used "vi CONFIGNAME".) ...plus, the user can insert arbitrary, random options.... major win. On Fri, 14 Feb 1997 17:29:31 +1030 (CST) Michael Smith wrote: > I have the parser and the data structures and some of the interactive code > written. I have about half of a GUI frontend to 'pw' done as well. I > suspect that Tix will be required for both. This is why I tend to resist "GUI as standard equipment". "Ok, so we have to ship this library now..." Really, if it's going to ship with the OS, make it a curses thing... (Then, you can even run it on a serial console, which is important for server systems and, well, my hp 340 :-) Anyhow, $0.02 from a NetBSD guy... Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: 408.866.1912 NAS: M/S 258-6 Work: 415.604.0935 Moffett Field, CA 94035 Pager: 415.428.6939 From owner-freebsd-hackers Fri Feb 14 01:35:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA21411 for hackers-outgoing; Fri, 14 Feb 1997 01:35:12 -0800 (PST) Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA21396 for ; Fri, 14 Feb 1997 01:35:06 -0800 (PST) Received: from gid.co.uk (uucp@localhost) by isbalham.ist.co.uk (8.8.4/8.8.4) with UUCP id JAA06743; Fri, 14 Feb 1997 09:30:45 GMT Date: Fri, 14 Feb 1997 09:27:11 GMT Received: from [194.32.164.2] by seagoon.gid.co.uk; Fri, 14 Feb 1997 09:27:11 GMT X-Sender: rb@194.32.164.1 Message-Id: In-Reply-To: <199702132216.PAA02367@chon.xinside.com> References: <199702132125.NAA18583@vader.cs.berkeley.edu> <199702132125.NAA18583@vader.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: patrick@xinside.com From: Bob Bishop Subject: Re: Sun Workshop compiler vs. GCC? Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 10:16 pm -0000 13/2/97, Patrick Giagnocavo wrote: >[...] >Solaris won't capture the market, because they don't have a good >installation program. True, but not the main problem. Solaris won't capture the market because the SOB simply won't work on most hardware. With FreeBSD, you're having a very bad day if you can't just stuff the disks into a random PC and watch the thing install itself (I exaggerate only slightly). With Solaris, my experience is that you can forget it if the hardware doesn't conform in all respects to the letter of the "supported" list, and even then there's a good chance it won't play. Maybe if my clients had money to burn and bought Compaq, IBM, ... -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK From owner-freebsd-hackers Fri Feb 14 01:54:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA22452 for hackers-outgoing; Fri, 14 Feb 1997 01:54:09 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA22436 for ; Fri, 14 Feb 1997 01:52:38 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id KAA24821 for hackers@freebsd.org; Fri, 14 Feb 1997 10:05:20 +0100 From: Luigi Rizzo Message-Id: <199702140905.KAA24821@labinfo.iet.unipi.it> Subject: Re: to 4k_start or not to 4k_start? (fwd) To: hackers@freebsd.org Date: Fri, 14 Feb 1997 10:05:19 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Another interesting suggestion from David Borman, on the end2end list, about speeding up (short) TCP connections. Maybe David or Garret want to have a look at it. Luigi Forwarded message: > From majordom@ISI.EDU Fri Feb 14 00:14:17 1997 > Date: Thu, 13 Feb 1997 15:26:38 -0700 (MST) > From: David Borman > Message-Id: <199702132226.PAA28256@forge.BSDI.COM> > To: raj@hpisrdq.cup.hp.com, rstevens@kohala.com, shep@BBN.COM > Subject: Re: to 4k_start or not to 4k_start? > Cc: end2end-interest@ISI.EDU > Sender: owner-end2end-interest@ISI.EDU > Precedence: bulk > > Yes and no. I don't think that this was a specific "feature" in BSD, > but more of an accident. When I was working on some of the TCP > performance enhancements for BSD/OS 2.1 this summer (patch K210-019), > I dealt with this. What I discovered was that after completing the > 3-way handshake, the active side had a congestion window of 2*mss, and > the passive side had a congestion window of 1*mss. So, you would get > good initial throughput if the side doing the connect was pushing data > down the pipe, but if it was connecting and sucking down the data > (like most HTTP connections), then you'd get into the problem of only > sending one data packet, and then waiting for the other side to time > out the delayed ACK. I fixed BSD/OS so that now when either the SYN|ACK > or ACK arrives, when we are through processing it the congestion window > will be at 2*mss on both sides of the connection. This allows 2 packets > of data to be sent immediatly, and we get past the delayed ACK problem. > Note that you also need to change tcp_output(), so that on idle when > it resets the congestion window, that it sets it to 2*mss instead > of just 1*mss. > > I should point out that this isn't the only area that I made changes. > My goal was to make a short TCP connection (a few K of data) run fast, > without having any artifical delays (like delayed ACKs). > > Another solution is in the client. When the server side is most > likely doing slow start, immediatly ACK the first few data packets. > I implemented this in UNICOS by adding a new variable, call it > t_fastack, in the TCP control block. It is initially set to > seq + 8*MSS (don't ask why I chose 8, 2 probably would have been > just fine) As data comes in, if SEG.SEQ < t_fastack, it is immediatly > acked. As the connections continues, t_fastack is pulled along > as new data is acked. If the connection went idle for some amount > of time, then t_fastack was pushed ahead since the other side was > probably going to do slowstart. In tcp_input(): > */ > + if (tp->t_idle > IDLE_THRESHOLD) > + tp->t_fastack = tp->t_rcv_nxt + 8*tp->t_maxseg; > tp->t_idle = 0; > Anyway, the details aren't all there, but you get the picture. > > -David Borman, dab@bsdi.com -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Fri Feb 14 03:03:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA26171 for hackers-outgoing; Fri, 14 Feb 1997 03:03:44 -0800 (PST) Received: from multi22.netcomi.com (tucker@multi22.netcomi.com [204.58.155.222]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA26155 for ; Fri, 14 Feb 1997 03:03:40 -0800 (PST) Received: (from tucker@localhost) by multi22.netcomi.com (8.7.5/8.7.3) id FAA09065; Fri, 14 Feb 1997 05:02:59 -0600 Received: from pcg.com (pcg.com [207.98.153.4]) by multi22.netcomi.com (8.7.5/8.7.3) with ESMTP id FAA09060 for ; Fri, 14 Feb 1997 05:02:52 -0600 Received: (from bin@localhost) by pcg.com (8.8.5/8.8.5) id MAA12467 for linuxisp-outgoing; Thu, 13 Feb 1997 12:24:35 -0700 Message-Id: <3.0.32.19970213140425.00c16c70@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 13 Feb 1997 14:04:28 -0500 Old-To: freebsd-isp@freebsd.org From: dennis Subject: [Linux-ISP] ET users Lists Cc: hackers@freebsd.org, linuxisp@lightning.com, inet-access@earth.com, bsdi-users@bsdi.com, bsdi-isps@bsdi.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop: tucker@transnetional.com To: tucker@udb.transnetional.com Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Our list is back online, but you have to re-subscribe. We dont run it, so we're not sure what happened. Sorry of the inconvenience. See http://www.etinc.com/etlist.htm for details. Dennis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To [un]subscribe to this list, contact linuxisp-request@lightning.com Please send contributions for the mailing list to: linuxisp@lightning.com Please contact the mailing-list-owner as: linuxisp-owner@lightning.com From owner-freebsd-hackers Fri Feb 14 03:55:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA28139 for hackers-outgoing; Fri, 14 Feb 1997 03:55:12 -0800 (PST) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA28130 for ; Fri, 14 Feb 1997 03:55:09 -0800 (PST) Received: from vinyl.quickweb.com by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0vvHNz-00091zC; Thu, 13 Feb 97 22:44 PST Received: from localhost (mark@localhost) by vinyl.quickweb.com (8.7.5/8.6.12) with SMTP id BAA29333; Fri, 14 Feb 1997 01:41:07 -0500 (EST) Date: Fri, 14 Feb 1997 01:41:06 -0500 (EST) From: Mark Mayo To: Charles Mott cc: Joe Diehl , freebsd-hackers@FreeBSD.ORG Subject: Re: user-level ppp mtu problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 13 Feb 1997, Charles Mott wrote: > > I spent a little bit of time digging through the code, and came accross > > the `set mtu` command. I assumed then that this command would override > > the MTU setting. But to no avail, the connections didn't work. > > I have had the same experience. > > Charles Mott > I've also had similar problems. For me (and a few friends as well), user-level ppp will rise the load average up to 1.00 - say about 3 times out of 7. All of a sudden, the load will rise to 1.00, and won't come down until the ppp connection is dropped. The load seems to be "artificially" high, since the CPU is actually 99% idle, and the machine is normally responsive. I ktrace'd it when this happened once, but I lost the output.. perhaps I'll look into how load average is calculated, and see if I can figure out how to debug ppp when it acts weirdly... How should I go about this? Same results under 2.1.0 -> 2.2-GAMMA. Thanks, -mark ---------------------------------------------------------------------------- Mark Mayo mark@quickweb.com RingZero Comp. http://vinyl.quickweb.com/mark ---------------------------------------------------------------------------- "I prefer tongue-tied knowledge to ignorant loquacity." Cicero (106-43 B.C.) From owner-freebsd-hackers Fri Feb 14 04:16:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA29233 for hackers-outgoing; Fri, 14 Feb 1997 04:16:54 -0800 (PST) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id EAA29224 for ; Fri, 14 Feb 1997 04:16:50 -0800 (PST) Received: from deepo.prosa.dk ([193.89.187.27]) by mail.crl.com with SMTP id AA09153 (5.65c/IDA-1.5 for ); Fri, 14 Feb 1997 04:15:58 -0800 Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.5/8.8.4/prosa-1.1) id MAA14593; Fri, 14 Feb 1997 12:49:04 +0100 (CET) Message-Id: Date: Fri, 14 Feb 1997 12:49:04 +0100 From: regnauld@deepo.prosa.dk (Philippe Regnauld) To: freebsd-hackers@freebsd.org Subject: StarOffice/Linux (Was: MIME applications for FreeBSD) X-Mailer: Mutt 0.58 Mime-Version: 1.0 X-Operating-System: FreeBSD 2.2-BETA_A i386 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jake Hamby (jehamby) ecrit/writes: > > Hmm, I'd forgotten about Applixware, or for that matter StarOffice, which had a > free beta version of their office suite available from SunSite the last I > checked. StarOffice also makes Windows, OS/2 (and soon PowerMac and Solaris) > versions, I believe. Their Web site is: http://www.stardiv.de/ but it's > completely in German! www.stardiv.com is in english -- the problem is, the beta II expired... 1 Jan 97 ! More info on the german WWW indeed -- any German linguists available for info ? :-) -- -- Phil -[ Philippe Regnauld / Systems Administrator / regnauld@prosa.dk ]- -[ Location.: +55.4N +11.3E PGP Key: finger regnauld@deepo.prosa.dk ]- From owner-freebsd-hackers Fri Feb 14 04:23:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA00303 for hackers-outgoing; Fri, 14 Feb 1997 04:23:40 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id EAA00275 for ; Fri, 14 Feb 1997 04:23:34 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id MAA25239; Fri, 14 Feb 1997 12:37:15 +0100 From: Luigi Rizzo Message-Id: <199702141137.MAA25239@labinfo.iet.unipi.it> Subject: Re: Status of 21140AC driver ? To: tim@futuresouth.com (Tim Tsai) Date: Fri, 14 Feb 1997 12:37:15 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <199702131853.MAA23776@shell.futuresouth.com> from "Tim Tsai" at Feb 13, 97 12:52:59 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk To add a few datapoint to the 21140/21140A/21140-AC status: (the names are repeated so that the search engines will match someone of them!) the latest netbsd driver has a comment that the 21140A pass 2.0 and 2.1 have a broken receiver which might hang in case of rx overruns (this is very annoying since we have 20 of them!), which are likely to occur at 100Mbit/s with 8k NFS traffic. The driver apparently has a workaround but it is probably not operational (or, more likely, it is operational, but causes packets to be dropped; since the overrun is probably systematic, it does not allow the NFS traffic to continue; this would explain why the machine responds to pings). Now I have a machine running fully diskless with 1K NFS blocksize. pinging with 8000 bytes does not seem to cause the machine to hang. More news tonight. In the meantime, can people with problems tell me the Rev. and pass. number of their boards (printed by the kernel diagnostics) I'd really like to try and have this fixed, so your cooperation is very much appreciated. Thanks for your help Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Fri Feb 14 05:20:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA04513 for hackers-outgoing; Fri, 14 Feb 1997 05:20:37 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA04507 for ; Fri, 14 Feb 1997 05:20:34 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA09310; Fri, 14 Feb 1997 08:20:02 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Fri, 14 Feb 1997 08:20 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id HAA00655 for ; Fri, 14 Feb 1997 07:44:04 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id HAA10493 for freebsd-hackers@freefall.cdrom.com; Fri, 14 Feb 1997 07:48:42 -0500 (EST) Date: Fri, 14 Feb 1997 07:48:42 -0500 (EST) From: Thomas David Rivers Message-Id: <199702141248.HAA10493@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: Another panic: ffs_valloc: dup alloc Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Just so this doesn't languish - but not to be aggravating either, I just got another panic: ffs_valloc: dup alloc on different machine. (FreeBSD 2.1.6.1.) - Dave Rivers - From owner-freebsd-hackers Fri Feb 14 06:54:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA09680 for hackers-outgoing; Fri, 14 Feb 1997 06:54:53 -0800 (PST) Received: from news.cioe.com (news.cioe.com [204.120.165.34]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA09669 for ; Fri, 14 Feb 1997 06:54:48 -0800 (PST) Received: (from steve@localhost) by news.cioe.com (8.8.4/8.7.3) id JAA12395 for freebsd-hackers@freebsd.org; Fri, 14 Feb 1997 09:55:14 -0500 (EST) Date: Fri, 14 Feb 1997 09:55:14 -0500 (EST) From: Steve Ames Message-Id: <199702141455.JAA12395@news.cioe.com> To: freebsd-hackers@freebsd.org Subject: Re: Freewin95 - just fyi Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > It looked really good until I read the part of about him losing his > head of something or other before coding had begun due to a > personality dispute... It still looks good. I'm solidly behind the concept of getting more Free OSs out there. Their project might not get anywhere, but then again it might produce some usable code. I thought the gnu people were working on a UNIX varient also? Anyone know the status on that? -Steve From owner-freebsd-hackers Fri Feb 14 07:56:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA12466 for hackers-outgoing; Fri, 14 Feb 1997 07:56:42 -0800 (PST) Received: from carriage.chesco.com (root@carriage.chesco.com [205.164.157.2]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA12460 for ; Fri, 14 Feb 1997 07:56:37 -0800 (PST) Received: from a486.chesco.com ([206.62.61.5]) by carriage.chesco.com (8.8.5/8.6.9) with SMTP id KAA04579; Fri, 14 Feb 1997 10:56:24 -0500 (EST) Message-Id: <2.2.32.19970214155941.0073d220@carriage.chesco.com> X-Sender: bryan@carriage.chesco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Feb 1997 10:59:41 -0500 To: inet-access@earth.com From: Bryan Seltzer Subject: ET users Lists Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Subscribe ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| ||||||| |Bryan Seltzer Tech Hrs Mon, Tues, Thurs 9am-6pm |CCIS Tech Support Wed, Fri 11am-7pm 518-5700x910 From owner-freebsd-hackers Fri Feb 14 08:54:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA15479 for hackers-outgoing; Fri, 14 Feb 1997 08:54:54 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA15469 for ; Fri, 14 Feb 1997 08:54:49 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id RAA12815; Fri, 14 Feb 1997 17:51:05 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id RAA15687; Fri, 14 Feb 1997 17:36:53 +0100 (MET) Message-Id: <3.0.32.19970214173652.00c0b290@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 14 Feb 1997 17:36:53 +0100 To: Terry Lambert From: Eivind Eklund Subject: NULL as ((void*)0) (was Re: strlen() question) Cc: joerg_wunsch@uriah.heep.sax.de, hackers@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I hereby propose changing the default declaration of NULL under FreeBSD from #define NULL 0 to #define NULL ((void*)0) for better type-safety and ease of transition to other architechtures (e.g. Alpha). This will probably save us from a quite a few varargs-voes, as well as generally making sure the code-base is using NULL correctly, which is important for those reading source-code. At 03:52 PM 2/13/97 -0700, Terry Lambert wrote: >> > > | style(9) - Kernel source file style guide >> > >> > See, there's the problem: libc is a user space library, not >> > a kernel source file. >> >> But that wasn't what you claimed being your original problem, right? >> I wonder when you ever admit being wrong for the first time... > >I said that strlen() took a NULL terminated string. I corrected >it to 0 terminated string to make the nit-pickers happy. "NUL" >with one "L" is the invention of a Pascal programmer with nothing >better to do than to make noises about sign-extension on non-two's >complement hardware for type demotion of 0 to character. NULL is not equvalient to null or 0 or NUL. What you're talking about is best called a null-terminated string, as this is what it is. If you have a Pasacal or Lisp reference handy, you can look up nil - nil in Pascal/Lisp is the same as all uppercase NULL in C. (I'm not doing this _only_ to pick a nit - I'm doing it because it is somewhat that is important both for semantic understanding and for portability.) Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/ eivind@freebsd.org From owner-freebsd-hackers Fri Feb 14 08:58:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA15638 for hackers-outgoing; Fri, 14 Feb 1997 08:58:24 -0800 (PST) Received: from deepo.prosa.dk ([193.89.187.27]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA15612; Fri, 14 Feb 1997 08:57:47 -0800 (PST) Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.5/8.8.4/prosa-1.1) id RAA17810; Fri, 14 Feb 1997 17:57:25 +0100 (CET) Message-ID: Date: Fri, 14 Feb 1997 17:57:24 +0100 From: regnauld@deepo.prosa.dk (Philippe Regnauld) To: freebsd-emulation@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: StarOffice Beta3 setup SEGFAULT on 2.2-B X-Mailer: Mutt 0.58 Mime-Version: 1.0 X-Operating-System: FreeBSD 2.2-BETA_A i386 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk System: 2.2-B / 486-133 Linux-lib 2.3 installed Acroread works fine, so does Netscape Setup (linux.x86) ELF StarOffice setup blows up on execution (seg fault). I tried rebuilding linux ld.so cache to no avail... -- -- Phil -[ Philippe Regnauld / Systems Administrator / regnauld@prosa.dk ]- -[ Location.: +55.4N +11.3E PGP Key: finger regnauld@deepo.prosa.dk ]- From owner-freebsd-hackers Fri Feb 14 09:54:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA18780 for hackers-outgoing; Fri, 14 Feb 1997 09:54:51 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA18773 for ; Fri, 14 Feb 1997 09:54:46 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA03110; Fri, 14 Feb 1997 10:52:49 -0700 From: Terry Lambert Message-Id: <199702141752.KAA03110@phaeton.artisoft.com> Subject: Re: MIME applications for FreeBSD To: dave@dogwood.com (Dave Cornejo) Date: Fri, 14 Feb 1997 10:52:49 -0700 (MST) Cc: jb@cimlogic.com.au, rb@gid.co.uk, hackers@FreeBSD.ORG, terry@lambert.org In-Reply-To: <199702140102.RAA15071@white.dogwood.com> from "Dave Cornejo" at Feb 13, 97 05:02:35 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > What are the licence restrictions on that source and things derived > > from it? > > WordPad is a demo program for the "power" of MFC - so you'd have to > port MFC to whatever to get it running. I think that they also supply > those on the 4.2 CD (I don't have mine here so can't check) but I'd > expect that all those sources are meant for reference use by licensees > of VC++ only... You're permitted to use MFC on other platforms, but you must have a copy of VC++ for each platform. You are permitted to use and redistribute the code, so long as you make "significant" improvement to it. I'm betting you won't be able to get away with distributing the sources, no matter how much you improve it, though there is nothing that actually says you can't (most likely, they will redefine "significant", as necessary, to prevent you from doing so). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Feb 14 10:02:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA19409 for hackers-outgoing; Fri, 14 Feb 1997 10:02:52 -0800 (PST) Received: from aris (aris.jpl.nasa.gov [137.78.161.113]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA19404 for ; Fri, 14 Feb 1997 10:02:47 -0800 (PST) Received: from localhost by aris (SMI-8.6/SMI-SVR4) id KAA11446; Fri, 14 Feb 1997 10:01:55 -0800 Date: Fri, 14 Feb 1997 10:01:55 -0800 (PST) From: Jake Hamby X-Sender: hamby@aris To: John Fieber cc: hackers@FreeBSD.ORG Subject: Re: Sun Workshop compiler vs. GCC? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 13 Feb 1997, John Fieber wrote: > On the whole, I think we would be better off having people > believe Sun's hype about Solaris than believing Microsoft's hype > about NT. FreeBSD would have a much greater chance of > successfully infiltrating a solaris environment than it would an > NT environment. :) EXACTLY my belief! Us UNIX geeks have to stick together. Also, I firmly believe that no one OS is good for all tasks. Personally, my choice for OS's goes something like (in alphabetical order): BeOS: Probably the future OS for multimedia content developers, much as the Amiga was in the '80s, except without Commodore's mismanagement. FreeBSD: The best OS for Internet servers and embedded UNIX boxes (like an X terminal or that Interjet system). Linux: A good UNIX for non-TCP/IP related apps (like UUCP) ;) MacOS: The OS for people we are trying to migrate to BeOS ;) NetBSD/OpenBSD: A valuable cousin of FreeBSD, and (on SPARC), a good choice for people who don't want to move to Solaris, but can't stay with SunOS. NT: A file/print server, or good workstation for CAD, business apps, or Windows software development. Not a "real" server in my book. SCO: Evil incarnate. Stay away at all costs! Solaris: An all-around good UNIX, if you can get past the somewhat complex sysadmin aspects (they like to trade versatility for complexity). Will get even better in 2.6. SunOS: The UNIX I'm trying to migrate everyone away from, before Sun drops it completely, or another massive security hole is found. UnixWare: Haven't had opportunity to use, but it's by all accounts the fastest database server on x86 by far. Win95: The desktop OS for people who can't afford NT. Oh well, I've probably missed one or two. The point is that they all have their places, but for FreeBSD to be successful, we need to be more aware than ever of what batlles are worth fighting, who our friends are, and who is the Real Enemy (and I don't mean SCO ;). ------------------------------------------------------------------------------ |Jake Hamby| APT Engineer at JPL, CS student at Cal Poly, and BeOS developer!| ------------------------------------------------------------------------------ "Life is hard..." From owner-freebsd-hackers Fri Feb 14 10:38:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA22838 for hackers-outgoing; Fri, 14 Feb 1997 10:38:27 -0800 (PST) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA22830; Fri, 14 Feb 1997 10:38:22 -0800 (PST) Received: from narnia (localhost [127.0.0.1]) by narnia.plutotech.com (8.8.5/8.7.3) with ESMTP id LAA13492; Fri, 14 Feb 1997 11:34:20 -0700 (MST) Message-Id: <199702141834.LAA13492@narnia.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Jason Thorpe cc: Michael Smith , phk@critter.dk.tfs.com (Poul-Henning Kamp), leisner@sdsp.mc.xerox.com, bsdcur@shadows.aeon.net, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: undocumented kernel options... In-reply-to: Your message of "Fri, 14 Feb 1997 00:07:58 PST." <199702140807.AAA14402@lestat.nas.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Feb 1997 11:34:20 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >[ sorry I missed Poul's original post... ] > >So, we over at NetBSD have resisted the "GUI kernel config frob" mostly >because: > > - bloat-ware (if you ship a GUI tool, you are basically required > to ship X, etc... I'm not about to force X on my users... :-) > - maintenance nightmare > >In our world, config(8) is simply too flexible, and having to update >the GUI to deal each time would .. suck. I don't think that this has to be the case. The last time I looked into the config system, I thought, "Hmm. What if all configurable driver options could be dynamically registered/deregistered from the syctl tree?" This would mean that Userconfig is simply a sysctl editor and only requires knowledge of the sysctl interface and nothing more. You can also make the utility as fancy or plain as you wish and having X and non-X utilities for doing this would be quite painless. Of course, sysctl would need to be extended a little bit to make this happen (mostly some additional data types), but I think that since it leverages off of existing technology and would group all configuration information in one place, that it is a very clean solution. >Anyhow, $0.02 from a NetBSD guy... > >Jason R. Thorpe thorpej@nas.nasa.gov >NASA Ames Research Center Home: 408.866.1912 >NAS: M/S 258-6 Work: 415.604.0935 >Moffett Field, CA 94035 Pager: 415.428.6939 > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Fri Feb 14 10:43:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA23114 for hackers-outgoing; Fri, 14 Feb 1997 10:43:43 -0800 (PST) Received: from gdi.uoregon.edu (gdi.uoregon.edu [128.223.170.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA23106 for ; Fri, 14 Feb 1997 10:43:33 -0800 (PST) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.5/8.6.12) with SMTP id KAA01518; Fri, 14 Feb 1997 10:42:31 -0800 (PST) Date: Fri, 14 Feb 1997 10:42:31 -0800 (PST) From: Doug White X-Sender: dwhite@localhost Reply-To: Doug White To: Luigi Rizzo cc: Tim Tsai , hackers@freebsd.org Subject: Re: Status of 21140AC driver ? In-Reply-To: <199702141137.MAA25239@labinfo.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This info was forwarded on to me, and since I have this info, I'll pass it on. I don't have the card anymore, though, so I can't test it. On Fri, 14 Feb 1997, Luigi Rizzo wrote: > To add a few datapoint to the 21140/21140A/21140-AC status: (the > names are repeated so that the search engines will match someone > of them!) > > More news tonight. In the meantime, can people with problems tell me > the Rev. and pass. number of their boards (printed by the kernel > diagnostics) This is what my Kingston EtherRx 10/100 card spit out: Feb 11 22:31:19 gdi /kernel: de0 rev 32 int a irq 10 on pci0:17 Feb 11 22:31:19 gdi /kernel: de0: 21140A [10-100Mb/s] pass 2.0 Feb 11 22:31:19 gdi /kernel: de0: address 00:c0:f0:16:3f:1d Feb 11 22:31:19 gdi /kernel: de0: enabling 100baseTX port The chip is labelled 21140-AC. I swapped this card with a Dayna that wasn't going anywhere in a Mac Performa 6360. To say the least, both parties are very happy to have functional PCI Ethernet cards. > I'd really like to try and have this fixed, so your cooperation is very > much appreciated. As a datapoint, the 21041-AA chip in the Dayna E/PCI-M works fine with the 21041 driver, with some i/o errors; I'm still trying to find where these are coming from. It's a .03% error rate so I'm not worried :) Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major From owner-freebsd-hackers Fri Feb 14 12:00:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA28031 for hackers-outgoing; Fri, 14 Feb 1997 12:00:04 -0800 (PST) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA27972 for ; Fri, 14 Feb 1997 11:59:54 -0800 (PST) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.5/8.7.3) with SMTP id LAA08612 for ; Fri, 14 Feb 1997 11:59:47 -0800 (PST) Date: Fri, 14 Feb 1997 11:59:46 -0800 (PST) From: Jaye Mathisen To: hackers@freebsd.org Subject: CVS question, sendmail, named Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Might as well whack out a bunch of them in 1 message... My understanding is that for whatever reason, sendmail 8.8.5 is in -current, but hasn't been tagged for RELENG_2_2. So how do I tag my CVS repository locally so that the sendmail from -current is in my local RELENG_2_2, such that if I check out a tree with tags RELENG_2_2, I get the sendmail 8.8.5? If I then update my CVS tree, will it get overwritten with the 8.8.4 stuff? Also, is anybody using bind-4.9.5-P1 on a box? Is this in -current? If so, I'd like to do the same thing to it as sendmail 8.8.5. (bring it into -GAMMA/RELENG_2_2). Is there any reason 8.8.5 isn't tagged into RELENG_2_2? From owner-freebsd-hackers Fri Feb 14 13:29:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA02335 for hackers-outgoing; Fri, 14 Feb 1997 13:29:58 -0800 (PST) Received: from pat.idt.unit.no (0@pat.idt.unit.no [129.241.103.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA02330 for ; Fri, 14 Feb 1997 13:29:55 -0800 (PST) Received: from idt.unit.no (27959@vier.idt.ntnu.no [129.241.103.4]) by pat.idt.unit.no (8.8.5/8.8.5) with ESMTP id WAA03375; Fri, 14 Feb 1997 22:29:37 +0100 (MET) Message-Id: <199702142129.WAA03375@pat.idt.unit.no> To: eivind@dimaga.com Cc: hackers@freebsd.org Subject: Re: NULL as ((void*)0) (was Re: strlen() question) In-Reply-To: Your message of "Fri, 14 Feb 1997 17:36:53 +0100" References: <3.0.32.19970214173652.00c0b290@dimaga.com> X-Mailer: Mew version 1.06 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 14 Feb 1997 22:29:37 +0100 From: "Arne H. Juul" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I hereby propose changing the default declaration of NULL under FreeBSD from > #define NULL 0 > to > #define NULL ((void*)0) > for better type-safety and ease of transition to other architechtures > (e.g. Alpha). This will probably save us from a quite a few varargs-voes, > as well as generally making sure the code-base is using NULL correctly, > which is important for those reading source-code. This *shouldn't* help. If it does, the code is broken. All code should do the right thing with varargs; if having NULL be plain 0 breaks it, so much the better :-) Broken code should be found and fixed, not nurtured. Ideally one should define NULL to plain 0 sometimes, to (void *)0 sometimes, and to (1-1) (or some other bizarre but legal option) sometimes, just to find bugs in the source tree. Just IMHO, - Arne H. J. From owner-freebsd-hackers Fri Feb 14 13:43:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA03112 for hackers-outgoing; Fri, 14 Feb 1997 13:43:50 -0800 (PST) Received: from rnd.border.com (elgreco.border.com [199.71.190.101]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA03090 for ; Fri, 14 Feb 1997 13:43:43 -0800 (PST) Received: from rafael.rnd.border.com ([192.168.132.5]) by elgreco.rnd.border.com with SMTP id <11649>; Fri, 14 Feb 1997 16:43:45 -0500 Received: from localhost.border.com by rafael.rnd.border.com (SMI-8.6/SMI-SVR4) id QAA01261; Fri, 14 Feb 1997 16:43:12 -0500 Message-Id: <199702142143.QAA01261@rafael.rnd.border.com> X-Mailer: exmh version 1.6.7 5/3/96 To: FreeBSD-hackers@Freebsd.org Subject: NAT Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Feb 1997 16:43:11 -0500 From: Jerry Kendall Sender: owner-hackers@Freebsd.org X-Loop: FreeBSD.org Precedence: bulk Does anybody have some Network Address Translation code working in the FreeBSD 2.1.x arena ???? -- Jerry Kendall | Senior Systems Developer, BorderWare Firewall Server jerry@border.com | Secure Computing Canada Ltd. +1 416 813 2052 (Tel) | 100 University Avenue. Suite 700 +1 416 813 2001 (Fax) | Toronto, Ontario M5J 1V6 CANADA From owner-freebsd-hackers Fri Feb 14 14:35:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA06311 for hackers-outgoing; Fri, 14 Feb 1997 14:35:10 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA06301 for ; Fri, 14 Feb 1997 14:35:02 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA06785; Fri, 14 Feb 1997 23:34:53 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id XAA12013; Fri, 14 Feb 1997 23:29:49 +0100 (MET) Message-ID: Date: Fri, 14 Feb 1997 23:29:48 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: dwhite@resnet.uoregon.edu (Doug White) Cc: hackers@freebsd.org Subject: Re: mfs & swap relationship References: X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Doug White on Feb 13, 1997 22:40:55 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Doug White wrote: > What's significant about mounting mfs's on the same partition as > a system swap partition? The mount_mfs(8) man page hints that this > partition is used for any spillover, but that doesn't make sense. Why > isolate it to a specific swap partition? It's not isolated, the entire swap is used to back the MFS. The only reason to prefer the swap partition is that this device node is used to `template' the UFS parameters from. Basically a moot point these days, now that we aren't using most of UFS's optimizations anymore. > And can you make an mfs that's attached to a different partition? Of course. It's only a little hard to mount a MFS on a machine that doesn't have any disk available at all. I've got patches in the queue that allow using /dev/null as a template (in which case mount_mfs invents some parameters, which is about the best it could do at all in case swapping goes over NFS). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Fri Feb 14 14:56:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA07884 for hackers-outgoing; Fri, 14 Feb 1997 14:56:37 -0800 (PST) Received: from plains.nodak.edu (tinguely@plains.NoDak.edu [134.129.111.64]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA07869 for ; Fri, 14 Feb 1997 14:56:23 -0800 (PST) Received: (from tinguely@localhost) by plains.nodak.edu (8.8.4/8.8.3) id QAA00188; Fri, 14 Feb 1997 16:55:56 -0600 (CST) Date: Fri, 14 Feb 1997 16:55:56 -0600 (CST) From: Mark Tinguely Message-Id: <199702142255.QAA00188@plains.nodak.edu> To: FreeBSD-hackers@freebsd.org, jerry@rafael.rnd.border.com Subject: Re: NAT Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Does anybody have some Network Address Translation code working > in the FreeBSD 2.1.x arena ???? there is two ways of doing NAT. the user ppp has added NAT. see: http://www.srv.net/~cmott/alias.html the IP Filter can configure NAT to any IP interface, but you need to add proxies for services like ftp. see: http://coombs.anu.edu.au/~avalon/ --mark. From owner-freebsd-hackers Fri Feb 14 14:57:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA07953 for hackers-outgoing; Fri, 14 Feb 1997 14:57:25 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA07946 for ; Fri, 14 Feb 1997 14:57:21 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id XAA17033; Fri, 14 Feb 1997 23:55:55 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id XAA18696; Fri, 14 Feb 1997 23:46:20 +0100 (MET) Message-Id: <3.0.32.19970214234620.00b72540@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 14 Feb 1997 23:46:22 +0100 To: "Arne H. Juul" From: Eivind Eklund Subject: Re: NULL as ((void*)0) (was Re: strlen() question) Cc: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 10:29 PM 2/14/97 +0100, Arne H. Juul wrote: >[Eivind Eklund] >> I hereby propose changing the default declaration of NULL under FreeBSD from >> #define NULL 0 >> to >> #define NULL ((void*)0) >> for better type-safety and ease of transition to other architechtures >> (e.g. Alpha). This will probably save us from a quite a few varargs-voes, >> as well as generally making sure the code-base is using NULL correctly, >> which is important for those reading source-code. > >This *shouldn't* help. If it does, the code is broken. >All code should do the right thing with varargs; if having NULL be >plain 0 breaks it, so much the better :-) Broken code should be >found and fixed, not nurtured. We presently cannot find it; and finding it all on the Alpha port could be pretty ugly. Besides, changing it to ((void*)0) will find as much broken code as we can, fix that, and make the other closer to harmless. (It will break only on architectures where different pointers have different internal structure, which are becoming rare.) I still say we should go for it. >Ideally one should define NULL to plain 0 sometimes, to >(void *)0 sometimes, and to (1-1) (or some other bizarre but >legal option) sometimes, just to find bugs in the source tree. Would be nice if there are some legal but bizarre options - unfortuneatly, there isn't ((1-1) is illegal - integer type). The following two (with possibly added parantheses) are all there is: #define NULL 0 #define NULL ((void*)0) If I remember correctly, NULL should reduce to a single token - then stripping parantheses from the second expression is technically incorrect. (This might be an inconsistency in the standard - it does not seem to be possible to produce a statement that give an error without parantheses but work with. However, the grammar conflict will come at different points.) Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/ eivind@freebsd.org From owner-freebsd-hackers Fri Feb 14 14:58:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA08069 for hackers-outgoing; Fri, 14 Feb 1997 14:58:46 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA08056 for ; Fri, 14 Feb 1997 14:58:40 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id XAA17040; Fri, 14 Feb 1997 23:56:07 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id XAA18747; Fri, 14 Feb 1997 23:53:13 +0100 (MET) Message-Id: <3.0.32.19970214235313.00bbc730@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 14 Feb 1997 23:53:15 +0100 To: Jerry Kendall From: Eivind Eklund Subject: Re: NAT Cc: FreeBSD-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk At 04:43 PM 2/14/97 -0500, Jerry Kendall wrote: > >Does anybody have some Network Address Translation code working >in the FreeBSD 2.1.x arena ???? http://www.srv.net/~cmott/ for PPP+pktAlias Darren Reed also has NAT support in IPFilter. Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/ eivind@freebsd.org From owner-freebsd-hackers Fri Feb 14 15:10:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA08876 for hackers-outgoing; Fri, 14 Feb 1997 15:10:59 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA08867 for ; Fri, 14 Feb 1997 15:10:54 -0800 (PST) Received: from darkstar (ras539.srv.net [205.180.127.39]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id PAA12172 for ; Fri, 14 Feb 1997 15:10:32 -0800 (PST) Received: (from cmott@localhost) by darkstar (8.6.12/8.6.12) id QAA08678; Fri, 14 Feb 1997 16:08:40 -0700 Date: Fri, 14 Feb 1997 16:08:39 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar To: Jerry Kendall cc: FreeBSD-hackers@freebsd.org Subject: Re: NAT In-Reply-To: <199702142143.QAA01261@rafael.rnd.border.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Just for user ppp. The more generalized natd needs the divert socket mechanism. There is also some Darren Reed software (ip-filter?) that I don't know too much about. On Fri, 14 Feb 1997, Jerry Kendall wrote: > > Does anybody have some Network Address Translation code working > in the FreeBSD 2.1.x arena ???? > > > > -- > Jerry Kendall | Senior Systems Developer, BorderWare Firewall Server > jerry@border.com | Secure Computing Canada Ltd. > +1 416 813 2052 (Tel) | 100 University Avenue. Suite 700 > +1 416 813 2001 (Fax) | Toronto, Ontario M5J 1V6 CANADA > > > From owner-freebsd-hackers Fri Feb 14 15:22:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA10137 for hackers-outgoing; Fri, 14 Feb 1997 15:22:53 -0800 (PST) Received: from perki0.connect.com.au (perki0.connect.com.au [192.189.54.85]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA10097 for ; Fri, 14 Feb 1997 15:22:45 -0800 (PST) Received: from nemeton.UUCP (Unemeton@localhost) by perki0.connect.com.au with UUCP id KAA28150 (8.7.6h/IDA-1.6); Sat, 15 Feb 1997 10:18:39 +1100 (EST) X-Authentication-Warning: perki0.connect.com.au: Unemeton set sender to giles@nemeton.com.au using -f Received: from localhost.nemeton.com.au (localhost.nemeton.com.au [127.0.0.1]) by nemeton.com.au (8.8.5/8.8.5) with SMTP id KAA12738; Sat, 15 Feb 1997 10:17:23 +1100 (EST) Message-Id: <199702142317.KAA12738@nemeton.com.au> To: Eivind Eklund cc: hackers@freebsd.org Subject: Re: NULL as ((void*)0) (was Re: strlen() question) In-reply-to: <3.0.32.19970214173652.00c0b290@dimaga.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <12731.855962183.0@nemeton.com.au> Date: Sat, 15 Feb 1997 10:17:23 +1100 From: Giles Lean Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12731.855962183.1@nemeton.com.au> On Fri, 14 Feb 1997 17:36:53 +0100 Eivind Eklund wrote: > I hereby propose changing the default declaration of NULL under FreeBSD from > #define NULL 0 > to > #define NULL ((void*)0) This is more of a kludge than a good idea, and I offer the following sage advice that I filed away many years ago. Regards, Giles ------- =_aaaaaaaaaa0 MIME-Version: 1.0 Content-Type: message/rfc822 >From rsalz@bbn.com Tue Nov 7 09:35:09 1989 Relay-Version: version Notes 2.8.2 87/11/24; site hpausla.aso.hp.com From: rsalz@bbn.com (Rich Salz) Date: Mon, 6 Nov 1989 22:35:09 GMT Date-Received: Tue, 7 Nov 1989 13:37:34 GMT Subject: Re: NULL Message-ID: <2144@prune.bbn.com> Organization: BBN Systems and Technologies Corporation Path: hpausla!hpcuhc!hpda!hplabs!hp-sdd!ucsdhub!sdcsvax!network.ucsd.edu!ucsd!tut.cis.ohio-state.edu!ukma!mailrus!bbn!bbn.com!rsalz Newsgroups: comp.os.minix References: <4455@ast.cs.vu.nl> Lines: 99 (This is part two of the set-up. Andy and I have exchanged email about this.) I believe that if you have anything other than "#define NULL 0" you are encouraging sloppy non-portable code. Yes, casting 0 all the time is a pain, but c'est la vie. Function prototypes help. When it comes to this topic, Chris Torek is one of the many people who are smarter than I am who are also better writers. I'll let his old words try to convince people: >From bbn.com!bbn!mit-eddie!ll-xn!ames!umd5!mimsy!chris Thu Mar 10 15:37:10 EST 1988 Article 5474 of comp.lang.c: Path: bbn.com!bbn!mit-eddie!ll-xn!ames!umd5!mimsy!chris >From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.lang.c Subject: Why NULL is 0 Summary: you have seen this before, but this one is for reference Message-ID: <10576@mimsy.UUCP> Date: 9 Mar 88 02:26:10 GMT References: <2550049@hpisod2.HP.COM> <7412@brl-smoke.ARPA> <3351@chinet.UUCP> <10574@mimsy.UUCP> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 73 (You may wish to save this, keeping it handy to show to anyone who claims `#define NULL 0 is wrong, it should be #define NULL '. I intend to do so, at any rate.) Let us begin by postulating the existence of a machine and a compiler for that machine. This machine, which I will call a `Prime', or sometimes `PR1ME', for obscure reasons such as the fact that it exists, has two kinds of pointers. `Character pointers', or objects of type (char *), are 48 bits wide. All other pointers, such as (int *) and (double *), are 32 bits wide. Now suppose we have the following C code: main() { f1(NULL); /* wrong */ f2(NULL); /* wrong */ exit(0); } f1(cp) char *cp; { if (cp != NULL) *cp = 'a'; } f2(dp) double *dp; { if (dp != NULL) *dp = 2.2; } There are two lines marked `wrong'. Now suppose we were to define NULL as 0. Clearly both calls are then wrong: both pass `(int)0', when the first should be a 48 bit (char *) nil pointer and the second a 32 bit (double *) nil pointer. Someone claims we can fix that by defining NULL as (char *)0. Suppose we do. Then the first call is correct, but the second now passes a 48 bit (char *) nil pointer instead of a 32 bit (double *) nil pointer. So much for that solution. Ah, I hear another. We should define NULL as (void *)0. Suppose we do. Then at least one call is not correct, because one should pass a 32 bit value and one a 48 bit value. If (void *) is 48 bits, the second is wrong; if it is 32 bits, the first is wrong. Obviously there is no solution. Or is there? Suppose we change the calls themselves, rather than the definition of NULL: main() { f1((char *)0); f2((double *)0); exit(0); } Now both calls are correct, because the first passes a 48 bit (char *) nil pointer, and the second a 32 bit (double *) nil pointer. And if we define NULL with #define NULL 0 we can then replace the two `0's with `NULL's: main() { f1((char *)NULL); f2((double *)NULL); exit(0); } The preprocessor changes both NULLs to 0s, and the code remains correct. On a machine such as the hypothetical `Prime', there is no single definition of NULL that will make uncasted, un-prototyped arguments correct in all cases. The C language provides a reasonable means of making the arguments correct, but it is not via `#define'. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out. ------- =_aaaaaaaaaa0 MIME-Version: 1.0 Content-Type: message/rfc822 >From henry@utzoo.uucp Wed Nov 8 05:35:40 1989 Relay-Version: version Notes 2.8.2 87/11/24; site hpausla.aso.hp.com From: henry@utzoo.uucp (Henry Spencer) Date: Tue, 7 Nov 1989 18:35:40 GMT Date-Received: Thu, 9 Nov 1989 06:24:45 GMT Subject: Re: NULL Message-ID: <1989Nov7.183540.2486@utzoo.uucp> Organization: U of Toronto Zoology Path: hpausla!hpcuhc!hpda!motcsd!apple!usc!cs.utexas.edu!wuarchive!mailrus!jarvis.csri.toronto.edu!utgpu!utzoo!henry Newsgroups: comp.os.minix References: <4455@ast.cs.vu.nl> <2144@prune.bbn.com> Lines: 30 In article <2144@prune.bbn.com> rsalz@bbn.com (Rich Salz) writes: >I believe that if you have anything other than "#define NULL 0" you >are encouraging sloppy non-portable code... Unfortunately, there is a lot of sloppy non-portable code out there already, and it is desirable to minimize code breakage where possible. This is why ANSI C allows NULL to be any integer constant expression equal to zero (e.g. `0' or `0L') or the same cast to `void *' (e.g. `((void *)0)': so that you can pick one that is the same size as the pointers on your machine, to minimize breakage of badly-written code. (The rationale for allowing the `void *' cast is that there may not be an integer type the same size as the pointers.) Of course, if different pointers are different sizes, or the representation of null pointers is strange, you are well and truly up the creek and there is *no* definition that will avoid breakage. Note that casting the zero to any *other* pointer type is illegal and pointless. (Although all manner of fudging may be necessary in the presence of non-ANSI compilers.) In any case, this stuff is a concession to badly-written code. No properly-written code under ANSI compilers will notice the difference between the different forms of NULL. In contexts where the desired type is not known from context -- basically, function arguments in the absence of a prototype or the presence of varargs -- NULL *must* be cast to the proper pointer type. Lazy programmers keep looking for a way around this, but there simply *isn't any*. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu ------- =_aaaaaaaaaa0-- From owner-freebsd-hackers Fri Feb 14 15:50:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA12006 for hackers-outgoing; Fri, 14 Feb 1997 15:50:42 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA11998 for ; Fri, 14 Feb 1997 15:50:36 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA08044 for hackers@FreeBSD.ORG; Sat, 15 Feb 1997 00:50:30 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id AAA12291; Sat, 15 Feb 1997 00:26:27 +0100 (MET) Message-ID: Date: Sat, 15 Feb 1997 00:26:27 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: NULL as ((void*)0) (was Re: strlen() question) References: <3.0.32.19970214173652.00c0b290@dimaga.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <3.0.32.19970214173652.00c0b290@dimaga.com>; from Eivind Eklund on Feb 14, 1997 17:36:53 +0100 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Eivind Eklund wrote: > I hereby propose changing the default declaration of NULL under FreeBSD from > #define NULL 0 > to > #define NULL ((void*)0) > for better type-safety and ease of transition to other architechtures > (e.g. Alpha). This will probably save us from a quite a few varargs-voes, > as well as generally making sure the code-base is using NULL correctly, > which is important for those reading source-code. Nope, it wouldn't get you anywhere. The vararg-woes cannot be solved by it either, since you gotta cast to the exact type in any case anyway. Passing (void *)0 into a vararg list is as invalid as passing 0 there if the target type is e.g. char *. It wouldn't ensure the code base is using NULL everywhere either, since assigning 0 to a pointer is valid (and sometimes [e.g. GNU] even encouraged) C code. Inside a function call, you only need to cast it into the correct target type if: 1) it's in a vararg list, or 2) it's in an arg list of a function declared with obsolete K&R style only. See also the comp.lang.c FAQ. The only reason to use NULL is to make it more obvious to the reader that you're thinking of a pointer context. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Fri Feb 14 15:51:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA12053 for hackers-outgoing; Fri, 14 Feb 1997 15:51:27 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA12036 for ; Fri, 14 Feb 1997 15:51:07 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA08075; Sat, 15 Feb 1997 00:50:58 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id AAA12318; Sat, 15 Feb 1997 00:39:35 +0100 (MET) Message-ID: Date: Sat, 15 Feb 1997 00:39:35 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: mrcpu@cdsnet.net (Jaye Mathisen) Cc: hackers@freebsd.org Subject: Re: CVS question, sendmail, named References: X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Jaye Mathisen on Feb 14, 1997 11:59:46 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Jaye Mathisen wrote: > So how do I tag my CVS repository locally so that the sendmail from > -current is in my local RELENG_2_2, such that if I check out a tree > with tags RELENG_2_2, I get the sendmail 8.8.5? If I then update my > CVS tree, will it get overwritten with the 8.8.4 stuff? You probably don't wanna tag your CVS repository, since it will modify the CVS files, so your next CVSup will `correct' the files again. What you wanna do is to just ``cvs update -A'' your sendmail subtree, to get it up to -current level. (You gotta use an explicit -r option if you later wanna revert it.) > Is there any reason 8.8.5 isn't tagged into RELENG_2_2? Since nobody did it yet. Our most favorite sendmail committer, Peter Wemm, still suffers from moving house recently... -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Fri Feb 14 16:25:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA14421 for hackers-outgoing; Fri, 14 Feb 1997 16:25:38 -0800 (PST) Received: from shell.monmouth.com (pechter@shell.monmouth.com [205.164.220.9]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA14327; Fri, 14 Feb 1997 16:25:25 -0800 (PST) Received: (from pechter@localhost) by shell.monmouth.com (8.8.4/8.7.3) id TAA14132; Fri, 14 Feb 1997 19:24:47 -0500 (EST) From: Bill/Carolyn Pechter Message-Id: <199702150024.TAA14132@shell.monmouth.com> Subject: pcvt/132 columns To: FreeBSD-hackers@freebsd.org (FreeBSD-hackers) Date: Fri, 14 Feb 1997 19:24:47 -0500 (EST) Cc: FreeBSD-current@freebsd.org (FreeBSD-current) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I don't know if this is the right place -- but I'll put it out to all takers. I've got an STB Lightspeed card (ET4000-W32p) running on 2.2-GAMMA with XFree86's XF86_W32 server. The card works nicely (actually, I was getting wierd problems with the S3Trio64v and this seems more stable in this machine). Anyway, I'm running PCVT and I found the card now does 132 column (NEAT!) vt100 emulation. The pcvt code talks about ET400 - but not the W32p so it may just be an accident it works. However, once I run X -- the sync rate is screwed up and 132 is no good. Anyone seen this or have recommendations. I know the pcvt for FreeBSD 2.2 is different than the pcvt-3.32.tar.gz I've got -- anyone know if this is fixed in a newer version than 3.20-b24 that's in 2.2-GAMMA. I'd love both X and 132 columns without a reboot. Bill +---------------------------------------------------------------------------+ | Bill/Carolyn Pechter | 17 Meredith Drive | Tinton Falls, New Jersey 07724 | | 908-389-3592 | Save computing history, give an old geek old hardware. | | pechter@shell.monmouth.com | +---------------------------------------------------------------------------+ | This message brought to you by the letters PDP and the number 11. | +---------------------------------------------------------------------------+ From owner-freebsd-hackers Fri Feb 14 16:36:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA15512 for hackers-outgoing; Fri, 14 Feb 1997 16:36:29 -0800 (PST) Received: from odin.visigenic.com (odin.visigenic.com [204.179.98.2]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA15505 for ; Fri, 14 Feb 1997 16:36:26 -0800 (PST) Received: from VSI48 (vsi48.visigenic.com [206.64.15.185]) by odin.visigenic.com (Netscape Mail Server v2.02) with SMTP id AAA3804; Fri, 14 Feb 1997 16:33:40 -0800 Message-Id: <3.0.32.19970214163630.0090cd60@visigenic.com> X-Sender: toneil@visigenic.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 14 Feb 1997 16:36:32 -0800 To: Giles Lean From: "Tim Oneil" Subject: Re: NULL as ((void*)0) (was Re: strlen() question) Cc: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 10:17 AM 2/15/97 +1100, you wrote: >On Fri, 14 Feb 1997 17:36:53 +0100 Eivind Eklund wrote: > >> I hereby propose changing the default declaration of NULL under FreeBSD from >> #define NULL 0 >> to >> #define NULL ((void*)0) > >This is more of a kludge than a good idea, and I offer the following >sage advice that I filed away many years ago. [wisdom snip'd] Giles; Excellent little bit of advice-like prose. I will indeed file this one. Thanks. -Tim From owner-freebsd-hackers Fri Feb 14 16:37:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA15620 for hackers-outgoing; Fri, 14 Feb 1997 16:37:52 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA15600; Fri, 14 Feb 1997 16:37:47 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.5/8.8.4) with SMTP id QAA16425; Fri, 14 Feb 1997 16:29:25 -0800 (PST) Message-ID: <330502EF.1CFBAE39@whistle.com> Date: Fri, 14 Feb 1997 16:27:28 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Simon Shapiro CC: freebsd-hackers@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: Software Interrupts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro wrote: > > I have dug into the software interrupts a bit and would like to confirm the > best approach. > > Problem Description: > > I would like to trigger an interrupt, from within a device driver. The > reason for doing so (may not be so good :-): > I would like to de-couple queueing SCSI commands from the calling layer on > one side and results analysis and error handling from the interrupt handler > on the other side. There is already support for this.. this is what the filesystem code does.. check out the files in kern/vfs_bio.c especially look at biodone() if you fill ou the b_iodone entry in the buf struct then it will call whatever routine you want on completion.. check the output() strategy() code for sd.c and the adapter to understand how your routine may return after having queueud the data. > > Let me be more specific: when the SCSI code calls my driver's xxx_scsi_cmd > entry point, I take the command, tweak it to the hardware vendor's content, > put the request in a queue. At this point i would like to evoke an > interrupt and return QUEUED_SUCCESSFULLY. The interrupt routine then will > go to the queue and negotiate with the device all these wonderful inb, > outb and such. The calling process is not bound by hardware delays. > > When a hardware interrupt, from the HBA, occurs, I want to be able to, > in the interrupt service routine to just capture the hardware state (it > takes only two inb's (can be reduced to one) one indirect dereferencing > and a 24 bytes bcopy) into the request's CCB, move the request to the > ``complete'' queue, schedule a software interrupt and schedule another > software interrupt. This one will process however many requests there are > in the ``completed'' queue. In this fasion, the interrupt routine will > remain very short, consume very little time. The device we are interfacing > to can give us SCSI command completion in less than 1ms. Much less in > fact. Usually, what you do is: get the old command status.. load teh next command process the old status.. > > Now, if you nice people know of a better way (than software interrupts) > to do this, i will be happy to hear about it. > > Just as an intelectual excercise, please help me understand the software > interrupts business. > > I have noticed that the Inet code that uses them, boils down to calling > setbits (an inline defined in i386/include/cpufunc.h). Setbits takes > the address of an unsigned and a u_int called bits. > > Different purposes in the kernel call setbits with different arguments. > The argument is always the address of either ipending or of idelayed. > > These appear to be global bitmaps describing which interrupts are pending > or delayed. > > What I cannot find is how to register a software interrupt. They appear, > as if by magic. look for schednetisr() software interrupts are run if there is anything scheduked for them when the SPL is set back to 0. > > So, after all this, i am asking for a way to schedule two software > interrupts. I really do not care what arguments will be passed to these > functions, what value they return, or what. Just so they get invoked > at some known priority, without fighting for CPU with the splbio guys. unless you duplicate teh splnet cade, you will end up running at the networking spl.. which may or may not be what you wanted.. > > At the context of a true SMP machine, this scheme makes even more sense. > But it may improve our responsiveness quite a bit, at some cost of > increased overhead. the old game of latency vs. throughput. > > Thanx a million. > > Simon From owner-freebsd-hackers Fri Feb 14 16:50:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA16797 for hackers-outgoing; Fri, 14 Feb 1997 16:50:39 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA16791 for ; Fri, 14 Feb 1997 16:50:36 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA05493; Fri, 14 Feb 1997 19:50:04 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Fri, 14 Feb 1997 19:50 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id TAA20097; Fri, 14 Feb 1997 19:39:41 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id TAA12014; Fri, 14 Feb 1997 19:44:22 -0500 (EST) Date: Fri, 14 Feb 1997 19:44:22 -0500 (EST) From: Thomas David Rivers Message-Id: <199702150044.TAA12014@lakes.water.net> To: ponds!dimaga.com!eivind, ponds!lambert.org!terry Subject: Re: NULL as ((void*)0) (was Re: strlen() question) Cc: ponds!freebsd.org!hackers, ponds!uriah.heep.sax.de!joerg_wunsch Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I hereby propose changing the default declaration of NULL under FreeBSD from > #define NULL 0 > to > #define NULL ((void*)0) > for better type-safety and ease of transition to other architechtures > (e.g. Alpha). This will probably save us from a quite a few varargs-voes, > as well as generally making sure the code-base is using NULL correctly, > which is important for those reading source-code. Unfortunately, because of C++'s tighter type model; this will make valid C++ programs un-compilable. For example, you won't be able to say: char *p; if( p == NULL) in C++ (with a truly ANSI (draft) conforming C++ compiler) as void * is not convertable to a char *. But, the integer constant 0 is comparable with any pointer. The best definition for NULL is as it is, 0. Now, I was wondering just where it would save varargs problems? Can you elaborate? - Dave Rivers - > > At 03:52 PM 2/13/97 -0700, Terry Lambert wrote: > >> > > | style(9) - Kernel source file style guide > >> > > >> > See, there's the problem: libc is a user space library, not > >> > a kernel source file. > >> > >> But that wasn't what you claimed being your original problem, right? > >> I wonder when you ever admit being wrong for the first time... > > > >I said that strlen() took a NULL terminated string. I corrected > >it to 0 terminated string to make the nit-pickers happy. "NUL" > >with one "L" is the invention of a Pascal programmer with nothing > >better to do than to make noises about sign-extension on non-two's > >complement hardware for type demotion of 0 to character. > > NULL is not equvalient to null or 0 or NUL. What you're talking about is > best called a null-terminated string, as this is what it is. If you have a > Pasacal or Lisp reference handy, you can look up nil - nil in Pascal/Lisp > is the same as all uppercase NULL in C. > (I'm not doing this _only_ to pick a nit - I'm doing it because it is > somewhat that is important both for semantic understanding and for > portability.) > > > Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/ > eivind@freebsd.org > > From owner-freebsd-hackers Fri Feb 14 17:15:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA17850 for hackers-outgoing; Fri, 14 Feb 1997 17:15:51 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA17838 for ; Fri, 14 Feb 1997 17:15:45 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id CAA18492; Sat, 15 Feb 1997 02:13:26 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id BAA19601; Sat, 15 Feb 1997 01:48:56 +0100 (MET) Message-Id: <3.0.32.19970215014856.00c14100@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 15 Feb 1997 01:48:58 +0100 To: Giles Lean From: Eivind Eklund Subject: Re: NULL as ((void*)0) (was Re: strlen() question) Cc: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 10:17 AM 2/15/97 +1100, Giles Lean wrote: >On Fri, 14 Feb 1997 17:36:53 +0100 Eivind Eklund wrote: > >> I hereby propose changing the default declaration of NULL under FreeBSD from >> #define NULL 0 >> to >> #define NULL ((void*)0) > >This is more of a kludge than a good idea, and I offer the following >sage advice that I filed away many years ago. Which I throughly agree with; it also come from people I defineatly respect. However, I don't feel that it disagree with the above proposition. [From Henry Spencer, of "10 commandments for C programmers" and regexp fame] >In any case, this stuff is a concession to badly-written code. No >properly-written code under ANSI compilers will notice the difference >between the different forms of NULL. In contexts where the desired >type is not known from context -- basically, function arguments in >the absence of a prototype or the presence of varargs -- NULL *must* >be cast to the proper pointer type. Having NULL ((void*)0) is a combination of a concession to badly written code (it makes it work on more machines, though not all) as well as a way of forcing people to avoid using NULL in non-pointer expressions. IMHO, a good thing. (If nobody else feel the same way I won't make any cahnges, of course.) BTW: I just got another idea - if we can turn the definition of NULL between ((void*)0) and 0 we can detect if NULL is abused if compiling on a machine with different sizeof(void*) and sizeof(int). If used correctly, code will be equal no matter what the definition - if used incorrectly, different code should result. This can provide fairly automatic detection of errors, provided we have two different builds. Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/ eivind@freebsd.org From owner-freebsd-hackers Fri Feb 14 18:04:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA19920 for hackers-outgoing; Fri, 14 Feb 1997 18:04:12 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA19883 for ; Fri, 14 Feb 1997 18:04:05 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id SAA12675 for ; Fri, 14 Feb 1997 18:05:38 -0800 (PST) Received: (qmail 1699 invoked by uid 110); 15 Feb 1997 02:03:45 -0000 Message-ID: <19970215020345.1698.qmail@suburbia.net> Subject: Re: pcvt/132 columns In-Reply-To: <199702150024.TAA14132@shell.monmouth.com> from Bill/Carolyn Pechter at "Feb 14, 97 07:24:47 pm" To: pechter@shell.monmouth.com (Bill/Carolyn Pechter) Date: Sat, 15 Feb 1997 13:03:45 +1100 (EST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Anyone seen this or have recommendations. I know the pcvt for FreeBSD > 2.2 is different than the pcvt-3.32.tar.gz I've got -- anyone know if this > is fixed in a newer version than 3.20-b24 that's in 2.2-GAMMA. > I'd love both X and 132 columns without a reboot. You can use my syscons SVGAtext mode patch that will allow you to do just about any text resolution, on an ET4000 I've had it running at 170x60 (with a 16x8 bit font) on a 22" monitor. Why this patch isn't in the standard distribution is a good question. -- Prof. Julian Assange |If you want to build a ship, don't drum up people |together to collect wood and don't assign them tasks proff@iq.org |and work, but rather teach them to long for the endless proff@gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery From owner-freebsd-hackers Fri Feb 14 18:05:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA20006 for hackers-outgoing; Fri, 14 Feb 1997 18:05:45 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA19995 for ; Fri, 14 Feb 1997 18:05:39 -0800 (PST) Received: (from jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) id SAA20599; Fri, 14 Feb 1997 18:05:37 -0800 (PST) To: freebsd-hackers@freebsd.org Path: not-for-mail From: jdp@polstra.com (John Polstra) Newsgroups: polstra.freebsd.hackers Subject: Re: CVS question, sendmail, named Date: 14 Feb 1997 18:05:36 -0800 Organization: Polstra & Co., Seattle, WA Lines: 66 Distribution: local Message-ID: <5e35lg$k3k@austin.polstra.com> References: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article , Jaye Mathisen wrote: > My understanding is that for whatever reason, sendmail 8.8.5 is in > -current, but hasn't been tagged for RELENG_2_2. > > So how do I tag my CVS repository locally so that the sendmail from > -current is in my local RELENG_2_2, such that if I check out a tree > with tags RELENG_2_2, I get the sendmail 8.8.5? If I then update my > CVS tree, will it get overwritten with the 8.8.4 stuff? Joerg already answered this. But it's a confusing topic, so I'm sure he won't mind if I give you more of a step-by-step answer. The first time you check out your tree (from scratch), do this: cd /usr cvs co -P -r RELENG_2_2 src Your whole tree is now at -2.2. Now to switch your sendmail to the -current version: cd /usr/src/usr.sbin/sendmail cvs update -APd In the future when you want to do updates: cd /usr/src cvs update -Pd Important: Do not specify the "-r", "-D", or "-A" flag. Your sticky tags are already set up such that your sendmail will be updated from -current, and the rest of your tree will be updated from -2.2. In the future if you decide you want to update your whole tree to -current: cd /usr/src cvs update -APd Or, if you want to revert your sendmail to the -2.2 version: cd /usr/src/usr.sbin/sendmail cvs update -Pd -r RELENG_2_2 The general rules of thumb: * Only use "cvs checkout" the first time, when you're building the tree from scratch. After that, always use "cvs update". * Don't use "-r " or "-D " or "-A" with "cvs update", except when you want to _change_ the version/branch that you're keeping in your tree. * Always use "-P" with checkout, and "-Pd" with update. * Be sure to brush after every meal. Oops, sorry about that last one. Wrong set of rules ... John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Fri Feb 14 18:18:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA20748 for hackers-outgoing; Fri, 14 Feb 1997 18:18:42 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA20743 for ; Fri, 14 Feb 1997 18:18:38 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id DAA19069 for hackers@FreeBSD.ORG; Sat, 15 Feb 1997 03:17:15 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id CAA20267 for ; Sat, 15 Feb 1997 02:55:06 +0100 (MET) Message-Id: <3.0.32.19970215025505.00c3f100@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 15 Feb 1997 02:55:07 +0100 To: hackers@FreeBSD.ORG (Joerg Wunsch) From: Eivind Eklund Subject: Re: NULL as ((void*)0) (was Re: strlen() question) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 12:26 AM 2/15/97 +0100, J Wunsch wrote: >As Eivind Eklund wrote: > >> I hereby propose changing the default declaration of NULL under FreeBSD from >> #define NULL 0 >> to >> #define NULL ((void*)0) >> for better type-safety and ease of transition to other architechtures >> (e.g. Alpha). This will probably save us from a quite a few varargs-voes, >> as well as generally making sure the code-base is using NULL correctly, >> which is important for those reading source-code. > >Nope, it wouldn't get you anywhere. The vararg-woes cannot be solved >by it either, since you gotta cast to the exact type in any case >anyway. Passing (void *)0 into a vararg list is as invalid as passing >0 there if the target type is e.g. char *. It isn't invalid except at the virtual machine level - it invoke undefined behaviour. In many cases (e.g. FreeBSD today) even passing an uncasted 0 works. In all cases, a void* passed instead of a char* will work (I can dig up chapter and verse for this one - bad example :) Passing void* for eg int* involve undefined behaviour, though. But on 99% of todays available hardware (excluding eg Prime and older Crays) pointers to different typed objects have the same size and the same internal structure. For this case, it will work. And in no case will it work worse[1]. >It wouldn't ensure the code base is using NULL everywhere either, This wasn't what I was thinking of - quite the opposite. I was thinking of making sure the code base wasn't abusing NULL in a non-pointer context, and make programming environment somewhat more precise for beginners. >See also the comp.lang.c FAQ. I have done, repeatedly and at regular intervals. comp.std.c is also to be recommended for those wanting a nitpicker or compiler-writer view of C. >The only reason to use NULL is to make it more obvious to the reader >that you're thinking of a pointer context. Agreed. [1] There has come up one serious objection here, relating to C++. If this objection is correct, it mean that the proposal absolutely should be dropped. Besides, nobody but me seems to be in favour, and it isn't important to me, so... Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/ eivind@freebsd.org From owner-freebsd-hackers Fri Feb 14 18:18:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA20775 for hackers-outgoing; Fri, 14 Feb 1997 18:18:51 -0800 (PST) Received: (from jmacd@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA20769 for hackers; Fri, 14 Feb 1997 18:18:49 -0800 (PST) Date: Fri, 14 Feb 1997 18:18:49 -0800 (PST) From: Joshua Peck Macdonald Message-Id: <199702150218.SAA20769@freefall.freebsd.org> To: hackers Subject: bsd.kmod.mk Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Here are some useful improvements on bsd.kmod.mk. The unload rule was broken, the load rule now unloads first, ignoring any errors, and the KERN variable is overridable. They were useful in doing kernel module development recently. Is anyone interested in having these commited? -josh *** mk/bsd.kmod.mk Mon Jan 13 22:33:19 1997 --- bsd.kmod.mk Fri Feb 14 18:16:02 1997 *************** *** 195,210 **** .if !target(load) ! load: ${PROG} ${MODLOAD} -o ${KMOD} -e${KMOD} ${PROG} .endif .if !target(unload) unload: ${PROG} ! ${MODUNLOAD} -n ${KMOD} .endif ! KERN= ${.CURDIR}/../../sys/kern vnode_if.h: ${KERN}/vnode_if.sh ${KERN}/vnode_if.src sh ${KERN}/vnode_if.sh ${KERN}/vnode_if.src --- 195,210 ---- .if !target(load) ! load: unload ${PROG} ${MODLOAD} -o ${KMOD} -e${KMOD} ${PROG} .endif .if !target(unload) unload: ${PROG} ! -${MODUNLOAD} -n ${KMOD:_mod=} .endif ! KERN?= ${.CURDIR}/../../sys/kern vnode_if.h: ${KERN}/vnode_if.sh ${KERN}/vnode_if.src sh ${KERN}/vnode_if.sh ${KERN}/vnode_if.src From owner-freebsd-hackers Fri Feb 14 18:49:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA22355 for hackers-outgoing; Fri, 14 Feb 1997 18:49:26 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA22259; Fri, 14 Feb 1997 18:48:41 -0800 (PST) Message-Id: <199702150248.SAA22259@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA148424740; Sat, 15 Feb 1997 13:45:40 +1100 From: Darren Reed Subject: Re: undocumented kernel options... To: thorpej@nas.nasa.gov Date: Sat, 15 Feb 1997 13:45:40 +1100 (EDT) Cc: msmith@atrad.adelaide.edu.au, phk@critter.dk.tfs.com, leisner@sdsp.mc.xerox.com, bsdcur@shadows.aeon.net, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org In-Reply-To: <199702140807.AAA14402@lestat.nas.nasa.gov> from "Jason Thorpe" at Feb 14, 97 00:07:58 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Jason Thorpe, sie said: [...] > Documentation on how to edit a kernel configuration file is loads better > IMO than having a rigid GUI (so, you update config to deal with new syntax, > and how you have to update the GUI, as well...) (So, if you've ever used > HP's SAM, you'll understand just how frustrating using a GUI to configure > your kernel can be, if you've previously used "vi CONFIGNAME".) > > ...plus, the user can insert arbitrary, random options.... major win. If anyone was ever tempted to do anything like SAM, I'd make them use it for every system admin. task first and see of that changed their mind. (Yes, we edit the config files rather than use SAM). From owner-freebsd-hackers Fri Feb 14 18:50:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA22472 for hackers-outgoing; Fri, 14 Feb 1997 18:50:42 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA22464 for ; Fri, 14 Feb 1997 18:50:37 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA00767; Fri, 14 Feb 1997 21:50:05 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Fri, 14 Feb 1997 21:50 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id TAA20343; Fri, 14 Feb 1997 19:46:50 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id TAA12058; Fri, 14 Feb 1997 19:51:30 -0500 (EST) Date: Fri, 14 Feb 1997 19:51:30 -0500 (EST) From: Thomas David Rivers Message-Id: <199702150051.TAA12058@lakes.water.net> To: ponds!aris.jpl.nasa.gov!hamby, ponds!indiana.edu!jfieber Subject: Re: Sun Workshop compiler vs. GCC? Cc: ponds!FreeBSD.ORG!hackers Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jake Hamby writes: > > On the whole, I think we would be better off having people > > believe Sun's hype about Solaris than believing Microsoft's hype > > about NT. FreeBSD would have a much greater chance of > > successfully infiltrating a solaris environment than it would an > > NT environment. :) I like your taxonomy of OS's here; I just have one question... > > EXACTLY my belief! Us UNIX geeks have to stick together. Also, I firmly > believe that no one OS is good for all tasks. Personally, my choice for > OS's goes something like (in alphabetical order): > > BeOS: Probably the future OS for multimedia content developers, much as > the Amiga was in the '80s, except without Commodore's mismanagement. > > FreeBSD: The best OS for Internet servers and embedded UNIX boxes (like > an X terminal or that Interjet system). > > Linux: A good UNIX for non-TCP/IP related apps (like UUCP) ;) If FreeBSD is good to internet servers, etc... wouldn't it also be good for UUCP (especially since it has the same UUCP as Linux?) I'm just curious. I'd also add something that points to the fact that so many 3rd-party developers seem to be supporting it. > > MacOS: The OS for people we are trying to migrate to BeOS ;) > > NetBSD/OpenBSD: A valuable cousin of FreeBSD, and (on SPARC), a good > choice for people who don't want to move to Solaris, but can't stay with > SunOS. > > NT: A file/print server, or good workstation for CAD, business apps, or > Windows software development. Not a "real" server in my book. > > SCO: Evil incarnate. Stay away at all costs! > > Solaris: An all-around good UNIX, if you can get past the somewhat > complex sysadmin aspects (they like to trade versatility for complexity). > Will get even better in 2.6. > > SunOS: The UNIX I'm trying to migrate everyone away from, before Sun > drops it completely, or another massive security hole is found. Ah, yes - the good 'ol days :-) > > UnixWare: Haven't had opportunity to use, but it's by all accounts the > fastest database server on x86 by far. Hmmm... what database would that be? Can FreeBSD run it? (just curious) > > Win95: The desktop OS for people who can't afford NT. (Good one...) > > Oh well, I've probably missed one or two. The point is that they all have > their places, but for FreeBSD to be successful, we need to be more aware > than ever of what batlles are worth fighting, who our friends are, and who > is the Real Enemy (and I don't mean SCO ;). - Dave Rivers - From owner-freebsd-hackers Fri Feb 14 20:05:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA26841 for hackers-outgoing; Fri, 14 Feb 1997 20:05:58 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA26825 for ; Fri, 14 Feb 1997 20:05:52 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id EAA00956 for ; Sat, 15 Feb 1997 04:05:46 GMT Date: Sat, 15 Feb 1997 13:05:46 +0900 (JST) From: Michael Hancock To: FreeBSD Hackers Subject: Re: Sun Workshop compiler vs. GCC? (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 14 Feb 1997, Thomas David Rivers wrote: > > UnixWare: Haven't had opportunity to use, but it's by all accounts the > > fastest database server on x86 by far. > > Hmmm... what database would that be? Can FreeBSD run it? (just curious) It seems to alternate between Oracle and Sybase. I think Sybase is the current leader. What's more interesting is the monstrosity of the hardware they use, a 4 CPU Compaq ProLiant with a 1GB of RAM and 72 2GB drives on multiple hardware disk arrays. The under $1,000,000 category ;-). NT on the same hardware loses 6000 something to 8000 something on the TCP/C benchmark. I heard that there was a FreeBSD driver for the Compaq Intelligent Drive Array somewhere, but how many of us have such a machine to test it on? Regards, Mike Hancock From owner-freebsd-hackers Fri Feb 14 20:16:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA27437 for hackers-outgoing; Fri, 14 Feb 1997 20:16:47 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA27430 for ; Fri, 14 Feb 1997 20:16:40 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id PAA04061; Sat, 15 Feb 1997 15:15:39 +1100 Date: Sat, 15 Feb 1997 15:15:39 +1100 From: Bruce Evans Message-Id: <199702150415.PAA04061@godzilla.zeta.org.au> To: Arne.Juul@idt.ntnu.no, eivind@dimaga.com Subject: Re: NULL as ((void*)0) (was Re: strlen() question) Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> I hereby propose changing the default declaration of NULL under FreeBSD from >> #define NULL 0 >> to >> #define NULL ((void*)0) >> for better type-safety and ease of transition to other architechtures >> ... >This *shouldn't* help. If it does, the code is broken. >All code should do the right thing with varargs; if having NULL be >plain 0 breaks it, so much the better :-) Broken code should be >found and fixed, not nurtured. I like plain 0 as a default because it tends to expose broken code sooner. >Ideally one should define NULL to plain 0 sometimes, to >(void *)0 sometimes, and to (1-1) (or some other bizarre but >legal option) sometimes, just to find bugs in the source tree. I did this for /usr/src/sys. This trick is also useful for types (if you want to see a lifetime's worth of bugs :-(): typedef signed char off_t; ... typedef long double off_t. Bruce From owner-freebsd-hackers Fri Feb 14 20:36:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA28434 for hackers-outgoing; Fri, 14 Feb 1997 20:36:34 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA28429 for ; Fri, 14 Feb 1997 20:36:30 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id PAA04488; Sat, 15 Feb 1997 15:32:00 +1100 Date: Sat, 15 Feb 1997 15:32:00 +1100 From: Bruce Evans Message-Id: <199702150432.PAA04488@godzilla.zeta.org.au> To: hackers@FreeBSD.ORG, j@uriah.heep.sax.de Subject: Re: NULL as ((void*)0) (was Re: strlen() question) Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >anyway. Passing (void *)0 into a vararg list is as invalid as passing >0 there if the target type is e.g. char *. I think `char *' is required to have the same representation as `void *', so this particular pointer mismatch must work. >encouraged) C code. Inside a function call, you only need to cast it >into the correct target type if: 1) it's in a vararg list, or 2) it's >in an arg list of a function declared with obsolete K&R style only. If it's in an arg list of a function declared with obsolescent K&R style period. `void foo __P((bar_t *));' is declared with obsolescent K&R style if __P(x) expands to (). There is not much point in using __P() if you don't write K&R code (or in using prototypes and depending on K&R misfeatures). Bruce From owner-freebsd-hackers Fri Feb 14 20:53:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA29123 for hackers-outgoing; Fri, 14 Feb 1997 20:53:24 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA29118 for ; Fri, 14 Feb 1997 20:53:19 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id PAA04750; Sat, 15 Feb 1997 15:44:38 +1100 Date: Sat, 15 Feb 1997 15:44:38 +1100 From: Bruce Evans Message-Id: <199702150444.PAA04750@godzilla.zeta.org.au> To: eivind@dimaga.com, hackers@freebsd.org Subject: Re: NULL as ((void*)0) (was Re: strlen() question) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >[1] There has come up one serious objection here, relating to C++. If this >objection is correct, it mean that the proposal absolutely should be >dropped. Besides, nobody but me seems to be in favour, and it isn't >important to me, so... NULL could be ifdefed for c++. However, gcc seems to accept `char *p = (void *)0;' at all warning levels. I don't know C++ well enough to tell if this is a bug. Bruce From owner-freebsd-hackers Fri Feb 14 21:47:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA01982 for hackers-outgoing; Fri, 14 Feb 1997 21:47:59 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id VAA01974 for ; Fri, 14 Feb 1997 21:47:51 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id GAA27639; Sat, 15 Feb 1997 06:02:22 +0100 From: Luigi Rizzo Message-Id: <199702150502.GAA27639@labinfo.iet.unipi.it> Subject: Re: mfs & swap relationship To: joerg_wunsch@uriah.heep.sax.de Date: Sat, 15 Feb 1997 06:02:22 +0100 (MET) Cc: dwhite@resnet.uoregon.edu, hackers@freebsd.org In-Reply-To: from "J Wunsch" at Feb 14, 97 11:29:29 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > And can you make an mfs that's attached to a different partition? > > Of course. It's only a little hard to mount a MFS on a machine that > doesn't have any disk available at all. I've got patches in the queue > that allow using /dev/null as a template (in which case mount_mfs > invents some parameters, which is about the best it could do at all in > case swapping goes over NFS). you don't need patches if you create an entry in disktab and pass that name to mount_mfs. That's what I do for diskless machines, and it works just fine. Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Fri Feb 14 21:58:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA02376 for hackers-outgoing; Fri, 14 Feb 1997 21:58:25 -0800 (PST) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA02343 for ; Fri, 14 Feb 1997 21:58:04 -0800 (PST) Received: (from davidn@localhost) by labs.usn.blaze.net.au (8.8.5/8.8.5) id QAA22441; Sat, 15 Feb 1997 16:57:00 +1100 (EST) Message-ID: <19970215165658.18171@usn.blaze.net.au> Date: Sat, 15 Feb 1997 16:56:58 +1100 From: David Nugent To: Bruce Evans Cc: hackers@FreeBSD.ORG, j@uriah.heep.sax.de Subject: Re: NULL as ((void*)0) (was Re: strlen() question) References: <199702150432.PAA04488@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61 In-Reply-To: <199702150432.PAA04488@godzilla.zeta.org.au>; from Bruce Evans on Feb 02, 1997 at 03:32:00PM Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Feb 02, 1997 at 03:32:00PM, Bruce Evans wrote: > >anyway. Passing (void *)0 into a vararg list is as invalid as passing > >0 there if the target type is e.g. char *. > > I think `char *' is required to have the same representation as `void *', > so this particular pointer mismatch must work. Hmm, I always thought it was "void * must be at least as large as the largest pointer type" for a given implementation. I must dig out my copy of the almost-final draft ANSI spec again, but I wasn't aware that char * should follow this rule too, which is what your statement implies. > If it's in an arg list of a function declared with obsolescent K&R style > period. `void foo __P((bar_t *));' is declared with obsolescent K&R > style if __P(x) expands to (). There is not much point in using __P() > if you don't write K&R code (or in using prototypes and depending on > K&R misfeatures). __P() is only useful in include files. FWIW, I think compatibility with K&R is a crock anyway these days. I follow this rule to keep people (hi Bruce ;-)) happy, and for the sake of consistency. Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-hackers Fri Feb 14 22:07:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA02760 for hackers-outgoing; Fri, 14 Feb 1997 22:07:37 -0800 (PST) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA02703 for ; Fri, 14 Feb 1997 22:04:20 -0800 (PST) Received: (from davidn@localhost) by labs.usn.blaze.net.au (8.8.5/8.8.5) id RAA23958; Sat, 15 Feb 1997 17:03:41 +1100 (EST) Message-ID: <19970215170339.32710@usn.blaze.net.au> Date: Sat, 15 Feb 1997 17:03:39 +1100 From: David Nugent To: Bruce Evans Cc: eivind@dimaga.com, hackers@freebsd.org Subject: Re: NULL as ((void*)0) (was Re: strlen() question) References: <199702150444.PAA04750@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61 In-Reply-To: <199702150444.PAA04750@godzilla.zeta.org.au>; from Bruce Evans on Feb 02, 1997 at 03:44:38PM Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Feb 02, 1997 at 03:44:38PM, Bruce Evans wrote: > >[1] There has come up one serious objection here, relating to C++. If this > >objection is correct, it mean that the proposal absolutely should be > >dropped. Besides, nobody but me seems to be in favour, and it isn't > >important to me, so... > > NULL could be ifdefed for c++. However, gcc seems to accept > `char *p = (void *)0;' at all warning levels. > I don't know C++ well enough to tell if this is a bug. Hard to say. If some other constant or pointer type is accepted then it certainly is. C++ provides no automatic type conversion of void* to any other pointer type, which of course is a feature and not a bug. :) Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-hackers Fri Feb 14 22:36:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA04081 for hackers-outgoing; Fri, 14 Feb 1997 22:36:52 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA04073 for ; Fri, 14 Feb 1997 22:36:48 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id RAA07576; Sat, 15 Feb 1997 17:34:19 +1100 Date: Sat, 15 Feb 1997 17:34:19 +1100 From: Bruce Evans Message-Id: <199702150634.RAA07576@godzilla.zeta.org.au> To: bde@zeta.org.au, davidn@labs.usn.blaze.net.au Subject: Re: NULL as ((void*)0) (was Re: strlen() question) Cc: hackers@FreeBSD.ORG, j@uriah.heep.sax.de Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Hmm, I always thought it was "void * must be at least as large as the >largest pointer type" for a given implementation. I must dig out my >copy of the almost-final draft ANSI spec again, but I wasn't aware >that char * should follow this rule too, which is what your statement >implies. I think the sizeof(void *) is unrelated to sizeof(foo_t *) except when foo_t is char. All that is generally required is that casts from a valid (foo_t *) to (void *) and back not lose information. (foo_t *) might be larger if it has unused bits. >__P() is only useful in include files. System include files. I agree, but CSRG didn't. >FWIW, I think compatibility with K&R is a crock anyway these >days. I follow this rule to keep people (hi Bruce ;-)) happy, >and for the sake of consistency. I only insist on K&R compatibility for consistency. BTW, the Lite2 merge would have been much easier if we had followed the style guide for new code and not changed the style of old code just to fix warnings. Changing `if (error = barf()) ...' to `error = barf;if (error) ...' caused lots of conflicts and usually got undone when barf() involves vfs stuff. Bruce From owner-freebsd-hackers Sat Feb 15 00:32:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA11786 for hackers-outgoing; Sat, 15 Feb 1997 00:32:31 -0800 (PST) Received: from casparc.ppp.net (mail.ppp.net [194.64.12.35]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA11771; Sat, 15 Feb 1997 00:32:18 -0800 (PST) Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m0vvfXZ-000IGSC; Sat, 15 Feb 97 09:32 MET Received: by ernie.kts.org via sendmail with stdio id for pechter@shell.monmouth.com; Sat, 15 Feb 1997 09:26:54 +0100 (MET) (Smail-3.2.0.91 1997-Jan-14 #2 built 1997-Feb-8) Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: Re: pcvt/132 columns To: pechter@shell.monmouth.com (Bill/Carolyn Pechter) Date: Sat, 15 Feb 1997 09:26:54 +0100 (MET) Cc: FreeBSD-hackers@freebsd.org, FreeBSD-current@freebsd.org In-Reply-To: <199702150024.TAA14132@shell.monmouth.com> from "Bill/Carolyn Pechter" at Feb 14, 97 07:24:47 pm Organization: Kitchen Table Systems Reply-To: hm@kts.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bill/Carolyn Pechter wrote: > However, once I run X -- the sync rate is screwed up and 132 is no good. I had the same problem with my S3 board, so the pcvt distribution contains a clock-set program which (re)programs the clock chip. This program was ripped off XFree86, i suggest you do the same for your clock chip. Have a look at /usr/src/usr.sbin/pcvt/set2061. It would be nice if the Xserver would contain a hook to let programs like this run automatically. hellmuth -- hellmuth michaelis hm@kts.org hamburg, europe From owner-freebsd-hackers Sat Feb 15 00:55:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA12254 for hackers-outgoing; Sat, 15 Feb 1997 00:55:26 -0800 (PST) Received: from nasu.utsunomiya-u.ac.jp (nasu.utsunomiya-u.ac.jp [160.12.128.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA12249 for ; Sat, 15 Feb 1997 00:55:23 -0800 (PST) Received: from nantai.utsunomiya-u.ac.jp (nantai.utsunomiya-u.ac.jp [160.12.195.11]) by nasu.utsunomiya-u.ac.jp (8.8.4+2.7Wbeta4/3.5Wpl3) with ESMTP id RAA00552; Sat, 15 Feb 1997 17:53:56 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (l84U5wACG08aSNHKtgmzNEDs5no4O3xY@zodiac.mech.utsunomiya-u.ac.jp [160.12.33.1]) by nantai.utsunomiya-u.ac.jp (8.8.4+2.7Wbeta4/3.5Wpl3) with ESMTP id RAA00537; Sat, 15 Feb 1997 17:53:50 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zenith.mech.utsunomiya-u.ac.jp [160.12.33.60]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id RAA23399; Sat, 15 Feb 1997 17:56:25 +0900 (JST) Message-Id: <199702150856.RAA23399@zodiac.mech.utsunomiya-u.ac.jp> To: Tony Overfield cc: freebsd-hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: psm and kbdio driver (was Re: Stuck! 2.2 Gamma won't go.) In-reply-to: Your message of "Tue, 11 Feb 1997 00:15:23 CST." <3.0.1.32.19970211001523.006a17b8@bugs.us.dell.com> References: Your message of "Mon, 10 Feb 1997 05:15:54 CST." <3.0.1.32.19970210051554.006a2350@bugs.us.dell.com> <3.0.1.32.19970210022848.00691d20@bugs.us.dell.com> <3.0.1.32.19970210051554.006a2350@bugs.us.dell.com> <3.0.1.32.19970211001523.006a17b8@bugs.us.dell.com> Date: Sat, 15 Feb 1997 17:56:23 +0900 From: Kazutaka YOKOTA Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>If I ask some qustions regarding the keyboard controller, would you be >>kind enough to answer them and assist me to improve the psm and kbdio >>drivers? >> >>I really want several points clarified about the keyboard/mouse/i8042. > >Go ahead, I'll help with anything I can. My experience has been >primarily focused on moving the data to and from the keyboard and >mouse devices through the keyboard controller, not so much on what >the data within those packets actually is. Should we find a more >appropriate mailing list or should we go to direct e-mail? Thank you. Let's move to the freebsd-hackers list, as we are not quite discussing a bug anymore. Here are first bunch of questions. Before I beg you answers to my questions, I had better tell you my source of information first, so that you can know how I learned the basics of the keyboard, the PS/2 mouse and the keyboard controller. [1] Van Gilluwe, F.: "The Undocumented PC", Addison Wesley, 1994. [2] Hogan, T.: "The Programmer's PC Sourcebook, 2nd Ed.", Microsoft Press, 1991. [3] Brown, R.: "Interrupt List". [4] Phoenix Technologies Ltd.: "System BIOS for IBM PC/XT/AT Computers and Compatibles", Addison Wesley, 1987. [5] Logitech Inc.: "Logitech Mouse Technical Reference and Programmer's Guide", 1992. I also use various magazine articles, English or Japanese. No, I don't have a copy of "Technical Reference - Personal Computer AT" from IBM. I know I should have one. But, is it still available? 1. Internal buffer size I understand that the AT keyboard (84/101) has an internal 16 byte buffer. Does the PS/2 mouse have an internal buffer too? If so, how large is it? Also, does the keyboard controller buffer data from the keyboard and the mouse (I guess this is unlikely though)? 2. Response to the command For most keyboard commands, the keyboard responds with ACK (0xfa). When exactly is it sent back? Suppose a data byte is waiting in the keyboard internal buffer to be transmitted to the system, then a command arrives. Will ACK be sent back before or after the data byte? The keyboard often sends two or more bytes for a single key make/break event. What if a command arrives after the first byte has been sent but before the second byte. Will ACK be sent before the second byte? What should I do to the first byte already received? Should I discard it (because the first byte will be sent again?), or save it so that I can use it together with the second byte which will be later received? The system can interrupt data transmission from the keyboard in the midst of a byte, by bringing the CLOCK line down. In such case, will the keyboard try to re-send the interrupted byte later? As for the PS/2 mouse, the Logitech Mouse Technical Reference is explicit about such circumstances; ACK will be sent immediately. If a command from the system interrupt a data packet from the mouse in the middle, the transmission of the data packet is aborted, and the system should discard data already received. The mouse will send the complete data packet again after the ACK. 3. Reset For the reset command (0xff), the keyboard responds with ACK and a result code (0xaa). The mouse responds with ACK, a result code and an device ID. I learned that the reset action takes a long, long time, and the keyboard/mouse driver has to exercise a long delay before attempting to read response from the device. The duration of necessary delay varies from one system to another (though, I have the impression the keyboard reset takes longer than the mouse reset...). So, we need go give sufficient margin to the delay. Is there standard or semi-standard or practical value for this duration? And when exactly should I wait? I have found many keyboard and mice return ACK immediately and takes their own sweet time to reset itself, so I do "send RESET - receive ACK - wait (up to a few hundred msec) - receive a result code". But, I recently learned that I need to wait before ACK for the built-in mouse device in some laptops. I would be grateful if you could shed some light on these questions. Kazu From owner-freebsd-hackers Sat Feb 15 01:38:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA13357 for hackers-outgoing; Sat, 15 Feb 1997 01:38:21 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA13344 for ; Sat, 15 Feb 1997 01:38:17 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id KAA23518 for hackers@freebsd.org; Sat, 15 Feb 1997 10:36:50 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id DAA22380 for ; Sat, 15 Feb 1997 03:41:37 +0100 (MET) Message-Id: <3.0.32.19970215034136.00c12990@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 15 Feb 1997 03:41:38 +0100 To: hackers@freebsd.org From: Eivind Eklund Subject: Re: NULL as ((void*)0) (was Re: strlen() question) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 07:44 PM 2/14/97 -0500, Thomas David Rivers wrote: >[Eivind Eklund] >> I hereby propose changing the default declaration of NULL under FreeBSD from >> #define NULL 0 >> to >> #define NULL ((void*)0) >> for better type-safety and ease of transition to other architechtures >> (e.g. Alpha). This will probably save us from a quite a few varargs-voes, >> as well as generally making sure the code-base is using NULL correctly, >> which is important for those reading source-code. [... snipped ...] > > The best definition for NULL is as it is, 0. > > Now, I was wondering just where it would save varargs problems? >Can you elaborate? On most machines, void* has internal structure that is equalient to all other pointers types. This will let an ill-used NULL in a varargs-list quietly 'do the right thing'. It isn't universal, but (assuming that this is a problem that occur a few places), it will save us some woes. We won't _have_ to fix it before things can work, only for code purity and ports to machines with differing internal pointer structure. (Please consider whether followups should go to -chat - this might be getting off-topic.) Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/ eivind@freebsd.org From owner-freebsd-hackers Sat Feb 15 02:26:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA15021 for hackers-outgoing; Sat, 15 Feb 1997 02:26:53 -0800 (PST) Received: from pat.idt.unit.no (0@pat.idt.unit.no [129.241.103.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA15011 for ; Sat, 15 Feb 1997 02:26:45 -0800 (PST) Received: from idt.unit.no (27959@vier.idt.ntnu.no [129.241.103.4]) by pat.idt.unit.no (8.8.5/8.8.5) with ESMTP id LAA23547; Sat, 15 Feb 1997 11:26:40 +0100 (MET) Message-Id: <199702151026.LAA23547@pat.idt.unit.no> To: eivind@dimaga.com Cc: hackers@freebsd.org Subject: Re: NULL as ((void*)0) (was Re: strlen() question) In-Reply-To: Your message of "Sat, 15 Feb 1997 01:48:58 +0100" References: <3.0.32.19970215014856.00c14100@dimaga.com> X-Mailer: Mew version 1.06 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sat, 15 Feb 1997 11:26:39 +0100 From: "Arne H. Juul" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > BTW: I just got another idea - if we can turn the definition of NULL > between ((void*)0) and 0 we can detect if NULL is abused if compiling on a > machine with different sizeof(void*) and sizeof(int). If used correctly, > code will be equal no matter what the definition - if used incorrectly, > different code should result. This can provide fairly automatic detection > of errors, provided we have two different builds. I think this is a good idea too, but it isn't really neccessary to change anything in the main source tree for this (though it would make it easier if there was just one place to change, of course). I have done a make world with (most) of the #define's for NULL set to ((void *)0) and have found a few minor bugs already (23% done). PR will follow. BTW, as far as I can see from my C standard the rules for NULL are pretty lax; both (1-1) and something like typedef enum { __ournull=0 } __dummynull; #define NULL __ournull should be legal. - Arne H. J. From owner-freebsd-hackers Sat Feb 15 04:15:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA18724 for hackers-outgoing; Sat, 15 Feb 1997 04:15:49 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA18700 for ; Sat, 15 Feb 1997 04:15:41 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id NAA10304 for ; Sat, 15 Feb 1997 13:15:26 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.4/8.6.12) with UUCP id NAA28906 for freebsd-hackers@freebsd.org; Sat, 15 Feb 1997 13:14:42 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.5/keltia-uucp-2.9) id KAA25978; Sat, 15 Feb 1997 10:25:29 +0100 (CET) Message-ID: <19970215102528.UU50356@keltia.freenix.fr> Date: Sat, 15 Feb 1997 10:25:28 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: freebsd-hackers@freebsd.org Subject: Re: undocumented kernel options... References: <199702140807.AAA14402@lestat.nas.nasa.gov> <199702150248.SAA22259@freefall.freebsd.org> X-Mailer: Mutt 0.60,1-3,9 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2999 In-Reply-To: <199702150248.SAA22259@freefall.freebsd.org>; from Darren Reed on Feb 15, 1997 13:45:40 +1100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Darren Reed: > If anyone was ever tempted to do anything like SAM, I'd make them use it > for every system admin. task first and see of that changed their mind. > (Yes, we edit the config files rather than use SAM). SMIT is almost as bad as SAM except that if you use it a little, you'll find that it generates a log file of every commands it runs, makeing easier the manual usage later... Both are horrible. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #39: Sun Feb 2 22:12:44 CET 1997 From owner-freebsd-hackers Sat Feb 15 04:20:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA18948 for hackers-outgoing; Sat, 15 Feb 1997 04:20:44 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id EAA18939 for ; Sat, 15 Feb 1997 04:20:38 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id NAA19287 for hackers@FreeBSD.ORG; Sat, 15 Feb 1997 13:20:35 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id NAA16241; Sat, 15 Feb 1997 13:03:47 +0100 (MET) Message-ID: Date: Sat, 15 Feb 1997 13:03:47 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: mfs & swap relationship References: <199702150502.GAA27639@labinfo.iet.unipi.it> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702150502.GAA27639@labinfo.iet.unipi.it>; from Luigi Rizzo on Feb 15, 1997 06:02:22 +0100 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Luigi Rizzo wrote: > > I've got patches in the queue > > that allow using /dev/null as a template (in which case mount_mfs > > invents some parameters, which is about the best it could do at all in > > case swapping goes over NFS). > > you don't need patches if you create an entry in disktab and pass that > name to mount_mfs. That's what I do for diskless machines, and it works > just fine. Hmm, although this seems to be a crock as well as my version, perhaps we should stuff a generic `mfs' entry into /etc/disktab, and document its use in the EXAMPLES section. Can you send your version to me? (It will only make sense if you can override the actual size from the commandline.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Feb 15 04:36:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA20142 for hackers-outgoing; Sat, 15 Feb 1997 04:36:28 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA20128; Sat, 15 Feb 1997 04:36:13 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id NAA24918; Sat, 15 Feb 1997 13:34:47 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id NAA26365; Sat, 15 Feb 1997 13:14:20 +0100 (MET) Message-Id: <3.0.32.19970215131419.00bc31d0@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 15 Feb 1997 13:14:21 +0100 To: Mikael Karpberg From: Eivind Eklund Subject: Re: MIME applications for FreeBSD Cc: se@freebsd.org (Stefan Esser), hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 12:46 AM 2/14/97 +0100, Mikael Karpberg wrote: >Well... One could always make someone documment the format by reverese >enginering, or looking at the MS example code. No code, just the format >of the files. Then just sending the documentation of the format to some >other people, ought to make receipents "clean" enough to be able to write >a BSD-licenced source from that, which can grok the format, and output >ascii/ps/pdf files. No? A friend of mine is doing a Word to SGML converter as a consultancy job for a company that need the functionality; it will be finished later this year. If I understood him correctly it will be released under the GNU licence when he's finished with it. The only bad thing about it is that it's written in CL, and thus somewhat harder to compile than nescessary. Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/ eivind@freebsd.org From owner-freebsd-hackers Sat Feb 15 05:08:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA22910 for hackers-outgoing; Sat, 15 Feb 1997 05:08:05 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA22884 for ; Sat, 15 Feb 1997 05:07:58 -0800 (PST) Message-Id: <199702151307.FAA22884@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA264122068; Sun, 16 Feb 1997 00:07:48 +1100 From: Darren Reed Subject: Re: Sun Workshop compiler vs. GCC? To: patrick@xinside.com Date: Sun, 16 Feb 1997 00:07:48 +1100 (EDT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199702132216.PAA02367@chon.xinside.com> from "Patrick Giagnocavo" at Feb 13, 97 03:16:27 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Patrick Giagnocavo, sie said: [...] > I tried to get Solaris x86 up on two different machines. No go. Can > however install Linux FreeBSD etc. on these systems no problem. [...] > Solaris won't capture the market, because they don't have a good > installation program. Maybe this isn't a very technical problem, but > it is a very real consideration when dealing with people who are just > trying to get things to work... I'd plunk down the money for Solaris > x86 if it would install easier - but it doesn't. Well, I've installed each of Linux, FreeBSD, NetBSD and Solaris. I rate the installation procedures as follows: 1. Solaris 2. FreeBSD 3. Linux (and a long way behind...) 4. NetBSD I installed on a standard clone, no special cards, etc. Solaris was by far the easiest, well, maybe the disk partitioning is a bit confusing. If I was a user, I'd also like the Solaris boot the best, too. A lot of people here will disagree with me, perhaps, but when I look at the bootup screen for Solaris2, I see a finish built for users who don't know or care about hardware details etc (makes FreeBSD and others look like "hacks"). If I could, I'd advocate that the free unixes have a similar quiet boot as default and a "verbose" option to see all the junk messages about detecting disks, etc. I see the same with NT4.0 (there is a way to get a "verbose" boot). Hack, on a fast PC, those boot messages disappear too quickly to digest anyway! "Hi, I don't know anything about computers except that I want it to work. I don't want to be confused." Darren From owner-freebsd-hackers Sat Feb 15 05:41:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA24777 for hackers-outgoing; Sat, 15 Feb 1997 05:41:07 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA24772 for ; Sat, 15 Feb 1997 05:41:04 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id FAA17585; Sat, 15 Feb 1997 05:40:45 -0800 (PST) To: Darren Reed cc: patrick@xinside.com, hackers@FreeBSD.ORG Subject: Re: Sun Workshop compiler vs. GCC? In-reply-to: Your message of "Sun, 16 Feb 1997 00:07:48 +1100." <199702151307.FAA22884@freefall.freebsd.org> Date: Sat, 15 Feb 1997 05:40:45 -0800 Message-ID: <17581.856014045@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > A lot of people here will disagree with me, perhaps, but when I look at > the bootup screen for Solaris2, I see a finish built for users who don't > know or care about hardware details etc (makes FreeBSD and others look > like "hacks"). If I could, I'd advocate that the free unixes have a > similar quiet boot as default and a "verbose" option to see all the junk For those of us who've never seen a Solaris2 machine boot up, could you perhaps tell us (though config@freebsd.org would be perhaps a better mailing list on which to do it) what it looks like and what about it you found so attractive? There is *nothing* about the current FreeBSD installation which is frozen in stone, and frankly I never expected it to last 2+ years looking just like it does now - I figured we'd have a totally different installation by now. Too many fires, too few hours in the day I guess. :-) Jordan From owner-freebsd-hackers Sat Feb 15 07:00:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA27311 for hackers-outgoing; Sat, 15 Feb 1997 07:00:05 -0800 (PST) Received: from spooky.rwwa.com (rwwa.com [198.115.177.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA27260 for ; Sat, 15 Feb 1997 06:59:33 -0800 (PST) Received: from spooky.rwwa.com (localhost.rwwa.com [127.0.0.1]) by spooky.rwwa.com (8.7.5/8.7.3) with ESMTP id JAA26056 for ; Sat, 15 Feb 1997 09:58:31 -0500 (EST) Message-Id: <199702151458.JAA26056@spooky.rwwa.com> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: Re: NULL as ((void*)0) (was Re: strlen() question) In-reply-to: Your message of "Fri, 14 Feb 1997 17:36:53 +0100." <3.0.32.19970214173652.00c0b290@dimaga.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Feb 1997 09:58:31 -0500 From: Robert Withrow Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk eivind@dimaga.com said: > I hereby propose changing the default declaration of NULL under > FreeBSD from #define NULL 0 to #define NULL ((void*)0) for better > type-safety and ease of transition to other architechtures (e.g. > Alpha). Well, once you understand ANSI you get over this compulsion to sprinkle your code with NULL, so I don't see the point. ----------------------------------------------------------------------------- Robert Withrow, Tel: +1 617 592 8935, Net: witr@rwwa.COM From owner-freebsd-hackers Sat Feb 15 10:45:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA08638 for hackers-outgoing; Sat, 15 Feb 1997 10:45:40 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA08629 for ; Sat, 15 Feb 1997 10:45:32 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA03735; Sat, 15 Feb 1997 11:44:06 -0700 From: Terry Lambert Message-Id: <199702151844.LAA03735@phaeton.artisoft.com> Subject: Re: Sun Workshop compiler vs. GCC? To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sat, 15 Feb 1997 11:44:05 -0700 (MST) Cc: avalon@coombs.anu.edu.au, patrick@xinside.com, hackers@FreeBSD.ORG In-Reply-To: <17581.856014045@time.cdrom.com> from "Jordan K. Hubbard" at Feb 15, 97 05:40:45 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > A lot of people here will disagree with me, perhaps, but when I look at > > the bootup screen for Solaris2, I see a finish built for users who don't > > know or care about hardware details etc (makes FreeBSD and others look > > like "hacks"). If I could, I'd advocate that the free unixes have a > > similar quiet boot as default and a "verbose" option to see all the junk > > For those of us who've never seen a Solaris2 machine boot up, could > you perhaps tell us (though config@freebsd.org would be perhaps a > better mailing list on which to do it) what it looks like and what > about it you found so attractive? Remember the boot splash discussion? Now you know. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Feb 15 10:49:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA08776 for hackers-outgoing; Sat, 15 Feb 1997 10:49:31 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA08770 for ; Sat, 15 Feb 1997 10:49:27 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA03747; Sat, 15 Feb 1997 11:47:40 -0700 From: Terry Lambert Message-Id: <199702151847.LAA03747@phaeton.artisoft.com> Subject: Re: NULL as ((void*)0) (was Re: strlen() question) To: davidn@labs.usn.blaze.net.au (David Nugent) Date: Sat, 15 Feb 1997 11:47:40 -0700 (MST) Cc: bde@zeta.org.au, hackers@FreeBSD.ORG, j@uriah.heep.sax.de In-Reply-To: <19970215165658.18171@usn.blaze.net.au> from "David Nugent" at Feb 15, 97 04:56:58 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > __P() is only useful in include files. > > FWIW, I think compatibility with K&R is a crock anyway these > days. I follow this rule to keep people (hi Bruce ;-)) happy, > and for the sake of consistency. I do it for the sake of code portability to machines that are not likely to be upgradeable, ever. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Feb 15 10:54:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA09007 for hackers-outgoing; Sat, 15 Feb 1997 10:54:51 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA09000 for ; Sat, 15 Feb 1997 10:54:47 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA03759; Sat, 15 Feb 1997 11:53:23 -0700 From: Terry Lambert Message-Id: <199702151853.LAA03759@phaeton.artisoft.com> Subject: Re: NULL as ((void*)0) (was Re: strlen() question) To: bde@zeta.org.au (Bruce Evans) Date: Sat, 15 Feb 1997 11:53:23 -0700 (MST) Cc: bde@zeta.org.au, davidn@labs.usn.blaze.net.au, hackers@FreeBSD.ORG, j@uriah.heep.sax.de In-Reply-To: <199702150634.RAA07576@godzilla.zeta.org.au> from "Bruce Evans" at Feb 15, 97 05:34:19 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I only insist on K&R compatibility for consistency. BTW, the > Lite2 merge would have been much easier if we had followed the > style guide for new code and not changed the style of old code > just to fix warnings. Changing `if (error = barf()) ...' to > `error = barf;if (error) ...' caused lots of conflicts > and usually got undone when barf() involves vfs stuff. The conversion from the use of assignment expression lvalues is an intentional style issue?!?! Does style also have us avoiding the comma operator, the question-mark operator, bit fields, and similar things, all of which might also be confusing to the total novice C programmer?!?! What about partial agregate initilization? I see it all over the kernel... and what about dangling commas in lists of enumerated types? The implication is that there exists a manifest zero... Ugh. Next we will avoid function calls because they are confusing to Pascal programmers who expect them to be hierarchically scoped... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Feb 15 11:51:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA10736 for hackers-outgoing; Sat, 15 Feb 1997 11:51:47 -0800 (PST) Received: from lightside.com (hamby1.lightside.net [207.67.176.17]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA10726 for ; Sat, 15 Feb 1997 11:51:38 -0800 (PST) Received: by lightside.com (SMI-8.6/SMI-SVR4) id LAA04265; Sat, 15 Feb 1997 11:52:13 -0800 Date: Sat, 15 Feb 1997 11:52:13 -0800 From: jehamby@lightside.com (Jake Hamby) Message-Id: <199702151952.LAA04265@lightside.com> To: freebsd-hackers@freebsd.org, steve@news.cioe.com Subject: Re: Freewin95 - just fyi Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: 4DnnDZmNTDRL9AUD5AFW3A== Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve writes: > > It looked really good until I read the part of about him losing his > > head of something or other before coding had begun due to a > > personality dispute... > > It still looks good. I'm solidly behind the concept of getting more > Free OSs out there. Their project might not get anywhere, but then again > it might produce some usable code. > > I thought the gnu people were working on a UNIX varient also? Anyone know > the status on that? > > -Steve I think it's a waste of effort. Instead of writing something from scratch (which may never happen, because of the sheer effort involved), why not build on top of what is already there? I strongly believe they should take FreeBSD or Linux as a base, and build on top of WINE, an existing Windows emulator that already supports 16-bit and 32-bit programs. There's nothing fundamentally wrong with WINE, it simply needs to support more API's. If the Freedows people actually want to get something that works by 1998, they should start from existing code rather than the foolish task of building a new OS from scratch! There is so much enthusiasm in the free software community, but it always bothers me when people go off and duplicate existing effort for no good reason! As for GNU, yes they have been working on HURD, which is a microkernel based on Mach. They had been working on it before Linux was invented, but it took them until recently to get even a 0.1 alpha release. So it seems pointless in the face of the Free UNIX's that already exist, except for two reasons. First, the project has gone on for so long that they want to finish it. Second, Stallman is bothered by the success of Linux, and the fact that people call it Linux, not "GNU/Linux", and neglect mentioning that if it weren't for GNU, Linux wouldn't be where it is today. -- Jake From owner-freebsd-hackers Sat Feb 15 12:58:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA12823 for hackers-outgoing; Sat, 15 Feb 1997 12:58:38 -0800 (PST) Received: from pahtoh.cwu.edu (root@pahtoh.cwu.edu [198.104.65.27]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA12818 for ; Sat, 15 Feb 1997 12:58:36 -0800 (PST) Received: from opus.cts.cwu.edu (skynyrd@opus.cts.cwu.edu [198.104.92.71]) by pahtoh.cwu.edu (8.6.13/8.6.9) with ESMTP id MAA05169; Sat, 15 Feb 1997 12:58:34 -0800 Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.8.5/8.8.5) with SMTP id MAA20928; Sat, 15 Feb 1997 12:58:33 -0800 (PST) Date: Sat, 15 Feb 1997 12:58:33 -0800 (PST) From: Chris Timmons To: Jaye Mathisen cc: hackers@freebsd.org Subject: Re: CVS question, sendmail, named In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk perhaps your CVS repository is stale; it's been in there for nearly 10 days... riffraff:CVSROOT/commitlogs> tail -1000 usrsbin | grep -A10 -B10 sendmail peter 97/02/04 23:29:35 Branch: usr.sbin/sendmail RELENG_2_2 usr.sbin/sendmail/cf RELENG_2_2 usr.sbin/sendmail/cf/cf RELENG_2_2 usr.sbin/sendmail/cf/m4 RELENG_2_2 usr.sbin/sendmail/contrib RELENG_2_2 usr.sbin/sendmail/doc/op RELENG_2_2 usr.sbin/sendmail/mail.local RELENG_2_2 usr.sbin/sendmail/mailstats RELENG_2_2 usr.sbin/sendmail/rmail RELENG_2_2 usr.sbin/sendmail/src RELENG_2_2 Modified: usr.sbin/sendmail RELEASE_NOTES usr.sbin/sendmail/cf README usr.sbin/sendmail/cf/cf Makefile freefall.mc usr.sbin/sendmail/cf/m4 cfhead.m4 proto.m4 version.m4 usr.sbin/sendmail/contrib bsdi.mc re-mqueue.pl usr.sbin/sendmail/doc/op op.me usr.sbin/sendmail/mail.local mail.local.8 mail.local.c usr.sbin/sendmail/mailstats mailstats.8 usr.sbin/sendmail/rmail Makefile rmail.c usr.sbin/sendmail/src Makefile READ_ME alias.c clock.c collect.c conf.c conf.h daemon.c deliver.c envelope.c headers.c main.c map.c mime.c queue.c readcf.c savemail.c sendmail.8 sendmail.h srvrsmtp.c udb.c usersmtp.c util.c version.c Log: Update 8.8.4 -> 8.8.5 on 2.2 branch On Fri, 14 Feb 1997, Jaye Mathisen wrote: > > Might as well whack out a bunch of them in 1 message... > > > My understanding is that for whatever reason, sendmail 8.8.5 is in > -current, but hasn't been tagged for RELENG_2_2. > > So how do I tag my CVS repository locally so that the sendmail from > -current is in my local RELENG_2_2, such that if I check out a tree > with tags RELENG_2_2, I get the sendmail 8.8.5? If I then update my > CVS tree, will it get overwritten with the 8.8.4 stuff? > > Also, is anybody using bind-4.9.5-P1 on a box? Is this in -current? If > so, I'd like to do the same thing to it as sendmail 8.8.5. (bring it into > -GAMMA/RELENG_2_2). > > Is there any reason 8.8.5 isn't tagged into RELENG_2_2? > > > From owner-freebsd-hackers Sat Feb 15 13:43:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA14819 for hackers-outgoing; Sat, 15 Feb 1997 13:43:39 -0800 (PST) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA14810 for ; Sat, 15 Feb 1997 13:43:29 -0800 (PST) Received: from localhost (narvi@localhost) by haldjas.folklore.ee (8.8.4/8.8.4) with SMTP id XAA08122; Sat, 15 Feb 1997 23:43:39 +0200 (EET) Date: Sat, 15 Feb 1997 23:43:38 +0200 (EET) From: Narvi To: Terry Lambert cc: Dave Cornejo , jb@cimlogic.com.au, rb@gid.co.uk, hackers@FreeBSD.ORG Subject: Re: MIME applications for FreeBSD In-Reply-To: <199702141752.KAA03110@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 14 Feb 1997, Terry Lambert wrote: > > > What are the licence restrictions on that source and things derived > > > from it? > > > > WordPad is a demo program for the "power" of MFC - so you'd have to > > port MFC to whatever to get it running. I think that they also supply > > those on the 4.2 CD (I don't have mine here so can't check) but I'd > > expect that all those sources are meant for reference use by licensees > > of VC++ only... > > You're permitted to use MFC on other platforms, but you must have a > copy of VC++ for each platform. > > You are permitted to use and redistribute the code, so long as you > make "significant" improvement to it. > > I'm betting you won't be able to get away with distributing the > sources, no matter how much you improve it, though there is nothing > that actually says you can't (most likely, they will redefine > "significant", as necessary, to prevent you from doing so). Well, could there be any more significat change (other than completele and utterly changing it to something another) than chaning it to work in another windowing environment? Sander > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > From owner-freebsd-hackers Sat Feb 15 14:11:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA15862 for hackers-outgoing; Sat, 15 Feb 1997 14:11:26 -0800 (PST) Received: from news.IAEhv.nl (root@news.IAEhv.nl [194.151.64.4]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA15838 for ; Sat, 15 Feb 1997 14:11:16 -0800 (PST) Received: from LOCAL (uucp@localhost) by news.IAEhv.nl (8.6.13/1.63) with IAEhv.nl; pid 29248 on Sat, 15 Feb 1997 23:11:07 +0100; id XAA29248 efrom: peter@grendel.IAEhv.nl; eto: hackers@FreeBSD.ORG Received: (from peter@localhost) by grendel.IAEhv.nl (8.8.4/8.8.4) id WAA00487; Sat, 15 Feb 1997 22:43:20 +0100 (MET) Message-ID: Date: Sat, 15 Feb 1997 22:43:20 +0100 From: peter@grendel.IAEhv.nl (Peter Korsten) To: hackers@FreeBSD.ORG Subject: Re: MIME applications for FreeBSD References: <199702130839.TAA00435@freebsd1.cimlogic.com.au> <199702121715.KAA00715@phaeton.artisoft.com> X-Mailer: Mutt 0.58-PL15 Mime-Version: 1.0 In-Reply-To: <199702130839.TAA00435@freebsd1.cimlogic.com.au>; from John Birrell on Feb 13, 1997 19:38:59 +1100 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk John Birrell shared with us: > > We are prevented from reverse engineering by the licence for msword > (I guess, since other MS products have that clause). MS is unlikely > to publicly document Word file format. Actually, someone (a student?) at the Technical University of Berlin has described the general Microsoft OLE file format. He states that this he isn't sure about the format and all variables, therefore he calls it the "LAOLA" file format. (Check it out with Alta Vista!) He also provides a library in Perl and a program to convert a MS Word document into an ASCII file. After some studying (the description wasn't clear in every point) I've written a converter in C (but during office hours, so I can't publish it). It shouldn't take you more than a couple of days, probably less. Though the description talks about the Word 6 format, I could easily read a Word 97 file. Really funny, 'cause Word 6 can't read Word 97 files. The Microsoft file format has actually some good points. They put a whole directory tree into it, it seems. Trouble is, they get *so* big. That really is ridiculous. Some 40 characters for test purposes were converted into 19 kB. On another note, I once stumbled across a page with many file formats. On "request" of Microsoft, the Word format was removed. They really don't want anyone to know. - Peter -- Peter Korsten | peter@grendel.IAEhv.nl (UUCP) | peterk@IAEhv.nl C/C++/Perl/Java hacker From owner-freebsd-hackers Sat Feb 15 14:27:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA16887 for hackers-outgoing; Sat, 15 Feb 1997 14:27:23 -0800 (PST) Received: from darkstar (dialin6.anlw.anl.gov [141.221.252.106]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA16882 for ; Sat, 15 Feb 1997 14:27:19 -0800 (PST) Received: (from cmott@localhost) by darkstar (8.6.12/8.6.12) id PAA10898; Sat, 15 Feb 1997 15:27:15 -0700 Date: Sat, 15 Feb 1997 15:27:12 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar To: freebsd-hackers@freebsd.org Subject: User ppp keepalive logic Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I was thinking it would be a good idea to only run keepalive logic on incoming packets and not outgoing packets in user ppp. With one ISP I use, I often run into a situation where the link hangs up, and no communication is possible, but user ppp thinks everything is ok. Unfortunately the link stays alive, because I have a mailer that keeps trying to look at an imap server, or a Win95 box on the local network is doing something stupid. If the keepalive only worked on incoming packets, it would handle the error condition where packets go out but never come back. I am going to do this for my own purposes, but I wondered whether people felt it might be a good idea for the freebsd distribution. Charles Mott From owner-freebsd-hackers Sat Feb 15 14:36:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA17462 for hackers-outgoing; Sat, 15 Feb 1997 14:36:03 -0800 (PST) Received: from lightside.com (hamby1.lightside.net [207.67.176.17]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA17429 for ; Sat, 15 Feb 1997 14:35:59 -0800 (PST) Received: by lightside.com (SMI-8.6/SMI-SVR4) id OAA05103; Sat, 15 Feb 1997 14:32:00 -0800 Date: Sat, 15 Feb 1997 14:32:00 -0800 From: jehamby@lightside.com (Jake Hamby) Message-Id: <199702152232.OAA05103@lightside.com> To: jkh@time.cdrom.com, terry@lambert.org Subject: Re: Sun Workshop compiler vs. GCC? Cc: avalon@coombs.anu.edu.au, patrick@xinside.com, hackers@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: eDJ7W4XSsQ0NZQi/964ShA== Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert writes: > > For those of us who've never seen a Solaris2 machine boot up, could > > you perhaps tell us (though config@freebsd.org would be perhaps a > > better mailing list on which to do it) what it looks like and what > > about it you found so attractive? > > Remember the boot splash discussion? > > Now you know. Except that Solaris doesn't _have_ a boot splash screen. Well, on a SPARC there's a little picture embedded in the ROM that prints at boot up, but that has nothing to do with Solaris. For that matter, my PC has a little AMI BIOS logo when it boots up. Is there some PC UNIX that _does_ have a boot splash screen? See my previous post (which I cc:ed to config, not hackers, as per Jordan's suggestion), in which I discuss what Solaris does when it boots (logs hardware probes to syslog by default, not the console), and why we should keep FreeBSD the way it is (because x86 hardware is difficult to configure and people WANT the hardware probe messages). I also suggest that FreeBSD add a splash screen with clearly printed directions on how to bypass it to see the hardware probes underneath. We could also add a custom FreeBSD logo to the CDE and/or XFree86 startup sequences. We could play .AU files while the system is starting up (as Sun does with the Netra), or go all the way and create an X-based installation program (as Solaris and some Linux distributions do). But no, Solaris doesn't have a splash screen. -- Jake From owner-freebsd-hackers Sat Feb 15 15:35:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA24518 for hackers-outgoing; Sat, 15 Feb 1997 15:35:13 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA24511 for ; Sat, 15 Feb 1997 15:35:10 -0800 (PST) Received: from muggsy.lkg.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id SAA20050; Sat, 15 Feb 1997 18:30:28 -0500 (EST) Received: from usr405.zko.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA02750; Sat, 15 Feb 1997 18:30:24 -0500 Message-Id: <3.0.32.19970215183032.006b2e58@netrix.lkg.dec.com> X-Sender: popmatt@netrix.lkg.dec.com X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Sat, 15 Feb 1997 18:30:40 -0500 To: jehamby@lightside.com (Jake Hamby) From: Matt Thomas Subject: Re: Sun Workshop compiler vs. GCC? Cc: hackers@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Is there some PC UNIX that _does_ have a boot splash screen? UnixWare -- Matt Thomas Internet: matt@3am-software.com 3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt.html Westford, MA Disclaimer: I disavow all knowledge of this message From owner-freebsd-hackers Sat Feb 15 15:46:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA25183 for hackers-outgoing; Sat, 15 Feb 1997 15:46:10 -0800 (PST) Received: from lightside.com (hamby1.lightside.net [207.67.176.17]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA25177 for ; Sat, 15 Feb 1997 15:46:05 -0800 (PST) Received: by lightside.com (SMI-8.6/SMI-SVR4) id PAA05346; Sat, 15 Feb 1997 15:46:45 -0800 Date: Sat, 15 Feb 1997 15:46:45 -0800 From: jehamby@lightside.com (Jake Hamby) Message-Id: <199702152346.PAA05346@lightside.com> To: hackers@freebsd.org Subject: Threads question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: 3dTrAtDFx+vtGeKtUsT3Mw== Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I need a threads package which supports the following operations: create thread exit thread kill thread suspend/resume thread semaphore operations get/set thread priority I'll probably discover some other features which would be nice (for example message ports), but I think everything I need can be implemented on top of the basic functions and either semaphores or mutexes. Anyway, on Solaris I have a choice between POSIX and Solaris threads. The man page for libthread gives a nice summary and comparison between the two. Although I'd like to use POSIX threads for the greater portability, apparently POSIX doesn't offer the option to suspend and resume threads, so I've decided to use Solaris threads. Anyway, just wanted to solicit any advice on the best thread library to use for a FreeBSD (or Linux) port of my toolkit, when it is finished. I've decided to start with a Solaris version, simply because I have access to it (on SPARC and x86), and it has VERY good documentation on the thread functions supported, the differences between Solaris and POSIX threads, and the thread-safeness of each library function. IMHO, this is one area where FreeBSD is very weak. Comments? -- Jake From owner-freebsd-hackers Sat Feb 15 15:46:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA25201 for hackers-outgoing; Sat, 15 Feb 1997 15:46:13 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA25184 for ; Sat, 15 Feb 1997 15:46:10 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA02739; Sat, 15 Feb 1997 16:42:12 -0700 From: Terry Lambert Message-Id: <199702152342.QAA02739@phaeton.artisoft.com> Subject: Re: MIME applications for FreeBSD To: narvi@haldjas.folklore.ee (Narvi) Date: Sat, 15 Feb 1997 16:42:12 -0700 (MST) Cc: terry@lambert.org, dave@dogwood.com, jb@cimlogic.com.au, rb@gid.co.uk, hackers@FreeBSD.ORG In-Reply-To: from "Narvi" at Feb 15, 97 11:43:38 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I'm betting you won't be able to get away with distributing the > > sources, no matter how much you improve it, though there is nothing > > that actually says you can't (most likely, they will redefine > > "significant", as necessary, to prevent you from doing so). > > Well, could there be any more significat change (other than completele > and utterly changing it to something another) than chaning it to work in > another windowing environment? I'm betting (above) that Microsoft would deem that "not significant", since it would prevent you from doing something they'd prefer you don't do (make their give-away code run on a platform you don't have to buy from them: the point of "give-away" code is to encourage use of their platforms). Also, it's "not significant" because it's a port to a platform which *should* already support the Microsoft interfaces, because by definition, Microsoft interfaces lead the industry and should be implemented on all platforms by you programmers from the unwashed masses. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Feb 15 15:49:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA25377 for hackers-outgoing; Sat, 15 Feb 1997 15:49:58 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA25363 for ; Sat, 15 Feb 1997 15:49:47 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA06371; Sat, 15 Feb 1997 16:47:43 -0700 From: Terry Lambert Message-Id: <199702152347.QAA06371@phaeton.artisoft.com> Subject: Re: Sun Workshop compiler vs. GCC? To: jehamby@lightside.com (Jake Hamby) Date: Sat, 15 Feb 1997 16:47:43 -0700 (MST) Cc: jkh@time.cdrom.com, terry@lambert.org, avalon@coombs.anu.edu.au, patrick@xinside.com, hackers@FreeBSD.ORG In-Reply-To: <199702152232.OAA05103@lightside.com> from "Jake Hamby" at Feb 15, 97 02:32:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > For those of us who've never seen a Solaris2 machine boot up, could > > > you perhaps tell us (though config@freebsd.org would be perhaps a > > > better mailing list on which to do it) what it looks like and what > > > about it you found so attractive? > > > > Remember the boot splash discussion? > > > > Now you know. > > Except that Solaris doesn't _have_ a boot splash screen. > > Well, on a SPARC there's a little picture embedded in the ROM that prints at > boot up, but that has nothing to do with Solaris. For that matter, my PC > has a little AMI BIOS logo when it boots up. > > Is there some PC UNIX that _does_ have a boot splash screen? A "splash screen", loosely defined, is "any screen that hides what is really happing, while giving the user something thought to be less confusing to look at". UnixWare has a splash screen in the *strict* definition: You see the UnixWare boot image, you don't see intermediate stuff, as long as all goes as planned and you don't hit "space" during the first yay many seconds of the booth, then you see a graphical login. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Feb 15 16:03:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA26370 for hackers-outgoing; Sat, 15 Feb 1997 16:03:04 -0800 (PST) Received: from aris (aris.jpl.nasa.gov [137.78.161.113]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA26365 for ; Sat, 15 Feb 1997 16:02:58 -0800 (PST) Received: from localhost by aris (SMI-8.6/SMI-SVR4) id QAA18279; Sat, 15 Feb 1997 16:01:19 -0800 Date: Sat, 15 Feb 1997 16:01:19 -0800 (PST) From: Jake Hamby X-Sender: hamby@aris To: "David S. Miller" cc: asami@vader.cs.berkeley.edu, jmb@freefall.freebsd.org, hackers@FreeBSD.ORG Subject: Re: Sun Workshop compiler vs. GCC? In-Reply-To: <199702140448.XAA18687@jenolan.caipgeneral> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 13 Feb 1997, David S. Miller wrote: > > Also, the various optimizer bugs in GCC in the past have led people > to be wary to use -O2 optimization, much less try additional > optimization flags. > > I know about them, just about all of them are in the strength > reduction pass. I am very familiar with the problematic bugs this > layer has, and I have been actively trying to get people on the GCC > development team to fix them. Almost all of these problems have to do > with when a pointer comparison is converted into an integer invariant > comparison, and vice versa. GCC in certain circumstances does not > notice the change in signed'ness and thus produces incorrect code. In > gcc-2.7.2.1, the strength reduction transformations that were known to > lead to this situation were disabled entirely and in fact this fix was > the entire reason for that release of gcc. Thanks for the insight into GCC. You might find it amusing to know that I've already discovered an optimizer bug in the latest version of Sun's C compiler! It affected the directory listing of XV when I compiled it with -fast (or any combination of -xO2 or higher optimization plus -xtarget=486, pentium, or pentium_pro). Fortunately, the nature of the bug was such that: 1) I was able to track it down within a few minutes (without needing a debugger), and 2) I was able to create a stand-alone program to demonstrate the bug. So I sent it as a bug report to the appropriate E-Mail address at Sun. It will be interesting to see how soon it is patched. In my programming career, I've discovered one other optimizer bug, in Metrowerks Codewarrior (BeOS/PowerPC). It was rather gratifying to see it fixed in the very next patch release, with my example code listed in the README under bugs fixed. :) ------------------------------------------------------------------------------ |Jake Hamby| APT Engineer at JPL, CS student at Cal Poly, and BeOS developer!| ------------------------------------------------------------------------------ "Life is hard..." From owner-freebsd-hackers Sat Feb 15 16:06:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA26660 for hackers-outgoing; Sat, 15 Feb 1997 16:06:23 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA26620 for ; Sat, 15 Feb 1997 16:06:15 -0800 (PST) Message-Id: <199702160006.QAA26620@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA076481531; Sun, 16 Feb 1997 11:05:31 +1100 From: Darren Reed Subject: Re: Sun Workshop compiler vs. GCC? To: jehamby@lightside.com (Jake Hamby) Date: Sun, 16 Feb 1997 11:05:30 +1100 (EDT) Cc: hackers@freebsd.org In-Reply-To: <199702152232.OAA05103@lightside.com> from "Jake Hamby" at Feb 15, 97 02:32:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Jake Hamby, sie said: [...] > See my previous post (which I cc:ed to config, not hackers, as per Jordan's > suggestion), in which I discuss what Solaris does when it boots (logs > hardware probes to syslog by default, not the console), and why we should > keep FreeBSD the way it is (because x86 hardware is difficult to configure > and people WANT the hardware probe messages). IMHO, that is a reflection of the diference in the knowledege of the average user of FreeBSD compared with Solaris. To those of us here, and probably 99% of those running FreeBSD, those probe messages mean something. Are they likely to mean anything to a secretary ? Another take on starting up is HP-UX 10. Being SVR4, it has run levels and start/stop scripts. HP have added "startmsg" and "stopmsg" to all their scripts, so that when you boot, it prints a menu type listing and displays "OK", "BUSY", "N/A", "FAIL" in the little check box for each rc script. With about 16 per screen, it clears the screen when it gets to the bottom and presents a new menu. It _looks_ very professional and is very informative (stderr/stdout for all rc scripts goes to a file). Darren From owner-freebsd-hackers Sat Feb 15 16:12:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA27188 for hackers-outgoing; Sat, 15 Feb 1997 16:12:59 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA27181 for ; Sat, 15 Feb 1997 16:12:53 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id LAA13003; Sun, 16 Feb 1997 11:13:33 +1100 (EST) Date: Sun, 16 Feb 1997 11:13:32 +1100 (EST) From: "Daniel O'Callaghan" To: Charles Mott cc: freebsd-hackers@freebsd.org Subject: Re: User ppp keepalive logic In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 15 Feb 1997, Charles Mott wrote: > I was thinking it would be a good idea to only run keepalive logic on > incoming packets and not outgoing packets in user ppp. > [snip] > > If the keepalive only worked on incoming packets, it would handle the > error condition where packets go out but never come back. > > I am going to do this for my own purposes, but I wondered whether people > felt it might be a good idea for the freebsd distribution. Sounds very reasonable. Have you had a look at kernel pppd/if_ppp? I'd really like to get idle-timeout going there. Some of the code is there, wrapped around #if _linux_ in pppd, but availabe in sys/net/if_ppp.c. It looks like someone implemented the last-packet deltas in the kernel, but did not finish making it work in the daemon. Does anyone have any ideas here? Danny From owner-freebsd-hackers Sat Feb 15 16:58:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA00179 for hackers-outgoing; Sat, 15 Feb 1997 16:58:54 -0800 (PST) Received: from werple.net.au (melb.werple.net.au [203.9.190.18]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA00167 for ; Sat, 15 Feb 1997 16:58:44 -0800 (PST) Received: (qmail 9225 invoked by uid 5); 16 Feb 1997 00:58:41 -0000 MBOX-Line: From jb@freebsd1.cimlogic.com.au Sun Feb 16 11:54:44 1997 Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.7.5/8.7.3) id LAA06913; Sun, 16 Feb 1997 11:54:44 +1100 (EST) From: John Birrell Message-Id: <199702160054.LAA06913@freebsd1.cimlogic.com.au> Subject: Re: Threads question To: jehamby@lightside.com (Jake Hamby) Date: Sun, 16 Feb 1997 11:54:41 +1100 (EST) Cc: hackers@freebsd.org In-Reply-To: <199702152346.PAA05346@lightside.com> from Jake Hamby at "Feb 15, 97 03:46:45 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jake Hamby wrote: [...] > Anyway, just wanted to solicit any advice on the best thread library to use > for a FreeBSD (or Linux) port of my toolkit, when it is finished. I've > decided to start with a Solaris version, simply because I have access to it > (on SPARC and x86), and it has VERY good documentation on the thread > functions supported, the differences between Solaris and POSIX threads, and > the thread-safeness of each library function. IMHO, this is one area where > FreeBSD is very weak. Comments? Try FreeBSD's libc_r. It is in -current and not built by default. It has all the things you mention except semaphores (which can be implemented with a condition variable and a mutex). Even the non-POSIX suspend/resume functions are there! They were added to support the JDK port. Your comment on thread-safeness for the libc functions is valid, though. 8-( Can't comment about Linux 'cause I've never used it (and due to GPL, never will). > > -- Jake > Regards, -- John Birrell - jb@cimlogic.com.au; jb@netbsd.org CIMlogic Pty Ltd, 119 Cecil Street, South Melbourne Vic 3205, Australia Tel +61 3 9690 6900 Fax +61 3 9690 6650 Mob +61 418 353 137 From owner-freebsd-hackers Sat Feb 15 17:05:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA00400 for hackers-outgoing; Sat, 15 Feb 1997 17:05:12 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id RAA00393 for ; Sat, 15 Feb 1997 17:05:05 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA06525; Sat, 15 Feb 1997 18:03:42 -0700 From: Terry Lambert Message-Id: <199702160103.SAA06525@phaeton.artisoft.com> Subject: Re: Threads question To: jehamby@lightside.com (Jake Hamby) Date: Sat, 15 Feb 1997 18:03:42 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: <199702152346.PAA05346@lightside.com> from "Jake Hamby" at Feb 15, 97 03:46:45 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Although I'd like to use POSIX threads for the greater portability, > apparently POSIX doesn't offer the option to suspend and resume threads, so > I've decided to use Solaris threads. > > Anyway, just wanted to solicit any advice on the best thread library to use > for a FreeBSD (or Linux) port of my toolkit, when it is finished. I've > decided to start with a Solaris version, simply because I have access to it > (on SPARC and x86), and it has VERY good documentation on the thread > functions supported, the differences between Solaris and POSIX threads, and > the thread-safeness of each library function. IMHO, this is one area where > FreeBSD is very weak. Comments? libc_r (r == reentrant) is thread-safe. The "suspend" and "resume" is a non-sequitur. It refers to the ability to control scheduling in a preeemptive scheduling environment. Pthreads is thread-safe. The "suspend" and "resume" is a non-sequitur. It refers to the ability to control scheduling in a preeemptive thread scheduling environment. Pthreads is a non-preemptive thread scheduler, performindg a thread context switch when a blocking call would occur, by calling a non-blocking call instead, and performing a context switch (implementation is not exact, but this is the net effect). What you are asking for is the ability to "suspend" a thread that is already "suspended"... and resume means "give away my processor to this other thread" -- "yield". If you want to have fine grain control over whether a thread is actually scheduled to run once it is on the ready-to-run queue in the user space scheduler, the modifications to the pthreads code would be trivial. In general, you can achive this same type of lock-step synchronization using semaphores, however, so there's no reason to mix the two control models. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Feb 15 17:12:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA00818 for hackers-outgoing; Sat, 15 Feb 1997 17:12:37 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id RAA00809 for ; Sat, 15 Feb 1997 17:12:31 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA06537; Sat, 15 Feb 1997 18:09:52 -0700 From: Terry Lambert Message-Id: <199702160109.SAA06537@phaeton.artisoft.com> Subject: Re: Sun Workshop compiler vs. GCC? To: hamby@aris.jpl.nasa.gov (Jake Hamby) Date: Sat, 15 Feb 1997 18:09:52 -0700 (MST) Cc: davem@jenolan.rutgers.edu, asami@vader.cs.berkeley.edu, jmb@freefall.freebsd.org, hackers@FreeBSD.ORG In-Reply-To: from "Jake Hamby" at Feb 15, 97 04:01:19 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [ ... SunSoft C optimizer bug ... ] > In my programming career, I've discovered one other optimizer bug, in > Metrowerks Codewarrior (BeOS/PowerPC). It was rather gratifying to see it > fixed in the very next patch release, with my example code listed in the > README under bugs fixed. :) Go to a platform using the "portable C compiler" (like Ultrix). Compile a program that does: char * func2( p, len) char *p; int len; { return( p + len); } char * func( param) char *param; { register char *p = param; p = func2( p, 3); /* XXX*/ return( p); } main() { char *str = "long string"; printf( "<%s>\n", str); str = func( str); printf( "<%s>\n", str); } What will happen is that the assignment of the return value will occur before the pop, and both strings will print the same as the pop overwrites the return value. This is the "Berkeley pop order bug". Now try compiling an unmodified Motif 1.x on Ultrix. 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Feb 15 17:48:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA04400 for hackers-outgoing; Sat, 15 Feb 1997 17:48:14 -0800 (PST) Received: from perki0.connect.com.au (perki0.connect.com.au [192.189.54.85]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA04395 for ; Sat, 15 Feb 1997 17:48:09 -0800 (PST) Received: from nemeton.UUCP (Unemeton@localhost) by perki0.connect.com.au with UUCP id MAA25471 (8.7.6h/IDA-1.6); Sun, 16 Feb 1997 12:47:44 +1100 (EST) X-Authentication-Warning: perki0.connect.com.au: Unemeton set sender to giles@nemeton.com.au using -f Received: from localhost.nemeton.com.au (localhost.nemeton.com.au [127.0.0.1]) by nemeton.com.au (8.8.5/8.8.5) with SMTP id MAA02784; Sun, 16 Feb 1997 12:44:34 +1100 (EST) Message-Id: <199702160144.MAA02784@nemeton.com.au> To: Darren Reed cc: jehamby@lightside.com (Jake Hamby), hackers@freebsd.org Subject: Re: boot messages (Was: Sun Workshop compiler vs. GCC?) In-reply-to: <199702160006.QAA26620@freefall.freebsd.org> Date: Sun, 16 Feb 1997 12:44:34 +1100 From: Giles Lean Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 16 Feb 1997 11:05:30 +1100 (EDT) Darren Reed wrote: > Another take on starting up is HP-UX 10. Being SVR4, it has run levels > and start/stop scripts. HP have added "startmsg" and "stopmsg" to all > their scripts, so that when you boot, it prints a menu type listing and > displays "OK", "BUSY", "N/A", "FAIL" in the little check box for each > rc script. When everything works, it is quite pretty. Syslog messages to the console and anything that talks directly to /dev/tty make a mess of it. A "splash screen" is really going to have to be graphical to work reliably. Does anyone have a nice banner for xdm with the FreeBSD logo? This is another way to present a more "professional" appearance with low impact to the existing code. I had thought that HP had wasted their money on the pretty boot code(*). I should know better; I always try to print management graphs in colour. Regards, Giles * I'd have preferred a fixed up lpsched, for example, or IP aliases in a different subnet, or a 'status' option to mt, or even a -a flag for ifconfig. Or perl5 in /usr/contrib, or tcpd, or a http daemon, or a COPS run before they cut the distribution CD, or support for IPFilter, or ... world peace, maybe. :) From owner-freebsd-hackers Sat Feb 15 17:58:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA05361 for hackers-outgoing; Sat, 15 Feb 1997 17:58:29 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA05353; Sat, 15 Feb 1997 17:58:20 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id SAA22265; Sat, 15 Feb 1997 18:57:43 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sat, 15 Feb 1997 18:35:49 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: freebsd-scsi@freebsd.org, FreeBSD-hackers@freebsd.org Subject: Device Not Ready, 2nd Posting Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I added the worm drive to both 2.2-BETA and 3.0-before_the_explosion with the result that it tells me ``Device not configured'' from wormcontrol. It did ``work'' for a while, then we rebooted and now it is very persistant. The worm support was added by adding: device worm0 at scbus? to the config file. Then we also added: disk worm6 at scbus0 target 6 unit 0 Still the same thing. nm on the kernel reveals that the code is there: ... f0197e88 t _worm_rezero_unit f0197898 t _worm_size f0197a7c t _worm_strategy f01e8a0c d _worm_switch f01978e4 t _wormattach f0197814 t _wormclose f01e8ae0 d _wormdev_sys_init f01977c8 T _worminit f01977f4 t _wormioctl f0197830 t _wormminphys f01977d8 t _wormopen f0197914 t _wormstart f0197844 t _wormstrategy f01977b8 t _wormunit f01977b0 F worm.o So what gives? Simon From owner-freebsd-hackers Sat Feb 15 19:02:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA07888 for hackers-outgoing; Sat, 15 Feb 1997 19:02:38 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA07867 for ; Sat, 15 Feb 1997 19:02:26 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id UAA22636; Sat, 15 Feb 1997 20:01:11 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199702152232.OAA05103@lightside.com> Date: Sat, 15 Feb 1997 19:11:40 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: (Jake Hamby) Subject: Re: Sun Workshop compiler vs. GCC? Cc: hackers@FreeBSD.ORG, patrick@xinside.com, avalon@coombs.anu.edu.au, terry@lambert.org, jkh@time.cdrom.com Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Jake Hamby; On 15-Feb-97 you wrote: ... > Is there some PC UNIX that _does_ have a boot splash screen? Last I have seen SVR4.2 (Unixware 2.2?), it had room for a bitmap that was thrown by the boot loader onto the VGA screen. The one I saw had the USL (anyone remember who they were?). I also saw one with a red Novell display. Is this whqt you refer to? . > I also suggest that FreeBSD add a splash screen with clearly printed > directions on how to bypass it to see the hardware probes underneath. We > could also add a custom FreeBSD logo to the CDE and/or XFree86 startup > sequences. We could play .AU files while the system is starting up (as Sun > does with the Netra), or go all the way and create an X-basedinstallation > program (as Solaris and some Linux distributions do). I would recommend that we put at least a blinking pixel, or dot, or continue the spinning dash, or some such as it is nerve wrecking to sit and wait for the boot to finish, not knowing ``has it crashed, hung, or just slow?'' Simon From owner-freebsd-hackers Sat Feb 15 19:02:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA07907 for hackers-outgoing; Sat, 15 Feb 1997 19:02:40 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA07865 for ; Sat, 15 Feb 1997 19:02:19 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id UAA22637; Sat, 15 Feb 1997 20:01:11 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199702160006.QAA26620@freefall.freebsd.org> Date: Sat, 15 Feb 1997 19:46:22 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: Darren Reed Subject: Re: Sun Workshop compiler vs. GCC? Cc: hackers@freebsd.org, (Jake Hamby) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Darren Reed; On 16-Feb-97 you wrote: ... > Another take on starting up is HP-UX 10. Being SVR4, it has run levels > and start/stop scripts. HP have added "startmsg" and "stopmsg" to all > their scripts, so that when you boot, it prints a menu type listing and > displays "OK", "BUSY", "N/A", "FAIL" in the little check box for each > rc script. With about 16 per screen, it clears the screen when it gets to > the bottom and presents a new menu. It _looks_ very professional and is > very informative (stderr/stdout for all rc scripts goes to a file). Now, this is a GOOD idea. Simon From owner-freebsd-hackers Sat Feb 15 19:28:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA09210 for hackers-outgoing; Sat, 15 Feb 1997 19:28:30 -0800 (PST) Received: from fallout.campusview.indiana.edu (fallout.campusview.indiana.edu [149.159.1.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA09199 for ; Sat, 15 Feb 1997 19:28:21 -0800 (PST) Received: from localhost (jfieber@localhost) by fallout.campusview.indiana.edu (8.8.5/8.8.5) with SMTP id WAA20562; Sat, 15 Feb 1997 22:27:48 -0500 (EST) Date: Sat, 15 Feb 1997 22:27:48 -0500 (EST) From: John Fieber To: Jake Hamby cc: hackers@freebsd.org Subject: Re: Sun Workshop compiler vs. GCC? In-Reply-To: <199702152232.OAA05103@lightside.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 15 Feb 1997, Jake Hamby wrote: > I also suggest that FreeBSD add a splash screen with clearly printed > directions on how to bypass it to see the hardware probes underneath. The windows 95 splash screen disappears at the press of Escape, revealing whatever is going on on the console (not much usually). I'd hazzard a guess that anyone clever enough to know what the FreeBSD probe messages mean is probably clever enough to figure out "Escape" within about 4 keystrokes. :) -john From owner-freebsd-hackers Sat Feb 15 19:33:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA09505 for hackers-outgoing; Sat, 15 Feb 1997 19:33:07 -0800 (PST) Received: from lightside.com (hamby1.lightside.net [207.67.176.17]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA09499 for ; Sat, 15 Feb 1997 19:33:02 -0800 (PST) Received: by lightside.com (SMI-8.6/SMI-SVR4) id TAA05777; Sat, 15 Feb 1997 19:33:15 -0800 Date: Sat, 15 Feb 1997 19:33:15 -0800 From: jehamby@lightside.com (Jake Hamby) Message-Id: <199702160333.TAA05777@lightside.com> To: jb@cimlogic.com.au Subject: Re: Threads question Cc: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: Y6LUyfnpPIR+b4kJ0+MD9Q== Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk John Birrell writes: > Jake Hamby wrote: > [...] > > Anyway, just wanted to solicit any advice on the best thread library to use > > for a FreeBSD (or Linux) port of my toolkit, when it is finished. I've > > decided to start with a Solaris version, simply because I have access to it > > (on SPARC and x86), and it has VERY good documentation on the thread > > functions supported, the differences between Solaris and POSIX threads, and > > the thread-safeness of each library function. IMHO, this is one area where > > FreeBSD is very weak. Comments? > > Try FreeBSD's libc_r. It is in -current and not built by default. It has > all the things you mention except semaphores (which can be implemented > with a condition variable and a mutex). Even the non-POSIX suspend/resume > functions are there! They were added to support the JDK port. > > Your comment on thread-safeness for the libc functions is valid, though. 8-( > > Can't comment about Linux 'cause I've never used it (and due to GPL, never > will). Thanks for the quick response! I knew about libc_r already, but I've never used it for a project. And I was too lazy to log into a FreeBSD box to look at the man pages. But mostly, I wanted to know if there were any thread packages I _didn't_ already know about that might be better. For example, "green threads", which Sun used for Java. I assume those must support suspend/resume, if the JDK uses them? At least on Solaris, there's a big advantage to using Solaris threads over green threads: Concurrency on MP systems. That's why Sun now has a version of the JDK which uses Solaris threads. Alas, I don't have access to an MP Solaris box to test that tricky aspect of my program. Anyway, I've decided that MT programming is tricky business as it is, and I'd rather choose the simplest, most well-documented OS to start with, then AFTER I'M FINISHED, consider porting to another box. For me, Solaris is the best choice to work with, but I'm glad to hear that FreeBSD's libc_r is capable. That will definitely be the second OS I support (and then Linux maybe six months after that ). I don't want to say too much about what I'm writing at this early date, but let's just say that when I'm done you'll have a "cross-platform" thread library for C++ ... and some other stuff. -- Jake Hamby From owner-freebsd-hackers Sat Feb 15 19:35:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA09688 for hackers-outgoing; Sat, 15 Feb 1997 19:35:11 -0800 (PST) Received: from n4hhe.ampr.org (max12-21.HiWAAY.net [208.147.148.21]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA09674 for ; Sat, 15 Feb 1997 19:35:01 -0800 (PST) Received: from nexgen (localhost [127.0.0.1]) by nexgen.ampr.org (8.8.5/8.8.4) with ESMTP id VAA28629; Sat, 15 Feb 1997 21:33:17 -0600 (CST) Message-Id: <199702160333.VAA28629@nexgen.ampr.org> X-Mailer: exmh version 1.6.9 8/22/96 To: jdp@polstra.com (John Polstra) Cc: freebsd-hackers@freebsd.org From: dkelly@hiwaay.net Subject: Just CVS (was Re: CVS question, sendmail, named) In-reply-to: Message from jdp@polstra.com (John Polstra) of "14 Feb 1997 18:05:36 PST." <5e35lg$k3k@austin.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Feb 1997 21:33:17 -0600 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk John Polstra wrote: > > Joerg already answered this. But it's a confusing topic, so I'm > sure he won't mind if I give you more of a step-by-step answer. I'm certainly confused. > The first time you check out your tree (from scratch), do this: > > cd /usr > cvs co -P -r RELENG_2_2 src > > Your whole tree is now at -2.2. Now to switch your sendmail to > the -current version: Asked essentially the same question I'm going to ask again last week on -current but apparently didn't ask right because I didn't get a workable solution. As a total CVS novice (who has a backup of his source tree) I attempted the above example and got complaints about lacking a CVSROOT. nexgen: {12} cd /usr nexgen: {13} cvs co -P -r RELENG_2_2 src cvs: in directory .: cvs: must set the CVSROOT environment variable cvs: or specify the '-d' option to cvs. cvs [co aborted]: You don't have a CVSROOT environment variable nexgen: {14} This is a quick way to get almost the exact same error message as I got attempting to roll my own release (2.2-GAMMA, sometime last week). It was suggested that I'd have the CVS stuff if I used cvsup to be current. So I studied /usr/share/examples/cvsup/cvs-supfile. I *think* it required slight modifications. This is my cvsup-2.2 with comments removed: *default host=cvsup2.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs tag=RELENG_2_2 *default delete use-rel-suffix *default compress src-all ports-all tag=. Think I needed the tag= items to get the proper files? And I changed prefix so it would act on /usr/src and /usr/ports without moving them to /home/ncvs. Maybe this was a mistake? So back to the original question: I'm lacking a CVSROOT and I don't have a ~/.cvsrc. How to I get there from here? Is there something I need in addition to src-all in my cvsup file? -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-hackers Sat Feb 15 19:37:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA09837 for hackers-outgoing; Sat, 15 Feb 1997 19:37:50 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA09826 for ; Sat, 15 Feb 1997 19:37:40 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id TAA11840; Sat, 15 Feb 1997 19:37:59 -0800 (PST) Message-Id: <199702160337.TAA11840@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: jehamby@lightside.com (Jake Hamby) cc: hackers@freebsd.org Subject: Re: Threads question In-reply-to: Your message of "Sat, 15 Feb 1997 15:46:45 PST." <199702152346.PAA05346@lightside.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Feb 1997 19:37:59 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk You can use the FreeBSD libc_r thread and if you have any problems just detailed to: John Birrell He has done an excellent job and is very responsive. Regards, Amancio From owner-freebsd-hackers Sat Feb 15 19:38:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA09905 for hackers-outgoing; Sat, 15 Feb 1997 19:38:56 -0800 (PST) Received: from lightside.com (hamby1.lightside.net [207.67.176.17]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA09900 for ; Sat, 15 Feb 1997 19:38:53 -0800 (PST) Received: by lightside.com (SMI-8.6/SMI-SVR4) id TAA05806; Sat, 15 Feb 1997 19:38:35 -0800 Date: Sat, 15 Feb 1997 19:38:35 -0800 From: jehamby@lightside.com (Jake Hamby) Message-Id: <199702160338.TAA05806@lightside.com> To: jehamby@lightside.com, jfieber@indiana.edu Subject: Re: boot messages (was: Sun Workshop compiler vs. GCC?) Cc: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: HAOkGltzm/PeYOudgRJA9Q== Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk John Fieber writes: > On Sat, 15 Feb 1997, Jake Hamby wrote: > > > I also suggest that FreeBSD add a splash screen with clearly printed > > directions on how to bypass it to see the hardware probes underneath. > > The windows 95 splash screen disappears at the press of Escape, > revealing whatever is going on on the console (not much usually). > I'd hazzard a guess that anyone clever enough to know what the > FreeBSD probe messages mean is probably clever enough to figure > out "Escape" within about 4 keystrokes. :) Yes, but as has already been mentioned, the device probes are run with interrupts off, which means the keyboard press can't be detected? In which case I suggest we simply add a boot option to the kernel to disable the splash screen, or perhaps overload "-v". Then you can simply put, in small print at the bottom of the splash screen, "To disable this startup screen, boot with '-v'." Sounds good? -- Jake From owner-freebsd-hackers Sat Feb 15 20:39:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA12459 for hackers-outgoing; Sat, 15 Feb 1997 20:39:36 -0800 (PST) Received: from fog.xinside.com (fog.xinside.com [199.164.187.39]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA12438; Sat, 15 Feb 1997 20:39:23 -0800 (PST) Received: (from smap@localhost) by fog.xinside.com (8.8.3/8.7.3) id VAA08320; Sat, 15 Feb 1997 21:38:00 -0700 (MST) X-Authentication-Warning: fog.xinside.com: smap set sender to using -f Received: from string.xinside.com(199.164.187.131) by fog.xinside.com via smap (V1.3) id sma008318; Sat Feb 15 21:37:37 1997 Message-ID: <33068F05.708D5F1B@xinside.com> Date: Sat, 15 Feb 1997 21:37:25 -0700 From: Jeremy Chatfield Organization: X Inside Incorporated X-Mailer: Mozilla 3.01Gold (X11; I; Linux 1.2.13 i586) MIME-Version: 1.0 To: hm@kts.org CC: FreeBSD-hackers@freebsd.org, FreeBSD-current@freebsd.org Subject: Re: pcvt/132 columns References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hellmuth Michaelis wrote: > ... It would be nice if the Xserver > would contain a hook to let programs like this run automatically. > > hellmuth > -- > hellmuth michaelis hm@kts.org hamburg, europe I missed the beginning of this, so apologies if my assumption is incorrect. I am assuming that you are probably complaining about a situation in which X Servers do not return to the text mode you selected, after setting up VT's with a nonstandard (not 80x25) text mode resolution. Bear with me, while I describe some background, and then make a proposal that should make FreeBSD a nicer VT environment than any of the others ;-) We (Xi Graphics) have run into this request on several OS's, so we've looked at it several times. The following suggestion is, however, completely my own idea. Thomas Roell appears to hate it (mostly, I think, because it would mean more OS-specific work for him!) Graphics boards have a BIOS, with a bunch of common functions. One of those functions permits switching text resolutions. The switch is made by directly programming graphics chip and DAC, with no knowledge of the changes to anything external to the BIOS. Switching to a nonstandard resolution *might* (it depends on lots of factors) require programming a write-only register. Depending upon the values of certain registers, a switch to any specific resolution may not be safe, if one of these write-only registers has had certain values stuffed into it. There's always a way to switch back to 'standard' 80x25 mode, though. That's always a safe transition. It is often possible to select many modes using a common clock, which is something that we take advantage of, on Linux. A 'safe' switch, is one in which the graphics board won't lock up the system tight. It is possible to make a system stop dead, totally locked up, buffers unflushed, with an unsafe switch. We think that this is unacceptable. Very few modern graphics boards exhibit the problem. It was much more common on boards that were popular about five years ago. However, graphics boards have a long life, especially on server systems. We think it is prudent to design for worst case, rather than best case. If the BIOS is used to switch to non-standard resolution, then another program should really use the BIOS to switch resolutions to something safe; then the BIOS can set up the registers as it wants and safely switch around. IMO it would be better to have never used the BIOS for a mode switch at all... There are many ways to program a graphics board to give a particular text resolution. It should be possible to write conflicting programs that will interfere when they alternately set up a text mode or a graphics mode switch. With the older boards, it is therefore possible to set up scenarios where those boards will lock up the system, persistently. On UNIX System V Release 4 derivatives, it is possible to start a Virtual Terminal Layer Manager. This can be configured to run a shell script the first time that a VT is switched to. I used to use that to select screen colours. SVR4 also has an ioctl() to control screen text resolution. This ioctl is quite limited, as implemented, but does allow selecting between 80x25, 40x25, 80x43 and perhaps 132x25, if I remember correctly. There was no way to use the BIOS in SVR4 boot or operation, so the ioctl, if conservative, was quite safe. Linux, during bootstrap, before the Linux kernel is running, can have the bootstrap loader set a non-standard resolution. This uses BIOS calls, which are not really accessible once Linux is running. An alternative method is to use a "setvgamode" program. Since this has local knowledge about how it programmed registers, it potentially (if correctly programmed to do so, etc) can be safely used to select and reselect different text modes. However, there is also local knowledge in the X Server about graphics and text switches. There is no guarantee that the knowledge is synchronised, so with certain graphics chips and boards, it may be possible to risk a state in which the machine is locked up. The effect may not be common, but it is possible. This is because the setvideomode program could assume one set of knowledge about how to switch to a certain state, and the X Server can assume a different set of knowledge. Each program running alone would be safe, but the two together are a hazard. We've ended up with our Linux Server deciding what modes are safe, and if it *can* preserve text modes, it will do so, but if it decides that the mode switch involves a possibly dangerous operation, it forces a return to 80x25, which can result in an unpleasant mess on screen, but at least leaves the system consistently running, rather than risking an abrupt halt. What I'd like to see in FreeBSD, are a more complete set of things for handling VT's. Fortunately, I think that the functions can be split to make it manageable, though I'll admit I've no intention of doing any of this work ;-) There are many ways to create a more flexible, more fully featured and safer VT switching mechanism than those in SVR4 and Linux. Here are some desirable characteristics: 1/ doesn't permit VGA BIOS control over switching, at all. 2/ uses a consistent body of knowledge for switching to a mode. 3/ assumes that all switches that it does not make, will be returned to a safe mode. 4/ is triggered whenever switching to a specific VT. 5/ has VT specific configuration modes. 6/ may use a VGA library, if one is present, so that games and other non-X graphics, can use a common knowledge base for safer switching. I think that this means either an ioctl(), perhaps with a user level daemon that does the work, or possibly, using the X approach, an entirely user level process, perhaps connected to a virtual terminal manager. Features that I'd expect in the VT manager, include: a) initialisation program on first switching to a VT. This could be used to start a system monitor whenever there's no process on a prticular VT, or to start a login program only when switching to that VT for the first time (or when there's no controlling program for that VT). b) a program that is run each time the screen is switched to; this could be used for setting odd modes. c) optional mode setting on each VT switch. For example, this would permit a switch from the X Server to go to 80x25 on VT1, and then the VT manager would catch the switch and reselect 132x25 with a blue background and yellow text with Cyrillic font. d) experiment mode, in which various modes could be tried and safe ones marked for use in a per system restrictions file, for use by the configuration program. This should be run by the System Admin, so that users can only select between modes that do not upset the screen or graphics board and risk system integrity. e) screen driven configuration program, feeding a plain text file to allow easy per-system and per-user configurations of modes and programs. The key points that I'm trying to make, are that it should not be the responsibility of the X Server to guess what knowledge base was used to set up a text mode, and that this is reasonably a function of an Operating System (providing controlled access to a shared resource). Once you start to think like that, wider solutions with more features are possible. Cheers, JeremyC. -- Jeremy Chatfield, Phone: +1 303/298-7478 FAX:+1 303/298-1406 Commercial X Products - for sales/support/information please try: http://www.xinside.com/ mailto:info@xinside.com ftp://ftp.xinside.com Xi Graphics, 1801 Broadway, 17th Floor, Denver, CO 80202 From owner-freebsd-hackers Sat Feb 15 22:25:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA15257 for hackers-outgoing; Sat, 15 Feb 1997 22:25:44 -0800 (PST) Received: from pahtoh.cwu.edu (root@pahtoh.cwu.edu [198.104.65.27]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id WAA15252 for ; Sat, 15 Feb 1997 22:25:42 -0800 (PST) Received: from opus.cts.cwu.edu (skynyrd@opus.cts.cwu.edu [198.104.92.71]) by pahtoh.cwu.edu (8.6.13/8.6.9) with ESMTP id WAA06737; Sat, 15 Feb 1997 22:25:41 -0800 Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.8.5/8.8.5) with SMTP id WAA22174; Sat, 15 Feb 1997 22:25:40 -0800 (PST) Date: Sat, 15 Feb 1997 22:25:39 -0800 (PST) From: Chris Timmons To: dkelly@hiwaay.net cc: John Polstra , freebsd-hackers@FreeBSD.ORG Subject: Re: Just CVS (was Re: CVS question, sendmail, named) In-Reply-To: <199702160333.VAA28629@nexgen.ampr.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk David, The example that John gave depended on the fact that user has a copy of the FreeBSD CVS repository on the local machine in the directory pointed at by the CVSROOT environment variable. Most users don't need to do this, as the repository contains the information necessary to reconstruct every version of every source file that is/was part of FreeBSD since 2.0-R. Right now that is about 345MB worth! What you can do instead is use John's CVSup tool to operate on copies of the CVS repository maintained on the various CVSup mirror machines; see the discussion in section 17.2 of the FreeBSD handbook (www.freebsd.org), and have a look at the examples in /usr/share/examples/cvsup on your system. Using CVSup it is very easy to track a particular revision of the _entire_ source tree, by specifying a 'tag=' in your cvsupfile. John would have to tell you if it would be possible to update most of your tree to one revision, while updating another portion (eg sendmail) to another, as in the example which used cvs and the local copy of the repository. If you have some extra disk space and want to play with the CVS repository, start with a copy from the most recent FreeBSD cd-rom you have (hopefully 2.1.6), and then have a look at the cvs-supfile example in /usr/share/examples/cvsup. Once you get that going, you could point CVSROOT at it, and then be able to manipulate your source tree in the manner described. Hope this helps, -Chris p.s. try cvsup5 for your CVSup adventures, it's fast :) From owner-freebsd-hackers Sat Feb 15 23:02:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA16674 for hackers-outgoing; Sat, 15 Feb 1997 23:02:57 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA16668 for ; Sat, 15 Feb 1997 23:02:53 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.5/8.8.4) with SMTP id XAA08177; Sat, 15 Feb 1997 23:01:11 -0800 (PST) Date: Sat, 15 Feb 1997 22:59:13 -0800 (PST) From: Julian Elischer To: Charles Mott cc: freebsd-hackers@freebsd.org Subject: Re: User ppp keepalive logic In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 15 Feb 1997, Charles Mott wrote: > I was thinking it would be a good idea to only run keepalive logic on > incoming packets and not outgoing packets in user ppp. > > With one ISP I use, I often run into a situation where the link hangs up, > and no communication is possible, but user ppp thinks everything is ok. > Unfortunately the link stays alive, because I have a mailer that keeps > trying to look at an imap server, or a Win95 box on the local network is > doing something stupid. > > If the keepalive only worked on incoming packets, it would handle the > error condition where packets go out but never come back. > > I am going to do this for my own purposes, but I wondered whether people > felt it might be a good idea for the freebsd distribution. Charles, check out mpd (multilink ppp daemon) in ftp.freebsd.org pub/FreeBSD/incoming > > Charles Mott > I'm not sure which version is there at the miment, but I know archie was doing quite a bit with this problem... failing that, I'd definitly have a word with him about it.. I believe he's gone to vegas for the weekend ;) but he'll be back tuesday julian > >