From owner-freebsd-arch Sun Jan 21 11:28:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 15FEF37B698 for ; Sun, 21 Jan 2001 11:28:01 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0LJRU901079; Sun, 21 Jan 2001 12:27:31 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101211927.f0LJRU901079@harmony.village.org> To: Daniel Eischen Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r Cc: "Jacques A. Vidrine" , arch@FreeBSD.ORG In-reply-to: Your message of "Sat, 20 Jan 2001 17:26:26 EST." References: Date: Sun, 21 Jan 2001 12:27:30 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Daniel Eischen writes: : > By the way, should it be __thread_sys_foo and __foo? Two underscores? : > ISTR some rule about using a single leading underscore for file scope : > (e.g. macros) and two for global scope. : : I don't recall that, but anything for file scope that isn't a macro : can be static and not use the underscores. Macros are usually upper : case anyways. ANSI C reserves _[A-Z]* and __[a-zA-Z] to the implementation space. That leaves _[a-z] to the user name space, so Jacques is right about that. I can quote chapter and verse if you really want me to. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 11:29:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 3118A37B400; Sun, 21 Jan 2001 11:29:12 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0LJT8901098; Sun, 21 Jan 2001 12:29:09 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101211929.f0LJT8901098@harmony.village.org> To: "Cameron Grant" Subject: Re: newpcm/kobj MFC Cc: arch@FreeBSD.ORG, stable@FreeBSD.ORG In-reply-to: Your message of "Sat, 20 Jan 2001 23:53:45 GMT." <003401c0833c$39ac3f40$1004020a@darkstar> References: <003401c0833c$39ac3f40$1004020a@darkstar> Date: Sun, 21 Jan 2001 12:29:08 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <003401c0833c$39ac3f40$1004020a@darkstar> "Cameron Grant" writes: : unless vetoed for good reason, i intend to MFC kobj support into 4.x and Wouldn't the kobj merge break binary compatibility that we're trying to maintain? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 12: 5:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id D25E137B400 for ; Sun, 21 Jan 2001 12:05:15 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id PAA04871; Sun, 21 Jan 2001 15:04:47 -0500 (EST) Date: Sun, 21 Jan 2001 15:04:43 -0500 (EST) From: Daniel Eischen To: Warner Losh Cc: "Jacques A. Vidrine" , arch@FreeBSD.ORG Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r In-Reply-To: <200101211927.f0LJRU901079@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 21 Jan 2001, Warner Losh wrote: > In message Daniel Eischen writes: > : > By the way, should it be __thread_sys_foo and __foo? Two underscores? > : > ISTR some rule about using a single leading underscore for file scope > : > (e.g. macros) and two for global scope. > : > : I don't recall that, but anything for file scope that isn't a macro > : can be static and not use the underscores. Macros are usually upper > : case anyways. > > ANSI C reserves _[A-Z]* and __[a-zA-Z] to the implementation space. > That leaves _[a-z] to the user name space, so Jacques is right about > that. Well, we don't seem to be following that right now, but I'll adhere to that in anything I add. So how about instead of using _thread_sys_foo, we use __sys_foo: __sys_foo - actual system call _foo - weak definition to __sys_foo foo - weak definition to __sys_foo We could always do this for all system calls, but I'd like to leave that for a future change if desired. I can also work my way through libc to clean up its namespace. Can we come to a concensus that with the above changes, I can proceed? I've tested everything I can under x86, and am waiting for someone to create a directory (/j/deischen) on beast to test a buildworld. > I can quote chapter and verse if you really want me to. No, that isn't necessary :-) -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 12:31:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id DDD5A37B400 for ; Sun, 21 Jan 2001 12:30:52 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0LKUV901434; Sun, 21 Jan 2001 13:30:31 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101212030.f0LKUV901434@harmony.village.org> To: Daniel Eischen Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r Cc: "Jacques A. Vidrine" , arch@FreeBSD.ORG In-reply-to: Your message of "Sun, 21 Jan 2001 15:04:43 EST." References: Date: Sun, 21 Jan 2001 13:30:31 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Daniel Eischen writes: : Well, we don't seem to be following that right now, but I'll adhere to : that in anything I add. So how about instead of using _thread_sys_foo, : we use __sys_foo: : : __sys_foo - actual system call : _foo - weak definition to __sys_foo : foo - weak definition to __sys_foo Good, but would it be easy to do __foo rather than _foo? Is there a reason why _foo would be desired? i'm not sure that I like all this weak stuff, but I'll reply with since I don't have . :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 13:24:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 2615E37B400 for ; Sun, 21 Jan 2001 13:23:56 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id QAA14344; Sun, 21 Jan 2001 16:23:31 -0500 (EST) Date: Sun, 21 Jan 2001 16:23:31 -0500 (EST) From: Daniel Eischen To: Warner Losh Cc: "Jacques A. Vidrine" , arch@FreeBSD.ORG Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r In-Reply-To: <200101212030.f0LKUV901434@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 21 Jan 2001, Warner Losh wrote: > In message Daniel Eischen writes: > : Well, we don't seem to be following that right now, but I'll adhere to > : that in anything I add. So how about instead of using _thread_sys_foo, > : we use __sys_foo: > : > : __sys_foo - actual system call > : _foo - weak definition to __sys_foo > : foo - weak definition to __sys_foo > > Good, but would it be easy to do __foo rather than _foo? Is there a > reason why _foo would be desired? Simply to differentiate between syscalls and library routines. > i'm not sure that I like all this weak stuff, but I'll reply with > since I don't have . :-) -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 13:33:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 2430B37B400 for ; Sun, 21 Jan 2001 13:33:04 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id QAA15453; Sun, 21 Jan 2001 16:32:39 -0500 (EST) Date: Sun, 21 Jan 2001 16:32:39 -0500 (EST) From: Daniel Eischen To: Warner Losh Cc: "Jacques A. Vidrine" , arch@FreeBSD.ORG Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r In-Reply-To: <200101212030.f0LKUV901434@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 21 Jan 2001, Warner Losh wrote: > In message Daniel Eischen writes: > : Well, we don't seem to be following that right now, but I'll adhere to > : that in anything I add. So how about instead of using _thread_sys_foo, > : we use __sys_foo: > : > : __sys_foo - actual system call > : _foo - weak definition to __sys_foo > : foo - weak definition to __sys_foo > > Good, but would it be easy to do __foo rather than _foo? Is there a > reason why _foo would be desired? Oops, sorry, I missed the second question. You need _foo to be used within libc, so that when libc_r/libpthread is linked in, it can provide a replacement function for it. We also need to determine if the function is a cancellation point or not, so if you just had foo and __sys_foo, libc_r/libpthread would have no way of knowing if foo was called from within libc or from the user application. The former is not a cancellation point, while the latter is (if foo is read for example). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 13:36:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 76E2037B404 for ; Sun, 21 Jan 2001 13:36:25 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0LLaM901943; Sun, 21 Jan 2001 14:36:22 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101212136.f0LLaM901943@harmony.village.org> To: Daniel Eischen Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r Cc: "Jacques A. Vidrine" , arch@FreeBSD.ORG In-reply-to: Your message of "Sun, 21 Jan 2001 16:32:39 EST." References: Date: Sun, 21 Jan 2001 14:36:22 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Daniel Eischen writes: : Oops, sorry, I missed the second question. You need _foo to be : used within libc, so that when libc_r/libpthread is linked in, : it can provide a replacement function for it. We also need to : determine if the function is a cancellation point or not, so : if you just had foo and __sys_foo, libc_r/libpthread would have : no way of knowing if foo was called from within libc or from : the user application. The former is not a cancellation point, : while the latter is (if foo is read for example). I understand that. I guess my question is why name it _foo instead of __foo? I see the need for the tripartiteness, just not the need to call it _foo. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 13:45:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id EC8EC37B401 for ; Sun, 21 Jan 2001 13:45:03 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id QAA16773; Sun, 21 Jan 2001 16:44:39 -0500 (EST) Date: Sun, 21 Jan 2001 16:44:38 -0500 (EST) From: Daniel Eischen To: Warner Losh Cc: "Jacques A. Vidrine" , arch@FreeBSD.ORG Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r In-Reply-To: <200101212136.f0LLaM901943@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 21 Jan 2001, Warner Losh wrote: > In message Daniel Eischen writes: > : Oops, sorry, I missed the second question. You need _foo to be > : used within libc, so that when libc_r/libpthread is linked in, > : it can provide a replacement function for it. We also need to > : determine if the function is a cancellation point or not, so > : if you just had foo and __sys_foo, libc_r/libpthread would have > : no way of knowing if foo was called from within libc or from > : the user application. The former is not a cancellation point, > : while the latter is (if foo is read for example). > > I understand that. I guess my question is why name it _foo instead of > __foo? I see the need for the tripartiteness, just not the need to > call it _foo. I guess it doesn't matter to me wether it's _foo or __foo, but we do have to use it within libc. We've already done the work to use _foo in libc, so it's extra work to go back and use __foo. I guess this gets back to the ANSI namespace issue. Our using _foo in libc doesn't affect an applications namespace because it's a weak definition; anything the user provides will override it. But, that means that our internal use of _foo would then call the user applications _foo. If it's OK for folks to see and use __foo in libc as opposed to _foo, I can make that change. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 14:37:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B9BA437B404; Sun, 21 Jan 2001 14:36:50 -0800 (PST) Received: from localhost (3ysk8l@localhost [127.0.0.1]) by green.dyndns.org (8.11.1/8.11.1) with ESMTP id f0LMajc09302; Sun, 21 Jan 2001 17:36:47 -0500 (EST) (envelope-from green@FreeBSD.org) Message-Id: <200101212236.f0LMajc09302@green.dyndns.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Warner Losh Cc: "Cameron Grant" , arch@FreeBSD.org, stable@FreeBSD.org Subject: Re: newpcm/kobj MFC In-Reply-To: Message from Warner Losh of "Sun, 21 Jan 2001 12:29:08 MST." <200101211929.f0LJT8901098@harmony.village.org> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Jan 2001 17:36:44 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > In message <003401c0833c$39ac3f40$1004020a@darkstar> "Cameron Grant" writes: > : unless vetoed for good reason, i intend to MFC kobj support into 4.x and > > Wouldn't the kobj merge break binary compatibility that we're trying > to maintain? And then make it so that binary compatibility will be preserved between 5.0 and 4.X for newpcm modules? (at least until the driver is properly locked ...) -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 14:40:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 83C4637B404; Sun, 21 Jan 2001 14:40:34 -0800 (PST) Received: from localhost (qieqtq@localhost [127.0.0.1]) by green.dyndns.org (8.11.1/8.11.1) with ESMTP id f0LMeSc20272; Sun, 21 Jan 2001 17:40:29 -0500 (EST) (envelope-from green@FreeBSD.org) Message-Id: <200101212240.f0LMeSc20272@green.dyndns.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Daniel Eischen Cc: Warner Losh , "Jacques A. Vidrine" , arch@FreeBSD.org Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r In-Reply-To: Message from Daniel Eischen of "Sun, 21 Jan 2001 16:44:38 EST." From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Jan 2001 17:40:28 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel Eischen wrote: > On Sun, 21 Jan 2001, Warner Losh wrote: > > In message Daniel Eischen writes: > > : Oops, sorry, I missed the second question. You need _foo to be > > : used within libc, so that when libc_r/libpthread is linked in, > > : it can provide a replacement function for it. We also need to > > : determine if the function is a cancellation point or not, so > > : if you just had foo and __sys_foo, libc_r/libpthread would have > > : no way of knowing if foo was called from within libc or from > > : the user application. The former is not a cancellation point, > > : while the latter is (if foo is read for example). > > > > I understand that. I guess my question is why name it _foo instead of > > __foo? I see the need for the tripartiteness, just not the need to > > call it _foo. > > I guess it doesn't matter to me wether it's _foo or __foo, but > we do have to use it within libc. We've already done the work > to use _foo in libc, so it's extra work to go back and use __foo. > I guess this gets back to the ANSI namespace issue. Our using > _foo in libc doesn't affect an applications namespace because > it's a weak definition; anything the user provides will override > it. But, that means that our internal use of _foo would then > call the user applications _foo. Yes, this is much too risky... if the two namespaces clearly stay away from eachother, then there's no worrying about this (unless you're a library writer who needs global __xxx symbols for some reason). > If it's OK for folks to see and use __foo in libc as opposed > to _foo, I can make that change. It's much too dangerous, I believe, to let libc escape out into the application's namespace much. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 14:55:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 2635D37B401; Sun, 21 Jan 2001 14:55:12 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id RAA25406; Sun, 21 Jan 2001 17:54:48 -0500 (EST) Date: Sun, 21 Jan 2001 17:54:48 -0500 (EST) From: Daniel Eischen To: "Brian F. Feldman" Cc: Warner Losh , "Jacques A. Vidrine" , arch@FreeBSD.org Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r In-Reply-To: <200101212240.f0LMeSc20272@green.dyndns.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 21 Jan 2001, Brian F. Feldman wrote: > Daniel Eischen wrote: > > On Sun, 21 Jan 2001, Warner Losh wrote: > > > In message Daniel Eischen writes: > > > : Oops, sorry, I missed the second question. You need _foo to be > > > : used within libc, so that when libc_r/libpthread is linked in, > > > : it can provide a replacement function for it. We also need to > > > : determine if the function is a cancellation point or not, so > > > : if you just had foo and __sys_foo, libc_r/libpthread would have > > > : no way of knowing if foo was called from within libc or from > > > : the user application. The former is not a cancellation point, > > > : while the latter is (if foo is read for example). > > > > > > I understand that. I guess my question is why name it _foo instead of > > > __foo? I see the need for the tripartiteness, just not the need to > > > call it _foo. > > > > I guess it doesn't matter to me wether it's _foo or __foo, but > > we do have to use it within libc. We've already done the work > > to use _foo in libc, so it's extra work to go back and use __foo. > > I guess this gets back to the ANSI namespace issue. Our using > > _foo in libc doesn't affect an applications namespace because > > it's a weak definition; anything the user provides will override > > it. But, that means that our internal use of _foo would then > > call the user applications _foo. > > Yes, this is much too risky... if the two namespaces clearly stay away from > eachother, then there's no worrying about this (unless you're a library > writer who needs global __xxx symbols for some reason). > > > If it's OK for folks to see and use __foo in libc as opposed > > to _foo, I can make that change. > > It's much too dangerous, I believe, to let libc escape out into the > application's namespace much. Remember that this is already possible. Our current syscalls are _foo with foo being a weak definition to _foo. We currently use foo all over libc and noone seems to object until now. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 15:36:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id 7773837B401; Sun, 21 Jan 2001 15:36:03 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.1/8.11.1) id f0LNd4374894; Sun, 21 Jan 2001 15:39:04 -0800 (PST) (envelope-from kris) Date: Sun, 21 Jan 2001 15:39:04 -0800 From: Kris Kennaway To: Cameron Grant Cc: arch@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: newpcm/kobj MFC Message-ID: <20010121153904.B74751@citusc17.usc.edu> References: <003401c0833c$39ac3f40$1004020a@darkstar> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="4SFOXa2GPu3tIq4H" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <003401c0833c$39ac3f40$1004020a@darkstar>; from gandalf@vilnya.demon.co.uk on Sat, Jan 20, 2001 at 11:53:45PM -0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --4SFOXa2GPu3tIq4H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 20, 2001 at 11:53:45PM -0000, Cameron Grant wrote: > this is a followup to my proposal some weeks ago which recieved no releva= nt > commentary. I'm also concerned about breaking binary compatibility. I understand your reasons for wanting this, but we really shouldn't be breaking binary compatibility in -stable. If we keep doing this then no third party vendor is going to want to support drivers that they have to update every few months. Kris --=20 NOTE: To fetch an updated copy of my GPG key which has not expired, finger kris@FreeBSD.org --4SFOXa2GPu3tIq4H Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6a3MYWry0BWjoQKURAs94AJ9mI543CvOBhCKTNx/CTUwufLqq+wCeLrki bxG3aijkA0rY3WLTtZ8040o= =8Ays -----END PGP SIGNATURE----- --4SFOXa2GPu3tIq4H-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 17: 4:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 8C56B37B400; Sun, 21 Jan 2001 17:04:03 -0800 (PST) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.1/8.11.0) with ESMTP id f0M142O04580; Sun, 21 Jan 2001 20:04:02 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200101220104.f0M142O04580@whizzo.transsys.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Kris Kennaway Cc: Cameron Grant , arch@FreeBSD.ORG, stable@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: newpcm/kobj MFC References: <003401c0833c$39ac3f40$1004020a@darkstar> <20010121153904.B74751@citusc17.usc.edu> In-reply-to: Your message of "Sun, 21 Jan 2001 15:39:04 PST." <20010121153904.B74751@citusc17.usc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Jan 2001 20:04:02 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sat, Jan 20, 2001 at 11:53:45PM -0000, Cameron Grant wrote: > > this is a followup to my proposal some weeks ago which recieved no relevant > > commentary. > > I'm also concerned about breaking binary compatibility. I understand > your reasons for wanting this, but we really shouldn't be breaking > binary compatibility in -stable. If we keep doing this then no third > party vendor is going to want to support drivers that they have to > update every few months. My concern as a "user" is that we continue to have maintained sound drivers in RELENG_4. My impression is that it will be a while before CURRENT is working well enough for the great unwashed masses to use, perhaps longer than usual for a new major version release. It would be useful perhaps to gauge the actual impact of this incompatability (how many people are using 3rd party sound driver?) before making a decision. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 17:11:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from vilnya.demon.co.uk (vilnya.demon.co.uk [158.152.19.238]) by hub.freebsd.org (Postfix) with ESMTP id DA77237B401; Sun, 21 Jan 2001 17:11:14 -0800 (PST) Received: from darkstar (darkstar.rings [10.2.4.16]) by vilnya.demon.co.uk (Postfix) with SMTP id B603CD9B8; Mon, 22 Jan 2001 01:11:12 +0000 (GMT) Message-ID: <001b01c0840f$b30ea070$1004020a@darkstar> From: "Cameron Grant" To: "Kris Kennaway" , "Louis A. Mamakos" Cc: , References: <003401c0833c$39ac3f40$1004020a@darkstar> <20010121153904.B74751@citusc17.usc.edu> <200101220104.f0M142O04580@whizzo.transsys.com> Subject: Re: newpcm/kobj MFC Date: Mon, 22 Jan 2001 01:07:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > On Sat, Jan 20, 2001 at 11:53:45PM -0000, Cameron Grant wrote: > > > this is a followup to my proposal some weeks ago which recieved no relevant > > > commentary. > > I'm also concerned about breaking binary compatibility. I understand > > your reasons for wanting this, but we really shouldn't be breaking > > binary compatibility in -stable. If we keep doing this then no third > > party vendor is going to want to support drivers that they have to > > update every few months. > It would be useful perhaps to gauge the actual impact of this > incompatability (how many people are using 3rd party sound driver?) > before making a decision. to the best of my knowledge, there exist 5 drivers not in the tree now, all of which have kobjified versions available and 4 of which will be entering the tree soon. i know of no commercial newpcm drivers. -cg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 17:39:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 2786437B400; Sun, 21 Jan 2001 17:39:04 -0800 (PST) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.1/8.11.0) with ESMTP id f0M1d1O05133; Sun, 21 Jan 2001 20:39:01 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200101220139.f0M1d1O05133@whizzo.transsys.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Cameron Grant" Cc: "Kris Kennaway" , arch@FreeBSD.ORG, stable@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: newpcm/kobj MFC References: <003401c0833c$39ac3f40$1004020a@darkstar> <20010121153904.B74751@citusc17.usc.edu> <200101220104.f0M142O04580@whizzo.transsys.com> <001b01c0840f$b30ea070$1004020a@darkstar> In-reply-to: Your message of "Mon, 22 Jan 2001 01:07:32 GMT." <001b01c0840f$b30ea070$1004020a@darkstar> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Jan 2001 20:39:01 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > On Sat, Jan 20, 2001 at 11:53:45PM -0000, Cameron Grant wrote: > > > > this is a followup to my proposal some weeks ago which recieved no > relevant > > > > commentary. > > > I'm also concerned about breaking binary compatibility. I understand > > > your reasons for wanting this, but we really shouldn't be breaking > > > binary compatibility in -stable. If we keep doing this then no third > > > party vendor is going to want to support drivers that they have to > > > update every few months. > > It would be useful perhaps to gauge the actual impact of this > > incompatability (how many people are using 3rd party sound driver?) > > before making a decision. > > to the best of my knowledge, there exist 5 drivers not in the tree now, all > of which have kobjified versions available and 4 of which will be entering > the tree soon. i know of no commercial newpcm drivers. Well, there you go. Is changing an unused API an incompatability? louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 17:40:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 7F7BE37B400; Sun, 21 Jan 2001 17:40:01 -0800 (PST) Received: from localhost (yr8x7g@localhost [127.0.0.1]) by green.dyndns.org (8.11.1/8.11.1) with ESMTP id f0M1dtc71205; Sun, 21 Jan 2001 20:39:56 -0500 (EST) (envelope-from green@FreeBSD.org) Message-Id: <200101220139.f0M1dtc71205@green.dyndns.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Daniel Eischen Cc: "Brian F. Feldman" , Warner Losh , "Jacques A. Vidrine" , arch@FreeBSD.org Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r In-Reply-To: Message from Daniel Eischen of "Sun, 21 Jan 2001 17:54:48 EST." From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Jan 2001 20:39:54 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel Eischen wrote: > On Sun, 21 Jan 2001, Brian F. Feldman wrote: > > Daniel Eischen wrote: > > > If it's OK for folks to see and use __foo in libc as opposed > > > to _foo, I can make that change. > > > > It's much too dangerous, I believe, to let libc escape out into the > > application's namespace much. > > Remember that this is already possible. Our current syscalls are > _foo with foo being a weak definition to _foo. We currently use > foo all over libc and noone seems to object until now. That's true. But if you're willing to change it, I think it's worth doing. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 18:13:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 2FF7D37B404; Sun, 21 Jan 2001 18:13:07 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0M2D6903850; Sun, 21 Jan 2001 19:13:06 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101220213.f0M2D6903850@harmony.village.org> To: "Brian F. Feldman" Subject: Re: newpcm/kobj MFC Cc: "Cameron Grant" , arch@FreeBSD.ORG, stable@FreeBSD.ORG In-reply-to: Your message of "Sun, 21 Jan 2001 17:36:44 EST." <200101212236.f0LMajc09302@green.dyndns.org> References: <200101212236.f0LMajc09302@green.dyndns.org> Date: Sun, 21 Jan 2001 19:13:06 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101212236.f0LMajc09302@green.dyndns.org> "Brian F. Feldman" writes: : Warner Losh wrote: : > In message <003401c0833c$39ac3f40$1004020a@darkstar> "Cameron Grant" writes: : > : unless vetoed for good reason, i intend to MFC kobj support into 4.x and : > : > Wouldn't the kobj merge break binary compatibility that we're trying : > to maintain? : : And then make it so that binary compatibility will be preserved between 5.0 : and 4.X for newpcm modules? (at least until the driver is properly locked : ...) There is no way in heck that a 4.x driver will run on 5.x right now. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 18:14:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id D27E637B400; Sun, 21 Jan 2001 18:14:27 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0M2EP903890; Sun, 21 Jan 2001 19:14:25 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101220214.f0M2EP903890@harmony.village.org> To: "Louis A. Mamakos" Subject: Re: newpcm/kobj MFC Cc: Kris Kennaway , Cameron Grant , arch@FreeBSD.ORG, stable@FreeBSD.ORG In-reply-to: Your message of "Sun, 21 Jan 2001 20:04:02 EST." <200101220104.f0M142O04580@whizzo.transsys.com> References: <200101220104.f0M142O04580@whizzo.transsys.com> <003401c0833c$39ac3f40$1004020a@darkstar> <20010121153904.B74751@citusc17.usc.edu> Date: Sun, 21 Jan 2001 19:14:25 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101220104.f0M142O04580@whizzo.transsys.com> "Louis A. Mamakos" writes: : It would be useful perhaps to gauge the actual impact of this : incompatability (how many people are using 3rd party sound driver?) : before making a decision. The right question is "How many people are using 3rd party drivers?" since this break binary compatibility for all drivers. That's if I understand the kobj stuff correctly. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 19:31:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from vilnya.demon.co.uk (vilnya.demon.co.uk [158.152.19.238]) by hub.freebsd.org (Postfix) with ESMTP id 52CDC37B401; Sun, 21 Jan 2001 19:30:51 -0800 (PST) Received: from darkstar (darkstar.rings [10.2.4.16]) by vilnya.demon.co.uk (Postfix) with SMTP id 2DA24D9B8; Mon, 22 Jan 2001 03:30:49 +0000 (GMT) Message-ID: <007101c08423$33d961a0$1004020a@darkstar> From: "Cameron Grant" To: "Brian F. Feldman" , "Warner Losh" Cc: , References: <200101212236.f0LMajc09302@green.dyndns.org> <200101220213.f0M2D6903850@harmony.village.org> Subject: Re: newpcm/kobj MFC Date: Mon, 22 Jan 2001 03:27:09 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <200101212236.f0LMajc09302@green.dyndns.org> "Brian F. Feldman" writes: > : Warner Losh wrote: > : > In message <003401c0833c$39ac3f40$1004020a@darkstar> "Cameron Grant" writes: > : > : unless vetoed for good reason, i intend to MFC kobj support into 4.x and > : > > : > Wouldn't the kobj merge break binary compatibility that we're trying > : > to maintain? > : > : And then make it so that binary compatibility will be preserved between 5.0 > : and 4.X for newpcm modules? (at least until the driver is properly locked > : ...) > > There is no way in heck that a 4.x driver will run on 5.x right now. once newpcm in 4.x is kobjified, drivers from 5.x will at least be source compatible, and appear to be binary compatible from the quick test i just did, though i'm not sure how dependancy data is handled. -cg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 19:41:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id BBF6037B400; Sun, 21 Jan 2001 19:41:34 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0M3fV904592; Sun, 21 Jan 2001 20:41:31 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101220341.f0M3fV904592@harmony.village.org> To: "Cameron Grant" Subject: Re: newpcm/kobj MFC Cc: "Brian F. Feldman" , arch@FreeBSD.ORG, stable@FreeBSD.ORG In-reply-to: Your message of "Mon, 22 Jan 2001 03:27:09 GMT." <007101c08423$33d961a0$1004020a@darkstar> References: <007101c08423$33d961a0$1004020a@darkstar> <200101212236.f0LMajc09302@green.dyndns.org> <200101220213.f0M2D6903850@harmony.village.org> Date: Sun, 21 Jan 2001 20:41:31 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <007101c08423$33d961a0$1004020a@darkstar> "Cameron Grant" writes: : once newpcm in 4.x is kobjified, drivers from 5.x will at least be source : compatible, and appear to be binary compatible from the quick test i just : did, though i'm not sure how dependancy data is handled. OK. Are you going to just change the interface between the sound drivers and the pcm system, or are you going to back port the newer kobj system. If just the former, then forget I said anything. If there's no kernel interaction other than the bus_space* functions, chances are pretty good it might work. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 19:50: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from vilnya.demon.co.uk (vilnya.demon.co.uk [158.152.19.238]) by hub.freebsd.org (Postfix) with ESMTP id 7B2FB37B400; Sun, 21 Jan 2001 19:49:43 -0800 (PST) Received: from darkstar (darkstar.rings [10.2.4.16]) by vilnya.demon.co.uk (Postfix) with SMTP id 5D88ED9B8; Mon, 22 Jan 2001 03:49:41 +0000 (GMT) Message-ID: <007901c08425$d6b11600$1004020a@darkstar> From: "Cameron Grant" To: "Warner Losh" Cc: "Brian F. Feldman" , , References: <007101c08423$33d961a0$1004020a@darkstar> <200101212236.f0LMajc09302@green.dyndns.org> <200101220213.f0M2D6903850@harmony.village.org> <200101220341.f0M3fV904592@harmony.village.org> Subject: Re: newpcm/kobj MFC Date: Mon, 22 Jan 2001 03:46:01 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > OK. Are you going to just change the interface between the sound > drivers and the pcm system, or are you going to back port the newer > kobj system. If just the former, then forget I said anything. If > there's no kernel interaction other than the bus_space* functions, > chances are pretty good it might work. the change involves backporting kobj, but it will only be used in the interface between newpcm and newpcm hardware drivers. there will be no change in binary compatibility for the rest of the kernel. -cg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 19:52:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 29C6537B402; Sun, 21 Jan 2001 19:52:22 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0M3qF904691; Sun, 21 Jan 2001 20:52:15 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101220352.f0M3qF904691@harmony.village.org> To: "Cameron Grant" Subject: Re: newpcm/kobj MFC Cc: "Brian F. Feldman" , arch@FreeBSD.ORG, stable@FreeBSD.ORG In-reply-to: Your message of "Mon, 22 Jan 2001 03:46:01 GMT." <007901c08425$d6b11600$1004020a@darkstar> References: <007901c08425$d6b11600$1004020a@darkstar> <007101c08423$33d961a0$1004020a@darkstar> <200101212236.f0LMajc09302@green.dyndns.org> <200101220213.f0M2D6903850@harmony.village.org> <200101220341.f0M3fV904592@harmony.village.org> Date: Sun, 21 Jan 2001 20:52:15 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <007901c08425$d6b11600$1004020a@darkstar> "Cameron Grant" writes: : the change involves backporting kobj, but it will only be used in the : interface between newpcm and newpcm hardware drivers. there will be no : change in binary compatibility for the rest of the kernel. Ah. I misunderstood. Change me to a "go for it" kinda guy. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 20:47:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id D529537B401 for ; Sun, 21 Jan 2001 20:47:26 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id FAA69487; Mon, 22 Jan 2001 05:47:25 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: arch@freebsd.org Subject: Second zone allocator patch From: Dag-Erling Smorgrav Date: 22 Jan 2001 05:47:25 +0100 Message-ID: Lines: 21 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG http://people.freebsd.org/~des/software/vm_zone-20010122.diff This replaces the simplelock in vm_zone with a mutex, and adds a subsystem mutex that must be held when manipulating zlist (which is now an SLIST). Stuff that remains to be done: - use atomic operations for updating the statistics counters. - implement vm_zone_init2() and find the right place to call it from, to remove the need for zinitna(). - make the rest of the VM system thread-safe so we can dispense with the Giant hackery in zinitna() and _zget(). - add a mail reader (accessible through the sysctl interface). DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 21 21:49:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 90C4937B404; Sun, 21 Jan 2001 21:48:56 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA06650; Mon, 22 Jan 2001 16:48:47 +1100 Date: Mon, 22 Jan 2001 16:48:41 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Warner Losh Cc: "Brian F. Feldman" , Cameron Grant , arch@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: newpcm/kobj MFC In-Reply-To: <200101220213.f0M2D6903850@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 21 Jan 2001, Warner Losh wrote: > In message <200101212236.f0LMajc09302@green.dyndns.org> "Brian F. Feldman" writes: > : And then make it so that binary compatibility will be preserved between 5.0 > : and 4.X for newpcm modules? (at least until the driver is properly locked > : ...) > > There is no way in heck that a 4.x driver will run on 5.x right now. E.g., 4.x drivers probably use spl's, but spl's no longer exist as extern functions. The vmware modules broke about 5 minutes after I rebuilt them when extern spl's went away a couple of days ago :-). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 0:27:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 89DCA37B698 for ; Mon, 22 Jan 2001 00:27:10 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA19786; Mon, 22 Jan 2001 19:27:01 +1100 Date: Mon, 22 Jan 2001 19:26:55 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: Second zone allocator patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > http://people.freebsd.org/~des/software/vm_zone-20010122.diff > > This replaces the simplelock in vm_zone with a mutex, and adds a > subsystem mutex that must be held when manipulating zlist (which is > now an SLIST). The simplelock was a spinlock, so changing it to a lock that can sleep changes the semantics. This seems to be a bug in the ZONE_INTERRUPT case -- note how the ZONE_INTERRUPT case of _zget() avoids locking stuff while the !ZONE_INTERRUPT case uses it. > - add a mail reader (accessible through the sysctl interface). Hehe. sysctl_vm_zone() reminds me too much of Linux procfs where the kernel wastes a lot of time formatting strings. It doesn't even provide any features that aren't implemented in userland like it did originally, since dillon implemented vmstat -z (except vmstat -z leaves out some details). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 1: 2:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id BB8AA37B404 for ; Mon, 22 Jan 2001 01:02:31 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id UAA22026; Mon, 22 Jan 2001 20:01:51 +1100 Date: Mon, 22 Jan 2001 20:01:45 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Warner Losh Cc: Daniel Eischen , "Jacques A. Vidrine" , arch@FreeBSD.ORG Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r In-Reply-To: <200101212136.f0LLaM901943@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 21 Jan 2001, Warner Losh wrote: > In message Daniel Eischen writes: > : Oops, sorry, I missed the second question. You need _foo to be > : used within libc, so that when libc_r/libpthread is linked in, > : it can provide a replacement function for it. We also need to > : determine if the function is a cancellation point or not, so > : if you just had foo and __sys_foo, libc_r/libpthread would have > : no way of knowing if foo was called from within libc or from > : the user application. The former is not a cancellation point, > : while the latter is (if foo is read for example). > > I understand that. I guess my question is why name it _foo instead of > __foo? I see the need for the tripartiteness, just not the need to > call it _foo. (1) Underscores are verbose and ugly. (2) _foo is usually sufficient. _[a-z] is not entirely in the user namespace like you are claimed. From the 1990 ISO standard: "All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary identifier and tag name spaces". In practice, this means that the implementation can use names beginning with _[a-z] except for macro names and global variables that are used in macros. E.g., errno must be defined as (*__error()) and not as (*_error()), since the latter would break the standard-conforming application code: #include void foo(void) { int _error = errno; } A single underscore is sufficient in all other cases. E.g., struct member names are in a nested namespace so they don't conflict with variable names at all. They may still need a single underscore so that they don't conflict with macro names. (3) We have some precedence for using _foo. (4) NetBSD uses _foo (at least in old versions). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 2:28:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 049B137B400 for ; Mon, 22 Jan 2001 02:28:15 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id FAA18961; Mon, 22 Jan 2001 05:27:47 -0500 (EST) Date: Mon, 22 Jan 2001 05:27:47 -0500 (EST) From: Daniel Eischen To: Bruce Evans Cc: Warner Losh , "Jacques A. Vidrine" , arch@FreeBSD.ORG Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 22 Jan 2001, Bruce Evans wrote: > On Sun, 21 Jan 2001, Warner Losh wrote: > > > In message Daniel Eischen writes: > > : Oops, sorry, I missed the second question. You need _foo to be > > : used within libc, so that when libc_r/libpthread is linked in, > > : it can provide a replacement function for it. We also need to > > : determine if the function is a cancellation point or not, so > > : if you just had foo and __sys_foo, libc_r/libpthread would have > > : no way of knowing if foo was called from within libc or from > > : the user application. The former is not a cancellation point, > > : while the latter is (if foo is read for example). > > > > I understand that. I guess my question is why name it _foo instead of > > __foo? I see the need for the tripartiteness, just not the need to > > call it _foo. > > (1) Underscores are verbose and ugly. > (2) _foo is usually sufficient. _[a-z] is not entirely in the user > namespace like you are claimed. From the 1990 ISO standard: > "All identifiers that begin with an underscore are always > reserved for use as identifiers with file scope in both the > ordinary identifier and tag name spaces". In practice, this > means that the implementation can use names beginning with > _[a-z] except for macro names and global variables that are > used in macros. E.g., errno must be defined as (*__error()) > and not as (*_error()), since the latter would break the > standard-conforming application code: > #include > void foo(void) { int _error = errno; } > A single underscore is sufficient in all other cases. E.g., > struct member names are in a nested namespace so they don't > conflict with variable names at all. They may still need a > single underscore so that they don't conflict with macro > names. > (3) We have some precedence for using _foo. > (4) NetBSD uses _foo (at least in old versions). How about this compromise: __sys_foo(T), _foo(W), foo(W). Noone but libc_r, except perhaps for exit.c, needs to reference __sys_foo. Poking around with nm on Solaris seems to show that they use __foo for system calls, and _bar for library functions. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 2:41:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 8F1F537B402 for ; Mon, 22 Jan 2001 02:41:15 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA28853; Mon, 22 Jan 2001 21:40:58 +1100 Date: Mon, 22 Jan 2001 21:40:52 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Peter Wemm Cc: "Jacques A. Vidrine" , Daniel Eischen , arch@FreeBSD.ORG Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r In-Reply-To: <200101210002.f0L02rk43575@mobile.wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 20 Jan 2001, Peter Wemm wrote: > "Jacques A. Vidrine" wrote: > > I have one objection: > > > > [snip] > > > _thread_sys_foo - actual syscall > > > _foo - weak definition to _thread_sys_foo > > > foo - weak definition to _thread_sys_foo > > > > > > I've changed all the instances of foo() to _foo() in libc for > > > those hidden system calls. Anyone modifying or adding to libc > > > will have to be careful to use the same conventions. > > > > Please, no. Kill `un-namespace' and let us continue to use the > > correct name for `foo'. Adding underscores in front of lotsa common > > calls hurt my eyes and hinders porting between different libc > > implementations (e.g. our `old' one, other *BSDs). I think it would be more confusing without the explicit underscores. The library really does call the underscored versions. To debug it you need to put breakpoints at the underscored versions... > Hmm. I went through the diff looking for reasons why we needed the > un-namespace.h stuff and to use the _ prefix, but now I am not sure. I > suspect we probably should add the _ characters and leave the #defines > active. Unless I missed something.. namespace.h is an evil hack (#defining names in the implementation namespace gives undefined behaviour, and can cause problems even for the implementor). un-namespace.h is to limit this hack to headers and prevent future unintentional dependencies on it. > On the subject of namespace etc, I wish this went further. Consider > malloc(). We provide a strong 'malloc' symbol. I think it would be better > if we provided _malloc(), _free(), _calloc() and a weak malloc->_malloc > pointer etc. This way if the user process provides an alternative malloc, > then libc and everything else should use the one single malloc. I helped implement this for the Minix libc many years ago. Not many people seem to care about it in practice. There is (was?) a Linux distribution that made a marketing point about it. glibc is careful about it. > > Finally, I hope this will lead us into introducing all non- Standard C > > (or at least non-POSIX) function identifiers in the same fashion, so > > as to clean up our namespace. For example, err(3). Jacques' nsswitch changes broke static linkage by calling the err() family from libc. I have uncommitted fixes. Recent crypto changes broke static linkage in several ways, one involving namespace collisions. > Yes! Something like what bind did with the resolver namespace? ie: if you Hopefully nothing like what bind did :-). Bind shows how not to do it. > want to use the res_foo() functions, you must #include in order > to get the prototypes and the #define res_foo __res_foo into scope. This > stops res_foo() in libc conflicting with your res_foo() in your program. This results in no library functions name res_foo actually being in your program. The following things break: 1) #undef'ing res_foo. ISTR that the Standard C library explicitly permits #undef'ing the names of most standard functions (ones which are documented as being macros only). You might want to do this for simpler debugging. 2) Calling (res_foo). The parentheses prevent the macro be expanded, and there should be a backing function. I'm sure Stdnard C permits this for most functions. 3) Putting a breakpoint at res_foo in a debugger. 4) Utilities that check things related to res_foo. I have a man page checker that reads the prototype for res_foo from its man page and checks that this matches one in the the headers documented in the man page. This fails because there is no prototype for res_foo in the headers, only one for __res_foo. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 6:53:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by hub.freebsd.org (Postfix) with ESMTP id 0981137B401; Mon, 22 Jan 2001 06:53:05 -0800 (PST) Received: from calcaphon.demon.co.uk ([193.237.19.5]) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 14KiL6-000JsJ-0K; Mon, 22 Jan 2001 14:53:02 +0000 Received: from doug01 (dhcp112.qubesoft.com [192.168.1.112]) by calcaphon.demon.co.uk (8.11.1/8.9.1) with SMTP id f0MEqxT33505; Mon, 22 Jan 2001 14:52:59 GMT (envelope-from dfr@nlsystems.com) Message-ID: <02af01c08482$d2dc9420$7001a8c0@doug01> From: "Doug Rabson" To: "Cameron Grant" , "Warner Losh" Cc: , References: <003401c0833c$39ac3f40$1004020a@darkstar> <200101211929.f0LJT8901098@harmony.village.org> Subject: Re: newpcm/kobj MFC Date: Mon, 22 Jan 2001 14:50:58 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ----- Original Message ----- From: "Warner Losh" To: "Cameron Grant" Cc: ; Sent: Sunday, January 21, 2001 7:29 PM Subject: Re: newpcm/kobj MFC > In message <003401c0833c$39ac3f40$1004020a@darkstar> "Cameron Grant" writes: > : unless vetoed for good reason, i intend to MFC kobj support into 4.x and > > Wouldn't the kobj merge break binary compatibility that we're trying > to maintain? As far as I know, Cameron is only merging kobj, not the changes to subr_bus.c which use kobj. The ABI for newbus will not be affected. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 7:31: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 4591837B401 for ; Mon, 22 Jan 2001 07:30:44 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 6A63C193E4; Mon, 22 Jan 2001 09:30:43 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.1/8.9.3) id f0MFUhO93317; Mon, 22 Jan 2001 09:30:43 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Mon, 22 Jan 2001 09:30:43 -0600 From: "Jacques A. Vidrine" To: Daniel Eischen Cc: arch@freebsd.org Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r Message-ID: <20010122093043.B93103@hamlet.nectar.com> References: <20010120153158.A88123@hamlet.nectar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from eischen@vigrid.com on Sat, Jan 20, 2001 at 05:26:26PM -0500 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 20, 2001 at 05:26:26PM -0500, Daniel Eischen wrote: > Sorry, I don't think that's going to work, especially for > sigaction, flock, and kevent. These cannot be #define'd to > there underscore(_) equivalents because it would also redefine > struct sigaction, struct flock, and struct kevent. So there are a handful of special cases. > The tree has already been populated with lotsa _foo calls; this > just finishes the job. A handful of `_foo's don't bother me. Having hundreds of calls that must be _foo does bother me (I'm speaking of all the symbols that need to be hidden). > > By the way, should it be __thread_sys_foo and __foo? Two underscores? > > ISTR some rule about using a single leading underscore for file scope > > (e.g. macros) and two for global scope. > > I don't recall that, but anything for file scope that isn't a macro > can be static and not use the underscores. Macros are usually upper > case anyways. Excerpt from C99 7.1.3.1: -- All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use. -- All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces. Maybe I'm reading it wrong, but it looks to me like _foo should really only be used for macros (file scope), and symbols that the implementation needs to expose should start with _[A-Z_]. Bruce once made this comment when we were discussing hiding the err(3) symbols: Better with 2 prepended underscores (mainly for consistency). Maybe he has more to add. > > Finally, I hope this will lead us into introducing all non- Standard C > > (or at least non-POSIX) function identifiers in the same fashion, so > > as to clean up our namespace. For example, err(3). > > I think that's a good idea, and am willing to do the work if given > list of the functions that need to be changed. ISO/IEC 9899:1999 lists the reserved names. Any other library functions should ideally be hidden. Maybe I'll make a list of the reserved names and post'em. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 7:32:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id B49BD37B401 for ; Mon, 22 Jan 2001 07:32:18 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 2774D193E4; Mon, 22 Jan 2001 09:32:18 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.1/8.9.3) id f0MFWI093324; Mon, 22 Jan 2001 09:32:18 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Mon, 22 Jan 2001 09:32:18 -0600 From: "Jacques A. Vidrine" To: Daniel Eischen Cc: Warner Losh , arch@FreeBSD.ORG Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r Message-ID: <20010122093218.C93103@hamlet.nectar.com> References: <200101211927.f0LJRU901079@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from eischen@vigrid.com on Sun, Jan 21, 2001 at 03:04:43PM -0500 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 21, 2001 at 03:04:43PM -0500, Daniel Eischen wrote: > On Sun, 21 Jan 2001, Warner Losh wrote: > > In message Daniel Eischen writes: > > : > By the way, should it be __thread_sys_foo and __foo? Two underscores? > > : > ISTR some rule about using a single leading underscore for file scope > > : > (e.g. macros) and two for global scope. > > : > > : I don't recall that, but anything for file scope that isn't a macro > > : can be static and not use the underscores. Macros are usually upper > > : case anyways. > > > > ANSI C reserves _[A-Z]* and __[a-zA-Z] to the implementation space. > > That leaves _[a-z] to the user name space, so Jacques is right about > > that. > > Well, we don't seem to be following that right now, but I'll adhere to > that in anything I add. So how about instead of using _thread_sys_foo, > we use __sys_foo: > > __sys_foo - actual system call > _foo - weak definition to __sys_foo > foo - weak definition to __sys_foo Sounds good to me. __sys_foo is off-limits to the application. _foo will be file-scope only (no external linkage). Thanks! -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 7:36:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 2977737B401 for ; Mon, 22 Jan 2001 07:36:13 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 7348E193E4; Mon, 22 Jan 2001 09:36:12 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.1/8.9.3) id f0MFaCe93334; Mon, 22 Jan 2001 09:36:12 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Mon, 22 Jan 2001 09:36:12 -0600 From: "Jacques A. Vidrine" To: Warner Losh Cc: Daniel Eischen , arch@FreeBSD.ORG Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r Message-ID: <20010122093612.D93103@hamlet.nectar.com> References: <200101212136.f0LLaM901943@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101212136.f0LLaM901943@harmony.village.org>; from imp@harmony.village.org on Sun, Jan 21, 2001 at 02:36:22PM -0700 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 21, 2001 at 02:36:22PM -0700, Warner Losh wrote: > I understand that. I guess my question is why name it _foo instead of > __foo? I see the need for the tripartiteness, just not the need to > call it _foo. I don't mind much either way. `_foo' is fine in terms of namespaces (as long as it is a macro). `_foo' is less typing and less ugly than `__foo'. On the other hand, I would rather just `foo' where possible. That would mean making sigaction, close, kevent, et cetera special cases, however. Well, we could #define sigaction(x) sigaction##x but then we'd have to resort to #ifdef __LIBC__ or something in headers. *sigh* -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 7:45:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id DD70737B402 for ; Mon, 22 Jan 2001 07:45:28 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 7CACC193E4; Mon, 22 Jan 2001 09:45:27 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.1/8.9.3) id f0MFjRM93384; Mon, 22 Jan 2001 09:45:27 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Mon, 22 Jan 2001 09:45:27 -0600 From: "Jacques A. Vidrine" To: Daniel Eischen Cc: Peter Wemm , arch@FreeBSD.ORG Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r Message-ID: <20010122094527.E93103@hamlet.nectar.com> References: <200101210002.f0L02rk43575@mobile.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from eischen@vigrid.com on Sat, Jan 20, 2001 at 09:57:49PM -0500 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 20, 2001 at 09:57:49PM -0500, Daniel Eischen wrote: > I'm all for making other changes, but I'd first like to get these > changes committed before trying to come up with an all-encompassing > patch set that everyone can agreee on ;-) I certainly don't mean to discourage you. Many of us have been talking about this namespace issue without doing anything about it for a long time. I'm glad someone takes some step. I just want to be sure that the issue is widened beyond stuff for threads so that folks can add to namespace.h in some confidence, just for the purpose of cleaning up the namespace. To this end, I still favor `foo' over `_foo' in library source files (reasons of ugliness and porting). Clearly there is not a simple approach that will cover all cases. sigaction is a bad example -- it doesn't need to be hidden (although it has to be specially handled with threads). kevent is not a great example. Only FreeBSD has kevent currently. However, I don't particularly want `_kevent' littered through library sources. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 7:47:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 5E73937B400 for ; Mon, 22 Jan 2001 07:47:04 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id C61E8193E4; Mon, 22 Jan 2001 09:47:03 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.1/8.9.3) id f0MFl3b93391; Mon, 22 Jan 2001 09:47:03 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Mon, 22 Jan 2001 09:47:03 -0600 From: "Jacques A. Vidrine" To: Bruce Evans Cc: Peter Wemm , Daniel Eischen , arch@FreeBSD.ORG Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r Message-ID: <20010122094703.F93103@hamlet.nectar.com> References: <200101210002.f0L02rk43575@mobile.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bde@zeta.org.au on Mon, Jan 22, 2001 at 09:40:52PM +1100 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 22, 2001 at 09:40:52PM +1100, Bruce Evans wrote: > I think it would be more confusing without the explicit underscores. > The library really does call the underscored versions. To debug it > you need to put breakpoints at the underscored versions... I sympathize with that point of view and indeed it describes how I felt about it at first, before I went src/lib/libc hacking. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 7:48:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id EEB1937B698; Mon, 22 Jan 2001 07:48:37 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 64AB6193E4; Mon, 22 Jan 2001 09:48:37 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.1/8.9.3) id f0MFmbc93398; Mon, 22 Jan 2001 09:48:37 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Mon, 22 Jan 2001 09:48:37 -0600 From: "Jacques A. Vidrine" To: "Brian F. Feldman" Cc: Daniel Eischen , Warner Losh , arch@FreeBSD.org Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r Message-ID: <20010122094837.G93103@hamlet.nectar.com> References: <200101212240.f0LMeSc20272@green.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101212240.f0LMeSc20272@green.dyndns.org>; from green@FreeBSD.org on Sun, Jan 21, 2001 at 05:40:28PM -0500 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 21, 2001 at 05:40:28PM -0500, Brian F. Feldman wrote: > > If it's OK for folks to see and use __foo in libc as opposed > > to _foo, I can make that change. > > It's much too dangerous, I believe, to let libc escape out into the > application's namespace much. In Daniel's proposal, _foo would only be a macro seen in the library source. The external symbols would start with `__', so application namespace pollution is dealt with. IMHO. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 7:51:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id E1BEE37B402; Mon, 22 Jan 2001 07:51:01 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 36333193E4; Mon, 22 Jan 2001 09:51:01 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.1/8.9.3) id f0MFp1g93408; Mon, 22 Jan 2001 09:51:01 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Mon, 22 Jan 2001 09:51:01 -0600 From: "Jacques A. Vidrine" To: Daniel Eischen Cc: "Brian F. Feldman" , Warner Losh , arch@FreeBSD.org Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r Message-ID: <20010122095101.H93103@hamlet.nectar.com> References: <200101212240.f0LMeSc20272@green.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from eischen@vigrid.com on Sun, Jan 21, 2001 at 05:54:48PM -0500 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 21, 2001 at 05:54:48PM -0500, Daniel Eischen wrote: > Remember that this is already possible. Our current syscalls are > _foo with foo being a weak definition to _foo. We currently use > foo all over libc and noone seems to object until now. I've objected, but I was not willing to address the issue without code. I still don't have code, but since you do, I thought I'd add my 2 cents :-) Besides, _foo is not really `all over libc' -- just a few calls here and there. Hiding everything needing to be hidden would cause a lot more _foo, _bar, _baz, to the point of being annoying (IMHO). Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 9: 0:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 05BBC37B69B for ; Mon, 22 Jan 2001 08:59:30 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id BFAE8193E4; Mon, 22 Jan 2001 10:59:28 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.1/8.9.3) id f0MGxS393621; Mon, 22 Jan 2001 10:59:28 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Mon, 22 Jan 2001 10:59:28 -0600 From: "Jacques A. Vidrine" To: Daniel Eischen Cc: arch@freebsd.org Subject: reserved names and names that ought to be hidden in 4.2-STABLE (was Re: Request For Review: libc/libc_r changes to allow -lc_r) Message-ID: <20010122105928.A93570@hamlet.nectar.com> References: <20010120153158.A88123@hamlet.nectar.com> <20010122093043.B93103@hamlet.nectar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010122093043.B93103@hamlet.nectar.com>; from n@nectar.com on Mon, Jan 22, 2001 at 09:30:43AM -0600 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 22, 2001 at 09:30:43AM -0600, Jacques A. Vidrine wrote: > ISO/IEC 9899:1999 lists the reserved names. Any other library > functions should ideally be hidden. Maybe I'll make a list of the > reserved names and post'em. What follows are the reserved function names taken from ISO/IEC 9899:1999, and then a list of symbols found in 4.2-STABLE libc that meet these criteria: = listed by `nm --defined-only -gp' = do not begin with '_' = are not one of the names in the function list There are over 300 of the former, and over 800 of the latter. There were also these. I'm not sure what to make of them. Clearly they cannot be used in C. .cerror .curbrk .mcount .minbrk -- function names from ISO/IEC 9899:1999 -- cacos[fl]? casin[fl]? catan[fl]? ccos[fl]? csin[fl]? ctan[fl]? cacosh[fl]? casinh[fl]? catanh[fl]? ccosh[fl]? csinh[fl]? ctanh[fl]? cexp[fl]? clog[fl]? cabs[fl]? cpow[fl]? csqrt[fl]? carg[fl]? cimag[fl]? conj[fl]? cproj[fl]? creal[fl]? isalnum isalpha isblank iscntrl isdigit isgraph islower isprint ispunct isspace isupper isxdigit tolower toupper errno feclearexcept fegetexceptflag feraiseexcept fesetexceptflag fesetexcept fegetround fesetround fegetenv feholdexcept fesetenv feupdateenv imaxabs imaxdiv strtoimax strtoumax wcstoimax wcstoumax setlocale localeconv fpclassify isfinite isinf isnan isnormal signbit acos[fl]? asin[fl]? atan[fl]? atan2[fl]? cos[fl]? sin[fl]? tan[fl]? acosh[fl]? asinh[fl]? atanh[fl]? cosh[fl]? sinh[fl]? tanh[fl]? exp[fl]? exp2[fl]? expm1[fl]? frexp[fl]? ilogb[fl]? ldexp[fl]? log[fl]? log10[fl]? log1p[fl]? log2[fl]? logb[fl]? modf[fl]? scalbn[fl]? scalbln[fl]? cbrt[fl]? fabs[fl]? hypot[fl]? pow[fl]? sqrt[fl]? erf[fl]? erfc[fl]? lgamma[fl]? tgamma[fl]? ceil[fl]? floor[fl]? nearbyint[fl]? rint[fl]? lrint[fl]? llrint[fl]? round[fl]? lround[fl]? llround[fl]? trunc[fl]? fmod[fl]? remainder[fl]? remquo[fl]? copysign[fl]? nan[fl]? nextafter[fl]? nexttoward[fl]? fdim[fl]? fmax[fl]? fmin[fl]? fma[fl]? isgreater isgreaterequal isless islessequal islessgreater isunordered setjmp longjmp signal raise va_start va_end va_copy va_arg stderr stdin stdout remove rename tmpfile tmpnam fclose fflush fopen freopen setbuf setvbuf fprintf fscanf scanf snprintf sprintf sscanf vfprintf vfscanf vprintf vscanf vsprintf vsnprintf vsscanf fgetc fgets fputc fputs getc getchar gets putc putchar puts ungetc fread fwrite fgetpos fseek ftell fsetpos rewind clearerr feof ferror perror atof ato[il] atoll strto[df] strtold strtol strto[lu]l strtoull rand srand calloc free malloc realloc abort atexit exit getenv system bsearch qsort abs labs llabs div ldiv lldiv mblen mbtowc wctomb mbstowcs wcstombs memcpy memmove strcpy strncpy strcat strncat memcmp strcmp strcoll strncmp strxfrm memchr strchr strcspn strpbrk strrchr strspn strstr strtok memset strerror strlen clock difftime mktime time asctime ctime gmtime localtime strftime fwprintf fwscanf swprintf swscanf vfwprintf vfwscanf vswprintf vswscanf vwprintf vwscanf wprintf wscanf fgetwc fgetws fputwc fputws fwide getwc getwchar putwc putwchar ungetwc wcsto[df] wcstold wcstol wcsto[lu]l wcstoull wcscpy wcsncpy wmemcpy wmemmove wcscat wcsncat wcscmp wcscoll wcsncmp wcsxfrm wmemcmp wcschr wcscspn wcspbrk wcsrchr wcsspn wcsstr wcstok wmemchr wcslen wmemset wcsftime btowc wctob mbrlen mbrtowc wcrtomb mbsrtowcs wcsrtombs iswalnum iswalpha iswblank iswcntrl iswdigit iswgraph iswlower iswprint iswpunct iswspace iswupper iswxdigit iswctype wctype towlower towupper towctrans wctrans -- function names in 4.2-STABLE libc that should be hidden -- accept access acct addr2ascii adjtime aio_cancel aio_error aio_read aio_return aio_suspend aio_waitcomplete aio_write alarm alloca alphasort arc4random arc4random_addrandom arc4random_stir ascii2addr asprintf authdes_create authdes_getucred authdes_pk_create authnone_create authunix_create authunix_create_default basename bcmp bcopy bind bindresvport bindresvport_sa brk bzero callrpc catclose catgets catopen cbc_crypt cfgetispeed cfgetospeed cfmakeraw cfsetispeed cfsetospeed cfsetspeed cgetcap cgetclose cgetent cgetfirst cgetmatch cgetnext cgetnum cgetset cgetstr cgetustr chdir chflags chmod chown chroot clnt_broadcast clnt_create clnt_pcreateerror clnt_perrno clnt_perror clnt_spcreateerror clnt_sperrno clnt_sperror clntraw_create clnttcp_create clntudp_bufcreate clntudp_create clntunix_create close closedir closelog confstr connect creat ctermid ctermid_r daemon dbm_clearerr dbm_close dbm_delete dbm_dirfno dbm_error dbm_fetch dbm_firstkey dbm_nextkey dbm_open dbm_store dbopen des_cipher des_crypt_1 des_setkey des_setparity devname digittoint dirname dladdr dlclose dlerror dllockinit dlopen dlsym dn_comp dn_count_labels dn_expand drand48 dup dup2 ecb_crypt encrypt endfsent endgrent endhostent endnetent endnetgrent endprotoent endpwent endrpcent endservent endttyent endusershell endvfsent erand48 err err_set_exit err_set_file errc errx ether_aton ether_hostton ether_line ether_ntoa ether_ntohost execl execle execlp exect execv execve execvp extattr_delete_file extattr_get_file extattr_set_file extattrctl f_prealloc fchdir fchflags fchmod fchown fcntl fdopen fflagstostr ffs fgetln fgetrune fhopen fhstat fhstatfs fileno flock flockfile fnmatch fork fp_resstat fpathconf fpurge fputrune fstat fstatfs fsync ftok ftruncate ftrylockfile fts_children fts_close fts_open fts_read fts_set fungetrune funlockfile funopen futimes gai_strerror get_myaddress getaddrinfo getbootfile getbsize getdents getdirentries getdiskbyname getdomainname getdtablesize getegid geteuid getfh getfsent getfsfile getfsspec getfsstat getgid getgrent getgrgid getgrnam getgrouplist getgroups gethostbyaddr gethostbyname gethostbyname2 gethostent gethostid gethostname getifaddrs getipnodebyaddr getipnodebyname getitimer getloadavg getlogin getlogin_r getmntinfo getmode getnameinfo getnetbyaddr getnetbyname getnetent getnetgrent getnetname getobjformat getopt getosreldate getpagesize getpass getpeername getpgid getpgrp getpid getppid getpriority getprotobyname getprotobynumber getprotoent getpublicandprivatekey getpublickey getpwent getpwnam getpwuid getresgid getresuid getrlimit getrpcbyname getrpcbynumber getrpcent getrpcport getrusage gettimeofday getttyent getttynam getuid getusershell getvfsbyname getvfsbytype getvfsent getw getwd glob globfree group_from_gid h_errlist h_errno h_nerr hash_create hash_destroy hash_purge hash_search hash_stats hash_traverse hcreate hdestroy heapsort herror host2netname hsearch hstrerror htonl htons i386_clr_watch i386_get_ioperm i386_get_ldt i386_set_ioperm i386_set_ldt i386_set_watch i386_vm86 if_freenameindex if_indextoname if_nameindex if_nametoindex in6addr_any in6addr_linklocal_allnodes in6addr_loopback in6addr_nodelocal_allnodes index inet6_option_alloc inet6_option_append inet6_option_find inet6_option_init inet6_option_next inet6_option_space inet6_rthdr_add inet6_rthdr_getaddr inet6_rthdr_getflags inet6_rthdr_init inet6_rthdr_lasthop inet6_rthdr_segments inet6_rthdr_space inet_addr inet_aton inet_lnaof inet_makeaddr inet_net_ntop inet_net_pton inet_neta inet_netof inet_network inet_nsap_addr inet_nsap_ntoa inet_ntoa inet_ntop inet_pton initgroups initstate innetgr ioctl iruserok iruserok_sa isascii isatty isdialuptty ishexnumber isideogram isnettty isnumber isphonogram isrune issetugid isspecial jail jrand48 kevent key_decryptsession key_decryptsession_pk key_encryptsession key_encryptsession_pk key_gendes key_get_conv key_secretkey_is_set key_setnet key_setsecret kill killpg kldfind kldfirstmod kldload kldnext kldstat kldsym kldunload kqueue ktrace lchmod lchown lcong48 link link_addr link_ntoa lio_listio listen lockf lrand48 lseek lstat lutimes madvise mbmb mbrrune mbrune memccpy mergesort mincore minherit mkdir mkdtemp mkfifo mknod mkstemp mkstemps mktemp mlock mmap modnext modstat moncontrol monstartup mount mpool_close mpool_filter mpool_get mpool_new mpool_open mpool_put mpool_sync mprotect mrand48 msgctl msgget msgrcv msgsnd msgsys msync munlock munmap netbsd_lchown netbsd_msync netname2host netname2user new_getvfsbyname nfssvc nfstat nice nlist nlstat nrand48 ns_addr ns_name_skip ns_ntoa nstat ntohl ntohs ntp_adjtime ntp_gettime offtime open opendir openlog optarg opterr optind optopt optreset p_fqnname p_query p_secstodate paddr pathconf pause pclose pipe pl pmap_getmaps pmap_getport pmap_rmtcall pmap_set pmap_unset poll popen posix2time pread printf profil psignal ptrace putenv putw pwrite quotactl radixsort rcmd rcmd_af read readdir readdir_r readlink readv realpath reboot recv recvfrom recvmsg regcomp regerror regexec regfree registerrpc res_init res_mkquery res_query res_querydomain res_search res_send res_send_setqhook res_send_setrhook res_update revoke rfork rindex rmdir rpc_createerr rpcdata rresvport rresvport_af rtime rtprio ruserok sbrk scandir sched_get_priority_max sched_get_priority_min sched_getparam sched_getscheduler sched_rr_get_interval sched_setparam sched_setscheduler sched_yield seed48 seekdir select semconfig semctl semget semop semsys send sendfile sendmsg sendto set_rpc_maxgrouplist setdomainname setegid setenv seteuid setfsent setgid setgrent setgroupent setgroups sethostent sethostid sethostname setinvalidrune setitimer setkey setlinebuf setlogin setlogmask setmode setnetent setnetgrent setpassent setpgid setpgrp setpriority setproctitle setprotoent setpwent setregid setresgid setresuid setreuid setrgid setrlimit setrpcent setruid setrunelocale setservent setsid setsockopt setstate settimeofday setttyent setuid setusershell setvfsent shm_open shm_unlink shmat shmctl shmdt shmget shmsys shutdown sigaction sigaddset sigaltstack sigblock sigdelset sigemptyset sigfillset siginterrupt sigismember siglongjmp sigpause sigpending sigprocmask sigreturn sigsetjmp sigsetmask sigsuspend sigvec sl_add sl_find sl_free sl_init sleep socket socketpair sradixsort stat statfs strcasecmp strdup strlcat strlcpy strmode strncasecmp strptime strsep strsignal strtoq strtouq strunvis strunvisx strvis strvisx suboptarg svc_auth_reg svc_fdset svc_getreq svc_getreqset svc_getreqset2 svc_maxfd svc_register svc_run svc_sendreply svc_unregister svcerr_auth svcerr_decode svcerr_noproc svcerr_noprog svcerr_progvers svcerr_systemerr svcerr_weakauth svcfd_create svcraw_create svctcp_create svcudp_bufcreate svcudp_create svcudp_enablecache svcunix_create svcunixfd_create swab swapon sym_ntop sym_ntos sym_ston symlink sync sys_errlist sys_nerr sys_nsig sys_siglist sys_signame sysarch syscall sysconf sysctl sysctlbyname syslog tcdrain tcflow tcflush tcgetattr tcgetpgrp tcsendbreak tcsetattr tcsetpgrp tdelete telldir tempnam tfind toascii tsearch ttyname ttyslot twalk tzname tzset tzsetwall ualarm umask uname undelete unlink unmount unsetenv unvis user2netname user_from_uid usleep utime utimes utrace vadvise valloc vasprintf verr verrc verrx vfork vfsisloadable vfsload vis vsyslog vwarn vwarnc vwarnx wait wait3 wait4 waitpid warn warnc warnx write writev xdr_accepted_reply xdr_array xdr_authdes_cred xdr_authdes_verf xdr_authunix_parms xdr_bool xdr_bytes xdr_callhdr xdr_callmsg xdr_char xdr_cryptkeyarg xdr_cryptkeyarg2 xdr_cryptkeyres xdr_datum xdr_des_block xdr_des_dir xdr_des_mode xdr_desargs xdr_desresp xdr_domainname xdr_double xdr_enum xdr_float xdr_free xdr_getcredres xdr_int xdr_int16_t xdr_int32_t xdr_int64_t xdr_key_netstarg xdr_key_netstres xdr_keybuf xdr_keydat xdr_keystatus xdr_long xdr_mapname xdr_netnamestr xdr_netobj xdr_opaque xdr_opaque_auth xdr_peername xdr_pmap xdr_pmaplist xdr_pointer xdr_reference xdr_rejected_reply xdr_replymsg xdr_rmtcall_args xdr_rmtcallres xdr_short xdr_sizeof xdr_string xdr_u_char xdr_u_int xdr_u_int16_t xdr_u_int32_t xdr_u_int64_t xdr_u_long xdr_u_short xdr_union xdr_unixcred xdr_valdat xdr_vector xdr_void xdr_wrapstring xdr_ypbind_binding xdr_ypbind_resp xdr_ypbind_resptype xdr_ypbind_setdom xdr_ypmap_parms xdr_ypmaplist xdr_yppush_status xdr_yppushresp_xfr xdr_ypreq_key xdr_ypreq_nokey xdr_ypreq_xfr xdr_ypreqtype xdr_yprequest xdr_ypresp_all xdr_ypresp_all_seq xdr_ypresp_key_val xdr_ypresp_maplist xdr_ypresp_master xdr_ypresp_order xdr_ypresp_val xdr_ypresp_xfr xdr_ypresponse xdr_ypresptype xdr_ypstat xdr_ypxfrstat xdrmem_create xdrrec_create xdrrec_endofrecord xdrrec_eof xdrrec_skiprecord xdrstdio_create xprt_register xprt_unregister yp_all yp_bind yp_first yp_get_default_domain yp_maplist yp_master yp_match yp_next yp_order yp_unbind ypbinderr_string yperr_string ypprot_err ypresp_allfn ypresp_data -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 9:16:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 7979237B69B; Mon, 22 Jan 2001 09:16:01 -0800 (PST) Received: from newsguy.com (p33-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.98]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id CAA23591; Tue, 23 Jan 2001 02:15:51 +0900 (JST) Message-ID: <3A6C6A34.59D392F@newsguy.com> Date: Tue, 23 Jan 2001 02:13:24 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: "Louis A. Mamakos" Cc: Cameron Grant , Kris Kennaway , arch@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: newpcm/kobj MFC References: <003401c0833c$39ac3f40$1004020a@darkstar> <20010121153904.B74751@citusc17.usc.edu> <200101220104.f0M142O04580@whizzo.transsys.com> <001b01c0840f$b30ea070$1004020a@darkstar> <200101220139.f0M1d1O05133@whizzo.transsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Louis A. Mamakos" wrote: > > > to the best of my knowledge, there exist 5 drivers not in the tree now, all > > of which have kobjified versions available and 4 of which will be entering > > the tree soon. i know of no commercial newpcm drivers. > > Well, there you go. Is changing an unused API an incompatability? Yes, it is... :-( It impacts reputation. OTOH, that has yet to prove a big problem for Linux, for instance. :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@a.crazy.bsdconspiracy.net "There is no spoon." -- Kiki To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 9:43:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id 1933A37B404 for ; Mon, 22 Jan 2001 09:43:33 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.1/8.11.1) id f0MHjmG90245; Mon, 22 Jan 2001 09:45:48 -0800 (PST) (envelope-from kris) Date: Mon, 22 Jan 2001 09:45:48 -0800 From: Kris Kennaway To: "Louis A. Mamakos" Cc: Cameron Grant , arch@FreeBSD.ORG Subject: Re: newpcm/kobj MFC Message-ID: <20010122094548.A90200@citusc17.usc.edu> References: <003401c0833c$39ac3f40$1004020a@darkstar> <20010121153904.B74751@citusc17.usc.edu> <200101220104.f0M142O04580@whizzo.transsys.com> <001b01c0840f$b30ea070$1004020a@darkstar> <200101220139.f0M1d1O05133@whizzo.transsys.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101220139.f0M1d1O05133@whizzo.transsys.com>; from louie@TransSys.COM on Sun, Jan 21, 2001 at 08:39:01PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 21, 2001 at 08:39:01PM -0500, Louis A. Mamakos wrote: > > to the best of my knowledge, there exist 5 drivers not in the tree now,= all > > of which have kobjified versions available and 4 of which will be enter= ing > > the tree soon. i know of no commercial newpcm drivers. >=20 > Well, there you go. Is changing an unused API an incompatability? I'm not going to make a huge fuss over this, but I think it doesn't help the cause to get acceptance from vendors if every few months a maintainer of a part of the tree were to decide to break binary compatability in an exported API in the -stable branch "just this once". Kris --=20 NOTE: To fetch an updated copy of my GPG key which has not expired, finger kris@FreeBSD.org --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6bHHMWry0BWjoQKURAjCHAKCkmhFh5I4SzdB2c4CpIK0Bos4zlACg3Wbd 3pO7mi7tJOdmPcIZaAp/btY= =0r+y -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 10: 3:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id F2A7037B401 for ; Mon, 22 Jan 2001 10:03:03 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 4A667193E4; Mon, 22 Jan 2001 12:03:02 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.1/8.9.3) id f0MI32M93719; Mon, 22 Jan 2001 12:03:02 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Mon, 22 Jan 2001 12:03:02 -0600 From: "Jacques A. Vidrine" To: Daniel Eischen Cc: arch@freebsd.org, jdp@polstra.com Subject: other approach for hiding names (was Re: Request For Review: libc/libc_r changes to allow -lc_r) Message-ID: <20010122120302.A93660@hamlet.nectar.com> References: <20010120153158.A88123@hamlet.nectar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from eischen@vigrid.com on Sat, Jan 20, 2001 at 05:26:26PM -0500 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [I cc'd: jdp directly because he's the person most knowledgeable about linker issues with which I've corresponded. Hope you don't mind, John!] On Sat, Jan 20, 2001 at 05:26:26PM -0500, Daniel Eischen wrote: > Sorry, I don't think that's going to work, especially for > sigaction, flock, and kevent. These cannot be #define'd to > there underscore(_) equivalents because it would also redefine > struct sigaction, struct flock, and struct kevent. I'm beginning to think that the pre-processor is the wrong tool for the job. It can't tell a function or object declaration from other tokens. Is there somewhere in the build process that we could insert a tool that does something like the following? for each externally visible symbol: skip symbol if it is reserved (e.g. '_[A-Z_]') skip symbol if it is not on the ISO C name list [1] if the symbol is defined in this module: rename 'symbol' to '__symbol' add weak reference for 'symbol' -> '__symbol' else (the symbol is an undefined reference): rename 'symbol' to '__symbol' If we had such a thing, then we wouldn't have to phuk around with the preprocessor and maul the source tree. All there would be to maintain would be a list of symbols that we want to be left unmangled (or the converse -- I'm not sure which serves better). Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org [1] Actually this list would probably be all ISO C names + other symbols that require special handling for threads. Or whatever. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 10:19:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id D34C937B402; Mon, 22 Jan 2001 10:19:32 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id E1514193E4; Mon, 22 Jan 2001 12:19:31 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.1/8.9.3) id f0MIJVB95339; Mon, 22 Jan 2001 12:19:31 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Mon, 22 Jan 2001 12:19:31 -0600 From: "Jacques A. Vidrine" To: "Brian F. Feldman" Cc: arch@FreeBSD.org Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r Message-ID: <20010122121931.A95321@hamlet.nectar.com> References: <200101212240.f0LMeSc20272@green.dyndns.org> <20010122094837.G93103@hamlet.nectar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010122094837.G93103@hamlet.nectar.com>; from n@nectar.com on Mon, Jan 22, 2001 at 09:48:37AM -0600 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 22, 2001 at 09:48:37AM -0600, Jacques A. Vidrine wrote: > On Sun, Jan 21, 2001 at 05:40:28PM -0500, Brian F. Feldman wrote: > > > If it's OK for folks to see and use __foo in libc as opposed > > > to _foo, I can make that change. > > > > It's much too dangerous, I believe, to let libc escape out into the > > application's namespace much. > > In Daniel's proposal, _foo would only be a macro seen in the library > source. Oops, needed more coffee. _foo would be a weak reference, not a macro. > The external symbols would start with `__', so application namespace > pollution is dealt with. IMHO. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 11:33:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from VL-MS-MR002.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id 1BD1637B400 for ; Mon, 22 Jan 2001 11:33:27 -0800 (PST) Received: from jehovah ([24.201.144.31]) by VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G7KWZQ01.0PS; Mon, 22 Jan 2001 14:33:26 -0500 Message-ID: <015201c084aa$6c356800$1f90c918@jehovah> From: "Bosko Milekic" To: , "Dag-Erling Smorgrav" References: Subject: Re: Second zone allocator patch Date: Mon, 22 Jan 2001 14:35:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > http://people.freebsd.org/~des/software/vm_zone-20010122.diff > > This replaces the simplelock in vm_zone with a mutex, and adds a > subsystem mutex that must be held when manipulating zlist (which is > now an SLIST). > > Stuff that remains to be done: > > - use atomic operations for updating the statistics counters. Can you get away with grouping the changes to these counters while holding the zlist lock? If so, you can get rid of the necessity for the atomic() ops. > - implement vm_zone_init2() and find the right place to call it from, > to remove the need for zinitna(). > > - make the rest of the VM system thread-safe so we can dispense with ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I can't believe you actually said this publically. :-) Now you're going to have to assume responsability for it. :-P > the Giant hackery in zinitna() and _zget(). > - add a mail reader (accessible through the sysctl interface). Port it to OpenBSD when you're done, and send it to Theo. CC -chat for entertainment purposes. :-) > DES > -- > Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 11:38: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 546E537B402 for ; Mon, 22 Jan 2001 11:37:44 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA40991; Mon, 22 Jan 2001 14:37:36 -0500 (EST) (envelope-from wollman) Date: Mon, 22 Jan 2001 14:37:36 -0500 (EST) From: Garrett Wollman Message-Id: <200101221937.OAA40991@khavrinen.lcs.mit.edu> To: n@nectar.com Cc: arch@freebsd.org Subject: Re: other approach for hiding names (was Re: Request For Review: libc/libc_r changes to allow -lc_r) X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: References: Organization: MIT Laboratory for Computer Science Cc: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >Is there somewhere in the build process that we could insert a tool >that does something like the following? > > for each externally visible symbol: This is not unlike what `crunch' does, so it's not impossible. >[1] Actually this list would probably be all ISO C names + other > symbols that require special handling for threads. Or whatever. Actually, no. The only symbols that need to be hidden are the ones actually used inside libc. There are different levels of hiding necessary; for functions used internal to the implementation of the ISO C standard library, all non-ISO-reserved names must be hidden, but for functions used to implement POSIX libraries, only non-POSIX-reserved names (a much smaller set) must be hidden. Of course, it may be more convenient to just do everything. In no circumstances do we need to hide a function that is used solely as an external interface; the linker will (read: is supposed to) do the Right Thing and resolve program-local references using such names to the program and not the library. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 11:51:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id AD6A937B699 for ; Mon, 22 Jan 2001 11:51:14 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f0MJp8B22505; Mon, 22 Jan 2001 14:51:09 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 22 Jan 2001 14:51:08 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: freebsd-chat@freebsd.org To: Dag-Erling Smorgrav Cc: arch@freebsd.org Subject: Re: Second zone allocator patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22 Jan 2001, Dag-Erling Smorgrav wrote: > - add a mail reader (accessible through the sysctl interface). VMINE -- VM Is Not Elm? VMMAP -- VM Mail Access Protocol Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 12:13: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id F009637B6A6; Mon, 22 Jan 2001 12:12:50 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0MKCns65410; Mon, 22 Jan 2001 13:12:50 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101222012.f0MKCns65410@aslan.scsiguy.com> To: arch@FreeBSD.org Cc: bde@FreeBSD.org Subject: Local driver include files. Date: Mon, 22 Jan 2001 13:12:49 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG When writing core driver code to run on several operating systems, the fact that we use -nostdinc becomes a real pain in the but. Take a look at sys/dev/aic7xxx/aic7xxx.c: #ifdef __linux__ #include "aic7xxx_linux.h" #include "aic7xxx_inline.h" #include "aicasm/aicasm_insformat.h" #endif #ifdef __FreeBSD__ #include #include #include #endif If we provided "-Ipath/to/file/being/compiled" this could be replaced with: #include "aic7xxx_osm.h" #include "aic7xxx_inline.h" #include "aicasm/aicasm_insformat.h" This is a much more scalable approach. I can understand the desire to fully document the path to an include file, but is this really too much to ask? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 12:55:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from net2.gendyn.com (nat2.gendyn.com [204.60.171.12]) by hub.freebsd.org (Postfix) with ESMTP id 1505B37B6A4 for ; Mon, 22 Jan 2001 12:55:17 -0800 (PST) Received: from [153.11.109.12] (helo=fatboy.clc.gdeb.com) by net2.gendyn.com with esmtp (Exim 2.12 #1) id 14Knzb-0004mh-00 for arch@FreeBSD.org; Mon, 22 Jan 2001 15:55:11 -0500 Received: from vigrid.com (localhost [127.0.0.1]) by fatboy.clc.gdeb.com (8.11.0/8.9.3) with ESMTP id f0ML0AO69690; Mon, 22 Jan 2001 16:00:11 -0500 (EST) (envelope-from eischen@vigrid.com) Message-ID: <3A6C9F5A.99083D3@vigrid.com> Date: Mon, 22 Jan 2001 16:00:10 -0500 From: Daniel Eischen X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1.1-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: arch@FreeBSD.org Subject: Final Call: (was Request For Review: libc/libc_r changes to allow -lc_r) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is what I've settled on: __sys_foo - actual syscall _foo - weak definition to __sys_foo foo - weak definition to __sys_foo The latest patches are at: http://people.freebsd.org/~deischen/libc.diffs http://people.freebsd.org/~deischen/libc_r.diffs I'll be committing them sometime within the next couple of days unless there's any other strong objections. This will also force a recompile of all (shared) threaded apps. I imagine the ports team will have a bit of a heartburn over this change as the -pthread linker option will no longer work in -current (separate message to be sent to -ports shortly). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 14:38:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id BA1DF37B6AE for ; Mon, 22 Jan 2001 14:38:06 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id XAA73729; Mon, 22 Jan 2001 23:37:59 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Bosko Milekic" Cc: Subject: Re: Second zone allocator patch References: <015201c084aa$6c356800$1f90c918@jehovah> From: Dag-Erling Smorgrav Date: 22 Jan 2001 23:37:58 +0100 In-Reply-To: "Bosko Milekic"'s message of "Mon, 22 Jan 2001 14:35:05 -0500" Message-ID: Lines: 36 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Bosko Milekic" writes: > Dag-Erling Smorgrav wrote: > > - use atomic operations for updating the statistics counters. > Can you get away with grouping the changes to these counters while > holding the zlist lock? If so, you can get rid of the necessity for the > atomic() ops. Well, right now they're updated inside _zget(), which holds the zone lock, and the zlist lock shouldn't be held while holding the zone lock (it'll cause a lock order reversal if vm_zone_sysctl() runs at the same time). Are atomic operations too expensive? Since these are just statistics, can we get away with leaving them as they are, at the risk of getting incorrect stats once in a while? > > - make the rest of the VM system thread-safe so we can dispense with > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I can't believe you actually said this publically. :-) Now you're going > to have to assume responsability for it. :-P I know, I know. I'm planning to take a long hard look at the kmem system, I'll pass it on to someone else if it proves to be beyond my skills. I've also been asked to implement some kind of zone destructor (which appears to be needed to allow unloading the NFS kld) - it should be simple enough. I'll do that first, right after I a) fix the bugs Bruce pointed out and b) write a man page for the zone allocator. > > the Giant hackery in zinitna() and _zget(). The Giant hackery was not committed, btw - Jason objected. Since the zone allocator still runs under Giant anyway, it shouldn't matter yet. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 14:54:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 9186537B6B0 for ; Mon, 22 Jan 2001 14:54:36 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id XAA73794; Mon, 22 Jan 2001 23:54:30 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Bruce Evans Cc: arch@FreeBSD.ORG Subject: Re: Second zone allocator patch References: From: Dag-Erling Smorgrav Date: 22 Jan 2001 23:54:29 +0100 In-Reply-To: Bruce Evans's message of "Mon, 22 Jan 2001 19:26:55 +1100 (EST)" Message-ID: Lines: 35 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bruce Evans writes: > The simplelock was a spinlock, so changing it to a lock that can sleep > changes the semantics. This seems to be a bug in the ZONE_INTERRUPT > case -- note how the ZONE_INTERRUPT case of _zget() avoids locking > stuff while the !ZONE_INTERRUPT case uses it. OK - how about changing the init code so that if the ZONE_INTERRUPT flag is specified, the lock is initialized as a spin lock? That will require adding a "zmtxtype" or similar member to struct vm_zone. > sysctl_vm_zone() reminds me too much of Linux procfs where the kernel > wastes a lot of time formatting strings. *groan* don't I know it. The advantage it has over linprocfs is that at least it returns all the data in one piece. With procfs and linprocfs, if the reader uses a small read buffer it can end up with gibberish. I'd really love to have session tracking so I could format the data on open (or on first read) and cache it until the end of that session. > It doesn't even provide > any features that aren't implemented in userland like it did originally, > since dillon implemented vmstat -z (except vmstat -z leaves out some > details). But vmstat -z gropes inside the zone allocator's private parts... and currently doesn't work because I wasn't aware of it until an hour ago, and didn't update it. I'd rather update vm_sysctl_conf() to be more like vmstat -z, and then have vmstat -z simply print its output, than teaching vmstat -z how to fondle the zone allocator's privates. That's simply not done in polite company. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 15:14:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from VL-MS-MR001.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id E19B137B6C1 for ; Mon, 22 Jan 2001 15:13:58 -0800 (PST) Received: from jehovah ([24.201.144.31]) by VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G7L76V02.RSC; Mon, 22 Jan 2001 18:13:43 -0500 Message-ID: <008901c084c9$32485cf0$1f90c918@jehovah> From: "Bosko Milekic" To: "Dag-Erling Smorgrav" Cc: References: <015201c084aa$6c356800$1f90c918@jehovah> Subject: Re: Second zone allocator patch Date: Mon, 22 Jan 2001 18:15:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > "Bosko Milekic" writes: > > Dag-Erling Smorgrav wrote: > > > - use atomic operations for updating the statistics counters. > > Can you get away with grouping the changes to these counters while > > holding the zlist lock? If so, you can get rid of the necessity for the > > atomic() ops. > > Well, right now they're updated inside _zget(), which holds the zone > lock, and the zlist lock shouldn't be held while holding the zone lock > (it'll cause a lock order reversal if vm_zone_sysctl() runs at the > same time). Are atomic operations too expensive? Since these are just > statistics, can we get away with leaving them as they are, at the risk > of getting incorrect stats once in a while? Better be correct and use atomic*(), then. [...] > > > the Giant hackery in zinitna() and _zget(). > > The Giant hackery was not committed, btw - Jason objected. Since the > zone allocator still runs under Giant anyway, it shouldn't matter yet. What Giant hackery is this? If this is the KASSERT, that's not "hackery," it's a debugging and prevention aid. > DES > -- > Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 15:52:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id C9C2F37B6DF for ; Mon, 22 Jan 2001 15:51:54 -0800 (PST) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id QAA04354; Mon, 22 Jan 2001 16:46:12 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpdAAADSaisi; Mon Jan 22 16:45:47 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id QAA04791; Mon, 22 Jan 2001 16:51:22 -0700 (MST) From: Terry Lambert Message-Id: <200101222351.QAA04791@usr08.primenet.com> Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r To: imp@harmony.village.org (Warner Losh) Date: Mon, 22 Jan 2001 23:51:22 +0000 (GMT) Cc: eischen@vigrid.com (Daniel Eischen), n@nectar.com (Jacques A. Vidrine), arch@FreeBSD.ORG In-Reply-To: <200101211927.f0LJRU901079@harmony.village.org> from "Warner Losh" at Jan 21, 2001 12:27:30 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : > By the way, should it be __thread_sys_foo and __foo? Two underscores? > : > ISTR some rule about using a single leading underscore for file scope > : > (e.g. macros) and two for global scope. > : > : I don't recall that, but anything for file scope that isn't a macro > : can be static and not use the underscores. Macros are usually upper > : case anyways. > > ANSI C reserves _[A-Z]* and __[a-zA-Z] to the implementation space. > That leaves _[a-z] to the user name space, so Jacques is right about > that. > > I can quote chapter and verse if you really want me to. In the old days, all C cymbols were decorated with a leading underscore by the compiler, and the only space with undecorated functions at all was in assembly. The change-over happened at ELF-time. I'm not positive whether an undecorated symbol was considered to be in the namespace at all; I'm pretty sure it wasn't, since you couldn't write C code that called or was called by an undecorated name. In some ways, life is a lot less pleasent, without the C space being escaped this way. I guess that now the space has been flattened, this becomes an issue. To drag things back on subject, I don't oppose the changes, but I am worried about internal use exposure of functions that have been replaced (e.g. the strdup calling the "wrong" malloc example). One of the things I've seen happening historically on the library front is well-intended people trying to "protect" bad programmers from their own errors (the biggest example of this is the paper that claims core dumping when passing in a NULL instead of a zero length string to some functions, like strcmp). In the grand tradition of foot-shooting being allowed, because it lets you do clever, as well as stupid things, this says to me that all the symbols in the standard library should be weak, to permit their replacement by toe-targeting users. It also says to me that it's a profoundly bad idea to use #define'd things as if they were the symbols themselves, since it may not be the #define'ing header file that provides the function prototype for a replaced C library function provided by a user. So even if the "sigaction" problem _could_ be resolved, it probably _shoudn't_ be (IMO). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 18: 7: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from kyra.unloved.org (kyra.unloved.org [62.58.62.162]) by hub.freebsd.org (Postfix) with ESMTP id 328FD37B400; Mon, 22 Jan 2001 18:06:14 -0800 (PST) Received: by kyra.unloved.org (Postfix) id 13586F431; Tue, 23 Jan 2001 03:06:08 +0100 (CET) Delivered-To: ashp@unloved.org Received: by kyra.unloved.org (Postfix, from userid 0) id 7E839F40E; Tue, 23 Jan 2001 03:06:07 +0100 (CET) To: root@unloved.org Subject: kyra.unloved.org daily run output Message-Id: <20010123020607.7E839F40E@kyra.unloved.org> Date: Tue, 23 Jan 2001 03:06:07 +0100 (CET) From: root@unloved.org (Charlie Root) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Removing stale files from /var/preserve: Cleaning out old system announcements: Removing stale files from /var/rwho: Backup passwd and group files: kyra.unloved.org passwd diffs: 68d67 < orion:(password):2004:2004::0:0:Orion Server:/home/orion:/usr/local/bin/bash 69a69 > postfix:(password):2001:3024::0:0:Postfix Mail System:/nonexistent:/nonexistent kyra.unloved.org group diffs: 93a94 > postfix:*:3024: Verifying group file syntax: Backing up mail aliases: kyra.unloved.org aliases diffs: --- /var/backups/aliases.bak Thu Sep 21 17:28:04 2000 +++ /etc/mail/aliases Mon Jan 22 11:02:55 2001 @@ -1,4 +1,4 @@ -# $FreeBSD: src/etc/mail/aliases,v 1.10.4.1 2000/08/27 17:31:38 gshapiro Exp $ +# $FreeBSD: src/etc/mail/aliases,v 1.10.4.2 2000/12/16 07:03:35 dougb Exp $ # @(#)aliases 5.3 (Berkeley) 5/24/90 # # Aliases in this file will NOT be expanded in the header from @@ -24,8 +24,10 @@ # General redirections for pseudo accounts bin: root +bind: root daemon: root games: root +kmem: root man: root news: root nobody: root @@ -33,6 +35,7 @@ pop: root system: root toor: root +tty: root usenet: news uucp: root xten: root Disk status: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad5s1a 198399 51629 130899 28% / /dev/ad5s2e 9505261 539884 8204957 6% /data /dev/ad5s1f 8473272 2924146 4871265 38% /usr /dev/ad5s1e 992239 18696 894164 2% /var procfs 4 4 0 100% /proc Last dump(s) done (Dump '>' file systems): UUCP status: Network interface status: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll xl0 1500 00:10:4b:09:ec:f0 49045770 0 84287087 4 0 xl0 1500 62.58.62.160/ kyra 49045770 0 84287087 4 0 xl0 1500 jacquie.would jacquie.would.b 49045770 0 84287087 4 0 xl0 1500 my.pussy.gets my.pussy.gets.w 49045770 0 84287087 4 0 xl0 1500 jacquie.loves jacquie.loves.a 49045770 0 84287087 4 0 xl0 1500 twilight.bast twilight.bastar 49045770 0 84287087 4 0 xl0 1500 freebsd.is.be freebsd.is.bett 49045770 0 84287087 4 0 xl0 1500 magic.kablast magic.kablasto. 49045770 0 84287087 4 0 xl0 1500 i.own.decix.n i.own.decix.net 49045770 0 84287087 4 0 xl0 1500 teefers.is.th teefers.is.thra 49045770 0 84287087 4 0 xl0 1500 i.fucked.freu i.fucked.freudi 49045770 0 84287087 4 0 xl0 1500 jacquie.swall jacquie.swallow 49045770 0 84287087 4 0 xl0 1500 unhappy.and/3 unhappy.and 49045770 0 84287087 4 0 xl0 1500 attyz.wants.t attyz.wants.to. 49045770 0 84287087 4 0 xl0 1500 jacquie.is.a. jacquie.is.a.cu 49045770 0 84287087 4 0 xl0 1500 i.am.not.real i.am.not.really 49045770 0 84287087 4 0 xl0 1500 you.need.a.go you.need.a.good 49045770 0 84287087 4 0 xl0 1500 will.never.be will.never.be 49045770 0 84287087 4 0 xl0 1500 vanitywhore.o vanitywhore.org 49045770 0 84287087 4 0 xl0 1500 is.a.masturba is.a.masturbati 49045770 0 84287087 4 0 xl0 1500 works.for.ver works.for.versa 49045770 0 84287087 4 0 xl0 1500 deeply.shallo deeply.shallow. 49045770 0 84287087 4 0 xl0 1500 62.58.48.84/3 62.58.48.84 49045770 0 84287087 4 0 lo0 16384 5114 0 5114 0 0 lo0 16384 127 localhost 5114 0 5114 0 0 Local system status: 3:01AM up 15:55, 1 user, load averages: 0.00, 0.00, 0.00 Mail in local queue: Mail queue is empty Security check: (output mailed separately) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 18: 8:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from kyra.unloved.org (kyra.unloved.org [62.58.62.162]) by hub.freebsd.org (Postfix) with ESMTP id B9C1237B402; Mon, 22 Jan 2001 18:06:15 -0800 (PST) Received: by kyra.unloved.org (Postfix) id E543DF431; Tue, 23 Jan 2001 03:06:14 +0100 (CET) Delivered-To: ashp@unloved.org Received: by kyra.unloved.org (Postfix) via BOUNCE id B6B6FF40E; Tue, 23 Jan 2001 03:06:14 +0100 (CET) Date: Tue, 23 Jan 2001 03:06:14 +0100 (CET) From: MAILER-DAEMON@unloved.org (Mail Delivery System) Subject: Undelivered Mail Returned to Sender To: root@unloved.org MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="13586F431.980215574/kyra.unloved.org" Message-Id: <20010123020614.B6B6FF40E@kyra.unloved.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a MIME-encapsulated message. --13586F431.980215574/kyra.unloved.org Content-Description: Notification Content-Type: text/plain This is the Postfix program at host kyra.unloved.org. I'm sorry to have to inform you that the message returned below could not be delivered to one or more destinations. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the message returned below. The Postfix program <$header_To@unloved.org>: unknown user: "$header_to" <$home/Mail/lists/freebsd-arch@unloved.org>: unknown user: "$home/mail/lists/freebsd-arch" <$home/Mail/lists/bugtraq@unloved.org>: unknown user: "$home/mail/lists/bugtraq" <$home/Mail/lists/freebsd-current@unloved.org>: unknown user: "$home/mail/lists/freebsd-current" <$home/Mail/lists/freebsd-cvs@unloved.org>: unknown user: "$home/mail/lists/freebsd-cvs" <$home/Mail/lists/freebsd-security@unloved.org>: unknown user: "$home/mail/lists/freebsd-security" <$home/Mail/lists/freeciv@unloved.org>: unknown user: "$home/mail/lists/freeciv" <^freeciv-dev@unloved.org>: unknown user: "^freeciv-dev" : unknown user: "contains" : unknown user: "endif" : unknown user: "if" : unknown user: "matches" : unknown user: "or" : unknown user: "save" : unknown user: "then" <$header_sender@unloved.org>: unknown user: "$header_sender" <$header_X-list@unloved.org>: unknown user: "$header_x-list" <$header_Cc@unloved.org>: unknown user: "$header_cc" --13586F431.980215574/kyra.unloved.org Content-Description: Delivery error report Content-Type: message/delivery-status Reporting-MTA: dns; kyra.unloved.org Arrival-Date: Tue, 23 Jan 2001 03:06:08 +0100 (CET) Final-Recipient: rfc822; $header_To@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$header_to" Final-Recipient: rfc822; $home/Mail/lists/freebsd-arch@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/freebsd-arch" Final-Recipient: rfc822; $home/Mail/lists/bugtraq@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/bugtraq" Final-Recipient: rfc822; $home/Mail/lists/freebsd-current@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/freebsd-current" Final-Recipient: rfc822; $home/Mail/lists/freebsd-cvs@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/freebsd-cvs" Final-Recipient: rfc822; $home/Mail/lists/freebsd-security@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/freebsd-security" Final-Recipient: rfc822; $home/Mail/lists/freeciv@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/freeciv" Final-Recipient: rfc822; ^freeciv-dev@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "^freeciv-dev" Final-Recipient: rfc822; contains@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "contains" Final-Recipient: rfc822; endif@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "endif" Final-Recipient: rfc822; if@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "if" Final-Recipient: rfc822; matches@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "matches" Final-Recipient: rfc822; or@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "or" Final-Recipient: rfc822; save@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "save" Final-Recipient: rfc822; then@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "then" Final-Recipient: rfc822; $header_sender@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$header_sender" Final-Recipient: rfc822; $header_X-list@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$header_x-list" Final-Recipient: rfc822; $header_Cc@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$header_cc" --13586F431.980215574/kyra.unloved.org Content-Description: Undelivered Message Content-Type: message/rfc822 Received: by kyra.unloved.org (Postfix) id 13586F431; Tue, 23 Jan 2001 03:06:08 +0100 (CET) Delivered-To: ashp@unloved.org Received: by kyra.unloved.org (Postfix, from userid 0) id 7E839F40E; Tue, 23 Jan 2001 03:06:07 +0100 (CET) To: root@unloved.org Subject: kyra.unloved.org daily run output Message-Id: <20010123020607.7E839F40E@kyra.unloved.org> Date: Tue, 23 Jan 2001 03:06:07 +0100 (CET) From: root@unloved.org (Charlie Root) Removing stale files from /var/preserve: Cleaning out old system announcements: Removing stale files from /var/rwho: Backup passwd and group files: kyra.unloved.org passwd diffs: 68d67 < orion:(password):2004:2004::0:0:Orion Server:/home/orion:/usr/local/bin/bash 69a69 > postfix:(password):2001:3024::0:0:Postfix Mail System:/nonexistent:/nonexistent kyra.unloved.org group diffs: 93a94 > postfix:*:3024: Verifying group file syntax: Backing up mail aliases: kyra.unloved.org aliases diffs: --- /var/backups/aliases.bak Thu Sep 21 17:28:04 2000 +++ /etc/mail/aliases Mon Jan 22 11:02:55 2001 @@ -1,4 +1,4 @@ -# $FreeBSD: src/etc/mail/aliases,v 1.10.4.1 2000/08/27 17:31:38 gshapiro Exp $ +# $FreeBSD: src/etc/mail/aliases,v 1.10.4.2 2000/12/16 07:03:35 dougb Exp $ # @(#)aliases 5.3 (Berkeley) 5/24/90 # # Aliases in this file will NOT be expanded in the header from @@ -24,8 +24,10 @@ # General redirections for pseudo accounts bin: root +bind: root daemon: root games: root +kmem: root man: root news: root nobody: root @@ -33,6 +35,7 @@ pop: root system: root toor: root +tty: root usenet: news uucp: root xten: root Disk status: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad5s1a 198399 51629 130899 28% / /dev/ad5s2e 9505261 539884 8204957 6% /data /dev/ad5s1f 8473272 2924146 4871265 38% /usr /dev/ad5s1e 992239 18696 894164 2% /var procfs 4 4 0 100% /proc Last dump(s) done (Dump '>' file systems): UUCP status: Network interface status: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll xl0 1500 00:10:4b:09:ec:f0 49045770 0 84287087 4 0 xl0 1500 62.58.62.160/ kyra 49045770 0 84287087 4 0 xl0 1500 jacquie.would jacquie.would.b 49045770 0 84287087 4 0 xl0 1500 my.pussy.gets my.pussy.gets.w 49045770 0 84287087 4 0 xl0 1500 jacquie.loves jacquie.loves.a 49045770 0 84287087 4 0 xl0 1500 twilight.bast twilight.bastar 49045770 0 84287087 4 0 xl0 1500 freebsd.is.be freebsd.is.bett 49045770 0 84287087 4 0 xl0 1500 magic.kablast magic.kablasto. 49045770 0 84287087 4 0 xl0 1500 i.own.decix.n i.own.decix.net 49045770 0 84287087 4 0 xl0 1500 teefers.is.th teefers.is.thra 49045770 0 84287087 4 0 xl0 1500 i.fucked.freu i.fucked.freudi 49045770 0 84287087 4 0 xl0 1500 jacquie.swall jacquie.swallow 49045770 0 84287087 4 0 xl0 1500 unhappy.and/3 unhappy.and 49045770 0 84287087 4 0 xl0 1500 attyz.wants.t attyz.wants.to. 49045770 0 84287087 4 0 xl0 1500 jacquie.is.a. jacquie.is.a.cu 49045770 0 84287087 4 0 xl0 1500 i.am.not.real i.am.not.really 49045770 0 84287087 4 0 xl0 1500 you.need.a.go you.need.a.good 49045770 0 84287087 4 0 xl0 1500 will.never.be will.never.be 49045770 0 84287087 4 0 xl0 1500 vanitywhore.o vanitywhore.org 49045770 0 84287087 4 0 xl0 1500 is.a.masturba is.a.masturbati 49045770 0 84287087 4 0 xl0 1500 works.for.ver works.for.versa 49045770 0 84287087 4 0 xl0 1500 deeply.shallo deeply.shallow. 49045770 0 84287087 4 0 xl0 1500 62.58.48.84/3 62.58.48.84 49045770 0 84287087 4 0 lo0 16384 5114 0 5114 0 0 lo0 16384 127 localhost 5114 0 5114 0 0 Local system status: 3:01AM up 15:55, 1 user, load averages: 0.00, 0.00, 0.00 Mail in local queue: Mail queue is empty Security check: (output mailed separately) --13586F431.980215574/kyra.unloved.org-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 18: 8:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from kyra.unloved.org (kyra.unloved.org [62.58.62.162]) by hub.freebsd.org (Postfix) with ESMTP id 5D1C937B404; Mon, 22 Jan 2001 18:06:17 -0800 (PST) Received: by kyra.unloved.org (Postfix) id 71C2CF432; Tue, 23 Jan 2001 03:06:16 +0100 (CET) Delivered-To: ashp@unloved.org Received: by kyra.unloved.org (Postfix) via BOUNCE id 24DA6F40E; Tue, 23 Jan 2001 03:06:16 +0100 (CET) Date: Tue, 23 Jan 2001 03:06:16 +0100 (CET) From: MAILER-DAEMON@unloved.org (Mail Delivery System) Subject: Undelivered Mail Returned to Sender To: root@unloved.org MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="162E6F432.980215576/kyra.unloved.org" Message-Id: <20010123020616.24DA6F40E@kyra.unloved.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a MIME-encapsulated message. --162E6F432.980215576/kyra.unloved.org Content-Description: Notification Content-Type: text/plain This is the Postfix program at host kyra.unloved.org. I'm sorry to have to inform you that the message returned below could not be delivered to one or more destinations. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the message returned below. The Postfix program <$header_Cc@unloved.org>: unknown user: "$header_cc" <$header_sender@unloved.org>: unknown user: "$header_sender" <$home/Mail/lists/bugtraq@unloved.org>: unknown user: "$home/mail/lists/bugtraq" <$home/Mail/lists/freebsd-arch@unloved.org>: unknown user: "$home/mail/lists/freebsd-arch" <$home/Mail/lists/freebsd-current@unloved.org>: unknown user: "$home/mail/lists/freebsd-current" <$home/Mail/lists/freebsd-security@unloved.org>: unknown user: "$home/mail/lists/freebsd-security" <$home/Mail/lists/freeciv@unloved.org>: unknown user: "$home/mail/lists/freeciv" <^freeciv-dev@unloved.org>: unknown user: "^freeciv-dev" : unknown user: "contains" : unknown user: "endif" : unknown user: "if" : unknown user: "matches" : unknown user: "or" : unknown user: "save" : unknown user: "then" <$header_To@unloved.org>: unknown user: "$header_to" <$header_X-list@unloved.org>: unknown user: "$header_x-list" <$home/Mail/lists/freebsd-cvs@unloved.org>: unknown user: "$home/mail/lists/freebsd-cvs" --162E6F432.980215576/kyra.unloved.org Content-Description: Delivery error report Content-Type: message/delivery-status Reporting-MTA: dns; kyra.unloved.org Arrival-Date: Tue, 23 Jan 2001 03:06:08 +0100 (CET) Final-Recipient: rfc822; $header_Cc@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$header_cc" Final-Recipient: rfc822; $header_sender@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$header_sender" Final-Recipient: rfc822; $home/Mail/lists/bugtraq@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/bugtraq" Final-Recipient: rfc822; $home/Mail/lists/freebsd-arch@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/freebsd-arch" Final-Recipient: rfc822; $home/Mail/lists/freebsd-current@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/freebsd-current" Final-Recipient: rfc822; $home/Mail/lists/freebsd-security@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/freebsd-security" Final-Recipient: rfc822; $home/Mail/lists/freeciv@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/freeciv" Final-Recipient: rfc822; ^freeciv-dev@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "^freeciv-dev" Final-Recipient: rfc822; contains@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "contains" Final-Recipient: rfc822; endif@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "endif" Final-Recipient: rfc822; if@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "if" Final-Recipient: rfc822; matches@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "matches" Final-Recipient: rfc822; or@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "or" Final-Recipient: rfc822; save@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "save" Final-Recipient: rfc822; then@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "then" Final-Recipient: rfc822; $header_To@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$header_to" Final-Recipient: rfc822; $header_X-list@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$header_x-list" Final-Recipient: rfc822; $home/Mail/lists/freebsd-cvs@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/freebsd-cvs" --162E6F432.980215576/kyra.unloved.org Content-Description: Undelivered Message Content-Type: message/rfc822 Received: by kyra.unloved.org (Postfix) id 162E6F432; Tue, 23 Jan 2001 03:06:08 +0100 (CET) Delivered-To: ashp@unloved.org Received: by kyra.unloved.org (Postfix, from userid 0) id 1CCE2F40C; Tue, 23 Jan 2001 03:06:07 +0100 (CET) Subject: kyra.unloved.org security check output Message-Id: <20010123020607.1CCE2F40C@kyra.unloved.org> Date: Tue, 23 Jan 2001 03:06:07 +0100 (CET) From: root@unloved.org (Charlie Root) To: undisclosed-recipients: ; Checking setuid files and devices: kyra.unloved.org setuid diffs: 1,54c1,52 < 21616 -r-xr-sr-x 1 root operator 56964 Oct 29 23:03:40 2000 /bin/df < 21532 -r-sr-xr-x 1 root wheel 241844 Oct 29 23:03:44 2000 /bin/rcp < 35919 -r-xr-sr-x 1 root kmem 62800 Oct 29 23:06:25 2000 /sbin/ccdconfig < 35863 -r-xr-sr-x 1 root kmem 69488 Oct 29 23:06:27 2000 /sbin/dmesg < 36290 -r-xr-sr-x 2 root tty 257044 Oct 29 23:06:27 2000 /sbin/dump < 35898 -r-sr-xr-x 1 root wheel 195636 Oct 29 23:06:42 2000 /sbin/ping < 35899 -r-sr-xr-x 1 root bin 190864 Oct 29 23:06:43 2000 /sbin/ping6 < 36290 -r-xr-sr-x 2 root tty 257044 Oct 29 23:06:27 2000 /sbin/rdump < 36041 -r-xr-sr-x 2 root tty 283376 Oct 29 23:06:44 2000 /sbin/restore < 35901 -r-sr-xr-x 1 root wheel 191712 Oct 29 23:06:44 2000 /sbin/route < 36041 -r-xr-sr-x 2 root tty 283376 Oct 29 23:06:44 2000 /sbin/rrestore < 35906 -r-sr-x--- 1 root operator 164524 Oct 29 23:06:46 2000 /sbin/shutdown < 8500 -r-sr-xr-x 4 root wheel 19324 Oct 29 23:07:48 2000 /usr/bin/at < 8500 -r-sr-xr-x 4 root wheel 19324 Oct 29 23:07:48 2000 /usr/bin/atq < 8500 -r-sr-xr-x 4 root wheel 19324 Oct 29 23:07:48 2000 /usr/bin/atrm < 8500 -r-sr-xr-x 4 root wheel 19324 Oct 29 23:07:48 2000 /usr/bin/batch < 8317 -r-sr-xr-x 6 root wheel 31972 Oct 29 23:07:52 2000 /usr/bin/chfn < 8317 -r-sr-xr-x 6 root wheel 31972 Oct 29 23:07:52 2000 /usr/bin/chpass < 8317 -r-sr-xr-x 6 root wheel 31972 Oct 29 23:07:52 2000 /usr/bin/chsh < 8235 -r-sr-xr-x 1 root wheel 23912 Oct 29 23:08:54 2000 /usr/bin/crontab < 8490 -r-sr-sr-x 1 uucp dialer 123456 Oct 29 23:04:16 2000 /usr/bin/cu < 8071 -r-xr-sr-x 1 root kmem 12900 Oct 29 23:08:00 2000 /usr/bin/fstat < 8087 -r-xr-sr-x 1 root kmem 9624 Oct 29 23:08:03 2000 /usr/bin/ipcs < 8026 -r-sr-xr-x 1 root wheel 510 Oct 29 23:08:04 2000 /usr/bin/keyinfo < 8094 -r-sr-xr-x 1 root wheel 7232 Oct 29 23:08:04 2000 /usr/bin/keyinit < 8110 -r-sr-xr-x 1 root wheel 6792 Oct 29 23:08:11 2000 /usr/bin/lock < 8113 -r-sr-xr-x 1 root wheel 19556 Oct 29 23:08:11 2000 /usr/bin/login < 8239 -r-sr-sr-x 1 root daemon 19796 Oct 29 23:09:35 2000 /usr/bin/lpq < 8240 -r-sr-sr-x 1 root daemon 22996 Oct 29 23:09:35 2000 /usr/bin/lpr < 8241 -r-sr-sr-x 1 root daemon 19132 Oct 29 23:09:36 2000 /usr/bin/lprm < 7984 -r-sr-xr-x 1 man wheel 28304 Oct 29 23:04:54 2000 /usr/bin/man < 8136 -r-xr-sr-x 1 root kmem 84736 Oct 29 23:08:16 2000 /usr/bin/netstat < 8138 -r-xr-sr-x 1 root kmem 9660 Oct 29 23:08:16 2000 /usr/bin/nfsstat < 8462 -r-sr-xr-x 2 root wheel 26356 Oct 29 23:08:18 2000 /usr/bin/passwd < 8148 -r-sr-xr-x 1 root wheel 10232 Oct 29 23:08:19 2000 /usr/bin/quota < 8152 -r-sr-xr-x 1 root wheel 9976 Oct 29 23:08:20 2000 /usr/bin/rlogin < 8156 -r-sr-xr-x 1 root wheel 7372 Oct 29 23:08:22 2000 /usr/bin/rsh < 8467 -r-sr-xr-x 2 root wheel 147872 Oct 29 23:10:00 2000 /usr/bin/slogin < 8467 -r-sr-xr-x 2 root wheel 147872 Oct 29 23:10:00 2000 /usr/bin/ssh < 8168 -r-sr-xr-x 1 root wheel 7960 Oct 29 23:08:24 2000 /usr/bin/su < 8171 -r-xr-sr-x 1 root kmem 56648 Oct 29 23:08:25 2000 /usr/bin/systat < 8179 -r-xr-sr-x 1 root kmem 32104 Oct 29 23:08:27 2000 /usr/bin/top < 8489 -r-sr-xr-x 1 uucp wheel 87984 Oct 29 23:04:18 2000 /usr/bin/uucp < 8350 -r-sr-xr-x 1 uucp wheel 37100 Oct 29 23:04:18 2000 /usr/bin/uuname < 8279 -r-sr-sr-x 1 uucp dialer 96540 Oct 29 23:04:19 2000 /usr/bin/uustat < 8274 -r-sr-xr-x 1 uucp wheel 88600 Oct 29 23:04:19 2000 /usr/bin/uux < 8200 -r-xr-sr-x 1 root kmem 16392 Oct 29 23:08:35 2000 /usr/bin/vmstat < 8201 -r-xr-sr-x 1 root tty 8860 Oct 29 23:08:35 2000 /usr/bin/wall < 8208 -r-xr-sr-x 1 root tty 7288 Oct 29 23:08:37 2000 /usr/bin/write < 8317 -r-sr-xr-x 6 root wheel 31972 Oct 29 23:07:52 2000 /usr/bin/ypchfn < 8317 -r-sr-xr-x 6 root wheel 31972 Oct 29 23:07:52 2000 /usr/bin/ypchpass < 8317 -r-sr-xr-x 6 root wheel 31972 Oct 29 23:07:52 2000 /usr/bin/ypchsh < 8462 -r-sr-xr-x 2 root wheel 26356 Oct 29 23:08:18 2000 /usr/bin/yppasswd < 1190465 -r-xr-sr-x 1 root games 6964 Oct 29 23:03:54 2000 /usr/games/dm --- > 21620 -r-xr-sr-x 1 root operator 56892 Jan 22 09:47:23 2001 /bin/df > 21532 -r-sr-xr-x 1 root wheel 241840 Jan 22 09:47:30 2001 /bin/rcp > 35924 -r-xr-sr-x 1 root kmem 62792 Jan 22 09:52:51 2001 /sbin/ccdconfig > 35863 -r-xr-sr-x 1 root kmem 69544 Jan 22 09:52:55 2001 /sbin/dmesg > 36344 -r-xr-sr-x 2 root tty 257100 Jan 22 09:52:56 2001 /sbin/dump > 35898 -r-sr-xr-x 1 root wheel 195660 Jan 22 09:53:19 2001 /sbin/ping > 35899 -r-sr-xr-x 1 root bin 190888 Jan 22 09:53:20 2001 /sbin/ping6 > 36344 -r-xr-sr-x 2 root tty 257100 Jan 22 09:52:56 2001 /sbin/rdump > 36159 -r-xr-sr-x 2 root tty 283372 Jan 22 09:53:22 2001 /sbin/restore > 35901 -r-sr-xr-x 1 root wheel 191736 Jan 22 09:53:23 2001 /sbin/route > 36159 -r-xr-sr-x 2 root tty 283372 Jan 22 09:53:22 2001 /sbin/rrestore > 35906 -r-sr-x--- 1 root operator 164484 Jan 22 09:53:26 2001 /sbin/shutdown > 8383 -r-sr-xr-x 4 root wheel 19540 Jan 22 09:56:32 2001 /usr/bin/at > 8383 -r-sr-xr-x 4 root wheel 19540 Jan 22 09:56:32 2001 /usr/bin/atq > 8383 -r-sr-xr-x 4 root wheel 19540 Jan 22 09:56:32 2001 /usr/bin/atrm > 8383 -r-sr-xr-x 4 root wheel 19540 Jan 22 09:56:32 2001 /usr/bin/batch > 8384 -r-sr-xr-x 6 root wheel 32184 Jan 22 09:56:43 2001 /usr/bin/chfn > 8384 -r-sr-xr-x 6 root wheel 32184 Jan 22 09:56:43 2001 /usr/bin/chpass > 8384 -r-sr-xr-x 6 root wheel 32184 Jan 22 09:56:43 2001 /usr/bin/chsh > 8235 -r-sr-xr-x 1 root wheel 24508 Jan 22 09:58:53 2001 /usr/bin/crontab > 8334 -r-sr-sr-x 1 uucp dialer 123856 Jan 22 09:48:31 2001 /usr/bin/cu > 8071 -r-xr-sr-x 1 root kmem 13108 Jan 22 09:56:58 2001 /usr/bin/fstat > 8087 -r-xr-sr-x 1 root kmem 9832 Jan 22 09:57:07 2001 /usr/bin/ipcs > 8025 -r-sr-xr-x 1 root wheel 510 Jan 22 09:57:09 2001 /usr/bin/keyinfo > 8094 -r-sr-xr-x 1 root wheel 7444 Jan 22 09:57:09 2001 /usr/bin/keyinit > 8110 -r-sr-xr-x 1 root wheel 7004 Jan 22 09:57:21 2001 /usr/bin/lock > 8113 -r-sr-xr-x 1 root wheel 19764 Jan 22 09:57:22 2001 /usr/bin/login > 8239 -r-sr-sr-x 1 root daemon 22728 Jan 22 10:00:25 2001 /usr/bin/lpq > 8240 -r-sr-sr-x 1 root daemon 26312 Jan 22 10:00:26 2001 /usr/bin/lpr > 8241 -r-sr-sr-x 1 root daemon 21612 Jan 22 10:00:27 2001 /usr/bin/lprm > 7984 -r-sr-xr-x 1 man wheel 27872 Jan 22 09:49:48 2001 /usr/bin/man > 8136 -r-xr-sr-x 1 root kmem 85104 Jan 22 09:57:32 2001 /usr/bin/netstat > 8138 -r-xr-sr-x 1 root kmem 9936 Jan 22 09:57:33 2001 /usr/bin/nfsstat > 8439 -r-sr-xr-x 2 root wheel 26564 Jan 22 09:57:39 2001 /usr/bin/passwd > 8148 -r-sr-xr-x 1 root wheel 10440 Jan 22 09:57:42 2001 /usr/bin/quota > 8152 -r-sr-xr-x 1 root wheel 10216 Jan 22 09:57:44 2001 /usr/bin/rlogin > 8156 -r-sr-xr-x 1 root wheel 7584 Jan 22 09:57:46 2001 /usr/bin/rsh > 8168 -r-sr-xr-x 1 root wheel 8168 Jan 22 09:57:53 2001 /usr/bin/su > 8171 -r-xr-sr-x 1 root kmem 56144 Jan 22 09:57:54 2001 /usr/bin/systat > 8179 -r-xr-sr-x 1 root kmem 32344 Jan 22 09:57:58 2001 /usr/bin/top > 8337 -r-sr-xr-x 1 uucp wheel 88228 Jan 22 09:48:33 2001 /usr/bin/uucp > 8340 -r-sr-xr-x 1 uucp wheel 37312 Jan 22 09:48:34 2001 /usr/bin/uuname > 8292 -r-sr-sr-x 1 uucp dialer 96752 Jan 22 09:48:35 2001 /usr/bin/uustat > 8279 -r-sr-xr-x 1 uucp wheel 88844 Jan 22 09:48:35 2001 /usr/bin/uux > 8200 -r-xr-sr-x 1 root kmem 15952 Jan 22 09:58:16 2001 /usr/bin/vmstat > 8201 -r-xr-sr-x 1 root tty 9072 Jan 22 09:58:17 2001 /usr/bin/wall > 8208 -r-xr-sr-x 1 root tty 7500 Jan 22 09:58:21 2001 /usr/bin/write > 8384 -r-sr-xr-x 6 root wheel 32184 Jan 22 09:56:43 2001 /usr/bin/ypchfn > 8384 -r-sr-xr-x 6 root wheel 32184 Jan 22 09:56:43 2001 /usr/bin/ypchpass > 8384 -r-sr-xr-x 6 root wheel 32184 Jan 22 09:56:43 2001 /usr/bin/ypchsh > 8439 -r-sr-xr-x 2 root wheel 26564 Jan 22 09:57:39 2001 /usr/bin/yppasswd > 1190465 -r-xr-sr-x 1 root games 7176 Jan 22 09:47:43 2001 /usr/games/dm 57,58c55,56 < 1190520 -r-sr-sr-x 1 uucp dialer 220460 Oct 29 23:04:16 2000 /usr/libexec/uucp/uucico < 1190524 -r-sr-s--- 1 uucp uucp 99340 Oct 29 23:04:19 2000 /usr/libexec/uucp/uuxqt --- > 1190520 -r-sr-sr-x 1 uucp dialer 220672 Jan 22 09:48:32 2001 /usr/libexec/uucp/uucico > 1190524 -r-sr-s--- 1 uucp uucp 99584 Jan 22 09:48:36 2001 /usr/libexec/uucp/uuxqt 62,74d59 < 1801974 -r-xr-sr-x 1 bin mail 26080 Oct 19 21:40:14 2000 /usr/local/libexec/cucipop < 1024241 -rwxr-sr-x 1 root mailman 16329 Jan 12 13:45:48 2001 /usr/local/mailman/cgi-bin/admin < 1024242 -rwxr-sr-x 1 root mailman 16333 Jan 12 13:45:48 2001 /usr/local/mailman/cgi-bin/admindb < 1024243 -rwxr-sr-x 1 root mailman 16341 Jan 12 13:45:48 2001 /usr/local/mailman/cgi-bin/archives < 1024244 -rwxr-sr-x 1 root mailman 16341 Jan 12 13:45:48 2001 /usr/local/mailman/cgi-bin/edithtml < 1024249 -rwxr-sr-x 1 root mailman 16349 Jan 12 13:45:48 2001 /usr/local/mailman/cgi-bin/handle_opts < 1024246 -rwxr-sr-x 1 root mailman 16341 Jan 12 13:45:48 2001 /usr/local/mailman/cgi-bin/listinfo < 1024245 -rwxr-sr-x 1 root mailman 16333 Jan 12 13:45:48 2001 /usr/local/mailman/cgi-bin/options < 1024250 -rwxr-sr-x 1 root mailman 16333 Jan 12 13:45:48 2001 /usr/local/mailman/cgi-bin/private < 1024248 -rwxr-sr-x 1 root mailman 16329 Jan 12 13:45:48 2001 /usr/local/mailman/cgi-bin/roster < 1024247 -rwxr-sr-x 1 root mailman 16345 Jan 12 13:45:48 2001 /usr/local/mailman/cgi-bin/subscribe < 1064052 -rwxr-sr-x 1 root mailman 16867 Jan 12 13:45:48 2001 /usr/local/mailman/mail/wrapper < 1627111 -rwsr-xr-x 1 root wheel 543149 Dec 23 15:29:16 2000 /usr/local/sbin/exim 76,89c61,75 < 1214251 -r-xr-sr-x 1 root kmem 4456 Oct 29 23:08:59 2000 /usr/sbin/ifmcstat < 1214253 -r-xr-sr-x 1 root kmem 10116 Oct 29 23:08:59 2000 /usr/sbin/iostat < 1214359 -r-xr-sr-x 1 root daemon 26784 Oct 29 23:09:35 2000 /usr/sbin/lpc < 1214276 -r-sr-xr-x 1 root wheel 16136 Oct 29 23:09:04 2000 /usr/sbin/mrinfo < 1214278 -r-sr-xr-x 1 root wheel 29688 Oct 29 23:09:04 2000 /usr/sbin/mtrace < 1214402 -r-sr-xr-- 1 root network 283964 Oct 29 23:09:15 2000 /usr/sbin/ppp < 1214403 -r-sr-xr-x 1 root wheel 96080 Oct 29 23:09:16 2000 /usr/sbin/pppd < 1214629 -r-xr-sr-x 2 root kmem 14368 Oct 29 23:09:17 2000 /usr/sbin/pstat < 1214327 -r-sr-x--- 1 root network 10776 Oct 29 23:09:23 2000 /usr/sbin/sliplogin < 1214629 -r-xr-sr-x 2 root kmem 14368 Oct 29 23:09:17 2000 /usr/sbin/swapinfo < 1214336 -r-sr-xr-x 1 root wheel 14900 Oct 29 23:09:26 2000 /usr/sbin/timedc < 1214337 -r-sr-xr-x 1 root wheel 12956 Oct 29 23:09:26 2000 /usr/sbin/traceroute < 1214338 -r-sr-xr-x 1 root bin 14744 Oct 29 23:09:27 2000 /usr/sbin/traceroute6 < 1214339 -r-xr-sr-x 1 root kmem 7832 Oct 29 23:09:27 2000 /usr/sbin/trpt --- > 1627116 -r-xr-sr-x 1 root maildrop 56904 Jan 22 14:34:20 2001 /usr/local/sbin/postdrop > 1214251 -r-xr-sr-x 1 root kmem 4664 Jan 22 09:59:01 2001 /usr/sbin/ifmcstat > 1214253 -r-xr-sr-x 1 root kmem 9608 Jan 22 09:59:02 2001 /usr/sbin/iostat > 1214359 -r-xr-sr-x 1 root daemon 29204 Jan 22 10:00:24 2001 /usr/sbin/lpc > 1214276 -r-sr-xr-x 1 root wheel 16348 Jan 22 09:59:12 2001 /usr/sbin/mrinfo > 1214278 -r-sr-xr-x 1 root wheel 29896 Jan 22 09:59:13 2001 /usr/sbin/mtrace > 1214402 -r-sr-xr-- 1 root network 294100 Jan 22 09:59:41 2001 /usr/sbin/ppp > 1214403 -r-sr-xr-x 1 root wheel 95612 Jan 22 09:59:42 2001 /usr/sbin/pppd > 1214640 -r-xr-sr-x 2 root kmem 14616 Jan 22 09:59:44 2001 /usr/sbin/pstat > 1214327 -r-sr-x--- 1 root network 11112 Jan 22 09:59:56 2001 /usr/sbin/sliplogin > 1214640 -r-xr-sr-x 2 root kmem 14616 Jan 22 09:59:44 2001 /usr/sbin/swapinfo > 1214336 -r-sr-xr-x 1 root wheel 15112 Jan 22 10:00:05 2001 /usr/sbin/timedc > 1214337 -r-sr-xr-x 1 root wheel 13168 Jan 22 10:00:06 2001 /usr/sbin/traceroute > 1214338 -r-sr-xr-x 1 root bin 14952 Jan 22 10:00:06 2001 /usr/sbin/traceroute6 > 1214339 -r-xr-sr-x 1 root kmem 8040 Jan 22 10:00:06 2001 /usr/sbin/trpt Checking for uids of 0: root 0 toor 0 Checking for passwordless accounts: kyra.unloved.org kernel log messages: > Copyright (c) 1992-2001 The FreeBSD Project. > FreeBSD 4.2-STABLE #0: Sun Jan 21 19:59:44 CET 2001 > ashp@kyra.unloved.org:/usr/obj/usr/src/sys/KYRA > avail memory = 258371584 (252316K bytes) kyra.unloved.org login failures: kyra.unloved.org refused connections: --162E6F432.980215576/kyra.unloved.org-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 19:32:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id 626C837B401; Mon, 22 Jan 2001 19:32:34 -0800 (PST) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id RAA35771; Mon, 22 Jan 2001 17:47:44 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200101230147.RAA35771@beastie.mckusick.com> To: Matt Dillon Subject: Fsck updates for filesystem Cc: Ian Dowse , Alfred Perlstein , Mike Smith , Tony Finch , Terry Lambert , Poul-Henning Kamp , arch@FreeBSD.org In-Reply-To: Your message of "Fri, 19 Jan 2001 13:02:15 PST." <200101192102.f0JL2F698129@earth.backplane.com> Date: Mon, 22 Jan 2001 17:47:44 -0800 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG There have been several suggestions on where to put the hooks for fsck to update a running filesystem: ioctl, mount, fcntl, and sysctl. As several folks pointed out, we are dealing with filesystem incore data, so ioctl is quite inappropriate as it really wants to deal with the underlying disk (the disk knows nothing about the filesystem data structures that are stored on it). Mount is possible, but dubious, because it has such bizzare semantics already which would be tricky to work around and most of which are at best unnecessary for the problem at hand. I lean against fcntl as its current functions are all things that are typically done by normal user programs. It has no kernel administration functions associated with it, and I believe that documenting them in the fcntl manual page will only lead to generally useless bloat in a page intended for relatively naive users. In addition it would be a non-standard extension to a POSIX defined interface. So, I am still of the opinion that sysctl is the right place for these functions. Like many other sysctl's, fsck want to manage kernel state. The correct administrative controls are already in place (checking for root). The framework extends in an obvious place (kern.vfs.ffs. where is one of adjlinkcnt, adjblockcnt, or setblockmap). A final evidence of correctness is that all the needed functionality for the above three functions adds a grand total of 40 lines to the kernel (including three sysctl definitions, comments, and code). Kirk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 19:47:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (unknown [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 6FC3D37B400 for ; Mon, 22 Jan 2001 19:45:57 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0N3jsx38108; Mon, 22 Jan 2001 19:45:54 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f0N3iSv14429; Mon, 22 Jan 2001 19:44:28 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 22 Jan 2001 19:44:28 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Bruce Evans Subject: Re: Second zone allocator patch Cc: arch@FreeBSD.ORG, Dag-Erling Smorgrav Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Jan-01 Bruce Evans wrote: >> http://people.freebsd.org/~des/software/vm_zone-20010122.diff >> >> This replaces the simplelock in vm_zone with a mutex, and adds a >> subsystem mutex that must be held when manipulating zlist (which is >> now an SLIST). > > The simplelock was a spinlock, so changing it to a lock that can sleep > changes the semantics. This seems to be a bug in the ZONE_INTERRUPT > case -- note how the ZONE_INTERRUPT case of _zget() avoids locking > stuff while the !ZONE_INTERRUPT case uses it. Blocking on a mutex is allowed in an interrupt context, just sleeping via a cv, or tsleep/msleep is prohibited, so using a normal mutex should be fine here. Note that it should still not call malloc() to avoid sleeping in the ZONE_INTERRUPT case, however, it should lock in all cases. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 19:51:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id C283737B699 for ; Mon, 22 Jan 2001 19:51:23 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id B70EA6AB70; Tue, 23 Jan 2001 14:21:21 +1030 (CST) Date: Tue, 23 Jan 2001 14:21:21 +1030 From: Greg Lehey To: arch@FreeBSD.org Subject: TAGS target in sys/Makefile? Message-ID: <20010123142121.L414@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG There are a number of tools people can use to find their way around the kernel sources: I know of at least ctags, etags and cscope. It would be nice to have build targets for the corresponding data files in sys/Makefile. I'd suggest adding targets 'tags' for ctags, 'TAGS' for etags, and 'cscope.out' (which just creates the cscope.out file) and 'cscope' (which also runs the program) for cscope. Does anybody have any objections? If not, there are a few odds and ends to tie up, like duplicate labels and machine architectures. I'd omit stuff like the boot code, which doesn't really relate to the kernel, but I don't have a really good idea how to tackle that; possibly ignore the machine-dependent stuff unless an environment variable is set. I'm very much open to suggestions here. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 19:59:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 41BCC37B400; Mon, 22 Jan 2001 19:59:07 -0800 (PST) Received: from localhost (green@localhost [127.0.0.1]) by green.dyndns.org (8.11.1/8.11.1) with ESMTP id f0N3wvW01298; Mon, 22 Jan 2001 22:58:59 -0500 (EST) (envelope-from green@FreeBSD.org) Message-Id: <200101230358.f0N3wvW01298@green.dyndns.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: arch@FreeBSD.org Cc: alfred@FreeBSD.org Subject: struct ucred is evil and must be contained From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Jan 2001 22:58:56 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Okay, maybe the subject is a bit sensationalistic, but the fact remains that ucred has grown into a monster, in the same manner of struct proc, that needs to be carefully contained. In this vain, I've created a struct xucred and replaced uses of ucred outside of the kernel with it where possible. This will also happen to fix the bug that if you screw up your interfaces (change the size of ucred, for example), mountd and nfsd will not panic the kernel because of it. This is a very good thing! Comments? Index: sbin/mountd/mountd.c =================================================================== RCS file: /usr2/ncvs/src/sbin/mountd/mountd.c,v retrieving revision 1.39 diff -u -r1.39 mountd.c --- sbin/mountd/mountd.c 1999/12/03 20:23:53 1.39 +++ sbin/mountd/mountd.c 2001/01/23 00:24:24 @@ -161,9 +161,9 @@ void del_mlist __P((char *, char *)); struct dirlist *dirp_search __P((struct dirlist *, char *)); int do_mount __P((struct exportlist *, struct grouplist *, int, - struct ucred *, char *, int, struct statfs *)); + struct xucred *, char *, int, struct statfs *)); int do_opt __P((char **, char **, struct exportlist *, struct grouplist *, - int *, int *, struct ucred *)); + int *, int *, struct xucred *)); struct exportlist *ex_search __P((fsid_t *)); struct exportlist *get_exp __P((void)); void free_dir __P((struct dirlist *)); @@ -184,7 +184,7 @@ void mntsrv __P((struct svc_req *, SVCXPRT *)); void nextfield __P((char **, char **)); void out_of_mem __P((void)); -void parsecred __P((char *, struct ucred *)); +void parsecred __P((char *, struct xucred *)); int put_exlist __P((struct dirlist *, XDR *, struct dirlist *, int *)); int scan_tree __P((struct dirlist *, u_int32_t)); static void usage __P((void)); @@ -202,8 +202,7 @@ struct mountlist *mlhead; struct grouplist *grphead; char exname[MAXPATHLEN]; -struct ucred def_anon = { - 1, +struct xucred def_anon = { (uid_t) -2, 1, { (gid_t) -2 } @@ -732,7 +731,7 @@ struct dirlist *dirhead; struct statfs fsb, *fsp; struct hostent *hpe; - struct ucred anon; + struct xucred anon; char *cp, *endcp, *dirp, *hst, *usr, *dom, savedc; int len, has_host, exflags, got_nondir, dirplen, num, i, netgrp; @@ -1332,7 +1331,7 @@ struct grouplist *grp; int *has_hostp; int *exflagsp; - struct ucred *cr; + struct xucred *cr; { char *cpoptarg, *cpoptend; char *cp, *endcp, *cpopt, savedc, savedc2; @@ -1591,7 +1590,7 @@ struct exportlist *ep; struct grouplist *grp; int exflags; - struct ucred *anoncrp; + struct xucred *anoncrp; char *dirp; int dirplen; struct statfs *fsb; @@ -1842,7 +1841,7 @@ void parsecred(namelist, cr) char *namelist; - struct ucred *cr; + struct xucred *cr; { char *name; int cnt; @@ -1854,7 +1853,6 @@ /* * Set up the unprivileged user. */ - cr->cr_ref = 1; cr->cr_uid = -2; cr->cr_groups[0] = -2; cr->cr_ngroups = 1; Index: sys/kern/vfs_subr.c =================================================================== RCS file: /usr2/ncvs/src/sys/kern/vfs_subr.c,v retrieving revision 1.298 diff -u -r1.298 vfs_subr.c --- sys/kern/vfs_subr.c 2000/12/15 20:08:19 1.298 +++ sys/kern/vfs_subr.c 2001/01/23 00:52:35 @@ -2314,7 +2314,11 @@ return (EPERM); np = &nep->ne_defexported; np->netc_exflags = argp->ex_flags; - np->netc_anon = argp->ex_anon; + bzero(&np->netc_anon, sizeof(np->netc_anon)); + np->netc_anon.cr_uid = argp->ex_anon.cr_uid; + np->netc_anon.cr_ngroups = argp->ex_anon.cr_ngroups; + bcopy(argp->ex_anon.cr_groups, np->netc_anon.cr_groups, + sizeof(np->netc_anon.cr_groups)); np->netc_anon.cr_ref = 1; mp->mnt_flag |= MNT_DEFEXPORTED; return (0); @@ -2358,7 +2362,11 @@ goto out; } np->netc_exflags = argp->ex_flags; - np->netc_anon = argp->ex_anon; + bzero(&np->netc_anon, sizeof(np->netc_anon)); + np->netc_anon.cr_uid = argp->ex_anon.cr_uid; + np->netc_anon.cr_ngroups = argp->ex_anon.cr_ngroups; + bcopy(argp->ex_anon.cr_groups, np->netc_anon.cr_groups, + sizeof(np->netc_anon.cr_groups)); np->netc_anon.cr_ref = 1; return (0); out: Index: sys/netinet/tcp_subr.c =================================================================== RCS file: /usr2/ncvs/src/sys/netinet/tcp_subr.c,v retrieving revision 1.86 diff -u -r1.86 tcp_subr.c --- sys/netinet/tcp_subr.c 2000/12/24 10:57:21 1.86 +++ sys/netinet/tcp_subr.c 2001/01/23 00:13:00 @@ -893,6 +893,7 @@ static int tcp_getcred(SYSCTL_HANDLER_ARGS) { + struct xucred xuc; struct sockaddr_in addrs[2]; struct inpcb *inp; int error, s; @@ -910,19 +911,25 @@ error = ENOENT; goto out; } - error = SYSCTL_OUT(req, inp->inp_socket->so_cred, sizeof(struct ucred)); + + xuc.cr_uid = inp->inp_socket->so_cred->cr_uid; + xuc.cr_ngroups = inp->inp_socket->so_cred->cr_ngroups; + bcopy(inp->inp_socket->so_cred->cr_groups, xuc.cr_groups, + sizeof(xuc.cr_groups)); + error = SYSCTL_OUT(req, &xuc, sizeof(struct xucred)); out: splx(s); return (error); } SYSCTL_PROC(_net_inet_tcp, OID_AUTO, getcred, CTLTYPE_OPAQUE|CTLFLAG_RW, - 0, 0, tcp_getcred, "S,ucred", "Get the ucred of a TCP connection"); + 0, 0, tcp_getcred, "S,xucred", "Get the xucred of a TCP connection"); #ifdef INET6 static int tcp6_getcred(SYSCTL_HANDLER_ARGS) { + struct xucred xuc; struct sockaddr_in6 addrs[2]; struct inpcb *inp; int error, s, mapped = 0; @@ -956,8 +963,12 @@ error = ENOENT; goto out; } - error = SYSCTL_OUT(req, inp->inp_socket->so_cred, - sizeof(struct ucred)); + + xuc.cr_uid = inp->inp_socket->so_cred->cr_uid; + xuc.cr_ngroups = inp->inp_socket->so_cred->cr_ngroups; + bcopy(inp->inp_socket->so_cred->cr_groups, xuc.cr_groups, + sizeof(xuc.cr_groups)); + error = SYSCTL_OUT(req, &xuc, sizeof(struct xucred)); out: splx(s); return (error); @@ -965,7 +976,7 @@ SYSCTL_PROC(_net_inet6_tcp6, OID_AUTO, getcred, CTLTYPE_OPAQUE|CTLFLAG_RW, 0, 0, - tcp6_getcred, "S,ucred", "Get the ucred of a TCP6 connection"); + tcp6_getcred, "S,xucred", "Get the xucred of a TCP6 connection"); #endif Index: sys/netinet/udp_usrreq.c =================================================================== RCS file: /usr2/ncvs/src/sys/netinet/udp_usrreq.c,v retrieving revision 1.80 diff -u -r1.80 udp_usrreq.c --- sys/netinet/udp_usrreq.c 2000/12/24 10:57:21 1.80 +++ sys/netinet/udp_usrreq.c 2001/01/23 00:13:50 @@ -606,6 +606,7 @@ static int udp_getcred(SYSCTL_HANDLER_ARGS) { + struct xucred xuc; struct sockaddr_in addrs[2]; struct inpcb *inp; int error, s; @@ -623,14 +624,19 @@ error = ENOENT; goto out; } - error = SYSCTL_OUT(req, inp->inp_socket->so_cred, sizeof(struct ucred)); + + xuc.cr_uid = inp->inp_socket->so_cred->cr_uid; + xuc.cr_ngroups = inp->inp_socket->so_cred->cr_ngroups; + bcopy(inp->inp_socket->so_cred->cr_groups, xuc.cr_groups, + sizeof(xuc.cr_groups)); + error = SYSCTL_OUT(req, &xuc, sizeof(struct xucred)); out: splx(s); return (error); } SYSCTL_PROC(_net_inet_udp, OID_AUTO, getcred, CTLTYPE_OPAQUE|CTLFLAG_RW, - 0, 0, udp_getcred, "S,ucred", "Get the ucred of a UDP connection"); + 0, 0, udp_getcred, "S,xucred", "Get the xucred of a UDP connection"); static int udp_output(inp, m, addr, control, p) Index: sys/netinet6/udp6_usrreq.c =================================================================== RCS file: /usr2/ncvs/src/sys/netinet6/udp6_usrreq.c,v retrieving revision 1.13 diff -u -r1.13 udp6_usrreq.c --- sys/netinet6/udp6_usrreq.c 2000/10/23 07:11:01 1.13 +++ sys/netinet6/udp6_usrreq.c 2001/01/23 00:15:16 @@ -474,6 +474,7 @@ static int udp6_getcred(SYSCTL_HANDLER_ARGS) { + struct xucred xuc; struct sockaddr_in6 addrs[2]; struct inpcb *inp; int error, s; @@ -484,7 +485,7 @@ if (req->newlen != sizeof(addrs)) return (EINVAL); - if (req->oldlen != sizeof(struct ucred)) + if (req->oldlen != sizeof(struct xucred)) return (EINVAL); error = SYSCTL_IN(req, addrs, sizeof(addrs)); if (error) @@ -498,9 +499,12 @@ error = ENOENT; goto out; } - error = SYSCTL_OUT(req, inp->inp_socket->so_cred, - sizeof(struct ucred)); + xuc.cr_uid = inp->inp_socket->so_cred->cr_uid; + xuc.cr_ngroups = inp->inp_socket->so_cred->cr_ngroups; + bcopy(inp->inp_socket->so_cred->cr_groups, xuc.cr_groups, + sizeof(xuc.cr_groups)); + error = SYSCTL_OUT(req, &xuc, sizeof(struct xucred)); out: splx(s); return (error); @@ -508,7 +512,7 @@ SYSCTL_PROC(_net_inet6_udp6, OID_AUTO, getcred, CTLTYPE_OPAQUE|CTLFLAG_RW, 0, 0, - udp6_getcred, "S,ucred", "Get the ucred of a UDP6 connection"); + udp6_getcred, "S,xucred", "Get the xucred of a UDP6 connection"); static int udp6_abort(struct socket *so) Index: sys/nfs/nfs.h =================================================================== RCS file: /usr2/ncvs/src/sys/nfs/nfs.h,v retrieving revision 1.56 diff -u -r1.56 nfs.h --- sys/nfs/nfs.h 2000/10/24 10:13:36 1.56 +++ sys/nfs/nfs.h 2001/01/23 00:28:27 @@ -197,7 +197,7 @@ struct nfsd *nsd_nfsd; /* Pointer to in kernel nfsd struct */ uid_t nsd_uid; /* Effective uid mapped to cred */ u_int32_t nsd_haddr; /* Ip address of client */ - struct ucred nsd_cr; /* Cred. uid maps to */ + struct xucred nsd_cr; /* Cred. uid maps to */ int nsd_authlen; /* Length of auth string (ret) */ u_char *nsd_authstr; /* Auth string (ret) */ int nsd_verflen; /* and the verfier */ Index: sys/nfs/nfs_syscalls.c =================================================================== RCS file: /usr2/ncvs/src/sys/nfs/nfs_syscalls.c,v retrieving revision 1.64 diff -u -r1.64 nfs_syscalls.c --- sys/nfs/nfs_syscalls.c 2000/12/21 21:44:24 1.64 +++ sys/nfs/nfs_syscalls.c 2001/01/23 00:48:56 @@ -244,7 +244,7 @@ slp->ns_numuids++; nuidp = (struct nfsuid *) malloc(sizeof (struct nfsuid), M_NFSUID, - M_WAITOK); + M_WAITOK | M_ZERO); } else nuidp = (struct nfsuid *)0; if ((slp->ns_flag & SLP_VALID) == 0) { @@ -260,7 +260,12 @@ FREE(nuidp->nu_nam, M_SONAME); } nuidp->nu_flag = 0; - nuidp->nu_cr = nsd->nsd_cr; + nuidp->nu_cr.cr_uid = nsd->nsd_cr.cr_uid; + nuidp->nu_cr.cr_ngroups = + nsd->nsd_cr.cr_ngroups; + bcopy(nsd->nsd_cr.cr_groups, + nuidp->nu_cr.cr_groups, + sizeof(nuidp->nu_cr.cr_groups)); if (nuidp->nu_cr.cr_ngroups > NGROUPS) nuidp->nu_cr.cr_ngroups = NGROUPS; nuidp->nu_cr.cr_ref = 1; Index: sys/sys/mount.h =================================================================== RCS file: /usr2/ncvs/src/sys/sys/mount.h,v retrieving revision 1.99 diff -u -r1.99 mount.h --- sys/sys/mount.h 2000/12/04 09:21:05 1.99 +++ sys/sys/mount.h 2001/01/23 00:32:10 @@ -245,11 +245,11 @@ struct export_args { int ex_flags; /* export related flags */ uid_t ex_root; /* mapping for root uid */ - struct ucred ex_anon; /* mapping for anonymous user */ + struct xucred ex_anon; /* mapping for anonymous user */ struct sockaddr *ex_addr; /* net address to which exported */ - int ex_addrlen; /* and the net address length */ + u_char ex_addrlen; /* and the net address length */ struct sockaddr *ex_mask; /* mask of valid bits in saddr */ - int ex_masklen; /* and the smask length */ + u_char ex_masklen; /* and the smask length */ char *ex_indexfile; /* index file for WebNFS URLs */ }; Index: sys/sys/ucred.h =================================================================== RCS file: /usr2/ncvs/src/sys/sys/ucred.h,v retrieving revision 1.19 diff -u -r1.19 ucred.h --- sys/sys/ucred.h 2000/11/30 19:09:47 1.19 +++ sys/sys/ucred.h 2001/01/23 00:25:53 @@ -37,6 +37,7 @@ #ifndef _SYS_UCRED_H_ #define _SYS_UCRED_H_ +#ifdef _KERNEL #include /* @@ -53,9 +54,19 @@ struct uidinfo *cr_uidinfo; /* per uid resource consumption */ struct mtx cr_mtx; /* protect refcount */ }; -#define cr_gid cr_groups[0] #define NOCRED ((struct ucred *)0) /* no credential available */ #define FSCRED ((struct ucred *)-1) /* filesystem credential */ +#endif + +/* + * This is the external representation of struct ucred which "won't change". + */ +struct xucred { + uid_t cr_uid; /* effective user id */ + short cr_ngroups; /* number of groups */ + gid_t cr_groups[NGROUPS]; /* groups */ +}; +#define cr_gid cr_groups[0] #ifdef _KERNEL Index: usr.sbin/inetd/builtins.c =================================================================== RCS file: /usr2/ncvs/src/usr.sbin/inetd/builtins.c,v retrieving revision 1.29 diff -u -r1.29 builtins.c --- usr.sbin/inetd/builtins.c 2000/12/05 13:56:01 1.29 +++ usr.sbin/inetd/builtins.c 2001/01/22 23:54:26 @@ -338,7 +338,7 @@ struct sockaddr_in6 sin6[2]; #endif struct sockaddr_storage ss[2]; - struct ucred uc; + struct xucred uc; struct timeval tv = { 10, 0 Index: usr.sbin/pstat/pstat.c =================================================================== RCS file: /usr2/ncvs/src/usr.sbin/pstat/pstat.c,v retrieving revision 1.52 diff -u -r1.52 pstat.c --- usr.sbin/pstat/pstat.c 2000/12/30 15:41:40 1.52 +++ usr.sbin/pstat/pstat.c 2001/01/23 00:32:34 @@ -48,8 +48,8 @@ #include #include #include -#include #define _KERNEL +#include #include #include #include -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 20: 7:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id E9B9D37B400; Mon, 22 Jan 2001 20:07:06 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0N4MTG01012; Mon, 22 Jan 2001 20:22:29 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101230422.f0N4MTG01012@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Brian F. Feldman" Cc: arch@FreeBSD.org, alfred@FreeBSD.org Subject: Re: struct ucred is evil and must be contained In-reply-to: Your message of "Mon, 22 Jan 2001 22:58:56 EST." <200101230358.f0N3wvW01298@green.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Jan 2001 20:22:29 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Okay, maybe the subject is a bit sensationalistic, but the fact remains that > ucred has grown into a monster, in the same manner of struct proc, that > needs to be carefully contained. In this vain, I've created a struct xucred > and replaced uses of ucred outside of the kernel with it where possible. > > This will also happen to fix the bug that if you screw up your interfaces > (change the size of ucred, for example), mountd and nfsd will not panic the > kernel because of it. This is a very good thing! Comments? #ifdef _KERNEL struct xucred { #else struct ucred { #endif The struct must be known as "ucred" in userspace to maintain compatibility with the old interfaces. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 20:28:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 7D7A137B400; Mon, 22 Jan 2001 20:28:13 -0800 (PST) Received: from localhost (green@localhost [127.0.0.1]) by green.dyndns.org (8.11.1/8.11.1) with ESMTP id f0N4SBW01468; Mon, 22 Jan 2001 23:28:12 -0500 (EST) (envelope-from green@FreeBSD.org) Message-Id: <200101230428.f0N4SBW01468@green.dyndns.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Mike Smith Cc: arch@FreeBSD.org Subject: Re: struct ucred is evil and must be contained In-Reply-To: Message from Mike Smith of "Mon, 22 Jan 2001 20:22:29 PST." <200101230422.f0N4MTG01012@mass.dis.org> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Jan 2001 23:28:11 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: > > Okay, maybe the subject is a bit sensationalistic, but the fact remains that > > ucred has grown into a monster, in the same manner of struct proc, that > > needs to be carefully contained. In this vain, I've created a struct xucred > > and replaced uses of ucred outside of the kernel with it where possible. > > > > This will also happen to fix the bug that if you screw up your interfaces > > (change the size of ucred, for example), mountd and nfsd will not panic the > > kernel because of it. This is a very good thing! Comments? > > #ifdef _KERNEL > struct xucred { > #else > struct ucred { > #endif > > The struct must be known as "ucred" in userspace to maintain > compatibility with the old interfaces. But it isn't compatible, necessarily, so it probably really should be changed. This is how it's done with e.g. xsocket, and the new proc interface doesn't use plain "proc" either. Is there a good reason to not change the name but still change the API? -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 20:36:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 79E3237B401; Mon, 22 Jan 2001 20:36:06 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0N4pSG01102; Mon, 22 Jan 2001 20:51:28 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101230451.f0N4pSG01102@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Brian F. Feldman" Cc: arch@FreeBSD.org Subject: Re: struct ucred is evil and must be contained In-reply-to: Your message of "Mon, 22 Jan 2001 23:28:11 EST." <200101230428.f0N4SBW01468@green.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Jan 2001 20:51:28 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The struct must be known as "ucred" in userspace to maintain > > compatibility with the old interfaces. > > But it isn't compatible, necessarily, so it probably really should be > changed. This is how it's done with e.g. xsocket, and the new proc > interface doesn't use plain "proc" either. Is there a good reason to not > change the name but still change the API? Only as far as I can tell because ucred is assumed to exist by software other than just the system, so whilst 'proc' and 'socket' were only ever exported for Bad and Evil reasons, ucred has been consumed because it's part of documented kernel interfaces. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 20:40:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 34F2A37B401; Mon, 22 Jan 2001 20:40:28 -0800 (PST) Received: by relay.butya.kz (Postfix, from userid 1000) id A1D5A288CB; Tue, 23 Jan 2001 10:40:21 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 95C0F28872; Tue, 23 Jan 2001 10:40:21 +0600 (ALMT) Date: Tue, 23 Jan 2001 10:40:21 +0600 (ALMT) From: Boris Popov To: Kris Kennaway Cc: "Louis A. Mamakos" , Cameron Grant , arch@FreeBSD.ORG Subject: Re: newpcm/kobj MFC In-Reply-To: <20010122094548.A90200@citusc17.usc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 22 Jan 2001, Kris Kennaway wrote: > On Sun, Jan 21, 2001 at 08:39:01PM -0500, Louis A. Mamakos wrote: > > > Well, there you go. Is changing an unused API an incompatability? > > I'm not going to make a huge fuss over this, but I think it doesn't > help the cause to get acceptance from vendors if every few months a > maintainer of a part of the tree were to decide to break binary > compatability in an exported API in the -stable branch "just this > once". On other hand, I'm welcome MFCing of kobj. This probably should be done even before 4.1.1... -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 22:52:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id D430337B402; Mon, 22 Jan 2001 22:52:24 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14KxQr-0000Kb-00; Mon, 22 Jan 2001 23:59:57 -0700 Message-ID: <3A6D2BED.66CA8268@softweyr.com> Date: Mon, 22 Jan 2001 23:59:57 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Justin T. Gibbs" Cc: arch@FreeBSD.org, bde@FreeBSD.org Subject: Re: Local driver include files. References: <200101222012.f0MKCns65410@aslan.scsiguy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Justin T. Gibbs" wrote: > > When writing core driver code to run on several operating systems, > the fact that we use -nostdinc becomes a real pain in the but. > Take a look at sys/dev/aic7xxx/aic7xxx.c: > > #ifdef __linux__ > #include "aic7xxx_linux.h" > #include "aic7xxx_inline.h" > #include "aicasm/aicasm_insformat.h" > #endif > > #ifdef __FreeBSD__ > #include > #include > #include > #endif > > If we provided "-Ipath/to/file/being/compiled" this could > be replaced with: > > #include "aic7xxx_osm.h" > #include "aic7xxx_inline.h" > #include "aicasm/aicasm_insformat.h" > > This is a much more scalable approach. > > I can understand the desire to fully document the path to > an include file, but is this really too much to ask? No, it's not. What does that have to do with -nostdinc? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 22 23:48: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id D56E337B400; Mon, 22 Jan 2001 23:47:42 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA29250; Tue, 23 Jan 2001 18:47:35 +1100 Date: Tue, 23 Jan 2001 18:47:28 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: "Justin T. Gibbs" Cc: arch@FreeBSD.org, bde@FreeBSD.org Subject: Re: Local driver include files. In-Reply-To: <200101222012.f0MKCns65410@aslan.scsiguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 22 Jan 2001, Justin T. Gibbs wrote: > When writing core driver code to run on several operating systems, > the fact that we use -nostdinc becomes a real pain in the but. > Take a look at sys/dev/aic7xxx/aic7xxx.c: > > #ifdef __linux__ > #include "aic7xxx_linux.h" > #include "aic7xxx_inline.h" > #include "aicasm/aicasm_insformat.h" > #endif > > #ifdef __FreeBSD__ > #include > #include > #include > #endif > > If we provided "-Ipath/to/file/being/compiled" this could > be replaced with: > > #include "aic7xxx_osm.h" > #include "aic7xxx_inline.h" > #include "aicasm/aicasm_insformat.h" > > This is a much more scalable approach. Except the size of the Makefile and most command lines generated by it is O(number of path/to/file/being/compiled). > I can understand the desire to fully document the path to > an include file, but is this really too much to ask? We attempt to enforce using full paths relative to $S to avoid ambiguities. This was mainly to avoid ambiguities for paths with no slashes in them. Ambiguities for other paths are less likely. They are probably most likely for alternative versions of drivers. BTW, the -current kernel Makefiles have already been hacked to add -I$S/dev (not to mention -I$S/contrib/dev/acpica/Subsystem/Include) to CFLAGS, so you don't need the above ifdefs in -current. You still need them in RELENG[3-4]. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 0:13:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 8CCB237B401; Tue, 23 Jan 2001 00:13:39 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0N8DdX18914; Tue, 23 Jan 2001 00:13:39 -0800 (PST) Date: Tue, 23 Jan 2001 00:13:39 -0800 From: Alfred Perlstein To: "Brian F. Feldman" Cc: arch@FreeBSD.ORG Subject: Re: struct ucred is evil and must be contained Message-ID: <20010123001339.L26076@fw.wintelcom.net> References: <200101230358.f0N3wvW01298@green.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101230358.f0N3wvW01298@green.dyndns.org>; from green@FreeBSD.ORG on Mon, Jan 22, 2001 at 10:58:56PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Brian F. Feldman [010122 19:59] wrote: > Okay, maybe the subject is a bit sensationalistic, but the fact remains that > ucred has grown into a monster, in the same manner of struct proc, that > needs to be carefully contained. In this vain, I've created a struct xucred > and replaced uses of ucred outside of the kernel with it where possible. > > This will also happen to fix the bug that if you screw up your interfaces > (change the size of ucred, for example), mountd and nfsd will not panic the > kernel because of it. This is a very good thing! Comments? As long as it doesn't break world, it looks good. :) Thanks for taking the time to do this. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 2: 3:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from roaming.cacheboy.net (roaming.cacheboy.net [203.56.168.69]) by hub.freebsd.org (Postfix) with ESMTP id F173F37B6A3 for ; Tue, 23 Jan 2001 02:02:55 -0800 (PST) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.1/8.11.1) id f0NA2ou01449; Tue, 23 Jan 2001 11:02:50 +0100 (CET) (envelope-from adrian) Date: Tue, 23 Jan 2001 11:02:50 +0100 From: Adrian Chadd To: Dag-Erling Smorgrav Cc: freebsd-arch@freebsd.org Subject: Re: Second zone allocator patch Message-ID: <20010123110249.C226@roaming.cacheboy.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Mon, Jan 22, 2001 at 11:54:29PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 22, 2001, Dag-Erling Smorgrav wrote: > *groan* don't I know it. The advantage it has over linprocfs is that > at least it returns all the data in one piece. With procfs and > linprocfs, if the reader uses a small read buffer it can end up with > gibberish. I'd really love to have session tracking so I could format > the data on open (or on first read) and cache it until the end of that > session. I've been looking at that for a revamp of procfs using sbufs. Basically, it'd be nice to be able to attach the sbuf to the file struct and abuse that as "local state". If people have ideas about session tracking, I'm all ears. It'd also help me implement some synthetic filesystems I'm having to do right now .. :) Adrian -- Adrian Chadd "Programming is like sex: One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 2:18:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id DE29D37B402 for ; Tue, 23 Jan 2001 02:18:06 -0800 (PST) Received: (qmail 3427 invoked by uid 1000); 23 Jan 2001 10:16:37 -0000 Date: Tue, 23 Jan 2001 12:16:37 +0200 From: Peter Pentchev To: Garrett Wollman Cc: freebsd-bugs@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: bin/24540: add '-c' flag to src/bin/domainname to clear domainname Message-ID: <20010123121637.E2376@ringworld.oblivion.bg> Mail-Followup-To: Garrett Wollman , freebsd-bugs@FreeBSD.org, freebsd-arch@FreeBSD.org References: <200101222010.f0MKA2185498@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101222010.f0MKA2185498@freefall.freebsd.org>; from wollman@khavrinen.lcs.mit.edu on Mon, Jan 22, 2001 at 12:10:02PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 22, 2001 at 12:10:02PM -0800, Garrett Wollman wrote: > The following reply was made to PR bin/24540; it has been noted by GNATS. > > From: Garrett Wollman > To: Pete Fritchman > Cc: freebsd-gnats-submit@FreeBSD.ORG, phk@FreeBSD.ORG > Subject: Re: bin/24540: add '-c' flag to src/bin/domainname to clear domainname > Date: Mon, 22 Jan 2001 15:02:57 -0500 (EST) > > < said: > > > electron# ./domainname foo.bar > > electron# ./domainname '' > > electron# ./domainname > > foo.bar > > I think this is a bug in sysctl. Note the following: > > root@khavrinen(6)# sysctl -w kern.domainname='' > kern.domainname: foo.bar -> foo.bar > > What is happening is that the sysctl() system call is interpreting the > request to set the MIB variable to a zero-length object as if it were > an indication that setting is not requested. Here is an (untested) > fix (beware cut&paste has bogotified whitespace): > > > > --- kern_sysctl.c 2000/07/28 22:40:04 1.100 > +++ kern_sysctl.c 2001/01/22 20:01:38 > @@ -862,7 +862,7 @@ > req.oldptr= old; > } > > - if (newlen) { > + if (new) { > req.newlen = newlen; > req.newptr = new; > } > @@ -1101,7 +1101,7 @@ > req.oldptr= old; > } > > - if (newlen) { > + if (new) { > if (!useracc(new, req.newlen, VM_PROT_READ)) > return (EFAULT); > req.newlen = newlen; > > -GAWollman This works for me; still, how about changing the test to if (newlen || (new != NULL)) in both places? I have a -current system which has been running fine for three hours now with this fix, and there have been no signs of breakage (there shouldn't be, unless somewhere someone passes uninit'd values to new or newval). -arch CC'd because of the proposed kern_sysctl change :) G'luck, Peter -- Nostalgia ain't what it used to be. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 4:53:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 3403137B400; Tue, 23 Jan 2001 04:53:21 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA16808; Tue, 23 Jan 2001 23:53:17 +1100 Date: Tue, 23 Jan 2001 23:53:10 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: arch@FreeBSD.ORG, Dag-Erling Smorgrav Subject: Re: Second zone allocator patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 22 Jan 2001, John Baldwin wrote: > On 22-Jan-01 Bruce Evans wrote: > >> http://people.freebsd.org/~des/software/vm_zone-20010122.diff > >> > >> This replaces the simplelock in vm_zone with a mutex, and adds a > >> subsystem mutex that must be held when manipulating zlist (which is > >> now an SLIST). > > > > The simplelock was a spinlock, so changing it to a lock that can sleep > > changes the semantics. This seems to be a bug in the ZONE_INTERRUPT > > case -- note how the ZONE_INTERRUPT case of _zget() avoids locking > > stuff while the !ZONE_INTERRUPT case uses it. > > Blocking on a mutex is allowed in an interrupt context, just sleeping via a cv, > or tsleep/msleep is prohibited, so using a normal mutex should be fine here. > Note that it should still not call malloc() to avoid sleeping in the > ZONE_INTERRUPT case, however, it should lock in all cases. I meant "sleep" to mean "give up control". The difference is almost irrelevant here anyway. If the lock is held, mtx_enter() has to give up control to run the thread that is holding the lock, so that that thread can release the lock. That thread may also modify state which the original thread "knows" will not be modified because it is doing a non-blocking zalloc() or malloc() (the problem is more obvious for malloc() because the no-block flag M_NOWAIT is explicit). I think this means that non-blocking [mz]alloc()'s shouldn't exist in SMP systems. They would have to use spinlocks to work at all, but spinlocks should be avoided if possible. However, they should use spinlocks for now, so that we don't have to worry about them when pushing down the Giant lock. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 8:15:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id CFC4D37B6A3; Tue, 23 Jan 2001 08:15:03 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0NGF1s81841; Tue, 23 Jan 2001 09:15:01 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101231615.f0NGF1s81841@aslan.scsiguy.com> To: Wes Peters Cc: arch@FreeBSD.org, bde@FreeBSD.org Subject: Re: Local driver include files. In-Reply-To: Your message of "Mon, 22 Jan 2001 23:59:57 MST." <3A6D2BED.66CA8268@softweyr.com> Date: Tue, 23 Jan 2001 09:15:01 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >No, it's not. What does that have to do with -nostdinc? Its actually -I-. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 9:32:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 941A337B401; Tue, 23 Jan 2001 09:32:02 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0NHVns82856; Tue, 23 Jan 2001 10:31:54 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101231731.f0NHVns82856@aslan.scsiguy.com> To: Bruce Evans Cc: arch@FreeBSD.org, bde@FreeBSD.org Subject: Re: Local driver include files. In-Reply-To: Your message of "Tue, 23 Jan 2001 18:47:28 +1100." Date: Tue, 23 Jan 2001 10:31:49 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> This is a much more scalable approach. > >Except the size of the Makefile and most command lines generated by >it is O(number of path/to/file/being/compiled). Really? It seems that this does what I need: INCLUDES= -nostdinc -I- -I. -I$S -I${<:H} Perhaps that is too simplistic? >BTW, the -current kernel Makefiles have already been hacked to add >-I$S/dev (not to mention -I$S/contrib/dev/acpica/Subsystem/Include) >to CFLAGS, so you don't need the above ifdefs in -current. You still >need them in RELENG[3-4]. I would have to use "aic7xxx/filename.h" which still forces the aic7xxx driver to be in a particular location in the source tree on all supported platforms. I'm not positive I can get that. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 10:22:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id CC2A637B698; Tue, 23 Jan 2001 10:22:34 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0NIMWk03583; Tue, 23 Jan 2001 10:22:32 -0800 (PST) Date: Tue, 23 Jan 2001 10:22:32 -0800 From: Alfred Perlstein To: Bruce Evans Cc: John Baldwin , arch@FreeBSD.ORG, Dag-Erling Smorgrav Subject: Re: Second zone allocator patch Message-ID: <20010123102231.Q26076@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bde@zeta.org.au on Tue, Jan 23, 2001 at 11:53:10PM +1100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Bruce Evans [010123 04:53] wrote: > On Mon, 22 Jan 2001, John Baldwin wrote: > > > On 22-Jan-01 Bruce Evans wrote: > > >> http://people.freebsd.org/~des/software/vm_zone-20010122.diff > > >> > > >> This replaces the simplelock in vm_zone with a mutex, and adds a > > >> subsystem mutex that must be held when manipulating zlist (which is > > >> now an SLIST). > > > > > > The simplelock was a spinlock, so changing it to a lock that can sleep > > > changes the semantics. This seems to be a bug in the ZONE_INTERRUPT > > > case -- note how the ZONE_INTERRUPT case of _zget() avoids locking > > > stuff while the !ZONE_INTERRUPT case uses it. > > > > Blocking on a mutex is allowed in an interrupt context, just sleeping via a cv, > > or tsleep/msleep is prohibited, so using a normal mutex should be fine here. > > Note that it should still not call malloc() to avoid sleeping in the > > ZONE_INTERRUPT case, however, it should lock in all cases. > > I meant "sleep" to mean "give up control". The difference is almost > irrelevant here anyway. If the lock is held, mtx_enter() has to give > up control to run the thread that is holding the lock, so that that > thread can release the lock. That thread may also modify state which > the original thread "knows" will not be modified because it is doing > a non-blocking zalloc() or malloc() (the problem is more obvious for > malloc() because the no-block flag M_NOWAIT is explicit). > > I think this means that non-blocking [mz]alloc()'s shouldn't exist in > SMP systems. They would have to use spinlocks to work at all, but > spinlocks should be avoided if possible. However, they should use > spinlocks for now, so that we don't have to worry about them when > pushing down the Giant lock. Correct me if I'm wrong... In 5.0 we actually have 3 states: 1) running 2) sleeping 3) blocked on a mutex Afaik, top half (user syscalls) can be in 1, 2 or 3. However interrupts should only be 1 or 3. The fact is that we really can't depend on mutual exclusion for much of _anything_ anymore, the only place I see mutual exclusion being useful is in the bottom half, but _only_ in hardware drivers, and only with thier private data, not counting useaccessable stuff (via ifconfig). Therefore the old trick of having 'non-blocking' code to provide interrupts with stable 'foo*' doesn't work anymore and mutexes are needed (or at least spinlocks), but even with spinlocks, you may still have an interrupt or user context come in on another CPU. There shouldn't be a problem with an interrupt blocking on a mutex. However there could be a problem if an interrupt stalls for too long because currently we only have a single interrupt thread per software interrupt class, if that gets stalled and happens to be the network thread we can't process any more packets in order to possibly free up the reasources needed. I think that, non-sleeping versions should continue to remain available. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 10:28:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (unknown [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id C149137B699 for ; Tue, 23 Jan 2001 10:28:35 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0NISRx48644; Tue, 23 Jan 2001 10:28:28 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f0NIS3026065; Tue, 23 Jan 2001 10:28:03 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010123102231.Q26076@fw.wintelcom.net> Date: Tue, 23 Jan 2001 10:28:03 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Alfred Perlstein Subject: Re: Second zone allocator patch Cc: Dag-Erling Smorgrav , arch@FreeBSD.ORG, Bruce Evans Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Jan-01 Alfred Perlstein wrote: > > Correct me if I'm wrong... > > In 5.0 we actually have 3 states: > 1) running > 2) sleeping > 3) blocked on a mutex > > Afaik, top half (user syscalls) can be in 1, 2 or 3. However > interrupts should only be 1 or 3. Correct. > Therefore the old trick of having 'non-blocking' code to > provide interrupts with stable 'foo*' doesn't work anymore > and mutexes are needed (or at least spinlocks), but even > with spinlocks, you may still have an interrupt or user > context come in on another CPU. Erm, spinlocks protect against preemption. > There shouldn't be a problem with an interrupt blocking on a > mutex. However there could be a problem if an interrupt > stalls for too long because currently we only have a single > interrupt thread per software interrupt class, if that gets > stalled and happens to be the network thread we can't process > any more packets in order to possibly free up the reasources > needed. > > I think that, non-sleeping versions should continue to remain > available. Yes, but the zone allocator can just use normal mutexes and achieve this. No need for spin mutexes. Also, to help with the problem of a software or hardware interrupt handler blocking and stalling other interrups, Jake and I have toyed with the notion of creating a new kthread to run the other handlers when an ithread blocks on a mutex, so that the other handlers wouldn't be broken. For hardware interrupts, this would require a refcount on the intrhand "interrupt source" so that the interrupt can be re-enabled when the refcount hits 0. However, this is only in conceptual stage right now, and as an optimizaation, is a bit down the priority list. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 10:55: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id A9C4337B69B; Tue, 23 Jan 2001 10:54:49 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0NIsna04831; Tue, 23 Jan 2001 10:54:49 -0800 (PST) Date: Tue, 23 Jan 2001 10:54:48 -0800 From: Alfred Perlstein To: John Baldwin Cc: Dag-Erling Smorgrav , arch@FreeBSD.ORG, Bruce Evans Subject: Re: Second zone allocator patch Message-ID: <20010123105448.T26076@fw.wintelcom.net> References: <20010123102231.Q26076@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.ORG on Tue, Jan 23, 2001 at 10:28:03AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John Baldwin [010123 10:28] wrote: > > On 23-Jan-01 Alfred Perlstein wrote: > > > > Correct me if I'm wrong... > > > > In 5.0 we actually have 3 states: > > 1) running > > 2) sleeping > > 3) blocked on a mutex > > > > Afaik, top half (user syscalls) can be in 1, 2 or 3. However > > interrupts should only be 1 or 3. > > Correct. > > > Therefore the old trick of having 'non-blocking' code to > > provide interrupts with stable 'foo*' doesn't work anymore > > and mutexes are needed (or at least spinlocks), but even > > with spinlocks, you may still have an interrupt or user > > context come in on another CPU. > > Erm, spinlocks protect against preemption. Spinlocks don't protect against interrupts on a different CPU, unless the resource is protected by that spinlock properly. I actually think I ment spl here, but I'm on my second day on 'the patch' so your guess is as good as mine. :) > > > There shouldn't be a problem with an interrupt blocking on a > > mutex. However there could be a problem if an interrupt > > stalls for too long because currently we only have a single > > interrupt thread per software interrupt class, if that gets > > stalled and happens to be the network thread we can't process > > any more packets in order to possibly free up the reasources > > needed. > > > > I think that, non-sleeping versions should continue to remain > > available. > > Yes, but the zone allocator can just use normal mutexes and achieve this. No > need for spin mutexes. Also, to help with the problem of a software or > hardware interrupt handler blocking and stalling other interrups, Jake and I > have toyed with the notion of creating a new kthread to run the other handlers > when an ithread blocks on a mutex, so that the other handlers wouldn't be > broken. For hardware interrupts, this would require a refcount on the intrhand > "interrupt source" so that the interrupt can be re-enabled when the refcount > hits 0. However, this is only in conceptual stage right now, and as an > optimizaation, is a bit down the priority list. Hmm, sort of like my suggestion at BAFUG but slower and with more context switches? :) I really don't think you want multiple hardware interrupts, but having multiple software interrupts is needed to provide SMP scalability of the network stack. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 10:57: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 1AB9C37B401; Tue, 23 Jan 2001 10:56:43 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0NIubW04982; Tue, 23 Jan 2001 10:56:37 -0800 (PST) Date: Tue, 23 Jan 2001 10:56:37 -0800 From: Alfred Perlstein To: Kirk McKusick Cc: Matt Dillon , Ian Dowse , Mike Smith , Tony Finch , Terry Lambert , Poul-Henning Kamp , arch@FreeBSD.org Subject: Re: Fsck updates for filesystem Message-ID: <20010123105637.U26076@fw.wintelcom.net> References: <200101192102.f0JL2F698129@earth.backplane.com> <200101230147.RAA35771@beastie.mckusick.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101230147.RAA35771@beastie.mckusick.com>; from mckusick@mckusick.com on Mon, Jan 22, 2001 at 05:47:44PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Kirk McKusick [010122 19:32] wrote: > There have been several suggestions on where to put the hooks for > fsck to update a running filesystem: ioctl, mount, fcntl, and sysctl. > As several folks pointed out, we are dealing with filesystem incore > data, so ioctl is quite inappropriate as it really wants to deal > with the underlying disk (the disk knows nothing about the > filesystem data structures that are stored on it). Mount is possible, > but dubious, because it has such bizzare semantics already which > would be tricky to work around and most of which are at best > unnecessary for the problem at hand. I lean against fcntl as its > current functions are all things that are typically done by normal > user programs. It has no kernel administration functions associated > with it, and I believe that documenting them in the fcntl manual > page will only lead to generally useless bloat in a page intended > for relatively naive users. In addition it would be a non-standard > extension to a POSIX defined interface. So, I am still of the > opinion that sysctl is the right place for these functions. Like > many other sysctl's, fsck want to manage kernel state. The correct > administrative controls are already in place (checking for root). > The framework extends in an obvious place (kern.vfs.ffs. > where is one of adjlinkcnt, adjblockcnt, or setblockmap). > A final evidence of correctness is that all the needed functionality > for the above three functions adds a grand total of 40 lines to > the kernel (including three sysctl definitions, comments, and code). I agree with the sysctl approach, along with your patch for making sysctl oid's non-repeating (although it could use a mpfixme() because of the global counter). So just commit it, I'll do the lock around the counter later. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 11: 6:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (unknown [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 9B4AA37B698 for ; Tue, 23 Jan 2001 11:06:20 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0NJ5hx51796; Tue, 23 Jan 2001 11:05:43 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f0NJ5JO26566; Tue, 23 Jan 2001 11:05:19 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010123105448.T26076@fw.wintelcom.net> Date: Tue, 23 Jan 2001 11:05:19 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Alfred Perlstein Subject: Re: Second zone allocator patch Cc: Bruce Evans , arch@FreeBSD.ORG, Dag-Erling Smorgrav Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Jan-01 Alfred Perlstein wrote: > * John Baldwin [010123 10:28] wrote: >> Yes, but the zone allocator can just use normal mutexes and achieve this. >> No >> need for spin mutexes. Also, to help with the problem of a software or >> hardware interrupt handler blocking and stalling other interrups, Jake and I >> have toyed with the notion of creating a new kthread to run the other >> handlers >> when an ithread blocks on a mutex, so that the other handlers wouldn't be >> broken. For hardware interrupts, this would require a refcount on the >> intrhand >> "interrupt source" so that the interrupt can be re-enabled when the refcount >> hits 0. However, this is only in conceptual stage right now, and as an >> optimizaation, is a bit down the priority list. > > Hmm, sort of like my suggestion at BAFUG but slower and with more > context switches? :) I really don't think you want multiple hardware > interrupts, but having multiple software interrupts is needed to > provide SMP scalability of the network stack. It would only kick in during a mutex block, i.e. in ithd_fixup() when we get to the point that that exists. However, stuff like this is not something to be worrying about anytime soon. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 11:10:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 2EA9A37B401; Tue, 23 Jan 2001 11:10:17 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0NJACs85801; Tue, 23 Jan 2001 12:10:13 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101231910.f0NJACs85801@aslan.scsiguy.com> Cc: Bruce Evans , arch@FreeBSD.org, bde@FreeBSD.org Subject: Re: Local driver include files. In-Reply-To: Your message of "Tue, 23 Jan 2001 10:31:49 MST." Date: Tue, 23 Jan 2001 12:10:12 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>> This is a much more scalable approach. >> >>Except the size of the Makefile and most command lines generated by >>it is O(number of path/to/file/being/compiled). > >Really? It seems that this does what I need: > >INCLUDES= -nostdinc -I- -I. -I$S -I${<:H} > >Perhaps that is too simplistic? Well, it was. I was able to build a kernel with the following modifications: Index: Makefile.i386 =================================================================== RCS file: /usr/cvs/src/sys/conf/Makefile.i386,v retrieving revision 1.179.2.2 diff -c -r1.179.2.2 Makefile.i386 *** Makefile.i386 2000/07/07 00:29:27 1.179.2.2 --- Makefile.i386 2001/01/23 19:05:35 *************** *** 68,74 **** # can override the others. CFLAGS+= ${CONF_CFLAGS} ! NORMAL_C= ${CC} -c ${CFLAGS} ${PROF} ${.IMPSRC} NORMAL_C_C= ${CC} -c ${CFLAGS} ${PROF} ${.IMPSRC} NORMAL_S= ${CC} -c ${ASM_CFLAGS} ${.IMPSRC} PROFILE_C= ${CC} -c ${CFLAGS} ${.IMPSRC} --- 68,74 ---- # can override the others. CFLAGS+= ${CONF_CFLAGS} ! NORMAL_C= ${CC} -c ${CFLAGS} -I${<:H} ${PROF} ${.IMPSRC} NORMAL_C_C= ${CC} -c ${CFLAGS} ${PROF} ${.IMPSRC} NORMAL_S= ${CC} -c ${ASM_CFLAGS} ${.IMPSRC} PROFILE_C= ${CC} -c ${CFLAGS} ${.IMPSRC} *************** *** 179,185 **** kernel-depend: assym.s param.c vnode_if.h ${BEFORE_DEPEND} \ ${CFILES} ${SYSTEM_CFILES} ${GEN_CFILES} ${SFILES} ${SYSTEM_SFILES} rm -f .newdep ! mkdep -a -f .newdep ${CFLAGS} ${CFILES} ${SYSTEM_CFILES} ${GEN_CFILES} env MKDEP_CPP="${CC} -E" \ mkdep -a -f .newdep ${ASM_CFLAGS} ${SFILES} ${SYSTEM_SFILES} rm -f .depend --- 179,185 ---- kernel-depend: assym.s param.c vnode_if.h ${BEFORE_DEPEND} \ ${CFILES} ${SYSTEM_CFILES} ${GEN_CFILES} ${SFILES} ${SYSTEM_SFILES} rm -f .newdep ! mkdep -a -f .newdep ${CFLAGS} ${CFILES:H:S/^/-I/} ${CFILES} ${SYSTEM_CFILES} ${GEN_CFILES} env MKDEP_CPP="${CC} -E" \ mkdep -a -f .newdep ${ASM_CFLAGS} ${SFILES} ${SYSTEM_SFILES} rm -f .depend -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 11:19:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 9CD5C37B401 for ; Tue, 23 Jan 2001 11:19:26 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0NJYpS01362; Tue, 23 Jan 2001 11:34:52 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101231934.f0NJYpS01362@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Justin T. Gibbs" Cc: arch@FreeBSD.org Subject: Re: Local driver include files. In-reply-to: Your message of "Tue, 23 Jan 2001 12:10:12 MST." <200101231910.f0NJACs85801@aslan.scsiguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Jan 2001 11:34:51 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >Really? It seems that this does what I need: > > > >INCLUDES= -nostdinc -I- -I. -I$S -I${<:H} > > > >Perhaps that is too simplistic? > > Well, it was. I was able to build a kernel with the following > modifications: ... FWIW, I like this basic concept; I didn't really like or want to add sys/dev to the hardcoded list of kernel includes. I'd also love it if there was some way to add an include path for a subset of files that wasn't just their source directory; the ACPICA include is an abomination. 8( -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 11:46:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from guardian.marianopolis.edu (unknown [207.183.55.144]) by hub.freebsd.org (Postfix) with SMTP id DE29637B400; Tue, 23 Jan 2001 11:45:57 -0800 (PST) Received: id LAA01766; Tue, 23 Jan 2001 11:42:38 -0800 Received: by gateway id ; Tue, 23 Jan 2001 14:43:54 -0500 Message-ID: From: "Bosko Milekic" To: "John Baldwin" , "Alfred Perlstein" Cc: "Dag-Erling Smorgrav" , , "Bruce Evans" Subject: Re: Second zone allocator patch Date: Tue, 23 Jan 2001 14:43:50 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Baldwin wrote: [...] > > There shouldn't be a problem with an interrupt blocking on a > > mutex. However there could be a problem if an interrupt > > stalls for too long because currently we only have a single > > interrupt thread per software interrupt class, if that gets > > stalled and happens to be the network thread we can't process > > any more packets in order to possibly free up the reasources > > needed. > > > > I think that, non-sleeping versions should continue to remain > > available. > > Yes, but the zone allocator can just use normal mutexes and achieve this. No > need for spin mutexes. Also, to help with the problem of a software or That's right. A "sleep" and a "waiting for lock" shouldn't be treated the same way. A cv sleep and {m,t}sleep() are "sleeps." A mtx_enter(&lock, MTX_DEF) shouldn't be considered a "sleep." I think Alfred was pretty clear when he said "non-sleeping versions should continue to remain available," given this consideration. > hardware interrupt handler blocking and stalling other interrups, Jake and I > have toyed with the notion of creating a new kthread to run the other handlers > when an ithread blocks on a mutex, so that the other handlers wouldn't be > broken. For hardware interrupts, this would require a refcount on the intrhand > "interrupt source" so that the interrupt can be re-enabled when the refcount > hits 0. However, this is only in conceptual stage right now, and as an > optimizaation, is a bit down the priority list. Icky. I would have thought that there would have been an alternative way to solving this. But let's wait until we're ready. > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ Later, Bosko. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 11:53: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (unknown [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id A083337B400 for ; Tue, 23 Jan 2001 11:52:48 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0NJq5x57076; Tue, 23 Jan 2001 11:52:05 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f0NJpf527165; Tue, 23 Jan 2001 11:51:41 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 23 Jan 2001 11:51:41 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Bosko Milekic Subject: Re: Second zone allocator patch Cc: Bruce Evans , arch@FreeBSD.ORG, Dag-Erling Smorgrav , Alfred Perlstein Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Jan-01 Bosko Milekic wrote: >> hardware interrupt handler blocking and stalling other interrups, Jake > and I >> have toyed with the notion of creating a new kthread to run the other > handlers >> when an ithread blocks on a mutex, so that the other handlers wouldn't be >> broken. For hardware interrupts, this would require a refcount on the > intrhand >> "interrupt source" so that the interrupt can be re-enabled when the > refcount >> hits 0. However, this is only in conceptual stage right now, and as an >> optimizaation, is a bit down the priority list. > > Icky. I would have thought that there would have been an alternative way > to solving this. But let's wait until we're ready. No more icky than light weight ithread switches. Much less, in fact. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 11:57: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 4F88537B400 for ; Tue, 23 Jan 2001 11:56:42 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.1/8.11.1) with ESMTP id f0NJuIj05190; Tue, 23 Jan 2001 11:56:18 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.1/8.11.0) id f0NJuDW24253; Tue, 23 Jan 2001 11:56:13 -0800 (PST) (envelope-from jdp) Date: Tue, 23 Jan 2001 11:56:13 -0800 (PST) Message-Id: <200101231956.f0NJuDW24253@vashon.polstra.com> To: arch@freebsd.org From: John Polstra Reply-To: arch@freebsd.org Cc: n@nectar.com Subject: Re: other approach for hiding names (was Re: Request For Review: libc/libc_r changes to allow -lc_r) In-Reply-To: <20010122120302.A93660@hamlet.nectar.com> References: <20010120153158.A88123@hamlet.nectar.com> <20010122120302.A93660@hamlet.nectar.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <20010122120302.A93660@hamlet.nectar.com>, Jacques A. Vidrine wrote: > [I cc'd: jdp directly because he's the person most knowledgeable about > linker issues with which I've corresponded. Hope you don't mind, > John!] No problem, but next time please use "bcc". Once you get on the cc list it's impossible to get off of it again. > I'm beginning to think that the pre-processor is the wrong tool for > the job. It can't tell a function or object declaration from other > tokens. > > Is there somewhere in the build process that we could insert a tool > that does something like the following? > > for each externally visible symbol: > skip symbol if it is reserved (e.g. '_[A-Z_]') > skip symbol if it is not on the ISO C name list [1] > if the symbol is defined in this module: > rename 'symbol' to '__symbol' > add weak reference for 'symbol' -> '__symbol' > else (the symbol is an undefined reference): > rename 'symbol' to '__symbol' I'm really leery of introducing a special tool for this. I think it could cause problems with upgrading from older versions, and would make us needlessly and confusingly different from the other BSDs. Also I think it's a lot clearer to be able to see what is going on by looking at the source files, without having to remember the magic going on behind the scenes. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 11:58:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id A926637B400 for ; Tue, 23 Jan 2001 11:58:13 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.1/8.11.1) with ESMTP id f0NJw7j05203; Tue, 23 Jan 2001 11:58:07 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.1/8.11.0) id f0NJw6P24271; Tue, 23 Jan 2001 11:58:06 -0800 (PST) (envelope-from jdp) Date: Tue, 23 Jan 2001 11:58:06 -0800 (PST) Message-Id: <200101231958.f0NJw6P24271@vashon.polstra.com> To: arch@freebsd.org From: John Polstra Reply-To: arch@freebsd.org Cc: bde@zeta.org.au Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article , Bruce Evans wrote: > > (1) Underscores are verbose and ugly. > (2) _foo is usually sufficient. _[a-z] is not entirely in the user > namespace like you are claimed. From the 1990 ISO standard: > "All identifiers that begin with an underscore are always > reserved for use as identifiers with file scope in both the > ordinary identifier and tag name spaces". In practice, this > means that the implementation can use names beginning with > _[a-z] except for macro names and global variables that are > used in macros. E.g., errno must be defined as (*__error()) > and not as (*_error()), since the latter would break the > standard-conforming application code: > #include > void foo(void) { int _error = errno; } > A single underscore is sufficient in all other cases. E.g., > struct member names are in a nested namespace so they don't > conflict with variable names at all. They may still need a > single underscore so that they don't conflict with macro > names. > (3) We have some precedence for using _foo. > (4) NetBSD uses _foo (at least in old versions). So did SVR4, which (I think) introduced weak symbols. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 12: 6:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 5FE4D37B400; Tue, 23 Jan 2001 12:06:05 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0NK64l07788; Tue, 23 Jan 2001 12:06:04 -0800 (PST) Date: Tue, 23 Jan 2001 12:06:04 -0800 From: Alfred Perlstein To: John Baldwin Cc: Bosko Milekic , Bruce Evans , arch@FreeBSD.ORG, Dag-Erling Smorgrav Subject: Re: Second zone allocator patch Message-ID: <20010123120604.Y26076@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.ORG on Tue, Jan 23, 2001 at 11:51:41AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John Baldwin [010123 11:53] wrote: > > On 23-Jan-01 Bosko Milekic wrote: > >> hardware interrupt handler blocking and stalling other interrups, Jake > > and I > >> have toyed with the notion of creating a new kthread to run the other > > handlers > >> when an ithread blocks on a mutex, so that the other handlers wouldn't be > >> broken. For hardware interrupts, this would require a refcount on the > > intrhand > >> "interrupt source" so that the interrupt can be re-enabled when the > > refcount > >> hits 0. However, this is only in conceptual stage right now, and as an > >> optimizaation, is a bit down the priority list. > > > > Icky. I would have thought that there would have been an alternative way > > to solving this. But let's wait until we're ready. > > No more icky than light weight ithread switches. Much less, in fact. afaik, most software interrupts are basically there to process queues. You can use the queue lock to protect the counter, if the counter is exceeded the thread can call kthread_exit (or whatever) and destroy itself. If a queueing process finds that all software threads are currently active it can spawn a new thread as long as the count is below a threshold. Basically a high and low watermark would suffice, or you could use a high count and if N number of software interrupt threads were waiting then they would destroy themselves. Not icky... but actually interesting. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 12:13:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (unknown [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 1AF4037B404 for ; Tue, 23 Jan 2001 12:13:19 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0NKCgx57770; Tue, 23 Jan 2001 12:12:42 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f0NKCIt27427; Tue, 23 Jan 2001 12:12:18 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010123120604.Y26076@fw.wintelcom.net> Date: Tue, 23 Jan 2001 12:12:18 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Alfred Perlstein Subject: Re: Second zone allocator patch Cc: arch@FreeBSD.ORG, Bosko Milekic Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Jan-01 Alfred Perlstein wrote: > * John Baldwin [010123 11:53] wrote: >> >> On 23-Jan-01 Bosko Milekic wrote: >> >> hardware interrupt handler blocking and stalling other interrups, >> >> Jake and I have toyed with the notion of creating a new kthread >> >> to run the other handlers when an ithread blocks on a mutex, so >> >> that the other handlers wouldn't be broken. For hardware >> >> interrupts, this would require a refcount on the intrhand >> >> "interrupt source" so that the interrupt can be re-enabled when >> >> the refcount hits 0. However, this is only in conceptual stage >> >> right now, and as an optimizaation, is a bit down the priority >> >> list. >> > >> > Icky. I would have thought that there would have been an >> > alternative way >> > to solving this. But let's wait until we're ready. >> >> No more icky than light weight ithread switches. Much less, in >> fact. > > afaik, most software interrupts are basically there to process > queues. Rewrite the code to use a taskqueue(9) then. :) And then have the software interrupt handler manage your worker thread pool. That is an orthogonal problem to hanging multiple handlers off an interrupt thread and wanting one handler blocking to not result in all handlers blocking. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 13: 6:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 753) id 6E44037B400; Tue, 23 Jan 2001 13:06:28 -0800 (PST) Date: Tue, 23 Jan 2001 13:06:28 -0800 From: Adrian Chadd To: freebsd-arch@freebsd.org Subject: mount options Message-ID: <20010123130628.A77423@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I'd like to spark a discussion on the mount interface. It seems a little evil right now, and I have noted that you can't add arbitrary mount options through to an FS since they're passed across as binary. For an FS porting project I'm doing, the mount interface needs to be able to export the mount options back out to userspace, and I'd like to tidy the code up instead of just fudge it for my needs. So, if you have an idea on how the mount interface *should* look, now is the time to stand up and tell me what you're thinking.. :-) Thanks! Adrian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 14:59:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 0D5B237B6A0; Tue, 23 Jan 2001 14:59:03 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0NMx2J14197; Tue, 23 Jan 2001 14:59:02 -0800 (PST) Date: Tue, 23 Jan 2001 14:59:02 -0800 From: Alfred Perlstein To: Adrian Chadd Cc: freebsd-arch@FreeBSD.ORG Subject: Re: mount options Message-ID: <20010123145902.F26076@fw.wintelcom.net> References: <20010123130628.A77423@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010123130628.A77423@hub.freebsd.org>; from adrian@FreeBSD.ORG on Tue, Jan 23, 2001 at 01:06:28PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Adrian Chadd [010123 13:06] wrote: > > Hi, > > I'd like to spark a discussion on the mount interface. It seems > a little evil right now, and I have noted that you can't add > arbitrary mount options through to an FS since they're passed > across as binary. > > For an FS porting project I'm doing, the mount interface needs > to be able to export the mount options back out to userspace, > and I'd like to tidy the code up instead of just fudge it for > my needs. > > So, if you have an idea on how the mount interface *should* look, > now is the time to stand up and tell me what you're thinking.. :-) I haven't thought about it much except how bad the interface is. Just some random thoughts on it. :) I would think that simply using a string passing method given some helper functions should be enough. There's really no effeciency problem as I can see because this wouldn't restrict the VFS from caching the information in a flags structure. At the same time it could allow for extracting some form of the mount options in the form of strings, perhaps a list of NULL terminated strings as a large block (sysctl or fetch syscall could specify the block length)? I also think that passing in each option shouldn't depend on formatting characters for seperation such as ',', instead it should be a list of null terminated strings and a length of the block. Some conventions might be in order, but the current async/noasync atime/noatime stuff seems to work pretty well. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 15:33:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (mail.dobox.com [208.187.122.44]) by hub.freebsd.org (Postfix) with ESMTP id 4760137B69C; Tue, 23 Jan 2001 15:32:58 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14L6rO-0000ck-00; Tue, 23 Jan 2001 10:03:59 -0700 Message-ID: <3A6DB97E.5EED550@softweyr.com> Date: Tue, 23 Jan 2001 10:03:58 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Justin T. Gibbs" Cc: arch@FreeBSD.org, bde@FreeBSD.org Subject: Re: Local driver include files. References: <200101231615.f0NGF1s81841@aslan.scsiguy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Justin T. Gibbs" wrote: > > > > >No, it's not. What does that have to do with -nostdinc? > > Its actually -I-. Either way, you can't use the system include files to build the kernel, or even world. What if you're doing a cross-compile for another architecture, or another system version? Adding a -I or three in a directory doesn't harm anything. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 15:38:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from roaming.cacheboy.net (roaming.cacheboy.net [203.56.168.69]) by hub.freebsd.org (Postfix) with ESMTP id F113137B69F for ; Tue, 23 Jan 2001 15:37:53 -0800 (PST) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.1/8.11.1) id f0NNbgi01406; Wed, 24 Jan 2001 00:37:42 +0100 (CET) (envelope-from adrian) Date: Wed, 24 Jan 2001 00:37:42 +0100 From: Adrian Chadd To: Alfred Perlstein Cc: freebsd-arch@freebsd.org Subject: Re: mount options Message-ID: <20010124003742.B863@roaming.cacheboy.net> References: <20010123130628.A77423@hub.freebsd.org> <20010123145902.F26076@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010123145902.F26076@fw.wintelcom.net>; from bright@wintelcom.net on Tue, Jan 23, 2001 at 02:59:02PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 23, 2001, Alfred Perlstein wrote: > I haven't thought about it much except how bad the interface is. Hah. :) > Just some random thoughts on it. :) > > I would think that simply using a string passing method given some > helper functions should be enough. There's really no effeciency > problem as I can see because this wouldn't restrict the VFS from > caching the information in a flags structure. At the same time it > could allow for extracting some form of the mount options in the > form of strings, perhaps a list of NULL terminated strings as a > large block (sysctl or fetch syscall could specify the block length)? > > I also think that passing in each option shouldn't depend on formatting > characters for seperation such as ',', instead it should be a list > of null terminated strings and a length of the block. I'm thinking something like this - but I was thinking about an array of sbufs per mountpoint containing the mountpoint options. Linux has a bunch of functions which manipulate the mount table and one of them gets a given mount option. This would be rather useful, both in kernel and user space. It also means that if the user decides to remount a filesystem and change the FS options (which is entirely possible, and we should provide the flexibility for each FS to support or not support this) then the options get updated correctly rather than "replaced" with the new set. > Some conventions might be in order, but the current async/noasync > atime/noatime stuff seems to work pretty well. Yup. Adrian -- Adrian Chadd "Programming is like sex: One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 15:41:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 8A0E337B6A2; Tue, 23 Jan 2001 15:41:24 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0NNfMs93027; Tue, 23 Jan 2001 16:41:22 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101232341.f0NNfMs93027@aslan.scsiguy.com> To: Wes Peters Cc: arch@FreeBSD.org, bde@FreeBSD.org Subject: Re: Local driver include files. In-Reply-To: Your message of "Tue, 23 Jan 2001 10:03:58 MST." <3A6DB97E.5EED550@softweyr.com> Date: Tue, 23 Jan 2001 16:41:22 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >"Justin T. Gibbs" wrote: >> >> > >> >No, it's not. What does that have to do with -nostdinc? >> >> Its actually -I-. > >Either way, you can't use the system include files to build the kernel, or >even world. What if you're doing a cross-compile for another architecture, >or another system version? I'm not saying that -I- is unnecessary, only that the build system should allow local includes. >Adding a -I or three in a directory doesn't harm anything. But adding just the ones for my driver to the whole build seems wrong. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 16:47:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id 2AD3D37B6A1; Tue, 23 Jan 2001 16:47:37 -0800 (PST) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id RAA53684; Tue, 23 Jan 2001 17:47:27 -0700 Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp10.phx.gblx.net, id smtpd.ZUpMa; Tue Jan 23 17:47:17 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id RAA05442; Tue, 23 Jan 2001 17:47:25 -0700 (MST) From: Terry Lambert Message-Id: <200101240047.RAA05442@usr08.primenet.com> Subject: Re: mount options To: adrian@FreeBSD.ORG (Adrian Chadd) Date: Wed, 24 Jan 2001 00:47:25 +0000 (GMT) Cc: freebsd-arch@FreeBSD.ORG In-Reply-To: <20010123130628.A77423@hub.freebsd.org> from "Adrian Chadd" at Jan 23, 2001 01:06:28 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'd like to spark a discussion on the mount interface. It seems > a little evil right now, and I have noted that you can't add > arbitrary mount options through to an FS since they're passed > across as binary. Options which take a parameter should be recovered from "newfs", by looking at metadata stored on the FS itself. That's what the superblock is for. Options which don't take a parameter should probably be stuffed into a bitmap of 32 characters in length, which will cover all of ASCII. Argument parsing, other than boolean behaviour changes, really don't belong in the kernel. I think the NFS exports should be handled by NFS stat'ing, and reading, if it's changed, the /etc/exports file. I lean heavily toward an "exportfs" command, as exists on many OS, for triggering this, if a stat isn't feasible (but I think it is). I think the covered mount point is a seperate parameter, and I'd like to see the FS's not know about the difference between a root mount and a non-root mount: that should all be handed by higher level, common code. Right now the difference is: 1) Covering the mount point, if any 2) Adjusting the stored value of "last mounted on" 3) Hooking it into the mounted VFS list, so that a mount point traversal can be handled automatically If the mount VFSOP were split into one for "place this FS in the mounted VFS list", and a seperate one for "set the last mounted on and other metadata for this VFS" (only to be called upon non-root FS's), I think that most of the work involved in mount operations could be moved to common, upper level code. So the order of operation is actually 3, 1, 2, if you do it this way. You could actually go so far as to do #3 each and every time a device "arrives", automatically, assuming it had an appropriate class (e.g. a memory card for pictures, from a camera). > For an FS porting project I'm doing, the mount interface needs > to be able to export the mount options back out to userspace, > and I'd like to tidy the code up instead of just fudge it for > my needs. The bitmap would be ideal for this. The only arguments which would not fall into this are the "what you are mounting" and the "where you are mounting it" arguments, which will have to be handled seperately, in any case. For these arguments, I'd suggest passing it in by descriptor, just like the VOPS and VFSOPS work today. This will let you do things like pre-parse NFS host addresses in user space, by way of a covenant betweeen the user space fs-specific mount command, and the kernel space NFS client VFSOP for mounting (for example). > So, if you have an idea on how the mount interface *should* look, > now is the time to stand up and tell me what you're thinking.. :-) My two cents, anyway... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 20:37:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id 5951037B698; Tue, 23 Jan 2001 20:37:38 -0800 (PST) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id UAA36783; Tue, 23 Jan 2001 20:37:14 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200101240437.UAA36783@beastie.mckusick.com> To: Alfred Perlstein Subject: Re: Fsck updates for filesystem Cc: Matt Dillon , Ian Dowse , Mike Smith , Tony Finch , Terry Lambert , Poul-Henning Kamp , arch@FreeBSD.org In-Reply-To: Your message of "Tue, 23 Jan 2001 10:56:37 PST." <20010123105637.U26076@fw.wintelcom.net> Date: Tue, 23 Jan 2001 20:37:14 -0800 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Date: Tue, 23 Jan 2001 10:56:37 -0800 From: Alfred Perlstein To: Kirk McKusick Cc: Matt Dillon , Ian Dowse , Mike Smith , Tony Finch , Terry Lambert , Poul-Henning Kamp , arch@FreeBSD.org Subject: Re: Fsck updates for filesystem I agree with the sysctl approach, along with your patch for making sysctl oid's non-repeating (although it could use a mpfixme() because of the global counter). So just commit it, I'll do the lock around the counter later. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." I have put in the change to avoid reuse of AUTO_OID's. Per your request, I have left the locking issues to you :-) Kirk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 22:59:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 967E437B69B for ; Tue, 23 Jan 2001 22:59:27 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0O6xJ955490; Tue, 23 Jan 2001 23:59:19 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101240659.f0O6xJ955490@harmony.village.org> To: "Justin T. Gibbs" Subject: Re: Local driver include files. Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 23 Jan 2001 12:10:12 MST." <200101231910.f0NJACs85801@aslan.scsiguy.com> References: <200101231910.f0NJACs85801@aslan.scsiguy.com> Date: Tue, 23 Jan 2001 23:59:19 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Short version: I like it... Long version: In message <200101231910.f0NJACs85801@aslan.scsiguy.com> "Justin T. Gibbs" writes: : Well, it was. I was able to build a kernel with the following : modifications: I think this might work. Did you change all "local" includes as well? If so, did you also compile the modules? Did that work too? This would make things easier to share with other systems. But only if those other systems also allow that to happen. I don't think that NetBSD's and OpenBSD's build system would allow it. If you wanted to support them, you'll need to your changes included there. From a asthetic point of view, I like this idea. As long as the include files are knowable, this makes it easier to maintain. And a little easier to explain to other folks. It would also make things more "local" and improve "locality of reference". It wouldn't help with the "where are the bus interface files located" problem that we also have (ok, it isn't a big problem), but you'd likely need ifdefs for that. Or maybe not since that sort of thing tends to be encapsulated in separate glue files for OSes or in interesting tricks done in include files. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 23:59:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id C56F637B401 for ; Tue, 23 Jan 2001 23:59:17 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.20 #1) id 14LKpF-0002RR-00; Wed, 24 Jan 2001 07:58:41 +0000 Date: Wed, 24 Jan 2001 07:58:41 +0000 From: Tony Finch To: Greg Lehey Cc: arch@FreeBSD.org Subject: Re: TAGS target in sys/Makefile? Message-ID: <20010124075841.C7190@hand.dotat.at> References: <20010123142121.L414@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010123142121.L414@wantadilla.lemis.com> Organization: Covalent Technologies, Inc Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Lehey wrote: > >There are a number of tools people can use to find their way around >the kernel sources: I know of at least ctags, etags and cscope. It >would be nice to have build targets for the corresponding data files >in sys/Makefile. Since I dig around the rest of the source tree more than I do the kernel, it would be useful if these targets could work over the whole source tree, or just parts of it. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at "Dead! And yet there he stands!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 23 23:59:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from roaming.cacheboy.net (roaming.cacheboy.net [203.56.168.69]) by hub.freebsd.org (Postfix) with ESMTP id 4D32F37B404 for ; Tue, 23 Jan 2001 23:59:38 -0800 (PST) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.1/8.11.1) id f0O7xLY02842; Wed, 24 Jan 2001 08:59:21 +0100 (CET) (envelope-from adrian) Date: Wed, 24 Jan 2001 08:59:21 +0100 From: Adrian Chadd To: Terry Lambert Cc: freebsd-arch@freebsd.org Subject: Re: mount options Message-ID: <20010124085920.A2795@roaming.cacheboy.net> References: <20010123130628.A77423@hub.freebsd.org> <200101240047.RAA05442@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101240047.RAA05442@usr08.primenet.com>; from tlambert@primenet.com on Wed, Jan 24, 2001 at 12:47:25AM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jan 24, 2001, Terry Lambert wrote: [snip] I'll reply to this snippet now, and the rest later today.. > > For an FS porting project I'm doing, the mount interface needs > > to be able to export the mount options back out to userspace, > > and I'd like to tidy the code up instead of just fudge it for > > my needs. > > The bitmap would be ideal for this. The only arguments which > would not fall into this are the "what you are mounting" and > the "where you are mounting it" arguments, which will have to > be handled seperately, in any case. The trouble is that the mount options aren't always going to be flags which are on or off. They *could* be say, a log device for seperate FS logging. This doesn't fit inside a bitmap, and I'd have to have to hack together a seperate sysctl or something just to get information for this particular FS. Adrian -- Adrian Chadd "Programming is like sex: One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 24 0:15:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 7DB9437B401 for ; Wed, 24 Jan 2001 00:15:01 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 92ED76AB73; Wed, 24 Jan 2001 18:44:59 +1030 (CST) Date: Wed, 24 Jan 2001 18:44:59 +1030 From: Greg Lehey To: Tony Finch Cc: arch@FreeBSD.org Subject: Re: TAGS target in sys/Makefile? Message-ID: <20010124184459.D37060@wantadilla.lemis.com> References: <20010123142121.L414@wantadilla.lemis.com> <20010124075841.C7190@hand.dotat.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010124075841.C7190@hand.dotat.at>; from dot@dotat.at on Wed, Jan 24, 2001 at 07:58:41AM +0000 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 24 January 2001 at 7:58:41 +0000, Tony Finch wrote: > Greg Lehey wrote: >> >> There are a number of tools people can use to find their way around >> the kernel sources: I know of at least ctags, etags and cscope. It >> would be nice to have build targets for the corresponding data files >> in sys/Makefile. > > Since I dig around the rest of the source tree more than I do the > kernel, it would be useful if these targets could work over the whole > source tree, or just parts of it. That's a different issue. Most userland code is relatively self-contained. When you're browsing through df(1), for example, you're probably not interested in similar names in syslogd(8). Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 24 0:51:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id 0D40937B698 for ; Wed, 24 Jan 2001 00:50:52 -0800 (PST) Received: (qmail 3881 invoked by uid 1000); 24 Jan 2001 08:49:24 -0000 Date: Wed, 24 Jan 2001 10:49:23 +0200 From: Peter Pentchev To: Greg Lehey Cc: Tony Finch , arch@FreeBSD.org Subject: Re: TAGS target in sys/Makefile? Message-ID: <20010124104923.A332@ringworld.oblivion.bg> Mail-Followup-To: Greg Lehey , Tony Finch , arch@FreeBSD.org References: <20010123142121.L414@wantadilla.lemis.com> <20010124075841.C7190@hand.dotat.at> <20010124184459.D37060@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010124184459.D37060@wantadilla.lemis.com>; from grog@lemis.com on Wed, Jan 24, 2001 at 06:44:59PM +1030 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jan 24, 2001 at 06:44:59PM +1030, Greg Lehey wrote: > On Wednesday, 24 January 2001 at 7:58:41 +0000, Tony Finch wrote: > > Greg Lehey wrote: > >> > >> There are a number of tools people can use to find their way around > >> the kernel sources: I know of at least ctags, etags and cscope. It > >> would be nice to have build targets for the corresponding data files > >> in sys/Makefile. > > > > Since I dig around the rest of the source tree more than I do the > > kernel, it would be useful if these targets could work over the whole > > source tree, or just parts of it. > > That's a different issue. Most userland code is relatively > self-contained. When you're browsing through df(1), for example, > you're probably not interested in similar names in syslogd(8). Yes, but you might be interested in (1) tags from df itself, or (2) tags from libraries df uses (as in "hm.. where was this again.. was it in libutil, or plain libc.. and which subdir of libc.."). (1) is easily fixed by running your favorite tag-creating tool inside the directory you're currently browsing.. how about (2) though? G'luck, Peter -- I am the thought you are now thinking. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 24 1:40:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id EC90D37B400 for ; Wed, 24 Jan 2001 01:40:29 -0800 (PST) Received: (qmail 4668 invoked by uid 1000); 24 Jan 2001 09:39:02 -0000 Date: Wed, 24 Jan 2001 11:39:02 +0200 From: Peter Pentchev To: freebsd-arch@FreeBSD.org Subject: patch for bsd.lib.mk to create include and lib dirs Message-ID: <20010124113902.B332@ringworld.oblivion.bg> Mail-Followup-To: freebsd-arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I tried to use bsd.lib.mk for a library I'm writing, and stumbled into a little difficulty: if a library tries to place its include files in a non-existing directory, bsd.lib.mk does not attempt to create it, but just tries to install files there. This might have strange side effects like installing a file with the name of the desired subdir. Attached is a little proposed patch to try to create ${DESTDIR}${INCDIR} and ${DESTDIR}${LIBDIR} if CREATEDESTDIRS is defined. And yes, I *am* aware of mtree and hierarchy; but until the actual advent of custom mtree files for ports (and maybe even then), I still think this might be a better solution than overriding beforeinstall and manually invoking '${MAKE} _includeinstall' after creating the directories needed. G'luck, Peter -- Do you think anybody has ever had *precisely this thought* before? Index: src/share/mk/bsd.lib.mk =================================================================== RCS file: /home/ncvs/src/share/mk/bsd.lib.mk,v retrieving revision 1.93 diff -u -r1.93 bsd.lib.mk --- src/share/mk/bsd.lib.mk 2000/10/02 08:48:49 1.93 +++ src/share/mk/bsd.lib.mk 2001/01/24 09:30:01 @@ -260,10 +260,16 @@ .if !target(install) .if !target(beforeinstall) beforeinstall: _includeinstall +.if defined(CREATEDESTDIRS) + ${MKDIR} ${DESTDIR}${LIBDIR} .endif +.endif _includeinstall: .if defined(INCS) +.if defined(CREATEDESTDIRS) + ${MKDIR} ${DESTDIR}${INCDIR} +.endif .for header in ${INCS} cd ${.CURDIR} && \ ${INSTALL} -C -o ${INCOWN} -g ${INCGRP} -m ${INCMODE} \ Index: src/share/mk/sys.mk =================================================================== RCS file: /home/ncvs/src/share/mk/sys.mk,v retrieving revision 1.46 diff -u -r1.46 sys.mk --- src/share/mk/sys.mk 2000/04/21 23:51:58 1.46 +++ src/share/mk/sys.mk 2001/01/24 09:30:01 @@ -57,6 +57,8 @@ .endif .endif +MKDIR ?= mkdir -p + .if defined(%POSIX) FC ?= fort77 FFLAGS ?= -O 1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 24 7:49:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 399EE37B400 for ; Wed, 24 Jan 2001 07:49:04 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 32E8B193E4; Wed, 24 Jan 2001 09:49:03 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.1/8.9.3) id f0OFn3d50287; Wed, 24 Jan 2001 09:49:03 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Wed, 24 Jan 2001 09:49:02 -0600 From: "Jacques A. Vidrine" To: arch@freebsd.org Subject: Re: other approach for hiding names (was Re: Request For Review: libc/libc_r changes to allow -lc_r) Message-ID: <20010124094902.A42047@hamlet.nectar.com> References: <20010120153158.A88123@hamlet.nectar.com> <20010122120302.A93660@hamlet.nectar.com> <200101231956.f0NJuDW24253@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101231956.f0NJuDW24253@vashon.polstra.com>; from jdp@polstra.com on Tue, Jan 23, 2001 at 11:56:13AM -0800 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 23, 2001 at 11:56:13AM -0800, John Polstra wrote: > > I'm beginning to think that the pre-processor is the wrong tool for > > the job. It can't tell a function or object declaration from other > > tokens. > > > > Is there somewhere in the build process that we could insert a tool > > that does something like the following? > > > > for each externally visible symbol: > > skip symbol if it is reserved (e.g. '_[A-Z_]') > > skip symbol if it is not on the ISO C name list [1] > > if the symbol is defined in this module: > > rename 'symbol' to '__symbol' > > add weak reference for 'symbol' -> '__symbol' > > else (the symbol is an undefined reference): > > rename 'symbol' to '__symbol' > > I'm really leery of introducing a special tool for this. I think it > could cause problems with upgrading from older versions, and would > make us needlessly and confusingly different from the other BSDs. But, if we take the route which Daniel used [1], simply to hide symbols, then soon we will be `needlessly and confusingly' different from the other BSDs. Do we really want every other [2] function call in libc to be prepended with an underscore? > Also I think it's a lot clearer to be able to see what is going on > by looking at the source files, without having to remember the magic > going on behind the scenes. I have to disagree. The magic is instead now in header files, and it is fragile and fraught with exceptions. On the other hand, if we don't have a goal of a pristine namespace, then the number of symbols we have to deal with is probably manageable with the pre-processor approach, if not aesthetically pleasing. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org [1] I don't have a problem with what Daniel committed. The functions handled in his commit have special requirements for threads, and are relatively few in number. [2] A rough count shows 4.2-STABLE libc with about 1025 symbols in the application namespace. Of these, about 853 need to be hidden. Many are probably leaf functions, or at least do not call any other functions that need to be hidden. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 24 10:21:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from balzac.cybercable.fr (balzac.cybercable.fr [212.198.0.198]) by hub.freebsd.org (Postfix) with SMTP id 7B10137B404 for ; Wed, 24 Jan 2001 10:21:12 -0800 (PST) Received: (qmail 3647317 invoked from network); 24 Jan 2001 18:21:06 -0000 Received: from s011.dhcp212-229.cybercable.fr (HELO gits.dyndns.org) ([212.198.229.11]) (envelope-sender ) by balzac.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 24 Jan 2001 18:21:06 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.1/8.11.1) id f0OIL4L16054; Wed, 24 Jan 2001 19:21:04 +0100 (CET) (envelope-from clefevre@citeweb.net) To: Peter Pentchev Cc: freebsd-arch@FreeBSD.ORG Subject: Re: patch for bsd.lib.mk to create include and lib dirs References: <20010124113902.B332@ringworld.oblivion.bg> X-Face: V|+c;4!|B?E%BE^{E6);aI.[<97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7@+30g0YD0*^^3jgyShN7o?a]C la*Zv'5NA,=963bM%J^o]C In-Reply-To: Peter Pentchev's message of "Wed, 24 Jan 2001 11:39:02 +0200" From: Cyrille Lefevre Reply-To: clefevre@noos.fr Mail-Copies-To: never Date: 24 Jan 2001 19:21:01 +0100 Message-ID: Lines: 51 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Pentchev writes: [snip] Index: src/share/mk/bsd.lib.mk =================================================================== RCS file: /home/ncvs/src/share/mk/bsd.lib.mk,v retrieving revision 1.93 diff -u -r1.93 bsd.lib.mk --- src/share/mk/bsd.lib.mk 2000/10/02 08:48:49 1.93 +++ src/share/mk/bsd.lib.mk 2001/01/24 09:30:01 @@ -260,10 +260,16 @@ .if !target(install) .if !target(beforeinstall) beforeinstall: _includeinstall +.if defined(CREATEDESTDIRS) + ${MKDIR} ${DESTDIR}${LIBDIR} .endif +.endif _includeinstall: .if defined(INCS) +.if defined(CREATEDESTDIRS) + ${MKDIR} ${DESTDIR}${INCDIR} +.endif .for header in ${INCS} cd ${.CURDIR} && \ ${INSTALL} -C -o ${INCOWN} -g ${INCGRP} -m ${INCMODE} \ Index: src/share/mk/sys.mk =================================================================== RCS file: /home/ncvs/src/share/mk/sys.mk,v retrieving revision 1.46 diff -u -r1.46 sys.mk --- src/share/mk/sys.mk 2000/04/21 23:51:58 1.46 +++ src/share/mk/sys.mk 2001/01/24 09:30:01 @@ -57,6 +57,8 @@ .endif .endif +MKDIR ?= mkdir -p + .if defined(%POSIX) FC ?= fort77 FFLAGS ?= -O 1 would not be better to use install -d instead of mkdir -p which permit, if needed alsewhere, to also set ownership ? Cyrille. -- home: mailto:clefevre@citeweb.net work: mailto:Cyrille.Lefevre@edf.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 24 13:18:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (pool84-tch-2.Sofia.0rbitel.net [212.95.171.84]) by hub.freebsd.org (Postfix) with SMTP id 49B5537B400 for ; Wed, 24 Jan 2001 13:18:09 -0800 (PST) Received: (qmail 4687 invoked by uid 1000); 24 Jan 2001 21:16:28 -0000 Date: Wed, 24 Jan 2001 23:16:28 +0200 From: Peter Pentchev To: clefevre@noos.fr Cc: freebsd-arch@FreeBSD.ORG Subject: Re: patch for bsd.lib.mk to create include and lib dirs Message-ID: <20010124231628.A442@ringworld.oblivion.bg> Mail-Followup-To: clefevre@noos.fr, freebsd-arch@FreeBSD.ORG References: <20010124113902.B332@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from clefevre@citeweb.net on Wed, Jan 24, 2001 at 07:21:01PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jan 24, 2001 at 07:21:01PM +0100, Cyrille Lefevre wrote: > Peter Pentchev writes: > > [snip] > > would not be better to use install -d instead of mkdir -p which permit, > if needed alsewhere, to also set ownership ? D'oh.. great idea! This simplifies things, because there's no need for the sys.mk patch to define MKDIR; INSTALL is already defined. New patch attached. G'luck, Peter -- This inert sentence is my body, but my soul is alive, dancing in the sparks of your brain. Index: src/share/mk/bsd.lib.mk =================================================================== RCS file: /home/ncvs/src/share/mk/bsd.lib.mk,v retrieving revision 1.93 diff -u -r1.93 bsd.lib.mk --- src/share/mk/bsd.lib.mk 2000/10/02 08:48:49 1.93 +++ src/share/mk/bsd.lib.mk 2001/01/24 09:30:01 @@ -260,10 +260,16 @@ .if !target(install) .if !target(beforeinstall) beforeinstall: _includeinstall +.if defined(CREATEDESTDIRS) + ${INSTALL} -d -o ${LIBOWN} -g ${LIBGRP} ${DESTDIR}${LIBDIR} .endif +.endif _includeinstall: .if defined(INCS) +.if defined(CREATEDESTDIRS) + ${INSTALL} -d -o ${INCOWN} -g ${INCGRP} ${DESTDIR}${LIBDIR} +.endif .for header in ${INCS} cd ${.CURDIR} && \ ${INSTALL} -C -o ${INCOWN} -g ${INCGRP} -m ${INCMODE} \ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 24 14: 2:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 7FBB137B401 for ; Wed, 24 Jan 2001 14:02:24 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0OM2I961735; Wed, 24 Jan 2001 15:02:18 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101242202.f0OM2I961735@harmony.village.org> To: clefevre@noos.fr Subject: Re: patch for bsd.lib.mk to create include and lib dirs Cc: Peter Pentchev , freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "24 Jan 2001 19:21:01 +0100." References: <20010124113902.B332@ringworld.oblivion.bg> Date: Wed, 24 Jan 2001 15:02:18 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Cyrille Lefevre writes: : would not be better to use install -d instead of mkdir -p which permit, : if needed alsewhere, to also set ownership ? install -d doesn't set the ownership, except on the last component of the path. It was brought into the tree to be compatible with other BSDs, and many objects were raised until I made the promise that it wouldn't be used in "new" code. This happend in 1996: revision 1.16 date: 1996/09/29 06:29:54; author: imp; state: Exp; lines: +56 -5 Implement -d in install. Update the man page to reflect this change. But it looks like install -d has crept into the tree in other places. But why have a define for this? Why not check to make sure that directory is missing before trying to create it? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 24 14:43:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (pool83-tch-1.Sofia.0rbitel.net [212.95.170.83]) by hub.freebsd.org (Postfix) with SMTP id 4BFBE37B400 for ; Wed, 24 Jan 2001 14:43:13 -0800 (PST) Received: (qmail 65139 invoked by uid 1000); 24 Jan 2001 22:41:43 -0000 Date: Thu, 25 Jan 2001 00:41:43 +0200 From: Peter Pentchev To: Warner Losh Cc: clefevre@noos.fr, freebsd-arch@FreeBSD.ORG Subject: Re: patch for bsd.lib.mk to create include and lib dirs Message-ID: <20010125004143.B442@ringworld.oblivion.bg> Mail-Followup-To: Warner Losh , clefevre@noos.fr, freebsd-arch@FreeBSD.ORG References: <20010124113902.B332@ringworld.oblivion.bg> <200101242202.f0OM2I961735@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101242202.f0OM2I961735@harmony.village.org>; from imp@harmony.village.org on Wed, Jan 24, 2001 at 03:02:18PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jan 24, 2001 at 03:02:18PM -0700, Warner Losh wrote: > In message Cyrille Lefevre writes: > : would not be better to use install -d instead of mkdir -p which permit, > : if needed alsewhere, to also set ownership ? > > install -d doesn't set the ownership, except on the last component of > the path. It was brought into the tree to be compatible with other > BSDs, and many objects were raised until I made the promise that it > wouldn't be used in "new" code. This happend in 1996: > > revision 1.16 > date: 1996/09/29 06:29:54; author: imp; state: Exp; lines: +56 -5 > Implement -d in install. Update the man page to reflect this change. > > But it looks like install -d has crept into the tree in other places. Well, it's either use install -d, or define MKDIR in sys.mk. Opinions? > But why have a define for this? Why not check to make sure that > directory is missing before trying to create it? I'd rather it was a define, because automatically creating directories might mean new directories *in the source tree* are left out of the hier mtree files. Having a define be turned on only by programs that know they need it could avoid this IMHO. G'luck, Peter -- This sentence was in the past tense. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 24 14:50: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 4719137B400 for ; Wed, 24 Jan 2001 14:49:48 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0OMnb962114; Wed, 24 Jan 2001 15:49:37 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101242249.f0OMnb962114@harmony.village.org> To: Peter Pentchev Subject: Re: patch for bsd.lib.mk to create include and lib dirs Cc: clefevre@noos.fr, freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 25 Jan 2001 00:41:43 +0200." <20010125004143.B442@ringworld.oblivion.bg> References: <20010125004143.B442@ringworld.oblivion.bg> <20010124113902.B332@ringworld.oblivion.bg> <200101242202.f0OM2I961735@harmony.village.org> Date: Wed, 24 Jan 2001 15:49:37 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010125004143.B442@ringworld.oblivion.bg> Peter Pentchev writes: : Well, it's either use install -d, or define MKDIR in sys.mk. : Opinions? install -d is a little better. : > But why have a define for this? Why not check to make sure that : > directory is missing before trying to create it? : : I'd rather it was a define, because automatically creating directories : might mean new directories *in the source tree* are left out of the : hier mtree files. Having a define be turned on only by programs that : know they need it could avoid this IMHO. I guess I'm objecting to creating directories that already exist... But it isn't a huge objection. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 24 15: 2:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (pool83-tch-1.Sofia.0rbitel.net [212.95.170.83]) by hub.freebsd.org (Postfix) with SMTP id 887B737B401 for ; Wed, 24 Jan 2001 15:02:33 -0800 (PST) Received: (qmail 65407 invoked by uid 1000); 24 Jan 2001 23:01:04 -0000 Date: Thu, 25 Jan 2001 01:01:04 +0200 From: Peter Pentchev To: Warner Losh Cc: clefevre@noos.fr, freebsd-arch@FreeBSD.ORG Subject: Re: patch for bsd.lib.mk to create include and lib dirs Message-ID: <20010125010104.C442@ringworld.oblivion.bg> Mail-Followup-To: Warner Losh , clefevre@noos.fr, freebsd-arch@FreeBSD.ORG References: <20010125004143.B442@ringworld.oblivion.bg> <20010124113902.B332@ringworld.oblivion.bg> <200101242202.f0OM2I961735@harmony.village.org> <20010125004143.B442@ringworld.oblivion.bg> <200101242249.f0OMnb962114@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101242249.f0OMnb962114@harmony.village.org>; from imp@harmony.village.org on Wed, Jan 24, 2001 at 03:49:37PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jan 24, 2001 at 03:49:37PM -0700, Warner Losh wrote: > In message <20010125004143.B442@ringworld.oblivion.bg> Peter Pentchev writes: > : Well, it's either use install -d, or define MKDIR in sys.mk. > : Opinions? > > install -d is a little better. > > : > But why have a define for this? Why not check to make sure that > : > directory is missing before trying to create it? > : > : I'd rather it was a define, because automatically creating directories > : might mean new directories *in the source tree* are left out of the > : hier mtree files. Having a define be turned on only by programs that > : know they need it could avoid this IMHO. > > I guess I'm objecting to creating directories that already exist... > But it isn't a huge objection. Yes, it's true that if a directory does exist, install -d -o -g will chown it to the new owner; but it will still be left mode 755, which should be enough for most header files' and libraries' dirs. G'luck, Peter -- This sentence contradicts itself - or rather - well, no, actually it doesn't! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 24 15:39:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id F197737B400 for ; Wed, 24 Jan 2001 15:39:24 -0800 (PST) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel3.hp.com (Postfix) with ESMTP id 0329CAF9; Wed, 24 Jan 2001 15:39:23 -0800 (PST) Received: from cup.hp.com (gauss.cup.hp.com [15.28.97.152]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id PAA25097; Wed, 24 Jan 2001 15:38:07 -0800 (PST) Message-ID: <3A6F675F.1434C601@cup.hp.com> Date: Wed, 24 Jan 2001 15:38:07 -0800 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Peter Pentchev Cc: Warner Losh , clefevre@noos.fr, freebsd-arch@FreeBSD.ORG Subject: Re: patch for bsd.lib.mk to create include and lib dirs References: <20010124113902.B332@ringworld.oblivion.bg> <200101242202.f0OM2I961735@harmony.village.org> <20010125004143.B442@ringworld.oblivion.bg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Pentchev wrote: > > > But why have a define for this? Why not check to make sure that > > directory is missing before trying to create it? > > I'd rather it was a define, because automatically creating directories > might mean new directories *in the source tree* are left out of the > hier mtree files. I don't understand this. There's a problem when the library is being installed. This either means that the directory has not been added in Makefile.inc1 or that the mtree files need to be updated. In both cases, creating the directory obfuscates a bug. The proper fix would be to add the directory to wherever it had to be created in the first place. Right? -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 25 1:16:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id 56C8137B400 for ; Thu, 25 Jan 2001 01:16:20 -0800 (PST) Received: (qmail 1811 invoked by uid 1000); 25 Jan 2001 09:14:40 -0000 Date: Thu, 25 Jan 2001 11:14:40 +0200 From: Peter Pentchev To: Marcel Moolenaar Cc: Warner Losh , clefevre@noos.fr, freebsd-arch@FreeBSD.ORG Subject: Re: patch for bsd.lib.mk to create include and lib dirs Message-ID: <20010125111440.A578@ringworld.oblivion.bg> Mail-Followup-To: Marcel Moolenaar , Warner Losh , clefevre@noos.fr, freebsd-arch@FreeBSD.ORG References: <20010124113902.B332@ringworld.oblivion.bg> <200101242202.f0OM2I961735@harmony.village.org> <20010125004143.B442@ringworld.oblivion.bg> <3A6F675F.1434C601@cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A6F675F.1434C601@cup.hp.com>; from marcel@cup.hp.com on Wed, Jan 24, 2001 at 03:38:07PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jan 24, 2001 at 03:38:07PM -0800, Marcel Moolenaar wrote: > Peter Pentchev wrote: > > > > > But why have a define for this? Why not check to make sure that > > > directory is missing before trying to create it? > > > > I'd rather it was a define, because automatically creating directories > > might mean new directories *in the source tree* are left out of the > > hier mtree files. > > I don't understand this. There's a problem when the library is being > installed. This either means that the directory has not been added in > Makefile.inc1 or that the mtree files need to be updated. In both cases, > creating the directory obfuscates a bug. The proper fix would be to add > the directory to wherever it had to be created in the first place. > Right? That's just what I meant - creating the directory automatically could (and probably would) obfuscate bugs in the FreeBSD source tree. As I stated in my original post though, this patch is meant for outside software packages which might still like to use bsd.lib.mk, install their stuff in /usr/local or such, and have the install fail because no one has created /usr/local/include/outsidepkg/. It is for packages like this that I want this define - packages which know they shall be creating directories no hier file has catered for, and which have to explicitly specify CREATEDESTDIRS=yes. And once again, yes, I know this can be done by overriding the beforeinstall target, but this requires knowledge of the inner workings of bsd.lib.mk - namely, explicitly invoking ${MAKE} _includeinstall. I suspect _includeinstall has that underscore for a reason ;) G'luck, Peter -- I am the meaning of this sentence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 25 10:35:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id 9FF1337B402 for ; Thu, 25 Jan 2001 10:35:06 -0800 (PST) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel3.hp.com (Postfix) with ESMTP id D38FDB87; Thu, 25 Jan 2001 10:35:05 -0800 (PST) Received: from cup.hp.com (gauss.cup.hp.com [15.28.97.152]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id KAA25484; Thu, 25 Jan 2001 10:35:04 -0800 (PST) Message-ID: <3A7071D8.F67B35BF@cup.hp.com> Date: Thu, 25 Jan 2001 10:35:04 -0800 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Peter Pentchev Cc: Warner Losh , clefevre@noos.fr, freebsd-arch@FreeBSD.ORG Subject: Re: patch for bsd.lib.mk to create include and lib dirs References: <20010124113902.B332@ringworld.oblivion.bg> <200101242202.f0OM2I961735@harmony.village.org> <20010125004143.B442@ringworld.oblivion.bg> <3A6F675F.1434C601@cup.hp.com> <20010125111440.A578@ringworld.oblivion.bg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Pentchev wrote: > > As I stated in my original post though, this patch is meant for outside > software packages which might still like to use bsd.lib.mk, install > their stuff in /usr/local or such, and have the install fail because > no one has created /usr/local/include/outsidepkg/. I somehow think our *.mk files are unsuitable for a wide audience. They seem to be made very specificly targeted for the FreeBSD source tree. Making the change is a signal that we promote/support the use of these files outside the source tree and I don't think we can deliver. This normally ends up in endless hackery until someone does a rewrite. > And once again, yes, I know this can be done by overriding the > beforeinstall target, but this requires knowledge of the inner workings > of bsd.lib.mk - namely, explicitly invoking ${MAKE} _includeinstall. > I suspect _includeinstall has that underscore for a reason ;) Hmmm, yes. I see what you mean. beforeinstall should have been an (empty) leaf dependency for it to be easily overridable. If we ever want to rewrite the *.mk files, these hacks will very likely go away and break their use outside the source tree. Other than this, if noone objects or has any good alternatives, don't let me stop you from making the change. -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 25 10:59:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 6FB3337B6AF for ; Thu, 25 Jan 2001 10:59:06 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0PIuA972448; Thu, 25 Jan 2001 11:56:10 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101251856.f0PIuA972448@harmony.village.org> To: Marcel Moolenaar Subject: Re: patch for bsd.lib.mk to create include and lib dirs Cc: Peter Pentchev , clefevre@noos.fr, freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 25 Jan 2001 10:35:04 PST." <3A7071D8.F67B35BF@cup.hp.com> References: <3A7071D8.F67B35BF@cup.hp.com> <20010124113902.B332@ringworld.oblivion.bg> <200101242202.f0OM2I961735@harmony.village.org> <20010125004143.B442@ringworld.oblivion.bg> <3A6F675F.1434C601@cup.hp.com> <20010125111440.A578@ringworld.oblivion.bg> Date: Thu, 25 Jan 2001 11:56:09 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3A7071D8.F67B35BF@cup.hp.com> Marcel Moolenaar writes: : If we ever want to rewrite the *.mk files, these hacks will very likely : go away and break their use outside the source tree. Other than this, if : noone objects or has any good alternatives, don't let me stop you from : making the change. We at Timing Solutins use tsc.FOO.mk that includes bsd.FOO.mk and maybe adds some tsc specific things to it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 25 11:24:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id 1B21237B6B4 for ; Thu, 25 Jan 2001 11:23:50 -0800 (PST) Received: (qmail 2126 invoked by uid 1000); 25 Jan 2001 19:22:19 -0000 Date: Thu, 25 Jan 2001 21:22:19 +0200 From: Peter Pentchev To: Marcel Moolenaar Cc: Warner Losh , clefevre@noos.fr, freebsd-arch@FreeBSD.ORG Subject: Re: patch for bsd.lib.mk to create include and lib dirs Message-ID: <20010125212219.D1122@ringworld.oblivion.bg> Mail-Followup-To: Marcel Moolenaar , Warner Losh , clefevre@noos.fr, freebsd-arch@FreeBSD.ORG References: <20010124113902.B332@ringworld.oblivion.bg> <200101242202.f0OM2I961735@harmony.village.org> <20010125004143.B442@ringworld.oblivion.bg> <3A6F675F.1434C601@cup.hp.com> <20010125111440.A578@ringworld.oblivion.bg> <3A7071D8.F67B35BF@cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A7071D8.F67B35BF@cup.hp.com>; from marcel@cup.hp.com on Thu, Jan 25, 2001 at 10:35:04AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 25, 2001 at 10:35:04AM -0800, Marcel Moolenaar wrote: > Peter Pentchev wrote: > > > > As I stated in my original post though, this patch is meant for outside > > software packages which might still like to use bsd.lib.mk, install > > their stuff in /usr/local or such, and have the install fail because > > no one has created /usr/local/include/outsidepkg/. > > I somehow think our *.mk files are unsuitable for a wide audience. They > seem to be made very specificly targeted for the FreeBSD source tree. > Making the change is a signal that we promote/support the use of these > files outside the source tree and I don't think we can deliver. This > normally ends up in endless hackery until someone does a rewrite. Hmm.. What I have in mind is primarily an in-house application, which used to use a gmake Makefile with my own clean, depend, etc targets. Then I found out FreeBSD has very well thought-out makefiles. I'm toying with the idea of making a Makefile.bsd for some apps I want to release as ports; but come to think of it, yes, using bsd.*.mk is quite dangerous. And for the in-house app I'm working on - well - I have already made quite a few local source tree patches, adding another one will not be too much of a problem. > > And once again, yes, I know this can be done by overriding the > > beforeinstall target, but this requires knowledge of the inner workings > > of bsd.lib.mk - namely, explicitly invoking ${MAKE} _includeinstall. > > I suspect _includeinstall has that underscore for a reason ;) > > Hmmm, yes. I see what you mean. beforeinstall should have been an > (empty) leaf dependency for it to be easily overridable. > > If we ever want to rewrite the *.mk files, these hacks will very likely > go away and break their use outside the source tree. Other than this, if > noone objects or has any good alternatives, don't let me stop you from > making the change. Well, you almost talked me out of it :) Still, if there's a src committer who thinks this is not all that bad an idea, they might as well go ahead and do it :) G'luck, Peter -- This sentence would be seven words long if it were six words shorter. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 25 12: 0:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id C8F6837B69D; Thu, 25 Jan 2001 12:00:29 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id MAA28189; Thu, 25 Jan 2001 12:56:00 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp05.primenet.com, id smtpdAAAc1aqa3; Thu Jan 25 12:55:52 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id NAA26572; Thu, 25 Jan 2001 13:00:18 -0700 (MST) From: Terry Lambert Message-Id: <200101252000.NAA26572@usr08.primenet.com> Subject: Re: mount options To: adrian@freebsd.org (Adrian Chadd) Date: Thu, 25 Jan 2001 20:00:18 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), freebsd-arch@freebsd.org In-Reply-To: <20010124085920.A2795@roaming.cacheboy.net> from "Adrian Chadd" at Jan 24, 2001 08:59:21 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'll reply to this snippet now, and the rest later today.. > > > > For an FS porting project I'm doing, the mount interface needs > > > to be able to export the mount options back out to userspace, > > > and I'd like to tidy the code up instead of just fudge it for > > > my needs. > > > > The bitmap would be ideal for this. The only arguments which > > would not fall into this are the "what you are mounting" and > > the "where you are mounting it" arguments, which will have to > > be handled seperately, in any case. > > The trouble is that the mount options aren't always going to be > flags which are on or off. They *could* be say, a log device for > seperate FS logging. This doesn't fit inside a bitmap, and I'd have > to have to hack together a seperate sysctl or something just to get > information for this particular FS. I still say parametric data belongs in the superblock or other metadata structure. You change it via "newfs" or "tunefs". The main thing to consider, I think, is that string processing really doesn't belong in the kernel. We are stuck with path component processing, not because we are really stuck with it (like we would be if we had globbing in the kernel), but because the design of the VFS stacking permits an underlying VFS to eat multiple path components. Personally, as far as component processing goes, I like the idea of a path component descriptor list far more than a string anyway, but we'd have to fix the lookup mutual recursion for this to work. That basically leaves sysctl and mount as aggregious examples of string passing and processing that shouldn't be there. Like I said, that's my two cents worth. For four cents worth, we should really think about doing globbing in the kernel, if we are going to be passing strings down, since it's a much, much bigger win to not pass useless data back across the user/kernel boundary if someone is, for example, looking for a list of directories. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 25 12:19:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id A61EB37B698 for ; Thu, 25 Jan 2001 12:19:12 -0800 (PST) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id NAA14599; Thu, 25 Jan 2001 13:16:23 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpdAAAD5ayyC; Thu Jan 25 13:16:12 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id NAA27092; Thu, 25 Jan 2001 13:18:54 -0700 (MST) From: Terry Lambert Message-Id: <200101252018.NAA27092@usr08.primenet.com> Subject: Re: patch for bsd.lib.mk to create include and lib dirs To: roam@orbitel.bg (Peter Pentchev) Date: Thu, 25 Jan 2001 20:18:54 +0000 (GMT) Cc: clefevre@noos.fr, freebsd-arch@FreeBSD.ORG In-Reply-To: <20010124231628.A442@ringworld.oblivion.bg> from "Peter Pentchev" at Jan 24, 2001 11:16:28 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > would not be better to use install -d instead of mkdir -p which permit, > > if needed alsewhere, to also set ownership ? > > D'oh.. great idea! This simplifies things, because there's no need > for the sys.mk patch to define MKDIR; INSTALL is already defined. > > New patch attached. Question: are these changes using portable, or FreeBSD specific options? The reason I ask is because of www.openpackages.org... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 25 12:34:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id 642A037B402 for ; Thu, 25 Jan 2001 12:34:29 -0800 (PST) Received: (qmail 3072 invoked by uid 1000); 25 Jan 2001 20:32:57 -0000 Date: Thu, 25 Jan 2001 22:32:57 +0200 From: Peter Pentchev To: Terry Lambert Cc: clefevre@noos.fr, freebsd-arch@FreeBSD.ORG Subject: Re: patch for bsd.lib.mk to create include and lib dirs Message-ID: <20010125223257.I1122@ringworld.oblivion.bg> Mail-Followup-To: Terry Lambert , clefevre@noos.fr, freebsd-arch@FreeBSD.ORG References: <20010124231628.A442@ringworld.oblivion.bg> <200101252018.NAA27092@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101252018.NAA27092@usr08.primenet.com>; from tlambert@primenet.com on Thu, Jan 25, 2001 at 08:18:54PM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 25, 2001 at 08:18:54PM +0000, Terry Lambert wrote: > > > would not be better to use install -d instead of mkdir -p which permit, > > > if needed alsewhere, to also set ownership ? > > > > D'oh.. great idea! This simplifies things, because there's no need > > for the sys.mk patch to define MKDIR; INSTALL is already defined. > > > > New patch attached. > > Question: are these changes using portable, or FreeBSD specific > options? > > The reason I ask is because of www.openpackages.org... If you mean my patch, it only uses -d, -o and -g. AFAIK, -o and -g are portable; GNU install has -d, I have no experience with install on other platforms. G'luck, Peter -- I am jealous of the first word in this sentence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 25 17:34:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id BBBE737B404 for ; Thu, 25 Jan 2001 17:33:57 -0800 (PST) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.1/8.11.0) with ESMTP id f0Q1Xts23156; Thu, 25 Jan 2001 18:33:56 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.1/8.8.3) with ESMTP id f0Q1WQs13551; Thu, 25 Jan 2001 18:32:26 -0700 (MST) Message-Id: <200101260132.f0Q1WQs13551@billy-club.village.org> To: Terry Lambert Subject: Re: patch for bsd.lib.mk to create include and lib dirs Cc: roam@orbitel.bg (Peter Pentchev), clefevre@noos.fr, freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 25 Jan 2001 20:18:54 GMT." <200101252018.NAA27092@usr08.primenet.com> References: <200101252018.NAA27092@usr08.primenet.com> Date: Thu, 25 Jan 2001 18:32:26 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101252018.NAA27092@usr08.primenet.com> Terry Lambert writes: : Question: are these changes using portable, or FreeBSD specific : options? install -d is standard bsd at this point. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 25 17:34:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 36BB437B69C for ; Thu, 25 Jan 2001 17:34:26 -0800 (PST) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.1/8.11.0) with ESMTP id f0Q1YOs23168; Thu, 25 Jan 2001 18:34:25 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.1/8.8.3) with ESMTP id f0Q1Wus13564; Thu, 25 Jan 2001 18:32:56 -0700 (MST) Message-Id: <200101260132.f0Q1Wus13564@billy-club.village.org> To: Peter Pentchev Subject: Re: patch for bsd.lib.mk to create include and lib dirs Cc: Terry Lambert , clefevre@noos.fr, freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 25 Jan 2001 22:32:57 +0200." <20010125223257.I1122@ringworld.oblivion.bg> References: <20010125223257.I1122@ringworld.oblivion.bg> <20010124231628.A442@ringworld.oblivion.bg> <200101252018.NAA27092@usr08.primenet.com> Date: Thu, 25 Jan 2001 18:32:56 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010125223257.I1122@ringworld.oblivion.bg> Peter Pentchev writes: : If you mean my patch, it only uses -d, -o and -g. AFAIK, -o and -g : are portable; GNU install has -d, I have no experience with install : on other platforms. Install -d was added by me so that we'd be more compatible with OpenBSD and NetBSD makefiles. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 25 18: 7:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 4E85237B400 for ; Thu, 25 Jan 2001 18:07:00 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id VAA111040; Thu, 25 Jan 2001 21:06:57 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <39CD0C1B.324AA1C5@geocities.com> References: <200007060342.UAA23667@beastie.mckusick.com> <39CD0C1B.324AA1C5@geocities.com> Date: Thu, 25 Jan 2001 21:06:55 -0500 To: arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: Snapshots in the Fast Filesystem Cc: Kirk McKusick Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sept 23/2000, Barry Pederson wrote: >On July 05/2000, Kirk McKusick wrote: > > >> I have completed an initial implementation of snapshots for the >> fast filesystem (UFS/FFS). I have put up a tarball on >> >> http://people.freebsd.org/~mckusick/snap.tgz >> >> I am looking for comments and feedback on these changes. I am >> proposing to put them into 5.0-current on Tuesday July 11th >> unless I get feedback indicating that folks are not happy > > with this addition. > > .................... > > So, as you can see, this is definitely alpha-quality code. >> Much remains to be done to make it really useful in >> production systems. But, I wanted to let folks get a chance >> to try it out and start reporting bugs. > > >I've been fooling with this in 5.0-CURRENT, and have have found >it to be a terribly, terribly cool feature. > [...skipping...] > >Lastly, I'm curious if it's possible that snapshots will be MFC'd >into 4.x at some point? or will this be a 5.0 and up only feature? I thought I would stir the waters again and ask how this new feature seems to be working out in -current. Is there much chance of it working with the 4.x-branch of releases? I realize there's a lot of work here, and that it may very well need to be tied into some of the smp-related work in 5.0 (wrt big-locks, etc), so I won't mind if it can't make it any sooner. Mainly I just wanted to reiterate that this sounds like a very cool feature (particularly given how huge disks are getting, a snapshot facility seems like a good use of that spare space), and that I'm looking forward to it whenever it does appear. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 27 13:48:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 153F937B400 for ; Sat, 27 Jan 2001 13:48:27 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0RLmQO28958 for ; Sat, 27 Jan 2001 14:48:26 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101272148.f0RLmQO28958@aslan.scsiguy.com> To: freebsd-arch@freebsd.org Subject: Re: Proposed change to sbuf semantics Date: Sat, 27 Jan 2001 14:48:26 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I guess I'll try this again... I will commit the changes I have for the sbuf interface unless I hear otherwise, 1 week from today. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 27 13:54:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id B0C0837B400 for ; Sat, 27 Jan 2001 13:54:36 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id WAA02760; Sat, 27 Jan 2001 22:54:31 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Justin T. Gibbs" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed change to sbuf semantics References: <200101272148.f0RLmQO28958@aslan.scsiguy.com> From: Dag-Erling Smorgrav Date: 27 Jan 2001 22:54:30 +0100 In-Reply-To: "Justin T. Gibbs"'s message of "Sat, 27 Jan 2001 14:48:26 -0700" Message-ID: Lines: 9 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Justin T. Gibbs" writes: > I will commit the changes I have for the sbuf interface unless > I hear otherwise, 1 week from today. Did you post updated patches for review? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 27 13:59:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id DF50937B400 for ; Sat, 27 Jan 2001 13:59:04 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0RLx0O29435; Sat, 27 Jan 2001 14:59:00 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101272159.f0RLx0O29435@aslan.scsiguy.com> To: Dag-Erling Smorgrav Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed change to sbuf semantics In-Reply-To: Your message of "27 Jan 2001 22:54:30 +0100." Date: Sat, 27 Jan 2001 14:59:00 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >"Justin T. Gibbs" writes: >> I will commit the changes I have for the sbuf interface unless >> I hear otherwise, 1 week from today. > >Did you post updated patches for review? No. From your last comments it seemed you wanted to "take this on", but I never heard anything back. There didn't seem to be any resolution to the issues that were brought up so its not clear that how, if at all, my original patches should be modified. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 27 14:23:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 8E0E137B402 for ; Sat, 27 Jan 2001 14:23:19 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id XAA02862; Sat, 27 Jan 2001 23:23:13 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Justin T. Gibbs" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed change to sbuf semantics References: <200101272159.f0RLx0O29435@aslan.scsiguy.com> From: Dag-Erling Smorgrav Date: 27 Jan 2001 23:23:12 +0100 In-Reply-To: "Justin T. Gibbs"'s message of "Sat, 27 Jan 2001 14:59:00 -0700" Message-ID: Lines: 12 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --=-=-= "Justin T. Gibbs" writes: > >Did you post updated patches for review? > No. [...] Is this acceptable to you? DES -- Dag-Erling Smorgrav - des@ofug.org --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=sbuf.diff Content-Description: sbuf patch Index: sys/kern/subr_sbuf.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_sbuf.c,v retrieving revision 1.1 diff -u -r1.1 subr_sbuf.c --- sys/kern/subr_sbuf.c 2000/12/13 19:51:07 1.1 +++ sys/kern/subr_sbuf.c 2001/01/27 22:15:40 @@ -68,8 +68,10 @@ * big enough to hold at least length characters. */ int -sbuf_new(struct sbuf *s, char *buf, size_t length, int flags) +sbuf_new(struct sbuf *s, char *buf, int length, int flags) { + KASSERT(length >= 0, + ("attempt to create an sbuf of negative length (%d)", length)); KASSERT(flags == 0, (__FUNCTION__ " called with non-zero flags")); KASSERT(s != NULL, @@ -92,7 +94,7 @@ * Set the sbuf's position to an arbitrary value */ int -sbuf_setpos(struct sbuf *s, size_t pos) +sbuf_setpos(struct sbuf *s, int pos) { assert_sbuf_integrity(s); assert_sbuf_state(s, 0); @@ -168,7 +170,7 @@ sbuf_printf(struct sbuf *s, char *fmt, ...) { va_list ap; - size_t len; + int len; assert_sbuf_integrity(s); assert_sbuf_state(s, 0); @@ -212,20 +214,26 @@ } /* - * Finish off an sbuf. + * Check if an sbuf overflowed */ int +sbuf_overflowed(struct sbuf *s) +{ + return SBUF_HASOVERFLOWED(s); +} + +/* + * Finish off an sbuf. + */ +void sbuf_finish(struct sbuf *s) { assert_sbuf_integrity(s); assert_sbuf_state(s, 0); - if (SBUF_HASOVERFLOWED(s)) - return (-1); - s->s_buf[s->s_len++] = '\0'; + SBUF_CLEARFLAG(s, SBUF_OVERFLOWED); SBUF_SETFLAG(s, SBUF_FINISHED); - return (0); } /* @@ -237,22 +245,20 @@ assert_sbuf_integrity(s); assert_sbuf_state(s, SBUF_FINISHED); - if (SBUF_HASOVERFLOWED(s)) - return (NULL); return s->s_buf; } /* * Return the length of the sbuf data. */ -size_t +int sbuf_len(struct sbuf *s) { assert_sbuf_integrity(s); assert_sbuf_state(s, SBUF_FINISHED); if (SBUF_HASOVERFLOWED(s)) - return (0); + return (-1); return s->s_len; } Index: sys/sys/sbuf.h =================================================================== RCS file: /home/ncvs/src/sys/sys/sbuf.h,v retrieving revision 1.1 diff -u -r1.1 sbuf.h --- sys/sys/sbuf.h 2000/12/13 19:51:07 1.1 +++ sys/sys/sbuf.h 2001/01/27 22:15:48 @@ -37,8 +37,8 @@ struct sbuf { char *s_buf; /* storage buffer */ struct sbuf *s_next; /* next in chain */ - size_t s_size; /* size of storage buffer */ - size_t s_len; /* current length of string */ + int s_size; /* size of storage buffer */ + int s_len; /* current length of string */ #define SBUF_AUTOEXTEND 0x00000001 /* automatically extend buffer */ #define SBUF_DYNAMIC 0x00010000 /* s_buf must be freed */ #define SBUF_FINISHED 0x00020000 /* set by sbuf_finish() */ @@ -58,19 +58,21 @@ * Other macros */ #define SBUF_SETFLAG(s, f) do { (s)->s_flags |= (f); } while (0) +#define SBUF_CLEARFLAG(s, f) do { (s)->s_flags &= ~(f); } while (0) /* * API functions */ -int sbuf_new(struct sbuf *s, char *buf, size_t length, int flags); -int sbuf_setpos(struct sbuf *s, size_t pos); +int sbuf_new(struct sbuf *s, char *buf, int length, int flags); +int sbuf_setpos(struct sbuf *s, int pos); int sbuf_cat(struct sbuf *s, char *str); int sbuf_cpy(struct sbuf *s, char *str); int sbuf_printf(struct sbuf *s, char *fmt, ...); int sbuf_putc(struct sbuf *s, int c); -int sbuf_finish(struct sbuf *s); +int sbuf_overflowed(struct sbuf *s); +void sbuf_finish(struct sbuf *s); char *sbuf_data(struct sbuf *s); -size_t sbuf_len(struct sbuf *s); +int sbuf_len(struct sbuf *s); void sbuf_delete(struct sbuf *s); #endif Index: share/man/man9/sbuf.9 =================================================================== RCS file: /home/ncvs/src/share/man/man9/sbuf.9,v retrieving revision 1.2 diff -u -r1.2 sbuf.9 --- share/man/man9/sbuf.9 2000/12/14 09:36:49 1.2 +++ share/man/man9/sbuf.9 2001/01/27 22:19:54 @@ -35,6 +35,7 @@ .Nm sbuf_cpy , .Nm sbuf_printf , .Nm sbuf_putc , +.Nm sbuf_overflowed , .Nm sbuf_finish , .Nm sbuf_data , .Nm sbuf_len , @@ -43,9 +44,9 @@ .Sh SYNOPSIS .Fd #include .Ft int -.Fn sbuf_new "struct sbuf *s" "char *buf" "size_t length" "int flags" +.Fn sbuf_new "struct sbuf *s" "char *buf" "int length" "int flags" .Ft int -.Fn sbuf_setpos "struct sbuf *s" "size_t pos" +.Fn sbuf_setpos "struct sbuf *s" "int pos" .Ft int .Fn sbuf_cat "struct sbuf *s" "char *str" .Ft int @@ -55,10 +56,12 @@ .Ft int .Fn sbuf_putc "struct sbuf *s" "int c" .Ft int +.Fn sbuf_overflowed "struct sbuf *s" +.Ft void .Fn sbuf_finish "struct sbuf *s" .Ft char * .Fn sbuf_data "struct sbuf *s" -.Ft size_t +.Ft int .Fn sbuf_len "struct sbuf *s" .Ft void .Fn sbuf_delete "struct sbuf *s" @@ -149,6 +152,12 @@ at the current position. .Pp The +.Fn sbuf_overflowed +function returns a non-zero value if the +.Fa sbuf +overflowed. +.Pp +The .Fn sbuf_finish function null-terminates the .Fa sbuf @@ -165,8 +174,9 @@ .Fn sbuf_data and .Fn sbuf_len -functions return the actual string and its length, respectively, and -only work on a finished and non-overflowed +functions return the actual string and its length, respectively; +.Fn sbuf_data +only works on a finished .Fa sbuf . .Pp Finally, the @@ -178,12 +188,12 @@ .Sh NOTES If an operation caused an .Fa sbuf -to overflow, most subsequent operations (including -.Fn sbuf_finish ) -on it will fail until the -.Fa sbuf Ns 's -position is reset to a value between 0 and one less than the size of -its storage buffer using +to overflow, most subsequent operations on it will fail until the +.Fa sbuf +is finished using +.Fn sbuf_finish , +or its position is reset to a value between 0 and one less than the +size of its storage buffer using .Fn sbuf_setpos , or it is reinitialized to a sufficiently short string using .Fn sbuf_cpy . @@ -200,17 +210,19 @@ .Fn sbuf_cat , .Fn sbuf_cpy , .Fn sbuf_printf , -.Fn sbuf_putc , and -.Fn sbuf_finish +.Fn sbuf_putc all return \-1 if the buffer overflowed, and zero otherwise. .Pp +.Fn sbuf_overflowed +returns a non-zero value if the buffer overflowed, and zero otherwise. +.Pp .Fn sbuf_data and .Fn sbuf_len return .Dv NULL -and 0, respectively, if the buffer overflowed. +and \-1, respectively, if the buffer overflowed. .Sh SEE ALSO .Xr printf 3 , .Xr strcat 3 , --=-=-=-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 27 14:30:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 7741F37B400 for ; Sat, 27 Jan 2001 14:30:39 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0RMUWO30395; Sat, 27 Jan 2001 15:30:35 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101272230.f0RMUWO30395@aslan.scsiguy.com> To: Dag-Erling Smorgrav Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed change to sbuf semantics In-Reply-To: Your message of "27 Jan 2001 23:23:12 +0100." Date: Sat, 27 Jan 2001 15:30:32 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >Is this acceptable to you? I still would need an "sbuf_empty()" type method. We should also move the macros into the .c file unless there is some compelling reason not to. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 27 14:43:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 9E91B37B400 for ; Sat, 27 Jan 2001 14:43:10 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id XAA02930; Sat, 27 Jan 2001 23:43:02 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Justin T. Gibbs" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed change to sbuf semantics References: <200101272230.f0RMUWO30395@aslan.scsiguy.com> From: Dag-Erling Smorgrav Date: 27 Jan 2001 23:43:02 +0100 In-Reply-To: "Justin T. Gibbs"'s message of "Sat, 27 Jan 2001 15:30:32 -0700" Message-ID: Lines: 12 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --=-=-= "Justin T. Gibbs" writes: > >Is this acceptable to you? > I still would need an "sbuf_empty()" type method. This better? DES -- Dag-Erling Smorgrav - des@ofug.org --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=sbuf.diff Content-Description: sbuf patch Index: sys/kern/subr_sbuf.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_sbuf.c,v retrieving revision 1.1 diff -u -r1.1 subr_sbuf.c --- sys/kern/subr_sbuf.c 2000/12/13 19:51:07 1.1 +++ sys/kern/subr_sbuf.c 2001/01/27 22:41:08 @@ -38,6 +38,23 @@ MALLOC_DEFINE(M_SBUF, "sbuf", "string buffers"); +/* + * Predicates + */ +#define SBUF_ISDYNAMIC(s) ((s)->s_flags & SBUF_DYNAMIC) +#define SBUF_ISFINISHED(s) ((s)->s_flags & SBUF_FINISHED) +#define SBUF_HASOVERFLOWED(s) ((s)->s_flags & SBUF_OVERFLOWED) +#define SBUF_HASROOM(s) ((s)->s_len < (s)->s_size - 1) + +/* + * Set / clear flags + */ +#define SBUF_SETFLAG(s, f) do { (s)->s_flags |= (f); } while (0) +#define SBUF_CLEARFLAG(s, f) do { (s)->s_flags &= ~(f); } while (0) + +/* + * Debugging support + */ #ifdef INVARIANTS static void assert_sbuf_integrity(struct sbuf *s) @@ -68,8 +85,10 @@ * big enough to hold at least length characters. */ int -sbuf_new(struct sbuf *s, char *buf, size_t length, int flags) +sbuf_new(struct sbuf *s, char *buf, int length, int flags) { + KASSERT(length >= 0, + ("attempt to create an sbuf of negative length (%d)", length)); KASSERT(flags == 0, (__FUNCTION__ " called with non-zero flags")); KASSERT(s != NULL, @@ -89,10 +108,23 @@ } /* + * Clear an sbuf and reset its position + */ +void +sbuf_clear(struct sbuf *s) +{ + assert_sbuf_integrity(s); + + SBUF_CLEARFLAG(s, SBUF_FINISHED); + SBUF_CLEARFLAG(s, SBUF_OVERFLOWED); + s->s_len = 0; +} + +/* * Set the sbuf's position to an arbitrary value */ int -sbuf_setpos(struct sbuf *s, size_t pos) +sbuf_setpos(struct sbuf *s, int pos) { assert_sbuf_integrity(s); assert_sbuf_state(s, 0); @@ -138,7 +170,7 @@ assert_sbuf_integrity(s); assert_sbuf_state(s, 0); - s->s_len = 0; + sbuf_clear(s); return (sbuf_cat(s, str)); } @@ -168,7 +200,7 @@ sbuf_printf(struct sbuf *s, char *fmt, ...) { va_list ap; - size_t len; + int len; assert_sbuf_integrity(s); assert_sbuf_state(s, 0); @@ -212,20 +244,26 @@ } /* - * Finish off an sbuf. + * Check if an sbuf overflowed */ int +sbuf_overflowed(struct sbuf *s) +{ + return SBUF_HASOVERFLOWED(s); +} + +/* + * Finish off an sbuf. + */ +void sbuf_finish(struct sbuf *s) { assert_sbuf_integrity(s); assert_sbuf_state(s, 0); - if (SBUF_HASOVERFLOWED(s)) - return (-1); - s->s_buf[s->s_len++] = '\0'; + SBUF_CLEARFLAG(s, SBUF_OVERFLOWED); SBUF_SETFLAG(s, SBUF_FINISHED); - return (0); } /* @@ -237,22 +275,20 @@ assert_sbuf_integrity(s); assert_sbuf_state(s, SBUF_FINISHED); - if (SBUF_HASOVERFLOWED(s)) - return (NULL); return s->s_buf; } /* * Return the length of the sbuf data. */ -size_t +int sbuf_len(struct sbuf *s) { assert_sbuf_integrity(s); assert_sbuf_state(s, SBUF_FINISHED); if (SBUF_HASOVERFLOWED(s)) - return (0); + return (-1); return s->s_len; } Index: sys/sys/sbuf.h =================================================================== RCS file: /home/ncvs/src/sys/sys/sbuf.h,v retrieving revision 1.1 diff -u -r1.1 sbuf.h --- sys/sys/sbuf.h 2000/12/13 19:51:07 1.1 +++ sys/sys/sbuf.h 2001/01/27 22:35:52 @@ -37,8 +37,8 @@ struct sbuf { char *s_buf; /* storage buffer */ struct sbuf *s_next; /* next in chain */ - size_t s_size; /* size of storage buffer */ - size_t s_len; /* current length of string */ + int s_size; /* size of storage buffer */ + int s_len; /* current length of string */ #define SBUF_AUTOEXTEND 0x00000001 /* automatically extend buffer */ #define SBUF_DYNAMIC 0x00010000 /* s_buf must be freed */ #define SBUF_FINISHED 0x00020000 /* set by sbuf_finish() */ @@ -47,30 +47,19 @@ }; /* - * Predicates - */ -#define SBUF_ISDYNAMIC(s) ((s)->s_flags & SBUF_DYNAMIC) -#define SBUF_ISFINISHED(s) ((s)->s_flags & SBUF_FINISHED) -#define SBUF_HASOVERFLOWED(s) ((s)->s_flags & SBUF_OVERFLOWED) -#define SBUF_HASROOM(s) ((s)->s_len < (s)->s_size - 1) - -/* - * Other macros - */ -#define SBUF_SETFLAG(s, f) do { (s)->s_flags |= (f); } while (0) - -/* * API functions */ -int sbuf_new(struct sbuf *s, char *buf, size_t length, int flags); -int sbuf_setpos(struct sbuf *s, size_t pos); +int sbuf_new(struct sbuf *s, char *buf, int length, int flags); +void sbuf_clear(struct sbuf *s); +int sbuf_setpos(struct sbuf *s, int pos); int sbuf_cat(struct sbuf *s, char *str); int sbuf_cpy(struct sbuf *s, char *str); int sbuf_printf(struct sbuf *s, char *fmt, ...); int sbuf_putc(struct sbuf *s, int c); -int sbuf_finish(struct sbuf *s); +int sbuf_overflowed(struct sbuf *s); +void sbuf_finish(struct sbuf *s); char *sbuf_data(struct sbuf *s); -size_t sbuf_len(struct sbuf *s); +int sbuf_len(struct sbuf *s); void sbuf_delete(struct sbuf *s); #endif Index: share/man/man9/sbuf.9 =================================================================== RCS file: /home/ncvs/src/share/man/man9/sbuf.9,v retrieving revision 1.2 diff -u -r1.2 sbuf.9 --- share/man/man9/sbuf.9 2000/12/14 09:36:49 1.2 +++ share/man/man9/sbuf.9 2001/01/27 22:40:33 @@ -30,11 +30,13 @@ .Os FreeBSD .Sh NAME .Nm sbuf_new , +.Nm sbuf_clear , .Nm sbuf_setpos , .Nm sbuf_cat , .Nm sbuf_cpy , .Nm sbuf_printf , .Nm sbuf_putc , +.Nm sbuf_overflowed , .Nm sbuf_finish , .Nm sbuf_data , .Nm sbuf_len , @@ -43,9 +45,11 @@ .Sh SYNOPSIS .Fd #include .Ft int -.Fn sbuf_new "struct sbuf *s" "char *buf" "size_t length" "int flags" +.Fn sbuf_new "struct sbuf *s" "char *buf" "int length" "int flags" +.Ft void +.Fn sbuf_clear "struct sbuf *s" .Ft int -.Fn sbuf_setpos "struct sbuf *s" "size_t pos" +.Fn sbuf_setpos "struct sbuf *s" "int pos" .Ft int .Fn sbuf_cat "struct sbuf *s" "char *str" .Ft int @@ -55,10 +59,12 @@ .Ft int .Fn sbuf_putc "struct sbuf *s" "int c" .Ft int +.Fn sbuf_overflowed "struct sbuf *s" +.Ft void .Fn sbuf_finish "struct sbuf *s" .Ft char * .Fn sbuf_data "struct sbuf *s" -.Ft size_t +.Ft int .Fn sbuf_len "struct sbuf *s" .Ft void .Fn sbuf_delete "struct sbuf *s" @@ -102,6 +108,12 @@ characters. .Pp The +.Fn sbuf_clear +function invalidates the contents of the +.Fa sbuf +and resets its position to zero. +.Pp +The .Fn sbuf_setpos function sets the .Fa sbuf Ns 's @@ -129,6 +141,8 @@ with a fresh .Fa sbuf or one which position has been reset to zero with +.Fn sbuf_clear +or .Fn sbuf_setpos . .Pp The @@ -149,6 +163,12 @@ at the current position. .Pp The +.Fn sbuf_overflowed +function returns a non-zero value if the +.Fa sbuf +overflowed. +.Pp +The .Fn sbuf_finish function null-terminates the .Fa sbuf @@ -165,8 +185,9 @@ .Fn sbuf_data and .Fn sbuf_len -functions return the actual string and its length, respectively, and -only work on a finished and non-overflowed +functions return the actual string and its length, respectively; +.Fn sbuf_data +only works on a finished .Fa sbuf . .Pp Finally, the @@ -178,12 +199,14 @@ .Sh NOTES If an operation caused an .Fa sbuf -to overflow, most subsequent operations (including -.Fn sbuf_finish ) -on it will fail until the -.Fa sbuf Ns 's -position is reset to a value between 0 and one less than the size of -its storage buffer using +to overflow, most subsequent operations on it will fail until the +.Fa sbuf +is finished using +.Fn sbuf_finish +or reset using +.Fn sbuf_clear , +or its position is reset to a value between 0 and one less than the +size of its storage buffer using .Fn sbuf_setpos , or it is reinitialized to a sufficiently short string using .Fn sbuf_cpy . @@ -200,17 +223,19 @@ .Fn sbuf_cat , .Fn sbuf_cpy , .Fn sbuf_printf , -.Fn sbuf_putc , and -.Fn sbuf_finish +.Fn sbuf_putc all return \-1 if the buffer overflowed, and zero otherwise. .Pp +.Fn sbuf_overflowed +returns a non-zero value if the buffer overflowed, and zero otherwise. +.Pp .Fn sbuf_data and .Fn sbuf_len return .Dv NULL -and 0, respectively, if the buffer overflowed. +and \-1, respectively, if the buffer overflowed. .Sh SEE ALSO .Xr printf 3 , .Xr strcat 3 , --=-=-=-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 27 14:50: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 8213237B400 for ; Sat, 27 Jan 2001 14:49:44 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0RMneO30798; Sat, 27 Jan 2001 15:49:41 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101272249.f0RMneO30798@aslan.scsiguy.com> To: Dag-Erling Smorgrav Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed change to sbuf semantics In-Reply-To: Your message of "27 Jan 2001 23:43:02 +0100." Date: Sat, 27 Jan 2001 15:49:40 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >--=-=-= > >"Justin T. Gibbs" writes: >> >Is this acceptable to you? >> I still would need an "sbuf_empty()" type method. > >This better? I still need an "sbuf_empty()" type method. 8-) Or did I miss something in the diff? In otherwords, I'd like to be able to test if an sbuf has been written to before it has been finalized so you can do things like: if (sbuf_empty(sbuf) == 0) sbuf_cat(sbuf, ", "); sbuf_ .... -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 27 15: 7: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id D7CE737B400 for ; Sat, 27 Jan 2001 15:06:47 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id AAA03019; Sun, 28 Jan 2001 00:06:38 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Justin T. Gibbs" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed change to sbuf semantics References: <200101272249.f0RMneO30798@aslan.scsiguy.com> From: Dag-Erling Smorgrav Date: 28 Jan 2001 00:06:37 +0100 In-Reply-To: "Justin T. Gibbs"'s message of "Sat, 27 Jan 2001 15:49:40 -0700" Message-ID: Lines: 18 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Justin T. Gibbs" writes: > I still need an "sbuf_empty()" type method. 8-) > Or did I miss something in the diff? Ooh, I thought you meant sbuf_clear(). sbuf_empty() as you put it is a predicate, not a method (or "an observer, not a generator" to use the terms I was taught in type theory class) > In otherwords, I'd like to be able to test if an > sbuf has been written to before it has been finalized > so you can do things like: Well, you can use sbuf_len() for that. It returns 0 if the sbuf is empty, -1 if it overflowed, and the length of its contents otherwise. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 27 15:12:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 94CA837B402 for ; Sat, 27 Jan 2001 15:12:29 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0RNCEi00450; Sat, 27 Jan 2001 15:12:14 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101272312.f0RNCEi00450@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Justin T. Gibbs" Cc: Dag-Erling Smorgrav , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed change to sbuf semantics In-reply-to: Your message of "Sat, 27 Jan 2001 15:49:40 MST." <200101272249.f0RMneO30798@aslan.scsiguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Jan 2001 15:12:14 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > if (sbuf_empty(sbuf) == 0) > sbuf_cat(sbuf, ", "); That should be sbuf_is_empty, since empty is both verb and adjective. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 27 15:50:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id EC8A237B400 for ; Sat, 27 Jan 2001 15:49:56 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0RNnrO31566; Sat, 27 Jan 2001 16:49:53 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101272349.f0RNnrO31566@aslan.scsiguy.com> To: Dag-Erling Smorgrav Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed change to sbuf semantics In-Reply-To: Your message of "28 Jan 2001 00:06:37 +0100." Date: Sat, 27 Jan 2001 16:49:53 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> In otherwords, I'd like to be able to test if an >> sbuf has been written to before it has been finalized >> so you can do things like: > >Well, you can use sbuf_len() for that. It returns 0 if the sbuf is >empty, -1 if it overflowed, and the length of its contents otherwise. I thought that sbuf_len() required a finalized buffer. Did you change this in your patches? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 27 16: 5:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 8693A37B401 for ; Sat, 27 Jan 2001 16:05:21 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id BAA03237; Sun, 28 Jan 2001 01:05:17 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Justin T. Gibbs" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed change to sbuf semantics References: <200101272349.f0RNnrO31566@aslan.scsiguy.com> From: Dag-Erling Smorgrav Date: 28 Jan 2001 01:05:16 +0100 In-Reply-To: "Justin T. Gibbs"'s message of "Sat, 27 Jan 2001 16:49:53 -0700" Message-ID: Lines: 9 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Justin T. Gibbs" writes: > I thought that sbuf_len() required a finalized buffer. Did you change > this in your patches? Yes. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 27 16: 8:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 35F0737B400 for ; Sat, 27 Jan 2001 16:08:24 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0S08JO33601; Sat, 27 Jan 2001 17:08:20 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101280008.f0S08JO33601@aslan.scsiguy.com> To: Dag-Erling Smorgrav Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed change to sbuf semantics In-Reply-To: Your message of "28 Jan 2001 01:05:16 +0100." Date: Sat, 27 Jan 2001 17:08:19 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >"Justin T. Gibbs" writes: >> I thought that sbuf_len() required a finalized buffer. Did you change >> this in your patches? > >Yes. Works for me then. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 27 16:38: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id D659537B400 for ; Sat, 27 Jan 2001 16:37:46 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id BAA03442; Sun, 28 Jan 2001 01:37:42 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Justin T. Gibbs" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed change to sbuf semantics References: <200101280008.f0S08JO33601@aslan.scsiguy.com> From: Dag-Erling Smorgrav Date: 28 Jan 2001 01:37:42 +0100 In-Reply-To: "Justin T. Gibbs"'s message of "Sat, 27 Jan 2001 17:08:19 -0700" Message-ID: Lines: 13 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Justin T. Gibbs" writes: > >"Justin T. Gibbs" writes: > > > I thought that sbuf_len() required a finalized buffer. Did you change > > > this in your patches? > > Yes. > Works for me then. Well, I thought I had, and I even documented the change, but I hadn't, so I did. Should work now. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 27 23:44: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from sandman.sandgate.com (sandman.sandgate.com [38.161.139.2]) by hub.freebsd.org (Postfix) with ESMTP id 9B15E37B400 for ; Sat, 27 Jan 2001 23:43:47 -0800 (PST) Received: from vectra (sandman.sandgate.com [38.161.139.2]) by sandman.sandgate.com (8.11.1/8.11.1) with SMTP id f0S7hgL22352 for ; Sun, 28 Jan 2001 02:43:43 -0500 (EST) From: "Sue Wainer" To: "Freebsd-Arch" Subject: kldunload, and calling uninit function Date: Sun, 28 Jan 2001 02:43:42 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_01C088D4.20638050" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C088D4.20638050 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C088D4.206506F0" ------=_NextPart_001_0007_01C088D4.206506F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I am having problems getting my SYSUNINIT function called when I do a kldunload. I have reduced my source file to containing nothing more than a sysinit and sysunit function, both of which only print out a diagnostic. I believe the setdef files look OK. I have traced through the loader symbol look up function, and the sysinit_set name is there, but the sysuninit_set name is not. I do get the diagnostic printed from my sysinit function. Since there is nothing to the files, I am including the source file try.c, the Makefile, the generated setdef files, and the symbol printouts. The total of everything is less than 1 1/2 pages. Thank you. Sue Wainer wainer@sandgate.com ------=_NextPart_001_0007_01C088D4.206506F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am having = problems getting my=20 SYSUNINIT function called when I do a kldunload.
I have reduced my = source file=20 to containing nothing more than a sysinit and sysunit=20 function,
both of which only = print out a=20 diagnostic. I believe the setdef files look OK. I have=20 traced
through the loader = symbol look=20 up function, and the sysinit_set name is there, but = the
sysuninit_set = name is not.=20 I do get the diagnostic printed from my sysinit = function.
 
