From owner-freebsd-arch Sun Jan 7 2: 4:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by hub.freebsd.org (Postfix) with ESMTP id 344FE37B400 for ; Sun, 7 Jan 2001 02:04:35 -0800 (PST) Received: from fwd03.sul.t-online.com by mailout02.sul.t-online.com with smtp id 14FCgi-0000NZ-06; Sun, 07 Jan 2001 11:04:32 +0100 Received: from neutron.cichlids.com (520050424122-0001@[62.225.192.100]) by fmrl03.sul.t-online.com with esmtp id 14FCgh-1LvlWSC; Sun, 7 Jan 2001 11:04:31 +0100 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id 54B11AB0C; Sun, 7 Jan 2001 11:05:27 +0100 (CET) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id 4838F14B32; Sun, 7 Jan 2001 11:04:30 +0100 (CET) Date: Sun, 7 Jan 2001 11:04:30 +0100 To: opentrax@email.com Subject: Re: [Question] CVS and CVS@freebsd Message-ID: <20010107110430.C1193@cichlids.cichlids.com> References: <200101070416.UAA04408@spammie.svbug.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101070416.UAA04408@spammie.svbug.com>; from opentrax@email.com on Sat, Jan 06, 2001 at 08:16:29PM -0800 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. From: alex@big.endian.de (Alexander Langer) X-Sender: 520050424122-0001@t-dialin.net Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake opentrax@email.com (opentrax@email.com): > [Note: I've BCC'd to arch to get advanced implemention suggestions] This is not what -arch is for: freebsd-arch Architecture and design discussions Neither is -hackers: freebsd-hackers General technical discussion you should have sent this to: freebsd-questions User questions and technical support Thanks, Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 7 7:27: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id B063E37B6B3 for ; Sun, 7 Jan 2001 07:17:29 -0800 (PST) Received: from amrelay1.boi.hp.com (amrelay1.boi.hp.com [15.56.8.24]) by palrel1.hp.com (Postfix) with ESMTP id 7165CD9D; Sun, 7 Jan 2001 07:17:23 -0800 (PST) Received: from xpabh1.boi.hp.com (xpabh1.boi.hp.com [15.56.8.33]) by amrelay1.boi.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id IAA00979; Sun, 7 Jan 2001 08:17:12 -0700 (MST) Received: by xpabh1.boi.hp.com with Internet Mail Service (5.5.2653.19) id ; Sun, 7 Jan 2001 07:17:12 -0800 Message-ID: From: "DINKEY,GENE (HP-Loveland,ex1)" To: "'Doug Barton'" , freebsd-arch@freebsd.org Subject: RE: Is /etc/mergemaster.conf desirable? Date: Sun, 7 Jan 2001 07:16:39 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > -----Original Message----- > From: Doug Barton [mailto:DougB@gorean.org] > Sent: Saturday, January 06, 2001 4:28 PM > To: freebsd-arch@freebsd.org > Subject: Is /etc/mergemaster.conf desirable? > 3. Another possibility would be to make a directory in /etc/ > which could contain the conf file, and example scripts to demonstrate how > to always install (or not install) certain files, etc. The reason I suggest this > is that this is an often requested addition to mm, but it's better done > outside the script itself because IMO there are just too many > different possible combinations, and there are already too many options > to what's supposed to be a simple program. The fact that I think it's a horrible > idea also enters into it. :) I think example files should stay in /usr/share/examples or /usr/local/share/examples. Also since mergemaster needs to be tuned for the system it's on I would think that /usr/local/etc would be an appropriate place to put the mergemaster.conf. Gene Dinkey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 7 8:52:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id C8E4537B400 for ; Sun, 7 Jan 2001 08:52:07 -0800 (PST) Received: from dragon.nuxi.com (Ipitythefoolthattrustsident@trang.nuxi.com [209.152.133.57]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id IAA15749; Sun, 7 Jan 2001 08:52:07 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.1/8.11.1) id f07Gq5494378; Sun, 7 Jan 2001 08:52:05 -0800 (PST) (envelope-from obrien) Date: Sun, 7 Jan 2001 08:52:05 -0800 From: "David O'Brien" To: "DINKEY,GENE (HP-Loveland,ex1)" Cc: freebsd-arch@freebsd.org Subject: Re: Is /etc/mergemaster.conf desirable? Message-ID: <20010107085205.A94355@dragon.nuxi.com> Reply-To: freebsd-arch@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from gene_dinkey@hp.com on Sun, Jan 07, 2001 at 07:16:39AM -0800 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 On Sun, Jan 07, 2001 at 07:16:39AM -0800, DINKEY,GENE (HP-Loveland,ex1) wrote: > Also since mergemaster needs to be tuned for the system it's on I would > think that /usr/local/etc would be an appropriate place to put the > mergemaster.conf. The base system does not assume the existance of /usr/local -- that is the domain of the Ports Collection (and one can specify something other than /usr/local). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 7 16:35:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 26EA637B69E for ; Sun, 7 Jan 2001 16:34:18 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f080YB529477; Sun, 7 Jan 2001 16:34:11 -0800 Date: Sun, 7 Jan 2001 16:34:11 -0800 From: Brooks Davis To: "DINKEY,GENE (HP-Loveland,ex1)" Cc: "'Doug Barton'" , freebsd-arch@FreeBSD.ORG Subject: Re: Is /etc/mergemaster.conf desirable? Message-ID: <20010107163411.A13527@Odin.AC.HMC.Edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from gene_dinkey@hp.com on Sun, Jan 07, 2001 at 07:16:39AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 07, 2001 at 07:16:39AM -0800, DINKEY,GENE (HP-Loveland,ex1) wrote: > Also since mergemaster needs to be tuned for the > system it's on I would think that /usr/local/etc would be an appropriate > place to put the mergemaster.conf. No. It needs to be in /etc because it's part of the base. The most correct solution is probably: /etc/defaults/mergemaster.conf (this opens the following two) /etc/mergemaster.conf /etc/mergemaster.conf.local Skipping the /etc/defaults file would probably be ok, but they are the trend and I think they are a very good idea. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 8 15: 7:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 9562037B6A1 for ; Mon, 8 Jan 2001 15:06:58 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.1/8.11.1) with ESMTP id f08N66w03742; Mon, 8 Jan 2001 15:06:07 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: "David Xu" Cc: "Alfred Perlstein" , arch@FreeBSD.ORG Subject: Re: retiring kernfs In-Reply-To: Message from "David Xu" of "Fri, 22 Dec 2000 09:27:19 +0800." <000301c06bb7$05ff79b0$6201a8c0@William> Date: Mon, 08 Jan 2001 15:06:06 -0800 Message-ID: <3738.978995166@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > how can I be a volunteer to help FreeBSD to setup a ChangLog system ? > I can do it in my free time, I am a software engineer at VIA SOFTWARE, > here 70% machines are Linux machine, 30% are M$ machine, I am unhappy, > I want to help FreeBSD to improve something what I can do. The best way would be to develop some sort of cvs changelog email to HTML converter, I guess. That's not very difficult. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 8 15:17:20 2001 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 62C1437B400 for ; Mon, 8 Jan 2001 15:17:02 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f08NGw803475; Mon, 8 Jan 2001 15:16:58 -0800 (PST) Date: Mon, 8 Jan 2001 15:16:58 -0800 From: Alfred Perlstein To: Jordan Hubbard Cc: David Xu , arch@FreeBSD.ORG Subject: Re: retiring kernfs Message-ID: <20010108151658.E15744@fw.wintelcom.net> References: <3738.978995166@winston.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3738.978995166@winston.osd.bsdi.com>; from jkh@winston.osd.bsdi.com on Mon, Jan 08, 2001 at 03:06:06PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Jordan Hubbard [010108 15:06] wrote: > > how can I be a volunteer to help FreeBSD to setup a ChangLog system ? > > I can do it in my free time, I am a software engineer at VIA SOFTWARE, > > here 70% machines are Linux machine, 30% are M$ machine, I am unhappy, > > I want to help FreeBSD to improve something what I can do. > > The best way would be to develop some sort of cvs changelog email to > HTML converter, I guess. That's not very difficult. If someone where to setup a slashdot forum where committers could post important changes (or cool stuff they'd like recognition about) I'd be happy to assist (or do all of the) monitoring/moderating the posts. -- -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 Mon Jan 8 22:53:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from VL-MS-MR003.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id D792937B400; Mon, 8 Jan 2001 22:53:11 -0800 (PST) Received: from jehovah ([24.202.203.37]) by VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G6VV4904.XO9; Tue, 9 Jan 2001 01:52:57 -0500 Message-ID: <001b01c07a08$fbd0dc30$25cbca18@jehovah> From: "Bosko Milekic" To: Cc: , Subject: lock order violation? (Was: Fw: [patch] quick review) Date: Tue, 9 Jan 2001 01:54:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, As Alfred suggests below, there may be a potential problem with the mbuf wait code calling m_reclaim() [the drain routines] with the mmbfree (mbuf freelist mutex) lock held. Presently, to avoid a race condition, we call m_reclaim() with the lock held and recurse into it from the drain routines which call m_free{m}() to free mbufs. This was initially written this way; it was partially adopted from BSD/OS (it's done the same way). This way, the mbuf wait code is sure to be the first one to get the chance to allocate after the drain routines run. Unfortunately, as mentionned, there appears to be a potential lock order problem. Using as an example the BSD/OS code, something like this happens: - In ip_slowtimo(), IPQ_LOCK is obtained and with the lock held, ip_freef() is called. ip_freef() calls m_freem() which grabs the MBUF_LOCK. The lock order here is IPQ -> MBUF. - In ip_drain(), which is called from m_reclaim() with the MBUF lock already held, IPQ lock is acquired. Then ip_freef() is called which does m_freem() [which grabs MBUF lock]. The lock order here, since ip_drain() is called with MBUF already held is MBUF -> IPQ. Are we correct to assume that there is a potential for deadlock here? Clearly, if one thread in ip_slowtimo() has IPQ and another thread presently draining has MBUF, there is deadlock. The proposed patch (for FreeBSD) is at the address immediately below. For now, what it does is avoid the lock recursion by calling m_reclaim() without the mbuf lock held. We deal with the race condition. In the future, if we can, we may want to weed out the drain routines and make sure that there are no lock ordering problems; but for now, until we're done with all the locking, I think it's better to do it this way. Thanks, Bosko. P.S.: Please feel free to snip -arch from the CC list, if judged appropriate. Alfred Perlstein wrote: > * Bosko Milekic [010108 19:13] wrote: > > Hi Alfred, > > > > Can you please review this: > > > > http://people.freebsd.org/~bmilekic/code/no_rec_mbsleep.patch > > > > All it does is in m_mballoc_wait() [wait routine for mbuf allocation] > > drop the mbuf freelist lock before calling the drain routines. It avoids > > recursing into the lock from within the drain routines. We discussed this > > some time ago and you brought up the fact that it should probably be changed; > > although I don't recall exactly why (besides for generally just getting rid > > of the lock recursion and relatively large lock contention)... I recall you > > having an even more important reason, can you remind me, if applicable? > > It's a lock ordering problem, you _can_ unwind the lock in the protocol > drain routines before locking down a socketbuffer or whatnot, but the > fact of the matter is if you have to lock _anything_ you pretty much > have to unwind the lock or have a reversal problem as the mbuf system > should be a leaf-lock. > > You're also blocking the natural free'ing of the mbufs by other code > running. > > So the comment is sorta lacking, it's to avoid: > 1) lock recursion (as you stated) > 2) lock reversal > 3) needing to to explicitly unwind the lock to avoid #2 > > At least I think. :) > > It looks like BSD/os holds the lock during the protocol drain routines, > but I think that's a mistake. > > Would you mind reposting this to -net/-smp, I think I'm right about > this, but some peer review couldn't hurt, I wasn't sure if reposting > was ok considering this came across in private. > > -- > -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 Tue Jan 9 7:55:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from spirit.jaded.net (shortbus.jaded.net [216.94.132.8]) by hub.freebsd.org (Postfix) with ESMTP id 6D9CB37B6A8; Tue, 9 Jan 2001 07:54:57 -0800 (PST) Received: (from dan@localhost) by spirit.jaded.net (8.11.1/8.11.1) id f09Fsk300463; Tue, 9 Jan 2001 10:54:46 -0500 (EST) (envelope-from dan) Date: Tue, 9 Jan 2001 10:54:45 -0500 From: Dan Moschuk To: arch@freebsd.org Cc: markm@freebsd.org Subject: Keeping an /entropy file Message-ID: <20010109105445.A434@spirit.jaded.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi everyone, I hope everyone enjoyed (or is still enjoying) their holidays. Without too big of a bikeshed, what does everyone think of either adding a system crontab or modifying the random device itself to generate /entropy at a specified interval? If the system crashes and doesn't get a chance to shut itself down properly, the next bootup can be somewhat slow (especially if there's no keyboard to mash on). This is especially relevant on servers. Cheers! -dan -- Man is a rational animal who always loses his temper when he is called upon to act in accordance with the dictates of reason. -- Oscar Wilde To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 9 11:19:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 62C9B37B699; Tue, 9 Jan 2001 11:19:38 -0800 (PST) Received: from dragon.nuxi.com (Ipitythefoolthattrustsident@trang.nuxi.com [209.152.133.57]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id LAA28745; Tue, 9 Jan 2001 11:19:37 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.1/8.11.1) id f09JJal77803; Tue, 9 Jan 2001 11:19:36 -0800 (PST) (envelope-from obrien) Date: Tue, 9 Jan 2001 11:19:36 -0800 From: "David O'Brien" To: Dan Moschuk Cc: arch@freebsd.org Subject: Re: Keeping an /entropy file Message-ID: <20010109111936.A77750@dragon.nuxi.com> Reply-To: freebsd-arch@freebsd.org References: <20010109105445.A434@spirit.jaded.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010109105445.A434@spirit.jaded.net>; from dan@freebsd.org on Tue, Jan 09, 2001 at 10:54:45AM -0500 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 On Tue, Jan 09, 2001 at 10:54:45AM -0500, Dan Moschuk wrote: > Without too big of a bikeshed, what does everyone think of either > adding a system crontab or modifying the random device itself to generate > /entropy at a specified interval? It should use the value of ${entropy_file} from /etc{,/defaults}/rc.conf. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 9 12:46:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from spirit.jaded.net (shortbus.jaded.net [216.94.132.8]) by hub.freebsd.org (Postfix) with ESMTP id E836D37B402 for ; Tue, 9 Jan 2001 12:46:01 -0800 (PST) Received: (from dan@localhost) by spirit.jaded.net (8.11.1/8.11.1) id f09Kjno02646 for freebsd-arch@FreeBSD.ORG; Tue, 9 Jan 2001 15:45:49 -0500 (EST) (envelope-from dan) Date: Tue, 9 Jan 2001 15:45:49 -0500 From: Dan Moschuk To: freebsd-arch@FreeBSD.ORG Subject: Re: Keeping an /entropy file Message-ID: <20010109154549.A2618@spirit.jaded.net> References: <20010109105445.A434@spirit.jaded.net> <20010109111936.A77750@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010109111936.A77750@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Tue, Jan 09, 2001 at 11:19:36AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | > Without too big of a bikeshed, what does everyone think of either | > adding a system crontab or modifying the random device itself to generate | > /entropy at a specified interval? | | It should use the value of ${entropy_file} from /etc{,/defaults}/rc.conf. Which eliminates modifying the random device. /etc/crontab, then? -- Man is a rational animal who always loses his temper when he is called upon to act in accordance with the dictates of reason. -- Oscar Wilde To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 10 0:50:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 57F7A37B401; Wed, 10 Jan 2001 00:50:27 -0800 (PST) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 14GGxc-0004A7-00; Wed, 10 Jan 2001 10:50:24 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id KAA08451; Wed, 10 Jan 2001 10:50:23 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 8232; Wed Jan 10 10:49:25 2001 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.20 #1) id 14GGwf-000IZu-00; Wed, 10 Jan 2001 10:49:25 +0200 From: Sheldon Hearn To: Dan Moschuk Cc: freebsd-arch@freebsd.org Subject: Re: Keeping an /entropy file In-reply-to: Your message of "Tue, 09 Jan 2001 15:45:49 EST." <20010109154549.A2618@spirit.jaded.net> Date: Wed, 10 Jan 2001 10:49:25 +0200 Message-ID: <71417.979116565@axl.fw.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 09 Jan 2001 15:45:49 EST, Dan Moschuk wrote: > | > Without too big of a bikeshed, what does everyone think of either > | > adding a system crontab or modifying the random device itself to generate > | > /entropy at a specified interval? > | > | It should use the value of ${entropy_file} from /etc{,/defaults}/rc.conf. > > Which eliminates modifying the random device. /etc/crontab, then? Assuming Mark doesn't have any better ideas about how to do this, just make sure that the script called from the crontab uses rc.source_conf to get the value of ${entropy_file} . I'm not convinced that the random device isn't the best candidate for the job, though. What about using a writable sysctl to specify to the random device the location of the entropy file? The value of the sysctl could be set early in rc . Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 10 2:10:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id A3FB337B400; Wed, 10 Jan 2001 02:10:41 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id LAA04038; Wed, 10 Jan 2001 11:10:40 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Dan Moschuk Cc: arch@FreeBSD.ORG, markm@FreeBSD.ORG Subject: Re: Keeping an /entropy file References: <20010109105445.A434@spirit.jaded.net> From: Dag-Erling Smorgrav Date: 10 Jan 2001 11:10:39 +0100 In-Reply-To: Dan Moschuk's message of "Tue, 9 Jan 2001 10:54:45 -0500" Message-ID: Lines: 11 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dan Moschuk writes: > Without too big of a bikeshed, what does everyone think of either > adding a system crontab or modifying the random device itself to generate > /entropy at a specified interval? Doesn't that consume a largish amount of entropy? If so, I don't think it's a very good idea. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 10 2:21:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 2D90937B401; Wed, 10 Jan 2001 02:21:17 -0800 (PST) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f0AAKsI03830; Wed, 10 Jan 2001 12:20:57 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200101101020.f0AAKsI03830@gratis.grondar.za> To: Dag-Erling Smorgrav Cc: Dan Moschuk , arch@FreeBSD.ORG, markm@FreeBSD.ORG Subject: Re: Keeping an /entropy file References: In-Reply-To: ; from Dag-Erling Smorgrav "10 Jan 2001 11:10:39 +0100." Date: Wed, 10 Jan 2001 12:21:26 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Dan Moschuk writes: > > Without too big of a bikeshed, what does everyone think of either > > adding a system crontab or modifying the random device itself to generate > > /entropy at a specified interval? > > Doesn't that consume a largish amount of entropy? If so, I don't think > it's a very good idea. It's mandated by the Yarrow algorithm, and it ensures a safe startup. Yarrow is resistant to entropy starvation, so the concept of "emptying the pool" is far less important than the ability to recover encryption keys of the ciphers used. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 10 3:46:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id F150037B69E; Wed, 10 Jan 2001 03:46:36 -0800 (PST) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 14GJi6-0006je-00; Wed, 10 Jan 2001 13:46:34 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id NAA19146; Wed, 10 Jan 2001 13:46:32 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 18986; Wed Jan 10 13:45:58 2001 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.20 #1) id 14GJhV-000Iyq-00; Wed, 10 Jan 2001 13:45:57 +0200 From: Sheldon Hearn To: Dan Moschuk Cc: freebsd-arch@freebsd.org Subject: Re: Keeping an /entropy file In-reply-to: Your message of "Wed, 10 Jan 2001 10:49:25 +0200." <71417.979116565@axl.fw.uunet.co.za> Date: Wed, 10 Jan 2001 13:45:57 +0200 Message-ID: <72963.979127157@axl.fw.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 10 Jan 2001 10:49:25 +0200, Sheldon Hearn wrote: > Assuming Mark doesn't have any better ideas about how to do this, just > make sure that the script called from the crontab uses rc.source_conf to > get the value of ${entropy_file} . I'm busy working on this, by the way. Patches to follow. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 10 11:41:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id 9C5CE37B404; Wed, 10 Jan 2001 11:41:38 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id GAA04093; Thu, 11 Jan 2001 06:41:19 +1100 (EDT) Received: from pc0640.alcatel.com.au ([139.188.24.25]) by cim.alcatel.com.au (PMDF V5.2-32 #37640) with ESMTP id <01JYRSHEIVN490HQH5@cim.alcatel.com.au>; Thu, 11 Jan 2001 06:41:18 +1100 Received: (from jeremyp@localhost) by pc0640.alcatel.com.au (8.8.7/8.8.7) id GAA10217; Thu, 11 Jan 2001 06:41:31 +1100 (EST envelope-from jeremyp) Date: Thu, 11 Jan 2001 06:41:26 +1100 From: Peter Jeremy Subject: Re: cvs commit: src/sys/gnu/i386/isa dgb.c dgm.c dgmreg.h dgreg.h In-reply-to: <200101052146.f05LkDi49430@hak.lan.Awfulhak.org>; from brian@Awfulhak.org on Fri, Jan 05, 2001 at 09:46:13PM +0000 To: Brian Somers Cc: Sergey Babkin , freebsd-arch@FreeBSD.ORG Message-id: <20010111064126.A10214@pc0640.alcatel.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <200101052146.f05LkDi49430@hak.lan.Awfulhak.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jan 05, 2001 at 09:46:13PM +0000, Brian Somers wrote: >I have the a driver that will replace dgb and dgm and support a bunch >of other digiboards. Now all I need is the time to add back the >{E,}ISA probe routines. There are come significant differences between the [E]ISA aand PCI DigiBoards: - The [E]ISA cards use I/O ports whilst the PCI boards use memory-mapped registers. - The PCI cards have a flat 4MB window. The [E]ISA cards access on-board memory via a 8KB or 32KB window. This means that the code does a lot of checking to see if the card is PCI or not, resulting in expressions like: ((IS_PCI(board_type)) ? *mem[reg] : inb(base + reg)) The Linux driver (maintained by Digi) uses (the equivalent of) virtual functions for all card accesses. Both these approaches add run-time overheads and can adversely affect code legibility. I believe that having separate [E]ISA and PCI drivers would make the code smaller and more understandable as well as reducing overheads (though I can't quantify the latter). There may (and probably are) other drivers that could similarly benefit from having different drivers for different buses. The disadvantages are: - Two drivers sharing common code increases the maintenance load (and the probability that a bug in the common code won't be fixed in both places). - A system with multiple cards on different buses would need several copies of similar drivers. I believe the latter situation is fairly unlikely and can be ignored as a disadvantage. The former is a real problem, but can be (at least partially) offset by sharing source code files between the different drivers. Would it be reasonable to have different drivers for different bus versions of the same card? Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 10 11:50:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 0D1ED37B401; Wed, 10 Jan 2001 11:49:59 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f0AJp1X58789; Wed, 10 Jan 2001 13:51:01 -0600 (CST) (envelope-from jlemon) Date: Wed, 10 Jan 2001 13:51:01 -0600 From: Jonathan Lemon To: Peter Jeremy Cc: Brian Somers , Sergey Babkin , freebsd-arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/gnu/i386/isa dgb.c dgm.c dgmreg.h dgreg.h Message-ID: <20010110135101.S29115@prism.flugsvamp.com> References: <200101052146.f05LkDi49430@hak.lan.Awfulhak.org> <20010111064126.A10214@pc0640.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20010111064126.A10214@pc0640.alcatel.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 11, 2001 at 06:41:26AM +1100, Peter Jeremy wrote: > There are come significant differences between the [E]ISA aand PCI > DigiBoards: > - The [E]ISA cards use I/O ports whilst the PCI boards use > memory-mapped registers. > - The PCI cards have a flat 4MB window. The [E]ISA cards access > on-board memory via a 8KB or 32KB window. > > This means that the code does a lot of checking to see if the card > is PCI or not, resulting in expressions like: > ((IS_PCI(board_type)) ? *mem[reg] : inb(base + reg)) This should be taken care of by the bus_space() macros; which is already done by most drivers in the tree. (Many drivers can run in either PIO or memory mapped mode) > The Linux driver (maintained by Digi) uses (the equivalent of) virtual > functions for all card accesses. This is another option; the ida driver does something like this, if I understand you correctly; it uses board-specific accessor functions to hide hardware implementation details. > Would it be reasonable to have different drivers for different bus > versions of the same card? I don't think this would be a good idea. We already have a framework where the common code is kept in a foo.c file, and the bus-specific code in foo_{pci|eisa}.c files, but the entire thing is wrapped up in a single "foo" driver. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 10 14:45:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id EDCCF37B402; Wed, 10 Jan 2001 14:45:15 -0800 (PST) Received: from slave (Studded@slave [10.0.0.1]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id OAA96256; Wed, 10 Jan 2001 14:44:37 -0800 (PST) (envelope-from DougB@gorean.org) Date: Wed, 10 Jan 2001 14:44:37 -0800 (PST) From: Doug Barton X-X-Sender: To: Sheldon Hearn Cc: Dan Moschuk , Subject: Re: Keeping an /entropy file In-Reply-To: <72963.979127157@axl.fw.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 Wed, 10 Jan 2001, Sheldon Hearn wrote: > > > On Wed, 10 Jan 2001 10:49:25 +0200, Sheldon Hearn wrote: > > > Assuming Mark doesn't have any better ideas about how to do this, just > > make sure that the script called from the crontab uses rc.source_conf to > > get the value of ${entropy_file} . > > I'm busy working on this, by the way. Patches to follow. Mark and I hammered out the requirements this weekend, I just haven't had a chance to finish the stuff yet. I'll try to finish it up tonight. Sheldon, if you're interested in the plan, let me know. Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White 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 Wed Jan 10 15:26:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id CC7C637B69F; Wed, 10 Jan 2001 15:26:14 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f0ANNcQ63145; Wed, 10 Jan 2001 15:23:39 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200101102323.f0ANNcQ63145@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jonathan Lemon Cc: Peter Jeremy , Sergey Babkin , freebsd-arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/gnu/i386/isa dgb.c dgm.c dgmreg.h dgreg.h In-Reply-To: <20010110135101.S29115@prism.flugsvamp.com> Date: Wed, 10 Jan 2001 15:23:38 -0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jonathan Lemon wrote: > On Thu, Jan 11, 2001 at 06:41:26AM +1100, Peter Jeremy wrote: > > There are come significant differences between the [E]ISA aand PCI > > DigiBoards: > > - The [E]ISA cards use I/O ports whilst the PCI boards use > > memory-mapped registers. > > - The PCI cards have a flat 4MB window. The [E]ISA cards access > > on-board memory via a 8KB or 32KB window. > > > > This means that the code does a lot of checking to see if the card > > is PCI or not, resulting in expressions like: > > ((IS_PCI(board_type)) ? *mem[reg] : inb(base + reg)) > > This should be taken care of by the bus_space() macros; which is > already done by most drivers in the tree. (Many drivers can run > in either PIO or memory mapped mode) But the bus_space_() stuff doesn't handle changing register windows etc. eg: if you have a 64K memory space and can read/write it directly when memory mapped, but when on ISA it is all crammed into 16 lots of 4K windows then bus_space_() cannot save you from this. ie: if (IS_PCI(board_type)) { value = *mem[reg]; } else { if (board->window != window(reg)) board->window = window(reg); value = inb(base + (reg % winsize)); } Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 10 16:35:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id D726B37B400; Wed, 10 Jan 2001 16:35:29 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0B0Z1s21398; Wed, 10 Jan 2001 17:35:13 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101110035.f0B0Z1s21398@aslan.scsiguy.com> To: Peter Wemm Cc: Jonathan Lemon , Peter Jeremy , Sergey Babkin , freebsd-arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/gnu/i386/isa dgb.c dgm.c dgmreg.h dgreg.h In-Reply-To: Your message of "Wed, 10 Jan 2001 15:23:38 PST." <200101102323.f0ANNcQ63145@mobile.wemm.org> Date: Wed, 10 Jan 2001 17:35:01 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> This should be taken care of by the bus_space() macros; which is >> already done by most drivers in the tree. (Many drivers can run >> in either PIO or memory mapped mode) > >But the bus_space_() stuff doesn't handle changing register windows etc. >eg: if you have a 64K memory space and can read/write it directly when >memory mapped, but when on ISA it is all crammed into 16 lots of 4K windows >then bus_space_() cannot save you from this. > >ie: > if (IS_PCI(board_type)) { > value = *mem[reg]; > } else { > if (board->window != window(reg)) > board->window = window(reg); > value = inb(base + (reg % winsize)); > } > >Cheers, >-Peter Right, so abstract that out with a macro. If performance is critical, create a set of inline functions for key operations, and have the macros optimize the access depending on which "attachment" they are included into. This means you have common code and pay no speed penalty for using it. Determine the equation for bloat vs. speed and you can easily decide which functionality can survive without optimized access (this code goes in foo.c) and which code can't (goes in foo_bus.c with #define indicating which access type to optimize for). -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 10 17: 3:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (dhcp244.osd.bsdi.com [204.216.28.244]) by hub.freebsd.org (Postfix) with ESMTP id 8619D37B400; Wed, 10 Jan 2001 17:03:16 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.1/8.11.1) with ESMTP id f0B1G8f00436; Wed, 10 Jan 2001 17:16:08 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200101110116.f0B1G8f00436@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Peter Wemm Cc: Jonathan Lemon , Peter Jeremy , Sergey Babkin , freebsd-arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/gnu/i386/isa dgb.c dgm.c dgmreg.h dgreg.h In-reply-to: Your message of "Wed, 10 Jan 2001 15:23:38 PST." <200101102323.f0ANNcQ63145@mobile.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Jan 2001 17:16:08 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > This means that the code does a lot of checking to see if the card > > > is PCI or not, resulting in expressions like: > > > ((IS_PCI(board_type)) ? *mem[reg] : inb(base + reg)) > > > > This should be taken care of by the bus_space() macros; which is > > already done by most drivers in the tree. (Many drivers can run > > in either PIO or memory mapped mode) > > But the bus_space_() stuff doesn't handle changing register windows etc. > eg: if you have a 64K memory space and can read/write it directly when > memory mapped, but when on ISA it is all crammed into 16 lots of 4K windows > then bus_space_() cannot save you from this. > > ie: > if (IS_PCI(board_type)) { > value = *mem[reg]; > } else { > if (board->window != window(reg)) > board->window = window(reg); > value = inb(base + (reg % winsize)); > } Typically, if you have half a clue, you will separate the ISA-aware parts of the driver from the PCI-aware parts and use a set of function vectors. Makes for much cleaner code. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 10 19:23:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id F28EB37B400; Wed, 10 Jan 2001 19:23:04 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f0B3N4Q64114; Wed, 10 Jan 2001 19:23:04 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200101110323.f0B3N4Q64114@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Mike Smith Cc: Jonathan Lemon , Peter Jeremy , Sergey Babkin , freebsd-arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/gnu/i386/isa dgb.c dgm.c dgmreg.h dgreg.h In-Reply-To: <200101110116.f0B1G8f00436@mass.osd.bsdi.com> Date: Wed, 10 Jan 2001 19:23:04 -0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: > > > > This means that the code does a lot of checking to see if the card > > > > is PCI or not, resulting in expressions like: > > > > ((IS_PCI(board_type)) ? *mem[reg] : inb(base + reg)) > > > > > > This should be taken care of by the bus_space() macros; which is > > > already done by most drivers in the tree. (Many drivers can run > > > in either PIO or memory mapped mode) > > > > But the bus_space_() stuff doesn't handle changing register windows etc. > > eg: if you have a 64K memory space and can read/write it directly when > > memory mapped, but when on ISA it is all crammed into 16 lots of 4K windows > > then bus_space_() cannot save you from this. > > > > ie: > > if (IS_PCI(board_type)) { > > value = *mem[reg]; > > } else { > > if (board->window != window(reg)) > > board->window = window(reg); > > value = inb(base + (reg % winsize)); > > } > > Typically, if you have half a clue, you will separate the ISA-aware parts > of the driver from the PCI-aware parts and use a set of function vectors. > Makes for much cleaner code. 8) Yes, that is what Peter Jeremy said in the original email.. It can be done but doesn't come for free. I was merely responding to the suggestion to use the bus_space_ macros with a reason why they cannot be used in this scenario to hide the different access methods. Yes, bus_space can be used in the backend functions, but not at the top level driver. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 10 20:36:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from caspian.scsiguy.com (caspian.scsiguy.com [63.229.232.105]) by hub.freebsd.org (Postfix) with ESMTP id 634A537B6A3 for ; Wed, 10 Jan 2001 20:36:02 -0800 (PST) Received: from caspian.scsiguy.com (localhost [127.0.0.1]) by caspian.scsiguy.com (8.11.1/8.11.1) with ESMTP id f0B4a5T00319 for ; Wed, 10 Jan 2001 21:36:05 -0700 (MST) (envelope-from gibbs@caspian.scsiguy.com) Message-Id: <200101110436.f0B4a5T00319@caspian.scsiguy.com> To: freebsd-arch@FreeBSD.org Subject: Re: Proposed chage to sbuf semantics. Date: Wed, 10 Jan 2001 21:36:05 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have yet to see a single comment about these changes. If I don't hear anything by Friday, I'll commit them to the tree. -- Justin ------- Forwarded Message To: freebsd-arch@FreeBSD.org Subject: Proposed chage to sbuf semantics. Date: Thu, 04 Jan 2001 21:59:55 -0700 From: "Justin T. Gibbs" I decided to use the sbuf code in some recent cardbus enhancements. Unfortunately, the sbuf code tried its best to prevent me from doing what I wanted to do. My goal was to fill a fixed sized buffer from a whole slew of data sources that may or may not be available. I didn't care if the end result was a truncated string so long as it was nul terminated. The only additional requirement for this task was the ability to occasionally find out if anything had been written to the sbuf prior to finalizing it (you may want to add a separator before adding new data, etc.) This kind of scenario is all over the CAM code too... you prioritize what you put in the passed in buffer and losing data off the end is okay. The following patches allowed me to get what I needed out of sbuf. I don't think it is unreasonable to allow this kind of behavior, but I'm sure someone will disagree. 8-) 1) Allow the user to finalize an overflowed buffer. If the user really cares about overflow, all they need to do is look at the error code of all previos operations or explicitly check for overflow prior to finalizing. Finalizing now clears the overflow flag as the string is null terminated, which allowes all "after finalize" methods to operate on this sbuf. 2) Remove SBUF_HASOVERFLOWED test in sbuf_data(). It can never be true if we've finalized the sbuf which is an asserted state for this method. 3) Add an SBUF_HASDATA macro that indicates if any data is currently in the sbuf. sbuf_len() is only available once you finalize an sbuf or I would have used that. 4) Add an SBUF_CLEARFLAG macro to mirror SBUF_SETFLAG(). It is debatable whether this should be in the exported sbuf API, but the same could be said for SBUF_SETFLAG(). - -- Justin Index: kern/subr_sbuf.c =================================================================== RCS file: /usr/cvs/src/sys/kern/subr_sbuf.c,v retrieving revision 1.1 diff -c -r1.1 subr_sbuf.c *** kern/subr_sbuf.c 2000/12/13 19:51:07 1.1 - --- kern/subr_sbuf.c 2001/01/03 20:36:39 *************** *** 220,229 **** assert_sbuf_integrity(s); assert_sbuf_state(s, 0); ! if (SBUF_HASOVERFLOWED(s)) ! return (-1); ! ! s->s_buf[s->s_len++] = '\0'; SBUF_SETFLAG(s, SBUF_FINISHED); return (0); } - --- 220,230 ---- assert_sbuf_integrity(s); assert_sbuf_state(s, 0); ! if (SBUF_HASOVERFLOWED(s)) { ! s->s_buf[s->s_len] = '\0'; ! SBUF_CLEARFLAG(s, SBUF_OVERFLOWED); ! } else ! s->s_buf[s->s_len++] = '\0'; SBUF_SETFLAG(s, SBUF_FINISHED); return (0); } *************** *** 237,244 **** assert_sbuf_integrity(s); assert_sbuf_state(s, SBUF_FINISHED); - - if (SBUF_HASOVERFLOWED(s)) - - return (NULL); return s->s_buf; } - --- 238,243 ---- Index: sys/sbuf.h =================================================================== RCS file: /usr/cvs/src/sys/sys/sbuf.h,v retrieving revision 1.1 diff -c -r1.1 sbuf.h *** sys/sbuf.h 2000/12/13 19:51:07 1.1 - --- sys/sbuf.h 2001/01/03 20:40:54 *************** *** 53,63 **** - --- 53,65 ---- #define SBUF_ISFINISHED(s) ((s)->s_flags & SBUF_FINISHED) #define SBUF_HASOVERFLOWED(s) ((s)->s_flags & SBUF_OVERFLOWED) #define SBUF_HASROOM(s) ((s)->s_len < (s)->s_size - 1) + #define SBUF_HASDATA(s) ((s)->s_len > 0) /* * Other macros */ #define SBUF_SETFLAG(s, f) do { (s)->s_flags |= (f); } while (0) + #define SBUF_CLEARFLAG(s, f) do { (s)->s_flags &= ~(f); } while (0) /* * API functions ------- 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 Thu Jan 11 1: 9:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id F3EC537B401 for ; Thu, 11 Jan 2001 01:09:05 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id KAA03696; Thu, 11 Jan 2001 10:08:57 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Justin T. Gibbs" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed chage to sbuf semantics. References: <200101110436.f0B4a5T00319@caspian.scsiguy.com> From: Dag-Erling Smorgrav Date: 11 Jan 2001 10:08:56 +0100 In-Reply-To: "Justin T. Gibbs"'s message of "Wed, 10 Jan 2001 21:36:05 -0700" Message-ID: Lines: 35 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Justin T. Gibbs" writes: > 1) Allow the user to finalize an overflowed buffer. If the user > really cares about overflow, all they need to do is look at > the error code of all previos operations or explicitly check > for overflow prior to finalizing. If the user really wants to finalize an overflowed sbuf, they can explicitly un-overflow it using setpos() (this is documented in the NOTES section of the man page). Please to not change the behavior of sbuf_finish(). > 2) Remove SBUF_HASOVERFLOWED test in sbuf_data(). It can never > be true if we've finalized the sbuf which is an asserted state > for this method. Correct. > 3) Add an SBUF_HASDATA macro that indicates if any data is currently > in the sbuf. sbuf_len() is only available once you finalize an > sbuf or I would have used that. If this is meant to be part of the API, it should be a function (or a macro named and written to look like a function). > 4) Add an SBUF_CLEARFLAG macro to mirror SBUF_SETFLAG(). It is > debatable whether this should be in the exported sbuf API, > but the same could be said for SBUF_SETFLAG(). None of these macros are part of the API. I guess I could have put them in subr_sbuf.c instead of sbuf.c, but I wanted to keep them close to the struct definition. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 11 1:23:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 2E2F037B401 for ; Thu, 11 Jan 2001 01:23:06 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id KAA03791; Thu, 11 Jan 2001 10:23:01 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Justin T. Gibbs" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed chage to sbuf semantics. References: <200101110436.f0B4a5T00319@caspian.scsiguy.com> From: Dag-Erling Smorgrav Date: 11 Jan 2001 10:23:01 +0100 In-Reply-To: Dag-Erling Smorgrav's message of "11 Jan 2001 10:08:56 +0100" Message-ID: Lines: 12 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > If the user really wants to finalize an overflowed sbuf, they can > explicitly un-overflow it using setpos() (this is documented in the > NOTES section of the man page). Please to not change the behavior of > sbuf_finish(). Actually, there's one alternative: provide a flag (settable at sbuf_new() time) that tells sbuf_finish() to ignore overflows. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 11 2: 6:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id EA39437B401; Thu, 11 Jan 2001 02:06:34 -0800 (PST) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 14Geco-0005xp-00; Thu, 11 Jan 2001 12:06:30 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id MAA22452; Thu, 11 Jan 2001 12:06:28 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 22377; Thu Jan 11 12:05:48 2001 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.20 #1) id 14Gec8-0000kd-00; Thu, 11 Jan 2001 12:05:48 +0200 From: Sheldon Hearn To: freebsd-arch@freebsd.org Cc: Dan Moschuk Subject: Re: Keeping an /entropy file In-reply-to: Your message of "Wed, 10 Jan 2001 14:44:37 PST." Date: Thu, 11 Jan 2001 12:05:48 +0200 Message-ID: <2890.979207548@axl.fw.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 10 Jan 2001 14:44:37 PST, Doug Barton wrote: > > I'm busy working on this, by the way. Patches to follow. > > Mark and I hammered out the requirements this weekend, I just > haven't had a chance to finish the stuff yet. Taken offline. 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 Jan 11 6:37:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 8670D37B698 for ; Thu, 11 Jan 2001 06:37:12 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0BEYes28373; Thu, 11 Jan 2001 07:34:41 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101111434.f0BEYes28373@aslan.scsiguy.com> To: Dag-Erling Smorgrav Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed chage to sbuf semantics. In-Reply-To: Your message of "11 Jan 2001 10:08:56 +0100." Date: Thu, 11 Jan 2001 07:34:40 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >"Justin T. Gibbs" writes: >> 1) Allow the user to finalize an overflowed buffer. If the user >> really cares about overflow, all they need to do is look at >> the error code of all previos operations or explicitly check >> for overflow prior to finalizing. > >If the user really wants to finalize an overflowed sbuf, they can >explicitly un-overflow it using setpos() (this is documented in the >NOTES section of the man page). Please to not change the behavior of >sbuf_finish(). This means the caller must know the length of the buffer and set the position correctly. If the sbuf is passed into a routine, this requires looking inside the sbuf to determine the buffer size. It was my understanding that sbufs should be treated as opaque. I'd rather have the code to fix an overflow written once an available in the sbuf code than force each client to get this right. >> 3) Add an SBUF_HASDATA macro that indicates if any data is currently >> in the sbuf. sbuf_len() is only available once you finalize an >> sbuf or I would have used that. > >If this is meant to be part of the API, it should be a function (or a >macro named and written to look like a function). Why is this different than any of the other macro predicates? Or are the predicates not part of the interface. If so, they should be moved to the .c file. >> 4) Add an SBUF_CLEARFLAG macro to mirror SBUF_SETFLAG(). It is >> debatable whether this should be in the exported sbuf API, >> but the same could be said for SBUF_SETFLAG(). > >None of these macros are part of the API. I guess I could have put >them in subr_sbuf.c instead of sbuf.c, but I wanted to keep them close >to the struct definition. I didn't read the man page, I read the code. Having these macros in the header invites their usage. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 11 6:38:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id C128837B400 for ; Thu, 11 Jan 2001 06:38:24 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0BEZrs28389; Thu, 11 Jan 2001 07:35:54 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101111435.f0BEZrs28389@aslan.scsiguy.com> To: Dag-Erling Smorgrav Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed chage to sbuf semantics. In-Reply-To: Your message of "11 Jan 2001 10:23:01 +0100." Date: Thu, 11 Jan 2001 07:35:53 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Dag-Erling Smorgrav writes: >> If the user really wants to finalize an overflowed sbuf, they can >> explicitly un-overflow it using setpos() (this is documented in the >> NOTES section of the man page). Please to not change the behavior of >> sbuf_finish(). > >Actually, there's one alternative: provide a flag (settable at >sbuf_new() time) that tells sbuf_finish() to ignore overflows. Why should the constuctor of the sbuf have to know this. Perhaps the sbuf is filled by helper functions, etc. This just ties the hand of the user. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 11 6:46:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (hades.cybercity.dk [212.242.42.118]) by hub.freebsd.org (Postfix) with ESMTP id 6F7EF37B400 for ; Thu, 11 Jan 2001 06:46:07 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0BEjxZ08609; Thu, 11 Jan 2001 15:45:59 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Justin T. Gibbs" Cc: Dag-Erling Smorgrav , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed chage to sbuf semantics. In-Reply-To: Your message of "Thu, 11 Jan 2001 07:34:40 MST." <200101111434.f0BEYes28373@aslan.scsiguy.com> Date: Thu, 11 Jan 2001 15:45:59 +0100 Message-ID: <8607.979224359@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As original perpetrator of the sbufs, I'd like to chime in briefly. I agree with Justin about being able to succesfully retreive an overflowed sbuf. I would even suggest that finish replaces the final characters in an overflowed sbuf with "[...]" as a generic marker that overflow happened. I also agree with Dag-Erling that the API should be entirely function based. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | 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 Thu Jan 11 6:50:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 18AE937B401 for ; Thu, 11 Jan 2001 06:50:07 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id PAA04807; Thu, 11 Jan 2001 15:50:03 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Justin T. Gibbs" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed chage to sbuf semantics. References: <200101111434.f0BEYes28373@aslan.scsiguy.com> From: Dag-Erling Smorgrav Date: 11 Jan 2001 15:50:02 +0100 In-Reply-To: "Justin T. Gibbs"'s message of "Thu, 11 Jan 2001 07:34:40 -0700" Message-ID: Lines: 13 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Justin T. Gibbs" writes: > This means the caller must know the length of the buffer and set > the position correctly. [...] OK, how about sbuf_finish() clears the overflow but still returns -1? > I didn't read the man page, I read the code. This is FreeBSD, not Linux. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 11 7: 4:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 01E7437B402 for ; Thu, 11 Jan 2001 07:04:02 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0BF3ws29178; Thu, 11 Jan 2001 08:03:58 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101111503.f0BF3ws29178@aslan.scsiguy.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Dag-Erling Smorgrav Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed chage to sbuf semantics. In-Reply-To: Your message of "11 Jan 2001 15:50:02 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Jan 2001 08:03:58 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >OK, how about sbuf_finish() clears the overflow but still returns -1? But sbuf_finish() hasn't failed. Remember that I've had the oportunity to notice the overflow on every other sbuf function invokation and I've chosen to ignore it. So long as SBUF_HASOVERFLOWED (or a function equivalent) is provided, any caller that really cares can check prior to calling sbuf_finish(). One other point. It would be nice if the return values were in the errno style unless you believe that the only error that can ever be returned indicates that an overflow occurred. >> I didn't read the man page, I read the code. > >This is FreeBSD, not Linux. I hardly see how this matters. Private interfaces should be documented as such in the header file (or not exist there at all) as well as the man page. Sometimes reading the code is easier than reading the man page and regardless of how you feel about the necessity of reading the man page the fact is that some people wont. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 11 7:11:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 1683037B401 for ; Thu, 11 Jan 2001 07:11:15 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id QAA04912; Thu, 11 Jan 2001 16:11:00 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Justin T. Gibbs" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed chage to sbuf semantics. References: <200101111503.f0BF3ws29178@aslan.scsiguy.com> From: Dag-Erling Smorgrav Date: 11 Jan 2001 16:11:00 +0100 In-Reply-To: "Justin T. Gibbs"'s message of "Thu, 11 Jan 2001 08:03:58 -0700" Message-ID: Lines: 11 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Justin T. Gibbs" writes: > One other point. It would be nice if the return values were in the > errno style unless you believe that the only error that can ever be > returned indicates that an overflow occurred. All the possible error conditions are documented in the man page. Please read it. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 11 7:20:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id C12A537B400; Thu, 11 Jan 2001 07:20:03 -0800 (PST) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id IAA04739; Thu, 11 Jan 2001 08:14:34 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpdAAAfkaWti; Thu Jan 11 08:13:27 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id IAA15411; Thu, 11 Jan 2001 08:18:32 -0700 (MST) From: Terry Lambert Message-Id: <200101111518.IAA15411@usr08.primenet.com> Subject: Re: cvs commit: src/sys/gnu/i386/isa dgb.c dgm.c dgmreg.h dgreg.h To: peter@netplex.com.au (Peter Wemm) Date: Thu, 11 Jan 2001 15:18:32 +0000 (GMT) Cc: msmith@FreeBSD.ORG (Mike Smith), jlemon@flugsvamp.com (Jonathan Lemon), peter.jeremy@alcatel.com.au (Peter Jeremy), babkin@FreeBSD.ORG (Sergey Babkin), freebsd-arch@FreeBSD.ORG In-Reply-To: <200101110323.f0B3N4Q64114@mobile.wemm.org> from "Peter Wemm" at Jan 10, 2001 07:23:04 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 > > > ie: > > > if (IS_PCI(board_type)) { > > > value = *mem[reg]; > > > } else { > > > if (board->window != window(reg)) > > > board->window = window(reg); > > > value = inb(base + (reg % winsize)); > > > } > > > > Typically, if you have half a clue, you will separate the ISA-aware parts > > of the driver from the PCI-aware parts and use a set of function vectors. > > Makes for much cleaner code. 8) > > Yes, that is what Peter Jeremy said in the original email.. It can be > done but doesn't come for free. I was merely responding to the suggestion > to use the bus_space_ macros with a reason why they cannot be used in this > scenario to hide the different access methods. Yes, bus_space can be used > in the backend functions, but not at the top level driver. Surely, this is a problem which has to be solved similarly for multiple cards with similar function. Rather than being a one-off, the abstraction should at _least_ have a recommended form, if not a documented DKI mechanism. 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 Thu Jan 11 7:20:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 6556337B401 for ; Thu, 11 Jan 2001 07:20:25 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0BFKLs29913; Thu, 11 Jan 2001 08:20:21 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101111520.f0BFKLs29913@aslan.scsiguy.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Dag-Erling Smorgrav Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed chage to sbuf semantics. In-Reply-To: Your message of "11 Jan 2001 16:11:00 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Jan 2001 08:20:21 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >"Justin T. Gibbs" writes: >> One other point. It would be nice if the return values were in the >> errno style unless you believe that the only error that can ever be >> returned indicates that an overflow occurred. > >All the possible error conditions are documented in the man page. >Please read it. Note I said "ever". Should the implementation change, the reason for failure may also change. Simply updating the man page in this case won't automatically update the code that uses the interface. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 11 7:52:11 2001 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 69A2337B400 for ; Thu, 11 Jan 2001 07:51:52 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id IAA19744; Thu, 11 Jan 2001 08:47:36 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp05.primenet.com, id smtpdAAAvTaqEM; Thu Jan 11 08:47:24 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id IAA16079; Thu, 11 Jan 2001 08:51:33 -0700 (MST) From: Terry Lambert Message-Id: <200101111551.IAA16079@usr08.primenet.com> Subject: Re: Proposed chage to sbuf semantics. To: gibbs@scsiguy.com (Justin T. Gibbs) Date: Thu, 11 Jan 2001 15:51:33 +0000 (GMT) Cc: des@ofug.org (Dag-Erling Smorgrav), freebsd-arch@FreeBSD.ORG In-Reply-To: <200101111503.f0BF3ws29178@aslan.scsiguy.com> from "Justin T. Gibbs" at Jan 11, 2001 08:03:58 AM 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 > >> I didn't read the man page, I read the code. > > > >This is FreeBSD, not Linux. > > I hardly see how this matters. Private interfaces should be > documented as such in the header file (or not exist there at all) > as well as the man page. Sometimes reading the code is easier than > reading the man page and regardless of how you feel about the > necessity of reading the man page the fact is that some people > wont. The claim that "This is FreeBSD, not Linux." should probably have been "This is FreeBSD, not Linux; therefore the code is more authoritative than the documentation, since documentation will usually lag the code by a significant amount.". If the macros are not for externa use, then they should not be in the external namespace, period. If they need to be accessed in multiple source files, then something like: #ifdef _INTERNAL_SBUF_ ... #endif /* _INTERNAL_SBUF_*/ should surround their use, and that manifest should be defined before inclusion of the header file to allow their use (this is a gross hack, in any case: more probably, the macros should be eliminated to the point they exist in only one source file, not a header file). My opinion is that if something is defined in scope, I should feel free to use it, since it was obviously intended by the author that it be available for my use. If the author didn't intend that, then the author has made an error an should correct it. On a side not, it really doesn't matther _what_ the documentation says, unless an interface has stabilized to the point where it will not change over a relatively large period of time (long enough to publish a book about it, and have the book continue to be correct for the period of a year, if not longer). FreeBSD does not have this level of DDI/DKI, though one hopes that it eventually will, and there is no policy that interfaces are not permitted to change unless accompanied by accurate documentation changes, as well. Either the macros are incorrectly scoped, or the documentation is incorrect, but _something_ is wrong here, and needs to be corrected. I personally think that what Justin is trying to do _should_ be possible, and I don't really understand why there is a pseudo-requirement that the api be made up of function calls, and not macros; certainly, this is not a global requirement, or someone would "fix" the select() interface, and other code where macros are used. Also, pretending that macros are functions by changing naming conventions in violation of the existing style requirements makes no sense to me; perhaps it was intended that they be inlines instead of macros? Since inlines live in the function convention namespace, this makes a heck of a lot more sense than hiding macros there... 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 Thu Jan 11 7:55:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 3736037B402 for ; Thu, 11 Jan 2001 07:55:12 -0800 (PST) Received: from luanda-56.budapest.interware.hu ([195.70.51.56] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 14Gk4A-0005uq-00; Thu, 11 Jan 2001 16:55:07 +0100 Message-ID: <3A5DCD67.66539A@elischer.org> Date: Thu, 11 Jan 2001 07:12:39 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Poul-Henning Kamp Cc: "Justin T. Gibbs" , Dag-Erling Smorgrav , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed chage to sbuf semantics. References: <8607.979224359@critter> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > As original perpetrator of the sbufs, I'd like to chime in briefly. > > I agree with Justin about being able to succesfully retreive an > overflowed sbuf. > > I would even suggest that finish replaces the final characters in > an overflowed sbuf with "[...]" as a generic marker that overflow > happened. I would like to set an sbuf with a 'potential' buffersize. So long as I have not reached the 'potential' maximum, an operation will not overlflow, though it may not have origianlly allocated so much memeory, or at least it may not always have that much... e.g. I would like to guarantee that a bunch of operations succeed, and then when I close the string maybe, it uses an appropriatly sized buffer. An operation to truncate back to some know size, after I have successfully completed the operations and an sbuf_getpos() would also be in my wishlist, as well as the ability to work WITHIN a longer already filled out string.. (e.g. insert, delete, replace :-) > > I also agree with Dag-Erling that the API should be entirely function > based. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | 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 -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 11 9:33:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 1AEFA37B400 for ; Thu, 11 Jan 2001 09:33:00 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id f0BHWC671100; Thu, 11 Jan 2001 09:32:12 -0800 (PST) (envelope-from dillon) Date: Thu, 11 Jan 2001 09:32:12 -0800 (PST) From: Matt Dillon Message-Id: <200101111732.f0BHWC671100@earth.backplane.com> To: Julian Elischer Cc: Poul-Henning Kamp , "Justin T. Gibbs" , Dag-Erling Smorgrav , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed chage to sbuf semantics. References: <8607.979224359@critter> <3A5DCD67.66539A@elischer.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You guys are all crazy. I would just write an snappendf() function, similar to snprintf(), and use a static buffer. snappendf(buf, bufsize, ctl, ...); Have the function return the index of where the \0 would normally go had the buffer been big enough. So the last snappendf(): r = snappendf(...) if (r >= bufsize) ... data was truncated ... The routine is about 5 lines of code. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 13 13: 9:11 2001 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 63CF937B69B for ; Sat, 13 Jan 2001 13:08:54 -0800 (PST) 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 <0G7400IFDD801E@mta5.rcsntx.swbell.net> for arch@FreeBSD.org; Sat, 13 Jan 2001 15:04:48 -0600 (CST) Received: (from chris@localhost) by holly.calldei.com (8.11.1/8.9.3) id f0DL6nH05383; Sat, 13 Jan 2001 15:06:49 -0600 (CST envelope-from chris) Date: Sat, 13 Jan 2001 15:06:48 -0600 From: Chris Costello Subject: Re: retiring kernfs In-reply-to: <20010108151658.E15744@fw.wintelcom.net> To: Alfred Perlstein Cc: arch@FreeBSD.org Reply-To: chris@calldei.com Message-id: <20010113150648.A4539@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <3738.978995166@winston.osd.bsdi.com> <20010108151658.E15744@fw.wintelcom.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Cc: list trimmed; all these people are on -arch, I'm sure] On Monday, January 08, 2001, Alfred Perlstein wrote: > If someone where to setup a slashdot forum where committers could > post important changes (or cool stuff they'd like recognition about) > I'd be happy to assist (or do all of the) monitoring/moderating > the posts. For that matter, a Majordomo (closed-posting) list with archives that can be perused (by awk or Perl or something) to produce a RELNOTES file. For that matter, if a special data format is required, a shell script could be used, something similar to GNATS. (But I don't see much need for such a script.) -- +-------------------+--------------------+ | Chris Costello | User: | | chris@calldei.com | A harmless drudge. | +-------------------+--------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message