From owner-freebsd-hackers Sun Oct 19 00:18:06 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id AAA26384
for hackers-outgoing; Sun, 19 Oct 1997 00:18:06 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA26348
for <freebsd-hackers@freebsd.org>; Sun, 19 Oct 1997 00:15:54 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id QAA01175;
Sun, 19 Oct 1997 16:42:10 +0930 (CST)
Message-Id: <199710190712.QAA01175@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: "David E. Cross" <dec@phoenix.its.rpi.edu>
cc: freebsd-hackers@freebsd.org
Subject: Re: FreeBSD authentication...
In-reply-to: Your message of "Sat, 18 Oct 1997 10:29:58 -0400."
<Pine.BSF.3.96.971018102700.27956A-100000@phoenix.its.rpi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 19 Oct 1997 16:42:08 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> Is anyone working on supporting Kerberos V5 now that it is out, instead of
> the kerb-4 eBones packge?
This is in -current.
> Is there any interest (should there be) to mooving to Pluggabl
> Authentication Modules. (Since they are implimented as shared libraries,
> that you link in as needed, would we need to rewrite ld.so a bit to ensure
> that people couldn't set their LD_LIBRARY_PATH, and then run su to get
> full root acces, sans password?)
Modules are loaded explicitly, so this is not an issue. See my
homepage (http://www.smith.net.au/~mike) for a port of a slightly older
version of the Linux-PAM distribution to FreeBSD. There are a number
of problems which need to be addressed before PAM can be taken
seriously, but these really just require developer time.
mike
From owner-freebsd-hackers Sun Oct 19 00:54:36 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id AAA27290
for hackers-outgoing; Sun, 19 Oct 1997 00:54:36 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA27282
for <freebsd-hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 00:54:14 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id RAA01382;
Sun, 19 Oct 1997 17:16:24 +0930 (CST)
Message-Id: <199710190746.RAA01382@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Peter Dufault <dufault@hda.com>
cc: mdean@best.com (mdean), freebsd-hackers@FreeBSD.ORG
Subject: Re: Opinions wanted.
In-reply-to: Your message of "Sat, 18 Oct 1997 19:13:30 -0400."
<199710182313.TAA23016@hda.hda.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 19 Oct 1997 17:16:20 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > If an 8255 (digital I/O) 8-bit port is opened via open() call by the user
> > as O_RDWR then it becomes an output,
It makes little sense to model the 8255 like this. It would be much
more sensible to allow open/close and require an ioctl to provide
register access.
> The system design must arrange to pull the signals high at start
> up (if you can, yes I'm mostly software) so that it doesn't turn
> on devices.
This is impossible with the 8255, as it resets its outputs low whenever
the mode byte is changed. It is a most disgusting device indeed.
mike
From owner-freebsd-hackers Sun Oct 19 01:55:33 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id BAA28615
for hackers-outgoing; Sun, 19 Oct 1997 01:55:33 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA28609
for <freebsd-hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 01:55:28 -0700 (PDT)
(envelope-from jamil@trojanhorse.ml.org)
Received: from localhost (jamil@localhost)
by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id BAA00524;
Sun, 19 Oct 1997 01:28:22 -0700 (PDT)
Date: Sun, 19 Oct 1997 01:28:22 -0700 (PDT)
From: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
To: Mike Smith <mike@smith.net.au>
cc: Peter Dufault <dufault@hda.com>, freebsd-hackers@FreeBSD.ORG
Subject: Re: Opinions wanted.
In-Reply-To: <199710190746.RAA01382@word.smith.net.au>
Message-ID: <Pine.BSF.3.96.971019012338.518A-100000@trojanhorse.ml.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > > If an 8255 (digital I/O) 8-bit port is opened via open() call by the user
> > > as O_RDWR then it becomes an output,
>
> It makes little sense to model the 8255 like this. It would be much
> more sensible to allow open/close and require an ioctl to provide
> register access.
I would have to disagree with this, here's how I have it configure itself.
O_RDWR or O_WRONLY makes it an output
O_RDONLY makes it an input
To have to ioctl() it for a basic operation like determining if it is an
input or output is just extra work when the open flags describe operation
precisely anyway. I have completed my work and debugged it (it took much
longer than expected). I would now like to request to have some kernel
type person look at it and tell me if I have major league screwed up
anything (it works fine in all my tests).
From owner-freebsd-hackers Sun Oct 19 02:22:50 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id CAA29331
for hackers-outgoing; Sun, 19 Oct 1997 02:22:50 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id CAA29317
for <freebsd-hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 02:22:43 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA20575; Sun, 19 Oct 1997 11:22:41 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id LAA17267;
Sun, 19 Oct 1997 11:14:43 +0200 (MET DST)
Message-ID: <19971019111443.MO62406@uriah.heep.sax.de>
Date: Sun, 19 Oct 1997 11:14:43 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: freebsd-hackers@FreeBSD.ORG
Cc: tad@csh.rit.edu (Tad Hunt)
Subject: Re: libc_r and print...
References: <199710190058.UAA26658@jake.csh.rit.edu>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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: <199710190058.UAA26658@jake.csh.rit.edu>; from Tad Hunt on Oct 18, 1997 20:58:39 -0400
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Tad Hunt wrote:
> I'm having a problem with the following simple test case
> on FreeBSD-2.2-RELEASE when linking with libc_r
> % gcc -static foo.c -lc_r
> % ./a.out
> [ hang in print ]
>
> When I compile with -static, I am unable to stop a.out from running unless
> I signal it with SIGKILL.
Works fine in -current. You could analyze the ps output to see what
it is waiting for.
--
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 Oct 19 05:24:38 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id FAA04658
for hackers-outgoing; Sun, 19 Oct 1997 05:24:38 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: (from jmb@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id FAA04645;
Sun, 19 Oct 1997 05:24:27 -0700 (PDT)
(envelope-from jmb)
From: "Jonathan M. Bresler" <jmb>
Message-Id: <199710191224.FAA04645@hub.freebsd.org>
Subject: Re: pulling email addresses from freebsd lists
To: joerg_wunsch@uriah.heep.sax.de
Date: Sun, 19 Oct 1997 05:24:27 -0700 (PDT)
Cc: hackers@FreeBSD.ORG
In-Reply-To: <19971018143950.GR04030@uriah.heep.sax.de> from "J Wunsch" at Oct 18, 97 02:39:50 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
J Wunsch wrote:
>
> As Hellmuth Michaelis wrote:
>
> > I'd vote to disable majordomos feature to send out the complete list of
> > memebers, its useless for the normal user anyway.
>
> This feature has been disabled long ago.
the "who" feature was disabled long ago.
there is also a "which" feature...a subscriber sends mail
with the command "which"...it returns a list of mailing lists
that the subscriber is subscribed to.
unfortunately, it does not check the subscriber address against
the "which" request. so a "which @" returns all the addresses
in the mailing lists.
"which" has been diabled.
jmb
From owner-freebsd-hackers Sun Oct 19 06:50:43 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id GAA07214
for hackers-outgoing; Sun, 19 Oct 1997 06:50:43 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA07209
for <freebsd-hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 06:50:37 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id PAA23248 for freebsd-hackers@FreeBSD.ORG; Sun, 19 Oct 1997 15:50:35 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id PAA00447;
Sun, 19 Oct 1997 15:36:40 +0200 (MET DST)
Message-ID: <19971019153639.DJ26052@uriah.heep.sax.de>
Date: Sun, 19 Oct 1997 15:36:39 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: freebsd-hackers@FreeBSD.ORG
Subject: Re: fd.c and Compaq AERO
References: <XFMail.970911143014.alex@hugo.bmg.gv.at>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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.970911143014.alex@hugo.bmg.gv.at>; from Alexander Hausner on Sep 11, 1997 14:02:38 +0200
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Alexander Hausner wrote:
> There is a problem concerning detection of the pcmcia-floppy
> on compaq aero notebooks. I found some entries in the freebsd-questions
> archive:
Well, this is a heads-up for those who don't read the commit messages
(and serves also reference purposes in the list archives):
The proposed hack looked too disgusting to me. Instead, i've just
committed the code and documentation for a `flags 0x1' to the fdc
config line (so it can also be specified from within UserConfig).
Setting this flag will pretend a floppy drive 0 of type 1.44 MB,
regardless of what the CMOS says. This is supposedly a good enough
bandaid for those plagued by the Compaq Aero.
--
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 Oct 19 07:16:09 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id HAA07997
for hackers-outgoing; Sun, 19 Oct 1997 07:16:09 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA07991
for <freebsd-hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 07:16:03 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id XAA00268;
Sun, 19 Oct 1997 23:41:20 +0930 (CST)
Message-Id: <199710191411.XAA00268@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
cc: Mike Smith <mike@smith.net.au>, Peter Dufault <dufault@hda.com>,
freebsd-hackers@FreeBSD.ORG
Subject: Re: Opinions wanted.
In-reply-to: Your message of "Sun, 19 Oct 1997 01:28:22 MST."
<Pine.BSF.3.96.971019012338.518A-100000@trojanhorse.ml.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 19 Oct 1997 23:41:18 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
>
>>>> If an 8255 (digital I/O) 8-bit port is opened via open() call by the user
>>>> as O_RDWR then it becomes an output,
>>
>> It makes little sense to model the 8255 like this. It would be much
>> more sensible to allow open/close and require an ioctl to provide
>> register access.
>
> I would have to disagree with this, here's how I have it configure itself.
>
> O_RDWR or O_WRONLY makes it an output
> O_RDONLY makes it an input
I'll reiterate the point, and clarify. It makes little sense to model
the 8255 like this, as it is prohibitively restrictive.
Each of ports A and B are split in half, and each half can be
configured for input or output. You don't make allowance for this mode
of operation.
You also don't provide for use of the bit-port operations on port C.
It makes little sense to model the port like this. If it's worth
anything, I have been down this road a number of times with different
I/O parts (8255, Z8536, AM29???) and every time the optimal solution
has been either a driver which addresses the operational mode of the
hardware on the other side of the device, or straight user-mode I/O.
> I have completed my work and debugged it (it took much
> longer than expected). I would now like to request to have some kernel
> type person look at it and tell me if I have major league screwed up
> anything (it works fine in all my tests).
If it's only going to be used for your application, the fact that it
works for you is probably enough. If you're aiming for mainstream
integration, you've got a lot more ground to cover. 8)
mike
From owner-freebsd-hackers Sun Oct 19 07:48:17 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id HAA09099
for hackers-outgoing; Sun, 19 Oct 1997 07:48:17 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from intercore.com (num1sun.intercore.com [199.181.243.1])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA09087
for <hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 07:48:11 -0700 (PDT)
(envelope-from robin@intercore.com)
Received: (robin@localhost) by intercore.com (8.7.1/8.6.4) id KAA24537; Sun, 19 Oct 1997 10:45:11 -0400 (EDT)
Message-ID: <19971019104510.16409@num1sun.intercore.com>
Date: Sun, 19 Oct 1997 10:45:10 -0400
From: Robin Cutshaw <robin@intercore.com>
To: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Cc: hackers@FreeBSD.ORG
Subject: Re: 48 hours left in 2.2.5 BETA cycle!
References: <27616.877235537@time.cdrom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.79
In-Reply-To: <27616.877235537@time.cdrom.com>; from Jordan K. Hubbard on Sat, Oct 18, 1997 at 09:32:17PM -0700
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Sat, Oct 18, 1997 at 09:32:17PM -0700, Jordan K. Hubbard wrote:
> And, as things would have it, Peter has just committed a last minute
> syncronization patch with Matt Thomas's latest to the de driver,
> meaning that *anyone* with a DC21xxx based card should very definitely
> install 2.2.5-971018-BETA from ftp.freebsd.org or one of its mirrors
> as soon as possible and let us know if it *doesn't* work. If it does
> work, great, you've nothing to worry about for 2.2.5. If it doesn't,
> we need to know about it instantly! ;)
>
Still no joy. The de driver does not correctly detect 100 Mb/s mode
and link2 doesn't change anything.
robin
--
----
Robin Cutshaw internet: robin@interlabs.com robin@intercore.com
Internet Labs, Inc. BellNet: 404-817-9787 robin@XFree86.Org
"Time is just one damn thing after another" -- PBS/Nova
----
--
From owner-freebsd-hackers Sun Oct 19 08:26:48 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id IAA13435
for hackers-outgoing; Sun, 19 Oct 1997 08:26:48 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from intercore.com (num1sun.intercore.com [199.181.243.1])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA13429
for <hackers@freebsd.org>; Sun, 19 Oct 1997 08:26:45 -0700 (PDT)
(envelope-from robin@intercore.com)
Received: (robin@localhost) by intercore.com (8.7.1/8.6.4) id LAA24578; Sun, 19 Oct 1997 11:23:54 -0400 (EDT)
Message-ID: <19971019112353.26513@num1sun.intercore.com>
Date: Sun, 19 Oct 1997 11:23:53 -0400
From: Robin Cutshaw <robin@intercore.com>
To: hackers@freebsd.org
Subject: fsck problem with 2.2.5-971015-BETA
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.79
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
System: P5-200, 64MB ram, 3 3GB IDE drives, 2 2GB scsi, 4 9GB scsi.
"fsck -p" in /etc/rc fails when it gets to the 1st 9GB drive
with "cannot alloc 2088961 bytes for statemap".
I'm using the dpt_1.2.4 patches to get to the scsi drives.
robin
--
----
Robin Cutshaw internet: robin@interlabs.com robin@intercore.com
Internet Labs, Inc. BellNet: 404-817-9787 robin@XFree86.Org
"Time is just one damn thing after another" -- PBS/Nova
----
--
From owner-freebsd-hackers Sun Oct 19 09:53:59 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id JAA18492
for hackers-outgoing; Sun, 19 Oct 1997 09:53:59 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA18487
for <hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 09:53:48 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA24824; Sun, 19 Oct 1997 18:51:08 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id SAA00990;
Sun, 19 Oct 1997 18:35:51 +0200 (MET DST)
Message-ID: <19971019183550.SV35032@uriah.heep.sax.de>
Date: Sun, 19 Oct 1997 18:35:50 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: hackers@FreeBSD.ORG
Cc: robin@intercore.com (Robin Cutshaw)
Subject: Re: fsck problem with 2.2.5-971015-BETA
References: <19971019112353.26513@num1sun.intercore.com>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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: <19971019112353.26513@num1sun.intercore.com>; from Robin Cutshaw on Oct 19, 1997 11:23:53 -0400
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Robin Cutshaw wrote:
> "fsck -p" in /etc/rc fails when it gets to the 1st 9GB drive
> with "cannot alloc 2088961 bytes for statemap".
ISTR a comment that you need to increase the VM resource limits to
fsck large filesystems.
--
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 Oct 19 10:09:17 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA19042
for hackers-outgoing; Sun, 19 Oct 1997 10:09:17 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from iq.org (proff@profane.iq.org [203.4.184.222])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA19032
for <freebsd-hackers@freebsd.org>; Sun, 19 Oct 1997 10:09:07 -0700 (PDT)
(envelope-from proff@iq.org)
Received: (qmail 1110 invoked by uid 110); 19 Oct 1997 17:08:38 -0000
Date: 19 Oct 1997 17:08:38 -0000
Message-ID: <19971019170838.1109.qmail@iq.org>
From: Julian Assange <proff@iq.org>
To: freebsd-hackers@freebsd.org
Subject: nasty problem with vnode and other disk drivers?
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Surely this can't be correct behavior:
# cp /usr/share/dict/words words
# head words
A
a
aa
aal
aalii
aam
Aani
aardvark
aardwolf
Aaron
# vnconfig /dev/vn0 words
# dd if=/dev/rvn0 bs=8 count=10
A
a
aa
aA
a
aa
aA
a
aa
aA
a
aa
aA
a
aa
aA
a
aa
aA
a
aa
aA
a
aa
aA
a
aa
aA
a
aa
a10+0 records in
10+0 records out
80 bytes transferred in 0.002210 secs (36199 bytes/sec)
# dd if=/dev/vn0 bs=8 count=10
A
a
aa
aal
aalii
aam
Aani
aardvark
aardwolf
Aaron
Aaronic
Aaronical
Aaronite
Aar10+0 records in
10+0 records out
physio() is passed a uio argument, with an offset into the device.
It then builds a struct buf, and calculates b_blkno like so:
bp->b_blkno = btodb(uio->uio_offset);
(btodb just divides by 512)
vn_strategy() is called via physio() with a struct buf * argument
(only). vn_strategy() then tries to "rebuild" uio->uio_offset
from bp->b_blkno with:
auio.uio_offset = dbtob (bp->b_blkno);
But the earlier btodb() has of course sliced off the bottem 9 bits
in the division - meaning the same data is fetched over and over
again, within each 512 byte block.
The reason the block device (/dev/vn0) works where the character
device fails is that the block device is always accessed in multiples
of 2048, regardless of how short the userland read()
--
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 Sun Oct 19 11:51:02 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA25215
for hackers-outgoing; Sun, 19 Oct 1997 11:51:02 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA25206
for <freebsd-hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 11:50:55 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id UAA26468; Sun, 19 Oct 1997 20:50:53 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id UAA01482;
Sun, 19 Oct 1997 20:40:19 +0200 (MET DST)
Message-ID: <19971019204018.PF25731@uriah.heep.sax.de>
Date: Sun, 19 Oct 1997 20:40:18 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: freebsd-hackers@FreeBSD.ORG
Cc: proff@iq.org (Julian Assange)
Subject: Re: nasty problem with vnode and other disk drivers?
References: <19971019170838.1109.qmail@iq.org>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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: <19971019170838.1109.qmail@iq.org>; from Julian Assange on Oct 19, 1997 17:08:38 -0000
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Julian Assange wrote:
> physio() is passed a uio argument, with an offset into the device.
> It then builds a struct buf, and calculates b_blkno like so:
>
> bp->b_blkno = btodb(uio->uio_offset);
>
> (btodb just divides by 512)
(and so on)
All this nasty shiftomania is subject to be killed some day, for
b_blkno should be replaced by a b_offset field (of type off_t). I
think a number of (not so unimportant to the project effort :) people
already agreed that this is the way to go, so it's only a matter of
time, until someone can spend the energy required to make this change,
and debug everything.
Hopefully, this should still be before 3.0 hits the surface.
--
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 Oct 19 11:54:49 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA25592
for hackers-outgoing; Sun, 19 Oct 1997 11:54:49 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA25577
for <freebsd-hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 11:54:42 -0700 (PDT)
(envelope-from jamil@trojanhorse.ml.org)
Received: from localhost (jamil@localhost)
by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id LAA00646;
Sun, 19 Oct 1997 11:54:24 -0700 (PDT)
Date: Sun, 19 Oct 1997 11:54:23 -0700 (PDT)
From: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
Reply-To: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
To: Mike Smith <mike@smith.net.au>
cc: Peter Dufault <dufault@hda.com>, freebsd-hackers@FreeBSD.ORG
Subject: Re: Opinions wanted.
In-Reply-To: <199710191411.XAA00268@word.smith.net.au>
Message-ID: <Pine.BSF.3.96.971019114225.605A-100000@trojanhorse.ml.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
This particular hardware has 2 8255's (and only the C port can be
split), it also only operates in mode 0. And since the point of
spliting the c port is so you can have your bits half and half it is not
necessary here since there are two 8255's. The board also has change of
state interrupts (on all lines) which is why I did this in the first
place. Unless you have a better way to pass interrupts through to a
user process (I'll immediately throw away all my work and use that).
I think criticism is good here but please take a look at the spec sheet
first: http://www.indcompsrc.com/products/data/html/dio48s_at-p.html
> I'll reiterate the point, and clarify. It makes little sense to model
> the 8255 like this, as it is prohibitively restrictive.
>
> Each of ports A and B are split in half, and each half can be
> configured for input or output. You don't make allowance for this mode
> of operation.
Also it is only port C that can be split not port A and B
> You also don't provide for use of the bit-port operations on port C.
Set/Reset operations are not supported by this board, that bit is used for
tristate enable/disable
> If it's only going to be used for your application, the fact that it
> works for you is probably enough. If you're aiming for mainstream
> integration, you've got a lot more ground to cover. 8)
I've been trying my best to make it as general as possible. If you have
tangible ideas in terms of functionality after you see the code and spec
sheet I'd be happy to add them.
From owner-freebsd-hackers Sun Oct 19 12:34:39 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id MAA27734
for hackers-outgoing; Sun, 19 Oct 1997 12:34:39 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from cleopatra.ultra.net (cleopatra.ultra.net [199.232.56.35])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA27727
for <hackers@freebsd.org>; Sun, 19 Oct 1997 12:34:33 -0700 (PDT)
(envelope-from moncrg@ma.ultranet.com)
Received: from moncrg (d8.dial-17.mbo.ma.ultra.net [146.115.100.168]) by cleopatra.ultra.net (8.8.5/ult1.05) with SMTP id PAA11843; Sun, 19 Oct 1997 15:34:19 -0400 (EDT)
From: "Gregory D Moncreaff" <moncrg@ma.ultranet.com>
To: "Hackers FreeBSD" <hackers@freebsd.org>,
"Terry Lambert" <tlambert@primenet.com>
Subject: Re: [Q] Is recvmsg for ancillary (control) data part of protocol or generic sockets?
Date: Sun, 19 Oct 1997 14:32:34 -0400
Message-ID: <01bcdcbd$5e351cc0$a8647392@moncrg>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0103_01BCDC9B.D7237CC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_0103_01BCDC9B.D7237CC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
-----Original Message-----
From: Terry Lambert <tlambert@primenet.com>
To: Gregory D Moncreaff <moncrg@ma.ultranet.com>
Cc: hackers@FreeBSD.ORG <hackers@FreeBSD.ORG>
Date: Friday, October 17, 1997 4:00 PM
Subject: Re: [Q] Is recvmsg for ancillary (control) data part of protocol or
generic sockets?
>> was looking at design and implementation 4.4 and
>> there was a PRU_RECV, PRU_RECVOOB but no
>> PRU_RECVCTL.
>>
>> just wondering how the control data gets from the
>> protocol to the user....
>
>man recvmsg.
>
>The control and data parts are retrieved simultaneously.
>
>
> Terry Lambert
> terry@lambert.org
>---
>Any opinions in this posting are my own and not those of my present
>or previous employers.
>
I eventually found the code in kern/uipc_socket.c:soreceive()
There seems to be a problem with connection oriented protocols getting
disconnect data since
soreceive checks PR_CONNREQUIRED and aborts before checking to see if
control data is
present.
Is this by accident or design? PR_CONNREQUIRED is only supposed to gate
send according to sys/protosw.h...
if (m == 0 || (( .....
.....
if ((so->so_state & (SS_ISCONNECTED|SS_ISCONNECTING)) == 0 &&
(so->so_proto->pr_flags & PR_CONNREQUIRED)) {
error = ENOTCONN;
goto release;
.....
while (m && m->m_type == MT_CONTROL && error == 0) {
if (flags & MSG_PEEK) {
if (controlp)
*controlp = m_copy(m, 0, m->m_len);
m = m->m_next;
.....
release:
sbunlock(&so->so_rcv);
splx(s);
return (error);
=====================================================================
Gregory D. Moncreaff Phone 1-508-490-2048
Raytheon Electronic Systems Fax 1-508-490-2086
Gregory_D_Moncreaff@res.raytheon.com Home moncrg@ma.ultranet.com
---------------------------------------------------------------------
------=_NextPart_000_0103_01BCDC9B.D7237CC0
Content-Type: text/x-vcard;
name="Gregory Donald Moncreaff.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Gregory Donald Moncreaff.vcf"
BEGIN:VCARD
N:Moncreaff;Gregory;Donald
FN:Gregory Donald Moncreaff
EMAIL;PREF;INTERNET:moncrg@ma.ultranet.com
END:VCARD
------=_NextPart_000_0103_01BCDC9B.D7237CC0--
From owner-freebsd-hackers Sun Oct 19 12:40:35 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id MAA28186
for hackers-outgoing; Sun, 19 Oct 1997 12:40:35 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA28177
for <freebsd-hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 12:40:30 -0700 (PDT)
(envelope-from toor@dyson.iquest.net)
Received: (from root@localhost)
by dyson.iquest.net (8.8.7/8.8.5) id OAA04475;
Sun, 19 Oct 1997 14:39:00 -0500 (EST)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199710191939.OAA04475@dyson.iquest.net>
Subject: Re: nasty problem with vnode and other disk drivers?
In-Reply-To: <19971019170838.1109.qmail@iq.org> from Julian Assange at "Oct 19, 97 05:08:38 pm"
To: proff@iq.org (Julian Assange)
Date: Sun, 19 Oct 1997 14:39:00 -0500 (EST)
Cc: freebsd-hackers@FreeBSD.ORG
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-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Julian Assange said:
>
>
> Surely this can't be correct behavior:
>
> # cp /usr/share/dict/words words
> # head words
> A
> a
> aa
> aal
> aalii
> aam
> Aani
> aardvark
> aardwolf
> Aaron
> # vnconfig /dev/vn0 words
> # dd if=/dev/rvn0 bs=8 count=10
> A
> a
> aa
> aA
> a
> aa
> aA
> a
> aa
>
It isn't expected behavior, but raw, block devices currently need I/O on
512 byte boundarys for integrals of 512 byte lengths.
John
From owner-freebsd-hackers Sun Oct 19 15:43:13 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA06428
for hackers-outgoing; Sun, 19 Oct 1997 15:43:13 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from citrine.cyberstation.net (citrine.cyberstation.net [205.167.0.5])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA06420
for <hackers@freebsd.org>; Sun, 19 Oct 1997 15:42:58 -0700 (PDT)
(envelope-from hannibal@cyberstation.net)
Received: from localhost (hannibal@localhost)
by citrine.cyberstation.net (8.8.7/8.8.7) with SMTP id RAA23371
for <hackers@freebsd.org>; Sun, 19 Oct 1997 17:42:46 -0500 (CDT)
Date: Sun, 19 Oct 1997 17:42:46 -0500 (CDT)
From: Dan Walters <hannibal@cyberstation.net>
To: hackers@freebsd.org
Subject: ATAPI CD-RW documentation...
Message-ID: <Pine.BSI.3.96.971019170816.20632A-100000@citrine.cyberstation.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I just ordered a EIDE CD-RW (all the 4x models I could find were EIDE, and
if hard drives are any indication I bet most CD-RWs will probably be EIDE
soon) and of course would like to use it under FreeBSD. I don't even see
anything looking like support for it under Linux, which really surprised
me. I'd be interested in at least attempting to implement some support
for it. Can someone tell me where I could get my hands on some sort of
programmer's guide or manual for these? Would the specifics for a CD-RW
actually be covered in the ATAPI specs from WD?
======================================================================
Dan Walters
hannibal@cyberstation.net
======================================================================
From owner-freebsd-hackers Sun Oct 19 15:48:42 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA06694
for hackers-outgoing; Sun, 19 Oct 1997 15:48:42 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from eps.ufsc.br (eps.ufsc.br [150.162.1.50])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA06687
for <freebsd-hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 15:48:33 -0700 (PDT)
(envelope-from george@eps.ufsc.br)
Received: from localhost (d51.ad.eps.ufsc.br [150.162.46.51]) by eps.ufsc.br (8.8.6/8.7.3) with SMTP id VAA29503 for <freebsd-hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 21:46:04 -0200 (EDT)
Date: Sun, 19 Oct 1997 20:47:46 -0200 (EDT)
From: George Tavares <george@eps.ufsc.br>
X-Sender: george@localhost
To: freebsd-hackers@FreeBSD.ORG
Subject: PThread
Message-ID: <Pine.BSF.3.96.971019203831.11291B-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
I was using pthread (libc_r) packages I like to know if this
package is the same from MIT (MIT pthread).
When I running a pthread application, I press ^C and it doesn't
kill my application (running same program im Solaris it works). The
signals aren't passed to application?
Another think, how I know what function are MT-SAFE. I don't see
nothing about this in the man's.
Why it is not compiled in make world? Many bugs?
-----------------------------------------------------------------------
| George Tavares Ciencias da Computacao - UFSC |
| Fone:(048)331-7020 E-mail: george@eps.ufsc.br |
| http://www.eps.ufsc.br/~george PGP key disponivel por http |
-----------------------------------------------------------------------
From owner-freebsd-hackers Sun Oct 19 16:09:25 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id QAA07672
for hackers-outgoing; Sun, 19 Oct 1997 16:09:25 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from citrine.cyberstation.net (hannibal@citrine.cyberstation.net [205.167.0.5])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA07667
for <hackers@freebsd.org>; Sun, 19 Oct 1997 16:09:19 -0700 (PDT)
(envelope-from hannibal@cyberstation.net)
Received: from localhost (hannibal@localhost)
by citrine.cyberstation.net (8.8.7/8.8.7) with SMTP id SAA25842
for <hackers@freebsd.org>; Sun, 19 Oct 1997 18:09:07 -0500 (CDT)
Date: Sun, 19 Oct 1997 18:09:07 -0500 (CDT)
From: Dan Walters <hannibal@cyberstation.net>
To: hackers@freebsd.org
Subject: Re: ATAPI CD-RW documentation...
Message-ID: <Pine.BSI.3.96.971019180502.25467A-100000@citrine.cyberstation.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Never mind, it's amazing how you always find things right after you give
up and ask. :) For anyone wondering, the motherload of specs can be
found by ftp at fission.dt.wdc.com, including the working draft of the
ATAPI Removable Rewritable Specification, SFF-8070. Wish their web pages
would mention the site. :)
So, has anyone already began work on this, or should I go ahead and give
it a shot when my drive gets in?
======================================================================
Dan Walters
hannibal@cyberstation.net
======================================================================
From owner-freebsd-hackers Sun Oct 19 16:40:33 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id QAA09175
for hackers-outgoing; Sun, 19 Oct 1997 16:40:33 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA09170
for <freebsd-hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 16:40:30 -0700 (PDT)
(envelope-from hasty@rah.star-gate.com)
Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1])
by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id QAA01433;
Sun, 19 Oct 1997 16:40:01 -0700 (PDT)
Message-Id: <199710192340.QAA01433@rah.star-gate.com>
X-Mailer: exmh version 2.0zeta 7/24/97
To: George Tavares <george@eps.ufsc.br>
cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: PThread
In-reply-to: Your message of "Sun, 19 Oct 1997 20:47:46 -0200."
<Pine.BSF.3.96.971019203831.11291B-100000@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 19 Oct 1997 16:40:01 -0700
From: Amancio <hasty@rah.star-gate.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
The default on FreeBSD 3.0-current is to build libc_r.
libc_r is not that the same a Provenzo's pthread package a couple
of years ago when I was interested on threads for FreeBSD provenzo's
pthread package was buggier than libc_r.
control-c is trap by thread package and a little ago there where patches
submitted to the list to fix this condition.
Amancio
>
> I was using pthread (libc_r) packages I like to know if this
> package is the same from MIT (MIT pthread).
> When I running a pthread application, I press ^C and it doesn't
> kill my application (running same program im Solaris it works). The
> signals aren't passed to application?
> Another think, how I know what function are MT-SAFE. I don't see
> nothing about this in the man's.
> Why it is not compiled in make world? Many bugs?
>
>
> -----------------------------------------------------------------------
> | George Tavares Ciencias da Computacao - UFSC |
> | Fone:(048)331-7020 E-mail: george@eps.ufsc.br |
> | http://www.eps.ufsc.br/~george PGP key disponivel por http |
> -----------------------------------------------------------------------
>
>
From owner-freebsd-hackers Sun Oct 19 16:43:45 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id QAA09336
for hackers-outgoing; Sun, 19 Oct 1997 16:43:45 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA09331
for <hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 16:43:43 -0700 (PDT)
(envelope-from dkelly@nospam.hiwaay.net)
Received: from nospam.hiwaay.net (tnt2-182.HiWAAY.net [208.147.148.182])
by fly.HiWAAY.net (8.8.7/8.8.6) with ESMTP id SAA30366;
Sun, 19 Oct 1997 18:43:36 -0500 (CDT)
Received: from nospam.hiwaay.net (localhost [127.0.0.1])
by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP
id SAA11486; Sun, 19 Oct 1997 18:43:34 -0500 (CDT)
Message-Id: <199710192343.SAA11486@nospam.hiwaay.net>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Dan Walters <hannibal@cyberstation.net>
cc: hackers@FreeBSD.ORG
From: dkelly@hiwaay.net
Subject: Re: ATAPI CD-RW documentation...
In-reply-to: Message from Dan Walters <hannibal@cyberstation.net>
of "Sun, 19 Oct 1997 17:42:46 CDT." <Pine.BSI.3.96.971019170816.20632A-100000@citrine.cyberstation.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 19 Oct 1997 18:43:32 -0500
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> I just ordered a EIDE CD-RW (all the 4x models I could find were EIDE, and
> if hard drives are any indication I bet most CD-RWs will probably be EIDE
> soon)
Really? EIDE? I've never seen a CR-R (not re-writable) EIDE but
wouldn't venture to claim they don't exist.
If you want to find good SCSI stuff, look in the Macintosh magazines.
SCSI CD-RW's are fairly easy to find there, EIDE models are not. Prices
for SCSI in the Mac magazines are usually way under Computer Shopper
prices. SCSI CD-RW's are fairly easy to find there, EIDE models are not.
--
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 Sun Oct 19 16:55:25 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id QAA10005
for hackers-outgoing; Sun, 19 Oct 1997 16:55:25 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA10000
for <freebsd-hackers@freebsd.org>; Sun, 19 Oct 1997 16:55:22 -0700 (PDT)
(envelope-from jamil@trojanhorse.ml.org)
Received: from localhost (jamil@localhost)
by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id QAA02799;
Sun, 19 Oct 1997 16:55:15 -0700 (PDT)
Date: Sun, 19 Oct 1997 16:55:15 -0700 (PDT)
From: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
Reply-To: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
To: freebsd-hackers@freebsd.org
cc: jkh@time.cdrom.com
Subject: Device Driver Submission
Message-ID: <Pine.BSF.3.96.971019163936.2743A-100000@trojanhorse.ml.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I wish to submit my device driver. Its name is "dio". I have written a
man page for it and have debugged it extensively. It drives a digital i/o
board that supports only mode 0 on the intel 8255 PPI. It supports change
of state interrupts on all inputs (this is a feature not found in other
boards). This type of hardware is commonly used to drive solid state
relays, for instance I have some backplanes and relays that will allow you
to do high current AC or DC switching. The change of state interrupts
might be used anywhere you are waiting for some event to occur (such as
an an alarm system or an industrial machine that must do limit detection.)
The driver is about 500 lines, I have tested it to make sure that its
devfs hooks work correctly (DEVFS btw is pretty cool) and is well
documented.
I'd like to know how this is usually done, especially since this does not
support some kind of critical system that would adversely effect
stability. In other words it is very special-purpose.
for specs see: http://www.indcompsrc.com/products/data/html/dio48s_at-p.html
I've been considering buying some of this hardware to do home automation.
For instance if you want to control some 0-60volt 3AMP dc signals a
backplane with 24 Solid State Relays runs about $400.
The board itself costs $260. I've used them on many different projects.
From owner-freebsd-hackers Sun Oct 19 17:13:53 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id RAA11203
for hackers-outgoing; Sun, 19 Oct 1997 17:13:53 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from gaia.coppe.ufrj.br ([146.164.5.200])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA11198
for <freebsd-hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 17:13:41 -0700 (PDT)
(envelope-from jonny@coppe.ufrj.br)
Received: (from jonny@localhost)
by gaia.coppe.ufrj.br (8.8.7/8.8.7) id WAA14748;
Sun, 19 Oct 1997 22:13:27 -0200 (EDT)
(envelope-from jonny)
From: Joao Carlos Mendes Luis <jonny@coppe.ufrj.br>
Message-Id: <199710200013.WAA14748@gaia.coppe.ufrj.br>
Subject: Re: PThread
In-Reply-To: <Pine.BSF.3.96.971019203831.11291B-100000@localhost> from George Tavares at "Oct 19, 97 08:47:46 pm"
To: george@eps.ufsc.br (George Tavares)
Date: Sun, 19 Oct 1997 22:13:27 -0200 (EDT)
Cc: freebsd-hackers@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
#define quoting(George Tavares)
// I was using pthread (libc_r) packages I like to know if this
// package is the same from MIT (MIT pthread).
// When I running a pthread application, I press ^C and it doesn't
// kill my application (running same program im Solaris it works). The
// signals aren't passed to application?
// Another think, how I know what function are MT-SAFE. I don't see
// nothing about this in the man's.
// Why it is not compiled in make world? Many bugs?
One professor here at UFRJ had a program with pthreads that worked
with Solaris and froze with FreeBSD. Even ^C did not break the
running code. Only SIGKILL could stop it.
I took a look at the program at it was simply a problem with
not initialized pointers. Compile your code with -Wall and
see if it helps.
I think libc_r is not default because most applications do not
need it and would waste CPU for nothing.
Jonny
PS: I really wonder how Solaris can run wrong code and do not
complain at all... :)
--
Joao Carlos Mendes Luis jonny@gta.ufrj.br
+55 21 290-4698 jonny@coppe.ufrj.br
Universidade Federal do Rio de Janeiro UFRJ/COPPE/CISI
PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2 83 5F E3 26 BF 0F EA 67
From owner-freebsd-hackers Sun Oct 19 17:16:11 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id RAA11397
for hackers-outgoing; Sun, 19 Oct 1997 17:16:11 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from pahtoh.cwu.edu (root@pahtoh.cwu.edu [198.104.65.27])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA11246;
Sun, 19 Oct 1997 17:14:55 -0700 (PDT)
(envelope-from skynyrd@opus.cts.cwu.edu)
Received: from opus.cts.cwu.edu (skynyrd@opus.cts.cwu.edu [198.104.92.71])
by pahtoh.cwu.edu (8.8.7/8.8.7) with ESMTP id RAA18645;
Sun, 19 Oct 1997 17:14:53 -0700 (PDT)
Received: from localhost (skynyrd@localhost)
by opus.cts.cwu.edu (8.8.7/8.8.7) with SMTP id RAA09457;
Sun, 19 Oct 1997 17:14:52 -0700 (PDT)
Date: Sun, 19 Oct 1997 17:14:52 -0700 (PDT)
From: Chris Timmons <skynyrd@opus.cts.cwu.edu>
Reply-To: Chris Timmons <skynyrd@opus.cts.cwu.edu>
To: Robin Cutshaw <robin@intercore.com>
cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, Peter Wemm <peter@FreeBSD.ORG>,
hackers@FreeBSD.ORG
Subject: New de driver in 2.2.5-BETA
In-Reply-To: <19971019104510.16409@num1sun.intercore.com>
Message-ID: <Pine.BSF.3.95.971019163009.8934A-100000@opus.cts.cwu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
link2 won't ever help you again - see de(4).
I am running DEC DE500-XA cards. I built the world and the kernel a
couple of hours ago, and adding "media 100baseTX" achieves the desired
result (ie in place of link2 in the ifconfig for that interface.)
One de driver difference between -current and 2.2.5-beta is that
-current's ifconfig always shows you the media options, while 2.2.5-beta
does so only if you say 'ifconfig -m', the documented behavior for both
-stable and -current.
I'm not sure if it is a feature or bug, but if your interface is
ifconfig'ed when there is no carrier present (eg. first machine up on a
crossover cable), ifconfig will tell you that there is no carrier even
after link is established:
2.2.5-beta> ifconfig de0
de0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.1.9 netmask 0xfffffff8 broadcast 192.168.1.15
ether 00:00:f8:01:10:ad
media: 100baseTX status: no carrier
current> ifconfig de0
de0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.1.10 netmask 0xfffffff8 broadcast 192.168.1.15
ether 00:00:f8:01:12:e8
media: 100baseTX status: no carrier
supported media: autoselect 100baseTX <full-duplex> 100baseTX
10baseT/UTP <full-duplex> 10baseT/UTP
Other than that the updated driver appears to work fine on the DE500,
-current and 2.2.5-beta
-Chris
On Sun, 19 Oct 1997, Robin Cutshaw wrote:
> On Sat, Oct 18, 1997 at 09:32:17PM -0700, Jordan K. Hubbard wrote:
> > And, as things would have it, Peter has just committed a last minute
> > syncronization patch with Matt Thomas's latest to the de driver,
> > meaning that *anyone* with a DC21xxx based card should very definitely
> > install 2.2.5-971018-BETA from ftp.freebsd.org or one of its mirrors
> > as soon as possible and let us know if it *doesn't* work. If it does
> > work, great, you've nothing to worry about for 2.2.5. If it doesn't,
> > we need to know about it instantly! ;)
> >
>
> Still no joy. The de driver does not correctly detect 100 Mb/s mode
> and link2 doesn't change anything.
>
> robin
> --
> ----
> Robin Cutshaw internet: robin@interlabs.com robin@intercore.com
> Internet Labs, Inc. BellNet: 404-817-9787 robin@XFree86.Org
>
> "Time is just one damn thing after another" -- PBS/Nova
> ----
> --
>
From owner-freebsd-hackers Sun Oct 19 18:09:55 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA14564
for hackers-outgoing; Sun, 19 Oct 1997 18:09:55 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from iq.org (proff@profane.iq.org [203.4.184.222])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA14528
for <freebsd-hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 18:09:26 -0700 (PDT)
(envelope-from proff@iq.org)
From: proff@iq.org
Received: (qmail 4636 invoked by uid 110); 20 Oct 1997 01:09:10 -0000
Message-ID: <19971020010910.4635.qmail@iq.org>
Subject: Re: nasty problem with vnode and other disk drivers?
In-Reply-To: <199710191939.OAA04475@dyson.iquest.net> from "John S. Dyson" at "Oct 19, 97 02:39:00 pm"
To: toor@dyson.iquest.net (John S. Dyson)
Date: Mon, 20 Oct 1997 11:09:09 +1000 (EST)
Cc: proff@iq.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-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> From toor@dyson.iquest.net Sun Oct 19 19:40:17 1997
> Delivered-To: proff@iq.org
> From: "John S. Dyson" <toor@dyson.iquest.net>
> Message-Id: <199710191939.OAA04475@dyson.iquest.net>
> Subject: Re: nasty problem with vnode and other disk drivers?
> In-Reply-To: <19971019170838.1109.qmail@iq.org> from Julian Assange at "Oct 19, 97 05:08:38 pm"
> To: proff@iq.org (Julian Assange)
> Date: Sun, 19 Oct 1997 14:39:00 -0500 (EST)
> Cc: freebsd-hackers@FreeBSD.ORG
> X-Mailer: ELM [version 2.4ME+ PL31 (25)]
> Julian Assange said:
> >
> >
> > Surely this can't be correct behavior:
> >
> > # cp /usr/share/dict/words words
> > # head words
> > A
> > a
> > aa
> > aal
> > aalii
> > aam
> > Aani
> > aardvark
> > aardwolf
> > Aaron
> > # vnconfig /dev/vn0 words
> > # dd if=/dev/rvn0 bs=8 count=10
> > A
> > a
> > aa
> > aA
> > a
> > aa
> > aA
> > a
> > aa
> >
> It isn't expected behavior, but raw, block devices currently need I/O on
> 512 byte boundarys for integrals of 512 byte lengths.
>
> John
>
>
>
/dev/rvn0 is a character device. /dev/vn0 is the block device.
From owner-freebsd-hackers Sun Oct 19 18:23:09 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA15244
for hackers-outgoing; Sun, 19 Oct 1997 18:23:09 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA15236
for <freebsd-hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 18:23:01 -0700 (PDT)
(envelope-from toor@dyson.iquest.net)
Received: (from root@localhost)
by dyson.iquest.net (8.8.7/8.8.5) id UAA05647;
Sun, 19 Oct 1997 20:21:26 -0500 (EST)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199710200121.UAA05647@dyson.iquest.net>
Subject: Re: nasty problem with vnode and other disk drivers?
In-Reply-To: <19971020010910.4635.qmail@iq.org> from "proff@iq.org" at "Oct 20, 97 11:09:09 am"
To: proff@iq.org
Date: Sun, 19 Oct 1997 20:21:26 -0500 (EST)
Cc: freebsd-hackers@FreeBSD.ORG
Reply-To: dyson@FreeBSD.ORG
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-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
proff@iq.org said:
> > >
> > It isn't expected behavior, but raw, block devices currently need I/O on
> > 512 byte boundarys for integrals of 512 byte lengths.
> >
> > John
> >
> >
> >
>
> /dev/rvn0 is a character device. /dev/vn0 is the block device.
>
I understand, as I said (raw, block device) is a type of character
device. So is a tty. Try seeking on a tty -- it won't skip characters,
but it is possible to implement. Such (raw, block device) types usually
support aligned transfers only (even on some SVR4 derivatives.) If you
want to do unaligned transfers, it is best to do some buffering. There
might be something coming along in the future, but not now.
--
John
dyson@freebsd.org
jdyson@nc.com
From owner-freebsd-hackers Sun Oct 19 18:33:06 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA15816
for hackers-outgoing; Sun, 19 Oct 1997 18:33:06 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from intercore.com (num1sun.intercore.com [199.181.243.1])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA15810
for <hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 18:33:00 -0700 (PDT)
(envelope-from robin@intercore.com)
Received: (robin@localhost) by intercore.com (8.7.1/8.6.4) id VAA25193; Sun, 19 Oct 1997 21:29:59 -0400 (EDT)
Message-ID: <19971019212958.33788@num1sun.intercore.com>
Date: Sun, 19 Oct 1997 21:29:58 -0400
From: Robin Cutshaw <robin@intercore.com>
To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
Cc: hackers@FreeBSD.ORG
Subject: Re: fsck problem with 2.2.5-971015-BETA
References: <19971019112353.26513@num1sun.intercore.com> <19971019183550.SV35032@uriah.heep.sax.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.79
In-Reply-To: <19971019183550.SV35032@uriah.heep.sax.de>; from J Wunsch on Sun, Oct 19, 1997 at 06:35:50PM +0200
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Sun, Oct 19, 1997 at 06:35:50PM +0200, J Wunsch wrote:
> As Robin Cutshaw wrote:
>
> > "fsck -p" in /etc/rc fails when it gets to the 1st 9GB drive
> > with "cannot alloc 2088961 bytes for statemap".
>
> ISTR a comment that you need to increase the VM resource limits to
> fsck large filesystems.
>
Why does the fsck work correctly once the system is up in multi-user
mode?
robin
--
----
Robin Cutshaw internet: robin@interlabs.com robin@intercore.com
Internet Labs, Inc. BellNet: 404-817-9787 robin@XFree86.Org
"Time is just one damn thing after another" -- PBS/Nova
----
--
From owner-freebsd-hackers Sun Oct 19 18:40:55 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA16255
for hackers-outgoing; Sun, 19 Oct 1997 18:40:55 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA16249
for <hackers@freebsd.org>; Sun, 19 Oct 1997 18:40:47 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id LAA00451;
Mon, 20 Oct 1997 11:07:31 +0930 (CST)
Message-Id: <199710200137.LAA00451@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Dan Walters <hannibal@cyberstation.net>
cc: hackers@freebsd.org
Subject: Re: ATAPI CD-RW documentation...
In-reply-to: Your message of "Sun, 19 Oct 1997 17:42:46 EST."
<Pine.BSI.3.96.971019170816.20632A-100000@citrine.cyberstation.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 20 Oct 1997 11:07:30 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> I just ordered a EIDE CD-RW (all the 4x models I could find were EIDE, and
> if hard drives are any indication I bet most CD-RWs will probably be EIDE
> soon) and of course would like to use it under FreeBSD. I don't even see
> anything looking like support for it under Linux, which really surprised
> me. I'd be interested in at least attempting to implement some support
> for it. Can someone tell me where I could get my hands on some sort of
> programmer's guide or manual for these? Would the specifics for a CD-RW
> actually be covered in the ATAPI specs from WD?
What you have basically bought is a SCSI device with an IDE connector.
If you're serious about hacking on ATAPI support for FreeBSD, you will
want to grab the relevant specifications documents (I've got most of
them at ftp://ftp.smith.net.au/doc/ATAPI,CAM) and Justin Gibbs' CAM work
(from ftp://ftp.freebsd.org/pub/FreeBSD/incoming/cam-*).
Kenneth Merry and I were discussing this the last week or so; I can
send you various excerpts and some useful diagrams that came out of
that if you're interested.
mike
From owner-freebsd-hackers Sun Oct 19 18:46:30 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA16654
for hackers-outgoing; Sun, 19 Oct 1997 18:46:30 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from mother.sneaker.net.au (akm@mother.sneaker.net.au [203.30.3.2])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA16641
for <freebsd-hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 18:46:23 -0700 (PDT)
(envelope-from akm@mother.sneaker.net.au)
Received: (from akm@localhost)
by mother.sneaker.net.au (8.8.5/8.8.5) id LAA06957;
Mon, 20 Oct 1997 11:54:28 GMT
From: Andrew Kenneth Milton <akm@mother.sneaker.net.au>
Message-Id: <199710201154.LAA06957@mother.sneaker.net.au>
Subject: Re: PThread
To: jonny@coppe.ufrj.br (Joao Carlos Mendes Luis)
Date: Mon, 20 Oct 1997 11:54:28 +0000 ()
Cc: george@eps.ufsc.br, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <199710200013.WAA14748@gaia.coppe.ufrj.br> from "Joao Carlos Mendes Luis" at Oct 19, 97 10:13:27 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-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
+-----[ Joao Carlos Mendes Luis ]------------------------------
|
| PS: I really wonder how Solaris can run wrong code and do not
| complain at all... :)
I'll drift off topic here and just say, that HPUX lets you dereference
NULL pointers as many times as you want, without skipping a beat. They
always return NULL though, not random data, so I suppose it's an
alternative form of robustness.
--
,-_|\ SneakerNet | Andrew Milton | GSM: +61(41)6 022 411
/ \ P.O. Box 154 | akm@sneaker.net.au | Fax: +61(2) 9746 8233
\_,-._/ N Strathfield +--+----------------------+---+ Ph: +61(2) 9746 8233
v NSW 2137 | Low cost Internet Solutions |
From owner-freebsd-hackers Sun Oct 19 18:53:35 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA17127
for hackers-outgoing; Sun, 19 Oct 1997 18:53:35 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from intercore.com (num1sun.intercore.com [199.181.243.1])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA16700;
Sun, 19 Oct 1997 18:47:09 -0700 (PDT)
(envelope-from robin@intercore.com)
Received: (robin@localhost) by intercore.com (8.7.1/8.6.4) id VAA25218; Sun, 19 Oct 1997 21:42:59 -0400 (EDT)
Message-ID: <19971019214258.62172@num1sun.intercore.com>
Date: Sun, 19 Oct 1997 21:42:58 -0400
From: Robin Cutshaw <robin@intercore.com>
To: Chris Timmons <skynyrd@opus.cts.cwu.edu>
Cc: Robin Cutshaw <robin@intercore.com>,
"Jordan K. Hubbard" <jkh@time.cdrom.com>,
Peter Wemm <peter@FreeBSD.ORG>, hackers@FreeBSD.ORG
Subject: Re: New de driver in 2.2.5-BETA
References: <19971019104510.16409@num1sun.intercore.com> <Pine.BSF.3.95.971019163009.8934A-100000@opus.cts.cwu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.79
In-Reply-To: <Pine.BSF.3.95.971019163009.8934A-100000@opus.cts.cwu.edu>; from Chris Timmons on Sun, Oct 19, 1997 at 05:14:52PM -0700
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Sun, Oct 19, 1997 at 05:14:52PM -0700, Chris Timmons wrote:
>
> I am running DEC DE500-XA cards. I built the world and the kernel a
> couple of hours ago, and adding "media 100baseTX" achieves the desired
> result (ie in place of link2 in the ifconfig for that interface.)
>
Correct you are. With "media 100baseTX" it works (even with the
971015 kernel). Looks like autosense is not working.
robin
From owner-freebsd-hackers Sun Oct 19 18:58:55 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA17434
for hackers-outgoing; Sun, 19 Oct 1997 18:58:55 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from dcarmich.pr.mcs.net (dcarmich.pr.mcs.net [204.95.63.202])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA17421
for <freebsd-hackers@freebsd.org>; Sun, 19 Oct 1997 18:58:45 -0700 (PDT)
(envelope-from dcarmich@dcarmich.pr.mcs.net)
Received: (from dcarmich@localhost)
by dcarmich.pr.mcs.net (8.8.5/8.8.5) id VAA00264;
Sun, 19 Oct 1997 21:02:20 -0500 (CDT)
Message-ID: <19971019210220.51925@dcarmich.pr.mcs.net>
Date: Sun, 19 Oct 1997 21:02:20 -0500
From: Douglas Carmichael <dcarmich@mcs.com>
To: freebsd-hackers@freebsd.org
Subject: Any X.25 support for FreeBSD?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.74e
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Is there any support coming for X.25 in FreeBSD, e.g. Eicon cards?
(I'd love to hook up a BBS machine to Sprintnet/Tymnet)
From owner-freebsd-hackers Sun Oct 19 19:42:54 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA19750
for hackers-outgoing; Sun, 19 Oct 1997 19:42:54 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA19741
for <hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 19:42:47 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id MAA00729;
Mon, 20 Oct 1997 12:09:23 +0930 (CST)
Message-Id: <199710200239.MAA00729@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Andrew Kenneth Milton <akm@mother.sneaker.net.au>
cc: hackers@FreeBSD.ORG
Subject: Re: PThread
In-reply-to: Your message of "Mon, 20 Oct 1997 11:54:28 GMT."
<199710201154.LAA06957@mother.sneaker.net.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 20 Oct 1997 12:09:23 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> +-----[ Joao Carlos Mendes Luis ]------------------------------
> |
> | PS: I really wonder how Solaris can run wrong code and do not
> | complain at all... :)
>
> I'll drift off topic here and just say, that HPUX lets you dereference
> NULL pointers as many times as you want, without skipping a beat. They
> always return NULL though, not random data, so I suppose it's an
> alternative form of robustness.
This is called "mapping page zero", and it is a concession to all those
stupid programmers out there that don't have the brains Zoroaster gave
a rock.
mike
(Apologies to any Zoroastrians out there that feel that rocks weren't so
hard done by as I am implying.)
From owner-freebsd-hackers Sun Oct 19 19:58:58 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA20542
for hackers-outgoing; Sun, 19 Oct 1997 19:58:58 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from postoffice.onu.edu (postoffice.onu.edu [140.228.10.2])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA20529
for <freebsd-hackers@freebsd.org>; Sun, 19 Oct 1997 19:58:47 -0700 (PDT)
(envelope-from n-ludban@onu.edu)
Received: from austin.onu.edu (austin.onu.edu [140.228.10.1])
by postoffice.onu.edu (8.8.5/8.8.5) with SMTP id WAA18391
for <freebsd-hackers@freebsd.org>; Sun, 19 Oct 1997 22:58:30 -0400 (EDT)
Date: Sun, 19 Oct 1997 22:58:34 -0400 (EDT)
From: Neil Ludban <n-ludban@onu.edu>
To: freebsd-hackers@freebsd.org
Subject: NCR 53c875j support?
Message-ID: <Pine.A32.3.96.971019190349.32001A-100000@austin.onu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Hello,
I've ruled out everything I could think of on this problem, and what's
left points to a question about the ncr driver for -hackers.
I'm trying to get FreeBSD 2.2.2-RELEASE to recognize a Diamond FirePort40
SCSI adapter, which uses the NCR 53c875j chip. A borrowed Asus PCI-SC875
is recognized correctly on the same system (53c875 chip, no j). I looked
through the ncr code and found the identification numbers for different
chip numbers, but didn't see anything about the 875j or even different
revisions of other chips.
Can anyone tell me if this should already work (I got a bad card, or a
messed up BIOS), or explain where to start to add support? According to
Symbios' web site, the j suffix means it "supports JTAG boundary scan for
onboard testing." I assume that if the current driver were to recognize
it, it would act like a plain 875, which would be good enough for me.
I've double checked all the BIOS settings, moved cards around, and removed
everything except the PCI video card (Graphics Blaster, CL5462 chip). The
motherboard is a HOT-433, with 486 PCI/ISA BIOS from AMI (copyright 1993),
and UMC 8881/8886 chipset. The only thing I have not done is install
Win95 to verify that the card works with its own drivers.
A possibly related problem is that having both SCSI cards installed at
once, or the Asus with a PCI NIC (ed2, RealTek 8029) causes the boot to
hang after the imasks line. The next thing should have been the BIOS
disk geometries. FWIW, the geometry of the SCSI disk is correct for
either controller.
Thanks for any help--
--Neil
Here'e the BIOS message from the FirePort40:
Diamond Multimedia Systems, Inc. SDMS (TM) V 4.0 PCI SCSI BIOS
Copyright 1995, 1996 Symbios Logic.
FirePort40 SCSI Host Adapter
DIAMOND-4.03.08c
And here's the pci section from dmesg after a boot -v with the 875j:
Copyright (c) 1992-1997 FreeBSD Inc.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 2.2.2-RELEASE #0: Thu Oct 2 20:49:53 EDT 1997
nludban@austin2.onu.edu:/usr/src/sys/compile/TIGGER
Calibrating clock(s) ... i8254 clock: 1193365 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
CPU: AMD Am5x86 Write-Back (486-class CPU)
Origin = "AuthenticAMD" Id = 0x4f4 Stepping=4
Features=0x1<FPU>
real memory = 33554432 (32768K bytes)
avail memory = 30351360 (29640K bytes)
pcibus_setup(1): mode 1 addr port (0x0cf8) is 0x80009040
pcibus_setup(1a): mode1res=0x80000000 (0x80000000)
pcibus_check: device 0 1 2 3 4 5 6 7 8 9 10 11 12 is there (id=008f1000)
Probing for devices on PCI bus 0:
configuration mode 1 allows 32 devices.
pci0:12: NCR/Symbios, device=0x008f, class=storage (scsi) int a irq 11
[no driver assigned]
map(10): io(fc00)
map(14): mem32(ffbebf00)
map(18): mem32(ffbea000)
vga0 <VGA-compatible display device> rev 1 on pci0:13
mapreg[10] type=0 addr=ffbec000 size=4000.
mapreg[14] type=0 addr=fc000000 size=2000000.
chip0 <generic PCI bridge (vendor=1060 device=8881 subclass=0)> rev 4 on
pci0:16
chip1 <generic PCI bridge (vendor=1060 device=886a subclass=1)> rev 14 on
pci0:18:0
pci0:18:1: UMC, device=0x673a, class=storage (ide) [no driver assigned]
map(10): io(ffe0)
map(14): io(fff0)
map(18): io(ffa8)
map(1c): io(ffa4)
map(20): io(ff90)
pci0: uses 33570816 bytes of memory from fc000000 upto ffbeffff.
Probing for devices on the ISA bus:
From owner-freebsd-hackers Sun Oct 19 20:05:18 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id UAA20908
for hackers-outgoing; Sun, 19 Oct 1997 20:05:18 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from shell.futuresouth.com (shell.futuresouth.com [207.141.254.20])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA20901
for <hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 20:05:11 -0700 (PDT)
(envelope-from fullermd@futuresouth.com)
Received: from shell.futuresouth.com (mail.futuresouth.com [207.141.254.21])
by shell.futuresouth.com (8.8.5/8.8.5) with SMTP id WAA25924;
Sun, 19 Oct 1997 22:04:50 -0500 (CDT)
Date: Sun, 19 Oct 1997 22:04:50 -0500 (CDT)
From: "Matthew D. Fuller" <fullermd@futuresouth.com>
To: Robin Cutshaw <robin@intercore.com>
cc: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>, hackers@FreeBSD.ORG
Subject: Re: fsck problem with 2.2.5-971015-BETA
In-Reply-To: <19971019212958.33788@num1sun.intercore.com>
Message-ID: <Pine.BSF.3.96.971019220410.24477A-100000@shell.futuresouth.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Sun, 19 Oct 1997, Robin Cutshaw wrote:
> On Sun, Oct 19, 1997 at 06:35:50PM +0200, J Wunsch wrote:
> > As Robin Cutshaw wrote:
> >
> > > "fsck -p" in /etc/rc fails when it gets to the 1st 9GB drive
> > > with "cannot alloc 2088961 bytes for statemap".
> >
> > ISTR a comment that you need to increase the VM resource limits to
> > fsck large filesystems.
> >
>
> Why does the fsck work correctly once the system is up in multi-user
> mode?
Because in multi-user, it has access to swap. If your turn swapon in
single-user, I'll bet the fsck will work.
>
> robin
> --
> ----
> Robin Cutshaw internet: robin@interlabs.com robin@intercore.com
> Internet Labs, Inc. BellNet: 404-817-9787 robin@XFree86.Org
>
> "Time is just one damn thing after another" -- PBS/Nova
> ----
> --
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| FreeBSD; the way computers were meant to be |
* "The only reason I'm burning my candle at both ends, is *
| that I haven't figured out how to light the middle yet."|
* fullermd@futuresouth.com :-} MAtthew Fuller *
| http://keystone.westminster.edu/~fullermd |
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
From owner-freebsd-hackers Sun Oct 19 21:24:18 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id VAA25134
for hackers-outgoing; Sun, 19 Oct 1997 21:24:18 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from dfw-ix16.ix.netcom.com (dfw-ix16.ix.netcom.com [206.214.98.16])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA25124
for <freebsd-hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 21:24:13 -0700 (PDT)
(envelope-from wghhicks@ix.netcom.com)
Received: (from smap@localhost)
by dfw-ix16.ix.netcom.com (8.8.4/8.8.4)
id XAA09662; Sun, 19 Oct 1997 23:23:08 -0500 (CDT)
Received: from atl-ga16-13.ix.netcom.com(204.32.174.141) by dfw-ix16.ix.netcom.com via smap (V1.3)
id rma009632; Sun Oct 19 23:22:32 1997
Message-ID: <344ADB89.46FC5A59@ix.netcom.com>
Date: Mon, 20 Oct 1997 00:18:17 -0400
From: Jerry Hicks <wghhicks@ix.netcom.com>
Reply-To: wghhicks@ix.netcom.com
Organization: TerraEarth
X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 2.2-STABLE i386)
MIME-Version: 1.0
To: Douglas Carmichael <dcarmich@mcs.com>
CC: freebsd-hackers@FreeBSD.ORG
Subject: Re: Any X.25 support for FreeBSD?
References: <19971019210220.51925@dcarmich.pr.mcs.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Douglas Carmichael wrote:
>
> Is there any support coming for X.25 in FreeBSD, e.g. Eicon cards?
> (I'd love to hook up a BBS machine to Sprintnet/Tymnet)
Eicon makes a developer sign a rather ugly NDA last time I tried.
It's a shame, their boards are my fave...
Jerry Hicks
jerry_hicks@bigfoot.com
From owner-freebsd-hackers Sun Oct 19 21:26:08 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id VAA25300
for hackers-outgoing; Sun, 19 Oct 1997 21:26:08 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from mail.san.rr.com (mail-atm.san.rr.com [204.210.0.1])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA25272
for <freebsd-hackers@freebsd.org>; Sun, 19 Oct 1997 21:25:59 -0700 (PDT)
(envelope-from Studded@dal.net)
Received: from dt5h1n61.san.rr.com (dt5h1n61.san.rr.com [204.210.31.97])
by mail.san.rr.com (8.8.7/8.8.7) with SMTP id VAA06271
for <freebsd-hackers@freebsd.org>; Sun, 19 Oct 1997 21:25:05 -0700 (PDT)
Message-Id: <199710200425.VAA06271@mail.san.rr.com>
From: "Studded" <Studded@dal.net>
To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Date: Sun, 19 Oct 97 21:24:57 -0700
Reply-To: "Studded" <Studded@dal.net>
Priority: Normal
X-Mailer: PMMail 1.95a For OS/2
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Fwd: misc/4766: Changes to rc* scripts for ipfw
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Pardon my forwarding this to yet another list, but it's been 5 days now, the deadline is
close at hand, and I've yet to hear any kind of comment on this. Even "Doug, go away." would
be fine at this point. :) If the concept of making the default rule "open" is too much of a
challenge, I would really like to suggest that some kind of warning is included in rc.conf, since
I think the fact that "open" is not the same as "OPEN" will cause more than one person to
stumble.
I have temporarily subscribed to -hackers since that seems to be the list that is next
most likely to get a response. I would prefer that discussion about this take place on -stable
though, since that is where it started. I know y'all are busy and it's close to release time, but
the actual changes I'm proposing are quite small (except for the default policy change, which
is easily reversed) and I really believe they will add to the usability of the system.
Thanks for your time,
Doug
==================BEGIN FORWARDED MESSAGE==================
>Date: Tue, 14 Oct 1997 20:59:14 -0700 (PDT)
>From: studded@dal.net
>Number: 4766
>Category: misc
>Synopsis: Simple changes to make ipfw safer and easier to use
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: freebsd-bugs
>State: open
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Tue Oct 14 21:00:01 PDT 1997
>Last-Modified:
>Originator: Studded
>Organization:
DALnet IRC network
>Release: FreeBSD 2.2.5-971012-BETA i386
>Environment:
All FreeBSD 2.2x systems. (Note that I'm unsure about the
category.)
>Description:
The ipfw functionality is a valuable part of FreeBSD, however
compiling it into the kernel or enabling the option in rc.conf (which
currently loads the kernel module from rc.network) can lead to a system
accidentally being closed off from the internet. This is especially
dangerous when administering a system remotely.
>How-To-Repeat:
Load ipfw.
>Fix:
The following patch (in both unified and context format because I
can never remember what y'all like :) make a few small changes to rc.conf
to make things more clear, add some safety features to rc.network and
rc.firewall so that the default firewall type is open, and makes sure that
rc.firewall is loaded if there is ipfw functionality in the kernel. It
also makes a small change to the rc.firewall script so that the rules in
the script look like the rules you see when doing 'ipfw list.' Finally it
makes rc.firewall and rc.network friendlier to a mistake in case for "YES"
vs. "yes," etc.
I realize that making the default rule "open" is a controversial
thing, however it would be trivial for someone who *wanted* a closed
system to make the firewall type "CLOSED." On the other hand, someone
compiling the ipfw option into the kernel or enabling it in rc.conf
without doing their "homework" will find themself with anything from a
mysterious situation to a catastrophic error for someone administering a
system remotely.
Even if the powers that be do not accept my proposal for changing
the default rule, I'd like serious consideration for the expanded and
clarified warning messages, and the change from "pass all" to "allow ip"
in rc.firewall.
There is currently a discussion on this topic happening on
freebsd-stable.
Hope this helps,
Doug
Context format:
diff -cr ../etc-1014/rc.conf ./rc.conf
*** ../etc-1014/rc.conf Sun Oct 12 13:33:28 1997
--- ./rc.conf Tue Oct 14 18:19:56 1997
***************
*** 4,10 ****
# This is rc.conf - a file full of useful variables that you can set
# to change the default startup behavior of your system.
#
! # All arguments must be in double or single quotes.
#
# $Id: rc.conf,v 1.1.2.26 1997/10/12 20:33:28 imp Exp $
--- 4,12 ----
# This is rc.conf - a file full of useful variables that you can set
# to change the default startup behavior of your system.
#
! # All arguments must be in double or single quotes, and are case sensitive.
! # Therefore you should use CAPITAL LETTERS for the YES/NO options.
! # "NO" is not the same as "no".
#
# $Id: rc.conf,v 1.1.2.26 1997/10/12 20:33:28 imp Exp $
***************
*** 28,35 ****
hostname="myname.my.domain" # Set this!
nisdomainname="NO" # Set to NIS domain if using NIS (or NO).
firewall_enable="NO" # Set to YES to enable firewall functionality
- firewall_type="UNKNOWN" # Firewall type (see
/etc/rc.firewall)
firewall_quiet="NO" # Set to YES to suppress rule display
tcp_extensions="YES" # Allow RFC1323 & RFC1544 extensions (or NO).
network_interfaces="lo0" # List of network interfaces (lo0 is loopback).
ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration.
--- 30,38 ----
hostname="myname.my.domain" # Set this!
nisdomainname="NO" # Set to NIS domain if using NIS (or NO).
firewall_enable="NO" # Set to YES to enable firewall functionality
firewall_quiet="NO" # Set to YES to suppress rule display
+ firewall_type="OPEN" # Firewall type (see /etc/rc.firewall)
+ # "OPEN" allows all traffic to pass by default. Other options are available.
tcp_extensions="YES" # Allow RFC1323 & RFC1544 extensions (or NO).
network_interfaces="lo0" # List of network interfaces (lo0 is loopback).
ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration.
diff -cr ../etc-1014/rc.firewall ./rc.firewall
*** ../etc-1014/rc.firewall Thu Sep 18 15:47:10 1997
--- ./rc.firewall Tue Oct 14 19:50:42 1997
***************
*** 4,13 ****
############
# Define the firewall type in /etc/rc.conf. Valid values are:
! # open - will allow anyone in
! # client - will try to protect just this machine
! # simple - will try to protect a whole network
! # closed - totally disables IP services except via lo0 interface
# UNKNOWN - disables the loading of firewall rules.
# filename - will load the rules in the given filename (full path required)
#
--- 4,13 ----
############
# Define the firewall type in /etc/rc.conf. Valid values are:
! # OPEN - will allow anyone in
! # CLIENT - will try to protect just this machine
! # SIMPLE - will try to protect a whole network
! # CLOSED - totally disables IP services except via lo0 interface
# UNKNOWN - disables the loading of firewall rules.
# filename - will load the rules in the given filename (full path required)
#
***************
*** 39,49 ****
if [ "x$1" != "x" ]; then
firewall_type=$1
fi
############
# Set quiet mode if requested
! if [ "x$firewall_quiet" = "xYES" ]; then
fwcmd="/sbin/ipfw -q"
else
fwcmd="/sbin/ipfw"
--- 39,51 ----
if [ "x$1" != "x" ]; then
firewall_type=$1
+ else
+ firewall_type=OPEN
fi
############
# Set quiet mode if requested
! if [ "x$firewall_quiet" = "xYES" -o "x$firewall_quiet" = "xyes" ]; then
fwcmd="/sbin/ipfw -q"
else
fwcmd="/sbin/ipfw"
***************
*** 53,77 ****
# Flush out the list before we begin.
$fwcmd -f flush
############
# If you just configured ipfw in the kernel as a tool to solve network
# problems or you just want to disallow some particular kinds of traffic
# they you will want to change the default policy to open. You can also
! # do this as your only action by setting the firewall_type to ``open''.
! # $fwcmd add 65000 pass all from any to any
############
# Only in rare cases do you want to change this rule
! $fwcmd add 1000 pass all from 127.0.0.1 to 127.0.0.1
# Prototype setups.
! if [ "${firewall_type}" = "open" ]; then
! $fwcmd add 65000 pass all from any to any
! elif [ "${firewall_type}" = "client" ]; then
############
# This is a prototype setup that will protect your system somewhat against
--- 55,85 ----
# Flush out the list before we begin.
$fwcmd -f flush
+ # In the examples below, the words "allow" and "ip" are equivalent to
+ # "pass" and "all" as used in this file previously, and accurately reflect
+ # how ipfw will list the rules when you use ipfw list. See man ipfw(8)
+ # for more details.
+
############
# If you just configured ipfw in the kernel as a tool to solve network
# problems or you just want to disallow some particular kinds of traffic
# they you will want to change the default policy to open. You can also
! # do this as your only action by setting the firewall_type to "OPEN" in
! # /etc/rc.conf.
! # $fwcmd add 65000 allow ip from any to any
############
# Only in rare cases do you want to change this rule
! $fwcmd add 100 allow ip from 127.0.0.1 to 127.0.0.1
# Prototype setups.
! if [ "${firewall_type}" = "OPEN" -o "${firewall_type}" = "open" ]; then
! $fwcmd add 65000 allow ip from any to any
! elif [ "${firewall_type}" = "CLIENT" -o "${firewall_type}" = "client" ]; then
############
# This is a prototype setup that will protect your system somewhat against
***************
*** 84,115 ****
ip="192.168.4.17"
# Allow any traffic to or from my own net.
! $fwcmd add pass all from ${ip} to ${net}:${mask}
! $fwcmd add pass all from ${net}:${mask} to ${ip}
# Allow TCP through if setup succeeded
! $fwcmd add pass tcp from any to any established
# Allow setup of incoming email
! $fwcmd add pass tcp from any to ${ip} 25 setup
# Allow setup of outgoing TCP connections only
! $fwcmd add pass tcp from ${ip} to any setup
# Disallow setup of all other TCP connections
$fwcmd add deny tcp from any to any setup
# Allow DNS queries out in the world
! $fwcmd add pass udp from any 53 to ${ip}
! $fwcmd add pass udp from ${ip} to any 53
# Allow NTP queries out in the world
! $fwcmd add pass udp from any 123 to ${ip}
! $fwcmd add pass udp from ${ip} to any 123
# Everything else is denied as default.
! elif [ "${firewall_type}" = "simple" ]; then
############
# This is a prototype setup for a simple firewall. Configure this machine
--- 92,125 ----
ip="192.168.4.17"
# Allow any traffic to or from my own net.
! $fwcmd add allow ip from ${ip} to ${net}:${mask}
! $fwcmd add allow ip from ${net}:${mask} to ${ip}
# Allow TCP through if setup succeeded
! $fwcmd add allow tcp from any to any established
# Allow setup of incoming email
! $fwcmd add allow tcp from any to ${ip} 25 setup
# Allow setup of outgoing TCP connections only
! $fwcmd add allow tcp from ${ip} to any setup
# Disallow setup of all other TCP connections
$fwcmd add deny tcp from any to any setup
# Allow DNS queries out in the world
! # (BIND 8.1.1 and later do not use port 53 by
! # default, but it can be configured to do so.)
! $fwcmd add allow udp from any 53 to ${ip}
! $fwcmd add allow udp from ${ip} to any 53
# Allow NTP queries out in the world
! $fwcmd add allow udp from any 123 to ${ip}
! $fwcmd add allow udp from ${ip} to any 123
# Everything else is denied as default.
! elif [ "${firewall_type}" = "SIMPLE" -o "${firewall_type}" = "simple" ]; then
############
# This is a prototype setup for a simple firewall. Configure this machine
***************
*** 130,171 ****
iip="192.168.3.17"
# Stop spoofing
! $fwcmd add deny all from ${inet}:${imask} to any in via ${oif}
! $fwcmd add deny all from ${onet}:${omask} to any in via ${iif}
# Stop RFC1918 nets on the outside interface
! $fwcmd add deny all from 192.168.0.0:255.255.0.0 to any via ${oif}
! $fwcmd add deny all from 172.16.0.0:255.240.0.0 to any via ${oif}
! $fwcmd add deny all from 10.0.0.0:255.0.0.0 to any via ${oif}
# Allow TCP through if setup succeeded
! $fwcmd add pass tcp from any to any established
# Allow setup of incoming email
! $fwcmd add pass tcp from any to ${oip} 25 setup
# Allow access to our DNS
! $fwcmd add pass tcp from any to ${oip} 53 setup
# Allow access to our WWW
! $fwcmd add pass tcp from any to ${oip} 80 setup
# Reject&Log all setup of incoming connections from the outside
$fwcmd add deny log tcp from any to any in via ${oif} setup
# Allow setup of any other TCP connection
! $fwcmd add pass tcp from any to any setup
# Allow DNS queries out in the world
! $fwcmd add pass udp from any 53 to ${oip}
! $fwcmd add pass udp from ${oip} to any 53
# Allow NTP queries out in the world
! $fwcmd add pass udp from any 123 to ${oip}
! $fwcmd add pass udp from ${oip} to any 123
# Everything else is denied as default.
! elif [ "${firewall_type}" != "NONE" -a -r "${firewall_type}" ]; then
$fwcmd ${firewall_type}
fi
--- 140,185 ----
iip="192.168.3.17"
# Stop spoofing
! $fwcmd add deny ip from ${inet}:${imask} to any in via ${oif}
! $fwcmd add deny ip from ${onet}:${omask} to any in via ${iif}
# Stop RFC1918 nets on the outside interface
! $fwcmd add deny ip from 192.168.0.0:255.255.0.0 to any via ${oif}
! $fwcmd add deny ip from 172.16.0.0:255.240.0.0 to any via ${oif}
! $fwcmd add deny ip from 10.0.0.0:255.0.0.0 to any via ${oif}
# Allow TCP through if setup succeeded
! $fwcmd add allow tcp from any to any established
# Allow setup of incoming email
! $fwcmd add allow tcp from any to ${oip} 25 setup
# Allow access to our DNS
! # (BIND 8.1.1 and later do not use port 53 by
! # default, but it can be configured to do so.)
! $fwcmd add allow tcp from any to ${oip} 53 setup
# Allow access to our WWW
! $fwcmd add allow tcp from any to ${oip} 80 setup
# Reject&Log all setup of incoming connections from the outside
$fwcmd add deny log tcp from any to any in via ${oif} setup
# Allow setup of any other TCP connection
! $fwcmd add allow tcp from any to any setup
# Allow DNS queries out in the world
! # (BIND 8.1.1 and later do not use port 53 by
! # default, but it can be configured to do so.)
! $fwcmd add allow udp from any 53 to ${oip}
! $fwcmd add allow udp from ${oip} to any 53
# Allow NTP queries out in the world
! $fwcmd add allow udp from any 123 to ${oip}
! $fwcmd add allow udp from ${oip} to any 123
# Everything else is denied as default.
! elif [ "${firewall_type}" != "UNKNOWN -a -r "${firewall_type}" ]; then
$fwcmd ${firewall_type}
fi
diff -cr ../etc-1014/rc.network ./rc.network
*** ../etc-1014/rc.network Thu Sep 18 15:47:12 1997
--- ./rc.network Tue Oct 14 20:28:16 1997
***************
*** 55,88 ****
ifconfig ${ifn}
done
! # Initialize IP filtering using ipfw
! echo ""
/sbin/ipfw -q flush > /dev/null 2>&1
! if [ $? = 1 ] ; then
firewall_in_kernel=0
else
firewall_in_kernel=1
fi
! if [ $firewall_in_kernel = 0 -a "x$firewall_enable" = "xYES" ] ; then
! modload /lkm/ipfw_mod.o
! if [ $? = 0 ]; then
! firewall_in_kernel=1 # module loaded successfully
! echo "Kernel firewall module loaded."
! else
! echo "Warning: firewall kernel module failed to load."
fi
fi
! # Load the filters if required
if [ $firewall_in_kernel = 1 ]; then
! if [ -n "$firewall_enable" -a -f /etc/rc.firewall -a \
! "x$firewall_enable" = "xYES" ] ; then
! . /etc/rc.firewall
! echo "Firewall rules loaded."
else
! echo "Warning: kernel has firewall functionality, but firewall rules are not enabled."
! echo " All ip services are disabled."
fi
fi
--- 55,95 ----
ifconfig ${ifn}
done
! echo "Initializing IP filtering using ipfw."
!
/sbin/ipfw -q flush > /dev/null 2>&1
! if [ $? != 0 ]; then
firewall_in_kernel=0
else
firewall_in_kernel=1
fi
! if [ "x$firewall_enable" = "xYES" -o "x$firewall_enable" = "xyes" ]; then
!
! if [ $firewall_in_kernel = 0 ]; then
! /sbin/modload /lkm/ipfw_mod.o
!
! if [ $? = 0 ]; then
! firewall_in_kernel=1
! echo "Kernel firewall module loaded successfully."
! else
! echo "Warning: Firewall is enabled in /etc/rc.conf, but it is not compiled"
! echo "Warning: into the kernel, and the kernel module failed to load."
! fi
fi
fi
! # Load the filters if ipfw is in the kernel or loaded above.
!
if [ $firewall_in_kernel = 1 ]; then
! if [ -r /etc/rc.firewall ]; then
! . /etc/rc.firewall
! echo "Firewall rules loaded from /etc/rc.firewall."
else
! echo "Warning: Firewall functionality is enabled, but firewall rules were"
! echo "Warning: not loaded from /etc/rc.firewall."
! echo ""
! echo "Warning: *** All IP services are disabled. ***"
fi
fi
Unified format:
diff -ur ../etc-1014/rc.conf ./rc.conf
--- ../etc-1014/rc.conf Sun Oct 12 13:33:28 1997
+++ ./rc.conf Tue Oct 14 18:19:56 1997
@@ -4,7 +4,9 @@
# This is rc.conf - a file full of useful variables that you can set
# to change the default startup behavior of your system.
#
-# All arguments must be in double or single quotes.
+# All arguments must be in double or single quotes, and are case sensitive.
+# Therefore you should use CAPITAL LETTERS for the YES/NO options.
+# "NO" is not the same as "no".
#
# $Id: rc.conf,v 1.1.2.26 1997/10/12 20:33:28 imp Exp $
@@ -28,8 +30,9 @@
hostname="myname.my.domain" # Set this!
nisdomainname="NO" # Set to NIS domain if using NIS (or NO).
firewall_enable="NO" # Set to YES to enable firewall functionality
-firewall_type="UNKNOWN" # Firewall type (see /etc/rc.firewall)
firewall_quiet="NO" # Set to YES to suppress rule display
+firewall_type="OPEN" # Firewall type (see /etc/rc.firewall)
+# "OPEN" allows all traffic to pass by default. Other options are available.
tcp_extensions="YES" # Allow RFC1323 & RFC1544 extensions (or NO).
network_interfaces="lo0" # List of network interfaces (lo0 is loopback).
ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration.
diff -ur ../etc-1014/rc.firewall ./rc.firewall
--- ../etc-1014/rc.firewall Thu Sep 18 15:47:10 1997
+++ ./rc.firewall Tue Oct 14 19:50:42 1997
@@ -4,10 +4,10 @@
############
# Define the firewall type in /etc/rc.conf. Valid values are:
-# open - will allow anyone in
-# client - will try to protect just this machine
-# simple - will try to protect a whole network
-# closed - totally disables IP services except via lo0 interface
+# OPEN - will allow anyone in
+# CLIENT - will try to protect just this machine
+# SIMPLE - will try to protect a whole network
+# CLOSED - totally disables IP services except via lo0 interface
# UNKNOWN - disables the loading of firewall rules.
# filename - will load the rules in the given filename (full path required)
#
@@ -39,11 +39,13 @@
if [ "x$1" != "x" ]; then
firewall_type=$1
+else
+ firewall_type=OPEN
fi
############
# Set quiet mode if requested
-if [ "x$firewall_quiet" = "xYES" ]; then
+if [ "x$firewall_quiet" = "xYES" -o "x$firewall_quiet" = "xyes" ]; then
fwcmd="/sbin/ipfw -q"
else
fwcmd="/sbin/ipfw"
@@ -53,25 +55,31 @@
# Flush out the list before we begin.
$fwcmd -f flush
+# In the examples below, the words "allow" and "ip" are equivalent to
+# "pass" and "all" as used in this file previously, and accurately reflect
+# how ipfw will list the rules when you use ipfw list. See man ipfw(8)
+# for more details.
+
############
# If you just configured ipfw in the kernel as a tool to solve network
# problems or you just want to disallow some particular kinds of traffic
# they you will want to change the default policy to open. You can also
-# do this as your only action by setting the firewall_type to ``open''.
+# do this as your only action by setting the firewall_type to "OPEN" in
+# /etc/rc.conf.
-# $fwcmd add 65000 pass all from any to any
+# $fwcmd add 65000 allow ip from any to any
############
# Only in rare cases do you want to change this rule
-$fwcmd add 1000 pass all from 127.0.0.1 to 127.0.0.1
+$fwcmd add 100 allow ip from 127.0.0.1 to 127.0.0.1
# Prototype setups.
-if [ "${firewall_type}" = "open" ]; then
+if [ "${firewall_type}" = "OPEN" -o "${firewall_type}" = "open" ]; then
- $fwcmd add 65000 pass all from any to any
+ $fwcmd add 65000 allow ip from any to any
-elif [ "${firewall_type}" = "client" ]; then
+elif [ "${firewall_type}" = "CLIENT" -o "${firewall_type}" = "client" ]; then
############
# This is a prototype setup that will protect your system somewhat against
@@ -84,32 +92,34 @@
ip="192.168.4.17"
# Allow any traffic to or from my own net.
- $fwcmd add pass all from ${ip} to ${net}:${mask}
- $fwcmd add pass all from ${net}:${mask} to ${ip}
+ $fwcmd add allow ip from ${ip} to ${net}:${mask}
+ $fwcmd add allow ip from ${net}:${mask} to ${ip}
# Allow TCP through if setup succeeded
- $fwcmd add pass tcp from any to any established
+ $fwcmd add allow tcp from any to any established
# Allow setup of incoming email
- $fwcmd add pass tcp from any to ${ip} 25 setup
+ $fwcmd add allow tcp from any to ${ip} 25 setup
# Allow setup of outgoing TCP connections only
- $fwcmd add pass tcp from ${ip} to any setup
+ $fwcmd add allow tcp from ${ip} to any setup
# Disallow setup of all other TCP connections
$fwcmd add deny tcp from any to any setup
# Allow DNS queries out in the world
- $fwcmd add pass udp from any 53 to ${ip}
- $fwcmd add pass udp from ${ip} to any 53
+ # (BIND 8.1.1 and later do not use port 53 by
+ # default, but it can be configured to do so.)
+ $fwcmd add allow udp from any 53 to ${ip}
+ $fwcmd add allow udp from ${ip} to any 53
# Allow NTP queries out in the world
- $fwcmd add pass udp from any 123 to ${ip}
- $fwcmd add pass udp from ${ip} to any 123
+ $fwcmd add allow udp from any 123 to ${ip}
+ $fwcmd add allow udp from ${ip} to any 123
# Everything else is denied as default.
-elif [ "${firewall_type}" = "simple" ]; then
+elif [ "${firewall_type}" = "SIMPLE" -o "${firewall_type}" = "simple" ]; then
############
# This is a prototype setup for a simple firewall. Configure this machine
@@ -130,42 +140,46 @@
iip="192.168.3.17"
# Stop spoofing
- $fwcmd add deny all from ${inet}:${imask} to any in via ${oif}
- $fwcmd add deny all from ${onet}:${omask} to any in via ${iif}
+ $fwcmd add deny ip from ${inet}:${imask} to any in via ${oif}
+ $fwcmd add deny ip from ${onet}:${omask} to any in via ${iif}
# Stop RFC1918 nets on the outside interface
- $fwcmd add deny all from 192.168.0.0:255.255.0.0 to any via ${oif}
- $fwcmd add deny all from 172.16.0.0:255.240.0.0 to any via ${oif}
- $fwcmd add deny all from 10.0.0.0:255.0.0.0 to any via ${oif}
+ $fwcmd add deny ip from 192.168.0.0:255.255.0.0 to any via ${oif}
+ $fwcmd add deny ip from 172.16.0.0:255.240.0.0 to any via ${oif}
+ $fwcmd add deny ip from 10.0.0.0:255.0.0.0 to any via ${oif}
# Allow TCP through if setup succeeded
- $fwcmd add pass tcp from any to any established
+ $fwcmd add allow tcp from any to any established
# Allow setup of incoming email
- $fwcmd add pass tcp from any to ${oip} 25 setup
+ $fwcmd add allow tcp from any to ${oip} 25 setup
# Allow access to our DNS
- $fwcmd add pass tcp from any to ${oip} 53 setup
+ # (BIND 8.1.1 and later do not use port 53 by
+ # default, but it can be configured to do so.)
+ $fwcmd add allow tcp from any to ${oip} 53 setup
# Allow access to our WWW
- $fwcmd add pass tcp from any to ${oip} 80 setup
+ $fwcmd add allow tcp from any to ${oip} 80 setup
# Reject&Log all setup of incoming connections from the outside
$fwcmd add deny log tcp from any to any in via ${oif} setup
# Allow setup of any other TCP connection
- $fwcmd add pass tcp from any to any setup
+ $fwcmd add allow tcp from any to any setup
# Allow DNS queries out in the world
- $fwcmd add pass udp from any 53 to ${oip}
- $fwcmd add pass udp from ${oip} to any 53
+ # (BIND 8.1.1 and later do not use port 53 by
+ # default, but it can be configured to do so.)
+ $fwcmd add allow udp from any 53 to ${oip}
+ $fwcmd add allow udp from ${oip} to any 53
# Allow NTP queries out in the world
- $fwcmd add pass udp from any 123 to ${oip}
- $fwcmd add pass udp from ${oip} to any 123
+ $fwcmd add allow udp from any 123 to ${oip}
+ $fwcmd add allow udp from ${oip} to any 123
# Everything else is denied as default.
-elif [ "${firewall_type}" != "NONE" -a -r "${firewall_type}" ]; then
+elif [ "${firewall_type}" != "UNKNOWN -a -r "${firewall_type}" ]; then
$fwcmd ${firewall_type}
fi
diff -ur ../etc-1014/rc.network ./rc.network
--- ../etc-1014/rc.network Thu Sep 18 15:47:12 1997
+++ ./rc.network Tue Oct 14 20:28:16 1997
@@ -55,34 +55,41 @@
ifconfig ${ifn}
done
- # Initialize IP filtering using ipfw
- echo ""
+ echo "Initializing IP filtering using ipfw."
+
/sbin/ipfw -q flush > /dev/null 2>&1
- if [ $? = 1 ] ; then
+ if [ $? != 0 ]; then
firewall_in_kernel=0
else
firewall_in_kernel=1
fi
- if [ $firewall_in_kernel = 0 -a "x$firewall_enable" = "xYES" ] ; then
- modload /lkm/ipfw_mod.o
- if [ $? = 0 ]; then
- firewall_in_kernel=1 # module loaded successfully
- echo "Kernel firewall module loaded."
- else
- echo "Warning: firewall kernel module failed to load."
+ if [ "x$firewall_enable" = "xYES" -o "x$firewall_enable" = "xyes" ]; then
+
+ if [ $firewall_in_kernel = 0 ]; then
+ /sbin/modload /lkm/ipfw_mod.o
+
+ if [ $? = 0 ]; then
+ firewall_in_kernel=1
+ echo "Kernel firewall module loaded successfully."
+ else
+echo "Warning: Firewall is enabled in /etc/rc.conf, but it is not compiled"
+echo "Warning: into the kernel, and the kernel module failed to load."
+ fi
fi
fi
- # Load the filters if required
+ # Load the filters if ipfw is in the kernel or loaded above.
+
if [ $firewall_in_kernel = 1 ]; then
- if [ -n "$firewall_enable" -a -f /etc/rc.firewall -a \
- "x$firewall_enable" = "xYES" ] ; then
- . /etc/rc.firewall
- echo "Firewall rules loaded."
+ if [ -r /etc/rc.firewall ]; then
+ . /etc/rc.firewall
+ echo "Firewall rules loaded from /etc/rc.firewall."
else
- echo "Warning: kernel has firewall functionality, but firewall rules are not enabled."
- echo " All ip services are disabled."
+echo "Warning: Firewall functionality is enabled, but firewall rules were"
+echo "Warning: not loaded from /etc/rc.firewall."
+echo ""
+echo "Warning: *** All IP services are disabled. ***"
fi
fi
>Audit-Trail:
>Unformatted:
===================END FORWARDED MESSAGE===================
*** Proud operator, designer and maintainer of the world's largest
*** Internet Relay Chat server. 4,168 clients and still growing. :-)
*** Try spider.dal.net on ports 6662-4 (Powered by FreeBSD)
From owner-freebsd-hackers Sun Oct 19 22:20:16 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id WAA28313
for hackers-outgoing; Sun, 19 Oct 1997 22:20:16 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from gate.mgt.msk.ru (mgtrep.24h.dialup.ru [194.87.18.139])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA28295;
Sun, 19 Oct 1997 22:20:11 -0700 (PDT)
(envelope-from tarkhil@mgt.msk.ru)
Received: from asteroid.mgt.msk.ru (asteroid.mgt.msk.ru [192.168.133.145])
by gate.mgt.msk.ru (8.8.6/8.8.6) with ESMTP id JAA15967;
Mon, 20 Oct 1997 09:20:05 +0400 (MSD)
Received: from asteroid.mgt.msk.ru (localhost.mgt.msk.ru [127.0.0.1])
by asteroid.mgt.msk.ru (8.8.7/8.8.6) with ESMTP id JAA24209;
Mon, 20 Oct 1997 09:19:22 +0400 (MSD)
Message-Id: <199710200519.JAA24209@asteroid.mgt.msk.ru>
To: hackers@freebsd.org, hardware@freebsd.org
Reply-To: tarkhil@mgt.msk.ru
Subject: on Worm detection
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 20 Oct 1997 09:19:21 +0400
From: "Alexander B. Povolotsky" <tarkhil@mgt.msk.ru>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Hello!
Since my 2.2-STABLE fails to detect Pinnacle Micro 4X4 CD-R as worm, and
2.2.2 or 2.2.1 did it, and I don't want to fetch it and install again, can't
one wise man describe me process of worm detection, so I'll try to make it
working?
Alex.
From owner-freebsd-hackers Sun Oct 19 23:26:49 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id XAA01703
for hackers-outgoing; Sun, 19 Oct 1997 23:26:49 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA01697
for <hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 23:26:45 -0700 (PDT)
(envelope-from sos@sos.freebsd.dk)
Received: (from sos@localhost) by sos.freebsd.dk (8.8.7/8.7.3) id IAA19215; Mon, 20 Oct 1997 08:26:30 +0200 (MEST)
Message-Id: <199710200626.IAA19215@sos.freebsd.dk>
Subject: Re: ATAPI CD-RW documentation...
In-Reply-To: <Pine.BSI.3.96.971019180502.25467A-100000@citrine.cyberstation.net> from Dan Walters at "Oct 19, 97 06:09:07 pm"
To: hannibal@cyberstation.net (Dan Walters)
Date: Mon, 20 Oct 1997 08:26:30 +0200 (MEST)
Cc: hackers@FreeBSD.ORG
From: Søren Schmidt <sos@FreeBSD.dk>
Reply-to: sos@FreeBSD.dk
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-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
In reply to Dan Walters who wrote:
> Never mind, it's amazing how you always find things right after you give
> up and ask. :) For anyone wondering, the motherload of specs can be
> found by ftp at fission.dt.wdc.com, including the working draft of the
> ATAPI Removable Rewritable Specification, SFF-8070. Wish their web pages
> would mention the site. :)
>
> So, has anyone already began work on this, or should I go ahead and give
> it a shot when my drive gets in?
No, there is nobody working at it so far, or at least not that I'm
aware of.
If you look carefully in the atapi.? files in sys/i386/isa you will
see that there is hooks for atapi disk & tapes, but its only stubs
the real driver are not written yet. You should hang of the CD-RW
in the same fashion I guess, giving us a wcdrw.c driver....
We should probably coordinate things a little, as I'm currently
adding changer support into the CDROM driver parts of our (E)IDE
subsystem...
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team
Even more code to hack -- will it ever end
..
From owner-freebsd-hackers Sun Oct 19 23:46:47 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id XAA02703
for hackers-outgoing; Sun, 19 Oct 1997 23:46:47 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from safeconcept.utimaco.co.at (mail-gw.utimaco.co.at [195.96.28.162])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA02694
for <hackers@FreeBSD.ORG>; Sun, 19 Oct 1997 23:46:26 -0700 (PDT)
(envelope-from Michael.Schuster@utimaco.co.at)
Received: (from uucp@localhost)
by safeconcept.utimaco.co.at (8.8.5/8.8.5) id IAA13517
for <hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 08:35:15 +0200 (CEST)
Received: from wshpux.utimaco.co.at(10.0.0.18) by safeconcept via smap (V2.0)
id xma013515; Mon, 20 Oct 97 08:35:13 +0200
Message-ID: <344AFDD1.52D4AF96@utimaco.co.at>
Date: Mon, 20 Oct 1997 08:44:33 +0200
From: Michael Schuster <Michael.Schuster@utimaco.co.at>
Organization: Utimaco Safe Concept GmbH., Linz, Austria
X-Mailer: Mozilla 4.02b7 [en] (X11; I; HP-UX B.10.01 9000/715)
MIME-Version: 1.0
To: "hackers@FreeBSD.ORG" <hackers@FreeBSD.ORG>
Subject: Re: outb() / inb()
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
0000-Administrator <root@trojanhorse.ml.org> wrote:
> outb (0x250, *c++); /* doesn't work whereas */
> outb (0x250, *c); c++; /* works */
>
> I would guess (but cannot verify) that
>
>
> *c++ = inb (0x250); /* probably works since the increment expression is
> * not part of the macro */
>
> can somebody verify this for me I am pretty sure about the inb (even
> though I can't test it easily), as for the outb since outb just is a macro
> that puts in an inline function outbv() why does it not work?
right: (copied by hand from /usr/include/machine/coufuncs.h):
>#define outb(port,data) \
> <....> \
> ? outbc(port,data):outbv(port,data))
which means that if you write
outb (0x250, *c++);
then the expression "*c++" gets evaluated twice, and only every other
byte is output to port 0x250.
Your solution is correct.
Michael
--
Michael Schuster
Utimaco Safe Concept GmbH. | Tel: +43 732 655755 41
Europaplatz 6 | Fax: +43 732 655755 5
A-4020 Linz Austria | email: Michael.Schuster@utimaco.co.at
From owner-freebsd-hackers Sun Oct 19 23:57:37 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id XAA03402
for hackers-outgoing; Sun, 19 Oct 1997 23:57:37 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from ren.dtir.qld.gov.au (firewall-user@ns.dtir.qld.gov.au [203.108.138.66])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA03395
for <freebsd-hackers@freebsd.org>; Sun, 19 Oct 1997 23:57:33 -0700 (PDT)
(envelope-from syssgm@dtir.qld.gov.au)
Received: by ren.dtir.qld.gov.au; id RAA21451; Mon, 20 Oct 1997 17:07:55 +1000 (EST)
Received: from ogre.dtir.qld.gov.au(167.123.8.3) by ren.dtir.qld.gov.au via smap (3.2)
id xma021446; Mon, 20 Oct 97 17:07:45 +1000
Received: from localhost.dtir.qld.gov.au (localhost.dtir.qld.gov.au [127.0.0.1])
by ogre.dtir.qld.gov.au (8.8.7/8.8.7) with SMTP id QAA18393;
Mon, 20 Oct 1997 16:56:52 +1000 (EST)
Message-Id: <199710200656.QAA18393@ogre.dtir.qld.gov.au>
X-Authentication-Warning: ogre.dtir.qld.gov.au: localhost.dtir.qld.gov.au [127.0.0.1] didn't use HELO protocol
To: Neil Ludban <n-ludban@onu.edu>
cc: freebsd-hackers@freebsd.org, syssgm@dtir.qld.gov.au
Subject: Re: NCR 53c875j support?
References: <Pine.A32.3.96.971019190349.32001A-100000@austin.onu.edu>
In-Reply-To: <Pine.A32.3.96.971019190349.32001A-100000@austin.onu.edu>
from Neil Ludban at "Mon, 20 Oct 1997 02:58:34 +0000"
Date: Mon, 20 Oct 1997 16:56:52 +1000
From: Stephen McKay <syssgm@dtir.qld.gov.au>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
On Monday, 20th October 1997, Neil Ludban wrote:
>I'm trying to get FreeBSD 2.2.2-RELEASE to recognize a Diamond FirePort40
>SCSI adapter, which uses the NCR 53c875j chip.
The 53c875j has a different ID than the 53c875. If you add that ID to the
appropriate switch statements in sys/pci/ncr.c, you'll be fine, assuming you
have some other way to do a 2.2.2 install. The latest code has these defines:
#define NCR_875_ID (0x000f1000ul)
#define NCR_875_ID2 (0x008f1000ul)
so you should be able to work this out from that.
Alternatively, an improved ncr driver (supporting the 875j and 875 at full
speed) is part of the very-soon-to-be-released 2.2.5. So, you could wait
a few days and install 2.2.5-release, or install a beta version right now.
>A possibly related problem is that having both SCSI cards installed at
>once, or the Asus with a PCI NIC (ed2, RealTek 8029) causes the boot to
>hang after the imasks line. The next thing should have been the BIOS
>disk geometries. FWIW, the geometry of the SCSI disk is correct for
>either controller.
I don't know what is happening here. Perhaps 2.2.5 will help here also.
Stephen.
From owner-freebsd-hackers Mon Oct 20 00:17:24 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id AAA04465
for hackers-outgoing; Mon, 20 Oct 1997 00:17:24 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from lab321.ru (anonymous1.omsk.net.ru [194.226.32.34])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA04458
for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 00:17:15 -0700 (PDT)
(envelope-from Eugeny.Kuzakov@lab321.ru)
Received: from lab321.ru (kev.l321.omsk.net.ru [194.226.33.68])
by lab321.ru (8.8.5-MVC-230497/8.8.5) with ESMTP id JAA25253;
Mon, 20 Oct 1997 09:41:17 +0600 (OSK)
Message-ID: <344AC4CD.362245D9@lab321.ru>
Date: Mon, 20 Oct 1997 09:41:17 +0700
From: Eugeny Kuzakov <Eugeny.Kuzakov@lab321.ru>
Organization: Powered by FreeBSD.
X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 3.0-971012-SNAP i386)
MIME-Version: 1.0
To: Douglas Carmichael <dcarmich@mcs.com>
CC: freebsd-hackers@FreeBSD.ORG
Subject: Re: Any X.25 support for FreeBSD?
References: <19971019210220.51925@dcarmich.pr.mcs.net>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Douglas Carmichael wrote:
> Is there any support coming for X.25 in FreeBSD, e.g. Eicon cards?
> (I'd love to hook up a BBS machine to Sprintnet/Tymnet)
I known about drivers for QZHS cards that support X.25.
Send mail to mailto://wolodn@novoch.ru
--
Best wishes, Eugeny Kuzakov
Laboratory 321 ( Omsk, Russia )
http://www.lab321.ru/~kev
kev@lab321.ru
From owner-freebsd-hackers Mon Oct 20 00:24:17 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id AAA04841
for hackers-outgoing; Mon, 20 Oct 1997 00:24:17 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA04836
for <freebsd-hackers@freebsd.org>; Mon, 20 Oct 1997 00:24:13 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA01452 for freebsd-hackers@freebsd.org; Mon, 20 Oct 1997 09:23:23 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id JAA05038;
Mon, 20 Oct 1997 09:22:56 +0200 (MET DST)
Message-ID: <19971020092256.EF31838@uriah.heep.sax.de>
Date: Mon, 20 Oct 1997 09:22:56 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: freebsd-hackers@freebsd.org (FreeBSD hackers)
Subject: Urge to apply the vn device hack even to 2.2.5
X-Mailer: Mutt 0.60_p2-3,5,8-9
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-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Here's a confirmation that Mr. KATO's hack for the lockmgr panic on
vn devices does also fix the problems on 2.2.5.
I would strongly recommend that we apply this hack, instead of
shipping 2.2.5 in the current state, where it's got a high probability
that our users can't successfully run a `make release' on it without
hitting a panic!
-----Forwarded message from tarkhil@mgt.msk.ru (Alexander B. Povolotsky)-----
Reply-To: tarkhil@mgt.msk.ru
Subject: Re: Repeated panic during work with vn
Date: Mon, 20 Oct 1997 09:10:41 +0400
From: "Alexander B. Povolotsky" <tarkhil@mgt.msk.ru>
> > I've tried the patch, but ... was it for -CURRENT or for -STABLE?
> > vn.c fails to compile.
>
> It was a CVS diff straight out of my -current system.
Ok, I've made it manually for -STABLE. Thanx, it helped!
Alex.
-----End of forwarded message-----
--
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 Oct 20 00:40:18 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id AAA05846
for hackers-outgoing; Mon, 20 Oct 1997 00:40:18 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA05831
for <hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 00:40:13 -0700 (PDT)
(envelope-from julian@whistle.com)
Received: (from daemon@localhost)
by alpo.whistle.com (8.8.5/8.8.5) id AAA23979;
Mon, 20 Oct 1997 00:34:26 -0700 (PDT)
Received: from current1.whistle.com(207.76.205.22)
via SMTP by alpo.whistle.com, id smtpd023977; Mon Oct 20 07:34:22 1997
Date: Mon, 20 Oct 1997 00:32:57 -0700 (PDT)
From: Julian Elischer <julian@whistle.com>
To: adrian@virginia.edu
cc: FreeBSD Hackers List <hackers@FreeBSD.ORG>
Subject: Re: Rhapsody is 4.4BSD based!?
In-Reply-To: <Pine.SUN.3.90.971016231053.22323D-100000@stretch.cs.Virginia.edu>
Message-ID: <Pine.BSF.3.95.971020003141.19680L-100000@current1.whistle.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
the NeXT OS was based on MACH with BSD 4.3++ parts
I would presme that they have continued to keep their code
up-to-date to at least some extent since then..
On Thu, 16 Oct 1997, Adrian T. Filipi-Martin wrote:
> Hi folks,
>
> Has anyone else seen this? Aparently Apples next generation OS
> is 4.4BSD based. Do I smell a new emmulation to support?
>
> You can get the basics from the following PCmag URL:
>
> http://www.zdnet.com/pcmag/news/trends/t971016a.htm
>
> I wonder which 4.4BSD they started with? It is reported to be
> multithreaded. I wonder if them mean kernel-multithreaded?
>
> Adrian
> --
> adrian@virginia.edu ---->>>>| If I were stranded on a desert island, and
> System Administrator --->>>| I could only have one OS for my computer,
> Neurosurgical Visualzation Lab -->>| it would be FreeBSD. Think about it.....
> http://www.nvl.virginia.edu/ ->| http://www.freebsd.org/
>
>
From owner-freebsd-hackers Mon Oct 20 05:13:22 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id FAA18171
for hackers-outgoing; Mon, 20 Oct 1997 05:13:22 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from seagull.cdrom.com (cracauer@seagull.cdrom.com [204.216.27.14])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA18165
for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 05:13:20 -0700 (PDT)
(envelope-from cracauer@seagull.cdrom.com)
Received: (from cracauer@localhost)
by seagull.cdrom.com (8.8.6/8.6.6) id FAA20236
; Mon, 20 Oct 1997 05:12:05 -0700 (PDT)
Message-ID: <19971020141203.20645@cons.org>
Date: Mon, 20 Oct 1997 14:12:03 +0200
From: Martin Cracauer <cracauer@cons.org>
To: Stefan Arentz <stefan.arentz@luna.net>
Cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: Linux Emulation - clone()
References: <19971018222208.49710@kalkoen.sateh.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.81
In-Reply-To: <19971018222208.49710@kalkoen.sateh.com>; from Stefan Arentz on Sat, Oct 18, 1997 at 10:22:08PM +0200
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
In <19971018222208.49710@kalkoen.sateh.com>, Stefan Arentz wrote:
> I'm trying to implement the linux clone() system call in 2.2.2.
Good news :-)
> It
> looks like this can be done with the FreeBSD rfork call except that
> Linux also allows you to set the user stack pointer for the new
> process.
>
> pid_t clone(void *sp, unsigned long flags)
>
> I'm still reading 'The design and implementation of the 4.4BSD
> operating system' to get a clue about where to setup the stack
> pointer, but it's still a big mystery to me ;)
The information in the book is outdated and doesn't apply to FreeBSD
anymore.
About a month ago, the semantics to FreeBSD's rfork system call has
been changed. The former behaviour left you with identical stacks in
parent and child. The new behaviour is to always copy the stack to a
new location, which is chosen by the system call. Check the mail
archives of -current from Sep, 18-20.
To emulate the Linux call, you can probably do it like this (I assume
the caller already allocated space for the stack):
- in the clone call, put the address of the user-supplied stack on the
stack.
- call rfork
- in the new child, do a return instruction from assembly, so that the
stack pointer now points to the user's location.
This should even work before and after the behaviour change I noted
above, since you don't use any rfork-supplied stack at all.
In a similar thread John Dyson noted that you might want to hold
signals until the new stack is in use in the child. See -hackers
archives from Sep, 16.
I hope this helps, but please note that I'm speaking from theory, never
tangled with this myself.
Aren't there some other problems, BTW? I know Linux planned to
implement clone flags so that process IDs are shared. This is needed
to be Posix threads compliant with plain fork/clone-based thread
packages.
And how are user's of clone() supposed to know how large the stack
region should be? If I'm not mistaken, the current FreeBSD rfork
implementation has grow-on-demand stacks as any usual process.
It seems to me this is an ugly performance hack to save the kernel
from allocating some space (but not from copying the contents, so it's
probably not worth the effort). comp.prorgramming.threads is full of
people claiming Linuxthreads can launch threads x-times faster than
any other system. Oh well...
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/
BSD User Group Hamburg/Germany http://www.bsdhh.org/
From owner-freebsd-hackers Mon Oct 20 06:38:32 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id GAA22584
for hackers-outgoing; Mon, 20 Oct 1997 06:38:32 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA22577
for <freebsd-hackers@freebsd.org>; Mon, 20 Oct 1997 06:38:28 -0700 (PDT)
(envelope-from guhl@mail90.mitre.org)
Received: from FUZZY (fuzzy.mitre.org [129.83.20.83])
by mbunix.mitre.org (8.8.6/8.8.6/mitre.0) with SMTP id JAA03813;
Mon, 20 Oct 1997 09:38:19 -0400 (EDT)
Date: Mon, 20 Oct 1997 09:38:19 -0400 (EDT)
Received: from m15081-mac.mitre.org (128.29.114.90) by fuzzy.mitre.org with SMTP id 8228; Mon, 20 Oct 1997 09:38:17 EST
X-Sender: guhl@mail90.mitre.org
Message-Id: <v03102802b070d61dba66@[128.29.114.90]>
In-Reply-To: <19971019210220.51925@dcarmich.pr.mcs.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: dcarmich@mcs.com (Douglas Carmichael), freebsd-hackers@freebsd.org
From: guhl@mitre.org (George Uhl)
Subject: OSI and X.25 support in FreeBSD
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
MITRE's ACET Lab supports X.25 over hdlc using ADAX APC
cards in FreeBSD version 2.2.1. We also support OSI protocols
(clnp, tp4 and cltp) in our 2.2.1 kernel. E-mail guhl@mitre.org
if you are interested in more information.
>Is there any support coming for X.25 in FreeBSD, e.g. Eicon cards?
>(I'd love to hook up a BBS machine to Sprintnet/Tymnet)
George Uhl
email: <guhl@mitre.org>
phone: 703-883-7305
The MITRE Corporation
Center for Advanced Aviation Systems Development
1820 Dolley Madison Blvd.
McLean, VA. 22102
From owner-freebsd-hackers Mon Oct 20 07:49:01 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id HAA26794
for hackers-outgoing; Mon, 20 Oct 1997 07:49:01 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA26653
for <hackers@freebsd.org>; Mon, 20 Oct 1997 07:45:12 -0700 (PDT)
(envelope-from gram@cdsec.com)
Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id QAA16483 for <hackers@freebsd.org>; Mon, 20 Oct 1997 16:54:54 +0200 (SAT)
Received: by citadel via recvmail id 16450; Mon Oct 20 16:54:04 1997
by gram.cdsec.com (8.8.5/8.8.5) id QAA11500
for hackers@freebsd.org; Mon, 20 Oct 1997 16:22:11 +0200 (SAT)
From: Graham Wheeler <gram@cdsec.com>
Message-Id: <199710201422.QAA11500@cdsec.com>
Subject: Bug in 2.2.2
To: hackers@freebsd.org
Date: Mon, 20 Oct 1997 16:22:10 +0200 (SAT)
X-Mailer: ELM [version 2.4 PL25-h4.1]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Hi all
This is just a brief follow up to the discussion that took place last month
about the possible bug in PHKmalloc. There are two points worth mentioning:
* the problem has not reoccurred with the firewall gateway program since
linking with the alternative libmalloc.
* the problem has been noted with other programs, including the firewall's
authentication daemon (which I have since linked with libmalloc).
More significantly, the problem has also occurred with the Midnight
Commander, and with `ps'.
[For those who missed the earlier discussion, the problem was corruption
of the heap, which resulted in a circularly linked list of memory blocks
in the internal heap data structures. At some point, a call to malloc/free
then never returns but keeps the process in a running state, chewing up
CPU cycles, and the process needs to be killed].
For the ps and mc cases, I could not verify that the code pointer was indeed
in the malloc library at the time, but the symptoms displayed were exactly
the same as with the earlier gateway problem, which was always in the
malloc library.
So it seems there is indeed a bug, either in phkmalloc or in some
other FreeBSD library code which uses phkmalloc.
I apologise for not being able to provide more detail than this.
--
Dr Graham Wheeler E-mail: gram@cdsec.com
Citadel Data Security Phone: +27(21)23-6065/6/7
Internet/Intranet Network Specialists Mobile: +27(83)-253-9864
Firewalls/Virtual Private Networks Fax: +27(21)24-3656
Data Security Products WWW: http://www.cdsec.com/
From owner-freebsd-hackers Mon Oct 20 08:18:23 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id IAA28252
for hackers-outgoing; Mon, 20 Oct 1997 08:18:23 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA28241;
Mon, 20 Oct 1997 08:18:15 -0700 (PDT)
(envelope-from rhh@ct.picker.com)
Received: from ct.picker.com by whqvax.picker.com with SMTP;
Mon, 20 Oct 1997 11:17:39 -0400 (EDT)
Received: from elmer.ct.picker.com by ct.picker.com (4.1/SMI-4.1)
id AA16535; Mon, 20 Oct 97 11:17:36 EDT
Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4)
id LAA20524; Mon, 20 Oct 1997 11:13:17 -0400
Message-Id: <19971020111316.33689@ct.picker.com>
Date: Mon, 20 Oct 1997 11:13:16 -0400
From: Randall Hopper <rhh@ct.picker.com>
To: Kristian Kennaway <kkennawa@physics.adelaide.edu.au>,
"Jonathan M. Bresler" <jmb@FreeBSD.ORG>
Cc: hackers@FreeBSD.ORG
Subject: Re: pulling email addresses from freebsd lists
References: <Pine.BSF.3.91.971016204728.21896A-100000@www2.shoppersnet.com> <9710170446.AA20901@compton>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.81
In-Reply-To: <9710170446.AA20901@compton>; from Kristian Kennaway on Fri, Oct 17, 1997 at 02:16:47PM +0930
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Kristian Kennaway:
|I'd just like to note that today I received my first ever spam-mail,
|after posting to this list for the first time a few days ago. Until now
|I've been successfully "hiding" by not having my email address make it
|out onto UseNet or anywhere else grepped by spammers.
Jonathan M. Bresler:
| we seem to be seeing a new tactic,
| evil spammer subscribes and harvests addresses from the
| list traffic.
I'd hazard a guess that the spammers aren't harvesting from the list e-mail
distribution directly but from NetNews (because of those numerous
list-to-NetNews gateways that some folks in the world funnel the FreeBSD
list traffic into). These pseudo-groups get out and into spam farmer
newsrc's without any real action on their part. Easy pickins'.
If I didn't choose to post to NetNews with my real e-mail address anyway,
I'd complain about these news gateways. As is, I just grin and have some
fun bustin' spammers with their ISPs. And procmail bounce rules to
postmaster,abuse,root for those ISPs that don't seem to care.
Randall
From owner-freebsd-hackers Mon Oct 20 08:37:54 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id IAA29464
for hackers-outgoing; Mon, 20 Oct 1997 08:37:54 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from elvis.vnet.net (elvis.vnet.net [166.82.1.5])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA29449
for <freebsd-hackers@freefall.FreeBSD.org>; Mon, 20 Oct 1997 08:37:45 -0700 (PDT)
(envelope-from rivers@dignus.com)
Received: from ponds.dignus.com (ponds.vnet.net [166.82.177.48])
by elvis.vnet.net (8.8.5/8.8.4) with ESMTP
id LAA12648; Mon, 20 Oct 1997 11:33:03 -0400 (EDT)
Received: from lakes.dignus.com (lakes [10.0.0.3])
by ponds.dignus.com (8.8.5/8.8.5) with ESMTP id LAA00287;
Mon, 20 Oct 1997 11:09:11 -0400 (EDT)
Received: (from rivers@localhost) by lakes.dignus.com (8.8.5/8.6.9) id KAA19512; Mon, 20 Oct 1997 10:59:36 -0400 (EDT)
Date: Mon, 20 Oct 1997 10:59:36 -0400 (EDT)
From: Thomas David Rivers <rivers@dignus.com>
Message-Id: <199710201459.KAA19512@lakes.dignus.com>
To: brian@awfulhak.org, rivers@dignus.com
Subject: Re: two natd's running?
Cc: freebsd-hackers@freefall.FreeBSD.org
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
All of this is included for context (since this is a rather
slow-running thread....)
> >
> > This is a rather old question I'm just now getting around to...
> >
> > What I have is a situation where I'd like to two SL/IP connections
> > going with multiple natd's running.
> >
> > Several people had suggested simply having two divert rules in
> > rc.firewall and running the two natd's that way.
> >
> > Here's what I've got the gateway (a 2.2-970510-RELENG machine) at
> > 10.0.0.1:
> >
> > ipfw -f flush
> > ipfw -f add 10 divert 32001 ip from any to 192.42.243.0/24 via sl1
>
> You can't masquerade in just one direction.... add
>
> ipfw -f add 10 divert 32001 ip from 192.42.243.0/24 to any via sl1
>
> > ipfw -f add 20 divert 32000 ip from any to any via sl0
> > ipfw -f add pass ip from any to any
> [.....]
> > - Thanks -
> > - Dave Rivers -
> >
>
> --
> Brian <brian@Awfulhak.org>, <brian@FreeBSD.org>, <bri@OpenBSD.org>
> <http://www.Awfulhak.org>
I followed Brian's suggestion and now have:
ipfw -f add 10 divert 32001 ip from any to 192.42.243.0/24 via sl1
ipfw -f add 15 divert 32001 ip from 192.42.243.0/24 to any via sl1
ipfw -f add 20 divert 32000 ip from any to any via sl0
ipfw -f add pass ip from any to any
as my firewall configuration....
and - I'm running two natd's:
/usr/local/bin/natd -l -port 32000 -interface sl0 -m -u -dynamic
/usr/local/bin/natd -l -port 32001 -interface sl1 -m -u -dynamic
This appears to be an improvement; as the gateway machine correctly
forwards traffic to 192.42.243.0/24 via sl1 (and natd it doing the
proper translation.)
However; something isn't working in the route tables...
On the gateway machine I have:
# netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
10/24 link#1 UC 0 0
10.0.0.3 0:40:33:22:a2:6b UHLW 6 1206 ed0 591
10.23.1.112 192.42.243.1 UGHS 0 0 sl1
10.23.1.115 192.42.243.1 UGHS 0 0 sl1
10.26.1.153 192.42.243.1 UGHS 0 0 sl1
10.26.1.157 192.42.243.1 UGHS 0 0 sl1
10.26.149.40 192.42.243.1 UGHS 0 0 sl1
10.252.1.2 192.42.243.1 UGHS 0 0 sl1
10.253.1.2 192.42.243.1 UGHS 0 0 sl1
127.0.0.1 127.0.0.1 UH 0 0 lo0
130.96.1.21 192.42.243.1 UGHS 0 0 sl1
149.173.52.101 192.42.243.1 UGHS 0 0 sl1
149.173.52.209 192.42.243.1 UGHS 0 0 sl1
149.173.160.12 192.42.243.1 UGHS 0 132 sl1
149.173.166.232 192.42.243.1 UGHS 0 0 sl1
172.16.0.200 192.42.243.1 UGHS 0 0 sl1
192.42.243.1 192.42.243.10 UH 16 12 sl1
192.42.243.10 192.42.243.1 UGHS 0 22 sl1
and, on an interior node, I can ping 192.42.243.10 and 192.42.243.1;
but I can't get to any of the other addresses... (e.g. 130.96.1.21 doesn't
go out via sl1 as I would like it to...)
I'm guessing I have to add more rules for each of the networks I'd like
to go out to there - but I was hoping the routing table would take care
of that... should it?
- Dave Rivers -
From owner-freebsd-hackers Mon Oct 20 09:16:05 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id JAA02306
for hackers-outgoing; Mon, 20 Oct 1997 09:16:05 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA02233
for <freebsd-hackers@freebsd.org>; Mon, 20 Oct 1997 09:15:55 -0700 (PDT)
(envelope-from nate@rocky.mt.sri.com)
Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100])
by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id KAA14139;
Mon, 20 Oct 1997 10:15:45 -0600 (MDT)
Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id KAA29216; Mon, 20 Oct 1997 10:15:44 -0600 (MDT)
Date: Mon, 20 Oct 1997 10:15:44 -0600 (MDT)
Message-Id: <199710201615.KAA29216@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: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Cc: freebsd-hackers@freebsd.org (FreeBSD hackers)
Subject: Re: Urge to apply the vn device hack even to 2.2.5
In-Reply-To: <19971020092256.EF31838@uriah.heep.sax.de>
References: <19971020092256.EF31838@uriah.heep.sax.de>
X-Mailer: VM 6.29 under 19.15 XEmacs Lucid
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> Here's a confirmation that Mr. KATO's hack for the lockmgr panic on
> vn devices does also fix the problems on 2.2.5.
>
> I would strongly recommend that we apply this hack, instead of
> shipping 2.2.5 in the current state, where it's got a high probability
> that our users can't successfully run a `make release' on it without
> hitting a panic!
My advice is to 'just do it'. I suspect Jordan must have the patch on
his build box in order for him to roll the release, and since there are
few hours left to do it in, it should be done ASAP.
With no 'official' FreeBSD-RE experience, I'd be afraid to get yelled at
as not understanding all the issues, so I don't dare. :) :)
Nate
From owner-freebsd-hackers Mon Oct 20 09:16:45 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id JAA02391
for hackers-outgoing; Mon, 20 Oct 1997 09:16:45 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from wafu.netgate.net (wafu.netgate.net [204.145.147.80])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA02377
for <hackers@freebsd.org>; Mon, 20 Oct 1997 09:16:35 -0700 (PDT)
(envelope-from shigio@wafu.netgate.net)
Received: from chiota.signet.or.jp (INS49.tama.dti.ne.jp [210.159.144.3]) by wafu.netgate.net (8.7.5/8.7.3) with ESMTP id IAA21452; Mon, 20 Oct 1997 08:17:18 GMT
Message-Id: <199710200817.IAA21452@wafu.netgate.net>
Received: from chiota.signet.or.jp (localhost.signet.or.jp [127.0.0.1]) by chiota.signet.or.jp (8.8.5/) with ESMTP id BAA09363; Tue, 21 Oct 1997 01:15:35 +0900 (JST)
To: hackers@freebsd.org
Cc: shigio@wafu.netgate.net
Subject: Re: Kernel Index
Date: Tue, 21 Oct 1997 01:15:34 +0900
From: Shigio Yamaguchi <shigio@wafu.netgate.net>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
On Oct 9, 1997 23:10:19 -0500, Jonathan wrote:
>On Oct 10, 1997 at 08:01:25PM -0700, mdean wrote:
>>
>> Does anyone have an index of all structs and functions they could send me?
>> make GTAGS bombed out on stable for me.
>> I'd really like to be able to reference the kernel source quickly.
>
>Did you run it on the entire src/ tree, or just the src/sys kernel subtree?
>I can generate a GTAGS file for the kernel subtree, albeit not for the
>entire distribution.
I have fixed this bug.
Sorry for my late reply.
By the way, If you are going to execute gtags(1) at '/usr/src', please confirm
the room of your disk. Tag files become very large.
# cd /usr/src
# gtags
# ls -l G*S
-rw-r--r-- 1 root wheel 82370560 Oct 20 22:13 GRTAGS
-rw-r--r-- 1 root wheel 75882496 Oct 21 00:47 GSYMS
-rw-r--r-- 1 root wheel 9904128 Oct 20 20:44 GTAGS
#
GLOBAL-2.1 make new tag file GSYMS for symbols other than function.
If you are not interested in these symbols, you had better to
execute gtags like this.
% gtags -o
'-o' option means 'old', that is, make GTAGS and GRTAGS but doesn't make GSYMS.
--
Shigio Yamaguchi (Freelance programmer)
Mail: shigio@wafu.netgate.net, WWW: http://wafu.netgate.net/tama/
From owner-freebsd-hackers Mon Oct 20 09:27:21 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id JAA03198
for hackers-outgoing; Mon, 20 Oct 1997 09:27:21 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA03183;
Mon, 20 Oct 1997 09:27:06 -0700 (PDT)
(envelope-from gram@cdsec.com)
Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id SAA19702; Mon, 20 Oct 1997 18:36:55 +0200 (SAT)
Received: by citadel via recvmail id 19669; Mon Oct 20 18:36:37 1997
by gram.cdsec.com (8.8.5/8.8.5) id SAA11653;
Mon, 20 Oct 1997 18:04:36 +0200 (SAT)
From: Graham Wheeler <gram@cdsec.com>
Message-Id: <199710201604.SAA11653@cdsec.com>
Subject: Re: Bug in 2.2.2
To: jmb@FreeBSD.ORG (Jonathan M. Bresler)
Date: Mon, 20 Oct 1997 18:04:35 +0200 (SAT)
Cc: hackers@FreeBSD.ORG
In-Reply-To: <199710201613.JAA02114@hub.freebsd.org> from "Jonathan M. Bresler" at Oct 20, 97 09:13:23 am
X-Mailer: ELM [version 2.4 PL25-h4.1]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Hi Jon
> can you tell me how to reproduce it within X hours?
> if i remember correctly, it was failing every X hours
> for you. if its statically linked i can hack on
> the shared library and see if i can track this down.
>
The original problem with the gateway usually occurred within less than an
hour, but it certainly wasn't a fixed interval. The Midnight Commander
instance happened after the mc had been running for quite some time (possibly
since the previous week).
The mc and ps instances were noticed at the same time. I now speculate that
the problem was within mc, not ps - the ps was probably run from the mc
command line, and inherited a corrupt heap from the parent process.
I can't provide much more detail than this - the sites where it happened
are in different cities, and I am mostly just summarising what was reported
to me by the administrators of the various firewalls, and, when I can get
them to do it, from looking at core dumps generated with SIGABRT.
I will write a small program to exercise the heap, and see if I
can replicate the problem at all.
--
Dr Graham Wheeler E-mail: gram@cdsec.com
Citadel Data Security Phone: +27(21)23-6065/6/7
Internet/Intranet Network Specialists Mobile: +27(83)-253-9864
Firewalls/Virtual Private Networks Fax: +27(21)24-3656
Data Security Products WWW: http://www.cdsec.com/
From owner-freebsd-hackers Mon Oct 20 09:48:56 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id JAA04356
for hackers-outgoing; Mon, 20 Oct 1997 09:48:56 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from intercore.com (num1sun.intercore.com [199.181.243.1])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA04351
for <hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 09:48:53 -0700 (PDT)
(envelope-from robin@intercore.com)
Received: (robin@localhost) by intercore.com (8.7.1/8.6.4) id MAA26282; Mon, 20 Oct 1997 12:45:47 -0400 (EDT)
Message-ID: <19971020124546.62622@num1sun.intercore.com>
Date: Mon, 20 Oct 1997 12:45:46 -0400
From: Robin Cutshaw <robin@intercore.com>
To: "Matthew D. Fuller" <fullermd@futuresouth.com>
Cc: Robin Cutshaw <robin@intercore.com>,
Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>, hackers@FreeBSD.ORG
Subject: Re: fsck problem with 2.2.5-971015-BETA
References: <19971019212958.33788@num1sun.intercore.com> <Pine.BSF.3.96.971019220410.24477A-100000@shell.futuresouth.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.79
In-Reply-To: <Pine.BSF.3.96.971019220410.24477A-100000@shell.futuresouth.com>; from Matthew D. Fuller on Sun, Oct 19, 1997 at 10:04:50PM -0500
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Sun, Oct 19, 1997 at 10:04:50PM -0500, Matthew D. Fuller wrote:
> >
> > Why does the fsck work correctly once the system is up in multi-user
> > mode?
> Because in multi-user, it has access to swap. If your turn swapon in
> single-user, I'll bet the fsck will work.
>
Swap is added just before the fsck (as is evidenced by the swapon
message appearing first and pstat -s showing it's there).
robin
--
----
Robin Cutshaw internet: robin@interlabs.com robin@intercore.com
Internet Labs, Inc. BellNet: 404-817-9787 robin@XFree86.Org
"Time is just one damn thing after another" -- PBS/Nova
----
--
From owner-freebsd-hackers Mon Oct 20 10:13:28 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA06068
for hackers-outgoing; Mon, 20 Oct 1997 10:13:28 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from nagual.pp.ru (ache.relcom.ru [194.58.229.133])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA06037
for <hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 10:12:35 -0700 (PDT)
(envelope-from ache@nagual.pp.ru)
Received: (from ache@localhost)
by nagual.pp.ru (8.8.7/8.8.7) id UAA01642;
Mon, 20 Oct 1997 20:55:11 +0400 (MSD)
(envelope-from ache)
Date: Mon, 20 Oct 1997 20:55:09 +0400 (MSD)
From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru>
To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
cc: FreeBSD-Hackers List <hackers@FreeBSD.ORG>,
Robin Cutshaw <robin@intercore.com>, Alexey Bulushev <bag@demos.su>,
Mishania Sokolov <mishania@demos.su>
Subject: Re: fsck problem with 2.2.5-971015-BETA
In-Reply-To: <19971019183550.SV35032@uriah.heep.sax.de>
Message-ID: <Pine.BSF.3.96.971020205424.1547D-100000@nagual.pp.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Sun, 19 Oct 1997, J Wunsch wrote:
> As Robin Cutshaw wrote:
>
> > "fsck -p" in /etc/rc fails when it gets to the 1st 9GB drive
> > with "cannot alloc 2088961 bytes for statemap".
>
> ISTR a comment that you need to increase the VM resource limits to
> fsck large filesystems.
We already have PR about this problem, sparse files involved somehow.
--
Andrey A. Chernov
<ache@nietzsche.net>
http://www.nagual.pp.ru/~ache/
From owner-freebsd-hackers Mon Oct 20 10:15:03 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA06193
for hackers-outgoing; Mon, 20 Oct 1997 10:15:03 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA05900
for <hackers@freebsd.org>; Mon, 20 Oct 1997 10:11:11 -0700 (PDT)
(envelope-from gram@cdsec.com)
Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id TAA21063 for <hackers@freebsd.org>; Mon, 20 Oct 1997 19:20:56 +0200 (SAT)
Received: by citadel via recvmail id 21028; Mon Oct 20 19:20:14 1997
by gram.cdsec.com (8.8.5/8.8.5) id SAA11704
for hackers@freebsd.org; Mon, 20 Oct 1997 18:48:13 +0200 (SAT)
From: Graham Wheeler <gram@cdsec.com>
Message-Id: <199710201648.SAA11704@cdsec.com>
Subject: Re: Bug in 2.2.2
To: hackers@freebsd.org
Date: Mon, 20 Oct 1997 18:48:12 +0200 (SAT)
X-Mailer: ELM [version 2.4 PL25-h4.1]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
>
> can you tell me how to reproduce it within X hours?
> if i remember correctly, it was failing every X hours
> for you. if its statically linked i can hack on
> the shared library and see if i can track this down.
I wrote a small program to exercise the heap and ran it for about ten million
iterations without a problem. Then I decided to add a periodic call to fork(),
as both Midnight Commander and the firewall gateway program both do plenty
of these. When I ran this the O/S panicked almost immediately.
Here is the program:
// A simple program to exercise the heap.
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <time.h>
main()
{
const int vsize = 10000;
char **vector = new char*[vsize];
int i, allocs = 0, deletes = 0;
int seed = time(0);
srand(seed);
for (i = 0; i < vsize; i++) vector[i] = 0;
i = 0;
for (;;)
{
if ((i%100000) == 0)
printf("%d: alloc %d delete %d seed %d\n",
i, allocs, deletes, seed);
if ((i % 100) == 0)
{
int pid = fork();
if (pid == 0) exit(0);
}
int slot = random() % vsize;
if (vector[slot])
{
delete [] vector[slot];
vector[slot] = 0;
deletes++;
}
else
{
int l = (random() % 4096)+1;
vector[slot] = new char[l];
memset(vector[slot], l, l);
allocs++;
}
if (++i < 0) i = 0;
}
}
I hadn't bothered doing any signal catching here; this was quick 'n dirty.
Still, it shouldn't cause a panic. Perhaps there is a connection between
this and the other problem?
> > So it seems there is indeed a bug, either in phkmalloc or in some
> > other FreeBSD library code which uses phkmalloc.
I strongly suspect the latter may be the case, and that the nature of
the bug is such that it affects phkmalloc but not the other malloc.
cheers
gram
--
Dr Graham Wheeler E-mail: gram@cdsec.com
Citadel Data Security Phone: +27(21)23-6065/6/7
Internet/Intranet Network Specialists Mobile: +27(83)-253-9864
Firewalls/Virtual Private Networks Fax: +27(21)24-3656
Data Security Products WWW: http://www.cdsec.com/
From owner-freebsd-hackers Mon Oct 20 11:01:20 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA09626
for hackers-outgoing; Mon, 20 Oct 1997 11:01:20 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from ns1.yes.no (ns1.yes.no [195.119.24.10])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA09612
for <freebsd-hackers@freebsd.org>; Mon, 20 Oct 1997 11:01:12 -0700 (PDT)
(envelope-from eivind@bitbox.follo.net)
Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36])
by ns1.yes.no (8.8.7/8.8.7) with ESMTP id SAA16058
for <freebsd-hackers@freebsd.org>; Mon, 20 Oct 1997 18:00:45 GMT
Received: (from eivind@localhost)
by bitbox.follo.net (8.8.6/8.8.6) id UAA01441;
Mon, 20 Oct 1997 20:00:44 +0200 (MET DST)
Date: Mon, 20 Oct 1997 20:00:44 +0200 (MET DST)
Message-Id: <199710201800.UAA01441@bitbox.follo.net>
From: Eivind Eklund <perhaps@yes.no>
To: freebsd-hackers@freebsd.org
Subject: Kernel config for web hosts
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Have anybody got a well-tuned (kernel or sysctl) configuration for
web hosts? This might be an idea to include on the distribution CD
(which is why I'm posting this here); most people don't know how to
tune a kernel well enough.
The configs we use have a tendency to introduce 5s lags at random
points, for some inexplicable reason (different network-cards,
different Apache-versions, different motherboards, different nets -
the only common feature seems to be FreeBSD 2.2.2 with some apache
version)
Eivind.
From owner-freebsd-hackers Mon Oct 20 11:24:51 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA11047
for hackers-outgoing; Mon, 20 Oct 1997 11:24:51 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA11039
for <hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 11:24:37 -0700 (PDT)
(envelope-from tlambert@usr05.primenet.com)
Received: (from daemon@localhost)
by smtp03.primenet.com (8.8.7/8.8.7) id LAA23047;
Mon, 20 Oct 1997 11:23:29 -0700 (MST)
Received: from usr05.primenet.com(206.165.6.205)
via SMTP by smtp03.primenet.com, id smtpd023030; Mon Oct 20 11:23:23 1997
Received: (from tlambert@localhost)
by usr05.primenet.com (8.8.5/8.8.5) id LAA09061;
Mon, 20 Oct 1997 11:23:20 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710201823.LAA09061@usr05.primenet.com>
Subject: Re: values for exit()
To: joerg_wunsch@uriah.heep.sax.de
Date: Mon, 20 Oct 1997 18:23:19 +0000 (GMT)
Cc: hackers@FreeBSD.ORG, jacques@wired.ctech.ac.za
In-Reply-To: <19971018085300.UT45874@uriah.heep.sax.de> from "J Wunsch" at Oct 18, 97 08:53:00 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > > > > Where can I find the exit values for
> > > > > exit()? Meaning, what is the difference
> > > > > between eg exit(1) and exit(2)?
> >
> > errno.h
>
> Only in TerryBSD. In FreeBSD, stick with sysexits(3).
Too bad you didn't quote the rest of my message.
The other OS's whose shells output messages for the program exit
values for non-script driven program starts are:
UnixWare 1.x
UnixWare 2.x
Solaris 2.x
SCO Version 5
Of course, Jorg could be right, and everyone else could be wrong.
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 Oct 20 11:35:00 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA11647
for hackers-outgoing; Mon, 20 Oct 1997 11:35:00 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA11632
for <hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 11:34:51 -0700 (PDT)
(envelope-from tlambert@usr05.primenet.com)
Received: (from daemon@localhost)
by smtp04.primenet.com (8.8.7/8.8.7) id LAA16051;
Mon, 20 Oct 1997 11:34:43 -0700 (MST)
Received: from usr05.primenet.com(206.165.6.205)
via SMTP by smtp04.primenet.com, id smtpd016047; Mon Oct 20 11:34:40 1997
Received: (from tlambert@localhost)
by usr05.primenet.com (8.8.5/8.8.5) id LAA09783;
Mon, 20 Oct 1997 11:34:31 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710201834.LAA09783@usr05.primenet.com>
Subject: Re: Freebsd 3.0 current fails ipfilter 3.2b8 build (fwd)
To: darrenr@cyber.com.au (Darren Reed)
Date: Mon, 20 Oct 1997 18:34:31 +0000 (GMT)
Cc: tlambert@primenet.com, julian@whistle.com, hackers@FreeBSD.ORG
In-Reply-To: <199710190545.PAA19458@plum.cyber.com.au> from "Darren Reed" at Oct 19, 97 03:45:30 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > If the code isn't portable to Linux, SVR4, and Solaris without
> > compile time switches, why write it?
>
> Well, prior to these changes to FreeBSD, it was portable between
> *BSD/SunOS4/Solaris2 without any compile time switches - not sure
> about Linux. Why ? Because up until recently, all would give
> you "struct ifnet" if you included net/if.h.
>
> So there you have it.
>
> This makes it harder to port code to FreeBSD.
>
> Or, from the other angle, FreeBSD code is less portable.
>
> Isn't that just wonderful ? *spew*
It seems your complaint is that the use of the struct ifnet in
the internal structures is not bracketed by:
#ifdef __IF_VAR_H__
#endif
If you are using structures that contain this opaque data object,
then you are doing something wrong.
This is not to say that I'm happy with the code (I'm not), but
that this type of interface seperation is both (1) necessary, and
(2) desirable, from a "pure environment" perspective.
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 Oct 20 11:43:43 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA12151
for hackers-outgoing; Mon, 20 Oct 1997 11:43:43 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from time.cdrom.com (time.cdrom.com [204.216.27.226])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA12139
for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 11:43:34 -0700 (PDT)
(envelope-from jkh@time.cdrom.com)
Received: from time.cdrom.com (localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id LAA13795; Mon, 20 Oct 1997 11:41:34 -0700 (PDT)
To: Nate Williams <nate@mt.sri.com>
cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch),
freebsd-hackers@FreeBSD.ORG (FreeBSD hackers)
Subject: Re: Urge to apply the vn device hack even to 2.2.5
In-reply-to: Your message of "Mon, 20 Oct 1997 10:15:44 MDT."
<199710201615.KAA29216@rocky.mt.sri.com>
Date: Mon, 20 Oct 1997 11:41:33 -0700
Message-ID: <13791.877372893@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> My advice is to 'just do it'. I suspect Jordan must have the patch on
> his build box in order for him to roll the release, and since there are
> few hours left to do it in, it should be done ASAP.
I don't, that's the weird thing. I'm running a standard 2.2-stable
kernel here. Maybe it only hits in situations where you have a
certain amount of RAM?
In any case, the tag is going down in just over 6 hours, so a decision
will need to be made quickly. :)
Jordan
From owner-freebsd-hackers Mon Oct 20 12:48:28 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id MAA15180
for hackers-outgoing; Mon, 20 Oct 1997 12:48:28 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA15173
for <freebsd-hackers@freebsd.org>; Mon, 20 Oct 1997 12:48:25 -0700 (PDT)
(envelope-from nate@rocky.mt.sri.com)
Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100])
by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id NAA15483;
Mon, 20 Oct 1997 13:48:13 -0600 (MDT)
Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA00007; Mon, 20 Oct 1997 13:48:13 -0600 (MDT)
Date: Mon, 20 Oct 1997 13:48:13 -0600 (MDT)
Message-Id: <199710201948.NAA00007@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: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Cc: Nate Williams <nate@mt.sri.com>,
joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch),
freebsd-hackers@freebsd.org (FreeBSD hackers)
Subject: Re: Urge to apply the vn device hack even to 2.2.5
In-Reply-To: <13791.877372893@time.cdrom.com>
References: <199710201615.KAA29216@rocky.mt.sri.com>
<13791.877372893@time.cdrom.com>
X-Mailer: VM 6.29 under 19.15 XEmacs Lucid
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> > My advice is to 'just do it'. I suspect Jordan must have the patch on
> > his build box in order for him to roll the release, and since there are
> > few hours left to do it in, it should be done ASAP.
>
> I don't, that's the weird thing. I'm running a standard 2.2-stable
> kernel here. Maybe it only hits in situations where you have a
> certain amount of RAM?
Hmm, I don't know. It's been seen by lots of folks though.
> In any case, the tag is going down in just over 6 hours, so a decision
> will need to be made quickly. :)
I decided to take the heat for it. I haven't been in a good flame wars
in awhile. It won't break the compile in any case, and I know enough
people who build 'private' releases that breaking it seems silly.
Nate
ps. It *shouldn't* break your build, but if it does yell at me and yank
it out.
From owner-freebsd-hackers Mon Oct 20 12:54:04 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id MAA15508
for hackers-outgoing; Mon, 20 Oct 1997 12:54:04 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA15497;
Mon, 20 Oct 1997 12:53:56 -0700 (PDT)
(envelope-from jamil@trojanhorse.ml.org)
Received: from localhost (jamil@localhost)
by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id MAA28921;
Mon, 20 Oct 1997 12:53:15 -0700 (PDT)
Date: Mon, 20 Oct 1997 12:53:15 -0700 (PDT)
From: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
To: Randall Hopper <rhh@ct.picker.com>
cc: Kristian Kennaway <kkennawa@physics.adelaide.edu.au>,
"Jonathan M. Bresler" <jmb@FreeBSD.ORG>, hackers@FreeBSD.ORG
Subject: Re: pulling email addresses from freebsd lists
In-Reply-To: <19971020111316.33689@ct.picker.com>
Message-ID: <Pine.BSF.3.96.971020124951.28888B-100000@trojanhorse.ml.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
One thing that might help is possibly assigning handles to email addresses
on freebsd.org like
189291@freebsd.org = jamil@trojanhorse.ml.org
and only allowing mail from other handles on that list
to be redirected through freebsd.org to the mailer
It would be much less likely for a spammer to attack because they would
half to attack from a subscribed account.
Or something like this...
On Mon, 20 Oct 1997, Randall Hopper wrote:
> Kristian Kennaway:
> |I'd just like to note that today I received my first ever spam-mail,
> |after posting to this list for the first time a few days ago. Until now
> |I've been successfully "hiding" by not having my email address make it
> |out onto UseNet or anywhere else grepped by spammers.
>
> Jonathan M. Bresler:
> | we seem to be seeing a new tactic,
> | evil spammer subscribes and harvests addresses from the
> | list traffic.
>
>
> I'd hazard a guess that the spammers aren't harvesting from the list e-mail
> distribution directly but from NetNews (because of those numerous
> list-to-NetNews gateways that some folks in the world funnel the FreeBSD
> list traffic into). These pseudo-groups get out and into spam farmer
> newsrc's without any real action on their part. Easy pickins'.
>
> If I didn't choose to post to NetNews with my real e-mail address anyway,
> I'd complain about these news gateways. As is, I just grin and have some
> fun bustin' spammers with their ISPs. And procmail bounce rules to
> postmaster,abuse,root for those ISPs that don't seem to care.
>
> Randall
>
>
From owner-freebsd-hackers Mon Oct 20 13:08:12 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id NAA16502
for hackers-outgoing; Mon, 20 Oct 1997 13:08:12 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from news.IAEhv.nl (root@news.IAEhv.nl [194.151.64.4])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA16454
for <hackers@freebsd.org>; Mon, 20 Oct 1997 13:07:51 -0700 (PDT)
(envelope-from devet@adv.IAEhv.nl)
Received: from LOCAL (uucp@localhost)
by news.IAEhv.nl (8.6.13/1.63) with IAEhv.nl; pid 23145
on Mon, 20 Oct 1997 20:07:29 GMT; id UAA23145
efrom: devet@adv.IAEhv.nl; eto: hackers@freebsd.org
Received: (from devet@localhost)
by adv.IAEhv.nl (8.8.5/8.8.6) id WAA06920;
Mon, 20 Oct 1997 22:03:28 +0200 (CEST)
Date: Mon, 20 Oct 1997 22:03:28 +0200 (CEST)
From: Arjan de Vet <Arjan.deVet@adv.IAEhv.nl>
Message-Id: <199710202003.WAA06920@adv.IAEhv.nl>
To: hackers@freebsd.org
Subject: Re: Urge to apply the vn device hack even to 2.2.5
X-Newsgroups: list.freebsd.hackers
In-Reply-To: <13791.877372893@time.cdrom.com>
References: <199710201615.KAA29216@rocky.mt.sri.com>
Organization: Internet Access Eindhoven, the Netherlands
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
In article <13791.877372893@time.cdrom.com> you write:
>> My advice is to 'just do it'. I suspect Jordan must have the patch on
>> his build box in order for him to roll the release, and since there are
>> few hours left to do it in, it should be done ASAP.
>
>I don't, that's the weird thing. I'm running a standard 2.2-stable
>kernel here. Maybe it only hits in situations where you have a
>certain amount of RAM?
I've done a 'make release' for 2.2-stable at least 5 times last week and I
haven't seen the vn panics either (with 64MB of RAM). Only some ioctl
message, see below.
Arjan
[...]
Compressing doc files...
sh -e /usr/src/release/doFS.sh /R/stage /mnt 1440 /R/stage/mfsfd 8000 minimum
ioctl DIOCWLABEL: Operation not supported by device
Warning: Block size restricts cylinders per group to 8.
/dev/rvn0c: 2880 sectors in 1 cylinders of 1 tracks, 2880 sectors
1.4MB in 1 cyl groups (8 c/g, 11.25MB/g, 1312 i/g)
super-block backups (for fsck -b #) at:
32,
2287 blocks
Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on
/dev/vn0c 1247 1159 88 93% 190 1120 15% /mnt
/dev/rvn0c: clean, 176 free (8 frags, 21 blocks, 0.3% fragmentation)
>>> Filesystem is 1440 K, 88 left
>>> 8000 bytes/inode, 1120 left
>>> 184
mv fs-image fs-image.std
mv fs-image.size fs-image.std.size
[...]
kzip data end address will be: 0x39ff28
sh -e /usr/src/release/doFS.sh /R/stage /mnt 1440 /R/stage/boot.std 100000 fd1440
ioctl DIOCWLABEL: Operation not supported by device
Warning: Block size restricts cylinders per group to 9.
/dev/rvn0c: 2880 sectors in 1 cylinders of 1 tracks, 2880 sectors
1.4MB in 1 cyl groups (9 c/g, 12.66MB/g, 128 i/g)
super-block backups (for fsck -b #) at:
32,
2397 blocks
Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on
/dev/vn0c 1395 1206 189 86% 5 121 4% /mnt
/dev/rvn0c: clean, 379 free (11 frags, 46 blocks, 0.4% fragmentation)
mv fs-image /R/stage/floppies/bootstd.flp
mv /R/stage/floppies/bootstd.flp /R/stage/floppies/boot.flp
Regular boot floppy made.
touch release.8
From owner-freebsd-hackers Mon Oct 20 13:20:57 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id NAA17289
for hackers-outgoing; Mon, 20 Oct 1997 13:20:57 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: (from jmb@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id NAA17269;
Mon, 20 Oct 1997 13:20:37 -0700 (PDT)
(envelope-from jmb)
From: "Jonathan M. Bresler" <jmb>
Message-Id: <199710202020.NAA17269@hub.freebsd.org>
Subject: Re: pulling email addresses from freebsd lists
To: jamil@trojanhorse.ml.org (Jamil J. Weatherbee)
Date: Mon, 20 Oct 1997 13:20:37 -0700 (PDT)
Cc: rhh@ct.picker.com, kkennawa@physics.adelaide.edu.au, jmb@FreeBSD.ORG,
hackers@FreeBSD.ORG
In-Reply-To: <Pine.BSF.3.96.971020124951.28888B-100000@trojanhorse.ml.org> from "Jamil J. Weatherbee" at Oct 20, 97 12:53:15 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Jamil J. Weatherbee wrote:
>
>
>
> One thing that might help is possibly assigning handles to email addresses
> on freebsd.org like
>
> 189291@freebsd.org = jamil@trojanhorse.ml.org
>
> and only allowing mail from other handles on that list
> to be redirected through freebsd.org to the mailer
>
> It would be much less likely for a spammer to attack because they would
> half to attack from a subscribed account.
>
> Or something like this...
>
while this is correct, it defeatss on of the purposes of the
mailing lists...to provide quick answers to users questions.
and it does not prevent people from subscribing and spamming
the lists. sendmail.cf blocked 14 spam messages today.
jmb
From owner-freebsd-hackers Mon Oct 20 13:22:43 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id NAA17393
for hackers-outgoing; Mon, 20 Oct 1997 13:22:43 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA17388
for <freebsd-hackers@freebsd.org>; Mon, 20 Oct 1997 13:22:38 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA08668 for freebsd-hackers@freebsd.org; Mon, 20 Oct 1997 22:22:37 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id WAA06381;
Mon, 20 Oct 1997 22:18:16 +0200 (MET DST)
Message-ID: <19971020221816.FF50549@uriah.heep.sax.de>
Date: Mon, 20 Oct 1997 22:18:16 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: freebsd-hackers@freebsd.org (FreeBSD hackers)
Subject: Re: Urge to apply the vn device hack even to 2.2.5
References: <199710201615.KAA29216@rocky.mt.sri.com> <13791.877372893@time.cdrom.com> <199710201948.NAA00007@rocky.mt.sri.com>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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: <199710201948.NAA00007@rocky.mt.sri.com>; from Nate Williams on Oct 20, 1997 13:48:13 -0600
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
As Nate Williams wrote:
> I decided to take the heat for it. I haven't been in a good flame wars
> in awhile. It won't break the compile in any case, and I know enough
> people who build 'private' releases that breaking it seems silly.
Thanks, Nate! I'll immediately give it a try.
--
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 Oct 20 13:44:24 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id NAA18693
for hackers-outgoing; Mon, 20 Oct 1997 13:44:24 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA18685
for <hackers@freebsd.org>; Mon, 20 Oct 1997 13:44:17 -0700 (PDT)
(envelope-from mrcpu@cdsnet.net)
Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5])
by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id NAA18089
for <hackers@freebsd.org>; Mon, 20 Oct 1997 13:44:14 -0700 (PDT)
Date: Mon, 20 Oct 1997 13:44:14 -0700 (PDT)
From: Jaye Mathisen <mrcpu@cdsnet.net>
To: hackers@freebsd.org
Subject: Is there any way to build a completely static system?
Message-ID: <Pine.NEB.3.95.971020134307.2330U-100000@mail.cdsnet.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I mean no .so's, nothing. Just the necessare .a's, and all binaries
statically linked...
Getting the binaries statically linked is easy, but I was hoping NOSHARED
would stop building the .so's for /usr/lib, but it seems to anyway.
Not critical, just curious.
From owner-freebsd-hackers Mon Oct 20 13:53:36 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id NAA19270
for hackers-outgoing; Mon, 20 Oct 1997 13:53:36 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from milehigh.denver.net (milehigh.denver.net [204.144.180.2])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA19261
for <hackers@freebsd.org>; Mon, 20 Oct 1997 13:53:23 -0700 (PDT)
(envelope-from jdc@milehigh.denver.net)
Received: (from jdc@localhost)
by milehigh.denver.net (8.8.5/8.8.5) id OAA08780;
Mon, 20 Oct 1997 14:53:53 -0600 (MDT)
Message-ID: <19971020145352.23528@denver.net>
Date: Mon, 20 Oct 1997 14:53:52 -0600
From: John-David Childs <jdc@nterprise.net>
To: hackers@freebsd.org
Subject: Re: Need source...
References: <199710172000.OAA21209@rocky.mt.sri.com> <199710171834.MAA03146@harmony.village.org> <199710172030.OAA03665@harmony.village.org> <199710172034.OAA21410@rocky.mt.sri.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.79
In-Reply-To: <199710172034.OAA21410@rocky.mt.sri.com>; from Nate Williams on Fri, Oct 17, 1997 at 02:34:11PM -0600
Organization: Enterprise Internet Solutions
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Or you could buy an external Jaz-drive and SCSI PCMCIA card ;-)
When I wanted to load 2.2-stable + X on my 800meg hard drive (not a
laptop), I partitioned my h.d. into a 100-meg 95 partition where
C:\WINDOWS sits and used the rest for FreeBSD. Win95 apps run from E:
Unfortunately, I was stupid (and cheap) and purchased an Adaptec-2920
before I ran outta money..so I can't use my Jaz drive with
2.2-stable/2.2.5 until the PAO stuff (and maybe the "hack" posted here a
few months ago) is updated.
--
John-David Childs (JC612) Enterprise Internet Solutions
Systems Administration @denver.net/internet-coach/@ronan.net
& Network Engineering 1031 S. Parker Rd. #I-8 Denver, CO 80231
Our country has plenty of good five-cent cigars, but the trouble is
they charge fifteen cents for them.
On Friday October 17, 1997, Nate Williams <nate@mt.sri.com>
had this to say about "Re: Need source...":
> > : And the problem is? I've got 3 OS's on my 800MB drive, Win95,
> > : FreeBSD-2.1 (stable non-changing unix environment), and FreeBSD-current
> > : (development environ with OS sources on it that is *very* tight on disk
> > : space.) I had to double-space the Win95 partition to get it to work,
> > : but it does. Unfortunately, I wasn't able to squeeze X onto the FreeBSD
> > : installations due to disk space.
> >
> > But I want X :-). It sounds like I can get most of what I want under
> > FreeBSD, however. -current has been stable enough for me for a long
> > time, so I may just run that.
>
> Then you probably have enough room for X. The double-space under Win95
> was the biggest factor in me being able to get both on the 800MB. (That
> and the fact that I don't do a whole lot under '95).
>
[SNIP]
From owner-freebsd-hackers Mon Oct 20 15:15:24 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA23829
for hackers-outgoing; Mon, 20 Oct 1997 15:15:24 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA23821
for <hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 15:15:18 -0700 (PDT)
(envelope-from atrens@nortel.ca)
Message-Id: <199710202215.PAA23821@hub.freebsd.org>
Received: from bcars520.ca.nortel.com (actually 47.128.5.188)
by bcarsde4.localhost; Mon, 20 Oct 1997 18:13:00 -0400
Received: from bnr.ca by bcars520.bnr.ca id <07023-0@bcars520.bnr.ca>;
Mon, 20 Oct 1997 18:12:30 -0400
Date: 20 Oct 1997 18:12 EDT
To: hackers@FreeBSD.ORG
From: "Andrew Atrens" <atrens@nortel.ca>
Subject: Re: pulling email addresses from freebsd lists
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
www.vix.com/spam seems to have been updated since my last visit in August -
they have several new tools (or at least new to me) that you may find helpful.
Imho the (more or less) free and open nature of the net, means that spammers
will always be a problem. I think our biggest advantage is that we outnumber
them. I think our biggest weakness is that we address the issue as individuals,
ie we don't leverage our numbers.
Perhaps we could come up with some sort of automated mechanism for collecting
and collectively complaining to joe spammer's isp. What I'm getting at it is
that when one of us on the list gets spam, likely we all do. Yet in most
instances we all need to go through the effort of identifying the guilty party,
and sending an appropriate complaint. if this information was captured somewhere,
and accessible by (perhaps) a web interface, then it would save all of the
duplicated investigation work required to nail down the spammer's identity.
Opinions anyone?
Andrew.
(opinions are mine, not Nortel's)
>
> One thing that might help is possibly assigning handles to email addresses
> on freebsd.org like
>
> 189291@freebsd.org = jamil@trojanhorse.ml.org
>
> and only allowing mail from other handles on that list
> to be redirected through freebsd.org to the mailer
>
> It would be much less likely for a spammer to attack because they would
> half to attack from a subscribed account.
>
> Or something like this...
>
>
>
>
> On Mon, 20 Oct 1997, Randall Hopper wrote:
>
> > Kristian Kennaway:
> > |I'd just like to note that today I received my first ever spam-mail,
> > |after posting to this list for the first time a few days ago. Until now
> > |I've been successfully "hiding" by not having my email address make it
> > |out onto UseNet or anywhere else grepped by spammers.
> >
> > Jonathan M. Bresler:
> > | we seem to be seeing a new tactic,
> > | evil spammer subscribes and harvests addresses from the
> > | list traffic.
> >
> >
> > I'd hazard a guess that the spammers aren't harvesting from the list e-mail
> > distribution directly but from NetNews (because of those numerous
> > list-to-NetNews gateways that some folks in the world funnel the FreeBSD
> > list traffic into). These pseudo-groups get out and into spam farmer
> > newsrc's without any real action on their part. Easy pickins'.
> >
> > If I didn't choose to post to NetNews with my real e-mail address anyway,
> > I'd complain about these news gateways. As is, I just grin and have some
> > fun bustin' spammers with their ISPs. And procmail bounce rules to
> > postmaster,abuse,root for those ISPs that don't seem to care.
> >
> > Randall
> >
> >
>
>
From owner-freebsd-hackers Mon Oct 20 15:17:08 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA23950
for hackers-outgoing; Mon, 20 Oct 1997 15:17:08 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from monk.via.net (monk.via.net [140.174.204.10])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA23940
for <freebsd-hackers@freebsd.org>; Mon, 20 Oct 1997 15:17:03 -0700 (PDT)
(envelope-from joe@via.net)
Received: (from joe@localhost) by monk.via.net (8.6.11/8.6.12) id PAA17351 for freebsd-hackers@freebsd.org; Mon, 20 Oct 1997 15:06:28 -0700
Date: Mon, 20 Oct 1997 15:06:28 -0700
From: Joe McGuckin <joe@via.net>
Message-Id: <199710202206.PAA17351@monk.via.net>
To: freebsd-hackers@freebsd.org
Subject: 2.2.2-RELEASE '875 SCSI won't negotiage
X-Sun-Charset: US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
(ncr0:0:0): "QUANTUM XP32275W LXY4" type 0 fixed SCSI 2
sd0(ncr0:0:0): Direct-Access
sd0(ncr0:0:0): WIDE SCSI (16 bit) enabled
sd0(ncr0:0:0): 20.0 MB/s (100 ns, offset 16)
Shouldn't this report back 40.0 MB/s for fast wide ultra ?
From owner-freebsd-hackers Mon Oct 20 15:53:40 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA26237
for hackers-outgoing; Mon, 20 Oct 1997 15:53:40 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA26228
for <hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 15:53:29 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA10385 for hackers@FreeBSD.ORG; Tue, 21 Oct 1997 00:52:57 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id AAA15149;
Tue, 21 Oct 1997 00:36:21 +0200 (MET DST)
Message-ID: <19971021003621.XE33370@uriah.heep.sax.de>
Date: Tue, 21 Oct 1997 00:36:21 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: hackers@FreeBSD.ORG
Subject: Re: Urge to apply the vn device hack even to 2.2.5
References: <199710201615.KAA29216@rocky.mt.sri.com> <199710202003.WAA06920@adv.IAEhv.nl>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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: <199710202003.WAA06920@adv.IAEhv.nl>; from Arjan de Vet on Oct 20, 1997 22:03:28 +0200
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Arjan de Vet wrote:
> I've done a 'make release' for 2.2-stable at least 5 times last week and I
> haven't seen the vn panics either (with 64MB of RAM). Only some ioctl
> message, see below.
I didn't have an occasion to run a full `make release' after applying
Nate's fix within the short time remaining before 2.2.5 is due.
However, i've tried to torture the vn device of such a kernel, and
haven't seen any ill effect. So i think we are safe with it.
Perhaps it's indeed that you've got too much RAM. I remember Mr. KATO
telling something about a condition that the lockmgr panic happened
whenever something (from the vn object) was about to be paged in or
out. So my normal (-current) `make release' machine has 32 MB of RAM
(and X11 running by the same time), perhaps that condition is simply
more likely then.
--
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 Oct 20 16:11:18 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id QAA27286
for hackers-outgoing; Mon, 20 Oct 1997 16:11:18 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA27262;
Mon, 20 Oct 1997 16:11:05 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA10796; Tue, 21 Oct 1997 01:10:57 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id BAA15227;
Tue, 21 Oct 1997 01:02:55 +0200 (MET DST)
Message-ID: <19971021010255.JX53463@uriah.heep.sax.de>
Date: Tue, 21 Oct 1997 01:02:55 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: hackers@FreeBSD.ORG, hardware@FreeBSD.ORG
Cc: tarkhil@mgt.msk.ru
Subject: Re: on Worm detection
References: <199710200519.JAA24209@asteroid.mgt.msk.ru>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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: <199710200519.JAA24209@asteroid.mgt.msk.ru>; from Alexander B. Povolotsky on Oct 20, 1997 09:19:21 +0400
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Alexander B. Povolotsky wrote:
> Since my 2.2-STABLE fails to detect Pinnacle Micro 4X4 CD-R as worm, and
> 2.2.2 or 2.2.1 did it, and I don't want to fetch it and install again, can't
> one wise man describe me process of worm detection, so I'll try to make it
> working?
All the magic is in /sys/scsi/scsiconf.c. If you'd care to quote the
boot messages, i could tell you what to add there.
--
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 Oct 20 16:35:53 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id QAA28677
for hackers-outgoing; Mon, 20 Oct 1997 16:35:53 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from time.cdrom.com (time.cdrom.com [204.216.27.226])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA28670
for <hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 16:35:45 -0700 (PDT)
(envelope-from jkh@time.cdrom.com)
Received: from time.cdrom.com (localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id QAA15924; Mon, 20 Oct 1997 16:34:42 -0700 (PDT)
To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
cc: hackers@FreeBSD.ORG
Subject: Re: Urge to apply the vn device hack even to 2.2.5
In-reply-to: Your message of "Tue, 21 Oct 1997 00:36:21 +0200."
<19971021003621.XE33370@uriah.heep.sax.de>
Date: Mon, 20 Oct 1997 16:34:42 -0700
Message-ID: <15920.877390482@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> Perhaps it's indeed that you've got too much RAM. I remember Mr. KATO
> telling something about a condition that the lockmgr panic happened
> whenever something (from the vn object) was about to be paged in or
> out. So my normal (-current) `make release' machine has 32 MB of RAM
> (and X11 running by the same time), perhaps that condition is simply
I was going to ask if RAM was a factor since I have 128MB in my
release building box and don't hit a lot of low memory problems that
others do as a result (and current.freebsd.org is another 128MB box -
maybe we should make our release-a-day server a 486SX with 8MB of
memory and switch it to being a release-a-week server instead.
We'd not have as useful a service by far, but it sure would catch
those load sensitive bugs early. :-)
Jordan
P.S. Yes, of course I'm just joking. :)
From owner-freebsd-hackers Mon Oct 20 16:52:15 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id QAA29596
for hackers-outgoing; Mon, 20 Oct 1997 16:52:15 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA29589
for <hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 16:52:07 -0700 (PDT)
(envelope-from tlambert@usr05.primenet.com)
Received: (from daemon@localhost)
by smtp04.primenet.com (8.8.7/8.8.7) id QAA04335;
Mon, 20 Oct 1997 16:51:51 -0700 (MST)
Received: from usr05.primenet.com(206.165.6.205)
via SMTP by smtp04.primenet.com, id smtpd004333; Mon Oct 20 16:51:50 1997
Received: (from tlambert@localhost)
by usr05.primenet.com (8.8.5/8.8.5) id QAA27105;
Mon, 20 Oct 1997 16:51:43 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710202351.QAA27105@usr05.primenet.com>
Subject: Re: Freebsd 3.0 current fails ipfilter 3.2b8 build (fwd)
To: darrenr@cyber.com.au (Darren Reed)
Date: Mon, 20 Oct 1997 23:51:43 +0000 (GMT)
Cc: tlambert@primenet.com, hackers@FreeBSD.ORG
In-Reply-To: <199710190548.PAA19493@plum.cyber.com.au> from "Darren Reed" at Oct 19, 97 03:48:32 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > > well, ifconfig, netstat, etc. all need it.
They reference kernel internal structures as an API.
> > > if you're writing your own LKM for a network driver, you need it.
LKM code is kernel code. Kernel code can have any requirements that
the kernel environment chooses to place on it (one of which is what
include files are necessary).
> > > if you're writing firewalling packet filtering code, you need it.
Again, kernel code.
> > > "struct ifnet" is used in _lots_ of places.
Not lots of places outside kernel code.
> > > if you want to simulate kernel code, then you also need it.
[ ... ]
> What if I mention this:
>
> I was using "struct ifnet" _WITHOUT_ wanting to look at kernel memory.
>
>
> Why would you want to do that, you ask.
>
> So you can more easily build userland code which interfaces with the
> code used in the kernel and test it that way.
In other words, unit testing.
I'd claim that your test framework must include whatever the kernel
includes, in order to properly simulate a kernel. Further, the code
you are unit testing in this fashion is -- kernel code.
I don't see this as being inconvenient except for users of "promiscuous"
interfaces (like your examples: ifconfig, netstat, etc.). I personally
*like* the idea of a "speed-bump" to slow down people going hell bent
for leather down the wrong road to an interface...
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 Oct 20 16:58:20 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id QAA00117
for hackers-outgoing; Mon, 20 Oct 1997 16:58:20 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA00111
for <hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 16:58:14 -0700 (PDT)
(envelope-from darrenr@cyber.com.au)
Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id JAA09206; Tue, 21 Oct 1997 09:57:17 +1000
From: Darren Reed <darrenr@cyber.com.au>
Message-Id: <199710202357.JAA09206@plum.cyber.com.au>
Subject: FreeBSD 3.0 kernel API ?!
To: tlambert@primenet.com (Terry Lambert)
Date: Tue, 21 Oct 1997 09:57:17 +1000 (EST)
Cc: julian@whistle.com, hackers@FreeBSD.ORG
In-Reply-To: <199710201834.LAA09783@usr05.primenet.com> from "Terry Lambert" at Oct 20, 97 06:34:31 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
In some mail I received from Terry Lambert, sie wrote
>
> > > If the code isn't portable to Linux, SVR4, and Solaris without
> > > compile time switches, why write it?
> >
> > Well, prior to these changes to FreeBSD, it was portable between
> > *BSD/SunOS4/Solaris2 without any compile time switches - not sure
> > about Linux. Why ? Because up until recently, all would give
> > you "struct ifnet" if you included net/if.h.
> >
> > So there you have it.
> >
> > This makes it harder to port code to FreeBSD.
> >
> > Or, from the other angle, FreeBSD code is less portable.
> >
> > Isn't that just wonderful ? *spew*
>
> It seems your complaint is that the use of the struct ifnet in
> the internal structures is not bracketed by:
>
> #ifdef __IF_VAR_H__
> #endif
No, it isn't.
> If you are using structures that contain this opaque data object,
> then you are doing something wrong.
> This is not to say that I'm happy with the code (I'm not), but
> that this type of interface seperation is both (1) necessary, and
> (2) desirable, from a "pure environment" perspective.
Sigh. This is all very amusing, I guess. Here's a tip for you:
if you *really* want to separate what user programs can and can not
include (or should and should not), don't put any "kernel only"
include files under /usr/include and remove all references from
/usr/include files to anything that should only be in the kernel.
Sure, you'll break lots of software out there, be totally
incompatible with everything else and annoy lots of 3rd party
software writers, but it _will_ achieve the goal you're aiming
for: - penalising anyone and everyone who makes use of a kernel
structure for non-kernel code, irrespective of its use.
Personally, I don't think any changes should be made for the
sake of making a change to hide structures but rather, effort
should be put into developing useful interfaces which software
can take advantage of.
Darren
p.s. what's up with hackers@freebsd ? I haven't seen any mail come
through it for a while now...
From owner-freebsd-hackers Mon Oct 20 17:01:09 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id RAA00417
for hackers-outgoing; Mon, 20 Oct 1997 17:01:09 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from whistle.com (s205m131.whistle.com [207.76.205.131])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA00404
for <freebsd-hackers@freebsd.org>; Mon, 20 Oct 1997 17:01:01 -0700 (PDT)
(envelope-from archie@whistle.com)
Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id RAA28205 for <freebsd-hackers@freebsd.org>; Mon, 20 Oct 1997 17:00:29 -0700 (PDT)
Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3)
id sma028203; Mon Oct 20 17:00:24 1997
Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id RAA11140 for freebsd-hackers@freebsd.org; Mon, 20 Oct 1997 17:00:24 -0700 (PDT)
From: Archie Cobbs <archie@whistle.com>
Message-Id: <199710210000.RAA11140@bubba.whistle.com>
Subject: Broken device LKM in 2.2
To: freebsd-hackers@freebsd.org
Date: Mon, 20 Oct 1997 17:00:23 -0700 (PDT)
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-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I guess nobody makes device type LKM's in 2.2.. but sys/lkm.h is
broken with respect to them. Here's a hack that fixes this. Perhaps
the "name ## _module", which is different from the other module
types, is there for some reason (?)
Anyway, it's incompatible with the DISPATCH macro defined later in
the file, and this fixes it...
More properly we should use MOD_DISPATCH instead of DISPATCH,
keep the "name ## _module" in MOD_DEV, add it also to the
other types, and use the first argument of MOD_DISPATCH -- the
module name -- in that macro to do a similar concatenation there.
-Archie
Index: lkm.h
===================================================================
RCS file: /cvs/freebsd/src/sys/sys/lkm.h,v
retrieving revision 1.12.2.1
diff -c -r1.12.2.1 lkm.h
*** 1.12.2.1 1997/06/29 08:45:45
--- lkm.h 1997/10/20 23:23:49
***************
*** 234,240 ****
#define MOD_DEV(name,devtype,devslot,devp) \
MOD_DECL(name); \
! static struct lkm_dev name ## _module = { \
LM_DEV, \
LKM_VERSION, \
#name ## "_mod", \
--- 234,240 ----
#define MOD_DEV(name,devtype,devslot,devp) \
MOD_DECL(name); \
! static struct lkm_dev _module = { \
LM_DEV, \
LKM_VERSION, \
#name ## "_mod", \
___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
From owner-freebsd-hackers Mon Oct 20 17:11:31 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id RAA01084
for hackers-outgoing; Mon, 20 Oct 1997 17:11:31 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.5.83])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA01077
for <hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 17:11:27 -0700 (PDT)
(envelope-from tlambert@usr05.primenet.com)
Received: (from daemon@localhost)
by smtp02.primenet.com (8.8.7/8.8.5) id RAA01527;
Mon, 20 Oct 1997 17:11:13 -0700 (MST)
Received: from usr05.primenet.com(206.165.6.205)
via SMTP by smtp02.primenet.com, id smtpd001515; Mon Oct 20 17:11:08 1997
Received: (from tlambert@localhost)
by usr05.primenet.com (8.8.5/8.8.5) id RAA28373;
Mon, 20 Oct 1997 17:11:05 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710210011.RAA28373@usr05.primenet.com>
Subject: Re: FreeBSD 3.0 kernel API ?!
To: darrenr@cyber.com.au (Darren Reed)
Date: Tue, 21 Oct 1997 00:11:04 +0000 (GMT)
Cc: tlambert@primenet.com, julian@whistle.com, hackers@FreeBSD.ORG
In-Reply-To: <199710202357.JAA09206@plum.cyber.com.au> from "Darren Reed" at Oct 21, 97 09:57:17 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> Sigh. This is all very amusing, I guess. Here's a tip for you:
> if you *really* want to separate what user programs can and can not
> include (or should and should not), don't put any "kernel only"
> include files under /usr/include and remove all references from
> /usr/include files to anything that should only be in the kernel.
The idea, I believe, is to clean up our own misuse of KVM as a
non-procedural interface to kernel data. Non-procedural interfaces
are bad because:
1) You can't hook them
2) A data version change equals an interface change,
and requires you to rebuild everything that
references the data
3) You can't "version" the interface so that the
program using it can operate against both old and
new versions.
> Sure, you'll break lots of software out there, be totally
> incompatible with everything else and annoy lots of 3rd party
> software writers, but it _will_ achieve the goal you're aiming
> for: - penalising anyone and everyone who makes use of a kernel
> structure for non-kernel code, irrespective of its use.
The only thing we intended to break was ourselves, because we knew
we were engaging in bad programming habits. It's only your poor
fortune to have *also* been engaging in bad programming habits.
> Personally, I don't think any changes should be made for the
> sake of making a change to hide structures but rather, effort
> should be put into developing useful interfaces which software
> can take advantage of.
I agree. But how can we get a picture of the spanning set of new
interfaces needed unless we take away all of the old interfaces,
and log what fails? Sure, we could organically grow things, and
let duplicate functionality (say like /procfs and sysinit) creep
up on us, so that we can't really point at "here is the right way",
but do we really want that?
Brass tacks time:
Why do *you, personally* need the kernel internal structure
defined by struct ifnet?
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 Oct 20 17:55:07 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id RAA04620
for hackers-outgoing; Mon, 20 Oct 1997 17:55:07 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA04594
for <hackers@Freebsd.org>; Mon, 20 Oct 1997 17:55:02 -0700 (PDT)
(envelope-from darrenr@cyber.com.au)
Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id KAA09620; Tue, 21 Oct 1997 10:54:24 +1000
From: Darren Reed <darrenr@cyber.com.au>
Message-Id: <199710210054.KAA09620@plum.cyber.com.au>
Subject: Re: FreeBSD 3.0 kernel API ?!
To: tlambert@primenet.com (Terry Lambert)
Date: Tue, 21 Oct 1997 10:54:23 +1000 (EST)
Cc: julian@whistle.com, hackers@Freebsd.org
In-Reply-To: <199710210011.RAA28373@usr05.primenet.com> from "Terry Lambert" at Oct 21, 97 00:11:04 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@Freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
In some mail I received from Terry Lambert, sie wrote
>
> I agree. But how can we get a picture of the spanning set of new
> interfaces needed unless we take away all of the old interfaces,
> and log what fails? Sure, we could organically grow things, and
> let duplicate functionality (say like /procfs and sysinit) creep
> up on us, so that we can't really point at "here is the right way",
> but do we really want that?
Hmmm, I think that duplicate functionality has some merit. For one,
it allows you to migrate from old to new rather than having to choose -
providing that it is posible to have both in a sane way. So whilst
the old functionality will not be available in the future, you can
use the old one whilst you refit to use the new one.
> Brass tacks time:
>
> Why do *you, personally* need the kernel internal structure
> defined by struct ifnet?
Because I try to use the same code for compiling into the kernel
as into the testing code. If I have to fake struct ifnet, I'll
only end up building a structure which has the same fields anyway.
Even though things like if_output aren't going to call the same
device driver output routine, I can use it to write to a file
and verify what's getting written out.
Darren
From owner-freebsd-hackers Mon Oct 20 18:05:14 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA05419
for hackers-outgoing; Mon, 20 Oct 1997 18:05:14 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: (from jmb@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA05395;
Mon, 20 Oct 1997 18:05:03 -0700 (PDT)
(envelope-from jmb)
From: "Jonathan M. Bresler" <jmb>
Message-Id: <199710210105.SAA05395@hub.freebsd.org>
Subject: Re: Bug in 2.2.2
To: gram@cdsec.com (Graham Wheeler)
Date: Mon, 20 Oct 1997 18:05:02 -0700 (PDT)
Cc: hackers@FreeBSD.ORG
In-Reply-To: <199710201648.SAA11704@cdsec.com> from "Graham Wheeler" at Oct 20, 97 06:48:12 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Graham Wheeler wrote:
>
> >
> > can you tell me how to reproduce it within X hours?
> > if i remember correctly, it was failing every X hours
> > for you. if its statically linked i can hack on
> > the shared library and see if i can track this down.
>
> I wrote a small program to exercise the heap and ran it for about ten million
> iterations without a problem. Then I decided to add a periodic call to fork(),
> as both Midnight Commander and the firewall gateway program both do plenty
> of these. When I ran this the O/S panicked almost immediately.
>
> Here is the program:
>
> // A simple program to exercise the heap.
Graham,
i have run your test program, both with and without fork(),
against phkmalloc from 2.2 upgraded to CTM 470 for over 10
million iterations. the upgrade replaces
/home/src/lib/libc/stdlib/malloc.c version 1.18.2.2 with
version 1.18.2.3. there are changes in the way that
phkmalloc deals with changing sizes fo allocated memory
and more. ;)
can you upgrade from 2.2.2 to 2.2.5 and run your code again?
2.2.5 will be out very soon. the source tree will be
tagged within the hour (Oct 20th 6pm PDT).
jmb
From owner-freebsd-hackers Mon Oct 20 18:24:53 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA06485
for hackers-outgoing; Mon, 20 Oct 1997 18:24:53 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA06474
for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 18:24:48 -0700 (PDT)
(envelope-from dkelly@nospam.hiwaay.net)
Received: from nospam.hiwaay.net (tnt2-162.HiWAAY.net [208.147.148.162])
by fly.HiWAAY.net (8.8.7/8.8.6) with ESMTP id UAA20202;
Mon, 20 Oct 1997 20:24:38 -0500 (CDT)
Received: from nospam.hiwaay.net (localhost [127.0.0.1])
by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP
id UAA14405; Mon, 20 Oct 1997 20:24:37 -0500 (CDT)
Message-Id: <199710210124.UAA14405@nospam.hiwaay.net>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Joe McGuckin <joe@via.net>
cc: freebsd-hackers@FreeBSD.ORG
From: dkelly@hiwaay.net
Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage
In-reply-to: Message from Joe McGuckin <joe@via.net>
of "Mon, 20 Oct 1997 15:06:28 PDT." <199710202206.PAA17351@monk.via.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 20 Oct 1997 20:24:34 -0500
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Joe McGuckin writes:
>
> (ncr0:0:0): "QUANTUM XP32275W LXY4" type 0 fixed SCSI 2
> sd0(ncr0:0:0): Direct-Access
> sd0(ncr0:0:0): WIDE SCSI (16 bit) enabled
> sd0(ncr0:0:0): 20.0 MB/s (100 ns, offset 16)
>
>
> Shouldn't this report back 40.0 MB/s for fast wide ultra ?
Probably should. But it might not really be up to 40 MB/sec. The MB/sec and
ns numbers agree. I got this the other day on my new Asus SC875 and 9G IBM
UW drive:
ncr0 <ncr 53c875 fast20 wide scsi> rev 3 int a irq 11 on pci0:11
ncr0 waiting for scsi devices to settle
(ncr0:0:0): WIDE SCSI (16 bit) enabled(ncr0:0:0): 10.0 MB/s (200 ns, offset 15)
(ncr0:0:0): "IBM OEM DCHS09W 2222" type 0 fixed SCSI 2
sd1(ncr0:0:0): Direct-Access
sd1(ncr0:0:0): WIDE SCSI (16 bit) enabled
sd1(ncr0:0:0): 20.0 MB/s (100 ns, offset 15)
8689MB (17796077 512 byte sectors)
Am mildly concerned about the 10.0 MB/s message that starts it off. And I'm
thinking about the whole issue because I'm not certian my performance is up
to snuff. Using bonnie:
IBM OEM DCHS09W on Asus SC875, new & empty 2.4G filesystem at end of disk:
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 3972 41.8 3986 14.6 2234 7.5 6700 76.3 8228 16.4 108.4 2.6
^^^^ this seems low
SEAGATE ST32550N on Adaptec 2940 (AIC-7870) old 86% full 1.8G fs
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 3980 43.2 4402 13.9 1774 5.0 4260 48.3 3759 5.7 71.5 1.5
System is an Asus P6NP5 PPro-166/512k 32M RAM.
# scsi -f /dev/rsd1c -m 8 -P 3
WCE: 0
MF: 0
RCD: 0
Demand Retention Priority: 1
Write Retention Priority: 1
Disable Pre-fetch Transfer Length: 65535
Minimum Pre-fetch: 0
Maximum Pre-fetch: 65535
Maximum Pre-fetch Ceiling: 65535
Observed the Seagate had the WCE set (Write Cache Enable) so I did the same
for the IBM.
Flipped the WCE bit from 0 to 1 and got this on the IBM (last fs):
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 7402 76.5 7927 31.0 2311 7.8 6587 75.2 8207 16.2 110.3 2.5
^^^^ ^^^^ both of these are *much* better.
After enabling the write cache, this drive is comparable to the new Seagate
4.3G Barracuda on an Adaptec 2940AU (AIC-7860) and P-133 I'm playing with
at work:
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 3653 75.6 8523 36.4 2293 15.9 3595 70.6 9183 38.4 92.2 4.3
It really bugged me that my UW HD on PentiumPro was being beat by a P-133
with narrow SCSI. Then I began to wonder if there was a difference between
inner and outer tracks. This fs starts about 200M past block 0, while the
above (up 2, the IBM) starts 2.4G from the end of the disk:
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 8098 79.7 9385 38.3 2758 9.2 6426 74.0 9772 20.1 111.2 2.5
...and that's more like it!
What really brought all this about was when a dump | restore from old 2.1G
Seagate to new 9.1G IBM reported 500k/sec thruput. The IBM fs's were still
mounted async as sysinstall left them.
--
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 Oct 20 18:32:53 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA06906
for hackers-outgoing; Mon, 20 Oct 1997 18:32:53 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.5.83])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA06883
for <hackers@freebsd.org>; Mon, 20 Oct 1997 18:32:36 -0700 (PDT)
(envelope-from tlambert@usr08.primenet.com)
Received: (from daemon@localhost)
by smtp02.primenet.com (8.8.7/8.8.5) id SAA08273;
Mon, 20 Oct 1997 18:31:25 -0700 (MST)
Received: from usr08.primenet.com(206.165.6.208)
via SMTP by smtp02.primenet.com, id smtpd008268; Mon Oct 20 18:31:23 1997
Received: (from tlambert@localhost)
by usr08.primenet.com (8.8.5/8.8.5) id SAA24304;
Mon, 20 Oct 1997 18:31:21 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710210131.SAA24304@usr08.primenet.com>
Subject: Re: FreeBSD 3.0 kernel API ?!
To: darrenr@cyber.com.au (Darren Reed)
Date: Tue, 21 Oct 1997 01:31:21 +0000 (GMT)
Cc: hackers@freebsd.org
In-Reply-To: <199710210054.KAA09620@plum.cyber.com.au> from "Darren Reed" at Oct 21, 97 10:54:23 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> Hmmm, I think that duplicate functionality has some merit. For one,
> it allows you to migrate from old to new rather than having to choose -
> providing that it is posible to have both in a sane way. So whilst
> the old functionality will not be available in the future, you can
> use the old one whilst you refit to use the new one.
This is the Novell NetWare API problem.
If I have an old interface and a new interface, I will choose to use
the old interface.
Why?
Because it's the larger market: my code will run on both old and new.
If I used the new interface, I'd only be able to run on new. The
market "old + new" > the market "old".
Simple economics.
> > Brass tacks time:
> >
> > Why do *you, personally* need the kernel internal structure
> > defined by struct ifnet?
>
> Because I try to use the same code for compiling into the kernel
> as into the testing code. If I have to fake struct ifnet, I'll
> only end up building a structure which has the same fields anyway.
> Even though things like if_output aren't going to call the same
> device driver output routine, I can use it to write to a file
> and verify what's getting written out.
I still don't understand. If it is kernel code, even if you plan on
running it in user space, you will define KERNEL. If you don't you
are not testing the code you will be running.
If it's kernel code you are testing, you will need to include if_var.h
for it to run in the kernel; therefore you need to include if_var.h
for it to run in the test jig, which pretends to be the kernel.
I think the issue is maybe that your test environment doesn't look
sufficiently like a kernel...
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 Oct 20 18:36:30 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA07190
for hackers-outgoing; Mon, 20 Oct 1997 18:36:30 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from misery.sdf.com (misery.sdf.com [204.244.210.193])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA07182
for <freebsd-hackers@freebsd.org>; Mon, 20 Oct 1997 18:36:26 -0700 (PDT)
(envelope-from tom@sdf.com)
Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1)
id 0xNTDx-00025N-00; Mon, 20 Oct 1997 18:35:09 -0700
Date: Mon, 20 Oct 1997 18:35:04 -0700 (PDT)
From: Tom <tom@sdf.com>
To: freebsd-hackers@freebsd.org
Subject: DLT drives
Message-ID: <Pine.BSF.3.95q.971020183404.8014B-100000@misery.sdf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
DLT tape drives will work under FreeBSD, right? I would think that they
would be just be a standard tape device. I'm looking at one of the
Quantum DLT drives.
Tom
From owner-freebsd-hackers Mon Oct 20 19:01:26 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA08783
for hackers-outgoing; Mon, 20 Oct 1997 19:01:26 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA08778
for <hackers@freebsd.org>; Mon, 20 Oct 1997 19:01:19 -0700 (PDT)
(envelope-from durian@plutotech.com)
Received: from shane.plutotech.com (shane.plutotech.com [206.168.67.149])
by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id UAA10419
for <hackers@freebsd.org>; Mon, 20 Oct 1997 20:01:12 -0600 (MDT)
Message-Id: <199710210201.UAA10419@pluto.plutotech.com>
From: "Mike Durian" <durian@plutotech.com>
To: hackers@freebsd.org
Subject: user vm addr to kernel vm addr
Date: Mon, 20 Oct 1997 20:01:11 -0600
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
In my virtual file system I'd like to speed up reads and writes
by copying directly from the uio structure to a vm address of
a buffer in the user process running on behalf of the filesystem.
I'm currently shoving all the data through a socket that the
user process reads from and copies into a buffer. I'd like to
go direct and skip the socket writing part. Does that make sense?
Anyway, I want to copy from a uio to a different process's vm space.
I can get the vm address of the destination buffer over a socket and
think I can use vm_fault_wire to make sure it stays accessable, but
I don't know how to convert that user space vm address into a
kernel space vm address that I can then use with copyout.
Is there an easy (or any) way to do this?
mike
From owner-freebsd-hackers Mon Oct 20 19:37:43 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA10828
for hackers-outgoing; Mon, 20 Oct 1997 19:37:43 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA10110
for <hackers@freebsd.org>; Mon, 20 Oct 1997 19:20:31 -0700 (PDT)
(envelope-from darrenr@cyber.com.au)
Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id MAA11955; Tue, 21 Oct 1997 12:18:59 +1000
From: Darren Reed <darrenr@cyber.com.au>
Message-Id: <199710210218.MAA11955@plum.cyber.com.au>
Subject: Re: FreeBSD 3.0 kernel API ?!
To: tlambert@primenet.com (Terry Lambert)
Date: Tue, 21 Oct 1997 12:18:59 +1000 (EST)
Cc: darrenr@cyber.com.au, hackers@freebsd.org
In-Reply-To: <199710210131.SAA24304@usr08.primenet.com> from "Terry Lambert" at Oct 21, 97 01:31:21 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
In some mail I received from Terry Lambert, sie wrote
>
> > > Brass tacks time:
> > >
> > > Why do *you, personally* need the kernel internal structure
> > > defined by struct ifnet?
> >
> > Because I try to use the same code for compiling into the kernel
> > as into the testing code. If I have to fake struct ifnet, I'll
> > only end up building a structure which has the same fields anyway.
> > Even though things like if_output aren't going to call the same
> > device driver output routine, I can use it to write to a file
> > and verify what's getting written out.
>
> I still don't understand. If it is kernel code, even if you plan on
> running it in user space, you will define KERNEL. If you don't you
> are not testing the code you will be running.
There are a couple of things lacking from the typical libc that are
in kernels. Things like mbuf functions, etc.
> If it's kernel code you are testing, you will need to include if_var.h
> for it to run in the kernel; therefore you need to include if_var.h
> for it to run in the test jig, which pretends to be the kernel.
Well, you see, that's just it. It doesn't need anything else, only the
"struct ifnet". I'd argue that a structure can be used and should be
available anywhere, it just describes a way to store some values in
memory. I have no problems with keeping variable names and function
prototypes away from users (in different .h files or whatever), it
even makes sense. But I don't think the same logic should be extended
to structures. I assume things like struct proc and struct user are
still available without defining KERNEL ?
> I think the issue is maybe that your test environment doesn't look
> sufficiently like a kernel...
No, it doesn't. Given that malloc(3) doesn't quite grok M_WAITOK,
probably never will :-)
Darren
From owner-freebsd-hackers Mon Oct 20 19:44:37 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA11185
for hackers-outgoing; Mon, 20 Oct 1997 19:44:37 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA11180
for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 19:44:35 -0700 (PDT)
(envelope-from karl@Mars.mcs.net)
Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id VAA22574; Mon, 20 Oct 1997 21:44:34 -0500 (CDT)
Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id VAA29554; Mon, 20 Oct 1997 21:44:34 -0500 (CDT)
Message-ID: <19971020214434.06832@Mars.Mcs.Net>
Date: Mon, 20 Oct 1997 21:44:34 -0500
From: Karl Denninger <karl@Mcs.Net>
To: Tom <tom@sdf.com>
Cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: DLT drives
References: <Pine.BSF.3.95q.971020183404.8014B-100000@misery.sdf.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.64
In-Reply-To: <Pine.BSF.3.95q.971020183404.8014B-100000@misery.sdf.com>; from Tom on Mon, Oct 20, 1997 at 06:35:04PM -0700
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Mon, Oct 20, 1997 at 06:35:04PM -0700, Tom wrote:
>
> DLT tape drives will work under FreeBSD, right? I would think that they
> would be just be a standard tape device. I'm looking at one of the
> Quantum DLT drives.
>
> Tom
Yes, they do, and quite nicely. We use them here (they're the only media
that has enough capacity and speed to be useful in our environment).
--
--
Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| NEW! K56Flex modem support is now available
Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines!
Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
From owner-freebsd-hackers Mon Oct 20 19:50:15 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA11476
for hackers-outgoing; Mon, 20 Oct 1997 19:50:15 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA11422
for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 19:49:46 -0700 (PDT)
(envelope-from tlambert@usr05.primenet.com)
Received: (from daemon@localhost)
by smtp04.primenet.com (8.8.7/8.8.7) id LAA15928;
Mon, 20 Oct 1997 11:27:24 -0700 (MST)
Received: from usr05.primenet.com(206.165.6.205)
via SMTP by smtp04.primenet.com, id smtpd015926; Mon Oct 20 11:27:23 1997
Received: (from tlambert@localhost)
by usr05.primenet.com (8.8.5/8.8.5) id LAA09252;
Mon, 20 Oct 1997 11:27:21 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710201827.LAA09252@usr05.primenet.com>
Subject: Re: FreeBSD authentication...
To: dec@phoenix.its.rpi.edu (David E. Cross)
Date: Mon, 20 Oct 1997 18:27:21 +0000 (GMT)
Cc: freebsd-hackers@FreeBSD.ORG
In-Reply-To: <Pine.BSF.3.96.971018102700.27956A-100000@phoenix.its.rpi.edu> from "David E. Cross" at Oct 18, 97 10:29:58 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> Is there any interest (should there be) to mooving to Pluggabl
> Authentication Modules. (Since they are implimented as shared libraries,
> that you link in as needed, would we need to rewrite ld.so a bit to ensure
> that people couldn't set their LD_LIBRARY_PATH, and then run su to get
> full root acces, sans password?)
Have you located a PAM implementation (not necessarily modules, but the
framework itself) which is under UCB copyright instead of GPL?
User authentication is a system critical function, like the kernel;
it's unlikely that PAM would be any more acceptable than a GPL'ed
driver if it's critical to system operation.
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 Oct 20 19:55:30 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA11773
for hackers-outgoing; Mon, 20 Oct 1997 19:55:30 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from misery.sdf.com (misery.sdf.com [204.244.210.193])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA11765
for <freebsd-hackers@freebsd.org>; Mon, 20 Oct 1997 19:55:26 -0700 (PDT)
(envelope-from tom@sdf.com)
Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1)
id 0xNURs-00027h-00; Mon, 20 Oct 1997 19:53:36 -0700
Date: Mon, 20 Oct 1997 19:53:33 -0700 (PDT)
From: Tom <tom@sdf.com>
To: Karl Denninger <karl@Mcs.Net>
cc: freebsd-hackers@freebsd.org
Subject: Re: DLT drives
In-Reply-To: <19971020214434.06832@Mars.Mcs.Net>
Message-ID: <Pine.BSF.3.95q.971020195244.8014E-100000@misery.sdf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
On Mon, 20 Oct 1997, Karl Denninger wrote:
> On Mon, Oct 20, 1997 at 06:35:04PM -0700, Tom wrote:
> >
> > DLT tape drives will work under FreeBSD, right? I would think that they
> > would be just be a standard tape device. I'm looking at one of the
> > Quantum DLT drives.
> >
> > Tom
>
> Yes, they do, and quite nicely. We use them here (they're the only media
> that has enough capacity and speed to be useful in our environment).
What kind? Quantum, HP, or...
Since you apparently need a lot of capacity, do also you use a changer?
> --
> --
> Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
> http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
> | NEW! K56Flex modem support is now available
> Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines!
> Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
>
>
Tom
From owner-freebsd-hackers Mon Oct 20 20:09:03 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id UAA12458
for hackers-outgoing; Mon, 20 Oct 1997 20:09:03 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA12444
for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 20:08:37 -0700 (PDT)
(envelope-from karl@Mars.mcs.net)
Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id WAA24160; Mon, 20 Oct 1997 22:07:45 -0500 (CDT)
Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id WAA00484; Mon, 20 Oct 1997 22:07:44 -0500 (CDT)
Message-ID: <19971020220744.21190@Mars.Mcs.Net>
Date: Mon, 20 Oct 1997 22:07:44 -0500
From: Karl Denninger <karl@mcs.net>
To: Tom <tom@sdf.com>
Cc: Karl Denninger <karl@mcs.net>, freebsd-hackers@FreeBSD.ORG
Subject: Re: DLT drives
References: <19971020214434.06832@Mars.Mcs.Net> <Pine.BSF.3.95q.971020195244.8014E-100000@misery.sdf.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.64
In-Reply-To: <Pine.BSF.3.95q.971020195244.8014E-100000@misery.sdf.com>; from Tom on Mon, Oct 20, 1997 at 07:53:33PM -0700
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Mon, Oct 20, 1997 at 07:53:33PM -0700, Tom wrote:
>
> On Mon, 20 Oct 1997, Karl Denninger wrote:
>
> > On Mon, Oct 20, 1997 at 06:35:04PM -0700, Tom wrote:
> > >
> > > DLT tape drives will work under FreeBSD, right? I would think that they
> > > would be just be a standard tape device. I'm looking at one of the
> > > Quantum DLT drives.
> > >
> > > Tom
> >
> > Yes, they do, and quite nicely. We use them here (they're the only media
> > that has enough capacity and speed to be useful in our environment).
>
> What kind? Quantum, HP, or...
I run two Compaq/Quantum 15/30s.
> Since you apparently need a lot of capacity, do also you use a changer?
2x30GB works ok for us at present, but we don't back up the news spool :-)
--
--
Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| NEW! K56Flex modem support is now available
Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines!
Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
From owner-freebsd-hackers Mon Oct 20 20:22:04 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id UAA13265
for hackers-outgoing; Mon, 20 Oct 1997 20:22:04 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from shell.futuresouth.com (shell.futuresouth.com [207.141.254.20])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA13257
for <hackers@freebsd.org>; Mon, 20 Oct 1997 20:22:01 -0700 (PDT)
(envelope-from fullermd@futuresouth.com)
Received: from shell.futuresouth.com (mail.futuresouth.com [207.141.254.21])
by shell.futuresouth.com (8.8.5/8.8.5) with SMTP id WAA15712
for <hackers@freebsd.org>; Mon, 20 Oct 1997 22:21:53 -0500 (CDT)
Date: Mon, 20 Oct 1997 22:21:52 -0500 (CDT)
From: "Matthew D. Fuller" <fullermd@futuresouth.com>
To: hackers@freebsd.org
Subject: Boot.flp + parallel ZIP...?
Message-ID: <Pine.BSF.3.96.971020221618.14260D-100000@shell.futuresouth.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I'm considering trying to assemble a boot floppy with parallel port ZIP
drive support. If it works, it'll be a lot easier to install from than
floppies (I know from unfortunate experience), but still have the easy,
do-it-yourself type of experience. It would also be easier for people
with small hard drives who don't want to waste space on a DOS partition
to install from, but don't want to much around with installing another
hard drive, or a SCSI bus for ZIP, etc.
This would be useful for me in a few situations, at least a little fun,
and (I think) a nice addition to our repetoir of installation methods.
I've often wished to install from a single ZIP disk instead of 50
floppies. So here're my questions:
1) Anyone already done it?
2) Is there any technical reason it can't be done?
3) Any reason it shouldn't be done?
4) Would it require any extraordinary means? i.e., serious source hacking
5) Any hints?
6) Want it if I make it?
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| FreeBSD; the way computers were meant to be |
* "The only reason I'm burning my candle at both ends, is *
| that I haven't figured out how to light the middle yet."|
* fullermd@futuresouth.com :-} MAtthew Fuller *
| http://keystone.westminster.edu/~fullermd |
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
From owner-freebsd-hackers Mon Oct 20 20:26:21 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id UAA13533
for hackers-outgoing; Mon, 20 Oct 1997 20:26:21 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sasami.jurai.net (winter@sasami.jurai.net [207.96.1.17])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA13521
for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 20:26:16 -0700 (PDT)
(envelope-from winter@jurai.net)
Received: from localhost (winter@localhost)
by sasami.jurai.net (8.8.7/8.8.7) with SMTP id XAA05988;
Mon, 20 Oct 1997 23:25:54 -0400 (EDT)
Date: Mon, 20 Oct 1997 23:25:54 -0400 (EDT)
From: "Matthew N. Dodd" <winter@jurai.net>
To: dkelly@hiwaay.net
cc: Joe McGuckin <joe@via.net>, freebsd-hackers@FreeBSD.ORG
Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage
In-Reply-To: <199710210124.UAA14405@nospam.hiwaay.net>
Message-ID: <Pine.BSF.3.95q.971020232218.18189C-100000@sasami.jurai.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Mon, 20 Oct 1997 dkelly@hiwaay.net wrote:
> It really bugged me that my UW HD on PentiumPro was being beat by a P-133
> with narrow SCSI. Then I began to wonder if there was a difference between
> inner and outer tracks. This fs starts about 200M past block 0, while the
> above (up 2, the IBM) starts 2.4G from the end of the disk:
Which is why you buy the largest, fastest drives available and short
stroke them when you want a really fast RAID system.
10k RPM drives are nice but the track to track seek delay is still a large
factor in performance.
Ideally I'd have an array of 100s of disk, each using only the outer
track. In a RAID 0/1 set, this would be really fast. :)
/*
Matthew N. Dodd | A memory retaining a love you had for life
winter@jurai.net | As cruel as it seems nothing ever seems to
http://www.jurai.net/~winter | go right - FLA M 3.1:53
*/
From owner-freebsd-hackers Mon Oct 20 20:52:01 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id UAA15010
for hackers-outgoing; Mon, 20 Oct 1997 20:52:01 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA14988
for <hackers@freebsd.org>; Mon, 20 Oct 1997 20:51:54 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id JAA02577;
Tue, 21 Oct 1997 09:25:10 +0930 (CST)
Message-Id: <199710202355.JAA02577@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Graham Wheeler <gram@cdsec.com>
cc: hackers@freebsd.org
Subject: Re: Bug in 2.2.2
In-reply-to: Your message of "Sat, 20 Oct 1997 18:48:12 +0200."
<199710201648.SAA11704@cdsec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 21 Oct 1997 09:25:08 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> >
> > can you tell me how to reproduce it within X hours?
> > if i remember correctly, it was failing every X hours
> > for you. if its statically linked i can hack on
> > the shared library and see if i can track this down.
>
> I wrote a small program to exercise the heap and ran it for about ten million
> iterations without a problem. Then I decided to add a periodic call to fork(),
> as both Midnight Commander and the firewall gateway program both do plenty
> of these. When I ran this the O/S panicked almost immediately.
This is starting to sound as though it might be related to the problem
that Marc Slemko and I (at least) are seeing with programs occupying 3x
required swap. I'm not sure if his system forks a lot, but our code
certainly does. No crashes/panics/arena corruption, but if there's
collateral damage in the VM system, then I can imagine that phkmalloc
is going to get its knickers much more twisted than other mallocs,
because it seems to dovetail closely with the VM behaviour.
> Here is the program:
Saved. I'm hoping to have a monster release-builder box going this
morning, and if I do I'll try this on 2.2.5 and 3.x.
mike
From owner-freebsd-hackers Mon Oct 20 21:06:18 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id VAA16018
for hackers-outgoing; Mon, 20 Oct 1997 21:06:18 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA16010
for <hackers@freebsd.org>; Mon, 20 Oct 1997 21:06:12 -0700 (PDT)
(envelope-from luigi@labinfo.iet.unipi.it)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id DAA20149; Tue, 21 Oct 1997 03:50:28 +0100
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199710210250.DAA20149@labinfo.iet.unipi.it>
Subject: How to deal with ERESTART ?
To: hackers@freebsd.org
Date: Tue, 21 Oct 1997 03:50:28 +0100 (MET)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I am having a problem in dealing with ERESTART in the audio driver.
Right now I have a sequence like
res = tsleep(..., PRIBIO | PCATCH , ..., timeout )
if (res == EINTR || res = ERESTART)
... do the same thing, typically abort operations.
the aim was to make it easy for apps to gain control on the driver.
Catching ERESTART this way had some interesting side effects on some
applications which makes me thing that it is probably wrong to
assimilate ERESTART and EINTR ?
So my question is: when can i get ERESTART as a result from tsleep(),
and would it be better to just restart the tsleep in this case ?
Cheers
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 Mon Oct 20 21:17:08 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id VAA16777
for hackers-outgoing; Mon, 20 Oct 1997 21:17:08 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA16760
for <hackers@freebsd.org>; Mon, 20 Oct 1997 21:16:58 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id NAA00473;
Tue, 21 Oct 1997 13:43:31 +0930 (CST)
Message-Id: <199710210413.NAA00473@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: "Mike Durian" <durian@plutotech.com>
cc: hackers@freebsd.org
Subject: Re: user vm addr to kernel vm addr
In-reply-to: Your message of "Mon, 20 Oct 1997 20:01:11 CST."
<199710210201.UAA10419@pluto.plutotech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 21 Oct 1997 13:43:30 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> In my virtual file system I'd like to speed up reads and writes
> by copying directly from the uio structure to a vm address of
> a buffer in the user process running on behalf of the filesystem.
uiomove() does this.
> I'm currently shoving all the data through a socket that the
> user process reads from and copies into a buffer. I'd like to
> go direct and skip the socket writing part. Does that make sense?
Yup.
mike
From owner-freebsd-hackers Mon Oct 20 21:18:12 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id VAA16850
for hackers-outgoing; Mon, 20 Oct 1997 21:18:12 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA16836
for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 21:18:07 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id NAA00457;
Tue, 21 Oct 1997 13:42:33 +0930 (CST)
Message-Id: <199710210412.NAA00457@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Terry Lambert <tlambert@primenet.com>
cc: dec@phoenix.its.rpi.edu (David E. Cross), freebsd-hackers@FreeBSD.ORG
Subject: Re: FreeBSD authentication...
In-reply-to: Your message of "Mon, 20 Oct 1997 18:27:21 GMT."
<199710201827.LAA09252@usr05.primenet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 21 Oct 1997 13:42:33 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > Is there any interest (should there be) to mooving to Pluggabl
> > Authentication Modules. (Since they are implimented as shared libraries,
> > that you link in as needed, would we need to rewrite ld.so a bit to ensure
> > that people couldn't set their LD_LIBRARY_PATH, and then run su to get
> > full root acces, sans password?)
>
> Have you located a PAM implementation (not necessarily modules, but the
> framework itself) which is under UCB copyright instead of GPL?
The Linux-PAM library is available under a dual (either-or) license.
Again, please see my page at http://www.smith.net.au/~mike.
There is a working and mostly-functional port of a slightly out-of-date
version linked off there, and the Linux-PAM people have been very easy
to work with. At one point Randy Terbush was attacking the libpwdb
code (similarly licensed), but I haven't heard from him for some time.
This module adds significant and useful functionality, but the code is
Bad.
> User authentication is a system critical function, like the kernel;
> it's unlikely that PAM would be any more acceptable than a GPL'ed
> driver if it's critical to system operation.
The problems with PAM and our current model are more related to the
current woolly concept of a "session", particularly associating an "end"
with a "beginning".
mike
From owner-freebsd-hackers Mon Oct 20 21:20:43 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id VAA17020
for hackers-outgoing; Mon, 20 Oct 1997 21:20:43 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA17015
for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 21:20:39 -0700 (PDT)
(envelope-from julian@whistle.com)
Received: (from daemon@localhost)
by alpo.whistle.com (8.8.5/8.8.5) id VAA26456;
Mon, 20 Oct 1997 21:19:01 -0700 (PDT)
Received: from current1.whistle.com(207.76.205.22)
via SMTP by alpo.whistle.com, id smtpd026454; Tue Oct 21 04:18:59 1997
Date: Mon, 20 Oct 1997 21:17:32 -0700 (PDT)
From: Julian Elischer <julian@whistle.com>
To: Terry Lambert <tlambert@primenet.com>
cc: "David E. Cross" <dec@phoenix.its.rpi.edu>, freebsd-hackers@FreeBSD.ORG
Subject: Re: FreeBSD authentication...
In-Reply-To: <199710201827.LAA09252@usr05.primenet.com>
Message-ID: <Pine.BSF.3.95.971020211634.20816A-100000@current1.whistle.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Mon, 20 Oct 1997, Terry Lambert wrote:
> > Is there any interest (should there be) to mooving to Pluggabl
> > Authentication Modules. (Since they are implimented as shared libraries,
> > that you link in as needed, would we need to rewrite ld.so a bit to ensure
> > that people couldn't set their LD_LIBRARY_PATH, and then run su to get
> > full root acces, sans password?)
>
> Have you located a PAM implementation (not necessarily modules, but the
> framework itself) which is under UCB copyright instead of GPL?
>
The MIT PAM which Linux uses is under a dual BSD/GNU copyright.
> User authentication is a system critical function, like the kernel;
> it's unlikely that PAM would be any more acceptable than a GPL'ed
> driver if it's critical to system operation.
>
>
> 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 Oct 20 22:10:21 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id WAA19307
for hackers-outgoing; Mon, 20 Oct 1997 22:10:21 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from gate.mgt.msk.ru (mgtrep.24h.dialup.ru [194.87.18.139])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA19299
for <hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 22:10:12 -0700 (PDT)
(envelope-from tarkhil@mgt.msk.ru)
Received: from asteroid.mgt.msk.ru (asteroid.mgt.msk.ru [192.168.133.145])
by gate.mgt.msk.ru (8.8.6/8.8.6) with ESMTP id JAA18194;
Tue, 21 Oct 1997 09:10:20 +0400 (MSD)
Received: from asteroid.mgt.msk.ru (localhost.mgt.msk.ru [127.0.0.1])
by asteroid.mgt.msk.ru (8.8.7/8.8.6) with ESMTP id JAA01364;
Tue, 21 Oct 1997 09:09:21 +0400 (MSD)
Message-Id: <199710210509.JAA01364@asteroid.mgt.msk.ru>
To: Arjan de Vet <Arjan.deVet@adv.IAEhv.nl>
cc: hackers@FreeBSD.ORG
Reply-To: tarkhil@mgt.msk.ru
Subject: Re: Urge to apply the vn device hack even to 2.2.5
In-reply-to: Your message of "Mon, 20 Oct 1997 22:03:28 +0200."
<199710202003.WAA06920@adv.IAEhv.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 21 Oct 1997 09:09:21 +0400
From: "Alexander B. Povolotsky" <tarkhil@mgt.msk.ru>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> I've done a 'make release' for 2.2-stable at least 5 times last week and I
> haven't seen the vn panics either (with 64MB of RAM). Only some ioctl
> message, see below.
Failed, with 32 and 128 MB... Anyway, I hope it's now history ;-)
Alex.
From owner-freebsd-hackers Mon Oct 20 22:14:47 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id WAA19455
for hackers-outgoing; Mon, 20 Oct 1997 22:14:47 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA19447
for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 22:14:41 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id OAA00653;
Tue, 21 Oct 1997 14:40:31 +0930 (CST)
Message-Id: <199710210510.OAA00653@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Julian Elischer <julian@whistle.com>
cc: Terry Lambert <tlambert@primenet.com>,
"David E. Cross" <dec@phoenix.its.rpi.edu>,
freebsd-hackers@FreeBSD.ORG
Subject: Re: FreeBSD authentication...
In-reply-to: Your message of "Mon, 20 Oct 1997 21:17:32 MST."
<Pine.BSF.3.95.971020211634.20816A-100000@current1.whistle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 21 Oct 1997 14:40:31 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > Have you located a PAM implementation (not necessarily modules, but the
> > framework itself) which is under UCB copyright instead of GPL?
>
> The MIT PAM which Linux uses is under a dual BSD/GNU copyright.
Which PAM is this? Are you referring to "Linux-PAM", ie. the Andrew
Morgan code? This is heavily supported by RedHat.
mike
From owner-freebsd-hackers Mon Oct 20 22:17:24 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id WAA19608
for hackers-outgoing; Mon, 20 Oct 1997 22:17:24 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from pluto.plutotech.com (ken@mail.plutotech.com [206.168.67.137])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA19602
for <hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 22:17:21 -0700 (PDT)
(envelope-from ken@plutotech.com)
Received: (from ken@localhost)
by pluto.plutotech.com (8.8.5/8.8.5) id XAA18704;
Mon, 20 Oct 1997 23:17:20 -0600 (MDT)
From: Kenneth Merry <ken@plutotech.com>
Message-Id: <199710210517.XAA18704@pluto.plutotech.com>
Subject: Re: user vm addr to kernel vm addr
In-Reply-To: <199710210201.UAA10419@pluto.plutotech.com> from Mike Durian at "Oct 20, 97 08:01:11 pm"
To: durian@plutotech.com (Mike Durian)
Date: Mon, 20 Oct 1997 23:17:20 -0600 (MDT)
Cc: hackers@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL28s (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Mike Durian wrote...
> In my virtual file system I'd like to speed up reads and writes
> by copying directly from the uio structure to a vm address of
> a buffer in the user process running on behalf of the filesystem.
> I'm currently shoving all the data through a socket that the
> user process reads from and copies into a buffer. I'd like to
> go direct and skip the socket writing part. Does that make sense?
> Anyway, I want to copy from a uio to a different process's vm space.
> I can get the vm address of the destination buffer over a socket and
> think I can use vm_fault_wire to make sure it stays accessable, but
> I don't know how to convert that user space vm address into a
> kernel space vm address that I can then use with copyout.
> Is there an easy (or any) way to do this?
I'm not positive this is what you're looking for, but... one way
to do it is to map the user address into the kernel address space using
vmapbuf().
If you want a specific code example, just let me know. (or look in
the CAM SCSI passthrough driver for the passmapmem() and passunmapmem()
functions)
Ken
--
Kenneth Merry
ken@plutotech.com
From owner-freebsd-hackers Mon Oct 20 23:06:10 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id XAA21678
for hackers-outgoing; Mon, 20 Oct 1997 23:06:10 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from safeconcept.utimaco.co.at (mail-gw.utimaco.co.at [195.96.28.162])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA21670
for <hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 23:06:01 -0700 (PDT)
(envelope-from Michael.Schuster@utimaco.co.at)
Received: (from uucp@localhost)
by safeconcept.utimaco.co.at (8.8.5/8.8.5) id HAA03404
for <hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 07:53:59 +0200 (CEST)
Received: from wshpux.utimaco.co.at(10.0.0.18) by safeconcept via smap (V2.0)
id xma003402; Tue, 21 Oct 97 07:53:45 +0200
Message-ID: <344C45CA.C98D731F@utimaco.co.at>
Date: Tue, 21 Oct 1997 08:03:54 +0200
From: Michael Schuster <Michael.Schuster@utimaco.co.at>
Organization: Utimaco Safe Concept GmbH., Linz, Austria
X-Mailer: Mozilla 4.03 [de] (X11; I; HP-UX B.10.01 9000/715)
MIME-Version: 1.0
To: "hackers@FreeBSD.ORG" <hackers@FreeBSD.ORG>
Subject: Re: outb() / inb()
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
James Raynard wrote:
>
> On Mon, Oct 20, 1997 at 08:44:33AM +0200, Michael Schuster wrote:
> >
> > >#define outb(port,data) \
> > > <....> \
> > > ? outbc(port,data):outbv(port,data))
> >
> > which means that if you write
> > outb (0x250, *c++);
> > then the expression "*c++" gets evaluated twice
>
> Sorry, but this isn't true: only one of the outbc/outbv expressions will
> be evaluated (the rules are exactly the same as for an if-else statement).
oops!
I got things mixed up there ...
actually, it's the first argument (port) that gets evaluated (at least)
twice, since it's in the expression before the "?" which I left out.
sorry about that & thanks for the hint
Michael
--
Michael Schuster
Utimaco Safe Concept GmbH. | Tel: +43 732 655755 41
Europaplatz 6 | Fax: +43 732 655755 5
A-4020 Linz Austria | email: Michael.Schuster@utimaco.co.at
From owner-freebsd-hackers Mon Oct 20 23:20:56 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id XAA22256
for hackers-outgoing; Mon, 20 Oct 1997 23:20:56 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA22248
for <hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 23:20:52 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA13844; Tue, 21 Oct 1997 08:20:34 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id IAA17010;
Tue, 21 Oct 1997 08:15:17 +0200 (MET DST)
Message-ID: <19971021081517.PE48415@uriah.heep.sax.de>
Date: Tue, 21 Oct 1997 08:15:17 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: hackers@FreeBSD.ORG
Cc: darrenr@cyber.com.au (Darren Reed)
Subject: Re: FreeBSD 3.0 kernel API ?!
References: <199710201834.LAA09783@usr05.primenet.com> <199710202357.JAA09206@plum.cyber.com.au>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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: <199710202357.JAA09206@plum.cyber.com.au>; from Darren Reed on Oct 21, 1997 09:57:17 +1000
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Darren Reed wrote:
> Sigh. This is all very amusing, I guess. Here's a tip for you:
> if you *really* want to separate what user programs can and can not
> include (or should and should not), don't put any "kernel only"
> include files under /usr/include and remove all references from
> /usr/include files to anything that should only be in the kernel.
You're missing the point of /usr/include/sys/ and friends. This
directory is intended to carry the common interface declarations
between kernel and userland. The most consistent way for a
development machine is, of course, to symlink these directories into
the kernel tree. (NB: this doesn't necessarily i agree with all those
*_var.h's. IMHO, an #ifdef _KERNEL (still misspelled without the
underscore in FreeBSD) should suffice. LKMs do need to define this
macro, too, of course.)
> p.s. what's up with hackers@freebsd ? I haven't seen any mail come
> through it for a while now...
Well, maybe your site caused excessive bounces, so Jonathan had to
remove you? I'm dropping you a Cc this time.
--
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 Oct 20 23:21:36 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id XAA22282
for hackers-outgoing; Mon, 20 Oct 1997 23:21:36 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA22276
for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 23:21:32 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA13850 for freebsd-hackers@FreeBSD.ORG; Tue, 21 Oct 1997 08:21:25 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id IAA17019;
Tue, 21 Oct 1997 08:18:00 +0200 (MET DST)
Message-ID: <19971021081759.TH50130@uriah.heep.sax.de>
Date: Tue, 21 Oct 1997 08:17:59 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: freebsd-hackers@FreeBSD.ORG
Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage
References: <joe@via.net> <199710210124.UAA14405@nospam.hiwaay.net>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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: <199710210124.UAA14405@nospam.hiwaay.net>; from dkelly@hiwaay.net on Oct 20, 1997 20:24:34 -0500
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As dkelly@hiwaay.net wrote:
> > sd0(ncr0:0:0): WIDE SCSI (16 bit) enabled
> > sd0(ncr0:0:0): 20.0 MB/s (100 ns, offset 16)
> >
> >
> > Shouldn't this report back 40.0 MB/s for fast wide ultra ?
>
> Probably should.
Probably should not. It should read as ``20 MHz'', this makes no
promises about the actual speed.
--
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 Oct 20 23:21:41 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id XAA22303
for hackers-outgoing; Mon, 20 Oct 1997 23:21:41 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA22294
for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Oct 1997 23:21:37 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA13851 for freebsd-hackers@FreeBSD.ORG; Tue, 21 Oct 1997 08:21:35 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id IAA17031;
Tue, 21 Oct 1997 08:19:04 +0200 (MET DST)
Message-ID: <19971021081904.GT30220@uriah.heep.sax.de>
Date: Tue, 21 Oct 1997 08:19:04 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: freebsd-hackers@FreeBSD.ORG
Subject: Re: DLT drives
References: <Pine.BSF.3.95q.971020183404.8014B-100000@misery.sdf.com>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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.95q.971020183404.8014B-100000@misery.sdf.com>; from Tom on Oct 20, 1997 18:35:04 -0700
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Tom wrote:
> DLT tape drives will work under FreeBSD, right?
They were a very boring :) experience to me. Just plug it in, nothing
else.
--
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 Oct 20 23:23:57 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id XAA22524
for hackers-outgoing; Mon, 20 Oct 1997 23:23:57 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA22518
for <freebsd-hackers@freebsd.org>; Mon, 20 Oct 1997 23:23:53 -0700 (PDT)
(envelope-from jamil@trojanhorse.ml.org)
Received: from localhost (jamil@localhost)
by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id XAA00272
for <freebsd-hackers@freebsd.org>; Mon, 20 Oct 1997 23:23:44 -0700 (PDT)
Date: Mon, 20 Oct 1997 23:23:43 -0700 (PDT)
From: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
To: freebsd-hackers@freebsd.org
Subject: Solid State Disks
Message-ID: <Pine.BSF.3.96.971020231150.258A-100000@trojanhorse.ml.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Anybody seen any good literature/prices on this sort of thing lately. How
long are they rumored to exist. It would be really cool if a PC was like
an hp48, damn thing never crashes and is basically always on.
My vision for the PC: (It will happen)
Pizzabox case, no fan. Seperate AC/DC transformer externally (like the
old C64's).
No moving parts, 17" active color lcd panel (touch).
Voice interface, keyboard area that can reconfigure itself.
Fiberoptic wide area networking port built in.
Never shuts down, goes off or resets.
Memory can be maintained indefinitely without application of
external power via eeprom mirroring.
Battery powered main memory/storage.
Second built in battery can act as ups to keep the machine up and function
throughout extended power outages.
From owner-freebsd-hackers Mon Oct 20 23:28:55 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id XAA22820
for hackers-outgoing; Mon, 20 Oct 1997 23:28:55 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA22812
for <freebsd-hackers@freebsd.org>; Mon, 20 Oct 1997 23:28:51 -0700 (PDT)
(envelope-from root@trojanhorse.ml.org)
Received: from localhost (root@localhost)
by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id XAA00288
for <freebsd-hackers@freebsd.org>; Mon, 20 Oct 1997 23:28:45 -0700 (PDT)
Date: Mon, 20 Oct 1997 23:28:45 -0700 (PDT)
From: 0000-Administrator <root@trojanhorse.ml.org>
To: freebsd-hackers@freebsd.org
Subject: Floppy Disk Driver (RELENG-stable)
Message-ID: <Pine.BSF.3.96.971020232447.282A-100000@trojanhorse.ml.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I witnessed an interesting thing the other day. I mounted a dos disk
copied over a big file in the background and then went to bash and tried
to do file completion on the file before it was done copying. This managed
to lock up the floppy disk permantely, plus hang any related things like
running "mount" or "df" or "ls /"
the system still was able to run but the root did not get unmounted
properly on shutdown and had to be fixed after reboot.
From owner-freebsd-hackers Tue Oct 21 00:36:51 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id AAA26294
for hackers-outgoing; Tue, 21 Oct 1997 00:36:51 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from heron.doc.ic.ac.uk (lExgEBkQ9UjPzeJI99id0Nf7uHDe4PS4@heron.doc.ic.ac.uk [146.169.2.31])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA26286
for <hackers@freebsd.org>; Tue, 21 Oct 1997 00:36:43 -0700 (PDT)
(envelope-from njs3@doc.ic.ac.uk)
Received: from oak67.doc.ic.ac.uk [146.169.33.67] ([Ul6DOs820hazxxEWdBkPMQcqlk4JVj9y])
by heron.doc.ic.ac.uk with smtp (Exim 1.62 #3)
id 0xNYsl-00025W-00; Tue, 21 Oct 1997 08:37:40 +0100
Received: from njs3 by oak67.doc.ic.ac.uk with local (Exim 1.62 #3)
id 0xNYrc-0004nJ-00; Tue, 21 Oct 1997 08:36:28 +0100
From: njs3@doc.ic.ac.uk (Niall Smart)
Date: Tue, 21 Oct 1997 08:36:27 +0100
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: "Andrew Atrens" <atrens@nortel.ca>
Subject: Re: pulling email addresses from freebsd lists
Cc: hackers@freebsd.org
Message-Id: <E0xNYrc-0004nJ-00@oak67.doc.ic.ac.uk>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
>
> www.vix.com/spam seems to have been updated since my last visit in August -
> they have several new tools (or at least new to me) that you may find helpful.
>
> Imho the (more or less) free and open nature of the net, means that spammers
> will always be a problem.
I disagree, I believe that (mail) protocols which require authentication
and tracability of the sender would cut spam dramatically, the problem
is that the internet's core protocols were designed with the assumption
that no-one would deliberately abuse them, that was fine in the 70's
and 80's but isn't the case today. If, when you received spam, you
could determine the senders email, name, and phone number the amount of
complaints to spammers and their ISP's would rise massively. It would
also provide the technological infrastructure that governments need to
enforce anti-spam legislation.
If the spammers knew their identity was available, and knew they would
get caught and prosecuted, then they wouldn't do it.
> I think our biggest advantage is that we outnumber
> them. I think our biggest weakness is that we address the issue as individuals,
> ie we don't leverage our numbers.
I agree.
>
> Perhaps we could come up with some sort of automated mechanism for collecting
> and collectively complaining to joe spammer's isp. What I'm getting at it is
> that when one of us on the list gets spam, likely we all do. Yet in most
> instances we all need to go through the effort of identifying the guilty party,
> and sending an appropriate complaint. if this information was captured somewhere,
> and accessible by (perhaps) a web interface, then it would save all of the
> duplicated investigation work required to nail down the spammer's identity.
This sounds like a good idea. Also, how about modifying majordomo so that
it does not show the senders email address, just their name? Obviously
this makes things awkward if two people on the list want to communicate
privately and do not know each others email address.. an obfuscated email
in the signature would help this. (e.g. n_js3_@do_c.ic.a_c.u_k)
Niall
From owner-freebsd-hackers Tue Oct 21 00:49:43 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id AAA27143
for hackers-outgoing; Tue, 21 Oct 1997 00:49:43 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA27131
for <hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 00:49:33 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id RAA00387;
Tue, 21 Oct 1997 17:16:16 +0930 (CST)
Message-Id: <199710210746.RAA00387@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: "Matthew D. Fuller" <fullermd@futuresouth.com>
cc: hackers@FreeBSD.ORG
Subject: Re: Boot.flp + parallel ZIP...?
In-reply-to: Your message of "Mon, 20 Oct 1997 22:21:52 EST."
<Pine.BSF.3.96.971020221618.14260D-100000@shell.futuresouth.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 21 Oct 1997 17:16:14 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> I'm considering trying to assemble a boot floppy with parallel port ZIP
> drive support.
Yay! Please do!
> 1) Anyone already done it?
No.
> 2) Is there any technical reason it can't be done?
No.
> 3) Any reason it shouldn't be done?
Guilt on my part that the ppa driver isn't in 2.2.5?
> 4) Would it require any extraordinary means? i.e., serious source hacking
It may be moderately magic getting ppa into the boot kernel config as
part of the release build process (if you do go that way).
> 5) Any hints?
Have patience. Working out how the boot floppy build process works can
be a challenge.
> 6) Want it if I make it?
I'm sure we can put it somewhere useful, yes!
mike
From owner-freebsd-hackers Tue Oct 21 01:11:22 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id BAA28417
for hackers-outgoing; Tue, 21 Oct 1997 01:11:22 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from ren.dtir.qld.gov.au (firewall-user@ns.dtir.qld.gov.au [203.108.138.66])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA28406
for <freebsd-hackers@freebsd.org>; Tue, 21 Oct 1997 01:11:15 -0700 (PDT)
(envelope-from syssgm@dtir.qld.gov.au)
Received: by ren.dtir.qld.gov.au; id SAA26660; Tue, 21 Oct 1997 18:21:58 +1000 (EST)
Received: from ogre.dtir.qld.gov.au(167.123.8.3) by ren.dtir.qld.gov.au via smap (3.2)
id xma026656; Tue, 21 Oct 97 18:21:32 +1000
Received: from localhost.dtir.qld.gov.au (localhost.dtir.qld.gov.au [127.0.0.1])
by ogre.dtir.qld.gov.au (8.8.7/8.8.7) with SMTP id SAA12294;
Tue, 21 Oct 1997 18:10:14 +1000 (EST)
Message-Id: <199710210810.SAA12294@ogre.dtir.qld.gov.au>
X-Authentication-Warning: ogre.dtir.qld.gov.au: localhost.dtir.qld.gov.au [127.0.0.1] didn't use HELO protocol
To: freebsd-hackers@freebsd.org
cc: syssgm@dtir.qld.gov.au
Subject: Re: Urge to apply the vn device hack even to 2.2.5
References: <15920.877390482@time.cdrom.com>
In-Reply-To: <15920.877390482@time.cdrom.com>
from "Jordan K. Hubbard" at "Mon, 20 Oct 1997 23:34:42 +0000"
Date: Tue, 21 Oct 1997 18:10:13 +1000
From: Stephen McKay <syssgm@dtir.qld.gov.au>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
On Monday, 20th October 1997, "Jordan K. Hubbard" wrote:
>maybe we should make our release-a-day server a 486SX with 8MB of
>memory and switch it to being a release-a-week server instead.
>We'd not have as useful a service by far, but it sure would catch
>those load sensitive bugs early. :-)
Hey, I used to do this for ya! I used to have a 386sx16 with 4Mb ram
and 13.5 Mb of swap. Yes, every byte of swap counted! It didn't have
enough disk to store anything, so /usr/src and /usr/obj were NFS. It
used to take around 10 days to crank out a make world. Sort of a
continuing lesson in patience. It did find real bugs though.
Unfortunately, it took sick and died. :-(
>P.S. Yes, of course I'm just joking. :)
I've always been fascinated by those bald blokes that whip themselves
in the name of religious purification. They don't joke either.
Stephen.
From owner-freebsd-hackers Tue Oct 21 01:46:07 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id BAA00416
for hackers-outgoing; Tue, 21 Oct 1997 01:46:07 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA00408
for <hackers@freebsd.org>; Tue, 21 Oct 1997 01:46:02 -0700 (PDT)
(envelope-from gram@cdsec.com)
Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id KAA26850 for <hackers@freebsd.org>; Tue, 21 Oct 1997 10:56:05 +0200 (SAT)
Received: by citadel via recvmail id 26817; Tue Oct 21 10:55:42 1997
by gram.cdsec.com (8.8.5/8.8.5) id KAA12807
for hackers@freebsd.org; Tue, 21 Oct 1997 10:22:20 +0200 (SAT)
From: Graham Wheeler <gram@cdsec.com>
Message-Id: <199710210822.KAA12807@cdsec.com>
Subject: Re: Bug in 2.2.2
To: hackers@freebsd.org
Date: Tue, 21 Oct 1997 10:22:19 +0200 (SAT)
X-Mailer: ELM [version 2.4 PL25-h4.1]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> > I wrote a small program to exercise the heap and ran it for about ten million
> > iterations without a problem. Then I decided to add a periodic call to fork(),
> > as both Midnight Commander and the firewall gateway program both do plenty
> > of these. When I ran this the O/S panicked almost immediately.
> >
> Graham,
> i have run your test program, both with and without fork(),
> against phkmalloc from 2.2 upgraded to CTM 470 for over 10
> million iterations. the upgrade replaces
> /home/src/lib/libc/stdlib/malloc.c version 1.18.2.2 with
> version 1.18.2.3. there are changes in the way that
> phkmalloc deals with changing sizes fo allocated memory
> and more. ;)
>
> can you upgrade from 2.2.2 to 2.2.5 and run your code again?
> 2.2.5 will be out very soon. the source tree will be
> tagged within the hour (Oct 20th 6pm PDT).
We have a subscription, which means I will be able to do this, but only in
a few weeks time. I upgraded my HDD at home last night, and, not having a
2.2.2 CD there, installed 2.2.1. If I remember I will run the program there
tonight, and see what happens, just for interest.
Would it be possible to use the newer malloc.c with 2.2.2, without changing
anything else? That would be a test I could do in the short term.
--
Dr Graham Wheeler E-mail: gram@cdsec.com
Citadel Data Security Phone: +27(21)23-6065/6/7
Internet/Intranet Network Specialists Mobile: +27(83)-253-9864
Firewalls/Virtual Private Networks Fax: +27(21)24-3656
Data Security Products WWW: http://www.cdsec.com/
From owner-freebsd-hackers Tue Oct 21 01:55:05 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id BAA00950
for hackers-outgoing; Tue, 21 Oct 1997 01:55:05 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA00944
for <hackers@freebsd.org>; Tue, 21 Oct 1997 01:55:01 -0700 (PDT)
(envelope-from gram@cdsec.com)
Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id LAA27137 for <hackers@freebsd.org>; Tue, 21 Oct 1997 11:05:05 +0200 (SAT)
Received: by citadel via recvmail id 27104; Tue Oct 21 11:04:17 1997
by gram.cdsec.com (8.8.5/8.8.5) id KAA12877
for hackers@freebsd.org; Tue, 21 Oct 1997 10:30:56 +0200 (SAT)
From: Graham Wheeler <gram@cdsec.com>
Message-Id: <199710210830.KAA12877@cdsec.com>
Subject: Re: Bug in 2.2.2
To: hackers@freebsd.org
Date: Tue, 21 Oct 1997 10:30:55 +0200 (SAT)
X-Mailer: ELM [version 2.4 PL25-h4.1]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
>
> I see the fork() in your code, but I don't see where it's doing a wait() t=
> o =
>
> pick up the childs exit status. Am I missing something?
No - I wrote the program very quickly. As I saved it I remembered I hadn't
caught the SIGCHLDs to reap the zombies, but decided to run it anyway, and
add the reap code afterwards. Which is why I said in my original message:
> I hadn't bothered doing any signal catching here; this was quick 'n dirty.
This doesn't change the point - which is that the program should
not cause a panic. It should just cause the process table to fill up and for
the fork()s to fail after a while. Admittedly this could cause problems with
the O/S if it tries to fork something else, but the first message I saw was
not a `cannot fork', but a `panic: vmstat...' (or something along those
lines; I don't remember the exact message but I do remember that it was a
VM related message).
cheers
gram
--
Dr Graham Wheeler E-mail: gram@cdsec.com
Citadel Data Security Phone: +27(21)23-6065/6/7
Internet/Intranet Network Specialists Mobile: +27(83)-253-9864
Firewalls/Virtual Private Networks Fax: +27(21)24-3656
Data Security Products WWW: http://www.cdsec.com/
From owner-freebsd-hackers Tue Oct 21 02:36:59 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id CAA03480
for hackers-outgoing; Tue, 21 Oct 1997 02:36:59 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA03474
for <freebsd-hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 02:36:52 -0700 (PDT)
(envelope-from roberto@keltia.freenix.fr)
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 LAA32082 for <freebsd-hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 11:36:52 +0200
Received: (from uucp@localhost)
by brasil.brainstorm.eu.org (8.8.6/brasil-1.2) with UUCP id LAA10868
for freebsd-hackers@FreeBSD.ORG; Tue, 21 Oct 1997 11:36:34 +0200
Received: (from roberto@localhost)
by keltia.freenix.fr (8.8.7/keltia-2.11/nospam) id HAA01628;
Tue, 21 Oct 1997 07:57:54 +0200 (CEST)
(envelope-from roberto)
Message-ID: <19971021075754.42358@keltia.freenix.fr>
Date: Tue, 21 Oct 1997 07:57:54 +0200
From: Ollivier Robert <roberto@keltia.freenix.fr>
To: freebsd-hackers@FreeBSD.ORG
Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage
References: <joe@via.net> <199710210124.UAA14405@nospam.hiwaay.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84
In-Reply-To: <199710210124.UAA14405@nospam.hiwaay.net>; from dkelly@hiwaay.net on Mon, Oct 20, 1997 at 08:24:34PM -0500
X-Operating-System: FreeBSD 3.0-CURRENT ctm#3745 AMD-K6 MMX @ 208 MHz
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
According to dkelly@hiwaay.net:
> ncr0 <ncr 53c875 fast20 wide scsi> rev 3 int a irq 11 on pci0:11
> ncr0 waiting for scsi devices to settle
> (ncr0:0:0): WIDE SCSI (16 bit) enabled
> (ncr0:0:0): 10.0 MB/s (200 ns, offset 15)
> (ncr0:0:0): "IBM OEM DCHS09W 2222" type 0 fixed SCSI 2
> sd1(ncr0:0:0): Direct-Access
> sd1(ncr0:0:0): WIDE SCSI (16 bit) enabled
> sd1(ncr0:0:0): 20.0 MB/s (100 ns, offset 15)
> 8689MB (17796077 512 byte sectors)
I'm very surprised because I have a DCAS (the 5400 rpm version) on a 875 as
well (the ASUS one) and it reports:
ncr0: <ncr 53c875 fast20 wide scsi> rev 0x03 int a irq 12 on pci0.11.0
scbus0 at ncr0 bus 0
sd0 at scbus0 target 0 lun 0
sd0: <IBM DCAS-34330W S65A> type 0 fixed SCSI 2
sd0: Direct-Access
sd0: WIDE SCSI (16 bit) enabled
sd0: 40.0 MB/s (50 ns, offset 15)
4134MB (8467200 512 byte sectors)
sd2 at scbus0 target 2 lun 0
sd2: <IBM DORS-32160 WA6A> type 0 fixed SCSI 2
sd2: Direct-Access
sd2: 20.0 MB/s (50 ns, offset 15)
2063MB (4226725 512 byte sectors)
sd2 is a Ultra narrow drive.
WCE was enabled on the DCAS from the factory.
--
Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr
FreeBSD keltia.freenix.fr 3.0-CURRENT #41: Sat Oct 18 18:47:01 CEST 1997
From owner-freebsd-hackers Tue Oct 21 03:53:09 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id DAA06978
for hackers-outgoing; Tue, 21 Oct 1997 03:53:09 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from gate.mgt.msk.ru (mgtrep.24h.dialup.ru [194.87.18.139])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA06955
for <hackers@freebsd.org>; Tue, 21 Oct 1997 03:52:49 -0700 (PDT)
(envelope-from tarkhil@mgt.msk.ru)
Received: from asteroid.mgt.msk.ru (asteroid.mgt.msk.ru [192.168.133.145])
by gate.mgt.msk.ru (8.8.6/8.8.6) with ESMTP id OAA18739
for <hackers@freebsd.org>; Tue, 21 Oct 1997 14:53:04 +0400 (MSD)
Received: from asteroid.mgt.msk.ru (localhost.mgt.msk.ru [127.0.0.1])
by asteroid.mgt.msk.ru (8.8.7/8.8.6) with ESMTP id OAA12808
for <hackers@freebsd.org>; Tue, 21 Oct 1997 14:52:02 +0400 (MSD)
Message-Id: <199710211052.OAA12808@asteroid.mgt.msk.ru>
To: hackers@freebsd.org
Reply-To: tarkhil@mgt.msk.ru
Subject: on ccd and large disk array
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 21 Oct 1997 14:52:01 +0400
From: "Alexander B. Povolotsky" <tarkhil@mgt.msk.ru>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Hello!
We're making a (relatively) large disk array using ccd: 5 Micropolis HDDs,
8.7 Gb each, i.e. about 40 Gb total.
Does anyone know possible traps on our way? Is FFS as-is stable on 40 Gb
filesystems? What may we need to patch?
We're running FreeBSD 2.2.2, PPro-200, 128 Mb RAM, AHA 2940 Ultra and AHA
2940 Ultra Wide (all HDDs in ccd are on Ultra Wide).
Alex.
From owner-freebsd-hackers Tue Oct 21 04:55:20 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id EAA09152
for hackers-outgoing; Tue, 21 Oct 1997 04:55:20 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from ifi.uio.no (ifi.uio.no [129.240.64.2])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA09134
for <hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 04:55:13 -0700 (PDT)
(envelope-from dag-erli@ifi.uio.no)
Received: from bera.ifi.uio.no (2602@bera.ifi.uio.no [129.240.65.84])
by ifi.uio.no (8.8.7/8.8.7/ifi0.2) with ESMTP id NAA11721
for <hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 13:54:35 +0200 (MET DST)
Received: (from dag-erli@localhost) by bera.ifi.uio.no ; Tue, 21 Oct 1997 13:54:32 +0200 (MET DST)
To: hackers@FreeBSD.ORG
Subject: Re: pulling email addresses from freebsd lists
References: <199710202215.PAA23821@hub.freebsd.org>
Organization: Not unless it can't be avoided.
X-url: http://www.ifi.uio.no/~dag-erli/
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
From: dag-erli@ifi.uio.no (Dag-Erling Coidan Smørgrav)
Date: 21 Oct 1997 13:54:29 +0200
In-Reply-To: "Andrew Atrens"'s message of 20 Oct 1997 18:12 EDT
Message-ID: <xzphgabnxfu.fsf@bera.ifi.uio.no>
Lines: 9
X-Mailer: Gnus v5.3/Emacs 19.34
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
"Andrew Atrens" <atrens@nortel.ca> writes:
> Perhaps we could come up with some sort of automated mechanism for collecting
> and collectively complaining to joe spammer's isp. What I'm getting at it is
Such a mechanism already exists. 'pkg_add adcomplain-1.6'.
--
* Finrod (INTJ) * Unix weenie * dag-erli@ifi.uio.no * cellular +47-92835919 *
RFC1123: "Be liberal in what you accept, and conservative in what you send"
From owner-freebsd-hackers Tue Oct 21 06:41:16 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id GAA13055
for hackers-outgoing; Tue, 21 Oct 1997 06:41:16 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA13032
for <freebsd-hackers@freebsd.org>; Tue, 21 Oct 1997 06:41:07 -0700 (PDT)
(envelope-from jbryant@argus.tfs.net)
Received: from argus.tfs.net (pm3-p19.tfs.net [206.154.183.211]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id IAA30272; Tue, 21 Oct 1997 08:40:28 -0500
Received: (from jbryant@localhost)
by argus.tfs.net (8.8.7/8.8.5) id IAA11750;
Tue, 21 Oct 1997 08:41:01 -0500 (CDT)
From: Jim Bryant <jbryant@unix.tfs.net>
Message-Id: <199710211341.IAA11750@argus.tfs.net>
Subject: Re: Solid State Disks
In-Reply-To: <Pine.BSF.3.96.971020231150.258A-100000@trojanhorse.ml.org> from "Jamil J. Weatherbee" at "Oct 20, 97 11:23:43 pm"
To: jamil@trojanhorse.ml.org (Jamil J. Weatherbee)
Date: Tue, 21 Oct 1997 08:41:01 -0500 (CDT)
Cc: freebsd-hackers@freebsd.org
Reply-to: jbryant@tfs.net
X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@#
X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
In reply:
> Anybody seen any good literature/prices on this sort of thing lately. How
> long are they rumored to exist. It would be really cool if a PC was like
> an hp48, damn thing never crashes and is basically always on.
kinda cool... SS disks have been around for a while, but i don't
recall non-volatility though.
> Memory can be maintained indefinitely without application of
> external power via eeprom mirroring.
>
> Battery powered main memory/storage.
> Second built in battery can act as ups to keep the machine up and function
> throughout extended power outages.
how about bringing back a tried but true technology:
bubbles... magnetic bubble memory is inherently non-volatile, and the
only problems to be overcome would be speed, and price. but then
again, have you seen the prices on DEC and IBM's SS disks???
another option could be a good 10AH gellcell on some
micropower-standby ram. would add some weight, but is the best option
for data retention at ram speeds.
jim
--
All opinions expressed are mine, if you | "I will not be pushed, stamped,
think otherwise, then go jump into turbid | briefed, debriefed, indexed, or
radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner"
------------------------------------------------------------------------------
Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw
voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant
------------------------------------------------------------------------------
HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+
From owner-freebsd-hackers Tue Oct 21 07:53:29 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id HAA16570
for hackers-outgoing; Tue, 21 Oct 1997 07:53:29 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sunmbx.netmbx.de (sunmbx.netmbx.de [192.76.152.9])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA16565
for <freebsd-hackers@FreeBSD.org>; Tue, 21 Oct 1997 07:53:26 -0700 (PDT)
(envelope-from TG@TechSoft.de)
Received: by sunmbx.netmbx.de (Smail3.2.0.96)
from TechSoft.de (193.101.167.2) with smtp
id <m0xNfgG-000JnbC>; Tue, 21 Oct 1997 16:53:12 +0200 (MET DST)
Received: from PROSIGNIA/SpoolDir by TechSoft.de (Mercury 1.31);
21 Oct 97 16:55:41 GMT+0100
Received: from SpoolDir by PROSIGNIA (Mercury 1.31); 21 Oct 97 16:55:28 GMT+0100
From: "Thilo Gelenk" <TG@TechSoft.de>
Organization: Tech Soft GmbH
To: freebsd-hackers@FreeBSD.org
Date: Tue, 21 Oct 1997 16:55:20 MET
Subject: source from FBSD2.2.2 decompressing
Priority: normal
X-mailer: Pegasus Mail for Windows (v2.54DE)
Message-ID: <1DDACE6256E@TechSoft.de>
Sender: owner-freebsd-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk
Hi folks,
I have bought the FreeBSD 2.2.2 CDs to get the source
code. It is contained on the CD under /src, but I need to
run "sh install.sh", what seems to be possible only under
BSD (so I have first to install it).
- I am searching for a way to decompress all source files from Dir
/src under DOS/Windows directly.
-Or should I try to read the CD Rom in an UNIX machine (HP)
and then - what is needed to uncompress the source
files ?
Any help would be great - please email me directly TG@techsoft.de
Thanks from Berlin
Thilo
From owner-freebsd-hackers Tue Oct 21 09:05:04 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id JAA20740
for hackers-outgoing; Tue, 21 Oct 1997 09:05:04 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from tahiti.oss.uswest.net (tahiti.oss.uswest.net [204.147.85.151])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA20721
for <freebsd-hackers@freebsd.org>; Tue, 21 Oct 1997 09:04:58 -0700 (PDT)
(envelope-from rantapaa@uswest.net)
Received: (from rantapaa@localhost) by tahiti.oss.uswest.net (8.8.5/8.6.12) id LAA05204; Tue, 21 Oct 1997 11:04:57 -0500 (CDT)
Date: Tue, 21 Oct 1997 11:04:56 -0500 (CDT)
From: Erik E Rantapaa <rantapaa@uswest.net>
To: freebsd-hackers@freebsd.org
Subject: PROT_READ needed for read() call?
Message-ID: <Pine.BSF.3.91.971021105226.996A-100000@tahiti.oss.uswest.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
While porting some code to FreeBSD 2.2-STABLE I noticed that in order
to read() into a mmap-ed address space you need PROT_READ as well as
PROT_WRITE, otherwise you get a "Bad address" error (EFAULT).
The original code (Solaris) only requires PROT_WRITE.
This is not a big deal, but I was wondering what the current thinking
was on such issues.
--
Erik Rantapaa
rantapaa@math.umn.edu
From owner-freebsd-hackers Tue Oct 21 09:07:07 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id JAA20871
for hackers-outgoing; Tue, 21 Oct 1997 09:07:07 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from austin.polstra.com (austin.polstra.com [206.213.73.10])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA20855
for <hackers@freebsd.org>; Tue, 21 Oct 1997 09:07:04 -0700 (PDT)
(envelope-from jdp@austin.polstra.com)
Received: from austin.polstra.com (jdp@localhost)
by austin.polstra.com (8.8.7/8.8.5) with ESMTP id JAA16013;
Tue, 21 Oct 1997 09:06:49 -0700 (PDT)
Message-Id: <199710211606.JAA16013@austin.polstra.com>
To: dec@phoenix.its.rpi.edu
Subject: Re: FreeBSD authentication...
In-Reply-To: <Pine.BSF.3.96.971018102700.27956A-100000@phoenix.its.rpi.edu>
References: <Pine.BSF.3.96.971018102700.27956A-100000@phoenix.its.rpi.edu>
Organization: Polstra & Co., Seattle, WA
Cc: hackers@freebsd.org
Date: Tue, 21 Oct 1997 09:06:48 -0700
From: John Polstra <jdp@polstra.com>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
In article <Pine.BSF.3.96.971018102700.27956A-100000@phoenix.its.rpi.edu>,
David E. Cross <dec@phoenix.its.rpi.edu> wrote:
> (Since they are implimented as shared libraries, that you link in as
> needed, would we need to rewrite ld.so a bit to ensure that people
> couldn't set their LD_LIBRARY_PATH, and then run su to get full root
> acces, sans password?)
The dynamic linker ignores LD_LIBRARY_PATH when running setuid or
setgid.
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 Tue Oct 21 09:51:31 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id JAA24303
for hackers-outgoing; Tue, 21 Oct 1997 09:51:31 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from pluto.plutotech.com (ken@mail.plutotech.com [206.168.67.137])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA24294
for <hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 09:51:29 -0700 (PDT)
(envelope-from ken@plutotech.com)
Received: (from ken@localhost)
by pluto.plutotech.com (8.8.5/8.8.5) id KAA18361;
Tue, 21 Oct 1997 10:50:49 -0600 (MDT)
From: Kenneth Merry <ken@plutotech.com>
Message-Id: <199710211650.KAA18361@pluto.plutotech.com>
Subject: Re: on ccd and large disk array
In-Reply-To: <199710211052.OAA12808@asteroid.mgt.msk.ru> from "Alexander B. Povolotsky" at "Oct 21, 97 02:52:01 pm"
To: tarkhil@mgt.msk.ru
Date: Tue, 21 Oct 1997 10:50:49 -0600 (MDT)
Cc: hackers@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL28s (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Alexander B. Povolotsky wrote...
> Hello!
>
> We're making a (relatively) large disk array using ccd: 5 Micropolis HDDs,
> 8.7 Gb each, i.e. about 40 Gb total.
>
> Does anyone know possible traps on our way? Is FFS as-is stable on 40 Gb
> filesystems? What may we need to patch?
You'll need to make sure that you edit login.conf and increase the
limits on memory usage, etc., so that you can fsck the partition.
> We're running FreeBSD 2.2.2, PPro-200, 128 Mb RAM, AHA 2940 Ultra and AHA
> 2940 Ultra Wide (all HDDs in ccd are on Ultra Wide).
I built a 60G ccd array a couple of months ago, it seemed to work
just fine. I think it should work okay for you as well, but you might
want to get input from some of the folks running news servers, etc., on big
ccd arrays.
Ken
--
Kenneth Merry
ken@plutotech.com
From owner-freebsd-hackers Tue Oct 21 10:25:41 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA26724
for hackers-outgoing; Tue, 21 Oct 1997 10:25:41 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA26719
for <freebsd-hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 10:25:35 -0700 (PDT)
(envelope-from gurney_j@efn.org)
Received: (from jmg@localhost)
by hydrogen.nike.efn.org (8.8.7/8.8.7) id KAA01399;
Tue, 21 Oct 1997 10:23:04 -0700 (PDT)
Message-ID: <19971021102303.60699@hydrogen.nike.efn.org>
Date: Tue, 21 Oct 1997 10:23:03 -0700
From: John-Mark Gurney <gurney_j@efn.org>
To: Thilo Gelenk <TG@TechSoft.de>
Cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: source from FBSD2.2.2 decompressing
References: <1DDACE6256E@TechSoft.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <1DDACE6256E@TechSoft.de>; from Thilo Gelenk on Tue, Oct 21, 1997 at 05:11:06PM +0100
Reply-To: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
Organization: Cu Networking
X-Operating-System: FreeBSD 2.2.1-RELEASE i386
X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4
X-Files: The truth is out there
X-URL: http://resnet.uoregon.edu/~gurney_j/
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Thilo Gelenk scribbled this message on Oct 21:
> Hi folks,
> I have bought the FreeBSD 2.2.2 CDs to get the source
> code. It is contained on the CD under /src, but I need to
> run "sh install.sh", what seems to be possible only under
> BSD (so I have first to install it).
>
> - I am searching for a way to decompress all source files from Dir
> /src under DOS/Windows directly.
> -Or should I try to read the CD Rom in an UNIX machine (HP)
> and then - what is needed to uncompress the source
> files ?
any program that can handle both tar and gz files will work.. the
files are just one large file that were split into 240k chunks..
copy file.aa+file.ab+...+file.zz file.tgz will reassemble the file
for you... the other thing is that the source probably isn't to useful
on a dos machine.. by my opinion only...
--
John-Mark Gurney Modem/FAX: +1 541 683 6954
Cu Networking
Live in Peace, destroy Micro$oft, support free software, run FreeBSD
From owner-freebsd-hackers Tue Oct 21 11:05:54 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA29632
for hackers-outgoing; Tue, 21 Oct 1997 11:05:54 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from misery.sdf.com (misery.sdf.com [204.244.210.193])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA29627
for <hackers@freebsd.org>; Tue, 21 Oct 1997 11:05:50 -0700 (PDT)
(envelope-from tom@sdf.com)
Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1)
id 0xNieV-0002mC-00; Tue, 21 Oct 1997 11:03:35 -0700
Date: Tue, 21 Oct 1997 11:03:28 -0700 (PDT)
From: Tom <tom@sdf.com>
To: Kenneth Merry <ken@plutotech.com>
cc: tarkhil@mgt.msk.ru, hackers@freebsd.org
Subject: Re: on ccd and large disk array
In-Reply-To: <199710211650.KAA18361@pluto.plutotech.com>
Message-ID: <Pine.BSF.3.95q.971021110209.10454G-100000@misery.sdf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
On Tue, 21 Oct 1997, Kenneth Merry wrote:
> I built a 60G ccd array a couple of months ago, it seemed to work
> just fine. I think it should work okay for you as well, but you might
> want to get input from some of the folks running news servers, etc., on big
> ccd arrays.
Many news servers are setup with multiple ccd arrays, especially since
you need to add aditional storage every 6 months.
> Ken
> --
> Kenneth Merry
> ken@plutotech.com
>
>
Tom
From owner-freebsd-hackers Tue Oct 21 11:13:37 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA00431
for hackers-outgoing; Tue, 21 Oct 1997 11:13:37 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA00422
for <freebsd-hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 11:13:31 -0700 (PDT)
(envelope-from toor@dyson.iquest.net)
Received: (from root@localhost)
by dyson.iquest.net (8.8.7/8.8.5) id NAA02391;
Tue, 21 Oct 1997 13:13:23 -0500 (EST)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199710211813.NAA02391@dyson.iquest.net>
Subject: Re: PROT_READ needed for read() call?
In-Reply-To: <Pine.BSF.3.91.971021105226.996A-100000@tahiti.oss.uswest.net> from Erik E Rantapaa at "Oct 21, 97 11:04:56 am"
To: rantapaa@uswest.net (Erik E Rantapaa)
Date: Tue, 21 Oct 1997 13:13:23 -0500 (EST)
Cc: freebsd-hackers@FreeBSD.ORG
Reply-To: dyson@FreeBSD.ORG
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-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Erik E Rantapaa said:
>
> While porting some code to FreeBSD 2.2-STABLE I noticed that in order
> to read() into a mmap-ed address space you need PROT_READ as well as
> PROT_WRITE, otherwise you get a "Bad address" error (EFAULT).
> The original code (Solaris) only requires PROT_WRITE.
>
> This is not a big deal, but I was wondering what the current thinking
> was on such issues.
>
As I remember, POSIX suggests/requires PROT_WRITE also imply PROT_READ.
If it does, I'll correct the situation. (I have a copy of POSIX.)
--
John
dyson@freebsd.org
jdyson@nc.com
From owner-freebsd-hackers Tue Oct 21 11:30:42 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA01779
for hackers-outgoing; Tue, 21 Oct 1997 11:30:42 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA01764
for <freebsd-hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 11:30:36 -0700 (PDT)
(envelope-from wilko@yedi.iaf.nl)
Received: by iafnl.es.iaf.nl with UUCP id AA28247
(5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Tue, 21 Oct 1997 20:30:46 +0200
Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id TAA00963; Tue, 21 Oct 1997 19:54:32 +0100 (MET)
From: Wilko Bulte <wilko@yedi.iaf.nl>
Message-Id: <199710211854.TAA00963@yedi.iaf.nl>
Subject: Re: Solid State Disks
To: jbryant@tfs.net
Date: Tue, 21 Oct 1997 19:54:32 +0100 (MET)
Cc: jamil@trojanhorse.ml.org, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <199710211341.IAA11750@argus.tfs.net> from "Jim Bryant" at Oct 21, 97 08:41:01 am
X-Organisation: Private FreeBSD site - Arnhem, The Netherlands
X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org'
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-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Jim Bryant wrote...
> In reply:
> > Anybody seen any good literature/prices on this sort of thing lately. How
> > long are they rumored to exist. It would be really cool if a PC was like
> > an hp48, damn thing never crashes and is basically always on.
>
> kinda cool... SS disks have been around for a while, but i don't
> recall non-volatility though.
Oh sure, they exist. DEC sells (Quantum) SSDs which also contain a NiCD
battery and a normal magnetic disk. When power fails the SSD contents
are dumped onto the magnetic one to get data retention.
> bubbles... magnetic bubble memory is inherently non-volatile, and the
> only problems to be overcome would be speed, and price. but then
> again, have you seen the prices on DEC and IBM's SS disks???
Qute he? ;-)
_ ____________________________________________________________________
| / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko
|/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try'
------------------ Support your local daemons: run FreeBSD Unix -----Yoda
From owner-freebsd-hackers Tue Oct 21 11:31:30 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA01834
for hackers-outgoing; Tue, 21 Oct 1997 11:31:30 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA01812
for <freebsd-hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 11:31:17 -0700 (PDT)
(envelope-from wilko@yedi.iaf.nl)
Received: by iafnl.es.iaf.nl with UUCP id AA28253
(5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Tue, 21 Oct 1997 20:30:59 +0200
Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id TAA01003; Tue, 21 Oct 1997 19:57:18 +0100 (MET)
From: Wilko Bulte <wilko@yedi.iaf.nl>
Message-Id: <199710211857.TAA01003@yedi.iaf.nl>
Subject: Re: DLT drives
To: tom@sdf.com (Tom)
Date: Tue, 21 Oct 1997 19:57:18 +0100 (MET)
Cc: karl@Mcs.Net, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <Pine.BSF.3.95q.971020195244.8014E-100000@misery.sdf.com> from "Tom" at Oct 20, 97 07:53:33 pm
X-Organisation: Private FreeBSD site - Arnhem, The Netherlands
X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org'
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-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Tom wrote...
>
> On Mon, 20 Oct 1997, Karl Denninger wrote:
>
> > On Mon, Oct 20, 1997 at 06:35:04PM -0700, Tom wrote:
> > >
> > > DLT tape drives will work under FreeBSD, right? I would think that they
> > > would be just be a standard tape device. I'm looking at one of the
> > > Quantum DLT drives.
> > >
> > > Tom
> >
> > Yes, they do, and quite nicely. We use them here (they're the only media
> > that has enough capacity and speed to be useful in our environment).
>
> What kind? Quantum, HP, or...
All are built by Quantum, who bought the tape and disk business from
Digital (DEC).
So, Sun, SGI, DEC, etc all just rebadge them.
Wilko
_ ____________________________________________________________________
| / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko
|/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try'
------------------ Support your local daemons: run FreeBSD Unix -----Yoda
From owner-freebsd-hackers Tue Oct 21 11:57:39 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA03286
for hackers-outgoing; Tue, 21 Oct 1997 11:57:39 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA03275
for <hackers@freebsd.org>; Tue, 21 Oct 1997 11:57:24 -0700 (PDT)
(envelope-from tlambert@usr04.primenet.com)
Received: (from daemon@localhost)
by smtp03.primenet.com (8.8.7/8.8.7) id LAA23766;
Tue, 21 Oct 1997 11:56:45 -0700 (MST)
Received: from usr04.primenet.com(206.165.6.204)
via SMTP by smtp03.primenet.com, id smtpd023751; Tue Oct 21 11:56:42 1997
Received: (from tlambert@localhost)
by usr04.primenet.com (8.8.5/8.8.5) id LAA13887;
Tue, 21 Oct 1997 11:56:41 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710211856.LAA13887@usr04.primenet.com>
Subject: Re: FreeBSD 3.0 kernel API ?!
To: darrenr@cyber.com.au (Darren Reed)
Date: Tue, 21 Oct 1997 18:56:40 +0000 (GMT)
Cc: tlambert@primenet.com, darrenr@cyber.com.au, hackers@freebsd.org
In-Reply-To: <199710210218.MAA11955@plum.cyber.com.au> from "Darren Reed" at Oct 21, 97 12:18:59 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> > If it's kernel code you are testing, you will need to include if_var.h
> > for it to run in the kernel; therefore you need to include if_var.h
> > for it to run in the test jig, which pretends to be the kernel.
>
> Well, you see, that's just it. It doesn't need anything else, only the
> "struct ifnet". I'd argue that a structure can be used and should be
> available anywhere, it just describes a way to store some values in
> memory. I have no problems with keeping variable names and function
> prototypes away from users (in different .h files or whatever), it
> even makes sense. But I don't think the same logic should be extended
> to structures. I assume things like struct proc and struct user are
> still available without defining KERNEL ?
Say I agree with you.
How will you deal with struct ifnet when we rename all the member
variables from their current names to "opaque_variable_01" through
"opaque_variable_NN"? Even if you can depend on the structure, you
can't reasonably expect the kernel internal interface to not change.
> > I think the issue is maybe that your test environment doesn't look
> > sufficiently like a kernel...
>
> No, it doesn't. Given that malloc(3) doesn't quite grok M_WAITOK,
> probably never will :-)
Setting aside for the moment that your test malloc whould grok M_NOWAIT,
and your code meant to run in the kernel should not be referencing the
malloc(3) function in the first place...
What exactly are you expecting to be able to test? Certainly, you
can't test any of the interfaces that implement struct ifnet type
derived parameters, and certainly you can't test race windows and spl
issues triggered by a malloc(..., M_NOWAIT) returning a failed (NULL)
allocation, etc..
I think your test case may be a bit contrived to justify your wanting
to access the internal structure. 8-|.
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 Oct 21 12:28:14 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id MAA04648
for hackers-outgoing; Tue, 21 Oct 1997 12:28:14 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA04502
for <hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 12:25:45 -0700 (PDT)
(envelope-from jhay@zibbi.mikom.csir.co.za)
Received: (from jhay@localhost)
by zibbi.mikom.csir.co.za (8.8.7/8.8.7) id VAA20535;
Tue, 21 Oct 1997 21:24:56 +0200 (SAT)
From: John Hay <jhay@mikom.csir.co.za>
Message-Id: <199710211924.VAA20535@zibbi.mikom.csir.co.za>
Subject: Re: FreeBSD 3.0 kernel API ?!
In-Reply-To: <199710211856.LAA13887@usr04.primenet.com> from Terry Lambert at "Oct 21, 97 06:56:40 pm"
To: tlambert@primenet.com (Terry Lambert)
Date: Tue, 21 Oct 1997 21:24:56 +0200 (SAT)
Cc: hackers@FreeBSD.ORG
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-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > > If it's kernel code you are testing, you will need to include if_var.h
> > > for it to run in the kernel; therefore you need to include if_var.h
> > > for it to run in the test jig, which pretends to be the kernel.
> >
> > Well, you see, that's just it. It doesn't need anything else, only the
> > "struct ifnet". I'd argue that a structure can be used and should be
> > available anywhere, it just describes a way to store some values in
> > memory. I have no problems with keeping variable names and function
> > prototypes away from users (in different .h files or whatever), it
> > even makes sense. But I don't think the same logic should be extended
> > to structures. I assume things like struct proc and struct user are
> > still available without defining KERNEL ?
>
>
> Say I agree with you.
>
> How will you deal with struct ifnet when we rename all the member
> variables from their current names to "opaque_variable_01" through
> "opaque_variable_NN"? Even if you can depend on the structure, you
> can't reasonably expect the kernel internal interface to not change.
Well, I'll ask that you also fix snmpd then and keep on fixing the
new versions. :-) Although it probably isn't a good example. The
snmpd code is already so full of #ifdef's a few hundred more will
probably not be noticed. :-)
John
--
John Hay -- John.Hay@mikom.csir.co.za
From owner-freebsd-hackers Tue Oct 21 13:17:15 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id NAA07415
for hackers-outgoing; Tue, 21 Oct 1997 13:17:15 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from charon.ccnvhi.com (wkstn.ccnvhi.com [207.247.3.162] (may be forged))
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA07408
for <freebsd-hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 13:17:13 -0700 (PDT)
(envelope-from pnorton@ccnvhi.com)
Received: by charon.ccnvhi.com; (5.65v3.2/1.3/10May95) id AA16670; Tue, 21 Oct 1997 12:12:57 -0700
Date: Tue, 21 Oct 1997 12:21:32 -0700
From: Paul Norton <pnorton@ccnvhi.com>
Subject: Re: DLT drives
In-Reply-To: <199710211857.TAA01003@yedi.iaf.nl>
To: Wilko Bulte <wilko@yedi.iaf.nl>
Cc: tom@sdf.com (Tom), karl@Mcs.Net, freebsd-hackers@FreeBSD.ORG
Message-Id: <199710211921.MAA00740@grumpy.ccnvhi.com>
Mime-Version: 1.0
X-Mailer: VM 6.22 under 19.15 XEmacs Lucid
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <Pine.BSF.3.95q.971020195244.8014E-100000@misery.sdf.com>
<"Tom"@Oct> <199710211857.TAA01003@yedi.iaf.nl>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Not so. Some load their own version of the DLT firmware.
Wilko Bulte writes:
> All are built by Quantum, who bought the tape and disk business from
> Digital (DEC).
>
> So, Sun, SGI, DEC, etc all just rebadge them.
>
> Wilko
> _ ____________________________________________________________________
> | / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko
> |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try'
> ------------------ Support your local daemons: run FreeBSD Unix -----Yoda
From owner-freebsd-hackers Tue Oct 21 14:33:43 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA11089
for hackers-outgoing; Tue, 21 Oct 1997 14:33:43 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from post.mail.demon.net (post-10.mail.demon.net [194.217.242.154])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA11073
for <freebsd-hackers@freebsd.org>; Tue, 21 Oct 1997 14:33:24 -0700 (PDT)
(envelope-from fhackers@jraynard.demon.co.uk)
Received: from jraynard.demon.co.uk ([158.152.42.77]) by post.mail.demon.net
id aa1000615; 21 Oct 97 22:20 BST
Received: (from fhackers@localhost)
by jraynard.demon.co.uk (8.8.7/8.8.7) id UAA07339;
Tue, 21 Oct 1997 20:54:09 +0100 (BST)
(envelope-from fhackers)
Message-ID: <19971021205409.64823@jraynard.demon.co.uk>
Date: Tue, 21 Oct 1997 20:54:09 +0100
From: James Raynard <fhackers@jraynard.demon.co.uk>
To: Stephen McKay <syssgm@dtir.qld.gov.au>
Cc: freebsd-hackers@freebsd.org
Subject: Old hardware
Reply-To: freebsd-chat@jraynard.demon.co.uk
References: <15920.877390482@time.cdrom.com> <199710210810.SAA12294@ogre.dtir.qld.gov.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.81e
In-Reply-To: <199710210810.SAA12294@ogre.dtir.qld.gov.au>; from Stephen McKay on Tue, Oct 21, 1997 at 06:10:13PM +1000
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
[reply-to set to chat]
On Tue, Oct 21, 1997 at 06:10:13PM +1000, Stephen McKay wrote:
> On Monday, 20th October 1997, "Jordan K. Hubbard" wrote:
>
> >maybe we should make our release-a-day server a 486SX with 8MB of
> >memory and switch it to being a release-a-week server instead.
> >We'd not have as useful a service by far, but it sure would catch
> >those load sensitive bugs early. :-)
I've always believed that developers should have the fastest possible
machines and testers should have the slowest known to mankind...
> I used to have a 386sx16 with 4Mb ram
> and 13.5 Mb of swap.
>
> Unfortunately, it took sick and died. :-(
I have an advert in front of me for an identical machine - (UKP85 or
about US$150 for the complete system, half that for a headless system
unit). Advertised as "ideal for keeping the kids off your PC!"
> I've always been fascinated by those bald blokes that whip themselves
> in the name of religious purification. They don't joke either.
"Oh system, who art great and mighty, do not crash upon us in our hour
of need, we beseech thee. For nothing can be done except at thy
command prompt"
<slap>
"Give us this day our daily uptime"
<slap>
"Forgive us our flamewars, as we forgive those who advocate against us"
<slap>
"And lead us not unto Linux, but deliver us from Windows"
<slap vigorously>
--
James Raynard, Edinburgh, Scotland.
james@jraynard.demon.co.uk
http://www.freebsd.org/~jraynard/
From owner-freebsd-hackers Tue Oct 21 15:11:22 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA13113
for hackers-outgoing; Tue, 21 Oct 1997 15:11:22 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA13107
for <freebsd-hackers@freebsd.org>; Tue, 21 Oct 1997 15:11:16 -0700 (PDT)
(envelope-from se@X14.MI.Uni-Koeln.DE)
Received: from x14.mi.uni-koeln.de ([134.95.219.124])
by Octopussy.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id AAA27759;
Wed, 22 Oct 1997 00:10:18 +0200 (MET DST)
Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id AAA01009; Wed, 22 Oct 1997 00:10:22 +0200 (CEST)
X-Face: "<d]#=8pzx);RzeqSKI86OVa7=!0/(uRa.+B.9Z9\eNUn@UG?!`y7yt2dFNn%k4'.}](uE%
yCO)$e&Y1%3EO~ifu6Q-#YUM&JZ't,}JkPnAz,8Dj33u%@GBi%[Y#LHz$]h7a<p4)-jKI7~sKjlP-^
EvA[G;]v&0]W!EL%shs,{7x0|oqN4YVIs5,NI#,V{9"WF):5&RkOhyj*#-IAG}Tnu;YCF,d
Message-ID: <19971022001022.62653@mi.uni-koeln.de>
Date: Wed, 22 Oct 1997 00:10:22 +0200
From: Stefan Esser <se@FreeBSD.ORG>
To: Joe McGuckin <joe@via.net>
Cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage
References: <199710202206.PAA17351@monk.via.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84
In-Reply-To: <199710202206.PAA17351@monk.via.net>; from Joe McGuckin on Mon, Oct 20, 1997 at 03:06:28PM -0700
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On 1997-10-20 15:06 -0700, Joe McGuckin <joe@via.net> wrote:
>
>
> (ncr0:0:0): "QUANTUM XP32275W LXY4" type 0 fixed SCSI 2
> sd0(ncr0:0:0): Direct-Access
> sd0(ncr0:0:0): WIDE SCSI (16 bit) enabled
> sd0(ncr0:0:0): 20.0 MB/s (100 ns, offset 16)
>
>
> Shouldn't this report back 40.0 MB/s for fast wide ultra ?
Yes it should, if it supported UW ...
But 2.2.2 doesn't and never will (it is history).
2.2-stable does for some time, and 2.2.5 will.
So just update your sources to 2.2-stable or wait
for the next release ...
Regards, STefan
From owner-freebsd-hackers Tue Oct 21 15:13:40 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA13351
for hackers-outgoing; Tue, 21 Oct 1997 15:13:40 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA13337
for <freebsd-hackers@freebsd.org>; Tue, 21 Oct 1997 15:13:32 -0700 (PDT)
(envelope-from se@X14.MI.Uni-Koeln.DE)
Received: from x14.mi.uni-koeln.de ([134.95.219.124])
by Octopussy.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id AAA27789;
Wed, 22 Oct 1997 00:13:21 +0200 (MET DST)
Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id AAA01028; Wed, 22 Oct 1997 00:13:26 +0200 (CEST)
X-Face: "<d]#=8pzx);RzeqSKI86OVa7=!0/(uRa.+B.9Z9\eNUn@UG?!`y7yt2dFNn%k4'.}](uE%
yCO)$e&Y1%3EO~ifu6Q-#YUM&JZ't,}JkPnAz,8Dj33u%@GBi%[Y#LHz$]h7a<p4)-jKI7~sKjlP-^
EvA[G;]v&0]W!EL%shs,{7x0|oqN4YVIs5,NI#,V{9"WF):5&RkOhyj*#-IAG}Tnu;YCF,d
Message-ID: <19971022001326.62136@mi.uni-koeln.de>
Date: Wed, 22 Oct 1997 00:13:26 +0200
From: Stefan Esser <se@FreeBSD.ORG>
To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
Cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage
References: <joe@via.net> <199710210124.UAA14405@nospam.hiwaay.net> <19971021081759.TH50130@uriah.heep.sax.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84
In-Reply-To: <19971021081759.TH50130@uriah.heep.sax.de>; from J Wunsch on Tue, Oct 21, 1997 at 08:17:59AM +0200
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On 1997-10-21 08:17 +0200, J Wunsch <j@uriah.heep.sax.de> wrote:
> As dkelly@hiwaay.net wrote:
>
> > > sd0(ncr0:0:0): WIDE SCSI (16 bit) enabled
> > > sd0(ncr0:0:0): 20.0 MB/s (100 ns, offset 16)
> > >
> > >
> > > Shouldn't this report back 40.0 MB/s for fast wide ultra ?
> >
> > Probably should.
>
> Probably should not. It should read as ``20 MHz'', this makes no
> promises about the actual speed.
Yes, I've been thinking so for quite some time, to.
But I changed the message to report MB/s, anyway, on
popular demand :)
If 40MB/s is reported, you still won't be able to get
more than some 37MB/s moved, actually, but well, it is
the number claimed by the drive and controller vendors,
and so it can't be wrong to report it :)
Regards, STefan
From owner-freebsd-hackers Tue Oct 21 15:23:25 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA13855
for hackers-outgoing; Tue, 21 Oct 1997 15:23:25 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA13826
for <freebsd-hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 15:23:15 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA23006 for freebsd-hackers@FreeBSD.ORG; Wed, 22 Oct 1997 00:23:14 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id AAA18786;
Wed, 22 Oct 1997 00:18:54 +0200 (MET DST)
Message-ID: <19971022001854.DS19056@uriah.heep.sax.de>
Date: Wed, 22 Oct 1997 00:18:54 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: freebsd-hackers@FreeBSD.ORG
Subject: Re: DLT drives
References: <Pine.BSF.3.95q.971020195244.8014E-100000@misery.sdf.com> <"Tom"@Oct> <199710211857.TAA01003@yedi.iaf.nl> <199710211921.MAA00740@grumpy.ccnvhi.com>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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: <199710211921.MAA00740@grumpy.ccnvhi.com>; from Paul Norton on Oct 21, 1997 12:21:32 -0700
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Paul Norton wrote:
> > So, Sun, SGI, DEC, etc all just rebadge them.
> Not so. Some load their own version of the DLT firmware.
Their own versions, or just their own vendor string only? I'd rather
assume the latter. The little brother of the NIH syndrome...
--
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 Oct 21 15:23:38 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA13893
for hackers-outgoing; Tue, 21 Oct 1997 15:23:38 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA13887
for <freebsd-hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 15:23:34 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA23008 for freebsd-hackers@FreeBSD.ORG; Wed, 22 Oct 1997 00:23:29 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id AAA18609;
Wed, 22 Oct 1997 00:03:18 +0200 (MET DST)
Message-ID: <19971022000318.WS35693@uriah.heep.sax.de>
Date: Wed, 22 Oct 1997 00:03:18 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: freebsd-hackers@FreeBSD.ORG
Subject: Re: Urge to apply the vn device hack even to 2.2.5
References: <15920.877390482@time.cdrom.com> <199710210810.SAA12294@ogre.dtir.qld.gov.au>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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: <199710210810.SAA12294@ogre.dtir.qld.gov.au>; from Stephen McKay on Oct 21, 1997 18:10:13 +1000
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Stephen McKay wrote:
> Hey, I used to do this for ya! I used to have a 386sx16 with 4Mb ram
> and 13.5 Mb of swap. Yes, every byte of swap counted! It didn't have
> enough disk to store anything, so /usr/src and /usr/obj were NFS. It
> used to take around 10 days to crank out a make world.
Don't use a blatant `make world' on such a slow machine. You could
perhaps cut it in five days by doing the steps manually. :)
That is, make -k and install the libs, make -k and install the rest,
then make the rest again, look where it still falls over, and resolve
any bootstrapping conflicts. I usually do it this way even on much
faster machines. I'm using `make world' only for hardware tests. ;-)
--
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 Oct 21 16:41:22 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id QAA18386
for hackers-outgoing; Tue, 21 Oct 1997 16:41:22 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from cynic.portal.ca (root@cynic.portal.ca [204.174.36.7])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA18373
for <hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 16:41:14 -0700 (PDT)
(envelope-from cjs@portal.ca)
Received: from localhost ([[UNIX: localhost]])
by cynic.portal.ca (8.8.5/8.8.5) with SMTP id QAA02947;
Tue, 21 Oct 1997 16:40:27 -0700 (PDT)
X-Authentication-Warning: cynic.portal.ca: cjs owned process doing -bs
Date: Tue, 21 Oct 1997 16:40:27 -0700 (PDT)
From: Curt Sampson <cjs@portal.ca>
Reply-To: Curt Sampson <cjs@portal.ca>
To: "Alexander B. Povolotsky" <tarkhil@mgt.msk.ru>
cc: hackers@FreeBSD.ORG, netbsd-users@netbsd.org
Subject: Re: on ccd and large disk array
In-Reply-To: <199710211052.OAA12808@asteroid.mgt.msk.ru>
Message-ID: <Pine.NEB.3.96.971021153240.25356J-100000@cynic.portal.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Tue, 21 Oct 1997, Alexander B. Povolotsky wrote:
> We're making a (relatively) large disk array using ccd: 5 Micropolis HDDs,
> 8.7 Gb each, i.e. about 40 Gb total.
>
> Does anyone know possible traps on our way? Is FFS as-is stable on 40 Gb
> filesystems? What may we need to patch?
I can't see any reason why a little one like that would be a problem. :-)
If you wanted to do a slightly larger one, you might follow the
lead of NASA Ames Research Laboratory. Take a couple of racks of
9 x 9 GB drives and put a hardware RAID-5 across them, for about
150 GB of storage:
sd9: 156260MB, 12594 cyl, 64 head, 141 sec, 512 bytes/sect x 320020992 sectors
Then take 4 of those and put a ccd across it, and put FFS on that:
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ccd0a 637453560 8 605580872 0% /mnt
That gives you a little over 600 GB on a single FFS. Of course,
that's probably not enough storage, so you want to have a couple
of those to bring it over a terrabite.
This is NetBSD running on a smallish AlphaServer 8400 (only 2 GB
RAM, 72 PCI slots [on 19 buses], one or two 800 MB HPPI buses).
There's four more with similar amounts of storage kicking around
the lab, too.
(If you FreeBSD guys ever feel like upgrading that little FTP
server of yours you have over at Walnut Creek, feel free to give
us a call. :-))
cjs
Curt Sampson cjs@portal.ca Info at http://www.portal.ca/
Internet Portal Services, Inc. Through infinite myst, software reverberates
Vancouver, BC (604) 257-9400 In code possess'd of invisible folly.
From owner-freebsd-hackers Tue Oct 21 16:48:01 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id QAA18760
for hackers-outgoing; Tue, 21 Oct 1997 16:48:01 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA18733;
Tue, 21 Oct 1997 16:47:45 -0700 (PDT)
(envelope-from gdonl@tsc.tdk.com)
Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191])
by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP
id QAA05116; Tue, 21 Oct 1997 16:47:44 -0700 (PDT)
Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194])
by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id QAA18441;
Tue, 21 Oct 1997 16:47:43 -0700 (PDT)
Received: (from gdonl@localhost)
by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id QAA09208;
Tue, 21 Oct 1997 16:47:42 -0700 (PDT)
From: Don Lewis <Don.Lewis@tsc.tdk.com>
Message-Id: <199710212347.QAA09208@salsa.gv.tsc.tdk.com>
Date: Tue, 21 Oct 1997 16:47:42 -0700
In-Reply-To: Stefan Esser <se@FreeBSD.ORG>
"Re: 2.2.2-RELEASE '875 SCSI won't negotiage" (Oct 22, 12:13am)
X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95)
To: Stefan Esser <se@FreeBSD.ORG>,
Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage
Cc: freebsd-hackers@FreeBSD.ORG
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Oct 22, 12:13am, Stefan Esser wrote:
} Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage
} On 1997-10-21 08:17 +0200, J Wunsch <j@uriah.heep.sax.de> wrote:
} > As dkelly@hiwaay.net wrote:
} >
} > > > sd0(ncr0:0:0): WIDE SCSI (16 bit) enabled
} > > > sd0(ncr0:0:0): 20.0 MB/s (100 ns, offset 16)
} > Probably should not. It should read as ``20 MHz'', this makes no
} > promises about the actual speed.
}
} Yes, I've been thinking so for quite some time, to.
} But I changed the message to report MB/s, anyway, on
} popular demand :)
}
} If 40MB/s is reported, you still won't be able to get
} more than some 37MB/s moved, actually, but well, it is
} the number claimed by the drive and controller vendors,
} and so it can't be wrong to report it :)
But isn't this misleading if it's only connected to narrow devices?
From owner-freebsd-hackers Tue Oct 21 17:20:59 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id RAA20836
for hackers-outgoing; Tue, 21 Oct 1997 17:20:59 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA20831
for <freebsd-hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 17:20:55 -0700 (PDT)
(envelope-from dkelly@nospam.hiwaay.net)
Received: from nospam.hiwaay.net (max4-120.HiWAAY.net [208.147.145.120])
by fly.HiWAAY.net (8.8.7/8.8.6) with ESMTP id TAA20787
for <freebsd-hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 19:20:47 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP
id TAA18051 for <freebsd-hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 19:09:47 -0500 (CDT)
Message-Id: <199710220009.TAA18051@nospam.hiwaay.net>
X-Mailer: exmh version 2.0zeta 7/24/97
To: freebsd-hackers@FreeBSD.ORG
From: dkelly@hiwaay.net
Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage
In-reply-to: Message from j@uriah.heep.sax.de (J Wunsch)
of "Tue, 21 Oct 1997 08:17:59 +0200." <19971021081759.TH50130@uriah.heep.sax.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 21 Oct 1997 19:09:47 -0500
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Joerg Wunsch replies:
>
> As dkelly@hiwaay.net wrote:
>
> > > sd0(ncr0:0:0): WIDE SCSI (16 bit) enabled
> > > sd0(ncr0:0:0): 20.0 MB/s (100 ns, offset 16)
> > >
> > >
> > > Shouldn't this report back 40.0 MB/s for fast wide ultra ?
> >
> > Probably should.
>
> Probably should not. It should read as ``20 MHz'', this makes no
> promises about the actual speed.
Poor choice of words on my part. The ncr driver is calling things exactly
right. Went back and RTFM'ed my Asus SC875 manual and obsverved on page 11
the default Synchronous Transfer Rate (MS/Sec) (sic) is 20. So is this MB/
sec or MHz? Time to reboot and see what numbers I can enter in the BIOS.
--
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 Tue Oct 21 17:23:36 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id RAA21009
for hackers-outgoing; Tue, 21 Oct 1997 17:23:36 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from stox.sa.enteract.com (stox.sa.enteract.com [207.229.132.161])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA21002
for <freebsd-hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 17:23:32 -0700 (PDT)
(envelope-from ken@stox.sa.enteract.com)
Received: from localhost (localhost.stox.sa.enteract.com [127.0.0.1]) by stox.sa.enteract.com (8.8.7/8.6.12) with SMTP id TAA10158; Tue, 21 Oct 1997 19:22:43 -0500 (CDT)
Date: Tue, 21 Oct 1997 19:22:40 -0500 (CDT)
From: "Kenneth P. Stox" <ken@stox.sa.enteract.com>
Reply-To: stox@enteract.com
To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: DLT drives
In-Reply-To: <19971022001854.DS19056@uriah.heep.sax.de>
Message-ID: <Pine.BSF.3.96.971021191408.28032A-100000@stox.sa.enteract.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Wed, 22 Oct 1997, J Wunsch wrote:
>> > So, Sun, SGI, DEC, etc all just rebadge them.
>
>> Not so. Some load their own version of the DLT firmware.
>
>Their own versions, or just their own vendor string only? I'd rather
>assume the latter. The little brother of the NIH syndrome...
Well, I can speak from experience that the DEC, Quantum, and SGI
versions are different. Whether they are actually different, or that
each vendor has chosen different loads from the same code base is a good
question. There have been many different loads of firmware since Digital
first introduced them, and Quantum took over. Of course, if one has
access to them, one may load SGI firware on a Quantum drive, etc.
-Ken Stox
"If you work with Petabytes, does that make you a Petaphile ?"
stox@enteract.com
From owner-freebsd-hackers Tue Oct 21 19:03:31 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA26043
for hackers-outgoing; Tue, 21 Oct 1997 19:03:31 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA26037
for <hackers@freebsd.org>; Tue, 21 Oct 1997 19:03:25 -0700 (PDT)
(envelope-from darrenr@cyber.com.au)
Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id MAA01643; Wed, 22 Oct 1997 12:02:37 +1000
From: Darren Reed <darrenr@cyber.com.au>
Message-Id: <199710220202.MAA01643@plum.cyber.com.au>
Subject: Re: FreeBSD 3.0 kernel API ?!
To: tlambert@primenet.com (Terry Lambert)
Date: Wed, 22 Oct 1997 12:02:36 +1000 (EST)
Cc: hackers@freebsd.org
In-Reply-To: <199710211856.LAA13887@usr04.primenet.com> from "Terry Lambert" at Oct 21, 97 06:56:40 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
In some mail I received from Terry Lambert, sie wrote
>
> > > If it's kernel code you are testing, you will need to include if_var.h
> > > for it to run in the kernel; therefore you need to include if_var.h
> > > for it to run in the test jig, which pretends to be the kernel.
> >
> > Well, you see, that's just it. It doesn't need anything else, only the
> > "struct ifnet". I'd argue that a structure can be used and should be
> > available anywhere, it just describes a way to store some values in
> > memory. I have no problems with keeping variable names and function
> > prototypes away from users (in different .h files or whatever), it
> > even makes sense. But I don't think the same logic should be extended
> > to structures. I assume things like struct proc and struct user are
> > still available without defining KERNEL ?
>
> Say I agree with you.
>
> How will you deal with struct ifnet when we rename all the member
> variables from their current names to "opaque_variable_01" through
> "opaque_variable_NN"? Even if you can depend on the structure, you
> can't reasonably expect the kernel internal interface to not change.
This sort of change I think is, to put it bluntly, fucked. (I'm
probably putting a lot of people who `control' freebsd offside here).
I'd heartily recommend spending time on something worthwhile rather
than going around making life more difficult for people that.
It's a change for the sake of a change with no reasonable reason to
happen. To recite an old adage: if it's not broken, don't fix it.
Things weren't broken.
> I think your test case may be a bit contrived to justify your wanting
> to access the internal structure. 8-|.
Well, at least if I implement a fake list of interfaces using other code,
I can still look them up, etc.
blah, time to giveup on FreeBSD and use Linux I think...at least Linus
doesn't allow silly changes that achieve nothing and just cause more
work.
Darren
From owner-freebsd-hackers Tue Oct 21 19:14:38 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA26593
for hackers-outgoing; Tue, 21 Oct 1997 19:14:38 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA26575
for <hackers@freebsd.org>; Tue, 21 Oct 1997 19:14:25 -0700 (PDT)
(envelope-from darrenr@cyber.com.au)
Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id MAA01798 for hackers@freebsd.org; Wed, 22 Oct 1997 12:14:23 +1000
Received: from satay.cyber.com.au (satay.cyber.com.au [203.7.155.20]) by plum.cyber.com.au (8.6.12/8.6.6) with ESMTP id GAA29580 for <darrenr@cyber.com.au>; Sat, 18 Oct 1997 06:17:55 +1000
Received: (from uucp@localhost) by satay.cyber.com.au (8.7.4/8.7.3) id GAA18029 for <darrenr@cyber.com.au>; Sat, 18 Oct 1997 06:14:40 +1000 (EST)
Received: from homeworld.cygnus.com(205.180.83.70) by satay.cyber.com.au via smap (V1.3)
id sma018025; Sat Oct 18 06:14:22 1997
Received: (qmail 5136 invoked by uid 1110); 17 Oct 1997 10:45:20 -0000
Delivered-To: darrenr@netbsd.org
Received: (qmail 4659 invoked by uid 605); 17 Oct 1997 10:43:25 -0000
Received: (qmail 4619 invoked by alias); 17 Oct 1997 10:43:12 -0000
Delivered-To: developers@netbsd.org
Received: (qmail 4605 invoked from network); 17 Oct 1997 10:43:10 -0000
Received: from kechara.flame.org (192.80.44.209)
by homeworld.cygnus.com with SMTP; 17 Oct 1997 10:43:10 -0000
Received: (qmail 11041 invoked by uid 173); 17 Oct 1997 10:42:13 -0000
Date: 17 Oct 1997 10:42:13 -0000
Message-ID: <19971017104213.11040.qmail@kechara.flame.org>
From: explorer@flame.org
To: developers@NetBSD.ORG
Subject: Possible SERIOUS bug in open()?
Delivered-To: netbsd-developers@NetBSD.ORG
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
This was sent to me recently... It seems to be a pretty serious hole
in open() and permissions...
Note, in the following, open() succeeds, and ioctls are probably
executed...
/*
* This will give you a file descriptor on a device you should not have
* access to. This seems really, really screwed up, since holding a fd
* lets you do a lot of ioctls that you should not be able to do...
*/
#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>
#include <err.h>
int
main(int argc, char **argv)
{
int fd;
fd = open("/dev/rsd0a", -1, 0);
if (fd < 0)
err(1, "open");
}
From owner-freebsd-hackers Tue Oct 21 19:30:34 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA27547
for hackers-outgoing; Tue, 21 Oct 1997 19:30:34 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA27542
for <hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 19:30:31 -0700 (PDT)
(envelope-from durian@plutotech.com)
Received: from shane.plutotech.com (shane.plutotech.com [206.168.67.149])
by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id UAA15838;
Tue, 21 Oct 1997 20:30:28 -0600 (MDT)
Message-Id: <199710220230.UAA15838@pluto.plutotech.com>
From: "Mike Durian" <durian@plutotech.com>
To: "Mike Durian" <durian@plutotech.com>
cc: hackers@FreeBSD.ORG
Subject: Re: user vm addr to kernel vm addr
In-reply-to: Your message of "Mon, 20 Oct 1997 20:01:11 MDT."
Date: Tue, 21 Oct 1997 20:30:28 -0600
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Mon, 20 Oct 1997 20:01:11 MDT, "Mike Durian" <durian@plutotech.com> wrote:
> In my virtual file system I'd like to speed up reads and writes
>by copying directly from the uio structure to a vm address of
>a buffer in the user process running on behalf of the filesystem.
>I'm currently shoving all the data through a socket that the
>user process reads from and copies into a buffer. I'd like to
>go direct and skip the socket writing part. Does that make sense?
> Anyway, I want to copy from a uio to a different process's vm space.
>I can get the vm address of the destination buffer over a socket and
>think I can use vm_fault_wire to make sure it stays accessable, but
>I don't know how to convert that user space vm address into a
>kernel space vm address that I can then use with copyout.
> Is there an easy (or any) way to do this?
I'm following up to my own post. I should mention that the
user process containing the vm buffer that I want to convert is
*not* curproc. I want to go between that buffer and a struct uio
in my VOP_READ and VOP_WRITE functions.
I did find something that works, but perhaps someone has a
better/cleaner way of doing it. I don't think I need to do
the vm_fault_wire either.
for each page in the vm buffer
vm_map_lookup to get the vm object
vm_page_lookup to get the page for the object
kmem_alloc_pageable to allocate kernel vm space
pmap_qenter to map the pages into the kernel vm address
uiomove copy from the new kernel address to uio
pmap_qremove to unmap the pages
kmem_free to release the kernel vm space
mike
From owner-freebsd-hackers Tue Oct 21 19:56:10 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA29029
for hackers-outgoing; Tue, 21 Oct 1997 19:56:10 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.235])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA28931
for <freebsd-hackers@freebsd.org>; Tue, 21 Oct 1997 19:55:44 -0700 (PDT)
(envelope-from koshy@india.hp.com)
Received: from postbox.india.hp.com (postbox.india.hp.com [15.10.45.1])
by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id TAA06692
for <freebsd-hackers@freebsd.org>; Tue, 21 Oct 1997 19:55:33 -0700 (PDT)
Message-Id: <199710220255.TAA06692@palrel1.hp.com>
Received: from localhost by postbox.india.hp.com with ESMTP
(1.39.111.2/16.2) id AA095678614; Wed, 22 Oct 1997 08:20:14 +0530
To: freebsd-hackers@freebsd.org
Subject: "UNIX An OS for the people"
Date: Wed, 22 Oct 1997 08:20:13 +0530
From: A Joseph Koshy <koshy@india.hp.com>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Press coverage on BSD (i.e. BSDI) and Linux. No mention of FreeBSD :-(.
http://www.wcmh.com/lantimes/97/97oct/710b061a.html
Koshy
<koshy@india.hp.com> My Personal Opinions Only.
From owner-freebsd-hackers Tue Oct 21 19:59:37 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA29196
for hackers-outgoing; Tue, 21 Oct 1997 19:59:37 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA29191
for <freebsd-hackers@freebsd.org>; Tue, 21 Oct 1997 19:59:34 -0700 (PDT)
(envelope-from dcarmich@Mars.mcs.net)
Received: from Mars.mcs.net (dcarmich@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id VAA27429 for <freebsd-hackers@freebsd.org>; Tue, 21 Oct 1997 21:59:33 -0500 (CDT)
Received: (from dcarmich@localhost) by Mars.mcs.net (8.8.7/8.8.2) id VAA20051 for freebsd-hackers@freebsd.org; Tue, 21 Oct 1997 21:59:33 -0500 (CDT)
From: Douglas Carmichael <dcarmich@Mcs.Net>
Message-Id: <199710220259.VAA20051@Mars.mcs.net>
Subject: Hardware RAID-x controllers for FreeBSD?
To: freebsd-hackers@freebsd.org
Date: Tue, 21 Oct 1997 21:59:33 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Do any you know of any hardware RAID-x controllers (x = >1, preferably 5)
that work with FreeBSD and either:
1) Have a native driver in FreeBSD for them
or 2) Appear as just another big disk
From owner-freebsd-hackers Tue Oct 21 20:24:49 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id UAA00882
for hackers-outgoing; Tue, 21 Oct 1997 20:24:49 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from time.cdrom.com (time.cdrom.com [204.216.27.226])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA00873
for <hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 20:24:41 -0700 (PDT)
(envelope-from jkh@time.cdrom.com)
Received: from time.cdrom.com (localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id UAA16063; Tue, 21 Oct 1997 20:23:04 -0700 (PDT)
To: Darren Reed <darrenr@cyber.com.au>
cc: tlambert@primenet.com (Terry Lambert), hackers@FreeBSD.ORG
Subject: Re: FreeBSD 3.0 kernel API ?!
In-reply-to: Your message of "Wed, 22 Oct 1997 12:02:36 +1000."
<199710220202.MAA01643@plum.cyber.com.au>
Date: Tue, 21 Oct 1997 20:23:03 -0700
Message-ID: <16059.877490583@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> blah, time to giveup on FreeBSD and use Linux I think...at least Linus
> doesn't allow silly changes that achieve nothing and just cause more
> work.
I think it's more likely time to stop bitching about things which
don't and never did merit such a degree of vitriol or personal
attachment. I suspect that you, like us, have better things to do
with your life than quibble over minutiae like this in the header
files and I strongly suggest that you simply get back to it rather
than continue to draw out what started as a pointless debate and has
only declined from there.
Jordan
From owner-freebsd-hackers Tue Oct 21 20:34:24 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id UAA01345
for hackers-outgoing; Tue, 21 Oct 1997 20:34:24 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from kithrup.com (kithrup.com [205.179.156.40])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA01339
for <hackers@freebsd.org>; Tue, 21 Oct 1997 20:34:22 -0700 (PDT)
(envelope-from sef@Kithrup.COM)
Received: (from sef@localhost) by kithrup.com (8.8.5/8.6.6) id UAA23820; Tue, 21 Oct 1997 20:34:20 -0700 (PDT)
Date: Tue, 21 Oct 1997 20:34:20 -0700 (PDT)
From: Sean Eric Fagan <sef@Kithrup.COM>
Message-Id: <199710220334.UAA23820@kithrup.com>
To: hackers@freebsd.org
Reply-To: hackers@freebsd.org
Subject: Re: FreeBSD 3.0 kernel API ?!
In-Reply-To: <199710220202.MAA01643.kithrup.freebsd.hackers@plum.cyber.com.au>
References: <199710211856.LAA13887@usr04.primenet.com> from "Terry Lambert" at Oct 21, 97 06:56:40 pm
Organization: Kithrup Enterprises, Ltd.
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
>> How will you deal with struct ifnet when we rename all the member
>> variables from their current names to "opaque_variable_01" through
>> "opaque_variable_NN"? Even if you can depend on the structure, you
>> can't reasonably expect the kernel internal interface to not change.
>This sort of change I think is, to put it bluntly, fucked.
Terry's problem is that he is forgetting that non-kernel bits are part of
the OS in unix.
This means that some non-kernel bits have to know the format (and location)
of some kernel data structures, sometimes. (While there are many cases
where you can abstract this into a usable API, there are many other cases
where you can't -- because what you want to get at is, indeed, exactly what
the kernel is using.)
This is further complicated by the fact that some utilities people have
decided are part of the OS are not maintained by us.
Ah, well.
Reply to me, or the list, but not both, please.
From owner-freebsd-hackers Tue Oct 21 20:37:32 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id UAA01522
for hackers-outgoing; Tue, 21 Oct 1997 20:37:32 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from phoenix.its.rpi.edu (phoenix.its.rpi.edu [128.113.161.45])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA01517
for <freebsd-hackers@freebsd.org>; Tue, 21 Oct 1997 20:37:30 -0700 (PDT)
(envelope-from dec@phoenix.its.rpi.edu)
Received: from localhost (dec@localhost)
by phoenix.its.rpi.edu (8.8.7/8.8.7) with SMTP id XAA08592
for <freebsd-hackers@freebsd.org>; Tue, 21 Oct 1997 23:38:21 -0400 (EDT)
Date: Tue, 21 Oct 1997 23:38:21 -0400 (EDT)
From: "David E. Cross" <dec@phoenix.its.rpi.edu>
To: freebsd-hackers@freebsd.org
Subject: Where's the beef^Wcdrom image?
Message-ID: <Pine.BSF.3.96.971021233651.8568A-100000@phoenix.its.rpi.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I thought that we/you (whatever) would be distributing a CDROM image of
the new RELEASEs? If this is true, could someone point me at it?
--
David Cross
ACS Consultant
From owner-freebsd-hackers Tue Oct 21 20:55:00 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id UAA02432
for hackers-outgoing; Tue, 21 Oct 1997 20:55:00 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id UAA02426
for <hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 20:54:56 -0700 (PDT)
(envelope-from darrenr@cyber.com.au)
Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id NAA03087; Wed, 22 Oct 1997 13:54:02 +1000
From: Darren Reed <darrenr@cyber.com.au>
Message-Id: <199710220354.NAA03087@plum.cyber.com.au>
Subject: Re: FreeBSD 3.0 kernel API ?!
To: jkh@time.cdrom.com (Jordan K. Hubbard)
Date: Wed, 22 Oct 1997 13:54:01 +1000 (EST)
Cc: tlambert@primenet.com, hackers@FreeBSD.ORG
In-Reply-To: <16059.877490583@time.cdrom.com> from "Jordan K. Hubbard" at Oct 21, 97 08:23:03 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
In some mail I received from Jordan K. Hubbard, sie wrote
>
> > blah, time to giveup on FreeBSD and use Linux I think...at least Linus
> > doesn't allow silly changes that achieve nothing and just cause more
> > work.
>
> I think it's more likely time to stop bitching about things which
> don't and never did merit such a degree of vitriol or personal
> attachment. I suspect that you, like us, have better things to do
> with your life than quibble over minutiae like this in the header
> files and I strongly suggest that you simply get back to it rather
> than continue to draw out what started as a pointless debate and has
> only declined from there.
Couldn't agree more. I've wondered a few times, how much time I've
wasted on this thread compared with how long it would have taken me
to accomodate this change in FreeBSD...
Darren
From owner-freebsd-hackers Tue Oct 21 21:20:13 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id VAA03628
for hackers-outgoing; Tue, 21 Oct 1997 21:20:13 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA03538
for <freebsd-hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 21:19:02 -0700 (PDT)
(envelope-from jamil@trojanhorse.ml.org)
Received: from localhost (jamil@localhost)
by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id VAA01050;
Tue, 21 Oct 1997 21:16:04 -0700 (PDT)
Date: Tue, 21 Oct 1997 21:16:03 -0700 (PDT)
From: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
To: Douglas Carmichael <dcarmich@Mcs.Net>
cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: Hardware RAID-x controllers for FreeBSD?
In-Reply-To: <199710220259.VAA20051@Mars.mcs.net>
Message-ID: <Pine.BSF.3.96.971021211536.859A-100000@trojanhorse.ml.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
I think adaptec have some that just look like a 2940, I saw one for about
$800.
On Tue, 21 Oct 1997, Douglas Carmichael wrote:
> Do any you know of any hardware RAID-x controllers (x = >1, preferably 5)
> that work with FreeBSD and either:
> 1) Have a native driver in FreeBSD for them
> or 2) Appear as just another big disk
>
>
From owner-freebsd-hackers Tue Oct 21 22:00:41 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id WAA05642
for hackers-outgoing; Tue, 21 Oct 1997 22:00:41 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from cs4.cs.ait.ac.th (root@cs4.cs.ait.ac.th [192.41.170.15])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA05637
for <hackers@freebsd.org>; Tue, 21 Oct 1997 22:00:30 -0700 (PDT)
(envelope-from a96456@cs.ait.ac.th)
Received: from bazooka.cs.ait.ac.th (a96456@bazooka.cs.ait.ac.th [192.41.170.2]) by cs4.cs.ait.ac.th (8.6.12/) with ESMTP
id LAA05692 for <hackers@freebsd.org>; Wed, 22 Oct 1997 11:48:56 +0700
Received: from localhost (a96456@localhost)
by bazooka.cs.ait.ac.th (8.8.5/8.8.5) with SMTP id LAA19938
for <hackers@freebsd.org>; Wed, 22 Oct 1997 11:48:50 +0700 (GMT)
X-Authentication-Warning: bazooka.cs.ait.ac.th: a96456 owned process doing -bs
Date: Wed, 22 Oct 1997 11:48:49 +0700 (GMT)
From: Sunthiti Patchararungruang <a96456@cs.ait.ac.th>
To: hackers@freebsd.org
Subject: Problem with FreeBSD2.2.2
Message-ID: <Pine.GSO.3.94.971022114014.19833A-100000@bazooka.cs.ait.ac.th>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Dear Everyboy
I have a computer with FreeBSD2.2.2. I have a problem about system
resource. When I login as a normal user up to 4 session, I cannot use
"man" command. It always report that "cannot fork" and "resource is
temporary unavailable". However, the problem does not occur when I login
as root. I think the problem is come from the swap space. Maybe normal
user cannot use it because all swap space is empty, checked by
"swapinfo". However, I don't know how to solve it. Please help me.
My system has 12MB RAM, 120MB HD for system, 70MB for swap. I
compiled the kernel with "users 40". Finally, the following is the data in
"/etc/fstab".
# Device Mountpoint FStype Options Dump Pass#
/dev/wd0s2b none swap sw 0 0
/dev/wd0a / ufs rw 1 1
proc /proc procfs rw 0 0
Sincerely Yours,
Sunthiti Patchararungraung
From owner-freebsd-hackers Tue Oct 21 23:02:10 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id XAA08110
for hackers-outgoing; Tue, 21 Oct 1997 23:02:10 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from misery.sdf.com (misery.sdf.com [204.244.210.193])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA08096
for <freebsd-hackers@freebsd.org>; Tue, 21 Oct 1997 23:02:07 -0700 (PDT)
(envelope-from tom@sdf.com)
Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1)
id 0xNtqH-00036Z-00; Tue, 21 Oct 1997 23:00:29 -0700
Date: Tue, 21 Oct 1997 23:00:27 -0700 (PDT)
From: Tom <tom@sdf.com>
To: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
cc: Douglas Carmichael <dcarmich@Mcs.Net>, freebsd-hackers@freebsd.org
Subject: Re: Hardware RAID-x controllers for FreeBSD?
In-Reply-To: <Pine.BSF.3.96.971021211536.859A-100000@trojanhorse.ml.org>
Message-ID: <Pine.BSF.3.95q.971021225743.11749B-100000@misery.sdf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
On Tue, 21 Oct 1997, Jamil J. Weatherbee wrote:
> I think adaptec have some that just look like a 2940, I saw one for about
> $800.
I don't know about that. I believe those controllers do look like
a 2940, but the RAID functionality requires software support. So
basically, the looks AND acts like a 2940.
The DPT SmartRaid IV works well. The driver is not incorporated into
the base distribution, but you can get it for 2.2-stable and
freebsd-current. I also like this card, because unlike the Mylex cards,
additional channels can be added later via a daughtercard.
Tom
From owner-freebsd-hackers Tue Oct 21 23:03:41 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id XAA08198
for hackers-outgoing; Tue, 21 Oct 1997 23:03:41 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from misery.sdf.com (misery.sdf.com [204.244.210.193])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA08189
for <hackers@freebsd.org>; Tue, 21 Oct 1997 23:03:38 -0700 (PDT)
(envelope-from tom@sdf.com)
Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1)
id 0xNtrS-00036c-00; Tue, 21 Oct 1997 23:01:42 -0700
Date: Tue, 21 Oct 1997 23:01:41 -0700 (PDT)
From: Tom <tom@sdf.com>
To: Sunthiti Patchararungruang <a96456@cs.ait.ac.th>
cc: hackers@freebsd.org
Subject: Re: Problem with FreeBSD2.2.2
In-Reply-To: <Pine.GSO.3.94.971022114014.19833A-100000@bazooka.cs.ait.ac.th>
Message-ID: <Pine.BSF.3.95q.971021230053.11749C-100000@misery.sdf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
On Wed, 22 Oct 1997, Sunthiti Patchararungruang wrote:
> Dear Everyboy
>
> I have a computer with FreeBSD2.2.2. I have a problem about system
> resource. When I login as a normal user up to 4 session, I cannot use
> "man" command. It always report that "cannot fork" and "resource is
You should use the freebsd-questions list, not freebsd-hackers
Your problem is caused by resource limits set in login.conf. See the
man page.
Tom
From owner-freebsd-hackers Tue Oct 21 23:04:21 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id XAA08287
for hackers-outgoing; Tue, 21 Oct 1997 23:04:21 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from shell.futuresouth.com (shell.futuresouth.com [207.141.254.20])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA08282
for <hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 23:04:18 -0700 (PDT)
(envelope-from fullermd@futuresouth.com)
Received: from shell.futuresouth.com (mail.futuresouth.com [207.141.254.21])
by shell.futuresouth.com (8.8.5/8.8.5) with SMTP id BAA11424;
Wed, 22 Oct 1997 01:04:05 -0500 (CDT)
Date: Wed, 22 Oct 1997 01:04:05 -0500 (CDT)
From: "Matthew D. Fuller" <fullermd@futuresouth.com>
To: Sunthiti Patchararungruang <a96456@cs.ait.ac.th>
cc: hackers@FreeBSD.ORG
Subject: Re: Problem with FreeBSD2.2.2
In-Reply-To: <Pine.GSO.3.94.971022114014.19833A-100000@bazooka.cs.ait.ac.th>
Message-ID: <Pine.BSF.3.96.971022010248.9034B-100000@shell.futuresouth.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Wed, 22 Oct 1997, Sunthiti Patchararungruang wrote:
> Dear Everyboy
>
> I have a computer with FreeBSD2.2.2. I have a problem about system
> resource. When I login as a normal user up to 4 session, I cannot use
> "man" command. It always report that "cannot fork" and "resource is
> temporary unavailable". However, the problem does not occur when I login
> as root. I think the problem is come from the swap space. Maybe normal
> user cannot use it because all swap space is empty, checked by
> "swapinfo". However, I don't know how to solve it. Please help me.
See man login.conf(5?)
you have to edit your login class in /etc/login.conf or change it using
vipw.
the default user class has CPU and process resource limit which you're
hitting there.
>
> Sincerely Yours,
> Sunthiti Patchararungraung
>
>
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| FreeBSD; the way computers were meant to be |
* "The only reason I'm burning my candle at both ends, is *
| that I haven't figured out how to light the middle yet."|
* fullermd@futuresouth.com :-} MAtthew Fuller *
| http://keystone.westminster.edu/~fullermd |
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
From owner-freebsd-hackers Tue Oct 21 23:14:37 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id XAA08898
for hackers-outgoing; Tue, 21 Oct 1997 23:14:37 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA08888
for <freebsd-hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 23:14:33 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA26733 for freebsd-hackers@FreeBSD.ORG; Wed, 22 Oct 1997 08:14:29 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id HAA20644;
Wed, 22 Oct 1997 07:59:19 +0200 (MET DST)
Message-ID: <19971022075919.IP16123@uriah.heep.sax.de>
Date: Wed, 22 Oct 1997 07:59:19 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: freebsd-hackers@FreeBSD.ORG
Subject: Re: DLT drives
References: <19971022001854.DS19056@uriah.heep.sax.de> <Pine.BSF.3.96.971021191408.28032A-100000@stox.sa.enteract.com>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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.96.971021191408.28032A-100000@stox.sa.enteract.com>; from Kenneth P. Stox on Oct 21, 1997 19:22:40 -0500
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Kenneth P. Stox wrote:
> >> Not so. Some load their own version of the DLT firmware.
> >
> >Their own versions, or just their own vendor string only?
> Well, I can speak from experience that the DEC, Quantum, and SGI
> versions are different.
Again, in what respect are they different? If it's just the vendor
string, you can certainly ignore it. I would find it hard that they
e.g. would implement all their different set of mode pages.
--
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 Oct 21 23:14:53 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id XAA08943
for hackers-outgoing; Tue, 21 Oct 1997 23:14:53 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA08930
for <freebsd-hackers@FreeBSD.ORG>; Tue, 21 Oct 1997 23:14:49 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA26737 for freebsd-hackers@FreeBSD.ORG; Wed, 22 Oct 1997 08:14:44 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id IAA20666;
Wed, 22 Oct 1997 08:03:41 +0200 (MET DST)
Message-ID: <19971022080341.HR59190@uriah.heep.sax.de>
Date: Wed, 22 Oct 1997 08:03:41 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: freebsd-hackers@FreeBSD.ORG
Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage
References: <19971021081759.TH50130@uriah.heep.sax.de> <199710220009.TAA18051@nospam.hiwaay.net>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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: <199710220009.TAA18051@nospam.hiwaay.net>; from dkelly@hiwaay.net on Oct 21, 1997 19:09:47 -0500
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As dkelly@hiwaay.net wrote:
> Went back and RTFM'ed my Asus SC875 manual and obsverved on page 11
> the default Synchronous Transfer Rate (MS/Sec) (sic) is 20. So is this MB/
> sec or MHz?
MHz. Together with the 16-bit bus, it makes a theoretical maximum of
40 MB/s (minus transaction overhead which is, as Stefan mentioned, not
neglicible).
--
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 Oct 22 00:02:20 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id AAA11459
for hackers-outgoing; Wed, 22 Oct 1997 00:02:20 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from casparc.ppp.net (mail.ppp.net [194.64.12.35])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA11442
for <freebsd-hackers@FreeBSD.ORG>; Wed, 22 Oct 1997 00:02:10 -0700 (PDT)
(envelope-from ernie!bert.kts.org!hm@ppp.net)
Received: from ernie by casparc.ppp.net with uucp
(Smail3.1.28.1 #1) id m0xNunr-0032TrC; Wed, 22 Oct 97 08:02 MET
Received: from bert.kts.org(really [194.55.156.2]) by ernie.kts.org
via sendmail with smtp
id <m0xNuWn-00001LC@ernie.kts.org>
for <joerg_wunsch@uriah.heep.sax.de>; Wed, 22 Oct 1997 08:44:25 +0200 (MET DST)
(Smail-3.2.0.91 1997-Jan-14 #2 built 1997-Feb-8)
Received: by bert.kts.org
via sendmail with stdio
id <m0xNuPI-00023GC@bert.kts.org>
for freebsd-hackers@FreeBSD.ORG; Wed, 22 Oct 1997 08:36:40 +0200 (CEST)
(Smail-3.2.0.94 1997-Apr-22 #7 built 1997-Jul-4)
Message-Id: <m0xNuPI-00023GC@bert.kts.org>
From: hm@kts.org (Hellmuth Michaelis)
Subject: Re: DLT drives
In-Reply-To: <19971022001854.DS19056@uriah.heep.sax.de> from J Wunsch at "Oct 22, 97 00:18:54 am"
To: joerg_wunsch@uriah.heep.sax.de
Date: Wed, 22 Oct 1997 08:36:40 +0200 (CEST)
Cc: freebsd-hackers@FreeBSD.ORG
Organization: Kitchen Table Systems
Reply-To: hm@kts.org
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
J Wunsch wrote:
>
> > Not so. Some load their own version of the DLT firmware.
>
> Their own versions, or just their own vendor string only? I'd rather
> assume the latter.
Their own versions. HP has a DLT (version) which can be run in 7980 mode
(which is an HP reel to reel tape) and i doubt this is possible with the
standard firmware.
hellmuth
--
Hellmuth Michaelis hm@kts.org Hamburg, Europe
"Those who can, do. Those who can't, talk.
And those who can't talk, talk about talking." (B. Shaw)
From owner-freebsd-hackers Wed Oct 22 00:31:12 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id AAA13240
for hackers-outgoing; Wed, 22 Oct 1997 00:31:12 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA13231
for <freebsd-hackers@freebsd.org>; Wed, 22 Oct 1997 00:31:09 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA27256 for freebsd-hackers@freebsd.org; Wed, 22 Oct 1997 09:31:07 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id JAA00380;
Wed, 22 Oct 1997 09:30:40 +0200 (MET DST)
Message-ID: <19971022093040.UM28723@uriah.heep.sax.de>
Date: Wed, 22 Oct 1997 09:30:40 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: freebsd-hackers@freebsd.org (FreeBSD hackers)
Subject: Re: Possible SERIOUS bug in open()?
References: <19971017104213.11040.qmail@kechara.flame.org>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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: <19971017104213.11040.qmail@kechara.flame.org>; from explorer@flame.org on Oct 17, 1997 10:42:13 -0000
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
As explorer@flame.org wrote:
> This was sent to me recently... It seems to be a pretty serious hole
> in open() and permissions...
Fixed.
--
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 Oct 22 00:42:15 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id AAA13951
for hackers-outgoing; Wed, 22 Oct 1997 00:42:15 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA13946
for <freebsd-hackers@freebsd.org>; Wed, 22 Oct 1997 00:42:09 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id RAA01949;
Wed, 22 Oct 1997 17:08:28 +0930 (CST)
Message-Id: <199710220738.RAA01949@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: jbryant@tfs.net
cc: jamil@trojanhorse.ml.org (Jamil J. Weatherbee),
freebsd-hackers@freebsd.org
Subject: Re: Solid State Disks
In-reply-to: Your message of "Tue, 21 Oct 1997 08:41:01 EST."
<199710211341.IAA11750@argus.tfs.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 22 Oct 1997 17:08:27 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> In reply:
> > Anybody seen any good literature/prices on this sort of thing lately. How
> > long are they rumored to exist. It would be really cool if a PC was like
> > an hp48, damn thing never crashes and is basically always on.
>
> kinda cool... SS disks have been around for a while, but i don't
> recall non-volatility though.
Several industrial computer suppliers have devices that are basically
an IDE interface, a micro, a pile of 72-pin SIMMs and a battery.
mike
From owner-freebsd-hackers Wed Oct 22 01:39:32 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id BAA16812
for hackers-outgoing; Wed, 22 Oct 1997 01:39:32 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA16807
for <freebsd-hackers@FreeBSD.ORG>; Wed, 22 Oct 1997 01:39:30 -0700 (PDT)
(envelope-from jamil@trojanhorse.ml.org)
Received: from localhost (jamil@localhost)
by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id BAA09787;
Wed, 22 Oct 1997 01:38:11 -0700 (PDT)
Date: Wed, 22 Oct 1997 01:38:11 -0700 (PDT)
From: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
cc: FreeBSD hackers <freebsd-hackers@FreeBSD.ORG>
Subject: Re: Possible SERIOUS bug in open()?
In-Reply-To: <19971022093040.UM28723@uriah.heep.sax.de>
Message-ID: <Pine.BSF.3.96.971022013546.8389A-100000@trojanhorse.ml.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Wed, 22 Oct 1997, J Wunsch wrote:
> As explorer@flame.org wrote:
>
> > This was sent to me recently... It seems to be a pretty serious hole
> > in open() and permissions...
>
> Fixed.
How exactly did you fix it, this is related to what I was saying about
opening a file as RD_ONLY and WR_ONLY, because if oflags = -1 then fflags
= 0 and that means the file is not open for read or write which my point
was that it should be forced to be open for one or the other. I don't
rememer who, but someone seemed to think that it could be actually useful
to hav a file not open for read or write
> --
> 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 Oct 22 02:09:08 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id CAA18315
for hackers-outgoing; Wed, 22 Oct 1997 02:09:08 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA18310
for <freebsd-hackers@freebsd.org>; Wed, 22 Oct 1997 02:09:04 -0700 (PDT)
(envelope-from thorpej@lestat.nas.nasa.gov)
Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.6/8.6.12) with SMTP id CAA13732; Wed, 22 Oct 1997 02:09:46 -0700 (PDT)
Message-Id: <199710220909.CAA13732@lestat.nas.nasa.gov>
X-Authentication-Warning: lestat.nas.nasa.gov: localhost [127.0.0.1] didn't use HELO protocol
To: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
Cc: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>,
FreeBSD hackers <freebsd-hackers@freebsd.org>
Subject: Re: Possible SERIOUS bug in open()?
Reply-To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Jason Thorpe <thorpej@nas.nasa.gov>
Date: Wed, 22 Oct 1997 02:09:44 -0700
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
On Wed, 22 Oct 1997 01:38:11 -0700 (PDT)
"Jamil J. Weatherbee" <jamil@trojanhorse.ml.org> wrote:
> How exactly did you fix it, this is related to what I was saying about
> opening a file as RD_ONLY and WR_ONLY, because if oflags = -1 then fflags
> = 0 and that means the file is not open for read or write which my point
> was that it should be forced to be open for one or the other. I don't
> rememer who, but someone seemed to think that it could be actually useful
> to hav a file not open for read or write
How would opening for !read !write be useful? What else could you possibly
want to do? (Yes, this is a trick question :-)
Jason R. Thorpe thorpej@nas.nasa.gov
NASA Ames Research Center Home: +1 408 866 1912
NAS: M/S 258-6 Work: +1 415 604 0935
Moffett Field, CA 94035 Pager: +1 415 428 6939
From owner-freebsd-hackers Wed Oct 22 02:47:49 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id CAA19917
for hackers-outgoing; Wed, 22 Oct 1997 02:47:49 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from seagull.cdrom.com (cracauer@seagull.cdrom.com [204.216.27.14])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA19910
for <hackers@FreeBSD.ORG>; Wed, 22 Oct 1997 02:47:47 -0700 (PDT)
(envelope-from cracauer@seagull.cdrom.com)
Received: (from cracauer@localhost)
by seagull.cdrom.com (8.8.6/8.6.6) id CAA24135
; Wed, 22 Oct 1997 02:46:25 -0700 (PDT)
Message-ID: <19971022114622.61668@cons.org>
Date: Wed, 22 Oct 1997 11:46:22 +0200
From: Martin Cracauer <cracauer@cons.org>
To: Jaye Mathisen <mrcpu@cdsnet.net>
Cc: hackers@FreeBSD.ORG
Subject: Re: Is there any way to build a completely static system?
References: <Pine.NEB.3.95.971020134307.2330U-100000@mail.cdsnet.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.81
In-Reply-To: <Pine.NEB.3.95.971020134307.2330U-100000@mail.cdsnet.net>; from Jaye Mathisen on Mon, Oct 20, 1997 at 01:44:14PM -0700
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
In <Pine.NEB.3.95.971020134307.2330U-100000@mail.cdsnet.net>, Jaye Mathisen wrote:
> I mean no .so's, nothing. Just the necessare .a's, and all binaries
> statically linked...
>
> Getting the binaries statically linked is easy, but I was hoping NOSHARED
> would stop building the .so's for /usr/lib, but it seems to anyway.
Look into /usr/share/mk/bsd.lib.mk
Around line 115 (in 2.2.2) you find
.if !defined(NOPIC)
.if defined(SHLIB_MAJOR) && defined(SHLIB_MINOR)
_LIBS+=lib${LIB}.so.${SHLIB_MAJOR}.${SHLIB_MINOR}
.endif
.if defined(INSTALL_PIC_ARCHIVE)
_LIBS+=lib${LIB}_pic.a
.endif
.endif
Although it is intended for per-library settings, I looks like
globally setting option NOPIC would do what you want. If not, just
delete the LIBS+= lines in bsd.lib.mk.
Please let me know if it works.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/
BSD User Group Hamburg/Germany http://www.bsdhh.org/
From owner-freebsd-hackers Wed Oct 22 03:09:13 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id DAA20563
for hackers-outgoing; Wed, 22 Oct 1997 03:09:13 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from david.siemens.de (david.siemens.de [139.23.36.11])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA20558
for <hackers@freebsd.org>; Wed, 22 Oct 1997 03:09:08 -0700 (PDT)
(envelope-from Andre.Albsmeier@mchp.siemens.de)
Received: from salomon.mchp.siemens.de (mail.siemens.de [139.23.33.13])
by david.siemens.de (8.8.7/8.8.7) with ESMTP id MAA28638
for <hackers@freebsd.org>; Wed, 22 Oct 1997 12:04:00 +0200 (MET DST)
Received: from curry.mchp.siemens.de (daemon@curry.mchp.siemens.de [146.180.31.23])
by salomon.mchp.siemens.de (8.8.7/8.8.5) with ESMTP id MAA28660
for <hackers@freebsd.org>; Wed, 22 Oct 1997 12:08:06 +0200 (MDT)
Received: (from daemon@localhost)
by curry.mchp.siemens.de (8.8.7/8.8.7) id MAA06932
for <hackers@freebsd.org>; Wed, 22 Oct 1997 12:08:05 +0200 (MET DST)
From: Andre Albsmeier <Andre.Albsmeier@mchp.siemens.de>
Message-Id: <199710221007.MAA01578@curry.mchp.siemens.de>
Subject: Suggestion for chown -h
To: hackers@freebsd.org
Date: Wed, 22 Oct 1997 12:07:47 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Hi,
after asking on -questions why "chown -R -h" isn't
allowed, I was told that this is due to the possibility
that there might be symlinks which point to underlaying
directories somewhere else.
However, this might really be a problem, but only if
the symlinks are followed. So if neither -L nor -H
are specified, I think it would be safe to allow -h
with -R.
The diff's are quite simple:
*** chown.c.ORI Wed Oct 22 11:35:40 1997
--- chown.c Tue Oct 21 20:23:30 1997
***************
*** 116,122 ****
fts_options = FTS_PHYSICAL;
if (Rflag) {
! if (hflag)
errx(1, "the -R and -h options may not be specified together");
if (Hflag)
fts_options |= FTS_COMFOLLOW;
--- 116,122 ----
fts_options = FTS_PHYSICAL;
if (Rflag) {
! if (hflag && (Lflag || Hflag) )
errx(1, "the -R and -h options may not be specified together");
if (Hflag)
fts_options |= FTS_COMFOLLOW;
I have tried it here and it works quite nice. The reason,
why I like it is, to pass a whole directory over to another
user; of course without the files the symlinks are pointing at.
What do you think about that?
-Andre
From owner-freebsd-hackers Wed Oct 22 05:16:24 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id FAA25137
for hackers-outgoing; Wed, 22 Oct 1997 05:16:24 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id FAA25132
for <hackers@freebsd.org>; Wed, 22 Oct 1997 05:16:20 -0700 (PDT)
(envelope-from darrenr@cyber.com.au)
Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id WAA06516; Wed, 22 Oct 1997 22:15:50 +1000
From: Darren Reed <darrenr@cyber.com.au>
Message-Id: <199710221215.WAA06516@plum.cyber.com.au>
Subject: more struct ifnet move lossage.
To: tlambert@primenet.com
Date: Wed, 22 Oct 1997 22:15:50 +1000 (EST)
Cc: hackers@freebsd.org
In-Reply-To: <199710202351.QAA27105@usr05.primenet.com> from "Terry Lambert" at Oct 20, 97 11:51:43 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Sigh...the changes for 3.0 are more extensive than I first thought,
although _all_ the problems stem from "struct ifnet" being moved and
it not being included, by default, from net/if.h (it appears to be the
_only_ change that isn't backward compatible). Including
netinet/if_ether.h, whilst backawrd compatible in -current with itself,
is broken because it requires "struct ifnet" in a structure.
I'm curious...does tcpdump still compile on -current, `out of the box' ?
(Just to state the obvious, you don't compile tcpdump with -DKERNEL)
Darren
From owner-freebsd-hackers Wed Oct 22 05:48:04 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id FAA26603
for hackers-outgoing; Wed, 22 Oct 1997 05:48:04 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (word.smith.net.au [202.0.75.3])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA26571
for <hackers@freebsd.org>; Wed, 22 Oct 1997 05:47:47 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id WAA00847;
Wed, 22 Oct 1997 22:13:17 +0930 (CST)
Message-Id: <199710221243.WAA00847@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Darren Reed <darrenr@cyber.com.au>
cc: hackers@freebsd.org
Subject: Re: more struct ifnet move lossage.
In-reply-to: Your message of "Wed, 22 Oct 1997 22:15:50 +1000."
<199710221215.WAA06516@plum.cyber.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 22 Oct 1997 22:13:15 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
>
> I'm curious...does tcpdump still compile on -current, `out of the box' ?
src/usr.sbin/tcpdump, src/contrib/tcpdump. And look ma, no diffs.
> (Just to state the obvious, you don't compile tcpdump with -DKERNEL)
Speaking of stating the obvious; you don't expect to have the
kernel-private data structures that are the subject of so much
vitriolic hatred to stay put, do you?
All of Terry's comments on a procedural interface are 100% on the mark.
If you don't like the grief that the structure changes are causing you,
now is the time to participating in producing a *BETTER* interface.
mike
From owner-freebsd-hackers Wed Oct 22 06:23:40 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id GAA27857
for hackers-outgoing; Wed, 22 Oct 1997 06:23:40 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA27850
for <hackers@freebsd.org>; Wed, 22 Oct 1997 06:23:36 -0700 (PDT)
(envelope-from darrenr@cyber.com.au)
Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id XAA06956; Wed, 22 Oct 1997 23:22:27 +1000
From: Darren Reed <darrenr@cyber.com.au>
Message-Id: <199710221322.XAA06956@plum.cyber.com.au>
Subject: Re: more struct ifnet move lossage.
To: mike@smith.net.au (Mike Smith)
Date: Wed, 22 Oct 1997 23:22:26 +1000 (EST)
Cc: hackers@freebsd.org
In-Reply-To: <199710221243.WAA00847@word.smith.net.au> from "Mike Smith" at Oct 22, 97 10:13:15 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
In some mail I received from Mike Smith, sie wrote
>
> > I'm curious...does tcpdump still compile on -current, `out of the box' ?
>
> src/usr.sbin/tcpdump, src/contrib/tcpdump. And look ma, no diffs.
No, I mean get tcpdump from ftp.ee.lbl.gov and compile that (3.4a5).
10:1 it doesn't compile (I'll put money on it :-).
> > (Just to state the obvious, you don't compile tcpdump with -DKERNEL)
>
> Speaking of stating the obvious; you don't expect to have the
> kernel-private data structures that are the subject of so much
> vitriolic hatred to stay put, do you?
I'm not commenting on this because I've had enough of it.
> All of Terry's comments on a procedural interface are 100% on the mark.
> If you don't like the grief that the structure changes are causing you,
> now is the time to participating in producing a *BETTER* interface.
Well, I didn't know they even existed until this nasty little thread...
maybe I'm just not on the right freebsd email lists where these sort of
things are announced and discussed.
From owner-freebsd-hackers Wed Oct 22 06:37:37 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id GAA28593
for hackers-outgoing; Wed, 22 Oct 1997 06:37:37 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (word.smith.net.au [202.0.75.3])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA28566
for <hackers@freebsd.org>; Wed, 22 Oct 1997 06:37:28 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id XAA01019;
Wed, 22 Oct 1997 23:04:15 +0930 (CST)
Message-Id: <199710221334.XAA01019@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Darren Reed <darrenr@cyber.com.au>
cc: hackers@freebsd.org
Subject: Re: more struct ifnet move lossage.
In-reply-to: Your message of "Wed, 22 Oct 1997 23:22:26 +1000."
<199710221322.XAA06956@plum.cyber.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 22 Oct 1997 23:04:13 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> In some mail I received from Mike Smith, sie wrote
> >
> > > I'm curious...does tcpdump still compile on -current, `out of the box' ?
> >
> > src/usr.sbin/tcpdump, src/contrib/tcpdump. And look ma, no diffs.
>
> No, I mean get tcpdump from ftp.ee.lbl.gov and compile that (3.4a5).
> 10:1 it doesn't compile (I'll put money on it :-).
You don't appear to understand. That *is* what's in src/contrib/
tcpdump. Try it yourself:
# cd /usr/src/contrib/tcpdump
# cvs diff -u -r LBL
Note that having the repo lets you see these things. If you check the
logs, you will see that it is a virgin LBL tcpdump, at revision 3.3.
So what does this mean? Probably that LBL write better code than you
do, I guess.
> > Speaking of stating the obvious; you don't expect to have the
> > kernel-private data structures that are the subject of so much
> > vitriolic hatred to stay put, do you?
>
> I'm not commenting on this because I've had enough of it.
I was referring to general slagging of the BSD network stack; I *agree*
that these structures don't belong as they are, where they are.
> > All of Terry's comments on a procedural interface are 100% on the mark.
> > If you don't like the grief that the structure changes are causing you,
> > now is the time to participating in producing a *BETTER* interface.
>
> Well, I didn't know they even existed until this nasty little thread...
> maybe I'm just not on the right freebsd email lists where these sort of
> things are announced and discussed.
Um, as a committer you can't avoid receiving all the commit messages.
Dump the ones that don't affect you, and just keep an eye on the ones
that do. There's been slow change and declaration of intent in there
for many months now.
And if you don't understand something, please say "I don't understand
why this was done", not "you're f'ing stupid for doing this". It saves
an enormous amount of grief. 8)
mike
From owner-freebsd-hackers Wed Oct 22 06:52:49 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id GAA29316
for hackers-outgoing; Wed, 22 Oct 1997 06:52:49 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA29307
for <hackers@freebsd.org>; Wed, 22 Oct 1997 06:52:42 -0700 (PDT)
(envelope-from darrenr@cyber.com.au)
Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id XAA07214; Wed, 22 Oct 1997 23:52:27 +1000
From: Darren Reed <darrenr@cyber.com.au>
Message-Id: <199710221352.XAA07214@plum.cyber.com.au>
Subject: Re: more struct ifnet move lossage.
To: mike@smith.net.au (Mike Smith)
Date: Wed, 22 Oct 1997 23:52:26 +1000 (EST)
Cc: hackers@freebsd.org
In-Reply-To: <199710221334.XAA01019@word.smith.net.au> from "Mike Smith" at Oct 22, 97 11:04:13 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
In some mail I received from Mike Smith, sie wrote
>
> > In some mail I received from Mike Smith, sie wrote
> > >
> > > > I'm curious...does tcpdump still compile on -current, `out of the box' ?
> > >
> > > src/usr.sbin/tcpdump, src/contrib/tcpdump. And look ma, no diffs.
> >
> > No, I mean get tcpdump from ftp.ee.lbl.gov and compile that (3.4a5).
> > 10:1 it doesn't compile (I'll put money on it :-).
>
> You don't appear to understand. That *is* what's in src/contrib/
> tcpdump. Try it yourself:
You've missed the point totally of what I originally said and that is
that tcpdump no longer compiles "out of the box". "out of the box"
means ftp'ing it from LBL, not using what's in src/contrib/tcpdump.
Or do you want to debate about that too ?
What's in src/contrib/tcpdump is the LBL tcpdump PLUS FreeBSD
compatibility hacks. Do you want to disagree on that ?
> # cd /usr/src/contrib/tcpdump
> # cvs diff -u -r LBL
>
> Note that having the repo lets you see these things. If you check the
> logs, you will see that it is a virgin LBL tcpdump, at revision 3.3.
>
> So what does this mean? Probably that LBL write better code than you
> do, I guess.
# cvs diff -u -r LBL | grep if_var.h
cvs diff: Diffing .
cvs diff: tag LBL is not in file FREEBSD-upgrade
cvs diff: tag LBL is not in file nfs.h
+#include <net/if_var.h>
cvs diff: Diffing lbl
There - that's my point. More crapola because of it being moved.
There is no such include in 3.4a5.
cripes...I thought this was going to be simple and not a debate about
what's in src/contrib/tcpdump vs what is in the tcpdump.tar.gz people
ftp from LBL!
> > > All of Terry's comments on a procedural interface are 100% on the mark.
> > > If you don't like the grief that the structure changes are causing you,
> > > now is the time to participating in producing a *BETTER* interface.
> >
> > Well, I didn't know they even existed until this nasty little thread...
> > maybe I'm just not on the right freebsd email lists where these sort of
> > things are announced and discussed.
>
> Um, as a committer you can't avoid receiving all the commit messages.
> Dump the ones that don't affect you, and just keep an eye on the ones
> that do. There's been slow change and declaration of intent in there
> for many months now.
Sorry, I don't keep months worth of cvs commit messages in my head or
on disk. I just scan things for relevance to myself, which is usually
limited to reading the subject line :)
But CVS commit messages do not make a discussion or announcement...(to
me anyway).
From owner-freebsd-hackers Wed Oct 22 07:01:15 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id HAA29961
for hackers-outgoing; Wed, 22 Oct 1997 07:01:15 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (word.smith.net.au [202.0.75.3])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA29956
for <hackers@freebsd.org>; Wed, 22 Oct 1997 07:01:09 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id XAA01139;
Wed, 22 Oct 1997 23:27:45 +0930 (CST)
Message-Id: <199710221357.XAA01139@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Darren Reed <darrenr@cyber.com.au>
cc: mike@smith.net.au (Mike Smith), hackers@freebsd.org
Subject: Re: more struct ifnet move lossage.
In-reply-to: Your message of "Wed, 22 Oct 1997 23:52:26 +1000."
<199710221352.XAA07214@plum.cyber.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 22 Oct 1997 23:27:44 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> You've missed the point totally of what I originally said and that is
> that tcpdump no longer compiles "out of the box". "out of the box"
> means ftp'ing it from LBL, not using what's in src/contrib/tcpdump.
> Or do you want to debate about that too ?
No, I'll confess that /usr/src on the box I checked on (I'm not
completely stupid 8) is 2.2, not -current (I've been beating on 2.2.5
pre-release).
> What's in src/contrib/tcpdump is the LBL tcpdump PLUS FreeBSD
> compatibility hacks. Do you want to disagree on that ?
No. Mea culpa.
> > Um, as a committer you can't avoid receiving all the commit messages.
> > Dump the ones that don't affect you, and just keep an eye on the ones
> > that do. There's been slow change and declaration of intent in there
> > for many months now.
>
> Sorry, I don't keep months worth of cvs commit messages in my head or
> on disk. I just scan things for relevance to myself, which is usually
> limited to reading the subject line :)
No offense, but I think you need to at least keep a little continuity
going...
> But CVS commit messages do not make a discussion or announcement...(to
> me anyway).
A trend in commits, or attached comments thereto can generally be taken
as an announcement. The people responsible for these changes (mostly
Bruce and Garrett) aren't given to lengthy pontification. If one of
them commits something, it's worth paying attention to.
mike
From owner-freebsd-hackers Wed Oct 22 07:30:01 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id HAA01453
for hackers-outgoing; Wed, 22 Oct 1997 07:30:01 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sasami.jurai.net (winter@sasami.jurai.net [207.96.1.17])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA01416
for <freebsd-hackers@FreeBSD.ORG>; Wed, 22 Oct 1997 07:29:55 -0700 (PDT)
(envelope-from winter@jurai.net)
Received: from localhost (winter@localhost)
by sasami.jurai.net (8.8.7/8.8.7) with SMTP id KAA26003;
Wed, 22 Oct 1997 10:26:24 -0400 (EDT)
Date: Wed, 22 Oct 1997 10:26:24 -0400 (EDT)
From: "Matthew N. Dodd" <winter@jurai.net>
To: Douglas Carmichael <dcarmich@Mcs.Net>
cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: Hardware RAID-x controllers for FreeBSD?
In-Reply-To: <199710220259.VAA20051@Mars.mcs.net>
Message-ID: <Pine.BSF.3.95q.971022102319.18189R-100000@sasami.jurai.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Tue, 21 Oct 1997, Douglas Carmichael wrote:
> Do any you know of any hardware RAID-x controllers (x = >1, preferably 5)
> that work with FreeBSD and either:
> 1) Have a native driver in FreeBSD for them
> or 2) Appear as just another big disk
http://www.cmd.com/
/*
Matthew N. Dodd | A memory retaining a love you had for life
winter@jurai.net | As cruel as it seems nothing ever seems to
http://www.jurai.net/~winter | go right - FLA M 3.1:53
*/
From owner-freebsd-hackers Wed Oct 22 09:50:27 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id JAA10673
for hackers-outgoing; Wed, 22 Oct 1997 09:50:27 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: (from jmb@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id JAA10663;
Wed, 22 Oct 1997 09:50:16 -0700 (PDT)
(envelope-from jmb)
From: "Jonathan M. Bresler" <jmb>
Message-Id: <199710221650.JAA10663@hub.freebsd.org>
Subject: Re: more struct ifnet move lossage.
To: mike@smith.net.au (Mike Smith)
Date: Wed, 22 Oct 1997 09:50:15 -0700 (PDT)
Cc: darrenr@cyber.com.au, mike@smith.net.au, hackers@freebsd.org
In-Reply-To: <199710221357.XAA01139@word.smith.net.au> from "Mike Smith" at Oct 22, 97 11:27:44 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
these changes should be announced in commercial@freebsd.org.
Mike Smith wrote:
> Darren Reed wrote:
> > But CVS commit messages do not make a discussion or announcement...(to
> > me anyway).
>
> A trend in commits, or attached comments thereto can generally be taken
> as an announcement. The people responsible for these changes (mostly
> Bruce and Garrett) aren't given to lengthy pontification. If one of
> them commits something, it's worth paying attention to.
>
> mike
>
>
>
From owner-freebsd-hackers Wed Oct 22 10:23:10 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA13135
for hackers-outgoing; Wed, 22 Oct 1997 10:23:10 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA13121
for <freebsd-hackers@FreeBSD.ORG>; Wed, 22 Oct 1997 10:22:59 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id TAA03228 for freebsd-hackers@FreeBSD.ORG; Wed, 22 Oct 1997 19:22:57 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id TAA01413;
Wed, 22 Oct 1997 19:02:25 +0200 (MET DST)
Message-ID: <19971022190225.DV50844@uriah.heep.sax.de>
Date: Wed, 22 Oct 1997 19:02:25 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: freebsd-hackers@FreeBSD.ORG (FreeBSD hackers)
Subject: Re: Possible SERIOUS bug in open()?
References: <19971022093040.UM28723@uriah.heep.sax.de> <Pine.BSF.3.96.971022013546.8389A-100000@trojanhorse.ml.org>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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.96.971022013546.8389A-100000@trojanhorse.ml.org>; from Jamil J. Weatherbee on Oct 22, 1997 01:38:11 -0700
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Jamil J. Weatherbee wrote:
> > > This was sent to me recently... It seems to be a pretty serious hole
> > > in open() and permissions...
> >
> > Fixed.
>
> How exactly did you fix it, this is related to what I was saying about
> opening a file as RD_ONLY and WR_ONLY, ...
Yep, this was in the same boat. The way the fix works, only one of
O_RDONLY, O_WRONLY, or O_RDWR should be possible now, and anything
else should be rejected as EINVAL.
--
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 Oct 22 10:45:06 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA14438
for hackers-outgoing; Wed, 22 Oct 1997 10:45:06 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from srv.net (snake.srv.net [199.104.81.3])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA14364;
Wed, 22 Oct 1997 10:44:09 -0700 (PDT)
(envelope-from cmott@srv.net)
Received: from darkstar.home (dialin1.anlw.anl.gov [141.221.254.101])
by srv.net (8.8.5/8.8.5) with SMTP id LAA21235;
Wed, 22 Oct 1997 11:43:53 -0600 (MDT)
Date: Wed, 22 Oct 1997 10:43:21 -0700 (MST)
From: Charles Mott <cmott@srv.net>
X-Sender: cmott@darkstar.home
To: freebsd-hackers@freebsd.org, freebsd-isp@freebsd.org
Subject: Password files and virtual IP addresses
Message-ID: <Pine.BSF.3.96.971022103356.10892B-100000@darkstar.home>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Suppose that one wanted to create different virtual
IP addresses with ifconfig alias, and when people telnet
or ftp or access pop3/imap2 at a virtual address, a
password file specific to that virtual address would be
used. This would allow username re-use.
Has this sort of thing been considered before? If not,
what sort of things would have to be hacked? If password
access routines could somehow be informed what virtual
address they were being accessed from, then it would
be possible to have multiple password files.
Of course, there are always unintended security
implications to doing these things...
Charles Mott
From owner-freebsd-hackers Wed Oct 22 11:13:04 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA16113
for hackers-outgoing; Wed, 22 Oct 1997 11:13:04 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA16102
for <freebsd-hackers@FreeBSD.ORG>; Wed, 22 Oct 1997 11:12:57 -0700 (PDT)
(envelope-from wilko@yedi.iaf.nl)
Received: by iafnl.es.iaf.nl with UUCP id AA21467
(5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Wed, 22 Oct 1997 20:12:41 +0200
Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id XAA02980; Tue, 21 Oct 1997 23:15:20 +0100 (MET)
From: Wilko Bulte <wilko@yedi.iaf.nl>
Message-Id: <199710212215.XAA02980@yedi.iaf.nl>
Subject: Re: DLT drives
To: pnorton@ccnvhi.com (Paul Norton)
Date: Tue, 21 Oct 1997 23:15:19 +0100 (MET)
Cc: tom@sdf.com, karl@Mcs.Net, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <199710211921.MAA00740@grumpy.ccnvhi.com> from "Paul Norton" at Oct 21, 97 12:21:32 pm
X-Organisation: Private FreeBSD site - Arnhem, The Netherlands
X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org'
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-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Paul Norton wrote...
> Not so. Some load their own version of the DLT firmware.
Which are different OEM 'personalities' provided (in the end) by
Quantum. You can as OEM ask for a specific feature. We do things like
that at work (== DEC). But for VendorID and ProductID you can just
use DLTtools (on the Quantum web site)
> Wilko Bulte writes:
> > All are built by Quantum, who bought the tape and disk business from
> > Digital (DEC).
> >
> > So, Sun, SGI, DEC, etc all just rebadge them.
_ ____________________________________________________________________
| / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko
|/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try'
------------------ Support your local daemons: run FreeBSD Unix -----Yoda
From owner-freebsd-hackers Wed Oct 22 11:22:28 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA16594
for hackers-outgoing; Wed, 22 Oct 1997 11:22:28 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from phoenix.its.rpi.edu (phoenix.its.rpi.edu [128.113.161.45])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA16589
for <freebsd-hackers@FreeBSD.ORG>; Wed, 22 Oct 1997 11:22:23 -0700 (PDT)
(envelope-from dec@phoenix.its.rpi.edu)
Received: from localhost (dec@localhost)
by phoenix.its.rpi.edu (8.8.7/8.8.7) with SMTP id OAA16665;
Wed, 22 Oct 1997 14:22:11 -0400 (EDT)
Date: Wed, 22 Oct 1997 14:22:11 -0400 (EDT)
From: "David E. Cross" <dec@phoenix.its.rpi.edu>
To: J Wunsch <j@uriah.heep.sax.de>
cc: FreeBSD hackers <freebsd-hackers@FreeBSD.ORG>
Subject: Re: Possible SERIOUS bug in open()?
In-Reply-To: <19971022190225.DV50844@uriah.heep.sax.de>
Message-ID: <Pine.BSF.3.96.971022142133.15884B-100000@phoenix.its.rpi.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Wed, 22 Oct 1997, J Wunsch wrote:
> As Jamil J. Weatherbee wrote:
>
> > > > This was sent to me recently... It seems to be a pretty serious hole
> > > > in open() and permissions...
> > >
> > > Fixed.
> >
> > How exactly did you fix it, this is related to what I was saying about
> > opening a file as RD_ONLY and WR_ONLY, ...
>
> Yep, this was in the same boat. The way the fix works, only one of
> O_RDONLY, O_WRONLY, or O_RDWR should be possible now, and anything
> else should be rejected as EINVAL.
I thought that O_RDRW = O_RDONLY | O_WRONLY.
--
David Cross
ACS Consultant
From owner-freebsd-hackers Wed Oct 22 11:25:17 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA16830
for hackers-outgoing; Wed, 22 Oct 1997 11:25:17 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from shasta.wstein.com (joes@shasta.wstein.com [207.173.11.132])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA16801;
Wed, 22 Oct 1997 11:25:09 -0700 (PDT)
(envelope-from joes@shasta.wstein.com)
Received: (from joes@localhost)
by shasta.wstein.com (8.8.7/8.8.7) id LAA17618;
Wed, 22 Oct 1997 11:25:02 -0700 (PDT)
From: Joseph Stein <joes@seaport.net>
Message-Id: <199710221825.LAA17618@shasta.wstein.com>
Subject: Interesting behaviour from sysctl(kern.boottime)
To: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org
Date: Wed, 22 Oct 1997 11:25:01 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I've written myself a utility that polls the boot time (okay, I stole that
part from w(1)) and sends a message to my pager so that I know that
everything is hunky-dory.
The actual message to my pager would look like this:
Oct 22 11:00:05 shasta status: up 1+13:40:20 [2 users]
But, I've come to notice the following: (five executions worth of data:)
----------------- cut here --------------
System time is (877528801) Wed Oct 22 07:00:01 1997
System Booted at (877407594) Mon Oct 20 21:19:54 1997
^^^^^^^^^^^^^^^^^^^
Difference is: 121207 seconds
-----
System time is (877532401) Wed Oct 22 08:00:01 1997
System Booted at (877407591) Mon Oct 20 21:19:51 1997
^^^^^^^^^^^^^^^^^^^
Difference is: 124810 seconds
-----
System time is (877536000) Wed Oct 22 09:00:00 1997
System Booted at (877407589) Mon Oct 20 21:19:49 1997
^^^^^^^^^^^^^^^^^^^
Difference is: 128411 seconds
-----
System time is (877539600) Wed Oct 22 10:00:00 1997
System Booted at (877407587) Mon Oct 20 21:19:47 1997
^^^^^^^^^^^^^^^^^^^
Difference is: 132013 seconds
-----
System time is (877543205) Wed Oct 22 11:00:05 1997
System Booted at (877407585) Mon Oct 20 21:19:45 1997
^^^^^^^^^^^^^^^^^^^
Difference is: 135620 seconds
----------------- cut here --------------
Is this a "feature" or a "bug". I would think that the boottime should
_not_ change.
I run xntpd. Could that be a factor? (updating the clock ticks or whatever?)
I haven't yet looked at the kernel sources that track the boot time, but
it does get kind of interesting to see the system be up for two more seconds
(or so) every hour...
joe
From owner-freebsd-hackers Wed Oct 22 11:48:16 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA18062
for hackers-outgoing; Wed, 22 Oct 1997 11:48:16 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from jake.csh.rit.edu (jake.csh.rit.edu [129.21.60.8])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA18010
for <freebsd-hackers@freebsd.org>; Wed, 22 Oct 1997 11:47:00 -0700 (PDT)
(envelope-from tad@mcp.csh.rit.edu)
Received: from localhost (tad@localhost)
by jake.csh.rit.edu (8.8.5/8.8.5) with SMTP id OAA01419
for <freebsd-hackers@freebsd.org>; Wed, 22 Oct 1997 14:46:27 -0400
Message-Id: <199710221846.OAA01419@jake.csh.rit.edu>
X-Authentication-Warning: jake.csh.rit.edu: tad owned process doing -bs
X-Authentication-Warning: jake.csh.rit.edu: tad@localhost didn't use HELO protocol
Reply-To: Tad Hunt <tad@csh.rit.edu>
To: freebsd-hackers@freebsd.org
Subject: -lc_r and setjmp (BUG)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1374.877545901.1@mail.csh.rit.edu>
Date: Wed, 22 Oct 1997 14:45:01 -0400
From: Tad Hunt <tad@mcp.csh.rit.edu>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I was looking at the libc_r implementation of setjmp
(lib/libc_r/uthread/uthread_setjmp.c) from (FreeBSD-2.2.5-101897)
from lib/libc_r/uthread/uthread_setjmp.c:
int
setjmp(jmp_buf env)
{
return (_thread_sys_setjmp(env));
}
where _thread_sys_setjmp is implemented in lib/libc/i386/gen/setjmp.S
as something like the following:
#ifdef _THREAD_SAFE
ENTRY(_thread_sys_setjmp)
#else
ENTRY(setjmp)
#endif
[... essentially the same implementation for both cases, except
for some signal stuff]
In the case of threaded programs calling setjmp() (instead of calling
_thread_sys_setjmp()) the wrong environment gets saved in the jmp_buf.
When longjmp does it's work, it returns into setjmp() (instead of returning
into the caller of setjmp(). Essentially the following is happening:
jmp_buf foo;
main()
{
bar();
longjmp(foo, 1);
}
bar()
{
setjmp(foo);
}
-Tad
P.S. I don't know if this is the right place to report the bug, please
redirect me if necessary.
From owner-freebsd-hackers Wed Oct 22 11:52:31 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA18348
for hackers-outgoing; Wed, 22 Oct 1997 11:52:31 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA18322
for <freebsd-hackers@FreeBSD.ORG>; Wed, 22 Oct 1997 11:52:18 -0700 (PDT)
(envelope-from wilko@yedi.iaf.nl)
Received: by iafnl.es.iaf.nl with UUCP id AA23544
(5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Wed, 22 Oct 1997 20:52:01 +0200
Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id UAA02767; Wed, 22 Oct 1997 20:18:27 +0100 (MET)
From: Wilko Bulte <wilko@yedi.iaf.nl>
Message-Id: <199710221918.UAA02767@yedi.iaf.nl>
Subject: Re: DLT drives
To: hm@kts.org
Date: Wed, 22 Oct 1997 20:18:27 +0100 (MET)
Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <m0xNuPI-00023GC@bert.kts.org> from "Hellmuth Michaelis" at Oct 22, 97 08:36:40 am
X-Organisation: Private FreeBSD site - Arnhem, The Netherlands
X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org'
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-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Hellmuth Michaelis wrote...
> J Wunsch wrote:
> >
> > > Not so. Some load their own version of the DLT firmware.
> >
> > Their own versions, or just their own vendor string only? I'd rather
> > assume the latter.
>
> Their own versions. HP has a DLT (version) which can be run in 7980 mode
> (which is an HP reel to reel tape) and i doubt this is possible with the
> standard firmware.
Check out http://www.quantum.com There are something like 5 or so
firmware personalities, e.g. also one that pretends to be an Exabyte.
Wilko
_ ____________________________________________________________________
| / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko
|/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try'
------------------ Support your local daemons: run FreeBSD Unix -----Yoda
From owner-freebsd-hackers Wed Oct 22 11:53:45 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA18410
for hackers-outgoing; Wed, 22 Oct 1997 11:53:45 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from out2.ibm.net (out2.ibm.net [165.87.194.229])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA18390
for <hackers@freebsd.org>; Wed, 22 Oct 1997 11:53:13 -0700 (PDT)
(envelope-from SimsS@IBM.Net)
Received: from Elvis.RatsNest.VaBeach.Va.Us (slip166-72-229-113.va.us.ibm.net [166.72.229.113]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id SAA124956 for <hackers@freebsd.org>; Wed, 22 Oct 1997 18:52:30 GMT
Received: by localhost with Microsoft MAPI; Wed, 22 Oct 1997 14:52:31 -0400
Message-ID: <01BCDEFA.1F723560.SimsS@IBM.Net>
From: Steve Sims <SimsS@IBM.Net>
Reply-To: "SimsS@IBM.Net" <SimsS@IBM.Net>
To: "'hackers@freebsd.org'" <hackers@freebsd.org>
Subject: SMP P-Pro MoBo - Recommendations?
Date: Wed, 22 Oct 1997 14:52:29 -0400
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4128
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I know this is a rehash of a thread from a couple of months ago, but.....
I'm thinking of plopping a dual P-Pro motherboard in my overstressed
P5/120.
There was a brief thread of pros & cons about various manufacturers and
features, but after an hour or so munging through the archives I come up
dry on trying to re-construct the thread.
One thing of interest was an URL to some "great motherboard web site in the
sky"(tm) that had the low-down on all sorts of mobo's, plus a few hackers
offered their 2-cent's worth.
Can anyone pass me a pointer or offer their experiences?
...sjs...
From owner-freebsd-hackers Wed Oct 22 12:21:50 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id MAA19997
for hackers-outgoing; Wed, 22 Oct 1997 12:21:50 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from coal.nis.newscorp.com (mxa.newscorp.com [206.15.105.135])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA19916
for <freebsd-hackers@FreeBSD.ORG>; Wed, 22 Oct 1997 12:20:02 -0700 (PDT)
(envelope-from ben@multivac.narcissus.net)
Received: from multivac.narcissus.net (ts2port12.port.net [207.38.248.140]) by coal.nis.newscorp.com (News Corp SMTP GW 1.1) with SMTP id PAA10100; Wed, 22 Oct 1997 15:20:18 -0400 (EDT)
Received: from localhost by multivac.narcissus.net (NX5.67e/NX3.0S)
id AA00270; Wed, 22 Oct 97 15:11:53 -0400
Date: Wed, 22 Oct 1997 15:11:52 -0400 (GMT-0400)
From: Snob Art Genre <ben@multivac.narcissus.net>
Reply-To: benedict@echonyc.com
To: "David E. Cross" <dec@phoenix.its.rpi.edu>
Cc: J Wunsch <j@uriah.heep.sax.de>,
FreeBSD hackers <freebsd-hackers@FreeBSD.ORG>
Subject: Re: Possible SERIOUS bug in open()?
In-Reply-To: <Pine.BSF.3.96.971022142133.15884B-100000@phoenix.its.rpi.edu>
Message-Id: <Pine.NXT.3.96.971022151033.254B-100000@multivac.narcissus.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Wed, 22 Oct 1997, David E. Cross wrote:
> I thought that O_RDRW = O_RDONLY | O_WRONLY.
Tsk -- do your research. From /usr/include/fcntl.h:
#define O_RDONLY 0x0000 /* open for reading only */
#define O_WRONLY 0x0001 /* open for writing only */
#define O_RDWR 0x0002 /* open for reading and writing */
Ben
"You have your mind on computers, it seems."
From owner-freebsd-hackers Wed Oct 22 12:23:16 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id MAA20099
for hackers-outgoing; Wed, 22 Oct 1997 12:23:16 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from iafnl.es.iaf.nl (root@iafnl.es.iaf.nl [195.108.17.20])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA20093
for <freebsd-hackers@FreeBSD.ORG>; Wed, 22 Oct 1997 12:23:13 -0700 (PDT)
(envelope-from wilko@yedi.iaf.nl)
Received: by iafnl.es.iaf.nl with UUCP id AA23548
(5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Wed, 22 Oct 1997 20:52:57 +0200
Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id UAA02858; Wed, 22 Oct 1997 20:29:58 +0100 (MET)
From: Wilko Bulte <wilko@yedi.iaf.nl>
Message-Id: <199710221929.UAA02858@yedi.iaf.nl>
Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage
To: joerg_wunsch@uriah.heep.sax.de
Date: Wed, 22 Oct 1997 20:29:58 +0100 (MET)
Cc: freebsd-hackers@FreeBSD.ORG
In-Reply-To: <19971022080341.HR59190@uriah.heep.sax.de> from "J Wunsch" at Oct 22, 97 08:03:41 am
X-Organisation: Private FreeBSD site - Arnhem, The Netherlands
X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org'
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-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As J Wunsch wrote...
> As dkelly@hiwaay.net wrote:
>
> > Went back and RTFM'ed my Asus SC875 manual and obsverved on page 11
> > the default Synchronous Transfer Rate (MS/Sec) (sic) is 20. So is this MB/
> > sec or MHz?
>
> MHz. Together with the 16-bit bus, it makes a theoretical maximum of
> 40 MB/s (minus transaction overhead which is, as Stefan mentioned, not
> neglicible).
Stick to mega-transfers/sec , covers both cases.
_ ____________________________________________________________________
| / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko
|/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try'
------------------ Support your local daemons: run FreeBSD Unix -----Yoda
From owner-freebsd-hackers Wed Oct 22 12:24:37 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id MAA20310
for hackers-outgoing; Wed, 22 Oct 1997 12:24:37 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from biggusdiskus.flyingfox.com (biggusdiskus.flyingfox.com [206.14.52.27])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA20267;
Wed, 22 Oct 1997 12:24:24 -0700 (PDT)
(envelope-from jas@flyingfox.com)
Received: (from jas@localhost)
by biggusdiskus.flyingfox.com (8.8.5/8.8.5) id MAA06912;
Wed, 22 Oct 1997 12:24:22 -0700 (PDT)
Date: Wed, 22 Oct 1997 12:24:22 -0700 (PDT)
From: Jim Shankland <jas@flyingfox.com>
Message-Id: <199710221924.MAA06912@biggusdiskus.flyingfox.com>
To: freebsd-hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, joes@seaport.net
Subject: Re: Interesting behaviour from sysctl(kern.boottime)
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> I've written myself a utility that polls the boot time (okay, I stole
> that part from w(1)) and sends a message to my pager so that I know
> that everything is hunky-dory....
>
> [ kernel's notion of boot time is changing ]
How fast are you moving relative to the machine at the time you
get these pages? It sounds to me as though relativity could be
a factor here.
Jim Shankland
Flying Fox Computer Systems, Inc.
From owner-freebsd-hackers Wed Oct 22 13:22:43 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id NAA24283
for hackers-outgoing; Wed, 22 Oct 1997 13:22:43 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA24275
for <hackers@FreeBSD.ORG>; Wed, 22 Oct 1997 13:22:38 -0700 (PDT)
(envelope-from sos@sos.freebsd.dk)
Received: (from sos@localhost) by sos.freebsd.dk (8.8.7/8.7.3) id WAA11525; Wed, 22 Oct 1997 22:21:48 +0200 (MEST)
Message-Id: <199710222021.WAA11525@sos.freebsd.dk>
Subject: Re: SMP P-Pro MoBo - Recommendations?
In-Reply-To: <01BCDEFA.1F723560.SimsS@IBM.Net> from Steve Sims at "Oct 22, 97 02:52:29 pm"
To: SimsS@IBM.Net
Date: Wed, 22 Oct 1997 22:21:48 +0200 (MEST)
Cc: hackers@FreeBSD.ORG
From: Søren Schmidt <sos@FreeBSD.dk>
Reply-to: sos@FreeBSD.dk
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-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
In reply to Steve Sims who wrote:
> I know this is a rehash of a thread from a couple of months ago, but.....
>
> I'm thinking of plopping a dual P-Pro motherboard in my overstressed
> P5/120.
>
> There was a brief thread of pros & cons about various manufacturers and
> features, but after an hour or so munging through the archives I come up
> dry on trying to re-construct the thread.
>
> One thing of interest was an URL to some "great motherboard web site in the
> sky"(tm) that had the low-down on all sorts of mobo's, plus a few hackers
> offered their 2-cent's worth.
>
> Can anyone pass me a pointer or offer their experiences?
Not exactly, but I plan to buy a TYAN TITAN dual PPro AT in the
next couble of weeks, so if anybody has any experience with that
I'd like to know
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team
Even more code to hack -- will it ever end
..
From owner-freebsd-hackers Wed Oct 22 13:29:41 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id NAA24852
for hackers-outgoing; Wed, 22 Oct 1997 13:29:41 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA24845
for <freebsd-hackers@freebsd.org>; Wed, 22 Oct 1997 13:29:39 -0700 (PDT)
(envelope-from thorpej@lestat.nas.nasa.gov)
Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.6/8.6.12) with SMTP id NAA20863; Wed, 22 Oct 1997 13:30:30 -0700 (PDT)
Message-Id: <199710222030.NAA20863@lestat.nas.nasa.gov>
X-Authentication-Warning: lestat.nas.nasa.gov: localhost [127.0.0.1] didn't use HELO protocol
To: dk+@ua.net
Cc: freebsd-hackers@freebsd.org
Subject: Re: Possible SERIOUS bug in open()?
Reply-To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Jason Thorpe <thorpej@nas.nasa.gov>
Date: Wed, 22 Oct 1997 13:30:28 -0700
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
On Wed, 22 Oct 1997 13:05:02 -0700 (PDT)
Dmitry Kohmanyuk <dk@dog.farm.org> wrote:
> > How would opening for !read !write be useful? What else could you possibly
> > want to do? (Yes, this is a trick question :-)
>
> just for ioctl()s?
Ah, that's the trick part of the question :-)
For ioctls that change the state of the device, you absolutely want to
have it open for writing. This is sort of obvious.
For ioctls that don't change the state of the device, you absolutely want
to have it open for reading. I.e. if you have a device that can expose
sensitive information by ioctl, and you set the mode to 600, you won't
want random people opening it via the neat little open hole and performing
that read-only ioctl.
Jason R. Thorpe thorpej@nas.nasa.gov
NASA Ames Research Center Home: +1 408 866 1912
NAS: M/S 258-6 Work: +1 415 604 0935
Moffett Field, CA 94035 Pager: +1 415 428 6939
From owner-freebsd-hackers Wed Oct 22 14:31:24 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA29634
for hackers-outgoing; Wed, 22 Oct 1997 14:31:24 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from earth.mat.net (root@earth.mat.net [206.246.122.2])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA29624
for <hackers@FreeBSD.ORG>; Wed, 22 Oct 1997 14:31:18 -0700 (PDT)
(envelope-from chuckr@glue.umd.edu)
Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by earth.mat.net (8.8.7/8.6.12) with SMTP id RAA09368; Wed, 22 Oct 1997 17:29:55 -0400 (EDT)
Date: Wed, 22 Oct 1997 16:29:42 -0400 (EDT)
From: Chuck Robey <chuckr@glue.umd.edu>
X-Sender: chuckr@picnic.mat.net
To: =?iso-8859-1?Q?S=F8ren_Schmidt?= <sos@FreeBSD.dk>
cc: SimsS@IBM.Net, hackers@FreeBSD.ORG
Subject: Re: SMP P-Pro MoBo - Recommendations?
In-Reply-To: <199710222021.WAA11525@sos.freebsd.dk>
Message-ID: <Pine.BSF.3.96.971022162800.13098I-100000@picnic.mat.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id OAA29629
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Wed, 22 Oct 1997, Søren Schmidt wrote:
> In reply to Steve Sims who wrote:
> > I know this is a rehash of a thread from a couple of months ago, but.....
> >
> > I'm thinking of plopping a dual P-Pro motherboard in my overstressed
> > P5/120.
> >
> > There was a brief thread of pros & cons about various manufacturers and
> > features, but after an hour or so munging through the archives I come up
> > dry on trying to re-construct the thread.
> >
> > One thing of interest was an URL to some "great motherboard web site in the
> > sky"(tm) that had the low-down on all sorts of mobo's, plus a few hackers
> > offered their 2-cent's worth.
> >
> > Can anyone pass me a pointer or offer their experiences?
>
> Not exactly, but I plan to buy a TYAN TITAN dual PPro AT in the
> next couble of weeks, so if anybody has any experience with that
> I'd like to know
I've got one, I have 2 PPro 166's in it, 512K cache per CPU. No problems,
works SMP just fine. BTW, it's a Titan II, I think the latest is a III, I
don't have any info about that one.
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team
> Even more code to hack -- will it ever end
> ..
>
>
----------------------------+-----------------------------------------------
Chuck Robey | Interests include any kind of voice or data
chuckr@eng.umd.edu | communications topic, C programming, and Unix.
213 Lakeside Drive Apt T-1 |
Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD
(301) 220-2114 | version 3.0 current -- and great FUN!
----------------------------+-----------------------------------------------
From owner-freebsd-hackers Wed Oct 22 14:48:57 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA01463
for hackers-outgoing; Wed, 22 Oct 1997 14:48:57 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA01448
for <freebsd-hackers@FreeBSD.ORG>; Wed, 22 Oct 1997 14:48:51 -0700 (PDT)
(envelope-from jamil@trojanhorse.ml.org)
Received: from localhost (jamil@localhost)
by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id OAA00811
for <freebsd-hackers@FreeBSD.ORG>; Wed, 22 Oct 1997 14:48:08 -0700 (PDT)
Date: Wed, 22 Oct 1997 14:48:08 -0700 (PDT)
From: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
To: freebsd-hackers@FreeBSD.ORG
Subject: using acquire_timer0() in drivers
In-Reply-To: <199710222021.WAA11525@sos.freebsd.dk>
Message-ID: <Pine.BSF.3.96.971022141721.744A-100000@trojanhorse.ml.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Am I correct to gather that on the 8253 timer chip.
clock 0 is freely available
clock 1 is used for scheduling interrupt (i.e. HZ)
clock 2 is connected to the speaker
If so I think there is a better way to utilize the clock 0 resource.
I was thinking that using acquire_timer0() is bad for any drivers that may
need it (such as data acquisition drivers). I wish to use it to clock
input from an analog board at around 1024hz, I am already certain that
this is perfectly doable. However, I am concerned that it might be a bad
architectural idea to acquire_timer0() for long periods of time in a
driver (or at all for that matter), since according to the clock.c code it
looks to me like only one interrupt routine can be acquired at a time.
But suppose I have 2 or three drivers needing polling service like this it
might be a good Idea to reimplement the 8253(8254 i think)
acquire_timer0() code so that more than one driver routine can be linked
to the interrupt routine. So polling hardware like this which does (and
will continue to exist) can get serviced properly. What I propose is that
multiple acquisitions are allowed which will make it easy to
check which routines will be run at that interrupt. The interrupt can be
maintained at the highest frequency requested.
like this: Routine Freq Reset val Phase val
1 256 4 1
2 512 2 0
3 1024 1 0
We could limit the counters to like 8 or more.
When a counter = 0 call the routine and set back to original counter
value. I would be interested in any analysis of the overhead here, we are
hopefully talking about small routines anyhow.
The phase value for instance would be a snapshot of the couter values at
one one point which would be the insertion point for dynamically added
routines. That way with 3 routines as above you optimize your distribution
of Timer Service Routines getting called. This would look like (in this
case). So with phase only 2 routines are getting executed on any one
interrupt.
2 1 2 2 1 2
3 3 3 3 3 3 3 3
Some of you may scream overhead and that your going to miss interrupts,
but if you had three boards on 3 different interrupts as above (their own
clocks presumably) I don't think it is going to look any better in terms
of overhead and chances of an interrupt getting missed (which is probably
the main concern).
From owner-freebsd-hackers Wed Oct 22 14:59:41 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA02310
for hackers-outgoing; Wed, 22 Oct 1997 14:59:41 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA02301
for <freebsd-hackers@FreeBSD.ORG>; Wed, 22 Oct 1997 14:59:38 -0700 (PDT)
(envelope-from jamil@trojanhorse.ml.org)
Received: from localhost (jamil@localhost)
by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id OAA00848;
Wed, 22 Oct 1997 14:57:51 -0700 (PDT)
Date: Wed, 22 Oct 1997 14:57:50 -0700 (PDT)
From: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
To: benedict@echonyc.com
cc: "David E. Cross" <dec@phoenix.its.rpi.edu>, J Wunsch <j@uriah.heep.sax.de>,
FreeBSD hackers <freebsd-hackers@FreeBSD.ORG>
Subject: Re: Possible SERIOUS bug in open()?
In-Reply-To: <Pine.NXT.3.96.971022151033.254B-100000@multivac.narcissus.net>
Message-ID: <Pine.BSF.3.96.971022145627.846A-100000@trojanhorse.ml.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
We had this discussion last week. It is really the fflags that matter, as
long as (fflags & 0x03) is true were ok.
On Wed, 22 Oct 1997, Snob Art Genre wrote:
> On Wed, 22 Oct 1997, David E. Cross wrote:
>
> > I thought that O_RDRW = O_RDONLY | O_WRONLY.
>
> Tsk -- do your research. From /usr/include/fcntl.h:
From owner-freebsd-hackers Wed Oct 22 15:01:00 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA02466
for hackers-outgoing; Wed, 22 Oct 1997 15:01:00 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from murrow.prognet.com (prognet.com [205.219.198.1])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA02460
for <freebsd-hackers@freebsd.org>; Wed, 22 Oct 1997 15:00:54 -0700 (PDT)
(envelope-from psh1@cornell.edu)
Received: from dirtboy.rih.org (ppp-206-170-1-173.snfc21.pacbell.net) by murrow.prognet.com with SMTP id AA06594
(5.67b/IDA-1.5 for <freebsd-hackers@freebsd.org>); Wed, 22 Oct 1997 15:04:32 -0700
Message-Id: <3.0.32.19971022150012.00686f44@mail.real.com>
X-Sender: peterh@mail.real.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 22 Oct 1997 15:00:47 -0700
To: freebsd-hackers@freebsd.org
From: Peter Haight <psh1@cornell.edu>
Subject: Re: SMP P-Pro MoBo - Recommendations?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
At 02:52 PM 10/22/97 -0400, you wrote:
>One thing of interest was an URL to some "great motherboard web site in the
>sky"(tm) that had the low-down on all sorts of mobo's, plus a few hackers
>offered their 2-cent's worth.
You are probably talking about Tom's Hardware Guide at
http://sysdoc.pair.com. He rates a lot of motherboards and explains a lot
of the issues involved.
From owner-freebsd-hackers Wed Oct 22 15:09:50 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA03220
for hackers-outgoing; Wed, 22 Oct 1997 15:09:50 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA03211;
Wed, 22 Oct 1997 15:09:43 -0700 (PDT)
(envelope-from danny@panda.hilink.com.au)
Received: (from danny@localhost)
by panda.hilink.com.au (8.8.5/8.8.5) id IAA13172;
Thu, 23 Oct 1997 08:09:25 +1000 (EST)
Date: Thu, 23 Oct 1997 08:09:24 +1000 (EST)
From: "Daniel O'Callaghan" <danny@panda.hilink.com.au>
To: Charles Mott <cmott@srv.net>
cc: freebsd-hackers@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG
Subject: Re: Password files and virtual IP addresses
In-Reply-To: <Pine.BSF.3.96.971022103356.10892B-100000@darkstar.home>
Message-ID: <Pine.BSF.3.91.971023080536.524N-100000@panda.hilink.com.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Wed, 22 Oct 1997, Charles Mott wrote:
> Suppose that one wanted to create different virtual
> IP addresses with ifconfig alias, and when people telnet
> or ftp or access pop3/imap2 at a virtual address, a
> password file specific to that virtual address would be
> used. This would allow username re-use.
You *could* do it by hacking getpw*(3) and including a call to
getsockname(2).
I do it by building virtual machines using a hacked inetd(8) which does a
getsockname(2) followed by a chroot(2) to the virtual machine. The vm
needs to have ld.so and lib/* etc, etc, etc. It is great for allowing
telnet access to web sites while preventing customers from peeking at
each other's stuff.
/* Daniel O'Callaghan */
/* HiLink Internet <http://www.hilink.com.au/> danny@hilink.com.au */
/* FreeBSD - works hard, plays hard... danny@freebsd.org */
From owner-freebsd-hackers Wed Oct 22 15:20:49 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA04184
for hackers-outgoing; Wed, 22 Oct 1997 15:20:49 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA04177
for <freebsd-hackers@FreeBSD.ORG>; Wed, 22 Oct 1997 15:20:44 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA02134 for freebsd-hackers@FreeBSD.ORG; Thu, 23 Oct 1997 00:20:32 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id AAA02035;
Thu, 23 Oct 1997 00:17:17 +0200 (MET DST)
Message-ID: <19971023001717.AU43421@uriah.heep.sax.de>
Date: Thu, 23 Oct 1997 00:17:17 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: freebsd-hackers@FreeBSD.ORG (FreeBSD hackers)
Subject: Re: Possible SERIOUS bug in open()?
References: <19971022190225.DV50844@uriah.heep.sax.de> <Pine.BSF.3.96.971022142133.15884B-100000@phoenix.its.rpi.edu>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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.96.971022142133.15884B-100000@phoenix.its.rpi.edu>; from David E. Cross on Oct 22, 1997 14:22:11 -0400
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As David E. Cross wrote:
> I thought that O_RDRW = O_RDONLY | O_WRONLY.
You better look at the actual values of these macros. ;-)
Inside the kernel, it's indeed this way (FREAD and FWRITE). However
in open(), O_RDONLY is 0, O_WRONLY is 1. Thus, your idea would just
yield O_WRONLY. The worse case was an attempt to use O_WRONLY|O_RDWR.
--
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 Oct 22 15:21:24 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA04252
for hackers-outgoing; Wed, 22 Oct 1997 15:21:24 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA04243
for <freebsd-hackers@FreeBSD.ORG>; Wed, 22 Oct 1997 15:21:18 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA02138 for freebsd-hackers@FreeBSD.ORG; Thu, 23 Oct 1997 00:20:47 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id AAA02047;
Thu, 23 Oct 1997 00:18:42 +0200 (MET DST)
Message-ID: <19971023001841.RF25584@uriah.heep.sax.de>
Date: Thu, 23 Oct 1997 00:18:41 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: freebsd-hackers@FreeBSD.ORG
Subject: Re: DLT drives
References: <m0xNuPI-00023GC@bert.kts.org> <199710221918.UAA02767@yedi.iaf.nl>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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: <199710221918.UAA02767@yedi.iaf.nl>; from Wilko Bulte on Oct 22, 1997 20:18:27 +0100
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Wilko Bulte wrote:
> Check out http://www.quantum.com There are something like 5 or so
> firmware personalities, e.g. also one that pretends to be an Exabyte.
Oh, i hope it doesn't jam the cassette as often as Exabytes tend to
do. :-]
--
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 Oct 22 15:21:46 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA04315
for hackers-outgoing; Wed, 22 Oct 1997 15:21:46 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA04302
for <freebsd-hackers@FreeBSD.ORG>; Wed, 22 Oct 1997 15:21:43 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA02145; Thu, 23 Oct 1997 00:21:30 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id AAA02010;
Thu, 23 Oct 1997 00:10:44 +0200 (MET DST)
Message-ID: <19971023001043.MK60020@uriah.heep.sax.de>
Date: Thu, 23 Oct 1997 00:10:43 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: freebsd-hackers@FreeBSD.ORG
Cc: cmott@srv.net (Charles Mott)
Subject: Re: Password files and virtual IP addresses
References: <Pine.BSF.3.96.971022103356.10892B-100000@darkstar.home>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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.96.971022103356.10892B-100000@darkstar.home>; from Charles Mott on Oct 22, 1997 10:43:21 -0700
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Charles Mott wrote:
> Suppose that one wanted to create different virtual
> IP addresses with ifconfig alias, and when people telnet
> or ftp or access pop3/imap2 at a virtual address, a
> password file specific to that virtual address would be
> used. This would allow username re-use.
Make a standalone telnetd that doesn't bind to INADDR_ANY, but to each
virtual address separately, and make them call different login
programs.
--
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 Oct 22 16:25:55 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id QAA08925
for hackers-outgoing; Wed, 22 Oct 1997 16:25:55 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from inspace.net (root@nova.ispace.com [207.204.40.7])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA08892;
Wed, 22 Oct 1997 16:25:43 -0700 (PDT)
(envelope-from gme@inspace.net)
Received: from caffeine (caffeine.inspace.net [207.204.40.248])
by inspace.net (8.8.6) (8.8.6) (SPAM Stopper: 3.0b2) with SMTP id TAA02620;
Wed, 22 Oct 1997 19:24:59 -0400 (EDT)
From: "George M. Ellenburg" <gme@inspace.net>
To: "Daniel O'Callaghan" <danny@panda.hilink.com.au>,
"Charles Mott" <cmott@srv.net>
Cc: <freebsd-hackers@FreeBSD.ORG>, <freebsd-isp@FreeBSD.ORG>
Subject: Re: Password files and virtual IP addresses
Date: Wed, 22 Oct 1997 19:24:20 -0400
Message-ID: <01bcdf41$9f805fb0$f828cccf@caffeine>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id QAA08901
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
What about the problem with "username re-use" with the effective UIDs of the users? Wouldn't 'webmaster@somedomain.com' and 'webmaster@anotherdomain.com' effectively have the same UID (excluding Sendmail tables/ tricks)? That is, if both users physically log in to the server with the user of 'webmaster'. How would you bypass the UIDs physically recorded in the UFS directory structure?
G.M.E.
-----Original Message-----
From: Daniel O'Callaghan <danny@panda.hilink.com.au>
To: Charles Mott <cmott@srv.net>
Cc: freebsd-hackers@FreeBSD.ORG <freebsd-hackers@FreeBSD.ORG>; freebsd-isp@FreeBSD.ORG <freebsd-isp@FreeBSD.ORG>
Date: Wednesday, October 22, 1997 7:04 PM
Subject: Re: Password files and virtual IP addresses
|
|On Wed, 22 Oct 1997, Charles Mott wrote:
|
|> Suppose that one wanted to create different virtual
|> IP addresses with ifconfig alias, and when people telnet
|> or ftp or access pop3/imap2 at a virtual address, a
|> password file specific to that virtual address would be
|> used. This would allow username re-use.
|
|You *could* do it by hacking getpw*(3) and including a call to
|getsockname(2).
|
|I do it by building virtual machines using a hacked inetd(8) which does a
|getsockname(2) followed by a chroot(2) to the virtual machine. The vm
|needs to have ld.so and lib/* etc, etc, etc. It is great for allowing
|telnet access to web sites while preventing customers from peeking at
|each other's stuff.
|
|
|/* Daniel O'Callaghan */
|/* HiLink Internet <http://www.hilink.com.au/> danny@hilink.com.au */
|/* FreeBSD - works hard, plays hard... danny@freebsd.org */
|
|
|
From owner-freebsd-hackers Wed Oct 22 16:45:03 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id QAA10051
for hackers-outgoing; Wed, 22 Oct 1997 16:45:03 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA10038;
Wed, 22 Oct 1997 16:44:58 -0700 (PDT)
(envelope-from danny@panda.hilink.com.au)
Received: (from danny@localhost)
by panda.hilink.com.au (8.8.5/8.8.5) id JAA13299;
Thu, 23 Oct 1997 09:44:14 +1000 (EST)
Date: Thu, 23 Oct 1997 09:44:14 +1000 (EST)
From: "Daniel O'Callaghan" <danny@panda.hilink.com.au>
To: "George M. Ellenburg" <gme@inspace.net>
cc: Charles Mott <cmott@srv.net>, freebsd-hackers@FreeBSD.ORG,
freebsd-isp@FreeBSD.ORG
Subject: Re: Password files and virtual IP addresses
In-Reply-To: <01bcdf41$9f805fb0$f828cccf@caffeine>
Message-ID: <Pine.BSF.3.91.971023093155.524P-100000@panda.hilink.com.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Wed, 22 Oct 1997, George M. Ellenburg wrote:
> |
> |I do it by building virtual machines using a hacked inetd(8) which does a
> |getsockname(2) followed by a chroot(2) to the virtual machine. The vm
> |needs to have ld.so and lib/* etc, etc, etc. It is great for allowing
> |telnet access to web sites while preventing customers from peeking at
> |each other's stuff.
> What about the problem with "username re-use" with the effective UIDs of
> the users? Wouldn't 'webmaster@somedomain.com' and
> 'webmaster@anotherdomain.com' effectively have the same UID (excluding
> Sendmail tables/ tricks)? That is, if both users physically log in to the
> server with the user of 'webmaster'. How would you bypass the UIDs
> physically recorded in the UFS directory structure?
No. You have separate /etc directories for each vm and you can use
different uids. Even if the uid is the same from one vm to another, how
much does it matter? It only matters in that you, the sysadmin, can't
tell who owns a file specifically without doing a pwd to find out which
vm you are in.
Danny
From owner-freebsd-hackers Wed Oct 22 17:02:16 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id RAA11153
for hackers-outgoing; Wed, 22 Oct 1997 17:02:16 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from misery.sdf.com (misery.sdf.com [204.244.210.193])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA11148
for <hackers@freebsd.org>; Wed, 22 Oct 1997 17:02:13 -0700 (PDT)
(envelope-from tom@sdf.com)
Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1)
id 0xOAhG-0003ar-00; Wed, 22 Oct 1997 17:00:18 -0700
Date: Wed, 22 Oct 1997 17:00:13 -0700 (PDT)
From: Tom <tom@sdf.com>
To: Steve Sims <SimsS@IBM.Net>
cc: "'hackers@freebsd.org'" <hackers@freebsd.org>
Subject: Re: SMP P-Pro MoBo - Recommendations?
In-Reply-To: <01BCDEFA.1F723560.SimsS@IBM.Net>
Message-ID: <Pine.BSF.3.95q.971022165754.13801B-100000@misery.sdf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
On Wed, 22 Oct 1997, Steve Sims wrote:
> I know this is a rehash of a thread from a couple of months ago, but.....
>
> I'm thinking of plopping a dual P-Pro motherboard in my overstressed
> P5/120.
ASUS has a nice dual-PPro board. The CPUs are on a daughter-card. You
can get dual-P5, dual-P6, and dual-PII daughtercards (there is only one
daughtercard slot). I've got two of these in 24x7 servers. Work well.
Tom
From owner-freebsd-hackers Wed Oct 22 17:36:35 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id RAA13560
for hackers-outgoing; Wed, 22 Oct 1997 17:36:35 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA13554
for <hackers@freebsd.org>; Wed, 22 Oct 1997 17:36:32 -0700 (PDT)
(envelope-from mrcpu@cdsnet.net)
Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5])
by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id RAA28141
for <hackers@freebsd.org>; Wed, 22 Oct 1997 17:36:24 -0700 (PDT)
Date: Wed, 22 Oct 1997 17:36:24 -0700 (PDT)
From: Jaye Mathisen <mrcpu@cdsnet.net>
To: hackers@freebsd.org
Subject: Locking process 0, and vm_page_alloc errors.
Message-ID: <Pine.NEB.3.95.971022173303.27699G-100000@mail.cdsnet.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I just upgraded to 2.2.5, supped a couple of days ago.
I'm getting the following on the console:
Oct 22 17:30:59 chop /kernel: pid 15918 (perl), uid 170, was killed: out
of swap space
Oct 22 17:31:04 chop /kernel: locking by process 0
Oct 22 17:31:05 chop last message repeated 3 times
Oct 22 17:31:17 chop /kernel: vm_page_alloc(ZERO): missing pages on cache
queue: 2
Yet pstat -s shows:
Device 1K-blocks Used Avail Capacity Type
/dev/sd0b 262144 215844 46236 82% Interleaved
/dev/?? 64000 61752 2184 97% Interleaved
Total 326016 277596 48420 85%
/dev/?? is a vn0b swap file. (I don't know why the ?? is there).
As I see it, there should be plenty of swap space, so I'm not sure what's
happening.
Also, the vm_page_alloc(ZERO) messages are a bit disconcerting.
Any ideas appreciated.
From owner-freebsd-hackers Wed Oct 22 18:24:51 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA17267
for hackers-outgoing; Wed, 22 Oct 1997 18:24:51 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from earth.mat.net (earth.mat.net [206.246.122.2])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA17260
for <hackers@FreeBSD.ORG>; Wed, 22 Oct 1997 18:24:47 -0700 (PDT)
(envelope-from chuckr@glue.umd.edu)
Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by earth.mat.net (8.8.7/8.6.12) with SMTP id VAA18826; Wed, 22 Oct 1997 21:23:51 -0400 (EDT)
Date: Wed, 22 Oct 1997 20:23:29 -0400 (EDT)
From: Chuck Robey <chuckr@glue.umd.edu>
X-Sender: chuckr@picnic.mat.net
To: Tom <tom@sdf.com>
cc: Steve Sims <SimsS@ibm.net>, "'hackers@freebsd.org'" <hackers@FreeBSD.ORG>
Subject: Re: SMP P-Pro MoBo - Recommendations?
In-Reply-To: <Pine.BSF.3.95q.971022165754.13801B-100000@misery.sdf.com>
Message-ID: <Pine.BSF.3.96.971022202152.13098N-100000@picnic.mat.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Wed, 22 Oct 1997, Tom wrote:
>
> On Wed, 22 Oct 1997, Steve Sims wrote:
>
> > I know this is a rehash of a thread from a couple of months ago, but.....
> >
> > I'm thinking of plopping a dual P-Pro motherboard in my overstressed
> > P5/120.
>
> ASUS has a nice dual-PPro board. The CPUs are on a daughter-card. You
> can get dual-P5, dual-P6, and dual-PII daughtercards (there is only one
> daughtercard slot). I've got two of these in 24x7 servers. Work well.
I don't doubt it's good, but it seemed to me to be nearly twice the cost
of the Tyan Titan that I settled on, for no difference in performance.
The Tyan Titan didn't use the motherboard, and I thin maybe that's the
largest reason for the higher cost. Either that, or maybe I didn't search
out the lowest cost ...
>
> Tom
>
>
>
>
----------------------------+-----------------------------------------------
Chuck Robey | Interests include any kind of voice or data
chuckr@glue.umd.edu | communications topic, C programming, and Unix.
213 Lakeside Drive Apt T-1 |
Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD
(301) 220-2114 | version 3.0 current -- and great FUN!
----------------------------+-----------------------------------------------
From owner-freebsd-hackers Wed Oct 22 19:11:19 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA20094
for hackers-outgoing; Wed, 22 Oct 1997 19:11:19 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from misery.sdf.com (misery.sdf.com [204.244.210.193])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA20087
for <hackers@freebsd.org>; Wed, 22 Oct 1997 19:11:15 -0700 (PDT)
(envelope-from tom@sdf.com)
Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1)
id 0xOCiD-0003eF-00; Wed, 22 Oct 1997 19:09:26 -0700
Date: Wed, 22 Oct 1997 19:09:23 -0700 (PDT)
From: Tom <tom@sdf.com>
To: Chuck Robey <chuckr@glue.umd.edu>
cc: Steve Sims <SimsS@ibm.net>, "'hackers@freebsd.org'" <hackers@freebsd.org>
Subject: Re: SMP P-Pro MoBo - Recommendations?
In-Reply-To: <Pine.BSF.3.96.971022202152.13098N-100000@picnic.mat.net>
Message-ID: <Pine.BSF.3.95q.971022190530.13968A-100000@misery.sdf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
On Wed, 22 Oct 1997, Chuck Robey wrote:
> On Wed, 22 Oct 1997, Tom wrote:
>
> > On Wed, 22 Oct 1997, Steve Sims wrote:
> >
> > > I know this is a rehash of a thread from a couple of months ago, but.....
> > >
> > > I'm thinking of plopping a dual P-Pro motherboard in my overstressed
> > > P5/120.
> >
> > ASUS has a nice dual-PPro board. The CPUs are on a daughter-card. You
> > can get dual-P5, dual-P6, and dual-PII daughtercards (there is only one
> > daughtercard slot). I've got two of these in 24x7 servers. Work well.
>
> I don't doubt it's good, but it seemed to me to be nearly twice the cost
> of the Tyan Titan that I settled on, for no difference in performance.
> The Tyan Titan didn't use the motherboard, and I thin maybe that's the
> largest reason for the higher cost. Either that, or maybe I didn't search
> out the lowest cost ...
Which Tyan Titan? I see about 9 different Titan boards.
I find the cost difference kind of hard to believe, but I get a pretty
good deal on ASUS stuff when buying from Supercom.
The daughtercard thing is pretty cool. If the system ever needs a bit
more kick, just put in the PII/300. Downtime is minimal, as you don't
have to remove the motherboad to install a different daughtercard. I wish
ASUS made a motherboard with two daughtercard slots, and up to 4 CPUs.
Tom
From owner-freebsd-hackers Wed Oct 22 19:20:28 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA20582
for hackers-outgoing; Wed, 22 Oct 1997 19:20:28 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from elvis.vnet.net (elvis.vnet.net [166.82.1.5])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA20575
for <freebsd-hackers@freefall.FreeBSD.org>; Wed, 22 Oct 1997 19:20:20 -0700 (PDT)
(envelope-from rivers@dignus.com)
Received: from ponds.dignus.com (ponds.vnet.net [166.82.177.48])
by elvis.vnet.net (8.8.5/8.8.4) with ESMTP
id WAA07318; Wed, 22 Oct 1997 22:20:07 -0400 (EDT)
Received: from lakes.dignus.com (lakes [10.0.0.3])
by ponds.dignus.com (8.8.5/8.8.5) with ESMTP id TAA01761;
Wed, 22 Oct 1997 19:52:48 -0400 (EDT)
Received: (from rivers@localhost) by lakes.dignus.com (8.8.5/8.6.9) id TAA05037; Wed, 22 Oct 1997 19:41:57 -0400 (EDT)
Date: Wed, 22 Oct 1997 19:41:57 -0400 (EDT)
From: Thomas David Rivers <rivers@dignus.com>
Message-Id: <199710222341.TAA05037@lakes.dignus.com>
To: freebsd-hackers@freefall.FreeBSD.org, joerg_wunsch@uriah.heep.sax.de
Subject: Re: Possible SERIOUS bug in open()?
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
J"org writes:
> As Jamil J. Weatherbee wrote:
>
> > > > This was sent to me recently... It seems to be a pretty serious hole
> > > > in open() and permissions...
> > >
> > > Fixed.
> >
> > How exactly did you fix it, this is related to what I was saying about
> > opening a file as RD_ONLY and WR_ONLY, ...
>
> Yep, this was in the same boat. The way the fix works, only one of
> O_RDONLY, O_WRONLY, or O_RDWR should be possible now, and anything
> else should be rejected as EINVAL.
>
> --
> cheers, J"org
Umm... I don't know the answer to this; it's just a thought I had.
Couldn't you do something like:
f = open("name", 0);
if(f>0) {
/* file exists... */
} else {
/* file doesn't exist. */
}
to see if the file exists? (You should use stat(), or access, but I'm
just devil's advocate here...) Or, are the semantics for that simply not
defined? What do other operating systems do in this case?
- Dave Rivers -
From owner-freebsd-hackers Wed Oct 22 19:25:14 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA20996
for hackers-outgoing; Wed, 22 Oct 1997 19:25:14 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from elvis.vnet.net (elvis.vnet.net [166.82.1.5])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA20991
for <freebsd-hackers@freefall.FreeBSD.org>; Wed, 22 Oct 1997 19:25:11 -0700 (PDT)
(envelope-from rivers@dignus.com)
Received: from ponds.dignus.com (ponds.vnet.net [166.82.177.48])
by elvis.vnet.net (8.8.5/8.8.4) with ESMTP
id WAA07304; Wed, 22 Oct 1997 22:20:03 -0400 (EDT)
Received: from lakes.dignus.com (lakes [10.0.0.3])
by ponds.dignus.com (8.8.5/8.8.5) with ESMTP id TAA01778;
Wed, 22 Oct 1997 19:59:53 -0400 (EDT)
Received: (from rivers@localhost) by lakes.dignus.com (8.8.5/8.6.9) id TAA05113; Wed, 22 Oct 1997 19:49:02 -0400 (EDT)
Date: Wed, 22 Oct 1997 19:49:02 -0400 (EDT)
From: Thomas David Rivers <rivers@dignus.com>
Message-Id: <199710222349.TAA05113@lakes.dignus.com>
To: freebsd-hackers@freefall.FreeBSD.org, joerg_wunsch@uriah.heep.sax.de
Subject: Re: Possible SERIOUS bug in open()?
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Well - to answer my own question:
f = open("name", 0)
would be the same as
f = open("name", O_RDONLY)
(since O_RDONLY is defined as 0x0000)....
So - please ignore the previous drivel....
- Dave Rivers -
From owner-freebsd-hackers Wed Oct 22 19:35:12 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA21691
for hackers-outgoing; Wed, 22 Oct 1997 19:35:12 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from elvis.mu.org (paul@elvis.mu.org [206.156.231.253])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA21679
for <freebsd-hackers@freebsd.org>; Wed, 22 Oct 1997 19:35:08 -0700 (PDT)
(envelope-from paul@elvis.mu.org)
Received: (from paul@localhost)
by elvis.mu.org (4.1/4.1) id VAA00538
for freebsd-hackers@freebsd.org; Wed, 22 Oct 1997 21:34:58 -0500 (CDT)
From: Paul Saab <paul@mu.org>
Message-Id: <199710230234.VAA00538@elvis.mu.org>
Subject: page fault
To: freebsd-hackers@freebsd.org
Date: Wed, 22 Oct 1997 21:34:58 -0500 (CDT)
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Hello,
I have a PPRO 200 that is running FreeBSD 2.2.2-RELEASE. This
machine has been running flawlessly for months now but today I had
a spontaneous reboot of the machine and when I came to the console
savecore reported that there was a page fault and then it proceeded
to save the stuff to /var/crash. My question is without debugging
symbols it is not possible to find out what caused the crash is
it?
There is nothing in the syslog to tell me what happened so I am
kind of baffled.
Thanks,
Paul
From owner-freebsd-hackers Wed Oct 22 21:16:13 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id VAA26430
for hackers-outgoing; Wed, 22 Oct 1997 21:16:13 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from netroplex.com (ns1.netroplex.com [206.171.95.130])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA26422
for <hackers@freebsd.org>; Wed, 22 Oct 1997 21:16:05 -0700 (PDT)
(envelope-from info@pagecreators.com)
Received: from awd (max008-34.netroplex.com [207.212.27.34]) by netroplex.com (8.8.5/8.8.2) with ESMTP id VAA07867 for <hackers@freebsd.org>; Wed, 22 Oct 1997 21:17:31 -0700 (PDT)
Message-ID: <344ECE3F.846776A7@pagecreators.com>
Date: Wed, 22 Oct 1997 21:10:39 -0700
From: Rod Ebrahimi <info@pagecreators.com>
X-Mailer: Mozilla 4.01 [en] (Win95; I)
MIME-Version: 1.0
To: hackers@freebsd.org
Subject: Upgrade
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I have read the install notes and still am unclear on the best
method of upgrading from 2.2.2 to 2.2.5 with little change of our source
configuration. Any help would be greatly appreciated.
Thank you,
Rod
From owner-freebsd-hackers Wed Oct 22 21:57:39 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id VAA28566
for hackers-outgoing; Wed, 22 Oct 1997 21:57:39 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA28559
for <freebsd-hackers@freebsd.org>; Wed, 22 Oct 1997 21:57:37 -0700 (PDT)
(envelope-from henrich@crh.cl.msu.edu)
Received: (from henrich@localhost)
by crh.cl.msu.edu (8.8.5/8.8.5) id AAA05508;
Thu, 23 Oct 1997 00:57:35 -0400 (EDT)
Message-ID: <19971023005735.38504@crh.cl.msu.edu>
Date: Thu, 23 Oct 1997 00:57:35 -0400
From: Charles Henrich <henrich@crh.cl.msu.edu>
To: freebsd-hackers@freebsd.org
Subject: de0 errors
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84
X-Operating-System: FreeBSD 2.2.2-RELEASE
X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
After moving to 2.2.5-RELEASE im seeing:
Oct 23 00:32:12 msunews /kernel: ccd0-3: Concatenated disk drivers
Oct 23 00:35:45 msunews /kernel: de0: abnormal interrupt: transmit underflow
(raising TX threshold to 96|256)
Oct 23 00:36:01 msunews /kernel: de0: abnormal interrupt: transmit underflow
(raising TX threshold to 8|512)
Oct 23 00:37:41 msunews /kernel: de0: abnormal interrupt: transmit underflow
(raising TX threshold to 1024)
Oct 23 00:55:14 msunews /kernel: de0: abnormal interrupt: transmit underflow
(switching to store-and-forward mode)
Any ideas? Are these informational, or are they bad?
-Crh
Charles Henrich Michigan State University henrich@msu.edu
http://pilot.msu.edu/~henrich
From owner-freebsd-hackers Thu Oct 23 00:06:56 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id AAA04284
for hackers-outgoing; Thu, 23 Oct 1997 00:06:56 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA04276
for <freebsd-hackers@freebsd.org>; Thu, 23 Oct 1997 00:06:52 -0700 (PDT)
(envelope-from henrich@crh.cl.msu.edu)
Received: (from henrich@localhost)
by crh.cl.msu.edu (8.8.5/8.8.5) id DAA06751;
Thu, 23 Oct 1997 03:06:51 -0400 (EDT)
Message-ID: <19971023030651.02177@crh.cl.msu.edu>
Date: Thu, 23 Oct 1997 03:06:51 -0400
From: Charles Henrich <henrich@crh.cl.msu.edu>
To: freebsd-hackers@freebsd.org
Subject: CHILD_MAX no longer valid in 2.2.5-RELEASE?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84
X-Operating-System: FreeBSD 2.2.2-RELEASE
X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I've send CHILD_MAX to 512 on my news server, which (used) to have the effect
of making the default maximum procs set to 512.. Bonus. Under 2.2.5-RELEASE
it doesnt appear to be having any effect :( The only thing I can think of is,
its placement in the config file is order important, or its no longer
supported? If the latter, how do you effect the same change in 2.2.5?
-Crh
Charles Henrich Michigan State University henrich@msu.edu
http://pilot.msu.edu/~henrich
From owner-freebsd-hackers Thu Oct 23 00:09:30 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id AAA04459
for hackers-outgoing; Thu, 23 Oct 1997 00:09:30 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA04453
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 00:09:28 -0700 (PDT)
(envelope-from mrcpu@cdsnet.net)
Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5])
by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id AAA14794;
Thu, 23 Oct 1997 00:08:45 -0700 (PDT)
Date: Thu, 23 Oct 1997 00:08:45 -0700 (PDT)
From: Jaye Mathisen <mrcpu@cdsnet.net>
To: Charles Henrich <henrich@crh.cl.msu.edu>
cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: de0 errors
In-Reply-To: <19971023005735.38504@crh.cl.msu.edu>
Message-ID: <Pine.NEB.3.95.971023000811.7603F-100000@mail.cdsnet.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
I am getting these as well in droves. I notice it especially when the
machine is serving NFS files.
2.2.5-BETA, supped 10/21/97.
On Thu, 23 Oct 1997, Charles Henrich wrote:
> After moving to 2.2.5-RELEASE im seeing:
>
> Oct 23 00:32:12 msunews /kernel: ccd0-3: Concatenated disk drivers
> Oct 23 00:35:45 msunews /kernel: de0: abnormal interrupt: transmit underflow
> (raising TX threshold to 96|256)
> Oct 23 00:36:01 msunews /kernel: de0: abnormal interrupt: transmit underflow
> (raising TX threshold to 8|512)
> Oct 23 00:37:41 msunews /kernel: de0: abnormal interrupt: transmit underflow
> (raising TX threshold to 1024)
> Oct 23 00:55:14 msunews /kernel: de0: abnormal interrupt: transmit underflow
> (switching to store-and-forward mode)
>
> Any ideas? Are these informational, or are they bad?
>
> -Crh
>
> Charles Henrich Michigan State University henrich@msu.edu
>
> http://pilot.msu.edu/~henrich
>
From owner-freebsd-hackers Thu Oct 23 00:33:46 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id AAA06199
for hackers-outgoing; Thu, 23 Oct 1997 00:33:46 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA06192
for <hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 00:33:37 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA07307 for hackers@FreeBSD.ORG; Thu, 23 Oct 1997 09:33:35 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id JAA04206;
Thu, 23 Oct 1997 09:28:48 +0200 (MET DST)
Message-ID: <19971023092847.TP39265@uriah.heep.sax.de>
Date: Thu, 23 Oct 1997 09:28:47 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: hackers@FreeBSD.ORG
Subject: Re: ACLs [Was: C2 Trusted FreeBSD?]
References: <19971021205331.53826@worldgate.com> <199710230105.TAA13328@xmission.xmission.com>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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: <199710230105.TAA13328@xmission.xmission.com>; from Wes Peters - Softweyr LLC on Oct 22, 1997 19:05:39 -0600
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
(Moved back to -hackers, it's technicall stuff.)
As Wes Peters - Softweyr LLC wrote:
> Yes, but how do you back them up, or, worse yet, restore them? How do
> you copy your HTML directory tree to another drive you're bringing
> on-line and preserve all the ACL settings? As noted before, *none*
> of the system tools support the ACLs.
I think you could make compatible changes to dump and restore to
support ACLs. Perhaps, drop a second record containing the ACLs right
behind an inode record (or even before, so the restore program knows
about the intended ACLs before actually even seeing the inode
information). The unknown records should simply be ignored by a
restore that doesn't understand them.
I once thought about extending dump to support gzip'ed files as well,
but never got around to actually do it. The idea is to invent a new
flag for the gzip'ed stored files, and then store the filename(s) as
`originalname.gz'. If the archive goes on to a restore that doesn't
understand the extension, it would extract the files with the new .gz
suffix, so not all is lost. If the archive goes on to a restore that
does understand the extension, it can decompress on the fly, and
restore the original filename(s). Files that did already have the
suffix .gz simply don't set the flag when being archived, and go to
the tape verbatim.
--
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 Oct 23 00:33:59 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id AAA06238
for hackers-outgoing; Thu, 23 Oct 1997 00:33:59 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA06225
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 00:33:54 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA07309; Thu, 23 Oct 1997 09:33:45 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id JAA04218;
Thu, 23 Oct 1997 09:32:20 +0200 (MET DST)
Message-ID: <19971023093219.WB10314@uriah.heep.sax.de>
Date: Thu, 23 Oct 1997 09:32:19 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: freebsd-hackers@FreeBSD.ORG
Cc: paul@mu.org (Paul Saab)
Subject: Re: page fault
References: <199710230234.VAA00538@elvis.mu.org>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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: <199710230234.VAA00538@elvis.mu.org>; from Paul Saab on Oct 22, 1997 21:34:58 -0500
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Paul Saab wrote:
> My question is without debugging
> symbols it is not possible to find out what caused the crash is
> it?
Even without debugging symbols, the kernel usually has the default
symbol table, so you could find out in which function it happened. My
normal way of analyzation is then to recompile parts of the kernel
(the interesting parts according to the stacktrace) with -g, and have
a closer look at them. Fortunately, gcc usually produces the same
code with or without -g, provided the -O etc. flags remain the same.
Hava a look at the section about kernel debugging in the handbook.
--
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 Oct 23 00:36:56 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id AAA06513
for hackers-outgoing; Thu, 23 Oct 1997 00:36:56 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA06508
for <freebsd-hackers@freefall.FreeBSD.org>; Thu, 23 Oct 1997 00:36:53 -0700 (PDT)
(envelope-from kuku@gilberto.physik.RWTH-Aachen.DE)
Received: from gil.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.30.2]) by Campino.Informatik.RWTH-Aachen.DE (8.8.7/RBI-Z13)
with ESMTP id JAA04952 for <freebsd-hackers@freefall.FreeBSD.org>; Thu, 23 Oct 1997 09:36:20 +0200 (MET DST)
Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.8.5/8.6.9) id JAA13974 for freebsd-hackers@freefall.cdrom.com; Thu, 23 Oct 1997 09:46:58 +0200 (MEST)
Date: Thu, 23 Oct 1997 09:46:58 +0200 (MEST)
From: Christoph Kukulies <kuku@gilberto.physik.RWTH-Aachen.DE>
Message-Id: <199710230746.JAA13974@gil.physik.rwth-aachen.de>
To: freebsd-hackers@freefall.FreeBSD.org
Subject: need help in ISA memory mapping
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
I have an industrial controller card (ISA) which has an
ISA memory window (0xc8000-0xcffff e.g.).
A user program should be able to directly read/write into these memory
locations via a pointer (byte or word). Is there a way tp 'map'
this into a user address space? Is it possible at all?
I can use the isa_dev structure in the kernel driver (I have written
a minimum driver that probes the card) but this only works in kernel
mode.
I thoughht of opening /dev/mem but that appears to be handled like a
file and operationg via a pointer seems weird. Even weirder when
I thing of mmapping that file.
Any ideas?
--
Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de
From owner-freebsd-hackers Thu Oct 23 00:54:49 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id AAA07316
for hackers-outgoing; Thu, 23 Oct 1997 00:54:49 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA07305
for <hackers@freebsd.org>; Thu, 23 Oct 1997 00:54:34 -0700 (PDT)
(envelope-from luigi@labinfo.iet.unipi.it)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id HAA26030; Thu, 23 Oct 1997 07:38:27 +0100
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199710230638.HAA26030@labinfo.iet.unipi.it>
Subject: zipfs filesystem anyone ?
To: hackers@freebsd.org
Date: Thu, 23 Oct 1997 07:38:26 +0100 (MET)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I was thinking of possible solutions for implementing a "zip file
system", ie a method to access pieces of a compressed archive as if they
were mounted in the filesystem [see Note 1 and 2]
Basically I would like to do something like
vnconfig /dev/vn0 /usr/distfiles/ports.zip
mount -t zipfs /dev/vn0 /usr/ports
The obvious approach of creating a new filesystem type is not very
attractive though, for the complexity involved in this work and
also for debugging purposes.
Thus, I was looking at something which would pass all filesystem
(or vn ?) calls to some user-space process which could then handle
them properly. Using this approach, little modifications to, say,
a standard "unzip" program, would permit such a filesystem to be
implemented relatively easily. Efficiency is not a major concern
for this type of application (especially because the typical use
would be sequential access to files).
I have been looking at the portal filesystem, but this only provides
an "open" service, i.e. only the open() call is passed to the user-space
process.
So I think my only choice is to try a merge of the "portal" and
"nullfs" filesystem to build the thing I need. But maybe such
implementations already exist, in some form or some other ?
NOTE 1: Motivation
The motivation for this is relatively simple. Many times one needs to
browse through things like a software package, which are available as
a compressed archive. The common approach is to extract the archive to
the filesystem and then use the file. But this approach tends to leave
garbage on your disk, and is time-consuming (ever noticed how slow is
to extract ports.tgz with its thousands of files and directories ?).
NOTE 2: Why ZIP and not .tar.gz
Implementing such a "filesystem" in user space is much easier if the
directory structure is directly available in the archive, rather than
being scattered all around and mixed with data. gzipped tar files have
this problem: you need to decompress data before being able to use
them. Conversely, I think zip archives have the directory structure in
clear and so it is easier to move through the tree, and decompression
is only necessary on the single components.
Cheers
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 Oct 23 01:00:23 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id BAA07773
for hackers-outgoing; Thu, 23 Oct 1997 01:00:23 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA07751;
Thu, 23 Oct 1997 01:00:17 -0700 (PDT)
(envelope-from julian@whistle.com)
Received: (from daemon@localhost)
by alpo.whistle.com (8.8.5/8.8.5) id AAA07182;
Thu, 23 Oct 1997 00:54:56 -0700 (PDT)
Received: from current1.whistle.com(207.76.205.22)
via SMTP by alpo.whistle.com, id smtpd007180; Thu Oct 23 07:54:55 1997
Date: Thu, 23 Oct 1997 00:53:22 -0700 (PDT)
From: Julian Elischer <julian@whistle.com>
To: Charles Mott <cmott@srv.net>
cc: freebsd-hackers@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG
Subject: Re: Password files and virtual IP addresses
In-Reply-To: <Pine.BSF.3.96.971022103356.10892B-100000@darkstar.home>
Message-ID: <Pine.BSF.3.95.971023005117.23413D-100000@current1.whistle.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
We have a whole virtual machine
using chroot, and a few other tricks such as a hacked inetd.
It was described recently on either hackers or questions (I forget which)
by Doug Ambrisko. (I think it was questions)
julian
On Wed, 22 Oct 1997, Charles Mott wrote:
> Suppose that one wanted to create different virtual
> IP addresses with ifconfig alias, and when people telnet
> or ftp or access pop3/imap2 at a virtual address, a
> password file specific to that virtual address would be
> used. This would allow username re-use.
>
> Has this sort of thing been considered before? If not,
> what sort of things would have to be hacked? If password
> access routines could somehow be informed what virtual
> address they were being accessed from, then it would
> be possible to have multiple password files.
>
> Of course, there are always unintended security
> implications to doing these things...
>
> Charles Mott
>
>
From owner-freebsd-hackers Thu Oct 23 01:57:11 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id BAA11712
for hackers-outgoing; Thu, 23 Oct 1997 01:57:11 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA11687;
Thu, 23 Oct 1997 01:57:05 -0700 (PDT)
(envelope-from bde@zeta.org.au)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id SAA29257; Thu, 23 Oct 1997 18:53:26 +1000
Date: Thu, 23 Oct 1997 18:53:26 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199710230853.SAA29257@godzilla.zeta.org.au>
To: freebsd-hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, joes@seaport.net
Subject: Re: Interesting behaviour from sysctl(kern.boottime)
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
>But, I've come to notice the following: (five executions worth of data:)
>
>----------------- cut here --------------
>System time is (877528801) Wed Oct 22 07:00:01 1997
>System Booted at (877407594) Mon Oct 20 21:19:54 1997
> ^^^^^^^^^^^^^^^^^^^
>Difference is: 121207 seconds
>-----
>System time is (877532401) Wed Oct 22 08:00:01 1997
>System Booted at (877407591) Mon Oct 20 21:19:51 1997
> ^^^^^^^^^^^^^^^^^^^
>Difference is: 124810 seconds
>-----
>...
>I run xntpd. Could that be a factor? (updating the clock ticks or whatever?)
Yes, it changes the boot time whenever it calls settimeofday() to step
the clock. settimeofday() always adjusts `boottime' when it adjust
`time'. This is correct when both were wrong originally, but completely
wrong if the clock has drifted. A drift of 3 seconds per day is good
if xntpd is _not_ used, but xntpd not step the clock if it is correctly
configured and the system is always connected.
Bruce
From owner-freebsd-hackers Thu Oct 23 02:04:00 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id CAA12496
for hackers-outgoing; Thu, 23 Oct 1997 02:04:00 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from ns2.accesscom.com (ns2.accesscom.com [205.226.156.3])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA12468
for <hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 02:03:49 -0700 (PDT)
(envelope-from reneem@ns2.accesscom.com)
From: reneem@ns2.accesscom.com
Received: from Default (user8.accesscom.com [205.226.158.8])
by ns2.accesscom.com (8.8.7/8.8.7) with SMTP id CAA09181
for <hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 02:03:47 -0700
Message-Id: <199710230903.CAA09181@ns2.accesscom.com>
To: reneem@accesscom.com
Date: Thu, 23 Oct 1997 02:02:39 PDT
Subject: Pre-launch Opportunity
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
This message is being brought to you by EMAIL BLASTER 2.5 software. If you would like a FREE copy of this software or any of our other HOT programs ABSOLTELY FREE call our FAX ON DEMAND number at 213-960-7822.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dear: Friend
Promotors needed for a unique new program in pre-launch. Get in now at the very top, don't let this one
pass you by. Recruit other promotors and customers. The product and the program are something you will not find anywhere else on the web. We offer free expert information. That's right, in the privacy of
your own home you can have an expert respond with an answer, all for FREE!! Our experts are trained
professionals. Lawyers, Doctors, Accountants, Real Estate and Banking just to name a few, there are
many other professions covered also.
Now, how hard can it be to recruit promotors and customers for a FREE service like this? This is a
win/win program. Now is the time to join us and tell all your friends about this too.
If you would like more information on this FREE opportunity please e-mail me at the following:
reneem@accesscom.com
Thank you for your time and please forgive me if this e-mail has caused you any inconvience.
From owner-freebsd-hackers Thu Oct 23 02:19:42 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id CAA13490
for hackers-outgoing; Thu, 23 Oct 1997 02:19:42 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA13473;
Thu, 23 Oct 1997 02:19:37 -0700 (PDT)
(envelope-from gdonl@tsc.tdk.com)
Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191])
by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP
id CAA19877; Thu, 23 Oct 1997 02:19:26 -0700 (PDT)
Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194])
by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id CAA19407;
Thu, 23 Oct 1997 02:19:25 -0700 (PDT)
Received: (from gdonl@localhost)
by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id CAA13620;
Thu, 23 Oct 1997 02:19:24 -0700 (PDT)
From: Don Lewis <Don.Lewis@tsc.tdk.com>
Message-Id: <199710230919.CAA13620@salsa.gv.tsc.tdk.com>
Date: Thu, 23 Oct 1997 02:19:24 -0700
In-Reply-To: "Daniel O'Callaghan" <danny@panda.hilink.com.au>
"Re: Password files and virtual IP addresses" (Oct 23, 9:44am)
X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95)
To: "Daniel O'Callaghan" <danny@panda.hilink.com.au>,
"George M. Ellenburg" <gme@inspace.net>
Subject: Re: Password files and virtual IP addresses
Cc: Charles Mott <cmott@srv.net>, freebsd-hackers@FreeBSD.ORG,
freebsd-isp@FreeBSD.ORG
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Oct 23, 9:44am, "Daniel O'Callaghan" wrote:
} Subject: Re: Password files and virtual IP addresses
} Even if the uid is the same from one vm to another, how
} much does it matter?
How do you keep users with the same uid's in different vm's from killing
each others processes? What about ps?
From owner-freebsd-hackers Thu Oct 23 02:55:36 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id CAA15319
for hackers-outgoing; Thu, 23 Oct 1997 02:55:36 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA15312
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 02:55:34 -0700 (PDT)
(envelope-from gdonl@tsc.tdk.com)
Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191])
by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP
id CAA20070; Thu, 23 Oct 1997 02:55:31 -0700 (PDT)
Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194])
by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id CAA20001;
Thu, 23 Oct 1997 02:55:30 -0700 (PDT)
Received: (from gdonl@localhost)
by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id CAA13696;
Thu, 23 Oct 1997 02:55:29 -0700 (PDT)
From: Don Lewis <Don.Lewis@tsc.tdk.com>
Message-Id: <199710230955.CAA13696@salsa.gv.tsc.tdk.com>
Date: Thu, 23 Oct 1997 02:55:29 -0700
In-Reply-To: Charles Henrich <henrich@crh.cl.msu.edu>
"de0 errors" (Oct 23, 12:57am)
X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95)
To: Charles Henrich <henrich@crh.cl.msu.edu>, freebsd-hackers@FreeBSD.ORG
Subject: Re: de0 errors
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Oct 23, 12:57am, Charles Henrich wrote:
} Subject: de0 errors
} After moving to 2.2.5-RELEASE im seeing:
}
} Oct 23 00:32:12 msunews /kernel: ccd0-3: Concatenated disk drivers
} Oct 23 00:35:45 msunews /kernel: de0: abnormal interrupt: transmit underflow
} (raising TX threshold to 96|256)
} Oct 23 00:36:01 msunews /kernel: de0: abnormal interrupt: transmit underflow
} (raising TX threshold to 8|512)
} Oct 23 00:37:41 msunews /kernel: de0: abnormal interrupt: transmit underflow
} (raising TX threshold to 1024)
} Oct 23 00:55:14 msunews /kernel: de0: abnormal interrupt: transmit underflow
} (switching to store-and-forward mode)
The 2114x chips have an internal FIFO into which they load transmit data
before sending the packet. To cut down on latency and increase performance,
they don't require that the entire packet be loaded into the FIFO before
starting transmission. There are a couple of bits in a control register
to tell the 2114x how much data to load before starting, and their meaning
is adjusted by another control bit that is supposed to indicate the
transmission speed that adjusts the values. In 10Mb mode, the threshold
values before transmission starts are 72, 96, 128, and 160 bytes. In
100Mb mode, the values are 128, 256, 512, and 1024 bytes. The threshold
has to be set large enough so that the 2114x won't run out of data to
transmit even if there are delays in transferring data across the PCI
bus, since you can't pause the transmission of a packet to wait for the
rest of the data to arrive. Since the FIFO drains faster at 100Mb, the
threshold values are larger in that mode. There's also another control
bit to force the 2114x to load the entire packet into the FIFO before
starting to transmit, which will guarantee that it won't run out of data.
Depending on the card, it is possible for the PHY chip to automatically
sense the network speed so that it can communicate with the network. This
will automatically set the data rate into and out of the 2114x. Since
there are so many different variations of 2114x-based cards the driver
may not be able to always correctly detect the speed the card is running
at and may incorrectly set the network speed bit in the 2114x. If the
card is connected to a 100Mb network but the driver thinks it's only 10Mb,
the transmit threshold values will be to small and the FIFO will empty
of data in the middle of a packet.
The messages you see are this sort of underflow occuring. The four
transmit underflows that you see indicate that four corrupted packets
have been sent, which the driver detected and compensated for. Once
the driver configures the store-and-forward mode, no more corrupted
packets will be sent, but your card may not be operating as efficiently
as possible.
What speed is your network (10Mb or 100Mb)? What speed does the de driver
think it's running at? What kind of card do you have?
The other possibility is excessive delays in copying data across the
PCI bus. This could indicate a configuration problem, like the latency
timer values being mis-programmed.
From owner-freebsd-hackers Thu Oct 23 03:15:51 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id DAA16731
for hackers-outgoing; Thu, 23 Oct 1997 03:15:51 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA16726;
Thu, 23 Oct 1997 03:15:45 -0700 (PDT)
(envelope-from danny@panda.hilink.com.au)
Received: (from danny@localhost)
by panda.hilink.com.au (8.8.5/8.8.5) id UAA14008;
Thu, 23 Oct 1997 20:13:15 +1000 (EST)
Date: Thu, 23 Oct 1997 20:13:15 +1000 (EST)
From: "Daniel O'Callaghan" <danny@panda.hilink.com.au>
To: Don Lewis <Don.Lewis@tsc.tdk.com>
cc: "George M. Ellenburg" <gme@inspace.net>, Charles Mott <cmott@srv.net>,
freebsd-hackers@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG
Subject: Re: Password files and virtual IP addresses
In-Reply-To: <199710230919.CAA13620@salsa.gv.tsc.tdk.com>
Message-ID: <Pine.BSF.3.91.971023201019.524R-100000@panda.hilink.com.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Thu, 23 Oct 1997, Don Lewis wrote:
> On Oct 23, 9:44am, "Daniel O'Callaghan" wrote:
> } Subject: Re: Password files and virtual IP addresses
>
> } Even if the uid is the same from one vm to another, how
> } much does it matter?
>
> How do you keep users with the same uid's in different vm's from killing
> each others processes? What about ps?
>
Ah, that's a good point. I had not thought of it because I don't put ps
or kill in the vm. But anyway, I allocate users within each vm and give
them a disabled entry in the main password file, with the same uid
used in the main passwd file and the vm passwd file. That way I get
sensible information when I do an ls. The vm users don't get root access
within their own vm.
/* Daniel O'Callaghan */
/* HiLink Internet <http://www.hilink.com.au/> danny@hilink.com.au */
/* FreeBSD - works hard, plays hard... danny@freebsd.org */
From owner-freebsd-hackers Thu Oct 23 03:29:27 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id DAA17463
for hackers-outgoing; Thu, 23 Oct 1997 03:29:27 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id DAA17453
for <hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 03:29:23 -0700 (PDT)
(envelope-from rminnich@Sarnoff.COM)
Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id GAA26370; Thu, 23 Oct 1997 06:28:39 -0400
Date: Thu, 23 Oct 1997 06:28:39 -0400 (EDT)
From: "Ron G. Minnich" <rminnich@Sarnoff.COM>
X-Sender: rminnich@terra
To: Steve Sims <SimsS@IBM.Net>
cc: "'hackers@freebsd.org'" <hackers@FreeBSD.ORG>
Subject: Re: SMP P-Pro MoBo - Recommendations?
In-Reply-To: <01BCDEFA.1F723560.SimsS@IBM.Net>
Message-ID: <Pine.SUN.3.91.971023062813.26349B-100000@terra>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
for low cost i like the tyan, but it is a shared cache. Works well on
clusters, where shared cache is mostly a win.
ron
Ron Minnich |Java: an operating-system-independent,
rminnich@sarnoff.com |architecture-independent programming language
(609)-734-3120 |for Windows/95 and Windows/NT on the Pentium
ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html
From owner-freebsd-hackers Thu Oct 23 05:12:16 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id FAA21664
for hackers-outgoing; Thu, 23 Oct 1997 05:12:16 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from dcarmich.pr.mcs.net (dcarmich.pr.mcs.net [204.95.63.202])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA21650
for <freebsd-hackers@freebsd.org>; Thu, 23 Oct 1997 05:12:12 -0700 (PDT)
(envelope-from dcarmich@dcarmich.pr.mcs.net)
Received: (from dcarmich@localhost)
by dcarmich.pr.mcs.net (8.8.5/8.8.5) id HAA00397;
Thu, 23 Oct 1997 07:15:47 -0500 (CDT)
Message-ID: <19971023071547.41059@dcarmich.pr.mcs.net>
Date: Thu, 23 Oct 1997 07:15:47 -0500
From: Douglas Carmichael <dcarmich@mcs.com>
To: freebsd-hackers@freebsd.org
Subject: Running DOSEMU on FreeBSD?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.74e
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Have any of you people been able to run the latest NetBSD version of
DOSEMU on FreeBSD?
From owner-freebsd-hackers Thu Oct 23 06:09:51 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id GAA24057
for hackers-outgoing; Thu, 23 Oct 1997 06:09:51 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from monoid.cs.tcd.ie (monoid.cs.tcd.ie [134.226.38.99])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA24049
for <hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 06:09:48 -0700 (PDT)
(envelope-from careilly@monoid.cs.tcd.ie)
Received: from monoid.cs.tcd.ie (localhost.my.domain [127.0.0.1])
by monoid.cs.tcd.ie (8.8.5/8.8.5) with ESMTP id OAA04169
for <hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 14:09:08 +0100 (IST)
Message-Id: <199710231309.OAA04169@monoid.cs.tcd.ie>
To: hackers@FreeBSD.ORG
Subject: Security Policies [Was: ACLs [Was: C2 Trusted FreeBSD?] ]
X-Address: Department of Computer Science, Trinity College, Dublin 2, Ireland.
X-Phone: +353-(0)1-6081321
In-reply-to: Your message dated today at 09:28.
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4164.877612147.1@monoid.cs.tcd.ie>
Content-Description: text
Date: Thu, 23 Oct 1997 14:09:08 +0100
From: Colman Reilly <careilly@monoid.cs.tcd.ie>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
[Deleted discussion about how difficult ACLs are to implement in UNIX]
The basic problem with implementing ACLs, multi-level labelling and so on is
that FreeBSD has very little support for security policies. It's not really a
part of the architecture and seems to be done on an ad hoc basis subsystem by
subsystem.
I think we'd be better off considering a more general solution rather than
trying to hack support in on a case by case basis.
So to this weeks insane plot;
A layered security model, similiar in conception to the layered
filesystem, which allows a choice of access control models or model
and which is used by all subsystems to make access control decisions.
This way an installation could choose between (say) standard UNIX access
control, ACL based access control, MAC style multi-level access control or
role based access control or combinations thereof. It would also allow for
more specialised access control models to be plugged in, and for the layers
to be used on a system by system basis, so that the news directory was using
standard UNIX access control while user directories were using ACLs on top
of MAC based controls.
The system would also be able to control things other than files - it could
give us the socket level controls suggested previously, and possibly access
controls on processes, so that unpriviledged users could send signals to
daemons, that sort of thing.
The main problem see (beyond the size of the task!) is where to store the
access control information.
The system tools would need to be changed, but thats doable - that's why we have
a full distribution rather than just a kernel. We should be able to wrap
most of the required stuff into a library to make changes easier.
Third party tools are more of a problem. How many of them will have
problems? Should we expect tar to handle this information? Does tar know how
to preserve ownership even now?
Colman, rambling again.
From owner-freebsd-hackers Thu Oct 23 06:46:37 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id GAA26551
for hackers-outgoing; Thu, 23 Oct 1997 06:46:37 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA26541
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 06:46:32 -0700 (PDT)
(envelope-from matt@3am-software.com)
Received: from chop.cdsnet.net (chop.cdsnet.net [204.118.244.3])
by mail.cdsnet.net (8.8.6/8.8.6) with ESMTP id GAA10263;
Thu, 23 Oct 1997 06:46:26 -0700 (PDT)
Received: from nowin (1Cust33.max3.boston.ma.ms.uu.net [153.35.70.161])
by chop.cdsnet.net (8.8.7/8.8.5) with SMTP id EAA27427;
Thu, 23 Oct 1997 04:56:08 -0700 (PDT)
Message-Id: <3.0.3.32.19971023075157.031f9f3c@ranier.altavista-software.com>
X-Sender: 3ampop@ranier.altavista-software.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 23 Oct 1997 07:51:57 -0400
To: Charles Henrich <henrich@crh.cl.msu.edu>,
Jaye Mathisen <mrcpu@cdsnet.net>
From: Matt Thomas <matt@3am-software.com>
Subject: Re: de0 errors
Cc: freebsd-hackers@FreeBSD.ORG
In-Reply-To: <19971023005735.38504@crh.cl.msu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
At 12:57 AM 10/23/97 -0400, Charles Henrich wrote:
>After moving to 2.2.5-RELEASE im seeing:
>
>Oct 23 00:32:12 msunews /kernel: ccd0-3: Concatenated disk drivers
>Oct 23 00:35:45 msunews /kernel: de0: abnormal interrupt: transmit underflow
>(raising TX threshold to 96|256)
>Oct 23 00:36:01 msunews /kernel: de0: abnormal interrupt: transmit underflow
>(raising TX threshold to 8|512)
>Oct 23 00:37:41 msunews /kernel: de0: abnormal interrupt: transmit underflow
>(raising TX threshold to 1024)
>Oct 23 00:55:14 msunews /kernel: de0: abnormal interrupt: transmit underflow
>(switching to store-and-forward mode)
>
>Any ideas? Are these informational, or are they bad?
they are informational.
--
Matt Thomas Internet: matt@3am-software.com
3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt/
Nashua, NH Disclaimer: I disavow all knowledge of this message
From owner-freebsd-hackers Thu Oct 23 06:54:54 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id GAA27140
for hackers-outgoing; Thu, 23 Oct 1997 06:54:54 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from cs.iastate.edu (root@cs.iastate.edu [129.186.3.1])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA27135
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 06:54:51 -0700 (PDT)
(envelope-from ghelmer@cs.iastate.edu)
Received: from popeye.cs.iastate.edu (popeye.cs.iastate.edu [129.186.3.4])
by cs.iastate.edu (8.8.7/8.8.7) with ESMTP id IAA02676;
Thu, 23 Oct 1997 08:54:47 -0500 (CDT)
Received: from localhost (ghelmer@localhost) by popeye.cs.iastate.edu (8.8.7/8.7.1) with SMTP id IAA07091; Thu, 23 Oct 1997 08:54:46 -0500 (CDT)
X-Authentication-Warning: popeye.cs.iastate.edu: ghelmer owned process doing -bs
Date: Thu, 23 Oct 1997 08:54:44 -0500 (CDT)
From: Guy Helmer <ghelmer@cs.iastate.edu>
To: Charles Henrich <henrich@crh.cl.msu.edu>
cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: CHILD_MAX no longer valid in 2.2.5-RELEASE?
In-Reply-To: <19971023030651.02177@crh.cl.msu.edu>
Message-ID: <Pine.HPP.3.96.971023084622.2752D-100000@popeye.cs.iastate.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Thu, 23 Oct 1997, Charles Henrich wrote:
> I've send CHILD_MAX to 512 on my news server, which (used) to have the effect
> of making the default maximum procs set to 512.. Bonus. Under 2.2.5-RELEASE
> it doesnt appear to be having any effect :( The only thing I can think of is,
> its placement in the config file is order important, or its no longer
> supported? If the latter, how do you effect the same change in 2.2.5?
init uses the "daemon" entry in /etc/login.conf to set process resource
limits before executing /etc/rc; it appears to me that the "maxproc" entry
(maxproc=256) is the one you need to adjust (see also login.conf(5) and
getcap(3)).
Hope that solves your problem,
Guy
Guy Helmer, Computer Science Graduate Student - ghelmer@cs.iastate.edu
Iowa State University http://www.cs.iastate.edu/~ghelmer
Research Assistant, Scalable Computing Laboratory, Ames Laboratory
From owner-freebsd-hackers Thu Oct 23 07:16:05 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id HAA28701
for hackers-outgoing; Thu, 23 Oct 1997 07:16:05 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA28692
for <hackers@freebsd.org>; Thu, 23 Oct 1997 07:16:01 -0700 (PDT)
(envelope-from darrenr@cyber.com.au)
Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id AAA06574 for hackers@freebsd.org; Fri, 24 Oct 1997 00:15:50 +1000
From: Darren Reed <darrenr@cyber.com.au>
Message-Id: <199710231415.AAA06574@plum.cyber.com.au>
Subject: MTU Path discovery.
To: hackers@freebsd.org
Date: Fri, 24 Oct 1997 00:15:50 +1000 (EST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I'm want to add a sysctl knob to control this (default to on).
At present, MTU path discovery only seems to be enabled for TCP, but
I'm reluctant to make it "net.inet.tcp.mtupathdiscovery" as I don't
want to limit its scope. However, I'm open for comments about
whether it should be ip or icmp.
I don't think the current behaviour (is on and cannot be controlled)
is all that desirable.
Darren
From owner-freebsd-hackers Thu Oct 23 07:21:14 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id HAA29090
for hackers-outgoing; Thu, 23 Oct 1997 07:21:14 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (word.smith.net.au [202.0.75.3])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA29085
for <hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 07:21:04 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id XAA00411;
Thu, 23 Oct 1997 23:47:11 +0930 (CST)
Message-Id: <199710231417.XAA00411@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Colman Reilly <careilly@monoid.cs.tcd.ie>
cc: hackers@FreeBSD.ORG
Subject: Re: Security Policies [Was: ACLs [Was: C2 Trusted FreeBSD?] ]
In-reply-to: Your message of "Thu, 23 Oct 1997 14:09:08 +0100."
<199710231309.OAA04169@monoid.cs.tcd.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 23 Oct 1997 23:47:10 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> [Deleted discussion about how difficult ACLs are to implement in UNIX]
[Serious security model revamp proposal]
> The main problem see (beyond the size of the task!) is where to store the
> access control information.
That too. Another would be making it clear to people how to work well
with the new model(s).
Having said all that, I'd still suggest that it's worth pursuing. If
you approach the problem generalistically, you'd end up with something
that could be applied to a not inconsiderable number of like systems,
and achieve a pretty major breakthrough in that regard.
mike
From owner-freebsd-hackers Thu Oct 23 07:31:02 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id HAA29646
for hackers-outgoing; Thu, 23 Oct 1997 07:31:02 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (word.smith.net.au [202.0.75.3])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA29632
for <freebsd-hackers@freefall.FreeBSD.org>; Thu, 23 Oct 1997 07:30:29 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id XAA00457;
Thu, 23 Oct 1997 23:56:23 +0930 (CST)
Message-Id: <199710231426.XAA00457@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Christoph Kukulies <kuku@gilberto.physik.RWTH-Aachen.DE>
cc: freebsd-hackers@freefall.FreeBSD.org
Subject: Re: need help in ISA memory mapping
In-reply-to: Your message of "Thu, 23 Oct 1997 09:46:58 +0200."
<199710230746.JAA13974@gil.physik.rwth-aachen.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 23 Oct 1997 23:56:07 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
>
> A user program should be able to directly read/write into these memory
> locations via a pointer (byte or word). Is there a way tp 'map'
> this into a user address space? Is it possible at all?
Yup. You just need to mmap() a friendly driver or memory extent.
> I can use the isa_dev structure in the kernel driver (I have written
> a minimum driver that probes the card) but this only works in kernel
> mode.
You could extend the driver trivially to offer mmap() facilities; this
would be ideal as it would allow you to detect the correct location for
the card & disallow the mapping if the card did not exist.
Have a look at the mapping stuff in syscons for an example.
mike
From owner-freebsd-hackers Thu Oct 23 07:45:36 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id HAA00800
for hackers-outgoing; Thu, 23 Oct 1997 07:45:36 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA00790
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 07:45:30 -0700 (PDT)
(envelope-from henrich@crh.cl.msu.edu)
Received: (from henrich@localhost)
by crh.cl.msu.edu (8.8.5/8.8.5) id KAA09776;
Thu, 23 Oct 1997 10:45:27 -0400 (EDT)
Message-ID: <19971023104527.34841@crh.cl.msu.edu>
Date: Thu, 23 Oct 1997 10:45:27 -0400
From: Charles Henrich <henrich@crh.cl.msu.edu>
To: Guy Helmer <ghelmer@cs.iastate.edu>
Cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: CHILD_MAX no longer valid in 2.2.5-RELEASE?
References: <19971023030651.02177@crh.cl.msu.edu> <Pine.HPP.3.96.971023084622.2752D-100000@popeye.cs.iastate.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84
In-Reply-To: <Pine.HPP.3.96.971023084622.2752D-100000@popeye.cs.iastate.edu>; from Guy Helmer on Thu, Oct 23, 1997 at 08:54:44AM -0500
X-Operating-System: FreeBSD 2.2.2-RELEASE
X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On the subject of Re: CHILD_MAX no longer valid in 2.2.5-RELEASE?, Guy Helmer stated:
> > I've send CHILD_MAX to 512 on my news server, which (used) to have the
> > effect of making the default maximum procs set to 512.. Bonus. Under
> > 2.2.5-RELEASE it doesnt appear to be having any effect :( The only thing
> > I can think of is, its placement in the config file is order important, or
> > its no longer supported? If the latter, how do you effect the same change
> > in 2.2.5?
>
> init uses the "daemon" entry in /etc/login.conf to set process resource
> limits before executing /etc/rc; it appears to me that the "maxproc" entry
> (maxproc=256) is the one you need to adjust (see also login.conf(5) and
> getcap(3)).
>
> Hope that solves your problem, Guy
I'll give it a shot, thanks! Im wondering that perhaps the name login.conf is
a badly named file, especially if its more to do with userresources and
nothing to do with the login process. Someone should also take CHILD_MAX out
of LINT :)
-Crh
Charles Henrich Michigan State University henrich@msu.edu
http://pilot.msu.edu/~henrich
From owner-freebsd-hackers Thu Oct 23 07:52:42 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id HAA01381
for hackers-outgoing; Thu, 23 Oct 1997 07:52:42 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (word.smith.net.au [202.0.75.3])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA01375
for <freebsd-hackers@freebsd.org>; Thu, 23 Oct 1997 07:52:38 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id AAA00606;
Fri, 24 Oct 1997 00:18:53 +0930 (CST)
Message-Id: <199710231448.AAA00606@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Archie Cobbs <archie@whistle.com>
cc: freebsd-hackers@freebsd.org
Subject: Re: Broken device LKM in 2.2
In-reply-to: Your message of "Mon, 20 Oct 1997 17:00:23 MST."
<199710210000.RAA11140@bubba.whistle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 24 Oct 1997 00:18:51 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
>
> I guess nobody makes device type LKM's in 2.2.. but sys/lkm.h is
> broken with respect to them. Here's a hack that fixes this. Perhaps
> the "name ## _module", which is different from the other module
> types, is there for some reason (?)
IIRC it's there to avoid symbol conflicts with statically loaded
versions. Could be wrong of course; there's nothing in the CVS log.
> Anyway, it's incompatible with the DISPATCH macro defined later in
> the file, and this fixes it...
Has anyone looked at this? Should we buy it?
mike
From owner-freebsd-hackers Thu Oct 23 08:22:41 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id IAA03878
for hackers-outgoing; Thu, 23 Oct 1997 08:22:41 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA03869
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 08:22:35 -0700 (PDT)
(envelope-from henrich@crh.cl.msu.edu)
Received: (from henrich@localhost)
by crh.cl.msu.edu (8.8.5/8.8.5) id LAA10054;
Thu, 23 Oct 1997 11:21:06 -0400 (EDT)
Message-ID: <19971023112105.56949@crh.cl.msu.edu>
Date: Thu, 23 Oct 1997 11:21:05 -0400
From: Charles Henrich <henrich@crh.cl.msu.edu>
To: Don Lewis <Don.Lewis@tsc.tdk.com>
Cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: de0 errors
References: <henrich@crh.cl.msu.edu> <199710230955.CAA13696@salsa.gv.tsc.tdk.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84
In-Reply-To: <199710230955.CAA13696@salsa.gv.tsc.tdk.com>; from Don Lewis on Thu, Oct 23, 1997 at 02:55:29AM -0700
X-Operating-System: FreeBSD 2.2.2-RELEASE
X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On the subject of Re: de0 errors, Don Lewis stated:
> packets will be sent, but your card may not be operating as efficiently
> as possible.
>
> What speed is your network (10Mb or 100Mb)? What speed does the de driver
> think it's running at? What kind of card do you have?
Its a 100mbit network, the card thinks its a 100mbit network.
de0 <Digital 21140 Fast Ethernet> rev 18 int a irq 9 on pci0:20
de0: SMC 9332DST 21140 [10-100Mb/s] pass 1.2
de0: address 00:00:c0:9e:ba:c7
de0: enabling 100baseTX port
de0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 35.8.2.20 netmask 0xfff80000 broadcast 35.15.255.255
ether 00:00:c0:9e:ba:c7
media: 100baseTX status: active
-Crh
Charles Henrich Michigan State University henrich@msu.edu
http://pilot.msu.edu/~henrich
From owner-freebsd-hackers Thu Oct 23 08:32:38 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id IAA04477
for hackers-outgoing; Thu, 23 Oct 1997 08:32:38 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from korin.warman.org.pl (korin.nask.waw.pl [148.81.160.10])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA04461
for <hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 08:32:28 -0700 (PDT)
(envelope-from abial@korin.warman.org.pl)
Received: from localhost (abial@localhost)
by korin.warman.org.pl (8.8.7/8.8.5) with SMTP id RAA23876;
Thu, 23 Oct 1997 17:33:57 +0200 (CEST)
Date: Thu, 23 Oct 1997 17:33:57 +0200 (CEST)
From: Andrzej Bialecki <abial@korin.warman.org.pl>
To: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
cc: hackers@FreeBSD.ORG
Subject: Re: zipfs filesystem anyone ?
In-Reply-To: <199710230638.HAA26030@labinfo.iet.unipi.it>
Message-ID: <Pine.NEB.3.95.971023173010.18947B-100000@korin.warman.org.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Thu, 23 Oct 1997, Luigi Rizzo wrote:
> So I think my only choice is to try a merge of the "portal" and
> "nullfs" filesystem to build the thing I need. But maybe such
> implementations already exist, in some form or some other ?
As far as I understand it, the CryptoFS (cfs in ports) implements
something similar by using a modified NFS daemon.
I like the idea of a zipfs.
Andrzej Bialecki
---------------------+---------------------------------------------------------
abial@warman.org.pl | if(halt_per_mth > 0) { fetch("http://www.freebsd.org") }
Research & Academic | "Be open-minded, but don't let your brains to fall out."
Network in Poland | All of the above (and more) is just my personal opinion.
---------------------+---------------------------------------------------------
From owner-freebsd-hackers Thu Oct 23 08:33:37 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id IAA04531
for hackers-outgoing; Thu, 23 Oct 1997 08:33:37 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from cs.iastate.edu (root@cs.iastate.edu [129.186.3.1])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA04526
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 08:33:32 -0700 (PDT)
(envelope-from ghelmer@cs.iastate.edu)
Received: from popeye.cs.iastate.edu (popeye.cs.iastate.edu [129.186.3.4])
by cs.iastate.edu (8.8.7/8.8.7) with ESMTP id KAA15481;
Thu, 23 Oct 1997 10:33:28 -0500 (CDT)
Received: from localhost (ghelmer@localhost) by popeye.cs.iastate.edu (8.8.7/8.7.1) with SMTP id KAA16023; Thu, 23 Oct 1997 10:33:27 -0500 (CDT)
X-Authentication-Warning: popeye.cs.iastate.edu: ghelmer owned process doing -bs
Date: Thu, 23 Oct 1997 10:33:26 -0500 (CDT)
From: Guy Helmer <ghelmer@cs.iastate.edu>
To: Charles Henrich <henrich@crh.cl.msu.edu>
cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: CHILD_MAX no longer valid in 2.2.5-RELEASE?
In-Reply-To: <19971023104527.34841@crh.cl.msu.edu>
Message-ID: <Pine.HPP.3.96.971023101746.2752E-100000@popeye.cs.iastate.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Thu, 23 Oct 1997, Charles Henrich wrote:
> On the subject of Re: CHILD_MAX no longer valid in 2.2.5-RELEASE?, Guy Helmer stated:
> > init uses the "daemon" entry in /etc/login.conf to set process resource
> > limits before executing /etc/rc; it appears to me that the "maxproc" entry
> > (maxproc=256) is the one you need to adjust (see also login.conf(5) and
> > getcap(3)).
>
> I'll give it a shot, thanks! Im wondering that perhaps the name login.conf is
> a badly named file, especially if its more to do with userresources and
> nothing to do with the login process. Someone should also take CHILD_MAX out
> of LINT :)
login.conf's primary use is for defining authentication methods, setting
user resource limits, and setting useful system-wide defaults at login
time, based on user class, but it is marginally overloaded (in particular,
for init(8) like we've noted).
There ought to be a couple of pointers to this use of the daemon entry in
login.conf in init(8)'s man page and LINT (assuming CHILD_MAX stays in) --
I suppose that means I ought to make diffs and write a gnats report :-)
Guy Helmer, Computer Science Graduate Student - ghelmer@cs.iastate.edu
Iowa State University http://www.cs.iastate.edu/~ghelmer
Research Assistant, Scalable Computing Laboratory, Ames Laboratory
From owner-freebsd-hackers Thu Oct 23 08:40:44 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id IAA05109
for hackers-outgoing; Thu, 23 Oct 1997 08:40:44 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (word.smith.net.au [202.0.75.3])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA05089
for <hackers@freebsd.org>; Thu, 23 Oct 1997 08:40:35 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id BAA00846;
Fri, 24 Oct 1997 01:06:19 +0930 (CST)
Message-Id: <199710231536.BAA00846@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Darren Reed <darrenr@cyber.com.au>
cc: hackers@freebsd.org
Subject: Re: MTU Path discovery.
In-reply-to: Your message of "Fri, 24 Oct 1997 00:15:50 +1000."
<199710231415.AAA06574@plum.cyber.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 24 Oct 1997 01:06:18 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
>
> I'm want to add a sysctl knob to control this (default to on).
Sounds reasonable.
> I don't think the current behaviour (is on and cannot be controlled)
> is all that desirable.
Which part is undesirable? And if the former, why?
mike
From owner-freebsd-hackers Thu Oct 23 08:42:52 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id IAA05232
for hackers-outgoing; Thu, 23 Oct 1997 08:42:52 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (word.smith.net.au [202.0.75.3])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA05218
for <hackers@freebsd.org>; Thu, 23 Oct 1997 08:42:45 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id BAA00881;
Fri, 24 Oct 1997 01:09:30 +0930 (CST)
Message-Id: <199710231539.BAA00881@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Dan Walters <hannibal@cyberstation.net>
cc: hackers@freebsd.org
Subject: Re: ATAPI CD-RW documentation...
In-reply-to: Your message of "Sun, 19 Oct 1997 18:09:07 EST."
<Pine.BSI.3.96.971019180502.25467A-100000@citrine.cyberstation.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 24 Oct 1997 01:09:30 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> Never mind, it's amazing how you always find things right after you give
> up and ask. :) For anyone wondering, the motherload of specs can be
> found by ftp at fission.dt.wdc.com, including the working draft of the
> ATAPI Removable Rewritable Specification, SFF-8070. Wish their web pages
> would mention the site. :)
Thanks for finding the number for me; I ran out of patience downloading
them, struggling to print them and giving up 8)
> So, has anyone already began work on this, or should I go ahead and give
> it a shot when my drive gets in?
Nobody's begun any work, as such. Again, I exhort you to look at
Justin Gibbs' CAM framework; it is the future of mass storage
interfaces in FreeBSD, and we should be looking towards it.
mike
From owner-freebsd-hackers Thu Oct 23 09:12:09 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id JAA06928
for hackers-outgoing; Thu, 23 Oct 1997 09:12:09 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (word.smith.net.au [202.0.75.3])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA06826
for <hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 09:11:45 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id BAA01020;
Fri, 24 Oct 1997 01:37:03 +0930 (CST)
Message-Id: <199710231607.BAA01020@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
cc: hackers@FreeBSD.ORG
Subject: Re: zipfs filesystem anyone ?
In-reply-to: Your message of "Thu, 23 Oct 1997 07:38:26 +0100."
<199710230638.HAA26030@labinfo.iet.unipi.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 24 Oct 1997 01:37:03 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> Thus, I was looking at something which would pass all filesystem
> (or vn ?) calls to some user-space process which could then handle
> them properly.
Look at the 'rumba' port for an example of using the NFS interface to
achieve this.
> NOTE 2: Why ZIP and not .tar.gz
>
> Implementing such a "filesystem" in user space is much easier if the
> directory structure is directly available in the archive, rather than
> being scattered all around and mixed with data. gzipped tar files have
> this problem: you need to decompress data before being able to use
> them. Conversely, I think zip archives have the directory structure in
> clear and so it is easier to move through the tree, and decompression
> is only necessary on the single components.
You are correct; gzipped tarfiles are organised the wrong way around
(metadata inside the compressed envelope), while zipfiles keep the
metadata outside.
mike
From owner-freebsd-hackers Thu Oct 23 09:13:07 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id JAA07028
for hackers-outgoing; Thu, 23 Oct 1997 09:13:07 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from horst.bfd.com (horst.bfd.com [204.160.242.10])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA07021
for <hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 09:13:04 -0700 (PDT)
(envelope-from ejs@bfd.com)
Received: from harlie.bfd.com (bastion.bfd.com [204.160.242.14]) by horst.bfd.com (8.8.5/8.7.3) with SMTP id JAA04248; Thu, 23 Oct 1997 09:12:37 -0700 (PDT)
Date: Thu, 23 Oct 1997 09:12:37 -0700 (PDT)
From: "Eric J. Schwertfeger" <ejs@bfd.com>
To: "Ron G. Minnich" <rminnich@Sarnoff.COM>
cc: Steve Sims <SimsS@IBM.Net>, "'hackers@freebsd.org'" <hackers@FreeBSD.ORG>
Subject: Re: SMP P-Pro MoBo - Recommendations?
In-Reply-To: <Pine.SUN.3.91.971023062813.26349B-100000@terra>
Message-ID: <Pine.BSF.3.95.971023091129.26953D-100000@harlie.bfd.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Thu, 23 Oct 1997, Ron G. Minnich wrote:
> for low cost i like the tyan, but it is a shared cache. Works well on
> clusters, where shared cache is mostly a win.
> ron
On the PPro boards, the L2 cache is on chip, so can't be shared. This was
an issue on Pentium motherboards, though, and the biggest reason the
PPro's do better in SMP environments.
From owner-freebsd-hackers Thu Oct 23 09:23:02 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id JAA07568
for hackers-outgoing; Thu, 23 Oct 1997 09:23:02 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA07560
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 09:22:58 -0700 (PDT)
(envelope-from henrich@crh.cl.msu.edu)
Received: (from henrich@localhost)
by crh.cl.msu.edu (8.8.5/8.8.5) id MAA10511;
Thu, 23 Oct 1997 12:22:55 -0400 (EDT)
Message-ID: <19971023122255.43108@crh.cl.msu.edu>
Date: Thu, 23 Oct 1997 12:22:55 -0400
From: Charles Henrich <henrich@crh.cl.msu.edu>
To: Guy Helmer <ghelmer@cs.iastate.edu>
Cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: CHILD_MAX no longer valid in 2.2.5-RELEASE?
References: <19971023104527.34841@crh.cl.msu.edu> <Pine.HPP.3.96.971023101746.2752E-100000@popeye.cs.iastate.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84
In-Reply-To: <Pine.HPP.3.96.971023101746.2752E-100000@popeye.cs.iastate.edu>; from Guy Helmer on Thu, Oct 23, 1997 at 10:33:26AM -0500
X-Operating-System: FreeBSD 2.2.2-RELEASE
X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On the subject of Re: CHILD_MAX no longer valid in 2.2.5-RELEASE?, Guy Helmer stated:
> There ought to be a couple of pointers to this use of the daemon entry in
> login.conf in init(8)'s man page and LINT (assuming CHILD_MAX stays in) --
> I suppose that means I ought to make diffs and write a gnats report :-)
Perhaps. Now I'd like to get up on my soapbox and bitch about this login.conf
business. For some assinine reason the defaults for login.conf for system
processes (including BOOT!). This bit me big time when trying to fsck a large
raid array, the fsck failed with out of memory.
What remotely possible, conceivable reason would you ever want to limit root
and its ilk from having free run of the system? This seems like a very
dangerous policy that can in dire system cases lock the administrators out of
the system. I would strongly suggest the defaults in login conf is everything
is wide open, and its up to the sysadmin to fix it. In 90 percent of the
FreeBSD installations out there, (my guess), this is appropriate, and only in
the ISP multi-user-login case is the current defaults usefull.
-Crh
Charles Henrich Michigan State University henrich@msu.edu
http://pilot.msu.edu/~henrich
From owner-freebsd-hackers Thu Oct 23 09:23:27 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id JAA07627
for hackers-outgoing; Thu, 23 Oct 1997 09:23:27 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA07616;
Thu, 23 Oct 1997 09:23:24 -0700 (PDT)
(envelope-from ambrisko@whistle.com)
Received: (from daemon@localhost)
by alpo.whistle.com (8.8.5/8.8.5) id JAA17056;
Thu, 23 Oct 1997 09:15:16 -0700 (PDT)
Received: from crab.whistle.com(207.76.205.112)
via SMTP by alpo.whistle.com, id smtpd017049; Thu Oct 23 16:15:06 1997
Received: (from ambrisko@localhost) by crab.whistle.com (8.8.7/8.6.12) id JAA22205; Thu, 23 Oct 1997 09:13:57 -0700 (PDT)
From: Doug Ambrisko <ambrisko@whistle.com>
Message-Id: <199710231613.JAA22205@crab.whistle.com>
Subject: Re: Password files and virtual IP addresses
In-Reply-To: <Pine.BSF.3.95.971023005117.23413D-100000@current1.whistle.com> from Julian Elischer at "Oct 23, 97 00:53:22 am"
To: freebsd-hackers@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG
Date: Thu, 23 Oct 1997 09:13:56 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL29 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Julian Elischer writes:
| We have a whole virtual machine
| using chroot, and a few other tricks such as a hacked inetd.
| It was described recently on either hackers or questions (I forget which)
| by Doug Ambrisko. (I think it was questions)
I was a hacked natd-like program. "inetd" was fine as is.
| On Wed, 22 Oct 1997, Charles Mott wrote:
|
| > Suppose that one wanted to create different virtual
| > IP addresses with ifconfig alias, and when people telnet
| > or ftp or access pop3/imap2 at a virtual address, a
| > password file specific to that virtual address would be
| > used. This would allow username re-use.
| >
| > Has this sort of thing been considered before? If not,
| > what sort of things would have to be hacked? If password
| > access routines could somehow be informed what virtual
| > address they were being accessed from, then it would
| > be possible to have multiple password files.
| >
| > Of course, there are always unintended security
| > implications to doing these things...
This is a pretty simple case since this services can be controled via
inetd. Since inetd is well-behaved (ie uses /etc/services to figure
out what ports to use), it is pretty easy to copy the stuff you need
into a small chroot and then do a "chroot path /usr/sbin/inetd" to
start your services that have been shifted via editing /etc/services in
the chroot. The tricky part is to make connections that come in through
the alias ip to do a "port shift" from the standard to the ones used in
the chroot. This can be done with a hacked natd that does port translation
instead of ip translation. Note this problem is simpler then the
case I described before since only incoming connections are made so
you don't have to worry about translating connections originating
from the chroot such as sendmail delivering mail from inside the chroot.
The translate code is based on some non-public Whistle code.
Doug A.
From owner-freebsd-hackers Thu Oct 23 09:40:11 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id JAA09091
for hackers-outgoing; Thu, 23 Oct 1997 09:40:11 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.5.83])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA09086
for <hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 09:40:06 -0700 (PDT)
(envelope-from tlambert@usr02.primenet.com)
Received: (from daemon@localhost)
by smtp02.primenet.com (8.8.7/8.8.7) id JAA24658
for <hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 09:40:04 -0700 (MST)
Received: from usr02.primenet.com(206.165.6.202)
via SMTP by smtp02.primenet.com, id smtpd024647; Thu Oct 23 09:40:01 1997
Received: (from tlambert@localhost)
by usr02.primenet.com (8.8.5/8.8.5) id JAA23174
for hackers@FreeBSD.ORG; Thu, 23 Oct 1997 09:40:01 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710231640.JAA23174@usr02.primenet.com>
Subject: Re: FreeBSD 3.0 kernel API ?!
To: hackers@FreeBSD.ORG
Date: Thu, 23 Oct 1997 16:40:01 +0000 (GMT)
In-Reply-To: <199710220334.UAA23820@kithrup.com> from "Sean Eric Fagan" at Oct 21, 97 08:34:20 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> >> How will you deal with struct ifnet when we rename all the member
> >> variables from their current names to "opaque_variable_01" through
> >> "opaque_variable_NN"? Even if you can depend on the structure, you
> >> can't reasonably expect the kernel internal interface to not change.
> >This sort of change I think is, to put it bluntly, fucked.
>
> Terry's problem is that he is forgetting that non-kernel bits are part of
> the OS in unix.
I'm not forgetting this. I'm fine with it.
> This means that some non-kernel bits have to know the format (and location)
> of some kernel data structures, sometimes.
This, I stringly disagree with. Kernel internal structures are *internal*,
that's the whole point in calling them that. 8-).
What this means is that they should be accessed via accessor functions
instead of directly. The best mechanism would be descriptor based to
not externalize any structure changes, *ever*.
> (While there are many cases where you can abstract this into a usable
> API, there are many other cases where you can't -- because what you
> want to get at is, indeed, exactly what the kernel is using.)
Then I would argue that you are cutting the interface in the wrong place:
in the middle of the iterator instead of above it.
Let's take an example: the proc struct. I want to iterate the processes
on the system, and provide some information as a result of this iteration.
This may be because I'm the 'w' command, or it may be that I'm the 'ps'
command, or it may be that I'm a to-be-written session manager.
Right now, this can be done one of several ways:
1) open /dev/kmem via lib kvm (and need to know the proc struct
size and layout) and grovel
2) popen() an existing command that does #1 already (and compound
the difficulty of fixing #1)
3) iterate /proc (and need to have it mounted)
Of these, the best programatic interface is currently #3. But it fails
to operate, as 'ps' currently does, on system dump images. Let's forget
for the moment that this functionality belongs in the system dump
analysis tool instead of the regular commands. How do we make our
putatively "new, improved" 'ps' command do these things?
The easiest way would be to associate the iterator interface, not with
the 'ps' program (and duplicate the code in all programs like it), but
to provide access via an iterator mechanism (as in #3)... only not to
depend on a cannonizing-data-exposure interface (like procfs). You
don't want to depend on data-exposure because it can only expose the
data of a running kernel. And libkvm is a non-cannonizing-data-exposure
interface.
So what do you do?
The obvious soloution is to somehow make an association of an iterator
interface with the image that creates the data. You can do this with
ELF by making the interface, effectivly, a shared library which resides
in the kernel image and exports data by descriptor. With ELF, you can
do this. The trick it to make the kernel loader not load sections with
a section attribute that indicates they are this interface, and to make
the dlopen() interface take a section type argument (actually, you change
dlopen() to wrap another interface with the third argument -- otherwise
you lose backward compatability and have to do things like actually
looking to the future -- ugh!).
Another alternative would be to *not* ignore what we did before: remove
the system dump analysis capability from 'ps' and 'w' and ..., and put
it in a system dump analyzer tool. Then do conversion to approach #3.
This makes procfs manadatory (I really don't think this is such a bad
thing, myself).
> This is further complicated by the fact that some utilities people have
> decided are part of the OS are not maintained by us.
These utilities must track system changes. That's all there is to it.
If it becomes too burdensome, then FreeBSD must pay for the ability
to make changes away from the mainstream by picking up maintenance.
Can you say a.out? ...I knew you could. Maintenance of old GNU tools
is the payment FreeBSD must render for not going to ELF with the rest
of the world.
Similarly, maintenance of things which grovel /dev/kmem (whether or
not via libkvm is irrelevant) falls to FreeBSD as well. Which is
the number one reason to eliminate the interface (number two is so
you don't have to rebuild libkvm and everything which uses it each
time a trivial kernel structure change takes place).
Back to the original poster:
There are two valid complaints you have, both of which require the
core team to establish policy:
1) How do I write portable kernel code on other platforms
which can be run on FreeBSD?
Right now, if you use kernel structures, you must define "KERNEL (as
someone else pointed out, this is a bogus name space incursion, and
should be "_KERNEL). This will alleviate your complaint, assuming
you are building "live" code.
2) How do I test kernel code in user space?
The ability to test kernel codde in user space is a developement
environmnet option. The FreeBSD core team is responsible for
decisions of policy regarding whether or not this option is to
be offered by FreeBSD.
My personal take (since I'm not one of them) is that it's a
desirable future goal to be able to develop and test kernel code in
user space, and that to some extent, this will require a conversion
to ELF to be able to externalize the kernel interfaces. I would
like to see a formal DDI/DKI definition, and I'd like to see that
definition result in a user space test harness and transport layer.
But what does this buy you beyond LKM's?
It buys you the ability to do source level debugging. Right now,
to get source level kernel debugging, it requires two machines.
So the answer for right now is to use LKM's, put the code into the
running kernel, and use another machine to get source debugging.
Hopefully, this subject is now exhausted.
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 Oct 23 09:47:16 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id JAA09632
for hackers-outgoing; Thu, 23 Oct 1997 09:47:16 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from elvis.mu.org (elvis.mu.org [206.156.231.253])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA09621
for <freebsd-hackers@freebsd.org>; Thu, 23 Oct 1997 09:47:11 -0700 (PDT)
(envelope-from paul@elvis.mu.org)
Received: (from paul@localhost)
by elvis.mu.org (8.8.7/8.8.7) id LAA04258
for freebsd-hackers@freebsd.org; Thu, 23 Oct 1997 11:47:07 -0500 (CDT)
(envelope-from paul)
From: Paul Saab <paul@mu.org>
Message-Id: <199710231647.LAA04258@elvis.mu.org>
Subject: Re: page fault
To: freebsd-hackers@freebsd.org
Date: Thu, 23 Oct 1997 11:47:07 -0500 (CDT)
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
J Wunsch wrote:
> As Paul Saab wrote:
>
> > My question is without debugging
> > symbols it is not possible to find out what caused the crash is
> > it?
>
> Even without debugging symbols, the kernel usually has the default
> symbol table, so you could find out in which function it happened. My
> normal way of analyzation is then to recompile parts of the kernel
> (the interesting parts according to the stacktrace) with -g, and have
> a closer look at them. Fortunately, gcc usually produces the same
> code with or without -g, provided the -O etc. flags remain the same.
>
> Hava a look at the section about kernel debugging in the handbook.
Ok.. here is what I got...
IdlePTD 21c000
current pcb at 1f16a4
panic: page fault
#0 0xf0113b83 in boot ()
(kgdb) where
#0 0xf0113b83 in boot ()
#1 0xf0113e42 in panic ()
#2 0xf01bffc6 in trap_fatal ()
#3 0xf01bfab4 in trap_pfault ()
#4 0xf01bf78f in trap ()
#5 0xf015a48f in tcp_ctlinput ()
#6 0xf01537aa in icmp_input ()
#7 0xf01542fe in ip_input ()
#8 0xf0154374 in ipintr ()
What does this mean?
Paul
From owner-freebsd-hackers Thu Oct 23 09:58:17 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id JAA10379
for hackers-outgoing; Thu, 23 Oct 1997 09:58:17 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA10372
for <hackers@freebsd.org>; Thu, 23 Oct 1997 09:58:13 -0700 (PDT)
(envelope-from tlambert@usr02.primenet.com)
Received: (from daemon@localhost)
by smtp03.primenet.com (8.8.7/8.8.7) id JAA27342;
Thu, 23 Oct 1997 09:58:12 -0700 (MST)
Received: from usr02.primenet.com(206.165.6.202)
via SMTP by smtp03.primenet.com, id smtpd027330; Thu Oct 23 09:58:00 1997
Received: (from tlambert@localhost)
by usr02.primenet.com (8.8.5/8.8.5) id JAA24042;
Thu, 23 Oct 1997 09:57:59 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710231657.JAA24042@usr02.primenet.com>
Subject: Re: FreeBSD 3.0 kernel API ?!
To: darrenr@cyber.com.au (Darren Reed)
Date: Thu, 23 Oct 1997 16:57:58 +0000 (GMT)
Cc: tlambert@primenet.com, hackers@freebsd.org
In-Reply-To: <199710220202.MAA01643@plum.cyber.com.au> from "Darren Reed" at Oct 22, 97 12:02:36 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> > How will you deal with struct ifnet when we rename all the member
> > variables from their current names to "opaque_variable_01" through
> > "opaque_variable_NN"? Even if you can depend on the structure, you
> > can't reasonably expect the kernel internal interface to not change.
>
> This sort of change I think is, to put it bluntly, fucked. (I'm
> probably putting a lot of people who `control' freebsd offside here).
> I'd heartily recommend spending time on something worthwhile rather
> than going around making life more difficult for people that.
>
> It's a change for the sake of a change with no reasonable reason to
> happen. To recite an old adage: if it's not broken, don't fix it.
It's an example of something that you, as a consumer of the kernel,
should not be permitted to tie the hands of kernel developers over,
and thereby preclude future dependent progress. It's very like my
layering changes to the FS, which add nothing functionally, only
architecturally. I can only demostrate small pieces of future
functionality (like NFS client locking); it's impossible to say
what the big picture is like until the future gets here. I, for
one, will not bitch about somone opening the curtains to give me
a bigger vista, even if I haven't bothered to step through the
window (yet).
A more real world example would be the VM system changes, which
required interface changes.
Anyone who wrote a module that implemented a paging policy on NetBSD
is rather screwed trying to port the code to FreeBSD because of
similar "arbitrary" changes.
Arbitrariness is in the eye of the beholder.
On the flip side, if you have a problem with a design choice, provide
an alternate implementation which still achieves the design goals of
the code you are complaining about, without the drawbacks you perceive
in the existing code.
> blah, time to giveup on FreeBSD and use Linux I think...at least Linus
> doesn't allow silly changes that achieve nothing and just cause more
> work.
ELF? Linux is still not using the ELF features which I believe
are the reasons FreeBSD should switch to ELF; there was no real
reason to switch Linux to ELF, except to enable future work along
the lines identified by myself and others. For Linux, that work
has yet to materialize, and there's no immediate significant advantage
to having done the switch. Meanwhile, much old code (mostly code
using old shared libraries) has been broken in the process.
Where are the cannonized-data-interfaces?
Where are the NT SCSI and network drivers?
Where is the 'ps' that can run against a system dump image, but that
doesn't need recompilation when the proc struct changes?
Where is section coloring for kernel paging of non-paging code-path
kernel pages?
Where is the ELF image archiver so the kernel never needs to be
recompiled, only it's archive edited?
Where are the objects that can be archived into the kernel image,
or alternately loaed as LKM's, without rebuilding them?
This is all yet nothing more than open curtains in Linux... but it's
still desirable to have the curtains open.
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 Oct 23 10:05:20 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA10706
for hackers-outgoing; Thu, 23 Oct 1997 10:05:20 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from mole.mole.org (marmot.mole.org [204.216.57.191])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA10691
for <freebsd-hackers@freebsd.org>; Thu, 23 Oct 1997 10:05:14 -0700 (PDT)
(envelope-from mrm@mole.mole.org)
Received: (from mail@localhost) by mole.mole.org (8.6.12/8.6.12) id RAA23067; Thu, 23 Oct 1997 17:04:27 GMT
Received: from meerkat.mole.org(206.197.192.20) by mole.mole.org via smap (V1.3)
id sma023065; Thu Oct 23 17:04:02 1997
Received: (from mrm@localhost) by meerkat.mole.org (8.6.11/8.6.9) id KAA06454; Thu, 23 Oct 1997 10:02:06 -0700
Date: Thu, 23 Oct 1997 10:02:06 -0700
From: "M.R.Murphy" <mrm@Mole.ORG>
Message-Id: <199710231702.KAA06454@meerkat.mole.org>
To: darrenr@cyber.com.au
Subject: Re: MTU Path discovery.
Cc: freebsd-hackers@freebsd.org
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
>
> I'm want to add a sysctl knob to control this (default to on).
>
> At present, MTU path discovery only seems to be enabled for TCP, but
> I'm reluctant to make it "net.inet.tcp.mtupathdiscovery" as I don't
> want to limit its scope. However, I'm open for comments about
> whether it should be ip or icmp.
>
> I don't think the current behaviour (is on and cannot be controlled)
> is all that desirable.
>
>From experience: MTU path discovery isn't that all fired reliable. Better
to just set the MTU to the highest guaranteed value on the last outgoing
router under one's control and leave it at that. I can't remember if it's
296. I hate losing my memory :-( The number is in the RFC's. Better to
take the performance hit than not have a reliable connection. The hitch
is blackhole routers.
--
Mike Murphy mrm@Mole.ORG +1 619 598 5874
Better is the enemy of Good
From owner-freebsd-hackers Thu Oct 23 10:22:57 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA11736
for hackers-outgoing; Thu, 23 Oct 1997 10:22:57 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.5.83])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA11731
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 10:22:53 -0700 (PDT)
(envelope-from tlambert@usr02.primenet.com)
Received: (from daemon@localhost)
by smtp02.primenet.com (8.8.7/8.8.7) id KAA27823;
Thu, 23 Oct 1997 10:04:53 -0700 (MST)
Received: from usr02.primenet.com(206.165.6.202)
via SMTP by smtp02.primenet.com, id smtpd027803; Thu Oct 23 10:04:47 1997
Received: (from tlambert@localhost)
by usr02.primenet.com (8.8.5/8.8.5) id KAA24394;
Thu, 23 Oct 1997 10:04:45 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710231704.KAA24394@usr02.primenet.com>
Subject: Re: Hardware RAID-x controllers for FreeBSD?
To: tom@sdf.com (Tom)
Date: Thu, 23 Oct 1997 17:04:45 +0000 (GMT)
Cc: jamil@trojanhorse.ml.org, dcarmich@mcs.net, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <Pine.BSF.3.95q.971021225743.11749B-100000@misery.sdf.com> from "Tom" at Oct 21, 97 11:00:27 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> The DPT SmartRaid IV works well. The driver is not incorporated into
> the base distribution, but you can get it for 2.2-stable and
> freebsd-current. I also like this card, because unlike the Mylex cards,
> additional channels can be added later via a daughtercard.
The Compaq RAID SCSI controller has a driver available from the author;
it has not been rolled into FreeBSD yet. Check the -hackers list
archives for details and the email address of the author.
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 Oct 23 10:26:01 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA11949
for hackers-outgoing; Thu, 23 Oct 1997 10:26:01 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.5.83])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA11944
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 10:25:59 -0700 (PDT)
(envelope-from tlambert@usr02.primenet.com)
Received: (from daemon@localhost)
by smtp02.primenet.com (8.8.7/8.8.7) id KAA00408;
Thu, 23 Oct 1997 10:25:28 -0700 (MST)
Received: from usr02.primenet.com(206.165.6.202)
via SMTP by smtp02.primenet.com, id smtpd000392; Thu Oct 23 10:25:25 1997
Received: (from tlambert@localhost)
by usr02.primenet.com (8.8.5/8.8.5) id KAA25749;
Thu, 23 Oct 1997 10:24:45 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710231724.KAA25749@usr02.primenet.com>
Subject: Re: Possible SERIOUS bug in open()?
To: thorpej@nas.nasa.gov
Date: Thu, 23 Oct 1997 17:24:41 +0000 (GMT)
Cc: jamil@trojanhorse.ml.org, joerg_wunsch@uriah.heep.sax.de,
freebsd-hackers@FreeBSD.ORG
In-Reply-To: <199710220909.CAA13732@lestat.nas.nasa.gov> from "Jason Thorpe" at Oct 22, 97 02:09:44 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > How exactly did you fix it, this is related to what I was saying about
> > opening a file as RD_ONLY and WR_ONLY, because if oflags = -1 then fflags
> > = 0 and that means the file is not open for read or write which my point
> > was that it should be forced to be open for one or the other. I don't
> > rememer who, but someone seemed to think that it could be actually useful
> > to hav a file not open for read or write
>
> How would opening for !read !write be useful? What else could you possibly
> want to do? (Yes, this is a trick question :-)
Hold a reference instance, but don't let your children have access
to read or write the device (ie: things like /dev/io).
Hold a reference instance to keep a Streams or similar stack instantiated,
even though you personally don't use it, because whoever does has a
tendency to crash and would otherwise take the stack with them and
make it necessary to rebuild the thing.
Call fcntl( fd, F_GETOWN, ...)
Call fdopen(), allowing the fd to be there, but not accessable except
through stdio updating the mode value
Proxy locks for NFS server locking, and use the lack of FREAD|FWRITE
to signal close(2) to override POSIX close/lock interaction semantics.
Call poll(2) on a directory to see if anything was added to it or
removed from it.
Become the process group leader on a tty so you get the SIGHUP on
ON-to-OFF DCD transition, but not do I/O (for example a session manager
on a tty, used as a credential holder for non-UNIX credentials, for
things like an SMB or NetWare client FS).
For use on a directory by a user usable "mount" command, without
giving full corresponding access to the user.
There are a *lot* of reasons.
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 Oct 23 10:29:44 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA12266
for hackers-outgoing; Thu, 23 Oct 1997 10:29:44 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA12257;
Thu, 23 Oct 1997 10:29:41 -0700 (PDT)
(envelope-from johnp@milo.lodgenet.com)
Received: from garbo.lodgenet.com (garbo.lodgenet.com [204.124.122.252])
by freefall.freebsd.org (8.8.6/8.8.5) with SMTP id KAA28214;
Thu, 23 Oct 1997 10:29:17 -0700 (PDT)
Received: from milo.lodgenet.com (milo.lodgenet.com [10.0.122.42]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id MAA06569; Thu, 23 Oct 1997 12:28:28 -0500
Received: from milo.lodgenet.com (localhost [127.0.0.1])
by milo.lodgenet.com (8.8.5/8.8.5) with ESMTP id MAA09336;
Thu, 23 Oct 1997 12:28:58 -0500 (CDT)
Message-Id: <199710231728.MAA09336@milo.lodgenet.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: hardware@freebsd.com, hackers@freebsd.com
Subject: Digi Xem
Reply-To: johnp@lodgenet.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 23 Oct 1997 12:28:58 -0500
From: John Prince <johnp@lodgenet.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
I'v read a few threads regarding Digi's Xem Mulitport, and was still
unsure.
Do we have a driver that supports the Xem product?
Thanks
--John
<johnp@lodgenet.com>
From owner-freebsd-hackers Thu Oct 23 10:31:40 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA12518
for hackers-outgoing; Thu, 23 Oct 1997 10:31:40 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA12513
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 10:31:38 -0700 (PDT)
(envelope-from tlambert@usr02.primenet.com)
Received: (from daemon@localhost)
by smtp04.primenet.com (8.8.7/8.8.7) id KAA13531;
Thu, 23 Oct 1997 10:31:32 -0700 (MST)
Received: from usr02.primenet.com(206.165.6.202)
via SMTP by smtp04.primenet.com, id smtpd013522; Thu Oct 23 10:31:30 1997
Received: (from tlambert@localhost)
by usr02.primenet.com (8.8.5/8.8.5) id KAA26108;
Thu, 23 Oct 1997 10:31:03 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710231731.KAA26108@usr02.primenet.com>
Subject: Re: Possible SERIOUS bug in open()?
To: thorpej@nas.nasa.gov
Date: Thu, 23 Oct 1997 17:31:02 +0000 (GMT)
Cc: dk+@ua.net, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <199710222030.NAA20863@lestat.nas.nasa.gov> from "Jason Thorpe" at Oct 22, 97 01:30:28 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> For ioctls that don't change the state of the device, you absolutely want
> to have it open for reading. I.e. if you have a device that can expose
> sensitive information by ioctl, and you set the mode to 600, you won't
> want random people opening it via the neat little open hole and performing
> that read-only ioctl.
What if I want to have a CDROM not mounted, allow users to mount it,
but not allow users to eject it? ...and at the same time, I have a
different drive that I want to allow users to both mount and eject?
I need to hold a reference. The "lock against eject" operation is
a side effect of an existing reference forcing the count over 1 for
the device in question.
So the short answer is "to obtain reference side effects without
granting read/write access on the descriptor".
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 Oct 23 10:46:15 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA13664
for hackers-outgoing; Thu, 23 Oct 1997 10:46:15 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA13659
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 10:46:12 -0700 (PDT)
(envelope-from jamil@trojanhorse.ml.org)
Received: from localhost (jamil@localhost)
by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id KAA02954;
Thu, 23 Oct 1997 10:43:05 -0700 (PDT)
Date: Thu, 23 Oct 1997 10:43:05 -0700 (PDT)
From: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
To: Terry Lambert <tlambert@primenet.com>
cc: thorpej@nas.nasa.gov, joerg_wunsch@uriah.heep.sax.de,
freebsd-hackers@FreeBSD.ORG
Subject: Re: Possible SERIOUS bug in open()? (Holy Shit!!!)
In-Reply-To: <199710231724.KAA25749@usr02.primenet.com>
Message-ID: <Pine.BSF.3.96.971023104116.2942B-100000@trojanhorse.ml.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> Hold a reference instance, but don't let your children have access
> to read or write the device (ie: things like /dev/io).
Wrong! The following code allows the regular joe blow user to read and
write to any port on the machine: (This is really bad)
I've verified that outb() is actually writing.
#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>
#include <err.h>
#include <machine/cpufunc.h>
int
main(int argc, char **argv)
{
int fd;
fd = open("/dev/io", -1, 0);
if (fd < 0)
err(1, "open");
outb (0x253,0x80);
outb (0x250,0xAA);
}
From owner-freebsd-hackers Thu Oct 23 10:54:18 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA14334
for hackers-outgoing; Thu, 23 Oct 1997 10:54:18 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA14313
for <hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 10:54:11 -0700 (PDT)
(envelope-from tlambert@usr02.primenet.com)
Received: (from daemon@localhost)
by smtp03.primenet.com (8.8.7/8.8.7) id KAA00365;
Thu, 23 Oct 1997 10:54:09 -0700 (MST)
Received: from usr02.primenet.com(206.165.6.202)
via SMTP by smtp03.primenet.com, id smtpd000359; Thu Oct 23 10:54:07 1997
Received: (from tlambert@localhost)
by usr02.primenet.com (8.8.5/8.8.5) id KAA27570;
Thu, 23 Oct 1997 10:54:06 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710231754.KAA27570@usr02.primenet.com>
Subject: Re: zipfs filesystem anyone ?
To: luigi@labinfo.iet.unipi.it (Luigi Rizzo)
Date: Thu, 23 Oct 1997 17:54:06 +0000 (GMT)
Cc: hackers@FreeBSD.ORG
In-Reply-To: <199710230638.HAA26030@labinfo.iet.unipi.it> from "Luigi Rizzo" at Oct 23, 97 07:38:26 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> Thus, I was looking at something which would pass all filesystem
> (or vn ?) calls to some user-space process which could then handle
> them properly. Using this approach, little modifications to, say,
> a standard "unzip" program, would permit such a filesystem to be
> implemented relatively easily. Efficiency is not a major concern
> for this type of application (especially because the typical use
> would be sequential access to files).
The VFS interface is not reflexive. Namei would expect your user
space code to free your path buffer allocated in the kernel. Also
you would have to externalize the lockmgr interface, and alias vnodes
in and out of the kernel, instead of treating them as opaque and using
a user space pointer in the data pointer. Etc..
Why do you think I go on and on about the VFS layering? It's not
because I'm an idiot, despite what some people think...
You could do one, but you will have to externalize a hell of a lot
of code, and provide proxy allocation and freeing mechanisms for
every place that is non-reflexive.
I have a device based FS gate for user space FS's, but it assumes
all of my FS changes, and is about 3 months out of sync with -current
8-(.
A better alternative for now might be to build a user space NFS server
at an alternate port (this is what the amd code does; you should look
at it, and "cryptofs" [comp.unix.sources] for more information).
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 Oct 23 10:56:19 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA14533
for hackers-outgoing; Thu, 23 Oct 1997 10:56:19 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.5.83])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA14523
for <hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 10:56:15 -0700 (PDT)
(envelope-from tlambert@usr02.primenet.com)
Received: (from daemon@localhost)
by smtp02.primenet.com (8.8.7/8.8.7) id KAA03717;
Thu, 23 Oct 1997 10:56:08 -0700 (MST)
Received: from usr02.primenet.com(206.165.6.202)
via SMTP by smtp02.primenet.com, id smtpd003690; Thu Oct 23 10:55:58 1997
Received: (from tlambert@localhost)
by usr02.primenet.com (8.8.5/8.8.5) id KAA27624;
Thu, 23 Oct 1997 10:55:57 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710231755.KAA27624@usr02.primenet.com>
Subject: Re: ACLs [Was: C2 Trusted FreeBSD?]
To: joerg_wunsch@uriah.heep.sax.de
Date: Thu, 23 Oct 1997 17:55:57 +0000 (GMT)
Cc: hackers@FreeBSD.ORG
In-Reply-To: <19971023092847.TP39265@uriah.heep.sax.de> from "J Wunsch" at Oct 23, 97 09:28:47 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > Yes, but how do you back them up, or, worse yet, restore them? How do
> > you copy your HTML directory tree to another drive you're bringing
> > on-line and preserve all the ACL settings? As noted before, *none*
> > of the system tools support the ACLs.
>
> I think you could make compatible changes to dump and restore to
> support ACLs. Perhaps, drop a second record containing the ACLs right
> behind an inode record (or even before, so the restore program knows
> about the intended ACLs before actually even seeing the inode
> information). The unknown records should simply be ignored by a
> restore that doesn't understand them.
If it's a stacking layer that uses a name space excape and uses a real
file in the underlying FS for the ACL's, then the answer is simple:
back up the underlying FS instead of the top layer of the stack.
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 Oct 23 10:56:38 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA14577
for hackers-outgoing; Thu, 23 Oct 1997 10:56:38 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA14566
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 10:56:31 -0700 (PDT)
(envelope-from jamil@trojanhorse.ml.org)
Received: from localhost (jamil@localhost)
by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id KAA03041;
Thu, 23 Oct 1997 10:54:25 -0700 (PDT)
Date: Thu, 23 Oct 1997 10:54:24 -0700 (PDT)
From: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
To: Terry Lambert <tlambert@primenet.com>
cc: thorpej@nas.nasa.gov, joerg_wunsch@uriah.heep.sax.de,
freebsd-hackers@FreeBSD.ORG
Subject: Re: Possible SERIOUS bug in open()? (Big time bug)
In-Reply-To: <199710231724.KAA25749@usr02.primenet.com>
Message-ID: <Pine.BSF.3.96.971023105123.2986A-100000@trojanhorse.ml.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Yep, tried reading an ioport on my service providers freebsd machine,
works fine. /dev/io is probably not the first and probably won't be the
last driver with this problem, in other works force to F_READ or F_WRITE.
That is precisely what I did in my dio driver because I depend on F_WRITE
and/or F_READ to be set to tell me about what the user wants.
From owner-freebsd-hackers Thu Oct 23 10:58:15 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA14711
for hackers-outgoing; Thu, 23 Oct 1997 10:58:15 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA14705
for <freebsd-hackers@freebsd.org>; Thu, 23 Oct 1997 10:58:14 -0700 (PDT)
(envelope-from thorpej@lestat.nas.nasa.gov)
Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.7/8.6.12) with SMTP id KAA04569; Thu, 23 Oct 1997 10:56:21 -0700 (PDT)
Message-Id: <199710231756.KAA04569@lestat.nas.nasa.gov>
X-Authentication-Warning: lestat.nas.nasa.gov: localhost [127.0.0.1] didn't use HELO protocol
To: Terry Lambert <tlambert@primenet.com>
Cc: dk+@ua.net, freebsd-hackers@freebsd.org
Subject: Re: Possible SERIOUS bug in open()?
Reply-To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Jason Thorpe <thorpej@nas.nasa.gov>
Date: Thu, 23 Oct 1997 10:56:17 -0700
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
On Thu, 23 Oct 1997 17:31:02 +0000 (GMT)
Terry Lambert <tlambert@primenet.com> wrote:
> I need to hold a reference. The "lock against eject" operation is
> a side effect of an existing reference forcing the count over 1 for
> the device in question.
>
> So the short answer is "to obtain reference side effects without
> granting read/write access on the descriptor".
I think "open for not read not write" is a silly way to do this, personally.
If you want to add/delete "artificial references", then invent a real
interface for it, don't use a hack like open with non-sensical flags.
Jason R. Thorpe thorpej@nas.nasa.gov
NASA Ames Research Center Home: +1 408 866 1912
NAS: M/S 258-6 Work: +1 415 604 0935
Moffett Field, CA 94035 Pager: +1 415 428 6939
From owner-freebsd-hackers Thu Oct 23 11:03:48 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA15092
for hackers-outgoing; Thu, 23 Oct 1997 11:03:48 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA15085
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 11:03:43 -0700 (PDT)
(envelope-from tlambert@usr02.primenet.com)
Received: (from daemon@localhost)
by smtp04.primenet.com (8.8.7/8.8.7) id LAA15386;
Thu, 23 Oct 1997 11:03:31 -0700 (MST)
Received: from usr02.primenet.com(206.165.6.202)
via SMTP by smtp04.primenet.com, id smtpd015372; Thu Oct 23 11:03:27 1997
Received: (from tlambert@localhost)
by usr02.primenet.com (8.8.5/8.8.5) id LAA28022;
Thu, 23 Oct 1997 11:03:19 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710231803.LAA28022@usr02.primenet.com>
Subject: Re: Broken device LKM in 2.2
To: mike@smith.net.au (Mike Smith)
Date: Thu, 23 Oct 1997 18:03:19 +0000 (GMT)
Cc: archie@whistle.com, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <199710231448.AAA00606@word.smith.net.au> from "Mike Smith" at Oct 24, 97 00:18:51 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > I guess nobody makes device type LKM's in 2.2.. but sys/lkm.h is
> > broken with respect to them. Here's a hack that fixes this. Perhaps
> > the "name ## _module", which is different from the other module
> > types, is there for some reason (?)
>
> IIRC it's there to avoid symbol conflicts with statically loaded
> versions. Could be wrong of course; there's nothing in the CVS log.
>
> > Anyway, it's incompatible with the DISPATCH macro defined later in
> > the file, and this fixes it...
>
> Has anyone looked at this? Should we buy it?
You want the uniquifier.
Think "disk device". A disk device LKM will want to define both a
character and a block interface. To do so would result in a symbol
conflict without the uniquifier.
You could consider any multiheaded device in the same light; for
example (bad example, I know... just let me get away with it) a
Streams module that was monolithic, but defined /dev/ip, /dev/tdp,
i/dev/icmp, and /dev/udp, seperately (to avoid getmsg/putmsg
boundry crossing internally adding a scheduling latency per
stack element boundry transition).
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 Oct 23 11:05:57 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA15262
for hackers-outgoing; Thu, 23 Oct 1997 11:05:57 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA15241
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 11:05:51 -0700 (PDT)
(envelope-from tlambert@usr02.primenet.com)
Received: (from daemon@localhost)
by smtp04.primenet.com (8.8.7/8.8.7) id LAA15566;
Thu, 23 Oct 1997 11:05:40 -0700 (MST)
Received: from usr02.primenet.com(206.165.6.202)
via SMTP by smtp04.primenet.com, id smtpd015530; Thu Oct 23 11:05:30 1997
Received: (from tlambert@localhost)
by usr02.primenet.com (8.8.5/8.8.5) id LAA28160;
Thu, 23 Oct 1997 11:05:18 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710231805.LAA28160@usr02.primenet.com>
Subject: Re: CHILD_MAX no longer valid in 2.2.5-RELEASE?
To: ghelmer@cs.iastate.edu (Guy Helmer)
Date: Thu, 23 Oct 1997 18:05:17 +0000 (GMT)
Cc: henrich@crh.cl.msu.edu, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <Pine.HPP.3.96.971023084622.2752D-100000@popeye.cs.iastate.edu> from "Guy Helmer" at Oct 23, 97 08:54:44 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > I've send CHILD_MAX to 512 on my news server, which (used) to have the
> > effect of making the default maximum procs set to 512.. Bonus. Under
> > 2.2.5-RELEASE it doesnt appear to be having any effect :( The only
> > thing I can think of is, its placement in the config file is order
> > important, or its no longer supported? If the latter, how do you
> > effect the same change in 2.2.5?
>
> init uses the "daemon" entry in /etc/login.conf to set process resource
> limits before executing /etc/rc; it appears to me that the "maxproc" entry
> (maxproc=256) is the one you need to adjust (see also login.conf(5) and
> getcap(3)).
Out of curiosity, what is the function of establishing a limit on rc
itself, as opposed to only the things rc runs?
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 Oct 23 11:08:52 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA15427
for hackers-outgoing; Thu, 23 Oct 1997 11:08:52 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA15422
for <freebsd-hackers@freebsd.org>; Thu, 23 Oct 1997 11:08:50 -0700 (PDT)
(envelope-from tlambert@usr02.primenet.com)
Received: (from daemon@localhost)
by smtp04.primenet.com (8.8.7/8.8.7) id LAA15746;
Thu, 23 Oct 1997 11:08:50 -0700 (MST)
Received: from usr02.primenet.com(206.165.6.202)
via SMTP by smtp04.primenet.com, id smtpd015739; Thu Oct 23 11:08:44 1997
Received: (from tlambert@localhost)
by usr02.primenet.com (8.8.5/8.8.5) id LAA28324;
Thu, 23 Oct 1997 11:08:40 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710231808.LAA28324@usr02.primenet.com>
Subject: Re: Possible SERIOUS bug in open()?
To: thorpej@nas.nasa.gov
Date: Thu, 23 Oct 1997 18:08:40 +0000 (GMT)
Cc: tlambert@primenet.com, dk+@ua.net, freebsd-hackers@freebsd.org
In-Reply-To: <199710231756.KAA04569@lestat.nas.nasa.gov> from "Jason Thorpe" at Oct 23, 97 10:56:17 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> > I need to hold a reference. The "lock against eject" operation is
> > a side effect of an existing reference forcing the count over 1 for
> > the device in question.
> >
> > So the short answer is "to obtain reference side effects without
> > granting read/write access on the descriptor".
>
> I think "open for not read not write" is a silly way to do this, personally.
>
> If you want to add/delete "artificial references", then invent a real
> interface for it, don't use a hack like open with non-sensical flags.
By this logic, locking should be implemented via a system call instead
of a hack like fcntl(). 8-(.
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 Oct 23 11:15:24 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA15796
for hackers-outgoing; Thu, 23 Oct 1997 11:15:24 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA15780
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 11:15:14 -0700 (PDT)
(envelope-from julian@whistle.com)
Received: (from daemon@localhost)
by alpo.whistle.com (8.8.5/8.8.5) id LAA21430;
Thu, 23 Oct 1997 11:13:00 -0700 (PDT)
Received: from current1.whistle.com(207.76.205.22)
via SMTP by alpo.whistle.com, id smtpd021424; Thu Oct 23 18:12:50 1997
Date: Thu, 23 Oct 1997 11:11:16 -0700 (PDT)
From: Julian Elischer <julian@whistle.com>
To: Mike Smith <mike@smith.net.au>
cc: Archie Cobbs <archie@whistle.com>, freebsd-hackers@FreeBSD.ORG
Subject: Re: Broken device LKM in 2.2
In-Reply-To: <199710231448.AAA00606@word.smith.net.au>
Message-ID: <Pine.BSF.3.95.971023110931.23970B-100000@current1.whistle.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
well it works with this change and doesn't even compile without it..
terry (who originaly wrote it) works here now, and blessed it..
and I can't see a problem..
how much do you need?
I'm planning on committing it myself unless someone gets to it first.
julian
On Fri, 24 Oct 1997, Mike Smith wrote:
> >
> > I guess nobody makes device type LKM's in 2.2.. but sys/lkm.h is
> > broken with respect to them. Here's a hack that fixes this. Perhaps
> > the "name ## _module", which is different from the other module
> > types, is there for some reason (?)
>
> IIRC it's there to avoid symbol conflicts with statically loaded
> versions. Could be wrong of course; there's nothing in the CVS log.
>
> > Anyway, it's incompatible with the DISPATCH macro defined later in
> > the file, and this fixes it...
>
> Has anyone looked at this? Should we buy it?
>
> mike
>
>
>
From owner-freebsd-hackers Thu Oct 23 11:35:10 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA17251
for hackers-outgoing; Thu, 23 Oct 1997 11:35:10 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA17240
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 11:35:06 -0700 (PDT)
(envelope-from wilko@yedi.iaf.nl)
Received: by iafnl.es.iaf.nl with UUCP id AA15654
(5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Thu, 23 Oct 1997 20:35:19 +0200
Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id TAA02672; Thu, 23 Oct 1997 19:30:15 +0100 (MET)
From: Wilko Bulte <wilko@yedi.iaf.nl>
Message-Id: <199710231830.TAA02672@yedi.iaf.nl>
Subject: Re: DLT drives
To: joerg_wunsch@uriah.heep.sax.de
Date: Thu, 23 Oct 1997 19:30:15 +0100 (MET)
Cc: freebsd-hackers@FreeBSD.ORG
In-Reply-To: <19971023001841.RF25584@uriah.heep.sax.de> from "J Wunsch" at Oct 23, 97 00:18:41 am
X-Organisation: Private FreeBSD site - Arnhem, The Netherlands
X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org'
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-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As J Wunsch wrote...
> As Wilko Bulte wrote:
>
> > Check out http://www.quantum.com There are something like 5 or so
> > firmware personalities, e.g. also one that pretends to be an Exabyte.
>
> Oh, i hope it doesn't jam the cassette as often as Exabytes tend to
> do. :-]
Fortunately not. You could speak of a split personality in this case.
_ ____________________________________________________________________
| / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko
|/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try'
------------------ Support your local daemons: run FreeBSD Unix -----Yoda
From owner-freebsd-hackers Thu Oct 23 12:07:25 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id MAA19628
for hackers-outgoing; Thu, 23 Oct 1997 12:07:25 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from garbo.lodgenet.com (garbo.lodgenet.com [204.124.122.252])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA19574;
Thu, 23 Oct 1997 12:07:10 -0700 (PDT)
(envelope-from johnp@milo.lodgenet.com)
Received: from milo.lodgenet.com (milo.lodgenet.com [10.0.122.42]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id OAA08574; Thu, 23 Oct 1997 14:05:59 -0500
Received: from milo.lodgenet.com (localhost [127.0.0.1])
by milo.lodgenet.com (8.8.5/8.8.5) with ESMTP id OAA10694;
Thu, 23 Oct 1997 14:06:36 -0500 (CDT)
Message-Id: <199710231906.OAA10694@milo.lodgenet.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: hardware@freebsd.org, hackers@freebsd.org
Subject: Digi Xem
Reply-To: johnp@lodgenet.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 23 Oct 1997 14:06:36 -0500
From: John Prince <johnp@lodgenet.com>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I'v read a few threads regarding Digi's Xem Mulitport, and was still
unsure.
Do we have a driver that supports the Xem product?
Thanks
--John
<johnp@lodgenet.com>
From owner-freebsd-hackers Thu Oct 23 12:13:35 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id MAA20238
for hackers-outgoing; Thu, 23 Oct 1997 12:13:35 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from citrine.cyberstation.net (hannibal@citrine.cyberstation.net [205.167.0.5])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA20223
for <hackers@freebsd.org>; Thu, 23 Oct 1997 12:13:31 -0700 (PDT)
(envelope-from hannibal@cyberstation.net)
Received: from localhost (hannibal@localhost)
by citrine.cyberstation.net (8.8.7/8.8.7) with SMTP id OAA05128;
Thu, 23 Oct 1997 14:13:19 -0500 (CDT)
Date: Thu, 23 Oct 1997 14:13:19 -0500 (CDT)
From: Dan Walters <hannibal@cyberstation.net>
To: Mike Smith <mike@smith.net.au>
cc: hackers@freebsd.org
Subject: Re: ATAPI CD-RW documentation...
In-Reply-To: <199710231539.BAA00881@word.smith.net.au>
Message-ID: <Pine.BSI.3.96.971023135209.2846B-100000@citrine.cyberstation.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
On Fri, 24 Oct 1997, Mike Smith wrote:
> > Never mind, it's amazing how you always find things right after you give
> > up and ask. :) For anyone wondering, the motherload of specs can be
> > found by ftp at fission.dt.wdc.com, including the working draft of the
> > ATAPI Removable Rewritable Specification, SFF-8070. Wish their web pages
> > would mention the site. :)
>
> Thanks for finding the number for me; I ran out of patience downloading
> them, struggling to print them and giving up 8)
It may be SFF-8080 though - I thought 8070 was it, but after reading the
intro it sounded more like something for the new floppy drives... 8080 is
clearly CD-RW.
> Nobody's begun any work, as such. Again, I exhort you to look at
> Justin Gibbs' CAM framework; it is the future of mass storage
> interfaces in FreeBSD, and we should be looking towards it.
Already downloaded it, just havn't had the chance to look at any of it
yet. I take it that going the CAM route would be a completely different
approach than writing an ATAPI sub-driver?
======================================================================
Dan Walters
hannibal@cyberstation.net
======================================================================
From owner-freebsd-hackers Thu Oct 23 12:20:55 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id MAA20906
for hackers-outgoing; Thu, 23 Oct 1997 12:20:55 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA20899
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 12:20:50 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA14825 for freebsd-hackers@FreeBSD.ORG; Thu, 23 Oct 1997 21:20:39 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id VAA05710;
Thu, 23 Oct 1997 21:17:57 +0200 (MET DST)
Message-ID: <19971023211757.IO46198@uriah.heep.sax.de>
Date: Thu, 23 Oct 1997 21:17:57 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: freebsd-hackers@FreeBSD.ORG
Subject: Re: page fault
References: <199710231647.LAA04258@elvis.mu.org>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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: <199710231647.LAA04258@elvis.mu.org>; from Paul Saab on Oct 23, 1997 11:47:07 -0500
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Paul Saab wrote:
> Ok.. here is what I got...
Hmm, Paul also sent it via private mail, and i've answered this
before.
--
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 Oct 23 12:36:00 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id MAA21798
for hackers-outgoing; Thu, 23 Oct 1997 12:36:00 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA21780
for <hackers@freebsd.org>; Thu, 23 Oct 1997 12:35:57 -0700 (PDT)
(envelope-from nate@rocky.mt.sri.com)
Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100])
by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id NAA11547;
Thu, 23 Oct 1997 13:35:27 -0600 (MDT)
Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA16573; Thu, 23 Oct 1997 13:35:27 -0600 (MDT)
Date: Thu, 23 Oct 1997 13:35:27 -0600 (MDT)
Message-Id: <199710231935.NAA16573@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: Terry Lambert <tlambert@primenet.com>
Cc: luigi@labinfo.iet.unipi.it (Luigi Rizzo), hackers@freebsd.org
Subject: Re: zipfs filesystem anyone ?
In-Reply-To: <199710231754.KAA27570@usr02.primenet.com>
References: <199710230638.HAA26030@labinfo.iet.unipi.it>
<199710231754.KAA27570@usr02.primenet.com>
X-Mailer: VM 6.29 under 19.15 XEmacs Lucid
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Terry Lambert writes:
> > Thus, I was looking at something which would pass all filesystem
> > (or vn ?) calls to some user-space process which could then handle
> > them properly. Using this approach, little modifications to, say,
> > a standard "unzip" program, would permit such a filesystem to be
> > implemented relatively easily. Efficiency is not a major concern
> > for this type of application (especially because the typical use
> > would be sequential access to files).
>
> The VFS interface is not reflexive.
Forgive me, but does that mean that the interface doesn't jerk when you
hit it in the knee? *grin*
Nate
From owner-freebsd-hackers Thu Oct 23 13:04:52 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id NAA23775
for hackers-outgoing; Thu, 23 Oct 1997 13:04:52 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA23759
for <freebsd-hackers@freebsd.org>; Thu, 23 Oct 1997 13:04:44 -0700 (PDT)
(envelope-from jbryant@argus.tfs.net)
Received: from argus.tfs.net (pm3-p42.tfs.net [206.154.183.234]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id PAA01600; Thu, 23 Oct 1997 15:03:52 -0500
Received: (from jbryant@localhost)
by argus.tfs.net (8.8.7/8.8.5) id PAA15951;
Thu, 23 Oct 1997 15:04:34 -0500 (CDT)
From: Jim Bryant <jbryant@unix.tfs.net>
Message-Id: <199710232004.PAA15951@argus.tfs.net>
Subject: Re: CHILD_MAX no longer valid in 2.2.5-RELEASE?
In-Reply-To: <199710231805.LAA28160@usr02.primenet.com> from Terry Lambert at "Oct 23, 97 06:05:17 pm"
To: tlambert@primenet.com (Terry Lambert)
Date: Thu, 23 Oct 1997 15:04:33 -0500 (CDT)
Cc: freebsd-hackers@freebsd.org
Reply-to: jbryant@tfs.net
X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@#
X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
In reply:
> Out of curiosity, what is the function of establishing a limit on rc
> itself, as opposed to only the things rc runs?
root's login.conf???
jim
--
All opinions expressed are mine, if you | "I will not be pushed, stamped,
think otherwise, then go jump into turbid | briefed, debriefed, indexed, or
radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner"
------------------------------------------------------------------------------
Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw
voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant
------------------------------------------------------------------------------
HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+
From owner-freebsd-hackers Thu Oct 23 13:46:17 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id NAA26414
for hackers-outgoing; Thu, 23 Oct 1997 13:46:17 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from elvis.mu.org (elvis.mu.org [206.156.231.253])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA26404
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 13:46:13 -0700 (PDT)
(envelope-from paul@elvis.mu.org)
Received: (from paul@localhost)
by elvis.mu.org (8.8.7/8.8.7) id PAA13423
for freebsd-hackers@FreeBSD.ORG; Thu, 23 Oct 1997 15:46:10 -0500 (CDT)
(envelope-from paul)
From: Paul Saab <paul@mu.org>
Message-Id: <199710232046.PAA13423@elvis.mu.org>
Subject: Re: page fault
In-Reply-To: <19971023211757.IO46198@uriah.heep.sax.de> from J Wunsch at "Oct 23, 97 09:17:57 pm"
To: freebsd-hackers@FreeBSD.ORG
Date: Thu, 23 Oct 1997 15:46:10 -0500 (CDT)
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
sorry about that.. I hit the wrong button when replying.
paul
J Wunsch wrote:
> As Paul Saab wrote:
>
> > Ok.. here is what I got...
>
> Hmm, Paul also sent it via private mail, and i've answered this
> before.
>
> --
> 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 Oct 23 14:11:47 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA28237
for hackers-outgoing; Thu, 23 Oct 1997 14:11:47 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA28231
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 14:11:43 -0700 (PDT)
(envelope-from dufault@hda.hda.com)
Received: (from dufault@localhost)
by hda.hda.com (8.8.5/8.8.5) id QAA12714;
Thu, 23 Oct 1997 16:21:40 -0400 (EDT)
From: Peter Dufault <dufault@hda.com>
Message-Id: <199710232021.QAA12714@hda.hda.com>
Subject: Re: Broken device LKM in 2.2
In-Reply-To: <Pine.BSF.3.95.971023110931.23970B-100000@current1.whistle.com> from Julian Elischer at "Oct 23, 97 11:11:16 am"
To: julian@whistle.com (Julian Elischer)
Date: Thu, 23 Oct 1997 16:21:39 -0400 (EDT)
Cc: mike@smith.net.au, archie@whistle.com, 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-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> well it works with this change and doesn't even compile without it..
> terry (who originaly wrote it) works here now, and blessed it..
> and I can't see a problem..
> how much do you need?
> I'm planning on committing it myself unless someone gets to it first.
Something like this was broken in -current and I kicked it, look
there to see if we're talking the same thing.
I don't have source here so I can't help right now.
Peter
--
Peter Dufault (dufault@hda.com) Realtime development, Machine control,
HD Associates, Inc. Safety critical systems, Agency approval
From owner-freebsd-hackers Thu Oct 23 14:29:17 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA29110
for hackers-outgoing; Thu, 23 Oct 1997 14:29:17 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA29105
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 14:29:15 -0700 (PDT)
(envelope-from tlambert@usr05.primenet.com)
Received: (from daemon@localhost)
by smtp03.primenet.com (8.8.7/8.8.7) id OAA12707;
Thu, 23 Oct 1997 14:29:00 -0700 (MST)
Received: from usr05.primenet.com(206.165.6.205)
via SMTP by smtp03.primenet.com, id smtpd012699; Thu Oct 23 14:28:58 1997
Received: (from tlambert@localhost)
by usr05.primenet.com (8.8.5/8.8.5) id OAA06900;
Thu, 23 Oct 1997 14:28:51 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710232128.OAA06900@usr05.primenet.com>
Subject: Re: Possible SERIOUS bug in open()? (Big time bug)
To: jamil@trojanhorse.ml.org (Jamil J. Weatherbee)
Date: Thu, 23 Oct 1997 21:28:51 +0000 (GMT)
Cc: tlambert@primenet.com, thorpej@nas.nasa.gov,
joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <Pine.BSF.3.96.971023105123.2986A-100000@trojanhorse.ml.org> from "Jamil J. Weatherbee" at Oct 23, 97 10:54:24 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> Yep, tried reading an ioport on my service providers freebsd machine,
> works fine. /dev/io is probably not the first and probably won't be the
> last driver with this problem, in other works force to F_READ or F_WRITE.
> That is precisely what I did in my dio driver because I depend on F_WRITE
> and/or F_READ to be set to tell me about what the user wants.
I agree; this is a driver issue; the driver should enforce permissions
when the user attempts the outb.
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 Oct 23 14:40:59 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA29739
for hackers-outgoing; Thu, 23 Oct 1997 14:40:59 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA29725
for <freebsd-hackers@freebsd.org>; Thu, 23 Oct 1997 14:40:31 -0700 (PDT)
(envelope-from tlambert@usr05.primenet.com)
Received: (from daemon@localhost)
by smtp04.primenet.com (8.8.7/8.8.7) id OAA27908;
Thu, 23 Oct 1997 14:40:18 -0700 (MST)
Received: from usr05.primenet.com(206.165.6.205)
via SMTP by smtp04.primenet.com, id smtpd027906; Thu Oct 23 14:40:13 1997
Received: (from tlambert@localhost)
by usr05.primenet.com (8.8.5/8.8.5) id OAA07475;
Thu, 23 Oct 1997 14:40:10 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710232140.OAA07475@usr05.primenet.com>
Subject: Re: CHILD_MAX no longer valid in 2.2.5-RELEASE?
To: jbryant@tfs.net
Date: Thu, 23 Oct 1997 21:40:10 +0000 (GMT)
Cc: tlambert@primenet.com, freebsd-hackers@freebsd.org
In-Reply-To: <199710232004.PAA15951@argus.tfs.net> from "Jim Bryant" at Oct 23, 97 03:04:33 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> > Out of curiosity, what is the function of establishing a limit on rc
> > itself, as opposed to only the things rc runs?
>
> root's login.conf???
If I'm root, I should be able to shoot myself in the foot if I want to.
I understand the denial of service aspects for non-root users shooting
each other in the foot, and the daemon aspects as regards daemons that
malfunction.
But root has a moral obligation to let me aim at my foot.
So I'd still like to know the function of establishing a limit on rc
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 Thu Oct 23 14:46:20 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA29941
for hackers-outgoing; Thu, 23 Oct 1997 14:46:20 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA29933
for <hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 14:46:10 -0700 (PDT)
(envelope-from tlambert@usr05.primenet.com)
Received: (from daemon@localhost)
by smtp03.primenet.com (8.8.7/8.8.7) id OAA14604;
Thu, 23 Oct 1997 14:46:00 -0700 (MST)
Received: from usr05.primenet.com(206.165.6.205)
via SMTP by smtp03.primenet.com, id smtpd014599; Thu Oct 23 14:45:56 1997
Received: (from tlambert@localhost)
by usr05.primenet.com (8.8.5/8.8.5) id OAA07834;
Thu, 23 Oct 1997 14:45:46 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710232145.OAA07834@usr05.primenet.com>
Subject: Re: zipfs filesystem anyone ?
To: nate@mt.sri.com (Nate Williams)
Date: Thu, 23 Oct 1997 21:45:46 +0000 (GMT)
Cc: tlambert@primenet.com, luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG
In-Reply-To: <199710231935.NAA16573@rocky.mt.sri.com> from "Nate Williams" at Oct 23, 97 01:35:27 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > The VFS interface is not reflexive.
>
> Forgive me, but does that mean that the interface doesn't jerk when you
> hit it in the knee? *grin*
No, it's a term from computer science, not medicine.
It means that there are side effects to the interface, and that the
caller is dependent on the side effects.
It's very difficult to proxy a side effect across a procedural only
interface (like corssing the user/kernel boundry).
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 Oct 23 14:53:29 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA00506
for hackers-outgoing; Thu, 23 Oct 1997 14:53:29 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from garbo.lodgenet.com (garbo.lodgenet.com [204.124.122.252])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA00480;
Thu, 23 Oct 1997 14:53:22 -0700 (PDT)
(envelope-from johnp@milo.lodgenet.com)
Received: from milo.lodgenet.com (milo.lodgenet.com [10.0.122.42]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id QAA13779; Thu, 23 Oct 1997 16:52:13 -0500
Received: from milo.lodgenet.com (localhost [127.0.0.1])
by milo.lodgenet.com (8.8.5/8.8.5) with ESMTP id QAA13502;
Thu, 23 Oct 1997 16:52:50 -0500 (CDT)
Message-Id: <199710232152.QAA13502@milo.lodgenet.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: hardware@freebsd.org, hackers@freebsd.org
Reply-To: johnp@lodgenet.com
Mime-Version: 1.0
Content-Type: text/plain
Date: Thu, 23 Oct 1997 16:52:50 -0500
From: John Prince <johnp@lodgenet.com>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I'v read a few threads regarding Digi's Xem Mulitport, and was still
unsure.
Do we have a driver that supports the Xem product?
Thanks
--John
<johnp@lodgenet.com>
From owner-freebsd-hackers Thu Oct 23 15:08:06 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA01420
for hackers-outgoing; Thu, 23 Oct 1997 15:08:06 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA01411
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 15:08:02 -0700 (PDT)
(envelope-from jamil@trojanhorse.ml.org)
Received: from localhost (jamil@localhost)
by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id PAA03543;
Thu, 23 Oct 1997 15:06:23 -0700 (PDT)
Date: Thu, 23 Oct 1997 15:06:23 -0700 (PDT)
From: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
To: Terry Lambert <tlambert@primenet.com>
cc: thorpej@nas.nasa.gov, joerg_wunsch@uriah.heep.sax.de,
freebsd-hackers@FreeBSD.ORG
Subject: Re: Possible SERIOUS bug in open()? (Big time bug)
In-Reply-To: <199710232128.OAA06900@usr05.primenet.com>
Message-ID: <Pine.BSF.3.96.971023150036.3526A-100000@trojanhorse.ml.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Thu, 23 Oct 1997, Terry Lambert wrote:
> > Yep, tried reading an ioport on my service providers freebsd machine,
> > works fine. /dev/io is probably not the first and probably won't be the
> > last driver with this problem, in other works force to F_READ or F_WRITE.
> > That is precisely what I did in my dio driver because I depend on F_WRITE
> > and/or F_READ to be set to tell me about what the user wants.
>
> I agree; this is a driver issue; the driver should enforce permissions
> when the user attempts the outb.
No, the user open() should return error for somebody trying to open for
not read and not write. /dev/io gives the process IOPL on the basis that
it is able to open /dev/io, not do operations on it. I think it is
perfectly reasonable for the driver to expect its open method called only
if the user has permissions on the file. When you start putting the
responsibility on the driver for maintaining the security of the system
and not the kernel then your'e just asking for trouble. Much like most
drivers do not check to see if the device being passed is valid once it is
opened because it should always be valid (under most circumstances).
>
>
> 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 Oct 23 15:11:53 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA01611
for hackers-outgoing; Thu, 23 Oct 1997 15:11:53 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA01604
for <hackers@freebsd.org>; Thu, 23 Oct 1997 15:11:49 -0700 (PDT)
(envelope-from nate@rocky.mt.sri.com)
Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100])
by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id QAA12560;
Thu, 23 Oct 1997 16:11:29 -0600 (MDT)
Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id QAA17154; Thu, 23 Oct 1997 16:11:28 -0600 (MDT)
Date: Thu, 23 Oct 1997 16:11:28 -0600 (MDT)
Message-Id: <199710232211.QAA17154@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: Terry Lambert <tlambert@primenet.com>
Cc: nate@mt.sri.com (Nate Williams), luigi@labinfo.iet.unipi.it,
hackers@freebsd.org
Subject: Re: zipfs filesystem anyone ?
In-Reply-To: <199710232145.OAA07834@usr05.primenet.com>
References: <199710231935.NAA16573@rocky.mt.sri.com>
<199710232145.OAA07834@usr05.primenet.com>
X-Mailer: VM 6.29 under 19.15 XEmacs Lucid
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> > > The VFS interface is not reflexive.
> >
> > Forgive me, but does that mean that the interface doesn't jerk when you
> > hit it in the knee? *grin*
>
> No, it's a term from computer science, not medicine.
Never heard it in any of my classes.
> It means that there are side effects to the interface, and that the
> caller is dependent on the side effects.
Kind of like strdup(3)? *grin*
Nate
From owner-freebsd-hackers Thu Oct 23 15:30:34 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA02515
for hackers-outgoing; Thu, 23 Oct 1997 15:30:34 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA02510
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 15:30:30 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA17278 for freebsd-hackers@FreeBSD.ORG; Fri, 24 Oct 1997 00:30:22 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id AAA07220;
Fri, 24 Oct 1997 00:24:51 +0200 (MET DST)
Message-ID: <19971024002450.UZ51487@uriah.heep.sax.de>
Date: Fri, 24 Oct 1997 00:24:50 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: freebsd-hackers@FreeBSD.ORG
Subject: Re: Possible SERIOUS bug in open()? (Big time bug)
References: <199710232128.OAA06900@usr05.primenet.com> <Pine.BSF.3.96.971023150036.3526A-100000@trojanhorse.ml.org>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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: freebsd-hackers@FreeBSD.ORG
In-Reply-To: <Pine.BSF.3.96.971023150036.3526A-100000@trojanhorse.ml.org>; from Jamil J. Weatherbee on Oct 23, 1997 15:06:23 -0700
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Jamil J. Weatherbee wrote:
> No, the user open() should return error for somebody trying to open for
> not read and not write.
It does (now). Why the h*ck are you both still arguing about it? For
me (being in MET DST timezone), it's already a matter of yesterday...
--
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 Oct 23 17:54:18 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id RAA09874
for hackers-outgoing; Thu, 23 Oct 1997 17:54:18 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA09863
for <hackers@freebsd.org>; Thu, 23 Oct 1997 17:54:15 -0700 (PDT)
(envelope-from mrcpu@cdsnet.net)
Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5])
by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id RAA10950
for <hackers@freebsd.org>; Thu, 23 Oct 1997 17:54:13 -0700 (PDT)
Date: Thu, 23 Oct 1997 17:54:13 -0700 (PDT)
From: Jaye Mathisen <mrcpu@cdsnet.net>
To: hackers@freebsd.org
Subject: Weird CVSUP messages.
Message-ID: <Pine.NEB.3.95.971023175303.2315o-100000@mail.cdsnet.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I cvsup -current about 2-3 times a week on average.
So why now am I getting delta's dated back in 1994? Should I be worried?
Edit src/usr.sbin/timed/timedc/cmdtab.c
Add delta 1.1 94.05.26.05.23.25 rgrimes
Add delta 1.2 97.10.22.06.20.04 charnier
Edit src/usr.sbin/timed/timedc/timedc.8
Add delta 1.4 97.10.22.06.20.04 charnier
Edit src/usr.sbin/timed/timedc/timedc.c
Add delta 1.1 94.05.26.05.23.25 rgrimes
Add delta 1.2 97.10.22.06.20.04 charnier
From owner-freebsd-hackers Thu Oct 23 19:25:09 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA14009
for hackers-outgoing; Thu, 23 Oct 1997 19:25:09 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (word.smith.net.au [202.0.75.3])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA14004
for <hackers@freebsd.org>; Thu, 23 Oct 1997 19:25:05 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id LAA00498;
Fri, 24 Oct 1997 11:51:29 +0930 (CST)
Message-Id: <199710240221.LAA00498@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Dan Walters <hannibal@cyberstation.net>
cc: Mike Smith <mike@smith.net.au>, hackers@freebsd.org
Subject: Re: ATAPI CD-RW documentation...
In-reply-to: Your message of "Thu, 23 Oct 1997 14:13:19 EST."
<Pine.BSI.3.96.971023135209.2846B-100000@citrine.cyberstation.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 24 Oct 1997 11:51:29 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
>
>
> > Nobody's begun any work, as such. Again, I exhort you to look at
> > Justin Gibbs' CAM framework; it is the future of mass storage
> > interfaces in FreeBSD, and we should be looking towards it.
>
> Already downloaded it, just havn't had the chance to look at any of it
> yet. I take it that going the CAM route would be a completely different
> approach than writing an ATAPI sub-driver?
Yes. Aside from the fact that the code would have a much longer life,
adding the requisite ATAPI parts to the CAM framework would
automatically buy you CD-RW, IDE tape and ATAPI disk support, modulo a
little more work.
mike
From owner-freebsd-hackers Thu Oct 23 19:26:56 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA14106
for hackers-outgoing; Thu, 23 Oct 1997 19:26:56 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA14101
for <hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 19:26:53 -0700 (PDT)
(envelope-from michaelh@cet.co.jp)
Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id CAA18094; Fri, 24 Oct 1997 02:26:00 GMT
Date: Fri, 24 Oct 1997 11:25:59 +0900 (JST)
From: Michael Hancock <michaelh@cet.co.jp>
To: Terry Lambert <tlambert@primenet.com>
cc: Luigi Rizzo <luigi@labinfo.iet.unipi.it>, hackers@FreeBSD.ORG
Subject: Re: zipfs filesystem anyone ?
In-Reply-To: <199710231754.KAA27570@usr02.primenet.com>
Message-ID: <Pine.SV4.3.95.971024111008.17710C-100000@parkplace.cet.co.jp>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Thu, 23 Oct 1997, Terry Lambert wrote:
> The VFS interface is not reflexive. Namei would expect your user
> space code to free your path buffer allocated in the kernel. Also
> you would have to externalize the lockmgr interface, and alias vnodes
> in and out of the kernel, instead of treating them as opaque and using
> a user space pointer in the data pointer. Etc..
[..]
> You could do one, but you will have to externalize a hell of a lot
> of code, and provide proxy allocation and freeing mechanisms for
> every place that is non-reflexive.
[..]
> A better alternative for now might be to build a user space NFS server
> at an alternate port (this is what the amd code does; you should look
> at it, and "cryptofs" [comp.unix.sources] for more information).
Wouldn't you have to externalize a lot of stuff anyway? We'd need some
extra syscalls along the lines of John Heidemann's ook* (Out Of Kernel)
stuff. You can make a fs specific call that serves as a general interface
to marshall fs related operations in and out of the kernel.
Then you can make a semantic-free user layer. It seems that a lot of NFS
related work these days have to do with adding state.
I was looking at this a few months ago after John H. released his layering
code.
It also seems that Poul and John Dyson have started cleaning up some fs
related interface and memory issues, but I haven't had time to examine all
the details.
Regards,
Mike Hancock
>
> 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 Oct 23 19:58:13 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA15785
for hackers-outgoing; Thu, 23 Oct 1997 19:58:13 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from bugs.us.dell.com (bugs.us.dell.com [143.166.169.147])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA15724
for <hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 19:57:45 -0700 (PDT)
(envelope-from tony@dell.com)
Received: from moth.us.dell.com (moth.us.dell.com [143.166.169.152]) by bugs.us.dell.com (8.6.12/8.6.12) with SMTP id VAA10425 for <hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 21:57:06 -0500
Message-Id: <3.0.3.32.19971023215701.006dc4b0@bugs.us.dell.com>
X-Sender: tony@bugs.us.dell.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Thu, 23 Oct 1997 21:57:01 -0500
To: hackers@FreeBSD.ORG
From: Tony Overfield <tony@dell.com>
Subject: fixes for syscons.c and daemon_saver.c
In-Reply-To: <199710221007.MAA01578@curry.mchp.siemens.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
While playing with the Dancin' Daemon screen saver, I noticed
three minor problems.
1. On some video cards (S3 Trio64 based ones at least), there
is a continuous, but brief, video glitch that mars the beauty
of the screen saver. It is caused by continuously updating
the border color, which briefly (for several pixel clocks)
sets the pixel data to the border color. This should be a
black glitch, but for some reason, it's producing a short
blue glitch on the Trio64 based cards.
One possible fix (in set_border() (syscons.c)):
Change this:
outb(ATC, 0x11); outb(ATC, color);
inb(crtc_addr + 6); /* reset flip-flop */
outb(ATC, 0x20); /* enable Palette */
to this:
outb(ATC, 0x31); outb(ATC, color);
This keeps valid pixel data from being replaced by the contents
of the overscan register.
Alternate (or additional) fix (in daemon_saver() (daemon_saver.c)):
Change code to call set_border(0) only once, like this:
if (blank) {
if (scrn_blanked == 0)
set_border(0);
if (scrn_blanked++ < 2)
return;
fillw( .... );
/* set_border(0); */
2. Switching video modes from VGA_80x50 to VGA_80x25 (and etc.)
can allow the Daemon and the hostname strings to wander far off
the edge of the screen, crashing the kernel after a short time.
This happens because the dimensions of the screen can change
after the static position variables have been moved outside
the new screen dimensions.
Suggested fix:
Change the code (in daemon_saver() (daemon_saver.c)) to make
inequality boundary crossing checks,
like this:
if (dxpos >= scp->xsize - DAEMON_MAX_WIDTH)
instead of:
if (dxpos == scp->xsize - DAEMON_MAX_WIDTH)
(repeat this 7 more times)
The code should also force the txpos, typos, dxpos, dypos variables
to all be in range, though this change will get them back in range
fairly quickly.
The draw_string(... message ...) stuff doesn't work right when the
message string is longer than the width of the screen, which is
easy to do in VGA_40x25 mode. The fix above doesn't fix this, but
it prevents it from trashing the system.
3. syscons.c does not maintain the border color correctly when
switching virtual terminals.
Suggested fix (in exchange_scr() (syscons.c)):
Add:
set_border(new_scp->border);
-
Tony
From owner-freebsd-hackers Thu Oct 23 20:35:56 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id UAA17650
for hackers-outgoing; Thu, 23 Oct 1997 20:35:56 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from dcarmich.pr.mcs.net (dcarmich.pr.mcs.net [204.95.63.202])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA17642
for <freebsd-hackers@freebsd.org>; Thu, 23 Oct 1997 20:35:48 -0700 (PDT)
(envelope-from dcarmich@dcarmich.pr.mcs.net)
Received: (from dcarmich@localhost)
by dcarmich.pr.mcs.net (8.8.5/8.8.5) id WAA00691;
Thu, 23 Oct 1997 22:39:29 -0500 (CDT)
Message-ID: <19971023223929.43563@dcarmich.pr.mcs.net>
Date: Thu, 23 Oct 1997 22:39:29 -0500
From: Douglas Carmichael <dcarmich@mcs.com>
To: freebsd-hackers@freebsd.org
Subject: Text-based sysinstall and serial console for installation?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.74e
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
A text-based sysinstall utility would be good for:
1) Blind users using a speech synthesizer and/or Braille terminal
2) Sighted users with systems w/low memory
3) Physically challenged users using alternate terminals/input devices that
can only display text with no cursor addressability.
Also, maybe incorporate the use of a serial port console to the boot.flp?
(One reason to do that is that so a blind user can hook up a serial cable from
the system they want to install FreeBSD on to their existing system that
is running a screen reader and/or Braille terminal driver).
From owner-freebsd-hackers Thu Oct 23 21:37:14 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id VAA21139
for hackers-outgoing; Thu, 23 Oct 1997 21:37:14 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from netroplex.com (ns1.netroplex.com [206.171.95.130])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA21134
for <hackers@freebsd.org>; Thu, 23 Oct 1997 21:37:09 -0700 (PDT)
(envelope-from info@pagecreators.com)
Received: from awd (hahaha@max008-49.netroplex.com [207.212.27.49]) by netroplex.com (8.8.5/8.8.2) with ESMTP id VAA05686; Thu, 23 Oct 1997 21:38:32 -0700 (PDT)
Message-ID: <345024A9.78F0254D@pagecreators.com>
Date: Thu, 23 Oct 1997 21:31:38 -0700
From: Rod Ebrahimi <info@pagecreators.com>
X-Mailer: Mozilla 4.01 [en] (Win95; I)
MIME-Version: 1.0
To: Fred Gilham <gilham@csl.sri.com>, hackers@freebsd.org
Subject: Re: Upgrade
X-Priority: 3 (Normal)
References: <199710231755.KAA16764@japonica.csl.sri.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Thank you... Also is there any fix files that can fix some of the
problems fixed from 2.2.2 to 2.2.5 stability without doing a full
upgrade?
Thank you,
Rod
Fred Gilham wrote:
> You wrote:
> ----------------------------------------
> I have read the install notes and still am unclear on the best
> method of upgrading from 2.2.2 to 2.2.5 with little change of our
> source
> configuration. Any help would be greatly appreciated.
> ----------------------------------------
>
> What I do is to get just the source, install it, and do a `make world'
>
> in /usr/src. I can do this on a system that's in service. It takes
> about 4 hours on a P-166. Once this finishes, I re-make the kernel
> with our kernel configuration file (I've set it up so I use the same
> one on all our machines) and reboot and I'm up with an upgraded
> system. I just did this yesterday on one of our systems.
>
> Once this is known to work, you can remote-mount the /usr/src and
> /usr/obj file systems on different machines and do `make reinstall' on
>
> those machines. That way you only have to compile once.
>
> I've been upgrading this way for a long time and it seems the most
> transparent to me. The only problem I have is when they add new files
>
> to /etc (such as login.conf) or change the group file or something. I
>
> have to fix this stuff by hand.
>
> -Fred
From owner-freebsd-hackers Thu Oct 23 22:02:31 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id WAA22690
for hackers-outgoing; Thu, 23 Oct 1997 22:02:31 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from time.cdrom.com (time.cdrom.com [204.216.27.226])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA22682
for <freebsd-hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 22:02:28 -0700 (PDT)
(envelope-from jkh@time.cdrom.com)
Received: from time.cdrom.com (localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id WAA07930; Thu, 23 Oct 1997 22:03:03 -0700 (PDT)
To: Douglas Carmichael <dcarmich@mcs.com>
cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: Text-based sysinstall and serial console for installation?
In-reply-to: Your message of "Thu, 23 Oct 1997 22:39:29 CDT."
<19971023223929.43563@dcarmich.pr.mcs.net>
Date: Thu, 23 Oct 1997 22:03:03 -0700
Message-ID: <7927.877669383@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> A text-based sysinstall utility would be good for:
> 1) Blind users using a speech synthesizer and/or Braille terminal
> 2) Sighted users with systems w/low memory
> 3) Physically challenged users using alternate terminals/input devices that
> can only display text with no cursor addressability.
Well, if you supply me with a boot.flp image which implements all of
this, I'll be happy to put it in the floppies/ directory of the next
release. I've always encouraged the idea of alternative installers.
Jordan
From owner-freebsd-hackers Thu Oct 23 23:09:39 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id XAA26224
for hackers-outgoing; Thu, 23 Oct 1997 23:09:39 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from safeconcept.utimaco.co.at (mail-gw.utimaco.co.at [195.96.28.162])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA26212
for <hackers@FreeBSD.ORG>; Thu, 23 Oct 1997 23:09:33 -0700 (PDT)
(envelope-from Michael.Schuster@utimaco.co.at)
Received: (from uucp@localhost)
by safeconcept.utimaco.co.at (8.8.5/8.8.5) id HAA22777
for <hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 07:57:59 +0200 (CEST)
Received: from wshpux.utimaco.co.at(10.0.0.18) by safeconcept via smap (V2.0)
id xma022772; Fri, 24 Oct 97 07:57:34 +0200
Message-ID: <34503B08.16D941F7@utimaco.co.at>
Date: Fri, 24 Oct 1997 08:07:04 +0200
From: Michael Schuster <Michael.Schuster@utimaco.co.at>
Organization: Utimaco Safe Concept GmbH., Linz, Austria
X-Mailer: Mozilla 4.03 [de] (X11; I; HP-UX B.10.01 9000/715)
MIME-Version: 1.0
To: "hackers@FreeBSD.ORG" <hackers@FreeBSD.ORG>
Subject: .zip vs. .tar.gz [was: zipfs filesystem anyone ? ]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Mike Smith <mike@smith.net.au> wrote:
>You are correct; gzipped tarfiles are organised the wrong way around
>(metadata inside the compressed envelope), while zipfiles keep the
>metadata outside.
If you like, you can first compress all your files and then tar them,
doing something like (not tested, just FTTOMH (from the top of my
head:-))
find . -type f <other criteria> | xargs gzip
tar cf .
This is of course not as elegant as saying
tar ....; gzip tarfile
The whole difference obviously comes from different approaches: Zip does
compression and archiving in one, whereas tar and gzip build on the
typical UNIX way of doing things: one tool for one purpose. That way,
your tools will be good, and you can upgrade one without having to touch
the other.
cheers
Michael
--
Michael Schuster
Utimaco Safe Concept GmbH. | Tel: +43 732 655755 41
Europaplatz 6 | Fax: +43 732 655755 5
A-4020 Linz Austria | email: Michael.Schuster@utimaco.co.at
From owner-freebsd-hackers Fri Oct 24 00:00:59 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id AAA28407
for hackers-outgoing; Fri, 24 Oct 1997 00:00:59 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (word.smith.net.au [202.0.75.3])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA28348
for <hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 00:00:07 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id QAA01921;
Fri, 24 Oct 1997 16:26:40 +0930 (CST)
Message-Id: <199710240656.QAA01921@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Michael Schuster <Michael.Schuster@utimaco.co.at>
cc: "hackers@FreeBSD.ORG" <hackers@FreeBSD.ORG>
Subject: Re: .zip vs. .tar.gz [was: zipfs filesystem anyone ? ]
In-reply-to: Your message of "Fri, 24 Oct 1997 08:07:04 +0200."
<34503B08.16D941F7@utimaco.co.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 24 Oct 1997 16:26:35 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> Mike Smith <mike@smith.net.au> wrote:
>
> >You are correct; gzipped tarfiles are organised the wrong way around
> >(metadata inside the compressed envelope), while zipfiles keep the
> >metadata outside.
>
> If you like, you can first compress all your files and then tar them,
> doing something like (not tested, just FTTOMH (from the top of my
> head:-))
>
> find . -type f <other criteria> | xargs gzip
> tar cf .
This leaves me with a tree full of compressed files, and when I unpack
the tarball I have to uncompress them. And if the tarball contains
files that are meant to be compressed, they'll get uncompressed, which
I don't want either.
> The whole difference obviously comes from different approaches: Zip does
> compression and archiving in one, whereas tar and gzip build on the
> typical UNIX way of doing things: one tool for one purpose. That way,
> your tools will be good, and you can upgrade one without having to touch
> the other.
If tar was smart, it would use the external compression tool to
compress the data for each file as it read it, rather than compressing
the output stream. You would still lose, as the tar format does not
have a central directory.
mike
From owner-freebsd-hackers Fri Oct 24 00:40:29 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id AAA00342
for hackers-outgoing; Fri, 24 Oct 1997 00:40:29 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from shell.futuresouth.com (shell.futuresouth.com [207.141.254.20])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA00336
for <hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 00:40:27 -0700 (PDT)
(envelope-from fullermd@futuresouth.com)
Received: from shell.futuresouth.com (mail.futuresouth.com [207.141.254.21])
by shell.futuresouth.com (8.8.5/8.8.5) with SMTP id CAA25607;
Fri, 24 Oct 1997 02:40:00 -0500 (CDT)
Date: Fri, 24 Oct 1997 02:40:00 -0500 (CDT)
From: "Matthew D. Fuller" <fullermd@futuresouth.com>
To: Mike Smith <mike@smith.net.au>
cc: Michael Schuster <Michael.Schuster@utimaco.co.at>,
"hackers@FreeBSD.ORG" <hackers@FreeBSD.ORG>
Subject: Re: .zip vs. .tar.gz [was: zipfs filesystem anyone ? ]
In-Reply-To: <199710240656.QAA01921@word.smith.net.au>
Message-ID: <Pine.BSF.3.96.971024023702.19781C-100000@shell.futuresouth.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Fri, 24 Oct 1997, Mike Smith wrote:
> If tar was smart, it would use the external compression tool to
> compress the data for each file as it read it, rather than compressing
> the output stream. You would still lose, as the tar format does not
> have a central directory.
I have to disagree with this. it's much more efficient space-wise to
compress a tarball than it is to tar a bunch of compressed files. and tar
isn't meant to be a random-access archive method; tar and gzip are meant
to save space and preserve directrory/file layout. And they're perfectly
suited for this task. They don't do what you're discussing too well, no,
but they aren't MEANT to. tar is smart for what tis' doing.
>
> mike
>
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| FreeBSD; the way computers were meant to be |
* "The only reason I'm burning my candle at both ends, is *
| that I haven't figured out how to light the middle yet."|
* fullermd@futuresouth.com :-} MAtthew Fuller *
| http://keystone.westminster.edu/~fullermd |
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
From owner-freebsd-hackers Fri Oct 24 01:09:08 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id BAA01753
for hackers-outgoing; Fri, 24 Oct 1997 01:09:08 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from mail.san.rr.com (san.rr.com [204.210.0.1])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA01747
for <hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 01:09:06 -0700 (PDT)
(envelope-from studded@san.rr.com)
Received: (from studded@localhost)
by mail.san.rr.com (8.8.7/8.8.7) id BAA01837;
Fri, 24 Oct 1997 01:07:47 -0700 (PDT)
Message-Id: <199710240807.BAA01837@mail.san.rr.com>
From: "Studded" <Studded@dal.net>
To: "Mike Smith" <mike@smith.net.au>
Cc: "hackers@FreeBSD.ORG" <hackers@FreeBSD.ORG>
Date: Fri, 24 Oct 97 01:07:38 -0700
Reply-To: "Studded" <Studded@dal.net>
Priority: Normal
X-Mailer: PMMail 1.95a For OS/2
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Re: .zip vs. .tar.gz [was: zipfs filesystem anyone ? ]
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Fri, 24 Oct 1997 16:26:35 +0930, Mike Smith wrote:
>If tar was smart, it would use the external compression tool to
>compress the data for each file as it read it, rather than compressing
>the output stream. You would still lose, as the tar format does not
>have a central directory.
I've never understood why InfoZip didn't catch on more in the
Unix world. It is a very useful tool, which does almost everything on
the list of requests that you and others are asking for. :) If you
want more info, http://www.cdrom.com/pub/infozip/
Doug
*** Proud operator, designer and maintainer of the world's largest
*** Internet Relay Chat server. 4,168 clients and still growing. :-)
*** Try spider.dal.net on ports 6662-4 (Powered by FreeBSD)
*** Part of the DALnet IRC network ***
From owner-freebsd-hackers Fri Oct 24 01:26:04 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id BAA02472
for hackers-outgoing; Fri, 24 Oct 1997 01:26:04 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA02456
for <hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 01:26:00 -0700 (PDT)
(envelope-from gurney_j@efn.org)
Received: (from jmg@localhost)
by hydrogen.nike.efn.org (8.8.7/8.8.7) id BAA21279;
Fri, 24 Oct 1997 01:25:53 -0700 (PDT)
Message-ID: <19971024012553.49295@hydrogen.nike.efn.org>
Date: Fri, 24 Oct 1997 01:25:53 -0700
From: John-Mark Gurney <gurney_j@efn.org>
To: Studded <Studded@dal.net>
Cc: "hackers@FreeBSD.ORG" <hackers@FreeBSD.ORG>
Subject: Re: .zip vs. .tar.gz [was: zipfs filesystem anyone ? ]
References: <199710240807.BAA01837@mail.san.rr.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <199710240807.BAA01837@mail.san.rr.com>; from Studded on Fri, Oct 24, 1997 at 01:07:38AM -0700
Reply-To: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
Organization: Cu Networking
X-Operating-System: FreeBSD 2.2.1-RELEASE i386
X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4
X-Files: The truth is out there
X-URL: http://resnet.uoregon.edu/~gurney_j/
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Studded scribbled this message on Oct 24:
> On Fri, 24 Oct 1997 16:26:35 +0930, Mike Smith wrote:
>
> >If tar was smart, it would use the external compression tool to
> >compress the data for each file as it read it, rather than compressing
> >the output stream. You would still lose, as the tar format does not
> >have a central directory.
>
> I've never understood why InfoZip didn't catch on more in the
> Unix world. It is a very useful tool, which does almost everything on
> the list of requests that you and others are asking for. :) If you
> want more info, http://www.cdrom.com/pub/infozip/
well.. personally it's because you can't compress/decompress with the
same program and the output is noisy... nothing nicer than doing:
tar -czf file.tar.gz file
and know that it's exactly what you wanted... no output, nothing... :)
plus you get much better compression rates as you merge the whole group
of files into one big one... meaning your dictionary will be larger
we you compress most of the files...
and really... how slow is it to extract a few hundredk now days?
if you want infozip.. just install the package/port...
--
John-Mark Gurney Modem/FAX: +1 541 683 6954
Cu Networking
Live in Peace, destroy Micro$oft, support free software, run FreeBSD
From owner-freebsd-hackers Fri Oct 24 05:34:31 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id FAA14931
for hackers-outgoing; Fri, 24 Oct 1997 05:34:31 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from pluto.senet.com.au (root@pluto.senet.com.au [203.11.90.2])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA14911
for <freebsd-hackers@freebsd.org>; Fri, 24 Oct 1997 05:34:25 -0700 (PDT)
(envelope-from darius@holly.rd.net)
Received: from holly.rd.net (c4-p24.senet.com.au [203.56.237.217])
by pluto.senet.com.au (8.8.7/8.8.7) with ESMTP id WAA07372
for <freebsd-hackers@freebsd.org>; Fri, 24 Oct 1997 22:04:19 +0930
Received: from holly.rd.net (localhost.rd.net [127.0.0.1])
by holly.rd.net (8.8.5/8.8.5) with ESMTP id WAA04548
for <freebsd-hackers@freebsd.org>; Fri, 24 Oct 1997 22:06:36 +0930 (CST)
Message-Id: <199710241236.WAA04548@holly.rd.net>
X-Mailer: exmh version 2.0zeta 7/24/97
To: freebsd-hackers@freebsd.org
Subject: Re: zipfs filesystem anyone ?
In-reply-to: Your message of "Thu, 23 Oct 1997 16:11:28 CST."
<199710232211.QAA17154@rocky.mt.sri.com>
Reply-to: doconnor@ist.flinders.edu.au
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 24 Oct 1997 22:06:35 +0930
From: "Daniel J. O'Connor" <darius@senet.com.au>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> > > > The VFS interface is not reflexive.
> > No, it's a term from computer science, not medicine.
> Never heard it in any of my classes.
Well actually, its from mathematics...
Do Logic and Graphs, and it will all be explained :)
Although I don't really see how the term applies here..
Maybe he means reentrant.. Or something like it
---------------
Daniel O'Connor
3rd Year Computer Science at Flinders University
http://www.geocities.com.au/CapeCanaveral/7200
From owner-freebsd-hackers Fri Oct 24 09:23:02 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id JAA01304
for hackers-outgoing; Fri, 24 Oct 1997 09:23:02 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from kcmain-int.SKW-Inc.Com ([208.132.78.205])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA01294
for <hackers@freebsd.org>; Fri, 24 Oct 1997 09:22:53 -0700 (PDT)
(envelope-from root@kcmain-int.SKW-Inc.Com)
Received: (from root@localhost)
by kcmain-int.SKW-Inc.Com (8.8.7/8.8.7) id LAA00247
for hackers@freebsd.org; Sat, 25 Oct 1997 11:22:24 -0500 (CDT)
Date: Sat, 25 Oct 1997 11:22:24 -0500 (CDT)
From: Charlie Root <root@kcmain-int.SKW-Inc.Com>
Message-Id: <199710251622.LAA00247@kcmain-int.SKW-Inc.Com>
To: hackers@freebsd.org
Subject: XFree86
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Greetings,
I have a new PC with a Trident 9680 chipset in it. When I try to start
Xwindows, it switches graphics mode, goes to all black and stops. If I do a
CTRL-ALT-BS, it comes back to my prompt. I thought this had something to do
with the Linear Frame Buffer being mis-aligned. I tried using the config
parameter to disable the frame buffer and it did not help.
When I start X I get:
SVGA: PCI: Trident TGUI 9660/9680/9682 rev 211, Memory @ 0xe0000000, 0xe0400000
Trident chipset version: 0xd3 (TGUI96xx)
SVGA: Detected a Trident 9680
SVGA: Revision 1
SVGA: Using Trident programmable clocks
SVGA: chipset: tgui96xx
SVGA: videoram: 1024k
SVGA: Using 8bpp, Depth 8, Color weight: 666
SVGA: Maximum allowed dot-clock: 135.000 MHz
From owner-freebsd-hackers Fri Oct 24 10:15:31 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA04749
for hackers-outgoing; Fri, 24 Oct 1997 10:15:31 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA04738
for <hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 10:15:15 -0700 (PDT)
(envelope-from tlambert@usr08.primenet.com)
Received: (from daemon@localhost)
by smtp04.primenet.com (8.8.7/8.8.7) id KAA21497;
Fri, 24 Oct 1997 10:15:10 -0700 (MST)
Received: from usr08.primenet.com(206.165.6.208)
via SMTP by smtp04.primenet.com, id smtpd021483; Fri Oct 24 10:15:06 1997
Received: (from tlambert@localhost)
by usr08.primenet.com (8.8.5/8.8.5) id KAA13208;
Fri, 24 Oct 1997 10:15:02 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710241715.KAA13208@usr08.primenet.com>
Subject: Re: zipfs filesystem anyone ?
To: michaelh@cet.co.jp (Michael Hancock)
Date: Fri, 24 Oct 1997 17:15:02 +0000 (GMT)
Cc: tlambert@primenet.com, luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG
In-Reply-To: <Pine.SV4.3.95.971024111008.17710C-100000@parkplace.cet.co.jp> from "Michael Hancock" at Oct 24, 97 11:25:59 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > You could do one, but you will have to externalize a hell of a lot
> > of code, and provide proxy allocation and freeing mechanisms for
> > every place that is non-reflexive.
>
> Wouldn't you have to externalize a lot of stuff anyway? We'd need some
> extra syscalls along the lines of John Heidemann's ook* (Out Of Kernel)
> stuff. You can make a fs specific call that serves as a general interface
> to marshall fs related operations in and out of the kernel.
No. The "ook" stuff is kind of a kludge having to do with the fact
that the VM interface consumed by local file systems is not encapsulated
by a VFS layer: in other words, for local file systems, the top and
bottom of the FS are different. This is actualy broken implementation
more than anything else, IMO.
Really, you need a clone top/bottom device, best case, or a paired
top/bottom device (ala pty's, which should be clone themselves) at
worst.
The only real pain is extending the number of VOP's, should you need to...
and that's going to bite you no matter how you approach it because the
BSD VFS init code is broken (it counts the number of VOP's in the
statically linked UFS instead of using the struct vnops descriptor count,
with placeholders for some "reasonable number" of new VOPs).
> Then you can make a semantic-free user layer.
Well, you know my opinion: they should all be semantic free, and all
implied state should be registered in a graph with all but the final
Warshall pass complete, and the graph should be used to implement
soft update semantics for all FS layers, everywhere. 8-).
> It seems that a lot of NFS related work these days have to do with
> adding state.
Yes. This has me alarmed. It seems to me that NFS is becoming one
kludge on top of another, with things getting tweaked until they appear
to work, with no one really looking at the big picture. That's the
same objection I have to stuffing VM glue into supposedly null function
bodies in nullfs, unionfs, etc. 8-(.
> I was looking at this a few months ago after John H. released his layering
> code.
??? John H's code has been available since before the 4.4-Lite release;
I was playing with it under 4.3 (FreeBSD 1.05)...
> It also seems that Poul and John Dyson have started cleaning up some fs
> related interface and memory issues, but I haven't had time to examine all
> the details.
I think John has been addressing real issues, and to be fair, I haven't
unpacked my machines yet, so I haven't been able to look at Poul's
stuff (the reduction of VOP calls seems sound in principle, but I can't
comment for real until I actually look at it). I think the excitement
over nullfs "working" has overshadowed a number of important design
considerations; but you know that from my posts, so I don't need to
repeat them.
I don't know how much of the recent twiddling has been "make it work at
any cost" as oppossed to real cleanup. I really think the VFS needs to
be "dekludgeified" before more new stuff is added. If you make something
parallel to something crooked, you end up with two crooked things. There
needs to be someone in there with a "T-square" before an entire crooked
house is built.
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 Oct 24 10:38:26 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA06364
for hackers-outgoing; Fri, 24 Oct 1997 10:38:26 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from super-g.inch.com (super-g.com [207.240.140.161])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA06357
for <freebsd-hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 10:38:23 -0700 (PDT)
(envelope-from spork@super-g.com)
Received: from localhost (spork@localhost)
by super-g.inch.com (8.8.7/8.8.5) with SMTP id NAA23663
for <freebsd-hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 13:35:57 -0400 (EDT)
Date: Fri, 24 Oct 1997 13:35:56 -0400 (EDT)
From: spork <spork@super-g.com>
X-Sender: spork@super-g.inch.com
To: freebsd-hackers@FreeBSD.ORG
Subject: Re: Possible SERIOUS bug in open()? (Big time bug)
In-Reply-To: <19971024002450.UZ51487@uriah.heep.sax.de>
Message-ID: <Pine.BSF.3.96.971024133340.21468E-100000@super-g.inch.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
J"org,
Is there any chance of you back-porting this fix to RELENG_2_1_0?
I can't really figure out how to do it, and a diff from then to now is
radically different to the point that it doesn't even look like it would
compile.
Please?
Charles
On Fri, 24 Oct 1997, J Wunsch wrote:
> As Jamil J. Weatherbee wrote:
>
> > No, the user open() should return error for somebody trying to open for
> > not read and not write.
>
> It does (now). Why the h*ck are you both still arguing about it? For
> me (being in MET DST timezone), it's already a matter of yesterday...
>
> --
> 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 Oct 24 10:42:36 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA06598
for hackers-outgoing; Fri, 24 Oct 1997 10:42:36 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA06593
for <freebsd-hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 10:42:34 -0700 (PDT)
(envelope-from tlambert@usr08.primenet.com)
Received: (from daemon@localhost)
by smtp03.primenet.com (8.8.7/8.8.7) id KAA17693;
Fri, 24 Oct 1997 10:42:00 -0700 (MST)
Received: from usr08.primenet.com(206.165.6.208)
via SMTP by smtp03.primenet.com, id smtpd017661; Fri Oct 24 10:41:50 1997
Received: (from tlambert@localhost)
by usr08.primenet.com (8.8.5/8.8.5) id KAA14255;
Fri, 24 Oct 1997 10:41:40 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710241741.KAA14255@usr08.primenet.com>
Subject: Re: Possible SERIOUS bug in open()? (Big time bug)
To: jamil@trojanhorse.ml.org (Jamil J. Weatherbee)
Date: Fri, 24 Oct 1997 17:41:40 +0000 (GMT)
Cc: tlambert@primenet.com, thorpej@nas.nasa.gov,
joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <Pine.BSF.3.96.971023150036.3526A-100000@trojanhorse.ml.org> from "Jamil J. Weatherbee" at Oct 23, 97 03:06:23 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> No, the user open() should return error for somebody trying to open for
> not read and not write. /dev/io gives the process IOPL on the basis that
> it is able to open /dev/io, not do operations on it.
This is an implied interface.
> I think it is perfectly reasonable for the driver to expect its open
> method called only if the user has permissions on the file.
Permission dictate whether the user may read the file or write the file;
the open method specific to the file dictates wheher the user can open
the file. There aren't permission bits associated with "openable", only
"readable" and "writeable".
For /dev/io, where opening has side effects that it wouldn't if people
were required to use ioctl()'s instead of inb/outb, or where the port
range was always trapped and proxied after trap instead of untrapped,
this wouldn't be a side effect.
Generally, /dev/io exists because there isn't a DDX in the console code
like there should be, and a couple of other similar uses.
> When you start putting the responsibility on the driver for maintaining
> the security of the system and not the kernel then your'e just asking
> for trouble.
A device must dictate the policy for its use in all implementations.
The original thread where the OR'ed flags resulted in an (unexpected to
the user) flags value of '3' was an issue of a device specific policy
prohibiting simultaneous readability and writeability for the device.
How would the kernel enforce security policy for a simplex audio device
which could not be used bidirectionally? Device flags indicating its
simplex nature? This seems to me to be an enforcement issue for the
audio driver, not for the kernel. /dev/io is unique in that it depends,
rightly or wrongly, on side effects instead of explicit action. I think
/dev/io is poorly designed compared to the Linux I/O port mapping
mechanism in this regard (for example).
> Much like most drivers do not check to see if the device
> being passed is valid once it is opened because it should always be
> valid (under most circumstances).
There's no accounting for programmers who don't know how to code for
hot pluggability...
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 Oct 24 10:47:02 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA06888
for hackers-outgoing; Fri, 24 Oct 1997 10:47:02 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA06877
for <hackers@freebsd.org>; Fri, 24 Oct 1997 10:46:56 -0700 (PDT)
(envelope-from tlambert@usr08.primenet.com)
Received: (from daemon@localhost)
by smtp03.primenet.com (8.8.7/8.8.7) id KAA18352;
Fri, 24 Oct 1997 10:46:49 -0700 (MST)
Received: from usr08.primenet.com(206.165.6.208)
via SMTP by smtp03.primenet.com, id smtpd018345; Fri Oct 24 10:46:46 1997
Received: (from tlambert@localhost)
by usr08.primenet.com (8.8.5/8.8.5) id KAA14398;
Fri, 24 Oct 1997 10:46:42 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710241746.KAA14398@usr08.primenet.com>
Subject: Re: zipfs filesystem anyone ?
To: nate@mt.sri.com (Nate Williams)
Date: Fri, 24 Oct 1997 17:46:42 +0000 (GMT)
Cc: tlambert@primenet.com, nate@mt.sri.com, luigi@labinfo.iet.unipi.it,
hackers@freebsd.org
In-Reply-To: <199710232211.QAA17154@rocky.mt.sri.com> from "Nate Williams" at Oct 23, 97 04:11:28 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> > It means that there are side effects to the interface, and that the
> > caller is dependent on the side effects.
>
> Kind of like strdup(3)? *grin*
More like a program using:
pwe = getpwnam( "bob");
/*deal with bob...*/
... pwe ...
... pwe ...
(void)getpwnam( "tom");
/*deal with tom...*/
... pwe ...
... pwe ...
With the idea that it knows that getpwnam returns a pointer to a static
data area, so it's OK to only set the pointer to that area once.
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 Oct 24 10:48:32 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA07001
for hackers-outgoing; Fri, 24 Oct 1997 10:48:32 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA06985
for <freebsd-hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 10:48:23 -0700 (PDT)
(envelope-from tlambert@usr08.primenet.com)
Received: (from daemon@localhost)
by smtp04.primenet.com (8.8.7/8.8.7) id KAA23876
for <freebsd-hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 10:48:15 -0700 (MST)
Received: from usr08.primenet.com(206.165.6.208)
via SMTP by smtp04.primenet.com, id smtpd023853; Fri Oct 24 10:48:11 1997
Received: (from tlambert@localhost)
by usr08.primenet.com (8.8.5/8.8.5) id KAA14447
for freebsd-hackers@FreeBSD.ORG; Fri, 24 Oct 1997 10:48:11 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710241748.KAA14447@usr08.primenet.com>
Subject: Re: Possible SERIOUS bug in open()? (Big time bug)
To: freebsd-hackers@FreeBSD.ORG
Date: Fri, 24 Oct 1997 17:48:10 +0000 (GMT)
In-Reply-To: <19971024002450.UZ51487@uriah.heep.sax.de> from "J Wunsch" at Oct 24, 97 00:24:50 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > No, the user open() should return error for somebody trying to open for
> > not read and not write.
>
> It does (now). Why the h*ck are you both still arguing about it? For
> me (being in MET DST timezone), it's already a matter of yesterday...
Because I think the "fix" should be backed out because the side effect
is useful, and he thinks it shouldn't because he doesn't want to have
to code device drivers with security policy in mind.
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 Oct 24 10:54:57 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA07457
for hackers-outgoing; Fri, 24 Oct 1997 10:54:57 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA07450
for <freebsd-hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 10:54:52 -0700 (PDT)
(envelope-from tlambert@usr08.primenet.com)
Received: (from daemon@localhost)
by smtp03.primenet.com (8.8.7/8.8.7) id KAA19414;
Fri, 24 Oct 1997 10:54:51 -0700 (MST)
Received: from usr08.primenet.com(206.165.6.208)
via SMTP by smtp03.primenet.com, id smtpd019385; Fri Oct 24 10:54:41 1997
Received: (from tlambert@localhost)
by usr08.primenet.com (8.8.5/8.8.5) id KAA14740;
Fri, 24 Oct 1997 10:54:39 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710241754.KAA14740@usr08.primenet.com>
Subject: Re: zipfs filesystem anyone ?
To: doconnor@ist.flinders.edu.au
Date: Fri, 24 Oct 1997 17:54:39 +0000 (GMT)
Cc: freebsd-hackers@FreeBSD.ORG
In-Reply-To: <199710241236.WAA04548@holly.rd.net> from "Daniel J. O'Connor" at Oct 24, 97 10:06:35 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > > > > The VFS interface is not reflexive.
> > > No, it's a term from computer science, not medicine.
> > Never heard it in any of my classes.
>
> Well actually, its from mathematics...
> Do Logic and Graphs, and it will all be explained :)
> Although I don't really see how the term applies here..
> Maybe he means reentrant.. Or something like it
"Principles of Object Oriented Design"
Sorry, I ,don't have an ISBN handy.
In absolutely dumbest terms, it means:
1) If *I* allocate it, it's *my* responsibility to free it
2) If I have to call a function to do something, I have to
call a function to undo it
3) If I have to access data, I'll call a function to do it.
4) Everything is data opaque (no "promiscuous" knowledge)
5) All operations are reversible
6) Etc.
...all sorts of good things.
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 Oct 24 10:58:00 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA07667
for hackers-outgoing; Fri, 24 Oct 1997 10:58:00 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA07651
for <hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 10:57:52 -0700 (PDT)
(envelope-from gurney_j@efn.org)
Received: (from jmg@localhost)
by hydrogen.nike.efn.org (8.8.7/8.8.7) id KAA26349;
Fri, 24 Oct 1997 10:57:35 -0700 (PDT)
Message-ID: <19971024105734.33600@hydrogen.nike.efn.org>
Date: Fri, 24 Oct 1997 10:57:34 -0700
From: John-Mark Gurney <gurney_j@efn.org>
To: Terry Lambert <tlambert@primenet.com>
Cc: Michael Hancock <michaelh@cet.co.jp>, luigi@labinfo.iet.unipi.it,
hackers@FreeBSD.ORG
Subject: Re: zipfs filesystem anyone ?
References: <Pine.SV4.3.95.971024111008.17710C-100000@parkplace.cet.co.jp> <199710241715.KAA13208@usr08.primenet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <199710241715.KAA13208@usr08.primenet.com>; from Terry Lambert on Fri, Oct 24, 1997 at 05:15:02PM +0000
Reply-To: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
Organization: Cu Networking
X-Operating-System: FreeBSD 2.2.1-RELEASE i386
X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4
X-Files: The truth is out there
X-URL: http://resnet.uoregon.edu/~gurney_j/
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Terry Lambert scribbled this message on Oct 24:
> The only real pain is extending the number of VOP's, should you need to...
> and that's going to bite you no matter how you approach it because the
> BSD VFS init code is broken (it counts the number of VOP's in the
> statically linked UFS instead of using the struct vnops descriptor count,
> with placeholders for some "reasonable number" of new VOPs).
are you really sure about this? by my reading of the code in vfs_init.c
(and I've sent enough time looking at the code reciently), the size of the
opv table is vfs_opv_numops = sizeof(vfs_op_desc)/
sizeof(struct vnodeop_desc*) -1... shouldn't this be enough? or am I
completely missreading the code?
wouldn't simply increasing the allocated vfs_opv_numops a constant value,
then keeping track of this information be enough?
or are you looking at something more?
[...]
> I don't know how much of the recent twiddling has been "make it work at
> any cost" as oppossed to real cleanup. I really think the VFS needs to
> be "dekludgeified" before more new stuff is added. If you make something
> parallel to something crooked, you end up with two crooked things. There
> needs to be someone in there with a "T-square" before an entire crooked
> house is built.
yep... I know what you mean... and that is why I'm not writing any code
for my bus/device design until I'm satisfied with it longer than a week..
(actually, the rate I've been going, more like a month) :)
--
John-Mark Gurney Modem/FAX: +1 541 683 6954
Cu Networking
Live in Peace, destroy Micro$oft, support free software, run FreeBSD
From owner-freebsd-hackers Fri Oct 24 11:24:47 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA09433
for hackers-outgoing; Fri, 24 Oct 1997 11:24:47 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA09423
for <hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 11:24:40 -0700 (PDT)
(envelope-from tlambert@usr08.primenet.com)
Received: (from daemon@localhost)
by smtp04.primenet.com (8.8.7/8.8.7) id LAA25397;
Fri, 24 Oct 1997 11:24:16 -0700 (MST)
Received: from usr08.primenet.com(206.165.6.208)
via SMTP by smtp04.primenet.com, id smtpd025394; Fri Oct 24 11:24:10 1997
Received: (from tlambert@localhost)
by usr08.primenet.com (8.8.5/8.8.5) id LAA16384;
Fri, 24 Oct 1997 11:24:05 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710241824.LAA16384@usr08.primenet.com>
Subject: Re: zipfs filesystem anyone ?
To: gurney_j@resnet.uoregon.edu
Date: Fri, 24 Oct 1997 18:24:05 +0000 (GMT)
Cc: tlambert@primenet.com, michaelh@cet.co.jp, luigi@labinfo.iet.unipi.it,
hackers@FreeBSD.ORG
In-Reply-To: <19971024105734.33600@hydrogen.nike.efn.org> from "John-Mark Gurney" at Oct 24, 97 10:57:34 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > The only real pain is extending the number of VOP's, should you need to...
> > and that's going to bite you no matter how you approach it because the
> > BSD VFS init code is broken (it counts the number of VOP's in the
> > statically linked UFS instead of using the struct vnops descriptor count,
> > with placeholders for some "reasonable number" of new VOPs).
>
> are you really sure about this? by my reading of the code in vfs_init.c
> (and I've sent enough time looking at the code reciently), the size of the
> opv table is vfs_opv_numops = sizeof(vfs_op_desc)/
> sizeof(struct vnodeop_desc*) -1... shouldn't this be enough? or am I
> completely missreading the code?
I haven't seen this; my home machine has been packed in a box on a truck
and is still in the box, only now in my livingroom.
This is, in fact, one of my VFS patches!
Yea, team!
If it's in there, then this is an important first step. The next step
would be to add a special placeholder descriptor that can be replaced
in vfs_op_desc for several slots. This would make it so you didn't
have to rebuild all of vnode_if.c and vnode_if.h to add new descriptors:
you can overwrite the placeholders instead.
Actually, that particular change (not using FFS to size the table)
is the first change in a chain that lets you boot a machine without
a file system at all (my original purpose). 8-) 8-).
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 Oct 24 11:43:07 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA10677
for hackers-outgoing; Fri, 24 Oct 1997 11:43:07 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA10671
for <hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 11:43:03 -0700 (PDT)
(envelope-from gurney_j@efn.org)
Received: (from jmg@localhost)
by hydrogen.nike.efn.org (8.8.7/8.8.7) id LAA26509;
Fri, 24 Oct 1997 11:42:44 -0700 (PDT)
Message-ID: <19971024114243.36902@hydrogen.nike.efn.org>
Date: Fri, 24 Oct 1997 11:42:43 -0700
From: John-Mark Gurney <gurney_j@efn.org>
To: Terry Lambert <tlambert@primenet.com>
Cc: michaelh@cet.co.jp, luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG
Subject: Re: zipfs filesystem anyone ?
References: <19971024105734.33600@hydrogen.nike.efn.org> <199710241824.LAA16384@usr08.primenet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <199710241824.LAA16384@usr08.primenet.com>; from Terry Lambert on Fri, Oct 24, 1997 at 06:24:05PM +0000
Reply-To: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
Organization: Cu Networking
X-Operating-System: FreeBSD 2.2.1-RELEASE i386
X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4
X-Files: The truth is out there
X-URL: http://resnet.uoregon.edu/~gurney_j/
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Terry Lambert scribbled this message on Oct 24:
> > > The only real pain is extending the number of VOP's, should you need to...
> > > and that's going to bite you no matter how you approach it because the
> > > BSD VFS init code is broken (it counts the number of VOP's in the
> > > statically linked UFS instead of using the struct vnops descriptor count,
> > > with placeholders for some "reasonable number" of new VOPs).
> >
> > are you really sure about this? by my reading of the code in vfs_init.c
> > (and I've sent enough time looking at the code reciently), the size of the
> > opv table is vfs_opv_numops = sizeof(vfs_op_desc)/
> > sizeof(struct vnodeop_desc*) -1... shouldn't this be enough? or am I
> > completely missreading the code?
>
> I haven't seen this; my home machine has been packed in a box on a truck
> and is still in the box, only now in my livingroom.
>
> This is, in fact, one of my VFS patches!
>
> Yea, team!
actually.. the change wasn't very massive.. just 3 lines of code and some
comment updates...
as a quick question.. now that we use vfs_opv_numops, should we get ride
of the dummy NULL entry?
> If it's in there, then this is an important first step. The next step
> would be to add a special placeholder descriptor that can be replaced
> in vfs_op_desc for several slots. This would make it so you didn't
> have to rebuild all of vnode_if.c and vnode_if.h to add new descriptors:
> you can overwrite the placeholders instead.
or should we simply use the dummy NULL entry (and add some) for the place
holder?
personally, a possible define that declares I want a possible X extra
vop vectors... and then have a couple variables that tell you the
maximum number, and the current last offset... this shouldn't be hard
to do...
> Actually, that particular change (not using FFS to size the table)
> is the first change in a chain that lets you boot a machine without
> a file system at all (my original purpose). 8-) 8-).
kool.... are you on -current? I guess I should of announced my vfsinit
patches to hackers instead... basicly, to get ride of LKM's and prepare
for kld modules, I needed to change the vfs system to initalize on a
permodule basis instead of a initalize all staticly compiled module
idea...
http://freefall.freebsd.org/~jmg/vfs.patch
--
John-Mark Gurney Modem/FAX: +1 541 683 6954
Cu Networking
Live in Peace, destroy Micro$oft, support free software, run FreeBSD
From owner-freebsd-hackers Fri Oct 24 13:02:24 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id NAA15829
for hackers-outgoing; Fri, 24 Oct 1997 13:02:24 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from gatekeeper.ray.com (gatekeeper.ray.com [138.125.162.1])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA15562
for <hackers@FreeBSD.org>; Fri, 24 Oct 1997 13:00:00 -0700 (PDT)
(envelope-from Gregory_D_Moncreaff@res.raytheon.com)
Received: (mailer@localhost) by gatekeeper.ray.com (8.8.7/8.8.7) id PAA25554 for <hackers@FreeBSD.org>; Fri, 24 Oct 1997 15:57:19 -0400
Received: from notes.res.ray.com/138.125.97.35(<Gregory_D_Moncreaff@res.raytheon.com>)
by gatekeeper.ray.com
id sma029710; Fri Oct 24 15:55:30 1997
X-SMAP-TO: <hackers@FreeBSD.org>
Received: by notes.res.ray.com(Lotus SMTP MTA v1.1 (385.6 5-6-1997)) id 8525653A.006D6E52 ; Fri, 24 Oct 1997 15:55:16 -0400
X-Lotus-FromDomain: RES
From: "Gregory D Moncreaff"<Gregory_D_Moncreaff@res.raytheon.com>
To: hackers@FreeBSD.org
Message-ID: <8525653A.006CE9C5.00@notes.res.ray.com>
Date: Fri, 24 Oct 1997 14:59:15 -0400
Subject: man recvmsg and soreceive
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk
With respect to connection oriented protocols PR_CONNREQUIRED (are there
any in 2.2.5?)
kern/uipc_socket.c:soreceive() will perform PDU_RCVD (which can have effect
of
implicitly confirming connection) when called ONLY to get control data
unless flags
has MSG_PEEK
Need to update man page to say that you must call recvmsg with MSG_PEEK to
avoid
implicitly confirming connection
=====================================================================
Gregory D. Moncreaff Phone 1-508-490-2048
Raytheon Electronic Systems Fax 1-508-490-2086
Gregory_D_Moncreaff@res.raytheon.com Home moncrg@ma.ultranet.com
---------------------------------------------------------------------
From owner-freebsd-hackers Fri Oct 24 13:12:07 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id NAA16413
for hackers-outgoing; Fri, 24 Oct 1997 13:12:07 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from cyber1.servtech.com (root@cyber1.servtech.com [199.1.22.8])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA16407
for <freebsd-hackers@freebsd.org>; Fri, 24 Oct 1997 13:12:02 -0700 (PDT)
(envelope-from housley@pr-comm.com)
Received: from pr-comm.com (root@prcomm.roc.servtech.com [204.181.3.14]) by cyber1.servtech.com (8.8.6/8.8.5) with ESMTP id QAA05516 for <freebsd-hackers@freebsd.org>; Fri, 24 Oct 1997 16:11:52 -0400 (EDT)
Received: from pr-comm.com (housley@localhost [127.0.0.1])
by pr-comm.com (8.8.7/8.8.7) with ESMTP id QAA00853
for <freebsd-hackers@freebsd.org>; Fri, 24 Oct 1997 16:09:26 -0400 (EDT)
(envelope-from housley@pr-comm.com)
Message-ID: <34510029.193E7316@pr-comm.com>
Date: Fri, 24 Oct 1997 16:08:09 -0400
From: "James E. Housley" <housley@pr-comm.com>
Organization: PR Communications, Inc.
X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386)
MIME-Version: 1.0
To: freebsd-hackers@freebsd.org
Subject: Anti-spam in hub.mc
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I think I am missing something important here. I was using an older anti-spam
rule set for sendmail. I started using the new set that is in hub.mc . My
question is that mail from a site that is blocked has a message/reply with
#blocked.contact postmaster@pr-comm.com (for me, was postmaster@FreeBSD.ORG).
My question is how will they actually contact the postmaster if mail from that
site is blocked?????
Am I missing something? I understand a very little of how the rules work, but
not much. I don't see anything that allows mail to postmaster mail through.
Jim.
--
-------------------------------------------+-------------------------
James E. Housley | PGP: 1024/03983B4D
PR Communications, Inc. | 2C 3F 3A 0D A8 D8 C3 13
www.servtech.com/public/pr-comm | 7C F0 B5 BF 27 8B 92 FE
From owner-freebsd-hackers Fri Oct 24 13:46:32 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id NAA19096
for hackers-outgoing; Fri, 24 Oct 1997 13:46:32 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA19091
for <freebsd-hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 13:46:30 -0700 (PDT)
(envelope-from gdonl@tsc.tdk.com)
Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191])
by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP
id NAA09415; Fri, 24 Oct 1997 13:45:35 -0700 (PDT)
Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194])
by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id NAA22945;
Fri, 24 Oct 1997 13:45:20 -0700 (PDT)
Received: (from gdonl@localhost)
by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id NAA18723;
Fri, 24 Oct 1997 13:45:08 -0700 (PDT)
From: Don Lewis <Don.Lewis@tsc.tdk.com>
Message-Id: <199710242045.NAA18723@salsa.gv.tsc.tdk.com>
Date: Fri, 24 Oct 1997 13:45:02 -0700
In-Reply-To: Terry Lambert <tlambert@primenet.com>
"Re: Possible SERIOUS bug in open()? (Big time bug)" (Oct 24, 5:41pm)
X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95)
To: Terry Lambert <tlambert@primenet.com>,
jamil@trojanhorse.ml.org (Jamil J. Weatherbee)
Subject: Re: Possible SERIOUS bug in open()? (Big time bug)
Cc: thorpej@nas.nasa.gov, joerg_wunsch@uriah.heep.sax.de,
freebsd-hackers@FreeBSD.ORG
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Oct 24, 5:41pm, Terry Lambert wrote:
} Subject: Re: Possible SERIOUS bug in open()? (Big time bug)
} Permission dictate whether the user may read the file or write the file;
} the open method specific to the file dictates wheher the user can open
} the file. There aren't permission bits associated with "openable", only
} "readable" and "writeable".
}
} For /dev/io, where opening has side effects
Opening files has side effects, too. For instance, space isn't
recovered if a file is unlinked if the file is open. There is
also the issue of O_EXLOCK and O_SHLOCK. I don't want another
user to have the ability to do either with my mode 0600 files.
From owner-freebsd-hackers Fri Oct 24 13:55:57 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id NAA19555
for hackers-outgoing; Fri, 24 Oct 1997 13:55:57 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from elvis.mu.org (elvis.mu.org [206.156.231.253])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA19532
for <freebsd-hackers@freebsd.org>; Fri, 24 Oct 1997 13:55:53 -0700 (PDT)
(envelope-from paul@elvis.mu.org)
Received: (from paul@localhost)
by elvis.mu.org (8.8.7/8.8.7) id PAA08603
for freebsd-hackers@freebsd.org; Fri, 24 Oct 1997 15:55:45 -0500 (CDT)
(envelope-from paul)
From: Paul Saab <paul@mu.org>
Message-Id: <199710242055.PAA08603@elvis.mu.org>
Subject: netstat: kvm_read: Bad address
To: freebsd-hackers@freebsd.org
Date: Fri, 24 Oct 1997 15:55:45 -0500 (CDT)
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I am trying to figure out why my machine has not been behaving
recently after running bug free for months. Wednesday I had a
kernel panic and Joerg has put me in the right direction to try
and find the bug. Now today I got this while doing a netstat on
another machine with exactly the same hardware configuration as
the one which had the kernel panic but it is running 2.2.5-RELEASE.
The machines are PPRO 200's with 2940UW's, 128MB of ram, and with
3c905 ethernet cards. My question is what does the following mean
and how should I fix it.
Active Internet connections
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp 0 0 themaneater.com.http 204.184.83.7.1976 ESTABLISHED
tcp 0 8398 themaneater.com.http 204.184.83.7.1975 ESTABLISHED
tcp 0 5650 themaneater.com.http 204.184.83.7.1974 ESTABLISHED
tcp 0 0 themaneater.com.http 208.196.245.66.2658 ESTABLISHED
tcp 0 0 themaneater.com.http 208.196.245.66.2657 ESTABLISHED
tcp 0 0 themaneater.com.ftp-da Mizzou-AS6-17.mi.1232 TIME_WAIT
tcp 361 -266160568 themaneater.com.http 16.211.65.241.2656 -264201400
tcp 0 -264546048 128.204.64.241.16625 144.105.65.241.39147 CLOSED
netstat: kvm_read: Bad address
???
udp 0 0 elvis.4724 elvis.domain
udp 0 0 localhost.domain *.*
udp 0 0 elvis.domain *.*
Thanks a bunch,
Paul
From owner-freebsd-hackers Fri Oct 24 14:14:44 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA20574
for hackers-outgoing; Fri, 24 Oct 1997 14:14:44 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from elvis.vnet.net (elvis.vnet.net [166.82.1.5])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA20567
for <hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 14:14:34 -0700 (PDT)
(envelope-from rivers@dignus.com)
Received: from ponds.dignus.com (ponds.vnet.net [166.82.177.48])
by elvis.vnet.net (8.8.5/8.8.4) with ESMTP
id RAA28779; Fri, 24 Oct 1997 17:14:23 -0400 (EDT)
Received: from lakes.dignus.com (lakes [10.0.0.3])
by ponds.dignus.com (8.8.5/8.8.5) with ESMTP id PAA29719;
Fri, 24 Oct 1997 15:39:31 -0400 (EDT)
Received: (from rivers@localhost) by lakes.dignus.com (8.8.5/8.6.9) id PAA13405; Fri, 24 Oct 1997 15:28:49 -0400 (EDT)
Date: Fri, 24 Oct 1997 15:28:49 -0400 (EDT)
From: Thomas David Rivers <rivers@dignus.com>
Message-Id: <199710241928.PAA13405@lakes.dignus.com>
To: hackers@FreeBSD.ORG, root@kcmain-int.SKW-Inc.Com
Subject: Re: XFree86
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> Greetings,
>
> I have a new PC with a Trident 9680 chipset in it. When I try to start
> Xwindows, it switches graphics mode, goes to all black and stops. If I do a
> CTRL-ALT-BS, it comes back to my prompt. I thought this had something to do
> with the Linear Frame Buffer being mis-aligned. I tried using the config
> parameter to disable the frame buffer and it did not help.
>
> When I start X I get:
>
> SVGA: PCI: Trident TGUI 9660/9680/9682 rev 211, Memory @ 0xe0000000, 0xe0400000
> Trident chipset version: 0xd3 (TGUI96xx)
> SVGA: Detected a Trident 9680
> SVGA: Revision 1
> SVGA: Using Trident programmable clocks
> SVGA: chipset: tgui96xx
> SVGA: videoram: 1024k
> SVGA: Using 8bpp, Depth 8, Color weight: 666
> SVGA: Maximum allowed dot-clock: 135.000 MHz
>
Just F.Y.I - I use a Trident 9680-based board in my machine (not the
best, by far, but certainly cheap...)
First - it's probably worthwhile to go ahead and splurge for another
1024k of RAM - the video won't be worthwhile without it...
Here's my XF86Config file.
- Dave Rivers -
# XF86Config auto-generated by XF86Setup
#
# Copyright (c) 1996 by The XFree86 Project, Inc.
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
# THE XFREE86 PROJECT BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
# WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
# OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
#
# Except as contained in this notice, the name of the XFree86 Project shall
# not be used in advertising or otherwise to promote the sale, use or other
# dealings in this Software without prior written authorization from the
# XFree86 Project.
#
# See 'man XF86Config' for info on the format of this file
Section "Files"
RgbPath "/usr/X11R6/lib/X11/rgb"
FontPath "/usr/X11R6/lib/X11/fonts/misc:unscaled"
FontPath "/usr/X11R6/lib/X11/fonts/75dpi:unscaled"
FontPath "/usr/X11R6/lib/X11/fonts/100dpi:unscaled"
FontPath "/usr/X11R6/lib/X11/fonts/Type1"
FontPath "/usr/X11R6/lib/X11/fonts/Speedo"
FontPath "/usr/X11R6/lib/X11/fonts/misc"
FontPath "/usr/X11R6/lib/X11/fonts/75dpi"
FontPath "/usr/X11R6/lib/X11/fonts/100dpi"
EndSection
Section "ServerFlags"
EndSection
Section "Keyboard"
Protocol "Standard"
XkbRules "xfree86"
XkbModel "pc101"
XkbLayout "us"
EndSection
Section "Pointer"
Protocol "Microsoft"
Device "/dev/cuaa0"
BaudRate 1200
EndSection
Section "Monitor"
Identifier "Primary Monitor"
VendorName "Unknown"
ModelName "Unknown"
HorizSync 31.5-69
VertRefresh 55-120
Modeline "1152x864" 65.00 1152 1200 1416 1480 864 893 903 973 interlace
Modeline "1024x768" 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync
Modeline "800x600" 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync
Modeline "640x480" 31.50 640 680 720 864 480 488 491 521
Modeline "640x400" 25.18 640 664 760 800 400 409 411 450
Modeline "480x300" 29.95 480 504 584 624 300 319 322 333 doublescan
Modeline "400x300" 25.00 400 424 488 520 300 319 322 333 doublescan
Modeline "320x240" 15.75 320 336 384 400 240 244 246 262 doublescan
Modeline "320x200" 12.59 320 336 384 400 200 204 205 225 doublescan
EndSection
Section "Device"
Identifier "Primary Card"
VendorName "Unknown"
BoardName "Trident TGUI9680 (generic)"
Option "med_dram"
# Option "tgui_pci_read_off" # Turn off PCI burst read mode.
Option "tgui_pci_write_off" # Turn off PCI burst write mode.
EndSection
Section "Screen"
Driver "SVGA"
Device "Primary Card"
Monitor "Primary Monitor"
SubSection "Display"
Depth 8
Modes "1152x864" "1024x768" "800x600" "640x480" "640x400" "480x300" "400x300" "320x240" "320x200"
EndSubSection
SubSection "Display"
Depth 15
Modes "1152x864" "1024x768" "800x600" "640x480" "640x400" "480x300" "400x300" "320x240" "320x200"
EndSubSection
SubSection "Display"
Depth 16
Modes "1152x864" "1024x768" "800x600" "640x480" "640x400" "480x300" "400x300" "320x240" "320x200"
EndSubSection
SubSection "Display"
Depth 24
Modes "1152x864" "1024x768" "800x600" "640x480" "640x400" "480x300" "400x300" "320x240" "320x200"
EndSubSection
SubSection "Display"
Depth 32
Modes "1152x864" "1024x768" "800x600" "640x480" "640x400" "480x300" "400x300" "320x240" "320x200"
EndSubSection
EndSection
From owner-freebsd-hackers Fri Oct 24 14:24:55 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA21196
for hackers-outgoing; Fri, 24 Oct 1997 14:24:55 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA21190
for <hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 14:24:51 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA01007; Fri, 24 Oct 1997 23:24:49 +0200
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.7/8.8.5) id XAA10790;
Fri, 24 Oct 1997 23:02:20 +0200 (MET DST)
Message-ID: <19971024230220.VY14522@uriah.heep.sax.de>
Date: Fri, 24 Oct 1997 23:02:20 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: hackers@FreeBSD.ORG
Cc: root@kcmain-int.SKW-Inc.Com (Charlie Root)
Subject: Re: XFree86
References: <199710251622.LAA00247@kcmain-int.SKW-Inc.Com>
X-Mailer: Mutt 0.60_p2-3,5,8-9
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: <199710251622.LAA00247@kcmain-int.SKW-Inc.Com>; from Charlie Root on Oct 25, 1997 11:22:24 -0500
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
As Charlie Root wrote:
> I have a new PC with a Trident 9680 chipset in it. When I try to start
> Xwindows, it switches graphics mode, goes to all black and stops. If I do a
> CTRL-ALT-BS, it comes back to my prompt. I thought this had something to do
> with the Linear Frame Buffer being mis-aligned. I tried using the config
> parameter to disable the frame buffer and it did not help.
That's probably something you'd better report to the XFree86 folks
(although i'm aware that David Dawes is reading this list as well).
Also, i think the TGUI support has been developed a lot lately, so
make sure to not use an outdated Xserver for your tests.
--
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 Oct 24 14:31:47 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA21704
for hackers-outgoing; Fri, 24 Oct 1997 14:31:47 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from cedb.dpcsys.com (cedb.dpcsys.com [206.16.184.4])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA21695
for <freebsd-hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 14:31:41 -0700 (PDT)
(envelope-from dan@dpcsys.com)
Received: from localhost (dan@localhost) by cedb.dpcsys.com (8.8.5/8.8.2) with SMTP id VAA10970; Fri, 24 Oct 1997 21:30:21 GMT
Date: Fri, 24 Oct 1997 14:30:21 -0700 (PDT)
From: Dan Busarow <dan@dpcsys.com>
To: "James E. Housley" <housley@pr-comm.com>
cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: Anti-spam in hub.mc
In-Reply-To: <34510029.193E7316@pr-comm.com>
Message-ID: <Pine.UW2.3.95.971024142647.10828F-100000@cedb>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Fri, 24 Oct 1997, James E. Housley wrote:
> I think I am missing something important here. I was using an older anti-spam
> rule set for sendmail. I started using the new set that is in hub.mc . My
> question is that mail from a site that is blocked has a message/reply with
> #blocked.contact postmaster@pr-comm.com (for me, was postmaster@FreeBSD.ORG).
> My question is how will they actually contact the postmaster if mail from that
> site is blocked?????
By telephone. Seriously, if you've blocked someone by mistake they
can either get your phone number from whois (you do keep your contact
information up to date, right) or send mail from an account at a non-blocked
site.
Personally I wouldn't bother with the contact ... message, our message
is "Access denied".
Dan
--
Dan Busarow 714 443 4172
DPC Systems / Beach.Net dan@dpcsys.com
Dana Point, California 83 09 EF 59 E0 11 89 B4 8D 09 DB FD E1 DD 0C 82
From owner-freebsd-hackers Fri Oct 24 14:44:22 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA22582
for hackers-outgoing; Fri, 24 Oct 1997 14:44:22 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from opus.cts.cwu.edu (skynyrd@opus.cts.cwu.edu [198.104.92.71])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA22577
for <freebsd-hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 14:44:19 -0700 (PDT)
(envelope-from skynyrd@opus.cts.cwu.edu)
Received: from localhost (skynyrd@localhost)
by opus.cts.cwu.edu (8.8.7/8.8.7) with SMTP id OAA08852;
Fri, 24 Oct 1997 14:44:13 -0700 (PDT)
(envelope-from skynyrd@opus.cts.cwu.edu)
Date: Fri, 24 Oct 1997 14:44:12 -0700 (PDT)
From: Chris Timmons <skynyrd@opus.cts.cwu.edu>
To: Paul Saab <paul@mu.org>
cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: netstat: kvm_read: Bad address
In-Reply-To: <199710242055.PAA08603@elvis.mu.org>
Message-ID: <Pine.BSF.3.95.971024144305.8342A-100000@opus.cts.cwu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
You might cvsup 2.2-STABLE and rebuild your kernel; David Greenman
recently committed a fix for a problem that sounds similar to yours.
-Chris
From owner-freebsd-hackers Fri Oct 24 14:47:43 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA22760
for hackers-outgoing; Fri, 24 Oct 1997 14:47:43 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA22755
for <hackers@freebsd.org>; Fri, 24 Oct 1997 14:47:40 -0700 (PDT)
(envelope-from jkh@time.cdrom.com)
Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id OAA24975 for <hackers@freebsd.org>; Fri, 24 Oct 1997 14:47:40 -0700 (PDT)
To: hackers@freebsd.org
Subject: Something which 2.2.5 upgraders might find handy.
Date: Fri, 24 Oct 1997 14:47:39 -0700
Message-ID: <24971.877729659@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
In ftp://freebsd.org/pub/jkh/225upgrade.tgz is a small package, simply
saying:
pkg_add ftp://freebsd.org/pub/jkh/225upgrade.tgz
to launch the 2.2.5 upgrade on your machine. The key thing this
package does is upgrade your /stand to 2.2.5 first so that the
sysinstall upgrade code you run is the latest (and upgrade's been
changed a bit for 2.2.5). All you should need to do is select your
media type, the distributions you want to upgrade and you should be
off and running.
Let me know how well it works in actual practice. :)
Jordan
From owner-freebsd-hackers Fri Oct 24 15:11:55 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA24017
for hackers-outgoing; Fri, 24 Oct 1997 15:11:55 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from localhost.zilker.net (jump-x2-1021.jumpnet.com [207.8.67.21])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA24012
for <freebsd-hackers@freebsd.org>; Fri, 24 Oct 1997 15:11:51 -0700 (PDT)
(envelope-from marquard@zilker.net)
Received: (from marquard@localhost) by localhost.zilker.net (8.8.7/8.8.3) id RAA10335; Fri, 24 Oct 1997 17:11:40 -0500 (CDT)
To: freebsd-hackers@freebsd.org
Subject: Re: netstat: kvm_read: Bad address
References: <199710242055.PAA08603@elvis.mu.org>
From: Dave Marquardt <marquard@zilker.net>
Date: 24 Oct 1997 17:11:09 -0500
In-Reply-To: Paul Saab's message of "Fri, 24 Oct 1997 15:55:45 -0500 (CDT)"
Message-ID: <85zpnyerr6.fsf@localhost.zilker.net>
Lines: 28
X-Mailer: Gnus v5.5/XEmacs 19.15
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Paul Saab <paul@mu.org> writes:
> and find the bug. Now today I got this while doing a netstat on
> another machine with exactly the same hardware configuration as
> the one which had the kernel panic but it is running 2.2.5-RELEASE.
>
>
> Active Internet connections
> Proto Recv-Q Send-Q Local Address Foreign Address (state)
> tcp 0 0 themaneater.com.http 204.184.83.7.1976 ESTABLISHED
> tcp 0 8398 themaneater.com.http 204.184.83.7.1975 ESTABLISHED
> tcp 0 5650 themaneater.com.http 204.184.83.7.1974 ESTABLISHED
> tcp 0 0 themaneater.com.http 208.196.245.66.2658 ESTABLISHED
> tcp 0 0 themaneater.com.http 208.196.245.66.2657 ESTABLISHED
> tcp 0 0 themaneater.com.ftp-da Mizzou-AS6-17.mi.1232 TIME_WAIT
> tcp 361 -266160568 themaneater.com.http 16.211.65.241.2656 -264201400
> tcp 0 -264546048 128.204.64.241.16625 144.105.65.241.39147 CLOSED
> netstat: kvm_read: Bad address
> ???
> udp 0 0 elvis.4724 elvis.domain
> udp 0 0 localhost.domain *.*
> udp 0 0 elvis.domain *.*
You'll see this on lots of BSD-based systems. netstat reads the items
on the tcb (TCP PCB) list one at a time from kernel memory, and the
list has changed while you were reading it. No big deal, just a
little annoying. To fix it would be painful, I think.
-Dave
From owner-freebsd-hackers Fri Oct 24 15:17:04 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA24521
for hackers-outgoing; Fri, 24 Oct 1997 15:17:04 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA24509
for <freebsd-hackers@freebsd.org>; Fri, 24 Oct 1997 15:17:00 -0700 (PDT)
(envelope-from jamil@trojanhorse.ml.org)
Received: from localhost (jamil@localhost)
by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id PAA01238
for <freebsd-hackers@freebsd.org>; Fri, 24 Oct 1997 15:12:48 -0700 (PDT)
Date: Fri, 24 Oct 1997 15:12:48 -0700 (PDT)
From: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
To: freebsd-hackers@freebsd.org
Subject: ioctl() base command groups
Message-ID: <Pine.BSF.3.96.971024151138.1236A-100000@trojanhorse.ml.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Are the groups used in the _IO* macros, which are usually a single
character supposed to have some systematic system of assignment?
From owner-freebsd-hackers Fri Oct 24 17:34:53 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id RAA01334
for hackers-outgoing; Fri, 24 Oct 1997 17:34:53 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from mail.calweb.com (mail.calweb.com [208.131.56.11])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA01325
for <freebsd-hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 17:34:51 -0700 (PDT)
(envelope-from jflists@mail.calweb.com)
Received: by mail.calweb.com (8.8.6/8.8.6) with SMTP id RAA18786;
Fri, 24 Oct 1997 17:31:57 -0700 (PDT)
X-SMTP: hello devnull from jflists@pop.calweb.com
server @devnull.calweb.com ip 207.173.135.51
Message-Id: <3.0.3.32.19971024173016.0099a1a0@pop.calweb.com>
Warning: Unsolicited Commercial Email (UCE) will be returned to send in bulk
X-Sender: jflists@pop.calweb.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 24 Oct 1997 17:30:16 -0700
To: Dan Busarow <dan@dpcsys.com>, "James E. Housley" <housley@pr-comm.com>
From: "jfesler@calweb.com" <jflists@calweb.com>
Subject: Re: Anti-spam in hub.mc
Cc: freebsd-hackers@FreeBSD.ORG
In-Reply-To: <Pine.UW2.3.95.971024142647.10828F-100000@cedb>
References: <34510029.193E7316@pr-comm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
The filter I use
At 02:30 PM 10/24/97 -0700, Dan Busarow quoted and added in..
>> My question is how will they actually contact the postmaster if mail
from that
>> site is blocked?????
>
>By telephone. Seriously, if you've blocked someone by mistake they
>can either get your phone number from whois (you do keep your contact
Personally, mail to "postmaster" is *always* accepted over here.
Period. Regardless of other filters that are in place. Most of the
time, the error message I give out says to contact Postmaster, as
in may cases domain names are being used without consent of their owners.
--
Jason Fesler jfesler@calweb.com 'whois jf319' | When the chips are down
Admin, CalWeb Internet Services www.calweb.com | The buffalo's empty
Junk email returned in bulk; 1 cc to your postmaster |
Junk mail probs? http://www.gigo.com/junkmail.htm | :-)
From owner-freebsd-hackers Fri Oct 24 18:14:13 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA02835
for hackers-outgoing; Fri, 24 Oct 1997 18:14:13 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA02828
for <hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 18:14:04 -0700 (PDT)
(envelope-from tlambert@usr08.primenet.com)
Received: (from daemon@localhost)
by smtp03.primenet.com (8.8.7/8.8.7) id SAA07130;
Fri, 24 Oct 1997 18:14:02 -0700 (MST)
Received: from usr08.primenet.com(206.165.6.208)
via SMTP by smtp03.primenet.com, id smtpd007124; Fri Oct 24 18:13:52 1997
Received: (from tlambert@localhost)
by usr08.primenet.com (8.8.5/8.8.5) id SAA10113;
Fri, 24 Oct 1997 18:13:43 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710250113.SAA10113@usr08.primenet.com>
Subject: Re: zipfs filesystem anyone ?
To: gurney_j@resnet.uoregon.edu
Date: Sat, 25 Oct 1997 01:13:43 +0000 (GMT)
Cc: tlambert@primenet.com, michaelh@cet.co.jp, luigi@labinfo.iet.unipi.it,
hackers@FreeBSD.ORG
In-Reply-To: <19971024114243.36902@hydrogen.nike.efn.org> from "John-Mark Gurney" at Oct 24, 97 11:42:43 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > If it's in there, then this is an important first step. The next step
> > would be to add a special placeholder descriptor that can be replaced
> > in vfs_op_desc for several slots. This would make it so you didn't
> > have to rebuild all of vnode_if.c and vnode_if.h to add new descriptors:
> > you can overwrite the placeholders instead.
>
> or should we simply use the dummy NULL entry (and add some) for the place
> holder?
The list terminator is still necessary for the population pass, where
the vectors get populated. The VOP_REPLACEME needs to be seperate.
> personally, a possible define that declares I want a possible X extra
> vop vectors... and then have a couple variables that tell you the
> maximum number, and the current last offset... this shouldn't be hard
> to do...
They kind of need to be static, unless the vector list becomes a linker
set. This can't happen until the linker set can be agregated between
linker uses. Basically, if you want to be able to pull it back out
later, you have to be able to distinguish it. My plan was to use a
seperate ELF section for each modules contribution to global linker
sets. This lets you use an ELF image archiver to "permanently" add
modules into the kernel (no difference between kld modules and normal
kernel components, except the image file that backs them).
> > Actually, that particular change (not using FFS to size the table)
> > is the first change in a chain that lets you boot a machine without
> > a file system at all (my original purpose). 8-) 8-).
>
> kool.... are you on -current?
Yes.
> I guess I should of announced my vfsinit
> patches to hackers instead... basicly, to get ride of LKM's and prepare
> for kld modules, I needed to change the vfs system to initalize on a
> permodule basis instead of a initalize all staticly compiled module
> idea...
Be very careful here. I did this code under Windows 95. It turns out
that you need to sort the *total* descriptor list, or you will end up
with order of reference problems. I loaded the UFS, then I loaded the
FFS, and initialized them in that order. This includes the NULL ops
that you normally leave of tf the end, and llow to be set in the
population pass (referred to above).
Sorting the list also allows you to reference by index instead of by
descriptor. If you think about it, you won't have a descriptor for
a new VOP, if you dynamically load it, in vnode_if.h. This loses the
little glue function. To fix this, you have to kill the glue functions.
And you can do it if you can indext into the op vector and get the right
function.
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 Oct 24 18:17:06 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA02975
for hackers-outgoing; Fri, 24 Oct 1997 18:17:06 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA02967
for <freebsd-hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 18:17:03 -0700 (PDT)
(envelope-from tlambert@usr08.primenet.com)
Received: (from daemon@localhost)
by smtp04.primenet.com (8.8.7/8.8.7) id SAA17899;
Fri, 24 Oct 1997 18:16:54 -0700 (MST)
Received: from usr08.primenet.com(206.165.6.208)
via SMTP by smtp04.primenet.com, id smtpd017880; Fri Oct 24 18:16:52 1997
Received: (from tlambert@localhost)
by usr08.primenet.com (8.8.5/8.8.5) id SAA10298;
Fri, 24 Oct 1997 18:16:48 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710250116.SAA10298@usr08.primenet.com>
Subject: Re: Anti-spam in hub.mc
To: jflists@calweb.com
Date: Sat, 25 Oct 1997 01:16:48 +0000 (GMT)
Cc: dan@dpcsys.com, housley@pr-comm.com, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <3.0.3.32.19971024173016.0099a1a0@pop.calweb.com> from "jfesler@calweb.com" at Oct 24, 97 05:30:16 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> >> My question is how will they actually contact the postmaster if mail
> >> from that site is blocked?????
>
> Personally, mail to "postmaster" is *always* accepted over here.
> Period. Regardless of other filters that are in place. Most of the
> time, the error message I give out says to contact Postmaster, as
> in may cases domain names are being used without consent of their owners.
This is actually required, unconditionally, even if you are blocking
other mail from that site.
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 Oct 24 18:20:58 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA03180
for hackers-outgoing; Fri, 24 Oct 1997 18:20:58 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA03175
for <freebsd-hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 18:20:54 -0700 (PDT)
(envelope-from karpen@ocean.campus.luth.se)
Received: (from karpen@localhost)
by ocean.campus.luth.se (8.8.5/8.8.5) id DAA11603;
Sat, 25 Oct 1997 03:29:08 +0200 (CEST)
From: Mikael Karpberg <karpen@ocean.campus.luth.se>
Message-Id: <199710250129.DAA11603@ocean.campus.luth.se>
Subject: Re: Anti-spam in hub.mc
In-Reply-To: <3.0.3.32.19971024173016.0099a1a0@pop.calweb.com> from "jfesler@calweb.com" at "Oct 24, 97 05:30:16 pm"
To: jflists@calweb.com
Date: Sat, 25 Oct 1997 03:29:08 +0200 (CEST)
Cc: freebsd-hackers@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
According to jfesler@calweb.com:
> The filter I use
>
> At 02:30 PM 10/24/97 -0700, Dan Busarow quoted and added in..
> >> My question is how will they actually contact the postmaster if mail
> >> from that site is blocked?????
Er... the filter, if I'm correct, will only block non-exiting domain names,
and the sender can, therefor, by simply NOT trying to fake his domain, but
instead using his normal mail system, mail postmaster.
/Mikael
From owner-freebsd-hackers Fri Oct 24 18:25:12 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA03304
for hackers-outgoing; Fri, 24 Oct 1997 18:25:12 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA03299
for <freebsd-hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 18:25:07 -0700 (PDT)
(envelope-from tlambert@usr08.primenet.com)
Received: (from daemon@localhost)
by smtp03.primenet.com (8.8.7/8.8.7) id SAA07520;
Fri, 24 Oct 1997 18:25:02 -0700 (MST)
Received: from usr08.primenet.com(206.165.6.208)
via SMTP by smtp03.primenet.com, id smtpd007514; Fri Oct 24 18:24:57 1997
Received: (from tlambert@localhost)
by usr08.primenet.com (8.8.5/8.8.5) id SAA10641;
Fri, 24 Oct 1997 18:24:47 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710250124.SAA10641@usr08.primenet.com>
Subject: Re: Possible SERIOUS bug in open()? (Big time bug)
To: Don.Lewis@tsc.tdk.com (Don Lewis)
Date: Sat, 25 Oct 1997 01:24:47 +0000 (GMT)
Cc: tlambert@primenet.com, jamil@trojanhorse.ml.org, thorpej@nas.nasa.gov,
joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <199710242045.NAA18723@salsa.gv.tsc.tdk.com> from "Don Lewis" at Oct 24, 97 01:45:02 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> Opening files has side effects, too. For instance, space isn't
> recovered if a file is unlinked if the file is open. There is
> also the issue of O_EXLOCK and O_SHLOCK. I don't want another
> user to have the ability to do either with my mode 0600 files.
Clearly, normal files would enforce read or write permision for
open.
But say you have a processor emulator that gets invoked by an
execution class loader so that it can mmap a foreign binary
in its address space, and then run it.
,------------------. ,------------------.
| DEC Alpha binary | | DEC Alpha binary |
| regular process | | emulator process |
| | | ,--------------. |
| | | | x86 image | |
| | | | (Netscape) | |
| | | `--------------' |
`------------------' `------------------'
You need to be able to open something with just "x" access to map
it so that a proces you own can "run" it. So you also want to
allow an open if you have execute access.
Does having only execute access keep you from reading a file?
No. You can make it core.
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 Oct 24 18:46:40 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA04174
for hackers-outgoing; Fri, 24 Oct 1997 18:46:40 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04166
for <hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 18:46:37 -0700 (PDT)
(envelope-from michaelh@cet.co.jp)
Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id BAA24648; Sat, 25 Oct 1997 01:44:30 GMT
Date: Sat, 25 Oct 1997 10:44:29 +0900 (JST)
From: Michael Hancock <michaelh@cet.co.jp>
To: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
cc: Terry Lambert <tlambert@primenet.com>, luigi@labinfo.iet.unipi.it,
hackers@FreeBSD.ORG
Subject: Re: zipfs filesystem anyone ?
In-Reply-To: <19971024114243.36902@hydrogen.nike.efn.org>
Message-ID: <Pine.SV4.3.95.971025103700.24520B-100000@parkplace.cet.co.jp>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Fri, 24 Oct 1997, John-Mark Gurney wrote:
> actually.. the change wasn't very massive.. just 3 lines of code and some
> comment updates...
>
Sheez, Terry, first you give us mega-commits and now you give us tiny
pointless ones. When are you going to get this right? ;-)
Mike Hancock
From owner-freebsd-hackers Fri Oct 24 18:49:39 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA04333
for hackers-outgoing; Fri, 24 Oct 1997 18:49:39 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from server.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04317
for <hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 18:49:20 -0700 (PDT)
(envelope-from perlsta@cs.sunyit.edu)
Received: from localhost (perlsta@localhost)
by server.local.sunyit.edu (8.8.7/8.8.5) with SMTP id VAA06304;
Fri, 24 Oct 1997 21:54:11 -0500 (EST)
X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs
Date: Fri, 24 Oct 1997 21:54:11 -0500 (EST)
From: Alfred Perlstein <perlsta@cs.sunyit.edu>
X-Sender: perlsta@server.local.sunyit.edu
To: "Jordan K. Hubbard" <jkh@time.cdrom.com>
cc: hackers@FreeBSD.ORG
Subject: why is freebsd distributed like this?
In-Reply-To: <24971.877729659@time.cdrom.com>
Message-ID: <Pine.BSF.3.96.971024215119.6289B-100000@server.local.sunyit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
I understand most of the FreeBSD release system, however i have a problem
with it that i feel should be addressed.
Why are there releases floating around with security holes in them?
certain 'fixes' that are trivial but nessesary like the procfs patch
should be applied all around the source tree as soon as possible.
I understand that that is what the -stable releases are for... but it's
almost being too much of a purist to let that stuff continue to be in
freebsd.
.________________________________________________________________________ __ _
|Alfred Perlstein - Programming & SysAdmin --"Have you seen my FreeBSD tatoo?"
|perlsta@sunyit.edu --"who was that masked admin?"
|http://www.cs.sunyit.edu/~perlsta
:
'
From owner-freebsd-hackers Fri Oct 24 18:55:28 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA04618
for hackers-outgoing; Fri, 24 Oct 1997 18:55:28 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from ren.dtir.qld.gov.au (firewall-user@ns.dtir.qld.gov.au [203.108.138.66])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04613
for <freebsd-hackers@freebsd.org>; Fri, 24 Oct 1997 18:55:25 -0700 (PDT)
(envelope-from syssgm@dtir.qld.gov.au)
Received: by ren.dtir.qld.gov.au; id MAA07244; Sat, 25 Oct 1997 12:07:18 +1000 (EST)
Received: from ogre.dtir.qld.gov.au(167.123.8.3) by ren.dtir.qld.gov.au via smap (3.2)
id xma007242; Sat, 25 Oct 97 12:07:04 +1000
Received: from troll.dtir.qld.gov.au (troll.dtir.qld.gov.au [167.123.8.1])
by ogre.dtir.qld.gov.au (8.8.7/8.8.7) with ESMTP id LAA24320;
Sat, 25 Oct 1997 11:54:15 +1000 (EST)
Received: from localhost (syssgm@localhost)
by troll.dtir.qld.gov.au (8.8.5/8.8.5) with SMTP id LAA02018;
Sat, 25 Oct 1997 11:54:11 +1000 (EST)
Message-Id: <199710250154.LAA02018@troll.dtir.qld.gov.au>
X-Authentication-Warning: troll.dtir.qld.gov.au: syssgm@localhost didn't use HELO protocol
To: Charles Henrich <henrich@crh.cl.msu.edu>
cc: freebsd-hackers@freebsd.org, syssgm@dtir.qld.gov.au
Subject: Perils of login.conf (Was: fsck (2.2.5-RELEASE) large filesystems broken)
References: <19971023004136.21792@crh.cl.msu.edu> <199710240723.RAA15535@ogre.dtir.qld.gov.au> <19971024083642.18571@crh.cl.msu.edu>
In-Reply-To: <19971024083642.18571@crh.cl.msu.edu>
from Charles Henrich at "Fri, 24 Oct 1997 08:36:42 -0400"
Date: Sat, 25 Oct 1997 11:54:11 +1000
From: Stephen McKay <syssgm@dtir.qld.gov.au>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
[Moved from -bugs to -hackers for a bit of debate]
On Friday, 24th October 1997, Charles Henrich wrote:
>On the subject of Re: fsck (2.2.5-RELEASE) large filesystems broken, Stephen McKay stated:
>
>> I'd guess that you are being bitten by /etc/login.conf. The comments in it
>> claim that 'daemon' is used by /etc/rc and 'daemon' has "datasize=32M". Try
>> bumping this to 64M.
>
>Yes, that was it. I'd like to take an assault rifle to the fellow who decided
>the defaults for FreeBSD is so limited, especially considering in most cases
>FreeBSD is installed as a one or two use system.
Ahem! Well, I wouldn't be using anything more dangerous than Nerf bats
myself, but I have been inconvenienced a couple times by login.conf.
There are some people who are very keen on it, and presumably it does
wonderful things for them. However, after some pain and a bit of reflection,
I think the defaults for everything should be pushed way up, like the maximum
that FreeBSD can take for all these knobs, and let those that support hundreds
or thousands of users wind them back to whatever limits they wish to impose.
If this was the case then regular users would have one less thing to worry
about and magazine reviewers who benchmark "out of the box" would get
sensible results. Those who really use login.conf to impose carefully
selected limits would be unaffected.
Stephen.
From owner-freebsd-hackers Fri Oct 24 19:03:47 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA05147
for hackers-outgoing; Fri, 24 Oct 1997 19:03:47 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA05142
for <hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 19:03:45 -0700 (PDT)
(envelope-from jkh@time.cdrom.com)
Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id TAA13382; Fri, 24 Oct 1997 19:03:09 -0700 (PDT)
To: Alfred Perlstein <perlsta@cs.sunyit.edu>
cc: hackers@FreeBSD.ORG
Subject: Re: why is freebsd distributed like this?
In-reply-to: Your message of "Fri, 24 Oct 1997 21:54:11 CDT."
<Pine.BSF.3.96.971024215119.6289B-100000@server.local.sunyit.edu>
Date: Fri, 24 Oct 1997 19:03:09 -0700
Message-ID: <13379.877744989@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> Why are there releases floating around with security holes in them?
> certain 'fixes' that are trivial but nessesary like the procfs patch
> should be applied all around the source tree as soon as possible.
1. We can't change what's already been released, at least not without
causing serious confusion.
2. If you know of a specific security hole still in -current or -stable
then the thing to do is NOT to whine here about it, the thing to do
is to submit a PR if you're actually interested in seeing it fixed.
And it's as simple as that.
Jordan
From owner-freebsd-hackers Fri Oct 24 19:11:49 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA05580
for hackers-outgoing; Fri, 24 Oct 1997 19:11:49 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from cedb.dpcsys.com (cedb.dpcsys.com [206.16.184.4])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA05574
for <freebsd-hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 19:11:48 -0700 (PDT)
(envelope-from dan@dpcsys.com)
Received: from localhost (dan@localhost) by cedb.dpcsys.com (8.8.5/8.8.2) with SMTP id CAA13215; Sat, 25 Oct 1997 02:11:34 GMT
Date: Fri, 24 Oct 1997 19:11:34 -0700 (PDT)
From: Dan Busarow <dan@dpcsys.com>
To: Terry Lambert <tlambert@primenet.com>
cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: Anti-spam in hub.mc
In-Reply-To: <199710250116.SAA10298@usr08.primenet.com>
Message-ID: <Pine.UW2.3.95.971024182721.12845A-100000@cedb>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Sat, 25 Oct 1997, Terry Lambert wrote:
> > >> My question is how will they actually contact the postmaster if mail
> > >> from that site is blocked?????
> >
> This is actually required, unconditionally, even if you are blocking
> other mail from that site.
What was that RFC number? I do have a postmater mailbox and
it is usable by 99.9995% of the Internet. (rough estimate)
I see nothing in in RFC1123 that says I MUST accept mail to
postmaster from every host on the Net, just that my MTA MUST
support the postmaster mailbox, which it does, filters and all.
Requiring postmaster to go through would also rule out check_mail
filters which are certainly allowed by the RFCs. (quoting
RFC821) "*if accepted*, the receiver-SMTP returns a 250 OK reply."
Emphasis mine.
RFC lawyering aside, care to share the IOS filter that checks
for recipient if the packet is for port 25 but from a blocked
source address?
Dan
--
Dan Busarow 714 443 4172
DPC Systems / Beach.Net dan@dpcsys.com
Dana Point, California 83 09 EF 59 E0 11 89 B4 8D 09 DB FD E1 DD 0C 82
From owner-freebsd-hackers Fri Oct 24 19:20:17 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA05956
for hackers-outgoing; Fri, 24 Oct 1997 19:20:17 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from misery.sdf.com (misery.sdf.com [204.244.210.193])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA05949
for <hackers@freebsd.org>; Fri, 24 Oct 1997 19:20:07 -0700 (PDT)
(envelope-from tom@sdf.com)
Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1)
id 0xOvnj-0005K6-00; Fri, 24 Oct 1997 19:18:07 -0700
Date: Fri, 24 Oct 1997 19:18:04 -0700 (PDT)
From: Tom <tom@sdf.com>
To: Alfred Perlstein <perlsta@cs.sunyit.edu>
cc: hackers@freebsd.org
Subject: Re: why is freebsd distributed like this?
In-Reply-To: <Pine.BSF.3.96.971024215119.6289B-100000@server.local.sunyit.edu>
Message-ID: <Pine.BSF.3.95q.971024191134.20278C-100000@misery.sdf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
On Fri, 24 Oct 1997, Alfred Perlstein wrote:
> I understand most of the FreeBSD release system, however i have a problem
> with it that i feel should be addressed.
>
> Why are there releases floating around with security holes in them?
> certain 'fixes' that are trivial but nessesary like the procfs patch
> should be applied all around the source tree as soon as possible.
>
> I understand that that is what the -stable releases are for... but it's
> almost being too much of a purist to let that stuff continue to be in
> freebsd.
If you are talking about older releases, then you shouldn't be using
older releases. By deleting older releases, you can't deny they ever
existed. If you change an older release, it is becomes something
different. Also, there aren't any "stable releases". There are
2.1-stable and 2.2-stable branches, which releases have been made from at
certain points in time.
I don't really see a problem here, but again, I also have an archive of
1.1.5.1 around still.
> .________________________________________________________________________ __ _
> |Alfred Perlstein - Programming & SysAdmin --"Have you seen my FreeBSD tatoo?"
> |perlsta@sunyit.edu --"who was that masked admin?"
> |http://www.cs.sunyit.edu/~perlsta
> :
> '
Tom
From owner-freebsd-hackers Fri Oct 24 19:20:22 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA05972
for hackers-outgoing; Fri, 24 Oct 1997 19:20:22 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from cedb.dpcsys.com (cedb.dpcsys.com [206.16.184.4])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA05967
for <freebsd-hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 19:20:21 -0700 (PDT)
(envelope-from dan@dpcsys.com)
Received: from localhost (dan@localhost) by cedb.dpcsys.com (8.8.5/8.8.2) with SMTP id CAA13232; Sat, 25 Oct 1997 02:20:14 GMT
Date: Fri, 24 Oct 1997 19:20:13 -0700 (PDT)
From: Dan Busarow <dan@dpcsys.com>
To: "jfesler@calweb.com" <jflists@calweb.com>
cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: Anti-spam in hub.mc
In-Reply-To: <3.0.3.32.19971024173016.0099a1a0@pop.calweb.com>
Message-ID: <Pine.UW2.3.95.971024191258.12845B-100000@cedb>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Fri, 24 Oct 1997, jfesler@calweb.com wrote:
> Personally, mail to "postmaster" is *always* accepted over here.
> Period. Regardless of other filters that are in place. Most of the
> time, the error message I give out says to contact Postmaster, as
> in may cases domain names are being used without consent of their owners.
A domain or IP block only makes it into our filters after the postmaster
there has made it clear that they don't care if someone sends spam
from their site. (saying we can't do anything about spam amounts to
don't care) I haven't blocked a relay site yet but I do have some
candidates.
Dan
--
Dan Busarow 714 443 4172
DPC Systems / Beach.Net dan@dpcsys.com
Dana Point, California 83 09 EF 59 E0 11 89 B4 8D 09 DB FD E1 DD 0C 82
From owner-freebsd-hackers Fri Oct 24 20:40:27 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id UAA09530
for hackers-outgoing; Fri, 24 Oct 1997 20:40:27 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA09518
for <hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 20:40:24 -0700 (PDT)
(envelope-from dkelly@nospam.hiwaay.net)
Received: from nospam.hiwaay.net (tnt1-221.HiWAAY.net [208.147.147.221])
by fly.HiWAAY.net (8.8.7/8.8.6) with ESMTP id WAA06035
for <hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 22:40:20 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP
id WAA04114 for <hackers@FreeBSD.ORG>; Fri, 24 Oct 1997 22:40:18 -0500 (CDT)
Message-Id: <199710250340.WAA04114@nospam.hiwaay.net>
X-Mailer: exmh version 2.0zeta 7/24/97
To: hackers@FreeBSD.ORG
From: dkelly@hiwaay.net
Subject: Re: why is freebsd distributed like this?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 24 Oct 1997 22:40:18 -0500
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> Why are there releases floating around with security holes in them?
Who is going to go around and take them away from people? :-)
I think its a good idea for Walnut Creek to keep older releases online for
a while. Sometimes its handy to be able to go back to older software just
to have a look. And for some, pulling it out of CVS might be too much.
Its really inconvienent when a port's master site decides to update their
code and delete the exact version a port relies on.
As for security holes? That's what the -security list is for. Can't do much
for people who don't care to help themselves.
--
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 Fri Oct 24 20:40:55 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id UAA09572
for hackers-outgoing; Fri, 24 Oct 1997 20:40:55 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA09565
for <hackers@freebsd.org>; Fri, 24 Oct 1997 20:40:51 -0700 (PDT)
(envelope-from nate@rocky.mt.sri.com)
Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100])
by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id VAA23053;
Fri, 24 Oct 1997 21:40:46 -0600 (MDT)
Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id VAA22910; Fri, 24 Oct 1997 21:40:43 -0600 (MDT)
Date: Fri, 24 Oct 1997 21:40:43 -0600 (MDT)
Message-Id: <199710250340.VAA22910@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: Alfred Perlstein <perlsta@cs.sunyit.edu>
Cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, hackers@freebsd.org
Subject: Re: why is freebsd distributed like this?
In-Reply-To: <Pine.BSF.3.96.971024215119.6289B-100000@server.local.sunyit.edu>
References: <24971.877729659@time.cdrom.com>
<Pine.BSF.3.96.971024215119.6289B-100000@server.local.sunyit.edu>
X-Mailer: VM 6.29 under 19.15 XEmacs Lucid
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> Why are there releases floating around with security holes in them?
> certain 'fixes' that are trivial but nessesary like the procfs patch
> should be applied all around the source tree as soon as possible.
Umm, they were? But, it's really hard to delete releases from CD's.
All security bugs are 'fixed' in the trees as soon as possible. But,
new bugs/problems are found, and you can't go change bits already set in
stone.
If people aren't watching the security mailing list, then there's
nothing we can do about it. And, the fact of the matter is that it
costs too much money for WC to burn all the CD's and build new ones for
every security bug that crops up. If people aren't willing to 'keep up'
with their vendor (ie; us) and find out about bugs, then there's nothing
we can do given the current resources. Even Sun doesn't let it's users
know about security violations 'on their own' and we pay them 10's of
thousands of dollars a year.
Nate
From owner-freebsd-hackers Sat Oct 25 00:46:06 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id AAA20163
for hackers-outgoing; Sat, 25 Oct 1997 00:46:06 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA20152
for <hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 00:46:01 -0700 (PDT)
(envelope-from gurney_j@efn.org)
Received: (from jmg@localhost)
by hydrogen.nike.efn.org (8.8.7/8.8.7) id AAA02976;
Sat, 25 Oct 1997 00:45:45 -0700 (PDT)
Message-ID: <19971025004544.21378@hydrogen.nike.efn.org>
Date: Sat, 25 Oct 1997 00:45:44 -0700
From: John-Mark Gurney <gurney_j@efn.org>
To: Terry Lambert <tlambert@primenet.com>
Cc: michaelh@cet.co.jp, luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG
Subject: Re: zipfs filesystem anyone ?
References: <19971024114243.36902@hydrogen.nike.efn.org> <199710250113.SAA10113@usr08.primenet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <199710250113.SAA10113@usr08.primenet.com>; from Terry Lambert on Sat, Oct 25, 1997 at 01:13:43AM +0000
Reply-To: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
Organization: Cu Networking
X-Operating-System: FreeBSD 2.2.1-RELEASE i386
X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4
X-Files: The truth is out there
X-URL: http://resnet.uoregon.edu/~gurney_j/
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Terry Lambert scribbled this message on Oct 25:
> > > If it's in there, then this is an important first step. The next step
> > > would be to add a special placeholder descriptor that can be replaced
> > > in vfs_op_desc for several slots. This would make it so you didn't
> > > have to rebuild all of vnode_if.c and vnode_if.h to add new descriptors:
> > > you can overwrite the placeholders instead.
> >
> > or should we simply use the dummy NULL entry (and add some) for the place
> > holder?
>
> The list terminator is still necessary for the population pass, where
> the vectors get populated. The VOP_REPLACEME needs to be seperate.
I can see on the vnodeopv_desc of the vfs layer, but why does the NULL
entry on the array of the vnodeop_desc array in vnode_if.c need the
last NULL, that is what vfs_opv_numops is for... (which the population
code uses)...
so what I'm saying is we make two vars, maxvfs_opv_numops in which we
allocate all the memory for that many ops... then as a new op is added
we simply increase vfs_opv_numops to keep track of were we add the next
op.. when it's equal to (or greater) then we simply disallow adding any
new ops...
the code to add this will be very minor... while your box is off line
you can use http://www.freebsd.org/cgi/cvsweb.cgi to browse the source...
> > personally, a possible define that declares I want a possible X extra
> > vop vectors... and then have a couple variables that tell you the
> > maximum number, and the current last offset... this shouldn't be hard
> > to do...
>
> They kind of need to be static, unless the vector list becomes a linker
> set. This can't happen until the linker set can be agregated between
I was talking about the size of the list being variable, but that ther
be an options like:
options "EXTRA_VNODEOPS=5"
then we simply do:
int maxvfs_opv_numops = (sizeof(vfs_op_descs)/sizeof(struct vnodeop_desc *)) +
EXTRA_VNODEOPS;
and then the define is like:
struct vnodeop_desc *vfs_op_descs[num] = {
};
and we simply modify the awk script to properly generate num... which
isn't hard...
> linker uses. Basically, if you want to be able to pull it back out
> later, you have to be able to distinguish it. My plan was to use a
> seperate ELF section for each modules contribution to global linker
> sets. This lets you use an ELF image archiver to "permanently" add
> modules into the kernel (no difference between kld modules and normal
> kernel components, except the image file that backs them).
ok.. good to hear...
> > I guess I should of announced my vfsinit
> > patches to hackers instead... basicly, to get ride of LKM's and prepare
> > for kld modules, I needed to change the vfs system to initalize on a
> > permodule basis instead of a initalize all staticly compiled module
> > idea...
>
> Be very careful here. I did this code under Windows 95. It turns out
> that you need to sort the *total* descriptor list, or you will end up
> with order of reference problems. I loaded the UFS, then I loaded the
> FFS, and initialized them in that order. This includes the NULL ops
> that you normally leave of tf the end, and llow to be set in the
> population pass (referred to above).
arg, I see what you mean.. ffs depends upon some of ufs's functions..
(arg, I was assuming that each module was independant)...
right now the only way I can think of preventhing this from being a
problem is to add the MOUNT_xxx to the declaration of the vnodeops,
and then including in the ffs a dependancy of ufs...
> Sorting the list also allows you to reference by index instead of by
> descriptor. If you think about it, you won't have a descriptor for
> a new VOP, if you dynamically load it, in vnode_if.h. This loses the
> little glue function. To fix this, you have to kill the glue functions.
> And you can do it if you can indext into the op vector and get the right
> function.
umm... isn't this already what is done? from vfs_opv_init:
opv_desc_vector[opve_descp->opve_op->vdesc_offset] =
opve_descp->opve_impl;
the above line will set the appropriate vector by the vdesc_offset..
comment from vdesc_offset:
/* offset in vector--first for speed */
then at the end, there is a second pass to fill in the remaining entries
with the entry from VOFFSET(vop_default) of it's own vector..
hmm... looks like we need to remove this comment:
/*
* Finally, go back and replace unfilled routines
* with their default. (Sigh, an O(n^3) algorithm. I
* could make it better, but that'd be work, and n is small.)
*/
as right now the final routine runs in n as far as I can tell... :)
ttyl..
--
John-Mark Gurney Modem/FAX: +1 541 683 6954
Cu Networking
Live in Peace, destroy Micro$oft, support free software, run FreeBSD
From owner-freebsd-hackers Sat Oct 25 01:03:31 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id BAA20838
for hackers-outgoing; Sat, 25 Oct 1997 01:03:31 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA20828
for <freebsd-hackers@freebsd.org>; Sat, 25 Oct 1997 01:03:27 -0700 (PDT)
(envelope-from gurney_j@efn.org)
Received: (from jmg@localhost)
by hydrogen.nike.efn.org (8.8.7/8.8.7) id BAA03032;
Sat, 25 Oct 1997 01:03:26 -0700 (PDT)
Message-ID: <19971025010326.61185@hydrogen.nike.efn.org>
Date: Sat, 25 Oct 1997 01:03:26 -0700
From: John-Mark Gurney <gurney_j@efn.org>
To: FreeBSD Hackers <freebsd-hackers@freebsd.org>
Subject: ld and kld dependancies...
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
Reply-To: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
Organization: Cu Networking
X-Operating-System: FreeBSD 2.2.1-RELEASE i386
X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4
X-Files: The truth is out there
X-URL: http://resnet.uoregon.edu/~gurney_j/
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
well.. I was working on getting kld dependancies... and right now
my only problem is that when I'm creating the kld module with ld, it
will store the dependancy as <module> but when making sure that it
exists on the machine, it will search for lib<module>.a...
so, as far as I can see, we have a couple options:
a) hack ld to understand either raw names passed to -l, or our
own little idea of a kld module, like <module>.kld
b) get the kld code to do the conversion from <module> to
lib<module>.a, and just keep ld the same...
I'm leaning towards option a... perhaps a -Bkld which will turn on
-Bshareable and searching of <module>.kld? of course then there is the
matter of the search path...
right now the search path of the kernel kld code is limited to the
same directory that the original file was located... I don't see
that as much of a problem...
--
John-Mark Gurney Modem/FAX: +1 541 683 6954
Cu Networking
Live in Peace, destroy Micro$oft, support free software, run FreeBSD
From owner-freebsd-hackers Sat Oct 25 01:08:55 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id BAA21041
for hackers-outgoing; Sat, 25 Oct 1997 01:08:55 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA21035
for <freebsd-hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 01:08:50 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id RAA00531;
Sat, 25 Oct 1997 17:35:31 +0930 (CST)
Message-Id: <199710250805.RAA00531@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: ioctl() base command groups
In-reply-to: Your message of "Fri, 24 Oct 1997 15:12:48 MST."
<Pine.BSF.3.96.971024151138.1236A-100000@trojanhorse.ml.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 25 Oct 1997 17:35:29 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
>
> Are the groups used in the _IO* macros, which are usually a single
> character supposed to have some systematic system of assignment?
No, not really. They combine with the other attributes of the ioctl to
help make the code unique, but there's nothing magic about them.
mike
From owner-freebsd-hackers Sat Oct 25 01:29:16 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id BAA22126
for hackers-outgoing; Sat, 25 Oct 1997 01:29:16 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from dcarmich.pr.mcs.net (dcarmich.pr.mcs.net [204.95.63.202])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA22109;
Sat, 25 Oct 1997 01:29:08 -0700 (PDT)
(envelope-from dcarmich@dcarmich.pr.mcs.net)
Received: (from dcarmich@localhost)
by dcarmich.pr.mcs.net (8.8.7/8.8.7) id DAA00245;
Sat, 25 Oct 1997 03:28:38 -0500 (CDT)
(envelope-from dcarmich)
From: Douglas Carmichael <dcarmich@dcarmich.pr.mcs.net>
Message-Id: <199710250828.DAA00245@dcarmich.pr.mcs.net>
Subject: 2.2.5-RELEASE installs fine, but can't detect TI PCI-1130 CardBus controller
To: freebsd-hackers@freebsd.org, freebsd-mobile@freebsd.org
Date: Sat, 25 Oct 1997 03:28:37 -0500 (CDT)
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I installed the 2.2.5-RELEASE bindist and srcdist from ftp2.freebsd.org and
they installed fine over my existing 2.2.2-RELEASE/PAO-970616 system, but
2.2.5-RELEASE does not detect my NEC Versa 6050MH laptop's TI PCI-1130 CardBus
PCMCIA controller when 2.2.2-RELEASE correctly detected it.
Here's my kernel configuration file:
# My new kernel configuration (10/3/97)
machine "i386"
cpu "I586_CPU"
ident NECVERSA
maxusers 60
options INET #InterNETworking
options FFS #Berkeley Fast Filesystem
options MFS #Memory Filesystem
options PROCFS #Process filesystem
options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!]
options UCONSOLE #Allow users to grab the console
options SYSVSHM
options SYSVSEM
options SYSVMSG
# kernel tracing
options KTRACE
# laptop-specific configuration
options LAPTOP
# If your laptop have not had Windoze95-Ready BIOS, please update it.
# Such old BIOS'es sometimes have critical bugs at 32-bit protected
# mode APM BIOS interface (which have not used by Windoze 3.1).
# PC-card suspend/resume support (experimental)
options APM_PCCARD_RESUME
options PCIC_RESUME_RESET
# Keep power for serial cards when the system suspends
# (If your machine hangs up when you try to suspend the system with
# FAX/Modem PCMCIA card, uncomment this option).
#options SIO_SUSP_KEEP_PWR
# Detach SCSI devices when the SCSI card is removed
options SCSI_DETACH
# Don't suspend the system immediately before the system is resumed
# from suspended mode (Default 3 seconds)
options "APM_NOSUSPEND_IMMEDIATE=3"
config kernel root on wd0
controller isa0
controller pci0
controller crd0
device pcic0 at crd?
device pcic1 at crd?
controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr
disk fd0 at fdc0 drive 0
controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr
disk wd0 at wdc0 drive 0 flags 0x80ff
options ATAPI #Enable ATAPI support for IDE bus
options ATAPI_STATIC #Don't do it as an LKM
device wcd0 #IDE CD-ROM
device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr
device npx0 at isa? port "IO_NPX" irq 13 vector npxintr
#
# Laptop support (see LINT for more options)
#
device apm0 at isa? # Advanced Power Management
options APM_BROKEN_STATCLOCK # Workaround some buggy APM BIOS
device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr
device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr
device sio2 at isa? port "IO_COM3" tty irq 9 vector siointr
device lpt0 at isa? port? tty irq 7 vector lptintr
device psm0 at isa? port "IO_KBD" conflicts tty irq 12 vector psmintr
# Sound devices
controller snd0
device sb0 at isa? port 0x220 irq 5 drq 1 vector sbintr
options SBC_IRQ=5
device sbxvi0 at isa? drq 5
device sbmidi0 at isa? port 0x330
device opl0 at isa? port 0x388
# Order is important here due to intrusive probes, do *not* alphabetize
# this list of network interfaces until the probes have been fixed.
# Right now it appears that the ie0 must be probed before ep0. See
# revision 1.20 of this file.
pseudo-device loop
pseudo-device speaker
pseudo-device tun 2
pseudo-device pty 16
pseudo-device gzip # Exec gzipped a.out's
pseudo-device vn #Vnode driver (turns a file into a device)
And dmesg output:
Copyright (c) 1992-1997 FreeBSD Inc.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 2.2.5-RELEASE #0: Sat Oct 25 02:07:45 CDT 1997
dcarmich@dcarmich.pr.mcs.net:/usr/src/sys/compile/NECVERSA
CPU: Pentium (150.85-MHz 586-class CPU)
Origin = "GenuineIntel" Id = 0x544 Stepping=4
Features=0x8001bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8>
real memory = 50331648 (49152K bytes)
avail memory = 47636480 (46520K bytes)
Probing for devices on PCI bus 0:
chip0 <Intel 82437MX mobile PCI cache memory controller> rev 2 on pci0:0
chip1 <Intel 82371MX mobile PCI I/O IDE accelerator (MPIIX)> rev 3 on pci0:1
vga0 <VGA-compatible display device> rev 69 on pci0:2
chip2 <generic PCI bridge (vendor=104c device=ac12 subclass=7)> rev 4 int a irq ?? on pci0:3:0
chip3 <generic PCI bridge (vendor=104c device=ac12 subclass=7)> rev 4 int b irq ?? on pci0:3:1
Probing for devices on the ISA bus:
sc0 at 0x60-0x6f irq 1 on motherboard
sc0: VGA color <16 virtual consoles, flags=0x0>
pccard driver sio added
sio0 at 0x3f8-0x3ff irq 4 on isa
sio0: type 16550A
sio1 at 0x2f8-0x2ff irq 3 on isa
sio1: type 16550A
sio2 at 0x3e8-0x3ef irq 9 on isa
sio2: type 16550A
lpt0 at 0x378-0x37f irq 7 on isa
lpt0: Interrupt-driven port
lp0: TCP/IP capable interface
psm0 at 0x60-0x64 irq 12 on motherboard
psm0: device ID 0
fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1.44MB 3.5in
wdc0 at 0x1f0-0x1f7 irq 14 on isa
wdc0: unit 0 (wd0): <TOSHIBA MK1401MAV>, 32-bit, multi-block-16
wd0: 1376MB (2818368 sectors), 2796 cyls, 16 heads, 63 S/T, 512 B/S
npx0 on motherboard
npx0: INT 16 interface
apm0 on isa
apm: found APM BIOS version 1.1
sb0 at 0x220 irq 5 drq 1 on isa
sb0: <SoundBlaster 16 4.13>
sbxvi0 at 0x0 drq 5 on isa
sbxvi0: <SoundBlaster 16 4.13>
sbmidi0 at 0x330 on isa
<SoundBlaster MPU-401>
opl0 at 0x388 on isa
opl0: <Yamaha OPL-3 FM>
PC-Card VLSI 82C146 (5 mem & 2 I/O windows)
pcic: controller irq 10
What could be causing the problem? Is there a later PAO that I can use?
A prompt response would be appreciated.
From owner-freebsd-hackers Sat Oct 25 03:03:45 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id DAA25325
for hackers-outgoing; Sat, 25 Oct 1997 03:03:45 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from server.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA25320
for <hackers@FreeBSD.org>; Sat, 25 Oct 1997 03:03:41 -0700 (PDT)
(envelope-from perlsta@cs.sunyit.edu)
Received: from localhost (perlsta@localhost)
by server.local.sunyit.edu (8.8.7/8.8.5) with SMTP id GAA00595
for <hackers@FreeBSD.org>; Sat, 25 Oct 1997 06:08:36 -0500 (EST)
X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs
Date: Sat, 25 Oct 1997 06:08:36 -0500 (EST)
From: Alfred Perlstein <perlsta@cs.sunyit.edu>
X-Sender: perlsta@server.local.sunyit.edu
To: hackers@FreeBSD.org
Subject: help with buildworld 2.2-stable?
Message-ID: <Pine.BSF.3.96.971025060406.590A-100000@server.local.sunyit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk
i've been just cvs-up'd to the latest 2.2-stable from a -stable from a
month or so ago, i've been trying:
make -j8 buildworld
but it keeps bombing out with the error:
--- lstReplace.o ---
--- lstSucc.o ---
--- realinstall ---
--- lstReplace.o ---
cc -O -I/usr/src/usr.bin/make -I/usr/obj/usr/src/tmp/usr/include -c
/usr/src/usr.bin/make/lst.lib/lstReplace.c
--- lstSucc.o ---
cc -O -I/usr/src/usr.bin/make -I/usr/obj/usr/src/tmp/usr/include -c
/usr/src/usr.bin/make/lst.lib/lstSucc.c
--- realinstall ---
install -c -s -o bin -g bin -m 555 make /usr/obj/usr/src/tmp/usr/bin
install: make: No such file or directory
*** Error code 71
1 error
*** Error code 2
1 error
several questions:
1) am i doing the right thing to upgrade to a 2.2.5'ish system?
2) why does the compile fail? it seems to be make'ing "make" when this
happens
observation:
1) if i go into /usr/src/usr.bin/make and type 'make' then 'make install'
it seems to go off without a hitch...
please excuse my poor knowledge of make file structure if the problem
seems obvious...
thank you,
.________________________________________________________________________ __ _
|Alfred Perlstein - Programming & SysAdmin --"Have you seen my FreeBSD tatoo?"
|perlsta@sunyit.edu --"who was that masked admin?"
|http://www.cs.sunyit.edu/~perlsta
:
'
From owner-freebsd-hackers Sat Oct 25 04:04:36 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id EAA29091
for hackers-outgoing; Sat, 25 Oct 1997 04:04:36 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA29082;
Sat, 25 Oct 1997 04:04:11 -0700 (PDT)
(envelope-from se@X14.MI.Uni-Koeln.DE)
Received: from x14.mi.uni-koeln.de ([134.95.219.124])
by Octopussy.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id NAA14764;
Sat, 25 Oct 1997 13:04:08 +0200 (MET DST)
Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id AAA01511; Fri, 24 Oct 1997 00:02:29 +0200 (CEST)
X-Face: "<d]#=8pzx);RzeqSKI86OVa7=!0/(uRa.+B.9Z9\eNUn@UG?!`y7yt2dFNn%k4'.}](uE%
yCO)$e&Y1%3EO~ifu6Q-#YUM&JZ't,}JkPnAz,8Dj33u%@GBi%[Y#LHz$]h7a<p4)-jKI7~sKjlP-^
EvA[G;]v&0]W!EL%shs,{7x0|oqN4YVIs5,NI#,V{9"WF):5&RkOhyj*#-IAG}Tnu;YCF,d
Message-ID: <19971024000229.47394@mi.uni-koeln.de>
Date: Fri, 24 Oct 1997 00:02:29 +0200
From: Stefan Esser <se@FreeBSD.ORG>
To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
Cc: freebsd-hackers@FreeBSD.ORG, Stefan Esser <se@FreeBSD.ORG>
Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage
References: <19971021081759.TH50130@uriah.heep.sax.de> <199710220009.TAA18051@nospam.hiwaay.net> <19971022080341.HR59190@uriah.heep.sax.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84
In-Reply-To: <19971022080341.HR59190@uriah.heep.sax.de>; from J Wunsch on Wed, Oct 22, 1997 at 08:03:41AM +0200
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On 1997-10-22 08:03 +0200, J Wunsch <j@uriah.heep.sax.de> wrote:
> As dkelly@hiwaay.net wrote:
>
> > Went back and RTFM'ed my Asus SC875 manual and obsverved on page 11
> > the default Synchronous Transfer Rate (MS/Sec) (sic) is 20. So is this MB/
> > sec or MHz?
>
> MHz. Together with the 16-bit bus, it makes a theoretical maximum of
> 40 MB/s (minus transaction overhead which is, as Stefan mentioned, not
> neglicible).
The theoretical maximum is 40,000,000 bytes per second,
or 38.1 * 1024*1024 bytes per second (== 38.1 MB/s).
This would still allow for some 600 transfers of 64KB
each.
Fast drives offer a command overhead of some 50us with
a fast controller. If the bus is to be saturated, and the
maximum transfer length is 64KB, then the overhead is at
least some 30ms per second, or 3%.
We get a maximum net data rate of some 36.9MB/s, under
those assumptions.
Regards, STefan
From owner-freebsd-hackers Sat Oct 25 04:05:09 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id EAA29141
for hackers-outgoing; Sat, 25 Oct 1997 04:05:09 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA29131
for <freebsd-hackers@freebsd.org>; Sat, 25 Oct 1997 04:05:05 -0700 (PDT)
(envelope-from se@X14.MI.Uni-Koeln.DE)
Received: from x14.mi.uni-koeln.de ([134.95.219.124])
by Octopussy.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id NAA14784
for <freebsd-hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 13:05:02 +0200 (MET DST)
Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id KAA00722; Sat, 25 Oct 1997 10:35:22 +0200 (CEST)
X-Face: "<d]#=8pzx);RzeqSKI86OVa7=!0/(uRa.+B.9Z9\eNUn@UG?!`y7yt2dFNn%k4'.}](uE%
yCO)$e&Y1%3EO~ifu6Q-#YUM&JZ't,}JkPnAz,8Dj33u%@GBi%[Y#LHz$]h7a<p4)-jKI7~sKjlP-^
EvA[G;]v&0]W!EL%shs,{7x0|oqN4YVIs5,NI#,V{9"WF):5&RkOhyj*#-IAG}Tnu;YCF,d
Message-ID: <19971025103522.51922@mi.uni-koeln.de>
Date: Sat, 25 Oct 1997 10:35:22 +0200
From: Stefan Esser <se@FreeBSD.ORG>
To: Don Lewis <Don.Lewis@tsc.tdk.com>
Cc: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>, freebsd-hackers@FreeBSD.ORG
Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage
References: <se@FreeBSD.ORG> <199710212347.QAA09208@salsa.gv.tsc.tdk.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84
In-Reply-To: <199710212347.QAA09208@salsa.gv.tsc.tdk.com>; from Don Lewis on Tue, Oct 21, 1997 at 04:47:42PM -0700
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On 1997-10-21 16:47 -0700, Don Lewis <Don.Lewis@tsc.tdk.com> wrote:
> On Oct 22, 12:13am, Stefan Esser wrote:
> } > > > sd0(ncr0:0:0): WIDE SCSI (16 bit) enabled
> } > > > sd0(ncr0:0:0): 20.0 MB/s (100 ns, offset 16)
> } If 40MB/s is reported, you still won't be able to get
> } more than some 37MB/s moved, actually, but well, it is
> } the number claimed by the drive and controller vendors,
> } and so it can't be wrong to report it :)
>
> But isn't this misleading if it's only connected to narrow devices?
Sure, it was, if that number was printed for a narrow device.
But it of course isn't: This is a per device message, and a
narrow device would have 20MB/s in its attach message (while
actually being limited to some 18.5MB/s).
Regards, STefan
From owner-freebsd-hackers Sat Oct 25 04:05:43 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id EAA29177
for hackers-outgoing; Sat, 25 Oct 1997 04:05:43 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA29171
for <freebsd-hackers@freebsd.org>; Sat, 25 Oct 1997 04:05:39 -0700 (PDT)
(envelope-from se@X14.MI.Uni-Koeln.DE)
Received: from x14.mi.uni-koeln.de ([134.95.219.124])
by Octopussy.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id NAA14757;
Sat, 25 Oct 1997 13:04:04 +0200 (MET DST)
Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id LAA00954; Sat, 25 Oct 1997 11:15:40 +0200 (CEST)
X-Face: "<d]#=8pzx);RzeqSKI86OVa7=!0/(uRa.+B.9Z9\eNUn@UG?!`y7yt2dFNn%k4'.}](uE%
yCO)$e&Y1%3EO~ifu6Q-#YUM&JZ't,}JkPnAz,8Dj33u%@GBi%[Y#LHz$]h7a<p4)-jKI7~sKjlP-^
EvA[G;]v&0]W!EL%shs,{7x0|oqN4YVIs5,NI#,V{9"WF):5&RkOhyj*#-IAG}Tnu;YCF,d
Message-ID: <19971025111540.12105@mi.uni-koeln.de>
Date: Sat, 25 Oct 1997 11:15:40 +0200
From: Stefan Esser <se@FreeBSD.ORG>
To: dkelly@hiwaay.net
Cc: Joe McGuckin <joe@via.net>, freebsd-hackers@FreeBSD.ORG
Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage
References: <joe@via.net> <199710210124.UAA14405@nospam.hiwaay.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84
In-Reply-To: <199710210124.UAA14405@nospam.hiwaay.net>; from dkelly@hiwaay.net on Mon, Oct 20, 1997 at 08:24:34PM -0500
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On 1997-10-20 20:24 -0500, dkelly@hiwaay.net wrote:
> ncr0 <ncr 53c875 fast20 wide scsi> rev 3 int a irq 11 on pci0:11
> ncr0 waiting for scsi devices to settle
> (ncr0:0:0): WIDE SCSI (16 bit) enabled(ncr0:0:0): 10.0 MB/s (200 ns, offset 15)
> (ncr0:0:0): "IBM OEM DCHS09W 2222" type 0 fixed SCSI 2
> sd1(ncr0:0:0): Direct-Access
> sd1(ncr0:0:0): WIDE SCSI (16 bit) enabled
> sd1(ncr0:0:0): 20.0 MB/s (100 ns, offset 15)
> 8689MB (17796077 512 byte sectors)
This is correct for the non-Ultra version of the NCR driver
(as of 2.2-stable before September 8, 1997).
> Am mildly concerned about the 10.0 MB/s message that starts it off. And I'm
No reason to worry!
The IBM drives have certain specific features, and their
active request for negotiation of a synchronous data rate
is one of them. The driver does not know anything about
the drive, when it initiates the negotiation, and will
not go beyond 5MHz, at that stage.
After the INQUIRY returned the drive name and features,
and after the quirks code had a chance to limit what the
driver will agree on, the driver initiates a negotiation
and the final synchronous transfer parameters are agreed
on.
> thinking about the whole issue because I'm not certian my performance is up
> to snuff. Using bonnie:
>
> IBM OEM DCHS09W on Asus SC875, new & empty 2.4G filesystem at end of disk:
> -------Sequential Output-------- ---Sequential Input-- --Random--
> -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
> MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
> 100 3972 41.8 3986 14.6 2234 7.5 6700 76.3 8228 16.4 108.4 2.6
> ^^^^ this seems low
This IS low!
Seems your drive does not signal early command completion
on writes, even if tags are used (or did you disable tags ?)
What's the state of the WCE bit in mode page 8 ?
# scsi -f /dev/sd0 -m 8
WCE: 1
[ ... having read further down, I see you DTRT WRT WCE ... ]
But your other Bonnie numbers seem odd, too. Or was there
much other activity on that system at the time of the test ?
The "per char" input rate should only be limited by available
CPU cycles, or the data rate should be no lower than in the
"block" input case.
Having the file system at the end of the disk does of course
affect performance.
> SEAGATE ST32550N on Adaptec 2940 (AIC-7870) old 86% full 1.8G fs
> -------Sequential Output-------- ---Sequential Input-- --Random--
> -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
> MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
> 100 3980 43.2 4402 13.9 1774 5.0 4260 48.3 3759 5.7 71.5 1.5
>
> System is an Asus P6NP5 PPro-166/512k 32M RAM.
>
> # scsi -f /dev/rsd1c -m 8 -P 3
> WCE: 0
> Observed the Seagate had the WCE set (Write Cache Enable) so I did the same
> for the IBM.
>
> Flipped the WCE bit from 0 to 1 and got this on the IBM (last fs):
> -------Sequential Output-------- ---Sequential Input-- --Random--
> -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
> MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
> 100 7402 76.5 7927 31.0 2311 7.8 6587 75.2 8207 16.2 110.3 2.5
> ^^^^ ^^^^ both of these are *much* better.
With an assumed data rate of near 8MB/s and a 64KB transfer,
you wrote 64KB in 8ms. Since Bonnie could not issue the next
command in time, one revolution of the media (8.3ms) was lost,
and the actual peformance was near 64KB/16ms or 4MB/s.
> After enabling the write cache, this drive is comparable to the new Seagate
> 4.3G Barracuda on an Adaptec 2940AU (AIC-7860) and P-133 I'm playing with
> at work:
> -------Sequential Output-------- ---Sequential Input-- --Random--
> -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
> MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
> 100 3653 75.6 8523 36.4 2293 15.9 3595 70.6 9183 38.4 92.2 4.3
This is obviously a file system on the outer tracks (or only
a few hundred MB offset from the start of the disk).
> It really bugged me that my UW HD on PentiumPro was being beat by a P-133
> with narrow SCSI. Then I began to wonder if there was a difference between
Well, I beat most people's Bonnie results with my 486/133 and
a 2GB Quantum Atlas connected to a NCR 53c810 for quite a while :)
> inner and outer tracks. This fs starts about 200M past block 0, while the
> above (up 2, the IBM) starts 2.4G from the end of the disk:
> -------Sequential Output-------- ---Sequential Input-- --Random--
> -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
> MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
> 100 8098 79.7 9385 38.3 2758 9.2 6426 74.0 9772 20.1 111.2 2.5
>
> ...and that's more like it!
Yes, it definitely is ... ;)
Regards, STefan
From owner-freebsd-hackers Sat Oct 25 07:22:43 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id HAA04845
for hackers-outgoing; Sat, 25 Oct 1997 07:22:43 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA04840
for <freebsd-hackers@freebsd.org>; Sat, 25 Oct 1997 07:22:39 -0700 (PDT)
(envelope-from se@X14.MI.Uni-Koeln.DE)
Received: from x14.mi.uni-koeln.de ([134.95.219.124])
by Octopussy.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id QAA15923;
Sat, 25 Oct 1997 16:22:33 +0200 (MET DST)
Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id OAA01064; Sat, 25 Oct 1997 14:03:01 +0200 (CEST)
X-Face: "<d]#=8pzx);RzeqSKI86OVa7=!0/(uRa.+B.9Z9\eNUn@UG?!`y7yt2dFNn%k4'.}](uE%
yCO)$e&Y1%3EO~ifu6Q-#YUM&JZ't,}JkPnAz,8Dj33u%@GBi%[Y#LHz$]h7a<p4)-jKI7~sKjlP-^
EvA[G;]v&0]W!EL%shs,{7x0|oqN4YVIs5,NI#,V{9"WF):5&RkOhyj*#-IAG}Tnu;YCF,d
Message-ID: <19971025140301.61013@mi.uni-koeln.de>
Date: Sat, 25 Oct 1997 14:03:01 +0200
From: Stefan Esser <se@FreeBSD.ORG>
To: Neil Ludban <n-ludban@onu.edu>
Cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: ncr53c875j under FreeBSD-2.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On 1997-10-19 22:58 -0400, Neil Ludban <n-ludban@onu.edu> wrote:
> Hello,
>
> I've ruled out everything I could think of on this problem, and what's
> left points to a question about the ncr driver for -hackers.
>
> I'm trying to get FreeBSD 2.2.2-RELEASE to recognize a Diamond FirePort40
> SCSI adapter, which uses the NCR 53c875j chip. A borrowed Asus PCI-SC875
> is recognized correctly on the same system (53c875 chip, no j). I looked
> through the ncr code and found the identification numbers for different
> chip numbers, but didn't see anything about the 875j or even different
> revisions of other chips.
Sorry, Symbios used a different PCI chip ID for the J version
of the 875, for reasons I do not really understand, but did not
mention this in the 875 data book. The driver was fixed to accept
both chip IDs (there is no difference between the two, as far as
the NCR driver is concerned). But this was too late for 2.2.2 ...
> Can anyone tell me if this should already work (I got a bad card, or a
> messed up BIOS), or explain where to start to add support? According to
> Symbios' web site, the j suffix means it "supports JTAG boundary scan for
> onboard testing." I assume that if the current driver were to recognize
> it, it would act like a plain 875, which would be good enough for me.
It does and it is :)
> A possibly related problem is that having both SCSI cards installed at
> once, or the Asus with a PCI NIC (ed2, RealTek 8029) causes the boot to
> hang after the imasks line. The next thing should have been the BIOS
> disk geometries. FWIW, the geometry of the SCSI disk is correct for
> either controller.
Hmmm, that's strange. I'm using two NCR SCSI chips and a RealTek
8029 based Ethernet card in my system, too ...
My guess is, that there is an IRQ conflict between PCI and ISA.
Could verify, that none of the IRQs printed for the PCI cards is
configured for one of your ISA cards, too. I do not know anything
about your PCI BIOS (whether it dynamically assigns interrupts to
PCI slots, for example), but assume some kind of configuration
problem exists.
> pci0:12: NCR/Symbios, device=0x008f, class=storage (scsi) int a irq 11
> [no driver assigned]
Just replace the line reading:
#define NCR_875_ID (0x000f1000ul)
by:
#define NCR_875_ID (0x008f1000ul)
and rebuild your kernel.
But this will make the driver ignore the non-J version of the 875.
The drivers in 2.2-stable and -current have been fixed to accept
both PCI IDs for quite some time, so you may want to upgrade, if
you need one kernel that supports both at a time.
Regards, STefan
From owner-freebsd-hackers Sat Oct 25 09:08:25 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id JAA08702
for hackers-outgoing; Sat, 25 Oct 1997 09:08:25 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from burka.carrier.kiev.ua (root@burka.carrier.kiev.ua [193.193.193.107])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA08638
for <hackers@freebsd.org>; Sat, 25 Oct 1997 09:07:54 -0700 (PDT)
(envelope-from archer@grape.carrier.kiev.ua)
Received: from sivka.carrier.kiev.ua (root@sivka.carrier.kiev.ua [193.193.193.101])
by burka.carrier.kiev.ua (8.8.6/8.8.6) with ESMTP id TAA18815
for <hackers@freebsd.org>;
Sat, 25 Oct 1997 19:07:24 +0300 (EEST)
Received: (from uucp@localhost)
by sivka.carrier.kiev.ua (8.8.7/8.8.7) with UUCP id TAA26527
for hackers@freebsd.org; Sat, 25 Oct 1997 19:02:50 +0300 (EEST)
Received: (from archer@localhost)
by grape.carrier.kiev.ua (8.8.7/8.8.7) id SAA11255;
Sat, 25 Oct 1997 18:49:23 +0300 (EEST)
Date: Sat, 25 Oct 1997 18:49:23 +0300 (EEST)
From: Alexander Litvin <archer@lucky.net>
Message-Id: <199710251549.SAA11255@grape.carrier.kiev.ua>
To: hackers@freebsd.org
Subject: Re: de0 errors
In-Reply-To: <henrich@crh.cl.msu.edu> <199710230955.CAA13696@salsa.gv.tsc.tdk.com> <19971023112105.56949@crh.cl.msu.edu>
X-Newsreader: TIN [UNIX 1.3 unoff BETA 970424; i386 FreeBSD 2.2.5-971010-BETA]
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
I experience the same.
No problem it would be, but with that card the box also seems
to lockup after a while :( It is our proxy server, quite busy
(about 30000 requests per hour), and I don't have opportunity
to investigate it in details, but after installation of DE it
locked up two times during one hour, so I decided to put back
PCI ed.
All that on 2.2.5, 266MHz P-II, Intel LX chipset.
In article <19971023112105.56949@crh.cl.msu.edu> you wrote:
> On the subject of Re: de0 errors, Don Lewis stated:
> > packets will be sent, but your card may not be operating as efficiently
> > as possible.
> >
> > What speed is your network (10Mb or 100Mb)? What speed does the de driver
> > think it's running at? What kind of card do you have?
> Its a 100mbit network, the card thinks its a 100mbit network.
> de0 <Digital 21140 Fast Ethernet> rev 18 int a irq 9 on pci0:20
> de0: SMC 9332DST 21140 [10-100Mb/s] pass 1.2
> de0: address 00:00:c0:9e:ba:c7
> de0: enabling 100baseTX port
> de0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> inet 35.8.2.20 netmask 0xfff80000 broadcast 35.15.255.255
> ether 00:00:c0:9e:ba:c7
> media: 100baseTX status: active
> -Crh
> Charles Henrich Michigan State University henrich@msu.edu
> http://pilot.msu.edu/~henrich
--
Litvin Alexander
"Real Programs dump Core"
From owner-freebsd-hackers Sat Oct 25 10:35:50 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id KAA12460
for hackers-outgoing; Sat, 25 Oct 1997 10:35:50 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA12440;
Sat, 25 Oct 1997 10:35:44 -0700 (PDT)
(envelope-from nate@rocky.mt.sri.com)
Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100])
by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id LAA28680;
Sat, 25 Oct 1997 11:35:42 -0600 (MDT)
Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id LAA24441; Sat, 25 Oct 1997 11:35:41 -0600 (MDT)
Date: Sat, 25 Oct 1997 11:35:41 -0600 (MDT)
Message-Id: <199710251735.LAA24441@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: Douglas Carmichael <dcarmich@dcarmich.pr.mcs.net>
Cc: freebsd-hackers@freebsd.org, freebsd-mobile@freebsd.org
Subject: Re: 2.2.5-RELEASE installs fine, but can't detect TI PCI-1130 CardBus controller
In-Reply-To: <199710250828.DAA00245@dcarmich.pr.mcs.net>
References: <199710250828.DAA00245@dcarmich.pr.mcs.net>
X-Mailer: VM 6.29 under 19.15 XEmacs Lucid
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> I installed the 2.2.5-RELEASE bindist and srcdist from
> ftp2.freebsd.org and they installed fine over my existing
> 2.2.2-RELEASE/PAO-970616 system, but 2.2.5-RELEASE does not detect my
> NEC Versa 6050MH laptop's TI PCI-1130 CardBus PCMCIA controller when
> 2.2.2-RELEASE correctly detected it.
^^^^^^^^^^^^^
There have been *NO* changes from 2.2.2 -> 2.2.5 in the pccard code, so
I'm pretty sure that 2.2.2 never detected your controller w/out the PAO
patches. And, there isn't (yet?) a PAO release for 2.2.5, so you'll
have to wait until one is made, or port the patches from PAO to 2.2.5.
But, I'm confused:
> And dmesg output:
> Copyright (c) 1992-1997 FreeBSD Inc.
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California. All rights reserved.
>
> FreeBSD 2.2.5-RELEASE #0: Sat Oct 25 02:07:45 CDT 1997
> dcarmich@dcarmich.pr.mcs.net:/usr/src/sys/compile/NECVERSA
...
> PC-Card VLSI 82C146 (5 mem & 2 I/O windows)
> pcic: controller irq 10
It certainly looks like your controller is found to me.
Nate
From owner-freebsd-hackers Sat Oct 25 11:56:17 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id LAA16076
for hackers-outgoing; Sat, 25 Oct 1997 11:56:17 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA16071
for <freebsd-hackers@freebsd.org>; Sat, 25 Oct 1997 11:56:14 -0700 (PDT)
(envelope-from jamil@trojanhorse.ml.org)
Received: from localhost (jamil@localhost)
by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id LAA00178
for <freebsd-hackers@freebsd.org>; Sat, 25 Oct 1997 11:55:34 -0700 (PDT)
Date: Sat, 25 Oct 1997 11:55:34 -0700 (PDT)
From: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
To: freebsd-hackers@freebsd.org
Subject: Parity Ram
Message-ID: <Pine.BSF.3.96.971025115335.173A-100000@trojanhorse.ml.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Can someone fill me in on when you would want to use parity ram as opposed
to non-parity ram these days? If there was some anomaly in memory how
would freebsd handle it (is there a trap for parity error?)
From owner-freebsd-hackers Sat Oct 25 12:33:49 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id MAA17653
for hackers-outgoing; Sat, 25 Oct 1997 12:33:49 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from isgate.is (isgate.is [193.4.58.51])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA17642
for <freebsd-hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 12:33:45 -0700 (PDT)
(envelope-from totii@est.is)
Received: from eh.est.is (eh.est.is [194.144.208.34]) by isgate.is (8.7.5-M/) with ESMTP id TAA29704; Sat, 25 Oct 1997 19:32:23 GMT
Received: from didda.est.is (totii@ppp-22.est.is [194.144.208.122])
by eh.est.is (8.8.5/8.8.5) with SMTP id TAA20876;
Sat, 25 Oct 1997 19:30:53 GMT
Message-ID: <34524948.41C67EA6@est.is>
Date: Sat, 25 Oct 1997 19:32:24 +0000
From: =?iso-8859-1?Q?=DEor=F0ur?= Ivarsson <totii@est.is>
X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386)
MIME-Version: 1.0
To: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
CC: freebsd-hackers@FreeBSD.ORG
Subject: Re: Parity Ram
References: <Pine.BSF.3.96.971025115335.173A-100000@trojanhorse.ml.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Jamil J. Weatherbee wrote:
>
> Can someone fill me in on when you would want to use parity ram as opposed
> to non-parity ram these days? If there was some anomaly in memory how
> would freebsd handle it (is there a trap for parity error?)
As far as I know, the 'parity check fail' is connected to NMI of CPU.
In most cases the BIOS rutines accept this and halt the computer with no
information on where or why , only something like 'NMI detected, system
halted' or
'Memory parity fail - NMI generated , system halted'.
The only reason for this might be giving you some warning of failed
memory rather
than failed software.
This has helped me several times when I was suspecting broken memory in
the old days (90-93) :-)
Thordur Ivarsson
From owner-freebsd-hackers Sat Oct 25 12:43:09 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id MAA18150
for hackers-outgoing; Sat, 25 Oct 1997 12:43:09 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA18133;
Sat, 25 Oct 1997 12:42:57 -0700 (PDT)
(envelope-from dkelly@nospam.hiwaay.net)
Received: from nospam.hiwaay.net (max7-198.HiWAAY.net [208.147.145.198])
by fly.HiWAAY.net (8.8.7/8.8.6) with ESMTP id OAA29225;
Sat, 25 Oct 1997 14:42:51 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
by nospam.hiwaay.net (8.8.7/8.8.4) with ESMTP
id NAA08387; Sat, 25 Oct 1997 13:31:47 -0500 (CDT)
Message-Id: <199710251831.NAA08387@nospam.hiwaay.net>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Stefan Esser <se@FreeBSD.ORG>
cc: freebsd-hackers@FreeBSD.ORG
From: dkelly@HiWAAY.net
Subject: Re: ncr53c875j under FreeBSD-2.2.2
In-reply-to: Message from Stefan Esser <se@FreeBSD.ORG>
of "Sat, 25 Oct 1997 14:03:01 +0200." <19971025140301.61013@mi.uni-koeln.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 25 Oct 1997 13:31:46 -0500
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Stefan Esser said:
>
> My guess is, that there is an IRQ conflict between PCI and ISA. Could
> verify, that none of the IRQs printed for the PCI cards is configured
> for one of your ISA cards, too. I do not know anything about your PCI
> BIOS (whether it dynamically assigns interrupts to PCI slots, for
> example), but assume some kind of configuration problem exists.
Is it OK for PCI cards to share the same IRQ? I was thinking my Asus
SC875 and IBM DCHS-39100 were not performing up to par and found it on
IRQ 9, also the 2940 and Mach32 were all on IRQ 9. Now the performance
is up to expectations after I discovered write buffering was not
enabled on the DCHS.
--
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 Oct 25 13:06:04 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id NAA19053
for hackers-outgoing; Sat, 25 Oct 1997 13:06:04 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA19043
for <hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 13:05:59 -0700 (PDT)
(envelope-from jak@cetlink.net)
Received: from ts1-cltnc-30-s19.cetlink.net (ts1-cltnc-30-s19.cetlink.net [209.54.58.30])
by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id QAA29372;
Sat, 25 Oct 1997 16:05:37 -0400 (EDT)
From: jak@cetlink.net (John Kelly)
To: dwhite@resnet.uoregon.edu
To: hackers@FreeBSD.ORG
Subject: Re: 48 meg double fault moved to 64 meg in 2.2.5
Date: Sat, 25 Oct 1997 14:24:29 -0400
Message-ID: <dljU0Y9zBc5e091yn@cetlink.net>
In-Reply-To: <Pine.BSF.3.96.971024211126.7229B-100000@gdi.uoregon.edu>
Lines: 77
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Doug White <dwhite@gdi.uoregon.edu> wrote:
>> I have extra parts to build a third machine identical to the
>> configuration which shows the problem.
>Keep us posted. If you find anything consistent, you should send
>it using send-pr and maybe followup to hackers@freebsd.org.
The problem does occur with no SCSI present -- just the motherboard
and a video card. When testing it this way, I had to use the floppy
controller on the motherboard instead of the faster one on the
Buslogic SCSI card. That seems to rule out either floppy controller
as a cause of the problem.
I found a CMOS option called "DRAM Hole for UNIX(64MB)" which I
enabled to see what would happen.
With 64 meg and 2.2.5, the problem disappeared. But with 48 meg
and 2.2.2 it had no effect, and the double fault still occurred.
I'm guessing that's because the BIOS does not try to create that
DRAM hole unless you fill the board with 64 meg of memory -- as
they do say in parentheses "(64MB)."
Unfortunately, I can't keep the "DRAM hole" enabled, because
after a reboot the memory test fails, and the only cure is the
hardware reset button. Even if I could leave it enabled, it's
of no help at all with 48 meg and the 2.2.2 boot floppy.
The memory test failure after a reboot may happen because this
motherboard does not have address line 26 wired to the chipset,
and thus anything over 64 meg cannot be addressed properly.
Presumably, to create the "DRAM hole," the BIOS remaps some
memory from below the 64 meg line to above 64 meg, and once it's
put there, it can no longer be seen, since A26 is unusable --
at least not by the chipset (although A26 is wired between the
CPU and the local bus).
I learned about the A26 problem on this motherboard when I tried
using the linear addressing feature of XFree86 with my Cirrus
5430 video card. Although the video card tries to use the A26
line to remap its memory above the 64 meg line, the motherboard
could not handle it. The XFree docs have a good explanation of
this situation in X11R6/lib/X11/doc/README.cirrus.
But as for the motherboard and the boot floppy problem, I don't
understand the purpose of the "DRAM hole for UNIX," although it
clearly does have a positive effect on the boot floppy problem
when it's activated with 64 meg in the machine.
Is it true that this problem only occurs with the boot floppy?
The last good message I see with the 2.2.2 boot floppy and 48
meg is "changing root device to fd0c," and then immediately the
"panic: double fault" appears.
Since floppy controllers use DMA, perhaps DMA and the bounce
buffers are an issue? Addressing memory remapped above 64 meg
may also be part of the problem, at least on this motherboard.
I did find an interesting tidbit in Messmer's "Indispensable
PC Hardware Book" (second edition). On page 621 he says:
"DMA transfer is not a trivial job, especially
when paging is enabled, even for the operating
system ... as the DMA controller overwrites the
physical memory contents mercilessly without any
care for the protection mechanisms of the protected
mode ... an incorrectly initialized DMA chip may ...
crash ... the complete computer system."
Hmmm... sounds familiar.
Oh well, I've reached the limits of my knowledge in these areas.
I hope my report is of some help to the experts.
John
From owner-freebsd-hackers Sat Oct 25 13:17:52 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id NAA19850
for hackers-outgoing; Sat, 25 Oct 1997 13:17:52 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from earth.mat.net (root@earth.mat.net [206.246.122.2])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA19845
for <freebsd-hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 13:17:49 -0700 (PDT)
(envelope-from chuckr@glue.umd.edu)
Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by earth.mat.net (8.8.7/8.6.12) with SMTP id QAA29210; Sat, 25 Oct 1997 16:17:07 -0400 (EDT)
Date: Sat, 25 Oct 1997 15:16:26 -0400 (EDT)
From: Chuck Robey <chuckr@glue.umd.edu>
X-Sender: chuckr@picnic.mat.net
To: =?iso-8859-1?Q?=DEor=F0ur?= Ivarsson <totii@est.is>
cc: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>,
freebsd-hackers@FreeBSD.ORG
Subject: Re: Parity Ram
In-Reply-To: <34524948.41C67EA6@est.is>
Message-ID: <Pine.BSF.3.96.971025151431.21591L-100000@picnic.mat.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id NAA19846
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Sat, 25 Oct 1997, Þorður Ivarsson wrote:
> Jamil J. Weatherbee wrote:
> >
> > Can someone fill me in on when you would want to use parity ram as opposed
> > to non-parity ram these days? If there was some anomaly in memory how
> > would freebsd handle it (is there a trap for parity error?)
>
> As far as I know, the 'parity check fail' is connected to NMI of CPU.
> In most cases the BIOS rutines accept this and halt the computer with no
> information on where or why , only something like 'NMI detected, system
> halted' or
> 'Memory parity fail - NMI generated , system halted'.
Huh ? BIOS routines? What's that got to do with FreeBSD? We don't use
the BIOS routines, they don't get called at all, right? If there's a
parity violation, if that's wired to NMI, then the NMI get's called, but
what that does is determined by FreeBSD, not your BIOS.
>
> The only reason for this might be giving you some warning of failed
> memory rather
> than failed software.
>
> This has helped me several times when I was suspecting broken memory in
> the old days (90-93) :-)
>
> Thordur Ivarsson
>
>
----------------------------+-----------------------------------------------
Chuck Robey | Interests include any kind of voice or data
chuckr@glue.umd.edu | communications topic, C programming, and Unix.
213 Lakeside Drive Apt T-1 |
Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD
(301) 220-2114 | version 3.0 current -- and great FUN!
----------------------------+-----------------------------------------------
From owner-freebsd-hackers Sat Oct 25 13:28:10 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id NAA20576
for hackers-outgoing; Sat, 25 Oct 1997 13:28:10 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA20565
for <freebsd-hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 13:28:06 -0700 (PDT)
(envelope-from sthaug@nethelp.no)
From: sthaug@nethelp.no
Received: (qmail 23834 invoked by uid 1001); 25 Oct 1997 20:28:01 +0000 (GMT)
To: jamil@trojanhorse.ml.org
Cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: Parity Ram
In-Reply-To: Your message of "Sat, 25 Oct 1997 11:55:34 -0700 (PDT)"
References: <Pine.BSF.3.96.971025115335.173A-100000@trojanhorse.ml.org>
X-Mailer: Mew version 1.05+ on Emacs 19.28.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Sat, 25 Oct 1997 22:28:01 +0200
Message-ID: <23832.877811281@verdi.nethelp.no>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> Can someone fill me in on when you would want to use parity ram as opposed
> to non-parity ram these days?
To avoid silently corrupting your data?
> If there was some anomaly in memory how
> would freebsd handle it (is there a trap for parity error?)
If you have a decent chipset (eg. 430HX, 440FX) parity memory can actually
give you single bit error correction, and double bit error detection. This
is actually quite a bit better than straight parity.
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
From owner-freebsd-hackers Sat Oct 25 13:31:02 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id NAA20844
for hackers-outgoing; Sat, 25 Oct 1997 13:31:02 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from fallout.campusview.indiana.edu (fallout.campusview.indiana.edu [149.159.1.1])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA20838
for <freebsd-hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 13:30:59 -0700 (PDT)
(envelope-from jfieber@indiana.edu)
Received: from localhost (jfieber@localhost)
by fallout.campusview.indiana.edu (8.8.7/8.8.7) with SMTP id PAA18625;
Sat, 25 Oct 1997 15:30:57 -0500 (EST)
Date: Sat, 25 Oct 1997 15:30:57 -0500 (EST)
From: John Fieber <jfieber@indiana.edu>
To: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: Parity Ram
In-Reply-To: <Pine.BSF.3.96.971025115335.173A-100000@trojanhorse.ml.org>
Message-ID: <Pine.BSF.3.96.971025152749.18619A-100000@fallout.campusview.indiana.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Sat, 25 Oct 1997, Jamil J. Weatherbee wrote:
> Can someone fill me in on when you would want to use parity ram as opposed
> to non-parity ram these days?
So when your memory fails, you know it was a memory failure
rather than an irreproducable software bug. Also, with
appropriate BIOS support, you can get not only error detection,
but some error correction capability.
My question is why would anybody want to use non-parity ram?
-john
From owner-freebsd-hackers Sat Oct 25 13:59:10 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id NAA23218
for hackers-outgoing; Sat, 25 Oct 1997 13:59:10 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from misery.sdf.com (misery.sdf.com [204.244.210.193])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA23206
for <freebsd-hackers@freebsd.org>; Sat, 25 Oct 1997 13:59:06 -0700 (PDT)
(envelope-from tom@sdf.com)
Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1)
id 0xPDH4-0006F2-00; Sat, 25 Oct 1997 13:57:35 -0700
Date: Sat, 25 Oct 1997 13:57:34 -0700 (PDT)
From: Tom <tom@sdf.com>
To: freebsd-hackers@freebsd.org
Subject: Re: Parity Ram
In-Reply-To: <Pine.BSF.3.96.971025115335.173A-100000@trojanhorse.ml.org>
Message-ID: <Pine.BSF.3.95q.971025134740.23973A-100000@misery.sdf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
On Sat, 25 Oct 1997, Jamil J. Weatherbee wrote:
> Can someone fill me in on when you would want to use parity ram as opposed
Why? To discover memory problems before they corrupt data, and cause
random panics, core dumps, hangs, or file system corruption. Personally,
I use ECC capable motherboards that can actually use parity to fix some
errors.
> to non-parity ram these days? If there was some anomaly in memory how
> would freebsd handle it (is there a trap for parity error?)
These days? RAM can fail. Nothing has changed in the last 10 years.
I've bought about a gig of RAM in the last couple of months, a good
percentage of SIMMs still arrive DOA.
FreeBSD systems simple reboot upon parity errors. This is pretty safe
thing to do. Much better than what a non-parity system would at this
point (ex. corrupt your filesystems). A smarter thing to do, might be to
simple stop the process owning the memory that failed, and flag the area
as unusable (NT does this). Doesn't help much if kernel is in the bad
memory area though.
Tom
From owner-freebsd-hackers Sat Oct 25 14:00:13 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA23360
for hackers-outgoing; Sat, 25 Oct 1997 14:00:13 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA23353
for <hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 14:00:08 -0700 (PDT)
(envelope-from jkh@time.cdrom.com)
Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id NAA18149; Sat, 25 Oct 1997 13:59:50 -0700 (PDT)
To: jak@cetlink.net (John Kelly)
cc: dwhite@resnet.uoregon.edu, hackers@FreeBSD.ORG
Subject: Re: 48 meg double fault moved to 64 meg in 2.2.5
In-reply-to: Your message of "Sat, 25 Oct 1997 14:24:29 EDT."
<dljU0Y9zBc5e091yn@cetlink.net>
Date: Sat, 25 Oct 1997 13:59:50 -0700
Message-ID: <18145.877813190@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> With 64 meg and 2.2.5, the problem disappeared. But with 48 meg
> and 2.2.2 it had no effect, and the double fault still occurred.
> I'm guessing that's because the BIOS does not try to create that
> DRAM hole unless you fill the board with 64 meg of memory -- as
> they do say in parentheses "(64MB)."
Hmmm. Bizarre. Ick.
> The memory test failure after a reboot may happen because this
> motherboard does not have address line 26 wired to the chipset,
> and thus anything over 64 meg cannot be addressed properly.
You know, christmas is coming up and a new Tyan motherboard would
probably not be that expensive. ;-)
> Is it true that this problem only occurs with the boot floppy?
Correct.
> The last good message I see with the 2.2.2 boot floppy and 48
> meg is "changing root device to fd0c," and then immediately the
> "panic: double fault" appears.
Yep, that sounds like the problem we've seen alright. Never did find
it in 2.2.2 and, now that it's mysteriously moved itself, are going to
have Even More Fun(tm) trying to track it down in 2.2-stable. I'm sure
that it's going to turn out to be something in the D'OH! category when
found.
> Since floppy controllers use DMA, perhaps DMA and the bounce
> buffers are an issue? Addressing memory remapped above 64 meg
> may also be part of the problem, at least on this motherboard.
I suppose I could always build you a boot floppy without bounce
buffering, just to see what effect it has, but that wouldn't do your
Buslogic controller any good at all during an actual installation. ;-)
Jordan
From owner-freebsd-hackers Sat Oct 25 14:09:34 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA23853
for hackers-outgoing; Sat, 25 Oct 1997 14:09:34 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA23848
for <freebsd-hackers@freebsd.org>; Sat, 25 Oct 1997 14:09:31 -0700 (PDT)
(envelope-from se@X14.MI.Uni-Koeln.DE)
Received: from x14.mi.uni-koeln.de ([134.95.219.124])
by Octopussy.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id XAA18070;
Sat, 25 Oct 1997 23:09:28 +0200 (MET DST)
Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id XAA03524; Sat, 25 Oct 1997 23:09:34 +0200 (CEST)
X-Face: "<d]#=8pzx);RzeqSKI86OVa7=!0/(uRa.+B.9Z9\eNUn@UG?!`y7yt2dFNn%k4'.}](uE%
yCO)$e&Y1%3EO~ifu6Q-#YUM&JZ't,}JkPnAz,8Dj33u%@GBi%[Y#LHz$]h7a<p4)-jKI7~sKjlP-^
EvA[G;]v&0]W!EL%shs,{7x0|oqN4YVIs5,NI#,V{9"WF):5&RkOhyj*#-IAG}Tnu;YCF,d
Message-ID: <19971025230932.41623@mi.uni-koeln.de>
Date: Sat, 25 Oct 1997 23:09:32 +0200
From: Stefan Esser <se@FreeBSD.ORG>
To: dkelly@hiwaay.net
Cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: ncr53c875j under FreeBSD-2.2.2
References: <se@FreeBSD.ORG> <199710251831.NAA08387@nospam.hiwaay.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84
In-Reply-To: <199710251831.NAA08387@nospam.hiwaay.net>; from dkelly@HiWAAY.net on Sat, Oct 25, 1997 at 01:31:46PM -0500
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On 1997-10-25 13:31 -0500, dkelly@HiWAAY.net wrote:
> Stefan Esser said:
> >
> > My guess is, that there is an IRQ conflict between PCI and ISA. Could
> > verify, that none of the IRQs printed for the PCI cards is configured
> > for one of your ISA cards, too. I do not know anything about your PCI
> > BIOS (whether it dynamically assigns interrupts to PCI slots, for
> > example), but assume some kind of configuration problem exists.
>
> Is it OK for PCI cards to share the same IRQ? I was thinking my Asus
> SC875 and IBM DCHS-39100 were not performing up to par and found it on
> IRQ 9, also the 2940 and Mach32 were all on IRQ 9. Now the performance
> is up to expectations after I discovered write buffering was not
> enabled on the DCHS.
PCI requires all cards to support shared interrupts,
while PCI chips wired onto a motherboard need not.
The interrupt code in FreeBSD knows how to deal with
shared interrupts, but there is some (low) additional
overhead, since all cards that share an interrupt have
to be polled to find the real interrupt source.
If anybody observes performance problems which depend
on shared interrupts, I'd like to hear about them.
On one occasion, going from shared to exclusive IRQs
helped performance a lot, but there may have been some
configuration or setup problem.
I have tried shared interrupts on my system (which
does require manual assignment of IRQs to PCI slots),
and found no measurable difference in performance with
2 NCR SCSI cards and one PCI NE2000 clone all using
the same IRQ.
Regards, STefan
From owner-freebsd-hackers Sat Oct 25 14:11:02 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA23968
for hackers-outgoing; Sat, 25 Oct 1997 14:11:02 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from dfw-ix12.ix.netcom.com (dfw-ix12.ix.netcom.com [206.214.98.12])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA23960
for <freebsd-hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 14:11:00 -0700 (PDT)
(envelope-from wghhicks@ix.netcom.com)
Received: (from smap@localhost)
by dfw-ix12.ix.netcom.com (8.8.4/8.8.4)
id QAA22095 for <freebsd-hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 16:10:27 -0500 (CDT)
Received: from atl-ga17-14.ix.netcom.com(204.32.174.174) by dfw-ix12.ix.netcom.com via smap (V1.3)
id rma022079; Sat Oct 25 16:09:57 1997
Message-ID: <34525F3B.1137B612@ix.netcom.com>
Date: Sat, 25 Oct 1997 17:06:03 -0400
From: Jerry Hicks <wghhicks@ix.netcom.com>
Reply-To: wghhicks@ix.netcom.com
Organization: TerraEarth
X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 2.2-STABLE i386)
MIME-Version: 1.0
To: freebsd-hackers@FreeBSD.ORG
Subject: Re: Parity Ram
References: <Pine.BSF.3.96.971025115335.173A-100000@trojanhorse.ml.org> <34524948.41C67EA6@est.is>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Þorður Ivarsson wrote:
>
> This has helped me several times when I was suspecting broken memory in
> the old days (90-93) :-)
>
> Thordur Ivarsson
ECC Memory was marginally useful for this years ago when were using NMOS
RAM. Lately, most memory failures I've seen are catastrophic, taking out
a whole device or better.
I'm not a hardware specialist; Does 'Parity RAM' employ a conventional
parity scheme, a la asynch serial communications?
Didn't Richard Hamming show these to -cause- more problems than they
solve? It seems I recall a number like 256K (bits/bytes/words?) as being
the threshold in a proof he presented.
Jerry Hicks
jerry_hicks@bigfoot.com
From owner-freebsd-hackers Sat Oct 25 14:30:51 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA24640
for hackers-outgoing; Sat, 25 Oct 1997 14:30:51 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from out2.ibm.net (out2.ibm.net [165.87.194.229])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA24634
for <hackers@freebsd.org>; Sat, 25 Oct 1997 14:30:49 -0700 (PDT)
(envelope-from SimsS@IBM.Net)
Received: from Elvis.RatsNest.VaBeach.Va.Us (slip166-72-229-67.va.us.ibm.net [166.72.229.67]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id VAA49340; Sat, 25 Oct 1997 21:30:43 GMT
Received: by localhost with Microsoft MAPI; Sat, 25 Oct 1997 17:30:46 -0400
Message-ID: <01BCE16B.BA31AFE0.SimsS@IBM.Net>
From: Steve Sims <SimsS@IBM.Net>
Reply-To: "SimsS@IBM.Net" <SimsS@IBM.Net>
To: "'Jordan K. Hubbard'" <jkh@time.cdrom.com>
Cc: "'hackers@freebsd.org'" <hackers@freebsd.org>
Subject: RE: Something which 2.2.5 upgraders might find handy.
Date: Sat, 25 Oct 1997 17:19:46 -0400
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4128
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Blew chunks for me on my stove-stock 2.2.2-RELEASE install. (This system
was installed two days ago from the latest CD)
It started to go well - pkg_add pulled the package from your directory.
It backed up /etc to /usr/tmp/etc (so I was protected).
I selected "Kernel Developer" and told it to use all of the existing
network configuration.
I selected FTP as the media.
(NB: My default route on the laptop is via ep0 to my desktop running
iij-ppp -auto)
I couldn't get connected to ftp.freebsd.org. A curse on those SlackWare
folks pulling down 'their' latest cut ;-)
It attempted to gracefully recover, so I selected ftp4.freebsd.org (since
it's closer to me).
Segmentation fault. :-( Spilled core and gave me a prompt.
The system was sufficiently hosed at this point that I went back to the CD,
did a clean install. Restored /usr/tmp/etc/* back to /etc and I was in
business again. Under 2.2.2-RELEASE.
Oh well. I'll try again later tonight.
...sjs...
On Friday, October 24, 1997 5:48 PM, Jordan K. Hubbard
[SMTP:jkh@time.cdrom.com] wrote:
> In ftp://freebsd.org/pub/jkh/225upgrade.tgz is a small package, simply
> saying:
> pkg_add ftp://freebsd.org/pub/jkh/225upgrade.tgz
>
> to launch the 2.2.5 upgrade on your machine. The key thing this
> package does is upgrade your /stand to 2.2.5 first so that the
> sysinstall upgrade code you run is the latest (and upgrade's been
> changed a bit for 2.2.5). All you should need to do is select your
> media type, the distributions you want to upgrade and you should be
> off and running.
>
> Let me know how well it works in actual practice. :)
>
> Jordan
>
From owner-freebsd-hackers Sat Oct 25 14:37:41 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA24922
for hackers-outgoing; Sat, 25 Oct 1997 14:37:41 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from misery.sdf.com (misery.sdf.com [204.244.210.193])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA24917
for <freebsd-hackers@freebsd.org>; Sat, 25 Oct 1997 14:37:38 -0700 (PDT)
(envelope-from tom@sdf.com)
Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1)
id 0xPDsG-0006GR-00; Sat, 25 Oct 1997 14:36:00 -0700
Date: Sat, 25 Oct 1997 14:35:56 -0700 (PDT)
From: Tom <tom@sdf.com>
To: Jerry Hicks <wghhicks@ix.netcom.com>
cc: freebsd-hackers@freebsd.org
Subject: Re: Parity Ram
In-Reply-To: <34525F3B.1137B612@ix.netcom.com>
Message-ID: <Pine.BSF.3.95q.971025143452.23973C-100000@misery.sdf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id OAA24918
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
On Sat, 25 Oct 1997, Jerry Hicks wrote:
> Þorður Ivarsson wrote:
> >
> > This has helped me several times when I was suspecting broken memory in
> > the old days (90-93) :-)
> >
> > Thordur Ivarsson
>
> ECC Memory was marginally useful for this years ago when were using NMOS
> RAM. Lately, most memory failures I've seen are catastrophic, taking out
> a whole device or better.
>
> I'm not a hardware specialist; Does 'Parity RAM' employ a conventional
> parity scheme, a la asynch serial communications?
Most do, except for ECC schemes.
> Didn't Richard Hamming show these to -cause- more problems than they
> solve? It seems I recall a number like 256K (bits/bytes/words?) as being
> the threshold in a proof he presented.
Huh? I don't understand. How does it cause problems to determine that
a memory location is corrupted?
> Jerry Hicks
> jerry_hicks@bigfoot.com
>
>
Tom
From owner-freebsd-hackers Sat Oct 25 14:42:30 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA25189
for hackers-outgoing; Sat, 25 Oct 1997 14:42:30 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from isgate.is (isgate.is [193.4.58.51])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA25180
for <freebsd-hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 14:42:27 -0700 (PDT)
(envelope-from totii@est.is)
Received: from eh.est.is (eh.est.is [194.144.208.34]) by isgate.is (8.7.5-M/) with ESMTP id VAA01372; Sat, 25 Oct 1997 21:42:21 GMT
Received: from didda.est.is (totii@ppp-22.est.is [194.144.208.122])
by eh.est.is (8.8.5/8.8.5) with SMTP id VAA24878;
Sat, 25 Oct 1997 21:40:51 GMT
Message-ID: <345267BF.167EB0E7@est.is>
Date: Sat, 25 Oct 1997 21:42:23 +0000
From: =?iso-8859-1?Q?=DEor=F0ur?= Ivarsson <totii@est.is>
X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386)
MIME-Version: 1.0
To: wghhicks@ix.netcom.com
CC: freebsd-hackers@FreeBSD.ORG
Subject: Re: Parity Ram
References: <Pine.BSF.3.96.971025115335.173A-100000@trojanhorse.ml.org> <34524948.41C67EA6@est.is> <34525F3B.1137B612@ix.netcom.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id OAA25185
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Jerry Hicks wrote:
>
> Þorður Ivarsson wrote:
> >
> > This has helped me several times when I was suspecting broken memory in
> > the old days (90-93) :-)
> >
> > Thordur Ivarsson
>
> ECC Memory was marginally useful for this years ago when were using NMOS
> RAM. Lately, most memory failures I've seen are catastrophic, taking out
> a whole device or better.
>
> I'm not a hardware specialist; Does 'Parity RAM' employ a conventional
> parity scheme, a la asynch serial communications?
>
> Didn't Richard Hamming show these to -cause- more problems than they
> solve? It seems I recall a number like 256K (bits/bytes/words?) as being
> the threshold in a proof he presented.
>
> Jerry Hicks
> jerry_hicks@bigfoot.com
In the old days 8088, 8086, 80186, 80286 and 80386 it was just plain odd
or even
parity like in serial communications but later on came better algorithm
that could
really fix wrong bits
Thordur Ivarsson
From owner-freebsd-hackers Sat Oct 25 14:46:56 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA25415
for hackers-outgoing; Sat, 25 Oct 1997 14:46:56 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA25407
for <freebsd-hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 14:46:49 -0700 (PDT)
(envelope-from joe@florence.pavilion.net)
Received: (from joe@localhost)
by florence.pavilion.net (8.8.7/8.8.7) id WAA01411;
Sat, 25 Oct 1997 22:45:35 +0100 (BST)
Message-ID: <19971025224535.22610@pavilion.net>
Date: Sat, 25 Oct 1997 22:45:35 +0100
From: Josef Karthauser <joe@pavilion.net>
To: Douglas Carmichael <dcarmich@mcs.net>
Cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: FreeBSD for digital recording w/PCI multitrack in/out cards?
References: <199710082310.SAA21519@Jupiter.Mcs.Net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.81
In-Reply-To: <199710082310.SAA21519@Jupiter.Mcs.Net>; from Douglas Carmichael on Wed, Oct 08, 1997 at 06:10:11PM -0500
X-NCC-RegID: uk.pavilion
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> What multitrack recording software exists for FreeBSD?
If someone could write a silicon graphics emulation we could all run
cubase and dump our pcs :)
(Now _that_ would be a nice christmas present.)
Joe
--
Josef Karthauser
Technical Manager Email: joe@pavilion.net
Pavilion Internet plc. [Tel: +44 1273 607072 Fax: +44 1273 607073]
From owner-freebsd-hackers Sat Oct 25 14:49:15 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA25524
for hackers-outgoing; Sat, 25 Oct 1997 14:49:15 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from isgate.is (isgate.is [193.4.58.51])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA25515
for <freebsd-hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 14:49:06 -0700 (PDT)
(envelope-from totii@est.is)
Received: from eh.est.is (eh.est.is [194.144.208.34]) by isgate.is (8.7.5-M/) with ESMTP id VAA01439; Sat, 25 Oct 1997 21:48:55 GMT
Received: from didda.est.is (totii@ppp-22.est.is [194.144.208.122])
by eh.est.is (8.8.5/8.8.5) with SMTP id VAA25196;
Sat, 25 Oct 1997 21:47:25 GMT
Message-ID: <34526949.2781E494@est.is>
Date: Sat, 25 Oct 1997 21:48:57 +0000
From: =?iso-8859-1?Q?=DEor=F0ur?= Ivarsson <totii@est.is>
X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386)
MIME-Version: 1.0
To: John Fieber <jfieber@indiana.edu>
CC: freebsd-hackers@FreeBSD.ORG
Subject: Re: Parity Ram
References: <Pine.BSF.3.96.971025152749.18619A-100000@fallout.campusview.indiana.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
John Fieber wrote:
>
> On Sat, 25 Oct 1997, Jamil J. Weatherbee wrote:
>
> > Can someone fill me in on when you would want to use parity ram as opposed
> > to non-parity ram these days?
>
> So when your memory fails, you know it was a memory failure
> rather than an irreproducable software bug. Also, with
> appropriate BIOS support, you can get not only error detection,
> but some error correction capability.
>
> My question is why would anybody want to use non-parity ram?
>
> -john
lot of memory without parity has been sold in low-end computers to cut
the price
but when you have to work on fix of broken computer it can take long
time if you are
not going to 'Just replace all the simms'. Very often you will have to
run the computer
hour after hour to find the broken one if you have parity-less memory.
Thordur Ivarsson
From owner-freebsd-hackers Sat Oct 25 14:51:57 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA25702
for hackers-outgoing; Sat, 25 Oct 1997 14:51:57 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from isgate.is (isgate.is [193.4.58.51])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA25694
for <freebsd-hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 14:51:51 -0700 (PDT)
(envelope-from totii@est.is)
Received: from eh.est.is (eh.est.is [194.144.208.34]) by isgate.is (8.7.5-M/) with ESMTP id VAA01467; Sat, 25 Oct 1997 21:51:42 GMT
Received: from didda.est.is (totii@ppp-22.est.is [194.144.208.122])
by eh.est.is (8.8.5/8.8.5) with SMTP id VAA25240;
Sat, 25 Oct 1997 21:50:13 GMT
Message-ID: <345269F0.446B9B3D@est.is>
Date: Sat, 25 Oct 1997 21:51:44 +0000
From: =?iso-8859-1?Q?=DEor=F0ur?= Ivarsson <totii@est.is>
X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386)
MIME-Version: 1.0
To: Tom <tom@sdf.com>
CC: freebsd-hackers@FreeBSD.ORG
Subject: Re: Parity Ram
References: <Pine.BSF.3.95q.971025134740.23973A-100000@misery.sdf.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Tom wrote:
>
> On Sat, 25 Oct 1997, Jamil J. Weatherbee wrote:
>
> > Can someone fill me in on when you would want to use parity ram as opposed
>
> Why? To discover memory problems before they corrupt data, and cause
> random panics, core dumps, hangs, or file system corruption. Personally,
> I use ECC capable motherboards that can actually use parity to fix some
> errors.
You need EDO ram I think for this to work, You need some memory to keep
information of what is in your memory before.
> > to non-parity ram these days? If there was some anomaly in memory how
> > would freebsd handle it (is there a trap for parity error?)
>
> These days? RAM can fail. Nothing has changed in the last 10 years.
> I've bought about a gig of RAM in the last couple of months, a good
> percentage of SIMMs still arrive DOA.
>
> FreeBSD systems simple reboot upon parity errors. This is pretty safe
> thing to do. Much better than what a non-parity system would at this
> point (ex. corrupt your filesystems). A smarter thing to do, might be to
> simple stop the process owning the memory that failed, and flag the area
> as unusable (NT does this). Doesn't help much if kernel is in the bad
> memory area though.
>
> Tom
From owner-freebsd-hackers Sat Oct 25 14:54:15 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA25841
for hackers-outgoing; Sat, 25 Oct 1997 14:54:15 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA25834
for <hackers@freebsd.org>; Sat, 25 Oct 1997 14:54:12 -0700 (PDT)
(envelope-from jkh@time.cdrom.com)
Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id OAA18532; Sat, 25 Oct 1997 14:54:13 -0700 (PDT)
To: "SimsS@IBM.Net" <SimsS@IBM.Net>
cc: "'hackers@freebsd.org'" <hackers@freebsd.org>
Subject: Re: Something which 2.2.5 upgraders might find handy.
In-reply-to: Your message of "Sat, 25 Oct 1997 17:19:46 EDT."
<01BCE16B.BA31AFE0.SimsS@IBM.Net>
Date: Sat, 25 Oct 1997 14:54:13 -0700
Message-ID: <18528.877816453@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
> I couldn't get connected to ftp.freebsd.org. A curse on those SlackWare
> folks pulling down 'their' latest cut ;-)
Actually, the machine was down for most of yesterday on an aborted 1GB
upgrade (looks like one of the SIMMs was bad). Looks like the
graceful recovery isn't so graceful, though. :-)
Thanks, I'll try and reproduce that one.
Jordan
From owner-freebsd-hackers Sat Oct 25 14:59:34 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id OAA26088
for hackers-outgoing; Sat, 25 Oct 1997 14:59:34 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from isgate.is (isgate.is [193.4.58.51])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA26080
for <freebsd-hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 14:59:26 -0700 (PDT)
(envelope-from totii@est.is)
Received: from eh.est.is (eh.est.is [194.144.208.34]) by isgate.is (8.7.5-M/) with ESMTP id VAA01526; Sat, 25 Oct 1997 21:55:36 GMT
Received: from didda.est.is (totii@ppp-22.est.is [194.144.208.122])
by eh.est.is (8.8.5/8.8.5) with SMTP id VAA25532;
Sat, 25 Oct 1997 21:54:05 GMT
Message-ID: <34526AD7.794BDF32@est.is>
Date: Sat, 25 Oct 1997 21:55:35 +0000
From: =?iso-8859-1?Q?=DEor=F0ur?= Ivarsson <totii@est.is>
X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386)
MIME-Version: 1.0
To: Chuck Robey <chuckr@glue.umd.edu>
CC: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>,
freebsd-hackers@FreeBSD.ORG
Subject: Re: Parity Ram
References: <Pine.BSF.3.96.971025151431.21591L-100000@picnic.mat.net>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id OAA26084
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Chuck Robey wrote:
>
> On Sat, 25 Oct 1997, Þorður Ivarsson wrote:
>
> > Jamil J. Weatherbee wrote:
> > >
> > > Can someone fill me in on when you would want to use parity ram as opposed
> > > to non-parity ram these days? If there was some anomaly in memory how
> > > would freebsd handle it (is there a trap for parity error?)
> >
> > As far as I know, the 'parity check fail' is connected to NMI of CPU.
> > In most cases the BIOS rutines accept this and halt the computer with no
> > information on where or why , only something like 'NMI detected, system
> > halted' or
> > 'Memory parity fail - NMI generated , system halted'.
>
> Huh ? BIOS routines? What's that got to do with FreeBSD? We don't use
> the BIOS routines, they don't get called at all, right? If there's a
> parity violation, if that's wired to NMI, then the NMI get's called, but
> what that does is determined by FreeBSD, not your BIOS.
>
> >
> > The only reason for this might be giving you some warning of failed
> > memory rather
> > than failed software.
> >
> > This has helped me several times when I was suspecting broken memory in
> > the old days (90-93) :-)
> >
> > Thordur Ivarsson
Ok, most of the old software and OSes did not fiddle with the NMI entry
point
so you did always get to the BIOS, but I don't know what happen in
FreeBSD it self.
Thordur Ivarsson
From owner-freebsd-hackers Sat Oct 25 15:19:07 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA26874
for hackers-outgoing; Sat, 25 Oct 1997 15:19:07 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from dfw-ix1.ix.netcom.com (dfw-ix1.ix.netcom.com [206.214.98.1])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA26869
for <freebsd-hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 15:19:05 -0700 (PDT)
(envelope-from wghhicks@ix.netcom.com)
Received: (from smap@localhost)
by dfw-ix1.ix.netcom.com (8.8.4/8.8.4)
id RAA20593; Sat, 25 Oct 1997 17:17:19 -0500 (CDT)
Received: from atl-ga20-15.ix.netcom.com(205.186.178.79) by dfw-ix1.ix.netcom.com via smap (V1.3)
id rma020575; Sat Oct 25 17:16:42 1997
Message-ID: <34526EE2.64DE0BA6@ix.netcom.com>
Date: Sat, 25 Oct 1997 18:12:50 -0400
From: Jerry Hicks <wghhicks@ix.netcom.com>
Reply-To: wghhicks@ix.netcom.com
Organization: TerraEarth
X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 2.2-STABLE i386)
MIME-Version: 1.0
To: "Þorður Ivarsson" <totii@est.is>
CC: freebsd-hackers@FreeBSD.ORG
Subject: Re: Parity Ram
References: <Pine.BSF.3.96.971025115335.173A-100000@trojanhorse.ml.org> <34524948.41C67EA6@est.is> <34525F3B.1137B612@ix.netcom.com> <345267BF.167EB0E7@est.is>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
Yeah, but when you go to buy memory they have ECC *OR* parity types
available. ECC generally costs more than parity...
i understand the way ECC works, the minicomputer systems i've worked
with in days past held 3 bits for every 8. Just wondering what parity
RAM *really* means (these daze).
WRT the reason parity could be worse, most of the schemes i'm familiar
with use only a single bit per eight bit quantity. Parity bits can be
bad too, that is why most ECC schemes are considered superior (to me
anyway).
Off to find Hamming's proof...
Cheers!
Jerry Hicks,
jerry_hicks@bigfoot.com
Þorður Ivarsson wrote:
>
> Jerry Hicks wrote:
> >
> > Þorður Ivarsson wrote:
> > >
> > > This has helped me several times when I was suspecting broken memory in
> > > the old days (90-93) :-)
> > >
> > > Thordur Ivarsson
> >
> > ECC Memory was marginally useful for this years ago when were using NMOS
> > RAM. Lately, most memory failures I've seen are catastrophic, taking out
> > a whole device or better.
> >
> > I'm not a hardware specialist; Does 'Parity RAM' employ a conventional
> > parity scheme, a la asynch serial communications?
> >
> > Didn't Richard Hamming show these to -cause- more problems than they
> > solve? It seems I recall a number like 256K (bits/bytes/words?) as being
> > the threshold in a proof he presented.
> >
> > Jerry Hicks
> > jerry_hicks@bigfoot.com
>
> In the old days 8088, 8086, 80186, 80286 and 80386 it was just plain odd
> or even
> parity like in serial communications but later on came better algorithm
> that could
> really fix wrong bits
>
> Thordur Ivarsson
From owner-freebsd-hackers Sat Oct 25 15:30:49 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA27480
for hackers-outgoing; Sat, 25 Oct 1997 15:30:49 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from misery.sdf.com (misery.sdf.com [204.244.210.193])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA27472
for <freebsd-hackers@freebsd.org>; Sat, 25 Oct 1997 15:30:45 -0700 (PDT)
(envelope-from tom@sdf.com)
Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1)
id 0xPEhd-0006IQ-00; Sat, 25 Oct 1997 15:29:06 -0700
Date: Sat, 25 Oct 1997 15:29:02 -0700 (PDT)
From: Tom <tom@sdf.com>
To: =?iso-8859-1?Q?=DEor=F0ur?= Ivarsson <totii@est.is>
cc: freebsd-hackers@freebsd.org
Subject: Re: Parity Ram
In-Reply-To: <345269F0.446B9B3D@est.is>
Message-ID: <Pine.BSF.3.95q.971025152756.23973D-100000@misery.sdf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id PAA27474
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
On Sat, 25 Oct 1997, [iso-8859-1] Þorður Ivarsson wrote:
> Tom wrote:
> >
> > On Sat, 25 Oct 1997, Jamil J. Weatherbee wrote:
> >
> > > Can someone fill me in on when you would want to use parity ram as opposed
> >
> > Why? To discover memory problems before they corrupt data, and cause
> > random panics, core dumps, hangs, or file system corruption. Personally,
> > I use ECC capable motherboards that can actually use parity to fix some
> > errors.
>
> You need EDO ram I think for this to work, You need some memory to keep
> information of what is in your memory before.
No. EDO is just like regular DRAM, except the timing is different
(faster). ECC uses the parity bits in regular parity RAM.
Tom
From owner-freebsd-hackers Sat Oct 25 15:57:21 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id PAA28601
for hackers-outgoing; Sat, 25 Oct 1997 15:57:21 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from out2.ibm.net (out2.ibm.net [165.87.194.229])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA28594
for <freebsd-hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 15:57:18 -0700 (PDT)
(envelope-from mouth@ibm.net)
Received: from slip129-37-53-68.ca.us.ibm.net (slip129-37-53-68.ca.us.ibm.net [129.37.53.68]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id WAA76996 for <freebsd-hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 22:57:10 GMT
From: mouth@ibm.net (John Kelly)
To: freebsd-hackers@FreeBSD.ORG
Subject: Re: Parity Ram
Date: Sat, 25 Oct 1997 22:58:33 GMT
Message-ID: <34536bc3.4216043@smtp-gw01.ny.us.ibm.net>
References: <Pine.BSF.3.96.971025115335.173A-100000@trojanhorse.ml.org> <34524948.41C67EA6@est.is> <34525F3B.1137B612@ix.netcom.com>
In-Reply-To: <34525F3B.1137B612@ix.netcom.com>
X-Mailer: Forte Agent 1.01/16.397
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id PAA28595
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
On Sat, 25 Oct 1997 17:06:03 -0400, Jerry Hicks
<wghhicks@ix.netcom.com> wrote:
>Didn't Richard Hamming show these to -cause- more problems than they
>solve? It seems I recall a number like 256K (bits/bytes/words?) as being
>the threshold in a proof he presented.
Even if he's correct that additional bits needed for parity increase
the overall frequency of bit errors, when a one-bit error does occur
on a parity SIMM, at least you are notified of that fact.
On the other hand, any bit errors occurring on a non-parity SIMM will
be unreported. You will have corrupted memory, which could be as
trivial as a reversed bit in a graphic image, or a serious data error.
The fact that you can change one bit in a graphic image without dire
consequences is why printers don't need parity memory.
But on the other hand, most banks use mainframes with ECC memory.
Would you be a satisfied customer if they kept your account balance on
a PC with non-parity memory and every once in a while subtracted
$16,384 from your account because they had a bit error in memory which
went undetected?
So it depends on the application. Non-parity memory has its place,
but not on any computer where data integrity is important.
Intel published a white paper which claimed that with modern memory
manufacturing techniques, bit errors due to gamma radiation and other
disturbances are no more likely than once every 20 years or so for a
DRAM chip. But that's just for one chip --- multiply the number of
SIMMs and individual chips found in a machine and the likelihood
increases.
A great shame upon the computer industry is that chip makers like
Intel have foisted non-parity chipsets like the 430FX upon an
unsuspecting and uninformed public who imagine their PCs operate
reliably as any other appliance. With so many non-parity chipsets and
memory in use, running bug-ridden Microsoft products, I'm amazed the
American economy hasn't collapsed entirely.
John
From owner-freebsd-hackers Sat Oct 25 16:00:33 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id QAA28741
for hackers-outgoing; Sat, 25 Oct 1997 16:00:33 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA28736
for <hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 16:00:29 -0700 (PDT)
(envelope-from tlambert@usr09.primenet.com)
Received: (from daemon@localhost)
by smtp04.primenet.com (8.8.7/8.8.7) id QAA10940;
Sat, 25 Oct 1997 16:00:23 -0700 (MST)
Received: from usr09.primenet.com(206.165.6.209)
via SMTP by smtp04.primenet.com, id smtpd010927; Sat Oct 25 16:00:14 1997
Received: (from tlambert@localhost)
by usr09.primenet.com (8.8.5/8.8.5) id QAA03495;
Sat, 25 Oct 1997 16:00:09 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710252300.QAA03495@usr09.primenet.com>
Subject: Re: zipfs filesystem anyone ?
To: michaelh@cet.co.jp (Michael Hancock)
Date: Sat, 25 Oct 1997 23:00:09 +0000 (GMT)
Cc: gurney_j@resnet.uoregon.edu, tlambert@primenet.com,
luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG
In-Reply-To: <Pine.SV4.3.95.971025103700.24520B-100000@parkplace.cet.co.jp> from "Michael Hancock" at Oct 25, 97 10:44:29 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > actually.. the change wasn't very massive.. just 3 lines of code and some
> > comment updates...
>
> Sheez, Terry, first you give us mega-commits and now you give us tiny
> pointless ones. When are you going to get this right? ;-)
That change was part of my original VFS "megacommit". It was also
seperated out as part of a smaller set of commits (just namei, just
vfs_init, etc.) when the "megacommit" was rejected.
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 Oct 25 16:45:01 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id QAA00116
for hackers-outgoing; Sat, 25 Oct 1997 16:45:01 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA29991;
Sat, 25 Oct 1997 16:44:49 -0700 (PDT)
(envelope-from gurney_j@efn.org)
Received: (from jmg@localhost)
by hydrogen.nike.efn.org (8.8.7/8.8.7) id QAA11993;
Sat, 25 Oct 1997 16:44:47 -0700 (PDT)
Message-ID: <19971025164446.39994@hydrogen.nike.efn.org>
Date: Sat, 25 Oct 1997 16:44:46 -0700
From: John-Mark Gurney <gurney_j@efn.org>
To: FreeBSD Hackers <freebsd-hackers@freebsd.org>
Cc: Peter Wemm <peter@freebsd.org>
Subject: bsd.libnames.mk problems...
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
Reply-To: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
Organization: Cu Networking
X-Operating-System: FreeBSD 2.2.1-RELEASE i386
X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4
X-Files: The truth is out there
X-URL: http://resnet.uoregon.edu/~gurney_j/
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
well.. Jonathan Mini pointed out that src/usr.bin/doscmd/Makefile used
a src reference to crt0.o... so I simply changed it to ${LIBCRT0} but
then the build failed...
upon further examination, it seems that bsd.libnames.mk is only included
from bsd.prog.mk if BINFORMAT != aout... why isn't it? it happens to
also break the other dependancy on ${LIBC}...
this change was introduced by peter in rev1.55 of bsd.prog.mk...
--
John-Mark Gurney Modem/FAX: +1 541 683 6954
Cu Networking
Live in Peace, destroy Micro$oft, support free software, run FreeBSD
From owner-freebsd-hackers Sat Oct 25 16:58:12 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id QAA00559
for hackers-outgoing; Sat, 25 Oct 1997 16:58:12 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA00554
for <hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 16:58:09 -0700 (PDT)
(envelope-from jak@cetlink.net)
Received: from ts1-cltnc-23-s12.cetlink.net (ts1-cltnc-23-s12.cetlink.net [209.54.58.23])
by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id TAA11728
for <hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 19:57:27 -0400 (EDT)
From: jak@cetlink.net (John Kelly)
To: hackers@FreeBSD.ORG
Subject: Re: 48 meg double fault moved to 64 meg in 2.2.5
Date: Sat, 25 Oct 1997 19:08:48 -0400
Message-ID: <AwnU0Y9zBEWf091yn@cetlink.net>
In-Reply-To: <18145.877813190@time.cdrom.com>
Lines: 34
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
"Jordan K. Hubbard" <jkh@time.cdrom.com> wrote:
>You know, christmas is coming up and a new Tyan motherboard would
>probably not be that expensive. ;-)
Heh. I've got one of those too. Dual P-133s which I would like
to try out on FreeBSD 3.0 one of these days. If I get much more
computer stuff it's going to start falling out the windows. At
auction for an incredible price, I bought over a hundred SMC Ultra
ethernet cards to connect this stuff with. Old McDonald had a web
farm, E-I-E I/O.
>I suppose I could always build you a boot floppy without bounce
>buffering, just to see what effect it has, but that wouldn't do your
>Buslogic controller any good at all during an actual installation. ;-)
Hmmm. I thought I read that bounce buffers were only needed for
ISA busmastering and boards with "broken" VLB controllers unable
to handle addresses above 16MB. Even though my motherboard does
not properly implement the A26 line (addresses 64 meg and above),
since the Buslogic 32-bit busmastering controller is only trying
to address memory below 64 meg (the motherboard maximum memory is
64 meg), it works well. And although it's a seemingly obsolete
486DX4-100, the 32-bit VLB SCSI and a Seagate 7200rpm Barracuda
make it pretty quick.
But in any case, if you create a boot floppy without the bounce
buffers, let me know. I'll spin it up to see if that change has
any effect on the boot floppy 48 meg problem.
John
From owner-freebsd-hackers Sat Oct 25 18:06:48 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA04106
for hackers-outgoing; Sat, 25 Oct 1997 18:06:48 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04078
for <hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 18:06:39 -0700 (PDT)
(envelope-from tlambert@usr04.primenet.com)
Received: (from daemon@localhost)
by smtp04.primenet.com (8.8.7/8.8.7) id SAA16040;
Sat, 25 Oct 1997 18:06:37 -0700 (MST)
Received: from usr04.primenet.com(206.165.6.204)
via SMTP by smtp04.primenet.com, id smtpd016033; Sat Oct 25 18:06:29 1997
Received: (from tlambert@localhost)
by usr04.primenet.com (8.8.5/8.8.5) id SAA15742;
Sat, 25 Oct 1997 18:06:25 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710260106.SAA15742@usr04.primenet.com>
Subject: Re: zipfs filesystem anyone ?
To: gurney_j@resnet.uoregon.edu
Date: Sun, 26 Oct 1997 01:06:25 +0000 (GMT)
Cc: tlambert@primenet.com, michaelh@cet.co.jp, luigi@labinfo.iet.unipi.it,
hackers@FreeBSD.ORG
In-Reply-To: <19971025004544.21378@hydrogen.nike.efn.org> from "John-Mark Gurney" at Oct 25, 97 00:45:44 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > The list terminator is still necessary for the population pass, where
> > the vectors get populated. The VOP_REPLACEME needs to be seperate.
>
> I can see on the vnodeopv_desc of the vfs layer, but why does the NULL
> entry on the array of the vnodeop_desc array in vnode_if.c need the
> last NULL, that is what vfs_opv_numops is for... (which the population
> code uses)...
OK. This code is not obvious. I will have to refer to the original
kern/vfs_init.c code for this. In vfs_opv_init(), there is a MALLOC()
where the dynamic vectors are allocated.
The purpose of this is that the per FS descriptor list for the VOP's
defined for a given VFS layer is sparse.
If you look further down in vfs_opv_init(), you will see:
/*
* Finally, go back and replace unfilled routines
* with their default. (Sigh, an O(n^3) algorithm. I
* could make it better, but that'd be work, and n is small.)
*/
So basically, it takes a list like:
{ A, D, F, J, NULL }
And changes it to:
{ A, b, c, D, e, F, g, h, i, J, k, l }
The point being that it knows the end of the per FS descriptor list by
the NULL.
This actually bears *directly* on my sorting recommendation: if the
descriptor list is sparse, you will not have a baseline for a sort of
a new descriptor entry that isn't also in the globally declared
descriptor array, because only the descriptors defined in vnode_if.c
will have known offsets.
> so what I'm saying is we make two vars, maxvfs_opv_numops in which we
> allocate all the memory for that many ops... then as a new op is added
> we simply increase vfs_opv_numops to keep track of were we add the next
> op.. when it's equal to (or greater) then we simply disallow adding any
> new ops...
Yes, this is just housekeeping, and it doesn't matter how it is
accomplished so long as it doesn't preclude some future use we haven't
thought of yet. It's a "don't care" state.
> > > personally, a possible define that declares I want a possible X extra
> > > vop vectors... and then have a couple variables that tell you the
> > > maximum number, and the current last offset... this shouldn't be hard
> > > to do...
> >
> > They kind of need to be static, unless the vector list becomes a linker
> > set. This can't happen until the linker set can be agregated between
>
> I was talking about the size of the list being variable, but that ther
> be an options like:
> options "EXTRA_VNODEOPS=5"
>
> then we simply do:
> int maxvfs_opv_numops = (sizeof(vfs_op_descs)/sizeof(struct vnodeop_desc *)) +
> EXTRA_VNODEOPS;
>
> and then the define is like:
> struct vnodeop_desc *vfs_op_descs[num] = {
> };
>
> and we simply modify the awk script to properly generate num... which
> isn't hard...
See above. The descriptors have to be unique at the time vnode_if.c is
compiled; different indices pointing to the same address won't cut it.
Probably you will need to have a special tag value, or you will need
to have a duplicate array containing only the replacement descriptor
entries portion of the vfs_op_descs table. Or you will need to save
them one behind when you add the descriptor, and remove them one behind.
I would caution *againt* saving them one behind, though. I could easily
see a new VOP being used by two loadable FS's. To make the thing work,
you would need to keep a reference count -- and that implies some place
to keep it. I would suggest in a structure with the VOP descriptors
you replace.
Really, the output (populated) per FS structure with all entries
filled in for the defaults should be possible to dereference
directly -- *IFF* it's sorted. This gets rid of the function stubs
for the VOP_* calls, and saves a lot of call overhead. Think about
it, anyway...
> arg, I see what you mean.. ffs depends upon some of ufs's functions..
> (arg, I was assuming that each module was independant)...
Yes. This kind of screws up the BSDI plans for Soft Updates, since
it mean the soft updates capable UFS will not be able to be shared
with MFS, LFS, etc..
> right now the only way I can think of preventhing this from being a
> problem is to add the MOUNT_xxx to the declaration of the vnodeops,
> and then including in the ffs a dependancy of ufs...
No. If the entries are sorted, and you have a reference, then an init
routine can reference the previously defined loaded module (the symbol
table is cumulative). This at least gets you an address to pass into
the modified vfs_opv_init() function so you can convert the UFS
descriptor list to a set of function pointers.
The trick is to know beforehand that the populated descriptor lists
are in the same order in the UFS and the FFS, and just use the offset
so you don't have to reference every function by symbol. Hence the
sort. It can be a simple bubble sort (that's what I used), since you
can sort it in place in the populated vector (dynamic vector is a bad
name for this in the code, IMO).
> > Sorting the list also allows you to reference by index instead of by
> > descriptor. If you think about it, you won't have a descriptor for
> > a new VOP, if you dynamically load it, in vnode_if.h. This loses the
> > little glue function. To fix this, you have to kill the glue functions.
> > And you can do it if you can indext into the op vector and get the right
> > function.
>
> umm... isn't this already what is done? from vfs_opv_init:
> opv_desc_vector[opve_descp->opve_op->vdesc_offset] =
> opve_descp->opve_impl;
> the above line will set the appropriate vector by the vdesc_offset..
No. This requires that the symbol set for the descriptor set be complete;
if you are adding a new VOP, then it won't be (unless you have ELF linker
set agregation across distinct per kld sections working). Even then,
the VOP entry may be duplicated, which I don't know how the linker set
could handle correctly. It really needs a reference count for each FS
that's using the new VOP.
It becomes a can of worms quickly unless you reduce the decriptor list
to a set of indices into an array of VOP functions. So again, doing
the physical sort is the right way to go. Note that if you ad a VOP,
you have to go back and repopulate the dynamic entry wheere the new VOP
came in, if there is a default behaviour specified. 8-(.
You can make the sort part of the vfs_opv_init(). Since the vfs_opv_init()
"knows" the descriptor list, this works.
> then at the end, there is a second pass to fill in the remaining entries
> with the entry from VOFFSET(vop_default) of it's own vector..
>
> hmm... looks like we need to remove this comment:
> /*
> * Finally, go back and replace unfilled routines
> * with their default. (Sigh, an O(n^3) algorithm. I
> * could make it better, but that'd be work, and n is small.)
> */
> as right now the final routine runs in n as far as I can tell... :)
The O(n^3) is wrong, unlesss you consider the whole thing, and you
consider it in light of how the UFS is referenced by the FFS. For that
specific case, O(n^3) is correct. This is because there is a seperate
"dynamic vector" for each reference instance of a "non-dynamic vector".
This is also not very obvious from the code. You need to look at the
array declarations themselves, and the specfs ops, etc., in context
to see this.
The part of the comment that says "replace unfilled routines" is correct,
but, again, it's descriptor based, which breaks truly dynamic loading
of intermediate VFS's as opposed to complete-to-bottom stacks.
The problem is in telling "NULL" entries from "uninitialized" entries.
You need to know this because you want to collapse the first defined
entry to the top of the stack so that you have the minimum possible
call overhead for any individual stacked VOP.
You can *almost* see how this is supposed to work in the "FFS stacked
on UFS" case. It's kind of obfuscated by the "struct fileops" crap,
and the fact that the vnode handling is from a global free pool, instead
of the vnode objects being subelements in the per FS object structure
(for UFS, struct inode for the in core inode). If you ignore that code
and pretend the references are direct instead of indirect, it's a lot
easier to visualize (one of the reasons I think the code should be
changed to make it match the conceptual design).
Right now, there is no real "collapse" taking place. Mostly because
things with NULL entries are broken and getting more broken the more
people stuff VM code into them. If you look at the "UFS in FFS VOP
structure" entries, you can see how the vnode pointer is supposed to
be an abstract type in each FS. The per FS macro for "VTOI" and "ITOV"
are supposed to be the only gates where a vnode is not treated as an
opaque type (and that goes back to the global pool implementation; you
*could* use pointer math to make it *truly* opaque if the vnode were
a subelement).
It's all very complicated, but you can see it if you take enough time.
Unfortunately, not very many people have taken enough time, since it's
a lot more convoluted than it should be (ideally and IMO, anyway).
But to ascend out of the fourth ring of hell, you first have to visit
the fourth ring of hell... otherwise you can't get there from here. ;-).
Once enough people understand the code so that a code review is possible
and people can get the warm fuzzies about the new code, it should be
possible to fix all of it to make it easier for people to get their
brains around. Then it picks up speed as it rolls downhill.
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 Oct 25 18:13:18 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id SAA04872
for hackers-outgoing; Sat, 25 Oct 1997 18:13:18 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04849
for <freebsd-hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 18:13:07 -0700 (PDT)
(envelope-from tlambert@usr04.primenet.com)
Received: (from daemon@localhost)
by smtp04.primenet.com (8.8.7/8.8.7) id SAA16242;
Sat, 25 Oct 1997 18:13:07 -0700 (MST)
Received: from usr04.primenet.com(206.165.6.204)
via SMTP by smtp04.primenet.com, id smtpd016235; Sat Oct 25 18:13:00 1997
Received: (from tlambert@localhost)
by usr04.primenet.com (8.8.5/8.8.5) id SAA15989;
Sat, 25 Oct 1997 18:12:57 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199710260112.SAA15989@usr04.primenet.com>
Subject: Re: FreeBSD for digital recording w/PCI multitrack in/out cards?
To: joe@pavilion.net (Josef Karthauser)
Date: Sun, 26 Oct 1997 01:12:57 +0000 (GMT)
Cc: dcarmich@mcs.net, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <19971025224535.22610@pavilion.net> from "Josef Karthauser" at Oct 25, 97 10:45:35 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > What multitrack recording software exists for FreeBSD?
>
> If someone could write a silicon graphics emulation we could all run
> cubase and dump our pcs :)
> (Now _that_ would be a nice christmas present.)
Processor emulation for SGI would require a MIPS emulation package,
an execution class loader, and the ability to open files that were
executable but not readable or writeable in order to map them into
the emulator's address space.
You can download a MIPS emulator (SPIM) from the net. I would be
happy to help get an emulation running, but you'd probrably have to
start with NetBSD MIPS binaries and work your way up...
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 Oct 25 19:24:22 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id TAA10121
for hackers-outgoing; Sat, 25 Oct 1997 19:24:22 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA10113
for <freebsd-hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 19:24:15 -0700 (PDT)
(envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost [127.0.0.1])
by word.smith.net.au (8.8.7/8.8.5) with ESMTP id LAA00510;
Sun, 26 Oct 1997 11:50:11 +1030 (CST)
Message-Id: <199710260120.LAA00510@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Josef Karthauser <joe@pavilion.net>
cc: Douglas Carmichael <dcarmich@mcs.net>, freebsd-hackers@FreeBSD.ORG
Subject: Re: FreeBSD for digital recording w/PCI multitrack in/out cards?
In-reply-to: Your message of "Sat, 25 Oct 1997 22:45:35 BST."
<19971025224535.22610@pavilion.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 26 Oct 1997 11:50:09 +1030
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> > What multitrack recording software exists for FreeBSD?
>
> If someone could write a silicon graphics emulation we could all run
> cubase and dump our pcs :)
> (Now _that_ would be a nice christmas present.)
You could just buy an old Atari and run it on the original platform 8)
(or hack STonX to make it run there...)
mike
From owner-freebsd-hackers Sat Oct 25 20:16:46 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id UAA13835
for hackers-outgoing; Sat, 25 Oct 1997 20:16:46 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from dfw-ix3.ix.netcom.com (dfw-ix3.ix.netcom.com [206.214.98.3])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA13829
for <freebsd-hackers@freebsd.org>; Sat, 25 Oct 1997 20:16:42 -0700 (PDT)
(envelope-from wghhicks@ix.netcom.com)
Received: (from smap@localhost)
by dfw-ix3.ix.netcom.com (8.8.4/8.8.4)
id WAA25933; Sat, 25 Oct 1997 22:15:12 -0500 (CDT)
Received: from atl-ga15-14.ix.netcom.com(204.32.174.110) by dfw-ix3.ix.netcom.com via smap (V1.3)
id rma025876; Sat Oct 25 22:14:41 1997
Message-ID: <3452B4B9.8A4510A9@ix.netcom.com>
Date: Sat, 25 Oct 1997 23:10:49 -0400
From: Jerry Hicks <wghhicks@ix.netcom.com>
Reply-To: wghhicks@ix.netcom.com
Organization: TerraEarth
X-Mailer: Mozilla 4.03b8 [en] (X11; I; FreeBSD 2.2-STABLE i386)
MIME-Version: 1.0
To: Mike Smith <mike@smith.net.au>
CC: freebsd-hackers@freebsd.org
Subject: Re: Parity Ram
References: <199710260126.LAA00539@word.smith.net.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Mike Smith wrote:
>
> > Yeah, but when you go to buy memory they have ECC *OR* parity types
> > available. ECC generally costs more than parity...
>
> Crap. In the case of 72-pin parts, parity and ECC are both x36. 30-pin
> parts are either x8 (no parity) or x9 (parity, or ECC in groups of 4).
>
> mike
Hi Mike,
i understood that they're referred to as ECC vs PARITY because of the
memory controller interface. True, the same number of bits are found in
devices labeled both ways.
Some ECC controllers must have special requirements of the interface to
the memory (timing, interleaving ?)
A quick AltaVista search on ECC found this link:
http://www1.ibmlink.ibm.com/HTML/SPEC/6062ipme.html#pari
(IBM, ugh) In this example they are pretty explicit that parity memory
is different from ECC-EDO devices. i'll bet the prices are different
too.
i'm really just trying to understand all this myself; i'm not a hardware
type. (heck, i'm not that much of a software type either ;)
Do you know anything of Richard Hamming's assertion that parity memory
(the old fashioned even/odd type) is-a-bad -thing in large
configurations?
this is bound to be a FAQ...
Thanks,
Jerry Hicks
jerry_hicks@bigfoot.com
From owner-freebsd-hackers Sat Oct 25 21:05:05 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id VAA15535
for hackers-outgoing; Sat, 25 Oct 1997 21:05:05 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133])
by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA15526
for <hackers@freebsd.org>; Sat, 25 Oct 1997 21:05:00 -0700 (PDT)
(envelope-from grog@freebie.lemis.com)
Received: (from grog@localhost)
by freebie.lemis.com (8.8.7/8.8.5) id OAA11964;
Sun, 26 Oct 1997 14:34:56 +1030 (CST)
Message-ID: <19971026143455.13913@lemis.com>
Date: Sun, 26 Oct 1997 14:34:55 +1030
From: Greg Lehey <grog@lemis.com>
To: FreeBSD Hackers <hackers@freebsd.org>
Subject: When login class?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84e
Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
WWW-Home-Page: http://www.lemis.com/~grog
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk
Am I correct in believing that the current login class concept was
introduced in 4.4BSD? Otherwise, where did it come from?
Greg
From owner-freebsd-hackers Sat Oct 25 23:53:49 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
by hub.freebsd.org (8.8.7/8.8.7) id XAA21287
for hackers-outgoing; Sat, 25 Oct 1997 23:53:49 -0700 (PDT)
(envelope-from owner-freebsd-hackers)
Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130])
by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA21282
for <freebsd-hackers@FreeBSD.ORG>; Sat, 25 Oct 1997 23:53:45 -0700 (PDT)
(envelope-from sthaug@nethelp.no)
From: sthaug@nethelp.no
Received: (qmail 26799 invoked by uid 1001); 26 Oct 1997 06:53:38 +0000 (GMT)
To: wghhicks@ix.netcom.com
Cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: Parity Ram
In-Reply-To: Your message of "Sat, 25 Oct 1997 18:12:50 -0400"
References: <34526EE2.64DE0BA6@ix.netcom.com>
X-Mailer: Mew version 1.05+ on Emacs 19.28.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Sun, 26 Oct 1997 07:53:37 +0100
Message-ID: <26797.877848817@verdi.nethelp.no>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
> i understand the way ECC works, the minicomputer systems i've worked
> with in days past held 3 bits for every 8. Just wondering what parity
> RAM *really* means (these daze).
>
> WRT the reason parity could be worse, most of the schemes i'm familiar
> with use only a single bit per eight bit quantity. Parity bits can be
> bad too, that is why most ECC schemes are considered superior (to me
> anyway).
Hardware based on the Intel 430HX and 440FX chipsets (probably 440LX
also) can use a single parity bit per byte to get you ECC. The trick is
that memory is read and written in units of 64 bits (ie. 72 bits with
the parity info). 72 bits per 64 bit of information is enough to get
you single bit correction and double bit detection.
Steinar Haug, Nethelp consulting, sthaug@nethelp.no