From owner-freebsd-hackers Sun Feb 9 00:14:40 1997
Return-Path: <owner-hackers>
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 <hackers@freebsd.org>; 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 <luigi@labinfo.iet.unipi.it>
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: <owner-hackers>
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 <bde@zeta.org.au>
From: Eivind Eklund <eivind@dimaga.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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" <danny@panda.hilink.com.au>
To: hackers@freebsd.org
Subject: Chalmers.com.au mysterious problem.
Message-ID: <Pine.BSF.3.91.970209214921.427M-100000@panda.hilink.com.au>
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 <robert@nanguo.chalmers.com.au>
To: Daniel O'Callaghan <danny@panda.hilink.com.au>
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 <mss 1460> (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 <mss 1460> (DF)
15:16:25.959225 skylark.hilink.com.au.3634 > nanguo.chalmers.com.au.http: S 1706172429:1706172429(0) win 16384 <mss 1460> (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 <mss 1460> (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: <owner-hackers>
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 <hackers@freebsd.org>; 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" <danny@panda.hilink.com.au>
To: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
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: <Pine.BSF.3.91.970209215631.427N-100000@panda.hilink.com.au>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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> <Mutt.19970208171621.j@uriah.heep.sax.de>
X-Mailer: Mutt 0.60,1-3,9
Mime-Version: 1.0
X-Operating-System: FreeBSD 3.0-CURRENT ctm#2999
In-Reply-To: <Mutt.19970208171621.j@uriah.heep.sax.de>; 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: <owner-hackers>
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 <hackers@freebsd.org>; 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: <Mutt.19970209122802.j@uriah.heep.sax.de>
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: <owner-hackers>
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 <freebsd-hackers@freefall.freebsd.org>; 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: <Mutt.19970209144704.j@uriah.heep.sax.de>
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: <smzKzua00YVpEcONQY@andrew.cmu.edu>
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: <smzKzua00YVpEcONQY@andrew.cmu.edu>; 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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <davidn@labs.usn.blaze.net.au>
To: Andreas Klemm <andreas@klemm.gtn.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <davidn@labs.usn.blaze.net.au>
To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
Cc: hackers@freebsd.org
Subject: Re: should permissions of /usr/bin/login be changed to 0100 ???
References: <19970208135454.ZJ37734@klemm.gtn.com> <Mutt.19970209122802.j@uriah.heep.sax.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.61
In-Reply-To: <Mutt.19970209122802.j@uriah.heep.sax.de>; 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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <snar@lucky.net>
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'9<F(0D516@(2K::ZW^_75!O?FGSH;[<7"K,)`*QBV=W'P#+)9SPVZ@F\XRG
MO=J0#:/1M!J]>N'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_<!=EI:#/P&,]EN821!=R?.RD?,(RR?,IC9AAPKLB2WE8!3"2!!22A(Q)
MEDU87$44,N*QF--.NQWG7*00IC&,)0.>@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^$,>Z<G$LRN9Q/
M!E"1!KLLS,>X=6C9:7NH+8=!2-'-[W#99FXI)M#(*`FGCR()HT$J[A(6]QCA
MOB\V,5=>(FTYQA<EXY@M,2%F$Y:($09P.WVZPPE@N<EU.&'9@"5LJECDN-.1
MV")8D4D5[%X56HPKD@@M#8?LF;.3BJ58[;G'6/-8,<1;1FS@H@E@:8PR1@1A
M1$.1LWED$@/)$#Z&+@J>Y6UVDD".6$3G"*=R.F`9G:"T.$M2SA:-Y@3GM@^^
M>QI<&9X%V&][[J7=M)IP<HU""SSKS&H%/ABM)IAN*_#LDT[@>C[\\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+,<WPT3FS'#JZ50Z=VT")SIVC/@+;A!;;9<0P/
MVAVO[?H*C>)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<R@LP;.;BJ2W9:*&4ER
MO6O")3[4&NAP=6[AN$><*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#G<WCLJO\6RC
MH1H1,[.AD@RF<R#XF2M%_H(/<BIK$9J7U?['U6%5SM%8>2)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?$<UCY&P>\P^6!_Y6(+*`>>86[#W*1E'@VDU9?G'=<6_KOC_I.+_HR(X'./J
M9D\+X#"=HL_;_U<U\#.GY%LNA7^:XC%1*_;SNA3^^Y7"136\4H1N-*U3O]K?
M6!GQK]4`+H%W_:#VPY)S-);]!-ZPVU&Y-!23HJN_8>']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<W
MU%ANALGC6^N8BT=#4YF(WL.Q29B%64_=>-<VX9^4]08<WRR4'O!D1TRJU!B%
MQ=\.\>T>#4!]?T@H"F%U7M%'NM<M+^Z?EY?7Q>M#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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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: <Mutt.19970209171329.j@uriah.heep.sax.de>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <gclarkii@main.gbdata.com>
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: <Pine.BSF.3.91.970209214921.427M-100000@panda.hilink.com.au> 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: <owner-hackers>
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: <owner-hackers>
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 <mt@CNS.UCLA.EDU>
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: <Pine.A32.3.95.970209095322.17585F-100000@quark.cns.ucla.edu>
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: <owner-hackers>
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 <freebsd-hackers@freefall.FreeBSD.org>; 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 </afs/andrew.cmu.edu/service/mailqs/q005/QF.8mzVLpW00YVpI0O0F5>;
Sun, 9 Feb 1997 13:22:45 -0500 (EST)
Received: from apriori.cc.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr4/rnw/.Outgoing/QF.EmzVLoW00YVpAZzH1c>;
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: <UmzVLnW00YVp8ZzGp=@andrew.cmu.edu>
Date: Sun, 9 Feb 1997 13:22:43 -0500 (EST)
From: Robert N Watson <rnw+@andrew.cmu.edu>
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: <owner-hackers>
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 <freebsd-hackers@freefall.FreeBSD.org>; 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 </afs/andrew.cmu.edu/service/mailqs/q002/QF.0mzVNWi00YVp80O0J3>;
Sun, 9 Feb 1997 13:24:34 -0500 (EST)
Received: from apriori.cc.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr4/rnw/.Outgoing/QF.8mzVNWC00YVp0ZzHxy>;
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: <wmzVNW200YVpMZzHlT@andrew.cmu.edu>
Date: Sun, 9 Feb 1997 13:24:34 -0500 (EST)
From: Robert N Watson <rnw+@andrew.cmu.edu>
To: freebsd-hackers@freefall.FreeBSD.org,
joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Subject: Re: Thoughts on upgrade process
In-Reply-To: <Mutt.19970209144704.j@uriah.heep.sax.de>
References: <smzKzua00YVpEcONQY@andrew.cmu.edu>
<Mutt.19970209144704.j@uriah.heep.sax.de>
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: <owner-hackers>
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 <jhay@zibbi.mikom.csir.co.za>
Message-Id: <199702091840.UAA13916@zibbi.mikom.csir.co.za>
Subject: Re: IPXrouted[64]: socket: Protocol not supported
In-Reply-To: <Pine.A32.3.95.970209095322.17585F-100000@quark.cns.ucla.edu> 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: <owner-hackers>
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 <freebsd-hackers@freefall.FreeBSD.org>; 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 <freebsd-hackers@freefall.cdrom.com>; 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 <ponds!rivers@dg-rtp.dg.com>
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: <owner-hackers>
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 <freebsd-hackers@freefall.FreeBSD.org>; 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 <ponds!rivers@dg-rtp.dg.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <eivind@dimaga.com>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <dwhite@gdi.uoregon.edu>
X-Sender: dwhite@localhost
Reply-To: Doug White <dwhite@resnet.uoregon.edu>
To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
cc: FreeBSD hackers <freebsd-hackers@freebsd.org>
Subject: Re: ASUS MB panics
In-Reply-To: <Mutt.19970208164755.j@uriah.heep.sax.de>
Message-ID: <Pine.BSI.3.94.970209113508.4185G-100000@localhost>
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: <owner-hackers>
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 <mt@CNS.UCLA.EDU>, questions@freebsd.org,
hackers@freebsd.org
From: Allen Hyer <allenh@wtrt.net>
Subject: Re: IPXrouted[64]: socket: Protocol not supported
Cc: scott@ctns.ucla.edu
In-Reply-To: <Pine.A32.3.95.970209095322.17585F-100000@quark.cns.ucla.ed
u>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <terry@lambert.org>
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: <owner-hackers>
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 <freebsd-hackers@FreeBSD.ORG>; 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 <terry@lambert.org>
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: <owner-hackers>
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 <freebsd-hackers@FreeBSD.ORG>; 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 <terry@lambert.org>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <terry@lambert.org>
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: <owner-hackers>
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 <freebsd-hackers@FreeBSD.ORG>; 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: <Mutt.19970209215020.j@uriah.heep.sax.de>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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" <danny@panda.hilink.com.au>
To: Gary Clark II <gclarkii@main.gbdata.com>
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: <Pine.BSF.3.91.970210082542.427R@panda.hilink.com.au>
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: <owner-hackers>
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" <danny@panda.hilink.com.au>
To: Andreas Klemm <andreas@klemm.gtn.com>
cc: David Nugent <davidn@labs.usn.blaze.net.au>, 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: <Pine.BSF.3.91.970210083351.427T-100000@panda.hilink.com.au>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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: <Mutt.19970209220222.j@uriah.heep.sax.de>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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: <Mutt.19970209221010.j@uriah.heep.sax.de>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <jehamby@lightside.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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: <Mutt.19970210002159.j@uriah.heep.sax.de>
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: <owner-hackers>
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 <freebsd-hackers@FreeBSD.org>; 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 <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
CC: FreeBSD hackers <freebsd-hackers@FreeBSD.org>,
Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
Subject: Re: daily panics, ffs_valloc: dup alloc - Good news!
References: <199702091853.NAA24339@lakes.water.net> <Mutt.19970209221010.j@uriah.heep.sax.de>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <cmott@srv.net>
X-Sender: cmott@darkstar
To: freebsd-hackers@freebsd.org
Subject: Bus Errors
Message-ID: <Pine.BSF.3.91.970209174624.3664A-100000@darkstar>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
CC: FreeBSD hackers <freebsd-hackers@freebsd.org>,
Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
Subject: Re: Copious information on panic: ffs_valloc: dup alloc - IDEAS???
References: <199702091818.NAA23739@lakes.water.net> <Mutt.19970209220222.j@uriah.heep.sax.de>
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: <owner-hackers>
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 <freebsd-hackers@freefall.freebsd.org>; 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 <msmith@atrad.adelaide.edu.au>
Message-Id: <199702100114.LAA20190@genesis.atrad.adelaide.edu.au>
Subject: Re: Thoughts on upgrade process
In-Reply-To: <wmzVNW200YVpMZzHlT@andrew.cmu.edu> 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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <jamie@inna.net>
To: Charles Mott <cmott@srv.net>
cc: freebsd-hackers@freebsd.org
Subject: Re: Bus Errors
In-Reply-To: <Pine.BSF.3.91.970209174624.3664A-100000@darkstar>
Message-ID: <Pine.BSF.3.91.970209203020.4128A-100000@dolphin.inna.net>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <michaelh@cet.co.jp>
To: Alexander Snarskii <snar@lucky.net>
cc: freebsd-hackers@freebsd.org
Subject: Re: Increasing overall security....
In-Reply-To: <199702091525.RAA05048@burka.carrier.kiev.ua>
Message-ID: <Pine.SV4.3.95.970210103603.19450A-100000@parkplace.cet.co.jp>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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" <danny@panda.hilink.com.au>
To: hackers@freebsd.org
Subject: ipfw command line - opinions wanted.
Message-ID: <Pine.BSF.3.91.970210134608.427Y-100000@panda.hilink.com.au>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <cmott@srv.net>
X-Sender: cmott@darkstar
To: Jamie Bowden <jamie@inna.net>
cc: freebsd-hackers@freebsd.org
Subject: Re: Bus Errors
In-Reply-To: <Pine.BSF.3.91.970209203020.4128A-100000@dolphin.inna.net>
Message-ID: <Pine.BSF.3.91.970209195200.3742A-100000@darkstar>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <nate@mt.sri.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Daniel O'Callaghan" <danny@panda.hilink.com.au>
Cc: hackers@freebsd.org
Subject: Re: ipfw command line - opinions wanted.
In-Reply-To: <Pine.BSF.3.91.970210134608.427Y-100000@panda.hilink.com.au>
References: <Pine.BSF.3.91.970210134608.427Y-100000@panda.hilink.com.au>
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: <owner-hackers>
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 <raistlin@ecpnet.com>
To: David Nugent <davidn@labs.usn.blaze.net.au>
cc: Zach Heilig <zach@blizzard.gaffaneys.com>,
Leonard Chua <lenc@earth.infinetconsulting.com>,
freebsd-bugs@freebsd.org, freebsd-hackers@freebsd.org
Subject: Re: moused and X11R6
In-Reply-To: <19970208165555.12961@usn.blaze.net.au>
Message-ID: <Pine.BSF.3.95.970209221112.2539A-100000@chaos.ecpnet.com>
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: <owner-hackers>
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 <freebsd-hackers@FreeBSD.ORG>; 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 <davidn@labs.usn.blaze.net.au>
To: Justen Stepka <raistlin@ecpnet.com>
Cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: moused and X11R6
References: <19970208165555.12961@usn.blaze.net.au> <Pine.BSF.3.95.970209221112.2539A-100000@chaos.ecpnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.61
In-Reply-To: <Pine.BSF.3.95.970209221112.2539A-100000@chaos.ecpnet.com>; 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <softweyr@xmission.com>
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 <sys/types.h>
#include <unistd.h>
#include <syslog.h>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <dev@trifecta.com>
To: Charles Mott <cmott@srv.net>
cc: freebsd-hackers@freebsd.org
Subject: Re: Bus Errors
In-Reply-To: <Pine.BSF.3.91.970209174624.3664A-100000@darkstar>
Message-ID: <Pine.BSF.3.91.970210015430.4759A-100000@www.trifecta.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <tom@sdf.com>
To: Wes Peters <softweyr@xmission.com>
cc: hackers@freebsd.org
Subject: Re: 'nologin' program for disabling user accounts
In-Reply-To: <199702100646.XAA06827@obie.softweyr.ml.org>
Message-ID: <Pine.NEB.3.94.970209144949.29838A-100000@misery.sdf.com>
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: <owner-hackers>
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 <ponds!rivers@dg-rtp.dg.com>
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 <phk@critter.dk.tfs.com>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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: <Mutt.19970210092904.j@uriah.heep.sax.de>
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> <Mutt.19970209220222.j@uriah.heep.sax.de> <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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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: <Mutt.19970210094131.j@uriah.heep.sax.de>
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 <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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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: <Mutt.19970210094622.j@uriah.heep.sax.de>
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: <Pine.BSF.3.91.970209174624.3664A-100000@darkstar>
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: <Pine.BSF.3.91.970209174624.3664A-100000@darkstar>; 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: <owner-hackers>
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 <freebsd-hackers@FreeBSD.ORG>; 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: <Mutt.19970210095933.j@uriah.heep.sax.de>
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: <Pine.BSF.3.91.970209203020.4128A-100000@dolphin.inna.net> <Pine.BSF.3.91.970209195200.3742A-100000@darkstar>
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: <Pine.BSF.3.91.970209195200.3742A-100000@darkstar>; 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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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: <Pine.BSF.3.91.970209203020.4128A-100000@dolphin.inna.net> 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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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: <Pine.BSF.3.95.970207225341.1517A-100000@why> 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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <ponds!rivers@dg-rtp.dg.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <ponds!rivers@dg-rtp.dg.com>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <ponds!rivers@dg-rtp.dg.com>
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: <owner-hackers>
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 <ponds!rivers@dg-rtp.dg.com>
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 <phk@critter.dk.tfs.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <cmott@srv.net>
From: Eivind Eklund <eivind@dimaga.com>
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: <owner-hackers>
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 <freebsd-hackers@freefall.FreeBSD.org>; 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 <freebsd-hackers@freefall.FreeBSD.org>; 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 <kuku@gilberto.physik.rwth-aachen.de>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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: <Mutt.19970112214937.j@uriah.heep.sax.de>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <ponds!rivers@dg-rtp.dg.com>
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: <owner-hackers>
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 <ponds!rivers@dg-rtp.dg.com>
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 <phk@critter.dk.tfs.com>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <snar@lucky.net>
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: <Pine.SV4.3.95.970210103603.19450A-100000@parkplace.cet.co.jp> 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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" <rcarter@consys.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <dwhite@gdi.uoregon.edu>
X-Sender: dwhite@localhost
Reply-To: Doug White <dwhite@resnet.uoregon.edu>
To: hackers@freebsd.org
cc: henryt2@ix.netcom.com
Subject: BSD216-syscall (fwd)
Message-ID: <Pine.BSI.3.94.970210095023.195E-100000@localhost>
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 <henryt2@ix.netcom.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <terry@lambert.org>
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: <Mutt.19970210002159.j@uriah.heep.sax.de> 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: <owner-hackers>
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 <freebsd-hackers@FreeBSD.ORG>; 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 <terry@lambert.org>
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: <Pine.BSF.3.91.970209174624.3664A-100000@darkstar> 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: <owner-hackers>
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 <hackers@freebsd.org>; 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" <rkw@dataplex.net>
To: "Russell L. Carter" <rcarter@consys.com>
Cc: hackers@freebsd.org
X-Mailer: Cyberdog/2.0a2
MIME-Version: 1.0
Message-Id: <AF24DE33-110BC7@204.69.236.50>
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
<mailto:rcarter@consys.com> 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <softweyr@xmission.com>
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: <Pine.NEB.3.94.970209144949.29838A-100000@misery.sdf.com> 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: <owner-hackers>
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 <rmike@sbox.tu-graz.ac.at>
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: <Pine.BSF.3.91.970210224003.256B-100000@dwarf.tu-graz.ac.at>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <michaelh@cet.co.jp>
To: Alexander Snarskii <snar@lucky.net>
cc: freebsd-hackers@freebsd.org
Subject: Re: Increasing overall security....
In-Reply-To: <199702101606.SAA08033@burka.carrier.kiev.ua>
Message-ID: <Pine.SV4.3.95.970211082337.25315G-100000@parkplace.cet.co.jp>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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: <Mutt.19970211012044.j@uriah.heep.sax.de>
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: <Pine.NEB.3.94.970209144949.29838A-100000@misery.sdf.com> <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: <owner-hackers>
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 <hackers@FreeBSD.org>; 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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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" <j_orthoefer@tia.net>
To: hackers@FreeBSD.org
Subject: Modifcation to user mode ppp
Message-ID: <Pine.BSF.3.95.970210191647.23696B-100000@mailbox.tia.net>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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 <dennis@etinc.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <tom@sdf.com>
To: Softweyr LLC <softweyr@xmission.com>
cc: hackers@freebsd.org
Subject: Re: 'nologin' program for disabling user accounts
In-Reply-To: <199702102140.OAA05879@xmission.xmission.com>
Message-ID: <Pine.NEB.3.94.970210090600.14735A-100000@misery.sdf.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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 <hasty@rah.star-gate.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <terry@lambert.org> 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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 <hasty@rah.star-gate.com>
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: <owner-hackers>
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 <freebsd-hackers@freefall.freebsd.org>; 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 <kuku@gilberto.physik.rwth-aachen.de>
cc: freebsd-hackers@freefall.freebsd.org
From: dkelly@hiwaay.net
Subject: Re: Freewin95 - just fyi
In-reply-to: Message from Christoph Kukulies <kuku@gilberto.physik.rwth-aachen.de>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <dk@dog.farm.org>
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 <bsd.*.mk> )
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <tony@nlanr.net>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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: <owner-hackers>
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 <freebsd-hackers@freefall.freebsd.org>; 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 <chuckr@glue.umd.edu>
X-Sender: chuckr@fiber.eng.umd.edu
To: dkelly@hiwaay.net
cc: Christoph Kukulies <kuku@gilberto.physik.rwth-aachen.de>,
freebsd-hackers@freefall.freebsd.org
Subject: Re: Freewin95 - just fyi
In-Reply-To: <199702110508.XAA18146@nexgen.ampr.org>
Message-ID: <Pine.OSF.3.95q.970211084633.1432C-100000@fiber.eng.umd.edu>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <ponds!rivers@dg-rtp.dg.com>
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: <owner-hackers>
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 <pechter@shell.monmouth.com>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <snar@lucky.net>
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: <Pine.SV4.3.95.970211082337.25315G-100000@parkplace.cet.co.jp> 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: <owner-hackers>
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 <freebsd-hackers@freefall.freebsd.org>; 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 <kuku@gilberto.physik.rwth-aachen.de>,
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 <imp@village.org>
Message-Id: <E0vuKAU-0006P6-00@rover.village.org>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <snar@lucky.net>
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 <imp@village.org>
Message-Id: <E0vuKJn-0006Ph-00@rover.village.org>
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: <owner-hackers>
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 <hackers@freefall.freebsd.org>; 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 <hackers@freefall.freebsd.org>; 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 <hackers@freefall.freebsd.org>; 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 <ajones@ctron.com>
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 <math.h>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <snar@lucky.net>
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: <E0vuKJn-0006Ph-00@rover.village.org> 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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <imp@village.org>
From: Eivind Eklund <eivind@dimaga.com>
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: <owner-hackers>
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 <hackers@freefall.freebsd.org>; 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 <bde@zeta.org.au>
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: <owner-hackers>
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: <v02130502af24f1e8a696@[128.29.114.90]>
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 <guhl@mitre.org>
The MITRE Corporation
From owner-freebsd-hackers Tue Feb 11 11:48:06 1997
Return-Path: <owner-hackers>
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 <markl@agis.net>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <spork@super-g.com>
X-Sender: spork@super-g.inch.com
To: dennis <dennis@etinc.com>
cc: hackers@freebsd.org
Subject: Re: 2.1.7R - soon?
In-Reply-To: <3.0.32.19970210202049.00a28320@etinc.com>
Message-ID: <Pine.BSF.3.95.970211144312.1164B-100000@super-g.inch.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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" <Dirk.vanGulik@jrc.it>
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: <owner-hackers>
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 <wollman@lcs.mit.edu>
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: <v02130502af24f1e8a696@[128.29.114.90]>
References: <v02130502af24f1e8a696@[128.29.114.90]>
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
<<On Tue, 11 Feb 1997 14:09:16 -0500, guhl@mitre.org (George Uhl) said:
> 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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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" <j_orthoefer@tia.net>
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."
<Pine.BSF.3.95.970210191647.23696B-100000@mailbox.tia.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 11 Feb 1997 20:57:41 +0000
From: Brian Somers <brian@awfulhak.demon.co.uk>
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 <brian@awfulhak.demon.co.uk>, <brian@freebsd.org>
<http://www.awfulhak.demon.co.uk/>
Don't _EVER_ lose your sense of humour....
From owner-freebsd-hackers Tue Feb 11 13:15:11 1997
Return-Path: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <freebsd-hackers@freebsd.org>); 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: <XFMail.970211141038.Shimon@i-Connect.Net>
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 <Shimon@i-Connect.Net>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <cmott@srv.net>
cc: Jamie Bowden <jamie@inna.net>, freebsd-hackers@freebsd.org
Subject: Re: Bus Errors
In-reply-to: Your message of "Sun, 09 Feb 1997 19:57:39 MST."
<Pine.BSF.3.91.970209195200.3742A-100000@darkstar>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 11 Feb 1997 20:50:25 +0000
From: Brian Somers <brian@awfulhak.demon.co.uk>
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 <brian@awfulhak.demon.co.uk>, <brian@freebsd.org>
<http://www.awfulhak.demon.co.uk/>
Don't _EVER_ lose your sense of humour....
From owner-freebsd-hackers Tue Feb 11 14:13:15 1997
Return-Path: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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 <hal@vailsys.com>
Reply-To: hal@vailsys.com
Organization: Vail Systems, Inc.
X-Mailer: Mozilla 3.0 (WinNT; I)
MIME-Version: 1.0
To: Peter da Silva <peter@taronga.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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 <dennis@etinc.com>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <terry@lambert.org>
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: <XFMail.970211141038.Shimon@i-Connect.Net> 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <luigi@labinfo.iet.unipi.it>
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: <owner-hackers>
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 <freebsd-hackers@FreeBSD.ORG>; 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: <Mutt.19970212000437.j@uriah.heep.sax.de>
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: <XFMail.970211141038.Shimon@i-Connect.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: <XFMail.970211141038.Shimon@i-Connect.Net>; 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: <owner-hackers>
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 <freebsd-hackers@FreeBSD.org>; 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 <freebsd-hackers@FreeBSD.org>; 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 <ponds!rivers@dg-rtp.dg.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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 <helbig@MX.BA-Stuttgart.De>
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: <owner-hackers>
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 <freebsd-hackers@freefall.freebsd.org>; 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 <msmith@atrad.adelaide.edu.au>
Message-Id: <199702112337.KAA08552@genesis.atrad.adelaide.edu.au>
Subject: Re: Freewin95 - just fyi
In-Reply-To: <E0vuKAU-0006P6-00@rover.village.org> 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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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" <Dirk.vanGulik@jrc.it>
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 <hasty@rah.star-gate.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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 <msmith@atrad.adelaide.edu.au>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <michaelh@cet.co.jp>
To: dennis <dennis@etinc.com>
cc: hackers@FreeBSD.ORG
Subject: Re: de0 - 100Mb setup
In-Reply-To: <3.0.32.19970211174133.00ab1934@etinc.com>
Message-ID: <Pine.SV4.3.95.970212100647.4003B-100000@parkplace.cet.co.jp>
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: <owner-hackers>
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 <freebsd-hackers@FreeBSD.org>; 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 <freebsd-hackers@FreeBSD.org>; 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 <michaelh@cet.co.jp>
To: dk+@ua.net
cc: Alexander Snarskii <snar@lucky.net>, freebsd-hackers@FreeBSD.org
Subject: Re: Increasing overall security....
In-Reply-To: <199702110604.WAA14933@dog.farm.org>
Message-ID: <Pine.SV4.3.95.970212103543.5799C-100000@parkplace.cet.co.jp>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <jb@cimlogic.com.au>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <bde@zeta.org.au>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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" <jkh@time.cdrom.com>
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 <jkh@freebsd.org>. 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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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" <mgessner@aristar.com>
Organization: Aristar, Inc.
X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.1.0-RELEASE i386)
MIME-Version: 1.0
To: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
CC: "Dirk.vanGulik" <Dirk.vanGulik@jrc.it>, 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, <mgessner@aristar.com>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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: <XFMail.970211233250.Shimon@i-Connect.Net>
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 <Shimon@i-Connect.Net>
To: Terry Lambert <terry@lambert.org>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: Terry Lambert <terry@lambert.org>
CC: Simon Shapiro <Shimon@i-Connect.Net>, 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; Tue, 11 Feb 1997 22:53:04 -0800 (PST)
Date: Tue, 11 Feb 1997 22:53:04 -0800 (PST)
From: Doug White <dwhite@gdi.uoregon.edu>
X-Sender: dwhite@localhost
Reply-To: Doug White <dwhite@resnet.uoregon.edu>
To: hackers@freebsd.org
Subject: Need definitive answer on de 21140-AC driver
Message-ID: <Pine.BSI.3.94.970211222507.743A-100000@localhost>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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" <danny@panda.hilink.com.au>
To: hackers@freebsd.org
Subject: strlen() question
Message-ID: <Pine.BSF.3.91.970212175317.427s-100000@panda.hilink.com.au>
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: <owner-hackers>
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 <vinay@agni.nuko.com>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <bde@zeta.org.au>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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: <Mutt.19970212093820.j@uriah.heep.sax.de>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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: <Mutt.19970212095013.j@uriah.heep.sax.de>
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: <Pine.BSI.3.94.970211222507.743A-100000@localhost>
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: <Pine.BSI.3.94.970211222507.743A-100000@localhost>; 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <bde@zeta.org.au>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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: <Mutt.19970212095452.j@uriah.heep.sax.de>
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: <Pine.BSF.3.91.970212175317.427s-100000@panda.hilink.com.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: <Pine.BSF.3.91.970212175317.427s-100000@panda.hilink.com.au>; 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: <owner-hackers>
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 <hackers@freebsd.org>; 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" <danny@panda.hilink.com.au>
To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
cc: hackers@freebsd.org
Subject: Re: strlen() question
In-Reply-To: <Mutt.19970212095452.j@uriah.heep.sax.de>
Message-ID: <Pine.BSF.3.91.970212204154.427x-100000@panda.hilink.com.au>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <davidn@labs.usn.blaze.net.au>
To: "Daniel O'Callaghan" <danny@panda.hilink.com.au>
Cc: hackers@freebsd.org
Subject: Re: strlen() question
References: <Pine.BSF.3.91.970212175317.427s-100000@panda.hilink.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.61
In-Reply-To: <Pine.BSF.3.91.970212175317.427s-100000@panda.hilink.com.au>; 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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <dufault@hda.com>
Message-Id: <199702121026.FAA11921@hda.hda.com>
Subject: Re: Raw I/O Question
In-Reply-To: <XFMail.970211233250.Shimon@i-Connect.Net> 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <msmith@atrad.adelaide.edu.au>
Message-Id: <199702121052.VAA13568@genesis.atrad.adelaide.edu.au>
Subject: Re: mdoc help?
In-Reply-To: <Mutt.19970212093820.j@uriah.heep.sax.de> 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: <owner-hackers>
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" <mishania@demos.su>
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: <owner-hackers>
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" <mishania@demos.su>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <jgreco@solaria.sol.net>
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: <no.id> 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: <owner-hackers>
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 <bde@zeta.org.au>
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: <owner-hackers>
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" <mishania@demos.su>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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: <Mutt.19970212145914.regnauld@deepo.prosa.dk>
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> <Pine.SV4.3.95.970212103543.5799C-100000@parkplace.cet.co.jp>
X-Mailer: Mutt 0.58
Mime-Version: 1.0
X-Operating-System: FreeBSD 2.2-BETA_A i386
In-Reply-To: <Pine.SV4.3.95.970212103543.5799C-100000@parkplace.cet.co.jp>; 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: <owner-hackers>
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==?= <ache@nagual.ru>
To: "Mikhail A. Sokolov" <mishania@demos.su>
Cc: hackers@freebsd.org, "Alex G. Bulushev" <bag@demos.su>,
current@freebsd.org
Subject: Re: upcoming version suggestions
In-Reply-To: <199702121121.OAA13512@megillah.demos.su>
Message-Id: <Pine.BSF.3.95q.970212175605.393C-100000@nagual.ru>
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
<ache@null.net>
http://www.nagual.ru/~ache/
From owner-freebsd-hackers Wed Feb 12 09:21:17 1997
Return-Path: <owner-hackers>
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 <hackers@freebsd.org>; 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 <terry@lambert.org>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <terry@lambert.org>
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: <Pine.SV4.3.95.970212103543.5799C-100000@parkplace.cet.co.jp> 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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <terry@lambert.org>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <terry@lambert.org>
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: <Pine.BSF.3.91.970212175317.427s-100000@panda.hilink.com.au> 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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <terry@lambert.org>
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: <XFMail.970211233250.Shimon@i-Connect.Net> 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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <hackers@FreeBSD.ORG>; 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 <markl@agis.net>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; Wed, 12 Feb 1997 12:01:31 -0800 (PST)
Date: Wed, 12 Feb 1997 12:01:31 -0800 (PST)
From: Chris Coleman <chris@bb.cc.wa.us>
To: hackers@freebsd.org
Subject: handbook in sgml
Message-ID: <Pine.NEB.3.94.970212120017.563B-100000@aries.bb.cc.wa.us>
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: <owner-hackers>
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 <freebsd-hackers@FreeBSD.org>; 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 <freebsd-hackers@FreeBSD.org>; 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 <snar@lucky.net>
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: <Pine.SV4.3.95.970212103543.5799C-100000@parkplace.cet.co.jp> 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>); 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <jmg@nike.efn.org>
Reply-To: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
To: Chris Coleman <chris@bb.cc.wa.us>
cc: hackers@freebsd.org
Subject: Re: handbook in sgml
In-Reply-To: <Pine.NEB.3.94.970212120017.563B-100000@aries.bb.cc.wa.us>
Message-ID: <Pine.BSF.3.95q.970212130627.24299f-100000@hydrogen.nike.efn.org>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <freebsd-hackers@freebsd.org>; 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: <Mutt.19970212145914.regnauld@deepo.prosa.dk> 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <chris@bb.cc.wa.us>
To: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
cc: hackers@freebsd.org
Subject: Re: handbook in sgml
In-Reply-To: <Pine.BSF.3.95q.970212130627.24299f-100000@hydrogen.nike.efn.org>
Message-ID: <Pine.NEB.3.94.970212134046.6997A-100000@aries.bb.cc.wa.us>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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: <Pine.NEB.3.94.970212120017.563B-100000@aries.bb.cc.wa.us>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
In article <Pine.NEB.3.94.970212120017.563B-100000@aries.bb.cc.wa.us>,
Chris Coleman <chris@bb.cc.wa.us> 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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <michaelh@cet.co.jp>
To: Terry Lambert <terry@lambert.org>
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: <Pine.SV4.3.95.970213073812.12287A-100000@parkplace.cet.co.jp>
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: <owner-hackers>
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 <freebsd-hackers@FreeBSD.org>; 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 <michaelh@cet.co.jp>
To: Alexander Snarskii <snar@lucky.net>
cc: dk+@ua.net, freebsd-hackers@FreeBSD.org
Subject: Re: Increasing overall security....
In-Reply-To: <199702122023.WAA21544@burka.carrier.kiev.ua>
Message-ID: <Pine.SV4.3.95.970213074440.12287B-100000@parkplace.cet.co.jp>
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: <owner-hackers>
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 <helbig@MX.BA-Stuttgart.De>
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: <owner-hackers>
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 <freebsd-hackers@FreeBSD.org>; 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" <mrm@Mole.ORG>
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: <owner-hackers>
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: <owner-hackers>
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 <jaykuri@oneway.com>
Reply-To: Jay Kuri <jaykuri@oneway.com>
To: hackers@freebsd.org, questions@freebsd.org
cc: Wes Peters <softweyr@xmission.com>
Subject: Max open files per process, changing param.c
Message-ID: <Pine.NEB.3.95.970212173515.23411E-100000@oneway.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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: <owner-hackers>
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 <bde@zeta.org.au>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <terry@lambert.org>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <freebsd-hackers@freebsd.org>; 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 <freebsd-hackers@freebsd.org>; 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 <seanb012@sunbeach.net>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <msmith@atrad.adelaide.edu.au>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <sef@Kithrup.COM>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <msmith@atrad.adelaide.edu.au>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <wong@a17b32.rogerswave.ca>
X-Sender: wong@wong.rogerswave.ca
Reply-To: wong@rogerswave.ca
To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
cc: "Daniel O'Callaghan" <danny@panda.hilink.com.au>, hackers@freebsd.org
Subject: Re: strlen() question, maybe str*cpy
In-Reply-To: <Mutt.19970212095452.j@uriah.heep.sax.de>
Message-ID: <Pine.BSF.3.91.970212230555.242B-100000@wong.rogerswave.ca>
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: <owner-hackers>
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 <freebsd-hackers@FreeBSD.org>; 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 <michaelh@cet.co.jp>
Reply-To: Michael Hancock <michaelh@cet.co.jp>
To: Terry Lambert <terry@lambert.org>
cc: dk+@ua.net, snar@lucky.net, freebsd-hackers@FreeBSD.org
Subject: Re: Increasing overall security....
In-Reply-To: <Pine.SV4.3.95.970213073812.12287A-100000@parkplace.cet.co.jp>
Message-ID: <Pine.SV4.3.95.970213130544.13986A-100000@parkplace.cet.co.jp>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <dwhite@gdi.uoregon.edu>
X-Sender: dwhite@localhost
Reply-To: Doug White <dwhite@resnet.uoregon.edu>
To: Joe Greco <jgreco@solaria.sol.net>
cc: hackers@freebsd.org
Subject: Re: Need definitive answer on de 21140-AC driver
In-Reply-To: <199702121254.GAA25336@solaria.sol.net>
Message-ID: <Pine.BSI.3.94.970212203009.300D-100000@localhost>
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 <Link> 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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: <Pine.BSF.3.91.970212230555.242B-100000@wong.rogerswave.ca>
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII
From: Zach Heilig <zach@blizzard.gaffaneys.com>
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 <wong@a17b32.rogerswave.ca> 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <msmith@atrad.adelaide.edu.au>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; Thu, 13 Feb 1997 09:12:21 +0100
Date: Thu, 13 Feb 1997 09:12:20 +0100 (MET)
From: "hackers@omnix.fr.org" <hackers@zapata.omniset.com>
To: hackers@freebsd.org
Message-ID: <Pine.BSF.3.95.970213091142.5852A-100000@zapata.omniset.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <sos@ravenock.cybercity.dk>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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 <helbig@MX.BA-Stuttgart.De>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <jb@cimlogic.com.au>
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 <LF> chars with <CR><LF> (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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <jb@cimlogic.com.au>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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: <Mutt.19970213103515.joe@florence.pavilion.net>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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: <l03020903af28aac879f3@[194.32.164.2]>
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 <jb@cimlogic.com.au>
From: Bob Bishop <rb@gid.co.uk>
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 <what you like> 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: <owner-hackers>
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 <hackers@freebsd.org>; 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" <danny@panda.hilink.com.au>
To: Josef Karthauser <joe@pavilion.net>
cc: hackers@freebsd.org
Subject: Re: additions to /etc/netstart
In-Reply-To: <Mutt.19970213103515.joe@florence.pavilion.net>
Message-ID: <Pine.BSF.3.91.970213224603.427K-100000@panda.hilink.com.au>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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: <Mutt.19970213114832.joe@florence.pavilion.net>
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: <Mutt.19970213103515.joe@florence.pavilion.net> <Pine.BSF.3.91.970213224603.427K-100000@panda.hilink.com.au>
X-Mailer: Mutt 0.58.1
Mime-Version: 1.0
In-Reply-To: <Pine.BSF.3.91.970213224603.427K-100000@panda.hilink.com.au>; 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <msmith@atrad.adelaide.edu.au>
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): <Maxtor 85120 A8 ->
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <sos@ravenock.cybercity.dk>
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): <Maxtor 85120 A8 ->
> 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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <seanb012@barpm5-10.caribsurf.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <msmith@atrad.adelaide.edu.au>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <luigi@labinfo.iet.unipi.it>
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 <tim@futuresouth.com> 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: <owner-hackers>
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 <hackers@freefall.freebsd.org>; 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 <espel@llaic.univ-bpclermont.fr>
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 <wong@a17b32.rogerswave.ca> 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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <msmith@atrad.adelaide.edu.au>
Message-Id: <199702131444.BAA19701@genesis.atrad.adelaide.edu.au>
Subject: Re: MIME applications for FreeBSD
In-Reply-To: <l03020903af28aac879f3@[194.32.164.2]> 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 <what you like> 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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <hackers@freebsd.org>; 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 <stesin@gu.net>
Reply-To: stesin@gu.net
To: Jake Hamby <jehamby@lightside.com>
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: <Pine.BSF.3.95.970213181855.1038B-100000@trifork.gu.net>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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 <p.richards@elsevier.co.uk>
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: <owner-hackers>
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 <hackers@freefall.freebsd.org>; 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 <neswold@aduxb.fnal.gov>
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: <Pine.GSO.3.95.970213091402.11349B-100000@aduxb.fnal.gov>
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 <wong@a17b32.rogerswave.ca>
>
> 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: <owner-hackers>
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 <hackers@freebsd.org>; 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]" <jin@george.lbl.gov>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <terry@lambert.org>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <terry@lambert.org>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <what you like> 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <tim@futuresouth.com>
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 <tim@futuresouth.com> 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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <hackers@FreeBSD.ORG>); 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 <luigi@labinfo.iet.unipi.it>, hackers@FreeBSD.ORG
From: dennis <dennis@etinc.com>
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 <tim@futuresouth.com> 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <luigi@labinfo.iet.unipi.it>
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 <tim@futuresouth.com> 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: <owner-hackers>
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 <dennis@etinc.com>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <vazquez@IQM.Unicamp.BR>
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 <tim@futuresouth.com> 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hamby@aris.jpl.nasa.gov>
X-Sender: hamby@aris
To: hackers@freebsd.org
Subject: Sun Workshop compiler vs. GCC?
Message-ID: <Pine.GSO.3.95.970213110530.9550A-100000@aris>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <jb@cimlogic.com.au>
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: <l03020903af28aac879f3@[194.32.164.2]> 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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <mbarkah@hemi.com>
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 - <http://www.hemi.com/>
-------------------------------------------------------------------
From owner-freebsd-hackers Thu Feb 13 12:27:33 1997
Return-Path: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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 <phk@critter.dk.tfs.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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."
<Mutt.19970213103515.joe@florence.pavilion.net>
Date: Thu, 13 Feb 1997 12:38:09 -0800
Message-ID: <20606.855866289@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <terry@lambert.org>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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: <Mutt.19970213205401.j@uriah.heep.sax.de>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <terry@lambert.org>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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: <XFMail.970213135550.Shimon@i-Connect.Net>
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 <Shimon@i-Connect.Net>
To: Terry Lambert <terry@lambert.org>
Subject: Re: Raw I/O Question
Cc: freebsd-hackers@freebsd.org, julian@whistle.com,
(Bruce Evans) <bde@zeta.org.au>
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: <owner-hackers>
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 <bsdcur@shadows.aeon.net>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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: <l03020907af2932974c2a@[194.32.164.2]>
In-Reply-To: <199702131933.GAA01212@freebsd1.cimlogic.com.au>
References: <l03020903af28aac879f3@[194.32.164.2]> 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 <jb@cimlogic.com.au>
From: Bob Bishop <rb@gid.co.uk>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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: <Pine.GSO.3.95.970213110530.9550A-100000@aris> (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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>); 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: <owner-hackers>
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" <jmb>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; Thu, 13 Feb 1997 15:16:32 -0700 (MST)
X-Authentication-Warning: fog.xinside.com: smap set sender to <patrick@chon.xinside.com> 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 <support@xinside.com>
To: hackers@freebsd.org
Subject: Re: Sun Workshop compiler vs. GCC?
In-Reply-To: <199702132125.NAA18583@vader.cs.berkeley.edu>
References: <Pine.GSO.3.95.970213110530.9550A-100000@aris>
<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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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: <Mutt.19970213230449.j@uriah.heep.sax.de>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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: <owner-hackers>
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 <bsdcur@shadows.aeon.net>
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" <leisner@sdsp.mc.xerox.com>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <terry@lambert.org>
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: <Mutt.19970213230449.j@uriah.heep.sax.de> 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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <wilko@yedi.iaf.nl>
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: <owner-hackers>
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 <karpen@ocean.campus.luth.se>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <karpen@ocean.campus.luth.se>
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: <Pine.GSO.3.95.970213110530.9550A-100000@aris> 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hamby@aris.jpl.nasa.gov>
X-Sender: hamby@aris
To: Satoshi Asami <asami@vader.cs.berkeley.edu>
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: <Pine.GSO.3.95.970213154912.10210A-100000@aris>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <hamby@aris.jpl.nasa.gov>
X-Sender: hamby@aris
To: Satoshi Asami <asami@vader.cs.berkeley.edu>
cc: hackers@FreeBSD.ORG
Subject: Re: Sun Workshop compiler vs. GCC?
In-Reply-To: <199702132125.NAA18583@vader.cs.berkeley.edu>
Message-ID: <Pine.GSO.3.95.970213161306.10210C-100000@aris>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hamby@aris.jpl.nasa.gov>
X-Sender: hamby@aris
To: Mikael Karpberg <karpen@ocean.campus.luth.se>
cc: hackers@freebsd.org
Subject: Re: Sun Workshop compiler vs. GCC?
In-Reply-To: <199702140004.BAA03489@ocean.campus.luth.se>
Message-ID: <Pine.GSO.3.95.970213163633.10210D-100000@aris>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <dave@dogwood.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <msmith@atrad.adelaide.edu.au>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <jb@cimlogic.com.au>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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" <davem@jenolan.rutgers.edu>
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 <karpen@ocean.campus.luth.se>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <hackers@FreeBSD.ORG>; 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" <davem@jenolan.rutgers.edu>
To: hamby@aris.jpl.nasa.gov
CC: asami@vader.cs.berkeley.edu, jmb@freefall.freebsd.org, hackers@FreeBSD.ORG
In-reply-to: <Pine.GSO.3.95.970213154912.10210A-100000@aris> (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 <hamby@aris.jpl.nasa.gov>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <hamby@aris.jpl.nasa.gov>
X-Sender: hamby@aris
To: "David S. Miller" <davem@jenolan.rutgers.edu>
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: <Pine.GSO.3.95.970213201150.10714A-100000@aris>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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" <davem@jenolan.rutgers.edu>
To: hamby@aris.jpl.nasa.gov
CC: asami@vader.cs.berkeley.edu, jmb@freefall.freebsd.org, hackers@FreeBSD.ORG
In-reply-to: <Pine.GSO.3.95.970213201150.10714A-100000@aris> (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 <hamby@aris.jpl.nasa.gov>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <jfieber@indiana.edu>
To: Jake Hamby <hamby@aris.jpl.nasa.gov>
cc: hackers@FreeBSD.ORG
Subject: Re: Sun Workshop compiler vs. GCC?
In-Reply-To: <Pine.GSO.3.95.970213161306.10210C-100000@aris>
Message-ID: <Pine.BSF.3.95q.970213234236.10804I-100000@fallout.campusview.indiana.edu>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <freebsd-hackers@freebsd.org>; 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: <Mutt.19970213225351.joed@marvin.ksu.edu>
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 <joed@ksu.edu>
PGP Key: finger joed@unix.ksu.edu
From owner-freebsd-hackers Thu Feb 13 21:44:08 1997
Return-Path: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <cmott@srv.net>
X-Sender: cmott@darkstar
To: Joe Diehl <joed@ksu.edu>
cc: freebsd-hackers@freebsd.org
Subject: Re: user-level ppp mtu problems
In-Reply-To: <Mutt.19970213225351.joed@marvin.ksu.edu>
Message-ID: <Pine.BSF.3.91.970213224313.7180B-100000@darkstar>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <terry@lambert.org>
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 <imp@village.org>
Message-Id: <E0vvGU1-0001xO-00@rover.village.org>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <joe@via.net>
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: <owner-hackers>
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: <XFMail.970213232104.Shimon@i-Connect.Net>
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 <Shimon@i-Connect.Net>
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: <owner-hackers>
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" <leisner@sdsp.mc.xerox.com>
cc: mika ruohotie <bsdcur@shadows.aeon.net>, 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 <phk@critter.dk.tfs.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; Thu, 13 Feb 1997 22:40:55 -0800 (PST)
Date: Thu, 13 Feb 1997 22:40:55 -0800 (PST)
From: Doug White <dwhite@gdi.uoregon.edu>
X-Sender: dwhite@localhost
Reply-To: Doug White <dwhite@resnet.uoregon.edu>
To: hackers@freebsd.org
Subject: mfs & swap relationship
Message-ID: <Pine.BSI.3.94.970213223902.612I-100000@localhost>
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: <owner-hackers>
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 <msmith@atrad.adelaide.edu.au>
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: <owner-hackers>
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 <bsdcur@shadows.aeon.net>
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: <owner-hackers>
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 <msmith@atrad.adelaide.edu.au>
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 <thorpej@nas.nasa.gov>
From: Jason Thorpe <thorpej@nas.nasa.gov>
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 <msmith@atrad.adelaide.edu.au> 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: <owner-hackers>
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 <hackers@freebsd.org>; 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: <l03020900af29dc661146@[194.32.164.2]>
In-Reply-To: <199702132216.PAA02367@chon.xinside.com>
References: <199702132125.NAA18583@vader.cs.berkeley.edu>
<Pine.GSO.3.95.970213110530.9550A-100000@aris>
<199702132125.NAA18583@vader.cs.berkeley.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: patrick@xinside.com
From: Bob Bishop <rb@gid.co.uk>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <luigi@labinfo.iet.unipi.it>
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 <dab@BSDI.COM>
> 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <tucker@transnetional.com>; 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 <dennis@etinc.com>
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: <owner-hackers>
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 <freebsd-hackers@FreeBSD.ORG>; 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 <mark@quickweb.com>
To: Charles Mott <cmott@srv.net>
cc: Joe Diehl <joed@ksu.edu>, freebsd-hackers@FreeBSD.ORG
Subject: Re: user-level ppp mtu problems
In-Reply-To: <Pine.BSF.3.91.970213224313.7180B-100000@darkstar>
Message-ID: <Pine.BSF.3.94.970214013611.29319A-100000@vinyl.quickweb.com>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <freebsd-hackers@freebsd.org>); 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: <Mutt.19970214124904.regnauld@deepo.prosa.dk>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <luigi@labinfo.iet.unipi.it>
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: <owner-hackers>
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 <freebsd-hackers@freefall.FreeBSD.org>; 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 <freebsd-hackers@freefall.cdrom.com>; 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 <ponds!rivers@dg-rtp.dg.com>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <steve@news.cioe.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <bryan@chesco.com>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <terry@lambert.org>
From: Eivind Eklund <eivind@dimaga.com>
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: <owner-hackers>
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: <Mutt.19970214175724.regnauld@deepo.prosa.dk>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <terry@lambert.org>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <hamby@aris.jpl.nasa.gov>
X-Sender: hamby@aris
To: John Fieber <jfieber@indiana.edu>
cc: hackers@FreeBSD.ORG
Subject: Re: Sun Workshop compiler vs. GCC?
In-Reply-To: <Pine.BSF.3.95q.970213234236.10804I-100000@fallout.campusview.indiana.edu>
Message-ID: <Pine.GSO.3.95.970214094939.11410A-100000@aris>
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: <owner-hackers>
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 <thorpej@nas.nasa.gov>
cc: Michael Smith <msmith@atrad.adelaide.edu.au>,
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" <gibbs@narnia.plutotech.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <dwhite@gdi.uoregon.edu>
X-Sender: dwhite@localhost
Reply-To: Doug White <dwhite@resnet.uoregon.edu>
To: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
cc: Tim Tsai <tim@futuresouth.com>, hackers@freebsd.org
Subject: Re: Status of 21140AC driver ?
In-Reply-To: <199702141137.MAA25239@labinfo.iet.unipi.it>
Message-ID: <Pine.BSI.3.94.970214103806.1369J-100000@localhost>
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 <Digital 21140A Fast Ethernet> 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; Fri, 14 Feb 1997 11:59:47 -0800 (PST)
Date: Fri, 14 Feb 1997 11:59:46 -0800 (PST)
From: Jaye Mathisen <mrcpu@cdsnet.net>
To: hackers@freebsd.org
Subject: CVS question, sendmail, named
Message-ID: <Pine.NEB.3.95.970214115504.4209I-100000@mail.cdsnet.net>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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" <Arne.Juul@idt.ntnu.no>
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: <owner-hackers>
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 <FreeBSD-hackers@Freebsd.org>; 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 <jerry@rafael.rnd.border.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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: <Mutt.19970214232948.j@uriah.heep.sax.de>
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: <Pine.BSI.3.94.970213223902.612I-100000@localhost>
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: <Pine.BSI.3.94.970213223902.612I-100000@localhost>; 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: <owner-hackers>
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 <FreeBSD-hackers@freebsd.org>; 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 <tinguely@plains.nodak.edu>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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" <Arne.Juul@idt.ntnu.no>
From: Eivind Eklund <eivind@dimaga.com>
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: <owner-hackers>
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 <FreeBSD-hackers@FreeBSD.org>; 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 <jerry@rafael.rnd.border.com>
From: Eivind Eklund <eivind@dimaga.com>
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: <owner-hackers>
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 <FreeBSD-hackers@freebsd.org>; 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 <FreeBSD-hackers@freebsd.org>; 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 <cmott@srv.net>
X-Sender: cmott@darkstar
To: Jerry Kendall <jerry@rafael.rnd.border.com>
cc: FreeBSD-hackers@freebsd.org
Subject: Re: NAT
In-Reply-To: <199702142143.QAA01261@rafael.rnd.border.com>
Message-ID: <Pine.BSF.3.91.970214160552.8659B-100000@darkstar>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <eivind@dimaga.com>
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 <giles@nemeton.com.au>
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 <xyzzy>'.
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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: <Mutt.19970215002627.j@uriah.heep.sax.de>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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: <Mutt.19970215003935.j@uriah.heep.sax.de>
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: <Pine.NEB.3.95.970214115504.4209I-100000@mail.cdsnet.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: <Pine.NEB.3.95.970214115504.4209I-100000@mail.cdsnet.net>; 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: <owner-hackers>
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 <pechter@shell.monmouth.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <giles@nemeton.com.au>
From: "Tim Oneil" <toneil@visigenic.com>
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: <owner-hackers>
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 <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: Simon Shapiro <Shimon@i-Connect.Net>
CC: freebsd-hackers@freebsd.org, freebsd-scsi@freebsd.org
Subject: Re: Software Interrupts
References: <XFMail.970213232104.Shimon@i-Connect.Net>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <ponds!rivers@dg-rtp.dg.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <giles@nemeton.com.au>
From: Eivind Eklund <eivind@dimaga.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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: <Pine.NEB.3.95.970214115504.4209I-100000@mail.cdsnet.net>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
In article <Pine.NEB.3.95.970214115504.4209I-100000@mail.cdsnet.net>,
Jaye Mathisen <mrcpu@cdsnet.net> 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 <branch>" or "-D <date>" 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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <hackers@FreeBSD.ORG>; 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 <eivind@dimaga.com>
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: <owner-hackers>
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 <jmacd>
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: <owner-hackers>
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 <avalon@coombs.anu.edu.au>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <ponds!rivers@dg-rtp.dg.com>
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: <owner-hackers>
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 <Hackers@FreeBSD.ORG>; 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 <Hackers@FreeBSD.ORG>; Sat, 15 Feb 1997 04:05:46 GMT
Date: Sat, 15 Feb 1997 13:05:46 +0900 (JST)
From: Michael Hancock <michaelh@cet.co.jp>
To: FreeBSD Hackers <Hackers@FreeBSD.ORG>
Subject: Re: Sun Workshop compiler vs. GCC? (fwd)
Message-ID: <Pine.SV4.3.95.970215130512.950A-100000@parkplace.cet.co.jp>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <bde@zeta.org.au>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <bde@zeta.org.au>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <bde@zeta.org.au>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <luigi@labinfo.iet.unipi.it>
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: <Mutt.19970214232948.j@uriah.heep.sax.de> 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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <davidn@labs.usn.blaze.net.au>
To: Bruce Evans <bde@zeta.org.au>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <davidn@labs.usn.blaze.net.au>
To: Bruce Evans <bde@zeta.org.au>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <bde@zeta.org.au>
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;<newline>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: <owner-hackers>
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 <m0vvfSQ-00001yC@ernie.kts.org>
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: <m0vvfSQ-00001yC@ernie.kts.org>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <tony@dell.com>
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 <yokota@zodiac.mech.utsunomiya-u.ac.jp>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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 <eivind@dimaga.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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" <Arne.Juul@idt.ntnu.no>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <freebsd-hackers@freebsd.org>; 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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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: <Mutt.19970215130347.j@uriah.heep.sax.de>
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: <Mutt.19970214232948.j@uriah.heep.sax.de> <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: <owner-hackers>
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 <karpen@ocean.campus.luth.se>
From: Eivind Eklund <eivind@dimaga.com>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <avalon@coombs.anu.edu.au>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <avalon@coombs.anu.edu.au>
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" <jkh@time.cdrom.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hackers@freebsd.org>; 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 <witr@rwwa.com>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <terry@lambert.org>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <terry@lambert.org>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <terry@lambert.org>
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;<newline>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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <skynyrd@opus.cts.cwu.edu>
To: Jaye Mathisen <mrcpu@cdsnet.net>
cc: hackers@freebsd.org
Subject: Re: CVS question, sendmail, named
In-Reply-To: <Pine.NEB.3.95.970214115504.4209I-100000@mail.cdsnet.net>
Message-ID: <Pine.BSF.3.95.970215125624.20705A-100000@opus.cts.cwu.edu>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <narvi@haldjas.folklore.ee>
To: Terry Lambert <terry@lambert.org>
cc: Dave Cornejo <dave@dogwood.com>, 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: <Pine.BSF.3.95.970215234046.7912B-100000@haldjas.folklore.ee>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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: <Mutt.19970215224320.peter@grendel.>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <cmott@srv.net>
X-Sender: cmott@darkstar
To: freebsd-hackers@freebsd.org
Subject: User ppp keepalive logic
Message-ID: <Pine.BSF.3.91.970215151514.10861C-100000@darkstar>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <matt@lkg.dec.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <terry@lambert.org>
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: <Pine.BSF.3.95.970215234046.7912B-100000@haldjas.folklore.ee> 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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <terry@lambert.org>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <hamby@aris.jpl.nasa.gov>
X-Sender: hamby@aris
To: "David S. Miller" <davem@jenolan.rutgers.edu>
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: <Pine.GSO.3.95.970215155419.18262A-100000@aris>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <avalon@coombs.anu.edu.au>
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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" <danny@panda.hilink.com.au>
To: Charles Mott <cmott@srv.net>
cc: freebsd-hackers@freebsd.org
Subject: Re: User ppp keepalive logic
In-Reply-To: <Pine.BSF.3.91.970215151514.10861C-100000@darkstar>
Message-ID: <Pine.BSF.3.91.970216111040.8268C-100000@panda.hilink.com.au>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <jb@cimlogic.com.au>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <terry@lambert.org>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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 <terry@lambert.org>
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: <Pine.GSO.3.95.970215155419.18262A-100000@aris> 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <avalon@coombs.anu.edu.au>
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 <giles@nemeton.com.au>
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: <owner-hackers>
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: <XFMail.970215185743.Shimon@i-Connect.Net>
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 <Shimon@i-Connect.Net>
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: <owner-hackers>
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 <hackers@FreeBSD.ORG>; 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: <XFMail.970215200110.Shimon@i-Connect.Net>
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 <Shimon@i-Connect.Net>
To: (Jake Hamby) <jehamby@lightside.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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: <XFMail.970215200110.Shimon@i-Connect.Net>
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 <Shimon@i-Connect.Net>
To: Darren Reed <avalon@coombs.anu.edu.au>
Subject: Re: Sun Workshop compiler vs. GCC?
Cc: hackers@freebsd.org, (Jake Hamby) <jehamby@lightside.com>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <jfieber@indiana.edu>
To: Jake Hamby <jehamby@lightside.com>
cc: hackers@freebsd.org
Subject: Re: Sun Workshop compiler vs. GCC?
In-Reply-To: <199702152232.OAA05103@lightside.com>
Message-ID: <Pine.BSF.3.95q.970215221920.14200H-100000@fallout.campusview.indiana.edu>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <evil grin>).
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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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: <owner-hackers>
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 <hackers@freebsd.org>; 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 <hasty@rah.star-gate.com>
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 <jb@cimlogic.com.au>
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: <owner-hackers>
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 <hackers@freebsd.org>; 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: <owner-hackers>
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 <jdc@xinside.com> 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 <jdc@xinside.com>
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: <m0vvfSQ-00001yC@ernie.kts.org>
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: <owner-hackers>
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 <freebsd-hackers@FreeBSD.ORG>; 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 <skynyrd@opus.cts.cwu.edu>
To: dkelly@hiwaay.net
cc: John Polstra <jdp@polstra.com>, freebsd-hackers@FreeBSD.ORG
Subject: Re: Just CVS (was Re: CVS question, sendmail, named)
In-Reply-To: <199702160333.VAA28629@nexgen.ampr.org>
Message-ID: <Pine.BSF.3.95.970215221100.22074A-100000@opus.cts.cwu.edu>
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=<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: <owner-hackers>
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 <freebsd-hackers@freebsd.org>; 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 <julian@current1.whistle.com>
To: Charles Mott <cmott@srv.net>
cc: freebsd-hackers@freebsd.org
Subject: Re: User ppp keepalive logic
In-Reply-To: <Pine.BSF.3.91.970215151514.10861C-100000@darkstar>
Message-ID: <Pine.BSF.3.95.970215225429.23451A-100000@current1.whistle.com>
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
>
>