From owner-freebsd-arch@FreeBSD.ORG Sun Mar 27 09:55:01 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BCFD16A4CE for ; Sun, 27 Mar 2005 09:55:01 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E17643D31 for ; Sun, 27 Mar 2005 09:55:00 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id 68B2550C9F for ; Sun, 27 Mar 2005 18:54:59 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id 0216350C9E for ; Sun, 27 Mar 2005 18:54:58 +0900 (JST) Date: Sun, 27 Mar 2005 18:54:57 +0900 Message-ID: <7m7jjtfm6m.wl%kuriyama@imgsrc.co.jp> From: Jun Kuriyama To: freebsd-arch@freebsd.org In-Reply-To: <42335A52.9060208@freebsd.org> References: <42335A52.9060208@freebsd.org> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 Subject: Re: Removing gtar from base X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2005 09:55:01 -0000 At Sat, 12 Mar 2005 13:08:34 -0800, Tim Kientzle wrote: > My plan with bsdtar has been to have both bsdtar and > gtar in 5.x, bsdtar only in 6.x. Do you have a plan to implement gtar's --listed-incremental option? Amanda (misc/amanda-server) uses this option... -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-arch@FreeBSD.ORG Mon Mar 28 04:21:08 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B690116A4CE for ; Mon, 28 Mar 2005 04:21:08 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 1BD6243D3F for ; Mon, 28 Mar 2005 04:21:08 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 9492 invoked by uid 89); 28 Mar 2005 04:21:06 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 28 Mar 2005 04:21:06 -0000 Received: (qmail 9480 invoked by uid 89); 28 Mar 2005 04:21:06 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 28 Mar 2005 04:21:06 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id j2S4L5w6065273; Sun, 27 Mar 2005 23:21:06 -0500 (EST) (envelope-from ups@tree.com) From: Stephan Uphoff To: Jeff Roberson In-Reply-To: <1110896909.29804.39143.camel@palm> References: <20050314213038.V20708@mail.chesapeake.net> <1110856553.29804.37784.camel@palm> <20050315003915.C20708@mail.chesapeake.net> <1110896909.29804.39143.camel@palm> Content-Type: text/plain Message-Id: <1111983665.64310.19.camel@palm> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 27 Mar 2005 23:21:05 -0500 Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: Freeing vnodes. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2005 04:21:08 -0000 On Tue, 2005-03-15 at 09:28, Stephan Uphoff wrote: > On Tue, 2005-03-15 at 00:39, Jeff Roberson wrote: > > On Mon, 14 Mar 2005, Stephan Uphoff wrote: > > > > > On Mon, 2005-03-14 at 21:38, Jeff Roberson wrote: > > > > I have a patch at http://www.chesapeake.net/~jroberson/freevnodes.diff > > > > that allows us to start reclaiming vnodes from the free list and release > > > > their memory. It also changes the semantics of wantfreevnodes, and makes > > > > getnewvnode() much prettier. > > > > > > > > The changes attempt to keep some number of vnodes, currently 2.5% of > > > > desiredvnodes, that are free in memory. Free vnodes are vnodes which > > > > have no references or pages in memory. For example, if an application > > > > simply stat's a vnode, it will end up on the free list at the end of the > > > > operation. The algorithm that is currently in place will immediately > > > > recycle these vnodes once there is enough pressure, which will cause us to > > > > do a full lookup and reread the inode, etc. as soon as it is stat'd again. > > > > > > > > This also removes the recycling from the getnewvnode() path. Instead, it > > > > is done by a new helper function that is called from vnlru_proc(). This > > > > function just frees vnodes from the head of the list until we reach our > > > > wantfreevnodes target. > > > > > > > > I haven't perf tested this yet, but I have a box that is doing a > > > > buildworld with a fairly constant freevnodes count which shows that vnodes > > > > are actually being uma_zfree'd. > > > > > > > > Comments? Anyone willing to do some perf tests for me? > > > > > > > > Thanks, > > > > Jeff > > > > > > Just looked at the raw diff and might have missed it - how are the > > > parent directory "name" cache entries ( vnode fields v_dd, v_ddid) > > > handled? > > > > Just as they were before, by calling cache_purge. > > This purges the fields of the vnode that will be recycled. > > I am worried about the v_dd,v_ddid fields of a directory B that has the > to be released vnode A as parent. (Obviously in this case there is no > namecache entry with the vnode A as the directory (nc_dvp)) > > Right now A is type stable - but if A is released, access to B->v_dd > may cause a page fault. > > Stephan Jeff, Do you plan to address the problem now that the code is checked in? Stephan From owner-freebsd-arch@FreeBSD.ORG Mon Mar 28 22:35:06 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 618A316A4CE for ; Mon, 28 Mar 2005 22:35:06 +0000 (GMT) Received: from mail27.sea5.speakeasy.net (mail27.sea5.speakeasy.net [69.17.117.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECFD443D49 for ; Mon, 28 Mar 2005 22:35:05 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 32621 invoked from network); 28 Mar 2005 22:35:05 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 28 Mar 2005 22:35:04 -0000 Received: from [10.50.41.231] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j2SMYwdW003330 for ; Mon, 28 Mar 2005 17:34:59 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: arch@FreeBSD.org Date: Mon, 28 Mar 2005 17:34:45 -0500 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200503281734.45926.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx Subject: Fixing DRM after phk's drive-by axeing X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2005 22:35:06 -0000 I have a commit-ready version of the vm_mmap() changes I made to get drm to work happily with the newer, cleaner cdev stuff that phk has been working on. Basically, I've changed vm_mmap() so that it can accept either a vnode or a cdev as its handle argument rather than just vnodes. For the cdev case, it calls a vm_mmap_cdev() function that is a cut down version of vm_mmap_vnode(). One thing to note is that this case loses the MAC check for this type of mmap() (currently only done from DRM) since MAC only checks mmaps for vnodes. If cdev were to grow a label, then a mmap check for the cdev could be added I suppose, though the case of a mmap'ing a vnode that maps to a cdev would have to be adjusted to make that extra call as well. The first cut at the patch added a new MAP_CDEV flag to vm_mmap() that specified that the handle argument was a cdev rather than a vnode. However, this method requires that any kernel code that calls vm_mmap() passing in flags from userland has to verify that MAP_CDEV isn't passed in from userland to avoid potential DOSs from random user processes that result in kernel panics. Thus, I decided to change vm_mmap() to instead take a objtype_t parameter that specifies what type of object the handle argument is. Thus, for MAP_ANON, the code passes in OBJT_DEFAULT, for vnodes OBJT_VNODE, and for cdevs (in drm) OBJT_DEVICE. I've stuck the patch at http://www.FreeBSD.org/~jhb/patches/mmap_cdev3.patch and am using it locally to get X working on my laptop. Any objections or bikeshed^Wsuggestions for a different interface? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Mon Mar 28 22:39:00 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA50E16A4CE; Mon, 28 Mar 2005 22:39:00 +0000 (GMT) Received: from lakermmtao08.cox.net (lakermmtao08.cox.net [68.230.240.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1B3443D3F; Mon, 28 Mar 2005 22:38:59 +0000 (GMT) (envelope-from mezz7@cox.net) Received: from mezz.mezzweb.com ([68.103.32.140]) by lakermmtao08.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050328223857.IKQB18351.lakermmtao08.cox.net@mezz.mezzweb.com>; Mon, 28 Mar 2005 17:38:57 -0500 Date: Mon, 28 Mar 2005 16:39:55 -0600 To: "John Baldwin" References: <200503281734.45926.jhb@FreeBSD.org> From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <200503281734.45926.jhb@FreeBSD.org> User-Agent: Opera M2/7.54 (Linux, build 955) cc: arch@freebsd.org Subject: Re: Fixing DRM after phk's drive-by axeing X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2005 22:39:01 -0000 On Mon, 28 Mar 2005 17:34:45 -0500, John Baldwin wrote: > I have a commit-ready version of the vm_mmap() changes I made to get drm > to > work happily with the newer, cleaner cdev stuff that phk has been > working on. > Basically, I've changed vm_mmap() so that it can accept either a vnode > or a > cdev as its handle argument rather than just vnodes. For the cdev case, > it > calls a vm_mmap_cdev() function that is a cut down version of > vm_mmap_vnode(). One thing to note is that this case loses the MAC > check for > this type of mmap() (currently only done from DRM) since MAC only checks > mmaps for vnodes. If cdev were to grow a label, then a mmap check for > the > cdev could be added I suppose, though the case of a mmap'ing a vnode that > maps to a cdev would have to be adjusted to make that extra call as well. > > The first cut at the patch added a new MAP_CDEV flag to vm_mmap() that > specified that the handle argument was a cdev rather than a vnode. > However, > this method requires that any kernel code that calls vm_mmap() passing in > flags from userland has to verify that MAP_CDEV isn't passed in from > userland > to avoid potential DOSs from random user processes that result in kernel > panics. Thus, I decided to change vm_mmap() to instead take a objtype_t > parameter that specifies what type of object the handle argument is. > Thus, > for MAP_ANON, the code passes in OBJT_DEFAULT, for vnodes OBJT_VNODE, > and for > cdevs (in drm) OBJT_DEVICE. I've stuck the patch at > http://www.FreeBSD.org/~jhb/patches/mmap_cdev3.patch and am using it > locally You had it typo for ',' instead '.'.. mmap_cdev3,patch http://people.freebsd.org/~jhb/patches/mmap_cdev3,patch Cheers, Mezz > to get X working on my laptop. Any objections or bikeshed^Wsuggestions > for a > different interface? -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Mon Mar 28 22:44:13 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8287C16A4CE for ; Mon, 28 Mar 2005 22:44:13 +0000 (GMT) Received: from mail26.sea5.speakeasy.net (mail26.sea5.speakeasy.net [69.17.117.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F2BD43D2F for ; Mon, 28 Mar 2005 22:44:13 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 6141 invoked from network); 28 Mar 2005 22:44:12 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 28 Mar 2005 22:44:10 -0000 Received: from [10.50.41.231] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j2SMi0Iu003376; Mon, 28 Mar 2005 17:44:05 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: "Jeremy Messenger" Date: Mon, 28 Mar 2005 17:41:19 -0500 User-Agent: KMail/1.6.2 References: <200503281734.45926.jhb@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <200503281741.19443.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: arch@FreeBSD.org Subject: Re: Fixing DRM after phk's drive-by axeing X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2005 22:44:13 -0000 On Monday 28 March 2005 05:39 pm, Jeremy Messenger wrote: > On Mon, 28 Mar 2005 17:34:45 -0500, John Baldwin wrote: > > I have a commit-ready version of the vm_mmap() changes I made to get drm > > to > > work happily with the newer, cleaner cdev stuff that phk has been > > working on. > > Basically, I've changed vm_mmap() so that it can accept either a vnode > > or a > > cdev as its handle argument rather than just vnodes. For the cdev case, > > it > > calls a vm_mmap_cdev() function that is a cut down version of > > vm_mmap_vnode(). One thing to note is that this case loses the MAC > > check for > > this type of mmap() (currently only done from DRM) since MAC only checks > > mmaps for vnodes. If cdev were to grow a label, then a mmap check for > > the > > cdev could be added I suppose, though the case of a mmap'ing a vnode that > > maps to a cdev would have to be adjusted to make that extra call as well. > > > > The first cut at the patch added a new MAP_CDEV flag to vm_mmap() that > > specified that the handle argument was a cdev rather than a vnode. > > However, > > this method requires that any kernel code that calls vm_mmap() passing in > > flags from userland has to verify that MAP_CDEV isn't passed in from > > userland > > to avoid potential DOSs from random user processes that result in kernel > > panics. Thus, I decided to change vm_mmap() to instead take a objtype_t > > parameter that specifies what type of object the handle argument is. > > Thus, > > for MAP_ANON, the code passes in OBJT_DEFAULT, for vnodes OBJT_VNODE, > > and for > > cdevs (in drm) OBJT_DEVICE. I've stuck the patch at > > http://www.FreeBSD.org/~jhb/patches/mmap_cdev3.patch and am using it > > locally > > You had it typo for ',' instead '.'.. mmap_cdev3,patch > > http://people.freebsd.org/~jhb/patches/mmap_cdev3,patch > > Cheers, > Mezz Heh, fixed. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Tue Mar 29 04:11:54 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EB5116A4CE for ; Tue, 29 Mar 2005 04:11:54 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFE2C43D1D for ; Tue, 29 Mar 2005 04:11:53 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id j2T4Bn9P007319; Mon, 28 Mar 2005 23:11:49 -0500 (EST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)j2T4Bngg007316; Mon, 28 Mar 2005 23:11:49 -0500 (EST) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Mon, 28 Mar 2005 23:11:48 -0500 (EST) From: Jeff Roberson To: Stephan Uphoff In-Reply-To: <1111983665.64310.19.camel@palm> Message-ID: <20050328231118.R54623@mail.chesapeake.net> References: <20050314213038.V20708@mail.chesapeake.net> <1110856553.29804.37784.camel@palm> <1110896909.29804.39143.camel@palm> <1111983665.64310.19.camel@palm> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: Freeing vnodes. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2005 04:11:54 -0000 On Sun, 27 Mar 2005, Stephan Uphoff wrote: > On Tue, 2005-03-15 at 09:28, Stephan Uphoff wrote: > > On Tue, 2005-03-15 at 00:39, Jeff Roberson wrote: > > > On Mon, 14 Mar 2005, Stephan Uphoff wrote: > > > > > > > On Mon, 2005-03-14 at 21:38, Jeff Roberson wrote: > > > > > I have a patch at http://www.chesapeake.net/~jroberson/freevnodes.diff > > > > > that allows us to start reclaiming vnodes from the free list and release > > > > > their memory. It also changes the semantics of wantfreevnodes, and makes > > > > > getnewvnode() much prettier. > > > > > > > > > > The changes attempt to keep some number of vnodes, currently 2.5% of > > > > > desiredvnodes, that are free in memory. Free vnodes are vnodes which > > > > > have no references or pages in memory. For example, if an application > > > > > simply stat's a vnode, it will end up on the free list at the end of the > > > > > operation. The algorithm that is currently in place will immediately > > > > > recycle these vnodes once there is enough pressure, which will cause us to > > > > > do a full lookup and reread the inode, etc. as soon as it is stat'd again. > > > > > > > > > > This also removes the recycling from the getnewvnode() path. Instead, it > > > > > is done by a new helper function that is called from vnlru_proc(). This > > > > > function just frees vnodes from the head of the list until we reach our > > > > > wantfreevnodes target. > > > > > > > > > > I haven't perf tested this yet, but I have a box that is doing a > > > > > buildworld with a fairly constant freevnodes count which shows that vnodes > > > > > are actually being uma_zfree'd. > > > > > > > > > > Comments? Anyone willing to do some perf tests for me? > > > > > > > > > > Thanks, > > > > > Jeff > > > > > > > > Just looked at the raw diff and might have missed it - how are the > > > > parent directory "name" cache entries ( vnode fields v_dd, v_ddid) > > > > handled? > > > > > > Just as they were before, by calling cache_purge. > > > > This purges the fields of the vnode that will be recycled. > > > > I am worried about the v_dd,v_ddid fields of a directory B that has the > > to be released vnode A as parent. (Obviously in this case there is no > > namecache entry with the vnode A as the directory (nc_dvp)) > > > > Right now A is type stable - but if A is released, access to B->v_dd > > may cause a page fault. > > > > Stephan > > Jeff, > > Do you plan to address the problem now that the code is checked in? Vnodes with children in the name cache are held with vhold() and not recycled. > > Stephan > From owner-freebsd-arch@FreeBSD.ORG Tue Mar 29 04:49:13 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FE9B16A4CE for ; Tue, 29 Mar 2005 04:49:13 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37D0F43D39 for ; Tue, 29 Mar 2005 04:49:13 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j2T4n6Lv009768; Mon, 28 Mar 2005 23:49:06 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j2T4n6g8009767; Mon, 28 Mar 2005 23:49:06 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Mon, 28 Mar 2005 23:49:05 -0500 From: David Schultz To: Jeff Roberson Message-ID: <20050329044905.GA9730@VARK.MIT.EDU> Mail-Followup-To: Jeff Roberson , Stephan Uphoff , arch@FreeBSD.ORG References: <20050314213038.V20708@mail.chesapeake.net> <1110856553.29804.37784.camel@palm> <1110896909.29804.39143.camel@palm> <1111983665.64310.19.camel@palm> <20050328231118.R54623@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050328231118.R54623@mail.chesapeake.net> cc: arch@FreeBSD.ORG cc: Stephan Uphoff Subject: Re: Freeing vnodes. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2005 04:49:13 -0000 On Mon, Mar 28, 2005, Jeff Roberson wrote: > > > I am worried about the v_dd,v_ddid fields of a directory B that has the > > > to be released vnode A as parent. (Obviously in this case there is no > > > namecache entry with the vnode A as the directory (nc_dvp)) > > > > > > Right now A is type stable - but if A is released, access to B->v_dd > > > may cause a page fault. > > > > > > Stephan > > > > Jeff, > > > > Do you plan to address the problem now that the code is checked in? > > Vnodes with children in the name cache are held with vhold() and not > recycled. Yes, but cache_purge() is called directly in a number of places where the vnode may have children, e.g. in mount. So dangling references might still be possible unless cache_purge() fixes up the children's v_dd pointers appropriately. From owner-freebsd-arch@FreeBSD.ORG Tue Mar 29 05:52:37 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD3E516A4CE; Tue, 29 Mar 2005 05:52:37 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08F3043D1D; Tue, 29 Mar 2005 05:52:37 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id j2T5qa9P030448; Tue, 29 Mar 2005 00:52:36 -0500 (EST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)j2T5qZsk030443; Tue, 29 Mar 2005 00:52:36 -0500 (EST) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Tue, 29 Mar 2005 00:52:35 -0500 (EST) From: Jeff Roberson To: David Schultz In-Reply-To: <20050329044905.GA9730@VARK.MIT.EDU> Message-ID: <20050329005142.U54623@mail.chesapeake.net> References: <20050314213038.V20708@mail.chesapeake.net> <1110856553.29804.37784.camel@palm> <1110896909.29804.39143.camel@palm> <1111983665.64310.19.camel@palm> <20050329044905.GA9730@VARK.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@FreeBSD.ORG cc: Stephan Uphoff Subject: Re: Freeing vnodes. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2005 05:52:38 -0000 On Mon, 28 Mar 2005, David Schultz wrote: > On Mon, Mar 28, 2005, Jeff Roberson wrote: > > > > I am worried about the v_dd,v_ddid fields of a directory B that has the > > > > to be released vnode A as parent. (Obviously in this case there is no > > > > namecache entry with the vnode A as the directory (nc_dvp)) > > > > > > > > Right now A is type stable - but if A is released, access to B->v_dd > > > > may cause a page fault. > > > > > > > > Stephan > > > > > > Jeff, > > > > > > Do you plan to address the problem now that the code is checked in? > > > > Vnodes with children in the name cache are held with vhold() and not > > recycled. > > Yes, but cache_purge() is called directly in a number of places > where the vnode may have children, e.g. in mount. So dangling > references might still be possible unless cache_purge() fixes up > the children's v_dd pointers appropriately. > ah, indeed. How does this look: Index: vfs_cache.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_cache.c,v retrieving revision 1.93 diff -u -r1.93 vfs_cache.c --- vfs_cache.c 28 Mar 2005 13:29:48 -0000 1.93 +++ vfs_cache.c 29 Mar 2005 05:48:40 -0000 @@ -553,22 +553,30 @@ * XXX: by incrementing each vnodes v_id individually instead of * XXX: using the global v_id. */ - -/* - * XXX This is sometimes called when a vnode may still be re-used, in which - * case v_dd may be invalid. Need to look this up. - */ void cache_purge(vp) struct vnode *vp; { + struct namecache *ncp; static u_long nextid; CACHE_LOCK(); while (!LIST_EMPTY(&vp->v_cache_src)) cache_zap(LIST_FIRST(&vp->v_cache_src)); - while (!TAILQ_EMPTY(&vp->v_cache_dst)) - cache_zap(TAILQ_FIRST(&vp->v_cache_dst)); + while (!TAILQ_EMPTY(&vp->v_cache_dst)) { + struct vnode *cvp; + + ncp = TAILQ_FIRST(&vp->v_cache_dst); + /* + * We must reset v_dd of any children so they don't continue + * to point to us. + */ + if ((cvp = ncp->nc_vp) && cvp->v_dd == vp) { + cvp->v_dd = cvp; + cvp->v_ddid = 0; + } + cache_zap(ncp); + } do nextid++; From owner-freebsd-arch@FreeBSD.ORG Tue Mar 29 05:55:45 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7973316A4CE; Tue, 29 Mar 2005 05:55:45 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CE7F43D2F; Tue, 29 Mar 2005 05:55:45 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id j2T5ti9P031074; Tue, 29 Mar 2005 00:55:44 -0500 (EST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)j2T5tiXE031071; Tue, 29 Mar 2005 00:55:44 -0500 (EST) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Tue, 29 Mar 2005 00:55:44 -0500 (EST) From: Jeff Roberson To: David Schultz In-Reply-To: <20050329005142.U54623@mail.chesapeake.net> Message-ID: <20050329005351.B54623@mail.chesapeake.net> References: <20050314213038.V20708@mail.chesapeake.net> <1110856553.29804.37784.camel@palm> <1110896909.29804.39143.camel@palm> <1111983665.64310.19.camel@palm> <20050329005142.U54623@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: Stephan Uphoff Subject: Re: Freeing vnodes. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2005 05:55:45 -0000 On Tue, 29 Mar 2005, Jeff Roberson wrote: > On Mon, 28 Mar 2005, David Schultz wrote: > > > On Mon, Mar 28, 2005, Jeff Roberson wrote: > > > > > I am worried about the v_dd,v_ddid fields of a directory B that has the > > > > > to be released vnode A as parent. (Obviously in this case there is no > > > > > namecache entry with the vnode A as the directory (nc_dvp)) > > > > > > > > > > Right now A is type stable - but if A is released, access to B->v_dd > > > > > may cause a page fault. > > > > > > > > > > Stephan > > > > > > > > Jeff, > > > > > > > > Do you plan to address the problem now that the code is checked in? > > > > > > Vnodes with children in the name cache are held with vhold() and not > > > recycled. > > > > Yes, but cache_purge() is called directly in a number of places > > where the vnode may have children, e.g. in mount. So dangling > > references might still be possible unless cache_purge() fixes up > > the children's v_dd pointers appropriately. > > > > ah, indeed. How does this look: Also, are the ids really necessary now that we don't reuse vnodes? Shouldn't the pointer be sufficient? > > Index: vfs_cache.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/vfs_cache.c,v > retrieving revision 1.93 > diff -u -r1.93 vfs_cache.c > --- vfs_cache.c 28 Mar 2005 13:29:48 -0000 1.93 > +++ vfs_cache.c 29 Mar 2005 05:48:40 -0000 > @@ -553,22 +553,30 @@ > * XXX: by incrementing each vnodes v_id individually instead of > * XXX: using the global v_id. > */ > - > -/* > - * XXX This is sometimes called when a vnode may still be re-used, in > which > - * case v_dd may be invalid. Need to look this up. > - */ > void > cache_purge(vp) > struct vnode *vp; > { > + struct namecache *ncp; > static u_long nextid; > > CACHE_LOCK(); > while (!LIST_EMPTY(&vp->v_cache_src)) > cache_zap(LIST_FIRST(&vp->v_cache_src)); > - while (!TAILQ_EMPTY(&vp->v_cache_dst)) > - cache_zap(TAILQ_FIRST(&vp->v_cache_dst)); > + while (!TAILQ_EMPTY(&vp->v_cache_dst)) { > + struct vnode *cvp; > + > + ncp = TAILQ_FIRST(&vp->v_cache_dst); > + /* > + * We must reset v_dd of any children so they don't continue > + * to point to us. > + */ > + if ((cvp = ncp->nc_vp) && cvp->v_dd == vp) { > + cvp->v_dd = cvp; > + cvp->v_ddid = 0; > + } > + cache_zap(ncp); > + } > > do > nextid++; > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Tue Mar 29 07:10:15 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76F6B16A4CE for ; Tue, 29 Mar 2005 07:10:15 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1904743D1D for ; Tue, 29 Mar 2005 07:10:15 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j2T7A78t010507; Tue, 29 Mar 2005 02:10:07 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j2T7A632010506; Tue, 29 Mar 2005 02:10:06 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Tue, 29 Mar 2005 02:10:06 -0500 From: David Schultz To: Jeff Roberson Message-ID: <20050329071006.GA10416@VARK.MIT.EDU> Mail-Followup-To: Jeff Roberson , arch@FreeBSD.ORG, Stephan Uphoff References: <20050314213038.V20708@mail.chesapeake.net> <1110856553.29804.37784.camel@palm> <1110896909.29804.39143.camel@palm> <1111983665.64310.19.camel@palm> <20050329044905.GA9730@VARK.MIT.EDU> <20050329005142.U54623@mail.chesapeake.net> <20050329005351.B54623@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050329005351.B54623@mail.chesapeake.net> cc: arch@FreeBSD.ORG cc: Stephan Uphoff Subject: Re: Freeing vnodes. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2005 07:10:15 -0000 On Tue, Mar 29, 2005, Jeff Roberson wrote: > On Tue, 29 Mar 2005, Jeff Roberson wrote: > > > On Mon, 28 Mar 2005, David Schultz wrote: > > > > > On Mon, Mar 28, 2005, Jeff Roberson wrote: > > > > > > I am worried about the v_dd,v_ddid fields of a directory B that has the > > > > > > to be released vnode A as parent. (Obviously in this case there is no > > > > > > namecache entry with the vnode A as the directory (nc_dvp)) > > > > > > > > > > > > Right now A is type stable - but if A is released, access to B->v_dd > > > > > > may cause a page fault. > > > > > > > > > > > > Stephan > > > > > > > > > > Jeff, > > > > > > > > > > Do you plan to address the problem now that the code is checked in? > > > > > > > > Vnodes with children in the name cache are held with vhold() and not > > > > recycled. > > > > > > Yes, but cache_purge() is called directly in a number of places > > > where the vnode may have children, e.g. in mount. So dangling > > > references might still be possible unless cache_purge() fixes up > > > the children's v_dd pointers appropriately. > > > > > > > ah, indeed. How does this look: > > Also, are the ids really necessary now that we don't reuse vnodes? > Shouldn't the pointer be sufficient? I think so. The patch I sent you a few days ago gets rid of v_id except in vfs_cache_lookup(), where it is used to guarantee that the vnode hasn't changed while sleeping in vn_lock(). With vnode reclamation, that isn't safe anyway, so if you fix vfs_cache_lookup(), we can kill v_id completely. Your patch looks okay at a glance, but shouldn't you be iterating over v_cache_src instead of v_cache_dst? From owner-freebsd-arch@FreeBSD.ORG Tue Mar 29 08:06:05 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B77E16A4CE; Tue, 29 Mar 2005 08:06:05 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4172B43D2F; Tue, 29 Mar 2005 08:06:04 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id j2T8639P062681; Tue, 29 Mar 2005 03:06:03 -0500 (EST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)j2T862Ea062677; Tue, 29 Mar 2005 03:06:02 -0500 (EST) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Tue, 29 Mar 2005 03:06:02 -0500 (EST) From: Jeff Roberson To: David Schultz In-Reply-To: <20050329071006.GA10416@VARK.MIT.EDU> Message-ID: <20050329030011.I54623@mail.chesapeake.net> References: <20050314213038.V20708@mail.chesapeake.net> <1110856553.29804.37784.camel@palm> <1110896909.29804.39143.camel@palm> <1111983665.64310.19.camel@palm> <20050329005142.U54623@mail.chesapeake.net> <20050329071006.GA10416@VARK.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@FreeBSD.ORG cc: Stephan Uphoff Subject: Re: Freeing vnodes. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2005 08:06:05 -0000 On Tue, 29 Mar 2005, David Schultz wrote: > On Tue, Mar 29, 2005, Jeff Roberson wrote: > > On Tue, 29 Mar 2005, Jeff Roberson wrote: > > > > > On Mon, 28 Mar 2005, David Schultz wrote: > > > > > > > On Mon, Mar 28, 2005, Jeff Roberson wrote: > > > > > > > I am worried about the v_dd,v_ddid fields of a directory B that has the > > > > > > > to be released vnode A as parent. (Obviously in this case there is no > > > > > > > namecache entry with the vnode A as the directory (nc_dvp)) > > > > > > > > > > > > > > Right now A is type stable - but if A is released, access to B->v_dd > > > > > > > may cause a page fault. > > > > > > > > > > > > > > Stephan > > > > > > > > > > > > Jeff, > > > > > > > > > > > > Do you plan to address the problem now that the code is checked in? > > > > > > > > > > Vnodes with children in the name cache are held with vhold() and not > > > > > recycled. > > > > > > > > Yes, but cache_purge() is called directly in a number of places > > > > where the vnode may have children, e.g. in mount. So dangling > > > > references might still be possible unless cache_purge() fixes up > > > > the children's v_dd pointers appropriately. > > > > > > > > > > ah, indeed. How does this look: > > > > Also, are the ids really necessary now that we don't reuse vnodes? > > Shouldn't the pointer be sufficient? > > I think so. The patch I sent you a few days ago gets rid of v_id > except in vfs_cache_lookup(), where it is used to guarantee that > the vnode hasn't changed while sleeping in vn_lock(). With vnode > reclamation, that isn't safe anyway, so if you fix vfs_cache_lookup(), > we can kill v_id completely. You're right, cache_lookup() needs to be changed to return a referenced vnode. There are only a few callers outside of vfs_cache.c that I'll have to change. I'll put this on my todo list. After that v_id can go away. I'll look at your patch again soon. > > Your patch looks okay at a glance, but shouldn't you be iterating over > v_cache_src instead of v_cache_dst? > Yes, I thought I double checked that. I haven't done any name cache stuff in a while, and I always get confused whether src means sources for this vnode, or names this vnode is a source for. From owner-freebsd-arch@FreeBSD.ORG Tue Mar 29 08:54:29 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4B7616A4CE; Tue, 29 Mar 2005 08:54:29 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id B94E443D48; Tue, 29 Mar 2005 08:54:28 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id j2T8sQQl043398; Tue, 29 Mar 2005 12:54:27 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Tue, 29 Mar 2005 12:54:26 +0400 (MSD) From: Maxim Konovalov To: John Baldwin In-Reply-To: <200503281734.45926.jhb@FreeBSD.org> Message-ID: <20050329123130.I42891@mp2.macomnet.net> References: <200503281734.45926.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: Fixing DRM after phk's drive-by axeing X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2005 08:54:29 -0000 On Mon, 28 Mar 2005, 17:34-0500, John Baldwin wrote: > I have a commit-ready version of the vm_mmap() changes I made to get > drm to work happily with the newer, cleaner cdev stuff that phk has > been working on. Basically, I've changed vm_mmap() so that it can [...] > locally to get X working on my laptop. Any objections or > bikeshed^Wsuggestions for a different interface? Just a report it works with my radeon on Sony PCG-505. Thanks! -- Maxim Konovalov From owner-freebsd-arch@FreeBSD.ORG Tue Mar 29 13:56:37 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0936F16A4CE; Tue, 29 Mar 2005 13:56:37 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id C82A543D39; Tue, 29 Mar 2005 13:56:35 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id j2TDuY9P057980; Tue, 29 Mar 2005 08:56:34 -0500 (EST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)j2TDuXbH057971; Tue, 29 Mar 2005 08:56:33 -0500 (EST) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Tue, 29 Mar 2005 08:56:32 -0500 (EST) From: Jeff Roberson To: David Schultz In-Reply-To: <20050329030011.I54623@mail.chesapeake.net> Message-ID: <20050329085512.M54623@mail.chesapeake.net> References: <20050314213038.V20708@mail.chesapeake.net> <1110856553.29804.37784.camel@palm> <1110896909.29804.39143.camel@palm> <1111983665.64310.19.camel@palm> <20050329071006.GA10416@VARK.MIT.EDU> <20050329030011.I54623@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: Stephan Uphoff Subject: Re: Freeing vnodes. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2005 13:56:37 -0000 On Tue, 29 Mar 2005, Jeff Roberson wrote: > On Tue, 29 Mar 2005, David Schultz wrote: > > > On Tue, Mar 29, 2005, Jeff Roberson wrote: > > > On Tue, 29 Mar 2005, Jeff Roberson wrote: > > > > > > > On Mon, 28 Mar 2005, David Schultz wrote: > > > > > > > > > On Mon, Mar 28, 2005, Jeff Roberson wrote: > > > > > > > > I am worried about the v_dd,v_ddid fields of a directory B that has the > > > > > > > > to be released vnode A as parent. (Obviously in this case there is no > > > > > > > > namecache entry with the vnode A as the directory (nc_dvp)) > > > > > > > > > > > > > > > > Right now A is type stable - but if A is released, access to B->v_dd > > > > > > > > may cause a page fault. > > > > > > > > > > > > > > > > Stephan > > > > > > > > > > > > > > Jeff, > > > > > > > > > > > > > > Do you plan to address the problem now that the code is checked in? > > > > > > > > > > > > Vnodes with children in the name cache are held with vhold() and not > > > > > > recycled. > > > > > > > > > > Yes, but cache_purge() is called directly in a number of places > > > > > where the vnode may have children, e.g. in mount. So dangling > > > > > references might still be possible unless cache_purge() fixes up > > > > > the children's v_dd pointers appropriately. > > > > > > > > > > > > > ah, indeed. How does this look: > > > > > > Also, are the ids really necessary now that we don't reuse vnodes? > > > Shouldn't the pointer be sufficient? > > > > I think so. The patch I sent you a few days ago gets rid of v_id > > except in vfs_cache_lookup(), where it is used to guarantee that > > the vnode hasn't changed while sleeping in vn_lock(). With vnode > > reclamation, that isn't safe anyway, so if you fix vfs_cache_lookup(), > > we can kill v_id completely. > > You're right, cache_lookup() needs to be changed to return a referenced > vnode. There are only a few callers outside of vfs_cache.c that I'll have > to change. I'll put this on my todo list. After that v_id can go away. > I'll look at your patch again soon. I fixed this. You should wrap vn_fullpath() with Giant and then commit your patch. I'll do the VFS_LOCK_GIANT() bit. Do you think we can get rid of v_id and v_ddid after you commit your patch? > > > > > Your patch looks okay at a glance, but shouldn't you be iterating over > > v_cache_src instead of v_cache_dst? > > > > Yes, I thought I double checked that. I haven't done any name cache stuff > in a while, and I always get confused whether src means sources for this > vnode, or names this vnode is a source for. > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Tue Mar 29 14:19:04 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5A1A16A4CE for ; Tue, 29 Mar 2005 14:19:04 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CB7443D2F for ; Tue, 29 Mar 2005 14:19:04 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j2TEIrMb013564; Tue, 29 Mar 2005 09:18:53 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j2TEIr54013563; Tue, 29 Mar 2005 09:18:53 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Tue, 29 Mar 2005 09:18:53 -0500 From: David Schultz To: Jeff Roberson Message-ID: <20050329141853.GA13447@VARK.MIT.EDU> Mail-Followup-To: Jeff Roberson , arch@FreeBSD.ORG, Stephan Uphoff References: <20050314213038.V20708@mail.chesapeake.net> <1110856553.29804.37784.camel@palm> <1110896909.29804.39143.camel@palm> <1111983665.64310.19.camel@palm> <20050329071006.GA10416@VARK.MIT.EDU> <20050329030011.I54623@mail.chesapeake.net> <20050329085512.M54623@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050329085512.M54623@mail.chesapeake.net> cc: arch@FreeBSD.ORG cc: Stephan Uphoff Subject: Re: Freeing vnodes. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2005 14:19:04 -0000 On Tue, Mar 29, 2005, Jeff Roberson wrote: > I fixed this. You should wrap vn_fullpath() with Giant and then commit > your patch. I'll do the VFS_LOCK_GIANT() bit. Do you think we can get > rid of v_id and v_ddid after you commit your patch? Yeah, I'll merge in your changes and commit that later today. I just realized that the patch I sent you isn't the same one that I sent phk last Monday, so it didn't actually include most of the v_id changes. Once I merge your changes into the following, v_id can go away entirely. BTW, I recently noticed that cache_leaf_test() is no longer used and can also go away. I'll get to that later unless you beat me to it. Index: sys/sys/vnode.h =================================================================== RCS file: /cvs/src/sys/sys/vnode.h,v retrieving revision 1.293 diff -u -r1.293 vnode.h --- sys/sys/vnode.h 16 Mar 2005 11:20:51 -0000 1.293 +++ sys/sys/vnode.h 19 Mar 2005 22:00:54 -0000 @@ -145,7 +145,6 @@ TAILQ_HEAD(, namecache) v_cache_dst; /* c Cache entries to us */ u_long v_id; /* c capability identifier */ struct vnode *v_dd; /* c .. vnode */ - u_long v_ddid; /* c .. capability identifier */ /* * clustering stuff Index: sys/kern/vfs_cache.c =================================================================== RCS file: /cvs/src/sys/kern/vfs_cache.c,v retrieving revision 1.90 diff -u -r1.90 vfs_cache.c --- sys/kern/vfs_cache.c 10 Feb 2005 12:16:42 -0000 1.90 +++ sys/kern/vfs_cache.c 19 Mar 2005 22:01:23 -0000 @@ -169,6 +169,8 @@ static void cache_zap(struct namecache *ncp); +static int vn_fullpath1(struct thread *td, struct vnode *vp, struct vnode *rdir, + char *buf, char **retbuf, u_int buflen); static MALLOC_DEFINE(M_VFSCACHE, "vfscache", "VFS name cache entries"); @@ -356,9 +358,8 @@ } if (cnp->cn_namelen == 2 && cnp->cn_nameptr[1] == '.') { dotdothits++; - if (dvp->v_dd->v_id != dvp->v_ddid || + if (dvp->v_dd == NULL || (cnp->cn_flags & MAKEENTRY) == 0) { - dvp->v_ddid = 0; CACHE_UNLOCK(); return (0); } @@ -369,7 +370,7 @@ } hash = fnv_32_buf(cnp->cn_nameptr, cnp->cn_namelen, FNV1_32_INIT); - hash = fnv_32_buf(&dvp->v_id, sizeof(dvp->v_id), hash); + hash = fnv_32_buf(&dvp, sizeof(dvp), hash); LIST_FOREACH(ncp, (NCHHASH(hash)), nc_hash) { numchecks++; if (ncp->nc_dvp == dvp && ncp->nc_nlen == cnp->cn_namelen && @@ -456,13 +457,7 @@ return; } if (cnp->cn_namelen == 2 && cnp->cn_nameptr[1] == '.') { - if (vp) { - dvp->v_dd = vp; - dvp->v_ddid = vp->v_id; - } else { - dvp->v_dd = dvp; - dvp->v_ddid = 0; - } + dvp->v_dd = vp; return; } } @@ -477,7 +472,8 @@ ncp->nc_flag = cnp->cn_flags & ISWHITEOUT ? NCF_WHITE : 0; } else if (vp->v_type == VDIR) { vp->v_dd = dvp; - vp->v_ddid = dvp->v_id; + } else { + vp->v_dd = NULL; } /* @@ -490,7 +486,7 @@ len = ncp->nc_nlen = cnp->cn_namelen; hash = fnv_32_buf(cnp->cn_nameptr, len, FNV1_32_INIT); bcopy(cnp->cn_nameptr, ncp->nc_name, len); - hash = fnv_32_buf(&dvp->v_id, sizeof(dvp->v_id), hash); + hash = fnv_32_buf(&dvp, sizeof(dvp), hash); ncpp = NCHHASH(hash); LIST_INSERT_HEAD(ncpp, ncp, nc_hash); if (LIST_EMPTY(&dvp->v_cache_src)) { @@ -542,16 +538,8 @@ * Invalidate all entries to a particular vnode. * * Remove all entries in the namecache relating to this vnode and - * change the v_id. We take the v_id from a global counter, since - * it becomes a handy sequence number in crash-dumps that way. - * No valid vnode will ever have (v_id == 0). - * - * XXX: Only time and the size of v_id prevents this from failing: - * XXX: In theory we should hunt down all (struct vnode*, v_id) - * XXX: soft references and nuke them, at least on the global - * XXX: v_id wraparound. The period of resistance can be extended - * XXX: by incrementing each vnodes v_id individually instead of - * XXX: using the global v_id. + * change the v_id. The counter is per-vnode, so two vnodes may + * have the same v_id. No valid vnode will ever have (v_id == 0). */ /* @@ -562,7 +550,6 @@ cache_purge(vp) struct vnode *vp; { - static u_long nextid; CACHE_LOCK(); while (!LIST_EMPTY(&vp->v_cache_src)) @@ -570,12 +557,9 @@ while (!TAILQ_EMPTY(&vp->v_cache_dst)) cache_zap(TAILQ_FIRST(&vp->v_cache_dst)); - do - nextid++; - while (nextid == vp->v_id || !nextid); - vp->v_id = nextid; - vp->v_dd = vp; - vp->v_ddid = 0; + MPASS(vp->v_id > 0); + vp->v_id++; + vp->v_dd = NULL; CACHE_UNLOCK(); } @@ -780,14 +764,6 @@ SYSCTL_INT(_debug, OID_AUTO, disablecwd, CTLFLAG_RW, &disablecwd, 0, "Disable the getcwd syscall"); -/* Various statistics for the getcwd syscall */ -static u_long numcwdcalls; STATNODE(CTLFLAG_RD, numcwdcalls, &numcwdcalls); -static u_long numcwdfail1; STATNODE(CTLFLAG_RD, numcwdfail1, &numcwdfail1); -static u_long numcwdfail2; STATNODE(CTLFLAG_RD, numcwdfail2, &numcwdfail2); -static u_long numcwdfail3; STATNODE(CTLFLAG_RD, numcwdfail3, &numcwdfail3); -static u_long numcwdfail4; STATNODE(CTLFLAG_RD, numcwdfail4, &numcwdfail4); -static u_long numcwdfound; STATNODE(CTLFLAG_RD, numcwdfound, &numcwdfound); - /* Implementation of the getcwd syscall */ int __getcwd(td, uap) @@ -802,94 +778,29 @@ kern___getcwd(struct thread *td, u_char *buf, enum uio_seg bufseg, u_int buflen) { char *bp, *tmpbuf; - int error, i, slash_prefixed; struct filedesc *fdp; - struct namecache *ncp; - struct vnode *vp; + int error; - numcwdcalls++; if (disablecwd) return (ENODEV); if (buflen < 2) return (EINVAL); if (buflen > MAXPATHLEN) buflen = MAXPATHLEN; - mtx_lock(&Giant); - error = 0; - tmpbuf = bp = malloc(buflen, M_TEMP, M_WAITOK); - bp += buflen - 1; - *bp = '\0'; + + tmpbuf = malloc(buflen, M_TEMP, M_WAITOK); fdp = td->td_proc->p_fd; - slash_prefixed = 0; FILEDESC_LOCK(fdp); - for (vp = fdp->fd_cdir; vp != fdp->fd_rdir && vp != rootvnode;) { - if (vp->v_vflag & VV_ROOT) { - if (vp->v_mount == NULL) { /* forced unmount */ - error = EBADF; - goto out; - } - vp = vp->v_mount->mnt_vnodecovered; - continue; - } - if (vp->v_dd->v_id != vp->v_ddid) { - numcwdfail1++; - error = ENOTDIR; - goto out; - } - CACHE_LOCK(); - ncp = TAILQ_FIRST(&vp->v_cache_dst); - if (!ncp) { - numcwdfail2++; - CACHE_UNLOCK(); - error = ENOENT; - goto out; - } - if (ncp->nc_dvp != vp->v_dd) { - numcwdfail3++; - CACHE_UNLOCK(); - error = EBADF; - goto out; - } - for (i = ncp->nc_nlen - 1; i >= 0; i--) { - if (bp == tmpbuf) { - numcwdfail4++; - CACHE_UNLOCK(); - error = ENOMEM; - goto out; - } - *--bp = ncp->nc_name[i]; - } - if (bp == tmpbuf) { - numcwdfail4++; - CACHE_UNLOCK(); - error = ENOMEM; - goto out; - } - *--bp = '/'; - slash_prefixed = 1; - vp = vp->v_dd; - CACHE_UNLOCK(); - } - if (!slash_prefixed) { - if (bp == tmpbuf) { - numcwdfail4++; - error = ENOMEM; - goto out; - } - *--bp = '/'; - } + error = vn_fullpath1(td, fdp->fd_cdir, fdp->fd_rdir, tmpbuf, + &bp, buflen); FILEDESC_UNLOCK(fdp); - mtx_unlock(&Giant); - numcwdfound++; - if (bufseg == UIO_SYSSPACE) - bcopy(bp, buf, strlen(bp) + 1); - else - error = copyout(bp, buf, strlen(bp) + 1); - free(tmpbuf, M_TEMP); - return (error); -out: - FILEDESC_UNLOCK(fdp); - mtx_unlock(&Giant); + + if (!error) { + if (bufseg == UIO_SYSSPACE) + bcopy(bp, buf, strlen(bp) + 1); + else + error = copyout(bp, buf, strlen(bp) + 1); + } free(tmpbuf, M_TEMP); return (error); } @@ -907,10 +818,10 @@ SYSCTL_INT(_debug, OID_AUTO, disablefullpath, CTLFLAG_RW, &disablefullpath, 0, "Disable the vn_fullpath function"); +/* These count for kern___getcwd(), too. */ STATNODE(numfullpathcalls); STATNODE(numfullpathfail1); STATNODE(numfullpathfail2); -STATNODE(numfullpathfail3); STATNODE(numfullpathfail4); STATNODE(numfullpathfound); @@ -921,90 +832,112 @@ int vn_fullpath(struct thread *td, struct vnode *vn, char **retbuf, char **freebuf) { - char *bp, *buf; - int i, slash_prefixed; + char *buf; struct filedesc *fdp; - struct namecache *ncp; - struct vnode *vp; + int error; - numfullpathcalls++; if (disablefullpath) return (ENODEV); if (vn == NULL) return (EINVAL); + buf = malloc(MAXPATHLEN, M_TEMP, M_WAITOK); - bp = buf + MAXPATHLEN - 1; - *bp = '\0'; fdp = td->td_proc->p_fd; - slash_prefixed = 0; - ASSERT_VOP_LOCKED(vn, "vn_fullpath"); FILEDESC_LOCK(fdp); - for (vp = vn; vp != fdp->fd_rdir && vp != rootvnode;) { + error = vn_fullpath1(td, vn, fdp->fd_rdir, buf, retbuf, MAXPATHLEN); + FILEDESC_UNLOCK(fdp); + + if (!error) + *freebuf = buf; + else + free(buf, M_TEMP); + return (error); +} + +/* + * The magic behind kern___getcwd() and vn_fullpath(). + */ +static int +vn_fullpath1(struct thread *td, struct vnode *vp, struct vnode *rdir, + char *buf, char **retbuf, u_int buflen) +{ + char *bp; + int error, i, slash_prefixed; + struct namecache *ncp; + + bp = buf + buflen - 1; + *bp = '\0'; + error = 0; + slash_prefixed = 0; + + CACHE_LOCK(); + numfullpathcalls++; + if (vp->v_type != VDIR) { + ncp = TAILQ_FIRST(&vp->v_cache_dst); + if (!ncp) { + numfullpathfail2++; + CACHE_UNLOCK(); + return (ENOENT); + } + for (i = ncp->nc_nlen - 1; i >= 0 && bp > buf; i--) + *--bp = ncp->nc_name[i]; + if (bp == buf) { + numfullpathfail4++; + CACHE_UNLOCK(); + return (ENOMEM); + } + *--bp = '/'; + slash_prefixed = 1; + vp = ncp->nc_dvp; + } + while (vp != rdir && vp != rootvnode) { if (vp->v_vflag & VV_ROOT) { if (vp->v_mount == NULL) { /* forced unmount */ - FILEDESC_UNLOCK(fdp); - free(buf, M_TEMP); - return (EBADF); + error = EBADF; + break; } vp = vp->v_mount->mnt_vnodecovered; continue; } - if (vp != vn && vp->v_dd->v_id != vp->v_ddid) { - FILEDESC_UNLOCK(fdp); - free(buf, M_TEMP); + if (vp->v_dd == NULL) { numfullpathfail1++; - return (ENOTDIR); + error = ENOTDIR; + break; } - CACHE_LOCK(); ncp = TAILQ_FIRST(&vp->v_cache_dst); if (!ncp) { numfullpathfail2++; - CACHE_UNLOCK(); - FILEDESC_UNLOCK(fdp); - free(buf, M_TEMP); - return (ENOENT); + error = ENOENT; + break; } - if (vp != vn && ncp->nc_dvp != vp->v_dd) { - numfullpathfail3++; - CACHE_UNLOCK(); - FILEDESC_UNLOCK(fdp); - free(buf, M_TEMP); - return (EBADF); - } - for (i = ncp->nc_nlen - 1; i >= 0; i--) { - if (bp == buf) { - numfullpathfail4++; - CACHE_UNLOCK(); - FILEDESC_UNLOCK(fdp); - free(buf, M_TEMP); - return (ENOMEM); - } + MPASS(ncp->nc_dvp == vp->v_dd); + for (i = ncp->nc_nlen - 1; i >= 0 && bp != buf; i--) *--bp = ncp->nc_name[i]; - } if (bp == buf) { numfullpathfail4++; - CACHE_UNLOCK(); - FILEDESC_UNLOCK(fdp); - free(buf, M_TEMP); - return (ENOMEM); + error = ENOMEM; + break; } *--bp = '/'; slash_prefixed = 1; vp = ncp->nc_dvp; + } + if (error) { CACHE_UNLOCK(); + return (error); } if (!slash_prefixed) { if (bp == buf) { numfullpathfail4++; - FILEDESC_UNLOCK(fdp); - free(buf, M_TEMP); + CACHE_UNLOCK(); return (ENOMEM); + } else { + *--bp = '/'; } - *--bp = '/'; } - FILEDESC_UNLOCK(fdp); numfullpathfound++; + CACHE_UNLOCK(); + *retbuf = bp; - *freebuf = buf; return (0); } Index: sys/kern/vfs_subr.c =================================================================== RCS file: /cvs/src/sys/kern/vfs_subr.c,v retrieving revision 1.596 diff -u -r1.596 vfs_subr.c --- sys/kern/vfs_subr.c 15 Mar 2005 14:38:16 -0000 1.596 +++ sys/kern/vfs_subr.c 19 Mar 2005 21:59:35 -0000 @@ -837,13 +837,12 @@ vp = (struct vnode *) uma_zalloc(vnode_zone, M_WAITOK|M_ZERO); mtx_init(&vp->v_interlock, "vnode interlock", NULL, MTX_DEF); - vp->v_dd = vp; bo = &vp->v_bufobj; bo->__bo_vnode = vp; bo->bo_mtx = &vp->v_interlock; vp->v_vnlock = &vp->v_lock; lockinit(vp->v_vnlock, PVFS, tag, VLKTIMEOUT, LK_NOPAUSE); - cache_purge(vp); /* Sets up v_id. */ + vp->v_id = 1; LIST_INIT(&vp->v_cache_src); TAILQ_INIT(&vp->v_cache_dst); } From owner-freebsd-arch@FreeBSD.ORG Wed Mar 30 23:48:07 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2313016A4CE for ; Wed, 30 Mar 2005 23:48:07 +0000 (GMT) Received: from pd4mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 606BB43D45 for ; Wed, 30 Mar 2005 23:48:06 +0000 (GMT) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from pd5mr1so.prod.shaw.ca (pd5mr1so-qfe3.prod.shaw.ca [10.0.141.232]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IE6009SMVG6T3D0@l-daemon> for freebsd-arch@freebsd.org; Wed, 30 Mar 2005 16:48:06 -0700 (MST) Received: from pn2ml2so.prod.shaw.ca ([10.0.121.146]) by pd5mr1so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IE6007GKVG6DJN0@pd5mr1so.prod.shaw.ca> for freebsd-arch@freebsd.org; Wed, 30 Mar 2005 16:48:06 -0700 (MST) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IE600D3EVG50H@l-daemon> for freebsd-arch@freebsd.org; Wed, 30 Mar 2005 16:48:06 -0700 (MST) Date: Wed, 30 Mar 2005 15:47:55 -0800 From: Colin Percival To: freebsd-arch@freebsd.org Message-id: <424B3AAB.6090200@wadham.ox.ac.uk> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050326) Subject: Adding bsdiff to the base system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2005 23:48:07 -0000 I'd like to add bsdiff/bspatch into the base system. I initially wrote these as part of FreeBSD Update, but I'm now also using them in portsnap, and bspatch has been part of the OS X base system for most of the past year as a result of being used by their patches. My reason for wanting to add this is that portsnap is next on my hit list, and I obviously need to get this done first. Any objections? Colin Percival From owner-freebsd-arch@FreeBSD.ORG Thu Mar 31 10:16:22 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD55416A4CE for ; Thu, 31 Mar 2005 10:16:22 +0000 (GMT) Received: from shrike.submonkey.net (cpc4-cdif3-6-1-cust116.cdif.cable.ntl.com [82.23.41.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5ECD743D3F for ; Thu, 31 Mar 2005 10:16:22 +0000 (GMT) (envelope-from setantae@submonkey.net) Received: from setantae by shrike.submonkey.net with local (Exim 4.50 (FreeBSD)) id 1DGwir-000975-7H; Thu, 31 Mar 2005 11:16:21 +0100 Date: Thu, 31 Mar 2005 11:16:21 +0100 From: Ceri Davies To: Colin Percival Message-ID: <20050331101621.GL10485@submonkey.net> Mail-Followup-To: Ceri Davies , Colin Percival , freebsd-arch@freebsd.org References: <424B3AAB.6090200@wadham.ox.ac.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IU5/I01NYhRvwH70" Content-Disposition: inline In-Reply-To: <424B3AAB.6090200@wadham.ox.ac.uk> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.9i Sender: Ceri Davies cc: freebsd-arch@freebsd.org Subject: Re: Adding bsdiff to the base system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2005 10:16:22 -0000 --IU5/I01NYhRvwH70 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 30, 2005 at 03:47:55PM -0800, Colin Percival wrote: > I'd like to add bsdiff/bspatch into the base system. I > initially wrote these as part of FreeBSD Update, but I'm now > also using them in portsnap, and bspatch has been part of the > OS X base system for most of the past year as a result of > being used by their patches. > My reason for wanting to add this is that portsnap is next > on my hit list, and I obviously need to get this done first. >=20 > Any objections? While it's probably easy to guess from the names, can you explain what they are? Ceri --=20 Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Einstein (attrib.) --IU5/I01NYhRvwH70 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCS831ocfcwTS3JF8RAu8RAJ9JavvlNNgNwfq7bJn3Ptqq88zK4gCgpLez 3N2grNjocEa9loyTzidcuW0= =axqF -----END PGP SIGNATURE----- --IU5/I01NYhRvwH70-- From owner-freebsd-arch@FreeBSD.ORG Thu Mar 31 10:24:57 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B19416A4CE for ; Thu, 31 Mar 2005 10:24:57 +0000 (GMT) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFECD43D60 for ; Thu, 31 Mar 2005 10:24:55 +0000 (GMT) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.50) id 1DGwrE-0005Tj-2e; Thu, 31 Mar 2005 17:25:00 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.13.3/8.13.1) with ESMTP id j2VAOjST099484; Thu, 31 Mar 2005 17:24:45 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.13.3/8.13.1/Submit) id j2VAOcZ0099428; Thu, 31 Mar 2005 17:24:38 +0700 (NOVST) (envelope-from danfe) Date: Thu, 31 Mar 2005 17:24:38 +0700 From: Alexey Dokuchaev To: Ceri Davies , Colin Percival , freebsd-arch@freebsd.org Message-ID: <20050331102437.GA98638@regency.nsu.ru> References: <424B3AAB.6090200@wadham.ox.ac.uk> <20050331101621.GL10485@submonkey.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050331101621.GL10485@submonkey.net> User-Agent: Mutt/1.4.2.1i Subject: Re: Adding bsdiff to the base system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2005 10:24:57 -0000 On Thu, Mar 31, 2005 at 11:16:21AM +0100, Ceri Davies wrote: > On Wed, Mar 30, 2005 at 03:47:55PM -0800, Colin Percival wrote: > > I'd like to add bsdiff/bspatch into the base system. I > > initially wrote these as part of FreeBSD Update, but I'm now > > also using them in portsnap, and bspatch has been part of the > > OS X base system for most of the past year as a result of > > being used by their patches. > > My reason for wanting to add this is that portsnap is next > > on my hit list, and I obviously need to get this done first. > > > > Any objections? > > While it's probably easy to guess from the names, can you explain what > they are? I also want to ask if there're enough reasons to bring portsnap and its dependencies into the base. What's wrong with having it in ports? It does not seem to be used/needed for vast majority of our user base, or am I wrong? Thanks! ./danfe From owner-freebsd-arch@FreeBSD.ORG Thu Mar 31 10:30:27 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AB5416A4CE for ; Thu, 31 Mar 2005 10:30:27 +0000 (GMT) Received: from pd2mo3so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22FFB43D55 for ; Thu, 31 Mar 2005 10:30:26 +0000 (GMT) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from pd4mr7so.prod.shaw.ca (pd4mr7so-qfe3.prod.shaw.ca [10.0.141.84])2004))freebsd-arch@freebsd.org; Thu, 31 Mar 2005 03:30:01 -0700 (MST) Received: from pn2ml10so.prod.shaw.ca ([10.0.121.80]) by pd4mr7so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IE700NOTP6135E0@pd4mr7so.prod.shaw.ca> for freebsd-arch@freebsd.org; Thu, 31 Mar 2005 03:30:01 -0700 (MST) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IE70005UP60CW@l-daemon> for freebsd-arch@freebsd.org; Thu, 31 Mar 2005 03:30:01 -0700 (MST) Date: Thu, 31 Mar 2005 02:29:50 -0800 From: Colin Percival In-reply-to: <20050331101621.GL10485@submonkey.net> To: Ceri Davies Message-id: <424BD11E.1090007@wadham.ox.ac.uk> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <424B3AAB.6090200@wadham.ox.ac.uk> <20050331101621.GL10485@submonkey.net> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050326) cc: freebsd-arch@freebsd.org Subject: Re: Adding bsdiff to the base system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2005 10:30:27 -0000 Ceri Davies wrote: > On Wed, Mar 30, 2005 at 03:47:55PM -0800, Colin Percival wrote: >> I'd like to add bsdiff/bspatch into the base system. > > While it's probably easy to guess from the names, can you explain what > they are? Oops. bsdiff constructs a "binary diff", and is designed to produce particularly small patches when the two files differ by a large number of substitutions relative to the number of insertions and deletions (this is significant since executable files tend to change in this manner, as a result of linking object files together). Compared to other "binary diff" tools, bsdiff often produces patches 3-5 times smaller; however, it has the disadvantage of being slower and rather more memory-intensive than other tools. bspatch is the opposite of bsdiff -- it takes the "old" file, the binary diff file, and produces the "new" file. Colin Percival From owner-freebsd-arch@FreeBSD.ORG Thu Mar 31 10:46:30 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1C7D16A4CE for ; Thu, 31 Mar 2005 10:46:30 +0000 (GMT) Received: from pd4mo3so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 784D943D1D for ; Thu, 31 Mar 2005 10:46:30 +0000 (GMT) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from pd4mr1so.prod.shaw.ca (pd4mr1so-qfe3.prod.shaw.ca [10.0.141.212]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IE700HHZPXI1BB0@l-daemon> for freebsd-arch@freebsd.org; Thu, 31 Mar 2005 03:46:30 -0700 (MST) Received: from pn2ml10so.prod.shaw.ca ([10.0.121.80]) by pd4mr1so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IE700I7PPXI9B70@pd4mr1so.prod.shaw.ca> for freebsd-arch@freebsd.org; Thu, 31 Mar 2005 03:46:30 -0700 (MST) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IE7000DPPXH4U@l-daemon> for freebsd-arch@freebsd.org; Thu, 31 Mar 2005 03:46:29 -0700 (MST) Date: Thu, 31 Mar 2005 02:46:19 -0800 From: Colin Percival In-reply-to: <20050331102437.GA98638@regency.nsu.ru> To: Alexey Dokuchaev Message-id: <424BD4FB.1050304@wadham.ox.ac.uk> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <424B3AAB.6090200@wadham.ox.ac.uk> <20050331102437.GA98638@regency.nsu.ru> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050326) cc: Ceri Davies cc: freebsd-arch@freebsd.org Subject: Re: Adding bsdiff to the base system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2005 10:46:30 -0000 Alexey Dokuchaev wrote: > I also want to ask if there're enough reasons to bring portsnap and > its dependencies into the base. What's wrong with having it in ports? > It does not seem to be used/needed for vast majority of our user base, > or am I wrong? I'll conceed that portsnap is not yet used by the majority of our user base; but I think that is largely because portsnap is still quite new, and thus relatively unknown. At present portsnap is the only mechanism available by which most users can securely maintain an up-to-date copy of the FreeBSD ports tree; it also provides some other advantages over cvsup (reduced bandwidth and ports INDEX/INDEX-5/INDEX-6 files). Since portsnap and its dependencies will not significantly bloat the base system -- portsnap + bsdiff weigh in at a combined 54kB -- I think it is a sufficiently useful tool to justify inclusion. When you consider that cvsup is a classic example of a program which is only excluded from the base system as a result of its dependencies, and portsnap makes cvsup unnecessary for most users, the case is even clearer. Colin Percival From owner-freebsd-arch@FreeBSD.ORG Thu Mar 31 01:24:51 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9203D16A4CE for ; Thu, 31 Mar 2005 01:24:51 +0000 (GMT) Received: from hotmail.com (bay19-f23.bay19.hotmail.com [64.4.53.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FB4D43D1D for ; Thu, 31 Mar 2005 01:24:51 +0000 (GMT) (envelope-from dragonylffly@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 30 Mar 2005 17:24:51 -0800 Message-ID: Received: from 61.187.16.2 by by19fd.bay19.hotmail.msn.com with HTTP; Thu, 31 Mar 2005 01:24:51 GMT X-Originating-IP: [61.187.16.2] X-Originating-Email: [dragonylffly@hotmail.com] X-Sender: dragonylffly@hotmail.com From: "dragonfly dragonfly" To: freebsd-arch@freebsd.org Date: Thu, 31 Mar 2005 09:24:51 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed X-OriginalArrivalTime: 31 Mar 2005 01:24:51.0275 (UTC) FILETIME=[6F8929B0:01C53590] X-Mailman-Approved-At: Thu, 31 Mar 2005 12:39:15 +0000 Subject: FreeBSD module inference count problem X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2005 01:24:51 -0000 Hi all, Recently I am doing some programming on FreeBSD KLD. In my KLD codes,I will start some kernel threads to serve requests,but i can not find how to increase the module reference count,something like 'MOD_INC_USE_COUNT' in Linux.If not do so,if the user downloaded the module before all kernel threads exit, the system must be panic.I searched the file 'module.h' carefully,only find module_reference().But it seemed in total kernel source,the function does not be used.Even use it,when i use kldstat to see its reference count,it keep __1__! When i download the module before the kernel thread wake up, system panic as expect. my KLD codes like below: module_t curmod; void do_job(void *arg) { if (!curmod) printf("Module not found\n"); else module_reference(curmod); tsleep(curproc,PRIBIO,"foo worker",15*hz); printf("Wake up\n"); if (curmod) module_release(curmod); kthread_exit(0); } static int foo_loader(struct module *m, int what, void *arg) { int err = 0; struct proc *newpp; switch (what) { case MOD_LOAD: curmod=m; kthread_create(do_job,NULL,&newpp,0,0,"foo worker"); printf("foo loaded\n"); break; case MOD_UNLOAD: case MOD_SHUTDOWN: printf("foo unloaded.\n"); break; default: err = EOPNOTSUPP; break; } return(err); } Could you help me? Thanks. _________________________________________________________________ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn From owner-freebsd-arch@FreeBSD.ORG Thu Mar 31 13:24:05 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3773116A4CE for ; Thu, 31 Mar 2005 13:24:05 +0000 (GMT) Received: from mail22.sea5.speakeasy.net (mail22.sea5.speakeasy.net [69.17.117.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id D90A143D31 for ; Thu, 31 Mar 2005 13:24:04 +0000 (GMT) (envelope-from john@baldwin.cx) Received: (qmail 27573 invoked from network); 31 Mar 2005 13:24:04 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 31 Mar 2005 13:24:03 -0000 Received: from [192.168.0.15] (osx.baldwin.cx [192.168.0.15]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j2VDNwQl024609; Thu, 31 Mar 2005 08:23:58 -0500 (EST) (envelope-from john@baldwin.cx) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Baldwin Date: Thu, 31 Mar 2005 08:23:57 -0500 To: "dragonfly dragonfly" X-Mailer: Apple Mail (2.619.2) X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD module inference count problem X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2005 13:24:05 -0000 On Mar 30, 2005, at 8:24 PM, dragonfly dragonfly wrote: > Hi all, Recently I am doing some programming on FreeBSD KLD. In my KLD > codes,I will start some kernel threads to serve requests,but i can not > find how to increase the module reference count,something like > 'MOD_INC_USE_COUNT' in Linux.If not do so,if the user downloaded the > module before all kernel threads exit, the system must be panic.I > searched the file 'module.h' carefully,only find > module_reference().But it seemed in total kernel source,the function > does not be used.Even use it,when i use kldstat to see its reference > count,it keep __1__! When i download the module before the kernel > thread wake up, system panic as expect. my KLD codes like below: > module_t curmod; void do_job(void *arg) { if (!curmod) printf("Module > not found\n"); else module_reference(curmod); > tsleep(curproc,PRIBIO,"foo worker",15*hz); printf("Wake up\n"); if > (curmod) module_release(curmod); kthread_exit(0); } static int > foo_loader(struct module *m, int what, void *arg) { int err = 0; > struct proc *newpp; > switch (what) { case MOD_LOAD: curmod=m; > kthread_create(do_job,NULL,&newpp,0,0,"foo worker"); printf("foo > loaded\n"); break; case MOD_UNLOAD: case MOD_SHUTDOWN: printf("foo > unloaded.\n"); break; default: err = EOPNOTSUPP; break; } > return(err); } Could you help me? Thanks. Right now you need to provide your own reference count and fail the operation with EBUSY when MOD_UNLOAD is called if you have open references. You can also have MOD_UNLOAD wake up the kthread and instruct it to die and then block until the kthread has exited before it returns. (You should do that anyway if you really need to unload this module to ensure that the kthread's code isn't unmapped out from under it while it is running.) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Fri Apr 1 05:02:24 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFC9716A4D0 for ; Fri, 1 Apr 2005 05:02:24 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF2F543D2F for ; Fri, 1 Apr 2005 05:02:24 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id E250446B83; Fri, 1 Apr 2005 00:02:23 -0500 (EST) Date: Fri, 1 Apr 2005 04:59:05 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Colin Percival In-Reply-To: <424B3AAB.6090200@wadham.ox.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: Adding bsdiff to the base system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2005 05:02:25 -0000 On Wed, 30 Mar 2005, Colin Percival wrote: > I'd like to add bsdiff/bspatch into the base system. I initially > wrote these as part of FreeBSD Update, but I'm now also using them in > portsnap, and bspatch has been part of the OS X base system for most of > the past year as a result of being used by their patches. I think this would be a useful addition. They're very handy, and are nice "atomic" tools that can be used to build more complex solutions in the traditional UNIX style. Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Fri Apr 1 05:56:31 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A39816A4CE for ; Fri, 1 Apr 2005 05:56:31 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 790E243D1F for ; Fri, 1 Apr 2005 05:56:30 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j315uM8d057124 for ; Thu, 31 Mar 2005 22:56:22 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 31 Mar 2005 22:56:33 -0700 (MST) Message-Id: <20050331.225633.125544617.imp@bsdimp.com> To: arch@freebsd.org From: "M. Warner Losh" X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: small change to config X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2005 05:56:31 -0000 I'd like to make a small change to config, and use that change to improve the pc98 port. Right now, the machine line in config looks like: machine pc98 This causes compile/FOO/machine to be linked to pc98/include. We have similar logic for modules. NetBSD's machine line, on some architecutres, has two arguments, which correspond to $MACHINE and $MACHINE_ARCH respectively. I'd like to pull this concept into FreeBSD. The only machine that this impacts is pc98. pc98 config files would change to: machine pc98 i386 config creates the machine link, as now. In addition, a link is made from i386 to sys/i386/include. This allows the majority of the .h files that are shared amoung ports that have the same CPU to live in one place, and the machine/foo.h files with minor tweaks. I'd like to move to this model on FreeBSD, and use it to reduce the number of #ifdef PC98 in the tree, while allowing a cleaner separation of pc98 from i386. This should reduce the maintanence impact of having pc98 in the tree, as well as being cleaner. This idea can be extended for whole families of CPUs. So in theory we could also add an x86 directory as well, and share that among i386, amd64 and pc98. However, that's beyond the scope of the work that I'm doing at the moment. There's a number of other things in the tree which need to be changed as well, which will follow in suit. This is just the first step. I have buildworld running on pc98, and am working on installworld and kernel targets. Comments? Warner P.S. I just noitced that I didn't bump the version of config... diff -u /home/imp/FreeBSD/src/usr.sbin/config/config.h /u2/imp/p4/src/usr.sbin/config/config.h --- /home/imp/FreeBSD/src/usr.sbin/config/config.h Fri Sep 3 21:29:01 2004 +++ /u2/imp/p4/src/usr.sbin/config/config.h Thu Mar 31 11:21:26 2005 @@ -91,9 +91,11 @@ * being used. It uses the name of the machine in choosing * files and directories. Thus if the name of the machine is ``i386'', * it will build from ``Makefile.i386'' and use ``../i386/inline'' - * in the makerules, etc. + * in the makerules, etc. machinearc is the global notion of the + * MACHINE_ARCH for this MACHINE. */ char *machinename; +char *machinearch; /* * For each machine, a set of CPU's may be specified as supported. diff -u /home/imp/FreeBSD/src/usr.sbin/config/config.y /u2/imp/p4/src/usr.sbin/config/config.y --- /home/imp/FreeBSD/src/usr.sbin/config/config.y Sun Nov 14 23:05:56 2004 +++ /u2/imp/p4/src/usr.sbin/config/config.y Thu Mar 31 11:21:26 2005 @@ -138,6 +138,15 @@ errx(1, "%s:%d: only one machine directive is allowed", yyfile, yyline); machinename = $2; + machinearch = $2; + } | + ARCH Save_id Save_id + = { + if (machinename != NULL) + errx(1, "%s:%d: only one machine directive is allowed", + yyfile, yyline); + machinename = $2; + machinearch = $3; } | CPU Save_id = { diff -u /home/imp/FreeBSD/src/usr.sbin/config/main.c /u2/imp/p4/src/usr.sbin/config/main.c --- /home/imp/FreeBSD/src/usr.sbin/config/main.c Wed Mar 30 14:45:08 2005 +++ /u2/imp/p4/src/usr.sbin/config/main.c Thu Mar 31 12:15:30 2005 @@ -163,6 +163,20 @@ srcdir, machinename); (void) unlink(path("machine")); (void) symlink(xxx, path("machine")); + if (strcmp(machinename, machinearch) != 0) { + /* + * make symbolic links in compilation directory for + * machinearch, if it is different than machinename. + */ + if (*srcdir == '\0') + (void)snprintf(xxx, sizeof(xxx), "../../../%s/include", + machinearch); + else + (void)snprintf(xxx, sizeof(xxx), "%s/%s/include", + srcdir, machinearch); + (void) unlink(path(machinearch)); + (void) symlink(xxx, path(machinearch)); + } options(); /* make options .h files */ makefile(); /* build Makefile */ headers(); /* make a lot of .h files */ From owner-freebsd-arch@FreeBSD.ORG Fri Apr 1 13:43:55 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B94916A4CE for ; Fri, 1 Apr 2005 13:43:55 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 0A83C43D48 for ; Fri, 1 Apr 2005 13:43:54 +0000 (GMT) (envelope-from m@MHoerich.de) Received: (qmail invoked by alias); 01 Apr 2005 13:43:52 -0000 Received: from p548CDD3F.dip.t-dialin.net (EHLO localhost) [84.140.221.63] by mail.gmx.net (mp003) with SMTP; 01 Apr 2005 15:43:52 +0200 X-Authenticated: #5114400 Date: Fri, 1 Apr 2005 15:43:48 +0200 From: Mario Hoerich To: Robert Watson Message-ID: <20050401134347.GA6676@Pandora.MHoerich.de> References: <424B3AAB.6090200@wadham.ox.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 cc: Colin Percival cc: freebsd-arch@freebsd.org Subject: Re: Adding bsdiff to the base system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2005 13:43:55 -0000 # Robert Watson: > On Wed, 30 Mar 2005, Colin Percival wrote: > > I'd like to add bsdiff/bspatch into the base system. [...] > I think this would be a useful addition. [...] Not that it's important, but the names probably aren't the best possible choice, as 'bsdiff' seems to suggest 'BSD licensed diff'. (See bsdtar.) Then again, maybe it's just me. Regards, Mario From owner-freebsd-arch@FreeBSD.ORG Fri Apr 1 15:28:07 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93BE716A4CE; Fri, 1 Apr 2005 15:28:07 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09F0343D2F; Fri, 1 Apr 2005 15:28:07 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j31FS6ow008472; Fri, 1 Apr 2005 09:28:06 -0600 (CST) (envelope-from dan) Date: Fri, 1 Apr 2005 09:28:05 -0600 From: Dan Nelson To: Mario Hoerich Message-ID: <20050401152805.GA4564@dan.emsphone.com> References: <424B3AAB.6090200@wadham.ox.ac.uk> <20050401134347.GA6676@Pandora.MHoerich.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050401134347.GA6676@Pandora.MHoerich.de> X-OS: FreeBSD 5.4-PRERELEASE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: Robert Watson cc: Colin Percival cc: freebsd-arch@freebsd.org Subject: Re: Adding bsdiff to the base system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2005 15:28:07 -0000 In the last episode (Apr 01), Mario Hoerich said: > # Robert Watson: > > On Wed, 30 Mar 2005, Colin Percival wrote: > > > I'd like to add bsdiff/bspatch into the base system. > [...] > > I think this would be a useful addition. > [...] > > Not that it's important, but the names probably aren't the best > possible choice, as 'bsdiff' seems to suggest 'BSD licensed diff'. > (See bsdtar.) Yes, that's what I assumed this thread was about for the first couple posts. bdiff/bpatch sound like better names. What's the s stand for? -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-arch@FreeBSD.ORG Fri Apr 1 20:16:52 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5A9C16A4CE for ; Fri, 1 Apr 2005 20:16:52 +0000 (GMT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 517B643D41 for ; Fri, 1 Apr 2005 20:16:52 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j31KGkrs002729; Fri, 1 Apr 2005 15:16:47 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20050401152805.GA4564@dan.emsphone.com> References: <424B3AAB.6090200@wadham.ox.ac.uk> <20050401134347.GA6676@Pandora.MHoerich.de> <20050401152805.GA4564@dan.emsphone.com> Date: Fri, 1 Apr 2005 15:16:45 -0500 To: Dan Nelson , Colin Percival From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.2 cc: freebsd-arch@freebsd.org Subject: Re: Adding bsdiff to the base system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2005 20:16:52 -0000 At 9:28 AM -0600 4/1/05, Dan Nelson wrote: >In the last episode (Apr 01), Mario Hoerich said: >> # Robert Watson: >> > On Wed, 30 Mar 2005, Colin Percival wrote: >> > > I'd like to add bsdiff/bspatch into the base system. >> [...] >> > I think this would be a useful addition. >> [...] >> >> Not that it's important, but the names probably aren't the best >> possible choice, as 'bsdiff' seems to suggest 'BSD licensed diff'. >> (See bsdtar.) > >Yes, that's what I assumed this thread was about for the first >couple posts. bdiff/bpatch sound like better names. What's the >'s' stand for? I was also confused by the names at first. How about just 'bindiff' and 'binpatch'? These do sound like useful utilities to add, now that I understand what they are... -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Fri Apr 1 20:37:35 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAA8F16A4CE for ; Fri, 1 Apr 2005 20:37:35 +0000 (GMT) Received: from mail23.sea5.speakeasy.net (mail23.sea5.speakeasy.net [69.17.117.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 635C543D49 for ; Fri, 1 Apr 2005 20:37:35 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 14325 invoked from network); 1 Apr 2005 20:37:35 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 1 Apr 2005 20:37:34 -0000 Received: from [10.50.41.231] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j31KbS12035272; Fri, 1 Apr 2005 15:37:29 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Fri, 1 Apr 2005 13:43:56 -0500 User-Agent: KMail/1.6.2 References: <20050331.225633.125544617.imp@bsdimp.com> In-Reply-To: <20050331.225633.125544617.imp@bsdimp.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <200504011343.56385.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: arch@FreeBSD.org Subject: Re: small change to config X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2005 20:37:36 -0000 On Friday 01 April 2005 12:56 am, M. Warner Losh wrote: > I'd like to make a small change to config, and use that change to > improve the pc98 port. > > Right now, the machine line in config looks like: > > machine pc98 > > This causes compile/FOO/machine to be linked to pc98/include. We have > similar logic for modules. > > NetBSD's machine line, on some architecutres, has two arguments, which > correspond to $MACHINE and $MACHINE_ARCH respectively. I'd like to > pull this concept into FreeBSD. The only machine that this impacts is > pc98. pc98 config files would change to: > > machine pc98 i386 > > config creates the machine link, as now. In addition, a link is made > from i386 to sys/i386/include. This allows the majority of the .h > files that are shared amoung ports that have the same CPU to live in > one place, and the machine/foo.h files with minor tweaks. > > I'd like to move to this model on FreeBSD, and use it to reduce the > number of #ifdef PC98 in the tree, while allowing a cleaner separation > of pc98 from i386. This should reduce the maintanence impact of > having pc98 in the tree, as well as being cleaner. Sounds ok to me. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Fri Apr 1 20:37:35 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB9F016A4CF for ; Fri, 1 Apr 2005 20:37:35 +0000 (GMT) Received: from mail23.sea5.speakeasy.net (mail23.sea5.speakeasy.net [69.17.117.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63BCA43D4C for ; Fri, 1 Apr 2005 20:37:35 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 14325 invoked from network); 1 Apr 2005 20:37:35 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 1 Apr 2005 20:37:34 -0000 Received: from [10.50.41.231] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j31KbS12035272; Fri, 1 Apr 2005 15:37:29 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Fri, 1 Apr 2005 13:43:56 -0500 User-Agent: KMail/1.6.2 References: <20050331.225633.125544617.imp@bsdimp.com> In-Reply-To: <20050331.225633.125544617.imp@bsdimp.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <200504011343.56385.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: arch@FreeBSD.org Subject: Re: small change to config X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2005 20:37:36 -0000 On Friday 01 April 2005 12:56 am, M. Warner Losh wrote: > I'd like to make a small change to config, and use that change to > improve the pc98 port. > > Right now, the machine line in config looks like: > > machine pc98 > > This causes compile/FOO/machine to be linked to pc98/include. We have > similar logic for modules. > > NetBSD's machine line, on some architecutres, has two arguments, which > correspond to $MACHINE and $MACHINE_ARCH respectively. I'd like to > pull this concept into FreeBSD. The only machine that this impacts is > pc98. pc98 config files would change to: > > machine pc98 i386 > > config creates the machine link, as now. In addition, a link is made > from i386 to sys/i386/include. This allows the majority of the .h > files that are shared amoung ports that have the same CPU to live in > one place, and the machine/foo.h files with minor tweaks. > > I'd like to move to this model on FreeBSD, and use it to reduce the > number of #ifdef PC98 in the tree, while allowing a cleaner separation > of pc98 from i386. This should reduce the maintanence impact of > having pc98 in the tree, as well as being cleaner. Sounds ok to me. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Fri Apr 1 21:19:01 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0CC516A4CE for ; Fri, 1 Apr 2005 21:19:01 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83A8D43D3F for ; Fri, 1 Apr 2005 21:19:01 +0000 (GMT) (envelope-from alexjeffburke@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so968688wra for ; Fri, 01 Apr 2005 13:19:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ZGsWE/fBZsbvg+Vrseme9TMCY/11a1XXMfRoW6BwWMbFrhATVmn9K/gTwN+ft9UdB5/vM4MU4pSYhCVAmS/giv80/ru2a3o3b7n/lBrEcw4r6wafs+NuZlvBJ03P09BOIW/FbQuL2ocY13BtkXSgdPVZXMG+jJjzVzPFN31Uvcw= Received: by 10.54.52.27 with SMTP id z27mr1041936wrz; Fri, 01 Apr 2005 13:19:01 -0800 (PST) Received: by 10.54.37.43 with HTTP; Fri, 1 Apr 2005 13:19:00 -0800 (PST) Message-ID: Date: Fri, 1 Apr 2005 22:19:00 +0100 From: Alex Burke To: arch@freebsd.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <424B3AAB.6090200@wadham.ox.ac.uk> <20050401134347.GA6676@Pandora.MHoerich.de> <20050401152805.GA4564@dan.emsphone.com> Subject: Re: Adding bsdiff to the base system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Alex Burke List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2005 21:19:02 -0000 Hi, At first I was also confused by the names...I agree with Garance, I think bindiff and binpatch are much better more descriptive names. Just my humble two cents, Alex Burke. Garance wrote: > I was also confused by the names at first. How about just > 'bindiff' and 'binpatch'? These do sound like useful utilities > to add, now that I understand what they are... > > -- > Garance Alistair Drosehn From owner-freebsd-arch@FreeBSD.ORG Fri Apr 1 22:12:43 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E8F416A4CE for ; Fri, 1 Apr 2005 22:12:43 +0000 (GMT) Received: from pd3mo3so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 713B943D5E for ; Fri, 1 Apr 2005 22:12:42 +0000 (GMT) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from pd2mr4so.prod.shaw.ca (pd2mr4so-qfe3.prod.shaw.ca [10.0.141.107]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IEA00MUZGCZ04WT@l-daemon> for freebsd-arch@freebsd.org; Fri, 01 Apr 2005 15:12:35 -0700 (MST) Received: from pn2ml1so.prod.shaw.ca ([10.0.121.145]) by pd2mr4so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IEA00GR5GCZI620@pd2mr4so.prod.shaw.ca> for freebsd-arch@freebsd.org; Fri, 01 Apr 2005 15:12:35 -0700 (MST) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IEA00D0BGCYIG@l-daemon> for freebsd-arch@freebsd.org; Fri, 01 Apr 2005 15:12:35 -0700 (MST) Date: Fri, 01 Apr 2005 14:12:23 -0800 From: Colin Percival In-reply-to: To: Garance A Drosihn Message-id: <424DC747.4020604@wadham.ox.ac.uk> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <424B3AAB.6090200@wadham.ox.ac.uk> <20050401134347.GA6676@Pandora.MHoerich.de> <20050401152805.GA4564@dan.emsphone.com> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050326) cc: Dan Nelson cc: lists@MHoerich.de cc: freebsd-arch@freebsd.org Subject: Re: Adding bsdiff to the base system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2005 22:12:43 -0000 >> In the last episode (Apr 01), Mario Hoerich said: >>> Not that it's important, but the names probably aren't the best >>> possible choice, as 'bsdiff' seems to suggest 'BSD licensed diff'. No, it would be "BSD licensed iff". :-) > At 9:28 AM -0600 4/1/05, Dan Nelson wrote: >> Yes, that's what I assumed this thread was about for the first >> couple posts. bdiff/bpatch sound like better names. What's the >> 's' stand for? Err... nothing. Or rather, I'm not sure what it stands for. I was looking for a name for a diff tool which worked on "binary software" (or more generally, files with lots of "byte-substitutions"), and which uses "bytewise subtraction" as part of its encoding process... (I'm sure you can think of other possible meanings of "bs", as well.) Garance A Drosihn wrote: > I was also confused by the names at first. How about just > 'bindiff' and 'binpatch'? These do sound like useful utilities > to add, now that I understand what they are... When I first wrote this code, I called it "bdiff". Soon thereafter, it was pointed out to me that there was a bit of a namespace collision -- the name "bdiff" -- and the name "bindiff", which was my second choice -- had each been used for several different (not very good) binary diff tools already. So I looked for a name which hadn't already been used by several other people, and settled on "bsdiff" / "bspatch" as a compromise between being descriptive and avoiding the possibility of getting confused with another program. This is all rather immaterial at this point, however: It's far too late to change the name now. Colin Percival From owner-freebsd-arch@FreeBSD.ORG Fri Apr 1 22:15:15 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65E7716A4CE for ; Fri, 1 Apr 2005 22:15:15 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AED243D46 for ; Fri, 1 Apr 2005 22:15:14 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 4F83F651F4; Fri, 1 Apr 2005 23:11:54 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15989-06; Fri, 1 Apr 2005 23:11:53 +0100 (BST) Received: from empiric.dek.spc.org (dhcp52.icir.org [192.150.187.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 06054651EB; Fri, 1 Apr 2005 23:11:50 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id A7DDD6823; Fri, 1 Apr 2005 14:15:04 -0800 (PST) Date: Fri, 1 Apr 2005 14:15:04 -0800 From: Bruce M Simpson To: "M. Warner Losh" Message-ID: <20050401221504.GC747@empiric.icir.org> References: <20050331.225633.125544617.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050331.225633.125544617.imp@bsdimp.com> cc: arch@freebsd.org Subject: Re: small change to config X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2005 22:15:15 -0000 On Thu, Mar 31, 2005 at 10:56:33PM -0700, M. Warner Losh wrote: > I'd like to make a small change to config, and use that change to > improve the pc98 port. I like this idea. From owner-freebsd-arch@FreeBSD.ORG Fri Apr 1 23:26:39 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 805D216A4CE for ; Fri, 1 Apr 2005 23:26:39 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 878AF43D31 for ; Fri, 1 Apr 2005 23:26:38 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.179] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DHVXB-0002wi-00; Sat, 02 Apr 2005 01:26:37 +0200 Received: from [217.227.151.221] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1DHVXA-0000vl-00; Sat, 02 Apr 2005 01:26:37 +0200 From: Max Laier To: freebsd-arch@freebsd.org Date: Sat, 2 Apr 2005 01:26:08 +0200 User-Agent: KMail/1.7.2 References: <424B3AAB.6090200@wadham.ox.ac.uk> <424DC747.4020604@wadham.ox.ac.uk> In-Reply-To: <424DC747.4020604@wadham.ox.ac.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1244220.2mfrUgNVmD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504020126.16738.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Dan Nelson cc: Garance A Drosihn cc: lists@mhoerich.de cc: Colin Percival Subject: Re: Adding bsdiff to the base system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2005 23:26:39 -0000 --nextPart1244220.2mfrUgNVmD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 02 April 2005 00:12, Colin Percival wrote: > >> In the last episode (Apr 01), Mario Hoerich said: > >>> Not that it's important, but the names probably aren't the best > >>> possible choice, as 'bsdiff' seems to suggest 'BSD licensed diff'. > > No, it would be "BSD licensed iff". :-) > > > At 9:28 AM -0600 4/1/05, Dan Nelson wrote: > >> Yes, that's what I assumed this thread was about for the first > >> couple posts. bdiff/bpatch sound like better names. What's the > >> 's' stand for? > > Err... nothing. Or rather, I'm not sure what it stands for. I was > looking for a name for a diff tool which worked on "binary software" (or > more generally, files with lots of "byte-substitutions"), and which uses > "bytewise subtraction" as part of its encoding process... (I'm sure you > can think of other possible meanings of "bs", as well.) Though it's "*B*inary *S*mall diff" ... and I like that name! > Garance A Drosihn wrote: > > I was also confused by the names at first. How about just > > 'bindiff' and 'binpatch'? These do sound like useful utilities > > to add, now that I understand what they are... > > When I first wrote this code, I called it "bdiff". Soon thereafter, it > was pointed out to me that there was a bit of a namespace collision -- the > name "bdiff" -- and the name "bindiff", which was my second choice -- had > each been used for several different (not very good) binary diff tools > already. > > So I looked for a name which hadn't already been used by several other > people, and settled on "bsdiff" / "bspatch" as a compromise between being > descriptive and avoiding the possibility of getting confused with another > program. > > This is all rather immaterial at this point, however: It's far too late > to change the name now. > > Colin Percival > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1244220.2mfrUgNVmD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCTdiYXyyEoT62BG0RAqBRAJ99TuLjoE55w5QS46MGthXwWfQKsACfe7mC sVFYFDcgBkfBKdZUmmUQAlU= =0xLf -----END PGP SIGNATURE----- --nextPart1244220.2mfrUgNVmD-- From owner-freebsd-arch@FreeBSD.ORG Sat Apr 2 20:16:10 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4021A16A4CE for ; Sat, 2 Apr 2005 20:16:10 +0000 (GMT) Received: from mail22.sea5.speakeasy.net (mail22.sea5.speakeasy.net [69.17.117.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCD1E43D1D for ; Sat, 2 Apr 2005 20:16:09 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 9324 invoked from network); 2 Apr 2005 20:16:09 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 2 Apr 2005 20:16:09 -0000 Received: from [192.168.0.15] (osx.baldwin.cx [192.168.0.15]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j32KG3ZT043306; Sat, 2 Apr 2005 15:16:03 -0500 (EST) (envelope-from jhb@FreeBSD.org) In-Reply-To: <200504020126.16738.max@love2party.net> References: <424B3AAB.6090200@wadham.ox.ac.uk> <424DC747.4020604@wadham.ox.ac.uk> <200504020126.16738.max@love2party.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4880d4c8fa4f5a350a0072ab1574ecc9@FreeBSD.org> Content-Transfer-Encoding: 7bit From: John Baldwin Date: Sat, 2 Apr 2005 15:16:02 -0500 To: Max Laier X-Mailer: Apple Mail (2.619.2) X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: Dan Nelson cc: Garance A Drosihn cc: Colin Percival cc: lists@mhoerich.de cc: freebsd-arch@FreeBSD.org Subject: Re: Adding bsdiff to the base system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2005 20:16:10 -0000 On Apr 1, 2005, at 6:26 PM, Max Laier wrote: > On Saturday 02 April 2005 00:12, Colin Percival wrote: >>>> In the last episode (Apr 01), Mario Hoerich said: >>>>> Not that it's important, but the names probably aren't the best >>>>> possible choice, as 'bsdiff' seems to suggest 'BSD licensed diff'. >> >> No, it would be "BSD licensed iff". :-) >> >>> At 9:28 AM -0600 4/1/05, Dan Nelson wrote: >>>> Yes, that's what I assumed this thread was about for the first >>>> couple posts. bdiff/bpatch sound like better names. What's the >>>> 's' stand for? >> >> Err... nothing. Or rather, I'm not sure what it stands for. I was >> looking for a name for a diff tool which worked on "binary software" >> (or >> more generally, files with lots of "byte-substitutions"), and which >> uses >> "bytewise subtraction" as part of its encoding process... (I'm sure >> you >> can think of other possible meanings of "bs", as well.) > > Though it's "*B*inary *S*mall diff" ... and I like that name! Heh, that's what I thought the "bs" stood for at first as well given that that is bs{diff,patch}'s claim to fame. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org