From owner-freebsd-arch Mon Sep 2 1:33:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D61D737B401; Mon, 2 Sep 2002 01:33:37 -0700 (PDT) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id E106E43E3B; Mon, 2 Sep 2002 01:33:36 -0700 (PDT) (envelope-from corecode@corecode.ath.cx) Received: from fwd02.sul.t-online.de by mailout06.sul.t-online.com with smtp id 17lmeJ-00080Z-00; Mon, 02 Sep 2002 10:33:31 +0200 Received: from spirit.zuhause.stoert.net (320050403952-0001@[80.128.110.56]) by fmrl02.sul.t-online.com with esmtp id 17lme3-0IfOqmC; Mon, 2 Sep 2002 10:33:15 +0200 Received: from terrorfish.uni.stoert.net (terrorfish.uni.stoert.net [10.150.180.178]) by spirit.zuhause.stoert.net (8.11.6/8.11.6) with ESMTP id g828XEk88369; Mon, 2 Sep 2002 10:33:14 +0200 (CEST) (envelope-from corecode@corecode.ath.cx) Received: from terrorfish.uni.stoert.net (localhost [127.0.0.1]) by terrorfish.uni.stoert.net (8.12.5/8.12.5) with ESMTP id g828WNKm000682; Mon, 2 Sep 2002 10:32:23 +0200 (CEST) (envelope-from corecode@terrorfish.uni.stoert.net) Received: (from corecode@localhost) by terrorfish.uni.stoert.net (8.12.5/8.12.5/Submit) id g828WIxx000681; Mon, 2 Sep 2002 10:32:18 +0200 (CEST) (envelope-from corecode) Date: Mon, 2 Sep 2002 10:32:15 +0200 From: "Simon 'corecode' Schubert" To: "David W. Chapman Jr." Cc: rbeyer@rossbeyer.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: package tools into ports/ (was: Re: Bzipped?) Message-Id: <20020902103215.36ae8e3b.corecode@corecode.ath.cx> In-Reply-To: <20020901191937.GI87971@leviathan.inethouston.net> References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> X-Mailer: Sylpheed version 0.8.2claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="h=.qH2weRKqj_b?4" X-Sender: 320050403952-0001@t-dialin.net Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --h=.qH2weRKqj_b?4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 1 Sep 2002 14:19:37 -0500 David W. Chapman Jr. wrote: > > So my question is how can I get pkg_add to work without downloading > > the *.tbz file, bunzipping it and then gzipping it back up so that > > pkg_add can properly digest it? > It should be fixed, you should be able to upgrade your freebsd and > use the new pkg_add actually this would be a much smaller mess if we had the package tools (with source) in the ports tree. best with auto-update... do we want to do this? (x-posting to arch@) cheers simon -- /"\ http://corecode.ath.cx/#donate \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News --h=.qH2weRKqj_b?4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9cyISr5S+dk6z85oRAnQ+AKCNeDrPn2MEdA/DkqjhuZ6S7sKSkQCfSrif 7A2L2J3yN+bdLR5IxZjlLAU= =O/N+ -----END PGP SIGNATURE----- --h=.qH2weRKqj_b?4-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 2 1:58:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DC5A37B400; Mon, 2 Sep 2002 01:58:29 -0700 (PDT) Received: from procyon.firepipe.net (procyon.firepipe.net [198.78.66.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5B1143E42; Mon, 2 Sep 2002 01:58:28 -0700 (PDT) (envelope-from will@csociety.org) Received: by procyon.firepipe.net (Postfix, from userid 1000) id 3F4512144E; Mon, 2 Sep 2002 01:56:54 -0700 (PDT) Date: Mon, 2 Sep 2002 01:56:54 -0700 From: Will Andrews To: Simon 'corecode' Schubert Cc: "David W. Chapman Jr." , rbeyer@rossbeyer.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) Message-ID: <20020902085654.GH2072@procyon.firepipe.net> Mail-Followup-To: Simon 'corecode' Schubert , "David W. Chapman Jr." , rbeyer@rossbeyer.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020902103215.36ae8e3b.corecode@corecode.ath.cx> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Sep 02, 2002 at 10:32:15AM +0200, Simon 'corecode' Schubert wrote: > actually this would be a much smaller mess if we had the package tools > (with source) in the ports tree. best with auto-update... > do we want to do this? > (x-posting to arch@) Yes we do. I plan to do this within the next week or so. Regards, -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 2 11:46:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 722AA37B400; Mon, 2 Sep 2002 11:46:15 -0700 (PDT) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FEEE43E4A; Mon, 2 Sep 2002 11:46:14 -0700 (PDT) (envelope-from mi@aldan.algebra.com) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.12.5/8.12.5) with ESMTP id g82IfXvC034754; Mon, 2 Sep 2002 14:41:33 -0400 (EDT) (envelope-from mi@aldan.algebra.com) Received: by aldan.algebra.com (8.12.5/8.12.5/Submit) id g82IfUOr034753; Mon, 2 Sep 2002 14:41:30 -0400 (EDT) Content-Type: text/plain; charset="iso-8859-1" From: Mikhail Teterin To: Jordan K Hubbard , Kris Kennaway Subject: Re: pkg-routines ignore the recorded md5 checksums Date: Mon, 2 Sep 2002 14:41:24 -0400 User-Agent: KMail/1.4.2 Cc: arch@FreeBSD.org, jkh@FreeBSD.org References: <049EDAFB-BCB3-11D6-A85D-0003938C7B7E@queasyweasel.com> In-Reply-To: <049EDAFB-BCB3-11D6-A85D-0003938C7B7E@queasyweasel.com> X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7whJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Saturday 31 August 2002 03:26 am, Jordan K Hubbard wrote: = Hysterical Raisins. We didn't even think of adding md5 checksums until = about a year or so after the pkg_install tools were done, and there was = concern at that point that adding another @foo directive would create a = set of "new packages" which didn't work with the older package tools. That said, why is ``@comment MD5:....'' any worse than the ``@md5 ....''. really?.. A bit longer, that's it... Unfortunately, I managed to erase my entire Inbox recently, so I have to respond to Jordan's comments about my patches from memory. 1. "Not every comment is an MD5 checksum". Of course it is not! The sscanf's format string will only save those, which start with ``MD5:''. Since the entire structure is bzero-ed a few lines above, if the comment was not an MD5, the pkg->tail->chsum will remain empty. What is quite offensive, Jordan, is that I answered THIS EXACT POINT to you back on April 1st (no fools), in the message with the ID: <200204020311.g323BdFX074921@aldan.algebra.com> You even replied to that message with <23914.1017722020@winston.freebsd.org>, promising to review the patch, although questioning the usefulness of the proposed feature :-( Evidently, the doubts are gone now... 2. "Style(9) violations". I tried. Feel free to correct them if you think, I failed. On the merits of Kris' (more complete) patch-set. 1. It will create packages, earlier versions will not understand -- same problem Jordan faced many years ago... May be, there is nothing wrong with ``@comment ORIGIN:'', "@comment MD5:'' and others instead? Yes, the ``@comment'' will keep growing in the future -- but that's what it is, a comment (a kitchen sink). The precedents are plenty -- lint directives like "/* fallthrough */", JavaDoc, etc. If that "Is Wrong", perhaps, the reading part of the pkg-library should, indeed, be modified to skip through unrecognized lines now, and be tought about this new directives, but the pkg-creation part should continue using the ``@comment'' fields (at least, in -stable) for a good while... 2. It looked to me, like Kris' code allocates memory dynamicly for each checksum encountered. On my system, 94.4% of the lines in /var/db/pkg/*/+CONTENTS have the MD5 line behind them. I'd say, the overhead of malloc-ing in the 94% of the cases will eat the saving of 33 bytes wasted in the remaining 6%. Mmap-ing each +CONTENTS and setting pointers to various places in it (along with the memorizing the string length) would be even better, but requires a lot more re-writing. -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 2 12:15:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E51A37B40A for ; Mon, 2 Sep 2002 12:15:46 -0700 (PDT) Received: from patrocles.silby.com (d76.as29.nwbl0.wi.voyager.net [169.207.73.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id D771843E4A for ; Mon, 2 Sep 2002 12:15:42 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.6/8.12.5) with ESMTP id g82JJ4xP000363 for ; Mon, 2 Sep 2002 14:19:04 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.6/8.12.6/Submit) with ESMTP id g82JJ3gu000360 for ; Mon, 2 Sep 2002 14:19:04 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 2 Sep 2002 14:19:03 -0500 (CDT) From: Mike Silbersack To: arch@freebsd.org Subject: Ethernet packet padding: How much is legal? Message-ID: <20020902140522.W281-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This may be offtopic for the list, but I know that some of you guys will know the answer to this question. :) Despite the overall success of the recent patches to the if_vr driver, Thomas Nystrom and Jean Delvare have continued to search for the root of the problems in the if_vr hardware. In short, they've found that if a 1500 byte packet + a small fragment adding up to approximately 2K are sent in quick succession, the small fragment will be dropped. This appears to be a bug in the Via Rhine hardware, so we're brainstorming on ways to work around this problem. One option we're seriously looking at is padding all ethernet packets within a certain size (400 - 600 bytes in size) up to 600 bytes. This would be done in vr_encap just as padding to minimum packet size is done currently: if (m_head->m_len < VR_MIN_FRAMELEN) { m_new->m_pkthdr.len += VR_MIN_FRAMELEN - m_new->m_len; m_new->m_len = m_new->m_pkthdr.len; } + if ((m_head->m_len > 400) && (m_head->m_len < 800)) { + m_new->m_pkthdr.len = 800; + m_new->m_len = m_new->m_pkthdr.len; + } Thomas says that the above preliminary patch seems to solve the problem, so it looks like a workable solution if we can more exactly determine the range in which we need to pad. (And perhaps only pad if the preceeding packet is a full size frame, etc - this is still being researched.) Anyway, now to the real question: Is adding arbitrary padding like this going to break anything? IP seems content, but will other protocols be broken by extra ethernet padding? Although we don't support too many protocols, the card could be passing all sorts of packets if it is used for bridging. Thanks, Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 2 12:30:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D00E37B400; Mon, 2 Sep 2002 12:30:38 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-64-169-104-37.dsl.lsan03.pacbell.net [64.169.104.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A45843E4A; Mon, 2 Sep 2002 12:30:38 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A3A0A66B8A; Mon, 2 Sep 2002 12:30:34 -0700 (PDT) Date: Mon, 2 Sep 2002 12:30:34 -0700 From: Kris Kennaway To: Will Andrews Cc: Simon 'corecode' Schubert , "David W. Chapman Jr." , rbeyer@rossbeyer.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) Message-ID: <20020902193033.GD55707@xor.obsecurity.org> References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jL2BoiuKMElzg3CS" Content-Disposition: inline In-Reply-To: <20020902085654.GH2072@procyon.firepipe.net> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --jL2BoiuKMElzg3CS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 02, 2002 at 01:56:54AM -0700, Will Andrews wrote: > On Mon, Sep 02, 2002 at 10:32:15AM +0200, Simon 'corecode' Schubert wrote: > > actually this would be a much smaller mess if we had the package tools > > (with source) in the ports tree. best with auto-update... > > do we want to do this? > > (x-posting to arch@) >=20 > Yes we do. I plan to do this within the next week or so. Wait a minute..the package tools are used by other things than the ports collection. I don't think they should be moved out of the source tree. What problem are you really trying to solve here? Kris --jL2BoiuKMElzg3CS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9c7xYWry0BWjoQKURAm8KAKD7hGB1uvXfPiAh/x1TKR9Y5TrMZQCgkqKs w/9aCWwcHwLiaIDsoGxK8tI= =rxwh -----END PGP SIGNATURE----- --jL2BoiuKMElzg3CS-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 2 12:47:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEF8637B409 for ; Mon, 2 Sep 2002 12:47:19 -0700 (PDT) Received: from smtpout.mac.com (smtpout.mac.com [204.179.120.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2ED343E81 for ; Mon, 2 Sep 2002 12:47:13 -0700 (PDT) (envelope-from justin@mac.com) Received: from smtp-relay01.mac.com (smtp-relay01-en1 [10.13.10.224]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id g82JikKw029121 for ; Mon, 2 Sep 2002 12:44:46 -0700 (PDT) Received: from asmtp02.mac.com (asmtp02-qfe3 [10.13.10.66]) by smtp-relay01.mac.com (8.12.1/8.12.1/1.0) with ESMTP id g82JijVw022705 for ; Mon, 2 Sep 2002 12:44:46 -0700 (PDT) Received: from lightnin ([12.234.224.67]) by asmtp02.mac.com (Netscape Messaging Server 4.15) with ESMTP id H1TTIL00.P5R for ; Mon, 2 Sep 2002 12:44:45 -0700 Date: Mon, 2 Sep 2002 14:44:52 -0500 Subject: Re: Ethernet packet padding: How much is legal? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: "Justin C. Walker" To: arch@FreeBSD.ORG Content-Transfer-Encoding: 7bit In-Reply-To: <20020902140522.W281-100000@patrocles.silby.com> Message-Id: <732CD7A3-BEAC-11D6-92CC-000393575CAC@mac.com> X-Mailer: Apple Mail (2.482) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Monday, September 2, 2002, at 02:19 , Mike Silbersack wrote: > This may be offtopic for the list, but I know that some of you guys will > know the answer to this question. :) > > Despite the overall success of the recent patches to the if_vr > driver, Thomas Nystrom and Jean Delvare have continued to search for the > root of the problems in the if_vr hardware. > > In short, they've found that if a 1500 byte packet + a small fragment > adding up to approximately 2K are sent in quick succession, the small > fragment will be dropped. This appears to be a bug in the Via Rhine > hardware, so we're brainstorming on ways to work around this problem. > > One option we're seriously looking at is padding all ethernet packets > within a certain size (400 - 600 bytes in size) up to 600 bytes. This > would be done in vr_encap just as padding to minimum packet size is done > currently: > > > if (m_head->m_len < VR_MIN_FRAMELEN) { > m_new->m_pkthdr.len += VR_MIN_FRAMELEN - > m_new->m_len; > m_new->m_len = m_new->m_pkthdr.len; > } > + if ((m_head->m_len > 400) && (m_head->m_len < 800)) { > + m_new->m_pkthdr.len = 800; > + m_new->m_len = m_new->m_pkthdr.len; > + } > > Thomas says that the above preliminary patch seems to solve the problem, > so it looks like a workable solution if we can more exactly determine > the > range in which we need to pad. (And perhaps only pad if the preceeding > packet is a full size frame, etc - this is still being researched.) > > Anyway, now to the real question: Is adding arbitrary padding like this > going to break anything? IP seems content, but will other protocols be > broken by extra ethernet padding? Although we don't support too many > protocols, the card could be passing all sorts of packets if it is used > for bridging. I'll hazard a guess that it's OK, unless there are protocols that live or die by the inferred length of a packet, rather than information in the packet itself. I don't know of any off-hand. I'm assuming that your code (above) doesn't actually affect internal length indicators, and just transmits extra bytes. For ethernet-2 (like IP/ARP), I can't say for sure that encapsulated protocols all carry their own lengths. IP does (AFAIK; most transport protocols seem to include their own length), and ARP is fixed-size. For 802.x, I believe that the length of the media frame is always present (as opposed to the network packet, as in IP). One thing to be wary of is IPX - it's got a zillion frame formats (OK, four) and at least one doesn't include a media frame length. Of course, there's always the question of whether a receiving driver will get bent out of shape if the stated (in the frame) length is smaller than the received length. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Men are from Earth. | Women are from Earth. | Deal with it. *--------------------------------------*-------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 2 13: 9: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E19C437B400; Mon, 2 Sep 2002 13:08:57 -0700 (PDT) Received: from procyon.firepipe.net (procyon.firepipe.net [198.78.66.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 714F143E4A; Mon, 2 Sep 2002 13:08:57 -0700 (PDT) (envelope-from will@csociety.org) Received: by procyon.firepipe.net (Postfix, from userid 1000) id 201C421452; Mon, 2 Sep 2002 12:43:57 -0700 (PDT) Date: Mon, 2 Sep 2002 12:43:57 -0700 From: Will Andrews To: Kris Kennaway Cc: Will Andrews , Simon 'corecode' Schubert , "David W. Chapman Jr." , rbeyer@rossbeyer.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) Message-ID: <20020902194357.GL2072@procyon.firepipe.net> Mail-Followup-To: Kris Kennaway , Will Andrews , Simon 'corecode' Schubert , "David W. Chapman Jr." , rbeyer@rossbeyer.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <20020902193033.GD55707@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020902193033.GD55707@xor.obsecurity.org> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Sep 02, 2002 at 12:30:34PM -0700, Kris Kennaway wrote: > Wait a minute..the package tools are used by other things than the > ports collection. I don't think they should be moved out of the > source tree. What problem are you really trying to solve here? I am not moving them out. I am trying to solve the problem that people have to upgrade to get package tools that can use bz2'd packages. This is a real problem. Besides which, it's a Very Bad Thing(TM) that ports are not branched but the pkg tools are. As I've already attempted to discuss several times on portmgr the last few weeks (my emails were all ignored), the plan is: 1) Add -V option to pkg_info to facilitate checking its version number. 2) MFC this option. 3) Tarball up the code and make a port using it. 4) Adjust bsd.port.mk to check whether pkg_info -V is of the necessary level (or if it exists) and if not, install the pkgtools port. This approach has been in use by NetBSD for quite some time (well, about 4 years now). See also: http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/pkgtools/pkg_install/ regards, -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 2 17:57:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04E0F37B400 for ; Mon, 2 Sep 2002 17:57:42 -0700 (PDT) Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D2F643E6E for ; Mon, 2 Sep 2002 17:57:41 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0137.cvx40-bradley.dialup.earthlink.net ([216.244.42.137] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17m20f-0001Mp-00; Mon, 02 Sep 2002 17:57:38 -0700 Message-ID: <3D7408C5.21CEBF2C@mindspring.com> Date: Mon, 02 Sep 2002 17:56:37 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Justin C. Walker" Cc: arch@FreeBSD.ORG Subject: Re: Ethernet packet padding: How much is legal? References: <732CD7A3-BEAC-11D6-92CC-000393575CAC@mac.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Justin C. Walker" wrote: > On Monday, September 2, 2002, at 02:19 , Mike Silbersack wrote: > > In short, they've found that if a 1500 byte packet + a small fragment > > adding up to approximately 2K are sent in quick succession, the small > > fragment will be dropped. This appears to be a bug in the Via Rhine > > hardware, so we're brainstorming on ways to work around this problem. > > > > One option we're seriously looking at is padding all ethernet packets > > within a certain size (400 - 600 bytes in size) up to 600 bytes. This > > would be done in vr_encap just as padding to minimum packet size is done > > currently: 1) The patch says "800", not "600"; is this is mistake, or is it just a case of "the more bytes, the merrier"? > > + if ((m_head->m_len > 400) && (m_head->m_len < 800)) { > > + m_new->m_pkthdr.len = 800; [ ... ] > One thing to be wary of is IPX - it's got a zillion frame formats (OK, > four) and at least one doesn't include a media frame length. 16bit NE1000's had the problem that, if you sent an odd number of bytes, that it would byte-swap the last byte with garbage (as far as I know, they still have this problem, unless someone has waved a wand 8-)). It was common practice to fix this in the driver to force sending of an extra byte for odd length packets, when doing the DMA, so that the length was 16bit aligned. This is true for the Windows, DOS, and UnixWare drivers, as they were shipped by Novell. > Of course, there's always the question of whether a receiving driver > will get bent out of shape if the stated (in the frame) length is > smaller than the received length. I was worried about this, too. One byte is generally not a problem, since there are receiver alignment issues, as well, that are "magically" taken care of by allocating the extra space. The only possible issue with such a massive pad (599 bytes as spec'ed, 799 bytes as written) is receives directly to user buffers. I don't think this is going to be a problem unless you have a network processor board, which knows about CP streams before doing the transfer to the user buffer, based on which stream the data is destined for (preemptive protocol processing). Probably the best person to ask on this would be CGD of NetBSD fame, who is currently working at Broadcom, which acquired sibyte (a product wihch does processing like this). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 2 22:18:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5718E37B401; Mon, 2 Sep 2002 22:18:12 -0700 (PDT) Received: from softweyr.com (softweyr.com [65.88.244.127]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60B1243E75; Mon, 2 Sep 2002 22:18:11 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from zaphod ([204.68.178.35] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.35 #1) id 17m647-00066a-00; Mon, 02 Sep 2002 23:17:27 -0600 Message-ID: <3D7445D3.DAA2C9B9@softweyr.com> Date: Mon, 02 Sep 2002 23:17:07 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Will Andrews Cc: Simon 'corecode' Schubert , "David W. Chapman Jr." , rbeyer@rossbeyer.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Will Andrews wrote: > > On Mon, Sep 02, 2002 at 10:32:15AM +0200, Simon 'corecode' Schubert wrote: > > actually this would be a much smaller mess if we had the package tools > > (with source) in the ports tree. best with auto-update... > > do we want to do this? > > (x-posting to arch@) > > Yes we do. I plan to do this within the next week or so. OK, how do you install the package tools package onto the system if it doesn't come with package tools? Please note that I'm all for having the package tools in ports, because it will make the one last feature I want to add to them ever so much easier to build, but we do have to fix this chicken vs. egg probem first. -- "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 Sep 2 22:21:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4953237B400; Mon, 2 Sep 2002 22:21:52 -0700 (PDT) Received: from softweyr.com (softweyr.com [65.88.244.127]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8817943E4A; Mon, 2 Sep 2002 22:21:51 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from zaphod ([204.68.178.35] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.35 #1) id 17m67l-00068U-00; Mon, 02 Sep 2002 23:21:13 -0600 Message-ID: <3D7446BC.E2A0BBBE@softweyr.com> Date: Mon, 02 Sep 2002 23:21:00 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kennaway Cc: Jordan K Hubbard , Mikhail Teterin , arch@FreeBSD.org, jkh@FreeBSD.org Subject: Re: pkg-routines ignore the recorded md5 checksums References: <20020831070918.GA72640@xor.obsecurity.org> <049EDAFB-BCB3-11D6-A85D-0003938C7B7E@queasyweasel.com> <20020831073845.GA74568@xor.obsecurity.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Kris Kennaway wrote: > > On Sat, Aug 31, 2002 at 12:26:51AM -0700, Jordan K Hubbard wrote: > > Hysterical Raisins. We didn't even think of adding md5 checksums until > > about a year or so after the pkg_install tools were done, and there was > > concern at that point that adding another @foo directive would create a > > set of "new packages" which didn't work with the older package tools. > > So it was decided to simply make them a special type of comment, which > > the previous package tools would simply ignore. In hindsight, of > > course... > > Perhaps we should change plist.c to make unrecognised commands > non-fatal, so we can have more flexibility about extending the > commandset in future. And able to turn them off (-q) or default to off with warnings if wanted (-v). ?? -- "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 Sep 3 1: 5: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77F6937B400; Tue, 3 Sep 2002 01:04:57 -0700 (PDT) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F22643E6E; Tue, 3 Sep 2002 01:04:51 -0700 (PDT) (envelope-from corecode@corecode.ath.cx) Received: from fwd00.sul.t-online.de by mailout02.sul.t-online.com with smtp id 17m8fb-0006qy-00; Tue, 03 Sep 2002 10:04:19 +0200 Received: from spirit.zuhause.stoert.net (320050403952-0001@[217.224.172.85]) by fmrl00.sul.t-online.com with esmtp id 17m8fK-0trg2KC; Tue, 3 Sep 2002 10:04:02 +0200 Received: from terrorfish.uni.stoert.net (terrorfish.uni.stoert.net [10.150.180.178]) by spirit.zuhause.stoert.net (8.11.6/8.11.6) with ESMTP id g83840k06789; Tue, 3 Sep 2002 10:04:00 +0200 (CEST) (envelope-from corecode@corecode.ath.cx) Received: from terrorfish.uni.stoert.net (localhost [127.0.0.1]) by terrorfish.uni.stoert.net (8.12.6/8.12.5) with ESMTP id g83832hd000360; Tue, 3 Sep 2002 10:03:02 +0200 (CEST) (envelope-from corecode@terrorfish.uni.stoert.net) Received: (from corecode@localhost) by terrorfish.uni.stoert.net (8.12.6/8.12.5/Submit) id g83831sH000359; Tue, 3 Sep 2002 10:03:01 +0200 (CEST) (envelope-from corecode) Date: Tue, 3 Sep 2002 10:02:58 +0200 From: "Simon 'corecode' Schubert" To: Wes Peters Cc: will@csociety.org, dwcjr@inethouston.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) Message-Id: <20020903100258.068fb3ab.corecode@corecode.ath.cx> In-Reply-To: <3D7445D3.DAA2C9B9@softweyr.com> References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> X-Mailer: Sylpheed version 0.8.2claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.sgSWKhPNK0EhRa" X-Sender: 320050403952-0001@t-dialin.net Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --=.sgSWKhPNK0EhRa Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 02 Sep 2002 23:17:07 -0600 Wes Peters wrote: > OK, how do you install the package tools package onto the system if it > doesn't come with package tools? > > Please note that I'm all for having the package tools in ports, because it > will make the one last feature I want to add to them ever so much easier > to build, but we do have to fix this chicken vs. egg probem first. i don't see a problem here. bsd.port.mk is always available, so we should be able to check for the right pkgtools version. if we need a newer one, just install the port. compilation works without pkgtools and the only one used in post-installation is pkg_create, which in turn should then already be installed on the system... cheers simon -- /"\ http://corecode.ath.cx/#donate \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News --=.sgSWKhPNK0EhRa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9dGy1r5S+dk6z85oRAkdxAJ0Qg5O4X1hnQKwoW7pt0/n+bzi+ggCeKSyY ccXHAYaTBdUBRiSL6GxXVIk= =X3pr -----END PGP SIGNATURE----- --=.sgSWKhPNK0EhRa-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 3 1:29:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F148137B406; Tue, 3 Sep 2002 01:29:22 -0700 (PDT) Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6EB8143E65; Tue, 3 Sep 2002 01:29:21 -0700 (PDT) (envelope-from sheldonh@starjuice.net) Received: from sheldonh by axl.seasidesoftware.co.za with local (Exim 4.10) id 17m8P7-000Bn6-00; Tue, 03 Sep 2002 09:47:17 +0200 Date: Tue, 3 Sep 2002 09:47:17 +0200 From: Sheldon Hearn To: Will Andrews Cc: Kris Kennaway , Simon 'corecode' Schubert , "David W. Chapman Jr." , rbeyer@rossbeyer.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) Message-ID: <20020903074717.GE45029@starjuice.net> Mail-Followup-To: Will Andrews , Kris Kennaway , Simon 'corecode' Schubert , "David W. Chapman Jr." , rbeyer@rossbeyer.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <20020902193033.GD55707@xor.obsecurity.org> <20020902194357.GL2072@procyon.firepipe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020902194357.GL2072@procyon.firepipe.net> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On (2002/09/02 12:43), Will Andrews wrote: > I am not moving them out. I am trying to solve the problem that > people have to upgrade to get package tools that can use bz2'd > packages. This is a real problem. Besides which, it's a Very > Bad Thing(TM) that ports are not branched but the pkg tools are. So make one-time upgrade packages available for the package tools. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 3 5:15:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F09B37B400; Tue, 3 Sep 2002 05:15:51 -0700 (PDT) Received: from procyon.firepipe.net (procyon.firepipe.net [198.78.66.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BDBB43E6E; Tue, 3 Sep 2002 05:15:50 -0700 (PDT) (envelope-from will@csociety.org) Received: by procyon.firepipe.net (Postfix, from userid 1000) id 435F221453; Tue, 3 Sep 2002 05:14:13 -0700 (PDT) Date: Tue, 3 Sep 2002 05:14:13 -0700 From: Will Andrews To: Simon 'corecode' Schubert Cc: Wes Peters , ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) Message-ID: <20020903121413.GN2072@procyon.firepipe.net> Mail-Followup-To: Simon 'corecode' Schubert , Wes Peters , ports@FreeBSD.ORG, arch@FreeBSD.ORG References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> <20020903100258.068fb3ab.corecode@corecode.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020903100258.068fb3ab.corecode@corecode.ath.cx> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Sep 03, 2002 at 10:02:58AM +0200, Simon 'corecode' Schubert wrote: Hitting two birds with one stone, so to speak. > > OK, how do you install the package tools package onto the system if it > > doesn't come with package tools? > > > > Please note that I'm all for having the package tools in ports, because it > > will make the one last feature I want to add to them ever so much easier > > to build, but we do have to fix this chicken vs. egg probem first. Simple. We keep the pkg_install stuff in the src tree. That way, everyone will always have a minimal version installed with the system. If needed, they can then install a newer version via the ports tree. If that newer version is installed, bsd.port.mk will use it instead. Please see NetBSD for an example that they have done for 4 years. It's such a great idea I'm not sure why nobody in FreeBSD did it. > i don't see a problem here. bsd.port.mk is always available, so we > should be able to check for the right pkgtools version. if we need a > newer one, just install the port. compilation works without pkgtools and > the only one used in post-installation is pkg_create, which in turn > should then already be installed on the system... Right, what I said above is a little clearer IMHO. regards, -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 3 6: 4: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F43E37B400; Tue, 3 Sep 2002 06:03:50 -0700 (PDT) Received: from baraca.united.net.ua (ns.united.net.ua [193.111.8.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 302B543E65; Tue, 3 Sep 2002 06:03:47 -0700 (PDT) (envelope-from max@vega.com) Received: from vega.vega.com (root@xDSL-2-2.united.net.ua [193.111.9.226] (may be forged)) by baraca.united.net.ua (8.11.6/8.11.6) with ESMTP id g83D2xs70068; Tue, 3 Sep 2002 16:03:00 +0300 (EEST) (envelope-from max@vega.com) Received: from vega.vega.com (max@localhost [127.0.0.1]) by vega.vega.com (8.12.5/8.12.5) with ESMTP id g83D2xLH008125; Tue, 3 Sep 2002 16:02:59 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: (from max@localhost) by vega.vega.com (8.12.5/8.12.5/Submit) id g83D2bJ1008123; Tue, 3 Sep 2002 16:02:38 +0300 (EEST) Date: Tue, 3 Sep 2002 16:02:37 +0300 From: Maxim Sobolev To: Will Andrews Cc: "Simon 'corecode' Schubert" , Wes Peters , ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) Message-ID: <20020903130237.GB8010@vega.vega.com> References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> <20020903100258.068fb3ab.corecode@corecode.ath.cx> <20020903121413.GN2072@procyon.firepipe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20020903121413.GN2072@procyon.firepipe.net> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Sep 03, 2002 at 05:14:13AM -0700, Will Andrews wrote: > On Tue, Sep 03, 2002 at 10:02:58AM +0200, Simon 'corecode' Schubert wrote: > > Hitting two birds with one stone, so to speak. > > > > OK, how do you install the package tools package onto the system if it > > > doesn't come with package tools? > > > > > > Please note that I'm all for having the package tools in ports, because it > > > will make the one last feature I want to add to them ever so much easier > > > to build, but we do have to fix this chicken vs. egg probem first. > > Simple. We keep the pkg_install stuff in the src tree. That > way, everyone will always have a minimal version installed with > the system. If needed, they can then install a newer version via > the ports tree. If that newer version is installed, bsd.port.mk > will use it instead. > > Please see NetBSD for an example that they have done for 4 years. > It's such a great idea I'm not sure why nobody in FreeBSD did it. I am also thinking about something like that for a quite some time, but it is not quite straightforward to implement correctly. Yes, you can add version reporting into pkg_info and make bsd.port.mk detecting it and installing a new version from ports if it is too outdated. The problem with such approach is that if you will overwrite older versions in /usr/sbin with newer ones, it will work, but only until the next build/installworld (for example if user runs security branch and new patchlevel is available requiring full world rebuild), when the newer ones will be replaced by old ones again. Sure, executing `make something' in ports tree will put things in order again, but what if before that the user will try to delete some package or add a new one using pkg_delete/pkg_add directly? Another approach is to install pkg_tools package into /usr/local, but extend tools in the base system to check version of their counterparts in /usr/local (if installed) and turn themselves into a wrappers if ones in /usr/local are newer than ones in the /usr. This approach is better in the long run, since it allows to not worry about system upgrades, but creates 'chiken and egg' problem, since adding checking/wrapping functionality would require to change pkg_install tools. Therefore, IMO some combined approach is necessary. I have the following (very preliminary) vision of what needs to be done to solve the problem: 1. Assign some form of version number to pkg_install tools. This number should be monotonically increased each time when new functionality is added or older functionality used in bsd.port.mk is changed. Add appropriate reporting routine. 2. Add wrapping functionality into pkg_install tools: on startup of any tool check that a configuration file in some pre-defined location exsists, read it, compare versions here and there and execve() specified file if it is newer, otherwise continue running. Format of file could be very simple, say one line with two words: the first is version number and the second is installation base, i.e. /var/db/pkg_install.wrap: 123455 /usr/local/sbin 3. Create an appropriate pkg_tools port, which will install latest version of the tools and generate configuration file described above when installed FreeBSD version supports finctionality described in (1). If it doesn't, then the port whould just overwrite versions of pkg tools in /usr/sbin with newer versions and warn user about the need to reinstall the port after buildworld/installworld. 4. Add bsd.port.mk bits and pieces for installing that pkg_tools port if system version is too old. I hope that this would be useful for you. Any comments or questions are appreciated. -Maxim > > > i don't see a problem here. bsd.port.mk is always available, so we > > should be able to check for the right pkgtools version. if we need a > > newer one, just install the port. compilation works without pkgtools and > > the only one used in post-installation is pkg_create, which in turn > > should then already be installed on the system... > > Right, what I said above is a little clearer IMHO. > > regards, > -- > wca > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ports" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 3 6:27:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AB6B37B400; Tue, 3 Sep 2002 06:27:38 -0700 (PDT) Received: from leviathan.inethouston.net (leviathan.inethouston.net [66.64.12.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B01D43E4A; Tue, 3 Sep 2002 06:27:38 -0700 (PDT) (envelope-from dwcjr@inethouston.net) Received: from dwcjr (dwcjr [192.168.0.248]) by leviathan.inethouston.net (Postfix) with SMTP id 346DD10DDD3; Tue, 3 Sep 2002 08:27:34 -0500 (CDT) Message-ID: <00a001c2534d$a89576f0$f800a8c0@dwcjr> From: "David W. Chapman Jr." To: "Wes Peters" , "Will Andrews" Cc: "Simon 'corecode' Schubert" , , , References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> Subject: Re: package tools into ports/ (was: Re: Bzipped?) Date: Tue, 3 Sep 2002 08:27:32 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > On Mon, Sep 02, 2002 at 10:32:15AM +0200, Simon 'corecode' Schubert wrote: > > > actually this would be a much smaller mess if we had the package tools > > > (with source) in the ports tree. best with auto-update... > > > do we want to do this? > > > (x-posting to arch@) > > > > Yes we do. I plan to do this within the next week or so. > > OK, how do you install the package tools package onto the system if it > doesn't come with package tools? pkg_add -r pkgtools To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 3 8:20:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 927E337B400; Tue, 3 Sep 2002 08:20:49 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-64-165-226-88.dsl.lsan03.pacbell.net [64.165.226.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3CA943E77; Tue, 3 Sep 2002 08:20:48 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 72E6466B8A; Tue, 3 Sep 2002 08:20:48 -0700 (PDT) Date: Tue, 3 Sep 2002 08:20:48 -0700 From: Kris Kennaway To: "David W. Chapman Jr." Cc: Wes Peters , Will Andrews , Simon 'corecode' Schubert , rbeyer@rossbeyer.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) Message-ID: <20020903152048.GC77952@xor.obsecurity.org> References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> <00a001c2534d$a89576f0$f800a8c0@dwcjr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ghzN8eJ9Qlbqn3iT" Content-Disposition: inline In-Reply-To: <00a001c2534d$a89576f0$f800a8c0@dwcjr> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --ghzN8eJ9Qlbqn3iT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 03, 2002 at 08:27:32AM -0500, David W. Chapman Jr. wrote: > > > On Mon, Sep 02, 2002 at 10:32:15AM +0200, Simon 'corecode' Schubert > wrote: > > > > actually this would be a much smaller mess if we had the package to= ols > > > > (with source) in the ports tree. best with auto-update... > > > > do we want to do this? > > > > (x-posting to arch@) > > > > > > Yes we do. I plan to do this within the next week or so. > > > > OK, how do you install the package tools package onto the system if it > > doesn't come with package tools? >=20 > pkg_add -r pkgtools Go and read the question again. Kris --ghzN8eJ9Qlbqn3iT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9dNNPWry0BWjoQKURAuN/AKDa7N3/iGOtCkSeO1Er71bpReeQOACgmGN2 451Mkm//I0npNxhpPqLAMDs= =bGc/ -----END PGP SIGNATURE----- --ghzN8eJ9Qlbqn3iT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 3 8:22: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32CA237B400; Tue, 3 Sep 2002 08:22:05 -0700 (PDT) Received: from leviathan.inethouston.net (leviathan.inethouston.net [66.64.12.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id A78C043E3B; Tue, 3 Sep 2002 08:22:04 -0700 (PDT) (envelope-from dwcjr@inethouston.net) Received: by leviathan.inethouston.net (Postfix, from userid 1001) id CE39910DE0E; Tue, 3 Sep 2002 10:22:06 -0500 (CDT) Date: Tue, 3 Sep 2002 10:22:06 -0500 From: "David W. Chapman Jr." To: Kris Kennaway Cc: "David W. Chapman Jr." , Wes Peters , Will Andrews , Simon 'corecode' Schubert , rbeyer@rossbeyer.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) Message-ID: <20020903152206.GD67890@leviathan.inethouston.net> Reply-To: "David W. Chapman Jr." Mail-Followup-To: Kris Kennaway , "David W. Chapman Jr." , Wes Peters , Will Andrews , Simon 'corecode' Schubert , rbeyer@rossbeyer.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> <00a001c2534d$a89576f0$f800a8c0@dwcjr> <20020903152048.GC77952@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020903152048.GC77952@xor.obsecurity.org> X-Operating-System: FreeBSD 4.6-STABLE i386 User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > pkg_add -r pkgtools > > Go and read the question again. Ok so maybe pkg_add -r was a wrong choice, but one should still be able to go into /usr/ports/whatever and do a make install or am I still not reading the question correctly? -- David W. Chapman Jr. dwcjr@inethouston.net Raintree Network Services, Inc. dwcjr@freebsd.org FreeBSD Committer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 3 10:34:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D36F37B400; Tue, 3 Sep 2002 10:34:02 -0700 (PDT) Received: from procyon.firepipe.net (procyon.firepipe.net [198.78.66.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7AD643E42; Tue, 3 Sep 2002 10:34:01 -0700 (PDT) (envelope-from will@csociety.org) Received: by procyon.firepipe.net (Postfix, from userid 1000) id D0EA121453; Tue, 3 Sep 2002 10:32:28 -0700 (PDT) Date: Tue, 3 Sep 2002 10:32:28 -0700 From: Will Andrews To: Maxim Sobolev Cc: Will Andrews , Simon 'corecode' Schubert , Wes Peters , ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) Message-ID: <20020903173228.GO2072@procyon.firepipe.net> Mail-Followup-To: Maxim Sobolev , Will Andrews , Simon 'corecode' Schubert , Wes Peters , ports@FreeBSD.ORG, arch@FreeBSD.ORG References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> <20020903100258.068fb3ab.corecode@corecode.ath.cx> <20020903121413.GN2072@procyon.firepipe.net> <20020903130237.GB8010@vega.vega.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020903130237.GB8010@vega.vega.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Sep 03, 2002 at 04:02:37PM +0300, Maxim Sobolev wrote: > I am also thinking about something like that for a quite some time, > but it is not quite straightforward to implement correctly. Yes, you > can add version reporting into pkg_info and make bsd.port.mk detecting > it and installing a new version from ports if it is too outdated. > > The problem with such approach is that if you will overwrite older > versions in /usr/sbin with newer ones, it will work, but only until > the next build/installworld (for example if user runs security branch > and new patchlevel is available requiring full world rebuild), when > the newer ones will be replaced by old ones again. Sure, executing > `make something' in ports tree will put things in order again, but > what if before that the user will try to delete some package or add > a new one using pkg_delete/pkg_add directly? Yes.. that was never my plan. > Another approach is to install pkg_tools package into /usr/local, but > extend tools in the base system to check version of their counterparts > in /usr/local (if installed) and turn themselves into a wrappers if > ones in /usr/local are newer than ones in the /usr. This approach is > better in the long run, since it allows to not worry about system > upgrades, but creates 'chiken and egg' problem, since adding > checking/wrapping functionality would require to change pkg_install > tools. This wouldn't be a problem if PATH was set to give priority to /usr/local and /usr/X11R6 over /usr. Unfortunately, that is another bug in FreeBSD. The above solution could certainly help the situation, especially for new users. However, we can "workaround" it by hardcoding exec*()'s of other pkg_* to their locations in /usr/local in the pkg_install port. > Therefore, IMO some combined approach is necessary. I have the following > (very preliminary) vision of what needs to be done to solve the > problem: > > 1. Assign some form of version number to pkg_install tools. This > number should be monotonically increased each time when new > functionality is added or older functionality used in bsd.port.mk > is changed. Add appropriate reporting routine. Agreed. > 2. Add wrapping functionality into pkg_install tools: on startup > of any tool check that a configuration file in some pre-defined > location exsists, read it, compare versions here and there and > execve() specified file if it is newer, otherwise continue running. > Format of file could be very simple, say one line with two words: > the first is version number and the second is installation base, i.e. > /var/db/pkg_install.wrap: > > 123455 /usr/local/sbin Agreed. > 3. Create an appropriate pkg_tools port, which will install latest > version of the tools and generate configuration file described above > when installed FreeBSD version supports finctionality described > in (1). If it doesn't, then the port whould just overwrite versions of > pkg tools in /usr/sbin with newer versions and warn user about the > need to reinstall the port after buildworld/installworld. The latest version is of some debate. I think that people installing from ports should get the -STABLE version, so that we can still test things on -CURRENT. After sufficient testing, MFC the bits and regenerate the pkg_install tarball and update the port. > 4. Add bsd.port.mk bits and pieces for installing that pkg_tools port > if system version is too old. Agreed. > I hope that this would be useful for you. Any comments or questions > are appreciated. Yes, I think the procedure you have described here is optimal. How about we divide up the task and meet back here? Which ones do you want to take? I'll take the others. Regards, -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 3 10:37:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7BC937B400; Tue, 3 Sep 2002 10:37:26 -0700 (PDT) Received: from procyon.firepipe.net (procyon.firepipe.net [198.78.66.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79E5D43E65; Tue, 3 Sep 2002 10:37:26 -0700 (PDT) (envelope-from will@csociety.org) Received: by procyon.firepipe.net (Postfix, from userid 1000) id E2C7421453; Tue, 3 Sep 2002 10:35:53 -0700 (PDT) Date: Tue, 3 Sep 2002 10:35:53 -0700 From: Will Andrews To: Kris Kennaway , "David W. Chapman Jr." , Wes Peters Cc: ports@FreeBSD.org, arch@FreeBSD.org Subject: Re: package tools into ports/ (was: Re: Bzipped?) Message-ID: <20020903173553.GP2072@procyon.firepipe.net> Mail-Followup-To: Kris Kennaway , "David W. Chapman Jr." , Wes Peters , ports@FreeBSD.org, arch@FreeBSD.org References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> <00a001c2534d$a89576f0$f800a8c0@dwcjr> <20020903152048.GC77952@xor.obsecurity.org> <20020903152206.GD67890@leviathan.inethouston.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020903152206.GD67890@leviathan.inethouston.net> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Sep 03, 2002 at 10:22:06AM -0500, David W. Chapman Jr. wrote: > Ok so maybe pkg_add -r was a wrong choice, but one should still be > able to go into /usr/ports/whatever and do a make install or am I > still not reading the question correctly? Actually, you must understand that under Wes' predicament, that is: removing pkg_install, you can't use ports. Ports create fake packages upon install and that requires pkg_create to do. However, I already stated that Wes' predicament doesn't exist under the plan. regards, -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 3 10:38:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BE4137B400; Tue, 3 Sep 2002 10:38:17 -0700 (PDT) Received: from procyon.firepipe.net (procyon.firepipe.net [198.78.66.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD48D43E42; Tue, 3 Sep 2002 10:38:16 -0700 (PDT) (envelope-from will@csociety.org) Received: by procyon.firepipe.net (Postfix, from userid 1000) id 56D6821453; Tue, 3 Sep 2002 10:36:44 -0700 (PDT) Date: Tue, 3 Sep 2002 10:36:44 -0700 From: Will Andrews To: Kris Kennaway Cc: "David W. Chapman Jr." , Wes Peters , Will Andrews , Simon 'corecode' Schubert , rbeyer@rossbeyer.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) Message-ID: <20020903173644.GQ2072@procyon.firepipe.net> Mail-Followup-To: Kris Kennaway , "David W. Chapman Jr." , Wes Peters , Will Andrews , Simon 'corecode' Schubert , rbeyer@rossbeyer.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> <00a001c2534d$a89576f0$f800a8c0@dwcjr> <20020903152048.GC77952@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020903152048.GC77952@xor.obsecurity.org> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Sep 03, 2002 at 08:20:48AM -0700, Kris Kennaway wrote: > > > OK, how do you install the package tools package onto the system if it > > > doesn't come with package tools? > > > > pkg_add -r pkgtools > > Go and read the question again. Actually, his answer makes perfect sense. We are *NOT* removing pkg_install from the source tree. :-) Regards, -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 3 12:20:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D6A037B400 for ; Tue, 3 Sep 2002 12:20:08 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09AF543E6A for ; Tue, 3 Sep 2002 12:20:08 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020903192007.HBPC19514.rwcrmhc52.attbi.com@InterJet.elischer.org>; Tue, 3 Sep 2002 19:20:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA13258; Tue, 3 Sep 2002 12:08:20 -0700 (PDT) Date: Tue, 3 Sep 2002 12:08:19 -0700 (PDT) From: Julian Elischer To: Alfred Perlstein Cc: arch@freebsd.org Subject: Re: Process/thread states. In-Reply-To: <20020827000404.GM96154@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 26 Aug 2002, Alfred Perlstein wrote: > * Julian Elischer [020826 17:00] wrote: > > > > Ok so I've mentionned this to a few peopel at different times and not got > > any real feedback/pushback.. time fopr a wider audience. > ... > > e.g. something like: (yeah I know its messy but...): > > > > > > > > #define TD_ST_SUSPQ 0x01 /* uses runq field */ > > #define TD_ST_RUNQ 0x02 /* uses runq field */ > > #define TD_ST_RUNNING 0x03 /* uses no (virtual) field */ > > #define TD_ST_MTX 0x04 /* uses mtx field */ > > #define TD_ST_RQ_MASK 0x07 /* mask of non sleep states */ > > #define TD_ST_SLPQ 0x08 /* uses slpq field */ > > enum thread_state { > > TDS_UNQUEUED = 0x00, > > TDS_SLP = TD_ST_SLPQ, > > TDS_RUNQ = TD_ST_RUNQ, > > TDS_RUNNING = TD_ST_RUNNING, > > TDS_SUSPENDED = TD_ST_SUSPQ, > > TDS_MTX = TD_ST_MTX, > > TDS_SUSP_SLP = TD_ST_SUSPQ|TD_ST_SLPQ, > > TDS_RUN_SLP = TD_ST_RUNNING|TD_ST_SLPQ, > > TDS_RUNQ_SLP = TD_ST_RUNQ|TD_ST_SLPQ, > > TDS_MTX_SLP = TD_ST_MTX|TD_ST_SLPQ, > > TDS_SWAPPING = TD_ST_SLPQ|TD_ST_RQ_MASK + 1, > > TDS_IWAIT, /* needed? */ > > TDS_SURPLUS /* needed? */ > > }; > > This seems good, another option would be to mostly expose things > through a functional interface, like proc_set_swapping() or something. In fact this is sort of what we have ended up doing.. we have refactored the thread states as shown above (aproximatly) but we have changed all teh cases where thread state is manipulated or tested to use a set of macros, such as: TD_SET_SUSPENDED(td) TD_SET_RUNQ(td) TD_SET_RUNNING(td) TD_SET_SLP(td) TD_CLR_SLP(td) TD_SET_SLEEPING(td) TD_SET_SWAPPED(td) and tests TD_ON_SUSPQ(td) TD_ON_RUNQ(td) TD_IS_RUNNING(td) TD_ON_SLPQ(td) TD_IS_SLEEPING(td) TD_IS_SWAPPED(td) this changes a lot of code to look like this: - } else if (td->td_wchan != NULL) { + } else if (TD_ON_SLPQ(td)) { or - if (td->td_state == TDS_SLP) { + if (TD_IS_SLEEPING(td)) { + TD_CLR_SLP(td); or - KASSERT((td->td_state != TDS_RUNQ), ("setrunqueue: bad thread state")); - td->td_state = TDS_RUNQ; + KASSERT(!TD_ON_RUNQ(td), ("setrunqueue: bad thread state")); + TD_SET_RUNQ(td); or more importantly: - } else if (td->td_wchan != NULL) { - if (td->td_state == TDS_SLP) /* XXXKSE */ + } else if (TD_ON_SLPQ(td)) { + if (TD_IS_SLEEPING(td)) /* XXXKSE */ which I think is a lot more readable. Once the macros are in place we actually have the oportunity to tune the implementations somewhat, and as KSE operations are implemented and mode code is changed to handle multiple threads the chances that we will need to tune the states will increase. Macros will insulate us from some of this.. Is there anyone who thinks that doing these changes is a REALLY BAD IDEA? We'd (david and I) like to go ahead and provide a general patch to implement this, for others to peruse, but we'd like to hear if there will be screaming first before we do more work on it.. > > -Alfred > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 3 12:27:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF2CC37B400 for ; Tue, 3 Sep 2002 12:27:17 -0700 (PDT) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D5F943E3B for ; Tue, 3 Sep 2002 12:27:17 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 5693 invoked from network); 3 Sep 2002 19:27:17 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 3 Sep 2002 19:27:17 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.5/8.12.5) with ESMTP id g83JRFBv004367; Tue, 3 Sep 2002 15:27:15 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 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, 03 Sep 2002 15:27:15 -0400 (EDT) From: John Baldwin To: Julian Elischer Subject: Re: Process/thread states. Cc: arch@freebsd.org, Alfred Perlstein Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 03-Sep-2002 Julian Elischer wrote: > We'd (david and I) like to go ahead and provide a general patch to > implement this, for others to peruse, but we'd like to > hear if there will be screaming first before we do more work on it.. Please be consistent. You have SLEEPING, so I would use SLEEP instead of SLP. Also, I would use CLEAR instead of CLR. Personally I don't want to have to use Caps Lock to write kernel code and I find the kernel shouting at me about thread states to be a bit much (I don't see why just using == to check a thread state is all that hard). Just please at least be consistent if you are going to uglify things. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "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 Sep 3 13:20:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82B4737B400; Tue, 3 Sep 2002 13:20:10 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0E5043E84; Tue, 3 Sep 2002 13:20:08 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020903202008.MGSV12451.rwcrmhc51.attbi.com@InterJet.elischer.org>; Tue, 3 Sep 2002 20:20:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA14635; Tue, 3 Sep 2002 13:07:41 -0700 (PDT) Date: Tue, 3 Sep 2002 13:07:39 -0700 (PDT) From: Julian Elischer To: John Baldwin Cc: arch@freebsd.org, Alfred Perlstein Subject: Re: Process/thread states. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 3 Sep 2002, John Baldwin wrote: > > On 03-Sep-2002 Julian Elischer wrote: > > We'd (david and I) like to go ahead and provide a general patch to > > implement this, for others to peruse, but we'd like to > > hear if there will be screaming first before we do more work on it.. > > Please be consistent. You have SLEEPING, so I would use SLEEP instead > of SLP. Also, I would use CLEAR instead of CLR. Personally I don't > want to have to use Caps Lock to write kernel code and I find the > kernel shouting at me about thread states to be a bit much (I don't > see why just using == to check a thread state is all that hard). because it in some cases actually becomes: (due to the fact thst you can be on the sleep queue AND teh run queue) #define TD_ON_RUNQ(td) (((td)->td_state & TD_BASE_MASK) == TD_ST_RUNQ) as you have to separate out the sleep queue bit. Ther eis a possibility that these states may get worse when thread suspensions and swapping are added to the picture. A thread can be swapped (as part of the process), AND sleeping AND suspended. Do you really want to type that sort of test everywhere? By making it a macro we can keep the implementation of this state hidden. e.g if we move the RUNQ part of the state to td_flags to make it independently testable, the rest of the code doesn;t have to know how we optimised this. (we are discussing this exact change now). similarly for swapped.. or other states. > Just please at least be consistent if you are going to uglify things. I prefer TD_ON_RUNQ(td) to (((td)->td_state & TD_BASESTATE_MASK) == TD_ST_RUNQ) > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 3 15:17: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A40C137B400; Tue, 3 Sep 2002 15:16:49 -0700 (PDT) Received: from baraca.united.net.ua (ns.united.net.ua [193.111.8.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94B4543E6E; Tue, 3 Sep 2002 15:16:45 -0700 (PDT) (envelope-from max@vega.com) Received: from vega.vega.com (root@xDSL-2-2.united.net.ua [193.111.9.226] (may be forged)) by baraca.united.net.ua (8.11.6/8.11.6) with ESMTP id g83MGKs90105; Wed, 4 Sep 2002 01:16:20 +0300 (EEST) (envelope-from max@vega.com) Received: from vega.vega.com (max@localhost [127.0.0.1]) by vega.vega.com (8.12.5/8.12.5) with ESMTP id g83MGMLH009613; Wed, 4 Sep 2002 01:16:22 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: (from max@localhost) by vega.vega.com (8.12.5/8.12.5/Submit) id g83MGDXj009612; Wed, 4 Sep 2002 01:16:13 +0300 (EEST) Date: Wed, 4 Sep 2002 01:16:13 +0300 From: Maxim Sobolev To: Will Andrews , "Simon 'corecode' Schubert" , Wes Peters , ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) Message-ID: <20020903221613.GC9384@vega.vega.com> References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> <20020903100258.068fb3ab.corecode@corecode.ath.cx> <20020903121413.GN2072@procyon.firepipe.net> <20020903130237.GB8010@vega.vega.com> <20020903173228.GO2072@procyon.firepipe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20020903173228.GO2072@procyon.firepipe.net> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Sep 03, 2002 at 10:32:28AM -0700, Will Andrews wrote: > On Tue, Sep 03, 2002 at 04:02:37PM +0300, Maxim Sobolev wrote: > > I am also thinking about something like that for a quite some time, > > but it is not quite straightforward to implement correctly. Yes, you > > can add version reporting into pkg_info and make bsd.port.mk detecting > > it and installing a new version from ports if it is too outdated. > > > > The problem with such approach is that if you will overwrite older > > versions in /usr/sbin with newer ones, it will work, but only until > > the next build/installworld (for example if user runs security branch > > and new patchlevel is available requiring full world rebuild), when > > the newer ones will be replaced by old ones again. Sure, executing > > `make something' in ports tree will put things in order again, but > > what if before that the user will try to delete some package or add > > a new one using pkg_delete/pkg_add directly? > > Yes.. that was never my plan. > > > Another approach is to install pkg_tools package into /usr/local, but > > extend tools in the base system to check version of their counterparts > > in /usr/local (if installed) and turn themselves into a wrappers if > > ones in /usr/local are newer than ones in the /usr. This approach is > > better in the long run, since it allows to not worry about system > > upgrades, but creates 'chiken and egg' problem, since adding > > checking/wrapping functionality would require to change pkg_install > > tools. > > This wouldn't be a problem if PATH was set to give priority to > /usr/local and /usr/X11R6 over /usr. Unfortunately, that is > another bug in FreeBSD. > > The above solution could certainly help the situation, especially > for new users. > > However, we can "workaround" it by hardcoding exec*()'s of other > pkg_* to their locations in /usr/local in the pkg_install port. > > > Therefore, IMO some combined approach is necessary. I have the following > > (very preliminary) vision of what needs to be done to solve the > > problem: > > > > 1. Assign some form of version number to pkg_install tools. This > > number should be monotonically increased each time when new > > functionality is added or older functionality used in bsd.port.mk > > is changed. Add appropriate reporting routine. > > Agreed. > > > 2. Add wrapping functionality into pkg_install tools: on startup > > of any tool check that a configuration file in some pre-defined > > location exsists, read it, compare versions here and there and > > execve() specified file if it is newer, otherwise continue running. > > Format of file could be very simple, say one line with two words: > > the first is version number and the second is installation base, i.e. > > /var/db/pkg_install.wrap: > > > > 123455 /usr/local/sbin > > Agreed. > > > 3. Create an appropriate pkg_tools port, which will install latest > > version of the tools and generate configuration file described above > > when installed FreeBSD version supports finctionality described > > in (1). If it doesn't, then the port whould just overwrite versions of > > pkg tools in /usr/sbin with newer versions and warn user about the > > need to reinstall the port after buildworld/installworld. > > The latest version is of some debate. I think that people > installing from ports should get the -STABLE version, so that we > can still test things on -CURRENT. After sufficient testing, MFC > the bits and regenerate the pkg_install tarball and update the port. > > > 4. Add bsd.port.mk bits and pieces for installing that pkg_tools port > > if system version is too old. > > Agreed. > > > I hope that this would be useful for you. Any comments or questions > > are appreciated. > > Yes, I think the procedure you have described here is optimal. > How about we divide up the task and meet back here? Which ones > do you want to take? I'll take the others. I could take src/usr.sbin/pkg_install part, leaving bsd.port.mk and actual pkg_tools (pkg_install?) port to you. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 3 15:19:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87BC737B400; Tue, 3 Sep 2002 15:19:34 -0700 (PDT) Received: from procyon.firepipe.net (procyon.firepipe.net [198.78.66.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 207DD43E42; Tue, 3 Sep 2002 15:19:34 -0700 (PDT) (envelope-from will@csociety.org) Received: by procyon.firepipe.net (Postfix, from userid 1000) id BA8A721453; Tue, 3 Sep 2002 15:18:00 -0700 (PDT) Date: Tue, 3 Sep 2002 15:18:00 -0700 From: Will Andrews To: Maxim Sobolev Cc: Will Andrews , Simon 'corecode' Schubert , Wes Peters , ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) Message-ID: <20020903221800.GE48750@procyon.firepipe.net> Mail-Followup-To: Maxim Sobolev , Will Andrews , Simon 'corecode' Schubert , Wes Peters , ports@FreeBSD.ORG, arch@FreeBSD.ORG References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> <20020903100258.068fb3ab.corecode@corecode.ath.cx> <20020903121413.GN2072@procyon.firepipe.net> <20020903130237.GB8010@vega.vega.com> <20020903173228.GO2072@procyon.firepipe.net> <20020903221613.GC9384@vega.vega.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020903221613.GC9384@vega.vega.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Sep 04, 2002 at 01:16:13AM +0300, Maxim Sobolev wrote: > I could take src/usr.sbin/pkg_install part, leaving bsd.port.mk and > actual pkg_tools (pkg_install?) port to you. OK. regards, -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 3 20:25: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EDF937B401 for ; Tue, 3 Sep 2002 20:24:53 -0700 (PDT) Received: from out5.mx.nwbl.wi.voyager.net (out5.mx.nwbl.wi.voyager.net [169.207.3.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2AD143E3B for ; Tue, 3 Sep 2002 20:24:52 -0700 (PDT) (envelope-from silby@silby.com) Received: from pop2.nwbl.wi.voyager.net (pop2.nwbl.wi.voyager.net [169.207.3.115]) by out5.mx.nwbl.wi.voyager.net (8.12.3/8.11.4/1.7) with ESMTP id g843Opr8007956; Tue, 3 Sep 2002 22:24:51 -0500 Received: from [10.1.1.6] (d107.as14.nwbl0.wi.voyager.net [169.207.134.107]) by pop2.nwbl.wi.voyager.net (8.10.2/8.10.2) with ESMTP id g843Oo189745; Tue, 3 Sep 2002 22:24:50 -0500 (CDT) Date: Tue, 3 Sep 2002 22:28:22 -0500 (CDT) From: Mike Silbersack To: Terry Lambert Cc: "Justin C. Walker" , Subject: Re: Ethernet packet padding: How much is legal? Message-ID: <20020903222619.H8025-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG (Sorry for the odd quoting, I'm not subscribed to arch, and am cutting/pasting.) --- 1) The patch says "800", not "600"; is this is mistake, or is it just a case of "the more bytes, the merrier"? --- The more the merrier; it was just a proof of concept patch, and the limits will certainly change. --- Probably the best person to ask on this would be CGD of NetBSD fame, who is currently working at Broadcom, which acquired sibyte ; (a product wihch does processing like this). -- Terry --- Ok, I'll look him up and ask. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 3 23:35: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82AD337B400; Tue, 3 Sep 2002 23:35:06 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3838443E3B; Tue, 3 Sep 2002 23:35:05 -0700 (PDT) (envelope-from bde@zeta.org.au) 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 GAA22570; Wed, 4 Sep 2002 06:34:57 GMT Date: Wed, 4 Sep 2002 16:42:19 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Julian Elischer Cc: John Baldwin , , Alfred Perlstein Subject: Re: Process/thread states. In-Reply-To: Message-ID: <20020904163927.N385-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 3 Sep 2002, Julian Elischer wrote: > On Tue, 3 Sep 2002, John Baldwin wrote: > > > ... (I don't > > see why just using == to check a thread state is all that hard). > > because it in some cases actually becomes: (due to the fact thst you > can be on the sleep queue AND teh run queue) > #define TD_ON_RUNQ(td) (((td)->td_state & TD_BASE_MASK) == TD_ST_RUNQ) > as you have to separate out the sleep queue bit. > ... > Do you really want to type that sort of test everywhere? > By making it a macro we can keep the implementation of this state > hidden. e.g if we move the RUNQ part of the state to td_flags > to make it independently testable, the rest of the code doesn;t have to > know how we optimised this. (we are discussing this exact change now). > similarly for swapped.. or other states. Just don't forget to change it back to a simple test once you have debugged and optimized it :-). One virtue of inline code is that it inhibits expansion of huge macros to huger ones. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 4 0: 0:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8813537B400; Wed, 4 Sep 2002 00:00:37 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id D113843E75; Wed, 4 Sep 2002 00:00:36 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020904070036.SGFO13899.sccrmhc02.attbi.com@InterJet.elischer.org>; Wed, 4 Sep 2002 07:00:36 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA29330; Tue, 3 Sep 2002 23:57:34 -0700 (PDT) Date: Tue, 3 Sep 2002 23:57:33 -0700 (PDT) From: Julian Elischer To: Bruce Evans Cc: John Baldwin , arch@FreeBSD.ORG, Alfred Perlstein Subject: Re: Process/thread states. In-Reply-To: <20020904163927.N385-100000@gamplex.bde.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 4 Sep 2002, Bruce Evans wrote: > On Tue, 3 Sep 2002, Julian Elischer wrote: > > > On Tue, 3 Sep 2002, John Baldwin wrote: > > > > > ... (I don't > > > see why just using == to check a thread state is all that hard). > > > > because it in some cases actually becomes: (due to the fact thst you > > can be on the sleep queue AND teh run queue) > > #define TD_ON_RUNQ(td) (((td)->td_state & TD_BASE_MASK) == TD_ST_RUNQ) > > as you have to separate out the sleep queue bit. > > ... > > Do you really want to type that sort of test everywhere? > > By making it a macro we can keep the implementation of this state > > hidden. e.g if we move the RUNQ part of the state to td_flags > > to make it independently testable, the rest of the code doesn;t have to > > know how we optimised this. (we are discussing this exact change now). > > similarly for swapped.. or other states. > > Just don't forget to change it back to a simple test once you have debugged > and optimized it :-). One virtue of inline code is that it inhibits expansion > of huge macros to huger ones. that is true, but I want to be able to make the Macros as fast and simple as possible. If I have to edit 300 places to rearange bits to achieve this it gets prohibative. If it's a macro that just says what I am trying to achieve, and how that is achieved is hidden, then I can rejig the macro to achieve that in the most efficient manner as different ideas abotu threading get tried and rejected or accepted... Do you mean edit it again and remove all the macros later? There is a certain readbility that comes with a concise macro name that is not present (from the point of view of the lay reader) in the more crude direct tests. If (TD_ON_SLEEPQ(td) && TD_IS_RUNNING(td)) is presently expressed as: if ((td->td_wchan != 0) && td->td_state == TDS_RUNNING) I know which of those two I'd rather see if I was a new developer trying to work out what the heck is going on.. A great increase in readability could be made by simply adding the macro TD_ON_SLEEPQ(td), but if we have that then we might as well have the rest of the macros as well. > > Bruce > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 4 2:54:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E1F637B400; Wed, 4 Sep 2002 02:54:36 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F89643E65; Wed, 4 Sep 2002 02:54:35 -0700 (PDT) (envelope-from bde@zeta.org.au) 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 JAA14464; Wed, 4 Sep 2002 09:54:28 GMT Date: Wed, 4 Sep 2002 20:01:50 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Julian Elischer Cc: John Baldwin , , Alfred Perlstein Subject: Re: Process/thread states. In-Reply-To: Message-ID: <20020904194643.H914-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 3 Sep 2002, Julian Elischer wrote: > On Wed, 4 Sep 2002, Bruce Evans wrote: > > > On Tue, 3 Sep 2002, Julian Elischer wrote: > > [... thread classification macros] > > Just don't forget to change it back to a simple test once you have debugged > > and optimized it :-). One virtue of inline code is that it inhibits expansion > > of huge macros to huger ones. > Do you mean edit it again and remove all the macros later? Yes, if you can get the state checks back to be simple ones (which is a reasonable goal for both efficiency and simplicity). > There is a certain readbility that comes with a concise macro name > that is not present (from the point of view of the lay reader) > in the more crude direct tests. > > If (TD_ON_SLEEPQ(td) && TD_IS_RUNNING(td)) > is presently expressed as: > > if ((td->td_wchan != 0) && td->td_state == TDS_RUNNING) > > I know which of those two I'd rather see if I was a new developer trying > to work out what the heck is going on.. I'd rather see (td->td_state == TDS_RUNNING). Only very lay readers don't want to know anything about the details hidden by the macro. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 4 9:20:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18D3337B400; Wed, 4 Sep 2002 09:20:25 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id C528443E6E; Wed, 4 Sep 2002 09:20:24 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020904162024.HZSR19514.rwcrmhc52.attbi.com@InterJet.elischer.org>; Wed, 4 Sep 2002 16:20:24 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA31446; Wed, 4 Sep 2002 09:18:06 -0700 (PDT) Date: Wed, 4 Sep 2002 09:18:06 -0700 (PDT) From: Julian Elischer To: Bruce Evans Cc: John Baldwin , arch@FreeBSD.ORG, Alfred Perlstein Subject: Re: Process/thread states. In-Reply-To: <20020904194643.H914-100000@gamplex.bde.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 4 Sep 2002, Bruce Evans wrote: > > I'd rather see (td->td_state == TDS_RUNNING). Only very lay readers don't > want to know anything about the details hidden by the macro. Assembler would be the ultimate in that direction.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 4 9:27:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D3C837B400; Wed, 4 Sep 2002 09:27:12 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id D678A43E72; Wed, 4 Sep 2002 09:27:11 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id A17A1AE147; Wed, 4 Sep 2002 09:27:11 -0700 (PDT) Date: Wed, 4 Sep 2002 09:27:11 -0700 From: Alfred Perlstein To: Julian Elischer Cc: Bruce Evans , John Baldwin , arch@FreeBSD.ORG Subject: Re: Process/thread states. Message-ID: <20020904162711.GO73747@elvis.mu.org> References: <20020904194643.H914-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Julian Elischer [020904 09:20] wrote: > > > On Wed, 4 Sep 2002, Bruce Evans wrote: > > > > > I'd rather see (td->td_state == TDS_RUNNING). Only very lay readers don't > > want to know anything about the details hidden by the macro. > > Assembler would be the ultimate in that direction.. I have to agree with Julian on this one, it's really annoying when we have bugs just because someone forgot that not only is foo->flags == SOMETHING, but that foo->enum is SOMETHINGELSE. Since the macros will be pretty simple for the most part and the compiler is somewhat smart about constant folding let's do it the way that Julian suggested. -- -Alfred Perlstein [alfred@freebsd.org] [#bsdcode/efnet/irc.prison.net] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 4 9:41:52 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48CE337B405; Wed, 4 Sep 2002 09:41:45 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AFDD43E88; Wed, 4 Sep 2002 09:40:14 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020904164013.KGPV13899.sccrmhc02.attbi.com@InterJet.elischer.org>; Wed, 4 Sep 2002 16:40:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA31530; Wed, 4 Sep 2002 09:26:47 -0700 (PDT) Date: Wed, 4 Sep 2002 09:26:46 -0700 (PDT) From: Julian Elischer To: Bruce Evans Cc: John Baldwin , arch@FreeBSD.ORG, Alfred Perlstein Subject: Re: Process/thread states. In-Reply-To: <20020904194643.H914-100000@gamplex.bde.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 4 Sep 2002, Bruce Evans wrote: > > I'd rather see (td->td_state == TDS_RUNNING). Only very lay readers don't > want to know anything about the details hidden by the macro. The reason I consider using Macros to test and set these states is that several people suggested it as a way to abstract away the possible complications of the states. I'm kind of curious that almost no-one seems to have comments on this consider it's what I would consider to be prime arguing material. apparently no-one cares any more.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 4 9:53:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E69E37B400 for ; Wed, 4 Sep 2002 09:53:48 -0700 (PDT) Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9803D43E6A for ; Wed, 4 Sep 2002 09:53:47 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 7183 invoked from network); 4 Sep 2002 16:53:35 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail15.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 4 Sep 2002 16:53:35 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.5/8.12.5) with ESMTP id g84GrYBv008141; Wed, 4 Sep 2002 12:53:34 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020904162711.GO73747@elvis.mu.org> Date: Wed, 04 Sep 2002 12:53:34 -0400 (EDT) From: John Baldwin To: Alfred Perlstein Subject: Re: Process/thread states. Cc: arch@FreeBSD.ORG, Bruce Evans , Julian Elischer Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 04-Sep-2002 Alfred Perlstein wrote: > * Julian Elischer [020904 09:20] wrote: >> >> >> On Wed, 4 Sep 2002, Bruce Evans wrote: >> >> > >> > I'd rather see (td->td_state == TDS_RUNNING). Only very lay readers don't >> > want to know anything about the details hidden by the macro. >> >> Assembler would be the ultimate in that direction.. > > I have to agree with Julian on this one, it's really annoying when > we have bugs just because someone forgot that not only is > foo->flags == SOMETHING, but that foo->enum is SOMETHINGELSE. > > Since the macros will be pretty simple for the most part and the > compiler is somewhat smart about constant folding let's do it the > way that Julian suggested. OK. I GUESS NOW I NEED TO TURN ON MY CAPS LOCK AND USE MACROS EVERYTIME I WANT TO CHECK A VARIABLE. if (FOO_BAR_FLAG_IS_SET(f) { PRINT_OUT_INT(FOO_BAZ_FIELD(foo)); PRINT_OUT_STRING(FOO_DESC_FIELD(FOO)); } Yes, that is _much_ better than: if (f->f_flag & FOO_BAR != 0) printf("%d%s", f->f_baz, f->f_desc); -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "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 Wed Sep 4 10: 0:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E56037B400; Wed, 4 Sep 2002 10:00:52 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0128D43E42; Wed, 4 Sep 2002 10:00:52 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id g84H0jlJ041936 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 4 Sep 2002 10:00:47 -0700 (PDT)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <03eb01c25434$9e6113f0$52557f42@errno.com> From: "Sam Leffler" To: "Julian Elischer" , "Bruce Evans" Cc: "John Baldwin" , , "Alfred Perlstein" References: Subject: Re: Process/thread states. Date: Wed, 4 Sep 2002 10:00:45 -0700 Organization: Errno Consulting 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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > On Wed, 4 Sep 2002, Bruce Evans wrote: > > > > > I'd rather see (td->td_state == TDS_RUNNING). Only very lay readers don't > > want to know anything about the details hidden by the macro. > > The reason I consider using Macros to test and set these states is that > several people suggested it as a way to abstract away the possible > complications of the states. I'm kind of curious that almost no-one > seems to have comments on this consider it's what I would consider to be > prime arguing material. > > apparently no-one cares any more.. > I care and I gave you my (few) comments. I consider this sort of thing to be an issue for the person writing the code. If you have resposibility for this work and commit privileges then people should respect that you'll do the right thing. There is a fine line between improving the status quo and obscuring what's going on. Bugs in macros can be extremely difficult to debug because they hide what's really happening. On the other hand they can make code more understandable to the first time reader and insure consistency. As I said above, I think this is really something you need to leave to the judgement of the person writing the code. It's easier to go from macros back to straight code than vice versa. If Julian's willing to do the work to "abstract things" then if the result is too obscure then it's not a big deal to switch back. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 4 10: 3:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69D4B37B411; Wed, 4 Sep 2002 10:03:23 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 344F843E6A; Wed, 4 Sep 2002 10:03:23 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id EE80BAE163; Wed, 4 Sep 2002 10:03:22 -0700 (PDT) Date: Wed, 4 Sep 2002 10:03:22 -0700 From: Alfred Perlstein To: John Baldwin Cc: arch@FreeBSD.ORG, Bruce Evans , Julian Elischer Subject: Re: Process/thread states. Message-ID: <20020904170322.GQ73747@elvis.mu.org> References: <20020904162711.GO73747@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * John Baldwin [020904 09:53] wrote: > > OK. I GUESS NOW I NEED TO TURN ON MY CAPS LOCK AND USE MACROS EVERYTIME > I WANT TO CHECK A VARIABLE. This is an invalid argument, there's no absolute need for them to be capitalized, especially if they are made into inlines. thanks, -- -Alfred Perlstein [alfred@freebsd.org] [#bsdcode/efnet/irc.prison.net] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 4 11:22:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A15437B400; Wed, 4 Sep 2002 11:22:45 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50A1E43E4A; Wed, 4 Sep 2002 11:22:44 -0700 (PDT) (envelope-from bde@zeta.org.au) 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 SAA19828; Wed, 4 Sep 2002 18:22:38 GMT Date: Thu, 5 Sep 2002 04:30:02 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Julian Elischer Cc: John Baldwin , , Alfred Perlstein Subject: Re: Process/thread states. In-Reply-To: Message-ID: <20020905041751.F2483-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 4 Sep 2002, Julian Elischer wrote: > On Wed, 4 Sep 2002, Bruce Evans wrote: > > > > I'd rather see (td->td_state == TDS_RUNNING). Only very lay readers don't > > want to know anything about the details hidden by the macro. > > The reason I consider using Macros to test and set these states is that > several people suggested it as a way to abstract away the possible > complications of the states. I'm kind of curious that almost no-one > seems to have comments on this consider it's what I would consider to be > prime arguing material. > > apparently no-one cares any more.. Macros are easier to write and maintain but harder to read and debug. Especially the maintain and debug parts. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 4 13: 5:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23AEA37B409 for ; Wed, 4 Sep 2002 13:05:08 -0700 (PDT) Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52B5443E4A for ; Wed, 4 Sep 2002 13:05:07 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g84K4r8Z135342; Wed, 4 Sep 2002 16:04:53 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020905041751.F2483-100000@gamplex.bde.org> References: <20020905041751.F2483-100000@gamplex.bde.org> Date: Wed, 4 Sep 2002 16:04:51 -0400 To: Bruce Evans , Julian Elischer From: Garance A Drosihn Subject: Re: Process/thread states. Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 4:30 AM +1000 9/5/02, Bruce Evans wrote: >On Wed, 4 Sep 2002, Julian Elischer wrote: > > > > The reason I consider using Macros to test and set these states is > > that several people suggested it as a way to abstract away the > > possible complications of the states. I'm kind of curious that > > almost no-one seems to have comments on this consider it's what > > I would consider to be prime arguing material. > > >> apparently no-one cares any more.. > >Macros are easier to write and maintain but harder to read and debug. >Especially the maintain and debug parts. Speaking for myself, in my own little tiny corner of the world (printing), one of the biggest problems I have with LPRng is that it has so many macros for everything. You effectively end up with a specialized language which is using cpp as the "compiler", instead of reading plain C code. Every time you're reading along, you have to stop and go back to see "what is this macro REALLY doing?". That's just me, of course -- ymmv. Chances are that I will never ever be debugging the kernel-level code that you're working on, so in that sense I don't want to annoy you with a debate over what you're doing (aka "I don't care"). And obviously I am happy to define the occasional macro when I'm writing code for lpr, but in general I find it frustrating when I'm debugging any code which resorts to macros for too many things. It is particularly bad if the code *sometimes* uses macros to fiddle with a given value, and other times it will operate directly on the value. Thus, the problem isn't that the macro itself is wrong, but that the macro hides a bug which is caused by some *other* code around the macro, which is manipulating the same variables but has no obviously-visible connection to the macro. This is just a matter of me rambling though. At the moment I'm fighting a samba server (running on linux...) which has suddenly decided to crash every six hours (now that our semester has started up), and this topic is a welcome diversion from that extreme irritation... Cheerio. -- Garance Alistair Drosehn = gad@gilead.netel.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 Wed Sep 4 14:40:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4668B37B401; Wed, 4 Sep 2002 14:40:27 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8834C43E42; Wed, 4 Sep 2002 14:40:26 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020904214026.BHQE19514.rwcrmhc52.attbi.com@InterJet.elischer.org>; Wed, 4 Sep 2002 21:40:26 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA32816; Wed, 4 Sep 2002 14:36:54 -0700 (PDT) Date: Wed, 4 Sep 2002 14:36:53 -0700 (PDT) From: Julian Elischer To: Alfred Perlstein Cc: John Baldwin , arch@FreeBSD.ORG, Bruce Evans Subject: Re: Process/thread states. In-Reply-To: <20020904170322.GQ73747@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 4 Sep 2002, Alfred Perlstein wrote: > * John Baldwin [020904 09:53] wrote: > > > > OK. I GUESS NOW I NEED TO TURN ON MY CAPS LOCK AND USE MACROS EVERYTIME > > I WANT TO CHECK A VARIABLE. John, are you objecting to the use of Macros or the use of caps? > > This is an invalid argument, there's no absolute need for them to > be capitalized, especially if they are made into inlines. Well, it's suggested in style(9).. --------------- The names of ``unsafe'' macros (ones that have side effects), and the names of macros for manifest constants, are all in uppercase. --------------- does that cover here? Is it a side-effect of TD_SET_RUNQ if it sets the "on runq" state? or is this juat the primary effect, in which case it is NOT required to be caps. (by my reading). > > thanks, > -- > -Alfred Perlstein [alfred@freebsd.org] [#bsdcode/efnet/irc.prison.net] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 4 15:41:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 210D337B400; Wed, 4 Sep 2002 15:41:40 -0700 (PDT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8871843E4A; Wed, 4 Sep 2002 15:41:39 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.5/8.12.5) id g84MfWt3088386; Wed, 4 Sep 2002 17:41:32 -0500 (CDT) (envelope-from dan) Date: Wed, 4 Sep 2002 17:41:32 -0500 From: Dan Nelson To: Julian Elischer Cc: Alfred Perlstein , John Baldwin , arch@FreeBSD.ORG, Bruce Evans Subject: Re: Process/thread states. Message-ID: <20020904224131.GA58170@dan.emsphone.com> References: <20020904170322.GQ73747@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 5.0-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In the last episode (Sep 04), Julian Elischer said: > Well, it's suggested in style(9).. > --------------- > The names of ``unsafe'' macros (ones that have side effects), and the > names of macros for manifest constants, are all in uppercase. > --------------- > does that cover here? Is it a side-effect of TD_SET_RUNQ if it sets the > "on runq" state? or is this juat the primary effect, in which case > it is NOT required to be caps. (by my reading). I think they mean macros that use their arguments more than once, like #define MAX(a,b) ((a)>(b)?(a):(b)) This macro has side-effects if you call it like c=MAX(getppid(),2). getppid() ends up being called twice and will return the wrong value if your parent exits between the two calls. -- Dan Nelson dnelson@allantgroup.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 4 21:27:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CD0437B400 for ; Wed, 4 Sep 2002 21:27:39 -0700 (PDT) Received: from nic.upatras.gr (nic.upatras.gr [150.140.129.30]) by mx1.FreeBSD.org (Postfix) with SMTP id 0963E43E42 for ; Wed, 4 Sep 2002 21:27:38 -0700 (PDT) (envelope-from keramida@ceid.upatras.gr) Received: (qmail 25096 invoked from network); 5 Sep 2002 04:20:54 -0000 Received: from upnet-dialinpool-23.upatras.gr (HELO hades.hell.gr) (150.140.128.231) by nic.upatras.gr with SMTP; 5 Sep 2002 04:20:54 -0000 Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.6/8.12.6) with ESMTP id g854RYlt011380; Thu, 5 Sep 2002 07:27:34 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from charon@localhost) by hades.hell.gr (8.12.6/8.12.6/Submit) id g854RXS3011379; Thu, 5 Sep 2002 07:27:33 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Thu, 5 Sep 2002 07:27:33 +0300 From: Giorgos Keramidas To: Bruce Evans Cc: Julian Elischer , arch@FreeBSD.ORG Subject: Re: Process/thread states. Message-ID: <20020905042733.GE8069@hades.hell.gr> References: <20020904194643.H914-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020904194643.H914-100000@gamplex.bde.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 2002-09-04 20:01 +0000, Bruce Evans wrote: > On Tue, 3 Sep 2002, Julian Elischer wrote: > > If (TD_ON_SLEEPQ(td) && TD_IS_RUNNING(td)) > > is presently expressed as: > > > > if ((td->td_wchan != 0) && td->td_state == TDS_RUNNING) > > > > I know which of those two I'd rather see if I was a new developer trying > > to work out what the heck is going on.. > > I'd rather see (td->td_state == TDS_RUNNING). Only very lay readers don't > want to know anything about the details hidden by the macro. The mask test is not that bad, when read from someone who has very small experience with this part of the kernel. Or even, checks like: if ((td->td_wchan == 0) && (td->td_state & TDS_RUNNING || td->td_state & TDS_SUSPENDED)) It's not bad to know what is going on `within' the td struct, imho. - Giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 4 22:11:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9722137B400 for ; Wed, 4 Sep 2002 22:11:29 -0700 (PDT) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 361F443E65 for ; Wed, 4 Sep 2002 22:11:29 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0312.cvx40-bradley.dialup.earthlink.net ([216.244.43.57] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17movD-0003zU-00; Wed, 04 Sep 2002 22:11:16 -0700 Message-ID: <3D76E737.B46FDA1E@mindspring.com> Date: Wed, 04 Sep 2002 22:10:15 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Giorgos Keramidas Cc: Bruce Evans , Julian Elischer , arch@FreeBSD.ORG Subject: Re: Process/thread states. References: <20020904194643.H914-100000@gamplex.bde.org> <20020905042733.GE8069@hades.hell.gr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Giorgos Keramidas wrote: > if ((td->td_wchan == 0) && (td->td_state & TDS_RUNNING || > td->td_state & TDS_SUSPENDED)) > > It's not bad to know what is going on `within' the td struct, imho. if ((td->td_wchan == 0) && (td->td_state & (TDS_RUNNING|TDS_SUSPENDED))) is more natural. Neither one of these works properly if there is more than one bit hidden in either of these; you have to get a lot more complicated: if ((td->td_wchan == 0) && ((td->td_state & TDS_RUNNING) == TDS_RUNNING || (td->td_state & TDS_SUSPENDED) == TDS_SUSPENDED)) That *still* doesn't work if, say, TDS_XXX is a superset of the bits in TDS_SUSPENDED. I personally dislike the idea of combined bits, without explicit equality tests. The problem that's trying to be solved here is the one of how do you represent a combinatorial state in a single comparison, and the equivalency of one combinatorial state and another for the purposes of whether or not some code should be run (as in this specific case). Te reality is probably that this state should be explicitly multiplied out in the code, so that it becomes a single value compare. The overall impact on the code of doing this is large, so it seems that people are reluctant to take that step to get a single compare against an explicit state. I've often though it would be useful to have a "switch"-type statement that operated on bit fields in the C language, e.g.: bitset( foo) { case FOO_BIT_ONE: ... case FOO_BIT_TWO: ... case FOO_BIT_THREE: ... default: ... } Until something like that shows up, though, I think we will pretty much have to "lump it", and refactor the code. PS: If anyone adds this, I also vote for the inclusion of an "^^" operator... ;^). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 4 22:40:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5EBF37B401 for ; Wed, 4 Sep 2002 22:40:14 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A55343E4A for ; Wed, 4 Sep 2002 22:40:14 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020905054010.RRAQ1399.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 5 Sep 2002 05:40:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA34525; Wed, 4 Sep 2002 22:35:39 -0700 (PDT) Date: Wed, 4 Sep 2002 22:35:38 -0700 (PDT) From: Julian Elischer To: Giorgos Keramidas Cc: Bruce Evans , arch@FreeBSD.ORG Subject: Re: Process/thread states. In-Reply-To: <20020905042733.GE8069@hades.hell.gr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 5 Sep 2002, Giorgos Keramidas wrote: > On 2002-09-04 20:01 +0000, Bruce Evans wrote: > > On Tue, 3 Sep 2002, Julian Elischer wrote: > > > If (TD_ON_SLEEPQ(td) && TD_IS_RUNNING(td)) > > > is presently expressed as: > > > > > > if ((td->td_wchan != 0) && td->td_state == TDS_RUNNING) > > > > > > I know which of those two I'd rather see if I was a new developer trying > > > to work out what the heck is going on.. > > > > I'd rather see (td->td_state == TDS_RUNNING). Only very lay readers don't > > want to know anything about the details hidden by the macro. > > The mask test is not that bad, when read from someone who has very > small experience with this part of the kernel. Or even, checks like: > > if ((td->td_wchan == 0) && (td->td_state & TDS_RUNNING || > td->td_state & TDS_SUSPENDED)) > > It's not bad to know what is going on `within' the td struct, imho. Are you saying the macros are good or bad? > > - Giorgos > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 4 22:43:50 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C56937B400 for ; Wed, 4 Sep 2002 22:43:46 -0700 (PDT) Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id A18BC43E42 for ; Wed, 4 Sep 2002 22:43:44 -0700 (PDT) (envelope-from keramida@ceid.upatras.gr) Received: from hades.hell.gr (patr530-b223.otenet.gr [212.205.244.231]) by mailsrv.otenet.gr (8.12.4/8.12.4) with ESMTP id g855hUqt025726; Thu, 5 Sep 2002 08:43:31 +0300 (EEST) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.6/8.12.6) with ESMTP id g855hT2m012312; Thu, 5 Sep 2002 08:43:29 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from charon@localhost) by hades.hell.gr (8.12.6/8.12.6/Submit) id g855hT5N012311; Thu, 5 Sep 2002 08:43:29 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Thu, 5 Sep 2002 08:43:29 +0300 From: Giorgos Keramidas To: Julian Elischer Cc: arch@FreeBSD.ORG Subject: Re: Process/thread states. Message-ID: <20020905054329.GN8069@hades.hell.gr> References: <20020905042733.GE8069@hades.hell.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Fingerprint: C1EB 0653 DB8B A557 3829 00F9 D60F 941A 3186 03B6 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 2002-09-04 22:35 +0000, Julian Elischer wrote: > On Thu, 5 Sep 2002, Giorgos Keramidas wrote: > > The mask test is not that bad, when read from someone who has very > > small experience with this part of the kernel. Or even, checks like: > > > > if ((td->td_wchan == 0) && (td->td_state & TDS_RUNNING || > > td->td_state & TDS_SUSPENDED)) > > > > It's not bad to know what is going on `within' the td struct, imho. > > Are you saying the macros are good or bad? Julian, it's up to you to decide. I can read both types of code just as easily. The mbuf code in many parts of the kernel uses both styles, alternating between the two. Allocation is done with M_GET() which is a macro. mbuf.m_flags tests are usually done with explicit checks instead of macros. I am not going to strongly object or favor any of these. They both have their place. It's you, as the implementor, that the ultimate choise lies with. - Giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 4 23:20:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EB9537B400 for ; Wed, 4 Sep 2002 23:20:09 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2955B43E3B for ; Wed, 4 Sep 2002 23:20:09 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020905062008.FSPJ19514.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 5 Sep 2002 06:20:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA34673; Wed, 4 Sep 2002 23:17:40 -0700 (PDT) Date: Wed, 4 Sep 2002 23:17:38 -0700 (PDT) From: Julian Elischer To: Terry Lambert Cc: Giorgos Keramidas , Bruce Evans , arch@FreeBSD.ORG Subject: Re: Process/thread states. In-Reply-To: <3D76E737.B46FDA1E@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 4 Sep 2002, Terry Lambert wrote: > Giorgos Keramidas wrote: > > if ((td->td_wchan == 0) && (td->td_state & TDS_RUNNING || > > td->td_state & TDS_SUSPENDED)) > > > > It's not bad to know what is going on `within' the td struct, imho. > > > > if ((td->td_wchan == 0) && (td->td_state & (TDS_RUNNING|TDS_SUSPENDED))) > > > is more natural. you can not test TDS_RUNNING|TDS_SUSPENDED as they are two states that are mutually exclusive. either the state is one or the other.. they are NOT bits.... however: the state of being on the sleep queue can occur in parallel with the other states, e.g. on the run queue, or running or on the suspend queue. Sleeping is really only being on the sleep queue without any other state taking precedence. This means that to truely represent the queue and run states of a thread the state variable consists of a state field with several values and a separate bit that represents the background reality of it also being on the sleep queue, and thus able to be awoken. There are also possibilities that a thread having been swapped out (as part of a process) that must also be kept orthogonal to whether the thread is suspended or sleeping or runnable. if this really does turn out to be the case REAL thread state tracking requires 3 orthognal tests. For this reason I want touse a macro to allow, 1/ experimentation on how thisis best done 2/ hiding of the sometime messy tests with meaningful named abstractions. > > Neither one of these works properly if there is more than > one bit hidden in either of these; you have to get a lot more > complicated: > this one could be real: if ((td->td_wchan == 0) && (td->td_state & TD_ST_MASK == TDS_UNQUEUED) && ((td->td_state & TDS_SWAPPED) == 0)) setrunnable(td); I'd rather make it if (td_on_sleepq_only(td) && !td_is_swapped(td)) setrunnable(td); Isn't that somewhat easier to understand? > > That *still* doesn't work if, say, TDS_XXX is a superset of the > bits in TDS_SUSPENDED. > > I personally dislike the idea of combined bits, without explicit > equality tests. I have no idea what you mean by that. > > The problem that's trying to be solved here is the one of how > do you represent a combinatorial state in a single comparison, > and the equivalency of one combinatorial state and another for > the purposes of whether or not some code should be run (as in > this specific case). > > The reality is probably that this state should be explicitly > multiplied out in the code, so that it becomes a single value > compare. sometimes you want otherwise.. e.g. What is the base state REGARDLESS of whether it is on the sleep queue. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Sep 4 23:51: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C852F37B400 for ; Wed, 4 Sep 2002 23:50:56 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D45743E65 for ; Wed, 4 Sep 2002 23:50:56 -0700 (PDT) (envelope-from baka@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1921) id 51B3CAE03F; Wed, 4 Sep 2002 23:50:56 -0700 (PDT) Date: Wed, 4 Sep 2002 23:50:56 -0700 From: Jon Mini To: Julian Elischer Cc: Giorgos Keramidas , Bruce Evans , arch@FreeBSD.ORG Subject: Re: Process/thread states. Message-ID: <20020905065056.GJ7265@elvis.mu.org> References: <20020905042733.GE8069@hades.hell.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer [julian@elischer.org] wrote : > > It's not bad to know what is going on `within' the td struct, imho. > > Are you saying the macros are good or bad? I brought my can of paint to this discussion, but when I opeend it up and stuck my brush in, I found that I'd accidentally bought automotive clearcoat! This will never do! I wanted purple macros and bright green spinlocks! Julian, do what you think is best. -- Jonathan Mini 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 Thu Sep 5 0:57:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D81037B400 for ; Thu, 5 Sep 2002 00:57:17 -0700 (PDT) Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7957E43E65 for ; Thu, 5 Sep 2002 00:57:16 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0151.cvx22-bradley.dialup.earthlink.net ([209.179.198.151] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17mrVG-0004PK-00; Thu, 05 Sep 2002 00:56:39 -0700 Message-ID: <3D770DF1.623A84B0@mindspring.com> Date: Thu, 05 Sep 2002 00:55:29 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Giorgos Keramidas , Bruce Evans , arch@FreeBSD.ORG Subject: Re: Process/thread states. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > the state of being on the sleep queue can occur in parallel with the other > states, e.g. on the run queue, or running or on the suspend queue. > Sleeping is really only being on the sleep queue without any other > state taking precedence. > This means that to truely represent the queue and run states of a thread > the state variable consists of a state field with several values > and a separate bit that represents the background reality of it also being > on the sleep queue, and thus able to be awoken. There are also > possibilities that a thread having been swapped out (as part of a process) > that must also be kept orthogonal to whether the thread is suspended or > sleeping or runnable. if this really does turn out to be the case > REAL thread state tracking requires 3 orthognal tests. For this reason I > want touse a macro to allow, > 1/ experimentation on how thisis best done > 2/ hiding of the sometime messy tests with meaningful named abstractions. To me this seems to introduce a bitfield/other-field-contents synchroniztion problem that wasn't there before. Effectively, you are saying that the value of the bit follows the change from NULL-to-non-NULL and non-NULL-to-NULL. There is an implicit race that happens, unless both objects are protected by the same mutex. In the case of a direct compare with the object itself, then there is not race in the following field. Bruce made the point that debugging such macros is arbitrarily hard. This is true because, even if you ensure that the order of operation is always set A/set B, unset B/unset A, your macro used in the comparator functions has to be consistent... and also used consistently. In other words, there is an implied semantic on use, when there is a combined state comparison, which is not explicit in the transitions between states themselves (assuming your state is represented by the "and" or "xor" of two pieces of information). There are several cases in the code in question where there are comparisons which fail. Specifically, the negation of the macro operation requires inverse ordering of the compared values, in order to avoid introducing a "follower" race window. It's possible to get this right, but it also means a lot of work; IMO, it's not worth the implied semantics to get the simplified "if" statements; you would basically need two macros, with one order for the assertion, and the other order for the assertion of the negation. The compiler can't enforce the use of the correct semantics here, so it's easy for programmers to make errors, e.g.: if (!ASSERTION_STATEMENT(x)) vs. if (NEGATION_STATEMENT(x)) that end up introducing incredibly small -- but still there -- race windows in the code, which will pop up as unrepeatable errors suffered by one or two users, which "disappear" when a printf() (or other timing-changing function) is introduced, etc.. To my mind, it is better to multiply the states explicitly, and use the product of the multiplication in the code. For anything more than a two-by-two, this introduces more states (2x3 := 5->6, 4x5 := 9->20, etc.). This means that a lot of care will have to be taken in the code. On the plus side, it means that someone who comes after you is not going to screw things up accidently by missing some required semantics that the compiler is unable to enforce. It's also possible to reduce the total number of states by eliminating "impossible" states (e.g. with a Karnot map), so the increase in total states is not necessarily really any greater than it would have been the other way. > > Neither one of these works properly if there is more than > > one bit hidden in either of these; you have to get a lot more > > complicated: > > this one could be real: > if ((td->td_wchan == 0) && (td->td_state & TD_ST_MASK == TDS_UNQUEUED) && > ((td->td_state & TDS_SWAPPED) == 0)) > setrunnable(td); > > I'd rather make it > > if (td_on_sleepq_only(td) && !td_is_swapped(td)) > setrunnable(td); > > Isn't that somewhat easier to understand? Yes. But it falls into the negation case race problem. A similar condition elsewhere: if (!td_on_sleepq_only(td) || td_is_swapped(td)) do_something(td); is actually a potential race, unless it's: if(td_is_swapped(td) || !td_on_sleepq_only(td)) ...but it's worse than that. By compressing the state compare into a single macro, you lock the order of operation. The only legitimate way to do this is if you have a mutex that protects the contents of td->td_state, since there is no way that you can guarantee that both elements will be updated atomically otherwise. The order of the update becomes important, if the condition is not exactly equal to the example. Further, I would argue that the use of a lowercase macro obfuscates the idea of atmoicity -- atomicity is implied, but not actually guaranteed over (possible) kernel preemption (e.g. a thread on another CPU explcitly killing the thread in question between one compare of td->td_state contents, and the other). > > That *still* doesn't work if, say, TDS_XXX is a superset of the > > bits in TDS_SUSPENDED. > > > I personally dislike the idea omf combined bits, without explicit > > equality tests. > > I have no idea what you mean by that. When you defined your manifest constants, you defined them as the logical OR of a number of bits in your enumerated type declaration; this means that one set of bits could be a subset of another. Even if you have a mask and two flag bits on a value, this is a problem. To make something up: enum { foo = 75 | 0x10000000, fum = 75 | 0x10000000 | 0x20000000, ... } This is actually *likely*, given that people will tend to add bits as time goes on. > > The problem that's trying to be solved here is the one of how > > do you represent a combinatorial state in a single comparison, > > and the equivalency of one combinatorial state and another for > > the purposes of whether or not some code should be run (as in > > this specific case). > > > > The reality is probably that this state should be explicitly > > multiplied out in the code, so that it becomes a single value > > compare. > > sometimes you want otherwise.. e.g. > What is the base state REGARDLESS of whether it is on the sleep queue. I would argue that the compare of the sleep queue entry pointer to NULL is the *ideal* was to get this information. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 5 9:40:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA58A37B400 for ; Thu, 5 Sep 2002 09:40:13 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0031043E6A for ; Thu, 5 Sep 2002 09:40:12 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020905164011.CUMD11061.sccrmhc01.attbi.com@InterJet.elischer.org>; Thu, 5 Sep 2002 16:40:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA36858; Thu, 5 Sep 2002 09:27:34 -0700 (PDT) Date: Thu, 5 Sep 2002 09:27:33 -0700 (PDT) From: Julian Elischer To: Terry Lambert Cc: Giorgos Keramidas , Bruce Evans , arch@FreeBSD.ORG Subject: Re: Process/thread states. In-Reply-To: <3D770DF1.623A84B0@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 5 Sep 2002, Terry Lambert wrote: > Julian Elischer wrote: > > the state of being on the sleep queue can occur in parallel with the other > > states, e.g. on the run queue, or running or on the suspend queue. > > Sleeping is really only being on the sleep queue without any other > > state taking precedence. > > This means that to truely represent the queue and run states of a thread > > the state variable consists of a state field with several values > > and a separate bit that represents the background reality of it also being > > on the sleep queue, and thus able to be awoken. There are also > > possibilities that a thread having been swapped out (as part of a process) > > that must also be kept orthogonal to whether the thread is suspended or > > sleeping or runnable. if this really does turn out to be the case > > REAL thread state tracking requires 3 orthognal tests. For this reason I > > want touse a macro to allow, > > 1/ experimentation on how thisis best done > > 2/ hiding of the sometime messy tests with meaningful named abstractions. > > To me this seems to introduce a bitfield/other-field-contents > synchroniztion problem that wasn't there before. Effectively, > you are saying that the value of the bit follows the change from > NULL-to-non-NULL and non-NULL-to-NULL. There is an implicit race > that happens, unless both objects are protected by the same mutex. > > In the case of a direct compare with the object itself, then there > is not race in the following field. > > Bruce made the point that debugging such macros is arbitrarily > hard. This is true because, even if you ensure that the order > of operation is always set A/set B, unset B/unset A, your macro > used in the comparator functions has to be consistent... and also > used consistently. In other words, there is an implied semantic > on use, when there is a combined state comparison, which is not > explicit in the transitions between states themselves (assuming > your state is represented by the "and" or "xor" of two pieces of > information). There are several cases in the code in question > where there are comparisons which fail. Specifically, the negation > of the macro operation requires inverse ordering of the compared > values, in order to avoid introducing a "follower" race window. state changes are all done under the sched lock > > It's possible to get this right, but it also means a lot of work; > IMO, it's not worth the implied semantics to get the simplified > "if" statements; you would basically need two macros, with one > order for the assertion, and the other order for the assertion > of the negation. The compiler can't enforce the use of the > correct semantics here, so it's easy for programmers to make > errors, e.g.: > > if (!ASSERTION_STATEMENT(x)) > > vs. > > if (NEGATION_STATEMENT(x)) > > that end up introducing incredibly small -- but still there -- > race windows in the code, which will pop up as unrepeatable > errors suffered by one or two users, which "disappear" when a > printf() (or other timing-changing function) is introduced, > etc.. > > To my mind, it is better to multiply the states explicitly, > and use the product of the multiplication in the code. For > anything more than a two-by-two, this introduces more states > (2x3 := 5->6, 4x5 := 9->20, etc.). This means that a lot of > care will have to be taken in the code. On the plus side, it > means that someone who comes after you is not going to screw > things up accidently by missing some required semantics that > the compiler is unable to enforce. It's also possible to > reduce the total number of states by eliminating "impossible" > states (e.g. with a Karnot map), so the increase in total > states is not necessarily really any greater than it would > have been the other way. > > > > > Neither one of these works properly if there is more than > > > one bit hidden in either of these; you have to get a lot more > > > complicated: > > > > this one could be real: > > if ((td->td_wchan == 0) && (td->td_state & TD_ST_MASK == TDS_UNQUEUED) && > > ((td->td_state & TDS_SWAPPED) == 0)) > > setrunnable(td); > > > > I'd rather make it > > > > if (td_on_sleepq_only(td) && !td_is_swapped(td)) > > setrunnable(td); > > > > Isn't that somewhat easier to understand? > > Yes. But it falls into the negation case race problem. A similar > condition elsewhere: > > if (!td_on_sleepq_only(td) || td_is_swapped(td)) > do_something(td); > > is actually a potential race, unless it's: > > if(td_is_swapped(td) || !td_on_sleepq_only(td)) > > ...but it's worse than that. By compressing the state compare into a > single macro, you lock the order of operation. The only legitimate > way to do this is if you have a mutex that protects the contents of > td->td_state, since there is no way that you can guarantee that both > elements will be updated atomically otherwise. The order of the > update becomes important, if the condition is not exactly equal to > the example. Further, I would argue that the use of a lowercase > macro obfuscates the idea of atmoicity -- atomicity is implied, but > not actually guaranteed over (possible) kernel preemption (e.g. a > thread on another CPU explcitly killing the thread in question > between one compare of td->td_state contents, and the other). > > > > > That *still* doesn't work if, say, TDS_XXX is a superset of the > > > bits in TDS_SUSPENDED. > > > > > I personally dislike the idea omf combined bits, without explicit > > > equality tests. > > > > I have no idea what you mean by that. > > When you defined your manifest constants, you defined them as the > logical OR of a number of bits in your enumerated type declaration; > this means that one set of bits could be a subset of another. Even > if you have a mask and two flag bits on a value, this is a problem. > To make something up: > > enum { > foo = 75 | 0x10000000, > fum = 75 | 0x10000000 | 0x20000000, > ... > } > > This is actually *likely*, given that people will tend to add bits > as time goes on. > > > > > The problem that's trying to be solved here is the one of how > > > do you represent a combinatorial state in a single comparison, > > > and the equivalency of one combinatorial state and another for > > > the purposes of whether or not some code should be run (as in > > > this specific case). > > > > > > The reality is probably that this state should be explicitly > > > multiplied out in the code, so that it becomes a single value > > > compare. > > > > sometimes you want otherwise.. e.g. > > What is the base state REGARDLESS of whether it is on the sleep queue. > > I would argue that the compare of the sleep queue entry pointer > to NULL is the *ideal* was to get this information. 8-). > > -- Terry > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 5 10:23: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7D2D37B400 for ; Thu, 5 Sep 2002 10:22:56 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FB7543E6A for ; Thu, 5 Sep 2002 10:22:55 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g85HMpGq009466 for ; Thu, 5 Sep 2002 11:22:51 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 05 Sep 2002 11:22:43 -0600 (MDT) Message-Id: <20020905.112243.88255915.imp@bsdimp.com> To: arch@freebsd.org Subject: Make more things honor NOFSCHG From: "M. Warner Losh" X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Right now only libraries will honor NOFSCHG. Laying aside for the moment the whole !@#$!$#@^$#^ NOFOO vs NO_FOO bikeshed, I'd like to commit the following patch to make other places where -fschg are added to installflags. This allows one to more things over a mix of local file systems and NFS and have them work (right now if you build on a local fs, then try to delete it via nfs, it fails because one can't unset file flags over nfs). Comments? Warner Index: bin/rcp/Makefile =================================================================== RCS file: /cache/ncvs/src/bin/rcp/Makefile,v retrieving revision 1.20 diff -u -r1.20 Makefile --- bin/rcp/Makefile 18 Apr 2002 07:01:34 -0000 1.20 +++ bin/rcp/Makefile 5 Sep 2002 17:14:09 -0000 @@ -23,6 +23,8 @@ BINOWN= root BINMODE=4555 +.if !defined(NOFSCHG) INSTALLFLAGS=-fschg +.endif .include Index: libexec/rtld-aout/Makefile =================================================================== RCS file: /cache/ncvs/src/libexec/rtld-aout/Makefile,v retrieving revision 1.31 diff -u -r1.31 Makefile --- libexec/rtld-aout/Makefile 12 Sep 2001 10:04:41 -0000 1.31 +++ libexec/rtld-aout/Makefile 5 Sep 2002 17:14:57 -0000 @@ -9,7 +9,10 @@ ASFLAGS+=-k DPADD+= ${LIBC:S/c.a/c_pic.a/} ${LIBC:S/c.a/gcc_pic.a/} LDADD+= -lc_pic -lgcc_pic -INSTALLFLAGS= -fschg -C # -C to install as atomically as possible +.if !defined(NOFSCHG) +INSTALLFLAGS= -fschg +.endif +INSTALLFLAGS+= -C # -C to install as atomically as possible MLINKS= rtld.1aout ld.so.1aout .PATH: ${.CURDIR}/${MACHINE_ARCH} Index: libexec/rtld-elf/Makefile =================================================================== RCS file: /cache/ncvs/src/libexec/rtld-elf/Makefile,v retrieving revision 1.16 diff -u -r1.16 Makefile --- libexec/rtld-elf/Makefile 10 Jun 2002 21:51:16 -0000 1.16 +++ libexec/rtld-elf/Makefile 5 Sep 2002 17:15:20 -0000 @@ -6,7 +6,10 @@ MAN= rtld.1 CFLAGS+= -Wall -DFREEBSD_ELF -I${.CURDIR}/${MACHINE_ARCH} -I${.CURDIR} LDFLAGS+= -nostdlib -e .rtld_start -INSTALLFLAGS= -fschg -C -b +.if !defined(NOFSCHG) +INSTALLFLAGS= -fschg +.endif +INSTALLFLAGS+= -C -b MLINKS= rtld.1 ld-elf.so.1.1 .if exists(${.CURDIR}/${MACHINE_ARCH}/Makefile.inc) Index: sbin/init/Makefile =================================================================== RCS file: /cache/ncvs/src/sbin/init/Makefile,v retrieving revision 1.27 diff -u -r1.27 Makefile --- sbin/init/Makefile 4 Dec 2001 02:19:48 -0000 1.27 +++ sbin/init/Makefile 5 Sep 2002 17:15:52 -0000 @@ -5,7 +5,10 @@ MAN= init.8 MLINKS= init.8 securelevel.8 BINMODE=500 -INSTALLFLAGS=-fschg -b -B.bak +.if !defined(NOFSCHG) +INSTALLFLAGS=-fschg +.endif +INSTALLFLAGS+=-b -B.bak CFLAGS+=-DDEBUGSHELL -DSECURE -DLOGIN_CAP -DCOMPAT_SYSV_INIT WARNS= 0 DPADD= ${LIBUTIL} ${LIBCRYPT} Index: usr.bin/login/Makefile =================================================================== RCS file: /cache/ncvs/src/usr.bin/login/Makefile,v retrieving revision 1.42 diff -u -r1.42 Makefile --- usr.bin/login/Makefile 21 Apr 2002 12:43:14 -0000 1.42 +++ usr.bin/login/Makefile 5 Sep 2002 17:16:17 -0000 @@ -9,7 +9,9 @@ MAN= login.1 login.access.5 BINOWN= root BINMODE=4555 +.if !defined(NOFSCHG) INSTALLFLAGS=-fschg +.endif NEED_LIBNAMES= yes .include Index: usr.bin/rlogin/Makefile =================================================================== RCS file: /cache/ncvs/src/usr.bin/rlogin/Makefile,v retrieving revision 1.25 diff -u -r1.25 Makefile --- usr.bin/rlogin/Makefile 8 May 2002 00:44:34 -0000 1.25 +++ usr.bin/rlogin/Makefile 5 Sep 2002 17:16:35 -0000 @@ -6,7 +6,9 @@ BINOWN= root BINMODE=4555 +.if !defined(NOFSCHG) INSTALLFLAGS=-fschg +.endif .if defined(MAKE_KERBEROS4) && !defined(NO_OPENSSL) && !defined(NOCRYPT) SRCS+= krcmd.c kcmd.c rcmd_util.c Index: usr.bin/rsh/Makefile =================================================================== RCS file: /cache/ncvs/src/usr.bin/rsh/Makefile,v retrieving revision 1.21 diff -u -r1.21 Makefile --- usr.bin/rsh/Makefile 8 May 2002 00:47:01 -0000 1.21 +++ usr.bin/rsh/Makefile 5 Sep 2002 17:16:56 -0000 @@ -20,6 +20,8 @@ BINOWN= root BINMODE=4555 +.if !defined(NOFSCHG) INSTALLFLAGS=-fschg +.endif .include Index: usr.bin/su/Makefile =================================================================== RCS file: /cache/ncvs/src/usr.bin/su/Makefile,v retrieving revision 1.38 diff -u -r1.38 Makefile --- usr.bin/su/Makefile 12 Dec 2001 23:29:13 -0000 1.38 +++ usr.bin/su/Makefile 5 Sep 2002 17:17:06 -0000 @@ -8,6 +8,8 @@ BINOWN= root BINMODE=4555 +.if !defined(NOFSCHG) INSTALLFLAGS=-fschg +.endif .include Index: usr.sbin/sliplogin/Makefile =================================================================== RCS file: /cache/ncvs/src/usr.sbin/sliplogin/Makefile,v retrieving revision 1.7 diff -u -r1.7 Makefile --- usr.sbin/sliplogin/Makefile 13 Sep 2001 06:48:16 -0000 1.7 +++ usr.sbin/sliplogin/Makefile 5 Sep 2002 17:17:27 -0000 @@ -6,6 +6,8 @@ BINOWN= root BINGRP= network BINMODE=4550 +.if !defined(NOFSCHG) INSTALLFLAGS=-fschg +.endif .include To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 5 10:25:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E38FC37B400 for ; Thu, 5 Sep 2002 10:25:33 -0700 (PDT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 926E043E3B for ; Thu, 5 Sep 2002 10:25:32 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from gosset.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 5 Sep 2002 18:25:31 +0100 (BST) To: "M. Warner Losh" Cc: arch@freebsd.org Subject: Re: Make more things honor NOFSCHG In-Reply-To: Your message of "Thu, 05 Sep 2002 11:22:43 MDT." <20020905.112243.88255915.imp@bsdimp.com> Date: Thu, 05 Sep 2002 18:25:30 +0100 From: Ian Dowse Message-ID: <200209051825.aa93685@salmon.maths.tcd.ie> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020905.112243.88255915.imp@bsdimp.com>, "M. Warner Losh" writes: >Right now only libraries will honor NOFSCHG. Laying aside for the >moment the whole !@#$!$#@^$#^ NOFOO vs NO_FOO bikeshed, I'd like to >commit the following patch to make other places where -fschg are added >to installflags. This allows one to more things over a mix of local >file systems and NFS and have them work (right now if you build on a >local fs, then try to delete it via nfs, it fails because one can't >unset file flags over nfs). > >Comments? The following in make.conf works: INSTALLFLAGS_EDIT= :S/-fschg// Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 5 10:58:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68E2737B400 for ; Thu, 5 Sep 2002 10:58:27 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id EAE4943E65 for ; Thu, 5 Sep 2002 10:58:23 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 2667 invoked by uid 1000); 5 Sep 2002 17:58:24 -0000 Date: Thu, 5 Sep 2002 10:58:24 -0700 (PDT) From: Nate Lawson To: Ian Dowse Cc: arch@freebsd.org Subject: Re: Make more things honor NOFSCHG In-Reply-To: <200209051825.aa93685@salmon.maths.tcd.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 5 Sep 2002, Ian Dowse wrote: > In message <20020905.112243.88255915.imp@bsdimp.com>, "M. Warner Losh" writes: > >Right now only libraries will honor NOFSCHG. Laying aside for the > >moment the whole !@#$!$#@^$#^ NOFOO vs NO_FOO bikeshed, I'd like to > >commit the following patch to make other places where -fschg are added > >to installflags. This allows one to more things over a mix of local > >file systems and NFS and have them work (right now if you build on a > >local fs, then try to delete it via nfs, it fails because one can't > >unset file flags over nfs). > > > >Comments? > > The following in make.conf works: > > INSTALLFLAGS_EDIT= :S/-fschg// > > Ian That is a useful tip plus I think Warner is right in making things consistent. Two for one special today. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 5 11:48:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4300437B400 for ; Thu, 5 Sep 2002 11:48:08 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53BDB43E84 for ; Thu, 5 Sep 2002 11:48:04 -0700 (PDT) (envelope-from bde@zeta.org.au) 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 EAA16648; Fri, 6 Sep 2002 04:47:44 +1000 Date: Fri, 6 Sep 2002 04:55:11 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "M. Warner Losh" Cc: arch@FreeBSD.ORG Subject: Re: Make more things honor NOFSCHG In-Reply-To: <20020905.112243.88255915.imp@bsdimp.com> Message-ID: <20020906044316.T8183-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 5 Sep 2002, M. Warner Losh wrote: > Right now only libraries will honor NOFSCHG. Laying aside for the > moment the whole !@#$!$#@^$#^ NOFOO vs NO_FOO bikeshed, I'd like to > commit the following patch to make other places where -fschg are added > to installflags. This allows one to more things over a mix of local > file systems and NFS and have them work (right now if you build on a > local fs, then try to delete it via nfs, it fails because one can't > unset file flags over nfs). > > Comments? > > Warner > > Index: bin/rcp/Makefile > =================================================================== > RCS file: /cache/ncvs/src/bin/rcp/Makefile,v > retrieving revision 1.20 > diff -u -r1.20 Makefile > --- bin/rcp/Makefile 18 Apr 2002 07:01:34 -0000 1.20 > +++ bin/rcp/Makefile 5 Sep 2002 17:14:09 -0000 > @@ -23,6 +23,8 @@ > > BINOWN= root > BINMODE=4555 > +.if !defined(NOFSCHG) > INSTALLFLAGS=-fschg > +.endif > > .include > ... Why not use the standard method of zapping install flags (INSTALLFLAGS_EDIT)? E.g., INSTALLFLAGS_EDIT=':S/-fschg//g' zaps all instances of -fschg. See the log message for bsd.prog.mk 1.84 for more examples. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 5 12:37: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E3E637B400; Thu, 5 Sep 2002 12:37:03 -0700 (PDT) Received: from softweyr.com (softweyr.com [65.88.244.127]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5E7643E6E; Thu, 5 Sep 2002 12:37:02 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from nextgig-8.access.nethere.net ([66.63.140.200] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.35 #1) id 17n2PK-000CtV-00; Thu, 05 Sep 2002 13:35:14 -0600 Message-ID: <3D77B40B.A9193058@softweyr.com> Date: Thu, 05 Sep 2002 12:44:11 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: "David W. Chapman Jr." Cc: Will Andrews , Simon 'corecode' Schubert , rbeyer@rossbeyer.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> <00a001c2534d$a89576f0$f800a8c0@dwcjr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "David W. Chapman Jr." wrote: > > > > On Mon, Sep 02, 2002 at 10:32:15AM +0200, Simon 'corecode' Schubert > wrote: > > > > actually this would be a much smaller mess if we had the package tools > > > > (with source) in the ports tree. best with auto-update... > > > > do we want to do this? > > > > (x-posting to arch@) > > > > > > Yes we do. I plan to do this within the next week or so. > > > > OK, how do you install the package tools package onto the system if it > > doesn't come with package tools? > > pkg_add -r pkgtools pkg_add: command not found You missed the part where I wrote "if it [the system] doesn't come with package tools." Assuming I'm an idiot is not going to advance this discussion much. -- "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 Thu Sep 5 12:38:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06E7D37B400; Thu, 5 Sep 2002 12:38:52 -0700 (PDT) Received: from softweyr.com (softweyr.com [65.88.244.127]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3657743E42; Thu, 5 Sep 2002 12:38:51 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from nextgig-11.access.nethere.net ([66.63.140.203] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.35 #1) id 17n2Qp-000CuM-00; Thu, 05 Sep 2002 13:36:47 -0600 Message-ID: <3D77B46E.F654A94F@softweyr.com> Date: Thu, 05 Sep 2002 12:45:50 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Will Andrews Cc: Kris Kennaway , "David W. Chapman Jr." , Simon 'corecode' Schubert , rbeyer@rossbeyer.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> <00a001c2534d$a89576f0$f800a8c0@dwcjr> <20020903152048.GC77952@xor.obsecurity.org> <20020903173644.GQ2072@procyon.firepipe.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Will Andrews wrote: > > On Tue, Sep 03, 2002 at 08:20:48AM -0700, Kris Kennaway wrote: > > > > OK, how do you install the package tools package onto the system if it > > > > doesn't come with package tools? > > > > > > pkg_add -r pkgtools > > > > Go and read the question again. > > Actually, his answer makes perfect sense. We are *NOT* removing > pkg_install from the source tree. :-) So how is the new package supposed to correctly update binaries that are not part of a package? Do you propose this as a change to the pkg tools? Please note that currently they will not do this unless you force it. -- "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 Thu Sep 5 12:39:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7820937B400; Thu, 5 Sep 2002 12:39:16 -0700 (PDT) Received: from softweyr.com (softweyr.com [65.88.244.127]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01A4443E3B; Thu, 5 Sep 2002 12:39:16 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from nextgig-8.access.nethere.net ([66.63.140.200] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.35 #1) id 17n2T9-000CwM-00; Thu, 05 Sep 2002 13:39:12 -0600 Message-ID: <3D77B507.1D45EDF2@softweyr.com> Date: Thu, 05 Sep 2002 12:48:23 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Will Andrews Cc: Simon 'corecode' Schubert , ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> <20020903100258.068fb3ab.corecode@corecode.ath.cx> <20020903121413.GN2072@procyon.firepipe.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Will Andrews wrote: > > On Tue, Sep 03, 2002 at 10:02:58AM +0200, Simon 'corecode' Schubert wrote: > > Hitting two birds with one stone, so to speak. > > > > OK, how do you install the package tools package onto the system if it > > > doesn't come with package tools? > > > > > > Please note that I'm all for having the package tools in ports, because it > > > will make the one last feature I want to add to them ever so much easier > > > to build, but we do have to fix this chicken vs. egg probem first. > > Simple. We keep the pkg_install stuff in the src tree. That > way, everyone will always have a minimal version installed with > the system. If needed, they can then install a newer version via > the ports tree. If that newer version is installed, bsd.port.mk > will use it instead. You're getting closer to the right answer here. Keep thinking. > Please see NetBSD for an example that they have done for 4 years. > It's such a great idea I'm not sure why nobody in FreeBSD did it. Because it's not the right answer. It's almost the right answer, one more step and you'll be able to see it. Yes, I know what the answer is, but I want *you* to get there too, to validate my thinking. Hint: /var/db/pkg... -- "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 Thu Sep 5 12:44:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4258437B400; Thu, 5 Sep 2002 12:44:13 -0700 (PDT) Received: from softweyr.com (softweyr.com [65.88.244.127]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5709E43E65; Thu, 5 Sep 2002 12:44:12 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from nextgig-11.access.nethere.net ([66.63.140.203] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.35 #1) id 17n2Xt-000Cxe-00; Thu, 05 Sep 2002 13:44:05 -0600 Message-ID: <3D77B62D.B8414858@softweyr.com> Date: Thu, 05 Sep 2002 12:53:17 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Maxim Sobolev Cc: Will Andrews , Simon 'corecode' Schubert , ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> <20020903100258.068fb3ab.corecode@corecode.ath.cx> <20020903121413.GN2072@procyon.firepipe.net> <20020903130237.GB8010@vega.vega.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Maxim Sobolev wrote: > > On Tue, Sep 03, 2002 at 05:14:13AM -0700, Will Andrews wrote: > > On Tue, Sep 03, 2002 at 10:02:58AM +0200, Simon 'corecode' Schubert wrote: > > > > Hitting two birds with one stone, so to speak. > > > > > > OK, how do you install the package tools package onto the system if it > > > > doesn't come with package tools? > > > > > > > > Please note that I'm all for having the package tools in ports, because it > > > > will make the one last feature I want to add to them ever so much easier > > > > to build, but we do have to fix this chicken vs. egg probem first. > > > > Simple. We keep the pkg_install stuff in the src tree. That > > way, everyone will always have a minimal version installed with > > the system. If needed, they can then install a newer version via > > the ports tree. If that newer version is installed, bsd.port.mk > > will use it instead. > > > > Please see NetBSD for an example that they have done for 4 years. > > It's such a great idea I'm not sure why nobody in FreeBSD did it. > > I am also thinking about something like that for a quite some time, > but it is not quite straightforward to implement correctly. Yes, you > can add version reporting into pkg_info and make bsd.port.mk detecting > it and installing a new version from ports if it is too outdated. > > The problem with such approach is that if you will overwrite older > versions in /usr/sbin with newer ones, it will work, but only until > the next build/installworld (for example if user runs security branch > and new patchlevel is available requiring full world rebuild), when > the newer ones will be replaced by old ones again. Sure, executing > `make something' in ports tree will put things in order again, but > what if before that the user will try to delete some package or add > a new one using pkg_delete/pkg_add directly? > > Another approach is to install pkg_tools package into /usr/local, but > extend tools in the base system to check version of their counterparts > in /usr/local (if installed) and turn themselves into a wrappers if > ones in /usr/local are newer than ones in the /usr. This approach is > better in the long run, since it allows to not worry about system > upgrades, but creates 'chiken and egg' problem, since adding > checking/wrapping functionality would require to change pkg_install > tools. > > Therefore, IMO some combined approach is necessary. I have the following > (very preliminary) vision of what needs to be done to solve the > problem: > > 1. Assign some form of version number to pkg_install tools. This > number should be monotonically increased each time when new > functionality is added or older functionality used in bsd.port.mk > is changed. Add appropriate reporting routine. > > 2. Add wrapping functionality into pkg_install tools: on startup > of any tool check that a configuration file in some pre-defined > location exsists, read it, compare versions here and there and > execve() specified file if it is newer, otherwise continue running. > Format of file could be very simple, say one line with two words: > the first is version number and the second is installation base, i.e. > /var/db/pkg_install.wrap: > > 123455 /usr/local/sbin > > 3. Create an appropriate pkg_tools port, which will install latest > version of the tools and generate configuration file described above > when installed FreeBSD version supports finctionality described > in (1). If it doesn't, then the port whould just overwrite versions of > pkg tools in /usr/sbin with newer versions and warn user about the > need to reinstall the port after buildworld/installworld. > > 4. Add bsd.port.mk bits and pieces for installing that pkg_tools port > if system version is too old. > > I hope that this would be useful for you. Any comments or questions > are appreciated. A very interesting approach. My thinking was simply to plop pkg_add or pkg_add on the install CD-ROM and have it install the mandatory pkg_tools package from the CD-ROM every time. The answer to the chicken and egg problem is to have a pre-existing system which can build this version of pkg_add. This would go for the 'mfs root' floppy for network installations as well. -- "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 Thu Sep 5 12:55:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD51037B41B; Thu, 5 Sep 2002 12:55:02 -0700 (PDT) Received: from procyon.firepipe.net (procyon.firepipe.net [198.78.66.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCFA543E42; Thu, 5 Sep 2002 12:54:50 -0700 (PDT) (envelope-from will@csociety.org) Received: by procyon.firepipe.net (Postfix, from userid 1000) id 34EB321455; Thu, 5 Sep 2002 12:52:41 -0700 (PDT) Date: Thu, 5 Sep 2002 12:52:41 -0700 From: Will Andrews To: Wes Peters Cc: Will Andrews , Kris Kennaway , "David W. Chapman Jr." , Simon 'corecode' Schubert , rbeyer@rossbeyer.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) Message-ID: <20020905195241.GM96003@procyon.firepipe.net> Mail-Followup-To: Wes Peters , Will Andrews , Kris Kennaway , "David W. Chapman Jr." , Simon 'corecode' Schubert , rbeyer@rossbeyer.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> <00a001c2534d$a89576f0$f800a8c0@dwcjr> <20020903152048.GC77952@xor.obsecurity.org> <20020903173644.GQ2072@procyon.firepipe.net> <3D77B46E.F654A94F@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D77B46E.F654A94F@softweyr.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Sep 05, 2002 at 12:45:50PM -0700, Wes Peters wrote: > So how is the new package supposed to correctly update binaries that are > not part of a package? Do you propose this as a change to the pkg tools? > Please note that currently they will not do this unless you force it. What are you talking about? pkg_* have never touched files that aren't part of a package. :-) regards, -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 5 12:55:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66B1537B400; Thu, 5 Sep 2002 12:55:50 -0700 (PDT) Received: from procyon.firepipe.net (procyon.firepipe.net [198.78.66.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16DD743E42; Thu, 5 Sep 2002 12:55:50 -0700 (PDT) (envelope-from will@csociety.org) Received: by procyon.firepipe.net (Postfix, from userid 1000) id BC33B2145A; Thu, 5 Sep 2002 12:54:07 -0700 (PDT) Date: Thu, 5 Sep 2002 12:54:07 -0700 From: Will Andrews To: Wes Peters Cc: ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) Message-ID: <20020905195407.GN96003@procyon.firepipe.net> Mail-Followup-To: Wes Peters , ports@FreeBSD.ORG, arch@FreeBSD.ORG References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> <00a001c2534d$a89576f0$f800a8c0@dwcjr> <3D77B40B.A9193058@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D77B40B.A9193058@softweyr.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Sep 05, 2002 at 12:44:11PM -0700, Wes Peters wrote: > > pkg_add -r pkgtools > > pkg_add: command not found > > You missed the part where I wrote "if it [the system] doesn't come with > package tools." Assuming I'm an idiot is not going to advance this > discussion much. Assuming he thought you were an idiot is not going to do it, either. Seriously now, the above answer is quite succinct and accurate, if I do say so myself. :-] regards, -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 5 13: 1:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F55E37B400; Thu, 5 Sep 2002 13:01:23 -0700 (PDT) Received: from procyon.firepipe.net (procyon.firepipe.net [198.78.66.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F51A43E77; Thu, 5 Sep 2002 13:01:23 -0700 (PDT) (envelope-from will@csociety.org) Received: by procyon.firepipe.net (Postfix, from userid 1000) id F399D2145B; Thu, 5 Sep 2002 12:59:45 -0700 (PDT) Date: Thu, 5 Sep 2002 12:59:45 -0700 From: Will Andrews To: Wes Peters Cc: ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) Message-ID: <20020905195945.GP96003@procyon.firepipe.net> Mail-Followup-To: Wes Peters , ports@FreeBSD.ORG, arch@FreeBSD.ORG References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> <20020903100258.068fb3ab.corecode@corecode.ath.cx> <20020903121413.GN2072@procyon.firepipe.net> <3D77B507.1D45EDF2@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D77B507.1D45EDF2@softweyr.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Sep 05, 2002 at 12:48:23PM -0700, Wes Peters wrote: > > Please see NetBSD for an example that they have done for 4 years. > > It's such a great idea I'm not sure why nobody in FreeBSD did it. > > Because it's not the right answer. It's almost the right answer, > one more step and you'll be able to see it. > > Yes, I know what the answer is, but I want *you* to get there too, to > validate my thinking. Hint: /var/db/pkg... Nope. Sorry, not ringing any bells. :-) -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 5 22: 6:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FF1F37B400; Thu, 5 Sep 2002 22:06:42 -0700 (PDT) Received: from softweyr.com (softweyr.com [65.88.244.127]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98A5D43E3B; Thu, 5 Sep 2002 22:06:41 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from nextgig-8.access.nethere.net ([66.63.140.200] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.35 #1) id 17nBHT-000DoF-00; Thu, 05 Sep 2002 23:03:43 -0600 Message-ID: <3D783951.7A449353@softweyr.com> Date: Thu, 05 Sep 2002 22:12:49 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Will Andrews Cc: Kris Kennaway , "David W. Chapman Jr." , Simon 'corecode' Schubert , rbeyer@rossbeyer.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ (was: Re: Bzipped?) References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> <00a001c2534d$a89576f0$f800a8c0@dwcjr> <20020903152048.GC77952@xor.obsecurity.org> <20020903173644.GQ2072@procyon.firepipe.net> <3D77B46E.F654A94F@softweyr.com> <20020905195241.GM96003@procyon.firepipe.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Will Andrews wrote: > > On Thu, Sep 05, 2002 at 12:45:50PM -0700, Wes Peters wrote: > > So how is the new package supposed to correctly update binaries that are > > not part of a package? Do you propose this as a change to the pkg tools? > > Please note that currently they will not do this unless you force it. > > What are you talking about? pkg_* have never touched files that > aren't part of a package. :-) If I'd meant -f, I would've said -f. I meant "force it" as in "delete or rename the file pkg_add won't overwrite." Remember the Alexander Haig rule of government: "When all else fails, result to brute force and ignorance. Oh hell, let's just start with brute force and ignorance." -- "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 Fri Sep 6 4:36:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54B0737B400; Fri, 6 Sep 2002 04:36:06 -0700 (PDT) Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DD8C43E72; Fri, 6 Sep 2002 04:36:05 -0700 (PDT) (envelope-from corecode@corecode.ath.cx) Received: from fwd08.sul.t-online.de by mailout03.sul.t-online.com with smtp id 17nHOy-0002Tx-0E; Fri, 06 Sep 2002 13:35:52 +0200 Received: from spirit.zuhause.stoert.net (320050403952-0001@[217.224.166.77]) by fmrl08.sul.t-online.com with esmtp id 17nHOp-29qy1YC; Fri, 6 Sep 2002 13:35:43 +0200 Received: from terrorfish.uni.stoert.net (terrorfish.uni.stoert.net [10.150.180.178]) by spirit.zuhause.stoert.net (8.11.6/8.11.6) with ESMTP id g86BZg311926; Fri, 6 Sep 2002 13:35:42 +0200 (CEST) (envelope-from corecode@corecode.ath.cx) Received: from terrorfish.uni.stoert.net (localhost [127.0.0.1]) by terrorfish.uni.stoert.net (8.12.6/8.12.5) with ESMTP id g86BYofw004933; Fri, 6 Sep 2002 13:34:50 +0200 (CEST) (envelope-from corecode@terrorfish.uni.stoert.net) Received: (from corecode@localhost) by terrorfish.uni.stoert.net (8.12.6/8.12.5/Submit) id g86BYkwI004932; Fri, 6 Sep 2002 13:34:46 +0200 (CEST) (envelope-from corecode) Date: Fri, 6 Sep 2002 13:34:36 +0200 From: "Simon 'corecode' Schubert" To: Wes Peters Cc: will@csociety.org, dwcjr@inethouston.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ Message-Id: <20020906133436.32554344.corecode@corecode.ath.cx> In-Reply-To: <3D7445D3.DAA2C9B9@softweyr.com> References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> X-Mailer: Sylpheed version 0.8.2claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="80edw=.h93xmW/Tj" X-Sender: 320050403952-0001@t-dialin.net Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --80edw=.h93xmW/Tj Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 02 Sep 2002 23:17:07 -0600 Wes Peters wrote: > OK, how do you install the package tools package onto the system if it > doesn't come with package tools? how about always building the package tools if they are outdated? or providing a special package for them plus a small script which will install that package... cheers simon -- /"\ http://corecode.ath.cx/#donate \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News --80edw=.h93xmW/Tj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9eJLVr5S+dk6z85oRAoMCAJ92mhcKRKj4T4op27v8xSAWGfcZHwCaAxEI fanQxdKK7Tk/lQ60gGxGswc= =HI1X -----END PGP SIGNATURE----- --80edw=.h93xmW/Tj-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 6 5:17:28 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9631C37B400; Fri, 6 Sep 2002 05:17:23 -0700 (PDT) Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2958443E75; Fri, 6 Sep 2002 05:17:23 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0015.cvx21-bradley.dialup.earthlink.net ([209.179.192.15] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17nI2Y-0005OL-00; Fri, 06 Sep 2002 05:16:46 -0700 Message-ID: <3D789C68.4B82930@mindspring.com> Date: Fri, 06 Sep 2002 05:15:36 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon 'corecode' Schubert Cc: Wes Peters , will@csociety.org, dwcjr@inethouston.net, ports@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: package tools into ports/ References: <20020901142653.A32415@capable.rogards.com> <20020901191937.GI87971@leviathan.inethouston.net> <20020902103215.36ae8e3b.corecode@corecode.ath.cx> <20020902085654.GH2072@procyon.firepipe.net> <3D7445D3.DAA2C9B9@softweyr.com> <20020906133436.32554344.corecode@corecode.ath.cx> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Simon 'corecode' Schubert wrote: > On Mon, 02 Sep 2002 23:17:07 -0600 Wes Peters wrote: > > OK, how do you install the package tools package onto the system if it > > doesn't come with package tools? > > how about always building the package tools if they are outdated? or > providing a special package for them plus a small script which will > install that package... I believe the intent is to allow replacement of the existing installed package tools with a new set of package tools which are mostly the same, but include Bzip support. I have no idea why anyone wants bzip support, but this seems to be the driver for this issue. So for Wes: They don't want to take the package tools out of the base system, they just want to be able to replace them with a version which is compiled seperately to add features (because of a GPL'ed library? I dunno...). For everyone else: it wasn't clear reading through the first couple of messages that you in fact were going to leave the default package tools in place, and replace the installed binaries with new ones. Given the way bzip archives are handled, such that you can't read the index until you have the whole file, I personally do not see the reason for bzip. OPver network links, it will mean taking a long time to download something only to find out you need to download prerequisites. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 6 5:32:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51D6D37B400 for ; Fri, 6 Sep 2002 05:32:28 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CB3243E4A for ; Fri, 6 Sep 2002 05:32:27 -0700 (PDT) (envelope-from bde@zeta.org.au) 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 WAA08662; Fri, 6 Sep 2002 22:32:07 +1000 Date: Fri, 6 Sep 2002 22:39:31 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Nate Lawson Cc: Ian Dowse , Subject: Re: Make more things honor NOFSCHG In-Reply-To: Message-ID: <20020906223815.D10867-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 5 Sep 2002, Nate Lawson wrote: > On Thu, 5 Sep 2002, Ian Dowse wrote: > > In message <20020905.112243.88255915.imp@bsdimp.com>, "M. Warner Losh" writes: > > >Right now only libraries will honor NOFSCHG. Laying aside for the > > >moment the whole !@#$!$#@^$#^ NOFOO vs NO_FOO bikeshed, I'd like to > > >commit the following patch to make other places where -fschg are added > > >to installflags. This allows one to more things over a mix of local > > >file systems and NFS and have them work (right now if you build on a > > >local fs, then try to delete it via nfs, it fails because one can't > > >unset file flags over nfs). > > > > > >Comments? > > > > The following in make.conf works: > > > > INSTALLFLAGS_EDIT= :S/-fschg// > > > > Ian > > That is a useful tip plus I think Warner is right in making things > consistent. Two for one special today. No thnaks. IIRC, hoek invented INSTALLFLAGS when I objected to cluttering Makefiles with more special-case hacks. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 6 13:38: 1 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96E2A37B400 for ; Fri, 6 Sep 2002 13:37:58 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 2EAC643E4A for ; Fri, 6 Sep 2002 13:37:58 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 5665 invoked by uid 1000); 6 Sep 2002 20:37:59 -0000 Date: Fri, 6 Sep 2002 13:37:59 -0700 (PDT) From: Nate Lawson To: Bruce Evans Cc: arch@FreeBSD.ORG Subject: Re: Make more things honor NOFSCHG In-Reply-To: <20020906223815.D10867-100000@gamplex.bde.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 6 Sep 2002, Bruce Evans wrote: > On Thu, 5 Sep 2002, Nate Lawson wrote: > > On Thu, 5 Sep 2002, Ian Dowse wrote: > > > In message <20020905.112243.88255915.imp@bsdimp.com>, "M. Warner Losh" writes: > > > >Right now only libraries will honor NOFSCHG. Laying aside for the > > > >moment the whole !@#$!$#@^$#^ NOFOO vs NO_FOO bikeshed, I'd like to > > > >commit the following patch to make other places where -fschg are added > > > >to installflags. This allows one to more things over a mix of local > > > >file systems and NFS and have them work (right now if you build on a > > > >local fs, then try to delete it via nfs, it fails because one can't > > > >unset file flags over nfs). > > > > > > > >Comments? > > > > > > The following in make.conf works: > > > > > > INSTALLFLAGS_EDIT= :S/-fschg// > > > > > > Ian > > > > That is a useful tip plus I think Warner is right in making things > > consistent. Two for one special today. > > No thnaks. IIRC, hoek invented INSTALLFLAGS when I objected to cluttering > Makefiles with more special-case hacks. > > Bruce Ok, then his patch should _remove_ the old NOFSCHG checks. Consistency is still good. :) -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 6 17:10:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F05DC37B400 for ; Fri, 6 Sep 2002 17:10:57 -0700 (PDT) Received: from tomts6-srv.bellnexxia.net (tomts6.bellnexxia.net [209.226.175.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFD5043E72 for ; Fri, 6 Sep 2002 17:10:56 -0700 (PDT) (envelope-from t.vanderhoek@utoronto.ca) Received: from localhost.nowhere ([64.231.126.32]) by tomts6-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20020906230901.HHHI2163.tomts6-srv.bellnexxia.net@localhost.nowhere>; Fri, 6 Sep 2002 19:09:01 -0400 Received: from localhost.nowhere (localhost [127.0.0.1]) by localhost.nowhere (8.12.5/8.12.5) with ESMTP id g86N8xRT028762; Fri, 6 Sep 2002 19:08:59 -0400 (EDT) (envelope-from tim@localhost.nowhere) Received: (from tim@localhost) by localhost.nowhere (8.12.5/8.12.5/Submit) id g86N8oNZ028746; Fri, 6 Sep 2002 19:08:50 -0400 (EDT) Date: Fri, 6 Sep 2002 19:08:50 -0400 From: Tim Vanderhoek To: Nate Lawson Cc: Bruce Evans , arch@FreeBSD.ORG Subject: Re: Make more things honor NOFSCHG Message-ID: <20020906230850.GA27804@turquoise> References: <20020906223815.D10867-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Sep 06, 2002 at 01:37:59PM -0700, Nate Lawson wrote: > > > > No thnaks. IIRC, hoek invented INSTALLFLAGS when I objected to cluttering > > Makefiles with more special-case hacks. > > > > Bruce > > Ok, then his patch should _remove_ the old NOFSCHG checks. Consistency is > still good. :) I think I left the old NOFSCHG in place because I didn't want to break people who used it. I guess I could remove it from -current. I know it's used in at least Makefile.inc1. If I remove it, I suppose INSTALLFLAGS_EDIT should be documented somewhere as the replacement, but I'm not sure where the best place for this documentation is. Alternatively, I could simply reimplement it in bsd.lib.mk to use the INSTALLFLAGS_EDIT. Comments? -- If I could think of a two-line witty aphorism for you to remember me by, this would definitely be it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 6 17:45:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6043D37B400 for ; Fri, 6 Sep 2002 17:45:12 -0700 (PDT) Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCD0D43E4A for ; Fri, 6 Sep 2002 17:45:11 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g870j5cA268142; Fri, 6 Sep 2002 20:45:06 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020906230850.GA27804@turquoise> References: <20020906223815.D10867-100000@gamplex.bde.org> <20020906230850.GA27804@turquoise> Date: Fri, 6 Sep 2002 20:45:05 -0400 To: Tim Vanderhoek , Nate Lawson From: Garance A Drosihn Subject: Re: Make more things honor NOFSCHG Cc: Bruce Evans , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 7:08 PM -0400 9/6/02, Tim Vanderhoek wrote: > >I think I left the old NOFSCHG in place because I didn't want to >break people who used it. > >I guess I could remove it from -current. I know it's used in at >least Makefile.inc1. If I remove it, I suppose INSTALLFLAGS_EDIT >should be documented somewhere as the replacement, but I'm not >sure where the best place for this documentation is. > >Alternatively, I could simply reimplement it in bsd.lib.mk to >use the INSTALLFLAGS_EDIT. > >Comments? How about, in Makefile.inc1, Check to see if NOFSCHG is set. If it is, print out an error message which tells the user the "new way to do it", and abort. I am only suggesting this for current. I don't know where INSTALLFLAGS_EDIT should be documented, I assume it would be any place which presently documents NOFSCHG ... -- Garance Alistair Drosehn = gad@gilead.netel.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 Fri Sep 6 18:33:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B53837B400 for ; Fri, 6 Sep 2002 18:33:30 -0700 (PDT) Received: from cannon.ecf.utoronto.ca (cannon.ecf.utoronto.ca [128.100.8.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6569643E7B for ; Fri, 6 Sep 2002 18:33:29 -0700 (PDT) (envelope-from vanderh@ecf.utoronto.ca) Received: from p22.ecf (p22.ecf [128.100.8.82]) by cannon.ecf.utoronto.ca (8.9.3/8.9.3) with ESMTP id VAA01647; Fri, 6 Sep 2002 21:33:28 -0400 Received: (from vanderh@localhost) by p22.ecf (8.9.3/8.9.3) id VAA04241; Fri, 6 Sep 2002 21:33:28 -0400 Date: Fri, 6 Sep 2002 21:33:28 -0400 From: Tim Vanderhoek To: Garance A Drosihn Cc: Nate Lawson , Bruce Evans , arch@FreeBSD.ORG Subject: Re: Make more things honor NOFSCHG Message-ID: <20020906213328.A4208@p22.ecf> References: <20020906223815.D10867-100000@gamplex.bde.org> <20020906230850.GA27804@turquoise> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from drosih@rpi.edu on Fri, Sep 06, 2002 at 08:45:05PM -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Sep 06, 2002 at 08:45:05PM -0400, Garance A Drosihn wrote: > > I am only suggesting this for current. I don't know where > INSTALLFLAGS_EDIT should be documented, I assume it would be > any place which presently documents NOFSCHG ... > I don't think that NOFSCHG is documented. I guess the NOFSCHG would be documented in make.conf(5) if it were documented. -- If I could think of a two-line witty aphorism for you to remember me by, this would definitely be it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 6 22:57:52 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A76C37B400 for ; Fri, 6 Sep 2002 22:57:49 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F7B643E3B for ; Fri, 6 Sep 2002 22:57:48 -0700 (PDT) (envelope-from bde@zeta.org.au) 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 PAA15512; Sat, 7 Sep 2002 15:57:32 +1000 Date: Sat, 7 Sep 2002 16:05:04 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Garance A Drosihn Cc: Tim Vanderhoek , Nate Lawson , Subject: Re: Make more things honor NOFSCHG In-Reply-To: Message-ID: <20020907155523.T18055-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 6 Sep 2002, Garance A Drosihn wrote: > At 7:08 PM -0400 9/6/02, Tim Vanderhoek wrote: > > > >I think I left the old NOFSCHG in place because I didn't want to > >break people who used it. > > > >I guess I could remove it from -current. I know it's used in at OK with me. > >least Makefile.inc1. If I remove it, I suppose INSTALLFLAGS_EDIT > >should be documented somewhere as the replacement, but I'm not > >sure where the best place for this documentation is. > > > >Alternatively, I could simply reimplement it in bsd.lib.mk to > >use the INSTALLFLAGS_EDIT. That would defeat the point of simplifying things by not having 2 knobs (one of which only worked for libraries). > How about, in Makefile.inc1, > Check to see if NOFSCHG is set. If it is, print out an error > message which tells the user the "new way to do it", and abort. That would defeat the point of simplifiying things by removing cruft. > I am only suggesting this for current. I don't know where > INSTALLFLAGS_EDIT should be documented, I assume it would be > any place which presently documents NOFSCHG ... I think NOFSCHG is documented mainly in bsd.lib.mk,v: % RCS file: /home/ncvs/src/share/mk/bsd.lib.mk,v % Working file: bsd.lib.mk % head: 1.136 % ---------------------------- % revision 1.87 % date: 1999/06/24 22:50:19; author: jmg; state: Exp; lines: +3 -3 % add support to buildworld as a normal user: % -DNOFSCHG disables installation of libs with flag schg % GAMEGRP change the group with which games are installed % % also organize the binary section into alphebetical order some what.. % ---------------------------- This shows that it was only intended to work for buildworld. It doesn't affect programs because none that set fschg is installed by buildworld. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 7 2:20:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 6E3AA37B400; Sat, 7 Sep 2002 02:20:03 -0700 (PDT) Date: Sat, 7 Sep 2002 02:20:03 -0700 From: Juli Mallett To: freebsd-arch@FreeBSD.org Subject: CFR: signalinfo(3) Message-ID: <20020907022003.A66983@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-LiveJournal: flata, jmallett X-Negacore: Yes Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hey, I've been doing a bunch of signal related hackery tonight, adding a new signal, and testing things up and down, and I've run into something that irritated me a lot, and stalled me a number of times, to replicate a bit of code that I wasn't used to having to replicate. See, signal(3) installs handlers for the sa_handler variety of signal handlers, and yet this is not the only type of handler one might want to have, one might also want the "traditional" sa_sigaction handler style, which includes siginfo_t, and struct sigcontext, both of which are very useful, depending on the signal. So I wrote signalinfo(3) which installs *those* kinds of signal handlers, no fuss. And attached is a diff to libc, including minor modifications to signal(3)'s manual page, etc. I'd like to commit this pretty soon, so I can realistically look at providing sane means of doing a few things in the kernel, without it being impossible to write tiny little test cases on the fly. Plus I think others might find it useful, who knows. Thanks, juli. -- Juli Mallett | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger jmallett@FreeBSD.org --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="signalinfo.diff" Index: signal.3 =================================================================== RCS file: /home/ncvs/src/lib/libc/gen/signal.3,v retrieving revision 1.29 diff -d -u -r1.29 signal.3 --- signal.3 12 Jul 2002 01:30:18 -0000 1.29 +++ signal.3 7 Sep 2002 09:12:45 -0000 @@ -32,11 +32,11 @@ .\" @(#)signal.3 8.3 (Berkeley) 4/19/94 .\" $FreeBSD: src/lib/libc/gen/signal.3,v 1.29 2002/07/12 01:30:18 keramida Exp $ .\" -.Dd April 19, 1994 +.Dd September 6, 2002 .Dt SIGNAL 3 .Os .Sh NAME -.Nm signal +.Nm signal signalinfo .Nd simplified software signal facilities .Sh LIBRARY .Lb libc @@ -46,10 +46,13 @@ .\" fix it. .Ft void \*(lp* .Fn signal "int sig" "void \*(lp*func\*(rp\*(lpint\*(rp\*(rp\*(rp\*(lpint" +.Ft void \*(lp* +.Fn signalinfo "int sig" "void \*(lp*func\*(rp\*(lpint, siginfo_t *, struct sigcontext *\*(rp\*(rp\*(rp\*(lpint, siginfo_t *, struct sigcontext *\*(rp" .Pp or in .Fx Ns 's -equivalent but easier to read typedef'd version: +equivalent but easier to read typedef'd version of +.Nm .Ft typedef "void \*(lp*sig_t\*(rp \*(lpint\*(rp" .Ft sig_t .Fn signal "int sig" "sig_t func" @@ -60,6 +63,13 @@ is a simplified interface to the more general .Xr sigaction 2 facility. +The +.Fn signalinfo +facility is a simplified interface similar to the sighandler-specific +.Fn signal +facility, except that it is for full sigaction handlers, and sets the +.Dv SA_SIGINFO +.Em sa_flag . .Pp Signals allow the manipulation of a process from outside its domain as well as allowing the process to manipulate itself or @@ -241,3 +251,7 @@ .Fn signal facility appeared in .Bx 4.0 . +The +.Fn signalinfo +facility appreared in +.Fx 5.0 . Index: signal.c =================================================================== RCS file: /home/ncvs/src/lib/libc/gen/signal.c,v retrieving revision 1.3 diff -d -u -r1.3 signal.c --- signal.c 1 Feb 2002 00:57:29 -0000 1.3 +++ signal.c 7 Sep 2002 09:02:25 -0000 @@ -63,3 +63,20 @@ return (SIG_ERR); return (osa.sa_handler); } + +sig_t +signalinfo(s, a) + int s; + void (*a)(int, siginfo_t *, struct sigcontext *); +{ + struct sidaction sa, osa; + + sa.sa_sigaction = a; + sigemptyset(&sa.sa_mask); + sa.sa_flags = SA_SIGINFO; + if (!sigismember(&_sigintr, s)) + sa.sa_flags |= SA_RESTART; + if (_sigaction(s, &sa, &osa) < 0) + return (SIG_ERR); + return (osa.sa_sigaction); +} --a8Wt8u1KmwUX3Y2C-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 7 10:11:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2314A37B400; Sat, 7 Sep 2002 10:11:23 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E03543E3B; Sat, 7 Sep 2002 10:11:22 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.5) with ESMTP id g87HBLVo048551 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 7 Sep 2002 13:11:21 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.5/Submit) id g87HBLxO048550; Sat, 7 Sep 2002 13:11:21 -0400 (EDT) (envelope-from wollman) Date: Sat, 7 Sep 2002 13:11:21 -0400 (EDT) From: Garrett Wollman Message-Id: <200209071711.g87HBLxO048550@khavrinen.lcs.mit.edu> To: jmallett@FreeBSD.ORG Subject: Re: CFR: signalinfo(3) X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: <20020907022003.A66983@FreeBSD.org> Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <20020907022003.A66983@FreeBSD.org> you write: >See, signal(3) installs handlers for the sa_handler variety of signal >handlers, and yet this is not the only type of handler one might want >to have, one might also want the "traditional" sa_sigaction handler >style, which includes siginfo_t, and struct sigcontext, both of which >are very useful, depending on the signal. Actually, those are new-style (POSIX Real-Time Signals) handlers. The traditional (Standard C) style takes a single argument. The really-old-fashioned (4.2BSD, pre-C89) handlers provided three arguments but they weren't the same as the three arguments used in RTS handlers and in any case we don't support that now. >So I wrote signalinfo(3) >which installs *those* kinds of signal handlers, no fuss. I'm confused. Why would you want to use this? There is already a perfectly good interface for installing Real-Time Signal handlers, and it's specified in the standard: sigaction(3). I don't think that this convenience function belongs in the C library. -GAWollman -- Garrett A. Wollman | [G]enes make enzymes, and enzymes control the rates of wollman@lcs.mit.edu | chemical processes. Genes do not make ``novelty- Opinions not those of| seeking'' or any other complex and overt behavior. MIT, LCS, CRS, or NSA| - Stephen Jay Gould (1941-2002) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Sep 7 11:44:51 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4861C37B400 for ; Sat, 7 Sep 2002 11:44:49 -0700 (PDT) Received: from kayak.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BD0043E42 for ; Sat, 7 Sep 2002 11:44:48 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.6/8.11.4) with ESMTP id g87Iimt69833 for ; Sat, 7 Sep 2002 11:44:48 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id g87IjLXf003555 for ; Sat, 7 Sep 2002 11:45:21 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id g87IjLA7003554 for arch@FreeBSD.org; Sat, 7 Sep 2002 11:45:21 -0700 (PDT) Date: Sat, 7 Sep 2002 11:45:21 -0700 From: Marcel Moolenaar To: arch@FreeBSD.org Subject: fortune(6) is not cross-buildable Message-ID: <20020907184521.GB3388@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Gang, I had to cross-build alpha on my i386 box, because I probably messed up my alpha enough that it couldn't do a buildworld on its own. All went well, but a very crucial application was broken: fortune(6) :-) The problem is that strfile(8) is built as a buildtool and since the data file header is defined in terms of long integer it writes out a header that matches the build machine, not the target machine. In this case, the datafile had 32-bit wide fields, while on alpha those are 64-bit fields. The questions: 1. Do we care enough that we want to fix this? 2. If so, do we want to fix the data file header or do we want to fix strfile(8)? If we fix the header, then it will be truely portable. Unfortunately, this means that on some architectures the header changes and we need to take care of it. If we avoid changing the file format, but change strfile(8) to take cross-building into account we probably have the least impact in general, but strfile(8) may become a bit ugly... Thoughts? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message