From owner-freebsd-arch Sun Jul 2 8: 5:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mimer.webgiro.com (mimer.webgiro.com [212.209.29.5]) by hub.freebsd.org (Postfix) with ESMTP id 6DE3537B85A; Sun, 2 Jul 2000 08:05:15 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by mimer.webgiro.com (Postfix, from userid 66) id 6895D2DC0C; Sun, 2 Jul 2000 17:10:59 +0200 (CEST) Received: by mx.webgiro.com (Postfix, from userid 1001) id E8ECD7817; Sun, 2 Jul 2000 17:00:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx.webgiro.com (Postfix) with ESMTP id E6AB810E17; Sun, 2 Jul 2000 17:00:44 +0200 (CEST) Date: Sun, 2 Jul 2000 17:00:44 +0200 (CEST) From: Andrzej Bialecki To: dfr@freebsd.org, jlemon@freebsd.org Cc: freebsd-arch@freebsd.org Subject: UPDATE: Re: Dynamic sysctls, next round (please review) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Ok, I think I solved all bad scenarios (described in the message at the end). Instead of implementing some complex referencing mechanism, I just added a possibility to do "safe delete" of context, so that it's possible to rollback the changes if it fails in the middle. I tested that creating partially overlapping subtrees, and deleting them independently works properly. The new patches are available at the same URL: http://www.freebsd.org/~abial/dyn_sysctl.tgz Please review and send me your comments. Thanks! 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/ ---- ---------- Forwarded message ---------- Date: Thu, 29 Jun 2000 12:19:48 +0200 (CEST) From: Andrzej Bialecki To: Doug Rabson Cc: dfr@freebsd.org, jlemon@freebsd.org Subject: Re: Dynamic sysctls, next round (please review) [snip...] The following scenario will break the reference counting as it is right now (ref counts in brackets): * module A creates: -static_root -node1(1) -node2(1) -leaf1(1) * module B creates: -node2(2) -leaf2(1) Why? Well, perhaps it checks that -node1 already exists... Now the tree looks like that: -static_root -node1(1) -node2(2) -leaf1(1) -leaf2(1) * module A wants to free the context: -leaf1(0) - free -node2(1) - leave -node1(0) - free * module B is left with subtree hanging in void: -static_root NOTHING! -node2(1) -leaf2(1) I don't have any good solution for it right now, except to warn users that they should always hang their subtrees off of static nodes. :-( 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-arch" in the body of the message From owner-freebsd-arch Sun Jul 2 11:26:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from astart2.astart.com (astart2.astart.com [206.71.174.194]) by hub.freebsd.org (Postfix) with ESMTP id 12ADD37B5BA for ; Sun, 2 Jul 2000 11:26:12 -0700 (PDT) (envelope-from papowell@astart.com) Received: from h4.private (papowell@h4.private [10.0.0.4]) by astart2.astart.com (8.9.3/8.9.3) with ESMTP id LAA23433; Sun, 2 Jul 2000 11:27:44 -0700 (PDT) Received: (from papowell@localhost) by h4.private (8.9.3/8.9.3) id LAA04873; Sun, 2 Jul 2000 11:25:37 -0700 (PDT) Date: Sun, 2 Jul 2000 11:25:37 -0700 (PDT) From: papowell@astart.com Message-Id: <200007021825.LAA04873@h4.private> To: drosih@rpi.edu, sheldonh@uunet.co.za, wes@softweyr.com Subject: Re: was: Bringing LPRng into FreeBSD? Cc: arch@FreeBSD.ORG, papowell@astart.com Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From drosih@rpi.edu Mon Jun 26 18:08:56 2000 > Date: Mon, 26 Jun 2000 21:09:27 -0400 > To: Wes Peters , Sheldon Hearn > From: Garance A Drosihn > Subject: Re: was: Bringing LPRng into FreeBSD? > Cc: arch@FreeBSD.ORG, papowell@astart.com > > At 5:08 PM -0600 6/26/00, Wes Peters wrote: > >Sheldon Hearn wrote: > > > > > > My only concern is that we lose through incompatibility with > > > previous releases what we gain in maintenance. > > > > > > Of course, I'm one of the people that isn't affected by this. > > > I'm just worried about the "replacement bandwagon" that seems > > > to be gathering momentum. [...] > > > >We're in the same boat here. I'm a very lightweight user of lpr, > >but also worry about replacement "because it's cool" rather than > >replacement because it really needs to be replaced. > > > >OTOH, I'm the first to agree that lpr is an arcane pile of bits. > >I wonder if we shouldn't hold out for something even more up-to-date > >than LPRng. Rather than going with an LPR system that sucks less, > >perhaps a really good queuing system that knows how to feed printers, > >handles print and graphics files formats automagically, and is > >configured through a simple web interface? > > Well, lprNG does offer some of that, though not the 'simple web > interface' for configuring. Part of the problem for that goal > is that the printers themselves have all kinds of annoying quirks. > > The current code for freebsd's lpr is actually cleaned up quite a > bit from a few years ago. Still a bit arcane and poorly structured, > but improving. I tend to prefer gradual cleanup like this to starting > some brand new printing project with all kinds of grand goals. If > anyone is uneasy about switching to lprNG, they'd have to be even > more uneasy about a complete printing rewrite which loses all trace > of past history. > > > --- > Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu > Senior Systems Programmer or drosih@rpi.edu > Rensselaer Polytechnic Institute > Ummm... LPRng is actually 16 years old... Patrick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 2 11:32:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 579CD37B773 for ; Sun, 2 Jul 2000 11:32:37 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id OAA19781; Sun, 2 Jul 2000 14:32:27 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200007021832.OAA19781@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Chuck Robey Cc: Garance A Drosihn , Will Andrews , papowell@astart.com, arch@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: was: Bringing LPRng into FreeBSD? References: In-reply-to: Your message of "Fri, 30 Jun 2000 22:01:52 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 02 Jul 2000 14:32:27 -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Fri, 30 Jun 2000, Garance A Drosihn wrote: > > > At 9:04 PM -0400 6/28/00, Chuck Robey wrote: > > >On Wed, 28 Jun 2000, Will Andrews wrote: > > > > > > > On Tue, Jun 27, 2000 at 02:41:27AM -0700, John Baldwin wrote: > > > > > Erm, then why not do this with apsfilter? > > > > > > > > Because apsfilter also brings in far more useless junk that > > > > LPRng does. 26,000 lines over our current lpr == LPRng. > > > > apsfilter == LPRng + lots and lots and lots of other crap. > > > > > >I'm curious about that. How does LPRng get gif to postscript > > >conversion without ghostscript (one of the biggest pieces of > > >"crap" you refer to). How does it get ascii (or any other > > >format) to postscript? > > > > I'm a bit spaced out right now, but offhand I don't see why > > ghostscript would be needed for converting anything (except > > PDF) into postscript. I suspect apsfilter only uses it for > > printing postscript jobs on non-postscript printers, or for > > doing clever manipulation of postscript (for page-counting, > > perhaps). I would be inclined to use something like netpbm > > to get GIF images INTO postscript. Not ghostscript. > > Were you aware that most of the netpbm things that go into postscript CALL > ghostscript? In fact, since you say you've been printing jpegs and gifs > for a long time, go a look (a closer one) at the executeables you've been > using. How do they do it? This can't be right. ghostscript is a PostScript interpreter, which takes as input a PostScript program. It executes the PostScript program, which usually as a side-effect causes an image to be rendered, usually in the form of a bitmap, for each page. Then that bitmap is squirted out to a printer than doesn't have it's own PostScript interpreter. To convert a JPEG, GIF or PNM bitmap into PostScript is at it's core a simply syntatic excercise. You produce the uncompressed bitmap from the input source by un-doing any compression according to the method associated with the file format. Ghostscript is not involved in this process. You then emit the bitmap along with some idomatic PostScript code, which included the image operator, which causes a PostScript printer to print the bitmap on the page (as compared to using the show operator to render a font on the page). I'm very familiar with the latter phase of this, as many year ago I wrote a DVI to PostScript converter program which converts many tiny bitmaps into a PostScript program to be rendered (usually on a PostScript printer). Now, a filter which claims to take a PostScript program as input would quite likely need ghostscript (or some other PostScript interpeter) to compute a bitmap for the netpbm tools to operate on. Perhaps this is what you had in mind? louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 2 12: 7:29 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 0CFF237B57D for ; Sun, 2 Jul 2000 12:07:27 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id MAA15118 for ; Sun, 2 Jul 2000 12:07:26 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id MAA31901; Sun, 2 Jul 2000 12:07:25 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Sun, 2 Jul 2000 12:07:25 -0700 (PDT) Message-Id: <200007021907.MAA31901@vashon.polstra.com> To: arch@freebsd.org Reply-To: arch@freebsd.org Subject: Re: Importing tsearch routines. In-Reply-To: <20000701121305.C96751@bone.nectar.com> References: <20000630153151.J275@fw.wintelcom.net> <13597.962468047@axl.ops.uunet.co.za> <20000701121305.C96751@bone.nectar.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <20000701121305.C96751@bone.nectar.com>, Jacques A. Vidrine wrote: > On Sat, Jul 01, 2000 at 06:14:07PM +0200, Sheldon Hearn wrote: > > I don't think you should bother asking if you're going to give people > > less than 24 hours to respond. > > IMHO, something that is specified by several standards and included by > all BSDs but FreeBSD have pretty good call to be on a fast track. Sorry, but my reaction to that is "baloney." We have always had a convention of waiting at least 72 hours for people to reply to a request for comments. Anything less than that simply doesn't make sense in a global project that is largely made up of people with jobs and, in some cases, Real Lives. It is disrespectful to the other members of the project to ask for comments and then take action before a reasonable amount of time has been allowed for responses. All it takes is a little bit of patience. It's not as if 72 hours were an eternity. There is nothing about tsearch that makes it urgent. There is no reason that one couldn't wait for 72 hours to see what everybody had to say about it. The only exception to the 72-hour rule is urgent security-related fixes. Tsearch certainly doesn't fall into that category. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 2 13: 0:13 2000 Delivered-To: freebsd-arch@freebsd.org Received: from dt052n3e.san.rr.com (dt052n3e.san.rr.com [204.210.33.62]) by hub.freebsd.org (Postfix) with ESMTP id B605137BE87 for ; Sun, 2 Jul 2000 13:00:09 -0700 (PDT) (envelope-from DougB@yahoo-inc.com) Received: from yahoo-inc.com (doug@master [10.0.0.2]) by dt052n3e.san.rr.com (8.9.3/8.9.3) with ESMTP id NAA77806 for ; Sun, 2 Jul 2000 13:00:09 -0700 (PDT) (envelope-from DougB@yahoo-inc.com) Message-ID: <395F9F48.555A88BD@yahoo-inc.com> Date: Sun, 02 Jul 2000 13:00:08 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 5.0-CURRENT-0629 i386) X-Accept-Language: en MIME-Version: 1.0 To: arch@FreeBSD.ORG Subject: Re: Importing tsearch routines. References: <20000630153151.J275@fw.wintelcom.net> <13597.962468047@axl.ops.uunet.co.za> <20000701121305.C96751@bone.nectar.com> <200007021907.MAA31901@vashon.polstra.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Polstra wrote: > Sorry, but my reaction to that is "baloney." We have always had a > convention of waiting at least 72 hours for people to reply to a > request for comments. Anything less than that simply doesn't make > sense in a global project that is largely made up of people with jobs > and, in some cases, Real Lives. Ok, I know this is a serious topic, but THAT was funny... :) Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 2 14:17:44 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id A074C37B52E for ; Sun, 2 Jul 2000 14:17:41 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e62LHep29600 for arch@freebsd.org; Sun, 2 Jul 2000 14:17:40 -0700 (PDT) Date: Sun, 2 Jul 2000 14:17:40 -0700 From: Alfred Perlstein To: arch@freebsd.org Subject: HEADSUP: Re: name cache size Message-ID: <20000702141740.S25571@fw.wintelcom.net> References: <20000702143001.B24321@cs.rice.edu> <20000702135026.P25571@fw.wintelcom.net> <20000702161458.A25129@cs.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000702161458.A25129@cs.rice.edu>; from ssiyer@cs.rice.edu on Sun, Jul 02, 2000 at 04:14:58PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Sitaram Iyer [000702 14:15] wrote: > Thus, Alfred Perlstein wrote... > > > how can I increase the size of freebsd's name cache? > > sysctl -w vfs.vmiodirenable=1 > > thanks, that worked. I would like to make this the default in 5.0 so the bugs (if any) can be worked out. sysctl -w vfs.vmiodirenable=1 I'm aware of the bloat of the dirsize for the default case, and it's a bogus argument, we need to be able to cache correctly for performance reasons. thanks, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 2 14:26:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 52CCF37BE73; Sun, 2 Jul 2000 14:26:40 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Sun, 2 Jul 2000 17:26:36 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Andrzej Bialecki Cc: dfr@freebsd.org, jlemon@freebsd.org, freebsd-arch@freebsd.org Subject: Re: UPDATE: Re: Dynamic sysctls, next round (please review) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 2 Jul 2000, Andrzej Bialecki wrote: > * module B is left with subtree hanging in void: > -static_root > NOTHING! > -node2(1) > -leaf2(1) > > I don't have any good solution for it right now, except to warn users that > they should always hang their subtrees off of static nodes. :-( There's already a good solution for this: you must always MODULE_DEPEND() upon the owner of a node which you hang things from :) Now, we just need to make sure each node is created by a module which you can MODULE_DEPEND() on, and that's not too hard! -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 2 15: 9: 1 2000 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id C98E737B78B for ; Sun, 2 Jul 2000 15:08:58 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id PAA97094 for arch@freebsd.org; Sun, 2 Jul 2000 15:08:58 -0700 (PDT) (envelope-from obrien) Date: Sun, 2 Jul 2000 15:08:58 -0700 From: "David O'Brien" To: arch@freebsd.org Subject: Re: Importing tsearch routines. Message-ID: <20000702150858.H59770@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <20000630153151.J275@fw.wintelcom.net> <13597.962468047@axl.ops.uunet.co.za> <20000701121305.C96751@bone.nectar.com> <200007021907.MAA31901@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007021907.MAA31901@vashon.polstra.com>; from jdp@polstra.com on Sun, Jul 02, 2000 at 12:07:25PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <20000701121305.C96751@bone.nectar.com>, Jacques A. Vidrine wrote: > On Sat, Jul 01, 2000 at 06:14:07PM +0200, Sheldon Hearn wrote: > > I don't think you should bother asking if you're going to give people > > less than 24 hours to respond. > > IMHO, something that is specified by several standards and included by > all BSDs but FreeBSD have pretty good call to be on a fast track. No. That is not how we operate. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 2 16:10:17 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mimer.webgiro.com (mimer.webgiro.com [212.209.29.5]) by hub.freebsd.org (Postfix) with ESMTP id 320B937B72E; Sun, 2 Jul 2000 16:10:14 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by mimer.webgiro.com (Postfix, from userid 66) id AF3A52DC0C; Mon, 3 Jul 2000 01:15:57 +0200 (CEST) Received: by mx.webgiro.com (Postfix, from userid 1001) id 227367817; Mon, 3 Jul 2000 01:06:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx.webgiro.com (Postfix) with ESMTP id 1DC0710E17; Mon, 3 Jul 2000 01:06:29 +0200 (CEST) Date: Mon, 3 Jul 2000 01:06:29 +0200 (CEST) From: Andrzej Bialecki To: Brian Fundakowski Feldman Cc: dfr@freebsd.org, jlemon@freebsd.org, freebsd-arch@freebsd.org Subject: Re: UPDATE: Re: Dynamic sysctls, next round (please review) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 2 Jul 2000, Brian Fundakowski Feldman wrote: > On Sun, 2 Jul 2000, Andrzej Bialecki wrote: > > * module B is left with subtree hanging in void: > > -static_root > > NOTHING! > > -node2(1) > > -leaf2(1) > > > > I don't have any good solution for it right now, except to warn users that > > they should always hang their subtrees off of static nodes. :-( > > There's already a good solution for this: you must always MODULE_DEPEND() > upon the owner of a node which you hang things from :) Now, we just need > to make sure each node is created by a module which you can MODULE_DEPEND() > on, and that's not too hard! I don't think this is relevant here. See the example (which is BTW a module, but doesn't need to be) provided with the patches. The granularity of dependancy is *per context*, not per module - in fact, the code that creates dynamic sysctls doesn't have to be a module, and it can create multiple contexts. The latest patches provide a working solution to this - perhaps not beautiful, but still something... BTW. I could limit support for dyn_sysctls to disjoint subtrees exclusively - but I think the ability to have partially overlapping trees is attractive enough to justify small overhead of traversing the tailq's several times... 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-arch" in the body of the message From owner-freebsd-arch Sun Jul 2 16:23:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailtoaster2.pipeline.ch (mailtoaster2.pipeline.ch [62.48.0.71]) by hub.freebsd.org (Postfix) with ESMTP id 7648137B72E for ; Sun, 2 Jul 2000 16:23:20 -0700 (PDT) (envelope-from oppermann@telehouse.ch) Received: (qmail 19170 invoked from network); 2 Jul 2000 23:26:07 -0000 Received: from unknown (HELO telehouse.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster2.pipeline.ch (qmail-ldap-1.03) with RC4-MD5 encrypted SMTP for ; 2 Jul 2000 23:26:07 -0000 Message-ID: <395FCED1.2ED61C43@telehouse.ch> Date: Mon, 03 Jul 2000 01:22:57 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: obrien@freebsd.org Cc: arch@freebsd.org Subject: Re: Import of new NetBSD ARP subsystem References: <395E09CC.2EEB627D@telehouse.ch> <20000701122217.C59770@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David O'Brien wrote: > > On Sat, Jul 01, 2000 at 05:10:04PM +0200, Andre Oppermann wrote: > > What is the status of the import of the link-level independent arp > > subsystem? > ...snip... > > Description here: > > http://www.daemonnews.org/199809/underhood.html > > Since daemonnews.org isn't answering me at the moment, you would do a > much better selling job if you would give some _details_ in your email. Hmm, that page is working fine for me... OK, here you go, excerpt from that page: : Traditional BSD kernels have only supported mapping IP addresses to Ethernet : 6-byte MAC addresses (and the FDDI and Token-Ring lookalikes). : However, when dealing with other types of addresses like ARCnet, AX25 packet : radio, etc. with a different length, more general aspects of the ARP mapping : have to be implemented. This paper reports on the one-to-N mapping developed : for NetBSD. : : Old BSD networking up to and including 4.4BSD-lite has only supported IP version : 4 over Ethernet. All modern operating systems based on 4.4BSD-lite have inherited : this limitation. The exception are link types that use the same 6-byte addressing : as Ethernet (e.g., FDDI). : ... Reading the whole page is still necessary, it provides much more detail about the changes. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 2 17:34:47 2000 Delivered-To: freebsd-arch@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id D86F437C073; Sun, 2 Jul 2000 17:34:29 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Sun, 2 Jul 2000 20:34:28 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Andrzej Bialecki Cc: dfr@freebsd.org, jlemon@freebsd.org, freebsd-arch@freebsd.org Subject: Re: UPDATE: Re: Dynamic sysctls, next round (please review) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 3 Jul 2000, Andrzej Bialecki wrote: > On Sun, 2 Jul 2000, Brian Fundakowski Feldman wrote: > > > On Sun, 2 Jul 2000, Andrzej Bialecki wrote: > > > * module B is left with subtree hanging in void: > > > -static_root > > > NOTHING! > > > -node2(1) > > > -leaf2(1) > > > > > > I don't have any good solution for it right now, except to warn users that > > > they should always hang their subtrees off of static nodes. :-( > > > > There's already a good solution for this: you must always MODULE_DEPEND() > > upon the owner of a node which you hang things from :) Now, we just need > > to make sure each node is created by a module which you can MODULE_DEPEND() > > on, and that's not too hard! > > I don't think this is relevant here. See the example (which is BTW a > module, but doesn't need to be) provided with the patches. The granularity > of dependancy is *per context*, not per module - in fact, the code that > creates dynamic sysctls doesn't have to be a module, and it can create > multiple contexts. I'm not understanding something here. Why would you want to add nodes to a dynamically created node when you don't know who created the node? If you don't know who created the node, you don't know whether it's appropriate to add your oids to it; if you do know who created it, you should be doing a MODULE_DEPEND() on them anyway. If you're the one creating that node, then you should be depended on, so why would you want two modules which both create the same node? I really can't see why you'd realistically want to do that and therefore need the context. > The latest patches provide a working solution to this - perhaps not > beautiful, but still something... Overall, it's quite good :) but I still have some issues with it. Other than indentation style, which I'm quite willing to fix for you if you'd like, there are some strange things. Why M_SYSCTL1? If anything, I'd name it M_SYSCTLOID. What's the point of all of the KASSERT()s against NULL? The system will crash in either case. Why was const removed from const char *oid_name? You still don't want anything modifying the contents of *oid_name. int ref should really be unsigned int oid_refcnt. Why do you want SYSCTL_CTX_* macros exactly? The SYSCTL_CTX_CREATE() one is broken, but I don't see the need for it anyway, and it encourages the MALLOC()-like lvalue-in-parameter list idiom which only leads to confusion. As far as the algorithms themselves go and the code, it looks good to me :) I would not be the one to give the final review for sysctl-related things, it does look alright to me. I'd like to have the functionality before 5.0. > BTW. I could limit support for dyn_sysctls to disjoint subtrees > exclusively - but I think the ability to have partially overlapping trees > is attractive enough to justify small overhead of traversing the tailq's > several times... I wouldn't worry about performance issues that are only applicable to the actual addition and deletion of nodes, and not the lookup :) > 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-arch" in the body of the message > -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 2 23: 1:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gateway.posi.net (c1096725-a.smateo1.sfba.home.com [24.20.139.104]) by hub.freebsd.org (Postfix) with ESMTP id 89B6537B797; Sun, 2 Jul 2000 23:01:30 -0700 (PDT) (envelope-from kbyanc@posi.net) Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.9.3/8.9.3) with ESMTP id XAA08696; Sun, 2 Jul 2000 23:02:42 -0700 (PDT) (envelope-from kbyanc@posi.net) Date: Sun, 2 Jul 2000 23:02:41 -0700 (PDT) From: Kelly Yancey To: Andrzej Bialecki Cc: dfr@FreeBSD.ORG, jlemon@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: UPDATE: Re: Dynamic sysctls, next round (please review) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 2 Jul 2000, Andrzej Bialecki wrote: > Hi, > > Ok, I think I solved all bad scenarios (described in the message at the > end). Instead of implementing some complex referencing mechanism, I just > added a possibility to do "safe delete" of context, so that it's possible > to rollback the changes if it fails in the middle. > > I tested that creating partially overlapping subtrees, and deleting them > independently works properly. > > The new patches are available at the same URL: > > http://www.freebsd.org/~abial/dyn_sysctl.tgz > > Please review and send me your comments. Thanks! > I think these look very good and I believe that most of my nits have already been mentioned by Brian. I do have a couple more issues though: It strikes me that the patch actually includes 2 semi-related changes: 1. The ability to create/delete oids at run-time, "dynamic sysctls". 2. Assistance to modules for managing these dynamic sysctls, "contexts". I should think that the former is not dependent on the latter. As such, I think that sysctl_add_oid should be able to accept a NULL clist pointer. Or, better yet, the context code should be completely independent to the extent that if the module wants to use contexts as a convenience for managing their dynamic sysctls, they should call sysctl_add_oid (which knows nothing of contexts now), return the syctl_oid * back, and pass that to the sysctl_ctx_add routine itself. The statements might look something like: oid = sysctl_add_oid(...) sysctl_ctx_add(myctx, oid); Of course, if the module didn't care about the oid handle for anything else, the two calls could be combined into one statement. In any event, I think this is cleaner and makes the purpose of contexts more clear. The other issue is with sysctl_remove_oid: it should never actually remove a node for which at least one child has a reference count > 0. As it stands, sysctl_remove_oid will recursively try to remove child nodes (which may only decrement their reference count to a value still > 0). But it will then proceed to delete the still-referenced children (presumably this was the justification for the warning comment). But this can be solved simply by checking if there are any nodes left after recursion, and if so, do not delete (but return success). Of course, none of this should matter if references counts are maintained correctly (in which case, I simply don't understand why the warning is there at all). But overall, I am looking forward to seeing this get into -current. This is very neat, and I'm already thinking of how it integrates with some sysctl work I've been up to. :) Kelly -- Kelly Yancey - kbyanc@posi.net - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 0:50:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mimer.webgiro.com (mimer.webgiro.com [212.209.29.5]) by hub.freebsd.org (Postfix) with ESMTP id E13B537B80A; Mon, 3 Jul 2000 00:50:14 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by mimer.webgiro.com (Postfix, from userid 66) id 9C1F72DC0B; Mon, 3 Jul 2000 09:55:57 +0200 (CEST) Received: by mx.webgiro.com (Postfix, from userid 1001) id D6C9C7817; Mon, 3 Jul 2000 09:49:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx.webgiro.com (Postfix) with ESMTP id D1AE710E17; Mon, 3 Jul 2000 09:49:54 +0200 (CEST) Date: Mon, 3 Jul 2000 09:49:54 +0200 (CEST) From: Andrzej Bialecki To: Brian Fundakowski Feldman Cc: dfr@freebsd.org, jlemon@freebsd.org, freebsd-arch@freebsd.org Subject: Re: UPDATE: Re: Dynamic sysctls, next round (please review) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 2 Jul 2000, Brian Fundakowski Feldman wrote: > On Mon, 3 Jul 2000, Andrzej Bialecki wrote: > > > On Sun, 2 Jul 2000, Brian Fundakowski Feldman wrote: > > > > > On Sun, 2 Jul 2000, Andrzej Bialecki wrote: > > > > * module B is left with subtree hanging in void: > > > > -static_root > > > > NOTHING! > > > > -node2(1) > > > > -leaf2(1) > > > > > > > > I don't have any good solution for it right now, except to warn users that > > > > they should always hang their subtrees off of static nodes. :-( > > > > > > There's already a good solution for this: you must always MODULE_DEPEND() > > > upon the owner of a node which you hang things from :) Now, we just need > > > to make sure each node is created by a module which you can MODULE_DEPEND() > > > on, and that's not too hard! > > > > I don't think this is relevant here. See the example (which is BTW a > > module, but doesn't need to be) provided with the patches. The granularity > > of dependancy is *per context*, not per module - in fact, the code that > > creates dynamic sysctls doesn't have to be a module, and it can create > > multiple contexts. > > I'm not understanding something here. Why would you want to add nodes to > a dynamically created node when you don't know who created the node? If > you don't know who created the node, you don't know whether it's appropriate > to add your oids to it; if you do know who created it, you should be doing > a MODULE_DEPEND() on them anyway. If you're the one creating that node, > then you should be depended on, so why would you want two modules which > both create the same node? I really can't see why you'd realistically > want to do that and therefore need the context. Hehe.. I don't claim it makes sense to add oids this way - I just wanted to protect the system from mistakes of module programmers. Before, it was easy to panic the system, now it's more difficult. As for the context - I think it's a useful concept even without this inter-dependency issue. If we allow to create sysctl oids on the fly (and deleting them), the context concept helps programmers to easily manage them. > > > The latest patches provide a working solution to this - perhaps not > > beautiful, but still something... > > Overall, it's quite good :) but I still have some issues with it. Other > than indentation style, which I'm quite willing to fix for you if you'd > like, there are some strange things. Why M_SYSCTL1? If anything, I'd > name it M_SYSCTLOID. Indentation is my weak point, true.. :-) M_SYSCTLOID sounds a bit like mongoloid, but I agree it makes more sense. > What's the point of all of the KASSERT()s against > NULL? The system will crash in either case. I planned to remove them later on. Now they provide easy means of identifying the cause. > Why was const removed > from const char *oid_name? To silence the compiler warning: it didn't like assigning and freeing pointers that are const char *. > You still don't want anything modifying the > contents of *oid_name. I'd qualify free(oidp->oid_name, M_SYSCTL1) as modification... > int ref should really be unsigned int oid_refcnt. Yes, that's a good idea. > Why do you want SYSCTL_CTX_* macros exactly? To hide the possible changes of implementation. > The SYSCTL_CTX_CREATE() one > is broken, Why? > but I don't see the need for it anyway, and it encourages the > MALLOC()-like lvalue-in-parameter list idiom which only leads to confusion. Could you elaborate? > As far as the algorithms themselves go and the code, it looks good to me :) > I would not be the one to give the final review for sysctl-related things, Who would? > it does look alright to me. I'd like to have the functionality before 5.0. > > > BTW. I could limit support for dyn_sysctls to disjoint subtrees > > exclusively - but I think the ability to have partially overlapping trees > > is attractive enough to justify small overhead of traversing the tailq's > > several times... > > I wouldn't worry about performance issues that are only applicable to > the actual addition and deletion of nodes, and not the lookup :) Thank you very much for your comments! They are very useful. 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-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 1:35:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id 229B737B80A for ; Mon, 3 Jul 2000 01:35:08 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.13 #1) id 1391h3-0000Eb-00 for arch@FreeBSD.org; Mon, 03 Jul 2000 10:35:05 +0200 From: Sheldon Hearn To: arch@FreeBSD.org Subject: truncate(1) implementation details Date: Mon, 03 Jul 2000 10:35:05 +0200 Message-ID: <904.962613305@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, I'm looking through Alexander Langer's truncate(1) with a view to importing it shortly. I raised some issues with Alexander and he responded with the message below. The issue I'd like feedback on is whether or not truncate(1) should create files given on the command-line when those files do not exist at the time of invocation. My feeling is that truncate should not do so. Alexander's opinion is given in the e-mail message. Any compelling arguments in either direction? Ciao, Sheldon. ------- Forwarded Message Date: Sun, 2 Jul 2000 19:36:44 +0200 From: Alexander Langer To: Sheldon Hearn Subject: Re: cvs commit: truncate - Imported sources Message-ID: <20000702193644.A11353@cichlids.cichlids.com> Thus spake Sheldon Hearn (sheldonh@uunet.co.za): > Drop the -h option. Look at cat and friends for examples. > Simple utilities don't need this. yes > Drop the special case for '?', which is caught by the default > case anyway. yes > Implement usage() properly, as per style(9). aaaah, style(9)! I knew I've read about the proper usage() function style before, but I couldn't remember, where :-)) > Use EXIT_SUCCESS and EXIT_FAILURE for exit() and EX_* for > errx(). yes :) > Also, are you _sure_ the file should be created if it didn't already > exist? I think this is a bad idea. This is a userland interface into > truncate(2), which does _not_ create non-existant files. not sure. It saves a call to touch(1). Hmm. What about -c: Create file if it doesn't exit? (or don't create, depends on the chosen default value). However, please ask -committers or -hackers about that. I'll leave tomorrow. Alex - -- cat: /home/alex/.sig: No such file or directory ------- End of Forwarded Message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 3:14:33 2000 Delivered-To: freebsd-arch@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 86A2B37BEAA for ; Mon, 3 Jul 2000 03:14:28 -0700 (PDT) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.9.3/8.9.3) id MAA60328; Mon, 3 Jul 2000 12:14:26 +0200 (CEST) (envelope-from olli) Date: Mon, 3 Jul 2000 12:14:26 +0200 (CEST) Message-Id: <200007031014.MAA60328@dorifer.heim3.tu-clausthal.de> From: Oliver Fromme To: freebsd-arch@FreeBSD.ORG Reply-To: freebsd-arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details X-Newsgroups: list.freebsd-arch In-Reply-To: <8jpj8m$27nt$1@atlantis.rz.tu-clausthal.de> Organization: Administration TU Clausthal MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: tin/1.4.1-19991201 ("Polish") (UNIX) (FreeBSD/3.4-19991219-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In list.freebsd-arch Sheldon Hearn wrote: > I'm looking through Alexander Langer's truncate(1) with a view to > importing it shortly. Ah. I was considering to submit my own truncate(1) which I've written long time ago. Not needed anymore, it seems. :-) > I raised some issues with Alexander and he responded with the message > below. The issue I'd like feedback on is whether or not truncate(1) > should create files given on the command-line when those files do not > exist at the time of invocation. My implementation of truncate(1) doesn't create files either, because I think it's part of the Unix philosophy to have many simple tools, each for their specific job. The strenght of Unix comes from combining those tools. And we already have touch(1). Furthermore, I wouldn't expect a tool called "truncate" to create a file if it doesn't exist. I'd rather expect it to exit with EX_NOINPUT. It's just the same as "chmod" and similar tools -- those don't create files either (and they don't have an option to do so), but they work on existing files, because that's their job. By the way, does Alexander's implementation handle negative numbers as well (meaning the numbers of bytes to strip from the end of the file)? If not, I'd like to submit a patch for this, as I've found that feature to be extremely useful (e.g. ``truncate -128 foo.mp3'' to strip ID3 junk from mp3 files). 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-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 3:32:57 2000 Delivered-To: freebsd-arch@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id 0676C37C00A for ; Mon, 3 Jul 2000 03:32:52 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.13 #1) id 1393Wz-0001d1-00 for freebsd-arch@FreeBSD.ORG; Mon, 03 Jul 2000 12:32:49 +0200 From: Sheldon Hearn To: freebsd-arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-reply-to: Your message of "Mon, 03 Jul 2000 12:14:26 +0200." <200007031014.MAA60328@dorifer.heim3.tu-clausthal.de> Date: Mon, 03 Jul 2000 12:32:49 +0200 Message-ID: <6262.962620369@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 03 Jul 2000 12:14:26 +0200, Oliver Fromme wrote: > By the way, does Alexander's implementation handle negative numbers > as well (meaning the numbers of bytes to strip from the end of the > file)? If not, I'd like to submit a patch for this, as I've found > that feature to be extremely useful (e.g. ``truncate -128 foo.mp3'' to > strip ID3 junk from mp3 files). I plan to patch his version to allow prepending + and - to the size to indicate a delta rather than an absolute size. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 3:42: 1 2000 Delivered-To: freebsd-arch@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 5D9F037C00A for ; Mon, 3 Jul 2000 03:41:58 -0700 (PDT) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.9.3/8.9.3) id MAA60829; Mon, 3 Jul 2000 12:41:57 +0200 (CEST) (envelope-from olli) Date: Mon, 3 Jul 2000 12:41:57 +0200 (CEST) Message-Id: <200007031041.MAA60829@dorifer.heim3.tu-clausthal.de> From: Oliver Fromme To: freebsd-arch@FreeBSD.ORG Reply-To: freebsd-arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details X-Newsgroups: list.freebsd-arch In-Reply-To: <8jpq5d$2c5o$1@atlantis.rz.tu-clausthal.de> Organization: Administration TU Clausthal MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: tin/1.4.1-19991201 ("Polish") (UNIX) (FreeBSD/3.4-19991219-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In list.freebsd-arch Sheldon Hearn wrote: > I plan to patch his version to allow prepending + and - to the size to > indicate a delta rather than an absolute size. Great! I assume it also supports the usual suffixes ("K" == Kbyte, "M" == Mbyte etc.), right? 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-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 4:16:12 2000 Delivered-To: freebsd-arch@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id 5C52037B5A4 for ; Mon, 3 Jul 2000 04:16:06 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.13 #1) id 1394Cm-0001gu-00 for freebsd-arch@FreeBSD.ORG; Mon, 03 Jul 2000 13:16:00 +0200 From: Sheldon Hearn To: freebsd-arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-reply-to: Your message of "Mon, 03 Jul 2000 12:41:57 +0200." <200007031041.MAA60829@dorifer.heim3.tu-clausthal.de> Date: Mon, 03 Jul 2000 13:16:00 +0200 Message-ID: <6503.962622960@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 03 Jul 2000 12:41:57 +0200, Oliver Fromme wrote: > Great! I assume it also supports the usual suffixes ("K" > Kbyte, "M" Mbyte etc.), right? No. Does yours? Is your source up for grabs? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 6: 1:34 2000 Delivered-To: freebsd-arch@freebsd.org Received: from po4.glue.umd.edu (po4.glue.umd.edu [128.8.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 29BC337B677 for ; Mon, 3 Jul 2000 06:01:31 -0700 (PDT) (envelope-from howardjp@glue.umd.edu) Received: from y.glue.umd.edu (root@y.glue.umd.edu [128.8.10.68]) by po4.glue.umd.edu (8.10.1/8.10.1) with ESMTP id e63D1LP12863; Mon, 3 Jul 2000 09:01:23 -0400 (EDT) Received: from y.glue.umd.edu (sendmail@localhost [127.0.0.1]) by y.glue.umd.edu (8.9.3/8.9.3) with SMTP id JAA03844; Mon, 3 Jul 2000 09:01:21 -0400 (EDT) Received: from localhost (howardjp@localhost) by y.glue.umd.edu (8.9.3/8.9.3) with ESMTP id JAA03840; Mon, 3 Jul 2000 09:01:21 -0400 (EDT) X-Authentication-Warning: y.glue.umd.edu: howardjp owned process doing -bs Date: Mon, 3 Jul 2000 09:01:20 -0400 (EDT) From: James Howard To: Sheldon Hearn Cc: arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-Reply-To: <904.962613305@axl.ops.uunet.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 3 Jul 2000, Sheldon Hearn wrote: > below. The issue I'd like feedback on is whether or not truncate(1) > should create files given on the command-line when those files do not > exist at the time of invocation. It would make sense to have it follow the semantics of the system call and then add a -c to create if nonexistent as Langer suggested. J~ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 6: 6: 8 2000 Delivered-To: freebsd-arch@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id 30C9937C0DF for ; Mon, 3 Jul 2000 06:06:00 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.13 #1) id 1395uq-0007ny-00; Mon, 03 Jul 2000 15:05:36 +0200 From: Sheldon Hearn To: James Howard Cc: arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-reply-to: Your message of "Mon, 03 Jul 2000 09:01:20 -0400." Date: Mon, 03 Jul 2000 15:05:36 +0200 Message-ID: <30005.962629536@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 03 Jul 2000 09:01:20 -0400, James Howard wrote: > It would make sense to have it follow the semantics of the system call and > then add a -c to create if nonexistent as Langer suggested. I'm convinced, but it introduces a problem. Given that it looks like we'll allow '+' or '-' to be prepended to the size argument to allow size changes rather than absolute sizes, what does this mean: truncate -c -1024 nonexistant_file Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 6:10:46 2000 Delivered-To: freebsd-arch@freebsd.org Received: from po4.glue.umd.edu (po4.glue.umd.edu [128.8.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 2325037BC85 for ; Mon, 3 Jul 2000 06:10:43 -0700 (PDT) (envelope-from howardjp@glue.umd.edu) Received: from y.glue.umd.edu (root@y.glue.umd.edu [128.8.10.68]) by po4.glue.umd.edu (8.10.1/8.10.1) with ESMTP id e63DAaP13052; Mon, 3 Jul 2000 09:10:36 -0400 (EDT) Received: from y.glue.umd.edu (sendmail@localhost [127.0.0.1]) by y.glue.umd.edu (8.9.3/8.9.3) with SMTP id JAA04109; Mon, 3 Jul 2000 09:10:36 -0400 (EDT) Received: from localhost (howardjp@localhost) by y.glue.umd.edu (8.9.3/8.9.3) with ESMTP id JAA04105; Mon, 3 Jul 2000 09:10:35 -0400 (EDT) X-Authentication-Warning: y.glue.umd.edu: howardjp owned process doing -bs Date: Mon, 3 Jul 2000 09:10:35 -0400 (EDT) From: James Howard To: Sheldon Hearn Cc: arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-Reply-To: <30005.962629536@axl.ops.uunet.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 3 Jul 2000, Sheldon Hearn wrote: > I'm convinced, but it introduces a problem. Given that it looks like > we'll allow '+' or '-' to be prepended to the size argument to allow > size changes rather than absolute sizes, what does this mean: > > truncate -c -1024 nonexistant_file What does this mean? howardjp@byzantine:~$ ls -l /etc/profile -rw-r--r-- 1 root wheel 963 Sep 6 1999 /etc/profile howardjp@byzantine:~$ truncate -1024 /etc/profile Also, what happens when it is run on a symbolic link or a directory? A block or character device? Jmie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 6:19: 7 2000 Delivered-To: freebsd-arch@freebsd.org Received: from po4.glue.umd.edu (po4.glue.umd.edu [128.8.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 5ECFC37B50C for ; Mon, 3 Jul 2000 06:19:04 -0700 (PDT) (envelope-from howardjp@glue.umd.edu) Received: from y.glue.umd.edu (root@y.glue.umd.edu [128.8.10.68]) by po4.glue.umd.edu (8.10.1/8.10.1) with ESMTP id e63DIvP13170; Mon, 3 Jul 2000 09:18:57 -0400 (EDT) Received: from y.glue.umd.edu (sendmail@localhost [127.0.0.1]) by y.glue.umd.edu (8.9.3/8.9.3) with SMTP id JAA04412; Mon, 3 Jul 2000 09:18:57 -0400 (EDT) Received: from localhost (howardjp@localhost) by y.glue.umd.edu (8.9.3/8.9.3) with ESMTP id JAA04408; Mon, 3 Jul 2000 09:18:57 -0400 (EDT) X-Authentication-Warning: y.glue.umd.edu: howardjp owned process doing -bs Date: Mon, 3 Jul 2000 09:18:57 -0400 (EDT) From: James Howard To: Sheldon Hearn Cc: arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 3 Jul 2000, Sheldon Hearn wrote: > I'm convinced, but it introduces a problem. Given that it looks like > we'll allow '+' or '-' to be prepended to the size argument to allow > size changes rather than absolute sizes, what does this mean: > > truncate -c -1024 nonexistant_file Hey, while I am at it, can I argue that this should be truncate -s +1024 x; truncate -s -1024 y head(1) and tail(1) don't even acknowledge that head -10; tail -10 works because they have been depreciated for a number of years. It would be silly to reintroduce that symantic. Jamie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 6:24:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id 1114C37C08C for ; Mon, 3 Jul 2000 06:24:22 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.13 #1) id 1396Cn-0007sK-00; Mon, 03 Jul 2000 15:24:09 +0200 From: Sheldon Hearn To: James Howard Cc: arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-reply-to: Your message of "Mon, 03 Jul 2000 09:10:35 -0400." Date: Mon, 03 Jul 2000 15:24:09 +0200 Message-ID: <30275.962630649@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 03 Jul 2000 09:10:35 -0400, James Howard wrote: > What does this mean? > > howardjp@byzantine:~$ ls -l /etc/profile > -rw-r--r-- 1 root wheel 963 Sep 6 1999 /etc/profile > howardjp@byzantine:~$ truncate -1024 /etc/profile Good point, this is a problem, but it has nothing to do with -c. Do you agree that truncation that would reduce the number of bytes allocated to a file below zero should silently set the file size to zero? > Also, what happens when it is run on a symbolic link or a directory? Allow truncate(2)'s semantics to "shine through", following symbolic links. > A block or character device? Block dewhat? :-) I would have expected truncate(2) to fail with ENOTSUPP on devices, but that's not what the manual page says. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 6:25:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id 93BF037BC85 for ; Mon, 3 Jul 2000 06:25:42 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.13 #1) id 1396E9-0007ss-00; Mon, 03 Jul 2000 15:25:33 +0200 From: Sheldon Hearn To: James Howard Cc: arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-reply-to: Your message of "Mon, 03 Jul 2000 09:18:57 -0400." Date: Mon, 03 Jul 2000 15:25:33 +0200 Message-ID: <30309.962630733@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 03 Jul 2000 09:18:57 -0400, James Howard wrote: > head(1) and tail(1) don't even acknowledge that > > head -10; tail -10 > > works because they have been depreciated for a number of years. It would > be silly to reintroduce that symantic. Can you explain why it's silly in the context of truncate(1), which _must_ take a size as an argument? It's obvious why it's silly for head(1), which needn't be passed a number of lines as an argument. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 6:40:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from po4.glue.umd.edu (po4.glue.umd.edu [128.8.10.124]) by hub.freebsd.org (Postfix) with ESMTP id AD8BE37B680 for ; Mon, 3 Jul 2000 06:40:14 -0700 (PDT) (envelope-from howardjp@glue.umd.edu) Received: from y.glue.umd.edu (root@y.glue.umd.edu [128.8.10.68]) by po4.glue.umd.edu (8.10.1/8.10.1) with ESMTP id e63De6P13545; Mon, 3 Jul 2000 09:40:06 -0400 (EDT) Received: from y.glue.umd.edu (sendmail@localhost [127.0.0.1]) by y.glue.umd.edu (8.9.3/8.9.3) with SMTP id JAA05502; Mon, 3 Jul 2000 09:40:06 -0400 (EDT) Received: from localhost (howardjp@localhost) by y.glue.umd.edu (8.9.3/8.9.3) with ESMTP id JAA05498; Mon, 3 Jul 2000 09:40:06 -0400 (EDT) X-Authentication-Warning: y.glue.umd.edu: howardjp owned process doing -bs Date: Mon, 3 Jul 2000 09:40:06 -0400 (EDT) From: James Howard To: Sheldon Hearn Cc: arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-Reply-To: <30275.962630649@axl.ops.uunet.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 3 Jul 2000, Sheldon Hearn wrote: > Good point, this is a problem, but it has nothing to do with -c. Do you > agree that truncation that would reduce the number of bytes allocated to > a file below zero should silently set the file size to zero? Yes. Maybe a -v to tell us what is happening. Wow, adding options right and left. Of course, if this were done at MIT, we'd have to make sure it could read mail. > Block dewhat? :-) DOH! I forgot those were gone. > I would have expected truncate(2) to fail with ENOTSUPP on devices, but > that's not what the manual page says. Try it on /dev/zero for kicks and see what happens. Jamie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 6:42:17 2000 Delivered-To: freebsd-arch@freebsd.org Received: from po4.glue.umd.edu (po4.glue.umd.edu [128.8.10.124]) by hub.freebsd.org (Postfix) with ESMTP id D3AB837B5B7 for ; Mon, 3 Jul 2000 06:42:11 -0700 (PDT) (envelope-from howardjp@glue.umd.edu) Received: from y.glue.umd.edu (root@y.glue.umd.edu [128.8.10.68]) by po4.glue.umd.edu (8.10.1/8.10.1) with ESMTP id e63Dg4P13576; Mon, 3 Jul 2000 09:42:04 -0400 (EDT) Received: from y.glue.umd.edu (sendmail@localhost [127.0.0.1]) by y.glue.umd.edu (8.9.3/8.9.3) with SMTP id JAA05547; Mon, 3 Jul 2000 09:42:03 -0400 (EDT) Received: from localhost (howardjp@localhost) by y.glue.umd.edu (8.9.3/8.9.3) with ESMTP id JAA05543; Mon, 3 Jul 2000 09:42:03 -0400 (EDT) X-Authentication-Warning: y.glue.umd.edu: howardjp owned process doing -bs Date: Mon, 3 Jul 2000 09:42:03 -0400 (EDT) From: James Howard To: Sheldon Hearn Cc: arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-Reply-To: <30309.962630733@axl.ops.uunet.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 3 Jul 2000, Sheldon Hearn wrote: > Can you explain why it's silly in the context of truncate(1), which > _must_ take a size as an argument? It's obvious why it's silly for > head(1), which needn't be passed a number of lines as an argument. Then the size should merely be the first argument. For instance, it isn't chmod -0666 foo But instead, chmod 0666 foo And this keeps you from having to include the same hack in yet another program to make sure getopt() can handle it. Jamie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 6:43:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id ECA3937B5B7 for ; Mon, 3 Jul 2000 06:43:36 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.13 #1) id 1396VT-0007zu-00; Mon, 03 Jul 2000 15:43:27 +0200 From: Sheldon Hearn To: James Howard Cc: arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-reply-to: Your message of "Mon, 03 Jul 2000 09:40:06 -0400." Date: Mon, 03 Jul 2000 15:43:27 +0200 Message-ID: <30745.962631807@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 03 Jul 2000 09:40:06 -0400, James Howard wrote: > Yes. Maybe a -v to tell us what is happening. Wow, adding options right > and left. None of which would be required if we just didn't create the files. Sometimes, simplicity is elegant. ;-) > > I would have expected truncate(2) to fail with ENOTSUPP on devices, but > > that's not what the manual page says. > > Try it on /dev/zero for kicks and see what happens. Oooh, I was right. It fails on ENOTSUPP. Great, an addition for the truncate(2) manual page. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 6:45:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id DAA4C37B5B7 for ; Mon, 3 Jul 2000 06:45:37 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.13 #1) id 1396XQ-00080p-00; Mon, 03 Jul 2000 15:45:28 +0200 From: Sheldon Hearn To: James Howard Cc: arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-reply-to: Your message of "Mon, 03 Jul 2000 09:42:03 -0400." Date: Mon, 03 Jul 2000 15:45:28 +0200 Message-ID: <30802.962631928@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 03 Jul 2000 09:42:03 -0400, James Howard wrote: > Then the size should merely be the first argument. For instance, it isn't > > chmod -0666 foo > > But instead, > > chmod 0666 foo Um, that's exactly what I'm proposing: truncate -c -1024 nonexistant_file That means lop off 1024 bytes of the file, creating it if it doesn't exist. I used that as an example, but I see now that it was a bad one. The tool won't introduce the size with an option. It'll be a required argument. You agree that this is "normal"? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 6:49: 8 2000 Delivered-To: freebsd-arch@freebsd.org Received: from po4.glue.umd.edu (po4.glue.umd.edu [128.8.10.124]) by hub.freebsd.org (Postfix) with ESMTP id EA54837C28D for ; Mon, 3 Jul 2000 06:48:56 -0700 (PDT) (envelope-from howardjp@glue.umd.edu) Received: from y.glue.umd.edu (root@y.glue.umd.edu [128.8.10.68]) by po4.glue.umd.edu (8.10.1/8.10.1) with ESMTP id e63Dmm013707; Mon, 3 Jul 2000 09:48:49 -0400 (EDT) Received: from y.glue.umd.edu (sendmail@localhost [127.0.0.1]) by y.glue.umd.edu (8.9.3/8.9.3) with SMTP id JAA05741; Mon, 3 Jul 2000 09:48:48 -0400 (EDT) Received: from localhost (howardjp@localhost) by y.glue.umd.edu (8.9.3/8.9.3) with ESMTP id JAA05737; Mon, 3 Jul 2000 09:48:48 -0400 (EDT) X-Authentication-Warning: y.glue.umd.edu: howardjp owned process doing -bs Date: Mon, 3 Jul 2000 09:48:48 -0400 (EDT) From: James Howard To: Sheldon Hearn Cc: arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-Reply-To: <30802.962631928@axl.ops.uunet.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 3 Jul 2000, Sheldon Hearn wrote: > truncate -c -1024 nonexistant_file > > That means lop off 1024 bytes of the file, creating it if it doesn't > exist. I used that as an example, but I see now that it was a bad one. > > The tool won't introduce the size with an option. It'll be a required > argument. You agree that this is "normal"? Okay, yes. I misread it previously. Jamie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 7:26:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id B33E237B88C for ; Mon, 3 Jul 2000 07:26:45 -0700 (PDT) (envelope-from ben@scientia.demon.co.uk) Received: from strontium.scientia.demon.co.uk ([192.168.91.36] ident=exim) by scientia.demon.co.uk with esmtp (Exim 3.15 #1) id 1396PU-00055g-00; Mon, 03 Jul 2000 14:37:16 +0100 Received: (from ben) by strontium.scientia.demon.co.uk (Exim 3.15 #1) id 1396PU-0007ob-00; Mon, 03 Jul 2000 14:37:16 +0100 Date: Mon, 3 Jul 2000 14:37:16 +0100 From: Ben Smithurst To: Sheldon Hearn Cc: arch@FreeBSD.org Subject: Re: truncate(1) implementation details Message-ID: <20000703143716.V48373@strontium.scientia.demon.co.uk> References: <904.962613305@axl.ops.uunet.co.za> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="LG5jgFgJbJFFiAfj" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <904.962613305@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --LG5jgFgJbJFFiAfj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sheldon Hearn wrote: > I raised some issues with Alexander and he responded with the message > below. The issue I'd like feedback on is whether or not truncate(1) > should create files given on the command-line when those files do not > exist at the time of invocation. >=20 > My feeling is that truncate should not do so. Alexander's opinion is > given in the e-mail message. I agree with alex that it should create files iff -c (or something) is given on the command line, and the default should be NOT to create anything. --=20 Ben Smithurst / ben@scientia.demon.co.uk / PGP: 0x99392F7D --LG5jgFgJbJFFiAfj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: Kd0oLNmOLEImLrt6gzGORk6j/9W3kIt6 iQCVAwUBOWCXDCsPVtiZOS99AQGfKwP/UdpGPE2ZCiFRFuJp2PT/PIJ5W9oROj13 Xbrk3ihbt/MjhFfstmFhntfiUvFXdC9nWSqh1lj8U4p02w7W4ziu5c9Ep/ZfZ9af TRdoOcEOkRQgIbqIY2aHOCNLtoz62xH7ehQCfCK2UZJcs48ZloVizw4z+rLriEKG USpoUniXImE= =IyXc -----END PGP SIGNATURE----- --LG5jgFgJbJFFiAfj-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 7:38: 9 2000 Delivered-To: freebsd-arch@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id 8E00337B88C for ; Mon, 3 Jul 2000 07:38:05 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.13 #1) id 1397Lo-0008Rp-00; Mon, 03 Jul 2000 16:37:32 +0200 From: Sheldon Hearn To: Ben Smithurst Cc: arch@FreeBSD.org Subject: Re: truncate(1) implementation details In-reply-to: Your message of "Mon, 03 Jul 2000 14:37:16 +0100." <20000703143716.V48373@strontium.scientia.demon.co.uk> Date: Mon, 03 Jul 2000 16:37:32 +0200 Message-ID: <32476.962635052@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 03 Jul 2000 14:37:16 +0100, Ben Smithurst wrote: > I agree with alex that it should create files iff -c (or something) > is given on the command line, and the default should be NOT to create > anything. Cool. That seems to be agreed all around. So we've got: truncate [-cv] [+|-]size file [...] -c Create files as necessary -v Warn about attempts to truncate below zero bytes where + and - turn the size argument into a delta to be applied, rather than an absolute size. Any objections to this interface? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 9:10:44 2000 Delivered-To: freebsd-arch@freebsd.org Received: from po3.glue.umd.edu (po3.glue.umd.edu [128.8.10.123]) by hub.freebsd.org (Postfix) with ESMTP id 0EE8237B90A for ; Mon, 3 Jul 2000 09:10:41 -0700 (PDT) (envelope-from howardjp@glue.umd.edu) Received: from y.glue.umd.edu (root@y.glue.umd.edu [128.8.10.68]) by po3.glue.umd.edu (8.10.1/8.10.1) with ESMTP id e63GAPb05418; Mon, 3 Jul 2000 12:10:27 -0400 (EDT) Received: from y.glue.umd.edu (sendmail@localhost [127.0.0.1]) by y.glue.umd.edu (8.9.3/8.9.3) with SMTP id MAA13955; Mon, 3 Jul 2000 12:10:25 -0400 (EDT) Received: from localhost (howardjp@localhost) by y.glue.umd.edu (8.9.3/8.9.3) with ESMTP id MAA13951; Mon, 3 Jul 2000 12:10:25 -0400 (EDT) X-Authentication-Warning: y.glue.umd.edu: howardjp owned process doing -bs Date: Mon, 3 Jul 2000 12:10:25 -0400 (EDT) From: James Howard To: Sheldon Hearn Cc: Ben Smithurst , arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-Reply-To: <32476.962635052@axl.ops.uunet.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 3 Jul 2000, Sheldon Hearn wrote: > So we've got: > > truncate [-cv] [+|-]size file [...] > -c Create files as necessary > -v Warn about attempts to truncate below zero bytes > > where + and - turn the size argument into a delta to be applied, rather > than an absolute size. > > Any objections to this interface? Looks good :) Jamie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 10:51:35 2000 Delivered-To: freebsd-arch@freebsd.org Received: from grimreaper.grondar.za (grimreaper.grondar.za [196.7.18.138]) by hub.freebsd.org (Postfix) with ESMTP id A4EA737C192 for ; Mon, 3 Jul 2000 10:51:24 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grimreaper.grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.9.3/8.9.3) with ESMTP id TAA01648; Mon, 3 Jul 2000 19:52:12 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200007031752.TAA01648@grimreaper.grondar.za> To: Sheldon Hearn Cc: arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details References: <30005.962629536@axl.ops.uunet.co.za> In-Reply-To: <30005.962629536@axl.ops.uunet.co.za> ; from Sheldon Hearn "Mon, 03 Jul 2000 15:05:36 +0200." Date: Mon, 03 Jul 2000 19:52:11 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, 03 Jul 2000 09:01:20 -0400, James Howard wrote: > > > It would make sense to have it follow the semantics of the system call and > > then add a -c to create if nonexistent as Langer suggested. > > I'm convinced, but it introduces a problem. Given that it looks like > we'll allow '+' or '-' to be prepended to the size argument to allow > size changes rather than absolute sizes, what does this mean: > > truncate -c -1024 nonexistant_file "Remove no more than 1024 characters from the end of the file; if the file is shorter than that, set the file length to 0." M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 11:24:30 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 46B5537B717 for ; Mon, 3 Jul 2000 11:24:27 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id LAA13477; Mon, 3 Jul 2000 11:24:12 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200007031824.LAA13477@gndrsh.dnsmgr.net> Subject: Re: truncate(1) implementation details In-Reply-To: <32476.962635052@axl.ops.uunet.co.za> from Sheldon Hearn at "Jul 3, 2000 04:37:32 pm" To: sheldonh@uunet.co.za (Sheldon Hearn) Date: Mon, 3 Jul 2000 11:24:12 -0700 (PDT) Cc: ben@scientia.demon.co.uk (Ben Smithurst), arch@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-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > On Mon, 03 Jul 2000 14:37:16 +0100, Ben Smithurst wrote: > > > I agree with alex that it should create files iff -c (or something) > > is given on the command line, and the default should be NOT to create > > anything. > > Cool. That seems to be agreed all around. I've seen conflict on the -c option, some say yes, some say no, so you can't have ``agreed all around'' :-) > So we've got: > > truncate [-cv] [+|-]size file [...] > -c Create files as necessary > -v Warn about attempts to truncate below zero bytes > > where + and - turn the size argument into a delta to be applied, rather > than an absolute size. > > Any objections to this interface? truncate(2) has no way to ``create'' a file, and thus truncate(1) should not either. Also -c has just the opposite meaning on the touch(1) command, probably leading to a POLA violation :-) -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 11:29:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from po4.glue.umd.edu (po4.glue.umd.edu [128.8.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 60DFD37B8AF for ; Mon, 3 Jul 2000 11:29:16 -0700 (PDT) (envelope-from howardjp@glue.umd.edu) Received: from y.glue.umd.edu (root@y.glue.umd.edu [128.8.10.68]) by po4.glue.umd.edu (8.10.1/8.10.1) with ESMTP id e63ISv519816; Mon, 3 Jul 2000 14:28:58 -0400 (EDT) Received: from y.glue.umd.edu (sendmail@localhost [127.0.0.1]) by y.glue.umd.edu (8.9.3/8.9.3) with SMTP id OAA28772; Mon, 3 Jul 2000 14:28:57 -0400 (EDT) Received: from localhost (howardjp@localhost) by y.glue.umd.edu (8.9.3/8.9.3) with ESMTP id OAA28766; Mon, 3 Jul 2000 14:28:56 -0400 (EDT) X-Authentication-Warning: y.glue.umd.edu: howardjp owned process doing -bs Date: Mon, 3 Jul 2000 14:28:56 -0400 (EDT) From: James Howard To: "Rodney W. Grimes" Cc: Sheldon Hearn , Ben Smithurst , arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-Reply-To: <200007031824.LAA13477@gndrsh.dnsmgr.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 3 Jul 2000, Rodney W. Grimes wrote: > truncate(2) has no way to ``create'' a file, and thus truncate(1) > should not either. Also -c has just the opposite meaning on the > touch(1) command, probably leading to a POLA violation :-) POLA? J~ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 11:37:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id BBCB937B532 for ; Mon, 3 Jul 2000 11:37:50 -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.3) with ESMTP id UAA07855; Mon, 3 Jul 2000 20:37:26 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: James Howard Cc: "Rodney W. Grimes" , Sheldon Hearn , Ben Smithurst , arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-reply-to: Your message of "Mon, 03 Jul 2000 14:28:56 EDT." Date: Mon, 03 Jul 2000 20:37:26 +0200 Message-ID: <7853.962649446@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , James How ard writes: >On Mon, 3 Jul 2000, Rodney W. Grimes wrote: > >> truncate(2) has no way to ``create'' a file, and thus truncate(1) >> should not either. Also -c has just the opposite meaning on the >> touch(1) command, probably leading to a POLA violation :-) > >POLA? Principle of least astonishment -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 11:50: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from njord.bart.nl (njord.bart.nl [194.158.170.15]) by hub.freebsd.org (Postfix) with ESMTP id A3B3837BBD2 for ; Mon, 3 Jul 2000 11:49:56 -0700 (PDT) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org (lucifer.is.an.elder.of.the.ninth-circle.org [195.38.216.226]) by njord.bart.nl (8.10.1/8.10.1) with ESMTP id e63InqY14748; Mon, 3 Jul 2000 20:49:52 +0200 (CEST) Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id TAA49416; Mon, 3 Jul 2000 19:54:57 +0200 (CEST) (envelope-from asmodai) Date: Mon, 3 Jul 2000 19:54:56 +0200 From: Jeroen Ruigrok/Asmodai To: Alfred Perlstein Cc: arch@freebsd.org Subject: Re: HEADSUP: Re: name cache size Message-ID: <20000703195456.H35215@daemon.ninth-circle.org> References: <20000702143001.B24321@cs.rice.edu> <20000702135026.P25571@fw.wintelcom.net> <20000702161458.A25129@cs.rice.edu> <20000702141740.S25571@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000702141740.S25571@fw.wintelcom.net>; from bright@wintelcom.net on Sun, Jul 02, 2000 at 02:17:40PM -0700 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000703 00:02], Alfred Perlstein (bright@wintelcom.net) wrote: > >I would like to make this the default in 5.0 so the bugs (if any) can >be worked out. > > sysctl -w vfs.vmiodirenable=1 > >I'm aware of the bloat of the dirsize for the default case, and it's a >bogus argument, we need to be able to cache correctly for performance >reasons. ACK on my side. People with time on their hands might try to find a clean way to drop something like dmalloc/electric fence/boehm-gc in the make world target cleanly. Also, INVARIANTS on by default and /etc/malloc.conf set to some value might be appropriate. I mean, this is CURRENT, we should be doing debugging on a lot of levels. -- Jeroen Ruigrok vd Werven/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project Trying to fool myself with Dreams that never come true... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 12: 4:25 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 39D0537BD15 for ; Mon, 3 Jul 2000 12:04:19 -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.3) with ESMTP id VAA08118; Mon, 3 Jul 2000 21:04:09 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Jeroen Ruigrok/Asmodai Cc: Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: HEADSUP: Re: name cache size In-reply-to: Your message of "Mon, 03 Jul 2000 19:54:56 +0200." <20000703195456.H35215@daemon.ninth-circle.org> Date: Mon, 03 Jul 2000 21:04:09 +0200 Message-ID: <8116.962651049@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Also, INVARIANTS on by default and /etc/malloc.conf set to some value >might be appropriate. Malloc.conf is partly in my court. I counted a concensus for yes, provided 'A' didn't fail on allocation failure. I changed the 'A' semantics that bit, but them ld(1) was hosed with 'J' which I belive is fixed now. The final bit is how to make sure that we don't ship a release with 'J' on by mistake, and since this involves a CFLAG to make world which might have other uses (like INVARIANTS etc) I kind of stalled here... Ideally we should have a #include file which will tell us "CURRENT or RELEASE" and a hack to src/release/Makefile to set it correctly. Any takers ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 13:44:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from dt052n3e.san.rr.com (dt052n3e.san.rr.com [204.210.33.62]) by hub.freebsd.org (Postfix) with ESMTP id B325037C1B9 for ; Mon, 3 Jul 2000 13:44:39 -0700 (PDT) (envelope-from DougB@gorean.org) Received: from gorean.org (doug@master [10.0.0.2]) by dt052n3e.san.rr.com (8.9.3/8.9.3) with ESMTP id NAA89883; Mon, 3 Jul 2000 13:41:55 -0700 (PDT) (envelope-from DougB@gorean.org) Message-ID: <3960FA93.4AE5B9EE@gorean.org> Date: Mon, 03 Jul 2000 13:41:55 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 5.0-CURRENT-0702 i386) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: Ben Smithurst , arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details References: <32476.962635052@axl.ops.uunet.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn wrote: > > On Mon, 03 Jul 2000 14:37:16 +0100, Ben Smithurst wrote: > > > I agree with alex that it should create files iff -c (or something) > > is given on the command line, and the default should be NOT to create > > anything. > > Cool. That seems to be agreed all around. Errr.. no. I agree that truncate(1) should be consistent with truncate(2). Rod also made the excellent point that -c means exactly the opposite in touch than you are proposing here. Even in a script, [ truncate foo ] || touch foo is not that hard to write. > So we've got: > > truncate [-cv] [+|-]size file [...] > -c Create files as necessary > -v Warn about attempts to truncate below zero bytes > > where + and - turn the size argument into a delta to be applied, rather > than an absolute size. Assuming that 'truncate 1024 foo' turns foo into a file with 1024 bytes in the absence of any +/- signs, I don't see anything wrong with the addition of the "delta" business. I'm also assuming that the -v option is only relevant in the presence of the - sign, yes? Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 14:55:29 2000 Delivered-To: freebsd-arch@freebsd.org Received: from server.baldwin.cx (server.geekhouse.net [64.81.6.52]) by hub.freebsd.org (Postfix) with ESMTP id 27A6C37B64B for ; Mon, 3 Jul 2000 14:55:15 -0700 (PDT) (envelope-from john@baldwin.cx) Received: from john.baldwin.cx (root@john.baldwin.cx [192.168.1.18]) by server.baldwin.cx (8.9.3/8.9.3) with ESMTP id OAA29908; Mon, 3 Jul 2000 14:55:13 -0700 (PDT) (envelope-from john@baldwin.cx) Received: (from john@localhost) by john.baldwin.cx (8.9.3/8.9.3) id OAA37008; Mon, 3 Jul 2000 14:56:15 -0700 (PDT) (envelope-from john) Message-Id: <200007032156.OAA37008@john.baldwin.cx> X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <904.962613305@axl.ops.uunet.co.za> Date: Mon, 03 Jul 2000 14:56:15 -0700 (PDT) From: John Baldwin To: Sheldon Hearn Subject: RE: truncate(1) implementation details Cc: arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 03-Jul-00 Sheldon Hearn wrote: > > Hi folks, > > I'm looking through Alexander Langer's truncate(1) with a view to > importing it shortly. > > I raised some issues with Alexander and he responded with the message > below. The issue I'd like feedback on is whether or not truncate(1) > should create files given on the command-line when those files do not > exist at the time of invocation. > > My feeling is that truncate should not do so. Alexander's opinion is > given in the e-mail message. > > Any compelling arguments in either direction? I think it should create the file. touch(1)'s job is just to change the file access and mod times, yet it creates files. Thus, I think there is adequate precedent for truncate(1) creating files. --- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 18:50:35 2000 Delivered-To: freebsd-arch@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 421FA37C53F for ; Mon, 3 Jul 2000 18:50:32 -0700 (PDT) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.9.3/8.9.3) id DAA83143; Tue, 4 Jul 2000 03:50:31 +0200 (CEST) (envelope-from olli) Date: Tue, 4 Jul 2000 03:50:31 +0200 (CEST) Message-Id: <200007040150.DAA83143@dorifer.heim3.tu-clausthal.de> From: Oliver Fromme To: freebsd-arch@FreeBSD.ORG Reply-To: freebsd-arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details X-Newsgroups: list.freebsd-arch In-Reply-To: <8jpso8$2dds$1@atlantis.rz.tu-clausthal.de> Organization: Administration TU Clausthal MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: tin/1.4.1-19991201 ("Polish") (UNIX) (FreeBSD/3.4-19991219-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In list.freebsd-arch Sheldon Hearn wrote: > On Mon, 03 Jul 2000 12:41:57 +0200, Oliver Fromme wrote: > > Great! I assume it also supports the usual suffixes ("K" > > Kbyte, "M" Mbyte etc.), right? > > No. Does yours? Yes. And an -r option to use the size of another file as a reference (similar to the -r option of touch(1)). > Is your source up for grabs? Sure: http://www.fromme.com/truncate/ I just hacked together a small manpage, but I'm not a native English speaker, so it probably needs a bit of editing. 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-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 19:43:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by hub.freebsd.org (Postfix) with ESMTP id DBE6637C266 for ; Mon, 3 Jul 2000 19:43:45 -0700 (PDT) (envelope-from chris@holly.calldei.com) Received: from holly.calldei.com ([208.191.149.190]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FX500JTVJGWJR@mta5.rcsntx.swbell.net> for arch@FreeBSD.ORG; Mon, 3 Jul 2000 21:41:21 -0500 (CDT) Received: (from chris@localhost) by holly.calldei.com (8.9.3/8.9.3) id VAA94774; Mon, 03 Jul 2000 21:41:30 -0500 (CDT envelope-from chris) Date: Mon, 03 Jul 2000 21:41:29 -0500 From: Chris Costello Subject: Re: truncate(1) implementation details In-reply-to: <3960FA93.4AE5B9EE@gorean.org> To: Doug Barton Cc: Sheldon Hearn , Ben Smithurst , arch@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20000703214129.F66762@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <32476.962635052@axl.ops.uunet.co.za> <3960FA93.4AE5B9EE@gorean.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, July 03, 2000, Doug Barton wrote: > Errr.. no. I agree that truncate(1) should be consistent with > truncate(2). Rod also made the excellent point that -c means exactly the > opposite in touch than you are proposing here. Even in a script, > > [ truncate foo ] || touch foo More or less ``touch foo && truncate foo'' accomplishes the same thing as the proposed truncate -c foo. -- |Chris Costello |Computer programmers do it byte by byte. `---------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 20:30:34 2000 Delivered-To: freebsd-arch@freebsd.org Received: from astart2.astart.com (astart2.astart.com [206.71.174.194]) by hub.freebsd.org (Postfix) with ESMTP id 598BB37B5E7 for ; Mon, 3 Jul 2000 20:30:30 -0700 (PDT) (envelope-from papowell@astart.com) Received: from h4.private (papowell@h4.private [10.0.0.4]) by astart2.astart.com (8.9.3/8.9.3) with ESMTP id UAA28679; Mon, 3 Jul 2000 20:32:33 -0700 (PDT) Received: (from papowell@localhost) by h4.private (8.9.3/8.9.3) id UAA07644; Mon, 3 Jul 2000 20:30:04 -0700 (PDT) Date: Mon, 3 Jul 2000 20:30:04 -0700 (PDT) From: papowell@astart.com Message-Id: <200007040330.UAA07644@h4.private> To: arch@FreeBSD.ORG, sheldonh@uunet.co.za Subject: Re: was: Bringing LPRng into FreeBSD? Cc: papowell@astart.com Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From sheldonh@axl.ops.uunet.co.za Mon Jun 26 02:46:32 2000 > From: Sheldon Hearn > To: arch@FreeBSD.ORG > cc: papowell@astart.com > Subject: Re: was: Bringing LPRng into FreeBSD? > Date: Mon, 26 Jun 2000 11:46:23 +0200 > > > Could someone just enumerate the advantages of importing LPRng? It > seems to be a package which can me made to do everything FreeBSD's lpr > can do, but it does not seem to be a superset of FreeBSD's lpr. This > means that there is a cost associated with bringing it in as a > replacement. > > Are we sure that the cost is justified? Is it so much better than the > existing lpr that having it available as a port is "not enough"? > > I have no stsrong opinion one way or the other, but I do get the feeling > that this thread has skipped an important issue, instead focusing on > licensing. This looks like a little cart before horse. > > Ciao, > Sheldon. > 1. Kerberos authentication, as well as PGP, md5, etc. support. 2. Load balancing queues 3. Dynamic routing of jobs 4. Form support 5. Permissions support for printers at the user level 6. Printcap support that allows you to easily use LDAP, NIS++, SQL, or your favorite network database. 7. Diagnostics. 8. More Diagnostics. 9. Did I mention dynamically configurable run time enabled diagnostics? 10. remote lpc administration Patrick Powell To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 20:35:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mercury.mich.com (mercury.mich.com [64.79.64.32]) by hub.freebsd.org (Postfix) with ESMTP id BB93137B9B5 for ; Mon, 3 Jul 2000 20:35:29 -0700 (PDT) (envelope-from will@almanac.yi.org) Received: from argon.gryphonsoft.com (pm002-002.dialup.bignet.net [64.79.80.50]) by mercury.mich.com (8.9.3/8.9.3) with ESMTP id XAA27953; Mon, 3 Jul 2000 23:34:53 -0400 Received: by argon.gryphonsoft.com (Postfix, from userid 1000) id E6A951992; Mon, 3 Jul 2000 23:32:55 -0400 (EDT) Date: Mon, 3 Jul 2000 23:32:55 -0400 From: Will Andrews To: papowell@astart.com Cc: arch@FreeBSD.ORG, sheldonh@uunet.co.za Subject: Re: was: Bringing LPRng into FreeBSD? Message-ID: <20000703233255.E94372@argon.gryphonsoft.com> References: <200007040330.UAA07644@h4.private> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200007040330.UAA07644@h4.private>; from papowell@astart.com on Mon, Jul 03, 2000 at 08:30:04PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 03, 2000 at 08:30:04PM -0700, papowell@astart.com wrote: [ nice list of advantages of lprng ] Would you be happy to import LPRng with a BSD license in the FreeBSD tree? The artistic license + GPL are prohibiting. Someone mentioned that you allowed BSDI to distribute LPRng in BSD/OS with a BSD license; can you not do the same for FreeBSD? -- Will Andrews GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ G++>+++ e->++++ h! r-->+++ y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 22:16:47 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id E5F0E37BB0D for ; Mon, 3 Jul 2000 22:16:44 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (qmail 3440 invoked from network); 4 Jul 2000 05:16:42 -0000 Received: from unknown (HELO bde.zeta.org.au) (203.2.228.102) by gidora.zeta.org.au with SMTP; 4 Jul 2000 05:16:42 -0000 Date: Tue, 4 Jul 2000 15:16:37 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Sheldon Hearn Cc: arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-Reply-To: <904.962613305@axl.ops.uunet.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 3 Jul 2000, Sheldon Hearn wrote: > > Use EXIT_SUCCESS and EXIT_FAILURE for exit() and EX_* for > > errx(). > > yes :) No. Use EXIT_* for errx() too. Magic error exit codes are especially useless when a human-readable error message is printed. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 22:31:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 8DF7137BCF7 for ; Mon, 3 Jul 2000 22:31:41 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 985BB1C6C; Tue, 4 Jul 2000 01:31:40 -0400 (EDT) Date: Tue, 4 Jul 2000 01:31:40 -0400 From: Bill Fumerola To: Bruce Evans Cc: Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details Message-ID: <20000704013140.F4034@jade.chc-chimes.com> References: <904.962613305@axl.ops.uunet.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from bde@zeta.org.au on Tue, Jul 04, 2000 at 03:16:37PM +1000 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 04, 2000 at 03:16:37PM +1000, Bruce Evans wrote: > > > Use EXIT_SUCCESS and EXIT_FAILURE for exit() and EX_* for > > > errx(). > > > > yes :) > > No. Use EXIT_* for errx() too. Magic error exit codes are especially > useless when a human-readable error message is printed. Just to butt into this conversation... I know this from my dealings with the Teachings of Bruce, but style(9) dictates that exit() use the sysexits(3) when appropriate. I can see where people could be confused. -- Bill Fumerola - Network Architect / Computer Horizons Corp - CHIMES e-mail: billf@chimesnet.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 22:42:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 2112A37C24E; Mon, 3 Jul 2000 22:41:51 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Tue, 4 Jul 2000 01:41:34 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Andrzej Bialecki Cc: dfr@freebsd.org, jlemon@freebsd.org, freebsd-arch@freebsd.org Subject: Re: UPDATE: Re: Dynamic sysctls, next round (please review) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 3 Jul 2000, Andrzej Bialecki wrote: > Hehe.. I don't claim it makes sense to add oids this way - I just wanted > to protect the system from mistakes of module programmers. Before, it was > easy to panic the system, now it's more difficult. > > As for the context - I think it's a useful concept even without this > inter-dependency issue. If we allow to create sysctl oids on the fly (and > deleting them), the context concept helps programmers to easily > manage them. Actually, I think you're definitely right :) It's a good thing to have this as a management tool; I was only considering it from the standpoint of it protecting people from depending on things in a wrong way. > > > The latest patches provide a working solution to this - perhaps not > > > beautiful, but still something... > > > > Overall, it's quite good :) but I still have some issues with it. Other > > than indentation style, which I'm quite willing to fix for you if you'd > > like, there are some strange things. Why M_SYSCTL1? If anything, I'd > > name it M_SYSCTLOID. > > Indentation is my weak point, true.. :-) M_SYSCTLOID sounds a bit like > mongoloid, but I agree it makes more sense. Well, I dunno what else I'd call it. I don't really see the point of keeping it as a separate definition from M_SYSCTL except for initial debugging. If you think it's worth keeping for later debugging help (detecting leaks and such, of course) as opposed to just M_SYSCTL, I won't argue there =) > > What's the point of all of the KASSERT()s against > > NULL? The system will crash in either case. > > I planned to remove them later on. Now they provide easy means of > identifying the cause. It's just my anti-bloat feelings that say they shouldn't be there. They don't hurt much, but they really don't help like checking for NULL function pointers does. NULL data pointers are easy to debug, but NULL function pointers... trashing your IP is not fun :( > > Why was const removed > > from const char *oid_name? > > To silence the compiler warning: it didn't like assigning and freeing > pointers that are const char *. Silence those few warnings yourself with casts where it is necessary. The const will prevent mistakes by others later, since they do _not_ have a reason to be modifying oid_name. > > You still don't want anything modifying the > > contents of *oid_name. > > I'd qualify free(oidp->oid_name, M_SYSCTL1) as modification... Well, you can cast it there. It's really an important thing to give the compiler a hint that you don't want other people messing with it. It doesn't change the code here, but only serves as the advisory not to touch the value. It makes it easy to check that noone else is doing evil things to the oid_name later on by grepping for (const char *), as you're the only person who should be doing it, and only in the sysctl implementation proper :) > > int ref should really be unsigned int oid_refcnt. > > Yes, that's a good idea. > > > Why do you want SYSCTL_CTX_* macros exactly? > > To hide the possible changes of implementation. > > > The SYSCTL_CTX_CREATE() one > > is broken, > > Why? Here's an example: if (SYSCTL_CTX_CREATE(ctx) == NULL) return (NULL); expands as such: if (ctx = sysctl_ctx_create() == NULL) return (NULL); The order of operations dictate that this is necessarily equal to: ctx = (sysctl_ctx_create() == NULL); if (ctx != NULL) return (NULL); If sysctl_ctx_create() succeeds here, ctx will be equal to 1 (or some other truth value), and you will panic soon. > > but I don't see the need for it anyway, and it encourages the > > MALLOC()-like lvalue-in-parameter list idiom which only leads to confusion. > > Could you elaborate? The implementation of SYSCTL_CTX_CREATE() defines it as an rvalue, which encourages people to treat it as such, like above. If people do that, the behavior will be incorrect. Now, simply adding parentheses around the macro's definition will fix this specifically. If you don't want people treating it as an rvalue, you should do as is done for all other macros like that, which is to enclose the implementation in a do { } while(0); The idiom is bad because C does not have references (automatic pointers) like C++ (and other languages, of course). SYSCTL_CTX_INIT(&ctx) is okay because you are treating ctx as a normal parameter, where to be modified it must be a pointer. SYSCTL_CTX_CREATE(ctx) is bad because C would not allow passing a struct pointer by reference to do void sysctl_ctx_create(struct sysctl_ctx *&); In C, you would do void sysctl_ctx_create(struct sysctl_ctx **); and pass a pointer to the sysctl_ctx pointer you want filled in. The idiom you're suggesting (references as in C++) suggests that the language would allow modifying of data you did not pass a pointer to. The macros like this are Certified-by-Brian-Evil =] As you have it now, code I write will look like: struct sysctl_ctx *ctxp; SYSCTL_CTX_CREATE(ctxp); /* modification of an argument itself */ That is no better than: struct sysctl_ctx *ctxp; ctxp = sysctl_ctx_create(); Either way, if the implementation changes, you will have the same behavior defined as requisite in the API (keeping a struct sysctl_ctx *). There's no way that the macro SYSCTL_CTX_CREATE() could prevent future API incompatibilities that wouldn't be provided by just using sysctl_ctx_create(). What could possibly change in the future? If you added an argument to sysctl_ctx_create(), then that would be Bad Magic to add that to SYSCTL_CTX_CREATE()'s implementation and blithely accept that the user will have the argument type you want in the name you want by coincidence. You'd have to add another argument to SYSCTL_CTX_CREATE(), changing the API, and SYSCTL_CTX_CREATE() didn't prevent the API from changing. I hope that made sense ;-) > > As far as the algorithms themselves go and the code, it looks good to me :) > > I would not be the one to give the final review for sysctl-related things, > > Who would? Doug Rabson himself would be a good choice. He did most of dynamicism for sysctl, the SLIST tree structure which allows for the runtime expansion. I think dfr is the right guy for reviewing this :) > > it does look alright to me. I'd like to have the functionality before 5.0. > > > > > BTW. I could limit support for dyn_sysctls to disjoint subtrees > > > exclusively - but I think the ability to have partially overlapping trees > > > is attractive enough to justify small overhead of traversing the tailq's > > > several times... > > > > I wouldn't worry about performance issues that are only applicable to > > the actual addition and deletion of nodes, and not the lookup :) > > Thank you very much for your comments! They are very useful. > > 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/ ---- > > > -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 23:10:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from server.baldwin.cx (server.geekhouse.net [64.81.6.52]) by hub.freebsd.org (Postfix) with ESMTP id CD2DB37BB08; Mon, 3 Jul 2000 23:10:21 -0700 (PDT) (envelope-from john@baldwin.cx) Received: from john.baldwin.cx (root@john.baldwin.cx [192.168.1.18]) by server.baldwin.cx (8.9.3/8.9.3) with ESMTP id XAA31833; Mon, 3 Jul 2000 23:10:12 -0700 (PDT) (envelope-from john@baldwin.cx) Received: (from john@localhost) by john.baldwin.cx (8.9.3/8.9.3) id XAA37685; Mon, 3 Jul 2000 23:11:16 -0700 (PDT) (envelope-from john) Message-Id: <200007040611.XAA37685@john.baldwin.cx> X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200007032156.OAA37008@john.baldwin.cx> Date: Mon, 03 Jul 2000 23:11:15 -0700 (PDT) From: John Baldwin To: John Baldwin Subject: RE: truncate(1) implementation details Cc: arch@FreeBSD.ORG, Sheldon Hearn Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 03-Jul-00 John Baldwin wrote: > > On 03-Jul-00 Sheldon Hearn wrote: >> >> Hi folks, >> >> I'm looking through Alexander Langer's truncate(1) with a view to >> importing it shortly. >> >> I raised some issues with Alexander and he responded with the message >> below. The issue I'd like feedback on is whether or not truncate(1) >> should create files given on the command-line when those files do not >> exist at the time of invocation. >> >> My feeling is that truncate should not do so. Alexander's opinion is >> given in the e-mail message. >> >> Any compelling arguments in either direction? > > I think it should create the file. touch(1)'s job is just to change > the file access and mod times, yet it creates files. Thus, I think > there is adequate precedent for truncate(1) creating files. After thinking about this further, since people keep pointing to touch(1)'s -c as a POLA violation wrt to the proposed -c to truncate(1), I think this points out that many people will view touch(1) and truncate(1) similary. Thus, if we really want to be consistent, they should have the same semantics. That is, both utilities will create files by default if they don't exist, and both will abstain from creating non-existent files if '-c' is provided. To me, that is the most consistent way to do it, especially since people are already grouping touch(1) and truncate(1) together. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 3 23:57: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 3802637C295; Mon, 3 Jul 2000 23:57:02 -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.3) with ESMTP id IAA11625; Tue, 4 Jul 2000 08:56:57 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: John Baldwin Cc: arch@FreeBSD.ORG, Sheldon Hearn Subject: Re: truncate(1) implementation details In-reply-to: Your message of "Mon, 03 Jul 2000 23:11:15 PDT." <200007040611.XAA37685@john.baldwin.cx> Date: Tue, 04 Jul 2000 08:56:57 +0200 Message-ID: <11623.962693817@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200007040611.XAA37685@john.baldwin.cx>, John Baldwin writes: >After thinking about this further, since people keep pointing to >touch(1)'s -c as a POLA violation wrt to the proposed -c to >truncate(1), I think this points out that many people will view >touch(1) and truncate(1) similary. Thus, if we really want to be >consistent, they should have the same semantics. That is, both >utilities will create files by default if they don't exist, and >both will abstain from creating non-existent files if '-c' is >provided. To me, that is the most consistent way to do it, >especially since people are already grouping touch(1) and >truncate(1) together. I agree. And for what its worth, I would prefer if they were actually one and the same program, and behaviour was determined by examining argv[0]. That way we avoid future divergence. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 4 0: 5:25 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id 64FAC37C1D1 for ; Tue, 4 Jul 2000 00:05:21 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (qmail 11983 invoked from network); 4 Jul 2000 07:05:18 -0000 Received: from unknown (HELO bde.zeta.org.au) (203.2.228.102) by gidora.zeta.org.au with SMTP; 4 Jul 2000 07:05:18 -0000 Date: Tue, 4 Jul 2000 17:05:13 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: "Jacques A. Vidrine" Cc: Alfred Perlstein , arch@freebsd.org, peter@freebsd.org Subject: Re: cvs commit: src/include search.h Makefile src/lib/libc/stdlib tdelete.c tfind.c tsearch.3 tsearch.c twalk.c Makefile.inc In-Reply-To: <20000701140842.A97167@bone.nectar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 1 Jul 2000, Jacques A. Vidrine wrote: > [btw, SUSv2 can be found at http://www.opengroup.com, among other > things] > > On Sat, Jul 01, 2000 at 10:19:19AM -0700, Alfred Perlstein wrote: > > part 2) > > repo copy the files insque.3 insque.c lsearch.3 lsearch.c and remque.c > > from src/lib/libcompat/4.3/ into src/lib/libc/stdlib and fixup the > > Makefiles. > > SUSv2 says: > insque, remque --- stdlib.h These were deprecated long ago. From our old man page: DESCRIPTION The insque and remque functions are considered obsolete. They are available from the compatibility library, libcompat. > > part 4) > > remove bsearch from search.h (it's already in stdlib.h) > > SUSv2 says: > bsearch --- stdlib.h > > And as previously stated, tsearch goes in . > > This seems dumb. I would expect [bhlt]search, at least, to all be in > ... bsearch seems to be odd man out. bsearch is in the ISO Standard C library, so it actually belongs in . Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 4 0:55:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 97B1637B65B; Tue, 4 Jul 2000 00:55:18 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e647tAr17876; Tue, 4 Jul 2000 00:55:10 -0700 (PDT) Date: Tue, 4 Jul 2000 00:55:10 -0700 From: Alfred Perlstein To: Bruce Evans Cc: "Jacques A. Vidrine" , arch@FreeBSD.ORG, peter@FreeBSD.ORG Subject: Re: cvs commit: src/include search.h Makefile src/lib/libc/stdlib tdelete.c tfind.c tsearch.3 tsearch.c twalk.c Makefile.inc Message-ID: <20000704005510.B25571@fw.wintelcom.net> References: <20000701140842.A97167@bone.nectar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from bde@zeta.org.au on Tue, Jul 04, 2000 at 05:05:13PM +1000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Bruce Evans [000704 00:05] wrote: > On Sat, 1 Jul 2000, Jacques A. Vidrine wrote: > > > [btw, SUSv2 can be found at http://www.opengroup.com, among other > > things] > > > > On Sat, Jul 01, 2000 at 10:19:19AM -0700, Alfred Perlstein wrote: > > > part 2) > > > repo copy the files insque.3 insque.c lsearch.3 lsearch.c and remque.c > > > from src/lib/libcompat/4.3/ into src/lib/libc/stdlib and fixup the > > > Makefiles. > > > > SUSv2 says: > > insque, remque --- stdlib.h > > These were deprecated long ago. From our old man page: We may have considered them deprecated, but doesn't the standard tell us we should have it available? I'm really more than open to suggestions for fixing this up, can I get an answer that clearly states what needs to be done? I still would like to ressurect the interfaces from libcompat, would that be wrong considering SUSv2? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 4 1: 1: 9 2000 Delivered-To: freebsd-arch@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id 0583B37B65B for ; Tue, 4 Jul 2000 01:01:06 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.13 #1) id 139NdS-00038e-00; Tue, 04 Jul 2000 10:00:50 +0200 From: Sheldon Hearn To: papowell@astart.com Cc: arch@FreeBSD.ORG Subject: Re: was: Bringing LPRng into FreeBSD? In-reply-to: Your message of "Mon, 03 Jul 2000 20:30:04 MST." <200007040330.UAA07644@h4.private> Date: Tue, 04 Jul 2000 10:00:50 +0200 Message-ID: <12067.962697650@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 03 Jul 2000 20:30:04 MST, papowell@astart.com wrote: > 1. Kerberos authentication, as well as PGP, md5, etc. support. > > 6. Printcap support that allows you to easily use LDAP, > NIS++, SQL, or your favorite network database. With the exception of Kerberos, md5 and NIS, these capabilities make LPRng a prime candidate for being a port. So can we drop this already? :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 4 2:46: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 7477C37B699; Tue, 4 Jul 2000 02:45:56 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (hak.nat.Awfulhak.org [172.31.0.12]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id KAA70191; Tue, 4 Jul 2000 10:45:53 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id JAA03271; Tue, 4 Jul 2000 09:25:45 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200007040825.JAA03271@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Ben Smithurst Cc: James Howard , Brian Somers , freebsd-hackers@FreeBSD.org, brian@hak.lan.Awfulhak.org, freebsd-arch@FreeBSD.org Subject: Re: /etc/security -> /etc/periodic/security ? In-Reply-To: Message from Ben Smithurst of "Tue, 04 Jul 2000 00:17:16 BST." <20000704001716.A13714@strontium.scientia.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Jul 2000 09:25:45 +0100 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ x-posted to -arch to fish for complaints ] > James Howard wrote: > > > On Thu, 29 Jun 2000, Ben Smithurst wrote: > >=20 > >> Try the attached. They haven't been thoroughly tested, but that's what > >> -CURRENT is for, right? :-) I even remembered to update the manual page > >> this time... > >=20 > > This needs to have knobs and stuff located in /etc/defaults/periodic.conf > > Umm, which knobs? I added the only two options the security stuff currently > uses, what else does it need? > > > Also, it would be cool if a security option were made to periodic(8). > > Well, "periodic security" will work as long as /etc/periodic/security > exists, so I guess you just mean the docs need updating? I'll get to > that if someone is actually planning on committing this stuff. Perhaps the best option is to do with the inline security option and just run ``periodic security'' from cron ? I can commit the changes. If you send me some diffs, I'll commit them and then look at introducing {daily,weekly,monthly,security}_silence flags that will silence mails that have nothing to say. Assuming there are no objections that is.... > --=20 > Ben Smithurst / ben@scientia.demon.co.uk / PGP: 0x99392F7D -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 4 3:43:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 1467E37B720 for ; Tue, 4 Jul 2000 03:43:35 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id UAA02450; Tue, 4 Jul 2000 20:43:25 +1000 Date: Tue, 4 Jul 2000 20:43:21 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Alfred Perlstein Cc: arch@FreeBSD.ORG Subject: Re: HEADSUP: Re: name cache size In-Reply-To: <20000702141740.S25571@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 2 Jul 2000, Alfred Perlstein wrote: > * Sitaram Iyer [000702 14:15] wrote: > > Thus, Alfred Perlstein wrote... > > > > how can I increase the size of freebsd's name cache? > > > sysctl -w vfs.vmiodirenable=1 > > > > thanks, that worked. > > I would like to make this the default in 5.0 so the bugs (if any) can > be worked out. > > sysctl -w vfs.vmiodirenable=1 > > I'm aware of the bloat of the dirsize for the default case, and it's a > bogus argument, we need to be able to cache correctly for performance > reasons. The current default is for performance reasons. It may be the wrong space-time tradeoff for systems with enough memory, but I think this is only because caching is poorly implemented in the non-VMIO case (we discard B_MALLOC'ed blocks too soon because we don't invest enough in resources to map them). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 4 3:54:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by hub.freebsd.org (Postfix) with ESMTP id 1DBF737B540; Tue, 4 Jul 2000 03:54:32 -0700 (PDT) (envelope-from se@freebsd.org) Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout1.freenet.de with esmtp (Exim 3.14 #3) id 139QLW-0007Io-00; Tue, 04 Jul 2000 12:54:30 +0200 Received: from a6e0c.pppool.de ([213.6.110.12] helo=StefanEsser.FreeBSD.org) by mx0.freenet.de with esmtp (Exim 3.15 #1) id 139QLT-0006ZR-00; Tue, 04 Jul 2000 12:54:27 +0200 Received: by StefanEsser.FreeBSD.org (Postfix, from userid 200) id CE101C4A; Tue, 4 Jul 2000 12:23:45 +0200 (CEST) Date: Tue, 4 Jul 2000 12:23:45 +0200 From: Stefan Esser To: freebsd-arch@FreeBSD.org Cc: Stefan Esser Subject: [Patch] make test,expr,printf support 64bit integers Message-ID: <20000703184219.A7587@StefanEsser.FreeBSD.org> Reply-To: Stefan Esser Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I want to commit the following changes to test, expr and printf, which extend the integer range supported by them from 32bit signed to 64bit signed. The patches that are appended to this message have been tested (I rebuilt the world a number of times with them and performed some regression tests). The binaries grow by only a few bytes ... The original reason to extend the range was a shell script, which used test on the result of cksum, which generates an unsigned 32bit number. The result can't be passed to expr, test or printf, since it will be out of range of a signed 32bit number, half of the time. The patches do in no way change the normal behaviour of the programs (i.e. if valid 32bit integers are passed as argument). According to Bruce Evans, there is no Posix requirement regarding test and expr, besides that at least 32 bit signed integers be supported. There were replies to my earlier message to -current from Bruce Evans and Sheldon Hearn. Sheldon told me to check with NetBSD, what they think about the patches. Since I am not on any NetBSD list and do not know whom to ask there, I'd prefer, if somebody else asked them (or forwarded this message or named a NetBSD person to contact). Regards, STefan PS: I also fixed a potential buffer overflow in printf, when I was there ... Index: /usr/src/bin/test/test.c =================================================================== RCS file: /usr/cvs/src/bin/test/test.c,v retrieving revision 1.29 diff -u -2 -r1.29 test.c --- /usr/src/bin/test/test.c 1999/12/28 09:34:57 1.29 +++ /usr/src/bin/test/test.c 2000/06/23 15:56:26 @@ -154,4 +154,6 @@ static int isoperand __P((void)); static int getn __P((const char *)); +static quad_t getq __P((const char *)); +static int intcmp __P((const char *, const char *)); static int newerf __P((const char *, const char *)); static int olderf __P((const char *, const char *)); @@ -299,15 +301,15 @@ return strcmp(opnd1, opnd2) > 0; case INTEQ: - return getn(opnd1) == getn(opnd2); + return intcmp(opnd1, opnd2) == 0; case INTNE: - return getn(opnd1) != getn(opnd2); + return intcmp(opnd1, opnd2) != 0; case INTGE: - return getn(opnd1) >= getn(opnd2); + return intcmp(opnd1, opnd2) >= 0; case INTGT: - return getn(opnd1) > getn(opnd2); + return intcmp(opnd1, opnd2) > 0; case INTLE: - return getn(opnd1) <= getn(opnd2); + return intcmp(opnd1, opnd2) <= 0; case INTLT: - return getn(opnd1) < getn(opnd2); + return intcmp(opnd1, opnd2) < 0; case FILNT: return newerf (opnd1, opnd2); @@ -442,4 +444,46 @@ return (int) r; +} + +/* atoi with error detection and 64 bit range */ +static quad_t +getq(s) + const char *s; +{ + char *p; + quad_t r; + + errno = 0; + r = strtoq(s, &p, 10); + + if (errno != 0) + errx(2, "%s: out of range", s); + + while (isspace((unsigned char)*p)) + p++; + + if (*p) + errx(2, "%s: bad number", s); + + return r; +} + +static int +intcmp (s1, s2) + const char *s1, *s2; +{ + quad_t q1, q2; + + + q1 = getq(s1); + q2 = getq(s2); + + if (q1 > q2) + return 1; + + if (q1 < q2) + return -1; + + return 0; } Index: /usr/src/bin/expr/expr.y =================================================================== RCS file: /usr/cvs/src/bin/expr/expr.y,v retrieving revision 1.14 diff -u -2 -r1.14 expr.y --- /usr/src/bin/expr/expr.y 1999/08/27 23:14:22 1.14 +++ /usr/src/bin/expr/expr.y 2000/06/24 12:20:59 @@ -8,4 +8,5 @@ */ +#include #include #include @@ -14,4 +15,5 @@ #include #include +#include enum valtype { @@ -23,5 +25,5 @@ union { char *s; - int i; + quad_t i; } u; } ; @@ -88,5 +90,5 @@ struct val * make_integer (i) -int i; +quad_t i; { struct val *vp; @@ -140,9 +142,9 @@ -int +quad_t to_integer (vp) struct val *vp; { - int i; + quad_t i; if (vp->type == integer) @@ -153,5 +155,5 @@ /* vp->type == numeric_string, make it numeric */ - i = atoi(vp->u.s); + i = strtoq(vp->u.s, (char**)NULL, 10); free (vp->u.s); vp->u.i = i; @@ -174,5 +176,5 @@ } - sprintf (tmp, "%d", vp->u.i); + sprintf (tmp, "%lld", vp->u.i); vp->type = string; vp->u.s = tmp; @@ -240,5 +242,5 @@ if (result->type == integer) - printf ("%d\n", result->u.i); + printf ("%lld\n", result->u.i); else printf ("%s\n", result->u.s); @@ -275,5 +277,5 @@ free_value (a); free_value (b); - return (make_integer (0)); + return (make_integer ((quad_t)0)); } else { free_value (b); @@ -291,9 +293,9 @@ to_string (a); to_string (b); - r = make_integer (strcoll (a->u.s, b->u.s) == 0); + r = make_integer ((quad_t)(strcoll (a->u.s, b->u.s) == 0)); } else { (void)to_integer(a); (void)to_integer(b); - r = make_integer (a->u.i == b->u.i); + r = make_integer ((quad_t)(a->u.i == b->u.i)); } @@ -312,9 +314,9 @@ to_string (a); to_string (b); - r = make_integer (strcoll (a->u.s, b->u.s) > 0); + r = make_integer ((quad_t)(strcoll (a->u.s, b->u.s) > 0)); } else { (void)to_integer(a); (void)to_integer(b); - r= make_integer (a->u.i > b->u.i); + r = make_integer ((quad_t)(a->u.i > b->u.i)); } @@ -333,9 +335,9 @@ to_string (a); to_string (b); - r = make_integer (strcoll (a->u.s, b->u.s) < 0); + r = make_integer ((quad_t)(strcoll (a->u.s, b->u.s) < 0)); } else { (void)to_integer(a); (void)to_integer(b); - r = make_integer (a->u.i < b->u.i); + r = make_integer ((quad_t)(a->u.i < b->u.i)); } @@ -354,9 +356,9 @@ to_string (a); to_string (b); - r = make_integer (strcoll (a->u.s, b->u.s) >= 0); + r = make_integer ((quad_t)(strcoll (a->u.s, b->u.s) >= 0)); } else { (void)to_integer(a); (void)to_integer(b); - r = make_integer (a->u.i >= b->u.i); + r = make_integer ((quad_t)(a->u.i >= b->u.i)); } @@ -375,9 +377,9 @@ to_string (a); to_string (b); - r = make_integer (strcoll (a->u.s, b->u.s) <= 0); + r = make_integer ((quad_t)(strcoll (a->u.s, b->u.s) <= 0)); } else { (void)to_integer(a); (void)to_integer(b); - r = make_integer (a->u.i <= b->u.i); + r = make_integer ((quad_t)(a->u.i <= b->u.i)); } @@ -396,9 +398,9 @@ to_string (a); to_string (b); - r = make_integer (strcoll (a->u.s, b->u.s) != 0); + r = make_integer ((quad_t)(strcoll (a->u.s, b->u.s) != 0)); } else { (void)to_integer(a); (void)to_integer(b); - r = make_integer (a->u.i != b->u.i); + r = make_integer ((quad_t)(a->u.i != b->u.i)); } @@ -418,5 +420,5 @@ } - r = make_integer (a->u.i + b->u.i); + r = make_integer ((quad_t)(a->u.i + b->u.i)); free_value (a); free_value (b); @@ -434,5 +436,5 @@ } - r = make_integer (a->u.i - b->u.i); + r = make_integer ((quad_t)(a->u.i - b->u.i)); free_value (a); free_value (b); @@ -450,5 +452,5 @@ } - r = make_integer (a->u.i * b->u.i); + r = make_integer ((quad_t)(a->u.i * b->u.i)); free_value (a); free_value (b); @@ -470,5 +472,5 @@ } - r = make_integer (a->u.i / b->u.i); + r = make_integer ((quad_t)(a->u.i / b->u.i)); free_value (a); free_value (b); @@ -490,5 +492,5 @@ } - r = make_integer (a->u.i % b->u.i); + r = make_integer ((quad_t)(a->u.i % b->u.i)); free_value (a); free_value (b); @@ -496,7 +498,4 @@ } -#include -#include - struct val * op_colon (a, b) @@ -527,9 +526,9 @@ } else { - v = make_integer (rm[0].rm_eo - rm[0].rm_so); + v = make_integer ((quad_t)(rm[0].rm_eo - rm[0].rm_so)); } } else { if (rp.re_nsub == 0) { - v = make_integer (0); + v = make_integer ((quad_t)0); } else { v = make_str (""); Index: /usr/src/usr.bin/printf/printf.c =================================================================== RCS file: /usr/cvs/src/usr.bin/printf/printf.c,v retrieving revision 1.13 diff -u -2 -r1.13 printf.c --- /usr/src/usr.bin/printf/printf.c 2000/04/20 09:31:54 1.13 +++ /usr/src/usr.bin/printf/printf.c 2000/07/03 16:21:25 @@ -87,5 +87,5 @@ static double getdouble __P((void)); static int getint __P((int *)); -static int getlong __P((long *)); +static int getlong __P((quad_t *)); static char *getstr __P((void)); static char *mklong __P((char *, int)); @@ -215,5 +215,5 @@ } case 'd': case 'i': case 'o': case 'u': case 'x': case 'X': { - long p; + quad_t p; char *f; @@ -250,6 +250,9 @@ len = strlen(str) + 2; + if (len > sizeof copy) + return NULL; + memmove(copy, str, len - 3); - copy[len - 3] = 'l'; + copy[len - 3] = 'q'; copy[len - 2] = ch; copy[len - 1] = '\0'; @@ -339,13 +342,13 @@ int *ip; { - long val; + quad_t val; if (getlong(&val)) return (1); - if (val > INT_MAX) { + if (val < INT_MIN || val > INT_MAX) { warnx3("%s: %s", *gargv, strerror(ERANGE)); return (1); } - *ip = val; + *ip = (int)val; return (0); } @@ -353,7 +356,7 @@ static int getlong(lp) - long *lp; + quad_t *lp; { - long val; + quad_t val; char *ep; @@ -364,5 +367,5 @@ if (strchr(Number, **gargv)) { errno = 0; - val = strtol(*gargv, &ep, 0); + val = strtoq(*gargv, &ep, 0); if (*ep != '\0') { warnx2("%s: illegal number", *gargv, NULL); @@ -370,9 +373,9 @@ } if (errno == ERANGE) - if (val == LONG_MAX) { + if (val == QUAD_MAX) { warnx3("%s: %s", *gargv, strerror(ERANGE)); return (1); } - if (val == LONG_MIN) { + if (val == QUAD_MIN) { warnx3("%s: %s", *gargv, strerror(ERANGE)); return (1); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 4 5:38:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id E2A6637B962 for ; Tue, 4 Jul 2000 05:38:00 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.13 #1) id 139RxZ-0004Jz-00 for freebsd-arch@FreeBSD.ORG; Tue, 04 Jul 2000 14:37:53 +0200 From: Sheldon Hearn To: freebsd-arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details (SUMMARY) Date: Tue, 04 Jul 2000 14:37:53 +0200 Message-ID: <16614.962714273@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've worked on Alexander Langer's version of truncate(1) to get it to the point where it's a useful utility. I'll be submitting patches back to him shortly. Having had some time to reflect, however, I feel that this utility should not be incorporated into the FreeBSD base system. SUSv2 does not mandate this utility, in spite of the fact that the standard mandates things like link(1), unlink(1) and pathchk(1). I feel that this is a good indicator that this utility is not needed often enough to warrant its inclusion. Certainly, it is useful at times. However, I think that it is best left as a port in the sysutils category, for those rare occasions when a shell script's performance needs make the use of head(1)/rm(1) or dd(1) infeasible. Since shell scripts are not generally high-performance tools, I believe that excluding the truncate(1) utility from the base system would be of very little consequence. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 4 6:42:36 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id 0679B37B8D0 for ; Tue, 4 Jul 2000 06:42:20 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (qmail 3585 invoked from network); 4 Jul 2000 13:42:17 -0000 Received: from unknown (HELO bde.zeta.org.au) (203.2.228.102) by gidora.zeta.org.au with SMTP; 4 Jul 2000 13:42:17 -0000 Date: Tue, 4 Jul 2000 23:42:12 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Alfred Perlstein Cc: arch@freebsd.org, peter@freebsd.org Subject: Re: cvs commit: src/include search.h Makefile src/lib/libc/stdlib tdelete.c tfind.c tsearch.3 tsearch.c twalk.c Makefile.inc In-Reply-To: <20000701101919.I25571@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 1 Jul 2000, Alfred Perlstein wrote: > part 2) > repo copy the files insque.3 insque.c lsearch.3 lsearch.c and remque.c > from src/lib/libcompat/4.3/ into src/lib/libc/stdlib and fixup the > Makefiles. > > part 3) > remove repo copied items from libcompat and fixup the manpages, the > interfaces are not obsolete, they are required by SUSv2. Some were deprecated, and should remain so. (What next? SUSv2 even has [efg]cvt, which became obsolete when sprintf() was fully specified.) > I also need feedback to know where this is incorrect and where > to actually dump the files if not libc/stdlib. Maybe libc/compat-susv2, libc/tsearch (for the tsearch routines only), or even libc/gen. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 4 7:34:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 27C1537B8B0 for ; Tue, 4 Jul 2000 07:34:19 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id HAA21528; Tue, 4 Jul 2000 07:33:25 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda21526; Tue Jul 4 07:33:07 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id HAA15641; Tue, 4 Jul 2000 07:33:07 -0700 (PDT) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdR15639; Tue Jul 4 07:32:15 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.10.2/8.9.1) id e64EWE507332; Tue, 4 Jul 2000 07:32:14 -0700 (PDT) Message-Id: <200007041432.e64EWE507332@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdUJ7328; Tue Jul 4 07:31:49 2000 X-Mailer: exmh version 2.1.1 10/15/1999 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.0-STABLE X-Sender: cy To: chris@calldei.com Cc: Doug Barton , Sheldon Hearn , Ben Smithurst , arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-reply-to: Your message of "Mon, 03 Jul 2000 21:41:29 CDT." <20000703214129.F66762@holly.calldei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Jul 2000 07:31:49 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000703214129.F66762@holly.calldei.com>, Chris Costello writes: > On Monday, July 03, 2000, Doug Barton wrote: > > Errr.. no. I agree that truncate(1) should be consistent with > > truncate(2). Rod also made the excellent point that -c means exactly the > > opposite in touch than you are proposing here. Even in a script, > > > > [ truncate foo ] || touch foo > > More or less ``touch foo && truncate foo'' accomplishes the > same thing as the proposed truncate -c foo. As one who writes shell scripts in order to reduce the overhead of forks and execs that are absolutely necessary, why not a -c option? For those who don't want a -c option, just don't use the option. What could be simpler? I don't see what all the fuss is about. If we need to keep everyone happy, #ifdef it and put the option in make.conf. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 4 8:40:17 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id C320437B976 for ; Tue, 4 Jul 2000 08:40:12 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id BAA19328; Wed, 5 Jul 2000 01:39:49 +1000 Date: Wed, 5 Jul 2000 01:39:45 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Bill Fumerola Cc: Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-Reply-To: <20000704013140.F4034@jade.chc-chimes.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 4 Jul 2000, Bill Fumerola wrote: > On Tue, Jul 04, 2000 at 03:16:37PM +1000, Bruce Evans wrote: > > > > > Use EXIT_SUCCESS and EXIT_FAILURE for exit() and EX_* for > > > > errx(). > > > > > > yes :) > > > > No. Use EXIT_* for errx() too. Magic error exit codes are especially > > useless when a human-readable error message is printed. > > Just to butt into this conversation... > > I know this from my dealings with the Teachings of Bruce, but style(9) > dictates that exit() use the sysexits(3) when appropriate. > > I can see where people could be confused. This is a bug in style(9) IMHO. It was introduced in rev.1.5: | Index: style.9 | =================================================================== | RCS file: /home/ncvs/src/share/man/man9/style.9,v | retrieving revision 1.4 | retrieving revision 1.5 | diff -r1.4 -r1.5 | 216,221c238,247 | < | < /* | < * Exits should be 0 on success, and 1 on failure. Don't denote | < * all the possible exit points, using the integers 1 through 300. | < */ | < exit(0); /* Avoid obvious comments such as "Exit 0 on success." */ | --- | > .Ed | > .Pp | > Exits should be 0 on success, or according to the predefined | > values in | > .Xr sysexits 3 . | > .Bd -literal -offset 0i | > exit(EX_OK); /* | > * Avoid obvious comments such as | > * "Exit 0 on success." | > */ Other bugs in this include uglier formatting of the comment and the comment no longer echoing the code. In 4.4BSDLite-2, is only used in rmail, mail.local, sccs, and in a few contrib'ed sources (bind, kermit, rcs, rtld and mh). Similarly in BSD/OS4.1. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 4 8:58:46 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 043D137B585; Tue, 4 Jul 2000 08:58:41 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id BAA20018; Wed, 5 Jul 2000 01:58:34 +1000 Date: Wed, 5 Jul 2000 01:58:30 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Brian Fundakowski Feldman Cc: Andrzej Bialecki , dfr@FreeBSD.ORG, jlemon@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: UPDATE: Re: Dynamic sysctls, next round (please review) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 4 Jul 2000, Brian Fundakowski Feldman wrote: > On Mon, 3 Jul 2000, Andrzej Bialecki wrote: > > > What's the point of all of the KASSERT()s against > > > NULL? The system will crash in either case. > > > > I planned to remove them later on. Now they provide easy means of > > identifying the cause. > > It's just my anti-bloat feelings that say they shouldn't be there. They > don't hurt much, but they really don't help like checking for NULL > function pointers does. NULL data pointers are easy to debug, but NULL > function pointers... trashing your IP is not fun :( The caller's IP can easily be recovered from the stack. Trashed IP's for jumps are more interesting. > > > > Why was const removed > > > from const char *oid_name? > > > > To silence the compiler warning: it didn't like assigning and freeing > > pointers that are const char *. To break the compiler warning :-). Actually to lose the protection of declaring the string as const. Since dynamically allocated strings aren't const, this seems to be the least of evils. > Silence those few warnings yourself with casts where it is necessary. The > const will prevent mistakes by others later, since they do _not_ have a > reason to be modifying oid_name. -Wcast-qual prevents breaking the warning using a cast :-). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 4 9: 0:17 2000 Delivered-To: freebsd-arch@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id CD00A37B6CD for ; Tue, 4 Jul 2000 09:00:12 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.13 #1) id 139V6y-0004nK-00; Tue, 04 Jul 2000 17:59:48 +0200 From: Sheldon Hearn To: Bruce Evans Cc: Bill Fumerola , arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-reply-to: Your message of "Wed, 05 Jul 2000 01:39:45 +1000." Date: Tue, 04 Jul 2000 17:59:48 +0200 Message-ID: <18433.962726388@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 05 Jul 2000 01:39:45 +1000, Bruce Evans wrote: > This is a bug in style(9) IMHO. It was introduced in rev.1.5: What would you like it to say? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 4 9:38: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id B7C8B37B585 for ; Tue, 4 Jul 2000 09:38:01 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id CAA21507; Wed, 5 Jul 2000 02:37:43 +1000 Date: Wed, 5 Jul 2000 02:37:39 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Sheldon Hearn Cc: Bill Fumerola , arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-Reply-To: <18433.962726388@axl.ops.uunet.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 4 Jul 2000, Sheldon Hearn wrote: > On Wed, 05 Jul 2000 01:39:45 +1000, Bruce Evans wrote: > > > This is a bug in style(9) IMHO. It was introduced in rev.1.5: > > What would you like it to say? Something about EXIT_SUCCESS, EXIT_FAILURE and stdlib.h. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 4 11:15:49 2000 Delivered-To: freebsd-arch@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id 3BC8C37BA28 for ; Tue, 4 Jul 2000 11:15:43 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.13 #1) id 139XEC-00053v-00; Tue, 04 Jul 2000 20:15:24 +0200 From: Sheldon Hearn To: Bruce Evans Cc: Bill Fumerola , arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-reply-to: Your message of "Wed, 05 Jul 2000 02:37:39 +1000." Date: Tue, 04 Jul 2000 20:15:24 +0200 Message-ID: <19462.962734524@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 05 Jul 2000 02:37:39 +1000, Bruce Evans wrote: > Something about EXIT_SUCCESS, EXIT_FAILURE and stdlib.h. So you think that EXIT_{SUCCESS|FAILURE} should be used exclusively, and not the values described in sysexits(3)? I'm not criticising (I realize that the English is ambiguous here), I just want to know what your standpoint is. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 4 13:30:36 2000 Delivered-To: freebsd-arch@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id C05E837BC8E; Tue, 4 Jul 2000 13:30:28 -0700 (PDT) (envelope-from ben@scientia.demon.co.uk) Received: from strontium.scientia.demon.co.uk ([192.168.91.36] ident=exim) by scientia.demon.co.uk with esmtp (Exim 3.15 #1) id 139RUO-0006p8-00; Tue, 04 Jul 2000 13:07:44 +0100 Received: (from ben) by strontium.scientia.demon.co.uk (Exim 3.15 #1) id 139RUO-000Jjj-00; Tue, 04 Jul 2000 13:07:44 +0100 Date: Tue, 4 Jul 2000 13:07:44 +0100 From: Ben Smithurst To: Brian Somers Cc: James Howard , freebsd-hackers@FreeBSD.org, brian@hak.lan.Awfulhak.org, freebsd-arch@FreeBSD.org Subject: Re: /etc/security -> /etc/periodic/security ? Message-ID: <20000704130744.D13714@strontium.scientia.demon.co.uk> References: <200007040825.JAA03271@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="pQhZXvAqiZgbeUkD" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007040825.JAA03271@hak.lan.Awfulhak.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --pQhZXvAqiZgbeUkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Brian Somers wrote: >> Well, "periodic security" will work as long as /etc/periodic/security >> exists, so I guess you just mean the docs need updating? I'll get to >> that if someone is actually planning on committing this stuff. >=20 > Perhaps the best option is to do with the inline security option and=20 > just run ``periodic security'' from cron ? I can commit the changes. I don't think there's really a problem with just running security from daily. I can add a note that this is normal practice in the manpage, and that security shouldn't be run separately unless you set daily_security_enable=3DNO or whatever the option is. --=20 Ben Smithurst / ben@scientia.demon.co.uk / PGP: 0x99392F7D --pQhZXvAqiZgbeUkD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: L2wKgXBd+m0yOO7lHvlBgD76Q3qlfpTM iQCVAwUBOWHTkCsPVtiZOS99AQEJZgP+Ly9fbYQFFKE5Qj+2N2L6I3+1SB5YMA9p dCwXX79Cz8sMHmxVqcm/w6dfvZ34RAZK6HkHZwlixnSXHV2BtxbDD7Uv3p09IbT/ t03D4/chMF2i6w2qbHv/ZzN9LgC51vKA1CHhQ3rnwdQH2OAeyO9QKRFO5XP9E/Jh cCloESlI9/E= =yZ+B -----END PGP SIGNATURE----- --pQhZXvAqiZgbeUkD-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 4 22:39:13 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 389FD37BC4D for ; Tue, 4 Jul 2000 22:39:08 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e655d2X18863; Tue, 4 Jul 2000 22:39:02 -0700 (PDT) Date: Tue, 4 Jul 2000 22:39:02 -0700 From: Alfred Perlstein To: Bruce Evans Cc: arch@FreeBSD.ORG Subject: search.h cleanup (was: Re: cvs commit: src/include search.h) Message-ID: <20000704223902.L25571@fw.wintelcom.net> References: <20000701101919.I25571@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from bde@zeta.org.au on Tue, Jul 04, 2000 at 11:42:12PM +1000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Bruce Evans [000704 06:44] wrote: > On Sat, 1 Jul 2000, Alfred Perlstein wrote: > > > part 2) > > repo copy the files insque.3 insque.c lsearch.3 lsearch.c and remque.c > > from src/lib/libcompat/4.3/ into src/lib/libc/stdlib and fixup the > > Makefiles. > > > > part 3) > > remove repo copied items from libcompat and fixup the manpages, the > > interfaces are not obsolete, they are required by SUSv2. > > Some were deprecated, and should remain so. (What next? SUSv2 even > has [efg]cvt, which became obsolete when sprintf() was fully specified.) > > > I also need feedback to know where this is incorrect and where > > to actually dump the files if not libc/stdlib. > > Maybe libc/compat-susv2, libc/tsearch (for the tsearch routines only), > or even libc/gen. Well they are already imported, in my own defense I did what NetBSD did and put them in libc/stdlib, since it's already in there here's what I'd like to do to clean things up and not ressurect the dead interfaces: Index: include/search.h =================================================================== RCS file: /home/ncvs/src/include/search.h,v retrieving revision 1.1 diff -u -u -r1.1 search.h --- include/search.h 2000/07/01 06:55:11 1.1 +++ include/search.h 2000/07/05 02:29:39 @@ -41,18 +41,21 @@ #endif __BEGIN_DECLS +/* stdlib.h void *bsearch __P((const void *, const void *, size_t, size_t, int (*)(const void *, const void *))); + */ int hcreate __P((size_t)); void hdestroy __P((void)); ENTRY *hsearch __P((ENTRY, ACTION)); - +/* depricated interfaces (in libcompat) void *lfind __P((const void *, const void *, size_t *, size_t, int (*)(const void *, const void *))); void *lsearch __P((const void *, const void *, size_t *, size_t, int (*)(const void *, const void *))); void insque __P((void *, void *)); void remque __P((void *)); + */ void *tdelete __P((const void *, void **, int (*)(const void *, const void *))); Index: lib/libc/db/hash/hsearch.c =================================================================== RCS file: /home/ncvs/src/lib/libc/db/hash/hsearch.c,v retrieving revision 1.2 diff -u -u -r1.2 hsearch.c --- lib/libc/db/hash/hsearch.c 1996/07/21 02:23:02 1.2 +++ lib/libc/db/hash/hsearch.c 2000/07/05 02:30:17 @@ -44,14 +44,14 @@ #include #include -#include "search.h" +#include static DB *dbp = NULL; static ENTRY retval; extern int hcreate(nel) - u_int nel; + size_t nel; { HASHINFO info; cvs diff: lib/libc/db/hash/search.h was removed, no comparison available Is this acceptable? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 5 12:44:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 3CF4537C29C for ; Wed, 5 Jul 2000 12:44:26 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id PAA111276; Wed, 5 Jul 2000 15:44:21 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20000628031106.A29494@mppsystems.com> References: <200006272329.RAA50325@harmony.village.org> <10451.962149487@localhost> <20000627230628.F42285@argon.gryphonsoft.com> <20000628031106.A29494@mppsystems.com> Date: Wed, 5 Jul 2000 15:45:22 -0400 To: Chuck Paterson From: Garance A Drosihn Subject: Re: Bringing LPRng into FreeBSD? Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At Wed, 28 Jun 2000, Chuck Paterson wrote: > Has anyone talked to the author about this? BSDi is planning > on releasing LPRng in the next release. It is in the contrib > section and along with all the other licenses contains a > Berkeley style license. The person doing the integration is > on vacation so I haven't been able to really check on the > details. and later wrote: > I am talking about releasing what is traditionally known as > LPRng in BSD/OS. BSDi has worked with Patrick on integrating > LPRng into BSD/OS. Patrick provided BSDi with a Berkeley style > copyright to go with it. Has the person who is integrating this into BSD/OS returned from vacation yet? I have the impression that the exact details of the licensing will influence many people's vote on the issue of bringing lprNG into freebsd to replace the current lpr. Assuming I have kept track of this thread correctly, I think the above message(s) are the only ones who claim that lprNG will in fact be available as a BSD license, as opposed to the slightly different artistic license. (I am not looking to debate the relative merits of the licenses, I'm just saying that it looks like a genuine BSD license would make this more attractive in some people's eyes, so I want a confirmation on that detail). --- 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-arch" in the body of the message From owner-freebsd-arch Wed Jul 5 14:45:16 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id E91BC37B522 for ; Wed, 5 Jul 2000 14:44:55 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@localhost [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id PAA16708; Wed, 5 Jul 2000 15:44:40 -0600 (MDT) Message-Id: <200007052144.PAA16708@berserker.bsdi.com> X-Mailer: exmh version 2.1.0 09/18/1999 To: Garance A Drosihn Cc: arch@freebsd.org Subject: Re: Bringing LPRng into FreeBSD? From: Chuck Paterson Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_-13623236570" Date: Wed, 05 Jul 2000 15:44:40 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multipart MIME message. --==_Exmh_-13623236570 Content-Type: text/plain; charset=us-ascii Let me re-interate, who ever wants this needs to talk to the author. I talked to our in house person and got a very unsatisfactory answer. It is very unclear what all of the rules. BSDi may be in fact waving some support cost to be able to ship this stuff, but nothing is formalized. I'm pretty sure a piece of paper can rectify the problems with BSD/OS shipping this, but I don't know what FreeBSD can do. I have included both copyrights that are with the stuff. Did the author reply when mail was sent to him? It wasn't clear to me if the mailing list software would allow him to post to the list. Chuck --==_Exmh_-13623236570 Content-Type: text/plain ; name="LICENSE"; charset=us-ascii Content-Description: LICENSE Content-Disposition: attachment; filename="LICENSE" *LPRng and IFHP LICENSE* GNU GPL and Artistic License (Version 4, Jan 24, 2000) Copyright Patrick Powell, Astart Technologies All rights reserved. You may use "LPRng" or "IFHP" under either the terms of the GNU GPL License or the Artistic License. These licenses are included below. These Licenses apply to the computer software packages known as "LPRng", "IFHP", and associated files. The "Package" or "Program" below refers to the programs, files, and associated software which are distributed as the package. The "LPRng" Software Package is a copyrighted work whose copyright is held by Patrick Powell. The "IFHP" Software Package is a copyrighted work whose copyright is held by Patrick Powell. BY MODIFYING OR DISTRIBUTING THE PROGRAM (OR ANY WORK BASED ON THE PROGRAM), YOU INDICATE YOUR ACCEPTANCE OF THIS LICENSE TO DO SO, AND ALL ITS TERMS AND CONDITIONS FOR COPYING, DISTRIBUTING OR MODIFYING THE PROGRAM OR WORKS BASED ON IT. NOTHING OTHER THAN THIS LICENSE GRANTS YOU PERMISSION TO MODIFY OR DISTRIBUTE THE PROGRAM OR ITS DERIVATIVE WORKS. THESE ACTIONS ARE PROHIBITED BY LAW. IF YOU DO NOT ACCEPT THESE TERMS AND CONDITIONS, DO NOT MODIFY OR DISTRIBUTE THE PROGRAM. ----------------------------------------------------------------------- Artistic License The "Artistic License" Preamble The intent of this document is to state the conditions under which a Package may be copied, such that the Copyright Holder maintains some semblance of artistic control over the development of the package, while giving the users of the package the right to use and distribute the Package in a more-or-less customary fashion, plus the right to make reasonable modifications. Definitions: "Package" refers to the collection of files distributed by the Copyright Holder, and derivatives of that collection of files created through textual modification. "Standard Version" refers to such a Package if it has not been modified, or has been modified in accordance with the wishes of the Copyright Holder. "Copyright Holder" is whoever is named in the copyright or copyrights for the package. "You" is you, if you're thinking about copying or distributing this Package. "Reasonable copying fee" is whatever you can justify on the basis of media cost, duplication charges, time of people involved, and so on. (You will not be required to justify it to the Copyright Holder, but only to the computing community at large as a market that must bear the fee.) "Freely Available" means that no fee is charged for the item itself, though there may be fees involved in handling the item. It also means that recipients of the item may redistribute it under the same conditions they received it. 1. You may make and give away verbatim copies of the source form of the Standard Version of this Package without restriction, provided that you duplicate all of the original copyright notices and associated disclaimers. 2. You may apply bug fixes, portability fixes and other modifications derived from the Public Domain or from the Copyright Holder. A Package modified in such a way shall still be considered the Standard Version. 3. You may otherwise modify your copy of this Package in any way, provided that you insert a prominent notice in each changed file stating how and when you changed that file, and provided that you do at least ONE of the following: a) place your modifications in the Public Domain or otherwise make them Freely Available, such as by posting said modifications to Usenet or an equivalent medium, or placing the modifications on a major archive site such as ftp.uu.net, or by allowing the Copyright Holder to include your modifications in the Standard Version of the Package. b) use the modified Package only within your corporation or organization. c) rename any non-standard executables so the names do not conflict with standard executables, which must also be provided, and provide a separate manual page for each non-standard executable that clearly documents how it differs from the Standard Version. d) make other distribution arrangements with the Copyright Holder. 4. You may distribute the programs of this Package in object code or executable form, provided that you do at least ONE of the following: a) distribute a Standard Version of the executables and library files, together with instructions (in the manual page or equivalent) on where to get the Standard Version. b) accompany the distribution with the machine-readable source of the Package with your modifications. c) accompany any non-standard executables with their corresponding Standard Version executables, giving the non-standard executables non-standard names, and clearly documenting the differences in manual pages (or equivalent), together with instructions on where to get the Standard Version. d) make other distribution arrangements with the Copyright Holder. 5. You may charge a reasonable copying fee for any distribution of this Package. You may charge any fee you choose for support of this Package. You may not charge a fee for this Package itself. However, you may distribute this Package in aggregate with other (possibly commercial) programs as part of a larger (possibly commercial) software distribution provided that you do not advertise this Package as a product of your own. 6. The scripts and library files supplied as input to or produced as output from the programs of this Package do not automatically fall under the copyright of this Package, but belong to whomever generated them, and may be sold commercially, and may be aggregated with this Package. 7. C or perl subroutines supplied by you and linked into this Package shall not be considered part of this Package. 8. The name of the Copyright Holder may not be used to endorse or promote products derived from this software without specific prior written permission. 9. THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. This license is based on the Open Source License available from http://www.opensource.org/artistic-license.html ------------------------------------------------------------------ GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 675 Mass Ave, Cambridge, MA 02139, USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations. Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. The precise terms and conditions for copying, distribution and modification follow. GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. 7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. 10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS Appendix: How to Apply These Terms to Your New Programs If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) 19yy This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. Also add information on how to contact you by electronic and paper mail. If the program is interactive, make it output a short notice like this when it starts in an interactive mode: Gnomovision version 69, Copyright (C) 19yy name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker. , 1 April 1989 Ty Coon, President of Vice This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License. --==_Exmh_-13623236570 Content-Type: text/plain ; name="COPYRIGHT"; charset=us-ascii Content-Description: COPYRIGHT Content-Disposition: attachment; filename="COPYRIGHT" COPYRIGHT NOTICES Copyright (c) 1986-2000 Patrick Powell 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 AUTHORS 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. Copyright 1986-2000, Patrick Powell, San Diego, CA. All rights reserved. The following notice is included to satisfy the requirements of the BSD 4.4 Software Distribution. Copyright (c) 1988 The Regents of the University of California. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Berkeley and its contributors. 4. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE REGENTS 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 REGENTS 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. --==_Exmh_-13623236570-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 5 15:13:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 5CB3E37B55B for ; Wed, 5 Jul 2000 15:13:28 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@localhost [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id QAA17010; Wed, 5 Jul 2000 16:13:24 -0600 (MDT) Message-Id: <200007052213.QAA17010@berserker.bsdi.com> Cc: Garance A Drosihn , arch@freebsd.org Subject: Re: Bringing LPRng into FreeBSD? From: Chuck Paterson Date: Wed, 05 Jul 2000 16:13:23 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chuck Paterson wrote on: Wed, 05 Jul 2000 15:44:40 MDT } Let me re-interate, who ever wants this needs to talk "re-interate", "who ever" Gag. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 5 17: 3:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from camus.cybercable.fr (camus.cybercable.fr [212.198.0.200]) by hub.freebsd.org (Postfix) with SMTP id EFCEE37B901 for ; Wed, 5 Jul 2000 17:03:51 -0700 (PDT) (envelope-from root@gits.dyndns.org) Received: (qmail 8984221 invoked from network); 6 Jul 2000 00:03:49 -0000 Received: from r224m65.cybercable.tm.fr (HELO gits.dyndns.org) ([195.132.224.65]) (envelope-sender ) by camus.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 6 Jul 2000 00:03:49 -0000 Received: (from root@localhost) by gits.dyndns.org (8.9.3/8.9.3) id CAA13316; Thu, 6 Jul 2000 02:03:48 +0200 (CEST) (envelope-from root) Posted-Date: Thu, 6 Jul 2000 02:03:48 +0200 (CEST) To: Stefan Esser Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [Patch] make test,expr,printf support 64bit integers References: <20000703184219.A7587@StefanEsser.FreeBSD.org> Reply-To: clefevre@citeweb.net X-Face: V|+c;4!|B?E%BE^{E6);aI.[<97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7@+30g0YD0*^^3jgyShN7o?a]C la*Zv'5NA,=963bM%J^o]C From: Cyrille Lefevre Date: 06 Jul 2000 02:03:48 +0200 In-Reply-To: Stefan Esser's message of "Tue, 4 Jul 2000 12:23:45 +0200" Message-ID: Lines: 91 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Canyonlands" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Stefan Esser writes: > Index: /usr/src/usr.bin/printf/printf.c > =================================================================== > RCS file: /usr/cvs/src/usr.bin/printf/printf.c,v > retrieving revision 1.13 > diff -u -2 -r1.13 printf.c > --- /usr/src/usr.bin/printf/printf.c 2000/04/20 09:31:54 1.13 > +++ /usr/src/usr.bin/printf/printf.c 2000/07/03 16:21:25 > @@ -87,5 +87,5 @@ > static double getdouble __P((void)); > static int getint __P((int *)); > -static int getlong __P((long *)); > +static int getlong __P((quad_t *)); ^^^^^^^ getquad > static char *getstr __P((void)); > static char *mklong __P((char *, int)); > @@ -215,5 +215,5 @@ > } > case 'd': case 'i': case 'o': case 'u': case 'x': case 'X': { > - long p; > + quad_t p; > char *f; > > @@ -250,6 +250,9 @@ > > len = strlen(str) + 2; > + if (len > sizeof copy) > + return NULL; > + > memmove(copy, str, len - 3); > - copy[len - 3] = 'l'; > + copy[len - 3] = 'q'; > copy[len - 2] = ch; > copy[len - 1] = '\0'; > @@ -339,13 +342,13 @@ > int *ip; > { > - long val; > + quad_t val; > > if (getlong(&val)) ^^^^^^^ getquad > return (1); > - if (val > INT_MAX) { > + if (val < INT_MIN || val > INT_MAX) { > warnx3("%s: %s", *gargv, strerror(ERANGE)); > return (1); > } > - *ip = val; > + *ip = (int)val; > return (0); > } > @@ -353,7 +356,7 @@ > static int > getlong(lp) > - long *lp; > + quad_t *lp; > { > - long val; > + quad_t val; > char *ep; > > @@ -364,5 +367,5 @@ > if (strchr(Number, **gargv)) { > errno = 0; > - val = strtol(*gargv, &ep, 0); > + val = strtoq(*gargv, &ep, 0); > if (*ep != '\0') { > warnx2("%s: illegal number", *gargv, NULL); > @@ -370,9 +373,9 @@ > } > if (errno == ERANGE) > - if (val == LONG_MAX) { > + if (val == QUAD_MAX) { > warnx3("%s: %s", *gargv, strerror(ERANGE)); > return (1); > } > - if (val == LONG_MIN) { > + if (val == QUAD_MIN) { > warnx3("%s: %s", *gargv, strerror(ERANGE)); > return (1); IMHO, be consistent w/ naming convention (getlong -> getquad). Regards, Cyrille. -- home:mailto:clefevre@no-spam.citeweb.net Supprimer "no-spam." pour me repondre. work:mailto:Cyrille.Lefevre@no-spam.edf.fr Remove "no-spam." to answer me back. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 5 17: 9:45 2000 Delivered-To: freebsd-arch@freebsd.org Received: from lafontaine.cybercable.fr (lafontaine.cybercable.fr [212.198.0.202]) by hub.freebsd.org (Postfix) with SMTP id 2378837B9D0 for ; Wed, 5 Jul 2000 17:09:35 -0700 (PDT) (envelope-from root@gits.dyndns.org) Received: (qmail 9111121 invoked from network); 6 Jul 2000 00:09:33 -0000 Received: from r224m65.cybercable.tm.fr (HELO gits.dyndns.org) ([195.132.224.65]) (envelope-sender ) by lafontaine.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 6 Jul 2000 00:09:33 -0000 Received: (from root@localhost) by gits.dyndns.org (8.9.3/8.9.3) id CAA13361; Thu, 6 Jul 2000 02:09:32 +0200 (CEST) (envelope-from root) Posted-Date: Thu, 6 Jul 2000 02:09:32 +0200 (CEST) To: Ben Smithurst Cc: Brian Somers , James Howard , freebsd-hackers@FreeBSD.ORG, brian@hak.lan.Awfulhak.org, freebsd-arch@FreeBSD.ORG Subject: Re: /etc/security -> /etc/periodic/security ? References: <200007040825.JAA03271@hak.lan.Awfulhak.org> <20000704130744.D13714@strontium.scientia.demon.co.uk> Reply-To: clefevre@citeweb.net X-Face: V|+c;4!|B?E%BE^{E6);aI.[<97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7@+30g0YD0*^^3jgyShN7o?a]C la*Zv'5NA,=963bM%J^o]C From: Cyrille Lefevre Date: 06 Jul 2000 02:09:32 +0200 In-Reply-To: Ben Smithurst's message of "Tue, 4 Jul 2000 13:07:44 +0100" Message-ID: Lines: 23 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Canyonlands" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ben Smithurst writes: > Brian Somers wrote: > > >> Well, "periodic security" will work as long as /etc/periodic/security > >> exists, so I guess you just mean the docs need updating? I'll get to > >> that if someone is actually planning on committing this stuff. > >=20 > > Perhaps the best option is to do with the inline security option and=20 > > just run ``periodic security'' from cron ? I can commit the changes. > > I don't think there's really a problem with just running security > from daily. I can add a note that this is normal practice in the > manpage, and that security shouldn't be run separately unless you set > daily_security_enable=3DNO or whatever the option is. why not even something like security_enable=[YES|NO] and security_periode=[daily|weekly|monthly] defaulting to daily? Cyrille. -- home:mailto:clefevre@no-spam.citeweb.net Supprimer "no-spam." pour me repondre. work:mailto:Cyrille.Lefevre@no-spam.edf.fr Remove "no-spam." to answer me back. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 5 18: 1: 7 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 9B00337B55B; Wed, 5 Jul 2000 18:00:58 -0700 (PDT) (envelope-from grog@wantadilla.lemis.com) Received: (from grog@localhost) by wantadilla.lemis.com (8.9.3/8.9.3) id KAA00923; Thu, 6 Jul 2000 10:30:51 +0930 (CST) (envelope-from grog) Date: Thu, 6 Jul 2000 10:30:51 +0930 From: Greg Lehey To: Bruce Evans Cc: Alfred Perlstein , arch@FreeBSD.ORG, peter@FreeBSD.ORG Subject: Re: cvs commit: src/include search.h Makefile src/lib/libc/stdlib tdelete.c tfind.c tsearch.3 tsearch.c twalk.c Makefile.inc Message-ID: <20000706103051.W97425@wantadilla.lemis.com> References: <20000701101919.I25571@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 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 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 4 July 2000 at 23:42:12 +1000, Bruce Evans wrote: > On Sat, 1 Jul 2000, Alfred Perlstein wrote: > >> part 2) >> repo copy the files insque.3 insque.c lsearch.3 lsearch.c and remque.c >> from src/lib/libcompat/4.3/ into src/lib/libc/stdlib and fixup the >> Makefiles. >> >> part 3) >> remove repo copied items from libcompat and fixup the manpages, the >> interfaces are not obsolete, they are required by SUSv2. > > Some were deprecated, and should remain so. (What next? SUSv2 even > has [efg]cvt, which became obsolete when sprintf() was fully specified.) They're deprecated in BSD. It seems that they're not in SUSv2. I don't see any problem in leaving things that way. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 5 19:32:57 2000 Delivered-To: freebsd-arch@freebsd.org Received: from astart2.astart.com (astart2.astart.com [206.71.174.194]) by hub.freebsd.org (Postfix) with ESMTP id 3F5E537B811; Wed, 5 Jul 2000 19:32:49 -0700 (PDT) (envelope-from papowell@astart.com) Received: from h4.private (papowell@h4.private [10.0.0.4]) by astart2.astart.com (8.9.3/8.9.3) with ESMTP id TAA38706; Wed, 5 Jul 2000 19:35:11 -0700 (PDT) Received: (from papowell@localhost) by h4.private (8.9.3/8.9.3) id TAA23720; Wed, 5 Jul 2000 19:32:06 -0700 (PDT) Date: Wed, 5 Jul 2000 19:32:06 -0700 (PDT) From: papowell@astart.com Message-Id: <200007060232.TAA23720@h4.private> To: drosih@rpi.edu, imp@village.org Subject: Re: Bringing LPRng into FreeBSD? - License Issues Cc: andrews@technologist.com, arch@FreeBSD.ORG, nik@FreeBSD.ORG, papowell@astart.com, sheldonh@uunet.co.za, will@almanac.yi.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From will@almanac.yi.org Mon Jul 3 20:35:14 2000 > Date: Mon, 3 Jul 2000 23:32:55 -0400 > From: Will Andrews > To: papowell@astart.com > Cc: arch@FreeBSD.ORG, sheldonh@uunet.co.za > Subject: Re: was: Bringing LPRng into FreeBSD? > > On Mon, Jul 03, 2000 at 08:30:04PM -0700, papowell@astart.com wrote: > > [ nice list of advantages of lprng ] > > Would you be happy to import LPRng with a BSD license in the FreeBSD > tree? The artistic license + GPL are prohibiting. > > Someone mentioned that you allowed BSDI to distribute LPRng in BSD/OS > with a BSD license; can you not do the same for FreeBSD? > > -- > Will Andrews > GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- > ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ > G++>+++ e->++++ h! r-->+++ y? > I am surprised at the concern of the licensing issue, so let me explain the development of the LPRng code and how the license issues evolved. If you are not interested in the following topics skip them. But please take the time to read the last one. Here are some questions that seem to be common to the license issue. You can skip most of them, but please read the last one, marked with a *, and please feel free to comment about this. Question: Why the Artistic License? Why the GPL License? Question: Why is BSDi using the BSD license? Question: Why is LPRng not currently under the BSD license? * Question: How would you distribute LPRng under the BSD license? Question: Why the Artistic License? Why the GPL License? The original PLP and LPRng distributions, up until the LPRng 3.5.* release as I recall, were under a variation of the BSD license. At this point in time I started to fold some code that had been provided by some 3rd party folks into the LPRng distribution. Actually, the code had been developed under contract for them, and they indicated that they had no objections about folding them back in. This has resulted in a 'main line' code which is distributed to the public and several 'corporate branches' that contain changes and facilities specific to various organizations that need them. Now, here comes the interesting part. Due to an encounter with some FSF representatives, the folks paying for me to do the various modifications stated that under no circumstances was I to put LPRng main line under GPL come hell, high water, or any other condition until they clarified the terms of the GPL. Apparently there was also some personality conflicts at the highest level that resulted in this dictum. They did not want me to accidentally include their code and have this released under GPL, which would then require them to make the GPL code available. Don't tell me that this is not the case - they had a legal opinion that said that this might be the case, and they could then be in the position of disposing of a corporate asset with no return, and then they would be targets for stockholder lawsuits. Besides, they were paying me a lot of money to do the code development, and I find it very hard to turn down money. One way to avoid this was to remove the API interfaces to their code in the LPRng main line distribution. This was done, and I put LPRng under the GPL about a year ago. Question: Why is BSDi using the BSD license? Answer: They are not. They have a direct license from me to include the binaries and source code in their distribution. In return, they send me the source for their version of the distributions. They do not need to ship source code for their versions or modifications unless they want to. (This satisfies the Artistic License requirements, by the way). Most folks who have included LPRng in their distributions also send me copies of their distributions as well. Question: Why is LPRng not currently under the BSD license? If somebody modifies LPRng and it turns out that the modified vesion has security holes in it, I want to make sure that the version is identfied in the CERT advisory as: 'The FumbleFingerd Corporation's Modified Version of LPRng x.x.x' and not as 'LPRng by Patrick Powell Version x.x.x', and point out the Joe Blortz of FFC made the mods. Now of course, if my baseline code has the flaw then I will not be happy about it, but I will eat crow in public, without salt AND with Louisiana Hot Sauce. This is currently one of the big weaknesses of the BSD license. In my not-so-humble opinion, Sendmail has had a lot of bad press because of the BSD license, mostly because some Major Corporations were using an out of date and buggy version of the Sendmail code, which they had modified, but did not tell what the modifications were, and would not update to a newer version. Now I do not claim that the modificiations were the cause of the problems, but without visibility of the modifications you can spend a lot of time trying to discover the cause of the problem in the baseline code, when this is not the source of the problem at all. ********** Please read and comment ************** Question: How would you distribute LPRng under the BSD license? I would distribute the code under the modified BSD license, but also include the following provision (I am writing this in plain English): If you make additional modifications to this code that are not already present in the source code distribution that you obtained it from, then this must be indicated by providing an additional message in the version and copyright information displayed by the appropriate command and included in the binary distribution. For example: Original LPRng, compiled from the raw distribution: ## lpc -V LPRng-3.6.19, Copyright 1988-2000 Patrick Powell, The FreeBSD Distribution binaries and binaries generated from the FreeBSD modifications to the source would show: ## lpc -V LPRng-3.6.19, Copyright 1988-2000 Patrick Powell, included in FreeBSD Distribution 4.X, 2000-Jan-01, Phil Phumbler And the version that FumbleFingerd made mods to in addition to the FreeBSD would show: ## lpc -V LPRng-3.6.19, Copyright 1988-2000 Patrick Powell, included in: FreeBSD Distribution 4.X, 2000-Jan-01, Phil Phumbler modified by: FumbleFingerd Corp- version 1.10, 2000-Jan-05, I think that this would go a little way to solving problems of tracking what version is used for what system, and where you got the code. I think this is a more global problem and should be added to the general way that 'Open Software' is being promoted. Note: There is NOTHING to prevent folks from going to the LPRng web site, downloading the orginal version, and using this. They could even rip off the patches needed to run under FreeBSD from the FreeBSD distribution code and claim them as their own. Ummm... bit dangerous that. I seem to recall some problems with AT&T and the University of California over something similar. Patrick Powell Astart Technologies, papowell@astart.com 9475 Chesapeake Drive, Suite D, Network and System San Diego, CA 92123 Consulting 858-874-6543 FAX 858-279-8424 LPRng - Print Spooler (http://www.astart.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 5 20:34:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from astart2.astart.com (astart2.astart.com [206.71.174.194]) by hub.freebsd.org (Postfix) with ESMTP id E94CD37B5CD for ; Wed, 5 Jul 2000 20:34:25 -0700 (PDT) (envelope-from papowell@astart.com) Received: from h4.private (papowell@h4.private [10.0.0.4]) by astart2.astart.com (8.9.3/8.9.3) with ESMTP id UAA38828; Wed, 5 Jul 2000 20:36:56 -0700 (PDT) Received: (from papowell@localhost) by h4.private (8.9.3/8.9.3) id UAA23827; Wed, 5 Jul 2000 20:33:51 -0700 (PDT) Date: Wed, 5 Jul 2000 20:33:51 -0700 (PDT) From: papowell@astart.com Message-Id: <200007060333.UAA23827@h4.private> To: sheldonh@uunet.co.za Subject: Re: was: Bringing LPRng into FreeBSD? Cc: andrews@technologist.com, arch@FreeBSD.ORG, papowell@astart.com, will@almanac.yi.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From sheldonh@axl.ops.uunet.co.za Mon Jun 26 02:46:32 2000 > From: Sheldon Hearn > To: arch@FreeBSD.ORG > cc: papowell@astart.com > Subject: Re: was: Bringing LPRng into FreeBSD? > Date: Mon, 26 Jun 2000 11:46:23 +0200 > > > Could someone just enumerate the advantages of importing LPRng? It > seems to be a package which can me made to do everything FreeBSD's lpr > can do, but it does not seem to be a superset of FreeBSD's lpr. This > means that there is a cost associated with bringing it in as a > replacement. > > Are we sure that the cost is justified? Is it so much better than the > existing lpr that having it available as a port is "not enough"? > > I have no stsrong opinion one way or the other, but I do get the feeling > that this thread has skipped an important issue, instead focusing on > licensing. This looks like a little cart before horse. > > Ciao, > Sheldon. > Dear Sheldon and others: A very perceptive question. I have written a small essay presented here which hopefully provides answers to the questions asked in your posting. The Joys of PRINTING Printing is one of the more critical areas in any major computing enterprise or facility. But it is NOT glamorous. Or exciting. Or interesting. So people do work on it only when they are directly effected, or when they need some 'enhanced functionality'. And they quickly forget about it, don't document it, and then the next person that has to deal with printing adds more to this mess. Anybody who has managed large installations knows that the one area where things do not work well is printing, because there are literally dozens of different print spooling systems, no two of which have the same configuration or management methods. The LPRng print spooling software compiles and runs on an extremely wide range of systems. And configures and runs almost identically on all of them (or it should!). If you think that writing a print spooler is simple - it is. MAINTAINING it is a lot of work. Removing some silly little compatibility problem is a lot of work. DOCUMENTING it is a lot of work. And enhancing it to provide additional facilities without breaking other things is a lot of work. I started the work on LPRng with one major goal in mind: make it secure when used in a Computer Science Laboratory. For example, LPRng does not need to run SETUID root unless compatibility with vintage or legacy printing systems such is required. The code is extremely paranoid about all buffer sizes, string lengths, and so forth, and goes to great lengths to check for various know hacker attacks as well. In addition, there are facilities to use encryption and Kerberos based authentication to prevent abuse of the printing system. Another of the goals was to make a system that would not fail under stress. This means that the LPRng system does not start processes, accept connections, or do things when there a limited amount of system resources. This has the side effect of (mostly) preventing LPRng from being used as a simple conduit for DOS attacks. The code was written to be testable and traceable. Over 60% of the code concerns itself with checking error return codes and logging messages for failure conditions. This, of course, has a certain overhead in terms of system size. But the verbose diagnostics are almost always preferable to the print job mysteriously vanishing into limbo and users wondering what happened. Finally, there is the LPRng documenation. It is available in HTML format and is generated from DocBook compatible SGML. In addition, hard copy (PostScript) versions are available as well, all 360 pages of it. This documentation includes a Tutorial and Reference section, as well as an index to the various LPRng facilities. Question: a) Is LPRng better than what we have? LPRng has functionality well beyond that of the current FreeBSD print spooler. The one thing that it has, above all, is the ability to provide diagnostic information. The tracing facilities are, to put it mildly, exhaustive. At least 60% of the code in LPRng is error handling and reporting. Perhaps higher. The LPRng software provides Enterprise level printing facilities. such as the following which are either not in the FreeBSD LPD print spooler or are greatly improved. Load Balance Queues (sometimes call Printer Pooling): You can select which of a set of destination printers by using (default) LRU, or by providing a script that tells the LPRng system which of an available set of printers to use. Authentication - Kerberos, PGP, MD5 The RFC 1179 protocol has little^H^H^H^H^H no authentication facilities. LPRng provides a simple set of hooks to add authentication. A simple scafholding for using Kerberos, PGP, and MD5 authentication is present in the distribution. You can add additional methods by adding or replacing the ones already present. Permissions There is a flexible and extensible mechanism for supporting printer permissions, on the user, host, job, or other basis. This can provide very fine grain control over access to printer facilties. If there is need for highly secure printing, then the Authentication and Permission facilties can be used in combination. Remote administration The 'lpc' command supports remote administration of printers and queues. It has a very versitile set of commands to enable and disable queues, start and stop printing, set serviced job classes, kill, abort, or hold jobs, and perform other administrative functions. Status displays with lots of detail The status displayed by LPRng provides a large amount of detail about the current print queue activities. Needless to say, the short form (lpq -s) provides a succinct summary. For those with a real need to know, the verbose (lpq -v) tells you more than you ever wanted to know. Accounting The accounting system used by LPRng was developed for use in one of the most hostile environments posssible - University Computer Systems facilities. The basic facilities can be used for simple accounting procedures, with the ability to restrict access and record usage of print queues in various manners. Routing Some system benefit from the abilty to have a single queue for printing, and then have the jobs sent to the queue selectively forwarded to the appropriate printer. This is easily supported by the LPRng routing facility. Redirection If a queue or printer is temporarily out of service, jobs can be redirected to an alternate queue by a simple adminitrative command. Form Support Many printer jobs require special setup or forms. LPRng provides support for these jobs in an extremely simple mannner. Job Holding and Releasing Jobs sent to a queue can be held until released. Job Reprinting A queue can be configured to allow jobs to be saved and then reprinted if they have errors or even if they are successful. Diagnostic and Tracing Facilities The diagnostic facilities in LPRng allow extremely detailed tracing of even the most complex jobs. These facilities can be enabled or disabled dynamically by the system adminstrator on a system or print queue level. Question: b) Do we need something better? Is the cost worth the benefits? Just about every site with more than 200 users discovers that their printing facilities do not do exactly what they want. They then assign a new system administrator or programmer to start modifying the legacy printing software to provide the facilities they need. After several iterations of this process nobody knows or understands their current printing system and everybody is afraid that it will break. And when it dies, nobody knows how to fix it. Given the large number of modified (and broken) versions of LPD in existence, there is obviously something lacking from the baseline LPD software. Over the last 10 years the LPRng software has had features and enhancements added to it that reflect the needs of the various sites. Many of these are specialized, but some have had surprisingly wide application. Most users of LPRng find that they can replace their current hand crafted software with LPRng, and run the same software on all the different systems they have, including a wide range of legacy systems. FreeBSD is one of my test platforms. The documentation for LPRng using the DocBook tools which are part of the FreeBSD Documentation Project. If LPRng is adopted for use by FreeBSD, I have stated that I would update and edit the current printing documentation in the FreeBSD Handbook and bring it into line with LPRng. Actually, there is very little that would change, as LPRng is largely backwards compatible at the simple, single user/single printer level covered in the handbook. In addition, I would provide support for the Makefiles and other items which are used as part of the baseline documentation. The LPRng distribution would be able to be compiled and installed using only the basic system utilities including BSD make, perl5, awk, and sed. The benefits are large: you get a much better print spooling system with documentation, and active maintenance. Patrick Powell Astart Technologies, papowell@astart.com 9475 Chesapeake Drive, Suite D, Network and System San Diego, CA 92123 Consulting 858-874-6543 FAX 858-279-8424 LPRng - Print Spooler (http://www.astart.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 5 20:42:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id DEB7937B83D for ; Wed, 5 Jul 2000 20:42:26 -0700 (PDT) (envelope-from mckusick@mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id UAA23667 for ; Wed, 5 Jul 2000 20:42:18 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200007060342.UAA23667@beastie.mckusick.com> To: arch@freebsd.org Subject: Snapshots in the Fast Filesystem Date: Wed, 05 Jul 2000 20:42:18 -0700 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have completed an initial implementation of snapshots for the fast filesystem (UFS/FFS). I have put up a tarball on http://people.freebsd.org/~mckusick/snap.tgz I am looking for comments and feedback on these changes. I am proposing to put them into 5.0-current on Tuesday July 11th unless I get feedback indicating that folks are not happy with this addition. Enclosed below is the README file that is included in the above tarball. Kirk McKusick =-=-=-=-=-=-=-=
Once you have a new kernel running, and new versions of fsck and mount (which a `make world' should provide for you), you are ready to try out snapshots. To create a snapshot of your /var filesystem, run the command: mount -u -o snapshot /var/snapshot/snap1 /var This command will take a snapshot of your /var filesystem and leave it in the file /var/snapshot/snap1. Note that snapshot files must be created in the filesystem that is being snapshotted. I use the convention of putting a `snapshot' directory at the root of each filesystem into which I can place snapshots. You may create up to 20 snapshots per filesystem. Active snapshots are recorded in the superblock, so they persist across unmount and remount operations and across system reboots. When your are done with a snapshot, it can be removed with the `rm' command. Snapshots may be removed in any order, however you may not get back all the space contained in the snapshot as another snapshot may claim some of the blocks that it is releasing. It takes about 30 seconds to create a snapshot of an 8Gb filesystem. Of that time 25 seconds is spent in preparation; filesystem activity is only suspended for the final 5 seconds of that period. Snapshot removal of an 8Gb filesystem takes about two minutes (twenty seconds if you are runnong with soft updates). Filesystem activity is never suspended during snapshot removal. Note that the `schg' flag is set on snapshots to ensure that not even the root user can write to them. The unlink command makes an exception for snapshot files in that it allows them to be removed even though they have the `schg' flag set, so it is not necessary to clear the `schg' flag before removing a snapshot file. Once you have taken a snapshot, there are three interesting things that you can do with it: 1) Run fsck on the snapshot file. Assuming that the filesystem was clean when it was mounted, you should always get a clean (and unchanging) result from running fsck on the snapshot. If you are running with soft updates and rebooted after a crash without cleaning up the filesystem, then fsck of the snapshot may find missing blocks and inodes or inodes with link counts that are too high. I have not yet added the system calls to allow fsck to add these missing resources back to the filesystem - that will be added once the basic snapshot code is working properly. So, view those reports as informational for now. 2) Run dump on the snapshot. You will get a dump that is consistent with the filesystem as of the timestamp of the snapshot. Note that I have not yet changed dump to set the dumpdates file correctly, so do not use this feature in production until that fix is made. 3) Mount the snapshot as a frozen image of the filesystem. To mount the snapshot /var/snapshot/snap1: vnconfig -c vn0c /var/snapshot/snap1 mount -r /dev/vn0c /mnt You can now cruise around your frozen /var filesystem at /mnt. Everything will be in the same state that it was at the time the snapshot was taken. The one exception is that any earlier snapshots will appear as zero length files. When you are done with the mounted snapshot: umount /mnt vnconfig -u vn0c Note that under some circumstances, the process accessing the frozen filesystem may deadlock. I am aware of this problem, but the solution is not simple. It requires using buffer read locks rather than exclusive locks when traversing the inode indirect blocks. Until this problem is fixed, you should avoid putting mounted snapshots into production. So, as you can see, this is definitely alpha-quality code. Much remains to be done to make it really useful in production systems. But, I wanted to let folks get a chance to try it out and start reporting bugs. Kirk McKusick July 5, 2000 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 6 1:20:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by hub.freebsd.org (Postfix) with ESMTP id 2AB9F37B86F for ; Thu, 6 Jul 2000 01:20:08 -0700 (PDT) (envelope-from asami@cs.berkeley.edu) Received: from silvia.hip.berkeley.edu (sji-ca14-12.ix.netcom.com [205.186.215.12]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id EAA05877; Thu, 6 Jul 2000 04:19:51 -0400 (EDT) Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.3/8.6.9) id BAA10041; Thu, 6 Jul 2000 01:18:48 -0700 (PDT) To: Kirk McKusick Cc: arch@freebsd.org Subject: Re: Snapshots in the Fast Filesystem References: <200007060342.UAA23667@beastie.mckusick.com> From: asami@freebsd.org (Satoshi - Ports Wraith - Asami) Date: 06 Jul 2000 01:18:27 -0700 In-Reply-To: Kirk McKusick's message of "Wed, 05 Jul 2000 20:42:18 -0700" Message-ID: Lines: 11 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * From: Kirk McKusick * I have completed an initial implementation of snapshots for the * fast filesystem (UFS/FFS). I have put up a tarball on * * http://people.freebsd.org/~mckusick/snap.tgz Wow, sounds like really great stuff! I wish I had some more machines so I can play with it! ;) Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 6 3: 9:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id 27B1837B85D for ; Thu, 6 Jul 2000 03:09:51 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.15 #1) id 13A8bI-00049J-00 for arch@FreeBSD.org; Thu, 06 Jul 2000 12:09:44 +0200 From: Sheldon Hearn To: arch@FreeBSD.org Subject: Why don't section 4 pages live with their drivers? Date: Thu, 06 Jul 2000 12:09:43 +0200 Message-ID: <15951.962878183@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, I notice that a lot of section 4 manual pages live in src/share/man/man4 instead of in the subdirectory in which the code that implements the associated drivers resides. I realize that many drivers have bits in too many directories for this to be possible. Case in point: I'm about to commit the md.4 manual page of phk's. I would have thought that the right place for it would be src/sys/dev/md, but the precedents which I can see certainly indicates that this would be "wrong". Bottom line: where do I put this thing and if it's not in src/sys/dev/md, why not? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 6 3:12:54 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id EA3D037C248 for ; Thu, 6 Jul 2000 03:12:48 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e66ACb905506; Thu, 6 Jul 2000 03:12:37 -0700 (PDT) Date: Thu, 6 Jul 2000 03:12:37 -0700 From: Alfred Perlstein To: Sheldon Hearn Cc: arch@FreeBSD.ORG Subject: Re: Why don't section 4 pages live with their drivers? Message-ID: <20000706031237.W25571@fw.wintelcom.net> References: <15951.962878183@axl.ops.uunet.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <15951.962878183@axl.ops.uunet.co.za>; from sheldonh@uunet.co.za on Thu, Jul 06, 2000 at 12:09:43PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Sheldon Hearn [000706 03:10] wrote: > > Hi folks, > > I notice that a lot of section 4 manual pages live in src/share/man/man4 > instead of in the subdirectory in which the code that implements the > associated drivers resides. > > I realize that many drivers have bits in too many directories for this > to be possible. > > Case in point: I'm about to commit the md.4 manual page of phk's. I > would have thought that the right place for it would be src/sys/dev/md, > but the precedents which I can see certainly indicates that this would > be "wrong". > > Bottom line: where do I put this thing and if it's not in > src/sys/dev/md, why not? Personally, I prefer to see the manpages alongside the code. (src/sys/dev/md) -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 6 9:49:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 6DE7237B8D8 for ; Thu, 6 Jul 2000 09:49:17 -0700 (PDT) (envelope-from mbendiks@eunet.no) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id SAA83868; Thu, 6 Jul 2000 18:49:14 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id SAA66471; Thu, 6 Jul 2000 18:49:13 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Thu, 6 Jul 2000 18:49:13 +0200 (CEST) From: Marius Bendiksen To: Alfred Perlstein Cc: Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: Why don't section 4 pages live with their drivers? In-Reply-To: <20000706031237.W25571@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Bottom line: where do I put this thing and if it's not in > > src/sys/dev/md, why not? > Personally, I prefer to see the manpages alongside the code. > (src/sys/dev/md) Agree. Perhaps its time to change things to this effect? Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 6 11:38: 8 2000 Delivered-To: freebsd-arch@freebsd.org Received: from njord.bart.nl (njord.bart.nl [194.158.170.15]) by hub.freebsd.org (Postfix) with ESMTP id 531C137B557 for ; Thu, 6 Jul 2000 11:38:05 -0700 (PDT) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org (lucifer.is.an.elder.of.the.ninth-circle.org [195.38.216.226]) by njord.bart.nl (8.10.1/8.10.1) with ESMTP id e66Ic0Y16594; Thu, 6 Jul 2000 20:38:00 +0200 (CEST) Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id UAA75226; Thu, 6 Jul 2000 20:37:54 +0200 (CEST) (envelope-from asmodai) Date: Thu, 6 Jul 2000 20:37:54 +0200 From: Jeroen Ruigrok/Asmodai To: Kirk McKusick Cc: arch@freebsd.org Subject: Re: Snapshots in the Fast Filesystem Message-ID: <20000706203754.W35215@daemon.ninth-circle.org> References: <200007060342.UAA23667@beastie.mckusick.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007060342.UAA23667@beastie.mckusick.com>; from mckusick@mckusick.com on Wed, Jul 05, 2000 at 08:42:18PM -0700 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000706 07:42], Kirk McKusick (mckusick@mckusick.com) wrote: >I am looking for comments and feedback on these changes. I am >proposing to put them into 5.0-current on Tuesday July 11th >unless I get feedback indicating that folks are not happy >with this addition. Enclosed below is the README file that >is included in the above tarball. Without looking at the functionality: I think that this is a great addition/option. I have used snapshots a lot with NetApp Filers and I really like it. I hope to test this ASAP on my box and inform you of my results. Thanks for yet another kicking implementation feature on top of FFS. =) -- Jeroen Ruigrok vd Werven/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project All of us visionaires with a rope around our neck... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 6 14:29:37 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 68DEB37B798 for ; Thu, 6 Jul 2000 14:29:32 -0700 (PDT) (envelope-from mbendiks@eunet.no) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id XAA09480; Thu, 6 Jul 2000 23:29:27 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id XAA68915; Thu, 6 Jul 2000 23:29:26 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Thu, 6 Jul 2000 23:29:26 +0200 (CEST) From: Marius Bendiksen To: Alfred Perlstein Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops In-Reply-To: <20000628231510.F275@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Can you elaborate on the problem you are describing? I'm not sure > I understand besideds certain processes being able to hog the > buffercache and filesystems. The problem lies, as I understand it (ask Feldman for details) in that a find(1) or similar process will cause a lot of work to be done in kernel space, which means the scheduler is not going to clamp down on it. Also, it apparently hogs buffercache and I/O bandwidth. Changing these VOPs to be incremental would solve the problem. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 6 14:32:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 37D1637B798 for ; Thu, 6 Jul 2000 14:32:35 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id B277D1C65; Thu, 6 Jul 2000 17:32:34 -0400 (EDT) Date: Thu, 6 Jul 2000 17:32:34 -0400 From: Bill Fumerola To: Marius Bendiksen Cc: Alfred Perlstein , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops Message-ID: <20000706173234.V4034@jade.chc-chimes.com> References: <20000628231510.F275@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from mbendiks@eunet.no on Thu, Jul 06, 2000 at 11:29:26PM +0200 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 06, 2000 at 11:29:26PM +0200, Marius Bendiksen wrote: > > Can you elaborate on the problem you are describing? I'm not sure > > I understand besideds certain processes being able to hog the > > buffercache and filesystems. > > The problem lies, as I understand it (ask Feldman for details) in that a > find(1) or similar process will cause a lot of work to be done in kernel > space, which means the scheduler is not going to clamp down on it. Also, > it apparently hogs buffercache and I/O bandwidth. Changing these VOPs to > be incremental would solve the problem. My systems get to the point of unusability when find(1) or cvsup(1) are running. These things should be getting scheduled way back, but when I hit 'i' in vi, it can take 30 seconds for it to switch to insert mode. These are not wimpy machines either. -- Bill Fumerola - Network Architect / Computer Horizons Corp - CHIMES e-mail: billf@chimesnet.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 6 14:47:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id ADCBA37B7D8 for ; Thu, 6 Jul 2000 14:47:18 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id PAA26072; Thu, 6 Jul 2000 15:47:08 -0600 (MDT) (envelope-from ken) Date: Thu, 6 Jul 2000 15:47:08 -0600 From: "Kenneth D. Merry" To: Sheldon Hearn Cc: arch@FreeBSD.ORG Subject: Re: Why don't section 4 pages live with their drivers? Message-ID: <20000706154708.B25951@panzer.kdm.org> References: <15951.962878183@axl.ops.uunet.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <15951.962878183@axl.ops.uunet.co.za>; from sheldonh@uunet.co.za on Thu, Jul 06, 2000 at 12:09:43PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 06, 2000 at 12:09:43 +0200, Sheldon Hearn wrote: > > Hi folks, > > I notice that a lot of section 4 manual pages live in src/share/man/man4 > instead of in the subdirectory in which the code that implements the > associated drivers resides. > > I realize that many drivers have bits in too many directories for this > to be possible. > > Case in point: I'm about to commit the md.4 manual page of phk's. I > would have thought that the right place for it would be src/sys/dev/md, > but the precedents which I can see certainly indicates that this would > be "wrong". > > Bottom line: where do I put this thing and if it's not in > src/sys/dev/md, why not? The main reason I can see not to do it is consistency. As you pointed out, with many drivers, the parts are all over the place. So there isn't one "right" place to put the man page. Another problem is when you're doing stuff like: cd /usr/src/sys find . -type f -print |xargs grep foofunc Of course you could just do 'find . -name "*.[ch]" -print...', but the first version of the command would give you mdoc output as well as C. Another issue is that this would clutter up shared directories like sys/pci -- you'd have a ton of man pages for various drivers as well as all the source code. With userland commands and libraries, things are separated out into different directories and it makes sense to put the man pages in the same place. With kernel man pages (section 4 and section 9), I think it makes things a little easier to just keep them in one place. I'm not hard-set against this change, but I do think the things I outlined above should be taken into consideration. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 6 16: 1:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id AA90337B866 for ; Thu, 6 Jul 2000 16:01:26 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e66N1K123888; Thu, 6 Jul 2000 16:01:20 -0700 (PDT) Date: Thu, 6 Jul 2000 16:01:20 -0700 From: Alfred Perlstein To: Bill Fumerola Cc: Marius Bendiksen , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops Message-ID: <20000706160120.Z25571@fw.wintelcom.net> References: <20000628231510.F275@fw.wintelcom.net> <20000706173234.V4034@jade.chc-chimes.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000706173234.V4034@jade.chc-chimes.com>; from billf@chimesnet.com on Thu, Jul 06, 2000 at 05:32:34PM -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Bill Fumerola [000706 14:33] wrote: > On Thu, Jul 06, 2000 at 11:29:26PM +0200, Marius Bendiksen wrote: > > > Can you elaborate on the problem you are describing? I'm not sure > > > I understand besideds certain processes being able to hog the > > > buffercache and filesystems. > > > > The problem lies, as I understand it (ask Feldman for details) in that a > > find(1) or similar process will cause a lot of work to be done in kernel > > space, which means the scheduler is not going to clamp down on it. Also, > > it apparently hogs buffercache and I/O bandwidth. Changing these VOPs to > > be incremental would solve the problem. > > My systems get to the point of unusability when find(1) or cvsup(1) are > running. These things should be getting scheduled way back, but when > I hit 'i' in vi, it can take 30 seconds for it to switch to insert mode. > > These are not wimpy machines either. The disks are busy and vi most likely is doing an IO request, either implement a per-process buffer high water mark or deal with it. :) -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 6 18:37:26 2000 Delivered-To: freebsd-arch@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id ADFD637BBE2 for ; Thu, 6 Jul 2000 18:37:21 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 572601C64; Thu, 6 Jul 2000 21:37:19 -0400 (EDT) Date: Thu, 6 Jul 2000 21:37:19 -0400 From: Bill Fumerola To: Alfred Perlstein Cc: Marius Bendiksen , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops Message-ID: <20000706213719.X4034@jade.chc-chimes.com> References: <20000628231510.F275@fw.wintelcom.net> <20000706173234.V4034@jade.chc-chimes.com> <20000706160120.Z25571@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000706160120.Z25571@fw.wintelcom.net>; from bright@wintelcom.net on Thu, Jul 06, 2000 at 04:01:20PM -0700 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 06, 2000 at 04:01:20PM -0700, Alfred Perlstein wrote: > > My systems get to the point of unusability when find(1) or cvsup(1) are > > running. These things should be getting scheduled way back, but when > > I hit 'i' in vi, it can take 30 seconds for it to switch to insert mode. > > > > These are not wimpy machines either. > > The disks are busy and vi most likely is doing an IO request, either > implement a per-process buffer high water mark or deal with it. :) There was a time when this didn't happened. Part of me wants to think "oh, FreeBSD is just more efficient at saturating the I/O bus" but the other part of me says "damnit, I don't give a shit how long cvsup takes or the nightly output run takes, but I would like to edit files sometime today." -- Bill Fumerola - Network Architect / Computer Horizons Corp - CHIMES e-mail: billf@chimesnet.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 6 18:43:16 2000 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id E15CF37BBC7 for ; Thu, 6 Jul 2000 18:43:11 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA96248; Thu, 6 Jul 2000 18:43:06 -0700 (PDT) (envelope-from dillon) Date: Thu, 6 Jul 2000 18:43:06 -0700 (PDT) From: Matthew Dillon Message-Id: <200007070143.SAA96248@apollo.backplane.com> To: Marius Bendiksen Cc: Alfred Perlstein , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Can you elaborate on the problem you are describing? I'm not sure :> I understand besideds certain processes being able to hog the :> buffercache and filesystems. : :The problem lies, as I understand it (ask Feldman for details) in that a :find(1) or similar process will cause a lot of work to be done in kernel :space, which means the scheduler is not going to clamp down on it. Also, :it apparently hogs buffercache and I/O bandwidth. Changing these VOPs to :be incremental would solve the problem. : :Marius I don't think it's that at all. Obviously find and cvsup eat a lot of *DISK* bandwidth -- all from seeking. The actual *I/O* bandwidth is very low (probably less then 1MByte/sec), but the disk is saturated. So I don't think we are blowing up any caches. What may be happening here is stalling in namei(). find and cvsup are very heavy on path lookups and that combined with seek latency on the drive could result in filesystem locks on directories being held for much longer periods of time then normal. Any other process trying to 'open' a file (verses reading or writing an already-open file) would start to stall. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 6 18:49: 8 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 59D7C37BCBF for ; Thu, 6 Jul 2000 18:49:03 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e671mxt27908; Thu, 6 Jul 2000 18:48:59 -0700 (PDT) Date: Thu, 6 Jul 2000 18:48:59 -0700 From: Alfred Perlstein To: Matthew Dillon Cc: Marius Bendiksen , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops Message-ID: <20000706184859.C25571@fw.wintelcom.net> References: <200007070143.SAA96248@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007070143.SAA96248@apollo.backplane.com>; from dillon@apollo.backplane.com on Thu, Jul 06, 2000 at 06:43:06PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Matthew Dillon [000706 18:43] wrote: > :> Can you elaborate on the problem you are describing? I'm not sure > :> I understand besideds certain processes being able to hog the > :> buffercache and filesystems. > : > :The problem lies, as I understand it (ask Feldman for details) in that a > :find(1) or similar process will cause a lot of work to be done in kernel > :space, which means the scheduler is not going to clamp down on it. Also, > :it apparently hogs buffercache and I/O bandwidth. Changing these VOPs to > :be incremental would solve the problem. > : > :Marius > > I don't think it's that at all. Obviously find and cvsup eat a lot > of *DISK* bandwidth -- all from seeking. The actual *I/O* bandwidth > is very low (probably less then 1MByte/sec), but the disk is saturated. > > So I don't think we are blowing up any caches. > > What may be happening here is stalling in namei(). find and cvsup > are very heavy on path lookups and that combined with seek latency > on the drive could result in filesystem locks on directories being > held for much longer periods of time then normal. Any other process > trying to 'open' a file (verses reading or writing an already-open file) > would start to stall. just a note: sysctl -w vfs.vmiodirenable=1 helps a _lot_. :) -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 6 18:55:46 2000 Delivered-To: freebsd-arch@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 8149037BB83 for ; Thu, 6 Jul 2000 18:55:44 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id DFFA91C64; Thu, 6 Jul 2000 21:55:43 -0400 (EDT) Date: Thu, 6 Jul 2000 21:55:43 -0400 From: Bill Fumerola To: Alfred Perlstein Cc: Matthew Dillon , Marius Bendiksen , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops Message-ID: <20000706215543.Z4034@jade.chc-chimes.com> References: <200007070143.SAA96248@apollo.backplane.com> <20000706184859.C25571@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000706184859.C25571@fw.wintelcom.net>; from bright@wintelcom.net on Thu, Jul 06, 2000 at 06:48:59PM -0700 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 06, 2000 at 06:48:59PM -0700, Alfred Perlstein wrote: > > What may be happening here is stalling in namei(). find and cvsup > > are very heavy on path lookups and that combined with seek latency > > on the drive could result in filesystem locks on directories being > > held for much longer periods of time then normal. Any other process > > trying to 'open' a file (verses reading or writing an already-open file) > > would start to stall. > > just a note: > sysctl -w vfs.vmiodirenable=1 > helps a _lot_. I'll turn it on and see if that helps. -- Bill Fumerola - Network Architect / Computer Horizons Corp - CHIMES e-mail: billf@chimesnet.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 6 19:49:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 0E31237B612 for ; Thu, 6 Jul 2000 19:49:19 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id TAA32333; Thu, 6 Jul 2000 19:47:29 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda32331; Thu Jul 6 19:47:24 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id TAA45571; Thu, 6 Jul 2000 19:47:14 -0700 (PDT) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdm45569; Thu Jul 6 19:47:04 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.10.2/8.9.1) id e672l2R73279; Thu, 6 Jul 2000 19:47:02 -0700 (PDT) Message-Id: <200007070247.e672l2R73279@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdF73275; Thu Jul 6 19:46:54 2000 X-Mailer: exmh version 2.1.1 10/15/1999 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.0-STABLE X-Sender: cy To: papowell@astart.com Cc: sheldonh@uunet.co.za, andrews@technologist.com, arch@FreeBSD.ORG, will@almanac.yi.org Subject: Re: was: Bringing LPRng into FreeBSD? In-reply-to: Your message of "Wed, 05 Jul 2000 20:33:51 PDT." <200007060333.UAA23827@h4.private> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Jul 2000 19:46:53 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200007060333.UAA23827@h4.private>, papowell@astart.com writes: > > From sheldonh@axl.ops.uunet.co.za Mon Jun 26 02:46:32 2000 > > From: Sheldon Hearn > > To: arch@FreeBSD.ORG > > cc: papowell@astart.com > > Subject: Re: was: Bringing LPRng into FreeBSD? > > Date: Mon, 26 Jun 2000 11:46:23 +0200 > > > > > > Could someone just enumerate the advantages of importing LPRng? It > > seems to be a package which can me made to do everything FreeBSD's lpr > > can do, but it does not seem to be a superset of FreeBSD's lpr. This > > means that there is a cost associated with bringing it in as a > > replacement. > > > > Are we sure that the cost is justified? Is it so much better than the > > existing lpr that having it available as a port is "not enough"? > > > > I have no stsrong opinion one way or the other, but I do get the feeling > > that this thread has skipped an important issue, instead focusing on > > licensing. This looks like a little cart before horse. > > I started the work on LPRng with one major goal in mind: make it > secure when used in a Computer Science Laboratory. For example, > LPRng does not need to run SETUID root unless compatibility with > vintage or legacy printing systems such is required. The code is > extremely paranoid about all buffer sizes, string lengths, and so > forth, and goes to great lengths to check for various know hacker > attacks as well. In addition, there are facilities to use > encryption and Kerberos based authentication to prevent abuse > of the printing system. An additional degree of security can be obtained by removing the setuid bit from Berkeley lpr and running it setgid "lpr". One could even turn off the setgid bit and make the lpd spool directories world writable with the sticky bit turned on. Of course this comes at the price of reduced functionality, e.g. lpr -r won't work any more. I'd suggest making lpr setgid "lpr" or running LPRng "secured" and providing instructions or a script for sysadmins to enable/disable the additional functionality by turning on/off the setuid bit. Posix.1e will go a long way to mitigate some of these issues and may make much of this moot. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 6 20: 9:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id F35F437BCDF for ; Thu, 6 Jul 2000 20:09:23 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id UAA32372; Thu, 6 Jul 2000 20:07:49 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda32370; Thu Jul 6 20:05:26 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id UAA45645; Thu, 6 Jul 2000 20:05:15 -0700 (PDT) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdz45643; Thu Jul 6 20:05:02 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.10.2/8.9.1) id e67351q73464; Thu, 6 Jul 2000 20:05:01 -0700 (PDT) Message-Id: <200007070305.e67351q73464@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdD73454; Thu Jul 6 20:04:56 2000 X-Mailer: exmh version 2.1.1 10/15/1999 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.0-STABLE X-Sender: cy To: Cy Schubert - ITSD Open Systems Group Cc: papowell@astart.com, sheldonh@uunet.co.za, andrews@technologist.com, arch@FreeBSD.ORG, will@almanac.yi.org Subject: Re: was: Bringing LPRng into FreeBSD? In-reply-to: Your message of "Thu, 06 Jul 2000 19:46:53 PDT." <200007070247.e672l2R73279@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Jul 2000 20:04:55 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oops. Looks like I was wrong. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC In message <200007070247.e672l2R73279@cwsys.cwsent.com>, Cy Schubert - ITSD Ope n Systems Group writes: > In message <200007060333.UAA23827@h4.private>, papowell@astart.com > writes: > > > From sheldonh@axl.ops.uunet.co.za Mon Jun 26 02:46:32 2000 > > > From: Sheldon Hearn > > > To: arch@FreeBSD.ORG > > > cc: papowell@astart.com > > > Subject: Re: was: Bringing LPRng into FreeBSD? > > > Date: Mon, 26 Jun 2000 11:46:23 +0200 > > > > > > > > > Could someone just enumerate the advantages of importing LPRng? It > > > seems to be a package which can me made to do everything FreeBSD's lpr > > > can do, but it does not seem to be a superset of FreeBSD's lpr. This > > > means that there is a cost associated with bringing it in as a > > > replacement. > > > > > > Are we sure that the cost is justified? Is it so much better than the > > > existing lpr that having it available as a port is "not enough"? > > > > > > I have no stsrong opinion one way or the other, but I do get the feeling > > > that this thread has skipped an important issue, instead focusing on > > > licensing. This looks like a little cart before horse. > > > > I started the work on LPRng with one major goal in mind: make it > > secure when used in a Computer Science Laboratory. For example, > > LPRng does not need to run SETUID root unless compatibility with > > vintage or legacy printing systems such is required. The code is > > extremely paranoid about all buffer sizes, string lengths, and so > > forth, and goes to great lengths to check for various know hacker > > attacks as well. In addition, there are facilities to use > > encryption and Kerberos based authentication to prevent abuse > > of the printing system. > > An additional degree of security can be obtained by removing the setuid > bit from Berkeley lpr and running it setgid "lpr". One could even turn > off the setgid bit and make the lpd spool directories world writable > with the sticky bit turned on. Of course this comes at the price of > reduced functionality, e.g. lpr -r won't work any more. > > I'd suggest making lpr setgid "lpr" or running LPRng "secured" and > providing instructions or a script for sysadmins to enable/disable the > additional functionality by turning on/off the setuid bit. > > Posix.1e will go a long way to mitigate some of these issues and may > make much of this moot. > > > Regards, Phone: (250)387-8437 > Cy Schubert Fax: (250)387-5766 > Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca > Open Systems Group, ITSD, ISTA > Province of BC > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 6 21:38:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 2B8CA37BD23 for ; Thu, 6 Jul 2000 21:38:56 -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 WAA26193; Thu, 6 Jul 2000 22:38:52 -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 WAA58169; Thu, 6 Jul 2000 22:38:27 -0600 (MDT) Message-Id: <200007070438.WAA58169@harmony.village.org> To: Marius Bendiksen Subject: Re: Why don't section 4 pages live with their drivers? Cc: Alfred Perlstein , Sheldon Hearn , arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 06 Jul 2000 18:49:13 +0200." References: Date: Thu, 06 Jul 2000 22:38:26 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Marius Bendiksen writes: : > > Bottom line: where do I put this thing and if it's not in : > > src/sys/dev/md, why not? : : > Personally, I prefer to see the manpages alongside the code. : > (src/sys/dev/md) : : Agree. Perhaps its time to change things to this effect? This works well for the new drivers that have their own directory (except you'll need to make sure that the man pages get installed somehow in make world either by .PATH in share/man/man4, or by descending into dev/md in make world). I don't think that the man pages should be installed as part of modules either. Sure, it is a nice place to hang this hat, but I don't want to install the man pages every time I build a kernel. How do you plan on dealing with all the drivers that live in, say, sys/isa or sys/pci? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 6 21:50:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 1545D37B6AA for ; Thu, 6 Jul 2000 21:50:37 -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 WAA26233; Thu, 6 Jul 2000 22:50:26 -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 WAA58237; Thu, 6 Jul 2000 22:50:02 -0600 (MDT) Message-Id: <200007070450.WAA58237@harmony.village.org> To: Poul-Henning Kamp Subject: Re: HEADSUP: Re: name cache size Cc: Jeroen Ruigrok/Asmodai , Alfred Perlstein , arch@FreeBSD.ORG In-reply-to: Your message of "Mon, 03 Jul 2000 21:04:09 +0200." <8116.962651049@critter.freebsd.dk> References: <8116.962651049@critter.freebsd.dk> Date: Thu, 06 Jul 2000 22:50:01 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <8116.962651049@critter.freebsd.dk> Poul-Henning Kamp writes: : I changed the 'A' semantics that bit, but them ld(1) was hosed : with 'J' which I belive is fixed now. ld has been fixed. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 6 22:32:55 2000 Delivered-To: freebsd-arch@freebsd.org Received: from klapaucius.zer0.org (azazel.zer0.org [204.152.186.45]) by hub.freebsd.org (Postfix) with ESMTP id 85C3A37BBD6 for ; Thu, 6 Jul 2000 22:32:52 -0700 (PDT) (envelope-from gsutter@zer0.org) Received: (from gsutter@localhost) by klapaucius.zer0.org (8.9.3/8.9.3) id WAA25840; Thu, 6 Jul 2000 22:31:50 -0700 (PDT) (envelope-from gsutter@zer0.org) X-Authentication-Warning: klapaucius.zer0.org: gsutter set sender to gsutter@zer0.org using -f Date: Thu, 6 Jul 2000 22:31:50 -0700 From: Gregory Sutter To: Alfred Perlstein Cc: Matthew Dillon , Marius Bendiksen , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops Message-ID: <20000706223150.A24949@klapaucius.zer0.org> References: <200007070143.SAA96248@apollo.backplane.com> <20000706184859.C25571@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000706184859.C25571@fw.wintelcom.net>; from bright@wintelcom.net on Thu, Jul 06, 2000 at 06:48:59PM -0700 Organization: Zer0 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2000-07-06 18:48 -0700, Alfred Perlstein wrote: > * Matthew Dillon [000706 18:43] wrote: > >: > > I don't think it's that at all. Obviously find and cvsup eat a lot > > of *DISK* bandwidth -- all from seeking. The actual *I/O* bandwidth > > is very low (probably less then 1MByte/sec), but the disk is saturated. > > > > So I don't think we are blowing up any caches. > > > > What may be happening here is stalling in namei(). find and cvsup > > are very heavy on path lookups and that combined with seek latency > > on the drive could result in filesystem locks on directories being > > held for much longer periods of time then normal. Any other process > > trying to 'open' a file (verses reading or writing an already-open file) > > would start to stall. > > just a note: > sysctl -w vfs.vmiodirenable=1 > helps a _lot_. Could you explain what this does? Don't say "use the source"; I looked and still have no idea. :) Thanks. Greg -- Gregory S. Sutter Computing is a terminal addiction. mailto:gsutter@zer0.org http://www.zer0.org/~gsutter/ PGP DSS public key 0x40AE3052 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 6 23: 9:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from garm.bart.nl (garm.bart.nl [194.158.170.13]) by hub.freebsd.org (Postfix) with ESMTP id 68E7A37BCF3 for ; Thu, 6 Jul 2000 23:09:38 -0700 (PDT) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org (lucifer.is.an.elder.of.the.ninth-circle.org [195.38.216.226]) by garm.bart.nl (8.10.1/8.10.1) with ESMTP id e6769WN80477; Fri, 7 Jul 2000 08:09:33 +0200 (CEST) Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id IAA78678; Fri, 7 Jul 2000 08:09:28 +0200 (CEST) (envelope-from asmodai) Date: Fri, 7 Jul 2000 08:09:28 +0200 From: Jeroen Ruigrok/Asmodai To: Warner Losh Cc: Poul-Henning Kamp , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: HEADSUP: Re: name cache size Message-ID: <20000707080928.Y35215@daemon.ninth-circle.org> References: <8116.962651049@critter.freebsd.dk> <200007070450.WAA58237@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007070450.WAA58237@harmony.village.org>; from imp@village.org on Thu, Jul 06, 2000 at 10:50:01PM -0600 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000707 08:00], Warner Losh (imp@village.org) wrote: >In message <8116.962651049@critter.freebsd.dk> Poul-Henning Kamp writes: >: I changed the 'A' semantics that bit, but them ld(1) was hosed >: with 'J' which I belive is fixed now. > >ld has been fixed. *nod* I can verify that, prior to the update when I started a make world it didn't even get past stage 1, now it passes that stage at least. Btw, using BDECFLAGS for building world and/or kernel is not going to work. make world I could understand, since we have a lot of GNU utils in contrib, but that a kernel and its modules will not compile cleanly is kinda awkward IMHO. Guess its time to crank out patches. -- Jeroen Ruigrok vd Werven/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project You prayed before, who are the prayers for..? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 6 23:32:57 2000 Delivered-To: freebsd-arch@freebsd.org Received: from njord.bart.nl (njord.bart.nl [194.158.170.15]) by hub.freebsd.org (Postfix) with ESMTP id 6C5B537BD23 for ; Thu, 6 Jul 2000 23:32:41 -0700 (PDT) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org (lucifer.is.an.elder.of.the.ninth-circle.org [195.38.216.226]) by njord.bart.nl (8.10.1/8.10.1) with ESMTP id e676WdS33917; Fri, 7 Jul 2000 08:32:39 +0200 (CEST) Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id IAA78715; Fri, 7 Jul 2000 08:31:16 +0200 (CEST) (envelope-from asmodai) Date: Fri, 7 Jul 2000 08:31:16 +0200 From: Jeroen Ruigrok/Asmodai To: Sheldon Hearn Cc: arch@FreeBSD.org Subject: Re: Why don't section 4 pages live with their drivers? Message-ID: <20000707083116.A35215@daemon.ninth-circle.org> References: <15951.962878183@axl.ops.uunet.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <15951.962878183@axl.ops.uunet.co.za>; from sheldonh@uunet.co.za on Thu, Jul 06, 2000 at 12:09:43PM +0200 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000706 19:13], Sheldon Hearn (sheldonh@uunet.co.za) wrote: > >I notice that a lot of section 4 manual pages live in src/share/man/man4 >instead of in the subdirectory in which the code that implements the >associated drivers resides. > >I realize that many drivers have bits in too many directories for this >to be possible. I prefer to have the manual pages in man4/ This makes updating them easy when Peter (for example) commits some config changes again. Contrary to me having to wade though the entire source tree scourging for the files. I find the placement of the man4 files in one subdir under man the better solution. -- Jeroen Ruigrok vd Werven/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project Haste makes waste... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 6 23:40:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id D6B2437BCF3; Thu, 6 Jul 2000 23:40:48 -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 AAA26807; Fri, 7 Jul 2000 00:40:46 -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 AAA59141; Fri, 7 Jul 2000 00:40:22 -0600 (MDT) Message-Id: <200007070640.AAA59141@harmony.village.org> To: "Kenneth D. Merry" Subject: Re: cvs commit: src UPDATING Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, arch@FreeBSD.org Reply-To: arch@FreeBSD.org In-reply-to: Your message of "Fri, 07 Jul 2000 00:31:39 MDT." <20000707003139.A1286@panzer.kdm.org> References: <20000707003139.A1286@panzer.kdm.org> <200007070517.WAA76347@freefall.freebsd.org> Date: Fri, 07 Jul 2000 00:40:22 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [[ redirected to arch ]] In message <20000707003139.A1286@panzer.kdm.org> "Kenneth D. Merry" writes: : Thanks for making the change. No problem. I saw the error and knew what the problem was instantly. Having hit it before... : Do you, or does anyone else know, whether it would be possible, or a good : idea, to use the .mk files from the share/mk directory that goes along : with a given source tree? We generally do. For buildworld, we already use the mk file in the tree. For the kernel we mostly already use the mk file in the sys tree. We're using sys/conf/kmod.mk. However, to support building outside of the sys tree we're still including bsd.kmod.mk. This file now just looks for how to define SYSDIR, defines it and includes $SYSDIR/sys/conf/kmod.mk. The real problem was that the change to bsd.kmod.mk wasn't done before the integraton of the sound changes. That would have made it easier to cope in the transition. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 5: 0:54 2000 Delivered-To: freebsd-arch@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 61C9137B58A for ; Fri, 7 Jul 2000 05:00:38 -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 KAA73289; Fri, 7 Jul 2000 10:03:59 +0100 (BST) (envelope-from nik) Date: Fri, 7 Jul 2000 10:03:58 +0100 From: Nik Clayton To: Jeroen Ruigrok/Asmodai Cc: Sheldon Hearn , arch@FreeBSD.org Subject: Re: Why don't section 4 pages live with their drivers? Message-ID: <20000707100358.A71608@catkin.nothing-going-on.org> References: <15951.962878183@axl.ops.uunet.co.za> <20000707083116.A35215@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000707083116.A35215@daemon.ninth-circle.org>; from asmodai@wxs.nl on Fri, Jul 07, 2000 at 08:31:16AM +0200 Organization: FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 07, 2000 at 08:31:16AM +0200, Jeroen Ruigrok/Asmodai wrote: > I prefer to have the manual pages in man4/ FWIW, I'd rather see them with the software. > This makes updating them easy when Peter (for example) commits some > config changes again. Contrary to me having to wade though the entire > source tree scourging for the files. locate config.8 N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 5:30: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id 637E637BB64 for ; Fri, 7 Jul 2000 05:28:24 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.15 #1) id 13AXDo-0001iq-00; Fri, 07 Jul 2000 14:27:08 +0200 From: Sheldon Hearn To: "Kenneth D. Merry" Cc: arch@FreeBSD.ORG Subject: Re: Why don't section 4 pages live with their drivers? In-reply-to: Your message of "Thu, 06 Jul 2000 15:47:08 CST." <20000706154708.B25951@panzer.kdm.org> Date: Fri, 07 Jul 2000 14:27:08 +0200 Message-ID: <6623.962972828@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 06 Jul 2000 15:47:08 CST, "Kenneth D. Merry" wrote: > I'm not hard-set against this change, but I do think the things I outlined > above should be taken into consideration. Although I was already convinced before your mail, yours was certainly the most convincing. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 5:58:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 9B30F37BD58 for ; Fri, 7 Jul 2000 05:58:37 -0700 (PDT) (envelope-from mbendiks@eunet.no) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id OAA28254; Fri, 7 Jul 2000 14:58:32 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id OAA72226; Fri, 7 Jul 2000 14:58:32 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Fri, 7 Jul 2000 14:58:32 +0200 (CEST) From: Marius Bendiksen To: Alfred Perlstein Cc: Bill Fumerola , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops In-Reply-To: <20000706160120.Z25571@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The disks are busy and vi most likely is doing an IO request, either > implement a per-process buffer high water mark or deal with it. :) This could be done by an IO scheduler. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 6: 5:54 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 9F8DB37BC92 for ; Fri, 7 Jul 2000 06:05:50 -0700 (PDT) (envelope-from mbendiks@eunet.no) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id PAA29726; Fri, 7 Jul 2000 15:05:48 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id PAA72256; Fri, 7 Jul 2000 15:05:48 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Fri, 7 Jul 2000 15:05:48 +0200 (CEST) From: Marius Bendiksen To: Matthew Dillon Cc: Alfred Perlstein , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops In-Reply-To: <200007070143.SAA96248@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What may be happening here is stalling in namei(). find and cvsup > are very heavy on path lookups and that combined with seek latency > on the drive could result in filesystem locks on directories being > held for much longer periods of time then normal. Any other process > trying to 'open' a file (verses reading or writing an already-open file) > would start to stall. Wouldn't this problem be alleviated by making the operations incremental, rather than performing the whole thing in one go in kernelspace? Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 6:10:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 2730837BC92 for ; Fri, 7 Jul 2000 06:10:45 -0700 (PDT) (envelope-from mbendiks@eunet.no) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id PAA30755; Fri, 7 Jul 2000 15:10:42 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id PAA72270; Fri, 7 Jul 2000 15:10:42 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Fri, 7 Jul 2000 15:10:42 +0200 (CEST) From: Marius Bendiksen To: Warner Losh Cc: Alfred Perlstein , Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: Why don't section 4 pages live with their drivers? In-Reply-To: <200007070438.WAA58169@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This works well for the new drivers that have their own directory > (except you'll need to make sure that the man pages get installed > somehow in make world either by .PATH in share/man/man4, or by > descending into dev/md in make world). I don't think that the man > pages should be installed as part of modules either. Sure, it is a > nice place to hang this hat, but I don't want to install the man pages > every time I build a kernel. I'm no expert on the build mechanism, but I'd think this issue could be resolved somehow? > How do you plan on dealing with all the drivers that live in, say, > sys/isa or sys/pci? sys/legacy/man4 Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 6:32: 9 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ywing.creative.net.au (ywing.creative.net.au [203.56.168.34]) by hub.freebsd.org (Postfix) with ESMTP id 2CB3337B505 for ; Fri, 7 Jul 2000 06:32:05 -0700 (PDT) (envelope-from adrian@ywing.creative.net.au) Received: (from adrian@localhost) by ywing.creative.net.au (8.9.3/8.9.3) id PAA86986; Fri, 7 Jul 2000 15:38:44 +0200 (CEST) (envelope-from adrian) Date: Fri, 7 Jul 2000 15:38:43 +0200 From: Adrian Chadd To: Marius Bendiksen Cc: Matthew Dillon , Alfred Perlstein , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops Message-ID: <20000707153843.H82859@ywing.creative.net.au> References: <200007070143.SAA96248@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mbendiks@eunet.no on Fri, Jul 07, 2000 at 03:05:48PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 07, 2000, Marius Bendiksen wrote: > > What may be happening here is stalling in namei(). find and cvsup > > are very heavy on path lookups and that combined with seek latency > > on the drive could result in filesystem locks on directories being > > held for much longer periods of time then normal. Any other process > > trying to 'open' a file (verses reading or writing an already-open file) > > would start to stall. > > Wouldn't this problem be alleviated by making the operations incremental, > rather than performing the whole thing in one go in kernelspace? Right, uhm, I'm still not entirely sure of what you mean by "incremental". Do you want to give a nice long example of how its done now and how you are proposing it should be done? Adrian -- Adrian Chadd Build a man a fire, and he's warm for the rest of the evening. Set a man on fire and he's warm for the rest of his life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 7:48:51 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 89E8F37B5E4 for ; Fri, 7 Jul 2000 07:48:47 -0700 (PDT) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.9.3/8.9.3) with ESMTP id IAA28540; Fri, 7 Jul 2000 08:48:45 -0600 (MDT) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost.village.org [127.0.0.1]) by billy-club.village.org (8.9.3/8.8.3) with ESMTP id IAA03051; Fri, 7 Jul 2000 08:46:02 -0600 (MDT) Message-Id: <200007071446.IAA03051@billy-club.village.org> To: Marius Bendiksen Subject: Re: Why don't section 4 pages live with their drivers? Cc: Alfred Perlstein , Sheldon Hearn , arch@FreeBSD.ORG In-reply-to: Your message of "Fri, 07 Jul 2000 15:10:42 +0200." References: Date: Fri, 07 Jul 2000 08:46:02 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Marius Bendiksen writes: : > This works well for the new drivers that have their own directory : > (except you'll need to make sure that the man pages get installed : > somehow in make world either by .PATH in share/man/man4, or by : > descending into dev/md in make world). I don't think that the man : > pages should be installed as part of modules either. Sure, it is a : > nice place to hang this hat, but I don't want to install the man pages : > every time I build a kernel. : : I'm no expert on the build mechanism, but I'd think this issue could be : resolved somehow? "Could be resolved somehow" isn't enough of a plan to move forward. : > How do you plan on dealing with all the drivers that live in, say, : > sys/isa or sys/pci? : : sys/legacy/man4 Why bother moving them them? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 8: 6:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 231F737C755 for ; Fri, 7 Jul 2000 08:06:50 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e67F6ic14848; Fri, 7 Jul 2000 08:06:44 -0700 (PDT) Date: Fri, 7 Jul 2000 08:06:44 -0700 From: Alfred Perlstein To: Marius Bendiksen Cc: Bill Fumerola , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops Message-ID: <20000707080644.H25571@fw.wintelcom.net> References: <20000706160120.Z25571@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mbendiks@eunet.no on Fri, Jul 07, 2000 at 02:58:32PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Marius Bendiksen [000707 05:58] wrote: > > The disks are busy and vi most likely is doing an IO request, either > > implement a per-process buffer high water mark or deal with it. :) > > This could be done by an IO scheduler. I think it's AIX that has a tuneable per-process limit on outstanding IO. It would be an interesting thing to implement. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 8: 9:45 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 831E137BEE1 for ; Fri, 7 Jul 2000 08:09:40 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e67F9YD14880; Fri, 7 Jul 2000 08:09:34 -0700 (PDT) Date: Fri, 7 Jul 2000 08:09:34 -0700 From: Alfred Perlstein To: Gregory Sutter Cc: Marius Bendiksen , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops Message-ID: <20000707080934.I25571@fw.wintelcom.net> References: <200007070143.SAA96248@apollo.backplane.com> <20000706184859.C25571@fw.wintelcom.net> <20000706223150.A24949@klapaucius.zer0.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000706223150.A24949@klapaucius.zer0.org>; from gsutter@zer0.org on Thu, Jul 06, 2000 at 10:31:50PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Gregory Sutter [000706 22:32] wrote: > On 2000-07-06 18:48 -0700, Alfred Perlstein wrote: > > > > just a note: > > sysctl -w vfs.vmiodirenable=1 > > helps a _lot_. > > Could you explain what this does? Don't say "use the source"; I > looked and still have no idea. :) Thanks. Directory blocks aren't malloc'd anymore, instead they are taken from the pagecache which gives a _lot_ more room to cache things. The only problem is that for the "average case" you waste nearly 3.5k per directory cached, so it's only really a win on systems with large amounts of ram. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 8:12:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 1B53637C32E for ; Fri, 7 Jul 2000 08:12:17 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e67FC3t14999; Fri, 7 Jul 2000 08:12:03 -0700 (PDT) Date: Fri, 7 Jul 2000 08:12:03 -0700 From: Alfred Perlstein To: Warner Losh Cc: Marius Bendiksen , Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: Why don't section 4 pages live with their drivers? Message-ID: <20000707081202.J25571@fw.wintelcom.net> References: <200007070438.WAA58169@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007070438.WAA58169@harmony.village.org>; from imp@village.org on Thu, Jul 06, 2000 at 10:38:26PM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Warner Losh [000706 21:39] wrote: > In message Marius Bendiksen writes: > : > > Bottom line: where do I put this thing and if it's not in > : > > src/sys/dev/md, why not? > : > : > Personally, I prefer to see the manpages alongside the code. > : > (src/sys/dev/md) > : > : Agree. Perhaps its time to change things to this effect? > > This works well for the new drivers that have their own directory > (except you'll need to make sure that the man pages get installed > somehow in make world either by .PATH in share/man/man4, or by > descending into dev/md in make world). I don't think that the man > pages should be installed as part of modules either. Sure, it is a > nice place to hang this hat, but I don't want to install the man pages > every time I build a kernel. > > How do you plan on dealing with all the drivers that live in, say, > sys/isa or sys/pci? Putting the manpages in the same directory shouldn't be that painful and makes getting at them easier. What's wrong with sys/pci/xl.4 ? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 8:26:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 13D6337BD79 for ; Fri, 7 Jul 2000 08:26:30 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e67FQHW15396; Fri, 7 Jul 2000 08:26:17 -0700 (PDT) Date: Fri, 7 Jul 2000 08:26:17 -0700 From: Alfred Perlstein To: Warner Losh Cc: Marius Bendiksen , Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: Why don't section 4 pages live with their drivers? Message-ID: <20000707082617.L25571@fw.wintelcom.net> References: <20000707081202.J25571@fw.wintelcom.net> <200007070438.WAA58169@harmony.village.org> <20000707081202.J25571@fw.wintelcom.net> <200007071522.JAA62042@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007071522.JAA62042@harmony.village.org>; from imp@village.org on Fri, Jul 07, 2000 at 09:22:54AM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Warner Losh [000707 08:23] wrote: > In message <20000707081202.J25571@fw.wintelcom.net> Alfred Perlstein writes: > : Putting the manpages in the same directory shouldn't be that painful > : and makes getting at them easier. > : > : What's wrong with sys/pci/xl.4 ? > > That's 7 extra files in sys/isa, but on the order of 30 in sys/pci. > That's starting to get painful, imho. I'm not sure I understand the 'pain' of that, is it just because you feel that it would bloat src/sys? I understand that concern but I don't really agree that it would be a problem. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 8:34:45 2000 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 7AFB837B687 for ; Fri, 7 Jul 2000 08:34:42 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id IAA00560; Fri, 7 Jul 2000 08:34:39 -0700 (PDT) (envelope-from dillon) Date: Fri, 7 Jul 2000 08:34:39 -0700 (PDT) From: Matthew Dillon Message-Id: <200007071534.IAA00560@apollo.backplane.com> To: Marius Bendiksen Cc: Alfred Perlstein , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :> What may be happening here is stalling in namei(). find and cvsup :> are very heavy on path lookups and that combined with seek latency :> on the drive could result in filesystem locks on directories being :> held for much longer periods of time then normal. Any other process :> trying to 'open' a file (verses reading or writing an already-open file) :> would start to stall. : :Wouldn't this problem be alleviated by making the operations incremental, :rather than performing the whole thing in one go in kernelspace? : :Marius No. The operations in kernel space are already incremental... the kernel is being entered once per path lookup by find/cvsup. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 8:36:10 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 8E12B37BED1 for ; Fri, 7 Jul 2000 08:36:03 -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 JAA28873; Fri, 7 Jul 2000 09:36:01 -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 JAA62175; Fri, 7 Jul 2000 09:35:36 -0600 (MDT) Message-Id: <200007071535.JAA62175@harmony.village.org> To: Alfred Perlstein Subject: Re: Why don't section 4 pages live with their drivers? Cc: Marius Bendiksen , Sheldon Hearn , arch@FreeBSD.ORG In-reply-to: Your message of "Fri, 07 Jul 2000 08:26:17 PDT." <20000707082617.L25571@fw.wintelcom.net> References: <20000707082617.L25571@fw.wintelcom.net> <20000707081202.J25571@fw.wintelcom.net> <200007070438.WAA58169@harmony.village.org> <20000707081202.J25571@fw.wintelcom.net> <200007071522.JAA62042@harmony.village.org> Date: Fri, 07 Jul 2000 09:35:36 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000707082617.L25571@fw.wintelcom.net> Alfred Perlstein writes: : * Warner Losh [000707 08:23] wrote: : > In message <20000707081202.J25571@fw.wintelcom.net> Alfred Perlstein writes: : > : Putting the manpages in the same directory shouldn't be that painful : > : and makes getting at them easier. : > : : > : What's wrong with sys/pci/xl.4 ? : > : > That's 7 extra files in sys/isa, but on the order of 30 in sys/pci. : > That's starting to get painful, imho. : : I'm not sure I understand the 'pain' of that, is it just because you : feel that it would bloat src/sys? I understand that concern but I : don't really agree that it would be a problem. No. The pain in sys/pci is that they would be in the way and make it harder to edit files and the like. Directory listings would be longer and would no longer fit on one screen, making files harder for humans to find. There's no need to move them there. Also, the man pages would be at xl.4, while the code would be at if_xl.c, which is a little confusing. Also, there's the whole netgraph set of man pages. netgraph lives in sys/net for the most part. It put its man pages illegally in modules/netgraph/foo/foo.4 (that tree's supposed to contain only Makefiles). We'd need to move them somewhere. We would be faced with the choice of creating a dev/netgraph for them (which isn't a horrible idea), or putting them into sys/net, which isn't desirable, but might be palatable. I think that having the man pages in the sys/dev/foo/foo.4 is an OK thing to do. But I have some concerns about it. Having them all in the dev tree would make the mods to the build system to support this easier, but I don't think we can reasonably expect them all to be in dev. Also, there's different versions of some of the man pages for alpha, i386 and pc-98. At least I think that's the case. I know for pc-98 there are additional flags and I thought those were documented in its own set of man pages for ed (since it has its own driver for ed), but I could be mistaken. Finally you have the issue of translators and docs people. They have all the files they need in one place righ tnow. It is easy to find and translate. If you move the man pages from there, as some people have done, it makes it harder for them to find them and easier for the man pages to get overlooked. I'm not violently opposed to this or anything, but there are lots of issues that need to be dealt with if you are serious about moving things. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 8:43:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 9AD1537BFB8 for ; Fri, 7 Jul 2000 08:43:24 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id IAA00597; Fri, 7 Jul 2000 08:43:22 -0700 (PDT) (envelope-from dillon) Date: Fri, 7 Jul 2000 08:43:22 -0700 (PDT) From: Matthew Dillon Message-Id: <200007071543.IAA00597@apollo.backplane.com> To: Bill Fumerola Cc: Alfred Perlstein , Marius Bendiksen , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops References: <200007070143.SAA96248@apollo.backplane.com> <20000706184859.C25571@fw.wintelcom.net> <20000706215543.Z4034@jade.chc-chimes.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :On Thu, Jul 06, 2000 at 06:48:59PM -0700, Alfred Perlstein wrote: : :> > What may be happening here is stalling in namei(). find and cvsup :> > are very heavy on path lookups and that combined with seek latency :> > on the drive could result in filesystem locks on directories being :> > held for much longer periods of time then normal. Any other process :> > trying to 'open' a file (verses reading or writing an already-open file) :> > would start to stall. :> :> just a note: :> sysctl -w vfs.vmiodirenable=1 :> helps a _lot_. : :I'll turn it on and see if that helps. : :-- :Bill Fumerola - Network Architect / Computer Horizons Corp - CHIMES :e-mail: billf@chimesnet.com / billf@FreeBSD.org Ahhhhh. We're waiting with baited breath! If setting vmiodirenable helps then what's probably happening is that the buffer cache's malloc space is being blown away by all the path lookups (due to the reading of all the directories). Turning on vmiodirenable would greatly increase the amount of memory available for caching directories. For the other person who asked what vmiodirenable is: It's a mechanism to allow the system's VM page cache (the master page cache in the system) to cache file pages associated with directories. With this turned on the system is able to cache at least 10x as many directories. With the option turned off (the default, see note below), the buffer cache implements a special 'malloc space' to hold directory pages. This space is very small, and we can't make it any bigger without really screwing up the system. sysctl -a | fgrep malloc My intention was to turn on vmiodirenable by default, but I got stalled on an obscure bug or two related to softupdates. That was a long time ago.. at least 6 months, probably more. It could very well be that the problems no longer exist. My intention is also at some point to remove the crufty malloc space feature in the buffer cache. It was originally designed to 'save memory' by packing small filesystem blocks rather then using the mandatory minimum of one page (4K on i386) that anything backed by the VM Page cache requires. For example, most small directories fit in much less then 4K. The concept is sound, but the implementation has severe scaling problems. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 8:44:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wso.williams.edu (wso.williams.edu [137.165.37.207]) by hub.freebsd.org (Postfix) with ESMTP id 560EE37C09C for ; Fri, 7 Jul 2000 08:44:13 -0700 (PDT) (envelope-from crichard@wso.williams.edu) Received: by wso.williams.edu (Postfix, from userid 1475) id C2E292E55A; Fri, 7 Jul 2000 11:44:11 -0400 (EDT) Date: Fri, 7 Jul 2000 11:44:11 -0400 From: Chris Richards To: freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops Message-ID: <20000707114411.A31035@wso.williams.edu> Mail-Followup-To: freebsd-arch@FreeBSD.ORG References: <200007070143.SAA96248@apollo.backplane.com> <20000706184859.C25571@fw.wintelcom.net> <20000706223150.A24949@klapaucius.zer0.org> <20000707080934.I25571@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <20000707080934.I25571@fw.wintelcom.net>; from bright@wintelcom.net on Fri, Jul 07, 2000 at 08:09:34AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 07, 2000 at 08:09:34AM -0700, Alfred Perlstein wrote: > The only problem is that for the "average case" you waste nearly > 3.5k per directory cached, so it's only really a win on systems > with large amounts of ram. In your estimation, how large is "large"? Of course each site should test to see what best suits its needs, but I'm looking for a rough idea. -chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 9: 0:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 8B0AB37BF7D for ; Fri, 7 Jul 2000 09:00:04 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA00696; Fri, 7 Jul 2000 09:00:01 -0700 (PDT) (envelope-from dillon) Date: Fri, 7 Jul 2000 09:00:01 -0700 (PDT) From: Matthew Dillon Message-Id: <200007071600.JAA00696@apollo.backplane.com> To: Chris Richards Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops References: <200007070143.SAA96248@apollo.backplane.com> <20000706184859.C25571@fw.wintelcom.net> <20000706223150.A24949@klapaucius.zer0.org> <20000707080934.I25571@fw.wintelcom.net> <20000707114411.A31035@wso.williams.edu> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Fri, Jul 07, 2000 at 08:09:34AM -0700, Alfred Perlstein wrote: : :> The only problem is that for the "average case" you waste nearly :> 3.5k per directory cached, so it's only really a win on systems :> with large amounts of ram. : :In your estimation, how large is "large"? Of course each site should :test to see what best suits its needs, but I'm looking for a rough :idea. : :-chris The number is also not correct. Sure, on a directory by directory basis the wastage can be 3.5K. But if the page is cached in the VM Page cache it will fall under the center-weighted LRU algorithm which means that idle directory cache pages will be reused by the system fairly quickly. In contrast, (512 byte) directory blocks sitting the buffer cache's MALLOC space are not governed by standard cache reuse mechanisms and are not as reusable. My personal feeling is that the simple fact that the pages become governed by standard reuse algorithms when in the VM Page cache more then compensates for the 'wasted' memory. And what does 'memory waste' mean anyway? If the system performs better then we shouldn't really care that 3.5K out of 4K is wasted for a few seconds, verses 512 bytes 'not wasted' but also held in the malloc cache 'forever' (except when the malloc cache gets saturated, in which case you reuse the blocks but are screwed anyway because the malloc cache is too small). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 9:11:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 9BCB537BFE4 for ; Fri, 7 Jul 2000 09:11:39 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e67GBZ916606; Fri, 7 Jul 2000 09:11:35 -0700 (PDT) Date: Fri, 7 Jul 2000 09:11:35 -0700 From: Alfred Perlstein To: Matthew Dillon Cc: Bill Fumerola , Marius Bendiksen , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops Message-ID: <20000707091134.M25571@fw.wintelcom.net> References: <200007070143.SAA96248@apollo.backplane.com> <20000706184859.C25571@fw.wintelcom.net> <20000706215543.Z4034@jade.chc-chimes.com> <200007071543.IAA00597@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007071543.IAA00597@apollo.backplane.com>; from dillon@apollo.backplane.com on Fri, Jul 07, 2000 at 08:43:22AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Matthew Dillon [000707 08:43] wrote: > > My intention was to turn on vmiodirenable by default, but I got stalled > on an obscure bug or two related to softupdates. That was a long time > ago.. at least 6 months, probably more. It could very well be that > the problems no longer exist. My intention is also at some point to > remove the crufty malloc space feature in the buffer cache. It was > originally designed to 'save memory' by packing small filesystem blocks > rather then using the mandatory minimum of one page (4K on i386) that > anything backed by the VM Page cache requires. For example, most > small directories fit in much less then 4K. The concept is sound, > but the implementation has severe scaling problems. A wishlist item could be packing these directories into pages through some sort of indirection mechanism. 2cents. :) -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 9:38:44 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 189D437BC92 for ; Fri, 7 Jul 2000 09:38:31 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id MAA67856; Fri, 7 Jul 2000 12:38:13 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 7 Jul 2000 12:38:13 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Dan Nelson Cc: Assar Westerlund , freebsd-arch@FreeBSD.ORG Subject: Re: Procedure for introducing new errno values? In-Reply-To: <20000513224341.B5564@dan.emsphone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 13 May 2000, Dan Nelson wrote: > Don't forget the errno mappings for the Linux/iBSC2/SVR4 compatibility > modules, and src/sys/nfs/nfs_subs.c as well. In both of these cases, what is the appropriate value to choose if the local ENOATTR doesn't map into a convenient remote/emulated errno value? Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 10:18: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 7D4C637BFED for ; Fri, 7 Jul 2000 10:18:02 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e67HI0h18354; Fri, 7 Jul 2000 10:18:00 -0700 (PDT) Date: Fri, 7 Jul 2000 10:18:00 -0700 From: Alfred Perlstein To: Chris Richards Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops Message-ID: <20000707101800.O25571@fw.wintelcom.net> References: <200007070143.SAA96248@apollo.backplane.com> <20000706184859.C25571@fw.wintelcom.net> <20000706223150.A24949@klapaucius.zer0.org> <20000707080934.I25571@fw.wintelcom.net> <20000707114411.A31035@wso.williams.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000707114411.A31035@wso.williams.edu>; from crichard-freebsd@wso.williams.edu on Fri, Jul 07, 2000 at 11:44:11AM -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Chris Richards [000707 09:24] wrote: > On Fri, Jul 07, 2000 at 08:09:34AM -0700, Alfred Perlstein wrote: > > > The only problem is that for the "average case" you waste nearly > > 3.5k per directory cached, so it's only really a win on systems > > with large amounts of ram. > > In your estimation, how large is "large"? Of course each site should > test to see what best suits its needs, but I'm looking for a rough > idea. You'll want to not drop the CC: when replying to me or I can miss the mail. It's really dependant on the system, a rough guess would be anything above 128 megs. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 10:20:49 2000 Delivered-To: freebsd-arch@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id B988E37C282; Fri, 7 Jul 2000 10:20:44 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.9.3/8.9.3) id MAA11579; Fri, 7 Jul 2000 12:20:38 -0500 (CDT) (envelope-from dan) Date: Fri, 7 Jul 2000 12:20:38 -0500 From: Dan Nelson To: Robert Watson Cc: Assar Westerlund , freebsd-arch@FreeBSD.ORG Subject: Re: Procedure for introducing new errno values? Message-ID: <20000707122038.A8474@dan.emsphone.com> References: <20000513224341.B5564@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.3.5i In-Reply-To: ; from "Robert Watson" on Fri Jul 7 12:38:13 GMT 2000 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Jul 07), Robert Watson said: > On Sat, 13 May 2000, Dan Nelson wrote: > > > Don't forget the errno mappings for the Linux/iBSC2/SVR4 compatibility > > modules, and src/sys/nfs/nfs_subs.c as well. > > In both of these cases, what is the appropriate value to choose if the > local ENOATTR doesn't map into a convenient remote/emulated errno value? For nfs_subs, the comments say: * Maps errno values to nfs error numbers. * Use NFSERR_IO as the catch all for ones not specifically defined in * RFC 1094. For linux, there are a lot of -6's in bsd_to_linux_errno (which map to ENXIO), so I'd say use that, or maybe ENODATA or ENOTSUP. If this error isn't going to be returned by any syscall that Linux emaulation uses, it doesn't matter what you pick :) -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 10:40:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id AB3AD37BCD4; Fri, 7 Jul 2000 10:40:34 -0700 (PDT) (envelope-from mbendiks@eunet.no) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id TAA84196; Fri, 7 Jul 2000 19:40:30 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id TAA74854; Fri, 7 Jul 2000 19:40:30 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Fri, 7 Jul 2000 19:40:30 +0200 (CEST) From: Marius Bendiksen To: Adrian Chadd Cc: Matthew Dillon , Alfred Perlstein , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops In-Reply-To: <20000707153843.H82859@ywing.creative.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Right, uhm, I'm still not entirely sure of what you mean by "incremental". > Do you want to give a nice long example of how its done now and how you > are proposing it should be done? Like I stated in the original post; currently, certain operations scan through a number of blocks in kernel space. I would like to be able to add an off_t to the argument list of said operations, set to VNOVAL by the caller, then initialized by the VOP, and incremented by it on each pass. The VOP will return a new error code (ERETRY) when the pass only partially completed, and the library will iterate. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 10:42:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 81BA437C032 for ; Fri, 7 Jul 2000 10:42:20 -0700 (PDT) (envelope-from mbendiks@eunet.no) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id TAA84442; Fri, 7 Jul 2000 19:42:18 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id TAA74860; Fri, 7 Jul 2000 19:42:18 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Fri, 7 Jul 2000 19:42:18 +0200 (CEST) From: Marius Bendiksen To: Alfred Perlstein Cc: Bill Fumerola , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops In-Reply-To: <20000707080644.H25571@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think it's AIX that has a tuneable per-process limit on outstanding > IO. It would be an interesting thing to implement. A more complex I/O system, with scheduling and good async operation, would also be interesting. For example, reads would be balanced more evenly across tasks, while writes would be buffered for larger chunk writes. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 10:44:30 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id EADDC37B8E6 for ; Fri, 7 Jul 2000 10:44:26 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e67HiMH19071; Fri, 7 Jul 2000 10:44:22 -0700 (PDT) Date: Fri, 7 Jul 2000 10:44:22 -0700 From: Alfred Perlstein To: Marius Bendiksen Cc: Bill Fumerola , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops Message-ID: <20000707104422.P25571@fw.wintelcom.net> References: <20000707080644.H25571@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mbendiks@eunet.no on Fri, Jul 07, 2000 at 07:42:18PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Marius Bendiksen [000707 10:42] wrote: > > I think it's AIX that has a tuneable per-process limit on outstanding > > IO. It would be an interesting thing to implement. > > A more complex I/O system, with scheduling and good async operation, > would also be interesting. For example, reads would be balanced more > evenly across tasks, while writes would be buffered for larger chunk > writes. We have that, see vfs_cluster.c, but if we could limit the outstanding IO per process whether read or write we could throttle procs so that they can't saturate the disks. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 10:53:10 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id DBCAA37C241 for ; Fri, 7 Jul 2000 10:53:06 -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.3) with ESMTP id TAA06144; Fri, 7 Jul 2000 19:52:49 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: Bill Fumerola , Alfred Perlstein , Marius Bendiksen , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops In-reply-to: Your message of "Fri, 07 Jul 2000 08:43:22 PDT." <200007071543.IAA00597@apollo.backplane.com> Date: Fri, 07 Jul 2000 19:52:49 +0200 Message-ID: <6142.962992369@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200007071543.IAA00597@apollo.backplane.com>, Matthew Dillon writ es: > Ahhhhh. We're waiting with baited breath! > > If setting vmiodirenable helps then what's probably happening is > that the buffer cache's malloc space is being blown away by all > the path lookups (due to the reading of all the directories). Actually, come to think of it, I wonder if V_SHOULDFREE prefers directory vnodes because their (vp)->v_object->resident_page_count is zero ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 11:18:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from astart2.astart.com (astart2.astart.com [206.71.174.194]) by hub.freebsd.org (Postfix) with ESMTP id C09EE37C098 for ; Fri, 7 Jul 2000 11:18:16 -0700 (PDT) (envelope-from papowell@astart.com) Received: from h4.private (papowell@h4.private [10.0.0.4]) by astart2.astart.com (8.9.3/8.9.3) with ESMTP id LAA46056; Fri, 7 Jul 2000 11:20:58 -0700 (PDT) Received: (from papowell@localhost) by h4.private (8.9.3/8.9.3) id LAA24199; Fri, 7 Jul 2000 11:17:33 -0700 (PDT) Date: Fri, 7 Jul 2000 11:17:33 -0700 (PDT) From: papowell@astart.com Message-Id: <200007071817.LAA24199@h4.private> To: Cy.Schubert@uumail.gov.bc.ca, papowell@astart.com Subject: Re: was: Bringing LPRng into FreeBSD? Cc: andrews@technologist.com, arch@FreeBSD.ORG, sheldonh@uunet.co.za, will@almanac.yi.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From Cy.Schubert@uumail.gov.bc.ca Thu Jul 6 19:48:34 2000 > From: Cy Schubert - ITSD Open Systems Group > To: papowell@astart.com > cc: sheldonh@uunet.co.za, andrews@technologist.com, arch@FreeBSD.ORG, > will@almanac.yi.org > Subject: Re: was: Bringing LPRng into FreeBSD? > Date: Thu, 06 Jul 2000 19:46:53 -0700 > > In message <200007060333.UAA23827@h4.private>, papowell@astart.com > writes: > > > From sheldonh@axl.ops.uunet.co.za Mon Jun 26 02:46:32 2000 > > > From: Sheldon Hearn > > > To: arch@FreeBSD.ORG > > > cc: papowell@astart.com > > > Subject: Re: was: Bringing LPRng into FreeBSD? > > > Date: Mon, 26 Jun 2000 11:46:23 +0200 > > > > > > > > > Could someone just enumerate the advantages of importing LPRng? It > > > seems to be a package which can me made to do everything FreeBSD's lpr > > > can do, but it does not seem to be a superset of FreeBSD's lpr. This > > > means that there is a cost associated with bringing it in as a > > > replacement. > > > > > > Are we sure that the cost is justified? Is it so much better than the > > > existing lpr that having it available as a port is "not enough"? > > > > > > I have no stsrong opinion one way or the other, but I do get the feeling > > > that this thread has skipped an important issue, instead focusing on > > > licensing. This looks like a little cart before horse. > > > > I started the work on LPRng with one major goal in mind: make it > > secure when used in a Computer Science Laboratory. For example, > > LPRng does not need to run SETUID root unless compatibility with > > vintage or legacy printing systems such is required. The code is > > extremely paranoid about all buffer sizes, string lengths, and so > > forth, and goes to great lengths to check for various know hacker > > attacks as well. In addition, there are facilities to use > > encryption and Kerberos based authentication to prevent abuse > > of the printing system. > > An additional degree of security can be obtained by removing the setuid > bit from Berkeley lpr and running it setgid "lpr". One could even turn > off the setgid bit and make the lpd spool directories world writable > with the sticky bit turned on. Of course this comes at the price of > reduced functionality, e.g. lpr -r won't work any more. > > I'd suggest making lpr setgid "lpr" or running LPRng "secured" and > providing instructions or a script for sysadmins to enable/disable the > additional functionality by turning on/off the setuid bit. > > Posix.1e will go a long way to mitigate some of these issues and may > make much of this moot. > > > Regards, Phone: (250)387-8437 > Cy Schubert Fax: (250)387-5766 > Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca > Open Systems Group, ITSD, ISTA > Province of BC If you look in the LPRng-HOWTO, there is a small section on security. There are a couple of things that the classical print spooler does that makes providing 'security out of the box' and 'compatibility with RFC1179' and 'backwards compatibility with vintage print servers' and 'compatibility with Commercial Unix Systems' really nasty. Just for your enjoyment, let me provide a short essay on the Joys of RFC1179 (LPD Print Protocol). The big problem with RFC1179 (LPD Print Protocol) is that the listening port (515) is 'reserved', AND according to RFC1179, the originating port for connections must be 721-731 (i.e. - 'reserved'). This has some nasty implications for security. If you must have OUTGOING compatibility with other LPD print spoolers, then, in the immortal words of Steve Bellovin, "You have a problem." You cannot surrender root privileges UNLESS you have the 'open priv port for listening' and 'bind to priv port for sending' capability, which as far as I know is only available in capability based permissions system. Next, you need to decide on how you are going to deliver output to your printers. If you are forced to use the RFC1179 (LPD) protocol because the printer manufacturer or network interface manufacturer decided that this was the only TCP/IP method they were going to support, then you are forced to keep root permissions and cannot drop them. If you can use the 'appsocket' protocol supported by the vast majority of printers now EXCEPT Apple (Hint: tell Apple you want this facility BACK) then you stand a fighting chance of making a fairly reliable network. The 'appsocket' protcol basically says that the printer will listen on a port (usually 9100 on HP JetDirect boxes), and deliver the input on this port to the print engine. In addition, you can usually configure this so that only connections from a specified IP address are accepted. Another alternative is to use the IPP protocol to deliver jobs to the printer. This is fairly new and is not supported on all printers yet. The real advantage of this protocol is that you do NOT need to originate a connection from a reserved port. If you do NOT require INCOMING compatibility with print spoolers other than LPRng, then you can have the LPD server started as a non-privileged user, and listen for connections on some port other than 515. This means that you NEVER run as root and greatly reduces the possibilities that a buffer overflow, etc., can cause problems. If you DO require INCOMING compatibility, then you can start as the lpd server as root, bind to port 515, and then drop root permissions using setuid(daemon). This is the undocumented option 'drop_root', which has the default value 'NO'. when I had it documented and set to 'YES' people would use this option and then discover that they could not connect to Solaris, HP Jet Direct boxes, etc. After 100 email messages about this 'Bug' I ripped this option out of the distribution. Sigh... Actually, this is NOT quite true. There are several broken implementations of TCP/IP stacks that have problems with dropping root permissions. On these systems if you open a socket as ROOT (euid 0), when you do 'talk = accept()' on the listening socket YOU CANNOT SET THE SOCKET OPTIONS on the 'talk' socket. This has the side effect that you cannot set the SO_LINGER, SO_REUSE, and other options that allow you do control other actions. More important is that you cannot use fcntl() on the socket either, and put it into blocking or non-blocking mode. Grrrr.... I have always wondered who was the bright eyed genius who thought that this was a good idea... :-) The only way to determine that you have this problem is to write a small test program that tests this out, and if this is the case you have to NOT drop root, or to do this in your lpd server each time it starts up. So we have dealt with the server. What about the clients? If you do NOT require FULL compatibility with RFC1179, then simply install them as ordinary applications. However, some people will whine at this and say that LPRng is supposed to be 'fully RFC1179' and that they cannot use this with Solaris/HP/Vax/.../JetDirect systems, and they want it back. So it is an option. As you probably have guessed, I have been through this problem several times, and each time I have had nothing but headaches. Summary: LPD Server Safest: run as daemon, use non-privledged port - incompatible with anything but LPRng Next Safest: start as root, drop root after listening socket created - only compatible with INCOMING connections Evil But Necessary: start as root, run with root LPR, LPRM, Safest: run as user, not setuid - incompatible with LPD that insists on connections originating from Priv Port (Solaris, etc.) Evil But Necessary: run setuid root Patrick ("Did I mention permissions on devices? No? Well, enough headaches for now") Powell To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 11:20: 8 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id B411C37BF17; Fri, 7 Jul 2000 11:20:01 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id OAA69181; Fri, 7 Jul 2000 14:19:58 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 7 Jul 2000 14:19:57 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Marius Bendiksen Cc: Adrian Chadd , Matthew Dillon , Alfred Perlstein , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 7 Jul 2000, Marius Bendiksen wrote: > Like I stated in the original post; currently, certain operations scan > through a number of blocks in kernel space. I would like to be able to > add an off_t to the argument list of said operations, set to VNOVAL by > the caller, then initialized by the VOP, and incremented by it on each > pass. The VOP will return a new error code (ERETRY) when the pass only > partially completed, and the library will iterate. VNOVAL is evil. This is not an opinion about the general point your making, just a comment on the poor design of vop_{get,set}attr. Right now, collisions between the usable data space of attributes and the VNOVAL constant can cause serious pain. For example, chowning a file to the integer value of VNOVAL :-). Ideally, in my mind, calls to vop_setattr() would be replaced with calls to vop_setextattr, allowing us to get rid of the VNOVAL use. That said, I'm not sure I expect that to happen, and there would be namespace issues if it did. robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 12:50:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C9A1137C396 for ; Fri, 7 Jul 2000 12:50:12 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA01243; Fri, 7 Jul 2000 12:50:11 -0700 (PDT) (envelope-from dillon) Date: Fri, 7 Jul 2000 12:50:11 -0700 (PDT) From: Matthew Dillon Message-Id: <200007071950.MAA01243@apollo.backplane.com> To: Alfred Perlstein Cc: Marius Bendiksen , Bill Fumerola , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops References: <20000707080644.H25571@fw.wintelcom.net> <20000707104422.P25571@fw.wintelcom.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :We have that, see vfs_cluster.c, but if we could limit the outstanding :IO per process whether read or write we could throttle procs so that :they can't saturate the disks. : :-- :-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Programs such as cvsup and find do not queue up billions of I/O's. They queue up one at a time pretty much, but the I/O's generate a lot of seeking due to the directory layouts on the media (when you have lots of small directories). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 12:51:35 2000 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 83D9437C23C; Fri, 7 Jul 2000 12:51:33 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA01257; Fri, 7 Jul 2000 12:51:30 -0700 (PDT) (envelope-from dillon) Date: Fri, 7 Jul 2000 12:51:30 -0700 (PDT) From: Matthew Dillon Message-Id: <200007071951.MAA01257@apollo.backplane.com> To: Marius Bendiksen Cc: Adrian Chadd , Alfred Perlstein , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Like I stated in the original post; currently, certain operations scan :through a number of blocks in kernel space. I would like to be able to :add an off_t to the argument list of said operations, set to VNOVAL by :the caller, then initialized by the VOP, and incremented by it on each :pass. The VOP will return a new error code (ERETRY) when the pass only :partially completed, and the library will iterate. : :Marius You are assuming that such scans are long enough to cause a problem. The general answer to that is: 99.99% of the scans done inside the kernel are very, very short, so adding all sorts of functionality to try to break them into pieces is not going to gain us anything. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 13:18:13 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 9AFCE37B743 for ; Fri, 7 Jul 2000 13:18:01 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@localhost [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id OAA16071; Fri, 7 Jul 2000 14:16:19 -0600 (MDT) Message-Id: <200007072016.OAA16071@berserker.bsdi.com> To: Matthew Dillon Cc: Alfred Perlstein , Marius Bendiksen , Bill Fumerola , freebsd-arch@freebsd.org Subject: Re: Alterations to vops From: Chuck Paterson Date: Fri, 07 Jul 2000 14:16:18 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote on: Fri, 07 Jul 2000 12:50:11 PDT } } Programs such as cvsup and find do not queue up billions of } I/O's. They queue up one at a time pretty much, but the I/O's } generate a lot of seeking due to the directory layouts on the } media (when you have lots of small directories). } } -Matt } Matthew Dillon } } } If for whatever reason part of your vm working gets paged out or has to be repaged in from an executable the system can have really bad user response. As Matt points out there aren't bunches of I/O queued from these processes, but you are still screwed. The process you are interested in gets to do one paging operation and then all other processes get to do one of there I/O operations. If there are a couple of processes running in the background then the disk ends up doing several seeks for every page your interactive process needs filled. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 13:56: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id D390137BC42; Fri, 7 Jul 2000 13:55:57 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Fri, 7 Jul 2000 16:55:55 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Matthew Dillon Cc: Marius Bendiksen , Alfred Perlstein , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops In-Reply-To: <200007070143.SAA96248@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 6 Jul 2000, Matthew Dillon wrote: > :> Can you elaborate on the problem you are describing? I'm not sure > :> I understand besideds certain processes being able to hog the > :> buffercache and filesystems. > : > :The problem lies, as I understand it (ask Feldman for details) in that a > :find(1) or similar process will cause a lot of work to be done in kernel > :space, which means the scheduler is not going to clamp down on it. Also, > :it apparently hogs buffercache and I/O bandwidth. Changing these VOPs to > :be incremental would solve the problem. > : > :Marius > > I don't think it's that at all. Obviously find and cvsup eat a lot > of *DISK* bandwidth -- all from seeking. The actual *I/O* bandwidth > is very low (probably less then 1MByte/sec), but the disk is saturated. > > So I don't think we are blowing up any caches. Right, that is definitely true. It's the disk bandwidth, not the cache. > What may be happening here is stalling in namei(). find and cvsup > are very heavy on path lookups and that combined with seek latency > on the drive could result in filesystem locks on directories being > held for much longer periods of time then normal. Any other process > trying to 'open' a file (verses reading or writing an already-open file) > would start to stall. No, that's not it. This is all about reading and writing, not lookups. The computer is slow with regard to I/O, not namei operations. We do not have any kind of disk scheduler to prioritize I/O, and some operations are extremely harsh on bandwidth, most notably reading directories. I don't know about you, but my home directory takes about 3 or 4 seconds of churning before an ls -l spits out the contents; during this time, other processes reading and writing get stalled very easily. If I were to be burning a CD, this likely would have caused an underrun. I do not have a set of extremely slow disks, nor is there contention on the bus. Each disk (and the CD-ROM drive) is ATA, but has its own controller: ad0: 6103MB [13228/15/63] at ata0-master using UDMA33 ad1: 9671MB [19650/16/63] at ata1-master using UDMA33 ad2: 1554MB [3158/16/63] at ata2-master using WDMA2 acd0: CD-R <\^B 1.10 CR-2801TE> at ata3-master using PIO0 Directory operations have extremely detrimental effects on overall system performance. They definitely seem to take overall priority. > -Matt > Matthew Dillon > -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 14:46:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 04B5C37C0A8 for ; Fri, 7 Jul 2000 14:46:16 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id OAA25725; Fri, 7 Jul 2000 14:46:33 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAADdaWgY; Fri Jul 7 14:46:22 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id OAA14015; Fri, 7 Jul 2000 14:45:56 -0700 (MST) From: Terry Lambert Message-Id: <200007072145.OAA14015@usr05.primenet.com> Subject: Re: Alterations to vops To: mbendiks@eunet.no (Marius Bendiksen) Date: Fri, 7 Jul 2000 21:45:56 +0000 (GMT) Cc: bright@wintelcom.net (Alfred Perlstein), billf@chimesnet.com (Bill Fumerola), freebsd-arch@FreeBSD.ORG In-Reply-To: from "Marius Bendiksen" at Jul 07, 2000 02:58:32 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The disks are busy and vi most likely is doing an IO request, either > > implement a per-process buffer high water mark or deal with it. :) > > This could be done by an IO scheduler. This is a cache starvation issue, where an I/O bound process starves a CPU bound process. A fair-share scheduler or I/O scheduler approach will only allow a program to steal the pages back from the culprit program, not deal with the underlying problem. It's possible to burn CPU an I/O cycles on this, and get what the use perceives as improved interactive performance, but in reality what the user is getting is some fraction less of a machine than that which they paid for. The most naieve fix for this is per vnode working set quotas, which would be implemented by causing the process to steal pages from itself, rather than from other processes, once some high water mark less than system resource limits has been reached. I tested this in a UnixWare kernel with much better results than the "fixd scheduling class" scheduler they ended up using to get X Windows interactive response (move mouse, wiggle cursor) to be better. 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-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 19:33:30 2000 Delivered-To: freebsd-arch@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 6F0CE37B5F1; Fri, 7 Jul 2000 19:33:26 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id WAA75900; Fri, 7 Jul 2000 22:32:49 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Fri, 7 Jul 2000 22:32:48 -0400 (EDT) From: Chuck Robey To: papowell@astart.com Cc: drosih@rpi.edu, imp@village.org, andrews@technologist.com, arch@FreeBSD.ORG, nik@FreeBSD.ORG, sheldonh@uunet.co.za, will@almanac.yi.org Subject: Re: Bringing LPRng into FreeBSD? - License Issues In-Reply-To: <200007060232.TAA23720@h4.private> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 5 Jul 2000 papowell@astart.com wrote: > I am surprised at the concern of the licensing issue, so let me explain > the development of the LPRng code and how the license issues evolved. > If you are not interested in the following topics skip them. But please > take the time to read the last one. You've written a nice set of huge responses, but it seems to me that you're laboring under a misconception. I might be wrong (and if I'm wrong I'm sure you'll correct me) but it seems to me that you think that the best utility must get brought into the sources. That's false. We have ports, and LPRng is one of them; many really nice pieces of software are. Many of these pieces of software are unquestionably better than the one that's provided in our main tree, but aren't there for a variety of reasons: license is one of them, but also size, difficulty in configuring, maintenance, and other ones. If we can't get you to release LPRng under a BSD license, and our present lpd *does* have such a license, then I don't think I can make too good a case that LPRng is not better than lpd, but I can really easily make a case that bringing in LPRng is going to hurt an important segment of FreeBSDers (commercial users of FreeBSD). Not bringing in LPRng isn't going to hurt much, since a nice port is available via ports/sysutils/LPRng. Can you see this? It's NOT a question of Having/NotHaving LPRng, we'll have it either way. It's a question of Hurting/NotHurting an important set of FreeBSD users, without making anyone at all do without LPRng. If you're a commercial user, who (for many reasons) doesn't want to have to have an on-staff lawyer every time a commit is done, you'd understand. Trying to give support under conditions where your customers can change things, or where you couldn't, would be a nightmare too. =============================================================== On top of that, and this is a purely personal feeling, I think needing a banner to print out every time your software starts up, well, that's a bit much too. Sources, yes. Requiring your copyright to be in some very available file, that's fine too. God, things would look pretty stupid if all of our utilities decided they needed to print a banner (even if it's a one or two liner). Why shouldn't the writer of "echo" get a banner too? ---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, FreeBSD, chuckr@picnic.mat.net | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 19:35:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mimer.webgiro.com (mimer.webgiro.com [212.209.29.5]) by hub.freebsd.org (Postfix) with ESMTP id 3E28137B60E for ; Fri, 7 Jul 2000 19:35:18 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by mimer.webgiro.com (Postfix, from userid 66) id BC09F2DC0B; Sat, 8 Jul 2000 04:40:53 +0200 (CEST) Received: by mx.webgiro.com (Postfix, from userid 1001) id 2970B7817; Sat, 8 Jul 2000 04:32:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx.webgiro.com (Postfix) with ESMTP id 1BF7610E17 for ; Sat, 8 Jul 2000 04:32:55 +0200 (CEST) Date: Sat, 8 Jul 2000 04:32:55 +0200 (CEST) From: Andrzej Bialecki To: freebsd-arch@freebsd.org Subject: UPDATE2: Dynamic sysctls Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi again, I received many useful comments regarding previous version, and made some changes in functionality. The latest patches can be found at: http://www.freebsd.org/~abial/dyn_sysctl-070700.tgz These patches provide support for fully dynamic sysctl manipulation. You can create and delete new sysctl_oid's at run time. There is also a framework to help you keep track of already created oids (called 'context'). With this version you can create new oids without using contexts, but it's easier to manage the oids if they are collected in context. The handling of improper attachments is working now as well. These patches require fresh -current (as of 5-7 July 2000). You need to patch your /sys, then rebuild the kernel and restart with it. Then you should be able to load and unload example module that adds a couple of sysctl oids to the tree (check with sysctl -a). The example module creates partially overlapping subtrees to demonstrate reference counting. It also contains example of attaching a subtree to the wrong place, i.e. to a dynamic oid that could belong to someone else. The framework should deal with this case gracefully. I received many helpful comments, ideas and code snippets from the following people (in no particular order): Arun Sharma, Jonathan Lemon, Doug Rabson, Brian Feldman, Kelly Yancey and others. Thank you, guys! 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-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 21:15:20 2000 Delivered-To: freebsd-arch@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 5BA7337B7E6; Fri, 7 Jul 2000 21:15:17 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id B53D11C70; Sat, 8 Jul 2000 00:15:15 -0400 (EDT) Date: Sat, 8 Jul 2000 00:15:15 -0400 From: Bill Fumerola To: Brian Fundakowski Feldman Cc: Matthew Dillon , Marius Bendiksen , Alfred Perlstein , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops Message-ID: <20000708001515.E4034@jade.chc-chimes.com> References: <200007070143.SAA96248@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from green@FreeBSD.org on Fri, Jul 07, 2000 at 04:55:55PM -0400 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 07, 2000 at 04:55:55PM -0400, Brian Fundakowski Feldman wrote: > ad0: 6103MB [13228/15/63] at ata0-master using UDMA33 > ad1: 9671MB [19650/16/63] at ata1-master using UDMA33 > ad2: 1554MB [3158/16/63] at ata2-master using WDMA2 > acd0: CD-R <\^B 1.10 CR-2801TE> at ata3-master using PIO0 > > Directory operations have extremely detrimental effects on overall system > performance. They definitely seem to take overall priority. Ditto. UDMA33, SCSI, it really doesn't matter. find(1) and cvsup(1) make performance unbearable. I've had to bump the daily run forward on machines I develop on because I find myself at the office when they kick in and I, in a bitter mood, doing killall -9 find. -- Bill Fumerola - Network Architect / Computer Horizons Corp - CHIMES e-mail: billf@chimesnet.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 22:44:44 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gateway.posi.net (c1096725-a.smateo1.sfba.home.com [24.20.139.104]) by hub.freebsd.org (Postfix) with ESMTP id 6239D37BB1E for ; Fri, 7 Jul 2000 22:44:35 -0700 (PDT) (envelope-from kbyanc@posi.net) Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.9.3/8.9.3) with ESMTP id WAA24959; Fri, 7 Jul 2000 22:47:42 -0700 (PDT) (envelope-from kbyanc@posi.net) Date: Fri, 7 Jul 2000 22:47:41 -0700 (PDT) From: Kelly Yancey To: Chuck Robey Cc: arch@FreeBSD.ORG Subject: Re: Bringing LPRng into FreeBSD? - License Issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 7 Jul 2000, Chuck Robey wrote: > > > On top of that, and this is a purely personal feeling, I think needing a > banner to print out every time your software starts up, well, that's a bit > much too. Sources, yes. Requiring your copyright to be in some very > available file, that's fine too. God, things would look pretty stupid if > all of our utilities decided they needed to print a banner (even if it's a > one or two liner). > > Why shouldn't the writer of "echo" get a banner too? > > Completely off-topic, but I couldn't agree with you more. I think the same thing each and every time I have to watch a linux box boot. Wait, come to think of it, *we* brint a banner on boot... Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. :) Kelly -- Kelly Yancey - kbyanc@posi.net - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 23: 7:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gateway.posi.net (c1096725-a.smateo1.sfba.home.com [24.20.139.104]) by hub.freebsd.org (Postfix) with ESMTP id 9D63137BAF1 for ; Fri, 7 Jul 2000 23:07:20 -0700 (PDT) (envelope-from kbyanc@posi.net) Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.9.3/8.9.3) with ESMTP id XAA25016; Fri, 7 Jul 2000 23:11:04 -0700 (PDT) (envelope-from kbyanc@posi.net) Date: Fri, 7 Jul 2000 23:11:04 -0700 (PDT) From: Kelly Yancey To: Andrzej Bialecki Cc: freebsd-arch@FreeBSD.ORG Subject: Re: UPDATE2: Dynamic sysctls In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 8 Jul 2000, Andrzej Bialecki wrote: > Hi again, > > I received many useful comments regarding previous version, and made some > changes in functionality. The latest patches can be found at: > > http://www.freebsd.org/~abial/dyn_sysctl-070700.tgz > > Looking good. On style(9) nit (god knows I'm not the one to preach style(9) :) ): struct sysctl_ctx_entry *sysctl_ctx_entry_add(struct sysctl_ctx_list *clist, struct sysctl_oid *oidp) should be: struct sysctl_ctx_entry * sysctl_ctx_entry_add(struct sysctl_ctx_list *clist, struct sysctl_oid *oidp) By the way, did you get message I sent regarding the last patchset? I am still unsure how the warning comment in sysctl_remove_oid applys. Also, I'de like to know what you thought of the suggestion to remove all special knowledge of contexts from sysctl_add_oid. i.e. to remove context handling from sysctl_add_oid and make the modules using contexts do something like: oid = sysctl_add_oid(...) sysctl_ctx_entry_add(myctx, oid); or just: sysctl_ctx_entry_add(myctx, sysctl_add_oid(...)); I think it would clean up the sysctl_add_oid code and the interface in general. This is great work that you are doing. Thanks, Kelly -- Kelly Yancey - kbyanc@posi.net - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 7 23:27:25 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 66B4F37BECE; Fri, 7 Jul 2000 23:27:11 -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 AAA32003; Sat, 8 Jul 2000 00:26:16 -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 AAA67301; Sat, 8 Jul 2000 00:26:13 -0600 (MDT) Message-Id: <200007080626.AAA67301@harmony.village.org> To: Chuck Robey Subject: Re: Bringing LPRng into FreeBSD? - License Issues Cc: papowell@astart.com, drosih@rpi.edu, andrews@technologist.com, arch@FreeBSD.ORG, nik@FreeBSD.ORG, sheldonh@uunet.co.za, will@almanac.yi.org In-reply-to: Your message of "Fri, 07 Jul 2000 22:32:48 EDT." References: Date: Sat, 08 Jul 2000 00:26:13 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Chuck Robey writes: : If we can't get you to release LPRng under a BSD license, and our present : lpd *does* have such a license, then I don't think I can make too good a : case that LPRng is not better than lpd, but I can really easily make a : case that bringing in LPRng is going to hurt an important segment of : FreeBSDers (commercial users of FreeBSD). Not bringing in LPRng isn't : going to hurt much, since a nice port is available via : ports/sysutils/LPRng. : : Can you see this? It's NOT a question of Having/NotHaving LPRng, we'll : have it either way. It's a question of Hurting/NotHurting an important : set of FreeBSD users, without making anyone at all do without LPRng. Actually, I do get the point. The big motivator was lack of a good lpr/lpd maintainer and the difficulty in getting simple fixes audited in lpr/lpd. We now have a maintainer, so that issue is likely to go away. Most of my desire for lprng was based on me wearing my SO hat and saying that for the good of the project you have to accept this. I've since realized that we might get the same goal in other ways. : If you're a commercial user, who (for many reasons) doesn't want to have : to have an on-staff lawyer every time a commit is done, you'd : understand. Trying to give support under conditions where your customers : can change things, or where you couldn't, would be a nightmare too. I understand completely. I work for just such a company. There's a cost of doing business with free software and companies that do this must understand that. The BSD license is easy to understand, but if you want to be sure, you MUST consult a lawyer. Ame is true for any hunk of software you hack on. It is a sad reality of life really. And neither of these situations is changed by importing lprng. However, events have overcome that argument. I don't think lprng will go into the tree. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 8 0: 9:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 0397537B98C for ; Sat, 8 Jul 2000 00:09:56 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p47-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.112]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id QAA13343; Sat, 8 Jul 2000 16:09:49 +0900 (JST) Message-ID: <3966D3DE.EE7078F2@newsguy.com> Date: Sat, 08 Jul 2000 16:10:22 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: Moving pccardd/pccardc to sbin References: <200006271927.NAA48425@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > I'd like to move pccardd/pccardc to sbin. This allows people booting > diskless to do so and has a few other advantages. I'd also like to > move pccardd startup earlier in the boot process. Same benefits. > > I'd like to do this in 4.1 as well. I can't htink of any reasoon not > do to do this. It will require a line in the UPDATING file > instructing people to delete the old pccardd, but other than that the > upgrade path is covered. There's a small chance it might break old > scripts, but a soltuion similar to mknode might work well. > > Comments? You'll need to move logger too. Aside from that, you know my opinion. My /home, /usr/local, /usr/ports, /compat, /usr/src among others are all on a Adaptec SlimSCSI AHA-1460 (aic). -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.great.underground.bsdconpiracy.org _DES: The Book of Bruce has only one sentence in it, and it says "the actual directives of my cult are left as an exercise for the reader. Good luck." jkh: does it really include the 'good luck' part? EE: OK, I made that part up. EE: I figured it should sound a bit more cheery than how Bruce initially dictated it to me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 8 6: 5:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mimer.webgiro.com (mimer.webgiro.com [212.209.29.5]) by hub.freebsd.org (Postfix) with ESMTP id 2934D37B552; Sat, 8 Jul 2000 06:05:16 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by mimer.webgiro.com (Postfix, from userid 66) id 816C32DC0A; Sat, 8 Jul 2000 15:10:51 +0200 (CEST) Received: by mx.webgiro.com (Postfix, from userid 1001) id 43CE87817; Sat, 8 Jul 2000 15:03:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx.webgiro.com (Postfix) with ESMTP id 376B210E17; Sat, 8 Jul 2000 15:03:21 +0200 (CEST) Date: Sat, 8 Jul 2000 15:03:21 +0200 (CEST) From: Andrzej Bialecki To: Kelly Yancey , green@freebsd.org Cc: freebsd-arch@FreeBSD.ORG Subject: Oops! (Re: UPDATE2: Dynamic sysctls) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 7 Jul 2000, Kelly Yancey wrote: > On Sat, 8 Jul 2000, Andrzej Bialecki wrote: > > > Hi again, > > > > I received many useful comments regarding previous version, and made some > > changes in functionality. The latest patches can be found at: > > > > http://www.freebsd.org/~abial/dyn_sysctl-070700.tgz I'm not sure, guys, that you retrieved the right version.... :-(( *blush* I must have done something stupid here when copying these files to freefall. It seems to me that you still refer to the older version, because in the new I changed the following: * SYSCTL_CTX_CREATE is gone, replaced by SYSCTL_CTX_INIT * sysctl_ctx_add was renamed, and two other functions were added: sysctl_ctx_entry_add sysctl_ctx_entry_find sysctl_ctx_entry_del * sysctl_add_oid accepts NULL as valid context * oidp->ref is now oidp->oid_refcnt etc, etc... Please check that you have this version. I accidentally overwrote the previous file on freefall, so I have no way of knowing what was there before... I know, I know (*bangs his head in the wall*)... Too little sleep. Anyway, I double checked it right now. The file that you want is named dyn_sysctl-080700.tgz. I added Brian's suggestion about M_WAITOK. Sorry again! > By the way, did you get message > I sent regarding > the last patchset? I am still unsure how the warning comment in > sysctl_remove_oid applys. Also, I'de like to know what you thought of the > suggestion to remove all special knowledge of contexts from > sysctl_add_oid. i.e. to remove context handling from sysctl_add_oid and make > the modules using contexts do something like: Yes, the new patches allow you to do this. Thank you for the idea! 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-arch" in the body of the message From owner-freebsd-arch Sat Jul 8 6:42: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from njord.bart.nl (njord.bart.nl [194.158.170.15]) by hub.freebsd.org (Postfix) with ESMTP id 39EE637B770; Sat, 8 Jul 2000 06:41:41 -0700 (PDT) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org (daemon.ninth-circle.org [195.38.216.226]) by njord.bart.nl (8.10.1/8.10.1) with ESMTP id e68DfYF05176; Sat, 8 Jul 2000 15:41:34 +0200 (CEST) Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id PAA85891; Sat, 8 Jul 2000 15:02:20 +0200 (CEST) (envelope-from asmodai) Date: Sat, 8 Jul 2000 15:02:20 +0200 From: Jeroen Ruigrok/Asmodai To: Nik Clayton Cc: Sheldon Hearn , arch@FreeBSD.org Subject: Re: Why don't section 4 pages live with their drivers? Message-ID: <20000708150220.I35215@daemon.ninth-circle.org> References: <15951.962878183@axl.ops.uunet.co.za> <20000707083116.A35215@daemon.ninth-circle.org> <20000707100358.A71608@catkin.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000707100358.A71608@catkin.nothing-going-on.org>; from nik@freebsd.org on Fri, Jul 07, 2000 at 10:03:58AM +0100 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000707 16:01], Nik Clayton (nik@freebsd.org) wrote: >On Fri, Jul 07, 2000 at 08:31:16AM +0200, Jeroen Ruigrok/Asmodai wrote: > >> This makes updating them easy when Peter (for example) commits some >> config changes again. Contrary to me having to wade though the entire >> source tree scourging for the files. > > locate config.8 Of course that idea struck me as well. However, given the recent changes to the configuration format where we went from fxp0 to fxp and that for all devices it makes manpage maintenance easier when I can simply cd to man4, vim * and modify everything needed and fcvs commit man4/* and be done. Using locate would mean I am wasting much more time. On the whole I find this request for moving the manpages and scattering them around src/ a mere change for the sake of change request with not much advantage coming from it. -- Jeroen Ruigrok vd Werven/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project Love conquers all... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 8 8:17:34 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by hub.freebsd.org (Postfix) with ESMTP id E8A3B37B60B; Sat, 8 Jul 2000 08:17:31 -0700 (PDT) (envelope-from se@freebsd.org) Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout1.freenet.de with esmtp (Exim 3.15 #1) id 13AwME-0001Ky-00; Sat, 08 Jul 2000 17:17:30 +0200 Received: from a6a05.pppool.de ([213.6.106.5] helo=StefanEsser.FreeBSD.org) by mx0.freenet.de with esmtp (Exim 3.15 #1) id 13AwMD-00050s-00; Sat, 08 Jul 2000 17:17:30 +0200 Received: by StefanEsser.FreeBSD.org (Postfix, from userid 200) id 539CED36; Sat, 8 Jul 2000 14:51:02 +0200 (CEST) Date: Sat, 8 Jul 2000 14:51:01 +0200 From: Stefan Esser To: clefevre@citeweb.net Cc: freebsd-arch@FreeBSD.ORG, Stefan Esser Subject: Re: [Patch] make test,expr,printf support 64bit integers Message-ID: <20000708145101.A3242@StefanEsser.FreeBSD.org> Reply-To: Stefan Esser References: <20000703184219.A7587@StefanEsser.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from clefevre@no-spam.citeweb.net on Thu, Jul 06, 2000 at 02:03:48AM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2000-07-06 02:03 +0200, Cyrille Lefevre wrote: > > -static int getlong __P((long *)); > > +static int getlong __P((quad_t *)); > ^^^^^^^ getquad > > if (getlong(&val)) > ^^^^^^^ getquad > IMHO, be consistent w/ naming convention (getlong -> getquad). Thanks for your comment! Yes, you are of course right. I remember to have considered changing the name to match the type, but for reasons I can't remember decided against this. (Probably because I wanted to restrict the patch to just the functional changes.) I'll change the ifunction name as you propose. If there are no other comments or requests for further changes, I'll commit the 64Bit extension on Sunday or Monday. Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 8 8:56:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id A1EA037B55D; Sat, 8 Jul 2000 08:56:23 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.15 #1) id 13Awxi-000EEX-00; Sat, 08 Jul 2000 17:56:14 +0200 From: Sheldon Hearn To: Jeroen Ruigrok/Asmodai Cc: Nik Clayton , arch@FreeBSD.org Subject: Re: Why don't section 4 pages live with their drivers? In-reply-to: Your message of "Sat, 08 Jul 2000 15:02:20 +0200." <20000708150220.I35215@daemon.ninth-circle.org> Date: Sat, 08 Jul 2000 17:56:14 +0200 Message-ID: <54716.963071774@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 08 Jul 2000 15:02:20 +0200, Jeroen Ruigrok/Asmodai wrote: > On the whole I find this request for moving the manpages and scattering > them around src/ a mere change for the sake of change request with not > much advantage coming from it. I'm the guy who started this whole thread, and I couldn't agree with you more. The status quo is fine, and I just wanted to make sure that there was at least one good reason for it. The good reason I've heard so far is that the manual pages should not be installed as part of the kernel installation, and I'm certainly content with that argument for the moment. This is not a pressing issue, and I don't think we lose anything by dropping the argument and getting on with things that actually benefit the project. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 8 9:29:13 2000 Delivered-To: freebsd-arch@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 8831037C090 for ; Sat, 8 Jul 2000 09:29:06 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p18-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.147]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id BAA07975; Sun, 9 Jul 2000 01:28:45 +0900 (JST) Message-ID: <396756DD.2235FC7C@newsguy.com> Date: Sun, 09 Jul 2000 01:29:17 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Sheldon Hearn Cc: James Howard , arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details References: <30005.962629536@axl.ops.uunet.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn wrote: > > On Mon, 03 Jul 2000 09:01:20 -0400, James Howard wrote: > > > It would make sense to have it follow the semantics of the system call and > > then add a -c to create if nonexistent as Langer suggested. > > I'm convinced, but it introduces a problem. Given that it looks like > we'll allow '+' or '-' to be prepended to the size argument to allow > size changes rather than absolute sizes, what does this mean: > > truncate -c -1024 nonexistant_file Means a syntax error. truncate -c -- -1024 nonexistant_file Though, really, what you posted is non-ambiguous, and easy to parse. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.great.underground.bsdconpiracy.org _DES: The Book of Bruce has only one sentence in it, and it says "the actual directives of my cult are left as an exercise for the reader. Good luck." jkh: does it really include the 'good luck' part? EE: OK, I made that part up. EE: I figured it should sound a bit more cheery than how Bruce initially dictated it to me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 8 10:29: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id 9638937B88C for ; Sat, 8 Jul 2000 10:28:59 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.15 #1) id 13AyP3-000EZw-00; Sat, 08 Jul 2000 19:28:33 +0200 From: Sheldon Hearn To: "Daniel C. Sobral" Cc: James Howard , arch@FreeBSD.ORG Subject: Re: truncate(1) implementation details In-reply-to: Your message of "Sun, 09 Jul 2000 01:29:17 +0900." <396756DD.2235FC7C@newsguy.com> Date: Sat, 08 Jul 2000 19:28:33 +0200 Message-ID: <56043.963077313@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 09 Jul 2000 01:29:17 +0900, "Daniel C. Sobral" wrote: > Means a syntax error. > > truncate -c -- -1024 nonexistant_file In actual fact, the introduction of the -r flag, which instructs truncate(1) to use the size of the file given as an argument, made a good case for demanding that a specified size argument be given as an argument to an option. See http://people.freebsd.org/~sheldonh/truncate/ in Alex's absence. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 8 11: 4:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by hub.freebsd.org (Postfix) with ESMTP id 6580537B9F0 for ; Sat, 8 Jul 2000 11:04:20 -0700 (PDT) (envelope-from chris@holly.calldei.com) Received: from holly.calldei.com ([208.191.149.190]) by mta4.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FXE00M3E4TXAA@mta4.rcsntx.swbell.net> for arch@FreeBSD.ORG; Sat, 8 Jul 2000 13:03:34 -0500 (CDT) Received: (from chris@localhost) by holly.calldei.com (8.9.3/8.9.3) id NAA13741; Sat, 08 Jul 2000 13:02:49 -0500 (CDT envelope-from chris) Date: Sat, 08 Jul 2000 13:02:49 -0500 From: Chris Costello Subject: Re: truncate(1) implementation details In-reply-to: <19462.962734524@axl.ops.uunet.co.za> To: Sheldon Hearn Cc: Bruce Evans , Bill Fumerola , arch@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20000708130249.C8475@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <19462.962734524@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, July 04, 2000, Sheldon Hearn wrote: > So you think that EXIT_{SUCCESS|FAILURE} should be used exclusively, and > not the values described in sysexits(3)? I'm not criticising (I realize > that the English is ambiguous here), I just want to know what your > standpoint is. It's probably because they're too arbitrary. EX_CONFIG vs. EX_SOFTWARE, EX_CANTCREAT vs. EX_NOPERM. See also the bugs section in sysexits(3). -- |Chris Costello |It takes an extra touch of stupidity to spill a drink |in electronics. -- Anonymous `----------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 8 11:37:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 8A40F37B556; Sat, 8 Jul 2000 11:37:29 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA06503; Sat, 8 Jul 2000 11:37:28 -0700 (PDT) (envelope-from dillon) Date: Sat, 8 Jul 2000 11:37:28 -0700 (PDT) From: Matthew Dillon Message-Id: <200007081837.LAA06503@apollo.backplane.com> To: Brian Fundakowski Feldman Cc: Marius Bendiksen , Alfred Perlstein , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :No, that's not it. This is all about reading and writing, not lookups. :The computer is slow with regard to I/O, not namei operations. We do :not have any kind of disk scheduler to prioritize I/O, and some operations :are extremely harsh on bandwidth, most notably reading directories. I :don't know about you, but my home directory takes about 3 or 4 seconds of :churning before an ls -l spits out the contents; during this time, other :processes reading and writing get stalled very easily. If I were to be :burning a CD, this likely would have caused an underrun. : :I do not have a set of extremely slow disks, nor is there contention on :the bus. Each disk (and the CD-ROM drive) is ATA, but has its own :... : Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / : green@FreeBSD.org `------------------------------' Let me give you an example, Brian. Lets say you have a find running on your whole filesystem. The directories & inodes being scanned by the find are for the most part not going to be in the cache, which means that find is going to cause at least two disk I/O's for each small directory and probably more. So at any given moment, the find process looks like this: read low level read I/O dispatched to the disk (stall) I/O complete read low level read I/O dispatched to the disk (stall) I/O complete read low level read I/O dispatched to the disk (stall) I/O complete read low level read I/O dispatched to the disk (stall) I/O complete Now lets say you have some other process -- any other process, which needs to do disk I/O. It issues a read: read (stall waiting for the I/O find has *ALREADY* dispatched to the disk to complete) low level read I/O dispatched to the disk (stall) I/O complete You have this problem even on a SCSI system with tagged queueing because the stall is from the disk itself doing a seek. Here's the problem: Once you've dispatched the I/O to the disk, you cannot abort it. At the time the find dispatches its I/O to the disk, there are NO OTHER PROCESSES trying to do I/O. That is, whenever some other process tries to do I/O the find will ALREADY have an I/O queued to disk. This is the natuer of an I/O bound process. The problem isn't the I/O bound process trying to do I/O on top of some other process's I/O, the problem is that the other processes are idle and so when they issue their I/O they will find the find process *already sitting waiting for its own to complete*. Thus you have nothing to prioritize (short of aborting the find's disk op, which you can't do). Dealing with this problem is not trivial. The only way to deal with it is to have the kernel actually impose a delay in the dispatch of find's I/O, even though no other processes are requesting I/O at the time, in order to give another process the chance to do several I/O's (non I/O bound I/O's) in between the I/O's that find/cvsup do (each of which has massive disk overhead due to the seeking). Needless to say, figuring out what kind of delay to impose is hard. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 8 13:12: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from astart2.astart.com (astart2.astart.com [206.71.174.194]) by hub.freebsd.org (Postfix) with ESMTP id 22ACC37B934; Sat, 8 Jul 2000 13:12:00 -0700 (PDT) (envelope-from papowell@astart.com) Received: from h4.private (papowell@h4.private [10.0.0.4]) by astart2.astart.com (8.9.3/8.9.3) with ESMTP id NAA52683; Sat, 8 Jul 2000 13:15:07 -0700 (PDT) Received: (from papowell@localhost) by h4.private (8.9.3/8.9.3) id NAA26688; Sat, 8 Jul 2000 13:11:25 -0700 (PDT) Date: Sat, 8 Jul 2000 13:11:25 -0700 (PDT) From: papowell@astart.com Message-Id: <200007082011.NAA26688@h4.private> To: chuckr@picnic.mat.net, papowell@astart.com Subject: Re: Bringing LPRng into FreeBSD? - License Issues Cc: andrews@technologist.com, arch@FreeBSD.ORG, drosih@rpi.edu, imp@village.org, nik@FreeBSD.ORG, sheldonh@uunet.co.za, will@almanac.yi.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From chuckr@picnic.mat.net Fri Jul 7 19:33:05 2000 > Date: Fri, 7 Jul 2000 22:32:48 -0400 (EDT) > From: Chuck Robey > To: papowell@astart.com > cc: drosih@rpi.edu, imp@village.org, andrews@technologist.com, > arch@FreeBSD.ORG, nik@FreeBSD.ORG, sheldonh@uunet.co.za, > will@almanac.yi.org > Subject: Re: Bringing LPRng into FreeBSD? - License Issues > > On Wed, 5 Jul 2000 papowell@astart.com wrote: > > > I am surprised at the concern of the licensing issue, so let me explain > > the development of the LPRng code and how the license issues evolved. > > If you are not interested in the following topics skip them. But please > > take the time to read the last one. > > If we can't get you to release LPRng under a BSD license, and our present > lpd *does* have such a license, then I don't think I can make too good a > case that LPRng is not better than lpd, but I can really easily make a > case that bringing in LPRng is going to hurt an important segment of > FreeBSDers (commercial users of FreeBSD). Not bringing in LPRng isn't > going to hurt much, since a nice port is available via > ports/sysutils/LPRng. As I not in my posting, I am not adverse, and quite willing to put it under BSD license, but I would like to be able to have the actual executable 'identify its lineage' in some way, so that it is identifiable as the 'True Code', modified by somebody, or 'modified by corporation X'. This is perfectly reasonable and common. > > =============================================================== > > > On top of that, and this is a purely personal feeling, I think needing a > banner to print out every time your software starts up, well, that's a bit > much too. Sources, yes. Requiring your copyright to be in some very > available file, that's fine too. God, things would look pretty stupid if > all of our utilities decided they needed to print a banner (even if it's a > one or two liner). > > Why shouldn't the writer of "echo" get a banner too? > h9: {27} % perl -V Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=freebsd, osvers=4.0-current, archname=i386-freebsd uname='FreeBSD freefall.FreeBSD.org 4.0-current FreeBSD 4.0-current #0: $Date$' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='undef', gccversion=2.95.2 19991024 (release) cppflags='' ccflags ='' stdchar='char', d_stdstdio=undef, usevfork=true intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags ='-Wl,-E -lperl -lm ' libpth=/usr/lib libs=-lm -lc -lcrypt libc=, so=so, useshrplib=true, libperl=libperl.so.3 Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-R/usr/lib' cccdlflags='-DPIC -fpic', lddlflags='-Wl,-E -shared -lperl -lm ' h9: {18} % awk -W version GNU Awk 3.0.4 Copyright (C) 1989, 1991-1999 Free Software Foundation. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. h9: {455} % lpr -V LPRng-3.6.20, Copyright 1988-2000 Patrick Powell, I am a little bit baffled on this. What are you talking about? I note carefully that you have to provide the -V option to cause this to happen, as does perl (perl -V) and awk (awk -W version, actually). So, are you objecting to the awk -W or perl -V command as well? I don't understand the cause of the . > > ---------------------------------------------------------------------------- > Chuck Robey | Interests include C & Java programming, FreeBSD, > chuckr@picnic.mat.net | electronics, communications, and signal processing. > > New Year's Resolution: I will not sphroxify gullible people into looking up > fictitious words in the dictionary. > ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 8 14: 1:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from astart2.astart.com (astart2.astart.com [206.71.174.194]) by hub.freebsd.org (Postfix) with ESMTP id 7752337BDA3; Sat, 8 Jul 2000 14:01:34 -0700 (PDT) (envelope-from papowell@astart.com) Received: from h4.private (papowell@h4.private [10.0.0.4]) by astart2.astart.com (8.9.3/8.9.3) with ESMTP id OAA52782; Sat, 8 Jul 2000 14:04:45 -0700 (PDT) Received: (from papowell@localhost) by h4.private (8.9.3/8.9.3) id OAA26787; Sat, 8 Jul 2000 14:01:05 -0700 (PDT) Date: Sat, 8 Jul 2000 14:01:05 -0700 (PDT) From: papowell@astart.com Message-Id: <200007082101.OAA26787@h4.private> To: chuckr@picnic.mat.net, papowell@astart.com Subject: Re: Bringing LPRng into FreeBSD? - License Issues Cc: andrews@technologist.com, arch@FreeBSD.ORG, drosih@rpi.edu, imp@village.org, nik@FreeBSD.ORG, sheldonh@uunet.co.za, will@almanac.yi.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have been reviewing some of the postings that folks have sent on this topic, and I would like to provide some clarification about printing. I think that there is a bit of confusion about the overall issue of printing. This is probably due to the fact that most people close their eyes to printing as soon as it is working for them, and hope never to get involved with configuring it again. A MOST perceptive and reasonable attitude, given the horrible state of printing. Lets start at the back end. What Gets Sent To The Printer Basically, a stream of bytes. The FORMAT of this stream of bytes is the critical issue. Most printers usually support a limited number of formats that they recognize: PCL - this is really text + control sequences PostScript - this is PostScript Now this is the 'basic' format. In addition, most printers require additional structure on this format, or additional 'support' for various things: PJL - Printer Job Language HP printers use this for 'metacontrol' of printers PostScript Document Structure Conventions How you will organize the PostScript PostScript PPD + Embedded Control Commands PostScript Printer Description files tell WHAT capabilities a printer has You use this to put commands into a PostScript file that will cause the printer to select the correct input bin, output bin, paper type, etc. How Does It Get There You can send it over a communication channel - Serial Channel Parallel Channel Network Channel Each of these channels MAY have a protocol used to transmit documents of a specific format. For example, if you want to send 'binary PostScript' over a 7 bit serial channel, then you need to use the 'TBCP' encoding for your PostScript job. Network Channels are REALLY fun, because you have not only the basic network level protocol, (TCP/IP, IPX, AppleTalk, etc.), but also application protocols such as the 'Appsocket', 'Socket', RFC1179, and others. This is why just sending a file to the printer via 'cat' or 'netcat' may have some unexpected side effects. Such as the file not getting printed :-). Print Spooler or Manager This is effectively the interface between a user program that is generating a job to print and the actual device. In some cases, this is just 'open /dev/lp0 and write to it' by the application. But usually it is a system service. For example, the 'lpd' server and the 'lpr' client programs are the commonly used BSD UNIX print spooler, 'lpsched' and 'lp' on SystemV, and so forth. These system work by having the user or application use the client program send a copy of print job to the server program via a network connection (or copy it to a special spool queue directory). The server then sends the job to the appropriate printer using the appropriate protocol on the appropriate interface or network address. Format Conversion Many times print jobs are in a format not supported by a printer. This means that Format conversion must be done on the print job. You might also want the 'Make the printer do this' which are part of the print job or meta information to be preserved by the format conversion. Application Print Job Generation This is the actual generation of the print job, i.e. - a string of bytes + meta information about the job. In many of the postings, I noticed that people were referring to apsfilter, a2ps, etc., GhostScript, and other programs. These are used in the printing process as FORMAT converters. Where is the format conversion done? You can do it in the application program. This is common. For example, a screen dump program will convert the raster image to PostScript, PBM, or some other format. However, many application programs produce only one output format, perhaps suitable for only one type of printer. If the output is PostScript, then usually it is pretty simple and will print on almost all PostScript printers. But not always. You can do it by having the application program send its output to the format converter, which then passes it to the print spooler. This is where a2ps, magicfilter, and other format conversion programs are used. Usually these work by determining the input file type, the desired output file format, and then running a set of conversion programs on the file until the desired file format is produced. You can have the print spooler do the format conversion. This usually is done by having the print spooler call the a2ps, magicfilter, or formatconversion. The benefit of this is that the print spooler usually has a better idea of the desired output format and can provide more information to the conversion process. This usually (not always!) gives better conversion results. Question: Do I need format conversion? Answer: If your files are in the same basic format as your printer requires, then you do not require format conversion. Question: But my printer does not understand PostScript and I want to print PostScript files! Answer: Then you will require a PostScript to printer compatible input converter. GhostScript has support for a very wide variety of output formats. Question: Why is this so complicated? Answer: because there are a large number of choices at each point, and a large number of different applications generating output. And a very long set of legacy applications and formats. Question: What is a 'printer driver' and why doesn't UNIX have them? Answer: The 'print driver' that you are talking about is really a set of configuration information AND a set of conversion libraries that are used by application programs to generate output that is compatible with a device. There is a well defined set of API's for these conversion routines, and a well defined set of API's that allow the conversion routines to determine what capabilities printers have. Microsoft has changed the methods and APIs for doing printing at least 4 times... This has the benefit that they do not have to support legacy APIs, and can update their printing stuff fairly easy by simply replacing everything each release. Question: Well, why doesn't somebody do this for UNIX? Answer: This has been done several times, but the problem is one of 'legacy' software and 'proprietary' interfaces. Several attempts have been made to do this, but this would require a lot of programs to be retrofitted with this capability. In addition, several of the proposed standards required the purchase or use of special libraries, etc., that did not sit well with various users. Patrick Powell Astart Technologies, papowell@astart.com 9475 Chesapeake Drive, Suite D, Network and System San Diego, CA 92123 Consulting 858-874-6543 FAX 858-279-8424 LPRng - Print Spooler (http://www.astart.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 8 18:13:39 2000 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 558) id 880E337BA97; Sat, 8 Jul 2000 18:13:38 -0700 (PDT) To: jdp@FreeBSD.ORG Subject: yield(2) (was Re: cvs commit: src/libexec/rtld-elf rtld.c rtld.h lockdflt.c) Cc: freebsd-arch@FreeBSD.ORG Message-Id: <20000709011338.880E337BA97@hub.freebsd.org> Date: Sat, 8 Jul 2000 18:13:38 -0700 (PDT) From: hsu@FreeBSD.ORG (Jeffrey Hsu) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Spinlocks are the only kinds of locks that work with all thread packages. But on uniprocessor systems they can be inefficient, because while a contender for the lock is spinning the holder of the lock cannot make any progress toward releasing it. To alleviate this disadvantage I have borrowed a trick from Sleepycat's Berkeley DB implementation. When spinning for a lock, the requester does a nanosleep() call for 1 usec. each time around the loop. This will generally yield the CPU to other threads, allowing the lock holder to finish its business and release the lock. What do you think of adding a real yield(2) system call? I do the nanosleep too in some locking code I use for a pre-forked server (like Apache), but I am unhappy with that. I chosed 100ms as the sleep time because that's one scheduler quantum (or used to be). It wasn't clear to me that a nanosleep of anything less than a quantum would guarantee a yield. Jeffrey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 8 18:48:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 5411437BDC8; Sat, 8 Jul 2000 18:48:16 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id SAA25619; Sat, 8 Jul 2000 18:48:15 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id SAA47584; Sat, 8 Jul 2000 18:48:14 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Sat, 8 Jul 2000 18:48:14 -0700 (PDT) Message-Id: <200007090148.SAA47584@vashon.polstra.com> To: hsu@freebsd.org Subject: Re: yield(2) (was Re: cvs commit: src/libexec/rtld-elf rtld.c rtld.h lockdflt.c) In-Reply-To: <20000709011338.880E337BA97@hub.freebsd.org> References: <20000709011338.880E337BA97@hub.freebsd.org> Organization: Polstra & Co., Seattle, WA Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <20000709011338.880E337BA97@hub.freebsd.org>, Jeffrey Hsu wrote: > What do you think of adding a real yield(2) system call? Well, we already have sched_yield(). Anyway, it wouldn't help the dynamic linker or spinlocks in general. What's needed is not a way for the process to yield the CPU, but a way for the running _thread_ to yield. So the yield implementation has to be tied into the threads package that's being used. And there are N different threads packages. Wine has its own, JDK has its own, Mozilla has its own, and then there's linuxthreads and of course pthreads. > I do the nanosleep too in some locking code I use for a pre-forked > server (like Apache), but I am unhappy with that. I am not too worried about it being "good" in the dynamic linker, because in practice it will spin only very rarely. The only way there is contention now is when a thread tries to do dlopen() or dlclose() while another thread is inside the dynamic linker. That just isn't going to happen very often. > I chosed 100ms as the sleep time because that's one scheduler > quantum (or used to be). It wasn't clear to me that a nanosleep of > anything less than a quantum would guarantee a yield. I don't know what the scheduler quantum is. In the kernel, even a 1 usec. sleep gets rounded up to 1/HZ = 10 msec. However, when a threads package is in use the sleep will be implemented by the threads package. Any sleep there will yield to another thread, I'd think. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 8 18:55:13 2000 Delivered-To: freebsd-arch@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 5335737BDEA; Sat, 8 Jul 2000 18:55:10 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Sat, 8 Jul 2000 21:55:09 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Matthew Dillon Cc: Marius Bendiksen , Alfred Perlstein , freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops In-Reply-To: <200007081837.LAA06503@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm still missing something. Why does a process that isn't doing anything on the filesystem still freezing? My disks are DMA, so there shouldn't be any tim ethat the kernel is busy-waiting for a seek, right? You explained why the I/O from one process can totally destroy the I/O bandwidth of the other, thank you :), but I don't see how that relates to the other part of this problem. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 8 18:58:52 2000 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 558) id 4E0F237BE3E; Sat, 8 Jul 2000 18:58:51 -0700 (PDT) To: jdp@FreeBSD.ORG Subject: Re: yield(2) (was Re: cvs commit: src/libexec/rtld-elf rtld.c rtld.h lockdflt.c) Cc: arch@FreeBSD.ORG Message-Id: <20000709015851.4E0F237BE3E@hub.freebsd.org> Date: Sat, 8 Jul 2000 18:58:51 -0700 (PDT) From: hsu@FreeBSD.ORG (Jeffrey Hsu) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Well, we already have sched_yield(). Yes, that's exactly what I was looking for. Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 8 21: 7:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id E814A37BFF2; Sat, 8 Jul 2000 21:07:09 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@[127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id WAA01726; Sat, 8 Jul 2000 22:07:07 -0600 (MDT) Message-Id: <200007090407.WAA01726@berserker.bsdi.com> To: Brian Fundakowski Feldman Cc: Matthew Dillon , Marius Bendiksen , Alfred Perlstein , freebsd-arch@freebsd.org Subject: Re: Alterations to vops From: Chuck Paterson Date: Sat, 08 Jul 2000 22:07:07 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Do you some how know that you are having to fill zero page faults from disk? Chuck ----- Begin Included Message ----- Date: Sat, 08 Jul 2000 21:55:09 -0400 From: Brian Fundakowski Feldman To: Matthew Dillon Subject: Re: Alterations to vops cc: Marius Bendiksen , Alfred Perlstein , freebsd-arch@FreeBSD.ORG I'm still missing something. Why does a process that isn't doing anything on the filesystem still freezing? My disks are DMA, so there shouldn't be any tim ethat the kernel is busy-waiting for a seek, right? You explained why the I/O from one process can totally destroy the I/O bandwidth of the other, thank you :), but I don't see how that relates to the other part of this problem. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message ----- End Included Message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 8 22:22:36 2000 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 1879137B6EB; Sat, 8 Jul 2000 22:22:27 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id XAA12359; Sat, 8 Jul 2000 23:22:26 -0600 (MDT) (envelope-from ken) Date: Sat, 8 Jul 2000 23:22:26 -0600 From: "Kenneth D. Merry" To: net@FreeBSD.ORG Subject: new zero copy sockets and NFS patches Message-ID: <20000708232226.A12332@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ -arch and -current BCC'ed for wider coverage, please direct followups to -net and/or me ] I have put a new copy of the zero copy sockets and NFS patches, against -current as of early July 8th, 2000, here: http://people.FreeBSD.ORG/~ken/zero_copy/ Feedback would be very welcome, we haven't gotten much response on this yet. Besides being generated against a newer version of -current, the following things have changed in the new patches posted above: - There was a potential panic caused by a bug in the driver side of the header splitting code. The bug only popped up with non-split packets that were long enough to fill up a mbuf. This generally meant IP fragments with a non-zero fragment offset, usually generated by NFS reads. Essentially the length of the initial receive buffer in the mbuf chain was overstated by two bytes, which caused the next mbuf pointer in the next contiguous mbuf to get partially overwritten. That could cause a panic in some situations. Thanks to Drew Gallatin for tracking this one down. - We now do header splitting on IP fragments with a fragment offset greater than 0. Thanks to Justin Gibbs for the idea. - The Tigon driver now loads and unloads cleanly. Thanks to Drew Gallatin for getting this working. - Outgoing IP fragments are now generated in page-multiple chunks if the outgoing interface's MTU is greater than a page in size. This helps receive-side bandwidth NFS significantly, since page flipping techniques can be used. Thanks to Drew Gallatin for this performance enhancement. Also, there are some new benchmark results in the benchmarks section of the web page -- Drew Gallatin has achieved 986Mbps TCP throughput with netperf, and 100MB/sec throughput over NFS. See the web page for a more detailed explanation of the hardware, conditions, etc. For those of you who missed the first message about this code (that went out to -net, -arch and -current), here's a quick list of what is included in the code: - Two sets of zero copy send code, written by Drew Gallatin and Robert Picco . - Zero copy receive code, written by Drew Gallatin. - Zero copy NFS code, written by Drew Gallatin. - Header splitting firmware for Alteon's Tigon II boards (written by me), based on version 12.4.11 of their firmware. This is used in combination with the zero copy receive code to guarantee that the payload of TCP or UDP packet is placed into a page-aligned buffer. - Alteon firmware debugging ioctls and supporting routines for the Tigon driver (also written by me). This will help anyone who is doing firmware development under FreeBSD for the Tigon boards. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message