From owner-freebsd-arch Tue Aug 21 10: 7: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id D14EC37B407; Tue, 21 Aug 2001 10:06:52 -0700 (PDT) (envelope-from iwasaki@jp.FreeBSD.org) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.11.3+3.4W/8.11.3/tasogare/smtpfeed 1.12) with ESMTP/inet id f7LH6aI12648; Wed, 22 Aug 2001 02:06:37 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: peter@wemm.org Cc: iwasaki@jp.FreeBSD.org, arch@FreeBSD.ORG, audit@FreeBSD.ORG, kumabu@t3.rim.or.jp Subject: Re: CFR: Timing to enable CR4.PGE bit In-Reply-To: <20010817072149.0BCD63811@overcee.netplex.com.au> References: <20010809035801V.iwasaki@jp.FreeBSD.org> <20010817072149.0BCD63811@overcee.netplex.com.au> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010822020634P.iwasaki@jp.FreeBSD.org> Date: Wed, 22 Aug 2001 02:06:34 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 86 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 Hi, thanks peter for your comments. > > Index: locore.s > > =================================================================== > > RCS file: /home/ncvs/src/sys/i386/i386/locore.s,v > > retrieving revision 1.144 > > diff -u -r1.144 locore.s > > --- locore.s 2001/07/12 06:32:50 1.144 > > +++ locore.s 2001/08/08 17:49:28 > > @@ -374,6 +374,12 @@ > > movl IdlePTD,%esi > > movl %esi,PCB_CR3(%eax) > > > > + testl $CPUID_PGE, R(cpu_feature) > > + jz 1f > > + movl %cr4, %eax > > + orl $CR4_PGE, %eax > > + movl %eax, %cr4 > > +1: > > pushl physfree /* value of first for init386(f > irst) */ > > call init386 /* wire 386 chip for unix opera > tion */ > > > > @@ -718,13 +724,6 @@ > > */ > > > > create_pagetables: > > - > > - testl $CPUID_PGE, R(cpu_feature) > > - jz 1f > > - movl %cr4, %eax > > - orl $CR4_PGE, %eax > > - movl %eax, %cr4 > > -1: > > > > /* Find end of kernel image (rounded up to a page boundary). */ > > movl $R(_end),%esi > > This part is fine. OK, I'll commit this one first. > However: > > > Also I have another thing to be confirmed. Should we utilize TLB by > > enabling PGE bit at very later stage? I think it would be more > > efficient to cache page entries with G flag in multi-user environment, > > not in kernel bootstrap. If we enable PGE bit in locore.s, TLB could > > be occupied by entries which is referenced by initialization code > > (yes, most of them are executed only once). > > # but I could be wrong... > > The G bit does not "lock" the TLB entries in. All it does is stop > unnecessary flushes when %cr3 is changed. If entries are not used > for a short while, they will be recycled when the TLB slot is needed > for something else soon enough. ie: this should not be a problem. My point is that users need higher system performance in multi-user environment rather than in kernel bootstrap. Also PGE bit has effects in multi-user environment where %cr3 is changed frequently. I think enabling PGE in early stage of kernel bootstrap won't give us performance advantages, entries which is used in bootstrap will remain in the TLB as Intel's document says; ---- 3.7. TRANSLATION LOOKASIDE BUFFERS (TLBS) [snip] When the processor loads a page-directory or page-table entry for a global page into a TLB, the entry will remain in the TLB indefinitely. The only way to deterministically invalidate global page entries is to clear the PGE flag and then invalidate the TLBs or to use the INVLPG instruction to invalidate individual page-directory or page-table entries in the TLBs. ---- According to i386/locore.s, it seems that PTEs for kernel text, data, bss and symbols have PG_G bit, I worry that it is enough many to fill TLB slot out... > Regardless of my doubts above, I do have a problem with the patch... > It only works for the PPro/p2/p3 and not the p4. Is this intentional? > All have the CPUID_PGE bit. I think the test for cpu_id & 0x600 is > bogus and should be removed. Understood. Thanks for pointing it out. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 21 22:56: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 74EDD37B40A; Tue, 21 Aug 2001 22:55:45 -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 PAA20801; Wed, 22 Aug 2001 15:55:23 +1000 Date: Wed, 22 Aug 2001 15:55:18 +1000 (EST) From: Bruce Evans X-X-Sender: To: Mitsuru IWASAKI Cc: , , , Subject: Re: CFR: Timing to enable CR4.PGE bit In-Reply-To: <20010822020634P.iwasaki@jp.FreeBSD.org> Message-ID: <20010822154635.P6058-100000@besplex.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, 22 Aug 2001, Mitsuru IWASAKI wrote: > Hi, thanks peter for your comments. > > The G bit does not "lock" the TLB entries in. All it does is stop > > unnecessary flushes when %cr3 is changed. If entries are not used > > for a short while, they will be recycled when the TLB slot is needed > > for something else soon enough. ie: this should not be a problem. > > My point is that users need higher system performance in multi-user > environment rather than in kernel bootstrap. Also PGE bit has effects > in multi-user environment where %cr3 is changed frequently. > I think enabling PGE in early stage of kernel bootstrap won't give us > performance advantages, entries which is used in bootstrap will remain > in the TLB as Intel's document says; > ---- > 3.7. TRANSLATION LOOKASIDE BUFFERS (TLBS) > [snip] > When the processor loads a page-directory or page-table entry for a > global page into a TLB, the entry will remain in the TLB indefinitely. ^^^^^^^^^^^^ > The only way to deterministically invalidate global page entries is to > clear the PGE flag and then invalidate the TLBs or to use the INVLPG > instruction to invalidate individual page-directory or page-table > entries in the TLBs. > ---- I think this just means that it is hard to say how long the entries remain in the TLB, not thatthey remain there forever. > According to i386/locore.s, it seems that PTEs for kernel text, data, > bss and symbols have PG_G bit, I worry that it is enough many to fill > TLB slot out... > > > Regardless of my doubts above, I do have a problem with the patch... > > It only works for the PPro/p2/p3 and not the p4. Is this intentional? > > All have the CPUID_PGE bit. I think the test for cpu_id & 0x600 is > > bogus and should be removed. Another thing I don't like about it: it uses a SYSINIT() so it obfuscates the initialization order. The problem fixed by the other half of your patch shows that it's hard enough to get the order right when the initializations are done inline. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 22 0:29:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id E78C437B406; Wed, 22 Aug 2001 00:29:02 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.135.228.Dial1.SanJose1.Level3.net [209.245.135.228]) by snipe.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f7M7Skh05589; Wed, 22 Aug 2001 00:28:46 -0700 (PDT) Message-ID: <3B835F58.68534CCE@mindspring.com> Date: Wed, 22 Aug 2001 00:29:28 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mitsuru IWASAKI Cc: peter@wemm.org, arch@FreeBSD.ORG, audit@FreeBSD.ORG, kumabu@t3.rim.or.jp Subject: Re: CFR: Timing to enable CR4.PGE bit References: <20010809035801V.iwasaki@jp.FreeBSD.org> <20010817072149.0BCD63811@overcee.netplex.com.au> <20010822020634P.iwasaki@jp.FreeBSD.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 Mitsuru IWASAKI wrote: > > This part is fine. > > OK, I'll commit this one first. What does setting PGE early do for you? I use PGE to avoid TLB shootdown on a number of memory regions shared between user and kernel space (including zero system call time functions), but setting it early seems wrong. Specifically, the conceptual idea is to make a VM that looks exactly like real memory, with the smallest relocation code chunk possible, so that as much as possible can be done in C code, and there's as little strangeness as possible (e.g. the evil that is machdep.c, and the "magic" numbers in pmap.h that have to match exactly the magic address at which the kernel gets linked, and have to be offset exactly by the SMP pages and other "off by one" hidden values). > > However: > > > > > Also I have another thing to be confirmed. Should we utilize TLB by > > > enabling PGE bit at very later stage? I think it would be more > > > efficient to cache page entries with G flag in multi-user environment, > > > not in kernel bootstrap. If we enable PGE bit in locore.s, TLB could > > > be occupied by entries which is referenced by initialization code > > > (yes, most of them are executed only once). > > > # but I could be wrong... PGE might be useful for shared libraries. It's set on the kernel itself, which means that trapping to kernel mode does not end up costing unnecessary overhead. It's kind of ugly, when the 4M page is set on the kernel, which loses the page table page for the 4k pages (yuck), and it's not nice for the case where the kernel gets larger than 4M. From a practical point of view, the hassle of having to set and unset a bit in CR3 to cause the TLB shootdown to occur is not really worth setting the PGE bit so early that you do not have most of the PTE's set up. > > The G bit does not "lock" the TLB entries in. All it does is stop > > unnecessary flushes when %cr3 is changed. If entries are not used > > for a short while, they will be recycled when the TLB slot is needed > > for something else soon enough. ie: this should not be a problem. It also stops necessary ones, unless you bounce it off, hit CR3, and bounce it back on... that's the strange code around the 4M page enable code. > My point is that users need higher system performance in multi-user > environment rather than in kernel bootstrap. Also PGE bit has effects > in multi-user environment where %cr3 is changed frequently. > I think enabling PGE in early stage of kernel bootstrap won't give us > performance advantages, entries which is used in bootstrap will remain > in the TLB as Intel's document says; > ---- > 3.7. TRANSLATION LOOKASIDE BUFFERS (TLBS) > [snip] > When the processor loads a page-directory or page-table entry for a > global page into a TLB, the entry will remain in the TLB indefinitely. > The only way to deterministically invalidate global page entries is to > clear the PGE flag and then invalidate the TLBs or to use the INVLPG > instruction to invalidate individual page-directory or page-table > entries in the TLBs. > ---- The INVLPG doesn't work exactly like you think it should, with PGE on, on more recent processors, unfortunately. > According to i386/locore.s, it seems that PTEs for kernel text, data, > bss and symbols have PG_G bit, I worry that it is enough many to fill > TLB slot out... The kernel is in a 4M page in most cases, so it's not an issue in most cases. It's really very important that you not have to flush in the case of a kernel entry (interrupt, system call, etc.), since it _will_ make a protection domain crossing significantly more expensive. Also, note that the 4M pages are in a seperate 8 entry conflict domain, and aren't in the same 16 entry data or 16 entry instruction TLB's, on every processor where they are supported, so the kernel is not competing with user space code anyway. NB: 4M pages only make sense in certain specific limited situations... using up 4M chunks of KVA space is generally a bad idea, unless the objects you are using them for are really 4M or larger in size. This is particularly true on 4G machines, where you really don't have any sparseness to burn on unused pages, and can't afford to use the remainder space without the same mapping you used for the rest of it (e.g. for libc.so, a copy-on-write page that is also executable, unless you split the code and data across the page boundary). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 22 0:36:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id EB8C237B405; Wed, 22 Aug 2001 00:36:28 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f7M7aSM77733; Wed, 22 Aug 2001 00:36:28 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id B64AB38FD; Wed, 22 Aug 2001 00:36:28 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: tlambert2@mindspring.com Cc: Mitsuru IWASAKI , arch@FreeBSD.ORG, audit@FreeBSD.ORG, kumabu@t3.rim.or.jp Subject: Re: CFR: Timing to enable CR4.PGE bit In-Reply-To: <3B835F58.68534CCE@mindspring.com> Date: Wed, 22 Aug 2001 00:36:28 -0700 From: Peter Wemm Message-Id: <20010822073628.B64AB38FD@overcee.netplex.com.au> 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 Terry Lambert wrote: > Mitsuru IWASAKI wrote: > > > This part is fine. > > > > OK, I'll commit this one first. > > What does setting PGE early do for you? The change is to avoid violating the rules in the CPU developers guide. Did you read the thread? Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 22 0:53:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 3802137B40D; Wed, 22 Aug 2001 00:53:33 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f7M7rXM77828; Wed, 22 Aug 2001 00:53:33 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id F003238FD; Wed, 22 Aug 2001 00:53:32 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Mitsuru IWASAKI Cc: arch@FreeBSD.ORG, audit@FreeBSD.ORG, kumabu@t3.rim.or.jp Subject: Re: CFR: Timing to enable CR4.PGE bit In-Reply-To: <20010822020634P.iwasaki@jp.FreeBSD.org> Date: Wed, 22 Aug 2001 00:53:32 -0700 From: Peter Wemm Message-Id: <20010822075332.F003238FD@overcee.netplex.com.au> 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 Mitsuru IWASAKI wrote: > > However: > > > > > Also I have another thing to be confirmed. Should we utilize TLB by > > > enabling PGE bit at very later stage? I think it would be more > > > efficient to cache page entries with G flag in multi-user environment, > > > not in kernel bootstrap. If we enable PGE bit in locore.s, TLB could > > > be occupied by entries which is referenced by initialization code > > > (yes, most of them are executed only once). > > > # but I could be wrong... > > > > The G bit does not "lock" the TLB entries in. All it does is stop > > unnecessary flushes when %cr3 is changed. If entries are not used > > for a short while, they will be recycled when the TLB slot is needed > > for something else soon enough. ie: this should not be a problem. > > My point is that users need higher system performance in multi-user > environment rather than in kernel bootstrap. Also PGE bit has effects > in multi-user environment where %cr3 is changed frequently. > I think enabling PGE in early stage of kernel bootstrap won't give us > performance advantages, entries which is used in bootstrap will remain > in the TLB as Intel's document says; > ---- > 3.7. TRANSLATION LOOKASIDE BUFFERS (TLBS) > [snip] > When the processor loads a page-directory or page-table entry for a > global page into a TLB, the entry will remain in the TLB indefinitely. > The only way to deterministically invalidate global page entries is to > clear the PGE flag and then invalidate the TLBs or to use the INVLPG > instruction to invalidate individual page-directory or page-table > entries in the TLBs. > ---- > > According to i386/locore.s, it seems that PTEs for kernel text, data, > bss and symbols have PG_G bit, I worry that it is enough many to fill > TLB slot out... No. All that this means is that the cpu will not flush them with a %cr3 reload. The cpu will still recycle the TLB slots as it sees fit. It just wont do it because we switch tasks. This is exactly what we want. PG_G does not mean they will stay there forever. If it did, then merely having 64 pages with PG_G set would mean we would lock up all the TLB entries forever. On a generic kernel, there are 154 pages of data + bss alone. If they were unable to be flushed from the tlb, then that would account for more than all tlb slots on current cpus. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 22 1: 2:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id DA48F37B403; Wed, 22 Aug 2001 01:02:25 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.135.228.Dial1.SanJose1.Level3.net [209.245.135.228]) by snipe.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f7M82Kh04101; Wed, 22 Aug 2001 01:02:20 -0700 (PDT) Message-ID: <3B836737.9C15EA8@mindspring.com> Date: Wed, 22 Aug 2001 01:03:03 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Mitsuru IWASAKI , arch@FreeBSD.ORG, audit@FreeBSD.ORG, kumabu@t3.rim.or.jp Subject: Re: CFR: Timing to enable CR4.PGE bit References: <20010822073628.B64AB38FD@overcee.netplex.com.au> 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 Peter Wemm wrote: > Terry Lambert wrote: > > Mitsuru IWASAKI wrote: > > > > This part is fine. > > > > > > OK, I'll commit this one first. > > > > What does setting PGE early do for you? > > The change is to avoid violating the rules in the CPU developers > guide. Did you read the thread? Yes. I still don't get what rules are being broken (no one quoted anything in comments inline in the code, citing the relevent pages in the guide, with a URL for the guide, for example). Let me ask again: what was broken before that is now fixed? To me, it seems that this will load the PGE bit enabled entries for the 4K pages into core exceptionally early, and that doing this will conflict with the later 4M page entry, which will end up having its own mapping (since 4M pages have their own, seperate table), and thus I will end up with two mappings for the same pages, neither of which can be easily invalidated on a P3 or P4 without toggling PGE off first, since they all have the PG_G bit set in them. I can tell you from personal experience on a Tyan Tiger with 1G of RAM and on a Super Micro with 4G of RAM that this can lead to very bad problems, unless you have enough entries being made in the KVA space to cause the invalidations to LRU out the pages... specifically, I saw some very interesting faults with mbufs, until I grew some kernel structures large enough to force the shootdown during the normal boot process, and it wasn't until later that I recognized the origin of the problem. It used to be that you could just reload CR3 with the same value to force an invalidation of pages without PG_G set with PGE enabled, or with PG_G set, without PGE enabled, but that's no longer true on newer systems, which will forego the invalidation if you are reloading the same value (for obvious performance reasons). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 22 1:28: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 495DF37B40E; Wed, 22 Aug 2001 01:27:50 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f7M8RoM78007; Wed, 22 Aug 2001 01:27:50 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id ED86038FD; Wed, 22 Aug 2001 01:27:49 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: tlambert2@mindspring.com Cc: Mitsuru IWASAKI , arch@FreeBSD.ORG, audit@FreeBSD.ORG, kumabu@t3.rim.or.jp Subject: Re: CFR: Timing to enable CR4.PGE bit In-Reply-To: <3B836737.9C15EA8@mindspring.com> Date: Wed, 22 Aug 2001 01:27:49 -0700 From: Peter Wemm Message-Id: <20010822082749.ED86038FD@overcee.netplex.com.au> 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 Terry Lambert wrote: > Peter Wemm wrote: > > Terry Lambert wrote: > > > Mitsuru IWASAKI wrote: > > > > > This part is fine. > > > > > > > > OK, I'll commit this one first. > > > > > > What does setting PGE early do for you? > > > > The change is to avoid violating the rules in the CPU developers > > guide. Did you read the thread? > > Yes. I still don't get what rules are being broken (no one > quoted anything in comments inline in the code, citing the > relevent pages in the guide, with a URL for the guide, for > example). > > Let me ask again: what was broken before that is now fixed? The very first article in the thread said: ======== According to developer's manual from Intel site, ftp://download.intel.com/design/PentiumII/manuals/24319202.pdf ---- 2.5. CONTROL REGISTERS [snip] PGE (2-17) Page Global Enable (bit 7 of CR4). (Introduced in the P6 family processors.) Enables the global page feature when set; disables the global page feature when clear. [snip] In addition, the bit must not ^^^^^^^^^^^^^^^^ be enabled before paging is enabled via CR0.PG. Program correctness ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ may be affected by reversing this sequence, and processor performance will be impacted. ---- Currently, we enable CR4.PGE bit in create_pagetables, then enable CR0.PG in locore.s. This seems to violate Intel's note. ====== This was in: Message-id: <20010809035801V.iwasaki@jp.FreeBSD.org> Subject: CFR: Timing to enable CR4.PGE bit From: Mitsuru IWASAKI Date: Thu, 09 Aug 2001 03:58:01 +0900 To: arch@FreeBSD.ORG Cc: audit@FreeBSD.ORG, kumabu@t3.rim.or.jp .. which is why I asked if you read the entire thread. I thought that quote was quite clear that we were in violation. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 22 1:49:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 82B5837B413; Wed, 22 Aug 2001 01:49:00 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f7M8n0M78097; Wed, 22 Aug 2001 01:49:00 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 4306738FD; Wed, 22 Aug 2001 01:49:00 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: tlambert2@mindspring.com Cc: Mitsuru IWASAKI , arch@FreeBSD.ORG, audit@FreeBSD.ORG, kumabu@t3.rim.or.jp Subject: Re: CFR: Timing to enable CR4.PGE bit In-Reply-To: <3B836737.9C15EA8@mindspring.com> Date: Wed, 22 Aug 2001 01:49:00 -0700 From: Peter Wemm Message-Id: <20010822084900.4306738FD@overcee.netplex.com.au> 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 Terry Lambert wrote: [the other part] > To me, it seems that this will load the PGE bit enabled > entries for the 4K pages into core exceptionally early, and > that doing this will conflict with the later 4M page entry, > which will end up having its own mapping (since 4M pages have > their own, seperate table), and thus I will end up with two > mappings for the same pages, neither of which can be easily > invalidated on a P3 or P4 without toggling PGE off first, > since they all have the PG_G bit set in them. While this is true, we do not change the wiring of the text+data+bss virtual -> physical pages that are double-mapped when we round up to the 4MB boundary. (see pmap_choose_addr() for the roundup) While they should never conflict and are never changed, I could imagine that having 4K and 4MB tlb's matching on the same virtual address could possibly cause some odd behavior, I'm a little doubtful. I would have expected it to turn up on other cpu brands (eg: athlon, transmeta etc) by now. > I can tell you from personal experience on a Tyan Tiger > with 1G of RAM and on a Super Micro with 4G of RAM that > this can lead to very bad problems, unless you have enough > entries being made in the KVA space to cause the invalidations > to LRU out the pages... specifically, I saw some very > interesting faults with mbufs, until I grew some kernel > structures large enough to force the shootdown during the > normal boot process, and it wasn't until later that I > recognized the origin of the problem. It would be cleaner to make a decision once in pmap_bootstrap() that went through and flipped PG_G on either the the 4MB page or the underlying 4K pages. That way there would be no possible overlapping PG_G tlb entries. > It used to be that you could just reload CR3 with the same > value to force an invalidation of pages without PG_G set > with PGE enabled, or with PG_G set, without PGE enabled, > but that's no longer true on newer systems, which will > forego the invalidation if you are reloading the same value > (for obvious performance reasons). I dont think we did this anyway. Once set, PG_G and PGE stayed set forever. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 22 1:58:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by hub.freebsd.org (Postfix) with ESMTP id C4C6937B406; Wed, 22 Aug 2001 01:58:47 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.135.228.Dial1.SanJose1.Level3.net [209.245.135.228]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id BAA23034; Wed, 22 Aug 2001 01:57:18 -0700 (PDT) Message-ID: <3B837418.2D5529E5@mindspring.com> Date: Wed, 22 Aug 2001 01:58:00 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Mitsuru IWASAKI , arch@FreeBSD.ORG, audit@FreeBSD.ORG, kumabu@t3.rim.or.jp Subject: Re: CFR: Timing to enable CR4.PGE bit References: <20010822082749.ED86038FD@overcee.netplex.com.au> 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 Peter Wemm wrote: > Page Global Enable (bit 7 of CR4). (Introduced in the P6 family > processors.) Enables the global page feature when set; disables the > global page feature when clear. [snip] In addition, the bit must not > ^^^^^^^^^^^^^^^^ > be enabled before paging is enabled via CR0.PG. Program correctness > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > may be affected by reversing this sequence, and processor performance > will be impacted. > ---- > > Currently, we enable CR4.PGE bit in create_pagetables, then enable > CR0.PG in locore.s. This seems to violate Intel's note. Ah. It looked like an inverted patch to me... it moved the code from line 725 or so in locore.s to line 375. I think moving this to _much_ later would not be a bad idea, since the only effect will be that the PG_G bit is ignored until it's actually enabled, right? FWIW: The message you quoted was from a cross-post from -audit to -arch, which I guess originally came from -audit? So the answer is "no, I didn't see the whole thread", and I only became interested enough to read it when I saw the assemply patch fly by on -arch. So since it's moving the enable to much later in the process (but earlier in the file -- in the old days, we used to program in order 8-)), I definitely don't object, unless I can talk you guys into delaying it until the 4M page for the kernel is being enabled... > .. which is why I asked if you read the entire thread. I thought that > quote was quite clear that we were in violation. I don't subscribe to audit, and the quoted stuff didn't look that important, so I didn't see it until now... sorry. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 22 2: 6:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (dialmess.nanolink.com [217.75.135.246]) by hub.freebsd.org (Postfix) with SMTP id AD94B37B403 for ; Wed, 22 Aug 2001 02:05:43 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 9040 invoked by uid 1000); 22 Aug 2001 09:04:02 -0000 Date: Wed, 22 Aug 2001 12:04:02 +0300 From: Peter Pentchev To: Terry Lambert Cc: Peter Wemm , Mitsuru IWASAKI , arch@FreeBSD.ORG, audit@FreeBSD.ORG, kumabu@t3.rim.or.jp Subject: Re: CFR: Timing to enable CR4.PGE bit Message-ID: <20010822120402.A8694@ringworld.oblivion.bg> Mail-Followup-To: Terry Lambert , Peter Wemm , Mitsuru IWASAKI , arch@FreeBSD.ORG, audit@FreeBSD.ORG, kumabu@t3.rim.or.jp References: <20010822082749.ED86038FD@overcee.netplex.com.au> <3B837418.2D5529E5@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B837418.2D5529E5@mindspring.com>; from tlambert2@mindspring.com on Wed, Aug 22, 2001 at 01:58:00AM -0700 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, Aug 22, 2001 at 01:58:00AM -0700, Terry Lambert wrote: > Peter Wemm wrote: > > Page Global Enable (bit 7 of CR4). (Introduced in the P6 family > > processors.) Enables the global page feature when set; disables the > > global page feature when clear. [snip] In addition, the bit must not > > ^^^^^^^^^^^^^^^^ > > be enabled before paging is enabled via CR0.PG. Program correctness > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > may be affected by reversing this sequence, and processor performance > > will be impacted. > > ---- > > > > Currently, we enable CR4.PGE bit in create_pagetables, then enable > > CR0.PG in locore.s. This seems to violate Intel's note. > > Ah. It looked like an inverted patch to me... it moved the > code from line 725 or so in locore.s to line 375. > > I think moving this to _much_ later would not be a bad idea, > since the only effect will be that the PG_G bit is ignored > until it's actually enabled, right? > > FWIW: The message you quoted was from a cross-post from -audit > to -arch, which I guess originally came from -audit? So the > answer is "no, I didn't see the whole thread", and I only > became interested enough to read it when I saw the assemply > patch fly by on -arch. The message he quoted was the original message in the thread, addressed to *both* -arch and -audit. Here are the relevant headers: To: arch@FreeBSD.ORG Cc: audit@FreeBSD.ORG, kumabu@t3.rim.or.jp Subject: CFR: Timing to enable CR4.PGE bit Date: Thu, 09 Aug 2001 03:58:01 +0900 From: Mitsuru IWASAKI G'luck, Peter -- No language can express every thought unambiguously, least of all this one. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 22 2:23: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id E706837B407; Wed, 22 Aug 2001 02:22:56 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f7M9MuM78491; Wed, 22 Aug 2001 02:22:56 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 9D3F73905; Wed, 22 Aug 2001 02:22:56 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: tlambert2@mindspring.com Cc: Mitsuru IWASAKI , arch@FreeBSD.ORG, audit@FreeBSD.ORG, kumabu@t3.rim.or.jp Subject: Re: CFR: Timing to enable CR4.PGE bit In-Reply-To: <3B837418.2D5529E5@mindspring.com> Date: Wed, 22 Aug 2001 02:22:56 -0700 From: Peter Wemm Message-Id: <20010822092256.9D3F73905@overcee.netplex.com.au> 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 Terry Lambert wrote: > FWIW: The message you quoted was from a cross-post from -audit > to -arch, which I guess originally came from -audit? So the > answer is "no, I didn't see the whole thread", and I only > became interested enough to read it when I saw the assemply > patch fly by on -arch. No, it was To: arch, cc: audit. It was just about a week ago. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 22 2:34:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (dialmess.nanolink.com [217.75.135.246]) by hub.freebsd.org (Postfix) with SMTP id BA4D837B407 for ; Wed, 22 Aug 2001 02:34:25 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 12895 invoked by uid 1000); 22 Aug 2001 09:33:01 -0000 Date: Wed, 22 Aug 2001 12:33:01 +0300 From: Peter Pentchev To: arch@FreeBSD.org Subject: kern/29931: problems with kern.corefile handling Message-ID: <20010822123301.D8694@ringworld.oblivion.bg> Reply-To: freebsd-gnats-submit@FreeBSD.org Mail-Followup-To: arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, This looks genuine. Any objections to committing it, and MFC'ing before 4.4 comes out? G'luck, Peter -- .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI ----- Forwarded message from Foldi Tamas ----- Date: 21 Aug 2001 22:07:51 +0200 From: Foldi Tamas To: FreeBSD-gnats-submit@freebsd.org Subject: kern/29931: problems with kern.corefile handling >Number: 29931 >Category: kern >Synopsis: if expand_name() return with NULL, coredump() crashes the kernel >Responsible: freebsd-bugs >State: open >Originator: Foldi Tamas >Release: FreeBSD 4.3-RELEASE i386 >Organization: Nektor IT >Environment: System: FreeBSD mancika.kapusoft 4.3-RELEASE FreeBSD 4.3-RELEASE #0: Sat Apr 21 10:54:49 GMT 2001 jkh@narf.osd.bsdi.com:/usr/src/sys/compile/GENERIC i386 Generic kernel. x86 architecture. >Description: When the expand_name() generates too large core filename, it's return value is NULL address. This NULL value is given to vn_open(), which causes kernel panic. In some cases (non default kern.corefile settings) users can freeze the system (of course, root always can). >How-To-Repeat: #!/bin/sh /sbin/sysctl -w kern.corefile=`perl -e 'print "%N" x 512'` echo 'int main (){int *a;printf("segfaulting...\n");printf("%u",*a);}'>/tmp/seg.c cd /tmp && make seg && /tmp/seg cd - >Fix: --- kern_sig.c.orig Thu Feb 22 06:15:04 2001 +++ kern_sig.c Tue Aug 21 11:35:35 2001 @@ -1620,6 +1620,8 @@ return 0; name = expand_name(p->p_comm, p->p_ucred->cr_uid, p->p_pid); + if (name == NULL) + return (EINVAL); NDINIT(&nd, LOOKUP, NOFOLLOW, UIO_SYSSPACE, name, p); error = vn_open(&nd, O_CREAT | FWRITE | O_NOFOLLOW, S_IRUSR | S_IWUSR); free(name, M_TEMP); >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 22 2:53:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by hub.freebsd.org (Postfix) with ESMTP id 7DB5237B40A; Wed, 22 Aug 2001 02:53:29 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.135.228.Dial1.SanJose1.Level3.net [209.245.135.228]) by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id CAA22320; Wed, 22 Aug 2001 02:51:57 -0700 (PDT) Message-ID: <3B8380E6.E4FC07B3@mindspring.com> Date: Wed, 22 Aug 2001 02:52:38 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Pentchev Cc: Peter Wemm , Mitsuru IWASAKI , arch@FreeBSD.ORG, audit@FreeBSD.ORG, kumabu@t3.rim.or.jp Subject: Re: CFR: Timing to enable CR4.PGE bit References: <20010822082749.ED86038FD@overcee.netplex.com.au> <3B837418.2D5529E5@mindspring.com> <20010822120402.A8694@ringworld.oblivion.bg> 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 Peter Pentchev wrote: > > FWIW: The message you quoted was from a cross-post from -audit > > to -arch, which I guess originally came from -audit? So the > > answer is "no, I didn't see the whole thread", and I only > > became interested enough to read it when I saw the assemply > > patch fly by on -arch. > > The message he quoted was the original message in the thread, > addressed to *both* -arch and -audit. Here are the relevant > headers: > > To: arch@FreeBSD.ORG > Cc: audit@FreeBSD.ORG, kumabu@t3.rim.or.jp > Subject: CFR: Timing to enable CR4.PGE bit > Date: Thu, 09 Aug 2001 03:58:01 +0900 > From: Mitsuru IWASAKI Sorry; it did not arrive here that way: it did not arrive here at all. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 22 9:41: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id E164D37B41A; Wed, 22 Aug 2001 09:40:49 -0700 (PDT) (envelope-from iwasaki@jp.FreeBSD.org) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.11.3+3.4W/8.11.3/tasogare/smtpfeed 1.12) with ESMTP/inet id f7MGeRI50789; Thu, 23 Aug 2001 01:40:27 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: tlambert2@mindspring.com Cc: peter@wemm.org, iwasaki@jp.FreeBSD.org, arch@FreeBSD.ORG, audit@FreeBSD.ORG, kumabu@t3.rim.or.jp Subject: Re: CFR: Timing to enable CR4.PGE bit In-Reply-To: <3B837418.2D5529E5@mindspring.com> References: <20010822082749.ED86038FD@overcee.netplex.com.au> <3B837418.2D5529E5@mindspring.com> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010823014025T.iwasaki@jp.FreeBSD.org> Date: Thu, 23 Aug 2001 01:40:25 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 35 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 Hi, thanks folks for comments and sorry for my late reply. Terry Lambert wrote: > Peter Wemm wrote: > > Page Global Enable (bit 7 of CR4). (Introduced in the P6 family > > processors.) Enables the global page feature when set; disables the > > global page feature when clear. [snip] In addition, the bit must not > > ^^^^^^^^^^^^^^^^ > > be enabled before paging is enabled via CR0.PG. Program correctness > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > may be affected by reversing this sequence, and processor performance > > will be impacted. > > ---- > > > > Currently, we enable CR4.PGE bit in create_pagetables, then enable > > CR0.PG in locore.s. This seems to violate Intel's note. > > Ah. It looked like an inverted patch to me... it moved the > code from line 725 or so in locore.s to line 375. I've just committed only part of moving CR4.PGE enabling code after paging is enabled. It was my primary goal to avoid violating the rules in the CPU developer's manual. Thanks folks! Another part of my original post was just for my curiosity, it's not so important. I thought it would be valuable to be considered if we can get better performance by moving CR4.PGE bit on to later stage without a lot of efforts. But I'm not sure how effective it is. There may be hardly effect. Does anyone test and measure it under suitable environment? If we get good result by this without any problems, then we can consider this issue again (including how to fire PGE enabling code as Bruce suggested), I think. Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 22 9:55:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id BF85A37B43B; Wed, 22 Aug 2001 09:54:17 -0700 (PDT) (envelope-from iwasaki@jp.FreeBSD.org) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.11.3+3.4W/8.11.3/tasogare/smtpfeed 1.12) with ESMTP/inet id f7MGsEI53226; Thu, 23 Aug 2001 01:54:14 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: bde@zeta.org.au Cc: iwasaki@jp.FreeBSD.org, peter@wemm.org, arch@FreeBSD.ORG, audit@FreeBSD.ORG, kumabu@t3.rim.or.jp Subject: Re: CFR: Timing to enable CR4.PGE bit In-Reply-To: <20010822154635.P6058-100000@besplex.bde.org> References: <20010822020634P.iwasaki@jp.FreeBSD.org> <20010822154635.P6058-100000@besplex.bde.org> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010823015412F.iwasaki@jp.FreeBSD.org> Date: Thu, 23 Aug 2001 01:54:12 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 21 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 Hi, > > 3.7. TRANSLATION LOOKASIDE BUFFERS (TLBS) > > [snip] > > When the processor loads a page-directory or page-table entry for a > > global page into a TLB, the entry will remain in the TLB indefinitely. > ^^^^^^^^^^^^ > > The only way to deterministically invalidate global page entries is to > > clear the PGE flag and then invalidate the TLBs or to use the INVLPG > > instruction to invalidate individual page-directory or page-table > > entries in the TLBs. > > ---- > > I think this just means that it is hard to say how long the entries remain > in the TLB, not thatthey remain there forever. Ah, understood. Japanese version of this document said it's something like `forever' in Japanese translation for this meaning :-) This is why I worried about this too much. Sorry about that. Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 22 10:23: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 8C47B37B40A for ; Wed, 22 Aug 2001 10:22:44 -0700 (PDT) (envelope-from iwasaki@jp.FreeBSD.org) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.11.3+3.4W/8.11.3/tasogare) with ESMTP/inet id f7MHMgI58039 for ; Thu, 23 Aug 2001 02:22:42 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: arch@FreeBSD.ORG Subject: CFR: Reenabling RTC interrupts after wakeup X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010823022240W.iwasaki@jp.FreeBSD.org> Date: Thu, 23 Aug 2001 02:22:40 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 68 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 Hi, I've noticed that RTC interrupts never be generated on some machines after sleep/wakeup by ACPI. As a result, statclock() stops and system statistics monitoring tools (such as systat, vmstat...) may have problems. I think that this problem is not only with ACPI, but also with APM because I saw the same kind of reports before (in mobile@ ?). Here the fix for this, please review it. I'll commit this comming weekend if no objections. Thanks Index: include/clock.h =================================================================== RCS file: /home/ncvs/src/sys/i386/include/clock.h,v retrieving revision 1.39 diff -u -r1.39 clock.h --- include/clock.h 2000/10/15 09:51:48 1.39 +++ include/clock.h 2001/08/21 14:44:29 @@ -44,6 +44,7 @@ #endif int sysbeep __P((int pitch, int period)); void i8254_restore __P((void)); +void rtc_restore __P((void)); #endif /* _KERNEL */ Index: isa/clock.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/clock.c,v retrieving revision 1.174 diff -u -r1.174 clock.c --- isa/clock.c 2001/05/15 23:22:21 1.174 +++ isa/clock.c 2001/08/21 14:43:32 @@ -716,6 +716,17 @@ mtx_unlock_spin(&clock_lock); } +void +rtc_restore(void) +{ + + mtx_lock_spin(&clock_lock); + /* Reenable RTC updates and interrupts. */ + writertc(RTC_STATUSB, RTCSB_HALT | RTCSB_24HR); + writertc(RTC_STATUSB, rtc_statusb); + mtx_unlock_spin(&clock_lock); +} + /* * Initialize 8254 timer 0 early so that it can be used in DELAY(). * XXX initialization of other timers is unintentionally left blank. Index: isa/pmtimer.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/pmtimer.c,v retrieving revision 1.1 diff -u -r1.1 pmtimer.c --- isa/pmtimer.c 2000/09/14 22:34:57 1.1 +++ isa/pmtimer.c 2001/08/21 15:04:04 @@ -84,6 +84,7 @@ /* modified for adjkerntz */ pl = splsoftclock(); i8254_restore(); /* restore timer_freq and hz */ + rtc_restore(); /* reenable RTC interrupts */ inittodr(0); /* adjust time to RTC */ microtime(&resume_time); getmicrotime(&tmp_time); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 23 12: 7:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from kawoserv.kawo2.rwth-aachen.de (kawoserv.kawo2.RWTH-Aachen.DE [134.130.180.1]) by hub.freebsd.org (Postfix) with ESMTP id 9E7C037B407; Thu, 23 Aug 2001 12:07:29 -0700 (PDT) (envelope-from alex@big.endian.de) Received: from zerogravity.kawo2.rwth-aachen.de (zerogravity.kawo2.rwth-aachen.de [134.130.181.28]) by kawoserv.kawo2.rwth-aachen.de (8.9.3/8.9.3) with ESMTP id VAA25474; Thu, 23 Aug 2001 21:07:29 +0200 Received: by zerogravity.kawo2.rwth-aachen.de (Postfix, from userid 1001) id 6C18714B0E; Thu, 23 Aug 2001 21:07:30 +0200 (CEST) Date: Thu, 23 Aug 2001 21:07:29 +0200 From: Alexander Langer To: arch@FreeBSD.org Cc: ports@FreeBSD.org Subject: ports.conf Message-ID: <20010823210729.A95484@zerogravity.kawo2.rwth-aachen.d> Mail-Followup-To: Alexander Langer , arch@FreeBSD.org, ports@FreeBSD.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline User-Agent: Mutt/1.2.5i X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. 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 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi folks! Inspired by a comment from JHB on IRC, I removed all ports relevant entries from /etc/defaults/make.conf and put them into a new ports.conf, along with some new entries (from bsd.gnome.mk). This ports.conf should probably maintained somewhere in the ports/ tree instead. It should be included as well, and _COMMON_ options should be listed in defaults/ports.conf (e.g. WITHOUT_X11 or WITH_GNOME). src/defaults/make.conf shouldn't be spammed with ports stuff. A attached the diff and the new file. Comments? Alex --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="make.conf.diff" Index: make.conf =================================================================== RCS file: /home/ncvs/src/etc/defaults/make.conf,v retrieving revision 1.172 diff -u -r1.172 make.conf --- make.conf 2001/08/16 06:05:17 1.172 +++ make.conf 2001/08/23 19:05:06 @@ -156,12 +156,6 @@ #COMPAT4X= yes # # -# If you do not want additional documentation (some of which are -# a few hundred KB's) for ports to be installed: -# -#NOPORTDOCS= true -# -# # Default format for system documentation, depends on your printer. # Set this to "ascii" for simple printers or screen # @@ -199,115 +193,6 @@ # #LOADER_TFTP_SUPPORT= YES # -# By default, the ports collection attempts to use XFree86 3.3.X. If -# you are running XFree86 4.X, uncomment this line. -# -#XFREE86_VERSION= 4 -# -# By default, this points to /usr/X11R6 for XFree86 releases 3.0 or earlier. -# If you have a XFree86 from before 3.0 that has the X distribution in -# /usr/X386, you want to uncomment this. -# -#X11BASE= /usr/X386 -# -# -# If you have Motif on your system, uncomment this. -# -#HAVE_MOTIF= yes -#MOTIF_STATIC= yes -# -# If the default location of the Motif library (specified below) is NOT -# appropriate for you, uncomment this and change it to the correct value. -# If your motif is in ${X11BASE}/lib, you don't need to touch this line. -# -#MOTIFLIB= -L${X11BASE}/lib -lXm -# -# -# If you're resident in the USA, this will help various ports to determine -# whether or not they should attempt to comply with the various U.S. -# export regulations on certain types of software which do not apply to -# anyone else in the world. -# -#USA_RESIDENT= YES -# -# -# Override "don't install a port that's already installed" behavior. -# One might wish to do this for ports debugging or to unconditionally -# reinstall a set of suspect/broken ports. -# -#FORCE_PKG_REGISTER= YES -# -# -# If you're behind a firewall and need FTP or HTTP proxy services for -# ports collection fetching to work, the following examples give the -# necessary syntax. See the fetch(3) man page for details. -# -#FTP_PROXY= 10.0.0.1:21 -#HTTP_PROXY= 10.0.0.1:80 -# -# -# Port master sites. -# -# If you want your port fetches to go somewhere else than the default -# (specified below) in case the distfile/patchfile was not found, -# uncomment this and change it to a location nearest you. (Don't -# remove the "/${DIST_SUBDIR}/" part.) -# -#MASTER_SITE_BACKUP?= \ -# ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/${DIST_SUBDIR}/ -# -# If you want your port fetches to check the above site first (before -# the MASTER_SITES specified in the port Makefiles), uncomment the -# line below. You can also change the right side to point to wherever -# you want. -# -#MASTER_SITE_OVERRIDE?= ${MASTER_SITE_BACKUP} -# -# Some ports use a special variable to point to a collection of -# mirrors of well-known software archives. If you have a mirror close -# to you, uncomment any of the following lines and change it to that -# address. (Don't remove the "/%SUBDIR%/" part.) -# -# Note: the right hand sides of the following lines are only for your -# information. For a full list of default sites, take a look at -# bsd.sites.mk. -# -#MASTER_SITE_AFTERSTEP= ftp://ftp.afterstep.org/%SUBDIR%/ -#MASTER_SITE_COMP_SOURCES= ftp://gatekeeper.dec.com/pub/usenet/comp.sources.%SUBDIR%/ -#MASTER_SITE_FREEBSD_ORG= ftp://ftp.FreeBSD.org/pub/FreeBSD/%SUBDIR%/ -#MASTER_SITE_GNOME= ftp://ftp.gnome.org/pub/GNOME/sources/%SUBDIR%/ -#MASTER_SITE_GNU= ftp://ftp.gnu.org/gnu/%SUBDIR%/ -#MASTER_SITE_KDE= ftp://ftp.kde.org/pub/kde/%SUBDIR%/ -#MASTER_SITE_LOCAL= ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/%SUBDIR%/ -#MASTER_SITE_MOZILLA= ftp://ftp.mozilla.org/pub/%SUBDIR%/ -#MASTER_SITE_NETBSD= ftp://ftp.netbsd.org/pub/NetBSD/packages/distfiles/%SUBDIR%/ -#MASTER_SITE_PERL_CPAN= ftp://ftp.digital.com/pub/plan/perl/CPAN/modules/by-module/%SUBDIR%/ -#MASTER_SITE_PORTS_JP= ftp://ports.jp.FreeBSD.org/pub/FreeBSD-jp/ports-jp/LOCAL_PORTS/%SUBDIR%/ -#MASTER_SITE_RINGSERVER= ftp://ftp.dnsbalance.ring.gr.jp/pub/%SUBDIR%/ -#MASTER_SITE_RUBY= ftp://ftp.ruby-lang.org/pub/ruby/%SUBDIR%/ -#MASTER_SITE_SOURCEFORGE= ftp://ftp2.sourceforge.net/pub/sourceforge/%SUBDIR%/ -#MASTER_SITE_SOURCEWARE= ftp://ftp.freesoftware.com/pub/sourceware/%SUBDIR%/ -#MASTER_SITE_SUNSITE= ftp://metalab.unc.edu/pub/Linux/%SUBDIR%/ -#MASTER_SITE_TCLTK= ftp://ftp.scriptics.com/pub/tcl/%SUBDIR%/ -#MASTER_SITE_TEX_CTAN= ftp://ftp.tex.ac.uk/tex-archive/%SUBDIR%/ -#MASTER_SITE_THEMES= ftp://ftp.themes.org/pub/themes/%SUBDIR%/ -#MASTER_SITE_WINDOWMAKER= ftp://ftp.windowmaker.org/pub/%SUBDIR%/ -#MASTER_SITE_XCONTRIB= ftp://ftp.x.org/contrib/%SUBDIR%/ -#MASTER_SITE_XEMACS= ftp://ftp.xemacs.org/pub/xemacs/%SUBDIR%/ -#MASTER_SITE_XFREE= ftp://ftp.xfree86.org/pub/XFree86/%SUBDIR%/source/ -# -# Also it is highly recommended that you configure MASTER_SORT_REGEX -# to choose better mirror sites for you. List awk(1)-style regular -# expressions separated by space so MASTER_SITES will be sorted in -# that order. The following example is for Japanese users; change -# "jp" part to your ccTLD ("de", "ru", "uk", etc.) or the domain names -# of your nearest/upstream networks to meet your needs. -# -#MASTER_SORT_REGEX?= ^file: ^ftp://ftp\.FreeBSD\.org/pub/FreeBSD/ports/local-distfiles/ ://[^/]*\.jp/ ://[^/]*\.jp\. -# -# Ports can place their working directories somewhere other than under -# /usr/ports. -#WRKDIRPREFIX= /var/tmp # # Kerberos IV # If you want KerberosIV (KTH eBones), define this: --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ports.conf" # $FreeBSD$ # # NOTE: Please would any committer updating this file also update the # ports(7) manual page, if necessary, which is located in # src/share/man/man5/make.conf.5. # # This file, if present, will be read by make (see /usr/share/mk/sys.mk). # It allows you to override macro definitions to make without changing # your source tree, or anything the source tree installs. # # This file must be in valid Makefile syntax. # # # If you do not want additional documentation (some of which are # a few hundred KB's) for ports to be installed: # #NOPORTDOCS= true # # # If you have Motif on your system, uncomment this. # #HAVE_MOTIF= yes #MOTIF_STATIC= yes # # If the default location of the Motif library (specified below) is NOT # appropriate for you, uncomment this and change it to the correct value. # If your motif is in ${X11BASE}/lib, you don't need to touch this line. # #MOTIFLIB= -L${X11BASE}/lib -lXm # # # If you're resident in the USA, this will help various ports to determine # whether or not they should attempt to comply with the various U.S. # export regulations on certain types of software which do not apply to # anyone else in the world. # #USA_RESIDENT= YES # # # Override "don't install a port that's already installed" behavior. # One might wish to do this for ports debugging or to unconditionally # reinstall a set of suspect/broken ports. # #FORCE_PKG_REGISTER= YES # # # If you're behind a firewall and need FTP or HTTP proxy services for # ports collection fetching to work, the following examples give the # necessary syntax. See the fetch(3) man page for details. # #FTP_PROXY= 10.0.0.1:21 #HTTP_PROXY= 10.0.0.1:80 # # # Port master sites. # # If you want your port fetches to go somewhere else than the default # (specified below) in case the distfile/patchfile was not found, # uncomment this and change it to a location nearest you. (Don't # remove the "/${DIST_SUBDIR}/" part.) # #MASTER_SITE_BACKUP?= \ # ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/${DIST_SUBDIR}/ # # If you want your port fetches to check the above site first (before # the MASTER_SITES specified in the port Makefiles), uncomment the # line below. You can also change the right side to point to wherever # you want. # #MASTER_SITE_OVERRIDE?= ${MASTER_SITE_BACKUP} # # Some ports use a special variable to point to a collection of # mirrors of well-known software archives. If you have a mirror close # to you, uncomment any of the following lines and change it to that # address. (Don't remove the "/%SUBDIR%/" part.) # # Note: the right hand sides of the following lines are only for your # information. For a full list of default sites, take a look at # bsd.sites.mk. # #MASTER_SITE_AFTERSTEP= ftp://ftp.afterstep.org/%SUBDIR%/ #MASTER_SITE_COMP_SOURCES= ftp://gatekeeper.dec.com/pub/usenet/comp.sources.%SUBDIR%/ #MASTER_SITE_FREEBSD_ORG= ftp://ftp.FreeBSD.org/pub/FreeBSD/%SUBDIR%/ #MASTER_SITE_GNOME= ftp://ftp.gnome.org/pub/GNOME/sources/%SUBDIR%/ #MASTER_SITE_GNU= ftp://ftp.gnu.org/gnu/%SUBDIR%/ #MASTER_SITE_KDE= ftp://ftp.kde.org/pub/kde/%SUBDIR%/ #MASTER_SITE_LOCAL= ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/%SUBDIR%/ #MASTER_SITE_MOZILLA= ftp://ftp.mozilla.org/pub/%SUBDIR%/ #MASTER_SITE_NETBSD= ftp://ftp.netbsd.org/pub/NetBSD/packages/distfiles/%SUBDIR%/ #MASTER_SITE_PERL_CPAN= ftp://ftp.digital.com/pub/plan/perl/CPAN/modules/by-module/%SUBDIR%/ #MASTER_SITE_PORTS_JP= ftp://ports.jp.FreeBSD.org/pub/FreeBSD-jp/ports-jp/LOCAL_PORTS/%SUBDIR%/ #MASTER_SITE_RINGSERVER= ftp://ftp.dnsbalance.ring.gr.jp/pub/%SUBDIR%/ #MASTER_SITE_RUBY= ftp://ftp.ruby-lang.org/pub/ruby/%SUBDIR%/ #MASTER_SITE_SOURCEFORGE= ftp://ftp2.sourceforge.net/pub/sourceforge/%SUBDIR%/ #MASTER_SITE_SOURCEWARE= ftp://ftp.freesoftware.com/pub/sourceware/%SUBDIR%/ #MASTER_SITE_SUNSITE= ftp://metalab.unc.edu/pub/Linux/%SUBDIR%/ #MASTER_SITE_TCLTK= ftp://ftp.scriptics.com/pub/tcl/%SUBDIR%/ #MASTER_SITE_TEX_CTAN= ftp://ftp.tex.ac.uk/tex-archive/%SUBDIR%/ #MASTER_SITE_THEMES= ftp://ftp.themes.org/pub/themes/%SUBDIR%/ #MASTER_SITE_WINDOWMAKER= ftp://ftp.windowmaker.org/pub/%SUBDIR%/ #MASTER_SITE_XCONTRIB= ftp://ftp.x.org/contrib/%SUBDIR%/ #MASTER_SITE_XEMACS= ftp://ftp.xemacs.org/pub/xemacs/%SUBDIR%/ #MASTER_SITE_XFREE= ftp://ftp.xfree86.org/pub/XFree86/%SUBDIR%/source/ # # Also it is highly recommended that you configure MASTER_SORT_REGEX # to choose better mirror sites for you. List awk(1)-style regular # expressions separated by space so MASTER_SITES will be sorted in # that order. The following example is for Japanese users; change # "jp" part to your ccTLD ("de", "ru", "uk", etc.) or the domain names # of your nearest/upstream networks to meet your needs. # #MASTER_SORT_REGEX?= ^file: ^ftp://ftp\.FreeBSD\.org/pub/FreeBSD/ports/local-distfiles/ ://[^/]*\.jp/ ://[^/]*\.jp\. # # Ports can place their working directories somewhere other than under # /usr/ports. #WRKDIRPREFIX= /var/tmp # # # The following defines apply to all possible knobs (at least if the # ports' maintainer implemented this). These overwrite all other # settings. # # WITH_ALL=yes: # - Always use options # WITHOUT_ALL=yes: # - Never use options # # # The following defines are for the X Window System: # # WITH_X11: # - Always use X11 # WITHOUT_X11: # - Never use X11 # # By default, the ports collection attempts to use XFree86 3.3.X. If # you are running XFree86 4.X, uncomment this line. #XFREE86_VERSION= 4 # # By default, this points to /usr/X11R6 for XFree86 releases 3.0 or earlier. # If you have a XFree86 from before 3.0 that has the X distribution in # /usr/X386, you want to uncomment this. # #X11BASE= /usr/X386 # # The following defines are for the various levels of libraries in the # GLib/GTK+/GNOME group of software. There are the following options: # # WITH_GLIB, WITH_GTK, WITH_ESOUND, WITH_IMLIB, WITH_GNOME: # - Always use GLib/GTK+ 1.2.x, Esound, Imlib or GNOME respectively. # WITHOUT_GLIB, WITHOUT_GTK, WITHOUT_ESOUND, WITHOUT_IMLIB, WITHOUT_GNOME: # - Never use GLib/GTK+ 1.2.x, Esound, Imlib or GNOME respectively. # --17pEHd4RhPHOinZp-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 23 12:48: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by hub.freebsd.org (Postfix) with ESMTP id D1BD237B40D; Thu, 23 Aug 2001 12:47:43 -0700 (PDT) (envelope-from parv@worldnet.att.net) Received: from worldnet.att.net ([32.100.199.138]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010823194742.YRMC1680.mtiwmhc21.worldnet.att.net@worldnet.att.net>; Thu, 23 Aug 2001 19:47:42 +0000 Received: by worldnet.att.net (Postfix, from userid 1001) id 6157950F9F; Thu, 23 Aug 2001 15:47:41 -0400 (EDT) Date: Thu, 23 Aug 2001 15:47:41 -0400 From: parv To: Alexander Langer Cc: arch@FreeBSD.org, ports@FreeBSD.org Subject: Re: ports.conf Message-ID: <20010823154740.A53980@moo.holy.cow> References: <20010823210729.A95484@zerogravity.kawo2.rwth-aachen.d> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010823210729.A95484@zerogravity.kawo2.rwth-aachen.d>; from alex@big.endian.de on Thu, Aug 23, 2001 at 09:07:29PM +0200 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 was, on the fateful occasion around Aug 23 15:07 -0400, sent by Alexander Langer > > Hi folks! > > Inspired by a comment from JHB on IRC, I removed all ports relevant > entries from /etc/defaults/make.conf and put them > into a new ports.conf, along with some new entries (from bsd.gnome.mk). ... signs of progress... i like this change. > src/defaults/make.conf shouldn't be spammed with ports stuff. amen to that! > A attached the diff and the new file. ... i haven't tried the diff yet. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 23 13:18:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-54.dsl.lsan03.pacbell.net [63.207.60.54]) by hub.freebsd.org (Postfix) with ESMTP id E6ED237B406; Thu, 23 Aug 2001 13:18:47 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A352F66E43; Thu, 23 Aug 2001 13:18:46 -0700 (PDT) Date: Thu, 23 Aug 2001 13:18:46 -0700 From: Kris Kennaway To: Alexander Langer Cc: arch@FreeBSD.org, ports@FreeBSD.org Subject: Re: ports.conf Message-ID: <20010823131846.C99242@xor.obsecurity.org> References: <20010823210729.A95484@zerogravity.kawo2.rwth-aachen.d> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Sr1nOIr3CvdE5hEN" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010823210729.A95484@zerogravity.kawo2.rwth-aachen.d>; from alex@big.endian.de on Thu, Aug 23, 2001 at 09:07:29PM +0200 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 --Sr1nOIr3CvdE5hEN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Aug 23, 2001 at 09:07:29PM +0200, Alexander Langer wrote: > -# If you're behind a firewall and need FTP or HTTP proxy services for > -# ports collection fetching to work, the following examples give the > -# necessary syntax. See the fetch(3) man page for details. > -# > -#FTP_PROXY= 10.0.0.1:21 > -#HTTP_PROXY= 10.0.0.1:80 These are used by other things than ports. Other than that it sounds fine.. I made a similar change myself locally, but for some reason never submitted it for comment. You'll need to modify as well, of course. Kris --Sr1nOIr3CvdE5hEN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7hWUmWry0BWjoQKURAgPXAKDoowIavHtiv5EAA+h7HhPNHZ1s8ACgvyj0 uiD/LEbDJyCbdgJEnLSyNqc= =wbLQ -----END PGP SIGNATURE----- --Sr1nOIr3CvdE5hEN-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 23 14: 0: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (dsl092-013-169.sfo1.dsl.speakeasy.net [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id B6E6637B401; Thu, 23 Aug 2001 13:59:54 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.5/8.11.1) id f7NKxfT17592; Thu, 23 Aug 2001 13:59:41 -0700 (PDT) (envelope-from obrien) Date: Thu, 23 Aug 2001 13:59:41 -0700 From: "David O'Brien" To: Alexander Langer Cc: arch@FreeBSD.org, ports@FreeBSD.org Subject: Re: ports.conf Message-ID: <20010823135941.B4003@dragon.nuxi.com> Reply-To: arch@FreeBSD.org, ports@FreeBSD.org Mail-Followup-To: arch@FreeBSD.org, ports@FreeBSD.org References: <20010823210729.A95484@zerogravity.kawo2.rwth-aachen.d> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010823210729.A95484@zerogravity.kawo2.rwth-aachen.d>; from alex@big.endian.de on Thu, Aug 23, 2001 at 09:07:29PM +0200 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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, Aug 23, 2001 at 09:07:29PM +0200, Alexander Langer wrote: > This ports.conf should probably maintained somewhere in the ports/ tree > instead. I disagree. I use a common NFS mounted /usr/ports to build stuff, but each machine is different. On some I have the commercial Motif, on others I want NOPORTSDOC=true to save space. -- -- David (obrien@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 Aug 23 14: 6:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from foo.osd.bsdi.com (foo.lab.nuxi.com [66.123.5.77]) by hub.freebsd.org (Postfix) with ESMTP id C9E0337B409; Thu, 23 Aug 2001 14:06:05 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.4/8.11.4) id f7NL5uo01754; Thu, 23 Aug 2001 14:05:56 -0700 (PDT) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010823210729.A95484@zerogravity.kawo2.rwth-aachen.d> Date: Thu, 23 Aug 2001 14:05:55 -0700 (PDT) From: John Baldwin To: Alexander Langer Subject: RE: ports.conf Cc: ports@FreeBSD.org, 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 On 23-Aug-01 Alexander Langer wrote: > Hi folks! > > Inspired by a comment from JHB on IRC, I removed all ports relevant > entries from /etc/defaults/make.conf and put them > into a new ports.conf, along with some new entries (from bsd.gnome.mk). > > This ports.conf should probably maintained somewhere in the ports/ tree > instead. It should be included as well, and _COMMON_ options should > be listed in defaults/ports.conf (e.g. WITHOUT_X11 or WITH_GNOME). > > src/defaults/make.conf shouldn't be spammed with ports stuff. > > A attached the diff and the new file. > > Comments? Just follow the /etc/defaults way of doing things when you modify bsd.port.mk, i.e.: allow /etc/ports.conf to override /etc/defaults/ports.conf. Thanks. > Alex -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 23 14:19:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id 8940F37B405 for ; Thu, 23 Aug 2001 14:19:30 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 5898 invoked by uid 1000); 23 Aug 2001 21:17:37 -0000 Date: Fri, 24 Aug 2001 00:17:37 +0300 From: Peter Pentchev To: arch@FreeBSD.org, ports@FreeBSD.org Cc: Alexander Langer Subject: Re: ports.conf Message-ID: <20010824001737.B1714@ringworld.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org, ports@FreeBSD.org, Alexander Langer References: <20010823210729.A95484@zerogravity.kawo2.rwth-aachen.d> <20010823135941.B4003@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010823135941.B4003@dragon.nuxi.com>; from dev-null@NUXI.com on Thu, Aug 23, 2001 at 01:59:41PM -0700 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, Aug 23, 2001 at 01:59:41PM -0700, David O'Brien wrote: > On Thu, Aug 23, 2001 at 09:07:29PM +0200, Alexander Langer wrote: > > This ports.conf should probably maintained somewhere in the ports/ tree > > instead. > > I disagree. I use a common NFS mounted /usr/ports to build stuff, but > each machine is different. On some I have the commercial Motif, on > others I want NOPORTSDOC=true to save space. I do believe this does not conflict with what Alex wrote. I think he meant 'maintained in the ports/ tree' just as make.conf is 'maintained in the src/ tree', that is, there is a src/etc/make.conf file with evolving defaults. Yes, ports.conf should probably live in /etc or some such place, but I, too, think that it should be maintained in the ports tree, quite possibly in ports/Mk/. G'luck, Peter -- This would easier understand fewer had omitted. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 23 14:21:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 5949E37B40A; Thu, 23 Aug 2001 14:21:34 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: by bazooka.unixfreak.org (Postfix, from userid 1000) id AB3F83E31; Thu, 23 Aug 2001 14:21:23 -0700 (PDT) Received: from bazooka.unixfreak.org (localhost [127.0.0.1]) by bazooka.unixfreak.org (Postfix) with ESMTP id A22E43C12B; Thu, 23 Aug 2001 14:21:23 -0700 (PDT) To: freebsd-gnats-submit@FreeBSD.org Cc: arch@FreeBSD.org Subject: Re: kern/29931: problems with kern.corefile handling In-Reply-To: <20010822123301.D8694@ringworld.oblivion.bg>; from roam@ringlet.net on "Wed, 22 Aug 2001 12:33:01 +0300" Date: Thu, 23 Aug 2001 14:21:18 -0700 From: Dima Dorfman Message-Id: <20010823212123.AB3F83E31@bazooka.unixfreak.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 Peter Pentchev writes: > This looks genuine. Any objections to committing it, and MFC'ing before > 4.4 comes out? I don't see any reason to rush the MFC. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 23 14:31:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id 50B3E37B40A for ; Thu, 23 Aug 2001 14:31:17 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 6193 invoked by uid 1000); 23 Aug 2001 21:29:24 -0000 Date: Fri, 24 Aug 2001 00:29:24 +0300 From: Peter Pentchev To: Dima Dorfman Cc: freebsd-gnats-submit@FreeBSD.org, arch@FreeBSD.org Subject: Re: kern/29931: problems with kern.corefile handling Message-ID: <20010824002924.C1714@ringworld.oblivion.bg> Mail-Followup-To: Dima Dorfman , freebsd-gnats-submit@FreeBSD.org, arch@FreeBSD.org References: <20010822123301.D8694@ringworld.oblivion.bg> <20010823212123.AB3F83E31@bazooka.unixfreak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010823212123.AB3F83E31@bazooka.unixfreak.org>; from dima@unixfreak.org on Thu, Aug 23, 2001 at 02:21:18PM -0700 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, Aug 23, 2001 at 02:21:18PM -0700, Dima Dorfman wrote: > Peter Pentchev writes: > > This looks genuine. Any objections to committing it, and MFC'ing before > > 4.4 comes out? > > I don't see any reason to rush the MFC. Mmmm.. preventing foot-shooting? A panicked kernel is a bit too harsh a punishment for a misconfigured kern.corefile, IMHO.. Granted, this level of misconfiguration is not easy to attain ;) But it could always happen as a result of a cut-and-paste-o and corefiles kept in a central directory or something.. G'luck, Peter -- I am jealous of the first word in this sentence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 23 14:32:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from foo.osd.bsdi.com (foo.lab.nuxi.com [66.123.5.77]) by hub.freebsd.org (Postfix) with ESMTP id 0037C37B407; Thu, 23 Aug 2001 14:32:47 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.4/8.11.4) id f7NLWaa02088; Thu, 23 Aug 2001 14:32:36 -0700 (PDT) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010824001737.B1714@ringworld.oblivion.bg> Date: Thu, 23 Aug 2001 14:32:35 -0700 (PDT) From: John Baldwin To: Peter Pentchev Subject: Re: ports.conf Cc: Alexander Langer , ports@FreeBSD.org, 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 On 23-Aug-01 Peter Pentchev wrote: > On Thu, Aug 23, 2001 at 01:59:41PM -0700, David O'Brien wrote: >> On Thu, Aug 23, 2001 at 09:07:29PM +0200, Alexander Langer wrote: >> > This ports.conf should probably maintained somewhere in the ports/ tree >> > instead. >> >> I disagree. I use a common NFS mounted /usr/ports to build stuff, but >> each machine is different. On some I have the commercial Motif, on >> others I want NOPORTSDOC=true to save space. > > I do believe this does not conflict with what Alex wrote. > I think he meant 'maintained in the ports/ tree' just as make.conf > is 'maintained in the src/ tree', that is, there is a src/etc/make.conf > file with evolving defaults. Yes, ports.conf should probably live > in /etc or some such place, but I, too, think that it should be > maintained in the ports tree, quite possibly in ports/Mk/. Erm, how does it get installed then? :) I think what you want is this perhaps: /usr/ports/Mk/ports.conf /etc/ports.conf instead of /etc/defaults/ports.conf /etc/ports.conf -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 23 14:37:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id 54FF237B40A for ; Thu, 23 Aug 2001 14:37:39 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 6382 invoked by uid 1000); 23 Aug 2001 21:36:06 -0000 Date: Fri, 24 Aug 2001 00:36:06 +0300 From: Peter Pentchev To: John Baldwin Cc: Alexander Langer , ports@FreeBSD.org, arch@FreeBSD.org Subject: Re: ports.conf Message-ID: <20010824003606.D1714@ringworld.oblivion.bg> Mail-Followup-To: John Baldwin , Alexander Langer , ports@FreeBSD.org, arch@FreeBSD.org References: <20010824001737.B1714@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Thu, Aug 23, 2001 at 02:32:35PM -0700 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, Aug 23, 2001 at 02:32:35PM -0700, John Baldwin wrote: > > On 23-Aug-01 Peter Pentchev wrote: > > On Thu, Aug 23, 2001 at 01:59:41PM -0700, David O'Brien wrote: > >> On Thu, Aug 23, 2001 at 09:07:29PM +0200, Alexander Langer wrote: > >> > This ports.conf should probably maintained somewhere in the ports/ tree > >> > instead. > >> > >> I disagree. I use a common NFS mounted /usr/ports to build stuff, but > >> each machine is different. On some I have the commercial Motif, on > >> others I want NOPORTSDOC=true to save space. > > > > I do believe this does not conflict with what Alex wrote. > > I think he meant 'maintained in the ports/ tree' just as make.conf > > is 'maintained in the src/ tree', that is, there is a src/etc/make.conf > > file with evolving defaults. Yes, ports.conf should probably live > > in /etc or some such place, but I, too, think that it should be > > maintained in the ports tree, quite possibly in ports/Mk/. > > Erm, how does it get installed then? :) I think what you want is this perhaps: > > /usr/ports/Mk/ports.conf > /etc/ports.conf > > instead of > > /etc/defaults/ports.conf > /etc/ports.conf Yeah, I wondered about installation myself, just after I fired off the previous message :) Yes, /usr/ports/Mk/ports.conf overridable by /etc/ports.conf sounds like just the thing! G'luck, Peter -- I am the thought you are now thinking. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 23 14:39: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (dsl092-013-169.sfo1.dsl.speakeasy.net [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 5683237B407; Thu, 23 Aug 2001 14:38:51 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.5/8.11.1) id f7NLcip18249; Thu, 23 Aug 2001 14:38:44 -0700 (PDT) (envelope-from obrien) Date: Thu, 23 Aug 2001 14:38:44 -0700 From: "David O'Brien" To: Peter Pentchev Cc: arch@FreeBSD.org, ports@FreeBSD.org, Alexander Langer Subject: Re: ports.conf Message-ID: <20010823143844.A18197@dragon.nuxi.com> Reply-To: Cc:arch@FreeBSD.org, ports@FreeBSD.org Mail-Followup-To: Peter Pentchev , arch@FreeBSD.org, ports@FreeBSD.org, Alexander Langer References: <20010823210729.A95484@zerogravity.kawo2.rwth-aachen.d> <20010823135941.B4003@dragon.nuxi.com> <20010824001737.B1714@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010824001737.B1714@ringworld.oblivion.bg>; from roam@ringlet.net on Fri, Aug 24, 2001 at 12:17:37AM +0300 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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, Aug 24, 2001 at 12:17:37AM +0300, Peter Pentchev wrote: > I think he meant 'maintained in the ports/ tree' just as make.conf > is 'maintained in the src/ tree', that is, there is a src/etc/make.conf > file with evolving defaults. Yes, ports.conf should probably live > in /etc or some such place, but I, too, think that it should be > maintained in the ports tree, quite possibly in ports/Mk/. How are you suggesting ports.conf get into /etc? A `make world' cannot depend on having a populated /usr/ports/Mk. -- -- David (obrien@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 Aug 23 14:46:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id C6C9337B40B; Thu, 23 Aug 2001 14:46:13 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: by bazooka.unixfreak.org (Postfix, from userid 1000) id 068E93E31; Thu, 23 Aug 2001 14:46:08 -0700 (PDT) Received: from bazooka.unixfreak.org (localhost [127.0.0.1]) by bazooka.unixfreak.org (Postfix) with ESMTP id EE45E3C12D; Thu, 23 Aug 2001 14:46:08 -0700 (PDT) To: Peter Pentchev Cc: freebsd-gnats-submit@FreeBSD.org, arch@FreeBSD.org Subject: Re: kern/29931: problems with kern.corefile handling In-Reply-To: <20010824002924.C1714@ringworld.oblivion.bg>; from roam@ringlet.net on "Fri, 24 Aug 2001 00:29:24 +0300" Date: Thu, 23 Aug 2001 14:46:03 -0700 From: Dima Dorfman Message-Id: <20010823214608.068E93E31@bazooka.unixfreak.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 Peter Pentchev writes: > On Thu, Aug 23, 2001 at 02:21:18PM -0700, Dima Dorfman wrote: > > Peter Pentchev writes: > > > This looks genuine. Any objections to committing it, and MFC'ing before > > > 4.4 comes out? > > > > I don't see any reason to rush the MFC. > > Mmmm.. preventing foot-shooting? A panicked kernel is a bit too harsh > a punishment for a misconfigured kern.corefile, IMHO.. > Granted, this level of misconfiguration is not easy to attain ;) > But it could always happen as a result of a cut-and-paste-o and > corefiles kept in a central directory or something.. I didn't say it shouldn't be MFC'd at all, just that I think it shouldn't be MFC'd this late into a code freeze since it's hardly critical. Anyway, that's for jkh and murray to decide. There's nothing wrong with the patch that I can see. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 23 16:34:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 121B537B40A; Thu, 23 Aug 2001 16:34:42 -0700 (PDT) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id RAA04349; Thu, 23 Aug 2001 17:34:40 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id RAA20136; Thu, 23 Aug 2001 17:34:40 -0600 (MDT) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15237.37648.38907.681657@nomad.yogotech.com> Date: Thu, 23 Aug 2001 17:34:40 -0600 To: Alexander Langer Cc: arch@FreeBSD.ORG, ports@FreeBSD.ORG Subject: Re: ports.conf In-Reply-To: <20010823210729.A95484@zerogravity.kawo2.rwth-aachen.d> References: <20010823210729.A95484@zerogravity.kawo2.rwth-aachen.d> X-Mailer: VM 6.95 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 > Inspired by a comment from JHB on IRC, I removed all ports relevant > entries from /etc/defaults/make.conf and put them > into a new ports.conf, along with some new entries (from bsd.gnome.mk). Whoo hoo. This is a much needed change, since the ports tree should be un-coupled from the rest of the tree, IMO. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 23 16:36:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id BD16937B40A; Thu, 23 Aug 2001 16:36:43 -0700 (PDT) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id RAA04432; Thu, 23 Aug 2001 17:36:40 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id RAA20151; Thu, 23 Aug 2001 17:36:39 -0600 (MDT) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15237.37767.274325.945753@nomad.yogotech.com> Date: Thu, 23 Aug 2001 17:36:39 -0600 To: arch@FreeBSD.ORG, ports@FreeBSD.ORG Cc: Alexander Langer Subject: Re: ports.conf In-Reply-To: <20010823135941.B4003@dragon.nuxi.com> References: <20010823210729.A95484@zerogravity.kawo2.rwth-aachen.d> <20010823135941.B4003@dragon.nuxi.com> X-Mailer: VM 6.95 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 ports.conf should probably maintained somewhere in the ports/ tree > > instead. > > I disagree. I use a common NFS mounted /usr/ports to build stuff, but > each machine is different. On some I have the commercial Motif, on > others I want NOPORTSDOC=true to save space. I think this is very much an exception to the general purpose. /usr/ports should be uncoupled more from /usr/src, and /etc/make.conf is really a part of the building /usr/src, so as such should not contain configuration from /usr/ports. Would something like /etc/ports.conf be acceptable? That way it can be modified separately from the configuration for the main /usr/src tree, yet still allow 'local' modifications. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 23 16:38:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from kawoserv.kawo2.rwth-aachen.de (kawoserv.kawo2.RWTH-Aachen.DE [134.130.180.1]) by hub.freebsd.org (Postfix) with ESMTP id 6C88237B406; Thu, 23 Aug 2001 16:38:12 -0700 (PDT) (envelope-from alex@big.endian.de) Received: from zerogravity.kawo2.rwth-aachen.de (zerogravity.kawo2.rwth-aachen.de [134.130.181.28]) by kawoserv.kawo2.rwth-aachen.de (8.9.3/8.9.3) with ESMTP id BAA02662; Fri, 24 Aug 2001 01:38:11 +0200 Received: by zerogravity.kawo2.rwth-aachen.de (Postfix, from userid 1001) id 0726C14B26; Fri, 24 Aug 2001 01:38:13 +0200 (CEST) Date: Fri, 24 Aug 2001 01:38:13 +0200 From: Alexander Langer To: John Baldwin Cc: Peter Pentchev , ports@FreeBSD.org, arch@FreeBSD.org Subject: Re: ports.conf Message-ID: <20010824013813.A14741@zerogravity.kawo2.rwth-aachen.d> Mail-Followup-To: Alexander Langer , John Baldwin , Peter Pentchev , ports@FreeBSD.org, arch@FreeBSD.org References: <20010824001737.B1714@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Thu, Aug 23, 2001 at 02:32:35PM -0700 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. 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 Thus spake John Baldwin (jhb@FreeBSD.org): > Erm, how does it get installed then? :) I think what you want is this perhaps: > /usr/ports/Mk/ports.conf > /etc/ports.conf Yes, that is similar to what I had in mind. Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 23 16:38:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id A415A37B405; Thu, 23 Aug 2001 16:38:44 -0700 (PDT) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id RAA04519; Thu, 23 Aug 2001 17:38:33 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id RAA20164; Thu, 23 Aug 2001 17:38:33 -0600 (MDT) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15237.37880.802441.215728@nomad.yogotech.com> Date: Thu, 23 Aug 2001 17:38:32 -0600 To: Cc:arch@FreeBSD.ORG, ports@FreeBSD.ORG Cc: Peter Pentchev , arch@FreeBSD.ORG, Alexander Langer Subject: Re: ports.conf In-Reply-To: <20010823143844.A18197@dragon.nuxi.com> References: <20010823210729.A95484@zerogravity.kawo2.rwth-aachen.d> <20010823135941.B4003@dragon.nuxi.com> <20010824001737.B1714@ringworld.oblivion.bg> <20010823143844.A18197@dragon.nuxi.com> X-Mailer: VM 6.95 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 > > I think he meant 'maintained in the ports/ tree' just as make.conf > > is 'maintained in the src/ tree', that is, there is a src/etc/make.conf > > file with evolving defaults. Yes, ports.conf should probably live > > in /etc or some such place, but I, too, think that it should be > > maintained in the ports tree, quite possibly in ports/Mk/. > > How are you suggesting ports.conf get into /etc? A `make world' cannot > depend on having a populated /usr/ports/Mk. 'make world' doesn't/shouldn't use anything in /usr/ports/Mk, since make world only builds sources in /usr/src. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 23 19:26:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (dsl092-013-169.sfo1.dsl.speakeasy.net [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 36E9537B40B; Thu, 23 Aug 2001 19:26:06 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.5/8.11.1) id f7O2Pww06340; Thu, 23 Aug 2001 19:25:58 -0700 (PDT) (envelope-from obrien) Date: Thu, 23 Aug 2001 19:25:58 -0700 From: "David O'Brien" To: Nate Williams Cc: arch@FreeBSD.ORG, ports@FreeBSD.ORG, Alexander Langer Subject: Re: ports.conf Message-ID: <20010823192558.A6265@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010823210729.A95484@zerogravity.kawo2.rwth-aachen.d> <20010823135941.B4003@dragon.nuxi.com> <15237.37767.274325.945753@nomad.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15237.37767.274325.945753@nomad.yogotech.com>; from nate@yogotech.com on Thu, Aug 23, 2001 at 05:36:39PM -0600 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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, Aug 23, 2001 at 05:36:39PM -0600, Nate Williams wrote: > and /etc/make.conf is > really a part of the building /usr/src, so as such should not contain > configuration from /usr/ports. No is not. Things in /etc/make.conf affect *EVERY* invocation of make. Don't even try to tell me otherwise unless you've supplied a patch that determines if you are w/in the logical equivalent of /usr/src to process the contents of /etc/make.conf. /etc is for the *machine*. If you want something just for /usr/src, then we should have a /usr/src/worldmake.conf > Would something like /etc/ports.conf be acceptable? That way it can be > modified separately from the configuration for the main /usr/src tree, Yes. Not because it separates things from knobs for /usr/src, but because it separates things logically. -- -- David (obrien@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 Aug 23 20:39:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from femail37.sdc1.sfba.home.com (femail37.sdc1.sfba.home.com [24.254.60.31]) by hub.freebsd.org (Postfix) with ESMTP id BD84C37B40B for ; Thu, 23 Aug 2001 20:39:49 -0700 (PDT) (envelope-from kyphur@kyphurland.com) Received: from ra ([24.181.2.55]) by femail37.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010824033949.TYVO29650.femail37.sdc1.sfba.home.com@ra> for ; Thu, 23 Aug 2001 20:39:49 -0700 Message-ID: <003101c12c4e$5c22f2b0$0401a8c0@ra> From: "kyphur" To: Subject: Question Date: Thu, 23 Aug 2001 23:39:20 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C12C2C.D4B8AB60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 is a multi-part message in MIME format. ------=_NextPart_000_002E_01C12C2C.D4B8AB60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm a computer arts student and I notice that when I go to look at = potential jobs that they look for Unix experienced employees. I know = that Free BSD is a Unix based system but what exactly are the = differences? =20 My question about the architecture is that I run a AMD 900Mhz and I see = that it's mainly for Intel archs. I know that you say it's a x86 = architecture and I know that the AMD also supports the x86 arch but have = you noticed any problems? Sorry about all the questions but I'm still learning and I'm really = interested in using Unix and/or FreeBSD. =20 I hope to hear back from you. Jason Powell ------=_NextPart_000_002E_01C12C2C.D4B8AB60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm a computer arts student and I = notice that when=20 I go to look at potential jobs that they look for Unix experienced=20 employees.  I know that Free BSD is a Unix based system but what = exactly=20 are the differences? 
 
