From owner-freebsd-arch@FreeBSD.ORG Sun May 29 11:14:32 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FE0016A41C for ; Sun, 29 May 2005 11:14:32 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAE0B43D1D for ; Sun, 29 May 2005 11:14:31 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 1461F46B28; Sun, 29 May 2005 07:14:31 -0400 (EDT) Date: Sun, 29 May 2005 12:14:48 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Scott Long In-Reply-To: <4298E316.9020303@samsco.org> Message-ID: <20050529121224.L52379@fledge.watson.org> References: <4298E316.9020303@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eriksson , freebsd-arch@freebsd.org Subject: Re: MPSAFE CAM? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2005 11:14:32 -0000 On Sat, 28 May 2005, Scott Long wrote: > If anyone wants to help tackle this, I'd be glad to help them get > started. BSD/OS 5.(mumble) did a minimal locking job on CAM that > probably works OK for systems with a single SCSI port, but likely gets > very inefficient once you go beyond that. They also rewrote the SCSI > probe state machine, which in our CAM is a source for quite a bit of > lock recursion. The work I did last year focused on addressing this. The good news is that with VFS and UFS out from under Giant, code left running under Giant experiences a lot less contention than it used to. So once the interrupt handler can run to completion without Giant in a CAM driver, we've gained many of the benefits of making MPSAFE. Especially if we can knock Giant off a lot of the remaining non-CAM device drivers that it's still stuck over. Another area that requires further attention is the tty code and tty drivers. It sounds like phk has some plans in this space, and as I told him at BSDCan, I'm happy to do the network side of tty-connected network code, if he takes care of the tty side. Once this is done, maybe someone can give another try at syscons... Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Sun May 29 12:05:21 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C87416A41C; Sun, 29 May 2005 12:05:21 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from pasmtp.tele.dk (pasmtp.tele.dk [193.162.159.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17B1E43D49; Sun, 29 May 2005 12:05:21 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (0x535c0e2a.sgnxx1.adsl-dhcp.tele.dk [83.92.14.42]) by pasmtp.tele.dk (Postfix) with ESMTP id 1B1361EC312; Sun, 29 May 2005 14:05:17 +0200 (CEST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.3) with ESMTP id j4TC5BG8020980; Sun, 29 May 2005 14:05:11 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Robert Watson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 29 May 2005 12:14:48 BST." <20050529121224.L52379@fledge.watson.org> Date: Sun, 29 May 2005 14:05:11 +0200 Message-ID: <20979.1117368311@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Daniel Eriksson , freebsd-arch@FreeBSD.org Subject: Re: MPSAFE CAM? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2005 12:05:21 -0000 In message <20050529121224.L52379@fledge.watson.org>, Robert Watson writes: >Another area that requires further attention is the tty code and tty >drivers. It sounds like phk has some plans in this space, and as I told >him at BSDCan, I'm happy to do the network side of tty-connected network >code, if he takes care of the tty side. Once this is done, maybe someone >can give another try at syscons... I hope to attack this over summer. It's not as simple as it sounds, mainly because of the console and SLIP/PPP/NETGRAPH linedisciplines, but I'll be more than happy to let someone else beat me to this :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sun May 29 14:07:57 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 485B416A41C; Sun, 29 May 2005 14:07:57 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id C996743D4C; Sun, 29 May 2005 14:07:56 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring [10.0.0.2]) by itchy.rabson.org (8.13.3/8.12.11) with ESMTP id j4TE7qoG054378; Sun, 29 May 2005 15:07:52 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-arch@freebsd.org Date: Sun, 29 May 2005 15:07:49 +0100 User-Agent: KMail/1.8 References: <20050528150815.X29776@fledge.watson.org> In-Reply-To: <20050528150815.X29776@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505291507.50289.dfr@nlsystems.com> X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on itchy.rabson.org X-Virus-Scanned: ClamAV 0.83/898/Sat May 28 06:11:03 2005 on itchy.rabson.org X-Virus-Status: Clean Cc: Robert Watson , arch@freebsd.org, Suleiman Souhlal Subject: Re: [PATCH] Stackgap X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2005 14:07:57 -0000 On Saturday 28 May 2005 15:10, Robert Watson wrote: > On Fri, 27 May 2005, Suleiman Souhlal wrote: > > You can find an implementation of stackgap from OpenBSD at http:// > > people.freebsd.org/~ssouhlal/testing/stackgap-20050527.diff > > > > You can control the range of the random stack gap with the > > kern.stackgap_random sysctl. A value of 0 disables it. Otherwise, > > it has to be a power of 2 and not too large. The default value is > > 64K. > > > > I've only had the chance to test this on i386. Could anyone test it > > on other architectures as well? > > > > Any comments/objections? > > In the past, substantial performance hits have been measured due to > poor stack alignment. Specifically, in combination with less optimal > compiler behavior, the results have been pretty nasty. Have you > tried micro-benchmarking a series of runs with this stack offset > randomness using floating point on stack arguments to see if there's > a measurable cost to moving the stack around? Hopefull if all is > well, there will be little or no difference, but a small error here > could result in a substantial performance hit... I recently modified the crt code to force the stack alignment to 16 bytes on startup (so that I could safely write code that uses movaps). From owner-freebsd-arch@FreeBSD.ORG Sun May 29 14:07:57 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 485B416A41C; Sun, 29 May 2005 14:07:57 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id C996743D4C; Sun, 29 May 2005 14:07:56 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring [10.0.0.2]) by itchy.rabson.org (8.13.3/8.12.11) with ESMTP id j4TE7qoG054378; Sun, 29 May 2005 15:07:52 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-arch@freebsd.org Date: Sun, 29 May 2005 15:07:49 +0100 User-Agent: KMail/1.8 References: <20050528150815.X29776@fledge.watson.org> In-Reply-To: <20050528150815.X29776@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505291507.50289.dfr@nlsystems.com> X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on itchy.rabson.org X-Virus-Scanned: ClamAV 0.83/898/Sat May 28 06:11:03 2005 on itchy.rabson.org X-Virus-Status: Clean Cc: Robert Watson , arch@freebsd.org, Suleiman Souhlal Subject: Re: [PATCH] Stackgap X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2005 14:07:57 -0000 On Saturday 28 May 2005 15:10, Robert Watson wrote: > On Fri, 27 May 2005, Suleiman Souhlal wrote: > > You can find an implementation of stackgap from OpenBSD at http:// > > people.freebsd.org/~ssouhlal/testing/stackgap-20050527.diff > > > > You can control the range of the random stack gap with the > > kern.stackgap_random sysctl. A value of 0 disables it. Otherwise, > > it has to be a power of 2 and not too large. The default value is > > 64K. > > > > I've only had the chance to test this on i386. Could anyone test it > > on other architectures as well? > > > > Any comments/objections? > > In the past, substantial performance hits have been measured due to > poor stack alignment. Specifically, in combination with less optimal > compiler behavior, the results have been pretty nasty. Have you > tried micro-benchmarking a series of runs with this stack offset > randomness using floating point on stack arguments to see if there's > a measurable cost to moving the stack around? Hopefull if all is > well, there will be little or no difference, but a small error here > could result in a substantial performance hit... I recently modified the crt code to force the stack alignment to 16 bytes on startup (so that I could safely write code that uses movaps). From owner-freebsd-arch@FreeBSD.ORG Sun May 29 16:57:27 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F03C616A41C for ; Sun, 29 May 2005 16:57:26 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id A222C43D1D for ; Sun, 29 May 2005 16:57:26 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix4-2.free.fr (Postfix) with ESMTP id 3A2BD31D93C; Sun, 29 May 2005 18:57:25 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 56123407E; Sun, 29 May 2005 18:57:19 +0200 (CEST) Date: Sun, 29 May 2005 18:57:19 +0200 From: Jeremie Le Hen To: Marc Olzheim Message-ID: <20050529165719.GF54337@obiwan.tataz.chchile.org> References: <1117139065.82793.20.camel@opus.cse.buffalo.edu> <20050527091750.GB91258@stack.nl> <1117195655.88498.9.camel@opus.cse.buffalo.edu> <20050527131014.GA93850@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527131014.GA93850@stack.nl> User-Agent: Mutt/1.5.9i Cc: Ken Smith , freebsd-arch@freebsd.org Subject: Re: Modifying file access time upon exec... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2005 16:57:27 -0000 Hi Marc, Ken, > > I'm not sure why you say NFS filesystems can't be mounted with noatime. > > No, I'm saying that there are filesystems you wouldn't want to mount > with noatime (/tmp, /var/tmp, /var/mail, /var/spool/*) because some > software depends on the atime being adjusted. I thought that, according to the goal of this patch, the "noatime" option you were talking about would be in fact a "noatime-on-exec" option. Access time would be still updated on other cases. Am I wrong ? Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-arch@FreeBSD.ORG Sun May 29 17:37:33 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64F0416A41C for ; Sun, 29 May 2005 17:37:33 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1135043D1D for ; Sun, 29 May 2005 17:37:30 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j4THcscD061546; Sun, 29 May 2005 11:38:55 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4299FD87.1000505@samsco.org> Date: Sun, 29 May 2005 11:36:07 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <20050525.212009.71136852.nyan@jp.FreeBSD.org> <20050525.111945.41668351.imp@bsdimp.com> In-Reply-To: <20050525.111945.41668351.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: "Justin T. Gibbs" , arch@freebsd.org, nyan@jp.FreeBSD.org Subject: Re: [RFC] remove bus_memio.h and bus_pio.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2005 17:37:33 -0000 M. Warner Losh wrote: > In message: <20050525.212009.71136852.nyan@jp.FreeBSD.org> > Takahashi Yoshihiro writes: > : The bus_memio.h and bus_pio.h for a micro-optimization depend on the > : implementation of the bus_space on i386 and amd64, so they are > : meaningless files on the other archs. I'd like to remove a MD part > : like this from MI drivers at least. > : > : I think that a increasing performance by using this method is very > : trivial on recent machines. If there is not strong objection, I'll > : remove bus_{mem,p}io.h and related code from all archs. > : > : Comments? > > Short answer: > > Great idea. aac and bfe should be tested after the change to > see if there is any benefit for them. Other drivers almost > certainly will see no benefit from this. > > Longer, more detailed answer. > > The original idea was to provide a hint to busspace that this driver > only ever used a certain subset of the available mappings so it should > assume that subset and agressively optimize the code. The assumption > was that one could know at compile time that one would never use > certain features. In an i386 centric world, this made good sense, > especially since the bus_space_* macros expanded to inb or whatever > and nothing else (compiler technology innovations may have changed > this over time). > > You are correct in that other architectures might have more than two > kinds of address space, might have other complicating factors. pc98 > has, as you know, an indirect vector because devices on the > motherboard and cbus are rarely mapped at contiguous locations due to > the dual 8-bit bus nature of the internal buses. In that case it > makes no sense to do any optimization at all, and these files should > be empty for such an implementation. > > Alpha, sparc64, powerpc and arm all have much more complex bus space > implementations due to their greater intra-architectural differences, > as well as their large difference with i386. To similarly optimize > these architectures, one would need additional MD info to know how to > inline things. None of them have chosen to support this level of > optimization. It is unclear to me how big a win such optimiztion > would be, even on the slower CPUs some of these platforms support. > > The lowest end of FreeBSD/i386 these days[*] is likely a Pentium II > running at 300MHz or a soekris box. The 4510 box is still only > 166MHz. However, the only device that it has that are likely to > benefit from this is sio. Well, in extreme cases, one could make the > case for any pci card or pccard, but I think that's too extreme to > consider. Since the soekris box has only one free serial port, we > need only keep up with a ppp connection on that serial port, so I'm > pretty sure we're OK. > > A number of drivers include only one of these two include files: > ti, bfe, trm, stg, scd, aac, kbd, ie, idt, hfa, gfb, fb, dpt, > cnw, aic, aha, ahb, adv > and some of the mii phy drivers, plus some other trivial uses. > > The only ones on the list that stand out are bfe and aac (the dpt > optimization is only for EISA cards, and only for the EISA specific > portions of the driver). I do not know how much this optimization > helps these devices, but they are the only ones that I see might be > affected. Simple benchmarks should be easy enough to do on aac and > bfe. > > Warner > > [*] Yes, I know that slower CPUs are supported, and do still perform > decently if you have enough memory. This is an arbitrary cutoff for > the cost-benefit analysis. This kind of makes me sad. I don't see how this was harming anything, it just wasn't documented so people didn't know how to use it. If it didn't apply to non-i386 and amd64, fine, just don't implement it for those platform. This optimization might have seemed trivial, but it's all of the little trivial optimizations that add up to make a nice system. I'm guessing that Justin only put effort into this originally because he did see a benefit; discounting it without doing any testing of your own is a bit disingenuous. Scott From owner-freebsd-arch@FreeBSD.ORG Mon May 30 02:33:01 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF25116A41C for ; Mon, 30 May 2005 02:33:01 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from sp.dominia.org (efnet-math.org [69.60.109.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FD6E43D1F; Mon, 30 May 2005 02:33:01 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.0.99] (pool-151-200-57-83.res.east.verizon.net [151.200.57.83]) (authenticated bits=0) by sp.dominia.org (8.13.1/8.13.1) with ESMTP id j4U2Wtwx020758 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 29 May 2005 22:33:00 -0400 In-Reply-To: <20050528150815.X29776@fledge.watson.org> References: <20050528150815.X29776@fledge.watson.org> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9001CAE4-ECF1-4417-91F3-BAC1FC0A03CE@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Suleiman Souhlal Date: Sun, 29 May 2005 22:32:50 -0400 To: Robert Watson X-Mailer: Apple Mail (2.730) Cc: arch@FreeBSD.org Subject: Re: [PATCH] Stackgap X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2005 02:33:02 -0000 Hi, On May 28, 2005, at 10:10 AM, Robert Watson wrote: > > On Fri, 27 May 2005, Suleiman Souhlal wrote: > > >> You can find an implementation of stackgap from OpenBSD at http:// >> people.freebsd.org/~ssouhlal/testing/stackgap-20050527.diff >> >> You can control the range of the random stack gap with the >> kern.stackgap_random sysctl. A value of 0 disables it. Otherwise, >> it has to be a power of 2 and not too large. The default value is >> 64K. >> >> I've only had the chance to test this on i386. Could anyone test >> it on other architectures as well? >> >> Any comments/objections? >> > > In the past, substantial performance hits have been measured due to > poor stack alignment. Specifically, in combination with less > optimal compiler behavior, the results have been pretty nasty. > Have you tried micro-benchmarking a series of runs with this stack > offset randomness using floating point on stack arguments to see if > there's a measurable cost to moving the stack around? Hopefull if > all is well, there will be little or no difference, but a small > error here could result in a substantial performance hit... I've modified the patch to make sure that the random offset is always correctly aligned.. Do you think it would be safe to commit it (maybe having the stackgap off by default)? Bye. -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Mon May 30 02:47:10 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6247516A41C for ; Mon, 30 May 2005 02:47:10 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from sp.dominia.org (efnet-math.org [69.60.109.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 001B643D1F for ; Mon, 30 May 2005 02:47:09 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.0.99] (pool-151-200-57-83.res.east.verizon.net [151.200.57.83]) (authenticated bits=0) by sp.dominia.org (8.13.1/8.13.1) with ESMTP id j4U2l8YG020792 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sun, 29 May 2005 22:47:09 -0400 Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <40BB7DA9-472A-476A-B6B0-8C3DFDCC9060@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: arch@FreeBSD.org From: Suleiman Souhlal Date: Sun, 29 May 2005 22:47:03 -0400 X-Mailer: Apple Mail (2.730) Cc: Subject: [PATCH] randomized mmap X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2005 02:47:10 -0000 Hi! The patch at http://people.freebsd.org/~ssouhlal/testing/ mmap_random-20050528.diff implements random mmap addresses (unless of course MAP_FIXED is being used), again from OpenBSD. This behavior can be disabled setting the vm.mmap_random sysctl to 0. I think this could greatly increase memory fragmentation, so I'm not sure it would be such a good idea to have it on by default. Also, it doesn't really make attacks unfeasable, but the implementation is so simple that I don't think we really lose anything by letting users decide if they want to enable it or not. Any comment? -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Mon May 30 04:02:34 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A522216A41C; Mon, 30 May 2005 04:02:34 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A62143D1D; Mon, 30 May 2005 04:02:34 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j4U42Xxn012002; Sun, 29 May 2005 21:02:33 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <40BB7DA9-472A-476A-B6B0-8C3DFDCC9060@FreeBSD.org> References: <40BB7DA9-472A-476A-B6B0-8C3DFDCC9060@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sun, 29 May 2005 21:02:32 -0700 To: Suleiman Souhlal X-Mailer: Apple Mail (2.622) Cc: arch@freebsd.org Subject: Re: [PATCH] randomized mmap X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2005 04:02:34 -0000 On May 29, 2005, at 7:47 PM, Suleiman Souhlal wrote: > The patch at > http://people.freebsd.org/~ssouhlal/testing/mmap_random-20050528.diff > implements random mmap addresses (unless of course MAP_FIXED is being > used), again from OpenBSD. > This behavior can be disabled setting the vm.mmap_random sysctl to 0. Can I suggest changing the default to 0? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Mon May 30 05:52:14 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C63C916A41C for ; Mon, 30 May 2005 05:52:14 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from schizoid.village.org (schizoid.village.org [168.103.84.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2610843D53 for ; Mon, 30 May 2005 05:52:13 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (duck-pond.village.org [10.200.4.2]) by schizoid.village.org (8.12.9p2/8.12.9) with ESMTP id j4U5q8VY075934; Sun, 29 May 2005 23:52:12 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 29 May 2005 23:52:03 -0600 (MDT) Message-Id: <20050529.235203.74669295.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <4299FD87.1000505@samsco.org> References: <20050525.212009.71136852.nyan@jp.FreeBSD.org> <20050525.111945.41668351.imp@bsdimp.com> <4299FD87.1000505@samsco.org> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: gibbs@scsiguy.com, arch@FreeBSD.org, nyan@jp.FreeBSD.org Subject: Re: [RFC] remove bus_memio.h and bus_pio.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2005 05:52:14 -0000 In message: <4299FD87.1000505@samsco.org> Scott Long writes: : This kind of makes me sad. I don't see how this was harming anything, : it just wasn't documented so people didn't know how to use it. If it : didn't apply to non-i386 and amd64, fine, just don't implement it for : those platform. This optimization might have seemed trivial, but it's : all of the little trivial optimizations that add up to make a nice : system. I'm guessing that Justin only put effort into this originally : because he did see a benefit; discounting it without doing any testing : of your own is a bit disingenuous. I've been unable to measure any difference in any of timing solution's drivers between having the bus_pio.h include and not having it at all (which disables the optimization). This is on a 266MHz Pentium. I'm guessing that the drivers did inb/outb/etc so infrequently that any benefit was swamped by the actual I/O. Even at the maximum data rates that we could see (which did about 20k inb/outb a second) I couldn't measure any CPU difference, nor could I measure any performance difference. I did this in the 4.3 time frame in our tree when looking to optimize a driver that was giving us trouble. A back of the envelope calculation suggests that I should have seen about 100us/s of extra CPU time. Since I ran the tests for about 1000 seconds, I should have seen .1s extra in CPU. Maybe I did, but iirc the standard deviation of the measurements as much more than that. I'll see if I can find the data I gathered at the time. I've not measured anything with memio to see if that matters, or if there is anything different about newer pentiums and the branching effects. However, when Justin introduced them in the 3.0 time frame, which is 1998. According to Intel's web site, the Pentium II had just been introduced, which puts the CPU speeds at just a little faster than the embedded systems we run at work. I also recall discussions with Justin at the time that said the biggest win was for 386 and 486 machines, but I might be misremembering those discussions, since they were over lunch about 7 years ago. Warner From owner-freebsd-arch@FreeBSD.ORG Mon May 30 08:37:57 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5512716A41C; Mon, 30 May 2005 08:37:57 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B87143D54; Mon, 30 May 2005 08:37:57 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 998C546B4D; Mon, 30 May 2005 04:37:56 -0400 (EDT) Date: Mon, 30 May 2005 09:38:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Suleiman Souhlal In-Reply-To: Message-ID: <20050530093629.K52379@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Robert Watson , arch@FreeBSD.org Subject: Re: [PATCH] Stackgap X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2005 08:37:57 -0000 On Sun, 29 May 2005, Suleiman Souhlal wrote: >> In the past, substantial performance hits have been measured due to poor >> stack alignment. Specifically, in combination with less optimal compiler >> behavior, the results have been pretty nasty. Have you tried >> micro-benchmarking a series of runs with this stack offset randomness using >> floating point on stack arguments to see if there's a measurable cost to >> moving the stack around? Hopefull if all is well, there will be little or >> no difference, but a small error here could result in a substantial >> performance hit... > > I've modified the patch to make sure that the random offset is always > correctly aligned.. Do you think it would be safe to commit it (maybe > having the stackgap off by default)? Have you had a chance to run any micro-benchmarks to confirm all is well? Also, I thought Poul-Henning's question about the degree of entropy here was interesting -- what's the actual scope of possible values? Are we talking about only a small number of offsets (16) or something much larger? I'm not opposed to it being merged as long as (a) we know it doesn't hurt us, and (b) it actually does help us. Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Mon May 30 08:46:04 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30F8416A41C; Mon, 30 May 2005 08:46:04 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id E78CB43D48; Mon, 30 May 2005 08:46:03 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 8923146B4D; Mon, 30 May 2005 04:46:03 -0400 (EDT) Date: Mon, 30 May 2005 09:46:28 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Suleiman Souhlal In-Reply-To: <40BB7DA9-472A-476A-B6B0-8C3DFDCC9060@FreeBSD.org> Message-ID: <20050530093845.T52379@fledge.watson.org> References: <40BB7DA9-472A-476A-B6B0-8C3DFDCC9060@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org Subject: Re: [PATCH] randomized mmap X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2005 08:46:04 -0000 On Sun, 29 May 2005, Suleiman Souhlal wrote: > The patch at http://people.freebsd.org/~ssouhlal/testing/ > mmap_random-20050528.diff implements random mmap addresses (unless of > course MAP_FIXED is being used), again from OpenBSD. This behavior can > be disabled setting the vm.mmap_random sysctl to 0. I think this could > greatly increase memory fragmentation, so I'm not sure it would be such > a good idea to have it on by default. Also, it doesn't really make > attacks unfeasable, but the implementation is so simple that I don't > think we really lose anything by letting users decide if they want to > enable it or not. Presumably the goal of this change is to make it harder to work around stack gap randomization, lack of execute bit on pages where code can be injected via data, etc by setting the return address in the overflowed buffer to a well-known address in a library rather than code injected into the stack? On a 32-bit system, this sort of change would be disastrous in terms of address space fragmentation, I would think. However, on a 64-bit system, it might be quite a bit less so. However, I'm not sure I'd implement it this way: in a 64-bit address space, we may want to do a bit more structuring of the address space and set aside a specific region for mmap's. Does it make sense to do the randomization only for mappings with the executable bit set, or implicitly set, when talking about 64-bit architectures that have a more reasonable notion of executable than i386? Were you aware that procfs has a 'map' feature that allows you to see what the practical effect of policy chnages in address space have on processes is? You might want to experiment a bit and see what the practical impact of maximum mapping is after loading a few shared libraries (etc) with this policy in place. If it turns out that, after 40 shared libraries are mapped into an address space, the process can no longer mmap more than a few megs, I'd definitely vote against it being included. Konqueror, btw, maps about 40 shared libraries by default on my notebook :-). How was the adjustment value of 256k selected, btw? Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Mon May 30 11:21:10 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C17C616A41C for ; Mon, 30 May 2005 11:21:10 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4381943D48 for ; Mon, 30 May 2005 11:21:10 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4UBL3rI012307; Mon, 30 May 2005 21:21:03 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4UBKmMC024395; Mon, 30 May 2005 21:20:49 +1000 Date: Mon, 30 May 2005 21:20:49 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: "M. Warner Losh" In-Reply-To: <20050529.235203.74669295.imp@bsdimp.com> Message-ID: <20050530201200.O843@epsplex.bde.org> References: <20050525.212009.71136852.nyan@jp.FreeBSD.org> <20050525.111945.41668351.imp@bsdimp.com> <4299FD87.1000505@samsco.org> <20050529.235203.74669295.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: gibbs@scsiguy.com, arch@freebsd.org, nyan@jp.FreeBSD.org Subject: Re: [RFC] remove bus_memio.h and bus_pio.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2005 11:21:11 -0000 On Sun, 29 May 2005, M. Warner Losh wrote: > In message: <4299FD87.1000505@samsco.org> > Scott Long writes: > : This kind of makes me sad. I don't see how this was harming anything, > : it just wasn't documented so people didn't know how to use it. If it > : didn't apply to non-i386 and amd64, fine, just don't implement it for > : those platform. This optimization might have seemed trivial, but it's > : all of the little trivial optimizations that add up to make a nice > : system. I'm guessing that Justin only put effort into this originally > : because he did see a benefit; discounting it without doing any testing > : of your own is a bit disingenuous. > > I've been unable to measure any difference in any of timing solution's > drivers between having the bus_pio.h include and not having it at all > (which disables the optimization). This is on a 266MHz Pentium. I'm > guessing that the drivers did inb/outb/etc so infrequently that any > benefit was swamped by the actual I/O. Even at the maximum data rates No, you couldn't measure it because a 266MHz is too fast. Try an 8088/5. inb/outb takes a significant fraction of a microsecond, but a 266MHz Pentium can do up to 532 instructions in a microsecond even if it is only a Pentium-I, so bloating the code from 1 instruction to 5 or so makes little difference -- the 1 instruction for an inb takes a few CPU cycles @ 4nsec each, plus a huge number of CPU cycles for the i/o (e.g., 300 @ 4 nsec each for a total of 1.2 usec). Then bloating the code to 5 instructions takes 3-5 more cycles @ 4 nsec each (lots more if they aren't in the pipeline but with 300 cycles for the i/o the CPU can easily fill up the pipeline while waiting). So bloating (a small part of) the code by a factor of 5 only bloats the execution time by a factor of < 5/300 or so. Multiply by 10 or so for a fast PCI device. On an 8088/5, i/o instructions are slightly faster than memory accesses and taken branches and instruction bandwidth is a problem, so bloating the code by a factor of 5 you would have an 80% pessimization. > that we could see (which did about 20k inb/outb a second) I couldn't > measure any CPU difference, nor could I measure any performance > difference. I did this in the 4.3 time frame in our tree when looking I can easily measure CPU differences in the 0.1% range for sio :-). With 32 active channels differences of 1% but not 0.1% are important. > I've not measured anything with memio to see if that matters, or if > there is anything different about newer pentiums and the branching > effects. However, when Justin introduced them in the 3.0 time frame, > which is 1998. According to Intel's web site, the Pentium II had just > been introduced, which puts the CPU speeds at just a little faster > than the embedded systems we run at work. I also recall discussions > with Justin at the time that said the biggest win was for 386 and 486 > machines, but I might be misremembering those discussions, since they > were over lunch about 7 years ago. It was 486's in 1992 (?) which made CPUs so much faster than i/o that optimizing instructions for i/o became not very useful. PCI later reduced the CPU:i/o speed imbalance only for a few years. Bruce From owner-freebsd-arch@FreeBSD.ORG Mon May 30 16:28:10 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D421316A41C; Mon, 30 May 2005 16:28:10 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from schizoid.village.org (schizoid.village.org [168.103.84.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5110443D49; Mon, 30 May 2005 16:28:10 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (duck-pond.village.org [10.200.4.2]) by schizoid.village.org (8.12.9p2/8.12.9) with ESMTP id j4UGS8VY079895; Mon, 30 May 2005 10:28:08 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 30 May 2005 10:28:03 -0600 (MDT) Message-Id: <20050530.102803.74664036.imp@bsdimp.com> To: rwatson@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20050529121224.L52379@fledge.watson.org> References: <4298E316.9020303@samsco.org> <20050529121224.L52379@fledge.watson.org> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: daniel_k_eriksson@telia.com, freebsd-arch@FreeBSD.org Subject: Re: MPSAFE CAM? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2005 16:28:11 -0000 In message: <20050529121224.L52379@fledge.watson.org> Robert Watson writes: : driver, we've gained many of the benefits of making MPSAFE. Especially if : we can knock Giant off a lot of the remaining non-CAM device drivers that : it's still stuck over. usb, psm and atkbd are important ones for interactive performance... Warner From owner-freebsd-arch@FreeBSD.ORG Mon May 30 17:21:05 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3447416A41C; Mon, 30 May 2005 17:21:05 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC5D443D53; Mon, 30 May 2005 17:21:04 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j4UHL4nG015318; Mon, 30 May 2005 10:21:04 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20050530093845.T52379@fledge.watson.org> References: <40BB7DA9-472A-476A-B6B0-8C3DFDCC9060@FreeBSD.org> <20050530093845.T52379@fledge.watson.org> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Mon, 30 May 2005 10:20:58 -0700 To: Robert Watson X-Mailer: Apple Mail (2.622) Cc: arch@freebsd.org, Suleiman Souhlal Subject: Re: [PATCH] randomized mmap X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2005 17:21:05 -0000 On May 30, 2005, at 1:46 AM, Robert Watson wrote: > On a 32-bit system, this sort of change would be disastrous in terms > of address space fragmentation, I would think. However, on a 64-bit > system, it might be quite a bit less so. However, I'm not sure I'd > implement it this way: in a 64-bit address space, we may want to do a > bit more structuring of the address space and set aside a specific > region for mmap's. Does it make sense to do the randomization only > for mappings with the executable bit set, or implicitly set, when > talking about 64-bit architectures that have a more reasonable notion > of executable than i386? Executable regions are typically read-only. Read-only regions can share TLBs across processes if the kernel supports this. Sharing of TLBs can be a performance booster by reducing TLB pressure in certain environments. Randomization of executable regions will probably hinder the sharing of TLBs to such extend that no sharing is possible. I think the suggestion to do it for executable pages only is not making things better. The benefits of randomizing mmap are questionable as it is, but the implementation is trivial it's not a bother. Keep it simple. It can be committed if it's simple and off by default. Change the implementation into something less trivial and the whole thing become a really bad idea. IMO of course. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Mon May 30 17:26:49 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D7CD16A41C for ; Mon, 30 May 2005 17:26:49 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3927943D53 for ; Mon, 30 May 2005 17:26:49 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 9F7A946B4B; Mon, 30 May 2005 13:26:48 -0400 (EDT) Date: Mon, 30 May 2005 18:27:17 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "M. Warner Losh" In-Reply-To: <20050530.102803.74664036.imp@bsdimp.com> Message-ID: <20050530182650.R90885@fledge.watson.org> References: <4298E316.9020303@samsco.org> <20050529121224.L52379@fledge.watson.org> <20050530.102803.74664036.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: daniel_k_eriksson@telia.com, freebsd-arch@FreeBSD.org Subject: Re: MPSAFE CAM? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2005 17:26:49 -0000 On Mon, 30 May 2005, M. Warner Losh wrote: > In message: <20050529121224.L52379@fledge.watson.org> > Robert Watson writes: > : driver, we've gained many of the benefits of making MPSAFE. Especially if > : we can knock Giant off a lot of the remaining non-CAM device drivers that > : it's still stuck over. > > usb, psm and atkbd are important ones for interactive performance... And the tty subsystem becomes an immediate dependency for several of these. Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Mon May 30 17:57:30 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A68A916A41F for ; Mon, 30 May 2005 17:57:30 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F40143D48 for ; Mon, 30 May 2005 17:57:30 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j4UI4h4v004965; Mon, 30 May 2005 12:04:43 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <429B53D3.4060806@samsco.org> Date: Mon, 30 May 2005 11:56:35 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <20050525.212009.71136852.nyan@jp.FreeBSD.org> <20050525.111945.41668351.imp@bsdimp.com> <4299FD87.1000505@samsco.org> <20050529.235203.74669295.imp@bsdimp.com> In-Reply-To: <20050529.235203.74669295.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: gibbs@scsiguy.com, arch@FreeBSD.org, nyan@jp.FreeBSD.org Subject: Re: [RFC] remove bus_memio.h and bus_pio.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2005 17:57:30 -0000 M. Warner Losh wrote: > In message: <4299FD87.1000505@samsco.org> > Scott Long writes: > : This kind of makes me sad. I don't see how this was harming anything, > : it just wasn't documented so people didn't know how to use it. If it > : didn't apply to non-i386 and amd64, fine, just don't implement it for > : those platform. This optimization might have seemed trivial, but it's > : all of the little trivial optimizations that add up to make a nice > : system. I'm guessing that Justin only put effort into this originally > : because he did see a benefit; discounting it without doing any testing > : of your own is a bit disingenuous. > > I've been unable to measure any difference in any of timing solution's > drivers between having the bus_pio.h include and not having it at all > (which disables the optimization). This is on a 266MHz Pentium. I'm > guessing that the drivers did inb/outb/etc so infrequently that any > benefit was swamped by the actual I/O. Even at the maximum data rates > that we could see (which did about 20k inb/outb a second) I couldn't > measure any CPU difference, nor could I measure any performance > difference. I did this in the 4.3 time frame in our tree when looking > to optimize a driver that was giving us trouble. A back of the > envelope calculation suggests that I should have seen about 100us/s of > extra CPU time. Since I ran the tests for about 1000 seconds, I > should have seen .1s extra in CPU. Maybe I did, but iirc the standard > deviation of the measurements as much more than that. I'll see if I > can find the data I gathered at the time. > > I've not measured anything with memio to see if that matters, or if > there is anything different about newer pentiums and the branching > effects. However, when Justin introduced them in the 3.0 time frame, > which is 1998. According to Intel's web site, the Pentium II had just > been introduced, which puts the CPU speeds at just a little faster > than the embedded systems we run at work. I also recall discussions > with Justin at the time that said the biggest win was for 386 and 486 > machines, but I might be misremembering those discussions, since they > were over lunch about 7 years ago. > > Warner Thanks for the explaination. One thing to note is that the Soekris is still a very popular platform, so this optimization might still be very relevant there. Even so, it was basically free, and the only thing it lacked was documentation so that people could use it correctly. It's a shame that it's gone. Scott From owner-freebsd-arch@FreeBSD.ORG Mon May 30 23:17:45 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A247C16A41C for ; Mon, 30 May 2005 23:17:45 +0000 (GMT) (envelope-from thompsa@fud.org.nz) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4567F43D1F for ; Mon, 30 May 2005 23:17:45 +0000 (GMT) (envelope-from thompsa@fud.org.nz) Received: from thompsa by heff.fud.org.nz with local (Exim 4.50 (FreeBSD)) id 1DctVv-0002Fk-Vq for arch@freebsd.org; Tue, 31 May 2005 11:17:43 +1200 Date: Tue, 31 May 2005 11:17:43 +1200 From: Andrew Thompson To: arch@freebsd.org Message-ID: <20050530231743.GB8316@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Sender: Andrew Thompson Cc: Subject: RFC: if_bridge X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2005 23:17:45 -0000 Hi, I am looking for testers and code review for if_bridge, the bridge implementation from NetBSD (and OpenBSD). The patch and instructions can be found at: http://people.freebsd.org/~thompsa/ Highlights include: - 802.1d spanning tree support - management of the bridge MAC table - view bridged packets with bpf(4) - good firewall support I am especially interested in people who can test !i386, and users with existing STP networks. I am looking forward to getting your feedback! Andrew From owner-freebsd-arch@FreeBSD.ORG Tue May 31 01:40:00 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FCBF16A41C; Tue, 31 May 2005 01:40:00 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BF3D43D49; Tue, 31 May 2005 01:39:59 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4V1dnrI008810; Tue, 31 May 2005 11:39:49 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4V1djMC020885; Tue, 31 May 2005 11:39:46 +1000 Date: Tue, 31 May 2005 11:39:47 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Robert Watson In-Reply-To: <20050530182650.R90885@fledge.watson.org> Message-ID: <20050531113008.R91505@delplex.bde.org> References: <4298E316.9020303@samsco.org> <20050529121224.L52379@fledge.watson.org> <20050530.102803.74664036.imp@bsdimp.com> <20050530182650.R90885@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: daniel_k_eriksson@telia.com, freebsd-arch@FreeBSD.org Subject: Re: MPSAFE CAM? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 01:40:00 -0000 On Mon, 30 May 2005, Robert Watson wrote: > On Mon, 30 May 2005, M. Warner Losh wrote: > >> In message: <20050529121224.L52379@fledge.watson.org> >> Robert Watson writes: >> : driver, we've gained many of the benefits of making MPSAFE. Especially >> if >> : we can knock Giant off a lot of the remaining non-CAM device drivers that >> : it's still stuck over. >> >> usb, psm and atkbd are important ones for interactive performance... > > And the tty subsystem becomes an immediate dependency for several of these. Interactive performance is irrelevant here. You can can lose efficiency by competing for Giant a few hundred thousand times in the time that it takes an interactive user to notice. The problem is that non-interactive performance is impaired by using Giant locking anywhere. Using it for interactive devices is only a problem if the interaction often requires holding Giant for a long time. It doesn't for most input devices including keyboards, but it might for slow bulk output devices like syscons consoles. Bruce From owner-freebsd-arch@FreeBSD.ORG Tue May 31 02:30:28 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD96E16A41C; Tue, 31 May 2005 02:30:28 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (berlin-qwest.village.org [168.103.84.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF60043D1F; Tue, 31 May 2005 02:30:25 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j4V2VU6W052048; Mon, 30 May 2005 20:31:31 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 30 May 2005 20:30:26 -0600 (MDT) Message-Id: <20050530.203026.35855612.imp@bsdimp.com> To: bde@zeta.org.au From: "M. Warner Losh" In-Reply-To: <20050531113008.R91505@delplex.bde.org> References: <20050530.102803.74664036.imp@bsdimp.com> <20050530182650.R90885@fledge.watson.org> <20050531113008.R91505@delplex.bde.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: rwatson@FreeBSD.org, daniel_k_eriksson@telia.com, freebsd-arch@FreeBSD.org Subject: Re: MPSAFE CAM? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 02:30:28 -0000 In message: <20050531113008.R91505@delplex.bde.org> Bruce Evans writes: : On Mon, 30 May 2005, Robert Watson wrote: : : > On Mon, 30 May 2005, M. Warner Losh wrote: : > : >> In message: <20050529121224.L52379@fledge.watson.org> : >> Robert Watson writes: : >> : driver, we've gained many of the benefits of making MPSAFE. Especially : >> if : >> : we can knock Giant off a lot of the remaining non-CAM device drivers that : >> : it's still stuck over. : >> : >> usb, psm and atkbd are important ones for interactive performance... : > : > And the tty subsystem becomes an immediate dependency for several of these. : : Interactive performance is irrelevant here. You can can lose efficiency : by competing for Giant a few hundred thousand times in the time that : it takes an interactive user to notice. The problem is that non-interactive : performance is impaired by using Giant locking anywhere. Using it for : interactive devices is only a problem if the interaction often requires : holding Giant for a long time. It doesn't for most input devices : including keyboards, but it might for slow bulk output devices like : syscons consoles. Also in the case of usb, it means that all devices sharing interrupts with the usb bridges are effectively under giant... Warner From owner-freebsd-arch@FreeBSD.ORG Tue May 31 11:38:47 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FFD316A41C; Tue, 31 May 2005 11:38:47 +0000 (GMT) (envelope-from nectar@FreeBSD.org) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 395F343D1D; Tue, 31 May 2005 11:38:47 +0000 (GMT) (envelope-from nectar@FreeBSD.org) Received: from lum.celabo.org (lum.celabo.org [10.0.1.107]) by gw.celabo.org (Postfix) with ESMTP id 8F10E3E634D; Tue, 31 May 2005 06:38:46 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lum.celabo.org (Postfix) with ESMTP id 79674FF680; Tue, 31 May 2005 06:38:44 -0500 (CDT) In-Reply-To: References: <200505041529.36826.peter@wemm.org> <20050509.104234.71141880.imp@bsdimp.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jacques Vidrine Date: Tue, 31 May 2005 06:38:41 -0500 To: Hajimu UMEMOTO X-Mailer: Apple Mail (2.730) Cc: standards@FreeBSD.org, freebsd-arch@FreeBSD.org, des@FreeBSD.org, current@FreeBSD.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 11:38:47 -0000 On May 27, 2005, at 1:30 PM, Hajimu UMEMOTO wrote: > Hi, >>>>>> On Mon, 09 May 2005 10:42:34 -0600 (MDT) >>>>>> Warner Losh said: >> Are you suggest when to remove padding? Since the major of libc was >> bumped already in 6-CURRENT, it may better to wait 7-CURRENT. > > imp> We've generally not worried compatibility in the 'rough and > tumble' > imp> world of FreeBSD current. So unless there's a problem in the > upgrade > imp> path, I think that we safely omit them. > > I'll commit the attached change to nuke padding. It will break ABI > compatibility on 64 bit arch. So, I'm planning bumping major of > affected shlibs. Please review it. It isn't clear to me that bumping the libraries' version number in - CURRENT is necessary, but I have no objection, either. Cheers, -- Jacques A Vidrine / NTT/Verio nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Tue May 31 12:26:04 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA23216A41C; Tue, 31 May 2005 12:26:04 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D32643D1D; Tue, 31 May 2005 12:26:04 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (ume@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j4VCPbMA007766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 May 2005 21:25:38 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 31 May 2005 21:25:35 +0900 Message-ID: From: Hajimu UMEMOTO To: Jacques Vidrine In-Reply-To: References: <200505041529.36826.peter@wemm.org> <20050509.104234.71141880.imp@bsdimp.com> User-Agent: xcite1.38> Wanderlust/2.15.1 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.4) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.4-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-2.0b5 (cheer.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Tue, 31 May 2005 21:25:38 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on cheer.mahoroba.org Cc: current@FreeBSD.org, standards@FreeBSD.org, des@FreeBSD.org, freebsd-arch@FreeBSD.org, Hajimu UMEMOTO Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 12:26:05 -0000 Hi, >>>>> On Tue, 31 May 2005 06:38:41 -0500 >>>>> Jacques Vidrine said: nectar> It isn't clear to me that bumping the libraries' version number in - nectar> CURRENT is necessary, but I have no objection, either. Thank you. Though libc was already bumped, the rest is not bumed. So, we need bumping the rest which refer getaddrinfo(3). Unless bumping, we'll not be able to have compat libs for 5.X. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Tue May 31 12:35:35 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 957FD16A41F for ; Tue, 31 May 2005 12:35:35 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from opus.cse.buffalo.edu (opus.cse.Buffalo.EDU [128.205.32.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3510A43D48 for ; Tue, 31 May 2005 12:35:34 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from opus.cse.buffalo.edu (opus.cse.buffalo.edu [128.205.32.4]) by opus.cse.buffalo.edu (8.13.3/8.12.10) with ESMTP id j4VCZTeo016766; Tue, 31 May 2005 08:35:29 -0400 (EDT) From: Ken Smith To: Jeremie Le Hen In-Reply-To: <20050529165719.GF54337@obiwan.tataz.chchile.org> References: <1117139065.82793.20.camel@opus.cse.buffalo.edu> <20050527091750.GB91258@stack.nl> <1117195655.88498.9.camel@opus.cse.buffalo.edu> <20050527131014.GA93850@stack.nl> <20050529165719.GF54337@obiwan.tataz.chchile.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-bR7uQjYiuCjt2zB8RwEj" Organization: U. Buffalo CSE Department Date: Tue, 31 May 2005 08:35:28 -0400 Message-Id: <1117542928.16376.3.camel@opus.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Cc: Marc Olzheim , freebsd-arch@freebsd.org Subject: Re: Modifying file access time upon exec... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 12:35:35 -0000 --=-bR7uQjYiuCjt2zB8RwEj Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2005-05-29 at 18:57 +0200, Jeremie Le Hen wrote: > Hi Marc, Ken, >=20 > > > I'm not sure why you say NFS filesystems can't be mounted with noatim= e. > >=20 > > No, I'm saying that there are filesystems you wouldn't want to mount > > with noatime (/tmp, /var/tmp, /var/mail, /var/spool/*) because some > > software depends on the atime being adjusted. >=20 > I thought that, according to the goal of this patch, the "noatime" > option you were talking about would be in fact a "noatime-on-exec" > option. Access time would be still updated on other cases. > Am I wrong ? This is correct. Other than changing it so that the atime on executable files gets modified when they get executed this patch should not change anything. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-bR7uQjYiuCjt2zB8RwEj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCnFoQ/G14VSmup/YRAqkKAKCQGUTyWGcWsJpUUE9lgMNOSJJ9QACfRF4c jn/XfhG2dAw4MclMe3zXqu8= =yJZo -----END PGP SIGNATURE----- --=-bR7uQjYiuCjt2zB8RwEj-- From owner-freebsd-arch@FreeBSD.ORG Tue May 31 14:09:55 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 395EC16A423; Tue, 31 May 2005 14:09:55 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (berlin-qwest.village.org [168.103.84.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 888C743D48; Tue, 31 May 2005 14:09:52 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j4VDqrvE060929; Tue, 31 May 2005 07:52:53 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 31 May 2005 07:53:29 -0600 (MDT) Message-Id: <20050531.075329.118637972.imp@bsdimp.com> To: ume@freebsd.org From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: nectar@freebsd.org, standards@freebsd.org, current@freebsd.org, des@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 14:09:55 -0000 In message: Hajimu UMEMOTO writes: : Hi, : : >>>>> On Tue, 31 May 2005 06:38:41 -0500 : >>>>> Jacques Vidrine said: : : nectar> It isn't clear to me that bumping the libraries' version number in - : nectar> CURRENT is necessary, but I have no objection, either. : : Thank you. : Though libc was already bumped, the rest is not bumed. So, we need : bumping the rest which refer getaddrinfo(3). Unless bumping, we'll : not be able to have compat libs for 5.X. So the libraries that depend on libc need to be bumped to allow producing compat libs for 5.x? Warner From owner-freebsd-arch@FreeBSD.ORG Tue May 31 14:43:34 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D077C16A41C; Tue, 31 May 2005 14:43:34 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5177C43D4C; Tue, 31 May 2005 14:43:33 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (ume@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j4VEgoFq067092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 May 2005 23:42:54 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 31 May 2005 23:42:48 +0900 Message-ID: From: Hajimu UMEMOTO To: "M. Warner Losh" In-Reply-To: <20050531.075329.118637972.imp@bsdimp.com> References: <20050531.075329.118637972.imp@bsdimp.com> User-Agent: xcite1.38> Wanderlust/2.15.1 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.4) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.4-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-2.0b5 (cheer.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Tue, 31 May 2005 23:42:54 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on cheer.mahoroba.org Cc: nectar@freebsd.org, standards@freebsd.org, current@freebsd.org, des@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 14:43:35 -0000 Hi, >>>>> On Tue, 31 May 2005 07:53:29 -0600 (MDT) >>>>> "M. Warner Losh" said: imp> So the libraries that depend on libc need to be bumped to allow imp> producing compat libs for 5.x? Yes, I think so. Do I have a misunderstanding? Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Tue May 31 14:51:41 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCAB616A41C; Tue, 31 May 2005 14:51:41 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (berlin-qwest.village.org [168.103.84.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AF8243D48; Tue, 31 May 2005 14:51:26 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j4VElvPY062346; Tue, 31 May 2005 08:47:57 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 31 May 2005 08:48:32 -0600 (MDT) Message-Id: <20050531.084832.20036038.imp@bsdimp.com> To: ume@freebsd.org From: "M. Warner Losh" In-Reply-To: References: <20050531.075329.118637972.imp@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: nectar@freebsd.org, standards@freebsd.org, current@freebsd.org, des@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 14:51:42 -0000 In message: Hajimu UMEMOTO writes: : >>>>> On Tue, 31 May 2005 07:53:29 -0600 (MDT) : >>>>> "M. Warner Losh" said: : : imp> So the libraries that depend on libc need to be bumped to allow : imp> producing compat libs for 5.x? : : Yes, I think so. Do I have a misunderstanding? In general, yes. However, I think that only those libraries that use the affected interfaces in libc need a bump in this case. Maybe we should look to see which libraries are affected rather than a blind bump. The blind bump is the only way to make sure, but so far the project has been unable to commit to doing such a bump due to the pain that trying to do it in ports would also cause. But that's my soapbox... Warner From owner-freebsd-arch@FreeBSD.ORG Tue May 31 15:06:50 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA6E016A41C; Tue, 31 May 2005 15:06:50 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21BAA43D49; Tue, 31 May 2005 15:06:49 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (ume@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j4VF6W2l085199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2005 00:06:32 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 01 Jun 2005 00:06:31 +0900 Message-ID: From: Hajimu UMEMOTO To: "M. Warner Losh" In-Reply-To: <20050531.084832.20036038.imp@bsdimp.com> References: <20050531.075329.118637972.imp@bsdimp.com> <20050531.084832.20036038.imp@bsdimp.com> User-Agent: xcite1.38> Wanderlust/2.15.1 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.4) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.4-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-2.0b5 (cheer.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Wed, 01 Jun 2005 00:06:33 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on cheer.mahoroba.org Cc: nectar@freebsd.org, standards@freebsd.org, current@freebsd.org, des@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 15:06:51 -0000 Hi, >>>>> On Tue, 31 May 2005 08:48:32 -0600 (MDT) >>>>> "M. Warner Losh" said: imp> In general, yes. However, I think that only those libraries that use imp> the affected interfaces in libc need a bump in this case. Maybe we imp> should look to see which libraries are affected rather than a blind imp> bump. No, it is not blind bump. The following libraries refers getaddrinfo(3), thus should be bumped: RELENG_5 HEAD Need to Bump libbsnmp 2 2 o libc 5 6 libfetch 3 3 o libftpio 5 5 o libipsec 1 1 o libkadm5clnt 7 7 o libkrb5 7 7 o libpam 2 2 pam_radius o pam_unix o libpcap 3 3 o libroken 7 7 o libssh 2 2 o libutil 4 4 o libwrap 3 3 o Actually, not all libraries of kerberos and pam stuff refer getaddrinfo(3). However, it seems shlib major of kerberos and pam stuff are managed by single major version. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Tue May 31 15:37:12 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29F8416A41C; Tue, 31 May 2005 15:37:12 +0000 (GMT) (envelope-from des@des.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89D8B43D1D; Tue, 31 May 2005 15:37:11 +0000 (GMT) (envelope-from des@des.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IHD002KE7XKBAA0@osl1smout1.broadpark.no>; Tue, 31 May 2005 19:44:08 +0200 (CEST) Received: from dsa.des.no ([80.203.228.37]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IHD00B5G2852Y57@osl1sminn1.broadpark.no>; Tue, 31 May 2005 17:40:53 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id 772E6451B3; Tue, 31 May 2005 17:37:09 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id 508DB45165; Tue, 31 May 2005 17:37:05 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 47B7F33C3B; Tue, 31 May 2005 17:37:05 +0200 (CEST) Date: Tue, 31 May 2005 17:37:05 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: To: Hajimu UMEMOTO Message-id: <86fyw32yqm.fsf@xps.des.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on dsa.des.no References: <20050531.075329.118637972.imp@bsdimp.com> <20050531.084832.20036038.imp@bsdimp.com> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.0.2 X-Spam-Level: Cc: nectar@freebsd.org, standards@freebsd.org, current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 15:37:12 -0000 Hajimu UMEMOTO writes: > No, it is not blind bump. The following libraries refers > getaddrinfo(3), thus should be bumped: > > RELENG_5 HEAD Need to Bump > [...] > libpam 2 2 > pam_radius o > pam_unix o You can't just bump libpam; you need to bump all the modules along with it, because libpam will only load modules with the same major number as itself. In fact, there is only a single SHLIB_MAJOR for the entire src/lib/libpam tree, in src/lib/libpam/Makefile.inc. Is it really necessary to remove the padding? It gives us a lot of trouble for zero gain. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue May 31 15:53:16 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6699F16A41C; Tue, 31 May 2005 15:53:16 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEBBC43D1D; Tue, 31 May 2005 15:53:15 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (ume@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j4VFqpZx030658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2005 00:52:51 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 01 Jun 2005 00:52:49 +0900 Message-ID: From: Hajimu UMEMOTO To: des@des.no (Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?=) In-Reply-To: <86fyw32yqm.fsf@xps.des.no> References: <20050531.075329.118637972.imp@bsdimp.com> <20050531.084832.20036038.imp@bsdimp.com> <86fyw32yqm.fsf@xps.des.no> User-Agent: xcite1.38> Wanderlust/2.15.1 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.4) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.4-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-2.0b5 (cheer.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Wed, 01 Jun 2005 00:52:51 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on cheer.mahoroba.org Cc: nectar@freebsd.org, standards@freebsd.org, current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 15:53:16 -0000 Hi, >>>>> On Tue, 31 May 2005 17:37:05 +0200 >>>>> Dag-Erling Sm=F8rgrav said: des> You can't just bump libpam; you need to bump all the modules along des> with it, because libpam will only load modules with the same major des> number as itself. In fact, there is only a single SHLIB_MAJOR for the des> entire src/lib/libpam tree, in src/lib/libpam/Makefile.inc. Thank you for clarification. My patch bumps SHLIB_MAJOR in lib/libpam/Makefile.inc. des> Is it really necessary to remove the padding? It gives us a lot of des> trouble for zero gain. I think such cleanup should be done before major release. However, if our consensus doesn't want to remove the padding, I'll stop removing it. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Tue May 31 16:51:17 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 516C016A41C; Tue, 31 May 2005 16:51:17 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D038743D4C; Tue, 31 May 2005 16:51:16 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.4/8.13.4/NETPLEX) with ESMTP id j4VGp0df008467; Tue, 31 May 2005 12:51:00 -0400 (EDT) Date: Tue, 31 May 2005 12:51:00 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= In-Reply-To: <86fyw32yqm.fsf@xps.des.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: nectar@freebsd.org, standards@freebsd.org, freebsd-arch@freebsd.org, current@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 16:51:17 -0000 On Tue, 31 May 2005, [iso-8859-1] Dag-Erling Sm=F8rgrav wrote: > Hajimu UMEMOTO writes: > > No, it is not blind bump. The following libraries refers > > getaddrinfo(3), thus should be bumped: > > > > =09=09=09RELENG_5=09HEAD=09Need to Bump > > [...] > > libpam=09=09=092=09=092 > > =09pam_radius=09=09=09=09o > > =09pam_unix=09=09=09=09o > > You can't just bump libpam; you need to bump all the modules along > with it, because libpam will only load modules with the same major > number as itself. In fact, there is only a single SHLIB_MAJOR for the > entire src/lib/libpam tree, in src/lib/libpam/Makefile.inc. > > Is it really necessary to remove the padding? It gives us a lot of > trouble for zero gain. And sometimes we put padding in place to allow for expansion (ucontext for one). I think the padding should stay. If we ever get symbol versioning, then you can remove it without having to bump library versions. --=20 DE From owner-freebsd-arch@FreeBSD.ORG Tue May 31 16:57:16 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42DA816A41C; Tue, 31 May 2005 16:57:16 +0000 (GMT) (envelope-from des@des.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id C077143D4C; Tue, 31 May 2005 16:57:15 +0000 (GMT) (envelope-from des@des.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IHD002LBBN0VF10@osl1smout1.broadpark.no>; Tue, 31 May 2005 21:04:12 +0200 (CEST) Received: from dsa.des.no ([80.203.228.37]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IHD00BK15XL2YI7@osl1sminn1.broadpark.no>; Tue, 31 May 2005 19:00:57 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id D819945165; Tue, 31 May 2005 18:57:13 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id 065D745131; Tue, 31 May 2005 18:57:09 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id DB3A533C3B; Tue, 31 May 2005 18:57:09 +0200 (CEST) Date: Tue, 31 May 2005 18:57:09 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: To: Hajimu UMEMOTO Message-id: <86k6lfbafu.fsf@xps.des.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on dsa.des.no References: <20050531.075329.118637972.imp@bsdimp.com> <20050531.084832.20036038.imp@bsdimp.com> <86fyw32yqm.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.0.2 X-Spam-Level: Cc: nectar@freebsd.org, standards@freebsd.org, current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 16:57:16 -0000 Hajimu UMEMOTO writes: > Dag-Erling Sm=F8rgrav writes: > > You can't just bump libpam; you need to bump all the modules along > > with it, because libpam will only load modules with the same major > > number as itself. In fact, there is only a single SHLIB_MAJOR for the > > entire src/lib/libpam tree, in src/lib/libpam/Makefile.inc. > Thank you for clarification. My patch bumps SHLIB_MAJOR in > lib/libpam/Makefile.inc. As PAM maintainer, I strongly object. > > Is it really necessary to remove the padding? It gives us a lot of > > trouble for zero gain. > I think such cleanup should be done before major release. What do we gain from removing the padding? Is there even a single practical benefit to doing so? DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue May 31 17:15:41 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4C6316A41C; Tue, 31 May 2005 17:15:41 +0000 (GMT) (envelope-from julian@elischer.org) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8F6143D4C; Tue, 31 May 2005 17:15:40 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 73BF57A403; Tue, 31 May 2005 10:15:40 -0700 (PDT) Message-ID: <429C9BBC.1060108@elischer.org> Date: Tue, 31 May 2005 10:15:40 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050423 X-Accept-Language: en, hu MIME-Version: 1.0 To: Robert Watson References: <20050528150815.X29776@fledge.watson.org> In-Reply-To: <20050528150815.X29776@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Suleiman Souhlal Subject: Re: [PATCH] Stackgap X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 17:15:42 -0000 Stack gap can actually improve performance in some cases.. the cache for the base of teh stack can become overly flushed by the fact that all stacks start with the same offset from the page. making this random can actually help this. Robert Watson wrote: > > On Fri, 27 May 2005, Suleiman Souhlal wrote: > > In the past, substantial performance hits have been measured due to > poor stack alignment. Specifically, in combination with less optimal > compiler behavior, the results have been pretty nasty. Have you tried > micro-benchmarking a series of runs with this stack offset randomness > using floating point on stack arguments to see if there's a measurable > cost to moving the stack around? Hopefull if all is well, there will > be little or no difference, but a small error here could result in a > substantial performance hit... Stack gap can actually improve performance in some cases.. the cache for the base of teh stack can become overly flushed by the fact that all stacks start with the same offset from the page. making this random can actually help this. > > > Robert N M Watson > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Tue May 31 17:47:03 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 460DB16A41C; Tue, 31 May 2005 17:47:03 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFAA843D49; Tue, 31 May 2005 17:47:02 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (ume@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j4VHkaGv085369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2005 02:46:36 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 01 Jun 2005 02:46:35 +0900 Message-ID: From: Hajimu UMEMOTO To: Daniel Eischen In-Reply-To: References: <86fyw32yqm.fsf@xps.des.no> User-Agent: xcite1.38> Wanderlust/2.15.1 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.4) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.4-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-2.0b5 (cheer.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Wed, 01 Jun 2005 02:46:37 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on cheer.mahoroba.org Cc: current@freebsd.org, nectar@freebsd.org, standards@freebsd.org, freebsd-arch@freebsd.org, Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 17:47:03 -0000 Hi, >>>>> On Tue, 31 May 2005 12:51:00 -0400 (EDT) >>>>> Daniel Eischen said: deischen> And sometimes we put padding in place to allow for expansion deischen> (ucontext for one). I think the padding should stay. If we deischen> ever get symbol versioning, then you can remove it without deischen> having to bump library versions. Since there are the padding only in 64 bit arch, I think we cannot use them for such purpose. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Tue May 31 17:56:45 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41CD816A41C; Tue, 31 May 2005 17:56:45 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (berlin-qwest.village.org [168.103.84.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E12F43D4C; Tue, 31 May 2005 17:56:43 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j4VHrcDt064683; Tue, 31 May 2005 11:53:45 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 31 May 2005 11:53:38 -0600 (MDT) Message-Id: <20050531.115338.74685129.imp@bsdimp.com> To: des@des.no From: Warner Losh In-Reply-To: <86k6lfbafu.fsf@xps.des.no> References: <86fyw32yqm.fsf@xps.des.no> <86k6lfbafu.fsf@xps.des.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: nectar@freebsd.org, standards@freebsd.org, freebsd-arch@freebsd.org, current@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 17:56:45 -0000 > Hajimu UMEMOTO writes: > > Dag-Erling Sm=F8rgrav writes: > > > You can't just bump libpam; you need to bump all the modules alon= g > > > with it, because libpam will only load modules with the same majo= r > > > number as itself. In fact, there is only a single SHLIB_MAJOR fo= r the > > > entire src/lib/libpam tree, in src/lib/libpam/Makefile.inc. > > Thank you for clarification. My patch bumps SHLIB_MAJOR in > > lib/libpam/Makefile.inc. > = > As PAM maintainer, I strongly object. Keep in mind that systemic changes can trump a maintainer's objection. This is a systemic change, so your single objection is not necessarily enough to not do this. However, the issues you raise may be reason enough to revert the systemic change. > > > Is it really necessary to remove the padding? It gives us a lot = of > > > trouble for zero gain. > > I think such cleanup should be done before major release. > = > What do we gain from removing the padding? Is there even a single > practical benefit to doing so? It is for posix compatibility. http://lists.freebsd.org/pipermail/freebsd-standards/2005-May/000869.ht= ml is where to start for an explaination. The question becomes one of do we care enough about 5.x compatibility with our new architectures to preserve it. The RE has indecated that he'd really like to see us do that (ABI stability). Warner From owner-freebsd-arch@FreeBSD.ORG Tue May 31 18:00:31 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C975D16A41C; Tue, 31 May 2005 18:00:31 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4856C43D5C; Tue, 31 May 2005 18:00:31 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (ume@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j4VI0BoF031579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2005 03:00:12 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 01 Jun 2005 03:00:10 +0900 Message-ID: From: Hajimu UMEMOTO To: des@des.no (Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?=) In-Reply-To: <86k6lfbafu.fsf@xps.des.no> References: <20050531.075329.118637972.imp@bsdimp.com> <20050531.084832.20036038.imp@bsdimp.com> <86fyw32yqm.fsf@xps.des.no> <86k6lfbafu.fsf@xps.des.no> User-Agent: xcite1.38> Wanderlust/2.15.1 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.4) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.4-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-2.0b5 (cheer.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Wed, 01 Jun 2005 03:00:12 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on cheer.mahoroba.org Cc: nectar@freebsd.org, standards@freebsd.org, current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 18:00:32 -0000 Hi, >>>>> On Tue, 31 May 2005 18:57:09 +0200 >>>>> Dag-Erling Sm=F8rgrav said: des> As PAM maintainer, I strongly object. des> What do we gain from removing the padding? Is there even a single des> practical benefit to doing so? Perhaps, nothing. It breaks only 64 bit arch. I think 64 bit arch will deployed more aftertime. If we plan to fix this up in the future, it is better to fix as soon as possible, IMHO. In anyway, there is one more issue in my patch. We cannot correct 1st argument of getnetbyaddr(3) without breaking ABI compatibility. Fortunately, getnetbyaddr(3) is not refered else where in our libraries. So, I'll fix getnetbyaddr(3). Sincerely, From owner-freebsd-arch@FreeBSD.ORG Tue May 31 18:05:38 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B19D016A41C; Tue, 31 May 2005 18:05:38 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D94C43D53; Tue, 31 May 2005 18:05:38 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.4/8.13.4/NETPLEX) with ESMTP id j4VI5WsE029159; Tue, 31 May 2005 14:05:32 -0400 (EDT) Date: Tue, 31 May 2005 14:05:32 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Warner Losh In-Reply-To: <20050531.115338.74685129.imp@bsdimp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: nectar@freebsd.org, des@des.no, standards@freebsd.org, current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 18:05:38 -0000 On Tue, 31 May 2005, Warner Losh wrote: > > > > What do we gain from removing the padding? Is there even a single > > practical benefit to doing so? > > It is for posix compatibility. > > http://lists.freebsd.org/pipermail/freebsd-standards/2005-May/000869.html > > is where to start for an explaination. I don't think anyone doubts why it was changed, but POSIX does not dictate any order or layout of the structure. The padding need not be removed just for compliance sake. Unless we're missing something... -- DE From owner-freebsd-arch@FreeBSD.ORG Tue May 31 19:09:09 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EA4A16A41C; Tue, 31 May 2005 19:09:09 +0000 (GMT) (envelope-from des@des.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E37A43D4C; Tue, 31 May 2005 19:09:08 +0000 (GMT) (envelope-from des@des.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IHD002S3HQTVS70@osl1smout1.broadpark.no>; Tue, 31 May 2005 23:16:05 +0200 (CEST) Received: from dsa.des.no ([80.203.228.37]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IHD00BLXC1E3EW7@osl1sminn1.broadpark.no>; Tue, 31 May 2005 21:12:50 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id 376D045165; Tue, 31 May 2005 21:09:07 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id 20B8245131; Tue, 31 May 2005 21:09:02 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id C751733C3B; Tue, 31 May 2005 21:09:01 +0200 (CEST) Date: Tue, 31 May 2005 21:09:01 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <20050531.115338.74685129.imp@bsdimp.com> To: Warner Losh Message-id: <86fyw3b4c2.fsf@xps.des.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on dsa.des.no References: <86fyw32yqm.fsf@xps.des.no> <86k6lfbafu.fsf@xps.des.no> <20050531.115338.74685129.imp@bsdimp.com> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.0.2 X-Spam-Level: Cc: nectar@freebsd.org, standards@freebsd.org, freebsd-arch@freebsd.org, current@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 19:09:09 -0000 Warner Losh writes: > Dag-Erling Sm=F8rgrav writes: > > What do we gain from removing the padding? Is there even a single > > practical benefit to doing so? > It is for posix compatibility. Nonsense. POSIX does not forbid padding or additional structure members. The exact wording is: > The header shall define the addrinfo structure that includes > at least the following members: -------- > > int ai_flags Input flags. > int ai_family Address family of socket. > int ai_socktype Socket type. > int ai_protocol Protocol of socket. > socklen_t ai_addrlen Length of socket address. > struct sockaddr *ai_addr Socket address of socket. > char *ai_canonname Canonical name of service location. > struct addrinfo *ai_next Pointer to next in list. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue May 31 20:05:48 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B742F16A41C; Tue, 31 May 2005 20:05:48 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (berlin-qwest.village.org [168.103.84.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id A983843D49; Tue, 31 May 2005 20:05:47 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j4VK3Y1V066276; Tue, 31 May 2005 14:03:34 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 31 May 2005 14:03:34 -0600 (MDT) Message-Id: <20050531.140334.74683681.imp@bsdimp.com> To: des@des.no From: Warner Losh In-Reply-To: <86fyw3b4c2.fsf@xps.des.no> References: <86k6lfbafu.fsf@xps.des.no> <20050531.115338.74685129.imp@bsdimp.com> <86fyw3b4c2.fsf@xps.des.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: nectar@freebsd.org, standards@freebsd.org, freebsd-arch@freebsd.org, current@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 20:05:48 -0000 > Warner Losh writes: > > Dag-Erling Sm=F8rgrav writes: > > > What do we gain from removing the padding? Is there even a singl= e > > > practical benefit to doing so? > > It is for posix compatibility. > = > Nonsense. POSIX does not forbid padding or additional structure > members. The exact wording is: > = > > The header shall define the addrinfo structure that inclu= des > > at least the following members: > -------- > > > > int ai_flags Input flags. > > int ai_family Address family of socket. > > int ai_socktype Socket type. > > int ai_protocol Protocol of socket. > > socklen_t ai_addrlen Length of socket address. > > struct sockaddr *ai_addr Socket address of socket. > > char *ai_canonname Canonical name of service location.= > > struct addrinfo *ai_next Pointer to next in list. Did you bother reading what I posted? I don't think so since you'd have known that ai_addrlen was changed to be socklen_t for posix compliance, and the padding was added for ABI compatibility. The removal of padding is the normal sort of thing that's done during major revisions. It was there, indirectly, for POSIX compliance. Maybe the padding removal is too painful given all the extra 'oh, by the ways' that we're stumbling over. Warner From owner-freebsd-arch@FreeBSD.ORG Tue May 31 20:08:36 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F0BB16A41C; Tue, 31 May 2005 20:08:36 +0000 (GMT) (envelope-from des@des.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA75643D49; Tue, 31 May 2005 20:08:35 +0000 (GMT) (envelope-from des@des.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IHD002XAKHVVR90@osl1smout1.broadpark.no>; Wed, 01 Jun 2005 00:15:32 +0200 (CEST) Received: from dsa.des.no ([80.203.228.37]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IHD00BM3ESG2ZP8@osl1sminn1.broadpark.no>; Tue, 31 May 2005 22:12:16 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id EEB4645165; Tue, 31 May 2005 22:08:32 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id 3A03C45131; Tue, 31 May 2005 22:08:30 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 2E20E33C3B; Tue, 31 May 2005 22:08:30 +0200 (CEST) Date: Tue, 31 May 2005 22:08:30 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <20050531.140334.74683681.imp@bsdimp.com> To: Warner Losh Message-id: <867jhfb1kx.fsf@xps.des.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on dsa.des.no References: <86k6lfbafu.fsf@xps.des.no> <20050531.115338.74685129.imp@bsdimp.com> <86fyw3b4c2.fsf@xps.des.no> <20050531.140334.74683681.imp@bsdimp.com> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.0.2 X-Spam-Level: Cc: nectar@freebsd.org, standards@freebsd.org, freebsd-arch@freebsd.org, current@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 20:08:36 -0000 Warner Losh writes: > Dag-Erling Sm=F8rgrav writes: > > Warner Losh writes: > > > Dag-Erling Sm=F8rgrav writes: > > > > What do we gain from removing the padding? Is there even a single > > > > practical benefit to doing so? > > > It is for posix compatibility. > > Nonsense. POSIX does not forbid padding or additional structure > > members. The exact wording is: [...] > Did you bother reading what I posted? I don't think so since you'd > have known that ai_addrlen was changed to be socklen_t for posix > compliance, and the padding was added for ABI compatibility. The > removal of padding is the normal sort of thing that's done during > major revisions. It was there, indirectly, for POSIX compliance. I know that. I am questioning the need to *remove* the padding, as you would know if *you* had bothered reading what *I* posted. I've included it so you can double-check. > Maybe the padding removal is too painful given all the extra 'oh, by > the ways' that we're stumbling over. That is exactly what I'm saying. BTW, could you please fix your MUA to correctly attribute quotes? DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue May 31 20:14:21 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBDA416A41C; Tue, 31 May 2005 20:14:20 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (berlin-qwest.village.org [168.103.84.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id E010A43D48; Tue, 31 May 2005 20:14:19 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j4VKDxNv066389; Tue, 31 May 2005 14:13:59 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 31 May 2005 14:13:59 -0600 (MDT) Message-Id: <20050531.141359.41699609.imp@bsdimp.com> To: des@des.no From: Warner Losh In-Reply-To: <867jhfb1kx.fsf@xps.des.no> References: <86fyw3b4c2.fsf@xps.des.no> <20050531.140334.74683681.imp@bsdimp.com> <867jhfb1kx.fsf@xps.des.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: nectar@FreeBSD.org, standards@FreeBSD.org, freebsd-arch@FreeBSD.org, ume@FreeBSD.org, current@FreeBSD.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 20:14:21 -0000 > > Maybe the padding removal is too painful given all the extra 'oh, by > > the ways' that we're stumbling over. > > That is exactly what I'm saying. I'm starting to wonder... > BTW, could you please fix your MUA to correctly attribute quotes? I think that your last message confused it because it had quoted material from posix... Warner From owner-freebsd-arch@FreeBSD.ORG Tue May 31 20:54:57 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EBD416A41C for ; Tue, 31 May 2005 20:54:57 +0000 (GMT) (envelope-from okumoto@ucsd.edu) Received: from mailbox8.ucsd.edu (mailbox8.ucsd.edu [132.239.1.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB16443D1F for ; Tue, 31 May 2005 20:54:56 +0000 (GMT) (envelope-from okumoto@ucsd.edu) Received: from smtp.ucsd.edu (smtp-a.ucsd.edu [132.239.1.49]) by mailbox8.ucsd.edu (8.13.3/8.13.3) with ESMTP id j4VKspJC038182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 31 May 2005 13:54:52 -0700 (PDT) Received: from ucsd.edu (adsl-63-199-247-93.dsl.sndg02.pacbell.net [63.199.247.93]) by smtp.ucsd.edu (8.12.10/8.9.3) with ESMTP id j4VKspTg006349 for ; Tue, 31 May 2005 13:54:51 -0700 (PDT) Message-ID: <429CCF1B.1060702@ucsd.edu> Date: Tue, 31 May 2005 13:54:51 -0700 From: Max Okumoto User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <15835986.1117210354543.JavaMail.root@vms069.mailsrvcs.net> <1117211600.666.5.camel@opus.cse.buffalo.edu> <20050528141302.J81578@delplex.bde.org> In-Reply-To: <20050528141302.J81578@delplex.bde.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylisting: NO DELAY (Trusted relay host); processed by UCSD_GL-v1.2 on mailbox8.ucsd.edu; Tue, 31 May 2005 13:54:52 -0700 (PDT) X-MailScanner: PASSED (v1.2.8 22921 j4VKspJC038182 mailbox8.ucsd.edu) Subject: Re: Modifying file access time upon exec... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 20:54:57 -0000 Bruce Evans wrote: [lots of stuff deleted] > > The 10-second granularity might be useful here. stat() on the other > client would still need to sync with local caches/marks for update on > other clients, but the other clients and the server can know that there > is no need to sync if less than 10 seconds has elapsed since the > last tick of the 1/10 Hz clock that gives the time to possibly update > (this clock must be synchronized). > > This wouldn't work for mtimes. The granularity must be much less than > 10 seconds for make(1) to work. I'm surprised it mostly works with a > granularity of 1 second. > I can't confirm this yet, since I have not gotten to that part of make. But from the docs, it looks like make(1) caches the stat() info. Which might explain why it mostly works over NFS. make docs in the usr.bin/make/PSD.doc/tutorial.ms Section 4.1 Something you should know about the way search paths are implemented is that each directory is read, and its contents cached, exactly once -- when it is first encountered -- so any changes to the directories while PMake is running will not be noted when searching for implicit sources, nor will they be found when PMake attempts to discover when the file was last modified, unless the file was created in the cur- rent directory. While people have suggested that PMake should read the directories each time, my experience sug- gests that the caching seldom causes problems. In addition, not caching the directories slows things down enormously because of PMake's attempts to apply transformation rules through non-existent files -- the number of extra file-sys- tem searches is truly staggering, especially if many files without suffixes are used and the null suffix isn't changed from .out. Max Okumoto [stuff deleted] From owner-freebsd-arch@FreeBSD.ORG Wed Jun 1 08:11:20 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05E8A16A437 for ; Wed, 1 Jun 2005 08:11:20 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E79443D1D for ; Wed, 1 Jun 2005 08:11:18 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 39F05EB0FB0 for ; Wed, 1 Jun 2005 16:11:14 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id DFCF813270E for ; Wed, 1 Jun 2005 16:11:10 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57350-04 for ; Wed, 1 Jun 2005 16:11:02 +0800 (CST) Received: from [10.217.12.87] (unknown [61.135.152.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by beastie.frontfree.net (Postfix) with ESMTP id D1246131A61 for ; Wed, 1 Jun 2005 16:11:01 +0800 (CST) From: Xin LI To: freebsd-arch@FreeBSD.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-BIvBxZ+A8mJEjevn7c+w" Organization: The FreeBSD Simplified Chinese Project Date: Wed, 01 Jun 2005 16:10:56 +0800 Message-Id: <1117613456.771.16.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port X-Virus-Scanned: amavisd-new at frontfree.net Cc: Subject: [PATCH RFC] Add a macro for null mount options to sbin/mount* X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: delphij@delphij.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2005 08:11:20 -0000 --=-BIvBxZ+A8mJEjevn7c+w Content-Type: multipart/mixed; boundary="=-Wwib6SqbBgdjdnWAPUXo" --=-Wwib6SqbBgdjdnWAPUXo Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, -arch@, In our mount* utilities, the null mount option, which is usually be used as a terminator of an option vector, is defined with some hand-rolled terms, e.g.: {NULL}, {NULL, 0, 0, 0}, etc. I think it would be nice to have a new macro to deal with this, say, MOPT_NULL, which would be extended to {NULL, 0, 0, 0}, which can act as an explicit initialize. And in my opinion, something like: %%% opt =3D { MOPT_STD, MOPT_NULL }; %%% Looks better than: %%% opt =3D { MOPT_STD, { NULL } }; %%% That has lead to the attached patchset. May I go ahead and commit it? Thanks in advance! Cheers, --=20 Xin LI http://www.delphij.net/ --=-Wwib6SqbBgdjdnWAPUXo Content-Disposition: attachment; filename=patch-mntopts Content-Type: text/x-patch; name=patch-mntopts; charset=ISO-8859-1 Content-Transfer-Encoding: base64 SW5kZXg6IG1vdW50L21udG9wdHMuaA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMv c3JjL3NiaW4vbW91bnQvbW50b3B0cy5oLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4yNA0KZGlm ZiAtdSAtcjEuMjQgbW50b3B0cy5oDQotLS0gbW91bnQvbW50b3B0cy5oCTMwIE5vdiAyMDA0IDE5 OjM2OjQwIC0wMDAwCTEuMjQNCisrKyBtb3VudC9tbnRvcHRzLmgJMjUgTWF5IDIwMDUgMDk6NDE6 NTkgLTAwMDANCkBAIC02NSw2ICs2NSw5IEBADQogLyogVGhpcyBpcyBwYXJzZWQgYnkgbW91bnQo OCksIGJ1dCBpcyBpZ25vcmVkIGJ5IHNwZWNpZmljIG1vdW50XyooOClzLiAqLw0KICNkZWZpbmUg TU9QVF9BVVRPCQl7ICJhdXRvIiwJMCwgMCwgMCB9DQogDQorLyogQSBoYW5keSBtYWNybyBhcyB0 ZXJtaW5hdG9yIG9mIE1OVF8gYXJyYXkgKi8NCisjZGVmaW5lIE1PUFRfTlVMTAkJeyBOVUxMLAkJ MCwgMCwgMCB9DQorDQogI2RlZmluZSBNT1BUX0ZTVEFCX0NPTVBBVAkJCQkJCVwNCiAJTU9QVF9S TywJCQkJCQkJXA0KIAlNT1BUX1JXLAkJCQkJCQlcDQpJbmRleDogbW91bnQvbW91bnRfdWZzLmMN Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zYmluL21vdW50L21vdW50X3Vm cy5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4yNA0KZGlmZiAtdSAtcjEuMjQgbW91bnRfdWZz LmMNCi0tLSBtb3VudC9tb3VudF91ZnMuYwk5IEFwciAyMDA0IDE5OjU4OjMxIC0wMDAwCTEuMjQN CisrKyBtb3VudC9tb3VudF91ZnMuYwkxIEp1biAyMDA1IDA3OjU2OjAwIC0wMDAwDQpAQCAtNjQs NyArNjQsNyBAQA0KIAlNT1BUX1NZTkMsDQogCU1PUFRfVVBEQVRFLA0KIAlNT1BUX1NOQVBTSE9U LA0KLQl7IE5VTEwgfQ0KKwlNT1BUX05VTEwNCiB9Ow0KIA0KIGludA0KSW5kZXg6IG1vdW50X2Nk OTY2MC9tb3VudF9jZDk2NjAuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3Jj L3NiaW4vbW91bnRfY2Q5NjYwL21vdW50X2NkOTY2MC5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24g MS4yOA0KZGlmZiAtdSAtcjEuMjggbW91bnRfY2Q5NjYwLmMNCi0tLSBtb3VudF9jZDk2NjAvbW91 bnRfY2Q5NjYwLmMJMTMgTm92IDIwMDQgMTc6MjY6NTQgLTAwMDAJMS4yOA0KKysrIG1vdW50X2Nk OTY2MC9tb3VudF9jZDk2NjAuYwkxIEp1biAyMDA1IDA3OjU3OjM4IC0wMDAwDQpAQCAtNzcsNyAr NzcsNyBAQA0KIAl7ICJycmlwIiwgMSwgSVNPRlNNTlRfTk9SUklQLCAxIH0sDQogCXsgImpvbGll dCIsIDEsIElTT0ZTTU5UX05PSk9MSUVULCAxIH0sDQogCXsgInN0cmljdGpvbGlldCIsIDEsIElT T0ZTTU5UX0JST0tFTkpPTElFVCwgMSB9LA0KLQl7IE5VTEwgfQ0KKwlNT1BUX05VTEwNCiB9Ow0K IA0KIGludAlnZXRfc3NlY3Rvcihjb25zdCBjaGFyICpkZXYpOw0KSW5kZXg6IG1vdW50X2V4dDJm cy9tb3VudF9leHQyZnMuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3Ni aW4vbW91bnRfZXh0MmZzL21vdW50X2V4dDJmcy5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4x OA0KZGlmZiAtdSAtcjEuMTggbW91bnRfZXh0MmZzLmMNCi0tLSBtb3VudF9leHQyZnMvbW91bnRf ZXh0MmZzLmMJOSBBcHIgMjAwNCAxOTo1ODozMSAtMDAwMAkxLjE4DQorKysgbW91bnRfZXh0MmZz L21vdW50X2V4dDJmcy5jCTEgSnVuIDIwMDUgMDc6NTc6NDggLTAwMDANCkBAIC02MCw3ICs2MCw3 IEBADQogCU1PUFRfRk9SQ0UsDQogCU1PUFRfU1lOQywNCiAJTU9QVF9VUERBVEUsDQotCXsgTlVM TCB9DQorCU1PUFRfTlVMTA0KIH07DQogDQogc3RhdGljIHZvaWQJdXNhZ2Uodm9pZCkgX19kZWFk MjsNCkluZGV4OiBtb3VudF9ocGZzL21vdW50X2hwZnMuYw0KPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6 IC9ob21lL25jdnMvc3JjL3NiaW4vbW91bnRfaHBmcy9tb3VudF9ocGZzLmMsdg0KcmV0cmlldmlu ZyByZXZpc2lvbiAxLjQNCmRpZmYgLXUgLXIxLjQgbW91bnRfaHBmcy5jDQotLS0gbW91bnRfaHBm cy9tb3VudF9ocGZzLmMJNyBBdWcgMjAwMyAwNDo1MDoyOSAtMDAwMAkxLjQNCisrKyBtb3VudF9o cGZzL21vdW50X2hwZnMuYwkxIEp1biAyMDA1IDA3OjU3OjU2IC0wMDAwDQpAQCAtNTAsNyArNTAs NyBAQA0KIA0KIHN0YXRpYyBzdHJ1Y3QgbW50b3B0IG1vcHRzW10gPSB7DQogCU1PUFRfU1RET1BU UywNCi0JeyBOVUxMIH0NCisJTU9QVF9OVUxMDQogfTsNCiANCiBzdGF0aWMgZ2lkX3QJYV9naWQo Y2hhciAqKTsNCkluZGV4OiBtb3VudF9tc2Rvc2ZzL21vdW50X21zZG9zZnMuYw0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3NiaW4vbW91bnRfbXNkb3Nmcy9tb3VudF9tc2Rv c2ZzLmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjM0DQpkaWZmIC11IC1yMS4zNCBtb3VudF9t c2Rvc2ZzLmMNCi0tLSBtb3VudF9tc2Rvc2ZzL21vdW50X21zZG9zZnMuYwkzMSBBdWcgMjAwNCAw NToxOTo1NyAtMDAwMAkxLjM0DQorKysgbW91bnRfbXNkb3Nmcy9tb3VudF9tc2Rvc2ZzLmMJMSBK dW4gMjAwNSAwNzo1ODowOSAtMDAwMA0KQEAgLTczLDcgKzczLDcgQEANCiAJeyAic2hvcnRuYW1l cyIsIDAsIE1TRE9TRlNNTlRfU0hPUlROQU1FLCAxIH0sDQogCXsgImxvbmduYW1lcyIsIDAsIE1T RE9TRlNNTlRfTE9OR05BTUUsIDEgfSwNCiAJeyAibm93aW45NSIsIDAsIE1TRE9TRlNNTlRfTk9X SU45NSwgMSB9LA0KLQl7IE5VTEwgfQ0KKwlNT1BUX05VTEwNCiB9Ow0KIA0KIHN0YXRpYyBnaWRf dAlhX2dpZChjaGFyICopOw0KSW5kZXg6IG1vdW50X25mcy9tb3VudF9uZnMuYw0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3NiaW4vbW91bnRfbmZzL21vdW50X25mcy5jLHYN CnJldHJpZXZpbmcgcmV2aXNpb24gMS42Mw0KZGlmZiAtdSAtcjEuNjMgbW91bnRfbmZzLmMNCi0t LSBtb3VudF9uZnMvbW91bnRfbmZzLmMJMTAgRmViIDIwMDUgMDk6MTk6MzEgLTAwMDAJMS42Mw0K KysrIG1vdW50X25mcy9tb3VudF9uZnMuYwkxIEp1biAyMDA1IDA3OjU4OjIyIC0wMDAwDQpAQCAt MTIxLDcgKzEyMSw3IEBADQogCXsgImxvY2tkIiwgMSwgQUxURl9OT0xPQ0tELCAxIH0sDQogCXsg ImluZXQ0IiwgMSwgQUxURl9OT0lORVQ0LCAxIH0sDQogCXsgImluZXQ2IiwgMSwgQUxURl9OT0lO RVQ2LCAxIH0sDQotCXsgTlVMTCB9DQorCU1PUFRfTlVMTA0KIH07DQogDQogc3RydWN0IG5mc19h cmdzIG5mc2RlZmFyZ3MgPSB7DQpJbmRleDogbW91bnRfbmZzNC9tb3VudF9uZnM0LmMNCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zYmluL21vdW50X25mczQvbW91bnRfbmZz NC5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS41DQpkaWZmIC11IC1yMS41IG1vdW50X25mczQu Yw0KLS0tIG1vdW50X25mczQvbW91bnRfbmZzNC5jCTEwIEZlYiAyMDA1IDA5OjE5OjMxIC0wMDAw CTEuNQ0KKysrIG1vdW50X25mczQvbW91bnRfbmZzNC5jCTEgSnVuIDIwMDUgMDc6NTg6MzUgLTAw MDANCkBAIC0xNTEsNyArMTUxLDcgQEANCiAJeyAibG9ja2QiLCAxLCBBTFRGX05PTE9DS0QsIDEg fSwNCiAJeyAiaW5ldDQiLCAxLCBBTFRGX05PSU5FVDQsIDEgfSwNCiAJeyAiaW5ldDYiLCAxLCBB TFRGX05PSU5FVDYsIDEgfSwNCi0JeyBOVUxMIH0NCisJTU9QVF9OVUxMDQogfTsNCiANCiBzdHJ1 Y3QgbmZzX2FyZ3MgbmZzZGVmYXJncyA9IHsNCkluZGV4OiBtb3VudF9udGZzL21vdW50X250ZnMu Yw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3NiaW4vbW91bnRfbnRmcy9t b3VudF9udGZzLmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjEyDQpkaWZmIC11IC1yMS4xMiBt b3VudF9udGZzLmMNCi0tLSBtb3VudF9udGZzL21vdW50X250ZnMuYwkxMCBGZWIgMjAwNSAwOTox OTozMSAtMDAwMAkxLjEyDQorKysgbW91bnRfbnRmcy9tb3VudF9udGZzLmMJMSBKdW4gMjAwNSAw Nzo1ODo0OSAtMDAwMA0KQEAgLTU4LDcgKzU4LDcgQEANCiANCiBzdGF0aWMgc3RydWN0IG1udG9w dCBtb3B0c1tdID0gew0KIAlNT1BUX1NURE9QVFMsDQotCXsgTlVMTCB9DQorCU1PUFRfTlVMTA0K IH07DQogDQogc3RhdGljIGdpZF90CWFfZ2lkKGNoYXIgKik7DQpJbmRleDogbW91bnRfbnVsbGZz L21vdW50X251bGxmcy5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc2Jp bi9tb3VudF9udWxsZnMvbW91bnRfbnVsbGZzLmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjIz DQpkaWZmIC11IC1yMS4yMyBtb3VudF9udWxsZnMuYw0KLS0tIG1vdW50X251bGxmcy9tb3VudF9u dWxsZnMuYwkxMCBGZWIgMjAwNSAwOToxOTozMSAtMDAwMAkxLjIzDQorKysgbW91bnRfbnVsbGZz L21vdW50X251bGxmcy5jCTEgSnVuIDIwMDUgMDc6NTg6NTggLTAwMDANCkBAIC01OSw3ICs1OSw3 IEBADQogDQogc3RydWN0IG1udG9wdCBtb3B0c1tdID0gew0KIAlNT1BUX1NURE9QVFMsDQotCXsg TlVMTCB9DQorCU1PUFRfTlVMTA0KIH07DQogDQogaW50CXN1YmRpcihjb25zdCBjaGFyICosIGNv bnN0IGNoYXIgKik7DQpJbmRleDogbW91bnRfcmVpc2VyZnMvbW91bnRfcmVpc2VyZnMuYw0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3NiaW4vbW91bnRfcmVpc2VyZnMvbW91 bnRfcmVpc2VyZnMuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMQ0KZGlmZiAtdSAtcjEuMSBt b3VudF9yZWlzZXJmcy5jDQotLS0gbW91bnRfcmVpc2VyZnMvbW91bnRfcmVpc2VyZnMuYwkyNCBN YXkgMjAwNSAxMjozNDo0NSAtMDAwMAkxLjENCisrKyBtb3VudF9yZWlzZXJmcy9tb3VudF9yZWlz ZXJmcy5jCTI1IE1heSAyMDA1IDA5OjQwOjQxIC0wMDAwDQpAQCAtNDEsNyArNDEsNyBAQA0KIA0K IHN0cnVjdCBtbnRvcHQgbW9wdHNbXSA9IHsNCiAJTU9QVF9TVERPUFRTLA0KLQl7IE5VTEwgfQ0K KwlNT1BUX05VTEwNCiB9Ow0KIA0KIHZvaWQJdXNhZ2Uodm9pZCk7DQpJbmRleDogbW91bnRfc3Rk L21vdW50X3N0ZC5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc2Jpbi9t b3VudF9zdGQvbW91bnRfc3RkLmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjE5DQpkaWZmIC11 IC1yMS4xOSBtb3VudF9zdGQuYw0KLS0tIG1vdW50X3N0ZC9tb3VudF9zdGQuYwk5IEFwciAyMDA0 IDE5OjU4OjMyIC0wMDAwCTEuMTkNCisrKyBtb3VudF9zdGQvbW91bnRfc3RkLmMJMSBKdW4gMjAw NSAwNzo1OToxNiAtMDAwMA0KQEAgLTU5LDcgKzU5LDcgQEANCiANCiBzdGF0aWMgc3RydWN0IG1u dG9wdCBtb3B0c1tdID0gew0KIAlNT1BUX1NURE9QVFMsDQotCXsgTlVMTCB9DQorCU1PUFRfTlVM TA0KIH07DQogDQogc3RhdGljIGNoYXIgKmZzbmFtZTsNCkluZGV4OiBtb3VudF91ZGYvbW91bnRf dWRmLmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zYmluL21vdW50X3Vk Zi9tb3VudF91ZGYuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTENCmRpZmYgLXUgLXIxLjEx IG1vdW50X3VkZi5jDQotLS0gbW91bnRfdWRmL21vdW50X3VkZi5jCTkgQXByIDIwMDQgMjA6MzQ6 NTEgLTAwMDAJMS4xMQ0KKysrIG1vdW50X3VkZi9tb3VudF91ZGYuYwkxIEp1biAyMDA1IDA3OjU5 OjI0IC0wMDAwDQpAQCAtNjQsNyArNjQsNyBAQA0KIHN0cnVjdCBtbnRvcHQgbW9wdHNbXSA9IHsN CiAJTU9QVF9TVERPUFRTLA0KIAlNT1BUX1VQREFURSwNCi0JeyBOVUxMLCAwLCAwLCAwIH0NCisJ TU9QVF9OVUxMDQogfTsNCiANCiBpbnQJc2V0X2NoYXJzZXQoY2hhciAqKiwgY2hhciAqKiwgY29u c3QgY2hhciAqKTsNCkluZGV4OiBtb3VudF91ZnMvbW91bnRfdWZzLmMNCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJD UyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zYmluL21vdW50X3Vmcy9tb3VudF91ZnMuYyx2DQpyZXRy aWV2aW5nIHJldmlzaW9uIDEuMg0KZGlmZiAtdSAtcjEuMiBtb3VudF91ZnMuYw0KLS0tIG1vdW50 X3Vmcy9tb3VudF91ZnMuYwkyOCBNYXIgMjAwNSAyMjoyMTo0NSAtMDAwMAkxLjINCisrKyBtb3Vu dF91ZnMvbW91bnRfdWZzLmMJMSBKdW4gMjAwNSAwNzo1OTozMiAtMDAwMA0KQEAgLTYxLDcgKzYx LDcgQEANCiAJTU9QVF9TWU5DLA0KIAlNT1BUX1VQREFURSwNCiAJTU9QVF9TTkFQU0hPVCwNCi0J eyBOVUxMIH0NCisJTU9QVF9OVUxMDQogfTsNCiANCiB2b2lkCXVzYWdlKHZvaWQpOw0KSW5kZXg6 IG1vdW50X3VtYXBmcy9tb3VudF91bWFwZnMuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21l L25jdnMvc3JjL3NiaW4vbW91bnRfdW1hcGZzL21vdW50X3VtYXBmcy5jLHYNCnJldHJpZXZpbmcg cmV2aXNpb24gMS4yMw0KZGlmZiAtdSAtcjEuMjMgbW91bnRfdW1hcGZzLmMNCi0tLSBtb3VudF91 bWFwZnMvbW91bnRfdW1hcGZzLmMJMTAgRmViIDIwMDUgMDk6MTk6MzIgLTAwMDAJMS4yMw0KKysr IG1vdW50X3VtYXBmcy9tb3VudF91bWFwZnMuYwkxIEp1biAyMDA1IDA3OjU5OjQwIC0wMDAwDQpA QCAtNzksNyArNzksNyBAQA0KIA0KIHN0YXRpYyBzdHJ1Y3QgbW50b3B0IG1vcHRzW10gPSB7DQog CU1PUFRfU1RET1BUUywNCi0JeyBOVUxMIH0NCisJTU9QVF9OVUxMDQogfTsNCiANCiBzdGF0aWMg dm9pZAl1c2FnZSh2b2lkKSBfX2RlYWQyOw0KSW5kZXg6IG1vdW50X3VuaW9uZnMvbW91bnRfdW5p b25mcy5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc2Jpbi9tb3VudF91 bmlvbmZzL21vdW50X3VuaW9uZnMuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjINCmRpZmYg LXUgLXIxLjIyIG1vdW50X3VuaW9uZnMuYw0KLS0tIG1vdW50X3VuaW9uZnMvbW91bnRfdW5pb25m cy5jCTEwIEZlYiAyMDA1IDA5OjE5OjMyIC0wMDAwCTEuMjINCisrKyBtb3VudF91bmlvbmZzL21v dW50X3VuaW9uZnMuYwkxIEp1biAyMDA1IDA3OjU5OjQ5IC0wMDAwDQpAQCAtNjAsNyArNjAsNyBA QA0KIA0KIHN0YXRpYyBzdHJ1Y3QgbW50b3B0IG1vcHRzW10gPSB7DQogCU1PUFRfU1RET1BUUywN Ci0JeyBOVUxMIH0NCisJTU9QVF9OVUxMDQogfTsNCiANCiBzdGF0aWMgaW50CXN1YmRpcihjb25z dCBjaGFyICosIGNvbnN0IGNoYXIgKik7DQo= --=-Wwib6SqbBgdjdnWAPUXo-- --=-BIvBxZ+A8mJEjevn7c+w Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCnW2Q/cVsHxFZiIoRAjyaAJ9d8CWW7NzifyMYFRtXZm1oZHLB3gCdGhcc O3qA9xIih1OM24pWIF0cJoA= =YOjG -----END PGP SIGNATURE----- --=-BIvBxZ+A8mJEjevn7c+w-- From owner-freebsd-arch@FreeBSD.ORG Wed Jun 1 09:17:35 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63E9116A41C for ; Wed, 1 Jun 2005 09:17:35 +0000 (GMT) (envelope-from mux@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BB4843D49 for ; Wed, 1 Jun 2005 09:17:34 +0000 (GMT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id D0F8E5C971; Wed, 1 Jun 2005 02:17:34 -0700 (PDT) Date: Wed, 1 Jun 2005 11:17:34 +0200 From: Maxime Henrion To: delphij@delphij.net Message-ID: <20050601091734.GA14661@elvis.mu.org> References: <1117613456.771.16.camel@spirit> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117613456.771.16.camel@spirit> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arch@FreeBSD.org Subject: Re: [PATCH RFC] Add a macro for null mount options to sbin/mount* X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2005 09:17:35 -0000 Xin LI wrote: > Hi, -arch@, > > In our mount* utilities, the null mount option, which is usually be used > as a terminator of an option vector, is defined with some hand-rolled > terms, e.g.: {NULL}, {NULL, 0, 0, 0}, etc. > > I think it would be nice to have a new macro to deal with this, say, > MOPT_NULL, which would be extended to {NULL, 0, 0, 0}, which can act as > an explicit initialize. And in my opinion, something like: > > %%% > opt = { > MOPT_STD, > MOPT_NULL > }; > %%% > > Looks better than: > > %%% > opt = { > MOPT_STD, > { NULL } > }; > %%% > > That has lead to the attached patchset. May I go ahead and commit it? This is definitely nice. Please commit! Cheers, Maxime From owner-freebsd-arch@FreeBSD.ORG Wed Jun 1 09:43:38 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2794316A41C for ; Wed, 1 Jun 2005 09:43:38 +0000 (GMT) (envelope-from jspedron@club-internet.fr) Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id C62A143D1D for ; Wed, 1 Jun 2005 09:43:37 +0000 (GMT) (envelope-from jspedron@club-internet.fr) Received: from [172.16.142.1] (213-223-184-193.dti.cegetel.net [213.223.184.193]) by smtp.cegetel.net (Postfix) with ESMTP id 6F08F1A4620; Wed, 1 Jun 2005 11:42:36 +0200 (CEST) Message-ID: <429D8349.5050404@club-internet.fr> Date: Wed, 01 Jun 2005 11:43:37 +0200 From: =?ISO-8859-15?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20050208 X-Accept-Language: fr-fr, fr, en-us, en, ja MIME-Version: 1.0 To: delphij@delphij.net References: <1117613456.771.16.camel@spirit> In-Reply-To: <1117613456.771.16.camel@spirit> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6B70081B81CD925B59F5ED70" Content-Transfer-Encoding: 8bit Cc: freebsd-arch@freebsd.org Subject: Re: [PATCH RFC] Add a macro for null mount options to sbin/mount* X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2005 09:43:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6B70081B81CD925B59F5ED70 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Xin LI wrote: > Hi, -arch@, > > In our mount* utilities, the null mount option, which is usually be used > as a terminator of an option vector, is defined with some hand-rolled > terms, e.g.: {NULL}, {NULL, 0, 0, 0}, etc. > > I think it would be nice to have a new macro to deal with this, say, > MOPT_NULL, which would be extended to {NULL, 0, 0, 0}, which can act as > an explicit initialize. And in my opinion, something like: This idea is really great, but may I suggest a name like MOPT_END or MOPT_LIST_END? Because the macro should indicate the end of this vector, not by what it'll be replaced. Regards, -- Jean-Sébastien Pédron http://www.dumbbell.fr/ PGP Key: http://www.dumbbell.fr/pgp/pubkey.asc --------------enig6B70081B81CD925B59F5ED70 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCnYNOa+xGJsFYOlMRAnlJAJ4m4V/Zf9845ShKV7fFyn1gpaSf/ACePvf+ KWzQqilSDJRnVSCXINVDJV8= =lnVb -----END PGP SIGNATURE----- --------------enig6B70081B81CD925B59F5ED70-- From owner-freebsd-arch@FreeBSD.ORG Wed Jun 1 11:23:37 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1996C16A41C for ; Wed, 1 Jun 2005 11:23:37 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EFC143D48 for ; Wed, 1 Jun 2005 11:23:36 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j51BNOkG007300; Wed, 1 Jun 2005 21:23:24 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j51BNMqB019842; Wed, 1 Jun 2005 21:23:23 +1000 Date: Wed, 1 Jun 2005 21:23:23 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: delphij@delphij.net In-Reply-To: <1117613456.771.16.camel@spirit> Message-ID: <20050601211628.V96009@delplex.bde.org> References: <1117613456.771.16.camel@spirit> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: [PATCH RFC] Add a macro for null mount options to sbin/mount* X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2005 11:23:37 -0000 On Wed, 1 Jun 2005, Xin LI wrote: > In our mount* utilities, the null mount option, which is usually be used > as a terminator of an option vector, is defined with some hand-rolled > terms, e.g.: {NULL}, {NULL, 0, 0, 0}, etc. "{ NULL }" is the documented way. See getmntopts.3. > I think it would be nice to have a new macro to deal with this, say, > MOPT_NULL, which would be extended to {NULL, 0, 0, 0}, which can act as > an explicit initialize. And in my opinion, something like: > > %%% > opt = { > MOPT_STD, > MOPT_NULL > }; > %%% MOPT_NULL is a poor name. It is not a null option, but a terminator that happens to have nulls in it. Bruce From owner-freebsd-arch@FreeBSD.ORG Wed Jun 1 12:44:25 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EF9A16A41C for ; Wed, 1 Jun 2005 12:44:25 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C26D43D1D for ; Wed, 1 Jun 2005 12:44:23 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (ume@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j51Ci5BY055893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2005 21:44:10 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 01 Jun 2005 21:44:03 +0900 Message-ID: From: Hajimu UMEMOTO To: freebsd-arch@freebsd.org, standards@freebsd.org, current@freebsd.org In-Reply-To: References: <20050531.075329.118637972.imp@bsdimp.com> <20050531.084832.20036038.imp@bsdimp.com> <86fyw32yqm.fsf@xps.des.no> <86k6lfbafu.fsf@xps.des.no> User-Agent: xcite1.38> Wanderlust/2.15.1 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.4) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.4-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Wed_Jun__1_21:44:03_2005-1" X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-2.0b5 (cheer.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Wed, 01 Jun 2005 21:44:12 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on cheer.mahoroba.org Cc: nectar@freebsd.org, des@des.no Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2005 12:44:25 -0000 --Multipart_Wed_Jun__1_21:44:03_2005-1 Content-Type: text/plain; charset=US-ASCII Hi, >>>>> On Wed, 01 Jun 2005 03:00:10 +0900 >>>>> Hajimu UMEMOTO said: ume> In anyway, there is one more issue in my patch. We cannot correct 1st ume> argument of getnetbyaddr(3) without breaking ABI compatibility. ume> Fortunately, getnetbyaddr(3) is not refered else where in our ume> libraries. So, I'll fix getnetbyaddr(3). I've attached the patch to correct 1st argument of getnetbyaddr(3) in this mail. It is subset of my previous patch. Since it breaks ABI compatibility of getnetbyaddr(3), I think it is better to correct n_net member of struct netent, too. Since there is objection, the patch leaves struct addrinfo as is. So, it doesn't need to bump any shlib major. Is it okay? Sincerely, --Multipart_Wed_Jun__1_21:44:03_2005-1 Content-Type: text/x-patch; charset=US-ASCII Content-Disposition: attachment; filename="netdb.h-fix-getnetbyadr.diff" Content-Transfer-Encoding: 7bit Index: include/netdb.h diff -u include/netdb.h.orig include/netdb.h --- include/netdb.h.orig Sat May 28 01:20:40 2005 +++ include/netdb.h Sat May 28 01:31:52 2005 @@ -105,28 +103,11 @@ #define h_addr h_addr_list[0] /* address, for backward compatibility */ }; -/* - * Note: n_net used to be an unsigned long integer. - * In XNS5, and subsequently in POSIX-2001 it was changed to an - * uint32_t. - * To accomodate for this while preserving binary compatibility with - * the old interface, we prepend or append 32 bits of padding, - * depending on the (LP64) architecture's endianness. - * - * This should be deleted the next time the libc major number is - * incremented. - */ struct netent { char *n_name; /* official name of net */ char **n_aliases; /* alias list */ int n_addrtype; /* net address type */ -#if __LONG_BIT == 64 && _BYTE_ORDER == _BIG_ENDIAN - uint32_t __n_pad0; /* ABI compatibility */ -#endif uint32_t n_net; /* network # */ -#if __LONG_BIT == 64 && _BYTE_ORDER == _LITTLE_ENDIAN - uint32_t __n_pad0; /* ABI compatibility */ -#endif }; struct servent { @@ -262,11 +226,7 @@ struct hostent *gethostent(void); struct hostent *getipnodebyaddr(const void *, size_t, int, int *); struct hostent *getipnodebyname(const char *, int, int, int *); -#if __LONG_BIT == 64 -struct netent *getnetbyaddr(unsigned long, int); /* ABI compatibility */ -#else struct netent *getnetbyaddr(uint32_t, int); -#endif struct netent *getnetbyname(const char *); struct netent *getnetent(void); int getnetgrent(char **, char **, char **); Index: lib/libc/net/getnetbydns.c diff -u -p lib/libc/net/getnetbydns.c.orig lib/libc/net/getnetbydns.c --- lib/libc/net/getnetbydns.c.orig Sat May 28 01:24:33 2005 +++ lib/libc/net/getnetbydns.c Sat May 28 01:36:52 2005 @@ -259,9 +259,6 @@ getnetanswer(querybuf *answer, int ansle break; } ne->n_aliases++; -#if __LONG_BIT == 64 - ne->__n_pad0 = 0; /* ABI compatibility */ -#endif return 0; } h_errno = TRY_AGAIN; @@ -334,9 +331,6 @@ _dns_getnetbyaddr(void *rval, void *cb_d while ((net & 0xff) == 0 && net != 0) net >>= 8; ne->n_net = net; -#if __LONG_BIT == 64 - ne->__n_pad0 = 0; /* ABI compatibility */ -#endif return NS_SUCCESS; } return NS_NOTFOUND; Index: lib/libc/net/getnetbyht.c diff -u -p lib/libc/net/getnetbyht.c.orig lib/libc/net/getnetbyht.c --- lib/libc/net/getnetbyht.c.orig Sat May 28 01:24:33 2005 +++ lib/libc/net/getnetbyht.c Sat May 28 01:37:13 2005 @@ -122,9 +122,6 @@ again: if (p != NULL) *p++ = '\0'; ne->n_net = inet_network(cp); -#if __LONG_BIT == 64 - ne->__n_pad0 = 0; /* ABI compatibility */ -#endif ne->n_addrtype = AF_INET; q = ne->n_aliases = ned->net_aliases; if (p != NULL) { Index: lib/libc/net/getnetbynis.c diff -u -p lib/libc/net/getnetbynis.c.orig lib/libc/net/getnetbynis.c --- lib/libc/net/getnetbynis.c.orig Sat May 28 01:24:33 2005 +++ lib/libc/net/getnetbynis.c Sat May 28 01:37:35 2005 @@ -99,9 +99,6 @@ _getnetbynis(const char *name, char *map cp++; ne->n_net = inet_network(cp); -#if __LONG_BIT == 64 - ne->__n_pad0 = 0; /* ABI compatibility */ -#endif ne->n_addrtype = AF_INET; q = ne->n_aliases = ned->net_aliases; Index: lib/libc/net/getnetnamadr.c diff -u -p lib/libc/net/getnetnamadr.c.orig lib/libc/net/getnetnamadr.c --- lib/libc/net/getnetnamadr.c.orig Sat May 28 01:35:00 2005 +++ lib/libc/net/getnetnamadr.c Sat May 28 01:35:32 2005 @@ -165,17 +165,13 @@ getnetbyname(const char *name) } struct netent * -#if __LONG_BIT == 64 -getnetbyaddr(u_long addr, int af) /* ABI compatibility */ -#else getnetbyaddr(uint32_t addr, int af) -#endif { struct netdata *nd; if ((nd = __netdata_init()) == NULL) return NULL; - if (getnetbyaddr_r((uint32_t)addr, af, &nd->net, &nd->data) != 0) + if (getnetbyaddr_r(addr, af, &nd->net, &nd->data) != 0) return NULL; return &nd->net; } --Multipart_Wed_Jun__1_21:44:03_2005-1 Content-Type: text/plain; charset=US-ASCII -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Wed_Jun__1_21:44:03_2005-1-- From owner-freebsd-arch@FreeBSD.ORG Wed Jun 1 13:44:20 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 198FA16A41C for ; Wed, 1 Jun 2005 13:44:20 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D0AD43D48 for ; Wed, 1 Jun 2005 13:44:19 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id CA6B2EB104D for ; Wed, 1 Jun 2005 21:44:15 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id EA939132137; Wed, 1 Jun 2005 21:44:01 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76025-05; Wed, 1 Jun 2005 21:43:54 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id E328E1319E8; Wed, 1 Jun 2005 21:43:51 +0800 (CST) Date: Wed, 1 Jun 2005 21:43:51 +0800 From: Xin LI To: Bruce Evans Message-ID: <20050601134351.GA76097@frontfree.net> References: <1117613456.771.16.camel@spirit> <20050601211628.V96009@delplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GID0FwUMdk1T2AWN" Content-Disposition: inline In-Reply-To: <20050601211628.V96009@delplex.bde.org> User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.4-RELEASE-p1 FreeBSD 5.4-RELEASE-p1 #1: Fri May 27 00:47:15 CST 2005 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: amavisd-new at frontfree.net Cc: delphij@delphij.net, freebsd-arch@freebsd.org Subject: Re: [PATCH RFC] Add a macro for null mount options to sbin/mount* X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2005 13:44:20 -0000 --GID0FwUMdk1T2AWN Content-Type: multipart/mixed; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 01, 2005 at 09:23:23PM +1000, Bruce Evans wrote: > On Wed, 1 Jun 2005, Xin LI wrote: >=20 > >In our mount* utilities, the null mount option, which is usually be used > >as a terminator of an option vector, is defined with some hand-rolled > >terms, e.g.: {NULL}, {NULL, 0, 0, 0}, etc. >=20 > "{ NULL }" is the documented way. See getmntopts.3. > > >I think it would be nice to have a new macro to deal with this, say, > >MOPT_NULL, which would be extended to {NULL, 0, 0, 0}, which can act as > >an explicit initialize. And in my opinion, something like: > > > >%%% > >opt =3D { > > MOPT_STD, > > MOPT_NULL > >}; > >%%% >=20 > MOPT_NULL is a poor name. It is not a null option, but a terminator that > happens to have nulls in it. Agreed... Will the patch found in attachment look better? It also updates the manpage. Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch-mntopts Content-Transfer-Encoding: quoted-printable Index: mount/getmntopts.3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/mount/getmntopts.3,v retrieving revision 1.13 diff -u -r1.13 getmntopts.3 --- mount/getmntopts.3 9 Apr 2004 19:58:30 -0000 1.13 +++ mount/getmntopts.3 1 Jun 2005 13:41:47 -0000 @@ -28,7 +28,7 @@ .\" @(#)getmntopts.3 8.3 (Berkeley) 3/30/95 .\" $FreeBSD: src/sbin/mount/getmntopts.3,v 1.13 2004/04/09 19:58:30 markm= Exp $ .\" -.Dd March 30, 1995 +.Dd June 1, 2005 .Dt GETMNTOPTS 3 .Os .Sh NAME @@ -148,7 +148,7 @@ struct mntopt mopts[] =3D { MOPT_STDOPTS, MOPT_UPDATE, - { NULL } + MOPT_LIST_END }; =20 ... Index: mount/mntopts.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/mount/mntopts.h,v retrieving revision 1.25 diff -u -r1.25 mntopts.h --- mount/mntopts.h 1 Jun 2005 09:39:34 -0000 1.25 +++ mount/mntopts.h 1 Jun 2005 13:35:57 -0000 @@ -66,7 +66,7 @@ #define MOPT_AUTO { "auto", 0, 0, 0 } =20 /* A handy macro as terminator of MNT_ array */ -#define MOPT_NULL { NULL, 0, 0, 0 } +#define MOPT_LIST_END { NULL, 0, 0, 0 } =20 #define MOPT_FSTAB_COMPAT \ MOPT_RO, \ Index: mount/mount_ufs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/mount/mount_ufs.c,v retrieving revision 1.25 diff -u -r1.25 mount_ufs.c --- mount/mount_ufs.c 1 Jun 2005 09:39:34 -0000 1.25 +++ mount/mount_ufs.c 1 Jun 2005 13:34:51 -0000 @@ -64,7 +64,7 @@ MOPT_SYNC, MOPT_UPDATE, MOPT_SNAPSHOT, - MOPT_NULL + MOPT_LIST_END }; =20 int Index: mount_cd9660/mount_cd9660.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/mount_cd9660/mount_cd9660.c,v retrieving revision 1.29 diff -u -r1.29 mount_cd9660.c --- mount_cd9660/mount_cd9660.c 1 Jun 2005 09:39:34 -0000 1.29 +++ mount_cd9660/mount_cd9660.c 1 Jun 2005 13:34:51 -0000 @@ -77,7 +77,7 @@ { "rrip", 1, ISOFSMNT_NORRIP, 1 }, { "joliet", 1, ISOFSMNT_NOJOLIET, 1 }, { "strictjoliet", 1, ISOFSMNT_BROKENJOLIET, 1 }, - MOPT_NULL + MOPT_LIST_END }; =20 int get_ssector(const char *dev); Index: mount_ext2fs/mount_ext2fs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/mount_ext2fs/mount_ext2fs.c,v retrieving revision 1.19 diff -u -r1.19 mount_ext2fs.c --- mount_ext2fs/mount_ext2fs.c 1 Jun 2005 09:39:34 -0000 1.19 +++ mount_ext2fs/mount_ext2fs.c 1 Jun 2005 13:34:51 -0000 @@ -60,7 +60,7 @@ MOPT_FORCE, MOPT_SYNC, MOPT_UPDATE, - MOPT_NULL + MOPT_LIST_END }; =20 static void usage(void) __dead2; Index: mount_hpfs/mount_hpfs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/mount_hpfs/mount_hpfs.c,v retrieving revision 1.5 diff -u -r1.5 mount_hpfs.c --- mount_hpfs/mount_hpfs.c 1 Jun 2005 09:39:34 -0000 1.5 +++ mount_hpfs/mount_hpfs.c 1 Jun 2005 13:34:51 -0000 @@ -50,7 +50,7 @@ =20 static struct mntopt mopts[] =3D { MOPT_STDOPTS, - MOPT_NULL + MOPT_LIST_END }; =20 static gid_t a_gid(char *); Index: mount_msdosfs/mount_msdosfs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/mount_msdosfs/mount_msdosfs.c,v retrieving revision 1.35 diff -u -r1.35 mount_msdosfs.c --- mount_msdosfs/mount_msdosfs.c 1 Jun 2005 09:39:34 -0000 1.35 +++ mount_msdosfs/mount_msdosfs.c 1 Jun 2005 13:34:51 -0000 @@ -73,7 +73,7 @@ { "shortnames", 0, MSDOSFSMNT_SHORTNAME, 1 }, { "longnames", 0, MSDOSFSMNT_LONGNAME, 1 }, { "nowin95", 0, MSDOSFSMNT_NOWIN95, 1 }, - MOPT_NULL + MOPT_LIST_END }; =20 static gid_t a_gid(char *); Index: mount_nfs/mount_nfs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/mount_nfs/mount_nfs.c,v retrieving revision 1.64 diff -u -r1.64 mount_nfs.c --- mount_nfs/mount_nfs.c 1 Jun 2005 09:39:35 -0000 1.64 +++ mount_nfs/mount_nfs.c 1 Jun 2005 13:34:51 -0000 @@ -121,7 +121,7 @@ { "lockd", 1, ALTF_NOLOCKD, 1 }, { "inet4", 1, ALTF_NOINET4, 1 }, { "inet6", 1, ALTF_NOINET6, 1 }, - MOPT_NULL + MOPT_LIST_END }; =20 struct nfs_args nfsdefargs =3D { Index: mount_nfs4/mount_nfs4.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/mount_nfs4/mount_nfs4.c,v retrieving revision 1.6 diff -u -r1.6 mount_nfs4.c --- mount_nfs4/mount_nfs4.c 1 Jun 2005 09:39:35 -0000 1.6 +++ mount_nfs4/mount_nfs4.c 1 Jun 2005 13:34:51 -0000 @@ -151,7 +151,7 @@ { "lockd", 1, ALTF_NOLOCKD, 1 }, { "inet4", 1, ALTF_NOINET4, 1 }, { "inet6", 1, ALTF_NOINET6, 1 }, - MOPT_NULL + MOPT_LIST_END }; =20 struct nfs_args nfsdefargs =3D { Index: mount_ntfs/mount_ntfs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/mount_ntfs/mount_ntfs.c,v retrieving revision 1.13 diff -u -r1.13 mount_ntfs.c --- mount_ntfs/mount_ntfs.c 1 Jun 2005 09:39:35 -0000 1.13 +++ mount_ntfs/mount_ntfs.c 1 Jun 2005 13:34:51 -0000 @@ -58,7 +58,7 @@ =20 static struct mntopt mopts[] =3D { MOPT_STDOPTS, - MOPT_NULL + MOPT_LIST_END }; =20 static gid_t a_gid(char *); Index: mount_nullfs/mount_nullfs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/mount_nullfs/mount_nullfs.c,v retrieving revision 1.24 diff -u -r1.24 mount_nullfs.c --- mount_nullfs/mount_nullfs.c 1 Jun 2005 09:39:35 -0000 1.24 +++ mount_nullfs/mount_nullfs.c 1 Jun 2005 13:34:51 -0000 @@ -59,7 +59,7 @@ =20 struct mntopt mopts[] =3D { MOPT_STDOPTS, - MOPT_NULL + MOPT_LIST_END }; =20 int subdir(const char *, const char *); Index: mount_reiserfs/mount_reiserfs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/mount_reiserfs/mount_reiserfs.c,v retrieving revision 1.2 diff -u -r1.2 mount_reiserfs.c --- mount_reiserfs/mount_reiserfs.c 1 Jun 2005 09:39:35 -0000 1.2 +++ mount_reiserfs/mount_reiserfs.c 1 Jun 2005 13:34:51 -0000 @@ -41,7 +41,7 @@ =20 struct mntopt mopts[] =3D { MOPT_STDOPTS, - MOPT_NULL + MOPT_LIST_END }; =20 void usage(void); Index: mount_std/mount_std.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/mount_std/mount_std.c,v retrieving revision 1.20 diff -u -r1.20 mount_std.c --- mount_std/mount_std.c 1 Jun 2005 09:39:36 -0000 1.20 +++ mount_std/mount_std.c 1 Jun 2005 13:34:51 -0000 @@ -59,7 +59,7 @@ =20 static struct mntopt mopts[] =3D { MOPT_STDOPTS, - MOPT_NULL + MOPT_LIST_END }; =20 static char *fsname; Index: mount_udf/mount_udf.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/mount_udf/mount_udf.c,v retrieving revision 1.12 diff -u -r1.12 mount_udf.c --- mount_udf/mount_udf.c 1 Jun 2005 09:39:36 -0000 1.12 +++ mount_udf/mount_udf.c 1 Jun 2005 13:34:51 -0000 @@ -64,7 +64,7 @@ struct mntopt mopts[] =3D { MOPT_STDOPTS, MOPT_UPDATE, - MOPT_NULL + MOPT_LIST_END }; =20 int set_charset(char **, char **, const char *); Index: mount_ufs/mount_ufs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/mount_ufs/mount_ufs.c,v retrieving revision 1.3 diff -u -r1.3 mount_ufs.c --- mount_ufs/mount_ufs.c 1 Jun 2005 09:39:36 -0000 1.3 +++ mount_ufs/mount_ufs.c 1 Jun 2005 13:34:51 -0000 @@ -61,7 +61,7 @@ MOPT_SYNC, MOPT_UPDATE, MOPT_SNAPSHOT, - MOPT_NULL + MOPT_LIST_END }; =20 void usage(void); Index: mount_umapfs/mount_umapfs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/mount_umapfs/mount_umapfs.c,v retrieving revision 1.24 diff -u -r1.24 mount_umapfs.c --- mount_umapfs/mount_umapfs.c 1 Jun 2005 09:39:36 -0000 1.24 +++ mount_umapfs/mount_umapfs.c 1 Jun 2005 13:34:51 -0000 @@ -79,7 +79,7 @@ =20 static struct mntopt mopts[] =3D { MOPT_STDOPTS, - MOPT_NULL + MOPT_LIST_END }; =20 static void usage(void) __dead2; Index: mount_unionfs/mount_unionfs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/mount_unionfs/mount_unionfs.c,v retrieving revision 1.23 diff -u -r1.23 mount_unionfs.c --- mount_unionfs/mount_unionfs.c 1 Jun 2005 09:39:36 -0000 1.23 +++ mount_unionfs/mount_unionfs.c 1 Jun 2005 13:34:51 -0000 @@ -60,7 +60,7 @@ =20 static struct mntopt mopts[] =3D { MOPT_STDOPTS, - MOPT_NULL + MOPT_LIST_END }; =20 static int subdir(const char *, const char *); --xHFwDpU9dbj6ez1V-- --GID0FwUMdk1T2AWN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD4DBQFCnbuX/cVsHxFZiIoRAu/oAJdFffiFCbzp+3sXNGto2/X2wQQwAJ4/VbFm gExDd+t75Y+42k6sKjqdLQ== =TynJ -----END PGP SIGNATURE----- --GID0FwUMdk1T2AWN-- From owner-freebsd-arch@FreeBSD.ORG Wed Jun 1 15:04:01 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D36816A41C for ; Wed, 1 Jun 2005 15:04:01 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 640BA43D49 for ; Wed, 1 Jun 2005 15:04:01 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j51F3jc1009032; Wed, 1 Jun 2005 08:03:45 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j51F3iKx009031; Wed, 1 Jun 2005 08:03:44 -0700 (PDT) (envelope-from obrien) Date: Wed, 1 Jun 2005 08:03:44 -0700 From: "David O'Brien" To: delphij@delphij.net Message-ID: <20050601150344.GA39784@dragon.NUXI.org> Mail-Followup-To: freebsd-arch@freebsd.org, delphij@delphij.net References: <1117613456.771.16.camel@spirit> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117613456.771.16.camel@spirit> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-arch@FreeBSD.org Subject: Re: [PATCH RFC] Add a macro for null mount options to sbin/mount* X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-arch@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2005 15:04:01 -0000 On Wed, Jun 01, 2005 at 04:10:56PM +0800, Xin LI wrote: > Hi, -arch@, > > In our mount* utilities, the null mount option, which is usually be used > as a terminator of an option vector, is defined with some hand-rolled > terms, e.g.: {NULL}, {NULL, 0, 0, 0}, etc. > > I think it would be nice to have a new macro to deal with this, say, > MOPT_NULL, which would be extended to {NULL, 0, 0, 0}, which can act as > an explicit initialize. And in my opinion, something like: I think it is better to leave it alone. The "NULL" termination of a list like this is a C idiom that should be clear to any C programmer. Hiding the details in a macro (is MOPT_NULL an integer or a sentinel?) makes it harder to see the idiom and know exactly what is going on and how this list will be processed. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Wed Jun 1 15:06:52 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6479316A41C for ; Wed, 1 Jun 2005 15:06:52 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CDC643D48 for ; Wed, 1 Jun 2005 15:06:52 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j51F6h4k034071; Wed, 1 Jun 2005 08:06:43 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j51F6fXL034070; Wed, 1 Jun 2005 08:06:41 -0700 (PDT) (envelope-from rizzo) Date: Wed, 1 Jun 2005 08:06:41 -0700 From: Luigi Rizzo To: freebsd-arch@freebsd.org, delphij@delphij.net Message-ID: <20050601080641.H30391@xorpc.icir.org> References: <1117613456.771.16.camel@spirit> <20050601150344.GA39784@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20050601150344.GA39784@dragon.NUXI.org>; from obrien@freebsd.org on Wed, Jun 01, 2005 at 08:03:44AM -0700 Cc: Subject: Re: [PATCH RFC] Add a macro for null mount options to sbin/mount* X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2005 15:06:52 -0000 On Wed, Jun 01, 2005 at 08:03:44AM -0700, David O'Brien wrote: > On Wed, Jun 01, 2005 at 04:10:56PM +0800, Xin LI wrote: > > Hi, -arch@, > > > > In our mount* utilities, the null mount option, which is usually be used > > as a terminator of an option vector, is defined with some hand-rolled > > terms, e.g.: {NULL}, {NULL, 0, 0, 0}, etc. > > > > I think it would be nice to have a new macro to deal with this, say, > > MOPT_NULL, which would be extended to {NULL, 0, 0, 0}, which can act as > > an explicit initialize. And in my opinion, something like: > > I think it is better to leave it alone. The "NULL" termination of a list > like this is a C idiom that should be clear to any C programmer. Hiding > the details in a macro (is MOPT_NULL an integer or a sentinel?) makes it > harder to see the idiom and know exactly what is going on and how this > list will be processed. on one side I have to agree here... however the alternative terms might cause problems with stricter compile flags (e.g. when some of the forms do not supply all fields), so perhaps a decent compromise could be to find a more explicative name such as MOPT_END or the like. cheers luigi > -- > -- David (obrien@FreeBSD.org) > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Wed Jun 1 15:11:55 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 857D016A41C for ; Wed, 1 Jun 2005 15:11:55 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E56B43D1D for ; Wed, 1 Jun 2005 15:11:52 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 17:11:50 +0200 Date: Wed, 1 Jun 2005 17:11:54 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: freebsd-arch@FreeBSD.org In-Reply-To: <20050601150344.GA39784@dragon.NUXI.org> Message-ID: <20050601170858.V51549@beagle.kn.op.dlr.de> References: <1117613456.771.16.camel@spirit> <20050601150344.GA39784@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 01 Jun 2005 15:11:50.0714 (UTC) FILETIME=[3CA331A0:01C566BC] Cc: delphij@delphij.net Subject: Re: [PATCH RFC] Add a macro for null mount options to sbin/mount* X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2005 15:11:55 -0000 On Wed, 1 Jun 2005, David O'Brien wrote: DO>On Wed, Jun 01, 2005 at 04:10:56PM +0800, Xin LI wrote: DO>> Hi, -arch@, DO>> DO>> In our mount* utilities, the null mount option, which is usually be used DO>> as a terminator of an option vector, is defined with some hand-rolled DO>> terms, e.g.: {NULL}, {NULL, 0, 0, 0}, etc. DO>> DO>> I think it would be nice to have a new macro to deal with this, say, DO>> MOPT_NULL, which would be extended to {NULL, 0, 0, 0}, which can act as DO>> an explicit initialize. And in my opinion, something like: DO> DO>I think it is better to leave it alone. The "NULL" termination of a list DO>like this is a C idiom that should be clear to any C programmer. Hiding DO>the details in a macro (is MOPT_NULL an integer or a sentinel?) makes it DO>harder to see the idiom and know exactly what is going on and how this DO>list will be processed. The problem is that with the right set of warning options gcc will warn if you write {NULL}, but there are more fields than just a pointer. If the structure definition is stable enough this is no problem - just go through all the programs and fix it once. If the definition is likely to change from time to time, a macro is better because it just does the right thing. harti From owner-freebsd-arch@FreeBSD.ORG Wed Jun 1 15:32:25 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCB5316A41C for ; Wed, 1 Jun 2005 15:32:25 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81ADE43D53 for ; Wed, 1 Jun 2005 15:32:23 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from mobile.pittgoth.com (ip68-105-180-6.dc.dc.cox.net [68.105.180.6]) (authenticated bits=0) by pittgoth.com (8.13.3/8.13.3) with ESMTP id j51FWC2L066388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Jun 2005 11:32:13 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Wed, 1 Jun 2005 11:31:26 -0400 From: Tom Rhodes To: Bruce Evans Message-ID: <20050601113126.2949ff1e@mobile.pittgoth.com> In-Reply-To: <20050601211628.V96009@delplex.bde.org> References: <1117613456.771.16.camel@spirit> <20050601211628.V96009@delplex.bde.org> X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: delphij@delphij.net, freebsd-arch@FreeBSD.org Subject: Re: [PATCH RFC] Add a macro for null mount options to sbin/mount* X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2005 15:32:26 -0000 On Wed, 1 Jun 2005 21:23:23 +1000 (EST) Bruce Evans wrote: > On Wed, 1 Jun 2005, Xin LI wrote: Here we go again! :P > > > In our mount* utilities, the null mount option, which is usually be used > > as a terminator of an option vector, is defined with some hand-rolled > > terms, e.g.: {NULL}, {NULL, 0, 0, 0}, etc. > > "{ NULL }" is the documented way. See getmntopts.3. That manual page has been unhooked since it's import IIRC. > > > I think it would be nice to have a new macro to deal with this, say, > > MOPT_NULL, which would be extended to {NULL, 0, 0, 0}, which can act as > > an explicit initialize. And in my opinion, something like: > > > > %%% > > opt = { > > MOPT_STD, > > MOPT_NULL > > }; > > %%% > > MOPT_NULL is a poor name. It is not a null option, but a terminator that > happens to have nulls in it. But MOPT_END is a better name, I like it. :) -- Tom Rhodes From owner-freebsd-arch@FreeBSD.ORG Wed Jun 1 16:55:10 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BAB416A41C for ; Wed, 1 Jun 2005 16:55:10 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 526BD43D49 for ; Wed, 1 Jun 2005 16:55:10 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id BCEFD46B3E for ; Wed, 1 Jun 2005 12:55:09 -0400 (EDT) Date: Wed, 1 Jun 2005 17:55:11 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Message-ID: <20050601174758.B689@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Status of various and sundry TrustedBSD/FreeBSD pieces (fwd) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2005 16:55:10 -0000 For those not actively following the TrustedBSD lists, here's some recent status information that might be of more general interest, especially with respect to changes in the pipeline for 6.0. Robert N M Watson ---------- Forwarded message ---------- Date: Tue, 31 May 2005 23:01:33 +0100 (BST) From: Robert Watson To: trustedbsd-discuss@TrustedBSD.org Subject: Status of various and sundry TrustedBSD/FreeBSD pieces Since I know many people following the TrustedBSD work aren't following the FreeBSD or TrustedBSD commit mailing lists, I thought I'd give a brief status update on various "works in progress": - At BSDCan and the associated FreeBSD Developer Summit, presentations were given on several TrustedBSD-related topics, including the Audit and OpenBSM implementations, the TrustedBSD MAC Framework, SEBSD policy module, and the experimental port to Darwin, as well as Christian Peron's work on an executable and kernel module checksumming policy module, mac_chkexec. - Christian Peron has integrated his mac_chkexec module and tools into the TrustedBSD MAC development branch on the FreeBSD perforce server, as well as some tweaks to the MAC Framework required to support proper checksumming of shared libraries as they are mapped (this change has been merged to FreeBSD 6.x and 5.x). - Changes to label and enforce protections for POSIX semaphores on FreeBSD were merged back to the FreeBSD 6.x tree from the TrustedBSD MAC development tree in early May, and will ship as part of FreeBSD 6.0 later this summer. - In April a number of enhancements were made to the set of socket-related acess control protections, such as protections for accept, poll, and others. These have been merged to the FreeBSD CVS tree for 6.0. - In April the addition of credential-related checks in the MAC Framework was merged to the FreeBSD CVS tree for 6.0. These allow MAC policies to control changes in UNIX credentials, and while not required for our labeled policies, are desirable for other hardening policies, such as the suidacl policy module from Samy Al Bahra. The credential changes were submitted by Samy. - In March, the System V IPC labeling and enforcement protections for the MAC Framework were merged to the FreeBSD CVS tree for 6.0. - An updated SEBSD ISO, based on an updated SELinux FLASK/TE drop from 20040819, as well as updated FreeBSD pieces, has been put together by Andrew Reisse and Scott Long. They're currently testing this release, and we hope to get an ISO on the web site in the near future. The ource for all of these changes is in the trustedbsd_sebsd branch currently. There are still a number of SEBSD-related changes that haven't been merged back to the base FreeBSD tree, such as relating to the labeling on cloned pseudo-devices; I met with Poul-Henning Kamp at the FreeBSD developer summit and he's cleared the way for these changes to be merged into FreeBSD CVS for 6.0. - Work to merge Audit/BSM to the base FreeBSD tree has now begun; the system call table format and structures were updated in the last couple of days to hold audit event mapping information, and we're currently polishing OpenBSM for a 1.0 release. The primary obstacles to progress here are finishing the cleanup, and waiting on Apple to relicense some of the kernel-related files under a BSD license (this is currently in the hands of Apple Legal, and should move shortly). Our hope is to ship Audit as an experimental feature in FreeBSD 6.0, and a production feature in FreeBSD 6.1. Many thanks to Wayne Salamon, Tom Rhodes, and others for their work on this. After meeting with Apple two weeks ago in Cupertino, it sounds like they're interested in picking up the OpenBSM bug fixes and enhancements to the user space BSM library, tools, documentation, etc, which would be another great outcome. So things are coming together nicely for the 6.0 release, although the deadlines for it are getting a bit tight! Robert N M Watson To Unsubscribe: send mail to majordomo@trustedbsd.org with "unsubscribe trustedbsd-discuss" in the body of the message From owner-freebsd-arch@FreeBSD.ORG Thu Jun 2 01:49:08 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A402716A41C for ; Thu, 2 Jun 2005 01:49:08 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EB2B43D1F for ; Thu, 2 Jun 2005 01:49:08 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j521mqkG018327; Thu, 2 Jun 2005 11:48:52 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j521mmMC028324; Thu, 2 Jun 2005 11:48:50 +1000 Date: Thu, 2 Jun 2005 11:48:49 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Xin LI In-Reply-To: <20050601134351.GA76097@frontfree.net> Message-ID: <20050602114323.R98072@delplex.bde.org> References: <1117613456.771.16.camel@spirit> <20050601211628.V96009@delplex.bde.org> <20050601134351.GA76097@frontfree.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: delphij@delphij.net, freebsd-arch@freebsd.org Subject: Re: [PATCH RFC] Add a macro for null mount options to sbin/mount* X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2005 01:49:08 -0000 On Wed, 1 Jun 2005, Xin LI wrote: > On Wed, Jun 01, 2005 at 09:23:23PM +1000, Bruce Evans wrote: >> >> MOPT_NULL is a poor name. It is not a null option, but a terminator that >> happens to have nulls in it. > > Agreed... Will the patch found in attachment look better? It also > updates the manpage. The name is OK now, but see other replies about the changes obfuscating the terminating condition. % Index: mount/mntopts.h % =================================================================== % RCS file: /home/ncvs/src/sbin/mount/mntopts.h,v % retrieving revision 1.25 % diff -u -r1.25 mntopts.h % --- mount/mntopts.h 1 Jun 2005 09:39:34 -0000 1.25 % +++ mount/mntopts.h 1 Jun 2005 13:35:57 -0000 % @@ -66,7 +66,7 @@ % #define MOPT_AUTO { "auto", 0, 0, 0 } % % /* A handy macro as terminator of MNT_ array */ The previous patch also has some style bugs. I noticed mainly the missing sentence (fragment) termination here. All other sentence (fragment)s in comments in this file except ones to the right of code are terminated normally. Bruce From owner-freebsd-arch@FreeBSD.ORG Thu Jun 2 02:06:22 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1466916A41C; Thu, 2 Jun 2005 02:06:22 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F7C643D4C; Thu, 2 Jun 2005 02:06:21 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j52268rI011333; Thu, 2 Jun 2005 12:06:08 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j52265MC003007; Thu, 2 Jun 2005 12:06:06 +1000 Date: Thu, 2 Jun 2005 12:06:07 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Harti Brandt In-Reply-To: <20050601170858.V51549@beagle.kn.op.dlr.de> Message-ID: <20050602114859.C98072@delplex.bde.org> References: <1117613456.771.16.camel@spirit> <20050601150344.GA39784@dragon.NUXI.org> <20050601170858.V51549@beagle.kn.op.dlr.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: delphij@delphij.net, freebsd-arch@freebsd.org Subject: Re: [PATCH RFC] Add a macro for null mount options to sbin/mount* X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2005 02:06:22 -0000 On Wed, 1 Jun 2005, Harti Brandt wrote: > On Wed, 1 Jun 2005, David O'Brien wrote: > > DO>On Wed, Jun 01, 2005 at 04:10:56PM +0800, Xin LI wrote: > DO>> Hi, -arch@, > DO>> > DO>> In our mount* utilities, the null mount option, which is usually be used > DO>> as a terminator of an option vector, is defined with some hand-rolled > DO>> terms, e.g.: {NULL}, {NULL, 0, 0, 0}, etc. > DO>> > DO>> I think it would be nice to have a new macro to deal with this, say, > DO>> MOPT_NULL, which would be extended to {NULL, 0, 0, 0}, which can act as > DO>> an explicit initialize. And in my opinion, something like: > DO> > DO>I think it is better to leave it alone. The "NULL" termination of a list > DO>like this is a C idiom that should be clear to any C programmer. Hiding > DO>the details in a macro (is MOPT_NULL an integer or a sentinel?) makes it > DO>harder to see the idiom and know exactly what is going on and how this > DO>list will be processed. I tend to agree. Here is the code that uses the terminator. From getmntopts.c: % /* Scan option table. */ % for (m = m0; m->m_option != NULL; ++m) { ^^^^^^^^^^^^^^^^^^^^ (1) % len = strlen(m->m_option); % if (strncasecmp(opt, m->m_option, len) == 0) % if ( m->m_option[len] == '\0' ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (2) % || m->m_option[len] == '=' ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (2) % ) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (2) % break; % } % % /* Save flag, or fail if option is not recognized. */ % if (m->m_option) { ^^^^^^^^^^^ (2) (1) Correct use of terminator. (2) Large logic and formatting style bugs were added in rev.1.2. (3) Obfuscated use of the terminator (no != NULL, unlike in the previous expression of the same condition). > The problem is that with the right set of warning options gcc will warn if > you write {NULL}, but there are more fields than just a pointer. If the > structure definition is stable enough this is no problem - just go through > all the programs and fix it once. If the definition is likely to change > from time to time, a macro is better because it just does the right thing. It would be a compiler bug to complain about missing initializaters for trailing fields -- consider explicitly initalizing all the data in "struct foo { char *p; int n[1024 * 1024]; }". Here the field holding the NULL is the only one that is used. The definition of the terminator would only need to change if this field is moved. Bruce From owner-freebsd-arch@FreeBSD.ORG Thu Jun 2 07:24:54 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C673816A41C; Thu, 2 Jun 2005 07:24:54 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from fafoe.narf.at (chello213047085026.6.14.vie.surfer.at [213.47.85.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 437A143D5E; Thu, 2 Jun 2005 07:24:54 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from wombat.fafoe.narf.at (wombat.fafoe.narf.at [192.168.1.42]) by fafoe.narf.at (Postfix) with ESMTP id 6A9453FA7; Thu, 2 Jun 2005 09:24:42 +0200 (CEST) Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id 0ABB814A; Thu, 2 Jun 2005 09:24:28 +0200 (CEST) Date: Thu, 2 Jun 2005 09:24:28 +0200 From: Stefan Farfeleder To: Bruce Evans Message-ID: <20050602072423.GK95633@wombat.fafoe.narf.at> References: <1117613456.771.16.camel@spirit> <20050601150344.GA39784@dragon.NUXI.org> <20050601170858.V51549@beagle.kn.op.dlr.de> <20050602114859.C98072@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050602114859.C98072@delplex.bde.org> User-Agent: Mutt/1.5.9i Cc: delphij@delphij.net, Harti Brandt , freebsd-arch@freebsd.org Subject: Re: [PATCH RFC] Add a macro for null mount options to sbin/mount* X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2005 07:24:54 -0000 On Thu, Jun 02, 2005 at 12:06:07PM +1000, Bruce Evans wrote: > It would be a compiler bug to complain about missing initializaters for > trailing fields -- consider explicitly initalizing all the data in > "struct foo { char *p; int n[1024 * 1024]; }". Here the field holding > the NULL is the only one that is used. The definition of the terminator > would only need to change if this field is moved. Seconded, however GCC does exactly that with -W (now -Wextra) which we happen to use when ${WARNS} >= 3. Stefan From owner-freebsd-arch@FreeBSD.ORG Thu Jun 2 19:20:29 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FECA16A41C; Thu, 2 Jun 2005 19:20:29 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CBDA43D1F; Thu, 2 Jun 2005 19:20:23 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (ume@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j52JK9fH054904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jun 2005 04:20:09 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Fri, 03 Jun 2005 04:20:06 +0900 Message-ID: From: Hajimu UMEMOTO To: freebsd-arch@freebsd.org, standards@freebsd.org, current@freebsd.org In-Reply-To: References: <20050531.075329.118637972.imp@bsdimp.com> <20050531.084832.20036038.imp@bsdimp.com> <86fyw32yqm.fsf@xps.des.no> <86k6lfbafu.fsf@xps.des.no> User-Agent: xcite1.38> Wanderlust/2.15.1 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.4) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.4-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-2.0b5 (cheer.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Fri, 03 Jun 2005 04:20:10 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on cheer.mahoroba.org Cc: nectar@freebsd.org, des@des.no Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2005 19:20:29 -0000 Hi, >>> On Wed, 01 Jun 2005 21:44:03 +0900 >>> Hajimu UMEMOTO said: ume> I've attached the patch to correct 1st argument of getnetbyaddr(3) in ume> this mail. It is subset of my previous patch. Since it breaks ABI ume> compatibility of getnetbyaddr(3), I think it is better to correct ume> n_net member of struct netent, too. Since there is objection, the ume> patch leaves struct addrinfo as is. So, it doesn't need to bump any ume> shlib major. Is it okay? Ultimately, I wish to correct struct addrinfo, too. Since correcting getnetbyaddr(3) breaks ABI compatibility after all, it seems storange to me to leave struct addrinfo alone as is. It is better to take this occasion to correct struct addrinfo as well. This breakage is only on 64 bit arch. The influence will grow as 64 bit arch spreads. So, I believe it should be done as soon as possible. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Thu Jun 2 19:59:11 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F05516A41C; Thu, 2 Jun 2005 19:59:11 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 062A443D4C; Thu, 2 Jun 2005 19:59:10 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.4/8.13.4/NETPLEX) with ESMTP id j52Jx7kM019809; Thu, 2 Jun 2005 15:59:07 -0400 (EDT) Date: Thu, 2 Jun 2005 15:59:07 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Hajimu UMEMOTO In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: nectar@freebsd.org, des@des.no, standards@freebsd.org, current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2005 19:59:11 -0000 On Fri, 3 Jun 2005, Hajimu UMEMOTO wrote: > Hi, > > >>> On Wed, 01 Jun 2005 21:44:03 +0900 > >>> Hajimu UMEMOTO said: > > ume> I've attached the patch to correct 1st argument of getnetbyaddr(3) in > ume> this mail. It is subset of my previous patch. Since it breaks ABI > ume> compatibility of getnetbyaddr(3), I think it is better to correct > ume> n_net member of struct netent, too. Since there is objection, the > ume> patch leaves struct addrinfo as is. So, it doesn't need to bump any > ume> shlib major. Is it okay? > > Ultimately, I wish to correct struct addrinfo, too. Since correcting > getnetbyaddr(3) breaks ABI compatibility after all, it seems storange > to me to leave struct addrinfo alone as is. It is better to take this > occasion to correct struct addrinfo as well. > This breakage is only on 64 bit arch. The influence will grow as 64 > bit arch spreads. So, I believe it should be done as soon as > possible. Just leave it alone for now. When symbol versioning comes, you should be able to remove the padding without bumping library versions and producing imcompatibilities. -- DE From owner-freebsd-arch@FreeBSD.ORG Thu Jun 2 20:26:33 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D10F216A41C; Thu, 2 Jun 2005 20:26:33 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25BF543D58; Thu, 2 Jun 2005 20:26:32 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (ume@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j52KQLat086993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jun 2005 05:26:21 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Fri, 03 Jun 2005 05:26:18 +0900 Message-ID: From: Hajimu UMEMOTO To: Daniel Eischen In-Reply-To: References: User-Agent: xcite1.38> Wanderlust/2.15.1 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.4) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.4-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-2.0b5 (cheer.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Fri, 03 Jun 2005 05:26:22 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on cheer.mahoroba.org Cc: nectar@freebsd.org, des@des.no, standards@freebsd.org, current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2005 20:26:34 -0000 Hi, >>>>> On Thu, 2 Jun 2005 15:59:07 -0400 (EDT) >>>>> Daniel Eischen said: > Ultimately, I wish to correct struct addrinfo, too. Since correcting > getnetbyaddr(3) breaks ABI compatibility after all, it seems storange > to me to leave struct addrinfo alone as is. It is better to take this > occasion to correct struct addrinfo as well. > This breakage is only on 64 bit arch. The influence will grow as 64 > bit arch spreads. So, I believe it should be done as soon as > possible. deischen> Just leave it alone for now. Please clarify what you mean for `it'. Which are you mean only struct addrinfo issue or both? deischen> When symbol versioning comes, you should be able to remove deischen> the padding without bumping library versions and producing deischen> imcompatibilities. It's curious. Is there any plan to provide symbol versioning? Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Thu Jun 2 20:38:13 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5495116A41C; Thu, 2 Jun 2005 20:38:13 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 052CA43D1F; Thu, 2 Jun 2005 20:38:12 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.4/8.13.4/NETPLEX) with ESMTP id j52KcBh9027619; Thu, 2 Jun 2005 16:38:11 -0400 (EDT) Date: Thu, 2 Jun 2005 16:38:11 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Hajimu UMEMOTO In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: nectar@freebsd.org, des@des.no, standards@freebsd.org, current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2005 20:38:13 -0000 On Fri, 3 Jun 2005, Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Thu, 2 Jun 2005 15:59:07 -0400 (EDT) > >>>>> Daniel Eischen said: > > > Ultimately, I wish to correct struct addrinfo, too. Since correcting > > getnetbyaddr(3) breaks ABI compatibility after all, it seems storange > > to me to leave struct addrinfo alone as is. It is better to take this > > occasion to correct struct addrinfo as well. > > This breakage is only on 64 bit arch. The influence will grow as 64 > > bit arch spreads. So, I believe it should be done as soon as > > possible. > > deischen> Just leave it alone for now. > > Please clarify what you mean for `it'. Which are you mean only struct > addrinfo issue or both? struct addrinfo. I am under the assumption that getnetbyaddr() only breaks libc compat which has already been bumped. Changing that has no effect on other libraries, right? > > deischen> When symbol versioning comes, you should be able to remove > deischen> the padding without bumping library versions and producing > deischen> imcompatibilities. > > It's curious. Is there any plan to provide symbol versioning? I recall seeing some mention of it (by kan@ ?) on some site or posting talking about the recent BSDCan. -- DE From owner-freebsd-arch@FreeBSD.ORG Thu Jun 2 20:50:26 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1326016A41C; Thu, 2 Jun 2005 20:50:26 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C3F343D1F; Thu, 2 Jun 2005 20:50:25 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (ume@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j52KoEfn009011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jun 2005 05:50:14 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Fri, 03 Jun 2005 05:50:11 +0900 Message-ID: From: Hajimu UMEMOTO To: Daniel Eischen In-Reply-To: References: User-Agent: xcite1.38> Wanderlust/2.15.1 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.4) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.4-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-2.0b5 (cheer.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Fri, 03 Jun 2005 05:50:15 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on cheer.mahoroba.org Cc: nectar@freebsd.org, des@des.no, standards@freebsd.org, current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2005 20:50:26 -0000 Hi, >>>>> On Thu, 2 Jun 2005 16:38:11 -0400 (EDT) >>>>> Daniel Eischen said: deischen> struct addrinfo. I am under the assumption that getnetbyaddr() only deischen> breaks libc compat which has already been bumped. Changing that deischen> has no effect on other libraries, right? Okay, thanks. Yes, getnetbyaddr(3) issue breaks only libc, and other libs doesn't refer getnet*(3). > > deischen> When symbol versioning comes, you should be able to remove > deischen> the padding without bumping library versions and producing > deischen> imcompatibilities. > > It's curious. Is there any plan to provide symbol versioning? deischen> I recall seeing some mention of it (by kan@ ?) on some site or deischen> posting talking about the recent BSDCan. Oh, it's great! Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Fri Jun 3 02:24:28 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A17AF16A41C; Fri, 3 Jun 2005 02:24:28 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F8E943D49; Fri, 3 Jun 2005 02:24:27 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from dibbler.crodrigues.org (c-66-30-114-143.hsd1.ma.comcast.net[66.30.114.143]) by comcast.net (rwcrmhc11) with ESMTP id <20050603022427013004mrpue>; Fri, 3 Jun 2005 02:24:27 +0000 Received: from c-66-30-114-143.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by dibbler.crodrigues.org (8.13.3/8.13.1) with ESMTP id j532OiCv034112; Thu, 2 Jun 2005 22:24:44 -0400 (EDT) (envelope-from rodrigc@c-66-30-114-143.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-114-143.hsd1.ma.comcast.net (8.13.3/8.13.1/Submit) id j532Oi3Z034111; Thu, 2 Jun 2005 22:24:44 -0400 (EDT) (envelope-from rodrigc) Date: Thu, 2 Jun 2005 22:24:44 -0400 From: Craig Rodrigues To: freebsd-fs@freebsd.org Message-ID: <20050603022444.GA34086@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Cc: dumbbell@freebsd.org, freebsd-arch@freebsd.org Subject: [RFC] Move reiserfs code to src/sys/gnu/fs? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2005 02:24:28 -0000 Hi, Due to the increasing number of filesystems with GNU licenses being imported into the tree (Reiserfs was just imported, and sometime in the future, XFS may be imported), I suggest that a new directory be created: src/sys/gnu/fs I also suggest that the recent Reiserfs code which was imported into the tree be moved from src/sys/gnu/reiserfs to src/sys/gnu/fs/reiserfs Since the code was just imported, this operation should be a simple case of cvs rm'ing the files that exist, and cvs add'ing them to the new directory. At some point, it would be nice to move ext2fs to src/sys/gnu/fs, but that would involve more work (a repo copy). What do people think? Thanks. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-arch@FreeBSD.ORG Fri Jun 3 02:31:12 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE66716A427; Fri, 3 Jun 2005 02:31:12 +0000 (GMT) (envelope-from owner-freebsd-fs@freebsd.org) Received: from heisenberg.zen.co.uk (heisenberg.zen.co.uk [212.23.3.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7A3243D48; Fri, 3 Jun 2005 02:31:11 +0000 (GMT) (envelope-from owner-freebsd-fs@freebsd.org) Received: from [82.69.255.50] (helo=rtxnetworks.co.uk) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1De1xm-0006Kl-Mu; Fri, 03 Jun 2005 02:31:10 +0000 Received: from mail pickup service by rtxnetworks.co.uk with Microsoft SMTPSVC; Fri, 3 Jun 2005 03:30:50 +0100 thread-index: AcVn5EHdqCH+68YnSDawxHHI9UqYGA== X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Date: Fri, 3 Jun 2005 03:30:50 +0100 From: "Craig Rodrigues" To: MIME-Version: 1.0 Message-ID: <000001c567e4$41dd3e30$144da8c0@rtxnetworks.local> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline User-Agent: Mutt/1.5.9i X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 X-Mailer: Microsoft CDO for Exchange 2000 Precedence: list Sender: Errors-To: owner-freebsd-fs@freebsd.org X-Zen-Test-Spam-Score: 1 X-Zen-Test-Spam-Bar: (/) X-Originating-Feynman-IP: [216.136.204.119] X-Envelope-From: owner-freebsd-fs@freebsd.org X-Envelope-To: james@rtxnetworks.co.uk X-Apparently-To: james@rtxnetworks.co.uk Content-Class: urn:content-classes:message X-Zen-Loop: 5141780d76c9dff8cdd2df89c3607fd0 Importance: normal X-Zen-Stored: julia.zen.co.uk/1De1rp-0008Vl-Qv/2005-06-03 02:25:01 Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-OriginalArrivalTime: 03 Jun 2005 02:30:50.0718 (UTC) FILETIME=[41FC37E0:01C567E4] X-Originating-Heisenberg-IP: [82.69.255.50] Cc: dumbbell@freebsd.org, freebsd-arch@freebsd.org Subject: [RFC] Move reiserfs code to src/sys/gnu/fs? X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2005 02:31:13 -0000 Hi, Due to the increasing number of filesystems with GNU licenses being imported into the tree (Reiserfs was just imported, and sometime in the future, XFS may be imported), I suggest that a new directory be created: src/sys/gnu/fs I also suggest that the recent Reiserfs code which was imported into the tree be moved from src/sys/gnu/reiserfs to src/sys/gnu/fs/reiserfs Since the code was just imported, this operation should be a simple case of cvs rm'ing the files that exist, and cvs add'ing them to the new directory. At some point, it would be nice to move ext2fs to src/sys/gnu/fs, but that would involve more work (a repo copy). What do people think? Thanks. -- Craig Rodrigues rodrigc@crodrigues.org _______________________________________________ freebsd-fs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Fri Jun 3 02:33:04 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07FC116A41C; Fri, 3 Jun 2005 02:33:04 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from sp.dominia.org (efnet-math.org [69.60.109.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 485CD43D4C; Fri, 3 Jun 2005 02:33:03 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.1.12] (63-170-138-118.cst-sg.blacksburg.ntc-com.net [63.170.138.118]) (authenticated bits=0) by sp.dominia.org (8.13.1/8.13.1) with ESMTP id j532WxLR015274 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 2 Jun 2005 22:33:00 -0400 In-Reply-To: <000001c567e4$41dd3e30$144da8c0@rtxnetworks.local> References: <000001c567e4$41dd3e30$144da8c0@rtxnetworks.local> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <92A59476-8E09-4B81-BC0C-F19614343F04@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Suleiman Souhlal Date: Thu, 2 Jun 2005 22:32:53 -0400 To: "Craig Rodrigues" X-Mailer: Apple Mail (2.730) Cc: james@FreeBSD.org, dumbbell@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [RFC] Move reiserfs code to src/sys/gnu/fs? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2005 02:33:04 -0000 Hi, On Jun 2, 2005, at 10:30 PM, Craig Rodrigues wrote: > Hi, > > Due to the increasing number of filesystems with GNU licenses > being imported into the tree (Reiserfs was just imported, and > sometime in the future, XFS may be imported), I suggest > that a new directory be created: > > src/sys/gnu/fs > > I also suggest that the recent Reiserfs code which was imported > into the tree be moved from > src/sys/gnu/reiserfs to src/sys/gnu/fs/reiserfs > > Since the code was just imported, this operation should be > a simple case of cvs rm'ing the files that exist, and cvs add'ing > them to the new directory. > > At some point, it would be nice to move ext2fs to > src/sys/gnu/fs, but that would involve more work (a repo copy). > > What do people think? I think it's a good idea. -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Fri Jun 3 02:34:51 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90D1616A41C; Fri, 3 Jun 2005 02:34:51 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3021843D1F; Fri, 3 Jun 2005 02:34:51 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j532fORQ030787; Thu, 2 Jun 2005 20:41:24 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <429FC188.8080805@samsco.org> Date: Thu, 02 Jun 2005 20:33:44 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Craig Rodrigues References: <20050603022444.GA34086@crodrigues.org> In-Reply-To: <20050603022444.GA34086@crodrigues.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-fs@freebsd.org, dumbbell@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Move reiserfs code to src/sys/gnu/fs? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2005 02:34:51 -0000 Craig Rodrigues wrote: > Hi, > > Due to the increasing number of filesystems with GNU licenses > being imported into the tree (Reiserfs was just imported, and > sometime in the future, XFS may be imported), I suggest > that a new directory be created: > > src/sys/gnu/fs > > I also suggest that the recent Reiserfs code which was imported > into the tree be moved from > src/sys/gnu/reiserfs to src/sys/gnu/fs/reiserfs > > Since the code was just imported, this operation should be > a simple case of cvs rm'ing the files that exist, and cvs add'ing > them to the new directory. > > At some point, it would be nice to move ext2fs to > src/sys/gnu/fs, but that would involve more work (a repo copy). > > What do people think? > > Thanks. > I agree! Scott From owner-freebsd-arch@FreeBSD.ORG Fri Jun 3 02:46:22 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 587A016A41C; Fri, 3 Jun 2005 02:46:22 +0000 (GMT) (envelope-from owner-freebsd-fs@freebsd.org) Received: from heisenberg.zen.co.uk (heisenberg.zen.co.uk [212.23.3.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id A712E43D53; Fri, 3 Jun 2005 02:46:21 +0000 (GMT) (envelope-from owner-freebsd-fs@freebsd.org) Received: from [82.69.255.50] (helo=rtxnetworks.co.uk) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1De2CS-0002jI-UG; Fri, 03 Jun 2005 02:46:21 +0000 Received: from mail pickup service by rtxnetworks.co.uk with Microsoft SMTPSVC; Fri, 3 Jun 2005 03:46:01 +0100 thread-index: AcVn5mCVLHUTvv89TsiLuQtdjiKfEA== X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Date: Fri, 3 Jun 2005 03:46:01 +0100 From: "Scott Long" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Message-ID: <000001c567e6$6097b060$144da8c0@rtxnetworks.local> References: <20050603022444.GA34086@crodrigues.org> In-Reply-To: <20050603022444.GA34086@crodrigues.org> Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org X-Mailer: Microsoft CDO for Exchange 2000 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: Errors-To: owner-freebsd-fs@freebsd.org X-Zen-Test-Spam-Score: 0 X-Zen-Test-Spam-Bar: (/) X-Originating-Feynman-IP: [216.136.204.119] X-Envelope-From: owner-freebsd-fs@freebsd.org X-Envelope-To: james@rtxnetworks.co.uk X-Apparently-To: james@rtxnetworks.co.uk X-Zen-Loop: 5141780d76c9dff8cdd2df89c3607fd0 Content-Class: urn:content-classes:message Importance: normal X-Zen-Stored: julia.zen.co.uk/1De21h-0007o5-Dt/2005-06-03 02:35:13 Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-OriginalArrivalTime: 03 Jun 2005 02:46:01.0265 (UTC) FILETIME=[60B6AA10:01C567E6] X-Originating-Heisenberg-IP: [82.69.255.50] Cc: freebsd-fs@freebsd.org, dumbbell@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Move reiserfs code to src/sys/gnu/fs? X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2005 02:46:22 -0000 Craig Rodrigues wrote: > Hi, > > Due to the increasing number of filesystems with GNU licenses > being imported into the tree (Reiserfs was just imported, and > sometime in the future, XFS may be imported), I suggest > that a new directory be created: > > src/sys/gnu/fs > > I also suggest that the recent Reiserfs code which was imported > into the tree be moved from > src/sys/gnu/reiserfs to src/sys/gnu/fs/reiserfs > > Since the code was just imported, this operation should be > a simple case of cvs rm'ing the files that exist, and cvs add'ing > them to the new directory. > > At some point, it would be nice to move ext2fs to > src/sys/gnu/fs, but that would involve more work (a repo copy). > > What do people think? > > Thanks. > I agree! Scott _______________________________________________ freebsd-fs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Fri Jun 3 06:37:52 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BBEF16A41C; Fri, 3 Jun 2005 06:37:52 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB88543D53; Fri, 3 Jun 2005 06:37:51 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j536bkhj070086; Fri, 3 Jun 2005 09:37:46 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 52866-01; Fri, 3 Jun 2005 09:37:45 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j536bj5o070083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jun 2005 09:37:45 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j536Dwqq050792; Fri, 3 Jun 2005 09:13:58 +0300 (EEST) (envelope-from ru) Date: Fri, 3 Jun 2005 09:13:58 +0300 From: Ruslan Ermilov To: Craig Rodrigues Message-ID: <20050603061357.GB50672@ip.net.ua> References: <20050603022444.GA34086@crodrigues.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JP+T4n/bALQSJXh8" Content-Disposition: inline In-Reply-To: <20050603022444.GA34086@crodrigues.org> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: freebsd-fs@freebsd.org, dumbbell@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Move reiserfs code to src/sys/gnu/fs? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2005 06:37:52 -0000 --JP+T4n/bALQSJXh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 02, 2005 at 10:24:44PM -0400, Craig Rodrigues wrote: > Hi, >=20 > Due to the increasing number of filesystems with GNU licenses > being imported into the tree (Reiserfs was just imported, and > sometime in the future, XFS may be imported), I suggest > that a new directory be created: >=20 > src/sys/gnu/fs >=20 > I also suggest that the recent Reiserfs code which was imported > into the tree be moved from > src/sys/gnu/reiserfs to src/sys/gnu/fs/reiserfs >=20 > Since the code was just imported, this operation should be > a simple case of cvs rm'ing the files that exist, and cvs add'ing > them to the new directory. >=20 > At some point, it would be nice to move ext2fs to > src/sys/gnu/fs, but that would involve more work (a repo copy). >=20 > What do people think? >=20 This would be in line with what I did with sys/fs/ at the time. Good idea. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --JP+T4n/bALQSJXh8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCn/UlqRfpzJluFF4RAiRbAKCdFlmkO8Tk66kTX1yqp7ayIahrnQCcDuZY bsQJU8QzyHjcWOjuuDvv2JA= =B95a -----END PGP SIGNATURE----- --JP+T4n/bALQSJXh8-- From owner-freebsd-arch@FreeBSD.ORG Fri Jun 3 06:46:09 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0916F16A41C; Fri, 3 Jun 2005 06:46:09 +0000 (GMT) (envelope-from owner-freebsd-fs@freebsd.org) Received: from rutherford.zen.co.uk (rutherford.zen.co.uk [212.23.3.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48DC143D1D; Fri, 3 Jun 2005 06:46:08 +0000 (GMT) (envelope-from owner-freebsd-fs@freebsd.org) Received: from [82.69.255.54] (helo=rtxnetworks.co.uk) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1De5wV-0002k8-A8; Fri, 03 Jun 2005 06:46:07 +0000 Received: from mail pickup service by rtxnetworks.co.uk with Microsoft SMTPSVC; Fri, 3 Jun 2005 07:45:47 +0100 thread-index: AcVoB98+DQjfRSW8Tg2SElbP0QnHyw== X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Date: Fri, 3 Jun 2005 07:45:46 +0100 From: "Ruslan Ermilov" To: Message-ID: <000001c56807$df3e0290$144da8c0@rtxnetworks.local> References: <20050603022444.GA34086@crodrigues.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JP+T4n/bALQSJXh8" Content-Disposition: inline In-Reply-To: <20050603022444.GA34086@crodrigues.org> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua X-Mailer: Microsoft CDO for Exchange 2000 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: Errors-To: owner-freebsd-fs@freebsd.org X-Zen-Test-Spam-Score: 0 X-Zen-Test-Spam-Bar: (/) X-Originating-Feynman-IP: [216.136.204.119] X-Envelope-From: owner-freebsd-fs@freebsd.org X-Envelope-To: james@rtxnetworks.co.uk X-Apparently-To: james@rtxnetworks.co.uk X-Zen-Loop: 5141780d76c9dff8cdd2df89c3607fd0 Content-Class: urn:content-classes:message Importance: normal X-Zen-Stored: julia.zen.co.uk/1De5p9-0008PS-Lc/2005-06-03 06:38:31 Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-OriginalArrivalTime: 03 Jun 2005 06:45:47.0140 (UTC) FILETIME=[DF5CFC40:01C56807] X-Originating-Rutherford-IP: [82.69.255.54] Cc: freebsd-fs@freebsd.org, dumbbell@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Move reiserfs code to src/sys/gnu/fs? X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2005 06:46:09 -0000 This is a multi-part message in MIME format. --JP+T4n/bALQSJXh8 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 02, 2005 at 10:24:44PM -0400, Craig Rodrigues wrote: > Hi, >=20 > Due to the increasing number of filesystems with GNU licenses > being imported into the tree (Reiserfs was just imported, and > sometime in the future, XFS may be imported), I suggest > that a new directory be created: >=20 > src/sys/gnu/fs >=20 > I also suggest that the recent Reiserfs code which was imported > into the tree be moved from > src/sys/gnu/reiserfs to src/sys/gnu/fs/reiserfs >=20 > Since the code was just imported, this operation should be > a simple case of cvs rm'ing the files that exist, and cvs add'ing > them to the new directory. >=20 > At some point, it would be nice to move ext2fs to > src/sys/gnu/fs, but that would involve more work (a repo copy). >=20 > What do people think? >=20 This would be in line with what I did with sys/fs/ at the time. Good idea. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --JP+T4n/bALQSJXh8 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCn/UlqRfpzJluFF4RAiRbAKCdFlmkO8Tk66kTX1yqp7ayIahrnQCcDuZY bsQJU8QzyHjcWOjuuDvv2JA= =B95a -----END PGP SIGNATURE----- --JP+T4n/bALQSJXh8-- From owner-freebsd-arch@FreeBSD.ORG Fri Jun 3 07:45:56 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AE2516A41C; Fri, 3 Jun 2005 07:45:56 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C93F43D1F; Fri, 3 Jun 2005 07:45:56 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j537jnjt066762; Fri, 3 Jun 2005 00:45:49 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j537jnrs066761; Fri, 3 Jun 2005 00:45:49 -0700 (PDT) (envelope-from obrien) Date: Fri, 3 Jun 2005 00:45:49 -0700 From: "David O'Brien" To: Craig Rodrigues Message-ID: <20050603074549.GA66709@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Craig Rodrigues , james@FreeBSD.ORG, dumbbell@freebsd.org, freebsd-arch@freebsd.org References: <000001c567e4$41dd3e30$144da8c0@rtxnetworks.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c567e4$41dd3e30$144da8c0@rtxnetworks.local> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: james@FreeBSD.ORG, dumbbell@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] Move reiserfs code to src/sys/gnu/fs? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@FreeBSD.ORG List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2005 07:45:56 -0000 On Fri, Jun 03, 2005 at 03:30:50AM +0100, Craig Rodrigues wrote: > Due to the increasing number of filesystems with GNU licenses > being imported into the tree (Reiserfs was just imported, and > sometime in the future, XFS may be imported), I suggest > that a new directory be created: > > src/sys/gnu/fs .. > At some point, it would be nice to move ext2fs to > src/sys/gnu/fs, but that would involve more work (a repo copy). > > What do people think? Keep ext2fs and reiserfs at the same place. I don't see what's wrong with src/sys/gnu as that directory now contains only 3 subdirs, so its not like its over flowing. But end the end I don't really care as long as both these file systems live in the same place (and not take months to make it so). -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Fri Jun 3 10:35:50 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A1D616A41C; Fri, 3 Jun 2005 10:35:50 +0000 (GMT) (envelope-from jspedron@club-internet.fr) Received: from smtp.cegetel.net (mf01.sitadelle.com [212.94.174.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id E65E143D49; Fri, 3 Jun 2005 10:35:49 +0000 (GMT) (envelope-from jspedron@club-internet.fr) Received: from [172.16.142.1] (213-223-184-193.dti.cegetel.net [213.223.184.193]) by smtp.cegetel.net (Postfix) with ESMTP id 8DA2D31837B; Fri, 3 Jun 2005 12:35:48 +0200 (CEST) Message-ID: <42A03288.8080608@club-internet.fr> Date: Fri, 03 Jun 2005 12:35:52 +0200 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20050208 X-Accept-Language: fr-fr, fr, en-us, en, ja MIME-Version: 1.0 To: Craig Rodrigues References: <20050603022444.GA34086@crodrigues.org> In-Reply-To: <20050603022444.GA34086@crodrigues.org> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig432660CADC0F7FCCDF1D3736" Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Move reiserfs code to src/sys/gnu/fs? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2005 10:35:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig432660CADC0F7FCCDF1D3736 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Craig Rodrigues wrote: > Hi, > > Due to the increasing number of filesystems with GNU licenses > being imported into the tree (Reiserfs was just imported, and > sometime in the future, XFS may be imported), I suggest > that a new directory be created: > > src/sys/gnu/fs > > I also suggest that the recent Reiserfs code which was imported > into the tree be moved from > src/sys/gnu/reiserfs to src/sys/gnu/fs/reiserfs > > Since the code was just imported, this operation should be > a simple case of cvs rm'ing the files that exist, and cvs add'ing > them to the new directory. > > At some point, it would be nice to move ext2fs to > src/sys/gnu/fs, but that would involve more work (a repo copy). > > What do people think? I'm ok with this change too. -- Jean-Sébastien Pédron http://www.dumbbell.fr/ PGP Key: http://www.dumbbell.fr/pgp/pubkey.asc --------------enig432660CADC0F7FCCDF1D3736 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCoDKLa+xGJsFYOlMRAnnxAKCkONEnCQSbFisz46/tPk9z2PNWoQCfY/as tGCB/zb3/hgy6XV/qyJho6Y= =ac38 -----END PGP SIGNATURE----- --------------enig432660CADC0F7FCCDF1D3736-- From owner-freebsd-arch@FreeBSD.ORG Fri Jun 3 10:46:02 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FD7816A41C; Fri, 3 Jun 2005 10:46:02 +0000 (GMT) (envelope-from owner-freebsd-fs@freebsd.org) Received: from rutherford.zen.co.uk (rutherford.zen.co.uk [212.23.3.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7AD443D49; Fri, 3 Jun 2005 10:46:01 +0000 (GMT) (envelope-from owner-freebsd-fs@freebsd.org) Received: from [82.69.255.54] (helo=rtxnetworks.co.uk) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1De9gf-0002S4-4V; Fri, 03 Jun 2005 10:46:01 +0000 Received: from mail pickup service by rtxnetworks.co.uk with Microsoft SMTPSVC; Fri, 3 Jun 2005 11:45:40 +0100 thread-index: AcVoKWJTTRkfCedbSPO+iBFHEZxpag== X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Date: Fri, 3 Jun 2005 11:45:40 +0100 From: =?iso-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20050208 X-Accept-Language: fr-fr, fr, en-us, en, ja MIME-Version: 1.0 To: Message-ID: <000001c56829$625347a0$144da8c0@rtxnetworks.local> References: <20050603022444.GA34086@crodrigues.org> In-Reply-To: <20050603022444.GA34086@crodrigues.org> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig432660CADC0F7FCCDF1D3736" X-Mailer: Microsoft CDO for Exchange 2000 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: Errors-To: owner-freebsd-fs@freebsd.org Content-Transfer-Encoding: 7bit X-Zen-Test-Spam-Score: 1 X-Zen-Test-Spam-Bar: (/) X-Originating-Oppenheimer-IP: [216.136.204.119] X-Envelope-From: owner-freebsd-fs@freebsd.org X-Envelope-To: james@rtxnetworks.co.uk X-Apparently-To: james@rtxnetworks.co.uk X-Zen-Loop: 5141780d76c9dff8cdd2df89c3607fd0 X-Zen-Stored: julia.zen.co.uk/1De9XS-00041U-Pg/2005-06-03 10:36:31 Content-Class: urn:content-classes:message Importance: normal X-Antivirus: AVG for E-mail 7.0.323 [267.4.1] Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-OriginalArrivalTime: 03 Jun 2005 10:45:40.0453 (UTC) FILETIME=[62724150:01C56829] X-Originating-Rutherford-IP: [82.69.255.54] Cc: freebsd-fs@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Move reiserfs code to src/sys/gnu/fs? X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2005 10:46:02 -0000 This is a multi-part message in MIME format. --------------enig432660CADC0F7FCCDF1D3736 Content-Type: text/plain; format=flowed; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Craig Rodrigues wrote: > Hi, > > Due to the increasing number of filesystems with GNU licenses > being imported into the tree (Reiserfs was just imported, and > sometime in the future, XFS may be imported), I suggest > that a new directory be created: > > src/sys/gnu/fs > > I also suggest that the recent Reiserfs code which was imported > into the tree be moved from > src/sys/gnu/reiserfs to src/sys/gnu/fs/reiserfs > > Since the code was just imported, this operation should be > a simple case of cvs rm'ing the files that exist, and cvs add'ing > them to the new directory. > > At some point, it would be nice to move ext2fs to > src/sys/gnu/fs, but that would involve more work (a repo copy). > > What do people think? I'm ok with this change too. -- Jean-S=E9bastien P=E9dron http://www.dumbbell.fr/ PGP Key: http://www.dumbbell.fr/pgp/pubkey.asc --------------enig432660CADC0F7FCCDF1D3736 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCoDKLa+xGJsFYOlMRAnnxAKCkONEnCQSbFisz46/tPk9z2PNWoQCfY/as tGCB/zb3/hgy6XV/qyJho6Y= =ac38 -----END PGP SIGNATURE----- --------------enig432660CADC0F7FCCDF1D3736--