From owner-freebsd-arch Sun Sep 17 9:49: 0 2000 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 7494237B424 for ; Sun, 17 Sep 2000 09:48:58 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13ahlC-0000Z4-00; Sun, 17 Sep 2000 10:57:46 -0600 Message-ID: <39C4F80A.FB1F244@softweyr.com> Date: Sun, 17 Sep 2000 10:57:46 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Will Andrews Cc: Steve Kargl , arch@FreeBSD.ORG Subject: Re: Rsh/Rlogin/Rcmd & friends References: <20000915143515.N40658@radon.gryphonsoft.com> <200009151956.MAA75808@troutmask.apl.washington.edu> <20000915145337.Q40658@radon.gryphonsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Will Andrews wrote: > > On Fri, Sep 15, 2000 at 12:56:10PM -0700, Steve Kargl wrote: > > What are the consequences of your proposal with the use of > > rdump/rrestore from another (non-FreeBSD) machine into a > > tape drive equipped FreeBSD box? > > What consequences? Remember, we'll still have ports for these things. > It only matters as far as new installations go. Post-install operations > are unimportant. Some enterprising young programmer could make rdump/rrestore use ssh as a transport for starting rmt. This would eliminate this problem entirely. Perhaps sdump and srestore? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Sep 17 10:15:16 2000 Delivered-To: freebsd-arch@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 5042037B422 for ; Sun, 17 Sep 2000 10:15:14 -0700 (PDT) Received: from localhost (scanner@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id NAA35853; Sun, 17 Sep 2000 13:13:08 -0400 (EDT) Date: Sun, 17 Sep 2000 13:13:08 -0400 (EDT) From: To: Wes Peters Cc: Will Andrews , Steve Kargl , arch@FreeBSD.ORG Subject: Re: Rsh/Rlogin/Rcmd & friends In-Reply-To: <39C4F80A.FB1F244@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 17 Sep 2000, Wes Peters wrote: > Some enterprising young programmer could make rdump/rrestore use ssh as a > transport for starting rmt. This would eliminate this problem entirely. > Perhaps sdump and srestore? I believe someone had already posted saying that had patches that used SSH as the transport for at least rdump. So we're half way there. ============================================================================= -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: scanner@jurai.net | Open Systems Inc., Wellington, Kansas Home: scanner@deceptively.shady.org | http://open-systems.net ============================================================================= WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tommorow?" BSD: "Are you guys coming or what?" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Sep 17 11:54:47 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 8212137B423 for ; Sun, 17 Sep 2000 11:54:44 -0700 (PDT) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id LAA04309 for ; Sun, 17 Sep 2000 11:54:44 -0700 Date: Sun, 17 Sep 2000 11:54:44 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: arch@freebsd.org Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpvar.h (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ moved to -arch where it should be ] > > [ moved to -developers ] > > I'm not sure you need to maintain NetBSD compatibility here. I don't believe > that NetBSD really cares what happens to the FreeBSD. The if_fxp driver in > NetBSD has been beat on substantially for a very very long time w/o in > back-sync to FreeBSD. In fact, it's not split into MI/MD pieces, etc. [ too much flu still- let's try this one again ] I'm not sure you need to maintain NetBSD compatibility here. I don't believe that NetBSD really cares what happens to the FreeBSD version. The if_fxp driver in NetBSD has been beat on substantially for a very very long time w/o in any back-sync to FreeBSD. In fact, it's been split into MI/MD pieces, etc. so that it's even hard to track any shared history with FreeBSD. > > I'd suggest that unless there is an author actively maintaining it in both > organizations and unless they're done as cleanly as (forgive my blushes, but > this is something I claim I know a fair amount about) as the Qlogic driver > (for SCSI HBAs) or the wx driver (for NICs), clearing out the NetBSD bits > would be a Good Thing To Do(tm) in order to increase maintainability on it. > > The same thing applies to the de driver also- which is almost deprecated in > NetBSD anyway. > > I thought dg was maintainer for fxp- should it be his call? > > On Sun, 17 Sep 2000, Chuck Paterson wrote: > > > cp 2000/09/17 06:26:26 PDT > > > > Modified files: > > sys/pci if_fxp.c if_fxpvar.h > > Log: > > Add locking to make able to run without the Giant lock being held. This > > is enabling as all entries are still called with Giant being held. > > Maintaining compatability with NetBSD makes what should be very simple > > kinda ugly. > > > > Reviewed by: Jason Evans > > > > Revision Changes Path > > 1.86 +45 -18 src/sys/pci/if_fxp.c > > 1.11 +8 -1 src/sys/pci/if_fxpvar.h > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Sep 17 12: 4:36 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 1180037B422 for ; Sun, 17 Sep 2000 12:04:33 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id NAA86878; Sun, 17 Sep 2000 13:04:29 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id NAA24354; Sun, 17 Sep 2000 13:04:22 -0600 (MDT) Message-Id: <200009171904.NAA24354@harmony.village.org> To: arch@freebsd.org, sjr@home.net Subject: sysctl on boot. Date: Sun, 17 Sep 2000 13:04:22 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Stephen Roznowski reports in PR conf/19629 that there's a weakness in /etc/rc.sysctl. As it stands now, it runs early in the boot process. And it needs to run early in the boot process for many sysctls. However, there is a problem. If you modload a driver or module after this point, any variables set early in the boot process will not be effective (because the setting fails). A short term fix is to just rerun /etc/rc.sysctl at the end of the boot sequence, just before the secrelevel change. Stephen's PR suggests this with a patch. I think it is good, but wanted to get some feedback from others before doing this. A long term fix might be to give the kernel a memory so it can initialize the sysctls from the get go. However, that's much harder to pull off and a whole lot more work. Comments? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Sep 17 12:34:36 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 0397737B422 for ; Sun, 17 Sep 2000 12:34:35 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e8HJYWl16793; Sun, 17 Sep 2000 12:34:32 -0700 (PDT) Date: Sun, 17 Sep 2000 12:34:32 -0700 From: Alfred Perlstein To: Warner Losh Cc: arch@FreeBSD.ORG, sjr@home.net Subject: Re: sysctl on boot. Message-ID: <20000917123432.M15156@fw.wintelcom.net> References: <200009171904.NAA24354@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200009171904.NAA24354@harmony.village.org>; from imp@village.org on Sun, Sep 17, 2000 at 01:04:22PM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Warner Losh [000917 12:04] wrote: > > Stephen Roznowski reports in PR conf/19629 that there's a weakness in > /etc/rc.sysctl. As it stands now, it runs early in the boot process. > And it needs to run early in the boot process for many sysctls. > However, there is a problem. If you modload a driver or module after > this point, any variables set early in the boot process will not be > effective (because the setting fails). > > A short term fix is to just rerun /etc/rc.sysctl at the end of the > boot sequence, just before the secrelevel change. Stephen's PR > suggests this with a patch. I think it is good, but wanted to get > some feedback from others before doing this. > > A long term fix might be to give the kernel a memory so it can > initialize the sysctls from the get go. However, that's much harder > to pull off and a whole lot more work. > > Comments? This is potentially dangerous as i'm not sure all sysctls are idempotent (sp?) meaning setting them twice can have weird effects, a solution might be to add another rc.sysctl2 or rc.sysctl.modules or something. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Sep 17 13:35:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 757F637B423; Sun, 17 Sep 2000 13:35:14 -0700 (PDT) Received: from localhost (11h991@localhost [127.0.0.1] (may be forged)) by green.dyndns.org (8.11.0/8.11.0) with ESMTP id e8HKYk525175; Sun, 17 Sep 2000 16:34:46 -0400 (EDT) (envelope-from green@FreeBSD.org) Message-Id: <200009172034.e8HKYk525175@green.dyndns.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Alfred Perlstein Cc: Warner Losh , arch@FreeBSD.org, sjr@home.net Subject: Re: sysctl on boot. In-Reply-To: Message from Alfred Perlstein of "Sun, 17 Sep 2000 12:34:32 PDT." <20000917123432.M15156@fw.wintelcom.net> From: "Brian F. Feldman" Date: Sun, 17 Sep 2000 16:34:46 -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > * Warner Losh [000917 12:04] wrote: > > > > Stephen Roznowski reports in PR conf/19629 that there's a weakness in > > /etc/rc.sysctl. As it stands now, it runs early in the boot process. > > And it needs to run early in the boot process for many sysctls. > > However, there is a problem. If you modload a driver or module after > > this point, any variables set early in the boot process will not be > > effective (because the setting fails). > > > > A short term fix is to just rerun /etc/rc.sysctl at the end of the > > boot sequence, just before the secrelevel change. Stephen's PR > > suggests this with a patch. I think it is good, but wanted to get > > some feedback from others before doing this. > > > > A long term fix might be to give the kernel a memory so it can > > initialize the sysctls from the get go. However, that's much harder > > to pull off and a whole lot more work. > > > > Comments? > > This is potentially dangerous as i'm not sure all sysctls are > idempotent (sp?) meaning setting them twice can have weird > effects, a solution might be to add another rc.sysctl2 or > rc.sysctl.modules or something. Yes, I agree with this. I'd call them rc.sysctl (keep that the same) and rc.late_sysctl (which would run after most things as you propose, before the securelevel change). You couldn't easily give the kernel a memory because the user might want sysctls in a specific order and you'd have to be able to record either the oid or the oid name for a given sysctl... and that wouldn't solve the problem of when to set them. IOW, it would add complexity but not gain anything that postponing rc.sysctl or adding a secondary rc wouldn't gain. So I wouldn't bother with that :) You're making it seem like we need a registry. I'd be a million times happier if a kldload(2) specified a hints file that could be used easily. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Sep 17 13:44:12 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 1A16137B422; Sun, 17 Sep 2000 13:44:10 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id OAA87299; Sun, 17 Sep 2000 14:44:06 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id OAA25218; Sun, 17 Sep 2000 14:43:58 -0600 (MDT) Message-Id: <200009172043.OAA25218@harmony.village.org> To: "Brian F. Feldman" Subject: Re: sysctl on boot. Cc: Alfred Perlstein , arch@FreeBSD.org, sjr@home.net In-reply-to: Your message of "Sun, 17 Sep 2000 16:34:46 EDT." <200009172034.e8HKYk525175@green.dyndns.org> References: <200009172034.e8HKYk525175@green.dyndns.org> Date: Sun, 17 Sep 2000 14:43:58 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200009172034.e8HKYk525175@green.dyndns.org> "Brian F. Feldman" writes: : IOW, it would add complexity but not gain anything that postponing rc.sysctl : or adding a secondary rc wouldn't gain. So I wouldn't bother with that :) : You're making it seem like we need a registry. I'd be a million times : happier if a kldload(2) specified a hints file that could be used easily. I've often thought about adding a sysctl.x.x.x facility like the hint.x.x.x facility, but haven't ad the time. I don't think there are any non-idempotent sysctls that people would be setting from rc.sysctl. However, I think I'm leaning towards a second parameter to /etc/rc.sysctl. The first one would be /etc/sysctl.conf and the second would be /etc/sysctl.modules.conf over the short term. I still think there's value in having a more persistant sysctl facility in the kernel, but will leave that for later. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Sep 17 13:51:52 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id E3FF637B423 for ; Sun, 17 Sep 2000 13:51:49 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id OAA87333; Sun, 17 Sep 2000 14:51:48 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id OAA25297; Sun, 17 Sep 2000 14:51:40 -0600 (MDT) Message-Id: <200009172051.OAA25297@harmony.village.org> To: Neil Blakey-Milner Subject: Re: Rsh/Rlogin/Rcmd & friends Cc: Christian Weisgerber , freebsd-arch@FreeBSD.org In-reply-to: Your message of "Sat, 16 Sep 2000 18:59:41 +0200." <20000916185941.A55093@mithrandr.moria.org> References: <20000916185941.A55093@mithrandr.moria.org> <200009151956.MAA75808@troutmask.apl.washington.edu> <200009160240.UAA09702@harmony.village.org> <8q0574$1i33$1@ganerc.mips.inka.de> Date: Sun, 17 Sep 2000 14:51:40 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000916185941.A55093@mithrandr.moria.org> Neil Blakey-Milner writes: : Warner suggested it was too specific to dump, and suggested the rshcmd : from OpenBSD last month. You had since changed your email address, and : I presume his response bounced like Sheldon's change of status to your : PR bounced. I've ported this and have been testing it in my tree for a while now. I've not had a chance to separate out an unrelated, but still green, change yet. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Sep 17 13:52:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 5E29837B423 for ; Sun, 17 Sep 2000 13:52:54 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id OAA87342; Sun, 17 Sep 2000 14:52:52 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id OAA25317; Sun, 17 Sep 2000 14:52:44 -0600 (MDT) Message-Id: <200009172052.OAA25317@harmony.village.org> To: Wes Peters Subject: Re: Rsh/Rlogin/Rcmd & friends Cc: Will Andrews , Steve Kargl , arch@FreeBSD.ORG In-reply-to: Your message of "Sun, 17 Sep 2000 10:57:46 MDT." <39C4F80A.FB1F244@softweyr.com> References: <39C4F80A.FB1F244@softweyr.com> <20000915143515.N40658@radon.gryphonsoft.com> <200009151956.MAA75808@troutmask.apl.washington.edu> <20000915145337.Q40658@radon.gryphonsoft.com> Date: Sun, 17 Sep 2000 14:52:44 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <39C4F80A.FB1F244@softweyr.com> Wes Peters writes: : Some enterprising young programmer could make rdump/rrestore use ssh as a : transport for starting rmt. This would eliminate this problem entirely. : Perhaps sdump and srestore? I have patches in my tree right now that do this. No need for a new name, a simple env var does the trick. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Sep 17 13:53:17 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 2869E37B422 for ; Sun, 17 Sep 2000 13:53:15 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id OAA87358; Sun, 17 Sep 2000 14:53:13 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id OAA25342; Sun, 17 Sep 2000 14:53:05 -0600 (MDT) Message-Id: <200009172053.OAA25342@harmony.village.org> To: scanner@jurai.net Subject: Re: Rsh/Rlogin/Rcmd & friends Cc: Wes Peters , Will Andrews , Steve Kargl , arch@FreeBSD.ORG In-reply-to: Your message of "Sun, 17 Sep 2000 13:13:08 EDT." References: Date: Sun, 17 Sep 2000 14:53:05 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message scanner@jurai.net writes: : I believe someone had already posted saying that had patches that : used SSH as the transport for at least rdump. So we're half way there. It was for both. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Sep 17 14: 5:36 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id E41C737B422; Sun, 17 Sep 2000 14:05:34 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e8HL5TM19062; Sun, 17 Sep 2000 14:05:29 -0700 (PDT) Date: Sun, 17 Sep 2000 14:05:29 -0700 From: Alfred Perlstein To: Warner Losh Cc: "Brian F. Feldman" , arch@FreeBSD.ORG, sjr@home.net Subject: Re: sysctl on boot. Message-ID: <20000917140529.P15156@fw.wintelcom.net> References: <200009172034.e8HKYk525175@green.dyndns.org> <200009172043.OAA25218@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200009172043.OAA25218@harmony.village.org>; from imp@village.org on Sun, Sep 17, 2000 at 02:43:58PM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Warner Losh [000917 13:44] wrote: > In message <200009172034.e8HKYk525175@green.dyndns.org> "Brian F. Feldman" writes: > : IOW, it would add complexity but not gain anything that postponing rc.sysctl > : or adding a secondary rc wouldn't gain. So I wouldn't bother with that :) > : You're making it seem like we need a registry. I'd be a million times > : happier if a kldload(2) specified a hints file that could be used easily. > > I've often thought about adding a sysctl.x.x.x facility like the > hint.x.x.x facility, but haven't ad the time. > > I don't think there are any non-idempotent sysctls that people would > be setting from rc.sysctl. However, I think I'm leaning towards > a second parameter to /etc/rc.sysctl. The first one would be > /etc/sysctl.conf and the second would be /etc/sysctl.modules.conf over > the short term. > > I still think there's value in having a more persistant sysctl > facility in the kernel, but will leave that for later. I agree on both points. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Sep 17 17: 5:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 3169137B422 for ; Sun, 17 Sep 2000 17:05:51 -0700 (PDT) Received: from newsguy.com (p16-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.17]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id JAA09310; Mon, 18 Sep 2000 09:05:40 +0900 (JST) Message-ID: <39C55C24.11A52A46@newsguy.com> Date: Mon, 18 Sep 2000 09:04:52 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Warner Losh Cc: arch@FreeBSD.ORG, sjr@home.net Subject: Re: sysctl on boot. References: <200009171904.NAA24354@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > A long term fix might be to give the kernel a memory so it can > initialize the sysctls from the get go. However, that's much harder > to pull off and a whole lot more work. > > Comments? Non-intialized sysctl's might be converted into hint.*, and used or not later. Of course, this results in a sort of memory leaking. And I'm not even sure we can add new kernel environment variables once booted. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.secret.bsdconspiracy.net "I demand that my picture show a handsome face, even if it doesn't look like me." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Sep 17 17:42:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 6B07337B424 for ; Sun, 17 Sep 2000 17:42:29 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id SAA88164 for ; Sun, 17 Sep 2000 18:42:27 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id SAA26812 for ; Sun, 17 Sep 2000 18:42:19 -0600 (MDT) Message-Id: <200009180042.SAA26812@harmony.village.org> To: arch@freebsd.org Subject: Comments requested: automatic hook for mergemaster Date: Sun, 17 Sep 2000 18:42:19 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Comments on the following. Warner Index: Makefile.inc1 =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/Makefile.inc1,v retrieving revision 1.169 diff -u -r1.169 Makefile.inc1 --- Makefile.inc1 2000/09/09 14:37:06 1.169 +++ Makefile.inc1 2000/09/18 00:41:05 @@ -305,6 +305,9 @@ done cd ${.CURDIR}; ${IMAKE} reinstall rm -rf ${INSTALLTMP} +.if defined(DO_MERGEMASTER) + mergemaster +.endif # # reinstall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Sep 17 18:16:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from merc95.us.sas.com (merc95.us.sas.com [149.173.6.5]) by hub.freebsd.org (Postfix) with ESMTP id D53A437B422 for ; Sun, 17 Sep 2000 18:16:11 -0700 (PDT) Received: from merc95.us.sas.com ([127.0.0.1]) by merc95.us.sas.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id TA8FLWGA; Sun, 17 Sep 2000 21:16:10 -0400 Received: from 10.28.149.26 by merc95.us.sas.com (InterScan E-Mail VirusWall NT); Sun, 17 Sep 2000 21:16:10 -0400 (Eastern Daylight Time) Received: from bb01f39.unx.sas.com (bb01f39.unx.sas.com [10.16.2.246]) by mozart.unx.sas.com (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id VAA11151; Sun, 17 Sep 2000 21:16:10 -0400 (EDT) Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.3/8.9.1) id VAA09959; Sun, 17 Sep 2000 21:16:09 -0400 (EDT) (envelope-from jwd) Date: Sun, 17 Sep 2000 21:16:09 -0400 From: John DeBoskey To: Warner Losh Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Comments requested: automatic hook for mergemaster Message-ID: <20000917211609.A9550@unx.sas.com> References: <200009180042.SAA26812@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200009180042.SAA26812@harmony.village.org>; from imp@village.org on Sun, Sep 17, 2000 at 06:42:19PM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I might be missing something here. What happens to a nightly 'make world' process if DO_MERGEMASTER is defined? We'd need a completely non-interactive approach to make this work (I'm not 100% familiar with mergemaster's internal workings). -John ----- Warner Losh's Original Message ----- > > Comments on the following. > > Warner > > > Index: Makefile.inc1 > =================================================================== > RCS file: /home/imp/FreeBSD/CVS/src/Makefile.inc1,v > retrieving revision 1.169 > diff -u -r1.169 Makefile.inc1 > --- Makefile.inc1 2000/09/09 14:37:06 1.169 > +++ Makefile.inc1 2000/09/18 00:41:05 > @@ -305,6 +305,9 @@ > done > cd ${.CURDIR}; ${IMAKE} reinstall > rm -rf ${INSTALLTMP} > +.if defined(DO_MERGEMASTER) > + mergemaster > +.endif > > # > # reinstall > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- Failure is NOT an option! It is built into every Micro$oft application. ... W2K is bigger, has a ton more features, and suffers from the usual microsoft "better to have a feature with bugs than to not have the feature at all" philosophy. FreeBSD... The choice of those who know how to choose... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Sep 17 18:22:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from diskfarm.firehouse.net (rdu25-12-043.nc.rr.com [24.25.12.43]) by hub.freebsd.org (Postfix) with ESMTP id 0FE9137B423 for ; Sun, 17 Sep 2000 18:22:37 -0700 (PDT) Received: (from abc@localhost) by diskfarm.firehouse.net (8.9.3/8.9.3) id VAA69662 for freebsd-arch@FreeBSD.ORG; Sun, 17 Sep 2000 21:24:21 -0400 (EDT) (envelope-from abc) Date: Sun, 17 Sep 2000 21:24:21 -0400 From: Alan Clegg To: freebsd-arch@FreeBSD.ORG Subject: Re: Comments requested: automatic hook for mergemaster Message-ID: <20000917212421.A69645@diskfarm.firehouse.net> References: <200009180042.SAA26812@harmony.village.org> <20000917211609.A9550@unx.sas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20000917211609.A9550@unx.sas.com>; from jwd@unx.sas.com on Sun, Sep 17, 2000 at 09:16:09PM -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Unless the network is lying to me again, John DeBoskey said: > What happens to a nightly 'make world' process if DO_MERGEMASTER > is defined? We'd need a completely non-interactive approach > to make this work (I'm not 100% familiar with mergemaster's > internal workings). In addition, we will definitely need MERGEMASTER_FLAGS or somesuch so that we can specify all of the needed flags. AlanC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Sep 17 18:49: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 5A9B537B422 for ; Sun, 17 Sep 2000 18:49:03 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id TAA88352; Sun, 17 Sep 2000 19:49:02 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id TAA27247; Sun, 17 Sep 2000 19:48:53 -0600 (MDT) Message-Id: <200009180148.TAA27247@harmony.village.org> To: John DeBoskey Subject: Re: Comments requested: automatic hook for mergemaster Cc: freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Sun, 17 Sep 2000 21:16:09 EDT." <20000917211609.A9550@unx.sas.com> References: <20000917211609.A9550@unx.sas.com> <200009180042.SAA26812@harmony.village.org> Date: Sun, 17 Sep 2000 19:48:53 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000917211609.A9550@unx.sas.com> John DeBoskey writes: : What happens to a nightly 'make world' process if DO_MERGEMASTER : is defined? We'd need a completely non-interactive approach : to make this work (I'm not 100% familiar with mergemaster's : internal workings). If DO_MERGEMASTER is defined, the build is no longer automatic. Now that I think about it, it might not be such a good idea. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Sep 17 18:51:16 2000 Delivered-To: freebsd-arch@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 159AD37B422 for ; Sun, 17 Sep 2000 18:51:14 -0700 (PDT) Received: from gorean.org (doug@master [10.0.0.2]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id SAA61239; Sun, 17 Sep 2000 18:50:59 -0700 (PDT) (envelope-from DougB@gorean.org) Message-ID: <39C57502.A0D1E3CA@gorean.org> Date: Sun, 17 Sep 2000 18:50:58 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 5.0-CURRENT-091 i386) X-Accept-Language: en MIME-Version: 1.0 To: Alan Clegg Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Comments requested: automatic hook for mergemaster References: <200009180042.SAA26812@harmony.village.org> <20000917211609.A9550@unx.sas.com> <20000917212421.A69645@diskfarm.firehouse.net> Content-Type: multipart/mixed; boundary="------------9E059BE290C0194B4DD03BA4" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------9E059BE290C0194B4DD03BA4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alan Clegg wrote: > > Unless the network is lying to me again, John DeBoskey said: > > > What happens to a nightly 'make world' process if DO_MERGEMASTER > > is defined? We'd need a completely non-interactive approach > > to make this work (I'm not 100% familiar with mergemaster's > > internal workings). > > In addition, we will definitely need MERGEMASTER_FLAGS or somesuch so that > we can specify all of the needed flags. I think a _FLAGS variable is a good idea. Also, mm already has an "autorun" mode that deletes files that match from the temproot environment and prints helpful messages for the ones that remain. The attached patch might be better. Doug -- "The dead cannot be seduced." - Kai, "Lexx" Do YOU Yahoo!? --------------9E059BE290C0194B4DD03BA4 Content-Type: text/plain; charset=us-ascii; name="Makefile.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Makefile.patch" Index: Makefile.inc1 =================================================================== RCS file: /usr/ncvs/src/Makefile.inc1,v retrieving revision 1.170 diff -u -r1.170 Makefile.inc1 --- Makefile.inc1 2000/09/17 21:02:58 1.170 +++ Makefile.inc1 2000/09/18 01:46:36 @@ -305,6 +305,10 @@ done cd ${.CURDIR}; ${IMAKE} reinstall rm -rf ${INSTALLTMP} +.if defined(DO_MERGEMASTER) + MERGEMASTER_FLAGS?= -a + mergemaster ${MERGEMASTER_FLAGS} +.endif # # reinstall --------------9E059BE290C0194B4DD03BA4-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 18 8:31:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 0099637B422 for ; Mon, 18 Sep 2000 08:31:57 -0700 (PDT) Received: from newsguy.com (p03-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.132]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id AAA03877; Tue, 19 Sep 2000 00:30:36 +0900 (JST) Message-ID: <39C634EB.EFBE77AA@newsguy.com> Date: Tue, 19 Sep 2000 00:29:47 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Warner Losh Cc: John DeBoskey , freebsd-arch@FreeBSD.ORG Subject: Re: Comments requested: automatic hook for mergemaster References: <20000917211609.A9550@unx.sas.com> <200009180042.SAA26812@harmony.village.org> <200009180148.TAA27247@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > In message <20000917211609.A9550@unx.sas.com> John DeBoskey writes: > : What happens to a nightly 'make world' process if DO_MERGEMASTER > : is defined? We'd need a completely non-interactive approach > : to make this work (I'm not 100% familiar with mergemaster's > : internal workings). > > If DO_MERGEMASTER is defined, the build is no longer automatic. Now > that I think about it, it might not be such a good idea. I disagree. Having a non-automatic option will not make the process non-automatic, as long as that option is not used. So, what happens is that nothing changes for anyone, except those that explicitly define the option. Those who do will have their installworld hanged waiting for input. (Well, unless -a is used for mergemaster -- but I like the interactive version myself.) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.secret.bsdconspiracy.net "I demand that my picture show a handsome face, even if it doesn't look like me." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 18 14:50:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2A46537B423; Mon, 18 Sep 2000 14:50:42 -0700 (PDT) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id OAA49147; Mon, 18 Sep 2000 14:50:42 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Mon, 18 Sep 2000 14:50:42 -0700 (PDT) From: Kris Kennaway To: Warner Losh Cc: arch@freebsd.org, sjr@home.net Subject: Re: sysctl on boot. In-Reply-To: <200009171904.NAA24354@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 17 Sep 2000, Warner Losh wrote: > A short term fix is to just rerun /etc/rc.sysctl at the end of the > boot sequence, just before the secrelevel change. Stephen's PR > suggests this with a patch. I think it is good, but wanted to get > some feedback from others before doing this. rc.sysctl_early and rc.sysctl_late? Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 18 15: 9:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 233E637B424; Mon, 18 Sep 2000 15:09:39 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA92173; Mon, 18 Sep 2000 16:09:34 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA33920; Mon, 18 Sep 2000 16:09:22 -0600 (MDT) Message-Id: <200009182209.QAA33920@harmony.village.org> To: Kris Kennaway Subject: Re: sysctl on boot. Cc: arch@FreeBSD.org, sjr@home.net In-reply-to: Your message of "Mon, 18 Sep 2000 14:50:42 PDT." References: Date: Mon, 18 Sep 2000 16:09:22 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Kris Kennaway writes: : On Sun, 17 Sep 2000, Warner Losh wrote: : : > A short term fix is to just rerun /etc/rc.sysctl at the end of the : > boot sequence, just before the secrelevel change. Stephen's PR : > suggests this with a patch. I think it is good, but wanted to get : > some feedback from others before doing this. : : rc.sysctl_early and rc.sysctl_late? I worry about a gratuitous change to the name. However, I could easily see rc.sysctl have an early file and a late one settable by rc.conf Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 18 17:35: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 05A2D37B422; Mon, 18 Sep 2000 17:35:01 -0700 (PDT) Received: from slave (Studded@slave [10.0.0.1]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id RAA10903; Mon, 18 Sep 2000 17:34:55 -0700 (PDT) (envelope-from DougB@gorean.org) Date: Mon, 18 Sep 2000 17:34:55 -0700 (PDT) From: Doug Barton X-Sender: doug@dt051n37.san.rr.com To: Warner Losh Cc: Kris Kennaway , arch@FreeBSD.ORG, sjr@home.net Subject: Re: sysctl on boot. In-Reply-To: <200009182209.QAA33920@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 18 Sep 2000, Warner Losh wrote: > In message Kris Kennaway writes: > : On Sun, 17 Sep 2000, Warner Losh wrote: > : > : > A short term fix is to just rerun /etc/rc.sysctl at the end of the > : > boot sequence, just before the secrelevel change. Stephen's PR > : > suggests this with a patch. I think it is good, but wanted to get > : > some feedback from others before doing this. > : > : rc.sysctl_early and rc.sysctl_late? > > I worry about a gratuitous change to the name. However, I could > easily see rc.sysctl have an early file and a late one settable by > rc.conf If I can speak from the "average user" standpoint, this scheme is fraught with disaster. In the long run it will be much easier to fix the sysctl's that can't be set twice than it would be to try and get users to figure out which ones are "early" and which ones are "late." This also accomplishes the task of making things work the way they should in the first place. :) Doug -- "The dead cannot be seduced." - Kai, "Lexx" Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 18 19:55: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from shidahara1.planet.sci.kobe-u.ac.jp (shidahara1.planet.sci.kobe-u.ac.jp [133.30.50.200]) by hub.freebsd.org (Postfix) with ESMTP id 4655837B424 for ; Mon, 18 Sep 2000 19:54:56 -0700 (PDT) Received: from shidahara1.planet.sci.kobe-u.ac.jp (localhost [127.0.0.1]) by shidahara1.planet.sci.kobe-u.ac.jp (8.9.3/8.9.3) with ESMTP id LAA77533 for ; Tue, 19 Sep 2000 11:55:00 +0900 (JST) (envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp) Message-Id: <200009190255.LAA77533@shidahara1.planet.sci.kobe-u.ac.jp> To: freebsd-arch@freebsd.org Subject: [CFR]patch for kern/kern_exec.c and sys/imgact.h Date: Tue, 19 Sep 2000 11:55:00 +0900 From: Takanori Watanabe Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I suggested by imp to talk about this issue in this list, So I write again in this list. I ported kernel part of PEACE (Portable Executable win32 API Compatible Environment) and I want to change kern/kern_exec.c and sys/imgact.h as follows to make the module run correctly. The main reason fot this change is as mentioned above but this change is useful for farther executable format support, I convince. Are there anyone review this patch?If this patch is reviewed,I'll commit ASAP. Takanori Watanabe Public Key Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A --- sys/imgact.h.orig Mon Sep 18 02:18:46 2000 +++ sys/imgact.h Mon Sep 18 02:19:25 2000 @@ -58,6 +58,7 @@ struct vm_page *firstpage; /* first page that we mapped */ char *fname; /* pointer to filename of executable (user space) */ unsigned long ps_strings; /* PS_STRINGS for BSD/OS binaries */ + size_t auxarg_size; }; #ifdef _KERNEL --- kern/kern_exec.c.orig Fri Jul 14 15:44:45 2000 +++ kern/kern_exec.c Mon Sep 18 02:59:45 2000 @@ -127,6 +127,7 @@ imgp->vp = NULL; imgp->firstpage = NULL; imgp->ps_strings = 0; + imgp->auxarg_size=0; /* * Allocate temporary demand zeroed space for argument and @@ -613,14 +614,21 @@ * If we have a valid auxargs ptr, prepare some room * on the stack. */ - if (imgp->auxargs) + if (imgp->auxargs){ + /* + * 'AT_COUNT*2' is size for the ELF Auxargs data. + * This is for lower compatibility. + */ + imgp->auxarg_size=(imgp->auxarg_size)?imgp->auxarg_size + :(AT_COUNT*2); /* * The '+ 2' is for the null pointers at the end of each of the - * arg and env vector sets, and 'AT_COUNT*2' is room for the - * ELF Auxargs data. + * arg and env vector sets,and imgp->auxarg_size is room for argument + * of Runtime loader. */ vectp = (char **)(destp - (imgp->argc + imgp->envc + 2 + - AT_COUNT*2) * sizeof(char*)); + imgp->auxarg_size) * sizeof(char*)); + } else /* * The '+ 2' is for the null pointers at the end of each of the To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 18 22:20:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id BA31537B423; Mon, 18 Sep 2000 22:20:08 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id BAA40167; Tue, 19 Sep 2000 01:19:55 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 19 Sep 2000 01:19:55 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Warner Losh Cc: "Brian F. Feldman" , Alfred Perlstein , arch@FreeBSD.org, sjr@home.net Subject: Re: sysctl on boot. In-Reply-To: <200009172043.OAA25218@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 17 Sep 2000, Warner Losh wrote: > I don't think there are any non-idempotent sysctls that people would > be setting from rc.sysctl. However, I think I'm leaning towards > a second parameter to /etc/rc.sysctl. The first one would be > /etc/sysctl.conf and the second would be /etc/sysctl.modules.conf over > the short term. There are some idempotent sysctls that might be relevant -- in particular, ones relating to security that disable features. For example, you'll find that if you set kern.suser_permitted to 0, no further sysctl's can be set. As such, it is not idempotent, and ordering is very important :-). You could argue, however, that the setting of that variable belongs in an ordered rc event. I'd be tempted to have rc.sysctl run only at the end of /etc/rc processing, and as other sysctls have ordering requirements, to indicate that they should be placed strategically in /etc/rc and others such that they make sense, or set when appropriate modules are loaded. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 18 22:45: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 7D67D37B424 for ; Mon, 18 Sep 2000 22:44:59 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id XAA93663 for ; Mon, 18 Sep 2000 23:44:58 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id XAA36298 for ; Mon, 18 Sep 2000 23:44:45 -0600 (MDT) Message-Id: <200009190544.XAA36298@harmony.village.org> To: arch@freebsd.org Subject: binary compat guidelines Date: Mon, 18 Sep 2000 23:44:45 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm wondering if we (the FreeBSD project) has guidelines for kernel binary compatibility over time. What things are allowed? What things are bogus? I've been following the rules. I've been focused on the card driver <-> bus driver interface, so these are slanted. o use kobj o don't add args to functions called with kobj o use only basic types in args. If pointers are used, they aren't dereferenced by the driver directly. o use ivars. icky but useful. o OK to make calls to external functions, not all calls must be brokered through kobj. These are convenience functions. o no sizeof(struct foo) o no offsetof And some silly things I've done or cleaned up in the past: o Don't have module symbol interdependencies Any others? Anything stupid I'm doing? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 19 0:58: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by hub.freebsd.org (Postfix) with ESMTP id 90FB837B42C for ; Tue, 19 Sep 2000 00:58:03 -0700 (PDT) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 13bIHq-0008Hz-0W; Tue, 19 Sep 2000 08:57:55 +0100 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA41734; Tue, 19 Sep 2000 09:00:26 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Tue, 19 Sep 2000 08:57:57 +0100 (BST) From: Doug Rabson To: Warner Losh Cc: arch@freebsd.org Subject: Re: binary compat guidelines In-Reply-To: <200009190544.XAA36298@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 18 Sep 2000, Warner Losh wrote: > > I'm wondering if we (the FreeBSD project) has guidelines for kernel > binary compatibility over time. What things are allowed? What things > are bogus? > > I've been following the rules. I've been focused on the card driver > <-> bus driver interface, so these are slanted. > o use kobj > o don't add args to functions called with kobj > o use only basic types in args. If pointers are used, they > aren't dereferenced by the driver directly. > o use ivars. icky but useful. > o OK to make calls to external functions, not all calls must > be brokered through kobj. These are convenience functions. > o no sizeof(struct foo) > o no offsetof > And some silly things I've done or cleaned up in the past: > o Don't have module symbol interdependencies > > Any others? Anything stupid I'm doing? This looks like a good set of rules for avoiding certain kinds of ABI change. For added longevity, you need to isolate yourself from the various kernel data structures which tend to change frequently. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8348 3944 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 19 21:53:36 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 7A58937B42C; Tue, 19 Sep 2000 21:53:34 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id AAA56298; Wed, 20 Sep 2000 00:53:25 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 20 Sep 2000 00:53:25 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Warner Losh Cc: "Brian F. Feldman" , Alfred Perlstein , arch@FreeBSD.org, sjr@home.net Subject: Re: sysctl on boot. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 19 Sep 2000, Robert Watson wrote: > There are some idempotent sysctls that might be relevant -- in particular, Needless to say this makes a lot more sense if you s/idempotent/non-idempotent/ Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 19 23:26:45 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 55B3737B424 for ; Tue, 19 Sep 2000 23:26:42 -0700 (PDT) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id IAA26237; Wed, 20 Sep 2000 08:26:36 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id IAA30055; Wed, 20 Sep 2000 08:26:36 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Wed, 20 Sep 2000 08:26:36 +0200 (CEST) From: Marius Bendiksen To: Cy Schubert - ITSD Open Systems Group Cc: arch@FreeBSD.ORG Subject: Re: Rsh/Rlogin/Rcmd & friends In-Reply-To: <200009152136.e8FLaou26312@cwsys.cwsent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > telnet/ftp/"r" commands shouldn't even be ports. We need to make it > difficult to install unsafe software on the system. That way the admin > would have to go to all the trouble to find the source for unsafe > software somewhere on the Net, port it, and install it. Then it's not > FreeBSD's fault if that admin's system is compromised. Excuse me. When did we go from "reliably delivering the bullet to its intended target" to "padding the sysadmin until he can't see the keyboard for all the fluff" ? It is not, has never been, and will never be, "FreeBSD's fault" if the admin didn't do a proper job of configuring his system. If anything, it is our task to meet the demands of the admin, whatever they may be. If I ever start seeing this "Are you sure?" thing popping up all across the system, I doubt FreeBSD will ever touch my desktop again, and my servers only for as long as no alternative exists. I believe this is a very common opinion. There should really be a policy decision made here, in a formal manner, rather than setting a precedent without having thought that through. Yours, Marius Bendiksen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 19 23:44:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id AAE0D37B423 for ; Tue, 19 Sep 2000 23:44:37 -0700 (PDT) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id IAA29019; Wed, 20 Sep 2000 08:44:36 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id IAA30123; Wed, 20 Sep 2000 08:44:36 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Wed, 20 Sep 2000 08:44:36 +0200 (CEST) From: Marius Bendiksen To: Cy Schubert - ITSD Open Systems Group Cc: arch@FreeBSD.ORG Subject: Re: Rsh/Rlogin/Rcmd & friends In-Reply-To: <200009161534.e8GFYDc32614@cwsys.cwsent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 4. Status quo. This is my vote, at least until (at some point in a distant future) sysinstallNG is finished, at which point we're bound to run into a lot of work with this anyway. > change my vote to option 4. (The bullying and insults didn't change my > mind. The few reasonable arguments -- Robert Watson's note comes to > mind -- is what did it). Please note that many people feel offended by what I perceived as bullying and insults on _your_ behalf, by the wording of the mail you posted. If we do not pay attention to the desires of our users, we will find ourselves a lot of users poorer. The so-perceived bullying and insults have been those users' voice in the matter. If we are to disregard our user base, or if we are to start prompting people whether they're sure they know what they're doing, or if we are to start assuming they don't without even asking, then I think another BSD is in order. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 19 23:57:36 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 5D27237B422 for ; Tue, 19 Sep 2000 23:57:34 -0700 (PDT) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id IAA30864; Wed, 20 Sep 2000 08:54:56 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id IAA30177; Wed, 20 Sep 2000 08:54:56 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Wed, 20 Sep 2000 08:54:56 +0200 (CEST) From: Marius Bendiksen To: Warner Losh Cc: arch@FreeBSD.ORG, sjr@home.net Subject: Re: sysctl on boot. In-Reply-To: <200009171904.NAA24354@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > A short term fix is to just rerun /etc/rc.sysctl at the end of the > boot sequence, just before the secrelevel change. Stephen's PR > suggests this with a patch. I think it is good, but wanted to get > some feedback from others before doing this. At peril to my continued existance, I dare rehash the topic of switching the current rc script mechanism. Eivind Eklund has written some scripts, which implement a proof-of-concept for this. Basically, IIRC, a dependency graph is constructed, and things are run in the proper order as detected by the startup scripts. He also proposed the ability to shut down and start services including dependencies using this mechanism. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 20 5:43:47 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.sunesi.net (ns1.sunesi.net [196.15.192.194]) by hub.freebsd.org (Postfix) with ESMTP id 1070337B423 for ; Wed, 20 Sep 2000 05:43:44 -0700 (PDT) Received: from nbm by ns1.sunesi.net with local (Exim 3.03 #1) id 13bjDl-0000BX-00; Wed, 20 Sep 2000 14:43:29 +0200 Date: Wed, 20 Sep 2000 14:43:29 +0200 From: Neil Blakey-Milner To: Marius Bendiksen Cc: Warner Losh , arch@FreeBSD.ORG, sjr@home.net Subject: Dependency-based rc system (Was Re: sysctl on boot.) Message-ID: <20000920144329.A675@mithrandr.moria.org> References: <200009171904.NAA24354@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from mbendiks@eunet.no on Wed, Sep 20, 2000 at 08:54:56AM +0200 Organization: Sunesi Clinical Systems X-Operating-System: FreeBSD 3.3-RELEASE i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed 2000-09-20 (08:54), Marius Bendiksen wrote: > At peril to my continued existance, I dare rehash the topic of switching > the current rc script mechanism. Eivind Eklund has written some scripts, > which implement a proof-of-concept for this. > > Basically, IIRC, a dependency graph is constructed, and things are run in > the proper order as detected by the startup scripts. He also proposed the > ability to shut down and start services including dependencies using this > mechanism. I was about to suggest this. NetBSD has a nice working example, and I intend to port and reconstruct it for FreeBSD, and suggest we cross over. They apparently took a little hammering on the mailing lists, and I imagine we will too, but it does seem the obvious way forward, and we can sidestep many of the issues from what they've learnt and done. It seems to have the advantages of SysV and the advantages of BSD, without the disadvantages of SysV and the disadvantages of BSD. Neil -- Neil Blakey-Milner Sunesi Clinical Systems nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 20 12: 8:52 2000 Delivered-To: freebsd-arch@freebsd.org Received: from roaming.cacheboy.net (roaming.cacheboy.net [203.56.168.69]) by hub.freebsd.org (Postfix) with ESMTP id DDB6C37B422; Wed, 20 Sep 2000 12:08:47 -0700 (PDT) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.0/8.11.0) id eBLKBmS19520; Thu, 21 Dec 2000 21:11:48 +0100 (CET) (envelope-from adrian) Date: Thu, 21 Dec 2000 21:11:48 +0100 From: Adrian Chadd To: Robert Watson Cc: Dan Moschuk , arch@FreeBSD.ORG Subject: Re: ftpd and sendfile() Message-ID: <20001221211148.C2065@roaming.cacheboy.net> References: <20000905101956.C415@spirit.jaded.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from rwatson@FreeBSD.ORG on Tue, Sep 05, 2000 at 11:47:00AM -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Sep 05, 2000, Robert Watson wrote: > > (a) Make sure it doesn't break ASCII mode > > (b) Make sure that interuption of transfers works, and that correct > reporting of bytes transfered happens regardless of success or > failure. > > Not sure what the implications of these two suggestions are :-). .. there's a PR assigned to myself about doing this. If you're going to do it, great! Just nab the PR. Adrian -- Adrian Chadd "The main reason Santa is so jolly is because he knows where all the bad girls live." -- Random IRC quote To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 21 4:48:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id C184437B422 for ; Thu, 21 Sep 2000 04:48:50 -0700 (PDT) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id NAA57626; Thu, 21 Sep 2000 13:46:15 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id NAA38166; Thu, 21 Sep 2000 13:46:13 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Thu, 21 Sep 2000 13:46:13 +0200 (CEST) From: Marius Bendiksen To: Neil Blakey-Milner Cc: Warner Losh , arch@FreeBSD.ORG, sjr@home.net Subject: Re: Dependency-based rc system (Was Re: sysctl on boot.) In-Reply-To: <20000920144329.A675@mithrandr.moria.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > NetBSD has a nice working example, and I intend to port and reconstruct You would probably do well to look at other implementations as well. The one Eivind wrote apparently works fine on FreeBSD, all done in shell script, and ISTR someone mentioning a more crippled way of doing this being employed in SCO or AIX or somesuch. > it for FreeBSD, and suggest we cross over. They apparently took a > little hammering on the mailing lists, and I imagine we will too, but it > does seem the obvious way forward, and we can sidestep many of the > issues from what they've learnt and done. *nod* There will always be issues with such a major change. I suppose we'd need a transition period in which the old scripts work mostly as expected. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 21 18:12:34 2000 Delivered-To: freebsd-arch@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id B773337B423; Thu, 21 Sep 2000 18:12:32 -0700 (PDT) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id SAA22459; Thu, 21 Sep 2000 18:12:32 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Thu, 21 Sep 2000 18:12:32 -0700 (PDT) From: Kris Kennaway To: Neil Blakey-Milner Cc: Marius Bendiksen , Warner Losh , arch@FreeBSD.ORG, sjr@home.net Subject: Re: Dependency-based rc system (Was Re: sysctl on boot.) In-Reply-To: <20000920144329.A675@mithrandr.moria.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 20 Sep 2000, Neil Blakey-Milner wrote: > NetBSD has a nice working example, and I intend to port and reconstruct > it for FreeBSD, and suggest we cross over. They apparently took a > little hammering on the mailing lists, and I imagine we will too, but it > does seem the obvious way forward, and we can sidestep many of the > issues from what they've learnt and done. I also suggest you compare and contrast with Eivind's prototype version to see if theres anything we can take from both. Thanks! Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 22 19:14:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id EDBC837B42C; Fri, 22 Sep 2000 19:14:11 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.ca ([24.201.203.136]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G1B00G14I7MY1@field.videotron.net>; Fri, 22 Sep 2000 22:14:10 -0400 (EDT) Date: Fri, 22 Sep 2000 22:17:49 -0400 (EDT) From: Bosko Milekic Subject: mbuf system and SMPng To: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello folks, Well, I'm presently ready to receive and act upon comments following review of SMPng-related changes to the mbuf system. I urge everybody to glance over at the following: http://people.freebsd.org/~bmilekic/mtx_journal and http://people.freebsd.org/~bmilekic/mbuf_mtx-v5.diff The latter is a ~40k diff to the mbuf system, mostly, that adds mutex locking, and generally cleans it up a bit. I realize that this description is not so clear, which is why I've - following Alfred Perlstein's suggestion - kept a log of changes/informal journal, and that's what the first link is. If you're reviewing the code, please make sure to check out all of the entries. As mentionned, I'm looking for feedback: technical, stylistic, etc. Please be advised that some of the stuff can probably use a little of a style makeover, and if you stumble upon such a thing, let me know and I'll adjust the diff once enough comments are gathered. As I still don't have SMP hardware, I'm also looking for people with these resources to run this and provide me with comments/notes. I'm looking forward to getting a hold of some better equipment to test with. If there's anything I missed, please let me know. Thanks, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 23 11: 8:26 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 643CF37B424; Sat, 23 Sep 2000 11:08:20 -0700 (PDT) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id MAA18066; Sat, 23 Sep 2000 12:08:19 -0600 (MDT) Message-Id: <200009231808.MAA18066@berserker.bsdi.com> To: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: mbuf system and SMPng In-reply-to: Your message of "Fri, 22 Sep 2000 22:17:49 EDT." From: Chuck Paterson Date: Sat, 23 Sep 2000 12:08:19 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bosko, It looks like you can reduce the number of mutex operations and the number of locked operations if you call m_mballoc and m_mballoc_wait with the mmbfree mutex held. for the interim you may have to drop the lock in m_mballoc before acquiring Giant and calling kmem_malloc with the M_NOWAIT flag. Eventually you should just be able to call kmem_malloc with the M_NOWAIT flag and not release you lock. You will be able to get rid of some of the the atomic_add_long()s. For m_mballoc_wait you can get rid of the immediate re-acquire of the lock on entry. You would need to make a version of MGET which doesn't acquire the lock for use inside these routines. If you really want only one version of the code you could do this my creating a lower level macro the MGET calls, with macro aguments that are non-existance or (mtx_enter(...) and mtx_exit(...)). You can then replace the asleep and await with a msleep(&mmbfree.m_mtx). The way the code is now you could end up with the wakeup occurring before you even call asleep and then never waking up. Also calling asleep and await are more expensive than a single call to msleep() You also don't want to be calling MBWAKEUP on every MFREE. You should hold the state you need to decided to do this under the mmbfree mutex which you are already getting and releasing. You don't want to call wakeupone if you don't have to, it is yet another locked operation. I put this together real quick so if it isn't clear I'll be glad to expand. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 23 11:43:46 2000 Delivered-To: freebsd-arch@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id 945B637B422; Sat, 23 Sep 2000 11:43:36 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.ca ([24.201.203.136]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G1C00MG5RZQMP@field.videotron.net>; Sat, 23 Sep 2000 14:43:03 -0400 (EDT) Date: Sat, 23 Sep 2000 14:46:44 -0400 (EDT) From: Bosko Milekic Subject: Re: mbuf system and SMPng In-reply-to: <200009231808.MAA18066@berserker.bsdi.com> To: Chuck Paterson Cc: freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 23 Sep 2000, Chuck Paterson wrote: > Bosko, > It looks like you can reduce the number of mutex operations > and the number of locked operations if you call m_mballoc and m_mballoc_wait > with the mmbfree mutex held. > > for the interim you may have to drop the lock in m_mballoc > before acquiring Giant and calling kmem_malloc with the M_NOWAIT flag. > Eventually you should just be able to call kmem_malloc with the > M_NOWAIT flag and not release you lock. Right, now that I look at it, MGET(HDR) can indeed be simplified a bunch by doing it this way. > You will be able to get rid of some of the the atomic_add_long()s. > > For m_mballoc_wait you can get rid of the immediate re-acquire > of the lock on entry. You would need to make a version of MGET which > doesn't acquire the lock for use inside these routines. If you really > want only one version of the code you could do this my creating a > lower level macro the MGET calls, with macro aguments that are non-existance > or (mtx_enter(...) and mtx_exit(...)). Indeed, the lock being released before the asleep() being called in m_mballoc_wait() is somewhat of a race. I was planning to get rid of the asleep/await combo anyway (noted in my journal). In fact, MGET() can be called even with the mutex held, it will just result in recursive grabbing of the mutex, but it's better to just re-arrange the macro with a lower-level one, as you say (I noticed BSD/OS does something like this). > You can then replace the asleep and await with a > msleep(&mmbfree.m_mtx). The way the code is now you could end up > with the wakeup occurring before you even call asleep and then > never waking up. Also calling asleep and await are more expensive > than a single call to msleep() Well, if it happens before asleep, it's not so bad because it will be woken up on the next MFREE(), since m_mballoc_wid will be incremented. But I agree that it should be changed to even rid ourselves of this race. > You also don't want to be calling MBWAKEUP on every MFREE. > You should hold the state you need to decided to do this under the mmbfree > mutex which you are already getting and releasing. You don't > want to call wakeupone if you don't have to, it is yet another > locked operation. Actually, MBWAKEUP() first makes sure to check m_mballoc_wid, and does so with the lock held, so it will not call wakeup_one() if nobody is sleeping. Note that MBWAKEUP() is always called with the necessary mutex held (whether it be the mclfree or mmbfree one). > I put this together real quick so if it isn't clear I'll be > glad to expand. > > Chuck Thanks, Chuck! I will be reviewing this tonight and rolling up a new diff. In the meantime, let me know if there's anything else... Cheers, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 23 12:15:47 2000 Delivered-To: freebsd-arch@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id 0272E37B422; Sat, 23 Sep 2000 12:15:42 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e8NJFdY07081; Sat, 23 Sep 2000 12:15:39 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma007074; Sat, 23 Sep 2000 12:15:15 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id MAA06552; Sat, 23 Sep 2000 12:15:14 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200009231915.MAA06552@bubba.whistle.com> Subject: Re: Dependency-based rc system (Was Re: sysctl on boot.) In-Reply-To: "from Kris Kennaway at Sep 21, 2000 06:12:32 pm" To: Kris Kennaway Date: Sat, 23 Sep 2000 12:15:14 -0700 (PDT) Cc: Neil Blakey-Milner , Marius Bendiksen , Warner Losh , arch@FreeBSD.ORG, sjr@home.net X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kris Kennaway writes: > > NetBSD has a nice working example, and I intend to port and reconstruct > > it for FreeBSD, and suggest we cross over. They apparently took a > > little hammering on the mailing lists, and I imagine we will too, but it > > does seem the obvious way forward, and we can sidestep many of the > > issues from what they've learnt and done. > > I also suggest you compare and contrast with Eivind's prototype version to > see if theres anything we can take from both. At Whistle we've thought a lot about this. On the InterJet we implemented this kind of dependency-based mechanism which is not ideal, but works pretty good. FWIW, here are some thoughts.. - Define a "module" as something that has a "start" method that derives its configuration fro the DB, and a "stop" method. Optionally it may have a "restart" that functions as an atomic stop and start (think SIGHUP). More generally a module is something that needs to be configured and may or may not actually "run". Examples: sendmail, named, apache... but also network interfaces, kernel routing table, system hostname. - There is always (either implicitly or explicitly) a database of configuration information from which all "modules" are configured. This DB contains all configuration information for the administration domain, in our case: hostname, IP addresses, routing info, forwarding nameservers, etc. Ideally, there would be an explicit DB and all code would reference it directly.. in the real world, however, every subsystem has its own configuration file format or whatever -- and these all represent redundant copies. Think of how many things you need to reconfigure when you change an IP address, or a hostname, etc.. - Modules may depend on other modules, i.e., module A may require that module B is running before module A will function correctly (think sendmail -> named). In fact, there is a finer distinction: module A can only require that module B is running, or it can additionally require that module B is running *with a consistent configuration* (i.e., B is running based on the same contents of the DB as A is). The latter dependency type is usually but not always the case (e.g., sendmail -> DNS). As an example of the former, consider that an FTP client requires that the IP interfaces be configured.. but it doesn't care what the actual IP addresses are. Also, sometimes A only requires that B is running when A is started: stopping B once A is already going is allowed. - Ideally, the logic that determines when a code module must be stopped, started, or restarted is kept with that module. That is, each module should know which fields of the DB must change before it requires a (reconfiguration and) restart. Part of the start process is copying this data out of the DB and into the module-specific configuration file (or whatever). Also, each module should know what other modules it depends on (rather than the other way around). - Following this idea, when the administrator wants to change something (say, his domain name) then (s)he simply makes the change in the DB.. then, each module (or some representative) independently notices the relevant change(s) and, if necessary, schedules the module to be restarted. A separate restart manager collects all the restart requests, enforces the dependencies, and actually performs all of the stop and start operations. - The DB must be transactional for this to work properly. E.g., the restart managager must know when all of the requests are in. - Any system should allow for dynamic registration of new code modules into the system (e.g., think about ports). This can work if each code module knows what configuration information it depends on and what other modules it depends on. A new module could even add new fields (or whatever) to the database. - Of course, the user interface is a whole separate question. But in any case, its design is completely separate from all of this. All it has to know about is what fields are in the database. Has it ever bothered you that when you change your IP address on a Windows machine you have to reboot?? That's because they don't have this kind of system. Neither does UNIX of course; instead, it's the administrator's problem to do all of the above manually :-) -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 23 12:45:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id E5CDB37B424; Sat, 23 Sep 2000 12:45:29 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e8NJhAk07190; Sat, 23 Sep 2000 12:43:10 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma007188; Sat, 23 Sep 2000 12:42:54 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id MAA06755; Sat, 23 Sep 2000 12:42:47 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200009231942.MAA06755@bubba.whistle.com> Subject: Re: Mutexes and semaphores (was: cvs commit: src/sys/conf files src/sys/sys random.h src/sys/dev/randomdev hash.c hash.h harvest.c randomdev.c yarrow.c yarro) In-Reply-To: <200009130027.e8D0RrH91664@hak.lan.Awfulhak.org> "from Brian Somers at Sep 13, 2000 01:27:53 am" To: Brian Somers Date: Sat, 23 Sep 2000 12:42:47 -0700 (PDT) Cc: Joerg Micheel , Greg Lehey , Matthew Jacob , Frank Mayhar , John Baldwin , Mark Murray , FreeBSD-arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian Somers writes: > > None, if it comes to the actual usage and implementation. Usually, > > people will use semaphores for locking blocks of code, mutexes for > > data structures. Not much of a difference in the end result, but > > locking data structures seems more natural to me. > > I would tend to disagree. > > A mutex is a way of guaranteeing that a resource isn't used more than > once. A semaphore is a mechanism for queuing a notification to a > (potentially) waiting process. > > A mutex is just a binary semaphore, but I don't think that's > relevant. This discussion (sorry I'm joining a week late) is somewhat fascinating to me, because everybody seems to have a slightly different definition of things. Now I don't know what to think :-) Does the following make sense? A SPIN LOCK is only used to serialize threads' access to data. A spin lock "protects" some region of memory. At the time a spin lock is acquired, you always know the data is in a consistent state. Moreover, a thread should never have to block on a spin lock for any longer than it takes the other thread(s) to access the protected data (and do nothing else!). All threads either holding or blocking on a spin lock are always "runnable" in a sense. It is illegal to "sleep" while holding a spin lock -- instead, you should arrange the data in a consistent state, release the spin lock, and then sleep. When you wake up, reacquire the spin lock. Since most data structures are small, spin lock hold times should be small and contention hopefully low. Therefore, spin-waiting is a feasible choice to implement spin lock blocking. There is no queue associated with a spin lock. Once you have the spin lock primitive, you can easily build semaphores, sleep queues, etc. A semaphore is just a counter plus a sleep queue -- all protected by the spin lock. A MUTEX is just a sepaphore whose initial count is 1. ?? -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 23 13:27:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp.med.und.nodak.edu (smtp.med.und.NoDak.edu [134.129.166.20]) by hub.freebsd.org (Postfix) with ESMTP id 0672637B42C for ; Sat, 23 Sep 2000 13:27:39 -0700 (PDT) Received: from localhost.med.und.nodak.edu ([127.0.0.1] helo=geocities.com) by smtp.med.und.nodak.edu with esmtp (Exim 3.16 #1) id 13cvtY-0006Ik-00 for arch@freebsd.org; Sat, 23 Sep 2000 15:27:37 -0500 Message-ID: <39CD0C1B.324AA1C5@geocities.com> Date: Sat, 23 Sep 2000 15:01:31 -0500 From: Barry Pederson X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: arch@freebsd.org Subject: Re: Snapshots in the Fast Filesystem References: <200007060342.UAA23667@beastie.mckusick.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kirk McKusick wrote: > > I have completed an initial implementation of snapshots for the > fast filesystem (UFS/FFS). I have put up a tarball on > > http://people.freebsd.org/~mckusick/snap.tgz > > I am looking for comments and feedback on these changes. I am > proposing to put them into 5.0-current on Tuesday July 11th > unless I get feedback indicating that folks are not happy > with this addition. Enclosed below is the README file that > is included in the above tarball. > .................... > > So, as you can see, this is definitely alpha-quality code. > Much remains to be done to make it really useful in > production systems. But, I wanted to let folks get a chance > to try it out and start reporting bugs. I've been fooling with this in 5.0-CURRENT, and have have found it to be a terribly, terribly cool feature. In trying to setup some scripts to automatically take snapshots on a daily basis, I came up with a few questions... Is there (or will there be) some way to get a list of snapshots that have been created on a filesystem? Kirk suggests following a convention for naming snapshot files, but if that doesn't happen for some reason, it would be good to have some foolproof way of determining what snaps exist. Otherwise, I suppose you could search a filesystem for files that -appear- to be almost as large as the filesystem itself, but that seems kind of a kludge - and I don't know if I'd want to trust a script to interpret those results correctly. Since snapshots can be mounted using vn devices, I was similarly wondering if there's a good way of determining if a particular vn device is already configured, and if so, which particular file it's using. (man vnconfig didn't seem to mention anything like this) (it seems to me that if you can create and configure 'things' in the OS, there should be some way to discover what's been created and/or how things have been configured) Kirk gives the example of mounting a snapshot by using a 'vn0c' device - I was wondering if the 'c' part of those device names is significant? Could you mount additional snapshots using 'vn0a', 'vn0b' and so on? or should a person stick to creating and using (as I've tried and found to work well) 'vn1c', 'vn2c', and so on? (That may be a bit of a newbie-unix question, but since I was asking about snapshots I thought I'd throw it out). Lastly, I'm curious if it's possible that snapshots will be MFC'd into 4.x at some point? or will this be a 5.0 and up only feature? Barry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 23 13:39:13 2000 Delivered-To: freebsd-arch@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id 86C1E37B42C; Sat, 23 Sep 2000 13:39:11 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e8NKdBt07441; Sat, 23 Sep 2000 13:39:11 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma007439; Sat, 23 Sep 2000 13:39:05 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id NAA06894; Sat, 23 Sep 2000 13:39:05 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200009232039.NAA06894@bubba.whistle.com> Subject: Re: sysctl MIB and kernel internals In-Reply-To: "from Robert Watson at Sep 15, 2000 12:26:56 pm" To: Robert Watson Date: Sat, 23 Sep 2000 13:39:05 -0700 (PDT) Cc: freebsd-arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert Watson writes: > I'd like to see us consider moving to an alternative model, divorcing the > implementation internals of various kernel objects (processes, et al) from > the MIB interface retrieving management data about them. I.e., struct > proc would continue to be used in kernel, but relevant fields would be > copied to struct export_proc for export via sysctl. In addition, it would > be worth prefixing these exported structures with a version number > allowing the caller to determine if they support an appropriate version of > the interface, allowing a more comprehensible error. Only fields > desirable to export would be in export_proc, so if an extra pointer is > added to struct ucred (recent resource control changes, capabilities), an > extra pointer to struct proc (jail), etc won't needless break userland > tools. One semi-remote possibility would be to use the netgraph/ng_parse.h library to convert all binary structures into ASCII form (and only the relevant fields). ng_parse is basically a C structure <-> ASCII translation library. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 23 13:58:29 2000 Delivered-To: freebsd-arch@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id F16EE37B422; Sat, 23 Sep 2000 13:58:26 -0700 (PDT) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel3.hp.com (Postfix) with ESMTP id 82FD0987; Sat, 23 Sep 2000 13:58:26 -0700 (PDT) Received: from cup.hp.com (p1000180.nsr.hp.com [15.109.0.180]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id NAA03648; Sat, 23 Sep 2000 13:58:25 -0700 (PDT) Message-ID: <39CD1971.874C72A6@cup.hp.com> Date: Sat, 23 Sep 2000 13:58:25 -0700 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: Kris Kennaway , arch@FreeBSD.ORG, sjr@home.net Subject: Re: sysctl on boot. References: <200009182209.QAA33920@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > In message Kris Kennaway writes: > : On Sun, 17 Sep 2000, Warner Losh wrote: > : > : > A short term fix is to just rerun /etc/rc.sysctl at the end of the > : > boot sequence, just before the secrelevel change. Stephen's PR > : > suggests this with a patch. I think it is good, but wanted to get > : > some feedback from others before doing this. > : > : rc.sysctl_early and rc.sysctl_late? > > I worry about a gratuitous change to the name. However, I could > easily see rc.sysctl have an early file and a late one settable by > rc.conf rc.sysctl could be made to work in stages. It could be given the stage as an argument, or could determine the stage by itself. Working in stages abstracts better than the creation of files and can be made as complex as necessary. -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 23 14: 6:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id A5A7337B424 for ; Sat, 23 Sep 2000 14:06:30 -0700 (PDT) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel3.hp.com (Postfix) with ESMTP id 8B4FBAFF; Sat, 23 Sep 2000 14:06:29 -0700 (PDT) Received: from cup.hp.com (p1000180.nsr.hp.com [15.109.0.180]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id OAA03846; Sat, 23 Sep 2000 14:06:28 -0700 (PDT) Message-ID: <39CD1B54.48195358@cup.hp.com> Date: Sat, 23 Sep 2000 14:06:28 -0700 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Daniel C. Sobral" Cc: Warner Losh , John DeBoskey , freebsd-arch@FreeBSD.ORG Subject: Re: Comments requested: automatic hook for mergemaster References: <20000917211609.A9550@unx.sas.com> <200009180042.SAA26812@harmony.village.org> <200009180148.TAA27247@harmony.village.org> <39C634EB.EFBE77AA@newsguy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" wrote: > > > In message <20000917211609.A9550@unx.sas.com> John DeBoskey writes: > > : What happens to a nightly 'make world' process if DO_MERGEMASTER > > : is defined? We'd need a completely non-interactive approach > > : to make this work (I'm not 100% familiar with mergemaster's > > : internal workings). > > > > If DO_MERGEMASTER is defined, the build is no longer automatic. Now > > that I think about it, it might not be such a good idea. > > I disagree. Having a non-automatic option will not make the process > non-automatic, as long as that option is not used. > > So, what happens is that nothing changes for anyone, except those that > explicitly define the option. Those who do will have their installworld > hanged waiting for input. (Well, unless -a is used for mergemaster -- > but I like the interactive version myself.) I envision the installworld target to be used in an upgrade target. Running mergemaster is more a task for such a target than it is for installworld. I therefore don't think we should add the hook to installworld. It can be added to a possible future upgrade target, though. -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 23 15:35:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 8688E37B42C; Sat, 23 Sep 2000 15:35:47 -0700 (PDT) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id QAA19401; Sat, 23 Sep 2000 16:35:27 -0600 (MDT) Message-Id: <200009232235.QAA19401@berserker.bsdi.com> To: Bosko Milekic Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: mbuf system and SMPng In-reply-to: Your message of "Sat, 23 Sep 2000 14:46:44 EDT." From: Chuck Paterson Date: Sat, 23 Sep 2000 16:35:27 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG } } Actually, MBWAKEUP() first makes sure to check m_mballoc_wid, and } does so with the lock held, so it will not call wakeup_one() if nobody is } sleeping. Note that MBWAKEUP() is always called with the necessary mutex } held (whether it be the mclfree or mmbfree one). } Right, you are. When you change the this it looks like you can also get rid of the atomic op in MBWAKEUP. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 23 15:43:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 834A237B422; Sat, 23 Sep 2000 15:43:14 -0700 (PDT) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id QAA19490; Sat, 23 Sep 2000 16:43:07 -0600 (MDT) Message-Id: <200009232243.QAA19490@berserker.bsdi.com> To: Bosko Milekic Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: mbuf system and SMPng In-reply-to: Your message of "Sat, 23 Sep 2000 14:46:44 EDT." From: Chuck Paterson Date: Sat, 23 Sep 2000 16:43:07 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Date: Sat, 23 Sep 2000 14:46:44 -0400 From: Bosko Milekic To: Chuck Paterson Subject: Re: mbuf system and SMPng cc: freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Bosko Milekic wrote on: Sat, 23 Sep 2000 14:46:44 EDT } Indeed, the lock being released before the asleep() being called in } m_mballoc_wait() is somewhat of a race. I was planning to get rid of the } asleep/await combo anyway (noted in my journal). In fact, MGET() can be } called even with the mutex held, it will just result in recursive } grabbing of the mutex, but it's better to just re-arrange the macro with } a lower-level one, as you say (I noticed BSD/OS does something like } this). } One thing to remember about the recursive stuff is that passing a recursively held mutex to msleep() will not get the mutex released, it will only release it one time. This means that you likely won't be able to get a wakeup. This could be changed, but ->>in general<<- something has gone very wrong if the mutex passed in to msleep() is recursively held. There is likely a layer of code that is expecting that its data is protected, and is not expecting some other process to be able to get at it. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 23 16:40: 9 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 59E7837B43E; Sat, 23 Sep 2000 16:39:45 -0700 (PDT) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8NNdMi98638; Sat, 23 Sep 2000 16:39:26 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.0/8.11.0) id e8NNbqS18868; Sat, 23 Sep 2000 16:37:52 -0700 (PDT) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200009232243.QAA19490@berserker.bsdi.com> Date: Sat, 23 Sep 2000 16:37:51 -0700 (PDT) Organization: BSD, Inc. From: John Baldwin To: Chuck Paterson Subject: Re: mbuf system and SMPng Cc: freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG, Bosko Milekic Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Sep-00 Chuck Paterson wrote: > > Date: Sat, 23 Sep 2000 14:46:44 -0400 > From: Bosko Milekic > To: Chuck Paterson > Subject: Re: mbuf system and SMPng > cc: freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG > > Bosko Milekic wrote on: Sat, 23 Sep 2000 14:46:44 EDT > > } Indeed, the lock being released before the asleep() being called in > } m_mballoc_wait() is somewhat of a race. I was planning to get rid of the > } asleep/await combo anyway (noted in my journal). In fact, MGET() can be > } called even with the mutex held, it will just result in recursive > } grabbing of the mutex, but it's better to just re-arrange the macro with > } a lower-level one, as you say (I noticed BSD/OS does something like > } this). > } > > One thing to remember about the recursive stuff is that > passing a recursively held mutex to msleep() will not get the > mutex released, it will only release it one time. This means > that you likely won't be able to get a wakeup. This could > be changed, but ->>in general<<- something has gone very wrong > if the mutex passed in to msleep() is recursively held. There > is likely a layer of code that is expecting that its data is protected, > and is not expecting some other process to be able to get at it. Hmm, do we want to add a KASSERT() to msleep() then to verify that the mutex isn't recursed when we release it? > Chuck -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 23 16:54:45 2000 Delivered-To: freebsd-arch@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 53F9637B424; Sat, 23 Sep 2000 16:54:42 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.ca ([24.201.203.136]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G1D00H836F4KM@falla.videotron.net>; Sat, 23 Sep 2000 19:54:40 -0400 (EDT) Date: Sat, 23 Sep 2000 19:58:20 -0400 (EDT) From: Bosko Milekic Subject: Re: mbuf system and SMPng In-reply-to: To: John Baldwin Cc: freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 23 Sep 2000, John Baldwin wrote: > Hmm, do we want to add a KASSERT() to msleep() then to verify > that the mutex isn't recursed when we release it? Yes... This is very important for the work that I'm doing because, although it would be out of the ordinary, I don't want to trip over some obfuscated way a protocol drain routine may end up in one of the mbuf "wait" routines (theoretically, this isn't possible, but let's just be 101% sure). Are you going to do it, or shall I? > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ Cheers, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 23 17:15:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 88A7437B42C; Sat, 23 Sep 2000 17:15:38 -0700 (PDT) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8O0FMi99151; Sat, 23 Sep 2000 17:15:22 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.0/8.11.0) id e8O0Dqg19141; Sat, 23 Sep 2000 17:13:52 -0700 (PDT) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sat, 23 Sep 2000 17:13:51 -0700 (PDT) Organization: BSD, Inc. From: John Baldwin To: Bosko Milekic Subject: Re: mbuf system and SMPng Cc: freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Sep-00 Bosko Milekic wrote: > > On Sat, 23 Sep 2000, John Baldwin wrote: > >> Hmm, do we want to add a KASSERT() to msleep() then to verify >> that the mutex isn't recursed when we release it? > > Yes... This is very important for the work that I'm doing because, > although it would be out of the ordinary, I don't want to trip over some > obfuscated way a protocol drain routine may end up in one of the mbuf > "wait" routines (theoretically, this isn't possible, but let's just be > 101% sure). > Are you going to do it, or shall I? I'm testing to make sure it builds ok, and I'll commit it once it does. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 23 20: 4:16 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 948CC37B424; Sat, 23 Sep 2000 20:04:13 -0700 (PDT) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id VAA20719; Sat, 23 Sep 2000 21:02:49 -0600 (MDT) Message-Id: <200009240302.VAA20719@berserker.bsdi.com> To: Archie Cobbs Cc: Brian Somers , Joerg Micheel , Greg Lehey , Matthew Jacob , Frank Mayhar , John Baldwin , Mark Murray , FreeBSD-arch@freebsd.org Subject: Re: Mutexes and semaphores (was: cvs commit: src/sys/conf files src/sys/sys random.h src/sys/dev/randomdev hash.c hash.h harvest.c randomdev.c yarrow.c yarro) In-reply-to: Your message of "Sat, 23 Sep 2000 12:42:47 PDT." <200009231942.MAA06755@bubba.whistle.com> From: Chuck Paterson Date: Sat, 23 Sep 2000 21:02:49 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG }Once you have the spin lock primitive, you can easily build }semaphores, sleep queues, etc. A semaphore is just a counter plus }a sleep queue -- all protected by the spin lock. } }A MUTEX is just a sepaphore whose initial count is 1. } }?? In general this might be true, but in specific it isn't. The sleep version of mutexs have no spin lock. Spin locks are more expensive than the mutices currently in FreeBSD and BSD/OS. In order to acquire a spin locks interrupts must be blocked, which isn't the case for mutices which are not contested. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 23 23:13:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 44CB737B43C; Sat, 23 Sep 2000 23:13:37 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e8O6CGe35439; Sun, 24 Sep 2000 15:42:16 +0930 (CST) (envelope-from grog) Date: Sun, 24 Sep 2000 15:42:16 +0930 From: Greg Lehey To: Chuck Paterson Cc: Archie Cobbs , Brian Somers , Joerg Micheel , Matthew Jacob , Frank Mayhar , John Baldwin , Mark Murray , FreeBSD-arch@freebsd.org Subject: Re: Mutexes and semaphores (was: cvs commit: src/sys/conf files src/sys/sys random.h src/sys/dev/randomdev hash.c hash.h harvest.c randomdev.c yarrow.c yarro) Message-ID: <20000924154216.D512@wantadilla.lemis.com> References: <200009231942.MAA06755@bubba.whistle.com> <200009240302.VAA20719@berserker.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200009240302.VAA20719@berserker.bsdi.com>; from cp@bsdi.com on Sat, Sep 23, 2000 at 09:02:49PM -0600 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Saturday, 23 September 2000 at 21:02:49 -0600, Chuck Paterson wrote: > >> Once you have the spin lock primitive, you can easily build >> semaphores, sleep queues, etc. A semaphore is just a counter plus >> a sleep queue -- all protected by the spin lock. >> >> A MUTEX is just a sepaphore whose initial count is 1. >> >> ?? > > In general this might be true, but in specific it isn't. As you know, I used to say exactly the same thing as Archie, but I've realized that this implied count of 1 causes a couple of important differences. I'm still working on a clearer definition, but what I've seen so far is: 1. Because "mutexes" (I really hate this term; I wish I could find a better one) only have an implied count of one, they can also have the concept of an owner, which we use. 2. Because the mutex has an owner, only the owner can release it. 3. The mutex can also be "recursive" (it's really iterative, I suppose): the owner can take it several times. The only reason for this appears to be sloppy coding, but in the short term I think we're agreed that we can't dispose of that. One thing that I don't think is important is the duration of ownership. We currently use mutexes for short periods of time, which is why we have the spin version. At Tandem, we only used semaphores, but they always had a count of 1, so they were effectively very close to our mutexes. They didn't allow recursion, which is the Right Thing in a system designed from the ground up, but they also didn't have owners. One of the most frequent complicated problems we had were system hangs (deadlocks), and we frequently couldn't figure out who had done what and why. Having owners is a great debug aid. > The sleep version of mutexs have no spin lock. Spin locks are more > expensive than the mutices currently in FreeBSD and BSD/OS. In > order to acquire a spin locks interrupts must be blocked, which > isn't the case for mutices which are not contested. If we can expect that the mutex will, on average, be freed in less time than it would take to schedule a new process, spin locks can be a better alternative. Otherwise we wouldn't need them at all. Anyway, this doesn't directly relate to semaphores. We have the basic issue of atomicity, which in general can be handled without spin locks, and that would apply to semaphores just as much as to mutexes. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 23 23:19: 9 2000 Delivered-To: freebsd-arch@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id 5584337B422; Sat, 23 Sep 2000 23:19:02 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.ca ([24.201.203.136]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G1D0042JO7OXQ@field.videotron.net>; Sun, 24 Sep 2000 02:19:00 -0400 (EDT) Date: Sun, 24 Sep 2000 02:22:41 -0400 (EDT) From: Bosko Milekic Subject: Re: mbuf system and SMPng (new revised diff) In-reply-to: To: Chuck Paterson Cc: freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Following Chuck Paterson's suggestions, I've reviewed the mbuf diff once again and diff'ed up a new revised version: http://people.freebsd.org/~bmilekic/mbuf_mtx-v6.diff I've really "axed" up sys/sys/mbuf.h, and have seperated the macros into more logical divisions, and ones that minimize code bloat (in fact, the diff is a TAD smaller, ~1.5k smaller). In effect, I've gotten rid of m_mballoc_wait_hdr and now just use m_mballoc_wait; much cleaner. Following Chuck's advice, I've minimized the hysterics over grabbing locks before and after the allocator routines. The only thing to note is that despite a mutex being held, certain mbstat members still need to be manipulated with atomic()s as they may sometimes be modified from code holding the mmbfree lock, and sometimes from code holding the mclfree lock (there are only 2 such members, if I recall). If you're reviewing, be sure to carefully look at the changes in sys/sys/mbuf.h. I've also tested this diff under heavy network load and a local mbuf starvation simulation, and it seemed to hold up pretty well (on UP hardware). Same deal for this version of the diff as before, comments/reports requested! Cheers, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message