My question about the architecture is = that I run a=20 AMD 900Mhz and I see that it's mainly for Intel archs.  I know that = you say=20 it's a x86 architecture and I know that the AMD also supports the x86 = arch but=20 have you noticed any problems?
 
Sorry about all the questions but I'm = still=20 learning and I'm really interested in using Unix and/or FreeBSD. =20
 
I hope to hear back from = you.
 
Jason Powell
------=_NextPart_000_002E_01C12C2C.D4B8AB60-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 23 21:37:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 5F7A937B406; Thu, 23 Aug 2001 21:37:36 -0700 (PDT) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id WAA16218; Thu, 23 Aug 2001 22:37:34 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id WAA21071; Thu, 23 Aug 2001 22:37:34 -0600 (MDT) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15237.55821.676471.752233@nomad.yogotech.com> Date: Thu, 23 Aug 2001 22:37:33 -0600 To: obrien@FreeBSD.ORG Cc: Nate Williams , arch@FreeBSD.ORG, ports@FreeBSD.ORG, Alexander Langer Subject: Re: ports.conf In-Reply-To: <20010823192558.A6265@dragon.nuxi.com> References: <20010823210729.A95484@zerogravity.kawo2.rwth-aachen.d> <20010823135941.B4003@dragon.nuxi.com> <15237.37767.274325.945753@nomad.yogotech.com> <20010823192558.A6265@dragon.nuxi.com> X-Mailer: VM 6.95 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 > > and /etc/make.conf is > > really a part of the building /usr/src, so as such should not contain > > configuration from /usr/ports. > > No is not. Things in /etc/make.conf affect *EVERY* invocation of make. > Don't even try to tell me otherwise unless you've supplied a patch that > determines if you are w/in the logical equivalent of /usr/src to process > the contents of /etc/make.conf. As Bruce would say, this is a bug, and I won't disagree with him. However, we have two different set of CFLAGS (one for kernel, and one for userland), which is just weird. Rather than untying the mess we have now, are you proposing we keep it and let /etc/make.conf grow everytime we add another port that needs tweaking? > /etc is for the *machine*. If you want something just for /usr/src, then > we should have a /usr/src/worldmake.conf Configuration files don't belong at the top of the src tree, IMO. > > Would something like /etc/ports.conf be acceptable? That way it can be > > modified separately from the configuration for the main /usr/src tree, > > Yes. Not because it separates things from knobs for /usr/src, but > because it separates things logically. Well, at least we agree on one thing. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 23 21:48: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (dsl092-013-169.sfo1.dsl.speakeasy.net [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id DAFE637B405; Thu, 23 Aug 2001 21:47:52 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.5/8.11.1) id f7O4lnb01697; Thu, 23 Aug 2001 21:47:49 -0700 (PDT) (envelope-from obrien) Date: Thu, 23 Aug 2001 21:47:49 -0700 From: "David O'Brien" To: Nate Williams Cc: arch@FreeBSD.ORG, ports@FreeBSD.ORG, Alexander Langer Subject: Re: ports.conf Message-ID: <20010823214749.A1674@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010823210729.A95484@zerogravity.kawo2.rwth-aachen.d> <20010823135941.B4003@dragon.nuxi.com> <15237.37767.274325.945753@nomad.yogotech.com> <20010823192558.A6265@dragon.nuxi.com> <15237.55821.676471.752233@nomad.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15237.55821.676471.752233@nomad.yogotech.com>; from nate@yogotech.com on Thu, Aug 23, 2001 at 10:37:33PM -0600 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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, Aug 23, 2001 at 10:37:33PM -0600, Nate Williams wrote: > As Bruce would say, this is a bug, and I won't disagree with him. > However, we have two different set of CFLAGS (one for kernel, and one > for userland), which is just weird. I would disagree. There should be a global make settings. There should also be one w/in /usr/src. > Rather than untying the mess we have now, are you proposing we keep it > and let /etc/make.conf grow everytime we add another port that needs > tweaking? Nope. I am just saying the src to ports.conf should probably live w/in /usr/src so it will get installed etc. -- -- David (obrien@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 Aug 23 21:50: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 16F2F37B40F; Thu, 23 Aug 2001 21:49:56 -0700 (PDT) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id WAA16723; Thu, 23 Aug 2001 22:49:54 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id WAA21191; Thu, 23 Aug 2001 22:49:53 -0600 (MDT) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15237.56561.741293.622635@nomad.yogotech.com> Date: Thu, 23 Aug 2001 22:49:53 -0600 To: obrien@FreeBSD.ORG Cc: Nate Williams , arch@FreeBSD.ORG, ports@FreeBSD.ORG, Alexander Langer Subject: Re: ports.conf In-Reply-To: <20010823214749.A1674@dragon.nuxi.com> References: <20010823210729.A95484@zerogravity.kawo2.rwth-aachen.d> <20010823135941.B4003@dragon.nuxi.com> <15237.37767.274325.945753@nomad.yogotech.com> <20010823192558.A6265@dragon.nuxi.com> <15237.55821.676471.752233@nomad.yogotech.com> <20010823214749.A1674@dragon.nuxi.com> X-Mailer: VM 6.95 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 > > As Bruce would say, this is a bug, and I won't disagree with him. > > However, we have two different set of CFLAGS (one for kernel, and one > > for userland), which is just weird. > > I would disagree. There should be a global make settings. There are: /usr/share/mk/*.mk Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 24 0:33:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by hub.freebsd.org (Postfix) with ESMTP id F2C1837B406 for ; Fri, 24 Aug 2001 00:33:27 -0700 (PDT) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id JAA20986; Fri, 24 Aug 2001 09:33:25 +0200 (CEST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.4/8.11.4) id f7O7XP043783; Fri, 24 Aug 2001 09:33:25 +0200 (CEST) (envelope-from wkb) Date: Fri, 24 Aug 2001 09:33:25 +0200 From: Wilko Bulte To: kyphur Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Question Message-ID: <20010824093325.B43742@freebie.xs4all.nl> Reply-To: freebsd-questions@FreeBSD.ORG References: <003101c12c4e$5c22f2b0$0401a8c0@ra> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <003101c12c4e$5c22f2b0$0401a8c0@ra>; from kyphur@kyphurland.com on Thu, Aug 23, 2001 at 11:39:20PM -0400 X-OS: FreeBSD 4.3-STABLE X-PGP: finger wilko@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 On Thu, Aug 23, 2001 at 11:39:20PM -0400, kyphur wrote: First a not: freebsd-arch is a list for architectural issues. You better send this kind of questions to freebsd-questions. > I'm a computer arts student and I notice that when I go to look at potential jobs that they look for Unix experienced employees. I know that Free BSD is a Unix based system but what exactly are the differences? FreeBSD is based on BSD4.4 which is the UNIX distribution that was distributed by Berkeley University in Berkeley, California. There are quite a few (commercial) Unixes out there. But once you know one in reasonable detail learning to admin. another Unix variant becomes a relatively easy thing to do. FreeBSD is a good starting point IMHO. > My question about the architecture is that I run a AMD 900Mhz and I see that it's mainly for Intel archs. I know that you say it's a x86 architecture and I know that the AMD also supports the x86 arch but have you noticed any problems? No, AMD works just fine. I've been running AMD based systems for years now (I'm typing this on an Athlon 700...) and it works like a charm. > Sorry about all the questions but I'm still learning and I'm really interested in using Unix and/or FreeBSD. > > I hope to hear back from you. > > Jason Powell ---end of quoted text--- -- | / o / / _ Arnhem, The Netherlands email: wilko@FreeBSD.org |/|/ / / /( (_) Bulte To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 24 2:32:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from kawoserv.kawo2.rwth-aachen.de (kawoserv.kawo2.RWTH-Aachen.DE [134.130.180.1]) by hub.freebsd.org (Postfix) with ESMTP id 12DFE37B408; Fri, 24 Aug 2001 02:32:44 -0700 (PDT) (envelope-from alex@big.endian.de) Received: from zerogravity.kawo2.rwth-aachen.de (zerogravity.kawo2.rwth-aachen.de [134.130.181.28]) by kawoserv.kawo2.rwth-aachen.de (8.9.3/8.9.3) with ESMTP id LAA21083; Fri, 24 Aug 2001 11:32:43 +0200 Received: by zerogravity.kawo2.rwth-aachen.de (Postfix, from userid 1001) id E61DD14B30; Fri, 24 Aug 2001 11:32:42 +0200 (CEST) Date: Fri, 24 Aug 2001 11:32:42 +0200 From: Alexander Langer To: "David O'Brien" Cc: Nate Williams , arch@FreeBSD.ORG, ports@FreeBSD.ORG Subject: Re: ports.conf Message-ID: <20010824113242.B1095@zerogravity.kawo2.rwth-aachen.d> Mail-Followup-To: Alexander Langer , David O'Brien , Nate Williams , arch@FreeBSD.ORG, ports@FreeBSD.ORG References: <20010823210729.A95484@zerogravity.kawo2.rwth-aachen.d> <20010823135941.B4003@dragon.nuxi.com> <15237.37767.274325.945753@nomad.yogotech.com> <20010823192558.A6265@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010823192558.A6265@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Thu, Aug 23, 2001 at 07:25:58PM -0700 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. 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 Thus spake David O'Brien (obrien@FreeBSD.ORG): > > Would something like /etc/ports.conf be acceptable? That way it can be > > modified separately from the configuration for the main /usr/src tree, > Yes. Not because it separates things from knobs for /usr/src, but > because it separates things logically. So, are you ok with: - share/mk/sys.mk only sucking in /defaults/make.conf and /etc/make.conf - bsd.port.mk sucking in $PORTSDIR/Mk/ports.conf and then overwriteable in /etc/ports.conf? (Don't bother about the location in the ports/ tree, which can change). I think this is the general agreement, isn't it? Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 24 6:23:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 4DCA537B40A; Fri, 24 Aug 2001 06:23:29 -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 XAA19514; Fri, 24 Aug 2001 23:23:11 +1000 Date: Fri, 24 Aug 2001 23:23:04 +1000 (EST) From: Bruce Evans X-X-Sender: To: Alexander Langer Cc: "David O'Brien" , Nate Williams , , Subject: Re: ports.conf In-Reply-To: <20010824113242.B1095@zerogravity.kawo2.rwth-aachen.d> Message-ID: <20010824231632.G1542-100000@besplex.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, 24 Aug 2001, Alexander Langer wrote: > So, are you ok with: > - share/mk/sys.mk only sucking in /defaults/make.conf and /etc/make.conf > - bsd.port.mk sucking in $PORTSDIR/Mk/ports.conf and then overwriteable > in /etc/ports.conf? I am, for the new stuff at least. sys.mk still sucks in /etc/defaults/make.conf.local (historical cruft). It shouldn't suck in /etc/defaults/make.conf because the latter shouldn't set anything. It currently only sets BDECFLAGS. /etc/defaults/make.conf is unlike all the other files in /etc/defaults. It [should] only gives examples. The actual defaults are in /usr/share/mk/sys.mk. Perhaps /etc/defaults/make.conf should be named make.conf.examples and put elsewhere (where?). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 24 6:45: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from kawoserv.kawo2.rwth-aachen.de (kawoserv.kawo2.RWTH-Aachen.DE [134.130.180.1]) by hub.freebsd.org (Postfix) with ESMTP id D51E837B407; Fri, 24 Aug 2001 06:44:53 -0700 (PDT) (envelope-from alex@big.endian.de) Received: from zerogravity.kawo2.rwth-aachen.de (zerogravity.kawo2.rwth-aachen.de [134.130.181.28]) by kawoserv.kawo2.rwth-aachen.de (8.9.3/8.9.3) with ESMTP id PAA29117; Fri, 24 Aug 2001 15:44:50 +0200 Received: by zerogravity.kawo2.rwth-aachen.de (Postfix, from userid 1001) id B679614B1F; Fri, 24 Aug 2001 15:44:38 +0200 (CEST) Date: Fri, 24 Aug 2001 15:44:38 +0200 From: Alexander Langer To: Bruce Evans Cc: "David O'Brien" , Nate Williams , arch@FreeBSD.ORG, ports@FreeBSD.ORG Subject: Re: ports.conf Message-ID: <20010824154438.A11364@zerogravity.kawo2.rwth-aachen.d> Mail-Followup-To: Alexander Langer , Bruce Evans , David O'Brien , Nate Williams , arch@FreeBSD.ORG, ports@FreeBSD.ORG References: <20010824113242.B1095@zerogravity.kawo2.rwth-aachen.d> <20010824231632.G1542-100000@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010824231632.G1542-100000@besplex.bde.org>; from bde@zeta.org.au on Fri, Aug 24, 2001 at 11:23:04PM +1000 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. 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 Thus spake Bruce Evans (bde@zeta.org.au): > I am, for the new stuff at least. Ok. > It shouldn't suck in /etc/defaults/make.conf because the latter shouldn't > set anything. It currently only sets BDECFLAGS. /etc/defaults/make.conf > is unlike all the other files in /etc/defaults. It [should] only gives > examples. The actual defaults are in /usr/share/mk/sys.mk. Perhaps > /etc/defaults/make.conf should be named make.conf.examples and put > elsewhere (where?). I agree it should be called make.conf.examples, but where would it be stored? I have no idea. /etc/examples is dumb, /usr/share/examples/etc doesn't really fit either. Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 24 8:29:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (dsl092-013-169.sfo1.dsl.speakeasy.net [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 7991937B406; Fri, 24 Aug 2001 08:29:08 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.5/8.11.1) id f7OFSqu86361; Fri, 24 Aug 2001 08:28:52 -0700 (PDT) (envelope-from obrien) Date: Fri, 24 Aug 2001 08:28:52 -0700 From: "David O'Brien" To: Nate Williams Cc: arch@FreeBSD.ORG, ports@FreeBSD.ORG, Alexander Langer Subject: Re: ports.conf Message-ID: <20010824082851.A85961@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010823210729.A95484@zerogravity.kawo2.rwth-aachen.d> <20010823135941.B4003@dragon.nuxi.com> <15237.37767.274325.945753@nomad.yogotech.com> <20010823192558.A6265@dragon.nuxi.com> <15237.55821.676471.752233@nomad.yogotech.com> <20010823214749.A1674@dragon.nuxi.com> <15237.56561.741293.622635@nomad.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15237.56561.741293.622635@nomad.yogotech.com>; from nate@yogotech.com on Thu, Aug 23, 2001 at 10:49:53PM -0600 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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, Aug 23, 2001 at 10:49:53PM -0600, Nate Williams wrote: > > > As Bruce would say, this is a bug, and I won't disagree with him. > > > However, we have two different set of CFLAGS (one for kernel, and one > > > for userland), which is just weird. > > > > I would disagree. There should be a global make settings. > > There are: > > /usr/share/mk/*.mk Wrong! /usr/share can be _shared_ across machines, duh! This is not a place for per-machine settings. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 24 8:32: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (dsl092-013-169.sfo1.dsl.speakeasy.net [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 0AD3337B403; Fri, 24 Aug 2001 08:32:03 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.5/8.11.1) id f7OFVeX86410; Fri, 24 Aug 2001 08:31:40 -0700 (PDT) (envelope-from obrien) Date: Fri, 24 Aug 2001 08:31:40 -0700 From: "David O'Brien" To: Alexander Langer , Bruce Evans , Nate Williams , arch@FreeBSD.ORG, ports@FreeBSD.ORG Subject: Re: ports.conf Message-ID: <20010824083139.B85961@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010824113242.B1095@zerogravity.kawo2.rwth-aachen.d> <20010824231632.G1542-100000@besplex.bde.org> <20010824154438.A11364@zerogravity.kawo2.rwth-aachen.d> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010824154438.A11364@zerogravity.kawo2.rwth-aachen.d>; from alex@big.endian.de on Fri, Aug 24, 2001 at 03:44:38PM +0200 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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, Aug 24, 2001 at 03:44:38PM +0200, Alexander Langer wrote: > /usr/share/examples/etc doesn't really fit either. Why? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 24 9:13: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from kabel203050.kabel.utwente.nl (kabel203050.kabel.utwente.nl [130.89.203.50]) by hub.freebsd.org (Postfix) with ESMTP id DB42737B40A for ; Fri, 24 Aug 2001 09:12:34 -0700 (PDT) (envelope-from mauddib@kabel203050.kabel.utwente.nl) Received: by mauddib.thuis (Postfix, from userid 1000) id 341C1B882; Fri, 24 Aug 2001 14:14:08 +0200 (CEST) Date: Fri, 24 Aug 2001 14:14:08 +0200 From: Edwin de Jong To: freebsd-arch@freebsd.org Subject: slight change to kldload(8)/kldunload(8) Message-ID: <20010824141407.A3733@gmx.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline User-Agent: Mutt/1.2.5i 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 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, The attached diffs are slight changes to kldload and kldload to support multiple arguments (so it is possible now to say kldload module1.ko module2.ko). Edwin de Jong (private mail if I did anything wrong, first commit) -- "I wish there was a knob on the TV to turn up the intelligence. There's a knob called `brightness', but it doesn't work." -- Gallagher --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kldload.diff" Index: kldload/kldload.8 =================================================================== RCS file: /home/ncvs/src/sbin/kldload/kldload.8,v retrieving revision 1.15 diff -r1.15 kldload.8 37a38 > \&... 41c42 < loads the file --- > loads the files Index: kldload/kldload.c =================================================================== RCS file: /home/ncvs/src/sbin/kldload/kldload.c,v retrieving revision 1.7 diff -r1.7 kldload.c 42c42 < fprintf(stderr, "usage: kldload [-v] filename\n"); --- > fprintf(stderr, "usage: kldload [-v] filename...\n"); 64,72c64,71 < if (argc != 1) < usage(); < < fileid = kldload(argv[0]); < if (fileid < 0) < err(1, "can't load %s", argv[0]); < else < if (verbose) < printf("Loaded %s, id=%d\n", argv[0], fileid); --- > for(argc-- ; argc >= 0 ; argc--) { > fileid = kldload(argv[argc]); > if (fileid < 0) > err(1, "can't load %s", argv[argc]); > else > if (verbose) > printf("Loaded %s, id=%d\n", argv[argc], fileid); > } --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kldunload.diff" Index: kldunload/kldunload.8 =================================================================== RCS file: /home/ncvs/src/sbin/kldunload/kldunload.8,v retrieving revision 1.11 diff -r1.11 kldunload.8 37a38 > \&... 40d40 < .Op Fl n 41a42 > \&... 45c46 < utility unloads a file which was previously loaded with --- > utility unloads files which were previously loaded with 52,57c53,54 < .It Fl i Ar id < Unload the file with this ID. < .It Fl n Ar name < Unload the file with this name. < .It Ar name < Unload the file with this name. --- > .It Fl i > Use ID's instead of names. Index: kldunload/kldunload.c =================================================================== RCS file: /home/ncvs/src/sbin/kldunload/kldunload.c,v retrieving revision 1.10 diff -r1.10 kldunload.c 42,43c42,43 < fprintf(stderr, "usage: kldunload [-v] -i id\n"); < fprintf(stderr, " kldunload [-v] [-n] name\n"); --- > fprintf(stderr, "usage: kldunload [-v] -i id...\n"); > fprintf(stderr, " kldunload [-v] name...\n"); 51,53c51,52 < int verbose = 0; < int fileid = 0; < char* filename = 0; --- > unsigned short int verbose = 0, optfileid = 0; > int fileid; 55c54 < while ((c = getopt(argc, argv, "i:n:v")) != -1) --- > while ((c = getopt(argc, argv, "inv")) != -1) 58,61c57 < fileid = atoi(optarg); < if (!fileid) < errx(1, "Invalid ID %s", optarg); < break; --- > optfileid = 1; 63d58 < filename = optarg; 74,80c69,70 < if (!fileid && !filename && (argc == 1)) { < filename = *argv; < argc--; < } < < if (argc != 0 || fileid && filename) < usage(); --- > if (argc == 0) > usage(); 82,83c72,88 < if (fileid == 0 && filename == 0) < usage(); --- > for(argc--; argc >= 0; argc--) { > if (optfileid == 0) { > if((fileid = kldfind(argv[argc])) < 0) > err(1, "can't find file %s", argv[argc]); > } > else { > if(!(fileid = atoi(argv[argc]))) > err(1, "invalid file id: %s", argv[argc]); > } > > if (verbose) { > struct kld_file_stat stat; > stat.version = sizeof stat; > if (kldstat(fileid, &stat) < 0) > err(1, "can't stat file id: %n", fileid); > printf("Unloading %s, id=%d\n", stat.name, fileid); > } 85,87c90,91 < if (filename) { < if ((fileid = kldfind(filename)) < 0) < err(1, "can't find file %s", filename); --- > if (kldunload(fileid) < 0) > err(1, "can't unload file id: %n", fileid); 89,99d92 < < if (verbose) { < struct kld_file_stat stat; < stat.version = sizeof stat; < if (kldstat(fileid, &stat) < 0) < err(1, "can't stat file"); < printf("Unloading %s, id=%d\n", stat.name, fileid); < } < < if (kldunload(fileid) < 0) < err(1, "can't unload file"); --IJpNTDwzlM2Ie8A6-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 24 9:13: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from kabel203050.kabel.utwente.nl (kabel203050.kabel.utwente.nl [130.89.203.50]) by hub.freebsd.org (Postfix) with ESMTP id BF8AF37B410 for ; Fri, 24 Aug 2001 09:12:35 -0700 (PDT) (envelope-from mauddib@kabel203050.kabel.utwente.nl) Received: by mauddib.thuis (Postfix, from userid 1000) id 4833FB972; Fri, 24 Aug 2001 17:55:55 +0200 (CEST) Date: Fri, 24 Aug 2001 17:55:54 +0200 From: Edwin de Jong To: freebsd-arch@freebsd.org Subject: Re: slight change to kldload(8)/kldunload(8) Message-ID: <20010824175554.A1282@gmx.net> References: <20010824141407.A3733@gmx.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010824141407.A3733@gmx.net>; from mauddib@gmx.net on Fri, Aug 24, 2001 at 02:14:08PM +0200 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 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Uhm, wrong patch, here is the real one: -- "I wish there was a knob on the TV to turn up the intelligence. There's a knob called `brightness', but it doesn't work." -- Gallagher --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kldload.diff" Index: kldload/kldload.8 =================================================================== RCS file: /home/ncvs/src/sbin/kldload/kldload.8,v retrieving revision 1.15 diff -r1.15 kldload.8 37a38 > \&... 41c42 < loads the file --- > loads the files Index: kldload/kldload.c =================================================================== RCS file: /home/ncvs/src/sbin/kldload/kldload.c,v retrieving revision 1.7 diff -r1.7 kldload.c 42c42 < fprintf(stderr, "usage: kldload [-v] filename\n"); --- > fprintf(stderr, "usage: kldload [-v] filename...\n"); 64,72c64,71 < if (argc != 1) < usage(); < < fileid = kldload(argv[0]); < if (fileid < 0) < err(1, "can't load %s", argv[0]); < else < if (verbose) < printf("Loaded %s, id=%d\n", argv[0], fileid); --- > for(argc-- ; argc >= 0 ; argc--) { > fileid = kldload(argv[argc]); > if (fileid < 0) > err(1, "can't load %s", argv[argc]); > else > if (verbose) > printf("Loaded %s, id=%d\n", argv[argc], fileid); > } --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kldunload.diff" ? kldunload/a.out Index: kldunload/kldunload.8 =================================================================== RCS file: /home/ncvs/src/sbin/kldunload/kldunload.8,v retrieving revision 1.11 diff -r1.11 kldunload.8 37a38 > \&... 40d40 < .Op Fl n 41a42 > \&... 45c46 < utility unloads a file which was previously loaded with --- > utility unloads files which were previously loaded with 52,57c53,54 < .It Fl i Ar id < Unload the file with this ID. < .It Fl n Ar name < Unload the file with this name. < .It Ar name < Unload the file with this name. --- > .It Fl i > Use ID's instead of names. Index: kldunload/kldunload.c =================================================================== RCS file: /home/ncvs/src/sbin/kldunload/kldunload.c,v retrieving revision 1.10 diff -r1.10 kldunload.c 42,43c42,43 < fprintf(stderr, "usage: kldunload [-v] -i id\n"); < fprintf(stderr, " kldunload [-v] [-n] name\n"); --- > fprintf(stderr, "usage: kldunload [-v] -i id...\n"); > fprintf(stderr, " kldunload [-v] name...\n"); 51,53c51,52 < int verbose = 0; < int fileid = 0; < char* filename = 0; --- > unsigned short int verbose = 0, optfileid = 0; > int fileid; 55c54 < while ((c = getopt(argc, argv, "i:n:v")) != -1) --- > while ((c = getopt(argc, argv, "inv")) != -1) 58,61c57,58 < fileid = atoi(optarg); < if (!fileid) < errx(1, "Invalid ID %s", optarg); < break; --- > optfileid = 1; > break; 63d59 < filename = optarg; 74,83c70,71 < if (!fileid && !filename && (argc == 1)) { < filename = *argv; < argc--; < } < < if (argc != 0 || fileid && filename) < usage(); < < if (fileid == 0 && filename == 0) < usage(); --- > if (argc == 0) > usage(); 85,87c73,93 < if (filename) { < if ((fileid = kldfind(filename)) < 0) < err(1, "can't find file %s", filename); --- > for(argc--; argc >= 0; argc--) { > if (optfileid == 0) { > if((fileid = kldfind(argv[argc])) < 0) > err(1, "can't find file %s", argv[argc]); > } > else if (!(fileid = atoi(argv[argc]))) { > err(1, "invalid file id: %s", argv[argc]); > } > else { > > if (verbose) { > struct kld_file_stat stat; > stat.version = sizeof stat; > if (kldstat(fileid, &stat) < 0) > err(1, "can't stat file id: %d", fileid); > printf("Unloading %s, id=%d\n", stat.name, fileid); > } > > if (kldunload(fileid) < 0) > err(1, "can't unload file id: %d", fileid); > } 89,99d94 < < if (verbose) { < struct kld_file_stat stat; < stat.version = sizeof stat; < if (kldstat(fileid, &stat) < 0) < err(1, "can't stat file"); < printf("Unloading %s, id=%d\n", stat.name, fileid); < } < < if (kldunload(fileid) < 0) < err(1, "can't unload file"); --1yeeQ81UyVL57Vl7-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 24 9:29:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from kabel203050.kabel.utwente.nl (kabel203050.kabel.utwente.nl [130.89.203.50]) by hub.freebsd.org (Postfix) with ESMTP id 5226C37B40B for ; Fri, 24 Aug 2001 09:29:14 -0700 (PDT) (envelope-from mauddib@kabel203050.kabel.utwente.nl) Received: by mauddib.thuis (Postfix, from userid 1000) id 43B00B982; Fri, 24 Aug 2001 18:08:42 +0200 (CEST) Date: Fri, 24 Aug 2001 18:08:41 +0200 From: Edwin de Jong To: arch@freebsd.org Subject: Slight change to kldload(8)/kldunload(8) Message-ID: <20010824180841.A4256@gmx.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline User-Agent: Mutt/1.2.5i 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 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I made a small change to kldload(8) and kldunload(8) so it supports multiple arguments (eg. kldload module1 module2; kldunload -i 1 2 3). Diffs are in the attachments, Regards, Edwin de Jong (ps. this is my first commit, any comments about this is highly appreciated) -- "I wish there was a knob on the TV to turn up the intelligence. There's a knob called `brightness', but it doesn't work." -- Gallagher --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kldload.diff" Index: kldload/kldload.8 =================================================================== RCS file: /home/ncvs/src/sbin/kldload/kldload.8,v retrieving revision 1.15 diff -r1.15 kldload.8 37a38 > \&... 41c42 < loads the file --- > loads the files Index: kldload/kldload.c =================================================================== RCS file: /home/ncvs/src/sbin/kldload/kldload.c,v retrieving revision 1.7 diff -r1.7 kldload.c 42c42 < fprintf(stderr, "usage: kldload [-v] filename\n"); --- > fprintf(stderr, "usage: kldload [-v] filename...\n"); 64,72c64,71 < if (argc != 1) < usage(); < < fileid = kldload(argv[0]); < if (fileid < 0) < err(1, "can't load %s", argv[0]); < else < if (verbose) < printf("Loaded %s, id=%d\n", argv[0], fileid); --- > for(argc-- ; argc >= 0 ; argc--) { > fileid = kldload(argv[argc]); > if (fileid < 0) > err(1, "can't load %s", argv[argc]); > else > if (verbose) > printf("Loaded %s, id=%d\n", argv[argc], fileid); > } --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kldunload.diff" ? kldunload/a.out Index: kldunload/kldunload.8 =================================================================== RCS file: /home/ncvs/src/sbin/kldunload/kldunload.8,v retrieving revision 1.11 diff -r1.11 kldunload.8 37a38 > \&... 40d40 < .Op Fl n 41a42 > \&... 45c46 < utility unloads a file which was previously loaded with --- > utility unloads files which were previously loaded with 52,57c53,54 < .It Fl i Ar id < Unload the file with this ID. < .It Fl n Ar name < Unload the file with this name. < .It Ar name < Unload the file with this name. --- > .It Fl i > Use ID's instead of names. Index: kldunload/kldunload.c =================================================================== RCS file: /home/ncvs/src/sbin/kldunload/kldunload.c,v retrieving revision 1.10 diff -r1.10 kldunload.c 42,43c42,43 < fprintf(stderr, "usage: kldunload [-v] -i id\n"); < fprintf(stderr, " kldunload [-v] [-n] name\n"); --- > fprintf(stderr, "usage: kldunload [-v] -i id...\n"); > fprintf(stderr, " kldunload [-v] name...\n"); 51,53c51,52 < int verbose = 0; < int fileid = 0; < char* filename = 0; --- > unsigned short int verbose = 0, optfileid = 0; > int fileid; 55c54 < while ((c = getopt(argc, argv, "i:n:v")) != -1) --- > while ((c = getopt(argc, argv, "inv")) != -1) 58,61c57,58 < fileid = atoi(optarg); < if (!fileid) < errx(1, "Invalid ID %s", optarg); < break; --- > optfileid = 1; > break; 63d59 < filename = optarg; 74,83c70,71 < if (!fileid && !filename && (argc == 1)) { < filename = *argv; < argc--; < } < < if (argc != 0 || fileid && filename) < usage(); < < if (fileid == 0 && filename == 0) < usage(); --- > if (argc == 0) > usage(); 85,87c73,93 < if (filename) { < if ((fileid = kldfind(filename)) < 0) < err(1, "can't find file %s", filename); --- > for(argc--; argc >= 0; argc--) { > if (optfileid == 0) { > if((fileid = kldfind(argv[argc])) < 0) > err(1, "can't find file %s", argv[argc]); > } > else if (!(fileid = atoi(argv[argc]))) { > err(1, "invalid file id: %s", argv[argc]); > } > else { > > if (verbose) { > struct kld_file_stat stat; > stat.version = sizeof stat; > if (kldstat(fileid, &stat) < 0) > err(1, "can't stat file id: %d", fileid); > printf("Unloading %s, id=%d\n", stat.name, fileid); > } > > if (kldunload(fileid) < 0) > err(1, "can't unload file id: %d", fileid); > } 89,99d94 < < if (verbose) { < struct kld_file_stat stat; < stat.version = sizeof stat; < if (kldstat(fileid, &stat) < 0) < err(1, "can't stat file"); < printf("Unloading %s, id=%d\n", stat.name, fileid); < } < < if (kldunload(fileid) < 0) < err(1, "can't unload file"); --/04w6evG8XlLl3ft-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 24 9:31:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id B4ABB37B405 for ; Fri, 24 Aug 2001 09:31:11 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 850 invoked by uid 1000); 24 Aug 2001 16:29:43 -0000 Date: Fri, 24 Aug 2001 19:29:43 +0300 From: Peter Pentchev To: Edwin de Jong Cc: freebsd-arch@freebsd.org Subject: Re: slight change to kldload(8)/kldunload(8) Message-ID: <20010824192943.B532@ringworld.oblivion.bg> Mail-Followup-To: Edwin de Jong , freebsd-arch@freebsd.org References: <20010824141407.A3733@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010824141407.A3733@gmx.net>; from mauddib@gmx.net on Fri, Aug 24, 2001 at 02:14:08PM +0200 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, Aug 24, 2001 at 02:14:08PM +0200, Edwin de Jong wrote: > Hi, > > The attached diffs are slight changes to kldload and kldload to support > multiple arguments (so it is possible now to say kldload module1.ko > module2.ko). > > Edwin de Jong > > (private mail if I did anything wrong, first commit) IMHO, additional cmdline arguments to kldload/kldunload(8) ought to be reserved for specifying options (hints, or whatever one would choose to call them). That *could* be done with getopt-style options or something, but IMHO, hints specified on the command line would be more useful and more intuitive than additional modules to load.. Then again, this is just my opinion :) G'luck, Peter -- I had to translate this sentence into English because I could not read the original Sanskrit. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 24 14:34:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-54.dsl.lsan03.pacbell.net [63.207.60.54]) by hub.freebsd.org (Postfix) with ESMTP id 315D537B401; Fri, 24 Aug 2001 14:34:45 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8BFF866D1C; Fri, 24 Aug 2001 14:34:44 -0700 (PDT) Date: Fri, 24 Aug 2001 14:34:44 -0700 From: Kris Kennaway To: "Cc:arch"@FreeBSD.ORG, ports@FreeBSD.ORG Cc: Peter Pentchev , arch@FreeBSD.ORG, Alexander Langer Subject: Re: ports.conf Message-ID: <20010824143444.B83171@xor.obsecurity.org> References: <20010823210729.A95484@zerogravity.kawo2.rwth-aachen.d> <20010823135941.B4003@dragon.nuxi.com> <20010824001737.B1714@ringworld.oblivion.bg> <20010823143844.A18197@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="6sX45UoQRIJXqkqR" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010823143844.A18197@dragon.nuxi.com>; from dev-null@NUXI.com on Thu, Aug 23, 2001 at 02:38:44PM -0700 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 --6sX45UoQRIJXqkqR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 23, 2001 at 02:38:44PM -0700, David O'Brien wrote: > On Fri, Aug 24, 2001 at 12:17:37AM +0300, Peter Pentchev wrote: > > I think he meant 'maintained in the ports/ tree' just as make.conf > > is 'maintained in the src/ tree', that is, there is a src/etc/make.conf > > file with evolving defaults. Yes, ports.conf should probably live > > in /etc or some such place, but I, too, think that it should be > > maintained in the ports tree, quite possibly in ports/Mk/. >=20 > How are you suggesting ports.conf get into /etc? A `make world' cannot > depend on having a populated /usr/ports/Mk. Same way /etc/make.conf gets into /etc. Kris --6sX45UoQRIJXqkqR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7hshzWry0BWjoQKURAp4tAKCjqe5JPmafMzKsG8Fn8B6nUgBpJwCeIsr0 WPoXJc7lHEWQEIiiIR+w9ic= =00ks -----END PGP SIGNATURE----- --6sX45UoQRIJXqkqR-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 25 1:57:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from kawoserv.kawo2.rwth-aachen.de (kawoserv.kawo2.RWTH-Aachen.DE [134.130.180.1]) by hub.freebsd.org (Postfix) with ESMTP id 8802A37B406; Sat, 25 Aug 2001 01:57:10 -0700 (PDT) (envelope-from alex@fump.kawo2.rwth-aachen.de) Received: from fump.kawo2.rwth-aachen.de (root@fump.kawo2.rwth-aachen.de [134.130.181.148]) by kawoserv.kawo2.rwth-aachen.de (8.9.3/8.9.3) with ESMTP id KAA32181; Sat, 25 Aug 2001 10:57:09 +0200 Received: (from alex@localhost) by fump.kawo2.rwth-aachen.de (8.11.3/8.11.3) id f7P8vE103779; Sat, 25 Aug 2001 10:57:14 +0200 (CEST) (envelope-from alex) Date: Sat, 25 Aug 2001 10:57:13 +0200 From: Alexander Langer To: "David O'Brien" Cc: Bruce Evans , Nate Williams , arch@FreeBSD.ORG, ports@FreeBSD.ORG Subject: Re: ports.conf Message-ID: <20010825105713.A3763@fump.kawo2.rwth-aachen.de> Mail-Followup-To: Alexander Langer , David O'Brien , Bruce Evans , Nate Williams , arch@FreeBSD.ORG, ports@FreeBSD.ORG References: <20010824113242.B1095@zerogravity.kawo2.rwth-aachen.d> <20010824231632.G1542-100000@besplex.bde.org> <20010824154438.A11364@zerogravity.kawo2.rwth-aachen.d> <20010824083139.B85961@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010824083139.B85961@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Fri, Aug 24, 2001 at 08:31:40AM -0700 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. 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 Thus spake David O'Brien (obrien@FreeBSD.ORG): > > /usr/share/examples/etc doesn't really fit either. > Why? Uhm, no idea why I wrote that. It fits perfectly. Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 25 8:50: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from kabel203050.kabel.utwente.nl (kabel203050.kabel.utwente.nl [130.89.203.50]) by hub.freebsd.org (Postfix) with ESMTP id 3CD4A37B40A for ; Sat, 25 Aug 2001 08:49:57 -0700 (PDT) (envelope-from mauddib@kabel203050.kabel.utwente.nl) Received: by kabel203050.kabel.utwente.nl (Postfix, from userid 1000) id E7841B882; Sat, 25 Aug 2001 17:54:32 +0200 (CEST) Date: Sat, 25 Aug 2001 17:51:14 +0200 From: Edwin de Jong To: Peter Pentchev Subject: Re: slight change to kldload(8)/kldunload(8) Message-ID: <20010825175113.A63868@gmx.net> References: <20010824141407.A3733@gmx.net> <20010824192943.B532@ringworld.oblivion.bg> <20010824200527.A41553@gmx.net> <20010825145021.G487@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010825145021.G487@ringworld.oblivion.bg>; from roam@ringlet.net on Sat, Aug 25, 2001 at 02:50:21PM +0300 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 Sat, Aug 25, 2001 at 02:50:21PM +0300, Peter Pentchev wrote: > On Fri, Aug 24, 2001 at 08:05:27PM +0200, Edwin de Jong wrote: > > On Fri, Aug 24, 2001 at 07:29:43PM +0300, Peter Pentchev wrote: > > > On Fri, Aug 24, 2001 at 02:14:08PM +0200, Edwin de Jong wrote: > > > > > > The attached diffs are slight changes to kldload and kldload to support > > > > multiple arguments (so it is possible now to say kldload module1.ko > > > > module2.ko). > > > > > IMHO, additional cmdline arguments to kldload/kldunload(8) ought > > > to be reserved for specifying options (hints, or whatever one would > > > choose to call them). That *could* be done with getopt-style options > > > or something, but IMHO, hints specified on the command line would be > > > more useful and more intuitive than additional modules to load.. > > > > Well, the idea was that since most other tools like ps, ls, rm, cp and > > others also take more than one input argument. Since in this case there > > are no hints to modules, this seems to be most clean option. > > > > Since shell glob substitution increases the number of arguments > > depending on the number of matches, this also allows you to use the > > shell more effectively. > > Yes, the ability to add more than one module might be useful, > I'm not saying it might not. > > All I'm saying is, the ability to specify options while loading > a module might be a bit more useful (think sound card IRQ's), > and adding the options after the module name is the way that it is > usually done in other OS's. > > And BTW, I do think that this discussion should be on a public > mailing list, to see how other people feel on this - quite important > IMHO - subject. At this moment, the function kldload only takes one arg, which is the filename of the module. Indeed, I agree with you that it might be best to add additional arguments to specify how and where the module should be loaded, but this would require a change to the module system also. I'm willing to look at that, and see how this could best be tackled. For now I think it might be best to keep the multiple arguments for a while. I don't want to say that modinstall (or whatever it is called in Linux) is one of the best solutions, however, the automatic loading of module dependencies could work out very well. Another interesting thing is for example with the screensaver modules. One generally only wants to load one module at a time (only the last one is effective). Actually the other modules should be unloaded automagically. Regards, Edwin -- "I wish there was a knob on the TV to turn up the intelligence. There's a knob called `brightness', but it doesn't work." -- Gallagher To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 25 8:58:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id 2C40637B408 for ; Sat, 25 Aug 2001 08:58:40 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 12144 invoked by uid 1000); 25 Aug 2001 15:57:12 -0000 Date: Sat, 25 Aug 2001 18:57:12 +0300 From: Peter Pentchev To: Edwin de Jong Cc: arch@FreeBSD.org Subject: Re: slight change to kldload(8)/kldunload(8) Message-ID: <20010825185712.H559@ringworld.oblivion.bg> Mail-Followup-To: Edwin de Jong , arch@FreeBSD.org References: <20010824141407.A3733@gmx.net> <20010824192943.B532@ringworld.oblivion.bg> <20010824200527.A41553@gmx.net> <20010825145021.G487@ringworld.oblivion.bg> <20010825175113.A63868@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010825175113.A63868@gmx.net>; from mauddib@gmx.net on Sat, Aug 25, 2001 at 05:51:14PM +0200 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 Hrm.. It looks like you sent this to -arch after I replied to your personal message to me.. Okay, here's my reply for the benefit of -arch.. On Sat, Aug 25, 2001 at 05:51:14PM +0200, Edwin de Jong wrote: > On Sat, Aug 25, 2001 at 02:50:21PM +0300, Peter Pentchev wrote: > > On Fri, Aug 24, 2001 at 08:05:27PM +0200, Edwin de Jong wrote: > > > On Fri, Aug 24, 2001 at 07:29:43PM +0300, Peter Pentchev wrote: > > > > On Fri, Aug 24, 2001 at 02:14:08PM +0200, Edwin de Jong wrote: > > > > > > > > The attached diffs are slight changes to kldload and kldload to support > > > > > multiple arguments (so it is possible now to say kldload module1.ko > > > > > module2.ko). > > > > > > > IMHO, additional cmdline arguments to kldload/kldunload(8) ought > > > > to be reserved for specifying options (hints, or whatever one would > > > > choose to call them). That *could* be done with getopt-style options > > > > or something, but IMHO, hints specified on the command line would be > > > > more useful and more intuitive than additional modules to load.. > > > > > > Well, the idea was that since most other tools like ps, ls, rm, cp and > > > others also take more than one input argument. Since in this case there > > > are no hints to modules, this seems to be most clean option. > > > > > > Since shell glob substitution increases the number of arguments > > > depending on the number of matches, this also allows you to use the > > > shell more effectively. > > > > Yes, the ability to add more than one module might be useful, > > I'm not saying it might not. > > > > All I'm saying is, the ability to specify options while loading > > a module might be a bit more useful (think sound card IRQ's), > > and adding the options after the module name is the way that it is > > usually done in other OS's. > > > > And BTW, I do think that this discussion should be on a public > > mailing list, to see how other people feel on this - quite important > > IMHO - subject. > > At this moment, the function kldload only takes one arg, which is the > filename of the module. Indeed, I agree with you that it might be > best to add additional arguments to specify how and where the module > should be loaded, but this would require a change to the module system > also. Well, modules in -current already honor hints. All that is needed is a userland utility to read/set hints - I have it on my RSN TODO list to see what I can do about the kldconfig(8) that I hacked up recently, but I suppose kldload(8) would be another nice place to specify hints for the module you're loading right now. > I'm willing to look at that, and see how this could best be tackled. > For now I think it might be best to keep the multiple arguments for a > while. Actually, it is kind of hard for me to think of a (commonly occurring) situation when you'd want to load more than one module of a time :) So basically, the question would be whether we want to *introduce* this functionality :) > I don't want to say that modinstall (or whatever it is called in Linux) > is one of the best solutions, however, the automatic loading of module > dependencies could work out very well. Module dependencies already work quite fine - or are supposed to. If they don't, then tackling *that* would be a much more important project :) > Another interesting thing is for example with the screensaver modules. > One generally only wants to load one module at a time (only the last one > is effective). Actually the other modules should be unloaded > automagically. This is interesting - having modules "provide" some "functionality", and either not allowing another module with the same functionality, or automatically unloading the old one.. What if there is a third module depending on the old one? Points to ponder.. Points to be raised in a separate mail to -arch and/or -hackers.. G'luck, Peter -- What would this sentence be like if it weren't self-referential? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 25 19:40:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 9964F37B40C for ; Sat, 25 Aug 2001 19:40:16 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id TAA66162; Sat, 25 Aug 2001 19:48:33 -0700 (PDT) Message-ID: <3B885ED0.9DFCA5B5@elischer.org> Date: Sat, 25 Aug 2001 19:28:32 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: "bsd-api-discuss@wasabisystems.com" , Arch@freebsd.org Subject: changes to BSD APIs for THREADS support Content-Type: text/plain; charset=iso-8859-2 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 With both FreeBSD and NetBSD closing in on complete Threads support, there are some items that need to be discussed. For example: How does procfs report a multithreaded process running on several processors? how does PS extract state from the kernel when a process is simultaniously in several states? What does "%cpu" actually indicate? Which wmesg is shown if there are 8 sleeping threads? (does someone have a MACH system that shows these things?) (MacOS X?) Inside the kernel, how are the proiority adjustments calculated when a process might be running and sleeping at the same time? How does ^T decide what thread/proc to report? All this is separate to what syscalls we will be wanting to add to actually give the multithreading libraries access to the new kernel support. On that front FreeBSD is looking at at least 4 new syscalls. I'm going to describe them by function rather than name as the names are not decided: 1/ Add a new kernel schedulable entity (KSE). The first call to this syscall turns on the threading support. To fully utilise an N CPU system you need to do N of these calls. This function will return many times, so its caller must never return or unwind it's stack (until threading is stopped). This system call will return whenever some other system call would block in the kernel. It supplies as an argument, a mailbox in which the reason for returning is to be placed. (and a lot more info). With at least one KSE in operation. All syscalls are asynchronous (Either they return immediatly or an upcall is generated onto the frame stored by #1). 2/ A yield() call which tells the kernel that the user thread scheduler has no present use for the current processor and it may be used by another process. This call does not return. (ever) The KSE is not destroyed, but marked 'idle' within eh kernel. The kernel way activate it (or in fact not idle it) if it DOES have something for it to do (e.g. complete a previously suspended syscall). 3/ A call that can be used by the user thread scheduler to 'unyield' a previously yielded processor. i.e. it could do with it, now, if it's available. (This call will return immediatly but will ALSO come back as an additional return of #1 for a KSE that was previously yielded.) 4/ A call by which a KSE suicides.. It will never return and the #1 frame (upcall frame) associated with this KSE will never be used again and can be freed. If there is only one KSE in action, process operation reverts to un-threaded operation. 5/ It is possible that we may need a call by which the user thread scheduler can 'cancel' the syscall that a particular kernel thread is currently operating on. (particularly if it is waiting). In addition there may be the need for one or two synchronisation primatives though this is not certain. -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 25 22:27:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.duh.org (rr-56-9-160.atl.mediaone.net [66.56.9.160]) by hub.freebsd.org (Postfix) with ESMTP id A4BDC37B401 for ; Sat, 25 Aug 2001 22:27:32 -0700 (PDT) (envelope-from tv@wasabisystems.com) Received: from todd (todd.int.duh.org [10.69.1.8]) by mail.duh.org (8.11.3/8.11.3/dsb-1.1a1) with ESMTP id f7Q5MpA02257; Sun, 26 Aug 2001 01:22:51 -0400 (EDT) Date: Sun, 26 Aug 2001 01:27:43 -0400 (Eastern Daylight Time) From: Todd Vierling To: Julian Elischer Cc: "bsd-api-discuss@wasabisystems.com" Subject: Re: changes to BSD APIs for THREADS support In-Reply-To: <3B885ED0.9DFCA5B5@elischer.org> Message-ID: X-Mailer: Wasabi NetBSD 1.5 X-X-Sender: tv@server.duh.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 Sat, 25 Aug 2001, Julian Elischer wrote: : [Moderators note: I'm not entirely fond of crosspostings between : moderated and non-moderated mailing lists -- please avoid it in the : future. The people on the non-moderated list tend to go off in weird : directions, keeping the same subject and never removing the moderated : list from the CC line. --Perry] I've moved the arch@freebsd.org list to Bcc:. [Note: I'm not a Solaris weenie; in fact, I really don't like Solaris much at all. However, I have cited it several times below, mostly because it's already traveled down all these roads successfully where we are treading anew.] : how does PS extract state from the kernel when a process is simultaniously in : several states? : Which wmesg is shown if there are 8 sleeping threads? I'd presume that the only useful way to deal with this is to provide per-thread info in a ps display. Solaris may be one possible prior art to look at (particularly with a multithreaded process under their compatibility /usr/ucb/ps). : What does "%cpu" actually indicate? There's two components to this. * Whether 100% = 1 CPU or 100% = all CPUs; * What to show for a process without expanding the individual threads in a display. Personally I prefer that 100% = all CPUs, but that's my take. Other prior art may be in Solaris /usr/bin/ps and /usr/ucb/ps for this. : Inside the kernel, how are the proiority adjustments calculated when : a process might be running and sleeping at the same time? Process priorities are a really implementation-specific concept, as a "complete" threading subsystem will have more complex scheduling than simple priorities (for RT ability) and multi-level scheduling (for limiting time allocation to all threads within a process and/or for honoring CPU affinity requests). So there's no real way to provide a standard for this. What's displayed to the user via ps or top isn't all that important otherwise; it might as well be a formula averaging the threads' priorities or somesuch, appropriate for the particular threading implementation. : How does ^T decide what thread/proc to report? Again, we might see if Solaris provides decent prior art with its LWPs. : All this is separate to what syscalls we will be wanting to add to : actually give the multithreading libraries access to the new kernel : support. : : On that front FreeBSD is looking at at least 4 new syscalls. : I'm going to describe them by function rather than name as the names are : not decided: : : 1/ Add a new kernel schedulable entity (KSE). I'm using the term "kernel thread" below, to define it as a thread of program flow scheduled by the kernel. It's less confusing to me, but only because of prior experience with kernel-scheduled threading. 8-) : 2/ A yield() call which tells the kernel that the user thread scheduler has no : present use for the current processor and it may be used by another process. By this I presume that you're talking about some sort of many-to-one userland thread scheduler? You might want to know that, after some personal conversation with Solaris developers at USENIX, they've decided that a two-level (userspace plus kernelspace) thread system is actually more overhead than it is worth and will be phasing it out in future releases. It turns out that reusing the existing context switch code available in the kernel is simpler and faster than jumping around with the userland scheduler's setjmp/longjmp-alike. I believe that the forthcoming NetBSD implementation also will leave scheduling entirely to the kernel, but the person in charge of writing it would know better than I.... : 3/ A call that can be used by the user thread scheduler to 'unyield' : a previously yielded processor. i.e. it could do with it, now, if it's : available. Unyield a processor, or a kernel thread? What it sounds like you're proposing here is to combine processor affinity and kernel thread pause/resume actions into one group. Processor affinity should really be separate from the operation of kernel threads. To define the differences, a kernel thread should be able to run on any available processor by default, but can be set to prefer a specific CPU or CPU group. CPU-specific operation is available as a subset of the available operations in this arrangement. : 4/ A call by which a KSE suicides.. It will never return : and the #1 frame (upcall frame) associated with this KSE will never be used : again and can be freed. AKA a kernel thread exit point; normal. : 5/ It is possible that we may need a call by which the user thread scheduler can : 'cancel' the syscall that a particular kernel thread is currently operating : on. (particularly if it is waiting). Solaris also has a way to do this, but I don't remember what it is off the top of my head. : In addition there may be the need for one or two synchronisation primatives : though this is not certain. NetBSD will require kernel-level synchronization primitives as a fallback, because not all processors NetBSD supports have atomic instructions. There's one more thing having serious interactions with threads that should be addressed: Multithreaded process signal delivery. There's an intricate way that this is handled in Solaris, as "async signals". More prior art that's probably worth imitating for code compatibility's sake. -- -- Todd Vierling * Wasabi NetBSD: Run with it. -- NetBSD 1.5.2 available on CD-ROM soon! -- http://www.wasabisystems.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 25 22:49: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 46F7937B401 for ; Sat, 25 Aug 2001 22:48:57 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f7Q5mtE03868; Sun, 26 Aug 2001 01:48:55 -0400 (EDT) (envelope-from wollman) Date: Sun, 26 Aug 2001 01:48:55 -0400 (EDT) From: Garrett Wollman Message-Id: <200108260548.f7Q5mtE03868@khavrinen.lcs.mit.edu> To: tv@wasabisystems.com Subject: Re: changes to BSD APIs for THREADS support X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: References: Organization: MIT Laboratory for Computer Science Cc: bsd-api-discuss@wasabisystems.com 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 you write: >Multithreaded process signal delivery. There's an intricate way that this >is handled in Solaris, as "async signals". More prior art that's probably >worth imitating for code compatibility's sake. I think that POSIX fully (or at least elaborately) specifies this, and note that POSIX does specify a mechanism whereby event notification can instantiate a new thread; see the description of SIGEV_THREAD in the Realtime Signals Extension. One issue, though, is whether programming to meet only the POSIX requirements is sufficient, or whether other, alternative threading models should be supported more directly. I'm agnostic on this issue (especially since I'm not doing the work either way). I'm not clear on whether those other models would require anything substantually different in the way of kernel support, and in any case that may well be a dead end anyway and not worth the time to investigate. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 25 23:40:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 0ACB737B40C for ; Sat, 25 Aug 2001 23:40:26 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA66945; Sat, 25 Aug 2001 23:50:13 -0700 (PDT) Message-ID: <3B889769.E1529443@elischer.org> Date: Sat, 25 Aug 2001 23:30:01 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Garrett Wollman Cc: bsd-api-discuss@wasabisystems.com Subject: Re: changes to BSD APIs for THREADS support References: <200108260548.f7Q5mtE03868@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=iso-8859-2 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 Garrett Wollman wrote: > > In article you write: > > >Multithreaded process signal delivery. There's an intricate way that this > >is handled in Solaris, as "async signals". More prior art that's probably > >worth imitating for code compatibility's sake. > > I think that POSIX fully (or at least elaborately) specifies this, and > note that POSIX does specify a mechanism whereby event notification > can instantiate a new thread; see the description of SIGEV_THREAD in > the Realtime Signals Extension. The GENERAL Posix scheme is that thread delivery type is defined ber process and thread delivery masking is per thread. They don't say what happens exactly if more than one thread doesn't mask a signal, but they do say that only one of them gets it. In the scheme we are proposing, signals are a per-process thing from the point of view of the kernel, and delivered to the Userland thread scheduler via a standard upcall. It can then decide which actual thread to deliver it to. If that thread is in the kernel, it can decide to abort that syscall using the proposed 5th syscall. > > One issue, though, is whether programming to meet only the POSIX > requirements is sufficient, or whether other, alternative threading > models should be supported more directly. I'm agnostic on this issue > (especially since I'm not doing the work either way). I'm not clear > on whether those other models would require anything substantually > different in the way of kernel support, and in any case that may well > be a dead end anyway and not worth the time to investigate. We can program to meet a superset of posix, if we can decide what the superset is.. :-) > > -GAWollman -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message