From owner-freebsd-arch@FreeBSD.ORG Sun Aug 29 04:36:06 2004 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 DE95A16A4CF for ; Sun, 29 Aug 2004 04:36:06 +0000 (GMT) Received: from digital-security.org (digital-security.org [216.254.116.252]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8071643D48 for ; Sun, 29 Aug 2004 04:36:06 +0000 (GMT) (envelope-from necro@digital-security.org) Received: from digital-security.org ([216.254.116.252]) by digital-security.org with esmtp (Exim 4.41 (FreeBSD)) id 1C1Fw1-0000BX-HH for freebsd-arch@freebsd.org; Sat, 28 Aug 2004 23:00:51 -0400 Date: Sat, 28 Aug 2004 23:00:47 -0400 (EDT) From: necro To: freebsd-arch@freebsd.org Message-ID: <20040828225815.A695@digital-security.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Spam-Report: Spam detection software, running on the system "digital-security.org", hasmessageblock similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi, not sure if this is the right place to ask, but there's no freebsd-doc list (may be there should be?) I was looking around for some type of resource that goes through /sys/kern and explains what each *.c file there is, lists functions in them, goes does it and may be lists where these functions are called and for what purpose. [...] Content analysis details: (0.0 points, 3.0 required) pts rule name description -------------------------------------------------- Subject: Documentation 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, 29 Aug 2004 04:36:07 -0000 Hi, not sure if this is the right place to ask, but there's no freebsd-doc list (may be there should be?) I was looking around for some type of resource that goes through /sys/kern and explains what each *.c file there is, lists functions in them, goes through the functions and explains what the function does / how it does it and may be lists where these functions are called and for what purpose. Is there such a beast? If not, would it help if I tried to write it? And how fast would it get obsolete? :) Any answers / comments / suggestions are appreciated. Val From owner-freebsd-arch@FreeBSD.ORG Sun Aug 29 05:34:08 2004 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 8C55816A4CE for ; Sun, 29 Aug 2004 05:34:08 +0000 (GMT) Received: from digital-security.org (digital-security.org [216.254.116.252]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5992643D39 for ; Sun, 29 Aug 2004 05:34:08 +0000 (GMT) (envelope-from necro@digital-security.org) Received: from digital-security.org ([216.254.116.252]) by digital-security.org with esmtp (Exim 4.41 (FreeBSD)) id 1C1GqB-0000Ia-3l for freebsd-arch@freebsd.org; Sat, 28 Aug 2004 23:58:52 -0400 Date: Sat, 28 Aug 2004 23:58:49 -0400 (EDT) From: Val Polyakov To: freebsd-arch@freebsd.org In-Reply-To: <20040828225815.A695@digital-security.org> Message-ID: <20040828235813.I1151@digital-security.org> References: <20040828225815.A695@digital-security.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Spam-Report: Spam detection software, running on the system "digital-security.org", hasmessageblock similar future email. If you have any questions, see the administrator of that system for details.there instead --Val [...] Content analysis details: (0.0 points, 3.0 required) pts rule name description -------------------------------------------------- Subject: Re: Documentation 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, 29 Aug 2004 05:34:08 -0000 nevermind! there is a freebsd-doc .. :D I'll post there instead --Val On Sat, 28 Aug 2004, necro wrote: > Hi, > > not sure if this is the right place to ask, but there's no freebsd-doc > list (may be there should be?) > > I was looking around for some type of resource that goes through /sys/kern > and explains what each *.c file there is, lists functions in them, goes > through the functions and explains what the function does / how it does it > and may be lists where these functions are called and for what purpose. > > Is there such a beast? If not, would it help if I tried to write it? > And how fast would it get obsolete? :) > > Any answers / comments / suggestions are appreciated. > > Val > _______________________________________________ > 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 Sun Aug 29 21:08:11 2004 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 4EEDC16A4CE for ; Sun, 29 Aug 2004 21:08:11 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4076143D55 for ; Sun, 29 Aug 2004 21:08:11 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 2FA7572DD4; Sun, 29 Aug 2004 14:08:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 26F8E72DCB; Sun, 29 Aug 2004 14:08:11 -0700 (PDT) Date: Sun, 29 Aug 2004 14:08:11 -0700 (PDT) From: Doug White To: necro In-Reply-To: <20040828225815.A695@digital-security.org> Message-ID: <20040829135920.T69068@carver.gumbysoft.com> References: <20040828225815.A695@digital-security.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: Documentation 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, 29 Aug 2004 21:08:11 -0000 On Sat, 28 Aug 2004, necro wrote: > I was looking around for some type of resource that goes through /sys/kern > and explains what each *.c file there is, lists functions in them, goes > through the functions and explains what the function does / how it does it > and may be lists where these functions are called and for what purpose. > > Is there such a beast? If not, would it help if I tried to write it? > And how fast would it get obsolete? :) I strongly suggest you run, not walk, to your favorite bookseller and buy "The Design & Implementation of the FreeBSD Operating System." It works at a higher level than individual functions and lines of code, but gives fantastic insight into, suprisingly, design and implementation concerns in the current kernel. Pretty much required bookshelf material for any aspiring kernel hacker. That being said -- if you can write such detailed documentation, then you probably deserve a case of beer and a commit bit since you'll know more about the system than most people :) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Mon Aug 30 14:49:24 2004 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 1044C16A4CE for ; Mon, 30 Aug 2004 14:49:24 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 931F143D55 for ; Mon, 30 Aug 2004 14:49:23 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i7UFmB2I004952 for ; Mon, 30 Aug 2004 10:48:11 -0500 Date: Mon, 30 Aug 2004 10:48:11 -0500 (EST) From: Sam X-X-Sender: sah@athena To: freebsd-arch@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: splxxx level? 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, 30 Aug 2004 14:49:24 -0000 Hello - I'm almost to testing on my AoE driver for 4.x and have a question about interrupt priority levels. There are currently three entry points into the driver: a) strategy routine b) network frame reception routine c) timer rexmit routine Any of the three can diddle with the device structure and thusly I need to ensure they're not running simultaneously. For example, the network reception can cause a buf to be completed and the rexmit timer can cause a buf to be failed. So, what kind of contexts are the callout, strategy, and network soft interrupt called in? Which splxxx will give one of them exclusive access to whatever they need? Just as a reality check -- I am thinking about this correct, right? Cheers, Sam From owner-freebsd-arch@FreeBSD.ORG Mon Aug 30 15:49:27 2004 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 03DB416A4CE for ; Mon, 30 Aug 2004 15:49:27 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8831C43D2F for ; Mon, 30 Aug 2004 15:49:26 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.0.12] (g4.samsco.home [192.168.0.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i7UFmvoD066507; Mon, 30 Aug 2004 09:48:57 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <41334C3B.4070101@freebsd.org> Date: Mon, 30 Aug 2004 09:48:11 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-arch@freebsd.org Subject: Re: splxxx level? 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, 30 Aug 2004 15:49:27 -0000 Sam wrote: > Hello - > > I'm almost to testing on my AoE driver for 4.x and have > a question about interrupt priority levels. > > There are currently three entry points into the driver: > > a) strategy routine > b) network frame reception routine > c) timer rexmit routine > > Any of the three can diddle with the device structure > and thusly I need to ensure they're not running simultaneously. > For example, the network reception can cause a buf to be completed > and the rexmit timer can cause a buf to be failed. > > So, what kind of contexts are the callout, strategy, and > network soft interrupt called in? Which splxxx will give > one of them exclusive access to whatever they need? > > Just as a reality check -- I am thinking about this correct, right? > > Cheers, > > Sam > With 4.x, only one CPU can be in the kernel at a time. You won't have to worry about multiple processes trying to get into strategy at the same time and whatnot. However, you can be preempted by your interrupt handler or by a timeout or by a software interrupt like the netisr. I don't remember if your driver is for a specific piece of hardware or if it's a generic layer that sits in between the network interface and the block layer. If it's for dedicated hardware then you'll need to define a interrupt type in bus_setup_intr() and use that type for the spl (i.e. INTR_TYPE_NET translates to splnet(), INTR_TYPE_BIO translates to splbio(), etc). The safe way to go is to protect all of your critical code sections with the appropriate spl level regardless. spls are very cheap and can be set/reset from an interrupt context so there is little penalty in using them liberally at first and then narrowing them down later. Just make sure that you don't leak an spl references, and don't hold an spl for so long that it creates priority inversions. Since the only interrupts and timeouts that you'll likely be dealing with are network related, splnet() is probably the right one to use. Scott From owner-freebsd-arch@FreeBSD.ORG Mon Aug 30 16:26:35 2004 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 7E51416A4CE; Mon, 30 Aug 2004 16:26:35 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98ABF43D60; Mon, 30 Aug 2004 16:26:34 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7UGQ0HQ052687; Mon, 30 Aug 2004 10:26:00 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 30 Aug 2004 10:26:06 -0600 (MDT) Message-Id: <20040830.102606.130865377.imp@bsdimp.com> To: scottl@freebsd.org From: "M. Warner Losh" In-Reply-To: <41334C3B.4070101@freebsd.org> References: <41334C3B.4070101@freebsd.org> 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 cc: sah@softcardsystems.com cc: freebsd-arch@freebsd.org Subject: Re: splxxx level? 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, 30 Aug 2004 16:26:35 -0000 In message: <41334C3B.4070101@freebsd.org> Scott Long writes: : Sam wrote: : : > Hello - : > : > I'm almost to testing on my AoE driver for 4.x and have : > a question about interrupt priority levels. : > : > There are currently three entry points into the driver: : > : > a) strategy routine : > b) network frame reception routine : > c) timer rexmit routine : > : > Any of the three can diddle with the device structure : > and thusly I need to ensure they're not running simultaneously. : > For example, the network reception can cause a buf to be completed : > and the rexmit timer can cause a buf to be failed. : > : > So, what kind of contexts are the callout, strategy, and : > network soft interrupt called in? Which splxxx will give : > one of them exclusive access to whatever they need? : > : > Just as a reality check -- I am thinking about this correct, right? : > : > Cheers, : > : > Sam : > : : With 4.x, only one CPU can be in the kernel at a time. You won't have : to worry about multiple processes trying to get into strategy at the : same time and whatnot. However, you can be preempted by your interrupt : handler or by a timeout or by a software interrupt like the netisr. I : don't remember if your driver is for a specific piece of hardware or if : it's a generic layer that sits in between the network interface and the : block layer. If it's for dedicated hardware then you'll need to define : a interrupt type in bus_setup_intr() and use that type for the spl : (i.e. INTR_TYPE_NET translates to splnet(), INTR_TYPE_BIO translates to : splbio(), etc). : : The safe way to go is to protect all of your critical code sections with : the appropriate spl level regardless. spls are very cheap and can be : set/reset from an interrupt context so there is little penalty in using : them liberally at first and then narrowing them down later. Just make : sure that you don't leak an spl references, and don't hold an spl for so : long that it creates priority inversions. Since the only interrupts and : timeouts that you'll likely be dealing with are network related, : splnet() is probably the right one to use. splimp() is what you want to use, not splnet(). Yes, this is confusing, but it appears to be what all the other network drivers use. None of them are using splnet() that I could find. splimp() is also used by the mbuf routines to protect mbuf operations. splnet() is a list of the software interrupts that are network drivers. splimp() is splnet() plus the hardware interrupts, so is more appropriate to block things called from the driver. Especially one that's described as having timeouts. If it is a network driver, you might consider using the timeout functionality in the net stack as opposed to the callout functions. This makes it possible to have almost the entire driver w/o doing any spls (most of the network drivers in 4 don't do spl at all, except for entry points that are outside the scope of the network/interrupt entry points, eg device_suspend). Warner From owner-freebsd-arch@FreeBSD.ORG Mon Aug 30 17:17:48 2004 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 3154216A4DF; Mon, 30 Aug 2004 17:17:47 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A2FB43D5C; Mon, 30 Aug 2004 17:17:46 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7UHELd0053311; Mon, 30 Aug 2004 11:14:21 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 30 Aug 2004 11:14:28 -0600 (MDT) Message-Id: <20040830.111428.56562495.imp@bsdimp.com> To: scottl@freebsd.org From: "M. Warner Losh" In-Reply-To: <20040830.102606.130865377.imp@bsdimp.com> References: <41334C3B.4070101@freebsd.org> <20040830.102606.130865377.imp@bsdimp.com> 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 cc: sah@softcardsystems.com cc: freebsd-arch@freebsd.org Subject: Re: splxxx level? 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, 30 Aug 2004 17:17:48 -0000 In message: <20040830.102606.130865377.imp@bsdimp.com> "M. Warner Losh" writes: : In message: <41334C3B.4070101@freebsd.org> : Scott Long writes: : : Sam wrote: : : : : > Hello - : : > : : > I'm almost to testing on my AoE driver for 4.x and have : : > a question about interrupt priority levels. : : > : : > There are currently three entry points into the driver: : : > : : > a) strategy routine : : > b) network frame reception routine : : > c) timer rexmit routine : : > : : > Any of the three can diddle with the device structure : : > and thusly I need to ensure they're not running simultaneously. : : > For example, the network reception can cause a buf to be completed : : > and the rexmit timer can cause a buf to be failed. : : > : : > So, what kind of contexts are the callout, strategy, and : : > network soft interrupt called in? Which splxxx will give : : > one of them exclusive access to whatever they need? : : > : : > Just as a reality check -- I am thinking about this correct, right? : : > : : > Cheers, : : > : : > Sam : : > : : : : With 4.x, only one CPU can be in the kernel at a time. You won't have : : to worry about multiple processes trying to get into strategy at the : : same time and whatnot. However, you can be preempted by your interrupt : : handler or by a timeout or by a software interrupt like the netisr. I : : don't remember if your driver is for a specific piece of hardware or if : : it's a generic layer that sits in between the network interface and the : : block layer. If it's for dedicated hardware then you'll need to define : : a interrupt type in bus_setup_intr() and use that type for the spl : : (i.e. INTR_TYPE_NET translates to splnet(), INTR_TYPE_BIO translates to : : splbio(), etc). : : : : The safe way to go is to protect all of your critical code sections with : : the appropriate spl level regardless. spls are very cheap and can be : : set/reset from an interrupt context so there is little penalty in using : : them liberally at first and then narrowing them down later. Just make : : sure that you don't leak an spl references, and don't hold an spl for so : : long that it creates priority inversions. Since the only interrupts and : : timeouts that you'll likely be dealing with are network related, : : splnet() is probably the right one to use. : : splimp() is what you want to use, not splnet(). Yes, this is : confusing, but it appears to be what all the other network drivers : use. None of them are using splnet() that I could find. splimp() is : also used by the mbuf routines to protect mbuf operations. : : splnet() is a list of the software interrupts that are network : drivers. : : splimp() is splnet() plus the hardware interrupts, so is more : appropriate to block things called from the driver. Especially one : that's described as having timeouts. If it is a network driver, you : might consider using the timeout functionality in the net stack as : opposed to the callout functions. This makes it possible to have : almost the entire driver w/o doing any spls (most of the network : drivers in 4 don't do spl at all, except for entry points that are : outside the scope of the network/interrupt entry points, eg : device_suspend). Ah, just saw 'AoE' in the reply. This likely means that you are writing a network stack that's glued into the system with the strategy routine. Inside the strategy routine, splbio() is likely what you need to hold while dealing with the struct buf that's passed into that routine. I'm not sure what spl level you need to be at to call into the network code. I'm thinking it is splimp(), but I'm not 100% sure about that. Stevens will likely be a good resource for 4.x. You may have to define a software interrupt to pass the packets to the network code to make the spls work out correctly. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Aug 30 17:48:46 2004 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 1438016A4CE for ; Mon, 30 Aug 2004 17:48:46 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C4CB43D54 for ; Mon, 30 Aug 2004 17:48:45 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.0.12] (g4.samsco.home [192.168.0.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i7UHmB7L066967; Mon, 30 Aug 2004 11:48:12 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <4133682D.3000403@freebsd.org> Date: Mon, 30 Aug 2004 11:47:25 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <41334C3B.4070101@freebsd.org> <20040830.102606.130865377.imp@bsdimp.com> <20040830.111428.56562495.imp@bsdimp.com> In-Reply-To: <20040830.111428.56562495.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: sah@softcardsystems.com cc: freebsd-arch@freebsd.org Subject: Re: splxxx level? 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, 30 Aug 2004 17:48:46 -0000 M. Warner Losh wrote: > In message: <20040830.102606.130865377.imp@bsdimp.com> > "M. Warner Losh" writes: > : In message: <41334C3B.4070101@freebsd.org> > : Scott Long writes: > : : Sam wrote: > : : > : : > Hello - > : : > > : : > I'm almost to testing on my AoE driver for 4.x and have > : : > a question about interrupt priority levels. > : : > > : : > There are currently three entry points into the driver: > : : > > : : > a) strategy routine > : : > b) network frame reception routine > : : > c) timer rexmit routine > : : > > : : > Any of the three can diddle with the device structure > : : > and thusly I need to ensure they're not running simultaneously. > : : > For example, the network reception can cause a buf to be completed > : : > and the rexmit timer can cause a buf to be failed. > : : > > : : > So, what kind of contexts are the callout, strategy, and > : : > network soft interrupt called in? Which splxxx will give > : : > one of them exclusive access to whatever they need? > : : > > : : > Just as a reality check -- I am thinking about this correct, right? > : : > > : : > Cheers, > : : > > : : > Sam > : : > > : : > : : With 4.x, only one CPU can be in the kernel at a time. You won't have > : : to worry about multiple processes trying to get into strategy at the > : : same time and whatnot. However, you can be preempted by your interrupt > : : handler or by a timeout or by a software interrupt like the netisr. I > : : don't remember if your driver is for a specific piece of hardware or if > : : it's a generic layer that sits in between the network interface and the > : : block layer. If it's for dedicated hardware then you'll need to define > : : a interrupt type in bus_setup_intr() and use that type for the spl > : : (i.e. INTR_TYPE_NET translates to splnet(), INTR_TYPE_BIO translates to > : : splbio(), etc). > : : > : : The safe way to go is to protect all of your critical code sections with > : : the appropriate spl level regardless. spls are very cheap and can be > : : set/reset from an interrupt context so there is little penalty in using > : : them liberally at first and then narrowing them down later. Just make > : : sure that you don't leak an spl references, and don't hold an spl for so > : : long that it creates priority inversions. Since the only interrupts and > : : timeouts that you'll likely be dealing with are network related, > : : splnet() is probably the right one to use. > : > : splimp() is what you want to use, not splnet(). Yes, this is > : confusing, but it appears to be what all the other network drivers > : use. None of them are using splnet() that I could find. splimp() is > : also used by the mbuf routines to protect mbuf operations. > : > : splnet() is a list of the software interrupts that are network > : drivers. > : > : splimp() is splnet() plus the hardware interrupts, so is more > : appropriate to block things called from the driver. Especially one > : that's described as having timeouts. If it is a network driver, you > : might consider using the timeout functionality in the net stack as > : opposed to the callout functions. This makes it possible to have > : almost the entire driver w/o doing any spls (most of the network > : drivers in 4 don't do spl at all, except for entry points that are > : outside the scope of the network/interrupt entry points, eg > : device_suspend). > > Ah, just saw 'AoE' in the reply. > > This likely means that you are writing a network stack that's glued > into the system with the strategy routine. Inside the strategy > routine, splbio() is likely what you need to hold while dealing with > the struct buf that's passed into that routine. I'm not sure what > spl level you need to be at to call into the network code. I'm > thinking it is splimp(), but I'm not 100% sure about that. Stevens > will likely be a good resource for 4.x. > > You may have to define a software interrupt to pass the packets to the > network code to make the spls work out correctly. > > Warner No, splbio() is not explicitely needed in this case. You'll be dealing with a bioq that might need protection, but you have total control over that. There is nothing else in the block layer that will interrupt you, not like the netisr in the network stack or the camisr in the CAM layer. Scott From owner-freebsd-arch@FreeBSD.ORG Mon Aug 30 18:02:24 2004 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 9E8BE16A4D4; Mon, 30 Aug 2004 18:02:24 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id E580043D4C; Mon, 30 Aug 2004 18:02:23 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7UI1IP8053881; Mon, 30 Aug 2004 12:01:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 30 Aug 2004 12:01:24 -0600 (MDT) Message-Id: <20040830.120124.28086427.imp@bsdimp.com> To: scottl@freebsd.org From: "M. Warner Losh" In-Reply-To: <4133682D.3000403@freebsd.org> References: <20040830.102606.130865377.imp@bsdimp.com> <20040830.111428.56562495.imp@bsdimp.com> <4133682D.3000403@freebsd.org> 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 cc: sah@softcardsystems.com cc: freebsd-arch@freebsd.org Subject: Re: splxxx level? 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, 30 Aug 2004 18:02:24 -0000 In message: <4133682D.3000403@freebsd.org> Scott Long writes: : M. Warner Losh wrote: : : > In message: <20040830.102606.130865377.imp@bsdimp.com> : > "M. Warner Losh" writes: : > : In message: <41334C3B.4070101@freebsd.org> : > : Scott Long writes: : > : : Sam wrote: : > : : : > : : > Hello - : > : : > : > : : > I'm almost to testing on my AoE driver for 4.x and have : > : : > a question about interrupt priority levels. : > : : > : > : : > There are currently three entry points into the driver: : > : : > : > : : > a) strategy routine : > : : > b) network frame reception routine : > : : > c) timer rexmit routine : > : : > : > : : > Any of the three can diddle with the device structure : > : : > and thusly I need to ensure they're not running simultaneously. : > : : > For example, the network reception can cause a buf to be completed : > : : > and the rexmit timer can cause a buf to be failed. : > : : > : > : : > So, what kind of contexts are the callout, strategy, and : > : : > network soft interrupt called in? Which splxxx will give : > : : > one of them exclusive access to whatever they need? : > : : > : > : : > Just as a reality check -- I am thinking about this correct, right? : > : : > : > : : > Cheers, : > : : > : > : : > Sam : > : : > : > : : : > : : With 4.x, only one CPU can be in the kernel at a time. You won't have : > : : to worry about multiple processes trying to get into strategy at the : > : : same time and whatnot. However, you can be preempted by your interrupt : > : : handler or by a timeout or by a software interrupt like the netisr. I : > : : don't remember if your driver is for a specific piece of hardware or if : > : : it's a generic layer that sits in between the network interface and the : > : : block layer. If it's for dedicated hardware then you'll need to define : > : : a interrupt type in bus_setup_intr() and use that type for the spl : > : : (i.e. INTR_TYPE_NET translates to splnet(), INTR_TYPE_BIO translates to : > : : splbio(), etc). : > : : : > : : The safe way to go is to protect all of your critical code sections with : > : : the appropriate spl level regardless. spls are very cheap and can be : > : : set/reset from an interrupt context so there is little penalty in using : > : : them liberally at first and then narrowing them down later. Just make : > : : sure that you don't leak an spl references, and don't hold an spl for so : > : : long that it creates priority inversions. Since the only interrupts and : > : : timeouts that you'll likely be dealing with are network related, : > : : splnet() is probably the right one to use. : > : : > : splimp() is what you want to use, not splnet(). Yes, this is : > : confusing, but it appears to be what all the other network drivers : > : use. None of them are using splnet() that I could find. splimp() is : > : also used by the mbuf routines to protect mbuf operations. : > : : > : splnet() is a list of the software interrupts that are network : > : drivers. : > : : > : splimp() is splnet() plus the hardware interrupts, so is more : > : appropriate to block things called from the driver. Especially one : > : that's described as having timeouts. If it is a network driver, you : > : might consider using the timeout functionality in the net stack as : > : opposed to the callout functions. This makes it possible to have : > : almost the entire driver w/o doing any spls (most of the network : > : drivers in 4 don't do spl at all, except for entry points that are : > : outside the scope of the network/interrupt entry points, eg : > : device_suspend). : > : > Ah, just saw 'AoE' in the reply. : > : > This likely means that you are writing a network stack that's glued : > into the system with the strategy routine. Inside the strategy : > routine, splbio() is likely what you need to hold while dealing with : > the struct buf that's passed into that routine. I'm not sure what : > spl level you need to be at to call into the network code. I'm : > thinking it is splimp(), but I'm not 100% sure about that. Stevens : > will likely be a good resource for 4.x. : > : > You may have to define a software interrupt to pass the packets to the : > network code to make the spls work out correctly. : > : > Warner : : No, splbio() is not explicitely needed in this case. You'll be : dealing with a bioq that might need protection, but you have total : control over that. There is nothing else in the block layer that : will interrupt you, not like the netisr in the network stack or the : camisr in the CAM layer. Why does da use splbio in its strategy routine then: static void dastrategy(struct buf *bp) { ... /* * Mask interrupts so that the pack cannot be invalidated until * after we are in the queue. Otherwise, we might not properly * clean up one of the buffers. */ s = splbio(); ...(error cases) /* * Place it in the queue of disk activities for this disk */ bufqdisksort(&softc->buf_queue, bp); splx(s); /* * Schedule ourselves for performing the work. */ xpt_schedule(periph, /* XXX priority */1); return; ... (error cases) } Is that due to the ISR routine from the cam layer? Or is the softc->buf_queue the 'bioq' that you were talking about? Warner From owner-freebsd-arch@FreeBSD.ORG Mon Aug 30 18:12:41 2004 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 E448916A4CE for ; Mon, 30 Aug 2004 18:12:41 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A2B643D5F for ; Mon, 30 Aug 2004 18:12:41 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.0.12] (g4.samsco.home [192.168.0.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i7UIC7rp067138; Mon, 30 Aug 2004 12:12:07 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <41336DC8.7080808@freebsd.org> Date: Mon, 30 Aug 2004 12:11:20 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <20040830.102606.130865377.imp@bsdimp.com> <20040830.111428.56562495.imp@bsdimp.com> <4133682D.3000403@freebsd.org> <20040830.120124.28086427.imp@bsdimp.com> In-Reply-To: <20040830.120124.28086427.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: sah@softcardsystems.com cc: freebsd-arch@freebsd.org Subject: Re: splxxx level? 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, 30 Aug 2004 18:12:42 -0000 M. Warner Losh wrote: > In message: <4133682D.3000403@freebsd.org> > Scott Long writes: > : M. Warner Losh wrote: > : > : > In message: <20040830.102606.130865377.imp@bsdimp.com> > : > "M. Warner Losh" writes: > : > : In message: <41334C3B.4070101@freebsd.org> > : > : Scott Long writes: > : > : : Sam wrote: > : > : : > : > : : > Hello - > : > : : > > : > : : > I'm almost to testing on my AoE driver for 4.x and have > : > : : > a question about interrupt priority levels. > : > : : > > : > : : > There are currently three entry points into the driver: > : > : : > > : > : : > a) strategy routine > : > : : > b) network frame reception routine > : > : : > c) timer rexmit routine > : > : : > > : > : : > Any of the three can diddle with the device structure > : > : : > and thusly I need to ensure they're not running simultaneously. > : > : : > For example, the network reception can cause a buf to be completed > : > : : > and the rexmit timer can cause a buf to be failed. > : > : : > > : > : : > So, what kind of contexts are the callout, strategy, and > : > : : > network soft interrupt called in? Which splxxx will give > : > : : > one of them exclusive access to whatever they need? > : > : : > > : > : : > Just as a reality check -- I am thinking about this correct, right? > : > : : > > : > : : > Cheers, > : > : : > > : > : : > Sam > : > : : > > : > : : > : > : : With 4.x, only one CPU can be in the kernel at a time. You won't have > : > : : to worry about multiple processes trying to get into strategy at the > : > : : same time and whatnot. However, you can be preempted by your interrupt > : > : : handler or by a timeout or by a software interrupt like the netisr. I > : > : : don't remember if your driver is for a specific piece of hardware or if > : > : : it's a generic layer that sits in between the network interface and the > : > : : block layer. If it's for dedicated hardware then you'll need to define > : > : : a interrupt type in bus_setup_intr() and use that type for the spl > : > : : (i.e. INTR_TYPE_NET translates to splnet(), INTR_TYPE_BIO translates to > : > : : splbio(), etc). > : > : : > : > : : The safe way to go is to protect all of your critical code sections with > : > : : the appropriate spl level regardless. spls are very cheap and can be > : > : : set/reset from an interrupt context so there is little penalty in using > : > : : them liberally at first and then narrowing them down later. Just make > : > : : sure that you don't leak an spl references, and don't hold an spl for so > : > : : long that it creates priority inversions. Since the only interrupts and > : > : : timeouts that you'll likely be dealing with are network related, > : > : : splnet() is probably the right one to use. > : > : > : > : splimp() is what you want to use, not splnet(). Yes, this is > : > : confusing, but it appears to be what all the other network drivers > : > : use. None of them are using splnet() that I could find. splimp() is > : > : also used by the mbuf routines to protect mbuf operations. > : > : > : > : splnet() is a list of the software interrupts that are network > : > : drivers. > : > : > : > : splimp() is splnet() plus the hardware interrupts, so is more > : > : appropriate to block things called from the driver. Especially one > : > : that's described as having timeouts. If it is a network driver, you > : > : might consider using the timeout functionality in the net stack as > : > : opposed to the callout functions. This makes it possible to have > : > : almost the entire driver w/o doing any spls (most of the network > : > : drivers in 4 don't do spl at all, except for entry points that are > : > : outside the scope of the network/interrupt entry points, eg > : > : device_suspend). > : > > : > Ah, just saw 'AoE' in the reply. > : > > : > This likely means that you are writing a network stack that's glued > : > into the system with the strategy routine. Inside the strategy > : > routine, splbio() is likely what you need to hold while dealing with > : > the struct buf that's passed into that routine. I'm not sure what > : > spl level you need to be at to call into the network code. I'm > : > thinking it is splimp(), but I'm not 100% sure about that. Stevens > : > will likely be a good resource for 4.x. > : > > : > You may have to define a software interrupt to pass the packets to the > : > network code to make the spls work out correctly. > : > > : > Warner > : > : No, splbio() is not explicitely needed in this case. You'll be > : dealing with a bioq that might need protection, but you have total > : control over that. There is nothing else in the block layer that > : will interrupt you, not like the netisr in the network stack or the > : camisr in the CAM layer. > > Why does da use splbio in its strategy routine then: > > static void > dastrategy(struct buf *bp) > { > ... > > /* > * Mask interrupts so that the pack cannot be invalidated until > * after we are in the queue. Otherwise, we might not properly > * clean up one of the buffers. > */ > s = splbio(); > > ...(error cases) > /* > * Place it in the queue of disk activities for this disk > */ > bufqdisksort(&softc->buf_queue, bp); > > splx(s); > > /* > * Schedule ourselves for performing the work. > */ > xpt_schedule(periph, /* XXX priority */1); > > return; > ... (error cases) > } > > Is that due to the ISR routine from the cam layer? Or is the > softc->buf_queue the 'bioq' that you were talking about? > > Warner Well, CAM is special in that it expects that all of the hardware drivers underneath it will use INTR_TYPE_BIO for their interrupts. That of course won't be true in the AoE case with network interface devices. Again, the only reason it is holding splbio() there is to protect the bioq during disksort. It can be protected using whatever spl you want, likely splimp() in the case of AoE, or nothing at all if you ensure that the bioq won't be touched from an interrupt/timeout/callout context. Scott From owner-freebsd-arch@FreeBSD.ORG Mon Aug 30 18:23:35 2004 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 2503016A4CE; Mon, 30 Aug 2004 18:23:35 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 993A743D55; Mon, 30 Aug 2004 18:23:34 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7UIKOM8054132; Mon, 30 Aug 2004 12:20:24 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 30 Aug 2004 12:20:30 -0600 (MDT) Message-Id: <20040830.122030.48201747.imp@bsdimp.com> To: scottl@freebsd.org From: "M. Warner Losh" In-Reply-To: <41336DC8.7080808@freebsd.org> References: <4133682D.3000403@freebsd.org> <20040830.120124.28086427.imp@bsdimp.com> <41336DC8.7080808@freebsd.org> 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 cc: sah@softcardsystems.com cc: freebsd-arch@freebsd.org Subject: Re: splxxx level? 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, 30 Aug 2004 18:23:35 -0000 In message: <41336DC8.7080808@freebsd.org> Scott Long writes: : M. Warner Losh wrote: : : > In message: <4133682D.3000403@freebsd.org> : > Scott Long writes: : > : M. Warner Losh wrote: : > : : > : > In message: <20040830.102606.130865377.imp@bsdimp.com> : > : > "M. Warner Losh" writes: : > : > : In message: <41334C3B.4070101@freebsd.org> : > : > : Scott Long writes: : > : > : : Sam wrote: : > : > : : : > : > : : > Hello - : > : > : : > : > : > : : > I'm almost to testing on my AoE driver for 4.x and have : > : > : : > a question about interrupt priority levels. : > : > : : > : > : > : : > There are currently three entry points into the driver: : > : > : : > : > : > : : > a) strategy routine : > : > : : > b) network frame reception routine : > : > : : > c) timer rexmit routine : > : > : : > : > : > : : > Any of the three can diddle with the device structure : > : > : : > and thusly I need to ensure they're not running simultaneously. : > : > : : > For example, the network reception can cause a buf to be completed : > : > : : > and the rexmit timer can cause a buf to be failed. : > : > : : > : > : > : : > So, what kind of contexts are the callout, strategy, and : > : > : : > network soft interrupt called in? Which splxxx will give : > : > : : > one of them exclusive access to whatever they need? : > : > : : > : > : > : : > Just as a reality check -- I am thinking about this correct, right? : > : > : : > : > : > : : > Cheers, : > : > : : > : > : > : : > Sam : > : > : : > : > : > : : : > : > : : With 4.x, only one CPU can be in the kernel at a time. You won't have : > : > : : to worry about multiple processes trying to get into strategy at the : > : > : : same time and whatnot. However, you can be preempted by your interrupt : > : > : : handler or by a timeout or by a software interrupt like the netisr. I : > : > : : don't remember if your driver is for a specific piece of hardware or if : > : > : : it's a generic layer that sits in between the network interface and the : > : > : : block layer. If it's for dedicated hardware then you'll need to define : > : > : : a interrupt type in bus_setup_intr() and use that type for the spl : > : > : : (i.e. INTR_TYPE_NET translates to splnet(), INTR_TYPE_BIO translates to : > : > : : splbio(), etc). : > : > : : : > : > : : The safe way to go is to protect all of your critical code sections with : > : > : : the appropriate spl level regardless. spls are very cheap and can be : > : > : : set/reset from an interrupt context so there is little penalty in using : > : > : : them liberally at first and then narrowing them down later. Just make : > : > : : sure that you don't leak an spl references, and don't hold an spl for so : > : > : : long that it creates priority inversions. Since the only interrupts and : > : > : : timeouts that you'll likely be dealing with are network related, : > : > : : splnet() is probably the right one to use. : > : > : : > : > : splimp() is what you want to use, not splnet(). Yes, this is : > : > : confusing, but it appears to be what all the other network drivers : > : > : use. None of them are using splnet() that I could find. splimp() is : > : > : also used by the mbuf routines to protect mbuf operations. : > : > : : > : > : splnet() is a list of the software interrupts that are network : > : > : drivers. : > : > : : > : > : splimp() is splnet() plus the hardware interrupts, so is more : > : > : appropriate to block things called from the driver. Especially one : > : > : that's described as having timeouts. If it is a network driver, you : > : > : might consider using the timeout functionality in the net stack as : > : > : opposed to the callout functions. This makes it possible to have : > : > : almost the entire driver w/o doing any spls (most of the network : > : > : drivers in 4 don't do spl at all, except for entry points that are : > : > : outside the scope of the network/interrupt entry points, eg : > : > : device_suspend). : > : > : > : > Ah, just saw 'AoE' in the reply. : > : > : > : > This likely means that you are writing a network stack that's glued : > : > into the system with the strategy routine. Inside the strategy : > : > routine, splbio() is likely what you need to hold while dealing with : > : > the struct buf that's passed into that routine. I'm not sure what : > : > spl level you need to be at to call into the network code. I'm : > : > thinking it is splimp(), but I'm not 100% sure about that. Stevens : > : > will likely be a good resource for 4.x. : > : > : > : > You may have to define a software interrupt to pass the packets to the : > : > network code to make the spls work out correctly. : > : > : > : > Warner : > : : > : No, splbio() is not explicitely needed in this case. You'll be : > : dealing with a bioq that might need protection, but you have total : > : control over that. There is nothing else in the block layer that : > : will interrupt you, not like the netisr in the network stack or the : > : camisr in the CAM layer. : > : > Why does da use splbio in its strategy routine then: : > : > static void : > dastrategy(struct buf *bp) : > { : > ... : > : > /* : > * Mask interrupts so that the pack cannot be invalidated until : > * after we are in the queue. Otherwise, we might not properly : > * clean up one of the buffers. : > */ : > s = splbio(); : > : > ...(error cases) : > /* : > * Place it in the queue of disk activities for this disk : > */ : > bufqdisksort(&softc->buf_queue, bp); : > : > splx(s); : > : > /* : > * Schedule ourselves for performing the work. : > */ : > xpt_schedule(periph, /* XXX priority */1); : > : > return; : > ... (error cases) : > } : > : > Is that due to the ISR routine from the cam layer? Or is the : > softc->buf_queue the 'bioq' that you were talking about? : > : > Warner : : Well, CAM is special in that it expects that all of the hardware drivers : underneath it will use INTR_TYPE_BIO for their interrupts. That of : course won't be true in the AoE case with network interface devices. : Again, the only reason it is holding splbio() there is to protect the : bioq during disksort. It can be protected using whatever spl you want, : likely splimp() in the case of AoE, or nothing at all if you ensure that : the bioq won't be touched from an interrupt/timeout/callout context. OK. That makes perfect sense. I wasn't sure if that was the reason, or if there were other things that might also be mucking with the bioq. It is good to know that it is explicitly due to the scsi host adapter driver's isr running at splbio calling back into the peripheral driver's code. Thanks for the clearification. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Aug 30 20:40:30 2004 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 E932416A4CF; Mon, 30 Aug 2004 20:40:30 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EB0743D5F; Mon, 30 Aug 2004 20:40:30 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i7ULdBB2008658; Mon, 30 Aug 2004 16:39:11 -0500 Date: Mon, 30 Aug 2004 16:39:11 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Scott Long In-Reply-To: <41336DC8.7080808@freebsd.org> Message-ID: References: <20040830.102606.130865377.imp@bsdimp.com> <20040830.111428.56562495.imp@bsdimp.com> <4133682D.3000403@freebsd.org> <20040830.120124.28086427.imp@bsdimp.com> <41336DC8.7080808@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-arch@freebsd.org Subject: Re: splxxx level? 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, 30 Aug 2004 20:40:31 -0000 Wow guys, this is great stuff, thanks! Here's what I've discovered so far and again, correct me if I'm wrong. In strategy, I need to protect from my callout and netisr running. In my netisr, I need to protect from my callout running. In my callout, I need to protect from my netisr running. It looks like I can use splnet() everywhere *except* where I'm pulling mbufs off of the mbuf queue in the netisr routine. There I'll have to use splimp() to keep from banging heads with the hardware. I think this is the optimum spl-ing as it will allow the network hardware to keep queueing up packets as I process them. Comments? Sam From owner-freebsd-arch@FreeBSD.ORG Mon Aug 30 22:08:35 2004 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 AA08516A4CF; Mon, 30 Aug 2004 22:08:35 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49B0943D31; Mon, 30 Aug 2004 22:08:35 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7UM5RA3057331; Mon, 30 Aug 2004 16:05:28 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 30 Aug 2004 16:05:34 -0600 (MDT) Message-Id: <20040830.160534.104033700.imp@bsdimp.com> To: sah@softcardsystems.com From: "M. Warner Losh" In-Reply-To: References: <20040830.120124.28086427.imp@bsdimp.com> <41336DC8.7080808@freebsd.org> 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 cc: scottl@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: splxxx level? 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, 30 Aug 2004 22:08:35 -0000 In message: Sam writes: : Wow guys, this is great stuff, thanks! : : Here's what I've discovered so far and again, : correct me if I'm wrong. : : In strategy, I need to protect from my callout : and netisr running. In my netisr, I need to : protect from my callout running. In my callout, : I need to protect from my netisr running. : : It looks like I can use splnet() everywhere *except* : where I'm pulling mbufs off of the mbuf queue in the : netisr routine. There I'll have to use splimp() to : keep from banging heads with the hardware. : : I think this is the optimum spl-ing as it will allow : the network hardware to keep queueing up packets as I : process them. Comments? I'd be more inclined to use splimp() in all places because the network code depends on it. There are some subtle dependencies that one will run into if one only uses splnet(). Warner From owner-freebsd-arch@FreeBSD.ORG Mon Aug 30 23:41:44 2004 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 BA11416A4CE for ; Mon, 30 Aug 2004 23:41:44 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 2945043D58 for ; Mon, 30 Aug 2004 23:41:44 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 16353 invoked by uid 89); 30 Aug 2004 23:41:43 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 30 Aug 2004 23:41:43 -0000 Received: (qmail 16332 invoked by uid 89); 30 Aug 2004 23:41:42 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 30 Aug 2004 23:41:42 -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 i7UNfffY072498; Mon, 30 Aug 2004 19:41:41 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: Sam In-Reply-To: References: <20040830.102606.130865377.imp@bsdimp.com> <4133682D.3000403@freebsd.org><41336DC8.7080808@freebsd.org> Content-Type: text/plain Message-Id: <1093909301.61235.410.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 30 Aug 2004 19:41:41 -0400 Content-Transfer-Encoding: 7bit cc: Scott Long cc: freebsd-arch@freebsd.org Subject: Re: splxxx level? 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, 30 Aug 2004 23:41:44 -0000 Hi, Disclaimer: I never developed for FreeBSD 4.X and might be a few miles off target... I vaguely recall seeing that vinum issues new strategy calls to member disks in the context of a buffer's biodone callback. Because of this mixing local and network disks in a vinum set could cause the network disk's strategy to be called in the the interrupt context of the local disk controller. ( And the other way round?) Stephan On Mon, 2004-08-30 at 17:39, Sam wrote: > Wow guys, this is great stuff, thanks! > > Here's what I've discovered so far and again, > correct me if I'm wrong. > > In strategy, I need to protect from my callout > and netisr running. In my netisr, I need to > protect from my callout running. In my callout, > I need to protect from my netisr running. > > It looks like I can use splnet() everywhere *except* > where I'm pulling mbufs off of the mbuf queue in the > netisr routine. There I'll have to use splimp() to > keep from banging heads with the hardware. > > I think this is the optimum spl-ing as it will allow > the network hardware to keep queueing up packets as I > process them. Comments? > > Sam > > _______________________________________________ > 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 Mon Aug 30 23:54:59 2004 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 1B8E716A4CE for ; Mon, 30 Aug 2004 23:54:59 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7E2B43D2F for ; Mon, 30 Aug 2004 23:54:58 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.0.12] (g4.samsco.home [192.168.0.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i7UNsV2b068648; Mon, 30 Aug 2004 17:54:32 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <4133BE08.1070405@freebsd.org> Date: Mon, 30 Aug 2004 17:53:44 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephan Uphoff References: <20040830.102606.130865377.imp@bsdimp.com> <20040830.111428.56562495.imp@bsdimp.com> <4133682D.3000403@freebsd.org> <20040830.120124.28086427.imp@bsdimp.com> <41336DC8.7080808@freebsd.org> <1093909301.61235.410.camel@palm.tree.com> In-Reply-To: <1093909301.61235.410.camel@palm.tree.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Sam cc: freebsd-arch@freebsd.org Subject: Re: splxxx level? 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, 30 Aug 2004 23:54:59 -0000 Stephan Uphoff wrote: > Hi, > > Disclaimer: I never developed for FreeBSD 4.X > and might be a few miles off target... > > I vaguely recall seeing that vinum issues > new strategy calls to member disks > in the context of a buffer's biodone callback. > > Because of this mixing local and network > disks in a vinum set could cause the network > disk's strategy to be called in the the > interrupt context of the local disk controller. > ( And the other way round?) > > Interesting observation, and I don't have a good answer for that. I guess for now it'll be prudent to avoid mixing subsystems like this. Scott From owner-freebsd-arch@FreeBSD.ORG Tue Aug 31 04:32:00 2004 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 9DFBD16A4F6 for ; Tue, 31 Aug 2004 04:32:00 +0000 (GMT) Received: from digital-security.org (digital-security.org [216.254.116.252]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5410143D46 for ; Tue, 31 Aug 2004 04:32:00 +0000 (GMT) (envelope-from necro@digital-security.org) Received: from digital-security.org ([216.254.116.252] ident=necro) by digital-security.org with esmtp (Exim 4.41 (FreeBSD)) id 1C1yp8-0001kR-0T for freebsd-arch@freebsd.org; Mon, 30 Aug 2004 22:56:43 -0400 Date: Mon, 30 Aug 2004 22:56:40 -0400 (EDT) From: Val Polyakov To: freebsd-arch@freebsd.org Message-ID: <20040830225401.Y6704@digital-security.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Spam-Report: Spam detection software, running on the system "digital-security.org", hasmessageblock similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi, again not very sure where to send this to.. so forgive me if it's a wrong place below is a transcript of the weirdness. I think netinet/ip_proxy.h is broke. :) Val [...] Content analysis details: (0.0 points, 3.0 required) pts rule name description -------------------------------------------------- 0.0 AWL AWL: Auto-whitelist adjustment Subject: ip_proxy.h weirdness 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, 31 Aug 2004 04:32:00 -0000 Hi, again not very sure where to send this to.. so forgive me if it's a wrong place below is a transcript of the weirdness. I think netinet/ip_proxy.h is broke. :) Val ---------------------------------------------------------- digital-security# uname -a FreeBSD digital-security.org 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #2: Sun Aug 29 14:30:57 EDT 2004 necro@digital-security.org:/usr/src/sys/i386/compile/THRILLKILLCULT i386 digital-security# cat hello.c #include #include main() { printf("hi\n"); } digital-security# gcc -o hello hello.c In file included from hello.c:2: /usr/include/netinet/ip_proxy.h:26: error: syntax error before "u_short" /usr/include/netinet/ip_proxy.h:30: error: syntax error before "tcp_seq" /usr/include/netinet/ip_proxy.h:32: error: syntax error before "tcp_seq" /usr/include/netinet/ip_proxy.h:37: error: syntax error before "u_short" /usr/include/netinet/ip_proxy.h:47: error: syntax error before "u_int" /usr/include/netinet/ip_proxy.h:71: error: syntax error before "u_char" /usr/include/netinet/ip_proxy.h:76: error: syntax error before '*' token /usr/include/netinet/ip_proxy.h:79: error: syntax error before '*' token /usr/include/netinet/ip_proxy.h:81: error: syntax error before '*' token /usr/include/netinet/ip_proxy.h:83: error: syntax error before '*' token /usr/include/netinet/ip_proxy.h:99: error: syntax error before "u_32_t" /usr/include/netinet/ip_proxy.h:125: error: syntax error before "u_short" /usr/include/netinet/ip_proxy.h:129: error: syntax error before "u_32_t" /usr/include/netinet/ip_proxy.h:147: error: syntax error before "ipsec_cookie_t" /usr/include/netinet/ip_proxy.h:150: error: syntax error before "ipsec_cookie_t" /usr/include/netinet/ip_proxy.h:153: error: syntax error before "ipnat_t" /usr/include/netinet/ip_proxy.h:167: error: syntax error before '*' token /usr/include/netinet/ip_proxy.h:168: error: syntax error before '*' token /usr/include/netinet/ip_proxy.h:171: error: syntax error before '*' token /usr/include/netinet/ip_proxy.h:172: error: syntax error before "char" /usr/include/netinet/ip_proxy.h:173: error: syntax error before '*' token digital-security# From owner-freebsd-arch@FreeBSD.ORG Tue Aug 31 04:55:46 2004 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 27B7416A4CE for ; Tue, 31 Aug 2004 04:55:46 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAD3143D48 for ; Tue, 31 Aug 2004 04:55:45 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i7V4r8Kw005291; Mon, 30 Aug 2004 21:53:08 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i7V4r8j9005287; Mon, 30 Aug 2004 21:53:08 -0700 Date: Mon, 30 Aug 2004 21:53:08 -0700 From: Brooks Davis To: Val Polyakov Message-ID: <20040831045308.GA32602@odin.ac.hmc.edu> References: <20040830225401.Y6704@digital-security.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <20040830225401.Y6704@digital-security.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-arch@freebsd.org Subject: Re: ip_proxy.h weirdness 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, 31 Aug 2004 04:55:46 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 30, 2004 at 10:56:40PM -0400, Val Polyakov wrote: > again not very sure where to send this to.. so forgive me if it's a wrong > place This is the wrong place. If it were actually an error -hackers might be appropriate. > below is a transcript of the weirdness. > I think netinet/ip_proxy.h is broke. :) No, it just follows BSD practice of not gratuitously including every header required to make it work. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBNAQzXY6L6fI4GtQRAqH9AKCunWglSCSvyXqbhhR12oj6sd/iIwCgjFIh BSnH5iHX7dPuHsBMi/j6hWs= =5zwS -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-arch@FreeBSD.ORG Tue Aug 31 19:21:32 2004 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 38CFC16A4CE for ; Tue, 31 Aug 2004 19:21:32 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA99643D1F for ; Tue, 31 Aug 2004 19:21:31 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i7VKLNUk008057 for ; Tue, 31 Aug 2004 15:21:23 -0500 Date: Tue, 31 Aug 2004 15:21:23 -0500 (EST) From: Sam X-X-Sender: sah@athena To: freebsd-arch@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: dev_t ? 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, 31 Aug 2004 19:21:32 -0000 Following dev/ata/ata-disk.c:200 I'm doing the following: dev = disk_create(...); dev->si_drv1 = d; dev->si_iosize_max = 1024; d->dev = dev; When compiling I get "dereferencing pointer to incomplete type" errors. Am I missing something here? Both code sets use dev_t types. From owner-freebsd-arch@FreeBSD.ORG Tue Aug 31 19:22:51 2004 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 B260A16A4CE for ; Tue, 31 Aug 2004 19:22:51 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 037B543D49 for ; Tue, 31 Aug 2004 19:22:51 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i7VJMhAK080722; Tue, 31 Aug 2004 21:22:48 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Sam From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 31 Aug 2004 15:21:23 CDT." Date: Tue, 31 Aug 2004 21:22:43 +0200 Message-ID: <80721.1093980163@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-arch@freebsd.org Subject: Re: dev_t ? 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, 31 Aug 2004 19:22:51 -0000 In message , Sam writes: >Following dev/ata/ata-disk.c:200 I'm doing the following: > >dev = disk_create(...); >dev->si_drv1 = d; >dev->si_iosize_max = 1024; >d->dev = dev; > >When compiling I get "dereferencing pointer to incomplete type" errors. > >Am I missing something here? Both code sets use dev_t types. #include -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Aug 31 20:20:33 2004 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 10F4916A4CE for ; Tue, 31 Aug 2004 20:20:33 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3AD643D54 for ; Tue, 31 Aug 2004 20:20:32 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i7VLKOw4008434 for ; Tue, 31 Aug 2004 16:20:24 -0500 Date: Tue, 31 Aug 2004 16:20:24 -0500 (EST) From: Sam X-X-Sender: sah@athena To: freebsd-arch@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: option directive and turning on AOE 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, 31 Aug 2004 20:20:33 -0000 Hello, I've added code to if_ethersubr.c:/ether_demux/ to queue up AoE frames as they appear. I followed suit with other protocols and included my addition inside of an #ifdef AOE. Where do I turn this on? I thought perhaps just adding an 'option AOE' to the config would do it, but it doesn't -- so clearly I don't understand how the option directive works. The config man page doesn't talk about option/device directives ... I'm still looking, but a clue would be well received. Cheers, Sam From owner-freebsd-arch@FreeBSD.ORG Tue Aug 31 20:28:48 2004 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 4235416A4CE for ; Tue, 31 Aug 2004 20:28:48 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5F1943D1D for ; Tue, 31 Aug 2004 20:28:47 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.0.12] (g4.samsco.home [192.168.0.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i7VKSQHZ072709; Tue, 31 Aug 2004 14:28:26 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <4134DF35.7070605@freebsd.org> Date: Tue, 31 Aug 2004 14:27:33 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-arch@freebsd.org Subject: Re: option directive and turning on AOE 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, 31 Aug 2004 20:28:48 -0000 Sam wrote: > Hello, > > I've added code to if_ethersubr.c:/ether_demux/ > to queue up AoE frames as they appear. I followed > suit with other protocols and included my addition > inside of an #ifdef AOE. Where do I turn this on? > I thought perhaps just adding an 'option AOE' to > the config would do it, but it doesn't -- so clearly > I don't understand how the option directive works. > The config man page doesn't talk about option/device > directives ... > > I'm still looking, but a clue would be well received. > > Cheers, > > Sam > Did you modify /sys/conf/options to tell it about your AOE option? If so, then you should have specified the name of a header file that the option would be #define'd into. Include that header file in if_ethersubr.c and you should have no problems. Incidentally, this might be an area when netgraph would be useful. Instead of having an AoE specific hook in the stack, you could have an AoE netgraph module that uses the existing netgraph hooks. It's just an idea, though. Scott From owner-freebsd-arch@FreeBSD.ORG Tue Aug 31 20:39:18 2004 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 A5F3C16A4CE; Tue, 31 Aug 2004 20:39:18 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A98A43D62; Tue, 31 Aug 2004 20:39:18 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i7VKdTtP030882; Tue, 31 Aug 2004 13:39:29 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i7VKdTvi030881; Tue, 31 Aug 2004 13:39:29 -0700 Date: Tue, 31 Aug 2004 13:39:29 -0700 From: Brooks Davis To: Scott Long Message-ID: <20040831203929.GB25134@odin.ac.hmc.edu> References: <4134DF35.7070605@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3uo+9/B/ebqu+fSQ" Content-Disposition: inline In-Reply-To: <4134DF35.7070605@freebsd.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Sam cc: freebsd-arch@freebsd.org Subject: Re: option directive and turning on AOE 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, 31 Aug 2004 20:39:18 -0000 --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 31, 2004 at 02:27:33PM -0600, Scott Long wrote: > Sam wrote: >=20 > >I've added code to if_ethersubr.c:/ether_demux/ > >to queue up AoE frames as they appear. I followed > >suit with other protocols and included my addition > >inside of an #ifdef AOE. Where do I turn this on? > >I thought perhaps just adding an 'option AOE' to > >the config would do it, but it doesn't -- so clearly > >I don't understand how the option directive works. > >The config man page doesn't talk about option/device > >directives ... > > > >I'm still looking, but a clue would be well received. >=20 > Did you modify /sys/conf/options to tell it about your > AOE option? If so, then you should have specified the name > of a header file that the option would be #define'd into. > Include that header file in if_ethersubr.c and you should > have no problems. >=20 > Incidentally, this might be an area when netgraph would be > useful. Instead of having an AoE specific hook in the > stack, you could have an AoE netgraph module that uses the > existing netgraph hooks. It's just an idea, though. Another option might be a PFIL hook. There isn't one there now, but I think I've seen talk of adding one. Actually, if we did that, we could get most of the netgraph specific hooks out of the ethernet code. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --3uo+9/B/ebqu+fSQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBNOIAXY6L6fI4GtQRAg5YAJ4lEaezZpnR+/CNR3tFJfataDutZgCfc64w OyOVBAkHghcChKKcdERpw+w= =fL4C -----END PGP SIGNATURE----- --3uo+9/B/ebqu+fSQ-- From owner-freebsd-arch@FreeBSD.ORG Tue Aug 31 20:42:10 2004 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 E7F0616A4CE for ; Tue, 31 Aug 2004 20:42:10 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9458843D3F for ; Tue, 31 Aug 2004 20:42:10 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.0.12] (g4.samsco.home [192.168.0.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i7VKfmWY072802; Tue, 31 Aug 2004 14:41:49 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <4134E258.4060903@freebsd.org> Date: Tue, 31 Aug 2004 14:40:56 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <4134DF35.7070605@freebsd.org> <20040831203929.GB25134@odin.ac.hmc.edu> In-Reply-To: <20040831203929.GB25134@odin.ac.hmc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Sam cc: freebsd-arch@freebsd.org Subject: Re: option directive and turning on AOE 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, 31 Aug 2004 20:42:11 -0000 Brooks Davis wrote: > On Tue, Aug 31, 2004 at 02:27:33PM -0600, Scott Long wrote: > >>Sam wrote: >> >> >>>I've added code to if_ethersubr.c:/ether_demux/ >>>to queue up AoE frames as they appear. I followed >>>suit with other protocols and included my addition >>>inside of an #ifdef AOE. Where do I turn this on? >>>I thought perhaps just adding an 'option AOE' to >>>the config would do it, but it doesn't -- so clearly >>>I don't understand how the option directive works. >>>The config man page doesn't talk about option/device >>>directives ... >>> >>>I'm still looking, but a clue would be well received. >> >>Did you modify /sys/conf/options to tell it about your >>AOE option? If so, then you should have specified the name >>of a header file that the option would be #define'd into. >>Include that header file in if_ethersubr.c and you should >>have no problems. >> >>Incidentally, this might be an area when netgraph would be >>useful. Instead of having an AoE specific hook in the >>stack, you could have an AoE netgraph module that uses the >>existing netgraph hooks. It's just an idea, though. > > > Another option might be a PFIL hook. There isn't one there now, but I > think I've seen talk of adding one. Actually, if we did that, we could > get most of the netgraph specific hooks out of the ethernet code. > > -- Brooks > Do the PFIL hooks exist in 4.x? I know that he's trying to target his driver for that right now. Netgraph exists in both, so using it would keep his code more portable. Anyways, this isn't my area of expertise, so do whatever you find to be best. Scott From owner-freebsd-arch@FreeBSD.ORG Tue Aug 31 20:42:18 2004 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 9B9BA16A4DD; Tue, 31 Aug 2004 20:42:18 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A09E43D46; Tue, 31 Aug 2004 20:42:18 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i7VLg9cI008597; Tue, 31 Aug 2004 16:42:10 -0500 Date: Tue, 31 Aug 2004 16:42:09 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Brooks Davis In-Reply-To: <20040831203929.GB25134@odin.ac.hmc.edu> Message-ID: References: <4134DF35.7070605@freebsd.org> <20040831203929.GB25134@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Scott Long cc: freebsd-arch@freebsd.org Subject: Re: option directive and turning on AOE 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, 31 Aug 2004 20:42:18 -0000 OK, once i get it up I'll look into these other avenues to see if they're a cleaner approach. On Tue, 31 Aug 2004, Brooks Davis wrote: > On Tue, Aug 31, 2004 at 02:27:33PM -0600, Scott Long wrote: >> Sam wrote: >> >>> I've added code to if_ethersubr.c:/ether_demux/ >>> to queue up AoE frames as they appear. I followed >>> suit with other protocols and included my addition >>> inside of an #ifdef AOE. Where do I turn this on? >>> I thought perhaps just adding an 'option AOE' to >>> the config would do it, but it doesn't -- so clearly >>> I don't understand how the option directive works. >>> The config man page doesn't talk about option/device >>> directives ... >>> >>> I'm still looking, but a clue would be well received. >> >> Did you modify /sys/conf/options to tell it about your >> AOE option? If so, then you should have specified the name >> of a header file that the option would be #define'd into. >> Include that header file in if_ethersubr.c and you should >> have no problems. >> >> Incidentally, this might be an area when netgraph would be >> useful. Instead of having an AoE specific hook in the >> stack, you could have an AoE netgraph module that uses the >> existing netgraph hooks. It's just an idea, though. > > Another option might be a PFIL hook. There isn't one there now, but I > think I've seen talk of adding one. Actually, if we did that, we could > get most of the netgraph specific hooks out of the ethernet code. > > -- Brooks > > -- > Any statement of the form "X is the one, true Y" is FALSE. > PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 > From owner-freebsd-arch@FreeBSD.ORG Tue Aug 31 20:46:37 2004 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 616FC16A4D0; Tue, 31 Aug 2004 20:46:37 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E9C643D4C; Tue, 31 Aug 2004 20:46:37 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i7VKkmkf032076; Tue, 31 Aug 2004 13:46:48 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i7VKkmbi032075; Tue, 31 Aug 2004 13:46:48 -0700 Date: Tue, 31 Aug 2004 13:46:48 -0700 From: Brooks Davis To: Scott Long Message-ID: <20040831204648.GC25134@odin.ac.hmc.edu> References: <4134DF35.7070605@freebsd.org> <20040831203929.GB25134@odin.ac.hmc.edu> <4134E258.4060903@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PuGuTyElPB9bOcsM" Content-Disposition: inline In-Reply-To: <4134E258.4060903@freebsd.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Sam cc: freebsd-arch@freebsd.org Subject: Re: option directive and turning on AOE 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, 31 Aug 2004 20:46:37 -0000 --PuGuTyElPB9bOcsM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 31, 2004 at 02:40:56PM -0600, Scott Long wrote: > Brooks Davis wrote: >=20 > >On Tue, Aug 31, 2004 at 02:27:33PM -0600, Scott Long wrote: > > > >>Sam wrote: > >> > >> > >>>I've added code to if_ethersubr.c:/ether_demux/ > >>>to queue up AoE frames as they appear. I followed > >>>suit with other protocols and included my addition > >>>inside of an #ifdef AOE. Where do I turn this on? > >>>I thought perhaps just adding an 'option AOE' to > >>>the config would do it, but it doesn't -- so clearly > >>>I don't understand how the option directive works. > >>>The config man page doesn't talk about option/device > >>>directives ... > >>> > >>>I'm still looking, but a clue would be well received. > >> > >>Did you modify /sys/conf/options to tell it about your > >>AOE option? If so, then you should have specified the name > >>of a header file that the option would be #define'd into. > >>Include that header file in if_ethersubr.c and you should > >>have no problems. > >> > >>Incidentally, this might be an area when netgraph would be > >>useful. Instead of having an AoE specific hook in the > >>stack, you could have an AoE netgraph module that uses the > >>existing netgraph hooks. It's just an idea, though. > > > > > >Another option might be a PFIL hook. There isn't one there now, but I > >think I've seen talk of adding one. Actually, if we did that, we could > >get most of the netgraph specific hooks out of the ethernet code. >=20 > Do the PFIL hooks exist in 4.x? I know that he's trying to target > his driver for that right now. Netgraph exists in both, so using it > would keep his code more portable. Anyways, this isn't my area of > expertise, so do whatever you find to be best. No, it doesn't look like pfil hooks are in 4.x. If we had a new service that wanted to use them in there, we could probably MFC them without converting existing services making it a fairly low-risk operation. Using netgraph is probably the easiest solution though. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --PuGuTyElPB9bOcsM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBNOO3XY6L6fI4GtQRAv9mAKC8WekMkgJ/Xb8pgdqtdH1Q/JM3HwCfeW0U pWCTq94ssN3rPsR6LGyk+Bs= =ePiK -----END PGP SIGNATURE----- --PuGuTyElPB9bOcsM-- From owner-freebsd-arch@FreeBSD.ORG Tue Aug 31 20:51:03 2004 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 698A416A4CE; Tue, 31 Aug 2004 20:51:03 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AE2E43D46; Tue, 31 Aug 2004 20:51:03 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id B836C7A3F9; Tue, 31 Aug 2004 13:51:02 -0700 (PDT) Message-ID: <4134E4B6.2030409@elischer.org> Date: Tue, 31 Aug 2004 13:51:02 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Brooks Davis References: <4134DF35.7070605@freebsd.org> <20040831203929.GB25134@odin.ac.hmc.edu> In-Reply-To: <20040831203929.GB25134@odin.ac.hmc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Sam cc: Scott Long cc: freebsd-arch@freebsd.org Subject: Re: option directive and turning on AOE 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, 31 Aug 2004 20:51:03 -0000 Brooks Davis wrote: >On Tue, Aug 31, 2004 at 02:27:33PM -0600, Scott Long wrote: > > >>Sam wrote: >> >> >> >>>I've added code to if_ethersubr.c:/ether_demux/ >>>to queue up AoE frames as they appear. I followed >>>suit with other protocols and included my addition >>>inside of an #ifdef AOE. Where do I turn this on? >>>I thought perhaps just adding an 'option AOE' to >>>the config would do it, but it doesn't -- so clearly >>>I don't understand how the option directive works. >>>The config man page doesn't talk about option/device >>>directives ... >>> >>>I'm still looking, but a clue would be well received. >>> >>> >>Did you modify /sys/conf/options to tell it about your >>AOE option? If so, then you should have specified the name >>of a header file that the option would be #define'd into. >>Include that header file in if_ethersubr.c and you should >>have no problems. >> >>Incidentally, this might be an area when netgraph would be >>useful. Instead of having an AoE specific hook in the >>stack, you could have an AoE netgraph module that uses the >>existing netgraph hooks. It's just an idea, though. >> >> > >Another option might be a PFIL hook. There isn't one there now, but I >think I've seen talk of adding one. Actually, if we did that, we could >get most of the netgraph specific hooks out of the ethernet code. > or visa versa.. make pfil have a netgraph hook. then you could use it to filter all kinds of things in netgraph graphs. :-) > >-- Brooks > > > From owner-freebsd-arch@FreeBSD.ORG Tue Aug 31 22:28:42 2004 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 6723916A4CE for ; Tue, 31 Aug 2004 22:28:42 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1C5943D45 for ; Tue, 31 Aug 2004 22:28:41 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 90442 invoked from network); 31 Aug 2004 22:26:33 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 31 Aug 2004 22:26:33 -0000 Message-ID: <4134FB98.6A3822BC@freebsd.org> Date: Wed, 01 Sep 2004 00:28:40 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brooks Davis References: <20040831203929.GB25134@odin.ac.hmc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Sam cc: Scott Long cc: freebsd-arch@freebsd.org Subject: Re: option directive and turning on AOE 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, 31 Aug 2004 22:28:42 -0000 Brooks Davis wrote: > > On Tue, Aug 31, 2004 at 02:27:33PM -0600, Scott Long wrote: > > Sam wrote: > > > > >I've added code to if_ethersubr.c:/ether_demux/ > > >to queue up AoE frames as they appear. I followed > > >suit with other protocols and included my addition > > >inside of an #ifdef AOE. Where do I turn this on? > > >I thought perhaps just adding an 'option AOE' to > > >the config would do it, but it doesn't -- so clearly > > >I don't understand how the option directive works. > > >The config man page doesn't talk about option/device > > >directives ... > > > > > >I'm still looking, but a clue would be well received. > > > > Did you modify /sys/conf/options to tell it about your > > AOE option? If so, then you should have specified the name > > of a header file that the option would be #define'd into. > > Include that header file in if_ethersubr.c and you should > > have no problems. > > > > Incidentally, this might be an area when netgraph would be > > useful. Instead of having an AoE specific hook in the > > stack, you could have an AoE netgraph module that uses the > > existing netgraph hooks. It's just an idea, though. > > Another option might be a PFIL hook. There isn't one there now, but I > think I've seen talk of adding one. Actually, if we did that, we could > get most of the netgraph specific hooks out of the ethernet code. What is AoE? And what kind of Frames does it come in? -- Andre From owner-freebsd-arch@FreeBSD.ORG Tue Aug 31 22:33:20 2004 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 3F15E16A4CE for ; Tue, 31 Aug 2004 22:33:20 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7527F43D53 for ; Tue, 31 Aug 2004 22:33:19 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 90474 invoked from network); 31 Aug 2004 22:31:10 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 31 Aug 2004 22:31:10 -0000 Message-ID: <4134FCAE.7374599A@freebsd.org> Date: Wed, 01 Sep 2004 00:33:18 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer References: <20040831203929.GB25134@odin.ac.hmc.edu> <4134E4B6.2030409@elischer.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Sam cc: Scott Long cc: freebsd-arch@freebsd.org Subject: Re: option directive and turning on AOE 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, 31 Aug 2004 22:33:20 -0000 Julian Elischer wrote: > > Brooks Davis wrote: > > >On Tue, Aug 31, 2004 at 02:27:33PM -0600, Scott Long wrote: > > > > > >>Sam wrote: > >> > >> > >> > >>>I've added code to if_ethersubr.c:/ether_demux/ > >>>to queue up AoE frames as they appear. I followed > >>>suit with other protocols and included my addition > >>>inside of an #ifdef AOE. Where do I turn this on? > >>>I thought perhaps just adding an 'option AOE' to > >>>the config would do it, but it doesn't -- so clearly > >>>I don't understand how the option directive works. > >>>The config man page doesn't talk about option/device > >>>directives ... > >>> > >>>I'm still looking, but a clue would be well received. > >>> > >>> > >>Did you modify /sys/conf/options to tell it about your > >>AOE option? If so, then you should have specified the name > >>of a header file that the option would be #define'd into. > >>Include that header file in if_ethersubr.c and you should > >>have no problems. > >> > >>Incidentally, this might be an area when netgraph would be > >>useful. Instead of having an AoE specific hook in the > >>stack, you could have an AoE netgraph module that uses the > >>existing netgraph hooks. It's just an idea, though. > >> > >> > > > >Another option might be a PFIL hook. There isn't one there now, but I > >think I've seen talk of adding one. Actually, if we did that, we could > >get most of the netgraph specific hooks out of the ethernet code. > > > > or visa versa.. > make pfil have a netgraph hook. then you could use it to filter all > kinds of things in netgraph graphs. Yea, a ng_pfilhook module should be fairly easy to write. I don't like it the other way around. PFIL_HOOKS is a hooking mechanism, so something should hook itself in there. PS: I'm thinking about moving all the IPSec cruft in IPv4 into a pfil hook. Thus IPSecKAME and FastIPSec could be loadable modules and it would relieve ip_input/output.c by some more 1000's of lines. Haven't looked fully into it yet though. I'm sure there are some difficulties hidden somewhere. ;-) -- Andre From owner-freebsd-arch@FreeBSD.ORG Tue Aug 31 22:46:25 2004 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 5BC6316A4CE; Tue, 31 Aug 2004 22:46:25 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id D499843D58; Tue, 31 Aug 2004 22:46:24 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.0.12] (g4.samsco.home [192.168.0.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i7VMk1PT073300; Tue, 31 Aug 2004 16:46:01 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <4134FF74.4010105@freebsd.org> Date: Tue, 31 Aug 2004 16:45:08 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <4134DF35.7070605@freebsd.org> <20040831203929.GB25134@odin.ac.hmc.edu> <4134E4B6.2030409@elischer.org> <4134FCAE.7374599A@freebsd.org> In-Reply-To: <4134FCAE.7374599A@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Sam cc: Julian Elischer cc: freebsd-arch@freebsd.org Subject: Re: option directive and turning on AOE 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, 31 Aug 2004 22:46:25 -0000 Andre Oppermann wrote: > Julian Elischer wrote: > >>Brooks Davis wrote: >> >> >>>On Tue, Aug 31, 2004 at 02:27:33PM -0600, Scott Long wrote: >>> >>> >>> >>>>Sam wrote: >>>> >>>> >>>> >>>> >>>>>I've added code to if_ethersubr.c:/ether_demux/ >>>>>to queue up AoE frames as they appear. I followed >>>>>suit with other protocols and included my addition >>>>>inside of an #ifdef AOE. Where do I turn this on? >>>>>I thought perhaps just adding an 'option AOE' to >>>>>the config would do it, but it doesn't -- so clearly >>>>>I don't understand how the option directive works. >>>>>The config man page doesn't talk about option/device >>>>>directives ... >>>>> >>>>>I'm still looking, but a clue would be well received. >>>>> >>>>> >>>> >>>>Did you modify /sys/conf/options to tell it about your >>>>AOE option? If so, then you should have specified the name >>>>of a header file that the option would be #define'd into. >>>>Include that header file in if_ethersubr.c and you should >>>>have no problems. >>>> >>>>Incidentally, this might be an area when netgraph would be >>>>useful. Instead of having an AoE specific hook in the >>>>stack, you could have an AoE netgraph module that uses the >>>>existing netgraph hooks. It's just an idea, though. >>>> >>>> >>> >>>Another option might be a PFIL hook. There isn't one there now, but I >>>think I've seen talk of adding one. Actually, if we did that, we could >>>get most of the netgraph specific hooks out of the ethernet code. >>> >> >>or visa versa.. >>make pfil have a netgraph hook. then you could use it to filter all >>kinds of things in netgraph graphs. > > > Yea, a ng_pfilhook module should be fairly easy to write. I don't like > it the other way around. PFIL_HOOKS is a hooking mechanism, so something > should hook itself in there. > > PS: I'm thinking about moving all the IPSec cruft in IPv4 into a pfil > hook. Thus IPSecKAME and FastIPSec could be loadable modules and it > would relieve ip_input/output.c by some more 1000's of lines. Haven't > looked fully into it yet though. I'm sure there are some difficulties > hidden somewhere. ;-) > Having a single common interface is definitely attractive, but there are performance and locking issues with the Netgraph framework that should probably be resolved first. Scott From owner-freebsd-arch@FreeBSD.ORG Tue Aug 31 23:02:36 2004 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 9AC2E16A4CE; Tue, 31 Aug 2004 23:02:36 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BABA43D58; Tue, 31 Aug 2004 23:02:36 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 356327A3E1; Tue, 31 Aug 2004 16:02:36 -0700 (PDT) Message-ID: <4135038B.4030203@elischer.org> Date: Tue, 31 Aug 2004 16:02:35 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Andre Oppermann References: <20040831203929.GB25134@odin.ac.hmc.edu> <4134E4B6.2030409@elischer.org> <4134FCAE.7374599A@freebsd.org> In-Reply-To: <4134FCAE.7374599A@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Sam cc: Scott Long cc: freebsd-arch@freebsd.org Subject: Re: option directive and turning on AOE 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, 31 Aug 2004 23:02:36 -0000 Andre Oppermann wrote: >Yea, a ng_pfilhook module should be fairly easy to write. I don't like >it the other way around. PFIL_HOOKS is a hooking mechanism, so something >should hook itself in there. > actually, netgraph is nothing but a hooking/connecting framework.. The modules are all just consumers of that interface. an ng_pfil node would be a node that filters packets that are received from a netgraph source.. it wouldn't have a clue what kind of source that was.. there already is an ng_ipfw node (but not in freebsd, though I believe it's coming) and there is an ng_bpf node that takes arbitrary filterring "programs" as generated by bpf. > >PS: I'm thinking about moving all the IPSec cruft in IPv4 into a pfil >hook. Thus IPSecKAME and FastIPSec could be loadable modules and it >would relieve ip_input/output.c by some more 1000's of lines. Haven't >looked fully into it yet though. I'm sure there are some difficulties >hidden somewhere. ;-) > > > From owner-freebsd-arch@FreeBSD.ORG Tue Aug 31 23:09:19 2004 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 84D9D16A4CE; Tue, 31 Aug 2004 23:09:19 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7493A43D31; Tue, 31 Aug 2004 23:09:19 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 222AE7A3E1; Tue, 31 Aug 2004 16:09:19 -0700 (PDT) Message-ID: <4135051E.2070007@elischer.org> Date: Tue, 31 Aug 2004 16:09:18 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Scott Long References: <4134DF35.7070605@freebsd.org> <20040831203929.GB25134@odin.ac.hmc.edu> <4134E4B6.2030409@elischer.org> <4134FCAE.7374599A@freebsd.org> <4134FF74.4010105@freebsd.org> In-Reply-To: <4134FF74.4010105@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Sam cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: option directive and turning on AOE 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, 31 Aug 2004 23:09:19 -0000 Scott Long wrote: > Andre Oppermann wrote: > >> > > Having a single common interface is definitely attractive, but there are > performance and locking issues with the Netgraph framework that should > probably be resolved first. both of these issues are in fact not major.. netgraph itself has no locking issuess.. (Netgraph is the framework), but some of teh node types have issues. Specifically, node types that can be caled from outside the netgraph framework, such as nodes that tie netgraph to other subsystems need to be worked on so that control enterring netgraph code from those subsystems gets an appropriate lock. This is not always needed, but every node needs to be examined with this in mind now that we have locking in teh rest of the system more worked out. performace.. well it can be fast. it depends on a lot of issues however.. in particular how many locks get contentions. > > > Scott From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 00:05:13 2004 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 5FACE16A4CE; Wed, 1 Sep 2004 00:05:13 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 196A343D3F; Wed, 1 Sep 2004 00:05:08 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.201] ([192.168.0.201]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i8104c2L073499; Tue, 31 Aug 2004 18:04:38 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4135118A.5030807@samsco.org> Date: Tue, 31 Aug 2004 18:02:18 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <4134DF35.7070605@freebsd.org> <20040831203929.GB25134@odin.ac.hmc.edu> <4134E4B6.2030409@elischer.org> <4134FCAE.7374599A@freebsd.org> <4134FF74.4010105@freebsd.org> <4135051E.2070007@elischer.org> In-Reply-To: <4135051E.2070007@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Andre Oppermann cc: Sam cc: Scott Long cc: freebsd-arch@freebsd.org Subject: Re: option directive and turning on AOE 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, 01 Sep 2004 00:05:13 -0000 Julian Elischer wrote: > > > Scott Long wrote: > >> Andre Oppermann wrote: >> >>> >> >> Having a single common interface is definitely attractive, but there are >> performance and locking issues with the Netgraph framework that should >> probably be resolved first. > > > both of these issues are in fact not major.. > netgraph itself has no locking issuess.. (Netgraph is the framework), > but some of teh node types have issues. Specifically, node types that > can be caled > from outside the netgraph framework, such as nodes that tie netgraph to > other subsystems > need to be worked on so that control enterring netgraph code from those > subsystems > gets an appropriate lock. This is not always needed, but every node > needs to be > examined with this in mind now that we have locking in teh rest of the > system > more worked out. > > performace.. well it can be fast. it depends on a lot of issues however.. > in particular how many locks get contentions. > >> >> >> Scott > > > My employer has done extensive profiling of packet delivery through netgraph. While the locking of the netgraph framework is definitely correct, it's not terribly efficient and leads to a good deal of latency. We are looking at various proposals on how to address this. This isn't a criticism of you or Netgraph, just a set 'real-life' observations under very high load (bridging and packet inspection on 4 GigE links simultaneously qualifies as high load =-) Scott From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 00:09:33 2004 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 6186816A4CE; Wed, 1 Sep 2004 00:09:33 +0000 (GMT) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51BB943D53; Wed, 1 Sep 2004 00:09:33 +0000 (GMT) (envelope-from peter@yahoo-inc.com) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id 376D58803; Tue, 31 Aug 2004 17:09:33 -0700 (PDT) From: Peter Wemm To: freebsd-arch@freebsd.org Date: Tue, 31 Aug 2004 17:09:32 -0700 User-Agent: KMail/1.6.2 References: <20040831203929.GB25134@odin.ac.hmc.edu> <4134FB98.6A3822BC@freebsd.org> In-Reply-To: <4134FB98.6A3822BC@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408311709.32927.peter@wemm.org> cc: Scott Long cc: Sam cc: Andre Oppermann Subject: Re: option directive and turning on AOE 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, 01 Sep 2004 00:09:33 -0000 On Tuesday 31 August 2004 03:28 pm, Andre Oppermann wrote: > Brooks Davis wrote: > > On Tue, Aug 31, 2004 at 02:27:33PM -0600, Scott Long wrote: > > > Sam wrote: > > > >I've added code to if_ethersubr.c:/ether_demux/ > > > >to queue up AoE frames as they appear. I followed > > > >suit with other protocols and included my addition > > > >inside of an #ifdef AOE. Where do I turn this on? > > > >I thought perhaps just adding an 'option AOE' to > > > >the config would do it, but it doesn't -- so clearly > > > >I don't understand how the option directive works. > > > >The config man page doesn't talk about option/device > > > >directives ... > > > > > > > >I'm still looking, but a clue would be well received. > > > > > > Did you modify /sys/conf/options to tell it about your > > > AOE option? If so, then you should have specified the name > > > of a header file that the option would be #define'd into. > > > Include that header file in if_ethersubr.c and you should > > > have no problems. > > > > > > Incidentally, this might be an area when netgraph would be > > > useful. Instead of having an AoE specific hook in the > > > stack, you could have an AoE netgraph module that uses the > > > existing netgraph hooks. It's just an idea, though. > > > > Another option might be a PFIL hook. There isn't one there now, > > but I think I've seen talk of adding one. Actually, if we did > > that, we could get most of the netgraph specific hooks out of the > > ethernet code. > > What is AoE? And what kind of Frames does it come in? ATA-over-Ethernet? http://news.gw.com/freebsd.arch/12939 (Ethernet frame type 0x88a2 apparently) -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 00:12:37 2004 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 A623316A4CE; Wed, 1 Sep 2004 00:12:37 +0000 (GMT) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9551B43D31; Wed, 1 Sep 2004 00:12:37 +0000 (GMT) (envelope-from peter@yahoo-inc.com) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id 899E68803; Tue, 31 Aug 2004 17:12:37 -0700 (PDT) From: Peter Wemm To: freebsd-arch@freebsd.org Date: Tue, 31 Aug 2004 17:12:37 -0700 User-Agent: KMail/1.6.2 References: <20040823153126.GB77326@green.homeunix.org> In-Reply-To: <20040823153126.GB77326@green.homeunix.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408311712.37221.peter@wemm.org> cc: Brian Fundakowski Feldman cc: arch@FreeBSD.org Subject: Re: erase/erase2 support 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, 01 Sep 2004 00:12:37 -0000 On Monday 23 August 2004 08:31 am, Brian Fundakowski Feldman wrote: > After jkh added basic erase/erase2 support a while back, I was > wondering why it didn't really seem to matter. It seems that just > about nothing takes into account the possibility of erase2 (VERASE2) > existing, so I took a look and found the three most noticeable > offenders (ncurses, nvi, and less) are all completely orthogonal. I > went ahead and added support in all three, but I think we need to > decide if the proper course of action right now is to get these > changes accepted and finish implementing erase2; if we don't try to > support it pervasively, I don't feel it has very good value. > > It's a no-brainer to add support to nvi, since it's essentially > "ours" now to do what we want with. How many other OSen have erase2 > support such that the ncurses and less maintainers will see the value > in it? > > See: http://green.homeunix.org/~green/erase2.patch My $0.02 worth: I'm all for it. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 00:12:37 2004 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 A623316A4CE; Wed, 1 Sep 2004 00:12:37 +0000 (GMT) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9551B43D31; Wed, 1 Sep 2004 00:12:37 +0000 (GMT) (envelope-from peter@yahoo-inc.com) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id 899E68803; Tue, 31 Aug 2004 17:12:37 -0700 (PDT) From: Peter Wemm To: freebsd-arch@freebsd.org Date: Tue, 31 Aug 2004 17:12:37 -0700 User-Agent: KMail/1.6.2 References: <20040823153126.GB77326@green.homeunix.org> In-Reply-To: <20040823153126.GB77326@green.homeunix.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408311712.37221.peter@wemm.org> cc: Brian Fundakowski Feldman cc: arch@FreeBSD.org Subject: Re: erase/erase2 support 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, 01 Sep 2004 00:12:37 -0000 On Monday 23 August 2004 08:31 am, Brian Fundakowski Feldman wrote: > After jkh added basic erase/erase2 support a while back, I was > wondering why it didn't really seem to matter. It seems that just > about nothing takes into account the possibility of erase2 (VERASE2) > existing, so I took a look and found the three most noticeable > offenders (ncurses, nvi, and less) are all completely orthogonal. I > went ahead and added support in all three, but I think we need to > decide if the proper course of action right now is to get these > changes accepted and finish implementing erase2; if we don't try to > support it pervasively, I don't feel it has very good value. > > It's a no-brainer to add support to nvi, since it's essentially > "ours" now to do what we want with. How many other OSen have erase2 > support such that the ncurses and less maintainers will see the value > in it? > > See: http://green.homeunix.org/~green/erase2.patch My $0.02 worth: I'm all for it. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 01:32:07 2004 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 7ABA016A4CE; Wed, 1 Sep 2004 01:32:07 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3526343D48; Wed, 1 Sep 2004 01:32:07 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i812Vw24010286; Tue, 31 Aug 2004 21:31:58 -0500 Date: Tue, 31 Aug 2004 21:31:58 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Peter Wemm In-Reply-To: <200408311709.32927.peter@wemm.org> Message-ID: References: <20040831203929.GB25134@odin.ac.hmc.edu> <4134FB98.6A3822BC@freebsd.org> <200408311709.32927.peter@wemm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Scott Long cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: option directive and turning on AOE 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, 01 Sep 2004 01:32:07 -0000 On Tue, 31 Aug 2004, Peter Wemm wrote: > On Tuesday 31 August 2004 03:28 pm, Andre Oppermann wrote: >> Brooks Davis wrote: >>> On Tue, Aug 31, 2004 at 02:27:33PM -0600, Scott Long wrote: >>>> Sam wrote: >>>>> I've added code to if_ethersubr.c:/ether_demux/ >>>>> to queue up AoE frames as they appear. I followed >>>>> suit with other protocols and included my addition >>>>> inside of an #ifdef AOE. Where do I turn this on? >>>>> I thought perhaps just adding an 'option AOE' to >>>>> the config would do it, but it doesn't -- so clearly >>>>> I don't understand how the option directive works. >>>>> The config man page doesn't talk about option/device >>>>> directives ... >>>>> >>>>> I'm still looking, but a clue would be well received. >>>> >>>> Did you modify /sys/conf/options to tell it about your >>>> AOE option? If so, then you should have specified the name >>>> of a header file that the option would be #define'd into. >>>> Include that header file in if_ethersubr.c and you should >>>> have no problems. >>>> >>>> Incidentally, this might be an area when netgraph would be >>>> useful. Instead of having an AoE specific hook in the >>>> stack, you could have an AoE netgraph module that uses the >>>> existing netgraph hooks. It's just an idea, though. >>> >>> Another option might be a PFIL hook. There isn't one there now, >>> but I think I've seen talk of adding one. Actually, if we did >>> that, we could get most of the netgraph specific hooks out of the >>> ethernet code. >> >> What is AoE? And what kind of Frames does it come in? > > ATA-over-Ethernet? > http://news.gw.com/freebsd.arch/12939 > (Ethernet frame type 0x88a2 apparently) > -- Yes, that is correct. It is a very simple RPC protocol for packaging up ATA commands and sending them over Ethernet to a server that will issue them to its attached device. I can supply the protocol to anyone who is interested (8 pages), just shoot me an e-mail. In case you're wondering why: http://www.coraid.com. Sam From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 05:04:01 2004 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 A995B16A4F2 for ; Wed, 1 Sep 2004 05:04:01 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B2C543D3F for ; Wed, 1 Sep 2004 05:04:01 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 17604 invoked from network); 1 Sep 2004 05:04:00 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 1 Sep 2004 05:04:00 -0000 Received: from hydrogen.funkthat.com (ytmlif@localhost.funkthat.com [127.0.0.1])i81540uU070393; Tue, 31 Aug 2004 22:04:00 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i8153xgZ070392; Tue, 31 Aug 2004 22:03:59 -0700 (PDT) Date: Tue, 31 Aug 2004 22:03:59 -0700 From: John-Mark Gurney To: Sam Message-ID: <20040901050359.GB29902@funkthat.com> Mail-Followup-To: Sam , freebsd-arch@freebsd.org References: <20040831203929.GB25134@odin.ac.hmc.edu> <4134FB98.6A3822BC@freebsd.org> <200408311709.32927.peter@wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-arch@freebsd.org Subject: Re: option directive and turning on AOE X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 05:04:02 -0000 Sam wrote this message on Tue, Aug 31, 2004 at 21:31 -0500: > >>What is AoE? And what kind of Frames does it come in? > > > >ATA-over-Ethernet? > >http://news.gw.com/freebsd.arch/12939 > >(Ethernet frame type 0x88a2 apparently) > >-- > > Yes, that is correct. It is a very simple RPC protocol > for packaging up ATA commands and sending them over > Ethernet to a server that will issue them to its > attached device. I can supply the protocol to anyone > who is interested (8 pages), just shoot me an e-mail. Is there plans for a 5.x/6.x driver for AoE? Also, are you going to be tieing into the ata frame work? or are you going to be creating your own device, and handling the ata command layer yourself? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 09:56:35 2004 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 1EAD416A4CE for ; Wed, 1 Sep 2004 09:56:35 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E7A543D60 for ; Wed, 1 Sep 2004 09:56:34 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 93898 invoked from network); 1 Sep 2004 09:54:20 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 1 Sep 2004 09:54:20 -0000 Message-ID: <41359CD2.E232327@freebsd.org> Date: Wed, 01 Sep 2004 11:56:34 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm References: <20040831203929.GB25134@odin.ac.hmc.edu> <4134FB98.6A3822BC@freebsd.org> <200408311709.32927.peter@wemm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Sam cc: Scott Long cc: freebsd-arch@freebsd.org Subject: Re: option directive and turning on AOE 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, 01 Sep 2004 09:56:35 -0000 Peter Wemm wrote: > > On Tuesday 31 August 2004 03:28 pm, Andre Oppermann wrote: > > Brooks Davis wrote: > > > On Tue, Aug 31, 2004 at 02:27:33PM -0600, Scott Long wrote: > > > > Sam wrote: > > > > >I've added code to if_ethersubr.c:/ether_demux/ > > > > >to queue up AoE frames as they appear. I followed > > > > >suit with other protocols and included my addition > > > > >inside of an #ifdef AOE. Where do I turn this on? > > > > >I thought perhaps just adding an 'option AOE' to > > > > >the config would do it, but it doesn't -- so clearly > > > > >I don't understand how the option directive works. > > > > >The config man page doesn't talk about option/device > > > > >directives ... > > > > > > > > > >I'm still looking, but a clue would be well received. > > > > > > > > Did you modify /sys/conf/options to tell it about your > > > > AOE option? If so, then you should have specified the name > > > > of a header file that the option would be #define'd into. > > > > Include that header file in if_ethersubr.c and you should > > > > have no problems. > > > > > > > > Incidentally, this might be an area when netgraph would be > > > > useful. Instead of having an AoE specific hook in the > > > > stack, you could have an AoE netgraph module that uses the > > > > existing netgraph hooks. It's just an idea, though. > > > > > > Another option might be a PFIL hook. There isn't one there now, > > > but I think I've seen talk of adding one. Actually, if we did > > > that, we could get most of the netgraph specific hooks out of the > > > ethernet code. > > > > What is AoE? And what kind of Frames does it come in? > > ATA-over-Ethernet? > http://news.gw.com/freebsd.arch/12939 > (Ethernet frame type 0x88a2 apparently) Ok, I see. However plugging in using PFIL_HOOKS is not an option here because at the moment they only work for IP packets and not for ethernet frames. -- Andre From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 14:02:36 2004 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 C7D5216A4CE for ; Wed, 1 Sep 2004 14:02:36 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89C9543D4C for ; Wed, 1 Sep 2004 14:02:36 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i81F2PeS013671; Wed, 1 Sep 2004 10:02:25 -0500 Date: Wed, 1 Sep 2004 10:02:25 -0500 (EST) From: Sam X-X-Sender: sah@athena To: John-Mark Gurney In-Reply-To: <20040901050359.GB29902@funkthat.com> Message-ID: References: <20040831203929.GB25134@odin.ac.hmc.edu> <4134FB98.6A3822BC@freebsd.org> <200408311709.32927.peter@wemm.org> <20040901050359.GB29902@funkthat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-arch@freebsd.org Subject: Re: option directive and turning on AOE 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, 01 Sep 2004 14:02:36 -0000 On Tue, 31 Aug 2004, John-Mark Gurney wrote: > Sam wrote this message on Tue, Aug 31, 2004 at 21:31 -0500: >>>> What is AoE? And what kind of Frames does it come in? >>> >>> ATA-over-Ethernet? >>> http://news.gw.com/freebsd.arch/12939 >>> (Ethernet frame type 0x88a2 apparently) >>> -- >> >> Yes, that is correct. It is a very simple RPC protocol >> for packaging up ATA commands and sending them over >> Ethernet to a server that will issue them to its >> attached device. I can supply the protocol to anyone >> who is interested (8 pages), just shoot me an e-mail. > > Is there plans for a 5.x/6.x driver for AoE? > > Also, are you going to be tieing into the ata frame work? or are you > going to be creating your own device, and handling the ata command > layer yourself? > Yes, I'm writing the 4.x driver so that it will be easy to drop in mutexes and port it to 5.x. As for -current, we'll see. I don't have a lot of cycles to spend chasing down bugs that aren't mine. I'm shooting for Darwin/OpenBSD support by the end of the year. I'm not tying into the ATA framework as there are some ATA commands which don't make sense in this context. I'm using Read Sectors, Write Sectors, and Identify Device. Next I'll look into supporting the SMART set via ioctl, but outside of that I don't think I'm missing anything. I'll admit I haven't yet examined the ata ioctl closely. Sam From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 16:33:10 2004 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 3DA7616A4CE for ; Wed, 1 Sep 2004 16:33:10 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id A172E43D53 for ; Wed, 1 Sep 2004 16:33:09 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i81HWw9D014636 for ; Wed, 1 Sep 2004 12:32:58 -0500 Date: Wed, 1 Sep 2004 12:32:58 -0500 (EST) From: Sam X-X-Sender: sah@athena To: freebsd-arch@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: disk_create and cdevsw_add 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, 01 Sep 2004 16:33:10 -0000 'lo again, kern/subr_disk.c:/^disk_create/ takes two cdevsw types, and I only vaguely understand why. Can someone explain it to me? I'm generally confused about resolving entry points into the driver. Does a block device only get an open() after registering it with disk_create? Supposing I want to set some ioctls for an aoecontrol utility (show all devices known, eg), what would aoecontrol open to ioctl? Sam From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 17:02:00 2004 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 6109916A4CE for ; Wed, 1 Sep 2004 17:02:00 +0000 (GMT) Received: from green.homeunix.org (pcp04368961pcs.nrockv01.md.comcast.net [69.140.212.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02C4843D45 for ; Wed, 1 Sep 2004 17:02:00 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i81H1xKF086046; Wed, 1 Sep 2004 13:01:59 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i81H1tnt086045; Wed, 1 Sep 2004 13:01:55 -0400 (EDT) (envelope-from green) Date: Wed, 1 Sep 2004 13:01:54 -0400 From: Brian Fundakowski Feldman To: Sam Message-ID: <20040901170154.GG45292@green.homeunix.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: freebsd-arch@freebsd.org Subject: Re: disk_create and cdevsw_add 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, 01 Sep 2004 17:02:00 -0000 On Wed, Sep 01, 2004 at 12:32:58PM -0500, Sam wrote: > 'lo again, > > kern/subr_disk.c:/^disk_create/ takes > two cdevsw types, and I only vaguely > understand why. Can someone explain it to me? > > I'm generally confused about resolving > entry points into the driver. Does a > block device only get an open() after > registering it with disk_create? > Supposing I want to set some ioctls for > an aoecontrol utility (show all devices > known, eg), what would aoecontrol open > to ioctl? Create /dev/aoectl which exists only to do global aoe things; alternately, you could use a sysctl interface, but that's not really as clean. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 18:14:56 2004 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 A847F16A4CE; Wed, 1 Sep 2004 18:14:56 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6901E43D54; Wed, 1 Sep 2004 18:14:56 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i81JEnBW001866; Wed, 1 Sep 2004 14:14:50 -0500 Date: Wed, 1 Sep 2004 14:14:49 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Brian Fundakowski Feldman In-Reply-To: <20040901170154.GG45292@green.homeunix.org> Message-ID: References: <20040901170154.GG45292@green.homeunix.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-arch@freebsd.org Subject: Re: disk_create and cdevsw_add 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, 01 Sep 2004 18:14:56 -0000 On Wed, 1 Sep 2004, Brian Fundakowski Feldman wrote: > On Wed, Sep 01, 2004 at 12:32:58PM -0500, Sam wrote: >> 'lo again, >> >> kern/subr_disk.c:/^disk_create/ takes >> two cdevsw types, and I only vaguely >> understand why. Can someone explain it to me? >> >> I'm generally confused about resolving >> entry points into the driver. Does a >> block device only get an open() after >> registering it with disk_create? >> Supposing I want to set some ioctls for >> an aoecontrol utility (show all devices >> known, eg), what would aoecontrol open >> to ioctl? > > Create /dev/aoectl which exists only to do global aoe things; alternately, > you could use a sysctl interface, but that's not really as clean. I presume this means I should do a make_dev with a minor of 0 on module load as I see is recommended in DEV_MODULE(9). Should I then assume that unit 0 is this control file and be prepared to fail any strategy calls to it? From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 18:43:19 2004 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 752A116A4CE for ; Wed, 1 Sep 2004 18:43:19 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7EE443D2F for ; Wed, 1 Sep 2004 18:43:16 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.201] ([192.168.0.201]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i81Ih0E1077939; Wed, 1 Sep 2004 12:43:01 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <413617A4.1030202@samsco.org> Date: Wed, 01 Sep 2004 12:40:36 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-arch@freebsd.org Subject: Re: disk_create and cdevsw_add 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, 01 Sep 2004 18:43:19 -0000 Sam wrote: > 'lo again, > > kern/subr_disk.c:/^disk_create/ takes > two cdevsw types, and I only vaguely > understand why. Can someone explain it to me? I'm not really clear on this myself, other than the first cdevsw contains your actual table, and the second one is a dummy that you allocate but don't actually touch. > > I'm generally confused about resolving > entry points into the driver. Does a > block device only get an open() after > registering it with disk_create? Yes. disk_create() is just a modified form of cdevsw_add(), and your cdevsw entry points are not accessable until that is called. > Supposing I want to set some ioctls for > an aoecontrol utility (show all devices > known, eg), what would aoecontrol open > to ioctl? You can either implement the ioctl handler in the same device as the AoE device, or you can create a separate control device with it's own major and minor that represents all of the AoE devices, or you can do both. You can also create a control device per AoE device, but that isn't terribly common these days and has implications when porting to 5.x and beyond. What kind of things will aoecontrol do? If it will be creating and destroying AoE device instances, then you definetly want a separate control device. You might want to look at my old 4.x RAIDFrame patches that do this. They can be found at http://people.freebsd.org/~scottl/rf Scott From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 19:34:24 2004 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 E507B16A4CE; Wed, 1 Sep 2004 19:34:23 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6F3943D46; Wed, 1 Sep 2004 19:34:23 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i81JYkxH026194; Wed, 1 Sep 2004 12:34:46 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i81JYkV2026191; Wed, 1 Sep 2004 12:34:46 -0700 Date: Wed, 1 Sep 2004 12:34:45 -0700 From: Brooks Davis To: arch@freebsd.org Message-ID: <20040901193445.GC12483@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Clx92ZfkiYIKRjnr" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: scottl@freebsd.org cc: julian@freebsd.FreeBSD.ORG Subject: if_data size issues 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, 01 Sep 2004 19:34:24 -0000 --Clx92ZfkiYIKRjnr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable My recent commit to net/if.h adding ifi_epoch to struct if_data had unintended consequences. Specifically, because of the way ifconfig uses RTM_IFINFO routing socket messages via sysctl to obtain interface information, the value of sizeof(struct if_data) must be the same in the kernel and userland. I have committed a fix from Peter which allows ifconfig to handle growth of struct if_data. Unfortunately, this does not fix old ifconfigs with new kernels. Julian raises a valid point that this can cause problems for updates over the network. At this point we disagree on the severity of the problem. He says old binaries must work with new kernels. I argue that network updates are an edge case, a critically important one, but an edge case non-the-less. Because it is an edge case, I believe it would be acceptable to require an extra step in the upgrade process. That step is simply installing a new ifconfig binary. I haven't actually done it, but by observation, Peter's fix should apply cleanly all the way back to RELENG_2_2 so we could MFC the change as far back as we like thus providing people the ability to build a new ifconfig that works on any system. Upgrades could then be handled either by doing a two-stage upgrade or by preinstalling a new ifconfig. IIRC, we have required the two-stage upgrade for some version bumps in the past. It it probably even possible, if non-trivial to add a seatbelt to installkernel to prevent installation of a new kernel without a new ifconfig. I believe that providing backwards compatibility for ifconfig would be fairly difficult as it would require the creation of new values of RTM_IFINFO and NET_RT_IFLIST, a struct oif_data, a struct oifm_msghdr, and duplication of significant code in rtsock.c. We would also have to maintain this duplicate code in the future. In practice, I think requiring this level of binary compatibility would prevent additions to struct if_data (beyond one currently unassigned u_long variable). I would appreciate other opinions on this issue as we need to either back out both of these changes or begin MFCing the ifconfig changes. The commits to add ifi_epoch were: sys/net/if.c:1.201 sys/net/if.h:89 The changes to allow ifconfig to handle different sizes for struct if_data were: sbin/ifconfig/ifconfig.c:1.107 sys/net/if.c:1.202 sys/net/if.h:90 -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --Clx92ZfkiYIKRjnr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBNiRVXY6L6fI4GtQRAq83AJ9QG9UGc12m84GEgB0O7UyO5zt9XACgm3H9 RPaxgfp+QuQlrDCdGrStMv4= =Dw7u -----END PGP SIGNATURE----- --Clx92ZfkiYIKRjnr-- From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 19:46:38 2004 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 21D8116A4CE for ; Wed, 1 Sep 2004 19:46:38 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95F0143D1F for ; Wed, 1 Sep 2004 19:46:37 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i81KkSRE002447; Wed, 1 Sep 2004 15:46:31 -0500 Date: Wed, 1 Sep 2004 15:46:28 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Scott Long In-Reply-To: <413617A4.1030202@samsco.org> Message-ID: References: <413617A4.1030202@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-arch@freebsd.org Subject: Re: disk_create and cdevsw_add 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, 01 Sep 2004 19:46:38 -0000 On Wed, 1 Sep 2004, Scott Long wrote: > Sam wrote: >> 'lo again, >> >> kern/subr_disk.c:/^disk_create/ takes >> two cdevsw types, and I only vaguely >> understand why. Can someone explain it to me? > > I'm not really clear on this myself, other than the first cdevsw > contains your actual table, and the second one is a dummy that you > allocate but don't actually touch. > >> >> I'm generally confused about resolving >> entry points into the driver. Does a >> block device only get an open() after >> registering it with disk_create? > > Yes. disk_create() is just a modified form of cdevsw_add(), and > your cdevsw entry points are not accessable until that is called. > >> Supposing I want to set some ioctls for >> an aoecontrol utility (show all devices >> known, eg), what would aoecontrol open >> to ioctl? > > You can either implement the ioctl handler in the same device as the > AoE device, or you can create a separate control device with it's own > major and minor that represents all of the AoE devices, or you can do > both. You can also create a control device per AoE device, but that > isn't terribly common these days and has implications when porting to > 5.x and beyond. > > What kind of things will aoecontrol do? If it will be creating and > destroying AoE device instances, then you definetly want a separate > control device. You might want to look at my old 4.x RAIDFrame patches > that do this. They can be found at http://people.freebsd.org/~scottl/rf Right now it would be useful to pull out the list of devices the driver knows about. In lunix I have a char driver implementing a set of files, one of which is stat: % cat /dev/etherd/stat /dev/etherd/e0.0 up /dev/etherd/e0.1 up ... So I'm thinking that here I'll set up an ioctl so aoecontrol could spit out such information. Another idea is to permit a way to restrict the interfaces acceptable to do AoE on. Currently I broadcast on every interface to find devices I can talk to; I can imagine a sysadmin might find this undesirable. The former goes away with 5.x because if it's known, it's in /dev. The latter could be enforced by making the user recompile the module, a nightmare for non-coders. A further ponderance: Each AoE device has a major,minor address. Let's call them aoemajor/aoeminor to be clear. I have a simple association between unit and aoemajor/aoeminor using a MAJPERMIN constant: unit = aoemajor * MAJPERMIN + aoeminor; This permits me to create device nodes that abstract the network. As a lunix example, /dev/etherd/e0.0 is the AoE device with aoemajor=0, aoeminor=0. In coraid's implementation, aoemajor is a shelf id and aoeminor is a slot id. So this example uses the blade in shelf 0, slot 0. The AoE protocol permits specifying the aoemajor,aoeminor address in the frame. It's possible to send out an ethernet broadcast specifying a particular aoemajor,aoeminor and have only the blade with that aoemajor,aoeminor process it. So: if I could get an open on a device I could send out a frame to see if the device is there at open time. Due to the current scheme I have to periodically send out a broadcast (with aoemajor and aoeminor unspecified) to probe the network. In a setup with a large number of blades, avoiding a periodic storm would be desirable. Any thoughts on this? Sam From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 21:09:01 2004 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 7264F16A4CE for ; Wed, 1 Sep 2004 21:09:01 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B633743D39 for ; Wed, 1 Sep 2004 21:08:58 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.201] ([192.168.0.201]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i81L8hxL078460; Wed, 1 Sep 2004 15:08:43 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <413639CA.2060400@samsco.org> Date: Wed, 01 Sep 2004 15:06:18 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam References: <413617A4.1030202@samsco.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-arch@freebsd.org Subject: Re: disk_create and cdevsw_add 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, 01 Sep 2004 21:09:01 -0000 Sam wrote: > > > On Wed, 1 Sep 2004, Scott Long wrote: > >> Sam wrote: >> >>> 'lo again, >>> >>> kern/subr_disk.c:/^disk_create/ takes >>> two cdevsw types, and I only vaguely >>> understand why. Can someone explain it to me? >> >> >> I'm not really clear on this myself, other than the first cdevsw >> contains your actual table, and the second one is a dummy that you >> allocate but don't actually touch. >> >>> >>> I'm generally confused about resolving >>> entry points into the driver. Does a >>> block device only get an open() after >>> registering it with disk_create? >> >> >> Yes. disk_create() is just a modified form of cdevsw_add(), and >> your cdevsw entry points are not accessable until that is called. >> >>> Supposing I want to set some ioctls for >>> an aoecontrol utility (show all devices >>> known, eg), what would aoecontrol open >>> to ioctl? >> >> >> You can either implement the ioctl handler in the same device as the >> AoE device, or you can create a separate control device with it's own >> major and minor that represents all of the AoE devices, or you can do >> both. You can also create a control device per AoE device, but that >> isn't terribly common these days and has implications when porting to >> 5.x and beyond. >> >> What kind of things will aoecontrol do? If it will be creating and >> destroying AoE device instances, then you definetly want a separate >> control device. You might want to look at my old 4.x RAIDFrame patches >> that do this. They can be found at http://people.freebsd.org/~scottl/rf > > > Right now it would be useful to pull out the list of devices > the driver knows about. In lunix I have a char driver implementing > a set of files, one of which is stat: > > % cat /dev/etherd/stat > /dev/etherd/e0.0 up > /dev/etherd/e0.1 up > ... > > So I'm thinking that here I'll set up an ioctl so aoecontrol > could spit out such information. You can express this via a sysctl. Think of the sysctl tree as serving a similar purpose to all of the pseudofs trees in linux that have all of their magic nodes. Of course, expressing it via an ioctl is fine, too, but sysctls are pretty easy to implement, not much harder than a proc handler in Linux. > Another idea is to permit > a way to restrict the interfaces acceptable to do AoE on. > Currently I broadcast on every interface to find devices > I can talk to; I can imagine a sysadmin might find this undesirable. > The former goes away with 5.x because if it's known, it's > in /dev. The latter could be enforced by making the user > recompile the module, a nightmare for non-coders. I'm not sure what you mean here. You're going to have an AoE 'target' and and AoE 'initiator', where the target contains the actual storage, and the initiator sends ATA-over-Eth commands to the target, right? If so, then how can the initiator know what the available targets are without doing a scan? Or are you talking about auto-configuring the target machine to have it present all locally-discovered devices as AoE targets on the network? If so, then you probably want to let the admin have as much control over this process as possible. Nothing spells 'heart-attack' as quickly as a security leak via inadvertent advertisement. > > A further ponderance: > > Each AoE device has a major,minor address. Let's call them > aoemajor/aoeminor to be clear. I have a simple association > between unit and aoemajor/aoeminor using a MAJPERMIN constant: > > unit = aoemajor * MAJPERMIN + aoeminor; > > This permits me to create device nodes that abstract the > network. As a lunix example, /dev/etherd/e0.0 is the > AoE device with aoemajor=0, aoeminor=0. In coraid's > implementation, aoemajor is a shelf id and aoeminor is > a slot id. So this example uses the blade in shelf 0, slot 0. > > The AoE protocol permits specifying the aoemajor,aoeminor > address in the frame. It's possible to send out an > ethernet broadcast specifying a particular aoemajor,aoeminor > and have only the blade with that aoemajor,aoeminor process it. > > So: if I could get an open on a device I could send out a > frame to see if the device is there at open time. Due to > the current scheme I have to periodically send out a > broadcast (with aoemajor and aoeminor unspecified) to probe > the network. In a setup with a large number of blades, > avoiding a periodic storm would be desirable. > > Any thoughts on this? > > Sam > I haven't read enough of the AoE paper to comment here, sorry. Scott From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 21:40:15 2004 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 EE25116A563; Wed, 1 Sep 2004 21:40:15 +0000 (GMT) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E8BC43D41; Wed, 1 Sep 2004 21:40:13 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id i81LeBxF017265; Wed, 1 Sep 2004 17:40:11 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040901193445.GC12483@odin.ac.hmc.edu> References: <20040901193445.GC12483@odin.ac.hmc.edu> Date: Wed, 1 Sep 2004 17:40:10 -0400 To: Brooks Davis , arch@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: scottl@freebsd.org Subject: Re: if_data size issues 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, 01 Sep 2004 21:40:16 -0000 At 12:34 PM -0700 9/1/04, Brooks Davis wrote: > >Julian raises a valid point that this can cause problems for updates >over the network. At this point we disagree on the severity of the >problem. > >He says old binaries must work with new kernels. I argue that >network updates are an edge case, a critically important one, but >an edge case non-the-less. IMO it is a more significant than just an edge-case, particularly since it includes nfs-mounted installs. But that's just MO. >Because it is an edge case, I believe it would be acceptable to >require an extra step in the upgrade process. That step is simply >installing a new ifconfig binary. My immediate reaction is that we could probably do something like this, although we would have to think a bit about the best way to get it done. We could certainly install the fix from Peter in the 4.10-stable and 4.10-errata branches, for instance. It shouldn't hurt anything to have that fix installed ASA-SufficientlyTested. >I would appreciate other opinions on this issue as we need to either >back out both of these changes or begin MFCing the ifconfig changes. Perhaps we could do something like have the update process require an "ifconfig5" (or some other unique name), and use that if it exists. Not sure that is a great idea, but it gives us an easy way to make sure the system has the right binary. 'installkernel' could just stop if the needed binary is not on the destination system. Some of the tricks I used in the 64-bTT upgrade on sparc64 might also be of interest, although I have to run right now so I can't come up with the specifics at the moment. -- 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 Wed Sep 1 21:50:14 2004 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 A22C816A4CE; Wed, 1 Sep 2004 21:50:14 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69ADD43D1D; Wed, 1 Sep 2004 21:50:14 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 0E1177A403; Wed, 1 Sep 2004 14:50:14 -0700 (PDT) Message-ID: <41364415.9040708@elischer.org> Date: Wed, 01 Sep 2004 14:50:13 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Brooks Davis References: <20040901193445.GC12483@odin.ac.hmc.edu> In-Reply-To: <20040901193445.GC12483@odin.ac.hmc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: scottl@freebsd.org cc: julian@freebsd.FreeBSD.ORG Subject: Re: if_data size issues 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, 01 Sep 2004 21:50:14 -0000 Brooks Davis wrote: >My recent commit to net/if.h adding ifi_epoch to struct if_data had >unintended consequences. Specifically, because of the way ifconfig >uses RTM_IFINFO routing socket messages via sysctl to obtain interface >information, the value of sizeof(struct if_data) must be the same in the >kernel and userland. I have committed a fix from Peter which allows >ifconfig to handle growth of struct if_data. Unfortunately, this does >not fix old ifconfigs with new kernels. > What is the reason that ifi_epoch needs to be accurate the microsecond? you have a u)long just next door that is unused that could hold a seconds count that would last at least 68 years if expressed as a count from boot time. > >Julian raises a valid point that this can cause problems for updates >over the network. At this point we disagree on the severity of the >problem. > >He says old binaries must work with new kernels. I argue that network >updates are an edge case, a critically important one, but an edge >case non-the-less. Because it is an edge case, I believe it would be >acceptable to require an extra step in the upgrade process. That step >is simply installing a new ifconfig binary. I haven't actually done >it, but by observation, Peter's fix should apply cleanly all the way >back to RELENG_2_2 so we could MFC the change as far back as we like >thus providing people the ability to build a new ifconfig that works on >any system. Upgrades could then be handled either by doing a two-stage >upgrade or by preinstalling a new ifconfig. IIRC, we have required the >two-stage upgrade for some version bumps in the past. It it probably >even possible, if non-trivial to add a seatbelt to installkernel to >prevent installation of a new kernel without a new ifconfig. > >I believe that providing backwards compatibility for ifconfig would >be fairly difficult as it would require the creation of new values of >RTM_IFINFO and NET_RT_IFLIST, a struct oif_data, a struct oifm_msghdr, >and duplication of significant code in rtsock.c. We would also have >to maintain this duplicate code in the future. In practice, I think >requiring this level of binary compatibility would prevent additions >to struct if_data (beyond one currently unassigned u_long variable). > >I would appreciate other opinions on this issue as we need to either >back out both of these changes or begin MFCing the ifconfig changes. > >The commits to add ifi_epoch were: > >sys/net/if.c:1.201 >sys/net/if.h:89 > >The changes to allow ifconfig to handle different sizes for struct >if_data were: > >sbin/ifconfig/ifconfig.c:1.107 >sys/net/if.c:1.202 >sys/net/if.h:90 > >-- Brooks > > > From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 21:56:05 2004 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 58C0816A4CF; Wed, 1 Sep 2004 21:56:05 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3149E43D41; Wed, 1 Sep 2004 21:56:05 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 241617A3E1; Wed, 1 Sep 2004 14:56:05 -0700 (PDT) Message-ID: <41364574.8070201@elischer.org> Date: Wed, 01 Sep 2004 14:56:04 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Garance A Drosihn References: <20040901193445.GC12483@odin.ac.hmc.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: scottl@freebsd.org Subject: Re: if_data size issues 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, 01 Sep 2004 21:56:05 -0000 Garance A Drosihn wrote: > At 12:34 PM -0700 9/1/04, Brooks Davis wrote: > >> >> Julian raises a valid point that this can cause problems for updates >> over the network. At this point we disagree on the severity of the >> problem. >> >> He says old binaries must work with new kernels. I argue that >> network updates are an edge case, a critically important one, but >> an edge case non-the-less. > > > IMO it is a more significant than just an edge-case, particularly > since it includes nfs-mounted installs. But that's just MO. > >> Because it is an edge case, I believe it would be acceptable to >> require an extra step in the upgrade process. That step is simply >> installing a new ifconfig binary. > > > My immediate reaction is that we could probably do something like > this, although we would have to think a bit about the best way to > get it done. We could certainly install the fix from Peter in the > 4.10-stable and 4.10-errata branches, for instance. It shouldn't > hurt anything to have that fix installed ASA-SufficientlyTested. And people upgrading from (say) 4.8 ?(we have 1000 machines on 4.8 in active production.. i.e. no patches.. no changes.. no nothing except when approved in tripplicate and with your first-born held as hostage in case they need you to back it out) > > >> I would appreciate other opinions on this issue as we need to either >> back out both of these changes or begin MFCing the ifconfig changes. > > > Perhaps we could do something like have the update process require > an "ifconfig5" (or some other unique name), and use that if it > exists. Not sure that is a great idea, but it gives us an easy > way to make sure the system has the right binary. 'installkernel' > could just stop if the needed binary is not on the destination > system. > > Some of the tricks I used in the 64-bTT upgrade on sparc64 might > also be of interest, although I have to run right now so I can't > come up with the specifics at the moment. I am not convinced we even have a problem.. why is the new field a timeval? why not a second count? there's room there for that... and we could give ourselves from 5.x to 6.x to let the 'size' field become "usual". > > From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 22:20:16 2004 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 17A8916A4CE; Wed, 1 Sep 2004 22:20:16 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF2F843D3F; Wed, 1 Sep 2004 22:20:15 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i81MKdIH017484; Wed, 1 Sep 2004 15:20:39 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i81MKdRV017483; Wed, 1 Sep 2004 15:20:39 -0700 Date: Wed, 1 Sep 2004 15:20:38 -0700 From: Brooks Davis To: Julian Elischer Message-ID: <20040901222038.GA12783@odin.ac.hmc.edu> References: <20040901193445.GC12483@odin.ac.hmc.edu> <41364415.9040708@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <41364415.9040708@elischer.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: arch@freebsd.org cc: scottl@freebsd.org cc: julian@freebsd.FreeBSD.ORG Subject: Re: if_data size issues 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, 01 Sep 2004 22:20:16 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 01, 2004 at 02:50:13PM -0700, Julian Elischer wrote: >=20 > >My recent commit to net/if.h adding ifi_epoch to struct if_data had > >unintended consequences. Specifically, because of the way ifconfig > >uses RTM_IFINFO routing socket messages via sysctl to obtain interface > >information, the value of sizeof(struct if_data) must be the same in the > >kernel and userland. I have committed a fix from Peter which allows > >ifconfig to handle growth of struct if_data. Unfortunately, this does > >not fix old ifconfigs with new kernels. >=20 > What is the reason that ifi_epoch needs to be accurate the microsecond? > you have a u)long just next door that is unused that could hold a=20 > seconds count that would last > at least 68 years if expressed as a count from boot time. It probably doesn't need to be, but that only puts off the problem by using the last remaining space. I initially used struct timeval because that's what ifi_lastchange used. If we decied to go this route, I'd be inclined to turn that variable into a time_t since it's the right width or smaller on all architectures (I believe struct padding will take care of the extra space on alpha, but we'll need to check). Bumping time_t to 64-bit on 32-bit arches will break the ABI will break due to ifi_lastchange so that's not a consideration. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD4DBQFBNks2XY6L6fI4GtQRAu2jAJURVRLTW9u5ODbbdxmDUtQ0zbJVAJ0StXxx HDy8pjG59+bWD9plZ4hK/w== =YZWG -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 23:32:54 2004 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 A84D116A4CE; Wed, 1 Sep 2004 23:32:54 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85ABA43D53; Wed, 1 Sep 2004 23:32:54 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 5F7EB7A3E1; Wed, 1 Sep 2004 16:32:54 -0700 (PDT) Message-ID: <41365C26.6050209@elischer.org> Date: Wed, 01 Sep 2004 16:32:54 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Brooks Davis References: <20040901193445.GC12483@odin.ac.hmc.edu> <41364415.9040708@elischer.org> <20040901222038.GA12783@odin.ac.hmc.edu> In-Reply-To: <20040901222038.GA12783@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: scottl@freebsd.org cc: julian@freebsd.FreeBSD.ORG Subject: Re: if_data size issues 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, 01 Sep 2004 23:32:54 -0000 Brooks Davis wrote: >On Wed, Sep 01, 2004 at 02:50:13PM -0700, Julian Elischer wrote: > > >>>My recent commit to net/if.h adding ifi_epoch to struct if_data had >>>unintended consequences. Specifically, because of the way ifconfig >>>uses RTM_IFINFO routing socket messages via sysctl to obtain interface >>>information, the value of sizeof(struct if_data) must be the same in the >>>kernel and userland. I have committed a fix from Peter which allows >>>ifconfig to handle growth of struct if_data. Unfortunately, this does >>>not fix old ifconfigs with new kernels. >>> >>> >>What is the reason that ifi_epoch needs to be accurate the microsecond? >>you have a u)long just next door that is unused that could hold a >>seconds count that would last >>at least 68 years if expressed as a count from boot time. >> >> > >It probably doesn't need to be, but that only puts off the problem by >using the last remaining space. I initially used struct timeval because >that's what ifi_lastchange used. > But if we put in the length field now in 4.x and use the u_long for time, we move a lot of our users out of the problem space.. What goes into 5.3 will basically be a the frozen ABI for the life of 5.x it can change for 6.x as long as 5.3+ and 4.11+ clients can cope. but it should be done at a time when the majority of 5.x people have moved onto the version that has the length change. >If we decied to go this route, I'd be inclined to turn that variable >into a time_t since it's the right width or smaller on all architectures >(I believe struct padding will take care of the extra space on alpha, >but we'll need to check). Bumping time_t to 64-bit on 32-bit arches >will break the ABI will break due to ifi_lastchange so that's not a >consideration. > > Whatever is practical. The BSD rule has always been: "ABI compatibility is always kept for at least 1 major revision." >-- Brooks > > > From owner-freebsd-arch@FreeBSD.ORG Thu Sep 2 00:06:16 2004 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 303DF16A4CE; Thu, 2 Sep 2004 00:06:16 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10FBE43D49; Thu, 2 Sep 2004 00:06:16 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i8206cWU012231; Wed, 1 Sep 2004 17:06:38 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8206bFZ012230; Wed, 1 Sep 2004 17:06:37 -0700 Date: Wed, 1 Sep 2004 17:06:37 -0700 From: Brooks Davis To: Julian Elischer Message-ID: <20040902000637.GA4120@odin.ac.hmc.edu> References: <20040901193445.GC12483@odin.ac.hmc.edu> <41364415.9040708@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: <41364415.9040708@elischer.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: arch@freebsd.org cc: scottl@freebsd.org cc: julian@freebsd.FreeBSD.ORG Subject: Re: if_data size issues 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, 02 Sep 2004 00:06:16 -0000 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 01, 2004 at 02:50:13PM -0700, Julian Elischer wrote: >=20 >=20 > Brooks Davis wrote: >=20 > >My recent commit to net/if.h adding ifi_epoch to struct if_data had > >unintended consequences. Specifically, because of the way ifconfig > >uses RTM_IFINFO routing socket messages via sysctl to obtain interface > >information, the value of sizeof(struct if_data) must be the same in the > >kernel and userland. I have committed a fix from Peter which allows > >ifconfig to handle growth of struct if_data. Unfortunately, this does > >not fix old ifconfigs with new kernels. >=20 > What is the reason that ifi_epoch needs to be accurate the microsecond? > you have a u)long just next door that is unused that could hold a=20 > seconds count that would last > at least 68 years if expressed as a count from boot time. I dug into the RFCs and found that ifCounterDiscontinuityTime is of type TimeStamp which is a TimeTick with the epoch of sysUpTime. The resolution of a TimeTick is 1/100s. Thus, given our choice of counters, struct timeval is most appropriate. However, in this case, meeting the letter of the rule is arguably unnecessary. Given the pain this change is causing and the limited impact of reducing the precision of ifi_epoch, I propose the following: - Back out the ifi_epoch addition. - MT5 and MT4 Peter's size change. - Turn ifi_unused into ifi_epoch. - After 5.3 is released, declare that upgrades to 6.0 from releases other then 4.x (x>=3D11) and 5.y (y>=3D3) require special handling and allow if_data to grow as demand requires. - If additional precision is deemed necessary at some future date, add a second ifi_epoch_tv. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBNmQMXY6L6fI4GtQRAn+sAJ9Jss/JgMyDzv651JUdtCWKSVHvdwCeK5eA 9PDn4A7pkl8jKzkRmoBaLQo= =M5BZ -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 2 00:14:34 2004 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 E108E16A4D1; Thu, 2 Sep 2004 00:14:34 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B151A43D2F; Thu, 2 Sep 2004 00:14:34 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id A9E3D7A3E1; Wed, 1 Sep 2004 17:14:34 -0700 (PDT) Message-ID: <413665EA.30003@elischer.org> Date: Wed, 01 Sep 2004 17:14:34 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Brooks Davis References: <20040901193445.GC12483@odin.ac.hmc.edu> <41364415.9040708@elischer.org> <20040902000637.GA4120@odin.ac.hmc.edu> In-Reply-To: <20040902000637.GA4120@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: scottl@freebsd.org cc: julian@freebsd.FreeBSD.ORG Subject: Re: if_data size issues 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, 02 Sep 2004 00:14:35 -0000 Brooks Davis wrote: >On Wed, Sep 01, 2004 at 02:50:13PM -0700, Julian Elischer wrote: > > >>Brooks Davis wrote: >> >> >> >>>My recent commit to net/if.h adding ifi_epoch to struct if_data had >>>unintended consequences. Specifically, because of the way ifconfig >>>uses RTM_IFINFO routing socket messages via sysctl to obtain interface >>>information, the value of sizeof(struct if_data) must be the same in the >>>kernel and userland. I have committed a fix from Peter which allows >>>ifconfig to handle growth of struct if_data. Unfortunately, this does >>>not fix old ifconfigs with new kernels. >>> >>> >>What is the reason that ifi_epoch needs to be accurate the microsecond? >>you have a u)long just next door that is unused that could hold a >>seconds count that would last >>at least 68 years if expressed as a count from boot time. >> >> > >I dug into the RFCs and found that ifCounterDiscontinuityTime is of type >TimeStamp which is a TimeTick with the epoch of sysUpTime. The >resolution of a TimeTick is 1/100s. Thus, given our choice of counters, >struct timeval is most appropriate. However, in this case, meeting the >letter of the rule is arguably unnecessary. > >Given the pain this change is causing and the limited impact of reducing >the precision of ifi_epoch, I propose the following: > > - Back out the ifi_epoch addition. > - MT5 and MT4 Peter's size change. > - Turn ifi_unused into ifi_epoch. > - After 5.3 is released, declare that upgrades to 6.0 from releases > other then 4.x (x>=11) and 5.y (y>=3) require special handling and > allow if_data to grow as demand requires. > - If additional precision is deemed necessary at some future date, > add a second ifi_epoch_tv. > sounds ok to me except that it should actually work from 4.x and 5.2 for a while.. say 6 months or so.. a lot of people run along the -current branch but don't upgrade every day.. after 6 months or so probably most of them will have moved onto something that can cope. Are there consumers of this info other than ifconfig? netstat? natd? route? etc? > >-- Brooks > > > From owner-freebsd-arch@FreeBSD.ORG Thu Sep 2 00:33:37 2004 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 BF4DF16A4CF; Thu, 2 Sep 2004 00:33:37 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 911C343D53; Thu, 2 Sep 2004 00:33:37 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i820Y1PC016548; Wed, 1 Sep 2004 17:34:01 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i820Y1FV016545; Wed, 1 Sep 2004 17:34:01 -0700 Date: Wed, 1 Sep 2004 17:34:01 -0700 From: Brooks Davis To: Julian Elischer Message-ID: <20040902003401.GA14224@odin.ac.hmc.edu> References: <20040901193445.GC12483@odin.ac.hmc.edu> <41364415.9040708@elischer.org> <20040902000637.GA4120@odin.ac.hmc.edu> <413665EA.30003@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline In-Reply-To: <413665EA.30003@elischer.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: arch@freebsd.org cc: scottl@freebsd.org cc: julian@freebsd.FreeBSD.ORG Subject: Re: if_data size issues 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, 02 Sep 2004 00:33:38 -0000 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 01, 2004 at 05:14:34PM -0700, Julian Elischer wrote: >=20 >=20 > Brooks Davis wrote: >=20 > >On Wed, Sep 01, 2004 at 02:50:13PM -0700, Julian Elischer wrote: > >=20 > > > >>Brooks Davis wrote: > >> > >> =20 > >> > >>>My recent commit to net/if.h adding ifi_epoch to struct if_data had > >>>unintended consequences. Specifically, because of the way ifconfig > >>>uses RTM_IFINFO routing socket messages via sysctl to obtain interface > >>>information, the value of sizeof(struct if_data) must be the same in t= he > >>>kernel and userland. I have committed a fix from Peter which allows > >>>ifconfig to handle growth of struct if_data. Unfortunately, this does > >>>not fix old ifconfigs with new kernels. > >>> =20 > >>> > >>What is the reason that ifi_epoch needs to be accurate the microsecond? > >>you have a u)long just next door that is unused that could hold a=20 > >>seconds count that would last > >>at least 68 years if expressed as a count from boot time. > >> =20 > >> > > > >I dug into the RFCs and found that ifCounterDiscontinuityTime is of type > >TimeStamp which is a TimeTick with the epoch of sysUpTime. The > >resolution of a TimeTick is 1/100s. Thus, given our choice of counters, > >struct timeval is most appropriate. However, in this case, meeting the > >letter of the rule is arguably unnecessary. > > > >Given the pain this change is causing and the limited impact of reducing > >the precision of ifi_epoch, I propose the following: > > > >- Back out the ifi_epoch addition. > >- MT5 and MT4 Peter's size change. > >- Turn ifi_unused into ifi_epoch. > >- After 5.3 is released, declare that upgrades to 6.0 from releases > > other then 4.x (x>=3D11) and 5.y (y>=3D3) require special handling and > > allow if_data to grow as demand requires. > >- If additional precision is deemed necessary at some future date, > > add a second ifi_epoch_tv. >=20 > sounds ok to me except that it should actually work from 4.x and 5.2 for= =20 > a while.. say 6 months or so.. > a lot of people run along the -current branch but don't upgrade every day= .. > after 6 months or so probably most of them will have moved onto=20 > something that can cope. The exact schedual is flexable. I just want it to be reasionable soon. 5.4-RELEASE might be a decent cut off. Then there will be 5.3, 5.4, and 4.11 as safe update points. > Are there consumers of this info other than ifconfig? netstat? natd?=20 > route? etc? There are a number of other consumers, but most of them won't matter. We will need to audit them to be sure, but so far most have been things like netstat that are unimportant. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBNmp5XY6L6fI4GtQRAgs2AKCNtnv3ds8lbW4CplsD6cJyiPrFZwCfZ2Z4 Xn5thuXpG1WmrCGLhVPRnFw= =WpHY -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 2 01:49:51 2004 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 6F92016A4D8 for ; Thu, 2 Sep 2004 01:49:51 +0000 (GMT) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BF0543D41 for ; Thu, 2 Sep 2004 01:49:51 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id i821nk4i019103; Wed, 1 Sep 2004 21:49:46 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <41364574.8070201@elischer.org> References: <20040901193445.GC12483@odin.ac.hmc.edu> <41364574.8070201@elischer.org> Date: Wed, 1 Sep 2004 21:49:45 -0400 To: Julian Elischer From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: arch@freebsd.org Subject: Re: if_data size issues 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, 02 Sep 2004 01:49:51 -0000 At 2:56 PM -0700 9/1/04, Julian Elischer wrote: >Garance A Drosihn wrote: > >>We could certainly install the fix from Peter in the >>4.10-stable and 4.10-errata branches, for instance. It shouldn't >>hurt anything to have that fix installed ASA-SufficientlyTested. > >And people upgrading from (say) 4.8 ? (we have 1000 machines on >4.8 in active production.. i.e. no patches.. no changes.. no nothing >except when approved in tripplicate and with your first-born held >as hostage in case they need you to back it out) I am just saying that we do not *hurt* anyone or anything if we add the fix to 4.10-stable and 4.10-errata. I do also realize that it does not help everyone, either. I'm just thinking we might as well get the fix in as-soon-as-practical. In a later message, Brooks Davis wrote: > >Given the pain this change is causing and the limited impact of >reducing the precision of ifi_epoch, I propose the following: > > - Back out the ifi_epoch addition. > - MT5 and MT4 Peter's size change. > - Turn ifi_unused into ifi_epoch. Given the time-constraints in that we want a solution "right now", these seem like good ideas. > - After 5.3 is released, declare that upgrades to 6.0 from releases > other then 4.x (x>=11) and 5.y (y>=3) require special handling > and allow if_data to grow as demand requires. > - If additional precision is deemed necessary at some future date, > add a second ifi_epoch_tv. We do not have to come to an agreement on these steps until we are ready to make additional changes to the structure. Something along these lines seems reasonable to me, but I don't think that we have to declare any specific timetables right now. -- 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 Thu Sep 2 05:13:48 2004 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 E092B16A4CE for ; Thu, 2 Sep 2004 05:13:48 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFA5243D41 for ; Thu, 2 Sep 2004 05:13:48 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i825EFKq025378; Wed, 1 Sep 2004 22:14:15 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i825EFF2025377; Wed, 1 Sep 2004 22:14:15 -0700 Date: Wed, 1 Sep 2004 22:14:15 -0700 From: Brooks Davis To: Garance A Drosihn Message-ID: <20040902051415.GA23926@odin.ac.hmc.edu> References: <20040901193445.GC12483@odin.ac.hmc.edu> <41364574.8070201@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: arch@freebsd.org cc: Julian Elischer Subject: Re: if_data size issues 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, 02 Sep 2004 05:13:49 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 01, 2004 at 09:49:45PM -0400, Garance A Drosihn wrote: > In a later message, Brooks Davis wrote: > > > >Given the pain this change is causing and the limited impact of > >reducing the precision of ifi_epoch, I propose the following: > > > > - Back out the ifi_epoch addition. > > - MT5 and MT4 Peter's size change. > > - Turn ifi_unused into ifi_epoch. >=20 > Given the time-constraints in that we want a solution "right now", > these seem like good ideas. I've done the backout and will submit Peter's change for MT5 on the 4th. I'll do the ifi_unused =3D> ifi_epoch change soon, but I need to verify my theory that I can use a time_t without changing the struct size. > > - After 5.3 is released, declare that upgrades to 6.0 from releases > > other then 4.x (x>=3D11) and 5.y (y>=3D3) require special handling > > and allow if_data to grow as demand requires. > > - If additional precision is deemed necessary at some future date, > > add a second ifi_epoch_tv. >=20 > We do not have to come to an agreement on these steps until we are > ready to make additional changes to the structure. Something along > these lines seems reasonable to me, but I don't think that we have > to declare any specific timetables right now. Agreed. I think it would be useful to declare upfront that should a change be made, we are willing to jetison full, offical support for upgrades to 6.0 from 5.x (x<3), but that's a minor detail. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBNqwmXY6L6fI4GtQRAvvJAKDncgVgmwatOT8hX2fguY0zKL1abQCglGvy bHqUpKJtB+BSAN3w+h3MRZ0= =Tjno -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 2 05:24:15 2004 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 516A316A4CE for ; Thu, 2 Sep 2004 05:24:15 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD69343D5C for ; Thu, 2 Sep 2004 05:24:14 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.201] ([192.168.0.201]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i825NtSR079817; Wed, 1 Sep 2004 23:23:55 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4136ADD7.6060207@samsco.org> Date: Wed, 01 Sep 2004 23:21:27 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <20040901193445.GC12483@odin.ac.hmc.edu> <41364574.8070201@elischer.org> <20040902051415.GA23926@odin.ac.hmc.edu> In-Reply-To: <20040902051415.GA23926@odin.ac.hmc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: arch@freebsd.org cc: Garance A Drosihn cc: Julian Elischer Subject: Re: if_data size issues 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, 02 Sep 2004 05:24:15 -0000 Brooks Davis wrote: > On Wed, Sep 01, 2004 at 09:49:45PM -0400, Garance A Drosihn wrote: > >>In a later message, Brooks Davis wrote: >> >>>Given the pain this change is causing and the limited impact of >>>reducing the precision of ifi_epoch, I propose the following: >>> >>>- Back out the ifi_epoch addition. >>>- MT5 and MT4 Peter's size change. >>>- Turn ifi_unused into ifi_epoch. >> >>Given the time-constraints in that we want a solution "right now", >>these seem like good ideas. > > > I've done the backout and will submit Peter's change for MT5 on the 4th. > I'll do the ifi_unused => ifi_epoch change soon, but I need to verify my > theory that I can use a time_t without changing the struct size. > > >>>- After 5.3 is released, declare that upgrades to 6.0 from releases >>> other then 4.x (x>=11) and 5.y (y>=3) require special handling >>> and allow if_data to grow as demand requires. >>>- If additional precision is deemed necessary at some future date, >>> add a second ifi_epoch_tv. >> >>We do not have to come to an agreement on these steps until we are >>ready to make additional changes to the structure. Something along >>these lines seems reasonable to me, but I don't think that we have >>to declare any specific timetables right now. > > > Agreed. I think it would be useful to declare upfront that should a > change be made, we are willing to jetison full, offical support for > upgrades to 6.0 from 5.x (x<3), but that's a minor detail. > > -- Brooks > Given that we aren't declaring 5-STABLE until 5.3, this is probably a reasonable position to take. Those early adopters of 5.0-5.2.1 should (theorectically) know what they are getting into. Scott From owner-freebsd-arch@FreeBSD.ORG Thu Sep 2 07:49:59 2004 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 891E116A4CF for ; Thu, 2 Sep 2004 07:49:59 +0000 (GMT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 295AA43D31 for ; Thu, 2 Sep 2004 07:49:59 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-69-104-103-54.dsl.snfc21.pacbell.net [69.104.103.54])i827nuH9071308; Thu, 2 Sep 2004 03:49:57 -0400 Message-ID: <4136D0A4.9000407@elischer.org> Date: Thu, 02 Sep 2004 00:49:56 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: Brooks Davis References: <20040901193445.GC12483@odin.ac.hmc.edu> <41364574.8070201@elischer.org> <20040902051415.GA23926@odin.ac.hmc.edu> In-Reply-To: <20040902051415.GA23926@odin.ac.hmc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: Garance A Drosihn Subject: Re: if_data size issues 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, 02 Sep 2004 07:49:59 -0000 Brooks Davis wrote: > On Wed, Sep 01, 2004 at 09:49:45PM -0400, Garance A Drosihn wrote: > >>In a later message, Brooks Davis wrote: >> >>>Given the pain this change is causing and the limited impact of >>>reducing the precision of ifi_epoch, I propose the following: >>> >>>- Back out the ifi_epoch addition. >>>- MT5 and MT4 Peter's size change. >>>- Turn ifi_unused into ifi_epoch. >> >>Given the time-constraints in that we want a solution "right now", >>these seem like good ideas. > > > I've done the backout and will submit Peter's change for MT5 on the 4th. > I'll do the ifi_unused => ifi_epoch change soon, but I need to verify my > theory that I can use a time_t without changing the struct size. > > >>>- After 5.3 is released, declare that upgrades to 6.0 from releases >>> other then 4.x (x>=11) and 5.y (y>=3) require special handling >>> and allow if_data to grow as demand requires. >>>- If additional precision is deemed necessary at some future date, >>> add a second ifi_epoch_tv. >> >>We do not have to come to an agreement on these steps until we are >>ready to make additional changes to the structure. Something along >>these lines seems reasonable to me, but I don't think that we have >>to declare any specific timetables right now. > > > Agreed. I think it would be useful to declare upfront that should a > change be made, we are willing to jetison full, offical support for > upgrades to 6.0 from 5.x (x<3), but that's a minor detail. yes I believe 5.2->6.0-current@X where X is a point in time a bit down the road, is not an important conversion, as very few people will be doing it... those who are running 5.2 will probably jump to either 5.3 or 6.0 within a relatively short time. those who go to 6 from 4 will probably go to 4.11 or more or 5.3+ first. > > -- Brooks > From owner-freebsd-arch@FreeBSD.ORG Thu Sep 2 08:06:20 2004 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 CB2C916A4CE; Thu, 2 Sep 2004 08:06:20 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EB0843D5E; Thu, 2 Sep 2004 08:06:20 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i8284lrR090618; Thu, 2 Sep 2004 02:04:47 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 02 Sep 2004 02:05:00 -0600 (MDT) Message-Id: <20040902.020500.26961549.imp@bsdimp.com> To: brooks@one-eyed-alien.net From: "M. Warner Losh" In-Reply-To: <20040902000637.GA4120@odin.ac.hmc.edu> References: <20040901193445.GC12483@odin.ac.hmc.edu> <41364415.9040708@elischer.org> <20040902000637.GA4120@odin.ac.hmc.edu> 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 cc: arch@freebsd.org cc: scottl@freebsd.org cc: julian@elischer.org cc: julian@freebsd.FreeBSD.ORG Subject: Re: if_data size issues 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, 02 Sep 2004 08:06:20 -0000 In message: <20040902000637.GA4120@odin.ac.hmc.edu> Brooks Davis writes: : - After 5.3 is released, declare that upgrades to 6.0 from releases : other then 4.x (x>=11) and 5.y (y>=3) require special handling and : allow if_data to grow as demand requires. There have long been plans to remove support to upgrade to 6.0 from 4.x, and I plan on moving forward with those plans after the 5.3 branch. There are a large number of hacks in place to allow upgrading all the way back to the 4.0 branch point, and these hacks have been the source of a lot of frustration and gnashing of teeth over the years. By right of conquest (eg writing the legacy library and working with both sides of this issue for litterally years), and by general consensus of the folks that do the grunt work to make it possible to upgrade, I think that desupporting upgrade to 6.0 from anything less than 5.2 (or maybe 5.1 for a time) is a reasonable path to follow. Given that the rest of the build system support for upgrades will be limited, I'm not sure the benefit of supporting the upgrade from 4.11 to 6. We never really supported upgrading from 3.5.1 to 5.0-Release, for example. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Sep 2 08:18:24 2004 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 2E41616A4D7 for ; Thu, 2 Sep 2004 08:18:24 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8D6443D31 for ; Thu, 2 Sep 2004 08:18:23 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i828Fawl090687; Thu, 2 Sep 2004 02:15:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 02 Sep 2004 02:15:49 -0600 (MDT) Message-Id: <20040902.021549.54181743.imp@bsdimp.com> To: julian@elischer.org From: "M. Warner Losh" In-Reply-To: <4136D0A4.9000407@elischer.org> References: <20040902051415.GA23926@odin.ac.hmc.edu> <4136D0A4.9000407@elischer.org> 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 cc: arch@freebsd.org cc: drosih@rpi.edu Subject: Re: if_data size issues 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, 02 Sep 2004 08:18:24 -0000 In message: <4136D0A4.9000407@elischer.org> Julian Elischer writes: : yes I believe 5.2->6.0-current@X : where X is a point in time a bit down the road, is not an important : conversion, as very few people will be doing it... : those who are running 5.2 will probably jump to either 5.3 or 6.0 : within a relatively short time. The current plans for the rest of the build system is to support 5.2 (or maybe 5.1) -> 6-CURRENT upgrades. This is a larger window than we had for the 5-current branch (which was 4 branchpoint -> current), but seems like a reasonable compromise. In the past, when core and non-core discussions of this have come up, stable branchpoint -> current was the compromise window of upgrade path that would be allowed in the tree to balance the needs of the users to upgrade, with the needs of the developers to do spring cleaning. There is much history of discussions here, and much behind the scenes negotiation to reach this compromise. : those who go to 6 from 4 will probably go to 4.11 or more or 5.3+ first. 4.x -> 6-current will need to go through 5.x (x >= 2) after 5.3 is released. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Sep 2 09:58:49 2004 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 33FE116A4CE for ; Thu, 2 Sep 2004 09:58:49 +0000 (GMT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CC7C43D1D for ; Thu, 2 Sep 2004 09:58:48 +0000 (GMT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i829wR2306550; Thu, 2 Sep 2004 11:58:27 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) i829wRI76636; Thu, 2 Sep 2004 11:58:27 +0200 Received: from beagle.kn.op.dlr.de (opkndnwsbsd178 [129.247.173.178]) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i829wMe29529; Thu, 2 Sep 2004 11:58:25 +0200 (MET DST) Date: Thu, 2 Sep 2004 11:58:22 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt@beagle.kn.op.dlr.de To: Julian Elischer In-Reply-To: <413665EA.30003@elischer.org> Message-ID: <20040902113909.M26182@beagle.kn.op.dlr.de> References: <20040901193445.GC12483@odin.ac.hmc.edu> <41364415.9040708@elischer.org> <20040902000637.GA4120@odin.ac.hmc.edu> <413665EA.30003@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: if_data size issues X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2004 09:58:49 -0000 On Wed, 1 Sep 2004, Julian Elischer wrote: JE> JE> JE>Brooks Davis wrote: JE> JE>> On Wed, Sep 01, 2004 at 02:50:13PM -0700, Julian Elischer wrote: JE>> JE>> > Brooks Davis wrote: JE>> > JE>> > JE>> > > My recent commit to net/if.h adding ifi_epoch to struct if_data had JE>> > > unintended consequences. Specifically, because of the way ifconfig JE>> > > uses RTM_IFINFO routing socket messages via sysctl to obtain interface JE>> > > information, the value of sizeof(struct if_data) must be the same in JE>> > > the JE>> > > kernel and userland. I have committed a fix from Peter which allows JE>> > > ifconfig to handle growth of struct if_data. Unfortunately, this does JE>> > > not fix old ifconfigs with new kernels. JE>> > > JE>> > What is the reason that ifi_epoch needs to be accurate the microsecond? JE>> > you have a u)long just next door that is unused that could hold a seconds JE>> > count that would last JE>> > at least 68 years if expressed as a count from boot time. JE>> > JE>> JE>> I dug into the RFCs and found that ifCounterDiscontinuityTime is of type JE>> TimeStamp which is a TimeTick with the epoch of sysUpTime. The JE>> resolution of a TimeTick is 1/100s. Thus, given our choice of counters, JE>> struct timeval is most appropriate. However, in this case, meeting the JE>> letter of the rule is arguably unnecessary. JE>> JE>> Given the pain this change is causing and the limited impact of reducing JE>> the precision of ifi_epoch, I propose the following: JE>> JE>> - Back out the ifi_epoch addition. JE>> - MT5 and MT4 Peter's size change. JE>> - Turn ifi_unused into ifi_epoch. JE>> - After 5.3 is released, declare that upgrades to 6.0 from releases JE>> other then 4.x (x>=11) and 5.y (y>=3) require special handling and JE>> allow if_data to grow as demand requires. JE>> - If additional precision is deemed necessary at some future date, JE>> add a second ifi_epoch_tv. JE>> JE> JE>sounds ok to me except that it should actually work from 4.x and 5.2 for a JE>while.. say 6 months or so.. JE>a lot of people run along the -current branch but don't upgrade every day.. JE>after 6 months or so probably most of them will have moved onto something JE>that can cope. JE> JE>Are there consumers of this info other than ifconfig? netstat? natd? route? JE>etc? The SNMP MIB-II module would happily use it I suppose (contrib/bsnmp/snmp_mibII). harti From owner-freebsd-arch@FreeBSD.ORG Thu Sep 2 17:23:16 2004 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 535D916A4D0; Thu, 2 Sep 2004 17:23:16 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3176243D2D; Thu, 2 Sep 2004 17:23:16 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i82HNkSH020920; Thu, 2 Sep 2004 10:23:46 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i82HNjrL020919; Thu, 2 Sep 2004 10:23:45 -0700 Date: Thu, 2 Sep 2004 10:23:45 -0700 From: Brooks Davis To: "M. Warner Losh" Message-ID: <20040902172345.GB3801@odin.ac.hmc.edu> References: <20040901193445.GC12483@odin.ac.hmc.edu> <41364415.9040708@elischer.org> <20040902000637.GA4120@odin.ac.hmc.edu> <20040902.020500.26961549.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="98e8jtXdkpgskNou" Content-Disposition: inline In-Reply-To: <20040902.020500.26961549.imp@bsdimp.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: arch@freebsd.org cc: scottl@freebsd.org cc: julian@elischer.org cc: julian@freebsd.FreeBSD.ORG Subject: Re: if_data size issues 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, 02 Sep 2004 17:23:16 -0000 --98e8jtXdkpgskNou Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 02, 2004 at 02:05:00AM -0600, M. Warner Losh wrote: > In message: <20040902000637.GA4120@odin.ac.hmc.edu> > Brooks Davis writes: > : - After 5.3 is released, declare that upgrades to 6.0 from releases > : other then 4.x (x>=3D11) and 5.y (y>=3D3) require special handling a= nd > : allow if_data to grow as demand requires. >=20 > There have long been plans to remove support to upgrade to 6.0 from > 4.x, and I plan on moving forward with those plans after the 5.3 > branch. There are a large number of hacks in place to allow upgrading > all the way back to the 4.0 branch point, and these hacks have been > the source of a lot of frustration and gnashing of teeth over the > years. By right of conquest (eg writing the legacy library and > working with both sides of this issue for litterally years), and by > general consensus of the folks that do the grunt work to make it > possible to upgrade, I think that desupporting upgrade to 6.0 from > anything less than 5.2 (or maybe 5.1 for a time) is a reasonable path > to follow. Given that the rest of the build system support for > upgrades will be limited, I'm not sure the benefit of supporting the > upgrade from 4.11 to 6. We never really supported upgrading from > 3.5.1 to 5.0-Release, for example. Note that a change of the size of struct if_data doesn't totally break ugprades from old versions, it just requires a bit of pre-planning if your upgrade process requires ifconfig or if you need the ability to roll back. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --98e8jtXdkpgskNou Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBN1cgXY6L6fI4GtQRAnhZAJ9L+GVTBZ+6cPVQW5zdONmIaVQYzQCfXV7b tsZGHfaaev3iVN/bwbDNGSU= =PFLS -----END PGP SIGNATURE----- --98e8jtXdkpgskNou-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 2 19:12:18 2004 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 CC22516A4CE; Thu, 2 Sep 2004 19:12:18 +0000 (GMT) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id B29AD43D31; Thu, 2 Sep 2004 19:12:18 +0000 (GMT) (envelope-from peter@yahoo-inc.com) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id A3EB88803; Thu, 2 Sep 2004 12:12:18 -0700 (PDT) From: Peter Wemm To: freebsd-arch@freebsd.org Date: Thu, 2 Sep 2004 12:12:18 -0700 User-Agent: KMail/1.6.2 References: <20040901193445.GC12483@odin.ac.hmc.edu> <20040902051415.GA23926@odin.ac.hmc.edu> In-Reply-To: <20040902051415.GA23926@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409021212.18344.peter@wemm.org> cc: arch@freebsd.org cc: Garance A Drosihn cc: Julian Elischer Subject: Re: if_data size issues 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, 02 Sep 2004 19:12:19 -0000 On Wednesday 01 September 2004 10:14 pm, Brooks Davis wrote: > On Wed, Sep 01, 2004 at 09:49:45PM -0400, Garance A Drosihn wrote: > > In a later message, Brooks Davis wrote: > > >Given the pain this change is causing and the limited impact of > > >reducing the precision of ifi_epoch, I propose the following: > > > > > > - Back out the ifi_epoch addition. > > > - MT5 and MT4 Peter's size change. > > > - Turn ifi_unused into ifi_epoch. > > > > Given the time-constraints in that we want a solution "right now", > > these seem like good ideas. > > I've done the backout and will submit Peter's change for MT5 on the > 4th. I'll do the ifi_unused => ifi_epoch change soon, but I need to > verify my theory that I can use a time_t without changing the struct > size. There is only one minor gotcha on this one.. Alpha. sizeof(time_t) == sizeof(u_long) on all our platforms except alpha. (note I said sizeof, not typeof). An additional pad would be needed on alpha to compensate. eg: u_long ifi_hwassist; /* HW offload capabilities */ time_t ifi_epoch; #ifdef __alpha__ u_int ifi_timepad; /* time_t is int, not long on alpha */ #endif struct timeval ifi_lastchange; /* time of last administrative change */ Actually, now that I look at it.. timeval begins with a 'long', so it'll be aligned correctly on alpha anyway, even without adding ifi_timepad. I personally like documenting hidden padding when there are abi issues though. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-arch@FreeBSD.ORG Thu Sep 2 19:12:18 2004 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 CC22516A4CE; Thu, 2 Sep 2004 19:12:18 +0000 (GMT) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id B29AD43D31; Thu, 2 Sep 2004 19:12:18 +0000 (GMT) (envelope-from peter@yahoo-inc.com) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id A3EB88803; Thu, 2 Sep 2004 12:12:18 -0700 (PDT) From: Peter Wemm To: freebsd-arch@freebsd.org Date: Thu, 2 Sep 2004 12:12:18 -0700 User-Agent: KMail/1.6.2 References: <20040901193445.GC12483@odin.ac.hmc.edu> <20040902051415.GA23926@odin.ac.hmc.edu> In-Reply-To: <20040902051415.GA23926@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409021212.18344.peter@wemm.org> cc: arch@freebsd.org cc: Garance A Drosihn cc: Julian Elischer Subject: Re: if_data size issues 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, 02 Sep 2004 19:12:19 -0000 On Wednesday 01 September 2004 10:14 pm, Brooks Davis wrote: > On Wed, Sep 01, 2004 at 09:49:45PM -0400, Garance A Drosihn wrote: > > In a later message, Brooks Davis wrote: > > >Given the pain this change is causing and the limited impact of > > >reducing the precision of ifi_epoch, I propose the following: > > > > > > - Back out the ifi_epoch addition. > > > - MT5 and MT4 Peter's size change. > > > - Turn ifi_unused into ifi_epoch. > > > > Given the time-constraints in that we want a solution "right now", > > these seem like good ideas. > > I've done the backout and will submit Peter's change for MT5 on the > 4th. I'll do the ifi_unused => ifi_epoch change soon, but I need to > verify my theory that I can use a time_t without changing the struct > size. There is only one minor gotcha on this one.. Alpha. sizeof(time_t) == sizeof(u_long) on all our platforms except alpha. (note I said sizeof, not typeof). An additional pad would be needed on alpha to compensate. eg: u_long ifi_hwassist; /* HW offload capabilities */ time_t ifi_epoch; #ifdef __alpha__ u_int ifi_timepad; /* time_t is int, not long on alpha */ #endif struct timeval ifi_lastchange; /* time of last administrative change */ Actually, now that I look at it.. timeval begins with a 'long', so it'll be aligned correctly on alpha anyway, even without adding ifi_timepad. I personally like documenting hidden padding when there are abi issues though. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-arch@FreeBSD.ORG Thu Sep 2 19:20:08 2004 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 6859A16A4CE; Thu, 2 Sep 2004 19:20:08 +0000 (GMT) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 521A743D1F; Thu, 2 Sep 2004 19:20:08 +0000 (GMT) (envelope-from peter@yahoo-inc.com) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id E8B76881F; Thu, 2 Sep 2004 12:20:07 -0700 (PDT) From: Peter Wemm To: freebsd-arch@freebsd.org Date: Thu, 2 Sep 2004 12:20:07 -0700 User-Agent: KMail/1.6.2 References: <20040901193445.GC12483@odin.ac.hmc.edu> <20040902.020500.26961549.imp@bsdimp.com> <20040902172345.GB3801@odin.ac.hmc.edu> In-Reply-To: <20040902172345.GB3801@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409021220.07611.peter@wemm.org> cc: scottl@freebsd.org cc: julian@freebsd.FreeBSD.ORG cc: arch@freebsd.org cc: julian@elischer.org Subject: Re: if_data size issues 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, 02 Sep 2004 19:20:08 -0000 On Thursday 02 September 2004 10:23 am, Brooks Davis wrote: > On Thu, Sep 02, 2004 at 02:05:00AM -0600, M. Warner Losh wrote: > > In message: <20040902000637.GA4120@odin.ac.hmc.edu> > > > > Brooks Davis writes: > > : - After 5.3 is released, declare that upgrades to 6.0 from > > : releases other then 4.x (x>=11) and 5.y (y>=3) require special > > : handling and allow if_data to grow as demand requires. > > > > There have long been plans to remove support to upgrade to 6.0 from > > 4.x, and I plan on moving forward with those plans after the 5.3 > > branch. There are a large number of hacks in place to allow > > upgrading all the way back to the 4.0 branch point, and these hacks > > have been the source of a lot of frustration and gnashing of teeth > > over the years. By right of conquest (eg writing the legacy > > library and working with both sides of this issue for litterally > > years), and by general consensus of the folks that do the grunt > > work to make it possible to upgrade, I think that desupporting > > upgrade to 6.0 from anything less than 5.2 (or maybe 5.1 for a > > time) is a reasonable path to follow. Given that the rest of the > > build system support for upgrades will be limited, I'm not sure the > > benefit of supporting the upgrade from 4.11 to 6. We never really > > supported upgrading from 3.5.1 to 5.0-Release, for example. > > Note that a change of the size of struct if_data doesn't totally > break ugprades from old versions, it just requires a bit of > pre-planning if your upgrade process requires ifconfig or if you need > the ability to roll back. Yes, thanks for the perspective reminder. As you say, this is a boot issue, not a build issue. We normally "just deal with it" for this sort of thing (ps, netstat, etc blowing up). But ifconfig is a bit more sensitive than ps. ifconfig can easily stop your system booting while ps is just cosmetic. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-arch@FreeBSD.ORG Thu Sep 2 19:20:08 2004 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 6859A16A4CE; Thu, 2 Sep 2004 19:20:08 +0000 (GMT) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 521A743D1F; Thu, 2 Sep 2004 19:20:08 +0000 (GMT) (envelope-from peter@yahoo-inc.com) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id E8B76881F; Thu, 2 Sep 2004 12:20:07 -0700 (PDT) From: Peter Wemm To: freebsd-arch@freebsd.org Date: Thu, 2 Sep 2004 12:20:07 -0700 User-Agent: KMail/1.6.2 References: <20040901193445.GC12483@odin.ac.hmc.edu> <20040902.020500.26961549.imp@bsdimp.com> <20040902172345.GB3801@odin.ac.hmc.edu> In-Reply-To: <20040902172345.GB3801@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409021220.07611.peter@wemm.org> cc: scottl@freebsd.org cc: julian@freebsd.FreeBSD.ORG cc: arch@freebsd.org cc: julian@elischer.org Subject: Re: if_data size issues 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, 02 Sep 2004 19:20:08 -0000 On Thursday 02 September 2004 10:23 am, Brooks Davis wrote: > On Thu, Sep 02, 2004 at 02:05:00AM -0600, M. Warner Losh wrote: > > In message: <20040902000637.GA4120@odin.ac.hmc.edu> > > > > Brooks Davis writes: > > : - After 5.3 is released, declare that upgrades to 6.0 from > > : releases other then 4.x (x>=11) and 5.y (y>=3) require special > > : handling and allow if_data to grow as demand requires. > > > > There have long been plans to remove support to upgrade to 6.0 from > > 4.x, and I plan on moving forward with those plans after the 5.3 > > branch. There are a large number of hacks in place to allow > > upgrading all the way back to the 4.0 branch point, and these hacks > > have been the source of a lot of frustration and gnashing of teeth > > over the years. By right of conquest (eg writing the legacy > > library and working with both sides of this issue for litterally > > years), and by general consensus of the folks that do the grunt > > work to make it possible to upgrade, I think that desupporting > > upgrade to 6.0 from anything less than 5.2 (or maybe 5.1 for a > > time) is a reasonable path to follow. Given that the rest of the > > build system support for upgrades will be limited, I'm not sure the > > benefit of supporting the upgrade from 4.11 to 6. We never really > > supported upgrading from 3.5.1 to 5.0-Release, for example. > > Note that a change of the size of struct if_data doesn't totally > break ugprades from old versions, it just requires a bit of > pre-planning if your upgrade process requires ifconfig or if you need > the ability to roll back. Yes, thanks for the perspective reminder. As you say, this is a boot issue, not a build issue. We normally "just deal with it" for this sort of thing (ps, netstat, etc blowing up). But ifconfig is a bit more sensitive than ps. ifconfig can easily stop your system booting while ps is just cosmetic. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-arch@FreeBSD.ORG Thu Sep 2 19:51:03 2004 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 E2B8E16A4CF; Thu, 2 Sep 2004 19:51:03 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEAA443D5E; Thu, 2 Sep 2004 19:51:03 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i82JpWVl011982; Thu, 2 Sep 2004 12:51:32 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i82JpWTw011981; Thu, 2 Sep 2004 12:51:32 -0700 Date: Thu, 2 Sep 2004 12:51:32 -0700 From: Brooks Davis To: Peter Wemm Message-ID: <20040902195132.GA10756@odin.ac.hmc.edu> References: <20040901193445.GC12483@odin.ac.hmc.edu> <20040902051415.GA23926@odin.ac.hmc.edu> <200409021212.18344.peter@wemm.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <200409021212.18344.peter@wemm.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: arch@freebsd.org cc: Garance A Drosihn cc: Julian Elischer cc: freebsd-arch@freebsd.org Subject: Re: if_data size issues 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, 02 Sep 2004 19:51:04 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 02, 2004 at 12:12:18PM -0700, Peter Wemm wrote: > On Wednesday 01 September 2004 10:14 pm, Brooks Davis wrote: > > On Wed, Sep 01, 2004 at 09:49:45PM -0400, Garance A Drosihn wrote: > > > In a later message, Brooks Davis wrote: > > > >Given the pain this change is causing and the limited impact of > > > >reducing the precision of ifi_epoch, I propose the following: > > > > > > > > - Back out the ifi_epoch addition. > > > > - MT5 and MT4 Peter's size change. > > > > - Turn ifi_unused into ifi_epoch. > > > > > > Given the time-constraints in that we want a solution "right now", > > > these seem like good ideas. > > > > I've done the backout and will submit Peter's change for MT5 on the > > 4th. I'll do the ifi_unused =3D> ifi_epoch change soon, but I need to > > verify my theory that I can use a time_t without changing the struct > > size. >=20 > There is only one minor gotcha on this one.. Alpha. sizeof(time_t) =3D= =3D=20 > sizeof(u_long) on all our platforms except alpha. (note I said sizeof,= =20 > not typeof). Yup I noticed that. > An additional pad would be needed on alpha to compensate. eg: > u_long ifi_hwassist; /* HW offload capabilities */ > time_t ifi_epoch; > #ifdef __alpha__ > u_int ifi_timepad; /* time_t is int, not long on alpha */ > #endif > struct timeval ifi_lastchange; /* time of last administrative=20 > change */ >=20 > Actually, now that I look at it.. timeval begins with a 'long', so it'll= =20 > be aligned correctly on alpha anyway, even without adding ifi_timepad. = =20 > I personally like documenting hidden padding when there are abi issues=20 > though. I wrote a little test program and yes, alpha keeps the size the same due to padding (I thought it would, but figured the two minutes required to check were worth it. :-). I will use the explict pad though. That will hopefully keep people from being confused in the future. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBN3nEXY6L6fI4GtQRAlZaAKDPSLnZRIakXTAzJ5M9LK7iurUnZgCfTLiY HFRww+3S5GdCOzEpV5uwZoY= =GIam -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 2 19:51:03 2004 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 E2B8E16A4CF; Thu, 2 Sep 2004 19:51:03 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEAA443D5E; Thu, 2 Sep 2004 19:51:03 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i82JpWVl011982; Thu, 2 Sep 2004 12:51:32 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i82JpWTw011981; Thu, 2 Sep 2004 12:51:32 -0700 Date: Thu, 2 Sep 2004 12:51:32 -0700 From: Brooks Davis To: Peter Wemm Message-ID: <20040902195132.GA10756@odin.ac.hmc.edu> References: <20040901193445.GC12483@odin.ac.hmc.edu> <20040902051415.GA23926@odin.ac.hmc.edu> <200409021212.18344.peter@wemm.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <200409021212.18344.peter@wemm.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: arch@freebsd.org cc: Garance A Drosihn cc: Julian Elischer cc: freebsd-arch@freebsd.org Subject: Re: if_data size issues 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, 02 Sep 2004 19:51:04 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 02, 2004 at 12:12:18PM -0700, Peter Wemm wrote: > On Wednesday 01 September 2004 10:14 pm, Brooks Davis wrote: > > On Wed, Sep 01, 2004 at 09:49:45PM -0400, Garance A Drosihn wrote: > > > In a later message, Brooks Davis wrote: > > > >Given the pain this change is causing and the limited impact of > > > >reducing the precision of ifi_epoch, I propose the following: > > > > > > > > - Back out the ifi_epoch addition. > > > > - MT5 and MT4 Peter's size change. > > > > - Turn ifi_unused into ifi_epoch. > > > > > > Given the time-constraints in that we want a solution "right now", > > > these seem like good ideas. > > > > I've done the backout and will submit Peter's change for MT5 on the > > 4th. I'll do the ifi_unused =3D> ifi_epoch change soon, but I need to > > verify my theory that I can use a time_t without changing the struct > > size. >=20 > There is only one minor gotcha on this one.. Alpha. sizeof(time_t) =3D= =3D=20 > sizeof(u_long) on all our platforms except alpha. (note I said sizeof,= =20 > not typeof). Yup I noticed that. > An additional pad would be needed on alpha to compensate. eg: > u_long ifi_hwassist; /* HW offload capabilities */ > time_t ifi_epoch; > #ifdef __alpha__ > u_int ifi_timepad; /* time_t is int, not long on alpha */ > #endif > struct timeval ifi_lastchange; /* time of last administrative=20 > change */ >=20 > Actually, now that I look at it.. timeval begins with a 'long', so it'll= =20 > be aligned correctly on alpha anyway, even without adding ifi_timepad. = =20 > I personally like documenting hidden padding when there are abi issues=20 > though. I wrote a little test program and yes, alpha keeps the size the same due to padding (I thought it would, but figured the two minutes required to check were worth it. :-). I will use the explict pad though. That will hopefully keep people from being confused in the future. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBN3nEXY6L6fI4GtQRAlZaAKDPSLnZRIakXTAzJ5M9LK7iurUnZgCfTLiY HFRww+3S5GdCOzEpV5uwZoY= =GIam -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From owner-freebsd-arch@FreeBSD.ORG Fri Sep 3 05:06:19 2004 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 CB70D16A4CE for ; Fri, 3 Sep 2004 05:06:19 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A3CB43D6D for ; Fri, 3 Sep 2004 05:06:19 +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 CEF7750B5D for ; Fri, 3 Sep 2004 14:06:17 +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 4771E50B78 for ; Fri, 3 Sep 2004 14:06:16 +0900 (JST) Date: Fri, 03 Sep 2004 14:06:16 +0900 Message-ID: <7m3c20x7p3.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: arch@FreeBSD.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) 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: abort(3) in libc/db/btree/bt_split.c 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, 03 Sep 2004 05:06:19 -0000 I found there are abort(3)s in bt_split.c (found by ruby18/portupgrade dumping core). It seems flags in data structure which ruby uses are corrupted, but abort(3) is not helpful for usual users. So I think __bt_split() (and other functions in this file) should return RET_ERROR, or write a dying message before abort(3). I'd like to try to code returing RET_ERROR (with internal tree cleanup) if that is the way to go. -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-arch@FreeBSD.ORG Fri Sep 3 17:03:47 2004 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 6B41016A4CE for ; Fri, 3 Sep 2004 17:03:47 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0556843D31 for ; Fri, 3 Sep 2004 17:03:47 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i83I3YbN016696 for ; Fri, 3 Sep 2004 13:03:34 -0500 Date: Fri, 3 Sep 2004 13:03:34 -0500 (EST) From: Sam X-X-Sender: sah@athena To: freebsd-arch@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: mknod minors 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, 03 Sep 2004 17:03:47 -0000 OK, I understand the layout of the minor number according to sys/disklabel.h, but what's with the numbering scheme here? freebsd# ls -l /dev/ad0* crw-r----- 2 root operator 116, 0x00010002 Nov 17 2002 /dev/ad0 crw-r----- 2 root operator 116, 0 Nov 17 2002 /dev/ad0a crw-r----- 2 root operator 116, 1 Nov 17 2002 /dev/ad0b crw-r----- 2 root operator 116, 2 Nov 17 2002 /dev/ad0c crw-r----- 2 root operator 116, 3 Nov 17 2002 /dev/ad0d crw-r----- 2 root operator 116, 4 Nov 17 2002 /dev/ad0e crw-r----- 2 root operator 116, 5 Nov 17 2002 /dev/ad0f crw-r----- 2 root operator 116, 6 Nov 17 2002 /dev/ad0g crw-r----- 2 root operator 116, 7 Nov 17 2002 /dev/ad0h crw-r----- 2 root operator 116, 0x00020002 Nov 17 2002 /dev/ad0s1 crw-r----- 2 root operator 116, 0x00020000 Nov 17 2002 /dev/ad0s1a crw-r----- 2 root operator 116, 0x00020001 Nov 17 2002 /dev/ad0s1b crw-r----- 2 root operator 116, 0x00020002 Nov 17 2002 /dev/ad0s1c crw-r----- 2 root operator 116, 0x00020003 Nov 17 2002 /dev/ad0s1d crw-r----- 2 root operator 116, 0x00020004 Nov 17 2002 /dev/ad0s1e crw-r----- 2 root operator 116, 0x00020005 Nov 17 2002 /dev/ad0s1f crw-r----- 2 root operator 116, 0x00020006 Nov 17 2002 /dev/ad0s1g crw-r----- 2 root operator 116, 0x00020007 Nov 17 2002 /dev/ad0s1h crw-r----- 2 root operator 116, 0x00030002 Nov 17 2002 /dev/ad0s2 crw-r----- 2 root operator 116, 0x00040002 Nov 17 2002 /dev/ad0s3 crw-r----- 2 root operator 116, 0x00050002 Nov 17 2002 /dev/ad0s4 Why is the whole disk slice 1, but partitions within it are slice 0? Why isn't the whole disk slice 0 and slice 1 is ... slice 1 (ad0s1)? What makes ad0s2 be partition 3? Am I reading this right? Sam From owner-freebsd-arch@FreeBSD.ORG Fri Sep 3 18:38:42 2004 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 A03CB16A4CE for ; Fri, 3 Sep 2004 18:38:42 +0000 (GMT) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 779B043D2F for ; Fri, 3 Sep 2004 18:38:41 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from [IPv6:::1] (schlepper [212.12.50.230]) by schlepper.zs64.net (8.12.11/8.11.1) with ESMTP id i83IcdJ1067985; Fri, 3 Sep 2004 20:38:39 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <794C3F76-FDD8-11D8-A251-000A95C893E4@lassitu.de> Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Fri, 3 Sep 2004 20:38:39 +0200 To: Sam X-Mailer: Apple Mail (2.619) cc: freebsd-arch@freebsd.org Subject: Re: mknod minors 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, 03 Sep 2004 18:38:42 -0000 Am 03.09.2004 um 20:03 schrieb Sam: > OK, I understand the layout of the minor number > according to sys/disklabel.h, but what's with > the numbering scheme here? > > freebsd# ls -l /dev/ad0* > crw-r----- 2 root operator 116, 0x00010002 Nov 17 2002 /dev/ad0 > crw-r----- 2 root operator 116, 0 Nov 17 2002 /dev/ad0a > crw-r----- 2 root operator 116, 1 Nov 17 2002 /dev/ad0b > crw-r----- 2 root operator 116, 2 Nov 17 2002 /dev/ad0c > crw-r----- 2 root operator 116, 3 Nov 17 2002 /dev/ad0d > crw-r----- 2 root operator 116, 4 Nov 17 2002 /dev/ad0e > crw-r----- 2 root operator 116, 5 Nov 17 2002 /dev/ad0f > crw-r----- 2 root operator 116, 6 Nov 17 2002 /dev/ad0g > crw-r----- 2 root operator 116, 7 Nov 17 2002 /dev/ad0h > crw-r----- 2 root operator 116, 0x00020002 Nov 17 2002 /dev/ad0s1 > crw-r----- 2 root operator 116, 0x00020000 Nov 17 2002 /dev/ad0s1a > crw-r----- 2 root operator 116, 0x00020001 Nov 17 2002 /dev/ad0s1b > crw-r----- 2 root operator 116, 0x00020002 Nov 17 2002 /dev/ad0s1c > crw-r----- 2 root operator 116, 0x00020003 Nov 17 2002 /dev/ad0s1d > crw-r----- 2 root operator 116, 0x00020004 Nov 17 2002 /dev/ad0s1e > crw-r----- 2 root operator 116, 0x00020005 Nov 17 2002 /dev/ad0s1f > crw-r----- 2 root operator 116, 0x00020006 Nov 17 2002 /dev/ad0s1g > crw-r----- 2 root operator 116, 0x00020007 Nov 17 2002 /dev/ad0s1h > crw-r----- 2 root operator 116, 0x00030002 Nov 17 2002 /dev/ad0s2 > crw-r----- 2 root operator 116, 0x00040002 Nov 17 2002 /dev/ad0s3 > crw-r----- 2 root operator 116, 0x00050002 Nov 17 2002 /dev/ad0s4 > > Why is the whole disk slice 1, but partitions within it are > slice 0? Why isn't the whole disk slice 0 and slice 1 > is ... slice 1 (ad0s1)? What makes ad0s2 be partition 3? I'm by no means an expert in this field, just a long-time user, but I'll try to give some answers: ad0[a-z] are the "compatibility" partitions. I'd guess that that's the reason they come first, number-wise. The compatibility partitions will access the first FreeBSD slice on the disk, if any. They have been depracated long ago (I believe somewhere around 3-current), and I'd think you do not need to provide them, since programs having distict ideas about what disk devices should be called should long be gone. Since the MS-DOS partitioning scheme does not provide an entry for the entire disk (like the BSD c partition would), it has to go somewhere; using another "slice" number-wise seems logical. And that makes ad0s2 the "third slice" (and so on). Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-arch@FreeBSD.ORG Sat Sep 4 05:13:38 2004 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 08C1716A4CE for ; Sat, 4 Sep 2004 05:13:38 +0000 (GMT) Received: from green.homeunix.org (pcp04368961pcs.nrockv01.md.comcast.net [69.140.212.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8700B43D31 for ; Sat, 4 Sep 2004 05:13:37 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i845DV7x035299; Sat, 4 Sep 2004 01:13:36 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i845DUtk035298; Sat, 4 Sep 2004 01:13:30 -0400 (EDT) (envelope-from green) Date: Sat, 4 Sep 2004 01:13:30 -0400 From: Brian Fundakowski Feldman To: Jun Kuriyama Message-ID: <20040904051330.GH45292@green.homeunix.org> References: <7m3c20x7p3.wl@black.imgsrc.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7m3c20x7p3.wl@black.imgsrc.co.jp> User-Agent: Mutt/1.5.6i cc: arch@FreeBSD.org Subject: Re: abort(3) in libc/db/btree/bt_split.c 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, 04 Sep 2004 05:13:38 -0000 On Fri, Sep 03, 2004 at 02:06:16PM +0900, Jun Kuriyama wrote: > > I found there are abort(3)s in bt_split.c (found by ruby18/portupgrade > dumping core). > > It seems flags in data structure which ruby uses are corrupted, but > abort(3) is not helpful for usual users. > > So I think __bt_split() (and other functions in this file) should > return RET_ERROR, or write a dying message before abort(3). > > I'd like to try to code returing RET_ERROR (with internal tree > cleanup) if that is the way to go. Have you checked if they were fixed in subsequent SleepyCat DB 1.x releases to return error instead of dump core, so we could use a vendor fix? -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-arch@FreeBSD.ORG Sat Sep 4 17:38:19 2004 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 A192316A4CE for ; Sat, 4 Sep 2004 17:38:19 +0000 (GMT) Received: from rly-ip03.mx.aol.com (rly-ip03.mx.aol.com [64.12.138.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3376443D48 for ; Sat, 4 Sep 2004 17:38:19 +0000 (GMT) (envelope-from hdteacher@usadatanet.com) Received: from smtp-mtc07.proxy.aol.com (smtp-mtc07.proxy.aol.com [64.12.118.20]) by rly-ip03.mx.aol.com (v98.19) with ESMTP id RELAYIN9-a4139fd4816c; Sat, 04 Sep 2004 13:37:12 -0400 Received: from [127.0.0.1] (ACA934DE.ipt.aol.com [172.169.52.222]) i84Hc7bd008176 for ; Sat, 4 Sep 2004 13:38:10 -0400 Message-ID: <4139FD7A.7040501@usadatanet.com> Date: Sat, 04 Sep 2004 10:38:02 -0700 From: "Richmond J. Platz" Organization: The Happy Drummer User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org Content-Type: multipart/mixed; boundary="------------060106090907020200010205" X-Scanned-By: MIMEDefang 2.43 X-Apparently-From: Platzhappyd@cs.com X-AOL-IP: 64.12.118.20 X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Free BSD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hdteacher@usadatanet.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2004 17:38:19 -0000 This is a multi-part message in MIME format. --------------060106090907020200010205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Is Thjis available for Win XP Pro? IF so,What is its Size? -- --------------060106090907020200010205-- From owner-freebsd-arch@FreeBSD.ORG Sat Sep 4 20:56:56 2004 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 3EEB916A4E3 for ; Sat, 4 Sep 2004 20:56:56 +0000 (GMT) Received: from cello.qnet.com (cello.qnet.com [209.221.193.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 159C843D31 for ; Sat, 4 Sep 2004 20:56:56 +0000 (GMT) (envelope-from stork@qnet.com) Received: from heredity2000p (66-42-105-180.lsan.dial.qnet.com [66.42.105.180]) by cello.qnet.com (8.12.10/8.12.10) with ESMTP id i84Kudsk021327 for ; Sat, 4 Sep 2004 13:56:44 -0700 (PDT) Message-Id: <200409042056.i84Kudsk021327@cello.qnet.com> From: "Paul Smith" To: Date: Sat, 4 Sep 2004 14:01:09 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0003_01C49287.ABCDFBA0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSSVLy/ZEQoF6OvSxyx9HpmdN8Kjw== X-MS-TNEF-Correlator: 0000000083EA75694EBEE6479FD17653560C4E6EA4642200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Microkernel Performance: FreeBSD versus Darwin 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, 04 Sep 2004 20:56:56 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C49287.ABCDFBA0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Theoretically the microkernel of Darwin should create overheads harming the performance. Has anybody seen an actual study comparing the performance of Darwin and FreeBSD? DEC's Tru64UNIX used a microkernel, but the Alpha hardware was so superior for its time that any loss of performance could have gone unnoticed. Similarly Tera runs on supercomputers that can absorb a little extra overhead. Does anybody know of any serious benefit arising from the microkernel? Or is Darwin simply Steve Jobs' passion to bring back NeXT? Paul Smith semenbank@yahoo.com --- Outgoing mail is certified Virus Checked. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.749 / Virus Database: 501 - Release Date: 9/1/2004 ------=_NextPart_000_0003_01C49287.ABCDFBA0--