Since there is = nothing to the=20 files, I am including the source file try.c, the = Makefile,
the generated = setdef files, and=20 the symbol printouts. The total of everything is less = than
1 1/2=20 pages.
 
Thank = you.
Sue = Wainer
wainer@sandgate.com
 
------=_NextPart_001_0007_01C088D4.206506F0-- ------=_NextPart_000_0006_01C088D4.20638050 Content-Type: application/msword; name="sue.doc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="sue.doc" try.c: #include #include #include static void asic_init_try __P((void *)); static void asic_uninit_try __P((void *)); SYSINIT(asic_try, SI_SUB_PROTO_DOMAIN, SI_ORDER_ANY, asic_init_try, = NULL) SYSUNINIT(asic_try, SI_SUB_PROTO_DOMAIN, SI_ORDER_ANY, asic_uninit_try, = NULL) void asic_init_try(void *dummy) { printf("********GOT INTO INIT***********\n"); } void asic_uninit_try(void *dummy) { printf("********GOT INTO UNINIT***********\n"); } Makefile: SRCS =3D try.c LD +=3D --print-map -Map try.map KMOD =3D try .include setdefs.h: DEFINE_SET(sysinit_set, 1); DEFINE_SET(sysuninit_set, 1); setdef0.c: /* THIS FILE IS GENERATED, DO NOT EDIT. */ #define DEFINE_SET(set, count) \ __asm__(".section .set." #set ",\"aw\""); \ __asm__(".globl " #set); \ __asm__(".type " #set ",@object"); \ __asm__(".p2align 2"); \ __asm__(#set ":"); \ __asm__(".long " #count); \ __asm__(".previous") #include "setdefs.h" /* Contains a `DEFINE_SET' for each set */ setdef1.c: /* THIS FILE IS GENERATED, DO NOT EDIT. */ #define DEFINE_SET(set, count) \ __asm__(".section .set." #set ",\"aw\""); \ __asm__(".long 0"); \ __asm__(".previous") #include "setdefs.h" /* Contains a `DEFINE_SET' for each set */ Diagnostic output when calling linker_elf_symbol_lookup(): Jan 28 02:16:27 BSD2 /kernel.diag: exhaustive search = name=3Dsysuninit_set Jan 28 02:16:27 BSD2 /kernel.diag: now do search Jan 28 02:16:27 BSD2 /kernel.diag: strp=3D Jan 28 02:16:27 BSD2 last message repeated 21 times Jan 28 02:16:27 BSD2 /kernel.diag: strp=3Dsetdef0.c Jan 28 02:16:27 BSD2 /kernel.diag: strp=3Dgcc2_compiled. Jan 28 02:16:27 BSD2 /kernel.diag: strp=3Dtry.c Jan 28 02:16:27 BSD2 /kernel.diag: strp=3Dgcc2_compiled. Jan 28 02:16:27 BSD2 /kernel.diag: strp=3Dasic_try_sys_init Jan 28 02:16:27 BSD2 /kernel.diag: strp=3Dasic_init_try Jan 28 02:16:27 BSD2 /kernel.diag: = strp=3D__set_sysinit_set_sym_asic_try_sys_init Jan 28 02:16:27 BSD2 /kernel.diag: strp=3Dasic_try_sys_uninit Jan 28 02:16:27 BSD2 /kernel.diag: strp=3Dasic_uninit_try Jan 28 02:16:27 BSD2 /kernel.diag: = strp=3D__set_sysuninit_set_sym_asic_try_sys_uninit Jan 28 02:16:27 BSD2 /kernel.diag: strp=3Dsetdef1.c Jan 28 02:16:27 BSD2 /kernel.diag: strp=3Dgcc2_compiled. Jan 28 02:16:27 BSD2 /kernel.diag: strp=3Dprintf Jan 28 02:16:27 BSD2 /kernel.diag: strp=3Dsysinit_set Jan 28 02:16:27 BSD2 /kernel.diag: strp=3D_DYNAMIC Jan 28 02:16:27 BSD2 /kernel.diag: strp=3D_etext Jan 28 02:16:27 BSD2 /kernel.diag: strp=3Dmaintry Jan 28 02:16:27 BSD2 /kernel.diag: strp=3D__bss_start Jan 28 02:16:27 BSD2 /kernel.diag: strp=3D_edata Jan 28 02:16:27 BSD2 /kernel.diag: strp=3D_GLOBAL_OFFSET_TABLE_ Jan 28 02:16:27 BSD2 /kernel.diag: strp=3D_end ------=_NextPart_000_0006_01C088D4.20638050-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message