From owner-freebsd-arch Sun Dec 16 8:16:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id BA58837B405; Sun, 16 Dec 2001 08:16:24 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.5/8.11.5) with ESMTP id fBGGGKg49403; Sun, 16 Dec 2001 09:16:21 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200112161616.fBGGGKg49403@aslan.scsiguy.com> To: Warner Losh Cc: Mike Smith , freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) In-Reply-To: Your message of "Tue, 11 Dec 2001 22:10:14 MST." <200112120510.fBC5AEM33040@harmony.village.org> Date: Sun, 16 Dec 2001 09:16:20 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >In message <200112120509.fBC59Qk07926@mass.dis.org> Mike Smith writes: >: > However, the argument for /usr is more than just that it is for crash >: > recovery. >: >: It is? Sounds like there are lots of retconned reasons that could >: equally easily be worked around. 8) Has the requirement for the root partition being first in the disklabel been removed? I prefer to have my swap partition as close to the front of the disk as possible to take advantage of the faster tracks. If / needs to come before swap, and / is *huge*, swap gets slower. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 16 8:25:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id 5C20F37B419; Sun, 16 Dec 2001 08:25:07 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id fBGGOx635567; Sun, 16 Dec 2001 17:24:59 +0100 (CET) (envelope-from wkb) Date: Sun, 16 Dec 2001 17:24:59 +0100 From: Wilko Bulte To: "Justin T. Gibbs" Cc: Warner Losh , Mike Smith , freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Message-ID: <20011216172459.A35552@freebie.xs4all.nl> References: <200112120510.fBC5AEM33040@harmony.village.org> <200112161616.fBGGGKg49403@aslan.scsiguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112161616.fBGGGKg49403@aslan.scsiguy.com>; from gibbs@scsiguy.com on Sun, Dec 16, 2001 at 09:16:20AM -0700 X-OS: FreeBSD 4.4-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 Sun, Dec 16, 2001 at 09:16:20AM -0700, Justin T. Gibbs wrote: > >In message <200112120509.fBC59Qk07926@mass.dis.org> Mike Smith writes: > >: > However, the argument for /usr is more than just that it is for crash > >: > recovery. > >: > >: It is? Sounds like there are lots of retconned reasons that could > >: equally easily be worked around. 8) > > Has the requirement for the root partition being first in the disklabel > been removed? I prefer to have my swap partition as close to the front > of the disk as possible to take advantage of the faster tracks. If / > needs to come before swap, and / is *huge*, swap gets slower. On Alpha this is still a No-No IIRC. No idea on x86. When system performance is dictated by the speed of the swap device it is time to add memory IMO. W/ -- | / o / /_ _ email: wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 16 9:28: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 8F77E37B416; Sun, 16 Dec 2001 09:27:57 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.5/8.11.5) with ESMTP id fBGHRug49634; Sun, 16 Dec 2001 10:27:56 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200112161727.fBGHRug49634@aslan.scsiguy.com> To: Mike Smith Cc: Thomas Moestl , arch@FreeBSD.ORG Subject: Re: Please review: changes to MI bus code for sparc64 In-Reply-To: Your message of "Thu, 13 Dec 2001 11:01:43 PST." <200112131901.fBDJ1hl02003@mass.dis.org> Date: Sun, 16 Dec 2001 10:27:56 -0700 From: "Justin T. Gibbs" 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 >> - make most functions in pci_pci.c non-static and add a new header >> (pcib.h) and an extension pointer to the softc to allow drivers for >> non-standard PCI-PCI bridges to use this code instead of duplicating >> most of it. > >I'm not sure that non-staticising this is the correct way to go; we need >a better way of subclassing things. Without knowing what you mean by >"non-standard", it's hard to see how calling these functions is useful. I have changes to new-bus in my tree that allow you to inherit and derive from opaque interfaces exported by other modules. I did this so that cardbus code could reuse the PCI code without having to know too much about the implementation details or PCI extern'ing every function. The unfortunate side effect of this is that every client of new-bus needs to be touched to understand the new method/interface declaration scheme. I've posted patches that allow me to use all the devices in my laptop here: http://people.FreeBSD.org/~gibbs/newbus_cardbus.diffs There is still lots of work to do (not as much code as could be reused is as of yet), but the patches will give you an idea of one possible way to address code reuse issues. It is also possible with this scheme to do an upcall to a parent interface's version of a method from an overridden one, but I haven't written the Perl glue (I have to pull out the book every time I write perl code) to generate the wrappers for this. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 16 10:29:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 239D037B41A; Sun, 16 Dec 2001 10:29:34 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBGITXa07743; Sun, 16 Dec 2001 11:29:33 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fBGITWM70307; Sun, 16 Dec 2001 11:29:32 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112161829.fBGITWM70307@harmony.village.org> To: "Justin T. Gibbs" Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Cc: Mike Smith , freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Sun, 16 Dec 2001 09:16:20 MST." <200112161616.fBGGGKg49403@aslan.scsiguy.com> References: <200112161616.fBGGGKg49403@aslan.scsiguy.com> Date: Sun, 16 Dec 2001 11:29:32 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200112161616.fBGGGKg49403@aslan.scsiguy.com> "Justin T. Gibbs" writes: : Has the requirement for the root partition being first in the disklabel : been removed? I prefer to have my swap partition as close to the front : of the disk as possible to take advantage of the faster tracks. If / : needs to come before swap, and / is *huge*, swap gets slower. Yes. This requirement has been removed. I have: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 307200 0 4.2BSD 1024 8192 16 # (Cyl. 0 -19*) b: 1126400 307200 swap # (Cyl. 19*-89*) c: 30266460 0 unused 0 0 # (Cyl. 0 -1883) e: 4194304 1433600 4.2BSD 1024 8192 16 # (Cyl. 89*-350*) f: 12582912 5627904 4.2BSD 1024 8192 16 # (Cyl. 350*-1133*) g: 12055644 18210816 4.2BSD 1024 8192 16 # (Cyl. 1133*-1883*) My -stable system is on partitions a and e (eg / and /usr), but my -current system is on partition f... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 16 11: 6:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id E0F8F37B416 for ; Sun, 16 Dec 2001 11:06:39 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBGJD3q01070; Sun, 16 Dec 2001 11:13:03 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112161913.fBGJD3q01070@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Justin T. Gibbs" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) In-reply-to: Your message of "Sun, 16 Dec 2001 09:16:20 MST." <200112161616.fBGGGKg49403@aslan.scsiguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 16 Dec 2001 11:13:03 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > >In message <200112120509.fBC59Qk07926@mass.dis.org> Mike Smith writes: > >: > However, the argument for /usr is more than just that it is for crash > >: > recovery. > >: > >: It is? Sounds like there are lots of retconned reasons that could > >: equally easily be worked around. 8) > > Has the requirement for the root partition being first in the disklabel > been removed? I prefer to have my swap partition as close to the front > of the disk as possible to take advantage of the faster tracks. If / > needs to come before swap, and / is *huge*, swap gets slower. The root partition has to be first in the disklabel, but it shouldn't have to be first on the disk. AFAIK, we don't use the first 64k of the swap partition explicitly to avoid stomping on labels and the like. I recall that sysinstall/libdisk had problems with this (it imposed a more rigid ordering than was necessary), but I think that was the only issue. If not, do you remember what the problem was? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 16 12:35:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id CFC7837B417; Sun, 16 Dec 2001 12:35:32 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBGKZVu24030; Sun, 16 Dec 2001 12:35:31 -0800 (PST) (envelope-from dillon) Date: Sun, 16 Dec 2001 12:35:31 -0800 (PST) From: Matthew Dillon Message-Id: <200112162035.fBGKZVu24030@apollo.backplane.com> To: "Justin T. Gibbs" Cc: Warner Losh , Mike Smith , freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) References: <200112161616.fBGGGKg49403@aslan.scsiguy.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 :>: It is? Sounds like there are lots of retconned reasons that could :>: equally easily be worked around. 8) : :Has the requirement for the root partition being first in the disklabel :been removed? I prefer to have my swap partition as close to the front :of the disk as possible to take advantage of the faster tracks. If / :needs to come before swap, and / is *huge*, swap gets slower. : :-- :Justin I address this in 'man tuning'. In the very first section I talk about ordering partitions on the disk to take advantage of outer-track access times. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 17 3:10: 2 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 A22D737B41B; Mon, 17 Dec 2001 03:09:52 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA23604; Mon, 17 Dec 2001 22:09:34 +1100 Date: Mon, 17 Dec 2001 22:10:45 +1100 (EST) From: Bruce Evans X-X-Sender: To: Warner Losh Cc: "Justin T. Gibbs" , Mike Smith , Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) In-Reply-To: <200112161829.fBGITWM70307@harmony.village.org> Message-ID: <20011217215246.F13494-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 16 Dec 2001, Warner Losh wrote: > In message <200112161616.fBGGGKg49403@aslan.scsiguy.com> "Justin T. Gibbs" writes: > : Has the requirement for the root partition being first in the disklabel > : been removed? I prefer to have my swap partition as close to the front > : of the disk as possible to take advantage of the faster tracks. If / > : needs to come before swap, and / is *huge*, swap gets slower. > > Yes. This requirement has been removed. I have: When did it even exist? There should only be a requirement that the boot loader is first on the disk (or slice). On i386's, boot1 must be in the first sector and boot2 soon after. boot2 defaults to reading configuration and booting from the 'a' partition, so you need a filesystem on the 'a' partition of the boot drive unless you want to change this manually every time, but the 'a' partition does not need to start at offset 0. > My -stable system is on partitions a and e (eg / and /usr), but my > -current system is on partition f... I sometimes boot manually from a non-default partition, and used to always boot automatically from a non-default drive on one system (by redirecting to the boot drive using /boot.config). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 17 5: 9:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 3ABA237B41D; Mon, 17 Dec 2001 05:09:07 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBHD90091884; Mon, 17 Dec 2001 15:09:00 +0200 (EET) (envelope-from ru) Date: Mon, 17 Dec 2001 15:09:00 +0200 From: Ruslan Ermilov To: Greg Lehey Cc: Garance A Drosihn , Peter Wemm , Nik Clayton , Warner Losh , ache@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Changing 'man' to check alternate destination for 'cat' pages Message-ID: <20011217150900.E83850@sunbay.com> References: <20011212001610.9AEA739EA@overcee.netplex.com.au> <20011214112255.L3448@monorchid.lemis.com> <20011214101857.C35094@sunbay.com> <20011215110505.H85108@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011215110505.H85108@monorchid.lemis.com> User-Agent: Mutt/1.3.23i 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, Dec 15, 2001 at 11:05:05AM +1030, Greg Lehey wrote: > On Friday, 14 December 2001 at 10:18:58 +0200, Ruslan Ermilov wrote: > > On Fri, Dec 14, 2001 at 11:22:55AM +1030, Greg Lehey wrote: > >> On Thursday, 13 December 2001 at 0:01:03 -0500, Garance A Drosihn wrote: > >> Under these circumstances it's interesting to know which man pages you > >> have, and where they are. It also had a 'query' option: > >> > >> $ man -q ls > >> -r--r--r-- 1 root wheel 5361 Sat Sep 30 17:13:47 2000 /usr/share/man/man1/ls.1.gz? n > >> -rw-r--r-- 1 root wheel 3062 Thu Aug 18 21:45:13 1994 /usr/share/man/4.4BSD/cat1/ls.1.gz? n > >> -r--r--r-- 1 bin bin 9435 Tue Jan 21 00:17:30 1997 /usr/share/man/BSDI/man1/ls.1? n > >> -rw-r--r-- 1 root wheel 2271 Fri Aug 25 23:54:06 2000 /usr/share/man/linux/man1/ls.1.gz? n > >> -rw-r--r-- 1 root wheel 4903 Fri Dec 10 09:30:51 1999 /usr/share/man/linux/man1/ls.1? n > >> -rw-r--r-- 1 bin sys 3354 Fri Jun 27 10:05:42 1975 /usr/share/man/V6/man1/ls.1? > >> > > What are you looking for is already available as: > > > > $ MANPATH=/home/ru/mann:/usr/share/man man -a -w ls > > /home/ru/mann/man1/ls.1 > > /usr/share/man/cat1/ls.1.gz (source: /usr/share/man/man1/ls.1.gz) > > Not quite. That corresponds to my man -l command: it just lists them, > it doesn't give you the choice to select them or not. See the '? n' at > the end of most lines; you can also answer 'y' or 'q'. > You said "it's interesting to know which man pages you have, and where they are". The -a -w answers this question. Implementing a 'query' option should be trivial. > >> As regards the cat files, it seems to me that an obvious solution > >> would be to add a CATMAN environment variable which would specify the > >> location of the catman pages, and default to /usr/share/man/cat. > > > > Just having a CATMAN envariable is not enough, this would break many > > things. > > Yes, I was leaving that as an exercise for the implementor :-) > Hmm, on a second thought, using just one CATMAN variable might be enough, if treated a little different. If CATMAN is set to /var/man, man(1) will look for and create catpages in the /var/man/%manpath% directory. So, for /usr/share/man/man1/cat.1, the catman will be searched for as /var/man/usr/share/man/man1/cat.1. If this is sufficient, I can implement this very quickly. > > The "cat" feature of man(1) is insecure, and is probably going to be > > nuked after a release of 4.5. > > I think this is a pity. What's the rationale? > man(1) is currently set-UID "man", to create the catpages under /usr/share/man/cat?, which are owned by "man". There's the race exists, where user-supplied MANPATH (or -M path) can be used to overwrite /usr/share/man/cat? files. See bin/32791 for a full story. > > Having catpages: > > > > - is optional > > - can be configured at ``make world'' time > > Agreed. > > > - in different place can be achieved by using symlinks to cat?. > > Yes, but I'd consider this a workaround. > Agreed. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 17 6:37:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from watery.cc.kogakuin.ac.jp (watery.cc.kogakuin.ac.jp [133.80.152.80]) by hub.freebsd.org (Postfix) with ESMTP id 9D0D137B416; Mon, 17 Dec 2001 06:37:26 -0800 (PST) Received: from localhost (localhost [::1]) by watery.cc.kogakuin.ac.jp (8.11.5/8.11.5) with ESMTP id fBHEbPT08816; Mon, 17 Dec 2001 23:37:25 +0900 (JST) (envelope-from nyan@FreeBSD.org) Date: Mon, 17 Dec 2001 23:36:30 +0900 (JST) Message-Id: <20011217.233630.74667853.yosihiro@cc.kogakuin.ac.jp> To: ru@FreeBSD.org, kato@FreeBSD.org Cc: arch@FreeBSD.org Subject: Re: hw.machine on PC98 From: Takahashi Yoshihiro In-Reply-To: <20011214173056.A94075@sunbay.com> References: <200112141527.fBEFRF594757@freefall.freebsd.org> <20011214173056.A94075@sunbay.com> X-Mailer: Mew version 2.1 on Emacs 20.7 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <20011214173056.A94075@sunbay.com> Ruslan Ermilov writes: > What do you think about making hw.machine display "pc98" > on PC98's? *I* think that hw.machine should be "pc98" on PC-98. But, *even if* we change hw.machine for PC-98, we MUST implement '-p' option for uname(1) and use it instead of '-m' before change hw.machine. And then, there is an opinion that hw.machie for IBM PC/AT should be also changed to the other one (ex. x86pc). 'i386' does not represent IBM PC/AT architecture, but represent CPU architecture. Do you think about this? And, NetBSD/pc98 guys started on merging pc98 support to main tree. I heard that the machine name for NetBSD/i386 is changed (x86pc?) when NetBSD/pc98 is merged to main tree. If so, it is a convenience that both FreeBSD and NetBSD use the same machine name. --- TAKAHASHI Yoshihiro THE CENTER for INFORMATION SCIENCE, Kogakuin Univ. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 17 9:21:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 18CC837B417; Mon, 17 Dec 2001 09:21:11 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBHHL0333523; Mon, 17 Dec 2001 19:21:01 +0200 (EET) (envelope-from ru) Date: Mon, 17 Dec 2001 19:21:00 +0200 From: Ruslan Ermilov To: Takahashi Yoshihiro Cc: kato@FreeBSD.org, arch@FreeBSD.org Subject: Re: hw.machine on PC98 Message-ID: <20011217192100.A31562@sunbay.com> References: <200112141527.fBEFRF594757@freefall.freebsd.org> <20011214173056.A94075@sunbay.com> <20011217.233630.74667853.yosihiro@cc.kogakuin.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011217.233630.74667853.yosihiro@cc.kogakuin.ac.jp> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Dec 17, 2001 at 11:36:30PM +0900, Takahashi Yoshihiro wrote: > In article <20011214173056.A94075@sunbay.com> > Ruslan Ermilov writes: > > > What do you think about making hw.machine display "pc98" > > on PC98's? > > *I* think that hw.machine should be "pc98" on PC-98. > > But, *even if* we change hw.machine for PC-98, we MUST implement '-p' > option for uname(1) and use it instead of '-m' before change > hw.machine. > uname -m should print the value of hw.machine uname -p should print the value of hw.machine_arch This corresponds to the code in NetBSD. > And then, there is an opinion that hw.machie for IBM PC/AT should be > also changed to the other one (ex. x86pc). 'i386' does not represent > IBM PC/AT architecture, but represent CPU architecture. > > Do you think about this? > I don't think we should be SysV compatible here; my UnixWare box prints i386 for -m and x86at for -p. I don't like it. > And, NetBSD/pc98 guys started on merging pc98 support to main tree. I > heard that the machine name for NetBSD/i386 is changed (x86pc?) when > NetBSD/pc98 is merged to main tree. If so, it is a convenience that > both FreeBSD and NetBSD use the same machine name. > Last time I checked (about a half year ago), NetBSD had PC98 as i386/i386. Would be interesting to know if that has changed. I will probably add the -p option handling, if nobody beats me to it. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 17 15:55:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id E45B537B41A for ; Mon, 17 Dec 2001 15:55:46 -0800 (PST) Received: from dialup-209.247.139.120.dial1.sanjose1.level3.net ([209.247.139.120] helo=blossom.cjclark.org) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16G7bl-00066O-00 for arch@freebsd.org; Mon, 17 Dec 2001 15:55:46 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id fBHNtic20457 for arch@freebsd.org; Mon, 17 Dec 2001 15:55:44 -0800 (PST) (envelope-from cjc) Date: Mon, 17 Dec 2001 15:55:44 -0800 From: "Crist J . Clark" To: arch@freebsd.org Subject: Keeping pppd(8) Stuff in /etc/ppp Message-ID: <20011217155544.C19170@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-URL: http://people.freebsd.org/~cjc/ 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 There are two pppd(8) configuration files in /etc/ppp, ppp.deny and ppp.shells.sample. There are no other pppd(8) sample files (anywhere) that I can find. Is there any point of leaving these two lying around in /etc/ppp? I would expect that currently their primary function is to confuse ppp(8) users. On a side note, does anyone use pppd(8) anymore? Bitrot? Does it even work correctly anymore? -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 17 17: 2:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tatu.nendai.nagoya-u.ac.jp (tatu.nendai.nagoya-u.ac.jp [133.6.144.218]) by hub.freebsd.org (Postfix) with ESMTP id 181EE37B405; Mon, 17 Dec 2001 17:02:38 -0800 (PST) Received: from ushi.nendai.nagoya-u.ac.jp (ushi.nendai.nagoya-u.ac.jp [133.6.144.221]) by tatu.nendai.nagoya-u.ac.jp (8.11.6/3.7W) with ESMTP id fBI12aY26973; Tue, 18 Dec 2001 10:02:36 +0900 (JST) Message-Id: <200112180102.fBI12aY26973@tatu.nendai.nagoya-u.ac.jp> Received: by ushi.nendai.nagoya-u.ac.jp (8.11.4/3.7W) id fBI12aT30492; Tue, 18 Dec 2001 10:02:36 +0900 (JST) Date: Tue, 18 Dec 2001 10:02:31 +0900 (JST) To: ru@FreeBSD.org Cc: nyan@FreeBSD.org, arch@FreeBSD.org Subject: Re: hw.machine on PC98 From: KATO Takenori In-Reply-To: <20011217192100.A31562@sunbay.com> References: <20011214173056.A94075@sunbay.com> <20011217.233630.74667853.yosihiro@cc.kogakuin.ac.jp> <20011217192100.A31562@sunbay.com> X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Check: 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 From: Ruslan Ermilov Subject: Re: hw.machine on PC98 Date: Mon, 17 Dec 2001 19:21:00 +0200 > Last time I checked (about a half year ago), NetBSD had PC98 as > i386/i386. Would be interesting to know if that has changed. NetBSD/pc98 has not yet merged into the NetBSD tree and was released separatedly by NetBSD/pc98 developer like PC-98 version of FreeBSD. NetBSD/pc98 people think unames of PC-AT and PC-98 should be different from each other and `i386' is not suitable for showing PC-AT architecutre because `i386' shows architecutre of processors. They proposed changing i386 into something different from it before or during merging PC-98 codes. As far as I know, NetBSD people who try to merge NetBSD/pc98 agree with this. -----------------------------------------------+--------------------------+ KATO Takenori | FreeBSD | Center for Chronological Research, Nagoya Univ.| The power to serve! | Nagoya, 464-8602, Japan | http://www.FreeBSD.org/ | |http://www.jp.FreeBSD.org/| ++++ FreeBSD(98) 4.4R-Rev. 01 available! +==========================+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 17 18:12:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id C40F737B41C for ; Mon, 17 Dec 2001 18:12:33 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBI2CWa13998; Mon, 17 Dec 2001 19:12:32 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fBI2CUM81074; Mon, 17 Dec 2001 19:12:31 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112180212.fBI2CUM81074@harmony.village.org> To: Thomas Moestl Subject: Re: Please review: changes to MI bus code for sparc64 Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 13 Dec 2001 21:15:44 +0100." <20011213211544.A4747@crow.dom2ip.de> References: <20011213211544.A4747@crow.dom2ip.de> <20011213192033.A871@crow.dom2ip.de> <200112131901.fBDJ1hl02003@mass.dis.org> Date: Mon, 17 Dec 2001 19:12:30 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011213211544.A4747@crow.dom2ip.de> Thomas Moestl writes: : I'm not sure how this is meant. As I wrote, I am using it to manage virtual : DVMA memory, so I need to be able to allocate resources with given : alignment and boundary (to implement the busdma interface). Specifying : an alignment is already supported. The only method to enforce a : boundary at a higher level I could think of would be to try to adjust : the allocation, which would be a gross hack. I don't understand the difference between boundary and alignment. The resource manager already supports specifying an alignment in the flags argument. I know, I added it :-). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 17 18:14:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 5D43737B41D for ; Mon, 17 Dec 2001 18:14:24 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBI2EMa14006; Mon, 17 Dec 2001 19:14:23 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fBI2ELM81094; Mon, 17 Dec 2001 19:14:22 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112180214.fBI2ELM81094@harmony.village.org> To: Terry Lambert Subject: Re: Please review: changes to MI bus code for sparc64 Cc: Thomas Moestl , arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 13 Dec 2001 14:32:16 PST." <3C192C70.9A79B3C5@mindspring.com> References: <3C192C70.9A79B3C5@mindspring.com> <20011213192033.A871@crow.dom2ip.de> <3C18F78D.C537D487@mindspring.com> <20011213201213.B871@crow.dom2ip.de> Date: Mon, 17 Dec 2001 19:14:21 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <3C192C70.9A79B3C5@mindspring.com> Terry Lambert writes: : > > The PCI_BROKEN_INTPIN/PCI_INTLINE_0_BAD seem to be the same thing; : : Still agree with Mike. PCI_INTLINE_0_BAD is already needed by i386 port. There are a number of broken bioses that do this. All of them impact the CardBus bridge, so there is a hack in the current code for both 255 and 0. I think that the right way to do this is to see intline 0 on the initial read of config space, and quietly changing it to 255. There are many places in the code we don't check, but should... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 17 18:20: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id C98FA37B41D; Mon, 17 Dec 2001 18:20:06 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBI2K5a14036; Mon, 17 Dec 2001 19:20:05 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fBI2K5M81153; Mon, 17 Dec 2001 19:20:05 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112180220.fBI2K5M81153@harmony.village.org> To: Thomas Moestl Subject: Re: Please review: changes to MI bus code for sparc64 Cc: Mike Smith , arch@FreeBSD.ORG In-reply-to: Your message of "Sun, 16 Dec 2001 02:33:21 +0100." <20011216023321.C458@crow.dom2ip.de> References: <20011216023321.C458@crow.dom2ip.de> <200112140028.fBE0Sol04630@mass.dis.org> Date: Mon, 17 Dec 2001 19:20:05 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011216023321.C458@crow.dom2ip.de> Thomas Moestl writes: : - remove PCI_INTLINE_0_BAD : - move the code for PCI_BROKEN_INTPIN to MD code, and use a quirk : table to identify the devices that need this fixup (I don't really : like this change, as I think it is not totally unlikely that the : device in question may also be used for other architectures; it is : not really specific to sparc64) I didn't see this in the patch... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 17 18:36:23 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 14D2737B41B for ; Mon, 17 Dec 2001 18:36:20 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fBI2aHM39997; Mon, 17 Dec 2001 21:36:17 -0500 (EST) (envelope-from wollman) Date: Mon, 17 Dec 2001 21:36:17 -0500 (EST) From: Garrett Wollman Message-Id: <200112180236.fBI2aHM39997@khavrinen.lcs.mit.edu> To: imp@harmony.village.org Subject: Re: Please review: changes to MI bus code for sparc64 In-Reply-To: <200112180212.fBI2CUM81074@harmony.village.org> References: <20011213211544.A4747@crow.dom2ip.de> <20011213192033.A871@crow.dom2ip.de> <200112131901.fBDJ1hl02003@mass.dis.org> <20011213211544.A4747@crow.dom2ip.de> Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <200112180212.fBI2CUM81074@harmony.village.org> you write: >I don't understand the difference between boundary and alignment. A boundary is a locus which an allocation must not cross. Consider, for example, the crufty old ISA DMA hardware: 16-bit transfers need only 16-bit alignment, but must not cross a 64-kbyte ``page'' boundary, because the address-generation logic was kluged out of a 16-bit DMA controller and an 8-bit latch. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 17 18:48:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id AF1BE37B41D for ; Mon, 17 Dec 2001 18:48:47 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBI2mka14125; Mon, 17 Dec 2001 19:48:46 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fBI2mjM81380; Mon, 17 Dec 2001 19:48:45 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112180248.fBI2mjM81380@harmony.village.org> To: Garrett Wollman Subject: Re: Please review: changes to MI bus code for sparc64 Cc: arch@FreeBSD.org In-reply-to: Your message of "Mon, 17 Dec 2001 21:36:17 EST." <200112180236.fBI2aHM39997@khavrinen.lcs.mit.edu> References: <200112180236.fBI2aHM39997@khavrinen.lcs.mit.edu> <20011213211544.A4747@crow.dom2ip.de> <20011213192033.A871@crow.dom2ip.de> <200112131901.fBDJ1hl02003@mass.dis.org> <20011213211544.A4747@crow.dom2ip.de> Date: Mon, 17 Dec 2001 19:48:45 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200112180236.fBI2aHM39997@khavrinen.lcs.mit.edu> Garrett Wollman writes: : In article <200112180212.fBI2CUM81074@harmony.village.org> you write: : >I don't understand the difference between boundary and alignment. : : A boundary is a locus which an allocation must not cross. Consider, : for example, the crufty old ISA DMA hardware: 16-bit transfers need : only 16-bit alignment, but must not cross a 64-kbyte ``page'' : boundary, because the address-generation logic was kluged out of a : 16-bit DMA controller and an 8-bit latch. Ah. That makes perfect sense. It doesn't need 64kbyte alignment, but must not cross a 64kbyte boundary... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 17 23:37:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay1.macomnet.ru (relay1.macomnet.ru [195.128.64.10]) by hub.freebsd.org (Postfix) with ESMTP id 4876237B41F; Mon, 17 Dec 2001 23:37:25 -0800 (PST) Received: from news1.macomnet.ru (maxim@news1.macomnet.ru [195.128.64.14]) by relay1.macomnet.ru (8.11.3/8.11.3) with ESMTP id fBI7bLc2171540; Tue, 18 Dec 2001 10:37:22 +0300 (MSK) Date: Tue, 18 Dec 2001 10:37:21 +0300 (MSK) From: Maxim Konovalov To: "Crist J . Clark" Cc: arch@FreeBSD.ORG Subject: Re: Keeping pppd(8) Stuff in /etc/ppp In-Reply-To: <20011217155544.C19170@blossom.cjclark.org> Message-ID: <20011218103547.N70503-100000@news1.macomnet.ru> 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 15:55-0800, Dec 17, 2001, Crist J . Clark wrote: > There are two pppd(8) configuration files in /etc/ppp, ppp.deny and > ppp.shells.sample. There are no other pppd(8) sample files (anywhere) > that I can find. Is there any point of leaving these two lying around > in /etc/ppp? I would expect that currently their primary function is > to confuse ppp(8) users. > > On a side note, does anyone use pppd(8) anymore? Bitrot? Does it even At least I do. > work correctly anymore? It works for me. -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: maxim@macomnet.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 18 0:32:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 121C937B405; Tue, 18 Dec 2001 00:32:13 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBI8WCa15159; Tue, 18 Dec 2001 01:32:12 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fBI8W5M83297; Tue, 18 Dec 2001 01:32:11 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112180832.fBI8W5M83297@harmony.village.org> To: Paul Richards Subject: Re: Anybody working on devd? Cc: Mike Smith , arch@FreeBSD.ORG In-reply-to: Your message of "Sat, 15 Dec 2001 03:14:55 GMT." <12520000.1008386095@lobster.originative.co.uk> References: <12520000.1008386095@lobster.originative.co.uk> <200111272301.fARN1nj04294@mass.dis.org> Date: Tue, 18 Dec 2001 01:32:05 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <12520000.1008386095@lobster.originative.co.uk> Paul Richards writes: : If eventd is a generic handler for all kernel events then all sorts of : things can be hooked into it. What would be needed is an api call in the : kernel to signal an event and then any part of the kernel would have a : mechanism to cause an userland action to occur. I fear this will be too general a daemon to every be written. There are too many modules that will goo up the works. But I suppose that someone will prove me wrong... : I think focussing the design around device type events would be a big : mistake in the long run. I agree, that's why the lowest layers of what we've been working on aren't device centric. At least the /dev/event that I've been working on.... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 18 2:26: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hal-4.inet.it (hal-4.inet.it [213.92.5.23]) by hub.freebsd.org (Postfix) with ESMTP id 9000737B41A for ; Tue, 18 Dec 2001 02:25:58 -0800 (PST) Received: (from root@localhost) by hal-4.inet.it (8.11.1/8.11.1) id fBIAPvw98282 for ; Tue, 18 Dec 2001 11:25:57 +0100 Received: from acampi.inet.it(213.92.1.165) by hal-4.inet.it via I-SMTP-4.0.3-100 id s-213.92.1.165-gB6tPj; Tue Dec 18 11:25:56 2001 Received: from webcom.it (brian.inet.it [213.92.1.190]) by acampi.inet.it (Postfix) with SMTP id 6222915534 for ; Tue, 18 Dec 2001 11:25:55 +0100 (CET) Received: (qmail 5288 invoked by uid 1000); 18 Dec 2001 10:25:54 -0000 Date: Tue, 18 Dec 2001 11:25:54 +0100 From: Andrea Campi To: Terry Lambert Cc: Bakul Shah , freebsd-arch@FreeBSD.ORG Subject: Re: Real world Root Resizing (was Re: Proposed auto-sizing patch ... Message-ID: <20011218102553.GA4617@webcom.it> References: <200112092050.PAA26830@glatton.cnchost.com> <20011212162203.GA9595@webcom.it> <3C17A3A3.A439BE21@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C17A3A3.A439BE21@mindspring.com> User-Agent: Mutt/1.3.24i X-Echelon: BND CIA NSA Mossad KGB MI6 IRA detonator nuclear assault strike 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, Dec 12, 2001 at 10:36:19AM -0800, Terry Lambert wrote: > This comes up once in a while, so it's worth treating, once in a while... [Interesting explanation trimmed] Terry, thanks for the explanation, even if I knew how it worked (though in lesser details). However, I still think it's useful knowing that if you really really need to extend your / *NOW*, you can do it easily. Anything more is appreciated but this is what you mostly need to know when the shit hits the fan... P.S. of course I resized my swap partition before! Bye, Andrea -- Speak softly and carry a cellular phone. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 18 6:24:57 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 131FB37B41C for ; Tue, 18 Dec 2001 06:24:53 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id BAA00908; Wed, 19 Dec 2001 01:24:41 +1100 Date: Wed, 19 Dec 2001 01:25:58 +1100 (EST) From: Bruce Evans X-X-Sender: To: Luigi Rizzo Cc: Subject: Re: swi_net In-Reply-To: <20011213091957.B39991@iguana.aciri.org> Message-ID: <20011219010205.P4481-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 13 Dec 2001, Luigi Rizzo wrote: > we have 2 slightly different versions of swi_net in -current and > -stable, listed below (STABLE/Alpha is approximately the same as > CURRENT). > > I like a lot the semantics of the version in -stable, because it > enforces a strict priority in the execution of soft handlers > (remember they are not preemptable), even when schednetisr(FOO) is > called within one of the handlers. I prefer the -stable version too, but I think the strict priority doesn't make much difference. Anyway, it's not completely strict, because lower priority handlers are not preemptable. > However I was wondering if there are objections in changing the > first line of the CURRENT version in > > for (; bits = atomic_readandclear_int(&netisr); ) > > so that we process all pending handlers without exiting from the > function and have a closer approximation of what STABLE does. It can't hurt, but I think it is only a tiny improvement. If another netisr is scheduled after the above atomic operation, then swi_net() will always be called again (from ithread_loop()) soon after it returns. We can't even avoid the overhead for the loop and the call unless several calls are coalesced. Other overheads in -current are relatively huge. > --------- u2/HEAD/src/sys/kern/kern_intr.c ----------------- > static void > swi_net(void *dummy) > { > u_int bits; > int i; > > bits = atomic_readandclear_int(&netisr); > while ((i = ffs(bits)) != 0) { > i--; > if (netisrs[i] != NULL) > netisrs[i](); > else > printf("swi_net: unregistered isr number: %d.\n", i); > bits &= ~(1 << i); > } > } > > > ----- STABLE/src/sys/i386/isa/ipl.s ----- > > swi_net: > MCOUNT > bsfl _netisr,%eax > je swi_net_done > swi_net_more: > btrl %eax,_netisr > jnc swi_net_next > call *_netisrs(,%eax,4) > swi_net_next: > bsfl _netisr,%eax > jne swi_net_more > swi_net_done: > ret -current is also missing the optimization of initializing the table with dummies so that it doesn't need to check the pointer. Unexpected netisrs could be handled even better by panicing for them. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 18 8:50: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (66-188-92-95.mad.wi.charter.com [66.188.92.95]) by hub.freebsd.org (Postfix) with ESMTP id CC07737B41A for ; Tue, 18 Dec 2001 08:49:57 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.6/8.11.6) id fBIGloX32070; Tue, 18 Dec 2001 10:47:50 -0600 (CST) (envelope-from jlemon) Date: Tue, 18 Dec 2001 10:47:50 -0600 From: Jonathan Lemon To: Bruce Evans Cc: Luigi Rizzo , arch@FreeBSD.ORG Subject: Re: swi_net Message-ID: <20011218104750.M377@prism.flugsvamp.com> References: <20011213091957.B39991@iguana.aciri.org> <20011219010205.P4481-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20011219010205.P4481-100000@gamplex.bde.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Dec 19, 2001 at 01:25:58AM +1100, Bruce Evans wrote: > On Thu, 13 Dec 2001, Luigi Rizzo wrote: > > > we have 2 slightly different versions of swi_net in -current and > > -stable, listed below (STABLE/Alpha is approximately the same as > > CURRENT). > > > > I like a lot the semantics of the version in -stable, because it > > enforces a strict priority in the execution of soft handlers > > (remember they are not preemptable), even when schednetisr(FOO) is > > called within one of the handlers. > > I prefer the -stable version too, but I think the strict priority > doesn't make much difference. Anyway, it's not completely strict, > because lower priority handlers are not preemptable. I'm planning on revising swi_net so that it is possible to run all network processing under the device interrupt instead of deferring things to a netisr(). This also has the advantage of eliminating all ipintr() style loops, as packet dequeueing is done in a centralized place, and makes it easier to bound the amount of work which is done. (Actually, the interface queues and netisrs are not completely gone; it is possible to switch back and forth dynamically) I have this working on -stable (the more difficult of the two, IMO) and it should be easy to extend this to -current. This will permit removal of Luigi's ether_pollmore() and associated cruft, since all packet handling relating to polling would be run in a single netisr 'thread'. -- Jonathan PS: > -current is also missing the optimization of initializing the table with > dummies so that it doesn't need to check the pointer. Unexpected netisrs > could be handled even better by panicing for them. Yeah, I saw that. However, panic'ing in a netisr (which I did several times over the weekend) appears to produce a stream of faults, eventually wedging the box so that it needs a powercycle. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 18 10:20:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id E668737B417 for ; Tue, 18 Dec 2001 10:20:09 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011218182009.JKKA6450.rwcrmhc52.attbi.com@InterJet.elischer.org>; Tue, 18 Dec 2001 18:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA40400; Tue, 18 Dec 2001 10:19:25 -0800 (PST) Date: Tue, 18 Dec 2001 10:19:23 -0800 (PST) From: Julian Elischer To: Jonathan Lemon Cc: Bruce Evans , Luigi Rizzo , arch@FreeBSD.ORG Subject: Re: swi_net In-Reply-To: <20011218104750.M377@prism.flugsvamp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Netgraph in -current uses netisr routines to run its dequeueing system (different to -stable which uses it as a netisr from interrupt scope as per normal). On Tue, 18 Dec 2001, Jonathan Lemon wrote: > On Wed, Dec 19, 2001 at 01:25:58AM +1100, Bruce Evans wrote: > > On Thu, 13 Dec 2001, Luigi Rizzo wrote: > > > > > we have 2 slightly different versions of swi_net in -current and > > > -stable, listed below (STABLE/Alpha is approximately the same as > > > CURRENT). > > > > > > I like a lot the semantics of the version in -stable, because it > > > enforces a strict priority in the execution of soft handlers > > > (remember they are not preemptable), even when schednetisr(FOO) is > > > called within one of the handlers. > > > > I prefer the -stable version too, but I think the strict priority > > doesn't make much difference. Anyway, it's not completely strict, > > because lower priority handlers are not preemptable. > > I'm planning on revising swi_net so that it is possible to run all > network processing under the device interrupt instead of deferring > things to a netisr(). This also has the advantage of eliminating all > ipintr() style loops, as packet dequeueing is done in a centralized > place, and makes it easier to bound the amount of work which is done. > (Actually, the interface queues and netisrs are not completely gone; > it is possible to switch back and forth dynamically) > > I have this working on -stable (the more difficult of the two, IMO) > and it should be easy to extend this to -current. > > This will permit removal of Luigi's ether_pollmore() and associated > cruft, since all packet handling relating to polling would be run in > a single netisr 'thread'. > -- > Jonathan > > > PS: > > > -current is also missing the optimization of initializing the table with > > dummies so that it doesn't need to check the pointer. Unexpected netisrs > > could be handled even better by panicing for them. > > Yeah, I saw that. However, panic'ing in a netisr (which I did several > times over the weekend) appears to produce a stream of faults, eventually > wedging the box so that it needs a powercycle. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 18 10:23:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id 9B26537B41A for ; Tue, 18 Dec 2001 10:23:05 -0800 (PST) Received: (qmail 10009 invoked by uid 0); 18 Dec 2001 18:23:04 -0000 Received: from pd9538aee.dip.t-dialin.net (HELO forge.local) (217.83.138.238) by mail.gmx.net (mp013-rz3) with SMTP; 18 Dec 2001 18:23:04 -0000 Received: from tmm by forge.local with local (Exim 3.30 #1) id 16GOtW-0001Kj-00; Tue, 18 Dec 2001 19:23:14 +0100 Date: Tue, 18 Dec 2001 19:23:14 +0100 From: Thomas Moestl To: Warner Losh Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: Please review: changes to MI bus code for sparc64 Message-ID: <20011218192314.A441@crow.dom2ip.de> Mail-Followup-To: Warner Losh , Mike Smith , arch@FreeBSD.ORG References: <20011216023321.C458@crow.dom2ip.de> <200112140028.fBE0Sol04630@mass.dis.org> <20011216023321.C458@crow.dom2ip.de> <200112180220.fBI2K5M81153@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112180220.fBI2K5M81153@harmony.village.org>; from imp@harmony.village.org on Mon, Dec 17, 2001 at 07:20:05PM -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 Mon, 2001/12/17 at 19:20:05 -0700, Warner Losh wrote: > In message <20011216023321.C458@crow.dom2ip.de> Thomas Moestl writes: > : - remove PCI_INTLINE_0_BAD > : - move the code for PCI_BROKEN_INTPIN to MD code, and use a quirk > : table to identify the devices that need this fixup (I don't really > : like this change, as I think it is not totally unlikely that the > : device in question may also be used for other architectures; it is > : not really specific to sparc64) > > I didn't see this in the patch... These are the deltas against the previous patch that would add these two options. The change to sparc64 MD code I mentioned are also not present in the patch. It just adds check for every config space access to the intpin register returning 0 that looks up the device in a quirk table, and will return a (bogus) value of 1 if the device is found to be quirky (the value does not matter since the interrupt is alredy routed for these devices). - thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 18 10:59:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (66-188-92-95.mad.wi.charter.com [66.188.92.95]) by hub.freebsd.org (Postfix) with ESMTP id A42AF37B405 for ; Tue, 18 Dec 2001 10:59:46 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.6/8.11.6) id fBIIwGP36832; Tue, 18 Dec 2001 12:58:16 -0600 (CST) (envelope-from jlemon) Date: Tue, 18 Dec 2001 12:58:16 -0600 From: Jonathan Lemon To: Julian Elischer Cc: Jonathan Lemon , Bruce Evans , Luigi Rizzo , arch@FreeBSD.ORG Subject: Re: swi_net Message-ID: <20011218125816.N377@prism.flugsvamp.com> References: <20011218104750.M377@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Dec 18, 2001 at 10:19:23AM -0800, Julian Elischer wrote: > Netgraph in -current uses netisr routines to run its > dequeueing system (different to -stable which uses it as a netisr > from interrupt scope as per normal). Thats fine - I'm not removing netisrs completely. I just wanted to add the ability to do direct dispatching as well. This is useful for non-interrupt driven execution, since the packet would get pushed through the stack as far as possible. Also, I wasn't able to remove ngintr() from -stable, since it uses non-standard queue handling. There are a few other cases like this as well; they are still handled in the normal fashion. One thing to note is that so far, I haven't seen any benefit of using a direct dispatch over the netisr approach; but then again, it may be that I'm simply not stressing my system enough. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 18 13: 8:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id A6D5137B419; Tue, 18 Dec 2001 13:08:17 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id NAA06296; Tue, 18 Dec 2001 13:08:17 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda06294; Tue Dec 18 13:08:12 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.6/8.9.1) id fBIL87D31904; Tue, 18 Dec 2001 13:08:07 -0800 (PST) Received: from UNKNOWN(10.1.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdT31898; Tue Dec 18 13:07:49 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.6/8.9.1) id fBIL7nJ23781; Tue, 18 Dec 2001 13:07:49 -0800 (PST) Message-Id: <200112182107.fBIL7nJ23781@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdp23772; Tue Dec 18 13:06:59 2001 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: "Crist J . Clark" Cc: arch@FreeBSD.ORG Subject: Re: Keeping pppd(8) Stuff in /etc/ppp In-reply-to: Your message of "Mon, 17 Dec 2001 15:55:44 PST." <20011217155544.C19170@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Dec 2001 13:06:59 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011217155544.C19170@blossom.cjclark.org>, "Crist J . Clark" write s: > There are two pppd(8) configuration files in /etc/ppp, ppp.deny and > ppp.shells.sample. There are no other pppd(8) sample files (anywhere) > that I can find. Is there any point of leaving these two lying around > in /etc/ppp? I would expect that currently their primary function is > to confuse ppp(8) users. > > On a side note, does anyone use pppd(8) anymore? Bitrot? Does it even > work correctly anymore? /me puts up his hand. I use it to dial into work on occasion when my cable provider's network has problems. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Email: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD Ministry of Management Services Province of BC FreeBSD UNIX: cy@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 18 13:42: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 7E6FC37B416 for ; Tue, 18 Dec 2001 13:41:59 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fBILfoe89350; Tue, 18 Dec 2001 13:41:50 -0800 (PST) (envelope-from rizzo) Date: Tue, 18 Dec 2001 13:41:50 -0800 From: Luigi Rizzo To: Jonathan Lemon Cc: Bruce Evans , arch@FreeBSD.ORG Subject: Re: swi_net Message-ID: <20011218134149.A89299@iguana.aciri.org> References: <20011213091957.B39991@iguana.aciri.org> <20011219010205.P4481-100000@gamplex.bde.org> <20011218104750.M377@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011218104750.M377@prism.flugsvamp.com> User-Agent: Mutt/1.3.23i 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'm planning on revising swi_net so that it is possible to run all > network processing under the device interrupt instead of deferring > things to a netisr(). This also has the advantage of eliminating all The thing is, some processing can be quite long (e.g. IPSec, very long ipfw rulesets, multicast when you have a large number of sockets trying to fetch the packet, etc.), so it is not 100% desirable having it run in interrupt context. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 18 13:54:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 4973937B417 for ; Tue, 18 Dec 2001 13:54:15 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fBILs7V89423; Tue, 18 Dec 2001 13:54:07 -0800 (PST) (envelope-from rizzo) Date: Tue, 18 Dec 2001 13:54:07 -0800 From: Luigi Rizzo To: Jonathan Lemon Cc: Julian Elischer , Bruce Evans , arch@FreeBSD.ORG Subject: Re: swi_net Message-ID: <20011218135407.B89299@iguana.aciri.org> References: <20011218104750.M377@prism.flugsvamp.com> <20011218125816.N377@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011218125816.N377@prism.flugsvamp.com> User-Agent: Mutt/1.3.23i 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 > One thing to note is that so far, I haven't seen any benefit of using > a direct dispatch over the netisr approach; but then again, it may be > that I'm simply not stressing my system enough. Direct dispatch is typically useful under heavy load, because: * it reduces the chance of livelock when you have lots of traffic coming from an interface (which gets queued without giving the netisr a chance to run); * as a side effect, it also works as a form of interrupt mitigation, because you stay longer in the ISR and so you might serve more packets on a single interrupt. As a drawback, if your packet processing time is longer than the packet interarrival time (which is sometimes possible under attack), you might remain in your ISR forever, literally. Just as a side note, the polling code deals very well with the above problems, and is not subject to the last one. I have been against deferred processing for a long time, but recently have slightly changed my mind because i now see a reason in it (mentioned in the previous msg, re. expensive processing), as long as you can reserve some amount of CPU to the deferred processing, and you make sure that interfaces are served in a fair way (early versions of the polling code had this problem, fetching large chunks of packets from the first interface and filling up the intermediate queue. The version in current has not, because ether_pollmore() among other things makes sure that interfaces are served in a round-robin fashion and with short bursts of packets before calling the netisr). cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 18 13:58: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id C4D6637B41D for ; Tue, 18 Dec 2001 13:57:51 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 5346F81E0C; Tue, 18 Dec 2001 15:57:46 -0600 (CST) Date: Tue, 18 Dec 2001 15:57:46 -0600 From: Alfred Perlstein To: Luigi Rizzo Cc: Jonathan Lemon , Julian Elischer , Bruce Evans , arch@FreeBSD.ORG Subject: Re: swi_net Message-ID: <20011218155746.K59831@elvis.mu.org> References: <20011218104750.M377@prism.flugsvamp.com> <20011218125816.N377@prism.flugsvamp.com> <20011218135407.B89299@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011218135407.B89299@iguana.aciri.org>; from rizzo@aciri.org on Tue, Dec 18, 2001 at 01:54:07PM -0800 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 * Luigi Rizzo [011218 15:54] wrote: > > One thing to note is that so far, I haven't seen any benefit of using > > a direct dispatch over the netisr approach; but then again, it may be > > that I'm simply not stressing my system enough. > > Direct dispatch is typically useful under heavy load, because: > > * it reduces the chance of livelock when you have lots of traffic > coming from an interface (which gets queued without giving the > netisr a chance to run); > > * as a side effect, it also works as a form of interrupt mitigation, > because you stay longer in the ISR and so you might serve more > packets on a single interrupt. > > As a drawback, if your packet processing time is longer than > the packet interarrival time (which is sometimes possible under > attack), you might remain in your ISR forever, literally. > > Just as a side note, the polling code deals very well with the above > problems, and is not subject to the last one. > > I have been against deferred processing for a long time, but recently > have slightly changed my mind because i now see a reason in it (mentioned in > the previous msg, re. expensive processing), as long as you can reserve > some amount of CPU to the deferred processing, and you make sure that > interfaces are served in a fair way (early versions of the polling code had > this problem, fetching large chunks of packets from the first interface > and filling up the intermediate queue. The version in current has not, > because ether_pollmore() among other things makes sure that interfaces > are served in a round-robin fashion and with short bursts of packets > before calling the netisr). It makes sense to switch to direct dispatch when the queue fills as you'll leave the hardware interrupt blocked and then be able to process your data. This doesn't mean that you'll be able to run userland code, but at least packets will move and not just be dropped from the queue. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 18 14:10: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id EE6F437B416 for ; Tue, 18 Dec 2001 14:10:05 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fBIM9vx89571; Tue, 18 Dec 2001 14:09:57 -0800 (PST) (envelope-from rizzo) Date: Tue, 18 Dec 2001 14:09:57 -0800 From: Luigi Rizzo To: Alfred Perlstein Cc: Jonathan Lemon , Julian Elischer , Bruce Evans , arch@FreeBSD.ORG Subject: Re: swi_net Message-ID: <20011218140957.D89299@iguana.aciri.org> References: <20011218104750.M377@prism.flugsvamp.com> <20011218125816.N377@prism.flugsvamp.com> <20011218135407.B89299@iguana.aciri.org> <20011218155746.K59831@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011218155746.K59831@elvis.mu.org> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Dec 18, 2001 at 03:57:46PM -0600, Alfred Perlstein wrote: ... > > I have been against deferred processing for a long time, but recently > > have slightly changed my mind because i now see a reason in it (mentioned in > > the previous msg, re. expensive processing), as long as you can reserve > > some amount of CPU to the deferred processing, and you make sure that ... > It makes sense to switch to direct dispatch when the queue fills as > you'll leave the hardware interrupt blocked and then be able to > process your data. it's a slipperly slope. Once you reach that stage, you are running out of CPU and you'd really want to drop things as early as possible until you go back to a bearable load level. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 18 14:48:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from technokratis.com (modemcable099.144-201-24.mtl.mc.videotron.ca [24.201.144.99]) by hub.freebsd.org (Postfix) with ESMTP id DDC0437B41A for ; Tue, 18 Dec 2001 14:48:27 -0800 (PST) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id fBIMsMK37664; Tue, 18 Dec 2001 17:54:22 -0500 (EST) (envelope-from bmilekic) Date: Tue, 18 Dec 2001 17:54:21 -0500 From: Bosko Milekic To: Luigi Rizzo Cc: Jonathan Lemon , Bruce Evans , arch@FreeBSD.ORG Subject: Re: swi_net Message-ID: <20011218175421.A37567@technokratis.com> References: <20011213091957.B39991@iguana.aciri.org> <20011219010205.P4481-100000@gamplex.bde.org> <20011218104750.M377@prism.flugsvamp.com> <20011218134149.A89299@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011218134149.A89299@iguana.aciri.org>; from rizzo@aciri.org on Tue, Dec 18, 2001 at 01:41:50PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Dec 18, 2001 at 01:41:50PM -0800, Luigi Rizzo wrote: > > I'm planning on revising swi_net so that it is possible to run all > > network processing under the device interrupt instead of deferring > > things to a netisr(). This also has the advantage of eliminating all > > The thing is, some processing can be quite long (e.g. IPSec, very > long ipfw rulesets, multicast when you have a large number of > sockets trying to fetch the packet, etc.), so it is not 100% > desirable having it run in interrupt context. I think it's good to have the possibility of processing in interrupt context while, at the same time, being able to easily turn it off for situations like the ones you bring up. While we're on the subject, running the stack in interrupt context seems to be an attempt to, mainly, remedy the load problem where we have a lot of interrupts and the soft int thread doesn't even get a chance to run... so we have a sort of livelock situation. For the cases that you describe, how effective do you think it would be to do as we presently do and just schedule the soft net thread to run, return from the interrupt but, when under load figure out a way to bump up the priority of the softnetisr thread enough so that it does get a chance to run? > cheers > luigi > -----------------------------------+------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > Mobile +39-347-0373137 > -----------------------------------+------------------------------------- -- Bosko Milekic bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 18 14:56: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 5AA0F37B426 for ; Tue, 18 Dec 2001 14:55:52 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fBIMtcg89913; Tue, 18 Dec 2001 14:55:38 -0800 (PST) (envelope-from rizzo) Date: Tue, 18 Dec 2001 14:55:38 -0800 From: Luigi Rizzo To: Bosko Milekic Cc: Jonathan Lemon , Bruce Evans , arch@FreeBSD.ORG Subject: Re: swi_net Message-ID: <20011218145538.A89864@iguana.aciri.org> References: <20011213091957.B39991@iguana.aciri.org> <20011219010205.P4481-100000@gamplex.bde.org> <20011218104750.M377@prism.flugsvamp.com> <20011218134149.A89299@iguana.aciri.org> <20011218175421.A37567@technokratis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011218175421.A37567@technokratis.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Dec 18, 2001 at 05:54:21PM -0500, Bosko Milekic wrote: ... > While we're on the subject, running the stack in interrupt context > seems to be an attempt to, mainly, remedy the load problem where we have > a lot of interrupts and the soft int thread doesn't even get a chance to > run... so we have a sort of livelock situation. For the cases that you yes that was the part I was in favour with... > describe, how effective do you think it would be to do as we presently > do and just schedule the soft net thread to run, return from the > interrupt but, when under load figure out a way to bump up the priority > of the softnetisr thread enough so that it does get a chance to run? the polling code in -current tries to do exacly this, and it is reasonbly self-adjusting: it grabs a small amount of packets from the interfaces, then processes the netisr to completion, then grabs more packets, and so on. Additionally, it guarantees that user tasks have a fraction of the CPU available, so if this traffic involves userland processing at least we avoid complete livelock. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 18 15:10: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (66-188-92-95.mad.wi.charter.com [66.188.92.95]) by hub.freebsd.org (Postfix) with ESMTP id C09AC37B405 for ; Tue, 18 Dec 2001 15:09:57 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.6/8.11.6) id fBIN8HU45970; Tue, 18 Dec 2001 17:08:17 -0600 (CST) (envelope-from jlemon) Date: Tue, 18 Dec 2001 17:08:17 -0600 From: Jonathan Lemon To: Luigi Rizzo Cc: Bosko Milekic , Jonathan Lemon , Bruce Evans , arch@FreeBSD.ORG Subject: Re: swi_net Message-ID: <20011218170817.P377@prism.flugsvamp.com> References: <20011213091957.B39991@iguana.aciri.org> <20011219010205.P4481-100000@gamplex.bde.org> <20011218104750.M377@prism.flugsvamp.com> <20011218134149.A89299@iguana.aciri.org> <20011218175421.A37567@technokratis.com> <20011218145538.A89864@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20011218145538.A89864@iguana.aciri.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 Tue, Dec 18, 2001 at 02:55:38PM -0800, Luigi Rizzo wrote: > On Tue, Dec 18, 2001 at 05:54:21PM -0500, Bosko Milekic wrote: > ... > > While we're on the subject, running the stack in interrupt context > > seems to be an attempt to, mainly, remedy the load problem where we have > > a lot of interrupts and the soft int thread doesn't even get a chance to > > run... so we have a sort of livelock situation. For the cases that you > > yes that was the part I was in favour with... > > > describe, how effective do you think it would be to do as we presently > > do and just schedule the soft net thread to run, return from the > > interrupt but, when under load figure out a way to bump up the priority > > of the softnetisr thread enough so that it does get a chance to run? > > the polling code in -current tries to do exacly this, and it is > reasonbly self-adjusting: it grabs a small amount of packets from > the interfaces, then processes the netisr to completion, then grabs > more packets, and so on. Yes - this is essentially what the code is cleaning up. Instead of grabbing packets from the interface, putting them on the queue, then running the netisr, it gets the packet from the queue and does the processing (in one step). So this removes the need for ether_pollmore(); which is really there because of the intermediate queue limits, and because we want to try and account for the time spent doing packet processing. > Additionally, it guarantees that user tasks have a fraction of > the CPU available, so if this traffic involves userland processing > at least we avoid complete livelock. Yes - with the direct dispatch loop, we also have the ability to measure how long it takes to process each packet, because the "for (;;)" loop which completely drained the protocol queue is gone, and moved up into a central loop. This makes it easier to account for processing time. -- Joanthan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 18 15:20: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id E60D837B416; Tue, 18 Dec 2001 15:20:03 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id AAA01287; Wed, 19 Dec 2001 00:20:03 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.11.6/8.11.6) id fBIMuk001274; Tue, 18 Dec 2001 23:56:46 +0100 (MET) (envelope-from j) Date: Tue, 18 Dec 2001 23:56:46 +0100 (MET) Message-Id: <200112182256.fBIMuk001274@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 1.0b.1 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: <20011218200918.A14073@sunbay.com> <20011218204720.B18124@sunbay.com> From: j@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: Recent fdc(4) commit broke Alpha kernels X-Original-Newsgroups: local.freebsd.current To: freebsd-current@freebsd.org Cc: arch@freebsd.org 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 Ruslan Ermilov wrote: > Oops sorry, that was Joerg. It's fixed now, although i'm still not convinces that using __i386__ is the right thing. If our defines several constants for _MACHINE_ARCH, they should all be distint for the various machines. As it seems now, all of them probably define the same or whatever, so we end up in _MACHINE_ARCH@i386 == _MACHINE_ARCH@alpha == _MACHINE_ARCH@IA64 etc. We could as well delete those lines from then since they are pretty useless in that case. And no, MACHINE_ARCH (without the leading underscore) cannot be used either since it defines a string constant that can't be used in a cpp conditional. Cc goes to arch@freebsd.org: what is the politically correct way to distinguish a PC-type architecture (in that case one that uses a PC-style RTC memory to store configuration information) from another architecture that uses IA32 CPUs (like PC98, although they aren't using /sys/isa/fd.c right now)? -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 18 16:55: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.trit.org (bazooka.trit.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id C309737B417; Tue, 18 Dec 2001 16:54:12 -0800 (PST) Received: by bazooka.trit.org (Postfix, from userid 1000) id 54A833E2F; Wed, 19 Dec 2001 00:54:12 +0000 (UTC) Received: from bazooka (localhost [127.0.0.1]) by bazooka.trit.org (Postfix) with ESMTP id 524D33C12E; Wed, 19 Dec 2001 00:54:12 +0000 (UTC) To: Robert Watson , "Brian F. Feldman" Cc: arch@freebsd.org Subject: xucred versioning and filling (was: MFC'ing xucred definition) Date: Wed, 19 Dec 2001 00:54:07 +0000 From: Dima Dorfman Message-Id: <20011219005412.54A833E2F@bazooka.trit.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 Does anybody have any comments on this? I'd like to commit it soon-ish, but don't plan to MFC it before 4.5 (since it's a new interface, and I'd rather not set it in stone (-stable) yet). Thanks. I wrote: > Robert Watson wrote: > > On Fri, 14 Dec 2001, Dima Dorfman wrote: > > > rwatson wrote: > > > > Actually, the one thing I'd like to see before we move forward > > > > is a standard routine that accepts a ucred, and a *xucred, and > > > > fills out the xucred using the ucred (preferably, in > > > > kern_prot.c). Right now, xucred is filled out in various > > > > places manually (netinet, socket code, et al). As we begin to > > > > broaden the scope of xucred (for example, I'd like to push in > > > > the ruid and rgid), it will make things a lot easier, and also > > > > prevent more code from knowing much about the innards of > > > > ucred. That way, also, the version number can be kept in one > > > > place. > > > > > > I had patches to add this routine (and vice versa, xucred->ucred) > > > before you added the extra fields to ucred, at which point I dropped it > > > since it didn't make much sense: Which fields do you copy? Effective, > > > real, or saved {u,g}ids? It would again make sense if xucred had the > > > same set of fields as ucred, however. > > > > It's always been euid in ucred previously, so I assumed that for version 0 > > of xucred, only euid and egid (plus additional groups) would be exported. > > Future versions of xucred (probably version 1, only in -CURRENT) would > > also be able to export ruid, svuid, rgid, and svgid. > > Very well. The attached patch adds two routines, cru2x() and crx2u() > which convert from a ucred to xucred and vice versa, respectively. > cru2x() sets the version number, and crx2u() checks it. If the check > fails, it returns EINVAL. I'm not sure if there's a better way to do > this error passing, since it seems that none of the other cr*() > routines return an error code. > > The userland parts remain unchanged from my previous patches. > > Index: lib/libc/gen/getpeereid.3 > =================================================================== > RCS file: /ref/cvsf/src/lib/libc/gen/getpeereid.3,v > retrieving revision 1.3 > diff -u -r1.3 getpeereid.3 > --- lib/libc/gen/getpeereid.3 2001/12/02 23:50:40 1.3 > +++ lib/libc/gen/getpeereid.3 2001/12/14 01:20:17 > @@ -118,7 +118,8 @@ > The argument > .Fa s > does not refer to a socket of type > -.Dv SOCK_STREAM . > +.Dv SOCK_STREAM , > +or the kernel returned invalid data. > .El > .Sh SEE ALSO > .Xr connect 2 , > Index: lib/libc/gen/getpeereid.c > =================================================================== > RCS file: /ref/cvsf/src/lib/libc/gen/getpeereid.c,v > retrieving revision 1.1 > diff -u -r1.1 getpeereid.c > --- lib/libc/gen/getpeereid.c 2001/08/17 22:09:15 1.1 > +++ lib/libc/gen/getpeereid.c 2001/12/14 01:20:17 > @@ -34,6 +34,7 @@ > #include > #include > > +#include > #include > > int > @@ -47,6 +48,8 @@ > error = getsockopt(s, LOCAL_PEERCRED, 1, &xuc, &xuclen); > if (error != 0) > return (error); > + if (xuc.cr_version != XUCRED_VERSION) > + return (EINVAL); > *euid = xuc.cr_uid; > *egid = xuc.cr_gid; > return (0); > Index: sbin/mountd/mountd.c > =================================================================== > RCS file: /ref/cvsf/src/sbin/mountd/mountd.c,v > retrieving revision 1.59 > diff -u -r1.59 mountd.c > --- sbin/mountd/mountd.c 2001/09/20 02:15:17 1.59 > +++ sbin/mountd/mountd.c 2001/12/14 01:20:17 > @@ -211,7 +211,7 @@ > struct grouplist *grphead; > char exname[MAXPATHLEN]; > struct xucred def_anon = { > - 0, > + XUCRED_VERSION, > (uid_t)-2, > 1, > { (gid_t)-2 }, > @@ -2050,6 +2050,7 @@ > struct group *gr; > int ngroups, groups[NGROUPS + 1]; > > + cr->cr_version = XUCRED_VERSION; > /* > * Set up the unprivileged user. > */ > Index: sys/kern/kern_prot.c > =================================================================== > RCS file: /ref/cvsf/src/sys/kern/kern_prot.c,v > retrieving revision 1.131 > diff -u -r1.131 kern_prot.c > --- sys/kern/kern_prot.c 2001/12/06 21:58:47 1.131 > +++ sys/kern/kern_prot.c 2001/12/14 03:30:55 > @@ -1670,6 +1670,41 @@ > } > > /* > + * Fill in a struct xucred based on a struct ucred. > + */ > +void > +cru2x(cr, xcr) > + struct ucred *cr; > + struct xucred *xcr; > +{ > + > + bzero(xcr, sizeof(*xcr)); > + xcr->cr_version = XUCRED_VERSION; > + xcr->cr_uid = cr->cr_uid; > + xcr->cr_ngroups = cr->cr_ngroups; > + bcopy(cr->cr_groups, xcr->cr_groups, sizeof(cr->cr_groups)); > +} > + > +/* > + * Copy information out of a struct xucred into a struct ucred. This > + * routine does *not* initialize (zero) the output structure (cr) > + * because that's the job of crget() or crdup(). > + */ > +int > +crx2u(xcr, cr) > + struct xucred *xcr; > + struct ucred *cr; > +{ > + > + if (xcr->cr_version != XUCRED_VERSION) > + return (EINVAL); > + cr->cr_uid = xcr->cr_uid; > + cr->cr_ngroups = xcr->cr_ngroups; > + bcopy(xcr->cr_groups, cr->cr_groups, sizeof(xcr->cr_groups)); > + return (0); > +} > + > +/* > * Get login name, if available. > */ > #ifndef _SYS_SYSPROTO_H_ > Index: sys/kern/uipc_usrreq.c > =================================================================== > RCS file: /ref/cvsf/src/sys/kern/uipc_usrreq.c,v > retrieving revision 1.78 > diff -u -r1.78 uipc_usrreq.c > --- sys/kern/uipc_usrreq.c 2001/12/13 22:09:37 1.78 > +++ sys/kern/uipc_usrreq.c 2001/12/14 03:33:12 > @@ -710,11 +710,7 @@ > * from its process structure at the time of connect() > * (which is now). > */ - memset(&unp3->unp_peercred, '\0', sizeof(unp3->unp_peercred)); > - unp3->unp_peercred.cr_uid = td->td_proc->p_ucred->cr_uid; > - unp3->unp_peercred.cr_ngroups = td->td_proc->p_ucred->cr_ngroup > s; > - memcpy(unp3->unp_peercred.cr_groups, td->td_proc->p_ucred->cr_g > roups, > - sizeof(unp3->unp_peercred.cr_groups)); > + cru2x(td->td_proc->p_ucred, &unp3->unp_peercred); > unp3->unp_flags |= UNP_HAVEPC; > /* > * The receiver's (server's) credentials are copied > @@ -1396,11 +1392,7 @@ > struct proc *p; > { > > - bzero(&unp->unp_peercred, sizeof(unp->unp_peercred)); > - unp->unp_peercred.cr_uid = p->p_ucred->cr_uid; > - unp->unp_peercred.cr_ngroups = p->p_ucred->cr_ngroups; > - bcopy(p->p_ucred->cr_groups, unp->unp_peercred.cr_groups, > - sizeof(unp->unp_peercred.cr_groups)); > + cru2x(p->p_ucred, &unp->unp_peercred); > unp->unp_flags |= UNP_HAVEPCCACHED; > return (0); > } > Index: sys/kern/vfs_export.c > =================================================================== > RCS file: /ref/cvsf/src/sys/kern/vfs_export.c,v > retrieving revision 1.312 > diff -u -r1.312 vfs_export.c > --- sys/kern/vfs_export.c 2001/09/10 11:28:05 1.312 > +++ sys/kern/vfs_export.c 2001/12/14 03:40:24 > @@ -98,11 +98,9 @@ > return (EPERM); > np = &nep->ne_defexported; > np->netc_exflags = argp->ex_flags; > - bzero(&np->netc_anon, sizeof(np->netc_anon)); > - np->netc_anon.cr_uid = argp->ex_anon.cr_uid; > - np->netc_anon.cr_ngroups = argp->ex_anon.cr_ngroups; > - bcopy(argp->ex_anon.cr_groups, np->netc_anon.cr_groups, > - sizeof(np->netc_anon.cr_groups)); > + error = crx2u(&argp->ex_anon, &np->netc_anon); > + if (error != 0) > + return (error); > np->netc_anon.cr_ref = 1; > mp->mnt_flag |= MNT_DEFEXPORTED; > return (0); > @@ -150,11 +148,9 @@ > goto out; > } > np->netc_exflags = argp->ex_flags; > - bzero(&np->netc_anon, sizeof(np->netc_anon)); > - np->netc_anon.cr_uid = argp->ex_anon.cr_uid; > - np->netc_anon.cr_ngroups = argp->ex_anon.cr_ngroups; > - bcopy(argp->ex_anon.cr_groups, np->netc_anon.cr_groups, > - sizeof(np->netc_anon.cr_groups)); > + error = crx2u(&argp->ex_anon, &np->netc_anon); > + if (error != 0) > + goto out; > np->netc_anon.cr_ref = 1; > return (0); > out: > Index: sys/netinet/tcp_subr.c > =================================================================== > RCS file: /ref/cvsf/src/sys/netinet/tcp_subr.c,v > retrieving revision 1.118 > diff -u -r1.118 tcp_subr.c > --- sys/netinet/tcp_subr.c 2001/11/22 04:50:43 1.118 > +++ sys/netinet/tcp_subr.c 2001/12/14 03:34:19 > @@ -919,11 +919,7 @@ > error = cr_cansee(req->td->td_proc->p_ucred, inp->inp_socket->so_cred); > if (error) > goto out; > - bzero(&xuc, sizeof(xuc)); > - xuc.cr_uid = inp->inp_socket->so_cred->cr_uid; > - xuc.cr_ngroups = inp->inp_socket->so_cred->cr_ngroups; > - bcopy(inp->inp_socket->so_cred->cr_groups, xuc.cr_groups, > - sizeof(xuc.cr_groups)); > + cru2x(inp->inp_socket->so_cred, &xuc); > error = SYSCTL_OUT(req, &xuc, sizeof(struct xucred)); > out: > splx(s); > @@ -975,11 +971,7 @@ > error = cr_cansee(req->td->td_proc->p_ucred, inp->inp_socket->so_cred); > if (error) > goto out; > - bzero(&xuc, sizeof(xuc)); > - xuc.cr_uid = inp->inp_socket->so_cred->cr_uid; > - xuc.cr_ngroups = inp->inp_socket->so_cred->cr_ngroups; > - bcopy(inp->inp_socket->so_cred->cr_groups, xuc.cr_groups, > - sizeof(xuc.cr_groups)); > + cru2x(inp->inp_socket->so_cred, &xuc); > error = SYSCTL_OUT(req, &xuc, sizeof(struct xucred)); > out: > splx(s); > Index: sys/netinet/udp_usrreq.c > =================================================================== > RCS file: /ref/cvsf/src/sys/netinet/udp_usrreq.c,v > retrieving revision 1.100 > diff -u -r1.100 udp_usrreq.c > --- sys/netinet/udp_usrreq.c 2001/11/08 02:13:17 1.100 > +++ sys/netinet/udp_usrreq.c 2001/12/14 03:34:36 > @@ -651,11 +651,7 @@ > error = cr_cansee(req->td->td_proc->p_ucred, inp->inp_socket->so_cred); > if (error) > goto out; > - bzero(&xuc, sizeof(xuc)); > - xuc.cr_uid = inp->inp_socket->so_cred->cr_uid; > - xuc.cr_ngroups = inp->inp_socket->so_cred->cr_ngroups; > - bcopy(inp->inp_socket->so_cred->cr_groups, xuc.cr_groups, > - sizeof(xuc.cr_groups)); > + cru2x(inp->inp_socket->so_cred, &xuc); > error = SYSCTL_OUT(req, &xuc, sizeof(struct xucred)); > out: > splx(s); > Index: sys/netinet6/udp6_usrreq.c > =================================================================== > RCS file: /ref/cvsf/src/sys/netinet6/udp6_usrreq.c,v > retrieving revision 1.19 > diff -u -r1.19 udp6_usrreq.c > --- sys/netinet6/udp6_usrreq.c 2001/11/08 02:13:18 1.19 > +++ sys/netinet6/udp6_usrreq.c 2001/12/14 03:35:00 > @@ -484,11 +484,7 @@ > error = ENOENT; > goto out; > } > - bzero(&xuc, sizeof(xuc)); > - xuc.cr_uid = inp->inp_socket->so_cred->cr_uid; > - xuc.cr_ngroups = inp->inp_socket->so_cred->cr_ngroups; > - bcopy(inp->inp_socket->so_cred->cr_groups, xuc.cr_groups, > - sizeof(xuc.cr_groups)); > + cru2x(inp->inp_socket->so_cred, &xuc); > error = SYSCTL_OUT(req, &xuc, sizeof(struct xucred)); > out: > splx(s); > Index: sys/security/lomac/kernel_socket.c > =================================================================== > RCS file: /ref/cvsf/src/sys/security/lomac/kernel_socket.c,v > retrieving revision 1.2 > diff -u -r1.2 kernel_socket.c > --- sys/security/lomac/kernel_socket.c 2001/12/03 00:21:18 1.2 > +++ sys/security/lomac/kernel_socket.c 2001/12/14 03:35:23 > @@ -265,11 +265,7 @@ > * from its process structure at the time of connect() > * (which is now). > */ > - memset(&unp3->unp_peercred, '\0', sizeof(unp3->unp_peercred)); > - unp3->unp_peercred.cr_uid = td->td_proc->p_ucred->cr_uid; > - unp3->unp_peercred.cr_ngroups = td->td_proc->p_ucred->cr_ngroup > s; > - memcpy(unp3->unp_peercred.cr_groups, td->td_proc->p_ucred->cr_g > roups, > - sizeof(unp3->unp_peercred.cr_groups)); > + cru2x(td->td_proc->p_ucred, &unp3->unp_peercred); > unp3->unp_flags |= UNP_HAVEPC; > /* > * The receiver's (server's) credentials are copied > Index: sys/sys/ucred.h > =================================================================== > RCS file: /ref/cvsf/src/sys/sys/ucred.h,v > retrieving revision 1.26 > diff -u -r1.26 ucred.h > --- sys/sys/ucred.h 2001/10/11 23:38:17 1.26 > +++ sys/sys/ucred.h 2001/12/14 03:30:26 > @@ -73,12 +73,13 @@ > * any need to change the size of this or layout of its used fields. > */ > struct xucred { > - u_short _cr_unused0; /* compatibility with old ucred */ > + u_short cr_version; /* structure layout version */ > uid_t cr_uid; /* effective user id */ > short cr_ngroups; /* number of groups */ > gid_t cr_groups[NGROUPS]; /* groups */ > void *_cr_unused1; /* compatibility with old ucred */ > }; > +#define XUCRED_VERSION 0 > > #ifdef _KERNEL > > @@ -95,6 +96,8 @@ > struct ucred *crget __P((void)); > struct ucred *crhold __P((struct ucred *cr)); > int crshared __P((struct ucred *cr)); > +void cru2x __P((struct ucred *cr, struct xucred *xcr)); > +int crx2u __P((struct xucred *xcr, struct ucred *cr)); > int groupmember __P((gid_t gid, struct ucred *cred)); > #endif /* _KERNEL */ > > Index: usr.sbin/inetd/builtins.c > =================================================================== > RCS file: /ref/cvsf/src/usr.sbin/inetd/builtins.c,v > retrieving revision 1.36 > diff -u -r1.36 builtins.c > --- usr.sbin/inetd/builtins.c 2001/07/17 07:12:57 1.36 > +++ usr.sbin/inetd/builtins.c 2001/12/14 01:20:18 > @@ -569,7 +569,7 @@ > getcredfail = EAFNOSUPPORT; > break; > } > - if (getcredfail != 0) { > + if (getcredfail != 0 || uc.cr_version != XUCRED_VERSION) { > if (*idbuf == '\0') > iderror(lport, fport, s, > getcredfail == ENOENT ? ID_NOUSER : ID_UNKNOWN); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 18 19:39:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0153637B419; Tue, 18 Dec 2001 19:38:59 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fBJ3bqi54990; Tue, 18 Dec 2001 22:37:52 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 18 Dec 2001 22:37:52 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Dima Dorfman Cc: "Brian F. Feldman" , arch@freebsd.org Subject: Re: xucred versioning and filling (was: MFC'ing xucred definition) In-Reply-To: <20011219005412.54A833E2F@bazooka.trit.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Should crx2u() attempt to handle reference counting issues, as well as uidinfo and friends? I'm far more comfortable with a notion of u2crx than vice versa, as the ucred structure has additional semantics, whereas the xucred structure doesn't. The vfs_export.c code that uses it may need further inspection for the same reasons, actually... Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Wed, 19 Dec 2001, Dima Dorfman wrote: > Does anybody have any comments on this? I'd like to commit it > soon-ish, but don't plan to MFC it before 4.5 (since it's a new > interface, and I'd rather not set it in stone (-stable) yet). > > Thanks. > > I wrote: > > Robert Watson wrote: > > > On Fri, 14 Dec 2001, Dima Dorfman wrote: > > > > rwatson wrote: > > > > > Actually, the one thing I'd like to see before we move forward > > > > > is a standard routine that accepts a ucred, and a *xucred, and > > > > > fills out the xucred using the ucred (preferably, in > > > > > kern_prot.c). Right now, xucred is filled out in various > > > > > places manually (netinet, socket code, et al). As we begin to > > > > > broaden the scope of xucred (for example, I'd like to push in > > > > > the ruid and rgid), it will make things a lot easier, and also > > > > > prevent more code from knowing much about the innards of > > > > > ucred. That way, also, the version number can be kept in one > > > > > place. > > > > > > > > I had patches to add this routine (and vice versa, xucred->ucred) > > > > before you added the extra fields to ucred, at which point I dropped it > > > > since it didn't make much sense: Which fields do you copy? Effective, > > > > real, or saved {u,g}ids? It would again make sense if xucred had the > > > > same set of fields as ucred, however. > > > > > > It's always been euid in ucred previously, so I assumed that for version 0 > > > of xucred, only euid and egid (plus additional groups) would be exported. > > > Future versions of xucred (probably version 1, only in -CURRENT) would > > > also be able to export ruid, svuid, rgid, and svgid. > > > > Very well. The attached patch adds two routines, cru2x() and crx2u() > > which convert from a ucred to xucred and vice versa, respectively. > > cru2x() sets the version number, and crx2u() checks it. If the check > > fails, it returns EINVAL. I'm not sure if there's a better way to do > > this error passing, since it seems that none of the other cr*() > > routines return an error code. > > > > The userland parts remain unchanged from my previous patches. > > > > Index: lib/libc/gen/getpeereid.3 > > =================================================================== > > RCS file: /ref/cvsf/src/lib/libc/gen/getpeereid.3,v > > retrieving revision 1.3 > > diff -u -r1.3 getpeereid.3 > > --- lib/libc/gen/getpeereid.3 2001/12/02 23:50:40 1.3 > > +++ lib/libc/gen/getpeereid.3 2001/12/14 01:20:17 > > @@ -118,7 +118,8 @@ > > The argument > > .Fa s > > does not refer to a socket of type > > -.Dv SOCK_STREAM . > > +.Dv SOCK_STREAM , > > +or the kernel returned invalid data. > > .El > > .Sh SEE ALSO > > .Xr connect 2 , > > Index: lib/libc/gen/getpeereid.c > > =================================================================== > > RCS file: /ref/cvsf/src/lib/libc/gen/getpeereid.c,v > > retrieving revision 1.1 > > diff -u -r1.1 getpeereid.c > > --- lib/libc/gen/getpeereid.c 2001/08/17 22:09:15 1.1 > > +++ lib/libc/gen/getpeereid.c 2001/12/14 01:20:17 > > @@ -34,6 +34,7 @@ > > #include > > #include > > > > +#include > > #include > > > > int > > @@ -47,6 +48,8 @@ > > error = getsockopt(s, LOCAL_PEERCRED, 1, &xuc, &xuclen); > > if (error != 0) > > return (error); > > + if (xuc.cr_version != XUCRED_VERSION) > > + return (EINVAL); > > *euid = xuc.cr_uid; > > *egid = xuc.cr_gid; > > return (0); > > Index: sbin/mountd/mountd.c > > =================================================================== > > RCS file: /ref/cvsf/src/sbin/mountd/mountd.c,v > > retrieving revision 1.59 > > diff -u -r1.59 mountd.c > > --- sbin/mountd/mountd.c 2001/09/20 02:15:17 1.59 > > +++ sbin/mountd/mountd.c 2001/12/14 01:20:17 > > @@ -211,7 +211,7 @@ > > struct grouplist *grphead; > > char exname[MAXPATHLEN]; > > struct xucred def_anon = { > > - 0, > > + XUCRED_VERSION, > > (uid_t)-2, > > 1, > > { (gid_t)-2 }, > > @@ -2050,6 +2050,7 @@ > > struct group *gr; > > int ngroups, groups[NGROUPS + 1]; > > > > + cr->cr_version = XUCRED_VERSION; > > /* > > * Set up the unprivileged user. > > */ > > Index: sys/kern/kern_prot.c > > =================================================================== > > RCS file: /ref/cvsf/src/sys/kern/kern_prot.c,v > > retrieving revision 1.131 > > diff -u -r1.131 kern_prot.c > > --- sys/kern/kern_prot.c 2001/12/06 21:58:47 1.131 > > +++ sys/kern/kern_prot.c 2001/12/14 03:30:55 > > @@ -1670,6 +1670,41 @@ > > } > > > > /* > > + * Fill in a struct xucred based on a struct ucred. > > + */ > > +void > > +cru2x(cr, xcr) > > + struct ucred *cr; > > + struct xucred *xcr; > > +{ > > + > > + bzero(xcr, sizeof(*xcr)); > > + xcr->cr_version = XUCRED_VERSION; > > + xcr->cr_uid = cr->cr_uid; > > + xcr->cr_ngroups = cr->cr_ngroups; > > + bcopy(cr->cr_groups, xcr->cr_groups, sizeof(cr->cr_groups)); > > +} > > + > > +/* > > + * Copy information out of a struct xucred into a struct ucred. This > > + * routine does *not* initialize (zero) the output structure (cr) > > + * because that's the job of crget() or crdup(). > > + */ > > +int > > +crx2u(xcr, cr) > > + struct xucred *xcr; > > + struct ucred *cr; > > +{ > > + > > + if (xcr->cr_version != XUCRED_VERSION) > > + return (EINVAL); > > + cr->cr_uid = xcr->cr_uid; > > + cr->cr_ngroups = xcr->cr_ngroups; > > + bcopy(xcr->cr_groups, cr->cr_groups, sizeof(xcr->cr_groups)); > > + return (0); > > +} > > + > > +/* > > * Get login name, if available. > > */ > > #ifndef _SYS_SYSPROTO_H_ > > Index: sys/kern/uipc_usrreq.c > > =================================================================== > > RCS file: /ref/cvsf/src/sys/kern/uipc_usrreq.c,v > > retrieving revision 1.78 > > diff -u -r1.78 uipc_usrreq.c > > --- sys/kern/uipc_usrreq.c 2001/12/13 22:09:37 1.78 > > +++ sys/kern/uipc_usrreq.c 2001/12/14 03:33:12 > > @@ -710,11 +710,7 @@ > > * from its process structure at the time of connect() > > * (which is now). > > */ > - memset(&unp3->unp_peercred, '\0', sizeof(unp3->unp_peercred)); > > - unp3->unp_peercred.cr_uid = td->td_proc->p_ucred->cr_uid; > > - unp3->unp_peercred.cr_ngroups = td->td_proc->p_ucred->cr_ngroup > > s; > > - memcpy(unp3->unp_peercred.cr_groups, td->td_proc->p_ucred->cr_g > > roups, > > - sizeof(unp3->unp_peercred.cr_groups)); > > + cru2x(td->td_proc->p_ucred, &unp3->unp_peercred); > > unp3->unp_flags |= UNP_HAVEPC; > > /* > > * The receiver's (server's) credentials are copied > > @@ -1396,11 +1392,7 @@ > > struct proc *p; > > { > > > > - bzero(&unp->unp_peercred, sizeof(unp->unp_peercred)); > > - unp->unp_peercred.cr_uid = p->p_ucred->cr_uid; > > - unp->unp_peercred.cr_ngroups = p->p_ucred->cr_ngroups; > > - bcopy(p->p_ucred->cr_groups, unp->unp_peercred.cr_groups, > > - sizeof(unp->unp_peercred.cr_groups)); > > + cru2x(p->p_ucred, &unp->unp_peercred); > > unp->unp_flags |= UNP_HAVEPCCACHED; > > return (0); > > } > > Index: sys/kern/vfs_export.c > > =================================================================== > > RCS file: /ref/cvsf/src/sys/kern/vfs_export.c,v > > retrieving revision 1.312 > > diff -u -r1.312 vfs_export.c > > --- sys/kern/vfs_export.c 2001/09/10 11:28:05 1.312 > > +++ sys/kern/vfs_export.c 2001/12/14 03:40:24 > > @@ -98,11 +98,9 @@ > > return (EPERM); > > np = &nep->ne_defexported; > > np->netc_exflags = argp->ex_flags; > > - bzero(&np->netc_anon, sizeof(np->netc_anon)); > > - np->netc_anon.cr_uid = argp->ex_anon.cr_uid; > > - np->netc_anon.cr_ngroups = argp->ex_anon.cr_ngroups; > > - bcopy(argp->ex_anon.cr_groups, np->netc_anon.cr_groups, > > - sizeof(np->netc_anon.cr_groups)); > > + error = crx2u(&argp->ex_anon, &np->netc_anon); > > + if (error != 0) > > + return (error); > > np->netc_anon.cr_ref = 1; > > mp->mnt_flag |= MNT_DEFEXPORTED; > > return (0); > > @@ -150,11 +148,9 @@ > > goto out; > > } > > np->netc_exflags = argp->ex_flags; > > - bzero(&np->netc_anon, sizeof(np->netc_anon)); > > - np->netc_anon.cr_uid = argp->ex_anon.cr_uid; > > - np->netc_anon.cr_ngroups = argp->ex_anon.cr_ngroups; > > - bcopy(argp->ex_anon.cr_groups, np->netc_anon.cr_groups, > > - sizeof(np->netc_anon.cr_groups)); > > + error = crx2u(&argp->ex_anon, &np->netc_anon); > > + if (error != 0) > > + goto out; > > np->netc_anon.cr_ref = 1; > > return (0); > > out: > > Index: sys/netinet/tcp_subr.c > > =================================================================== > > RCS file: /ref/cvsf/src/sys/netinet/tcp_subr.c,v > > retrieving revision 1.118 > > diff -u -r1.118 tcp_subr.c > > --- sys/netinet/tcp_subr.c 2001/11/22 04:50:43 1.118 > > +++ sys/netinet/tcp_subr.c 2001/12/14 03:34:19 > > @@ -919,11 +919,7 @@ > > error = cr_cansee(req->td->td_proc->p_ucred, inp->inp_socket->so_cred); > > if (error) > > goto out; > > - bzero(&xuc, sizeof(xuc)); > > - xuc.cr_uid = inp->inp_socket->so_cred->cr_uid; > > - xuc.cr_ngroups = inp->inp_socket->so_cred->cr_ngroups; > > - bcopy(inp->inp_socket->so_cred->cr_groups, xuc.cr_groups, > > - sizeof(xuc.cr_groups)); > > + cru2x(inp->inp_socket->so_cred, &xuc); > > error = SYSCTL_OUT(req, &xuc, sizeof(struct xucred)); > > out: > > splx(s); > > @@ -975,11 +971,7 @@ > > error = cr_cansee(req->td->td_proc->p_ucred, inp->inp_socket->so_cred); > > if (error) > > goto out; > > - bzero(&xuc, sizeof(xuc)); > > - xuc.cr_uid = inp->inp_socket->so_cred->cr_uid; > > - xuc.cr_ngroups = inp->inp_socket->so_cred->cr_ngroups; > > - bcopy(inp->inp_socket->so_cred->cr_groups, xuc.cr_groups, > > - sizeof(xuc.cr_groups)); > > + cru2x(inp->inp_socket->so_cred, &xuc); > > error = SYSCTL_OUT(req, &xuc, sizeof(struct xucred)); > > out: > > splx(s); > > Index: sys/netinet/udp_usrreq.c > > =================================================================== > > RCS file: /ref/cvsf/src/sys/netinet/udp_usrreq.c,v > > retrieving revision 1.100 > > diff -u -r1.100 udp_usrreq.c > > --- sys/netinet/udp_usrreq.c 2001/11/08 02:13:17 1.100 > > +++ sys/netinet/udp_usrreq.c 2001/12/14 03:34:36 > > @@ -651,11 +651,7 @@ > > error = cr_cansee(req->td->td_proc->p_ucred, inp->inp_socket->so_cred); > > if (error) > > goto out; > > - bzero(&xuc, sizeof(xuc)); > > - xuc.cr_uid = inp->inp_socket->so_cred->cr_uid; > > - xuc.cr_ngroups = inp->inp_socket->so_cred->cr_ngroups; > > - bcopy(inp->inp_socket->so_cred->cr_groups, xuc.cr_groups, > > - sizeof(xuc.cr_groups)); > > + cru2x(inp->inp_socket->so_cred, &xuc); > > error = SYSCTL_OUT(req, &xuc, sizeof(struct xucred)); > > out: > > splx(s); > > Index: sys/netinet6/udp6_usrreq.c > > =================================================================== > > RCS file: /ref/cvsf/src/sys/netinet6/udp6_usrreq.c,v > > retrieving revision 1.19 > > diff -u -r1.19 udp6_usrreq.c > > --- sys/netinet6/udp6_usrreq.c 2001/11/08 02:13:18 1.19 > > +++ sys/netinet6/udp6_usrreq.c 2001/12/14 03:35:00 > > @@ -484,11 +484,7 @@ > > error = ENOENT; > > goto out; > > } > > - bzero(&xuc, sizeof(xuc)); > > - xuc.cr_uid = inp->inp_socket->so_cred->cr_uid; > > - xuc.cr_ngroups = inp->inp_socket->so_cred->cr_ngroups; > > - bcopy(inp->inp_socket->so_cred->cr_groups, xuc.cr_groups, > > - sizeof(xuc.cr_groups)); > > + cru2x(inp->inp_socket->so_cred, &xuc); > > error = SYSCTL_OUT(req, &xuc, sizeof(struct xucred)); > > out: > > splx(s); > > Index: sys/security/lomac/kernel_socket.c > > =================================================================== > > RCS file: /ref/cvsf/src/sys/security/lomac/kernel_socket.c,v > > retrieving revision 1.2 > > diff -u -r1.2 kernel_socket.c > > --- sys/security/lomac/kernel_socket.c 2001/12/03 00:21:18 1.2 > > +++ sys/security/lomac/kernel_socket.c 2001/12/14 03:35:23 > > @@ -265,11 +265,7 @@ > > * from its process structure at the time of connect() > > * (which is now). > > */ > > - memset(&unp3->unp_peercred, '\0', sizeof(unp3->unp_peercred)); > > - unp3->unp_peercred.cr_uid = td->td_proc->p_ucred->cr_uid; > > - unp3->unp_peercred.cr_ngroups = td->td_proc->p_ucred->cr_ngroup > > s; > > - memcpy(unp3->unp_peercred.cr_groups, td->td_proc->p_ucred->cr_g > > roups, > > - sizeof(unp3->unp_peercred.cr_groups)); > > + cru2x(td->td_proc->p_ucred, &unp3->unp_peercred); > > unp3->unp_flags |= UNP_HAVEPC; > > /* > > * The receiver's (server's) credentials are copied > > Index: sys/sys/ucred.h > > =================================================================== > > RCS file: /ref/cvsf/src/sys/sys/ucred.h,v > > retrieving revision 1.26 > > diff -u -r1.26 ucred.h > > --- sys/sys/ucred.h 2001/10/11 23:38:17 1.26 > > +++ sys/sys/ucred.h 2001/12/14 03:30:26 > > @@ -73,12 +73,13 @@ > > * any need to change the size of this or layout of its used fields. > > */ > > struct xucred { > > - u_short _cr_unused0; /* compatibility with old ucred */ > > + u_short cr_version; /* structure layout version */ > > uid_t cr_uid; /* effective user id */ > > short cr_ngroups; /* number of groups */ > > gid_t cr_groups[NGROUPS]; /* groups */ > > void *_cr_unused1; /* compatibility with old ucred */ > > }; > > +#define XUCRED_VERSION 0 > > > > #ifdef _KERNEL > > > > @@ -95,6 +96,8 @@ > > struct ucred *crget __P((void)); > > struct ucred *crhold __P((struct ucred *cr)); > > int crshared __P((struct ucred *cr)); > > +void cru2x __P((struct ucred *cr, struct xucred *xcr)); > > +int crx2u __P((struct xucred *xcr, struct ucred *cr)); > > int groupmember __P((gid_t gid, struct ucred *cred)); > > #endif /* _KERNEL */ > > > > Index: usr.sbin/inetd/builtins.c > > =================================================================== > > RCS file: /ref/cvsf/src/usr.sbin/inetd/builtins.c,v > > retrieving revision 1.36 > > diff -u -r1.36 builtins.c > > --- usr.sbin/inetd/builtins.c 2001/07/17 07:12:57 1.36 > > +++ usr.sbin/inetd/builtins.c 2001/12/14 01:20:18 > > @@ -569,7 +569,7 @@ > > getcredfail = EAFNOSUPPORT; > > break; > > } > > - if (getcredfail != 0) { > > + if (getcredfail != 0 || uc.cr_version != XUCRED_VERSION) { > > if (*idbuf == '\0') > > iderror(lport, fport, s, > > getcredfail == ENOENT ? ID_NOUSER : ID_UNKNOWN); > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 18 20: 6:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id F07DE37B420; Tue, 18 Dec 2001 20:06:31 -0800 (PST) Received: from sdn-ar-002flnaplp142.dialsprint.net ([168.191.86.206] helo=gohan.cjclark.org) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16GXzx-0001h3-00; Tue, 18 Dec 2001 20:06:31 -0800 Received: (from cjc@localhost) by gohan.cjclark.org (8.11.6/8.11.1) id fBIHdoN00253; Tue, 18 Dec 2001 09:39:50 -0800 (PST) (envelope-from cjc) Date: Tue, 18 Dec 2001 09:39:50 -0800 From: "Crist J. Clark" To: Maxim Konovalov Cc: "Crist J . Clark" , arch@FreeBSD.ORG Subject: Re: Keeping pppd(8) Stuff in /etc/ppp Message-ID: <20011218093950.A231@gohan.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20011217155544.C19170@blossom.cjclark.org> <20011218103547.N70503-100000@news1.macomnet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011218103547.N70503-100000@news1.macomnet.ru>; from maxim@macomnet.ru on Tue, Dec 18, 2001 at 10:37:21AM +0300 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Dec 18, 2001 at 10:37:21AM +0300, Maxim Konovalov wrote: > On 15:55-0800, Dec 17, 2001, Crist J . Clark wrote: > > > There are two pppd(8) configuration files in /etc/ppp, ppp.deny and > > ppp.shells.sample. There are no other pppd(8) sample files (anywhere) > > that I can find. Is there any point of leaving these two lying around > > in /etc/ppp? I would expect that currently their primary function is > > to confuse ppp(8) users. > > > > On a side note, does anyone use pppd(8) anymore? Bitrot? Does it even > > At least I do. > > > work correctly anymore? > > It works for me. As a pppd(8) user, what is your opinion on losing the pppd(8) files in /etc/ppp? Are they of any real use? IMHO, we should either (a) just remove ppp.deny and ppp.shells.sample /etc/ppp or (b) remove those two from /etc/ppp and put them in /usr/share/examples/pppd with a full set of pppd(8) examples. Since I don't have files or the expertise to come up with examples for (b), I'd need the help of someone who knows pppd(8) to do it. -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 18 22:14:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 870E737B41C; Tue, 18 Dec 2001 22:14:23 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBJ6EMa19732; Tue, 18 Dec 2001 23:14:22 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fBJ6ELM94421; Tue, 18 Dec 2001 23:14:21 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112190614.fBJ6ELM94421@harmony.village.org> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: Recent fdc(4) commit broke Alpha kernels Cc: freebsd-current@FreeBSD.ORG, arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 18 Dec 2001 23:56:46 +0100." <200112182256.fBIMuk001274@uriah.heep.sax.de> References: <200112182256.fBIMuk001274@uriah.heep.sax.de> <20011218200918.A14073@sunbay.com> <20011218204720.B18124@sunbay.com> Date: Tue, 18 Dec 2001 23:14:21 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200112182256.fBIMuk001274@uriah.heep.sax.de> Joerg Wunsch writes: : Cc goes to arch@freebsd.org: what is the politically correct way to : distinguish a PC-type architecture (in that case one that uses a : PC-style RTC memory to store configuration information) from another : architecture that uses IA32 CPUs (like PC98, although they aren't : using /sys/isa/fd.c right now)? #if defined(__i386__) && !defined(PC98) is what is usually used... There's really only one other IA32 architecture these days. All the others I know of died in the 286 or 8088 time frame. We don't have a ibmpc or pc-at symbol. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 18 22:21:13 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 5D66F37B405 for ; Tue, 18 Dec 2001 22:21:08 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAA02452; Wed, 19 Dec 2001 17:20:50 +1100 Date: Wed, 19 Dec 2001 17:22:10 +1100 (EST) From: Bruce Evans X-X-Sender: To: Luigi Rizzo Cc: Jonathan Lemon , Subject: Re: swi_net In-Reply-To: <20011218134149.A89299@iguana.aciri.org> Message-ID: <20011219171202.W6928-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 18 Dec 2001, Luigi Rizzo wrote: > > I'm planning on revising swi_net so that it is possible to run all > > network processing under the device interrupt instead of deferring > > things to a netisr(). This also has the advantage of eliminating all > > The thing is, some processing can be quite long (e.g. IPSec, very > long ipfw rulesets, multicast when you have a large number of > sockets trying to fetch the packet, etc.), so it is not 100% > desirable having it run in interrupt context. Netisrs exist because it was 100% undesirable on old, slow machines, but it isn't a problem now that machines are infinitely fast ;-). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 19 0:37:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id E2AFE37B419 for ; Wed, 19 Dec 2001 00:37:07 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBJ8Uia20318; Wed, 19 Dec 2001 01:30:44 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fBJ8UhM25504; Wed, 19 Dec 2001 01:30:43 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112190830.fBJ8UhM25504@harmony.village.org> To: Joerg Wunsch Subject: Re: cvs commit: src/sys/isa fd.c Cc: arch@freebsd.org In-reply-to: Your message of "Wed, 19 Dec 2001 09:02:56 +0100." <20011219090256.E97821@uriah.heep.sax.de> References: <20011219090256.E97821@uriah.heep.sax.de> <200112182253.fBIMrdM92149@harmony.village.org> Date: Wed, 19 Dec 2001 01:30:43 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011219090256.E97821@uriah.heep.sax.de> Joerg Wunsch writes: : As Warner Losh wrote: : : > __i386__ is defined on both FreeBSD/i386 and FreeBSD/pc98. There's no : > unique symbole for FreeBSD/i386, so that should be : > : > #if defined(__i386__) && !defined(PC98) : : But that wouldn't exclude any further (hypothetical) architecture : using an IA32-class CPU. I still think we should make our _MACHINE : and MACHINE macros that are defined in work well : enough for cpp conditionals. I don't think we can fix them. There's no pc98/include/param.h. There's no pc98/include at all, but instead it uses the i386 ones. But we could add the right goo there. I don't think there will be another IA32 port ever. However, we could define something like PCAT for FreeBSD/i386. But that also is unsatisfying. I don't think that we can do the enumeration of all possible architectures well enough to make things work like you'd like. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 19 4:43: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay1.macomnet.ru (relay1.macomnet.ru [195.128.64.10]) by hub.freebsd.org (Postfix) with ESMTP id DB08A37B421; Wed, 19 Dec 2001 04:42:51 -0800 (PST) Received: from news1.macomnet.ru (maxim@news1.macomnet.ru [195.128.64.14]) by relay1.macomnet.ru (8.11.3/8.11.3) with ESMTP id fBJCgfc1452832; Wed, 19 Dec 2001 15:42:41 +0300 (MSK) Date: Wed, 19 Dec 2001 15:42:40 +0300 (MSK) From: Maxim Konovalov To: cjclark@alum.mit.edu Cc: "Crist J . Clark" , Subject: Re: Keeping pppd(8) Stuff in /etc/ppp In-Reply-To: <20011218093950.A231@gohan.cjclark.org> Message-ID: <20011219152641.A86316-100000@news1.macomnet.ru> 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 Hello Crist, On 09:39-0800, Dec 18, 2001, Crist J. Clark wrote: > On Tue, Dec 18, 2001 at 10:37:21AM +0300, Maxim Konovalov wrote: > > On 15:55-0800, Dec 17, 2001, Crist J . Clark wrote: > > > > > There are two pppd(8) configuration files in /etc/ppp, ppp.deny and > > > ppp.shells.sample. There are no other pppd(8) sample files (anywhere) > > > that I can find. Is there any point of leaving these two lying around > > > in /etc/ppp? I would expect that currently their primary function is > > > to confuse ppp(8) users. > > > > > > On a side note, does anyone use pppd(8) anymore? Bitrot? Does it even > > > > At least I do. > > > > > work correctly anymore? > > > > It works for me. > > As a pppd(8) user, what is your opinion on losing the pppd(8) files in > /etc/ppp? Are they of any real use? IMHO, we should either (a) just > remove ppp.deny and ppp.shells.sample /etc/ppp or (b) remove those two > from /etc/ppp and put them in /usr/share/examples/pppd with a full set > of pppd(8) examples. Since I don't have files or the expertise to come (b) is OK for me. > up with examples for (b), I'd need the help of someone who knows > pppd(8) to do it. Please take a look at http://news1.macomnet.ru/~maxim/p/pppd/ It is about a full set of sample files for pppd(8). pppd.8.diff is a patch for pppd(8) manpage and it does not belong to /usr/share/examples/pppd/ If you need any futher assistance with pppd please ask. Thanks! - -maxim -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: maxim@macomnet.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 19 11:45:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from repulse.cnchost.com (repulse.concentric.net [207.155.248.4]) by hub.freebsd.org (Postfix) with ESMTP id AE3A837B419; Wed, 19 Dec 2001 11:45:28 -0800 (PST) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by repulse.cnchost.com id OAA04975; Wed, 19 Dec 2001 14:45:20 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <200112191945.OAA04975@repulse.cnchost.com> To: Terry Lambert Cc: Andrea Campi , freebsd-arch@FreeBSD.ORG, freebsd-fs@freebsd.org Reply-To: freebsd-fs@freebsd.org Subject: Re: Real world Root Resizing (was Re: Proposed auto-sizing patch ... In-reply-to: Your message of "Wed, 12 Dec 2001 10:36:19 PST." <3C17A3A3.A439BE21@mindspring.com> Date: Wed, 19 Dec 2001 11:45:21 -0800 From: Bakul Shah Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [sorry, I should have sent my original message to -fs instead of -arch] Andrea Campi wrote: > #include > > I was able to simple boot to single user and growfs my / without any magic. > I *might* have changed it to read-only just for safety but I don't think so You are a smarter person than I! I believed the growfs man page (it only works on unmounted file system) but should've realized it would work on a readonly mount provided you reboot right after. But I admit, I didn't trust growfs to be bug free which is why I first made a mirror copy of the root partition. Terry Lambert writes: > You could imagine a brute force tool to do this: back up to tape, > newfs, and restore from tape. You can tar cf to another filesystem and tar xf for the special case of a small root filesystem. > A better tool would allow you to defragment an existing FS, or even > run in the background at boot, and defragment only if necessary (some > inequality threshold on per cylinder group fill amounts, perhaps). > > An even better tool might allow you to "defragment" a large disk, at > the same time declaring the end of that disk "off limits". Doing > that would let you actually free up cylinder groups at the end of a > disk -- and shrink partitions, as well as expand them. I wonder if one can devise a syscall interface to do this safely without requiring detailed knowledge of the FS layout and replicating a lot of FS code in user mode. * For shrinking a partition you need a syscall to limit disk block allocation. Something like int fs_alloc(const char* mountpoint, size_t offset, size_t limit); This would do all allocation the [offset..limit) range until the next call. Even if you grew a file outside this range, the new blocks will be allocated here. A filesystem that does not implement this functionality returns ENOSYS. offset and limit are in disk blocksize unit but may need to be rounded up to some FS specific parameter (such as cylinder group size for FFS). * For defragmenting you need a way to move file data. Something like int frealloc(fd, offset, count, addr) offset & count must be multiples of disk block size. addr is a hint as to where these blocks should be moved. The call fails if the suggested new blocks are in use. The FS code atomically (at syscall level) moves specified blocks to the new area. * You also need to be able to get to various freelists. I can't see how defragmentation can be done without some knowledge of FS layout but perhaps most of the details can be abstracted out well enough that the same interface can be used for different FSes. You would run this on a quiescent system but there is no need to unmount the FS or even bring the system down to single user. Placement of files can also be changed once you have this interface. One idea is to sample file access time. Files that gets read frequently can be moved to reduce seek time. Files with similar access time can be clustered and so on. What would be better than sampling atime is keeping read stats in each inode: each time a file is read and the atime is to be updated, increment a small counter (but make it `stick' when it reaches max). This counter is zeroed when the stats are gathered by a user program. I am not holding my breath though. Comments? -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 19 12:36: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id 8844037B419 for ; Wed, 19 Dec 2001 12:36:00 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id HAA24209; Thu, 20 Dec 2001 07:35:57 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37645) with ESMTP id <01KC30C9N0AO4M3I51@cim.alcatel.com.au>; Thu, 20 Dec 2001 07:35:38 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.6/8.11.6) id fBJKZsa58156; Thu, 20 Dec 2001 07:35:54 +1100 Content-return: prohibited Date: Thu, 20 Dec 2001 07:35:54 +1100 From: Peter Jeremy Subject: Swap performance (was: Getting rid of /usr file system) In-reply-to: <200112161616.fBGGGKg49403@aslan.scsiguy.com>; from gibbs@scsiguy.com on Sun, Dec 16, 2001 at 09:16:20AM -0700 To: "Justin T. Gibbs" Cc: freebsd-arch@FreeBSD.ORG Mail-Followup-To: "Justin T. Gibbs" , freebsd-arch@FreeBSD.ORG Message-id: <20011220073554.Q73243@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <200112120510.fBC5AEM33040@harmony.village.org> <200112161616.fBGGGKg49403@aslan.scsiguy.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 On Sun, Dec 16, 2001 at 09:16:20AM -0700, Justin T. Gibbs wrote: > I prefer to have my swap partition as close to the front >of the disk as possible to take advantage of the faster tracks. Is this particular piece of folklore still valid? It used to be true: When a process started, the text and data were read from the filesystem into memory. If necessary, the process was paged/swapped to/from swap. Pre-paging Unices in particular had comparatively high I/O load on swap since the entire process space needed to be read/written. (Hence the use of drums in better-equipped sites). For FreeBSD (and other modern Unices), processes are initially paged in from the filesystem. Under high memory load, pages will be paged to/from swap and from the filesystem. The removal of the need to swap entire processes and the removal of text (and other read-only data) from swap both reduce the I/O load of the swap device. It's no longer clear to me that dedicating the fastest piece of disk to swap is the best solution. The above is somewhat simplified - it ignores sticky executables (which transform filesystem I/O into swap I/O) and mmap(2) (which can result in paging to, as well as from, the filesystem) - but I believe it is generally representative. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 19 13:48:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.122.47]) by hub.freebsd.org (Postfix) with ESMTP id E39EC37B417 for ; Wed, 19 Dec 2001 13:48:31 -0800 (PST) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.11.3/8.10.1) with ESMTP id fBJLmgZ41334; Wed, 19 Dec 2001 13:48:42 -0800 (PST) Date: Wed, 19 Dec 2001 13:48:42 -0800 (PST) From: Doug White To: Peter Jeremy Cc: "Justin T. Gibbs" , Subject: Re: Swap performance (was: Getting rid of /usr file system) In-Reply-To: <20011220073554.Q73243@gsmx07.alcatel.com.au> Message-ID: X-All-Your-Base: are belong to us MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 20 Dec 2001, Peter Jeremy wrote: > The above is somewhat simplified - it ignores sticky executables > (which transform filesystem I/O into swap I/O) and mmap(2) (which can > result in paging to, as well as from, the filesystem) - but I believe > it is generally representative. There is no such thing as a 'sticky executable' on FreeBSD. See sticky(8). :-) Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 19 14: 3:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id BAFF537B41A for ; Wed, 19 Dec 2001 14:03:09 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id JAA04429; Thu, 20 Dec 2001 09:03:07 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37640) with ESMTP id <01KC33DPERHCVMM24Y@cim.alcatel.com.au>; Thu, 20 Dec 2001 09:03:05 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.6/8.11.6) id fBJM33u58592; Thu, 20 Dec 2001 09:03:03 +1100 Content-return: prohibited Date: Thu, 20 Dec 2001 09:03:03 +1100 From: Peter Jeremy Subject: Re: Swap performance (was: Getting rid of /usr file system) In-reply-to: ; from dwhite@resnet.uoregon.edu on Wed, Dec 19, 2001 at 01:48:42PM -0800 To: Doug White Cc: "Justin T. Gibbs" , freebsd-arch@FreeBSD.ORG Mail-Followup-To: Doug White , "Justin T. Gibbs" , freebsd-arch@FreeBSD.ORG Message-id: <20011220090303.T73243@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <20011220073554.Q73243@gsmx07.alcatel.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 On 2001-Dec-19 13:48:42 -0800, Doug White wrote: >On Thu, 20 Dec 2001, Peter Jeremy wrote: > >> The above is somewhat simplified - it ignores sticky executables >> (which transform filesystem I/O into swap I/O) and mmap(2) (which can >> result in paging to, as well as from, the filesystem) - but I believe >> it is generally representative. > >There is no such thing as a 'sticky executable' on FreeBSD. See sticky(8). >:-) I'm aware of that. The sticky bit reference was for traditional Unices - where the sticky bit on an executable meant that the text segment stuck in swap after the process exited. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 2:46: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (esplanaden.cybercity.dk [212.242.40.114]) by hub.freebsd.org (Postfix) with ESMTP id 77A4E37B43B for ; Thu, 20 Dec 2001 02:45:54 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id fBK8hg200602 for ; Thu, 20 Dec 2001 09:43:42 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org Subject: Kernel stack size and stacking: do we have a problem ? From: Poul-Henning Kamp Date: Thu, 20 Dec 2001 09:43:42 +0100 Message-ID: <600.1008837822@critter.freebsd.dk> 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 most of you have probably heard, I'm working on a stacking disk I/O layer (http://freefall.freebsd.org/~phk/Geom). This is as far as I know, only the third freely stackable subsystem in the kernel, the first two being VFS/filesystems and netgraph. The problem with stacking layered systems is that the naïve and simple implementation, just calling into the layer below, has basically unbounded kernel stack usage. Fortunately for us, neither VFS nor netgraph has had too much use yet, so we have not been excessively bothered by people running out of kernel-stack. It is well documented how to avoid the unbounded stack usage for such setups: simply queue the requests at each "gadget" and run a scheduler but this no where near as simple nor as fast as the direct call. So I guess we need to ask our selves the following questions: 1. What do we do when people start to run out of kernel stack because they stack filesystems ? a) Tell them not to. b) Tell them to increase UPAGES. c) Increase default UPAGES. d) Redesign VFS/VOP to avoid the problem. 2. Do we in general want to incur the overhead of scheduling in stacking layers or does increasing the kernel stack as needed make more sense ? 3. Would it be possible to make kernel stack size a sysctl ? 4. Would it make sense to build an intelligent kernel-stack overflow handling into the kernel, rather than "handling" this with a panic ? It should be trivially simple to make a function called enough_stack() which would return false if we were in the danger zone. This function could then be used to fail intelligently at strategic high-risk points in the kernel: int somefunction(...) { ... if (!enough_stack()) return (ENOMEM); ... } Think about it... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 4:40:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id E9F6F37B417; Thu, 20 Dec 2001 04:40:42 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA09572; Thu, 20 Dec 2001 23:40:33 +1100 Date: Thu, 20 Dec 2001 23:40:31 +1100 (EST) From: Bruce Evans X-X-Sender: To: Dima Dorfman Cc: Robert Watson , "Brian F. Feldman" , Subject: Re: xucred versioning and filling (was: MFC'ing xucred definition) In-Reply-To: <20011219005412.54A833E2F@bazooka.trit.org> Message-ID: <20011220232116.P607-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 19 Dec 2001, Dima Dorfman wrote: > Does anybody have any comments on this? I'd like to commit it > soon-ish, but don't plan to MFC it before 4.5 (since it's a new > interface, and I'd rather not set it in stone (-stable) yet). > > Index: sys/sys/ucred.h > > =================================================================== > > RCS file: /ref/cvsf/src/sys/sys/ucred.h,v > > retrieving revision 1.26 > > diff -u -r1.26 ucred.h > > --- sys/sys/ucred.h 2001/10/11 23:38:17 1.26 > > +++ sys/sys/ucred.h 2001/12/14 03:30:26 > > @@ -73,12 +73,13 @@ > > * any need to change the size of this or layout of its used fields. > > */ > > struct xucred { > > - u_short _cr_unused0; /* compatibility with old ucred */ > > + u_short cr_version; /* structure layout version */ > > uid_t cr_uid; /* effective user id */ > > short cr_ngroups; /* number of groups */ > > gid_t cr_groups[NGROUPS]; /* groups */ > > void *_cr_unused1; /* compatibility with old ucred */ > > }; > > +#define XUCRED_VERSION 0 _cr_unused0 does a poor job of reflecting the unused fields in the struct. The layout of the struct is actually: uint16_t cr_spare1; uint16_t cr_spare2; uint32_t cr_uid; int16_t cr_ngroups; int16_t cr_spare3; uint32_t cr_groups[NGROUPS]; uint32_t cr_spare4; Since you're changing the interface a little, I think the new field should use all the space available. RELENG_4 already uses it all, since it has the change from u_short to u_int for cr_ref. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 5: 9:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by hub.freebsd.org (Postfix) with ESMTP id 9B99A37B419 for ; Thu, 20 Dec 2001 05:09:15 -0800 (PST) Received: (from hch@localhost) by ns.caldera.de (8.11.1/8.11.1) id fBKD8tl09432; Thu, 20 Dec 2001 14:08:55 +0100 Date: Thu, 20 Dec 2001 14:08:55 +0100 From: Christoph Hellwig To: Warner Losh Cc: Joerg Wunsch , arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/isa fd.c Message-ID: <20011220140855.A8988@caldera.de> References: <20011219090256.E97821@uriah.heep.sax.de> <200112182253.fBIMrdM92149@harmony.village.org> <20011219090256.E97821@uriah.heep.sax.de> <200112190830.fBJ8UhM25504@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112190830.fBJ8UhM25504@harmony.village.org>; from imp@harmony.village.org on Wed, Dec 19, 2001 at 01:30:43AM -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, Dec 19, 2001 at 01:30:43AM -0700, Warner Losh wrote: > I don't think we can fix them. There's no pc98/include/param.h. > There's no pc98/include at all, but instead it uses the i386 ones. > But we could add the right goo there. > > I don't think there will be another IA32 port ever. o SGI Visual Workstation o SUN Roadrunner o DG NUMA machines To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 7: 7:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id B3C8F37B405; Thu, 20 Dec 2001 07:07:27 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16H4ov-00009x-00; Thu, 20 Dec 2001 17:09:17 +0200 From: Sheldon Hearn To: dougb@FreeBSD.org Cc: freebsd-arch@FreeBSD.org Subject: Why special handling of nfsclient kernel support in etc/rc? Date: Thu, 20 Dec 2001 17:09:17 +0200 Message-ID: <616.1008860957@axl.seasidesoftware.co.za> 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 Doug, I refer to the following change you made to src/etc/rc: revision 1.286 date: 2001/10/19 06:50:52; author: dougb; state: Exp; lines: +19 -4 Handle the lack of nfs server or client support in the kernel by kldload'ing the appropriate modules before enabling the service. Why is this needed? Shouldn't the vfsload() code in mount_nfs(1) handle this? error = getvfsbyname("nfs", &vfc); if (error && vfsisloadable("nfs")) { if(vfsload("nfs")) err(EX_OSERR, "vfsload(nfs)"); endvfsent(); /* clear cache */ error = getvfsbyname("nfs", &vfc); } I ask because I'd like to reintroduce my original "late mounting of remote filesystems" support before 4.5-RELEASE (with the release engineer's permission, of course). I noticed that my patch no longer applies because of the quoted change, but I can't see why the quoted change is necessary. Thanks, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 7:11:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from h132-197-179-27.gte.com (h132-197-179-27.gte.com [132.197.179.27]) by hub.freebsd.org (Postfix) with ESMTP id EA82937B41A for ; Thu, 20 Dec 2001 07:11:13 -0800 (PST) Received: (from ak03@localhost) by h132-197-179-27.gte.com (8.11.6/8.11.4) id fBKFAPL72358; Thu, 20 Dec 2001 10:10:25 -0500 (EST) (envelope-from ak03) Message-ID: X-Mailer: XFMail 1.5.1 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <616.1008860957@axl.seasidesoftware.co.za> Date: Thu, 20 Dec 2001 10:10:25 -0500 (EST) Organization: Verizon Laboratories Inc. From: "Alexander N. Kabaev" To: Sheldon Hearn Subject: RE: Why special handling of nfsclient kernel support in etc/rc? Cc: freebsd-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 rc script tries to set sysctl variables which are only available when NFS is present in the kernel. On 20-Dec-2001 Sheldon Hearn wrote: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 7:15:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id DBBE037B417 for ; Thu, 20 Dec 2001 07:15:38 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16H4wm-0000Co-00; Thu, 20 Dec 2001 17:17:24 +0200 From: Sheldon Hearn To: "Alexander N. Kabaev" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Why special handling of nfsclient kernel support in etc/rc? In-reply-to: Your message of "Thu, 20 Dec 2001 10:10:25 EST." Date: Thu, 20 Dec 2001 17:17:24 +0200 Message-ID: <793.1008861444@axl.seasidesoftware.co.za> 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, 20 Dec 2001 10:10:25 EST, "Alexander N. Kabaev" wrote: > rc script tries to set sysctl variables which are only > available when NFS is present in the kernel. But not at the point where NFS filesystems are mounted. Why can't we rely on mount_nfs's calls to vfsload() to do the right thing for us? I propose that the checks for the presence of NFS support should accompany the calls to sysctl, not the calls to mount_nfs. Ciao, SHeldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 7:47:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id E7B1A37B416; Thu, 20 Dec 2001 07:47:23 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 9203C81E0B; Thu, 20 Dec 2001 09:47:23 -0600 (CST) Date: Thu, 20 Dec 2001 09:47:23 -0600 From: Alfred Perlstein To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: Kernel stack size and stacking: do we have a problem ? Message-ID: <20011220094723.B48837@elvis.mu.org> References: <600.1008837822@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <600.1008837822@critter.freebsd.dk>; from phk@freebsd.org on Thu, Dec 20, 2001 at 09:43:42AM +0100 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 * Poul-Henning Kamp [011220 04:46] wrote: > > As most of you have probably heard, I'm working on a stacking > disk I/O layer (http://freefall.freebsd.org/~phk/Geom). > > This is as far as I know, only the third freely stackable subsystem > in the kernel, the first two being VFS/filesystems and netgraph. > > The problem with stacking layered systems is that the naïve and > simple implementation, just calling into the layer below, has > basically unbounded kernel stack usage. I think you're thinking way too hard about this, what would make sense is a near surefire way to catch stack overflow along with a panic message that was clear like "increase upages in kernel". Btw, Windows catches this and somehow assigns additional kernel stack pages to processes (or at least it seems). Do a search for "MinSp" or "MinSps". Lastly I would really avoid redesigning the VOPs however one suggestion would be to define an entry/exit function so that instead of having traditional stacking code like so: my_layer(void *foo) { if (mytest()) { NEXT_LAYER(foo); something; } return ERROR; } You could have: my_layer_entry(void *foo) { if (mytest()) return (foo, next_layer_ptr); else return ERROR; } my_layer_exit(void *foo) { something; } This would keep the stack at a near constant level at the expense of programming complexity. If you think about it though, it's quite like how network interrupts are handled, hardware queues the packets and then software runs after hardware returns. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 8: 7:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id CB88337B43B for ; Thu, 20 Dec 2001 08:07:03 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBKG72a27101; Thu, 20 Dec 2001 09:07:02 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fBKG70M36191; Thu, 20 Dec 2001 09:07:01 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112201607.fBKG70M36191@harmony.village.org> To: Christoph Hellwig Subject: Re: cvs commit: src/sys/isa fd.c Cc: Joerg Wunsch , arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 20 Dec 2001 14:08:55 +0100." <20011220140855.A8988@caldera.de> References: <20011220140855.A8988@caldera.de> <20011219090256.E97821@uriah.heep.sax.de> <200112182253.fBIMrdM92149@harmony.village.org> <20011219090256.E97821@uriah.heep.sax.de> <200112190830.fBJ8UhM25504@harmony.village.org> Date: Thu, 20 Dec 2001 09:07:00 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011220140855.A8988@caldera.de> Christoph Hellwig writes: : On Wed, Dec 19, 2001 at 01:30:43AM -0700, Warner Losh wrote: : > I don't think we can fix them. There's no pc98/include/param.h. : > There's no pc98/include at all, but instead it uses the i386 ones. : > But we could add the right goo there. : > : > I don't think there will be another IA32 port ever. : : o SGI Visual Workstation These are ibmpc clones, with a different BIOS interface. I've been told that FreeBSD/i386 works on them with only a slight hack. : o SUN Roadrunner : o DG NUMA machines These you have a point on, however. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 8:41:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2BE0D37B41A for ; Thu, 20 Dec 2001 08:41:17 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fBKGepi84445; Thu, 20 Dec 2001 11:40:51 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 20 Dec 2001 11:40:51 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Alexander N. Kabaev" Cc: Sheldon Hearn , freebsd-arch@FreeBSD.ORG Subject: RE: Why special handling of nfsclient kernel support in etc/rc? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG We need a better general solution for sysctls relating to this, I suspect. There are plenty of sysctls for dynamically loadable modules, and depending on when they are loaded, and when sysctl.conf gets processed, you can actually get fairly unpredictable behavior :-). That doesn't mean there's necessarily a problem, but it's worth considering whether there's a solution if it is a problem. Should there be a way to have sysctl's set as part of a module loading procedure? Do we have problems with any other common sysctls that might be set in /etc/sysctl.conf? Right now, some of the major components of the kernel that export sysctls aren't loadable as modules. But you could imagine more problems of this sort if they were. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Thu, 20 Dec 2001, Alexander N. Kabaev wrote: > rc script tries to set sysctl variables which are only > available when NFS is present in the kernel. > > On 20-Dec-2001 Sheldon Hearn wrote: > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 8:44: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 68E1A37B419; Thu, 20 Dec 2001 08:44:00 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16H6KN-0000oe-00; Thu, 20 Dec 2001 18:45:51 +0200 From: Sheldon Hearn To: Robert Watson Cc: "Alexander N. Kabaev" , freebsd-arch@FreeBSD.ORG Subject: Re: Why special handling of nfsclient kernel support in etc/rc? In-reply-to: Your message of "Thu, 20 Dec 2001 11:40:51 EST." Date: Thu, 20 Dec 2001 18:45:51 +0200 Message-ID: <3139.1008866751@axl.seasidesoftware.co.za> 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, 20 Dec 2001 11:40:51 EST, Robert Watson wrote: > We need a better general solution for sysctls relating to this, I suspect. Actually, I don't think Alexander's assertion that the manual loading of NFS client support in rc supports sysctl manipulation. Looking at the scripts, sysctl stuff is done in rc.network, but only if the nfs sysctl node exists. It tries to do its own module loading there as well. So I still need an answer back from Doug about this, although your point is valid. I just don't want a discussion on a generalized solution for dynamically loaded sysctls to hijack my question. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 8:48:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.disney.com (mail.disney.com [204.128.192.15]) by hub.freebsd.org (Postfix) with ESMTP id 1F1C937B417 for ; Thu, 20 Dec 2001 08:48:20 -0800 (PST) Received: from Hermes10.corp.disney.com (hermes10.corp.disney.com [153.7.110.102]) by mail.disney.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBKGkff02724 for ; Thu, 20 Dec 2001 08:46:42 -0800 (PST) Received: from [172.30.50.1] by hermes.corp.disney.com with ESMTP for arch@FreeBSD.ORG; Thu, 20 Dec 2001 08:47:33 -0800 Received: from plio.fan.fa.disney.com (plio.fan.fa.disney.com [153.7.118.2]) by pecos.fa.disney.com (8.11.3/8.11.3) with ESMTP id fBKGmF325425 for ; Thu, 20 Dec 2001 08:48:15 -0800 (PST) Received: from mercury.fan.fa.disney.com (mercury.fan.fa.disney.com [153.7.119.1]) by plio.fan.fa.disney.com (8.9.2/8.9.2) with ESMTP id IAA28565 for ; Thu, 20 Dec 2001 08:48:13 -0800 (PST) (envelope-from Jim.Pirzyk@disney.com) Received: from [172.30.5.103] by mercury.fan.fa.disney.com; Thu, 20 Dec 2001 08:48:11 -0800 Content-Type: text/plain; charset="iso-8859-1" From: "Pirzyk, Jim" Organization: Walt Disney Feature Animation To: Warner Losh , Christoph Hellwig Subject: Re: cvs commit: src/sys/isa fd.c Date: Thu, 20 Dec 2001 08:48:11 -0800 X-Mailer: KMail [version 1.3] Cc: Joerg Wunsch , arch@FreeBSD.ORG References: <20011220140855.A8988@caldera.de> <200112190830.fBJ8UhM25504@harmony.village.org> <200112201607.fBKG70M36191@harmony.village.org> In-Reply-To: <200112201607.fBKG70M36191@harmony.village.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: 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 Thursday 20 December 2001 08:07 am, Warner Losh wrote: > In message <20011220140855.A8988@caldera.de> Christoph Hellwig writes: > : On Wed, Dec 19, 2001 at 01:30:43AM -0700, Warner Losh wrote: > : > I don't think we can fix them. There's no pc98/include/param.h. > : > There's no pc98/include at all, but instead it uses the i386 ones. > : > But we could add the right goo there. > : > > : > I don't think there will be another IA32 port ever. > : > : o SGI Visual Workstation > > These are ibmpc clones, with a different BIOS interface. I've been > told that FreeBSD/i386 works on them with only a slight hack. I have been running FreeBSD on an SGI 550 for a while now without any hacks. Also this is a dead line from SGI, as they gave up their IA32 line in favor of the IA64 line. - JimP > > : o SUN Roadrunner > : o DG NUMA machines > > These you have a point on, however. > > Warner > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- --- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $ __o Jim.Pirzyk@disney.com ------------- pirzyk@freebsd.org _'\<,_ Senior Systems Engineer, Walt Disney Feature Animation (*)/ (*) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 10:31:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tomts14-srv.bellnexxia.net (tomts14.bellnexxia.net [209.226.175.35]) by hub.freebsd.org (Postfix) with ESMTP id 8D16337B417; Thu, 20 Dec 2001 10:31:39 -0800 (PST) Received: from khan.anarcat.dyndns.org ([65.94.189.35]) by tomts16-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20011220183113.WUZQ19575.tomts16-srv.bellnexxia.net@khan.anarcat.dyndns.org>; Thu, 20 Dec 2001 13:31:13 -0500 Received: from shall.anarcat.dyndns.org (shall.anarcat.dyndns.org [192.168.0.1]) by khan.anarcat.dyndns.org (Postfix) with ESMTP id B6551189D; Thu, 20 Dec 2001 13:31:10 -0500 (EST) Received: by shall.anarcat.dyndns.org (Postfix, from userid 1000) id 7A13F20ACB; Thu, 20 Dec 2001 13:31:05 -0500 (EST) Date: Thu, 20 Dec 2001 13:31:04 -0500 From: The Anarcat To: freebsd-arch@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: making /usr/share/mk apps PREFIX-independant??? Message-ID: <20011220183103.GH2956@shall.anarcat.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8w3uRX/HFJGApMzv" Content-Disposition: inline User-Agent: Mutt/1.3.24i 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 --8w3uRX/HFJGApMzv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [posted to -arch, and CC'd to hackers since I have no idea as to where this belongs, please redirect if necessary] Hi. As a developper working in the FreeBSD/ports paradigm, and developping exclusively for FreeBSD through the libh project, it has come to my attention that applications developped through /usr/share/mk Makefiles (in particular bsd.prog.mk and bsd.lib.mk) do not respect PREFIX.=20 That is, the libh Makefiles, as set now, install in /usr no matter what. There is no real alternative. Setting DESTDIR will install in /${DESTDIR}/usr, without changing the PREFIX (/usr).=20 In other words, apps developped using /usr/share/mk makefiles are incompatible with the ports collection PREFIX-independance paradigm. That sucks. This is a problem which must be solved. As a hack, the libh port uses a custom install target in the ports skeleton (ie, it doesn't use libh install targets). How I see it, the .mk files must be hacked. One could try such a replace pattern, I guess: s!install(.*)${DESTDIR}!install\1${PREFIX}/${DESTDIR}! I tried to produce a significant patch, and I failed. I do not understand how some files end up in /bin and some other in /usr/bin. If someone can help me with that, I will happily start hacking on the mk files, but in the meantime, I'm lost. thanks, A. --8w3uRX/HFJGApMzv 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 iEYEARECAAYFAjwiLmcACgkQttcWHAnWiGdNfwCeN0cuYhJ8DEoNicPu4uwubr3X I9wAnAzmbCChXhqDPgF5u3fiHDrmPptd =zkxs -----END PGP SIGNATURE----- --8w3uRX/HFJGApMzv-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 10:51:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 8443237B431; Thu, 20 Dec 2001 10:50:25 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id TAA02125; Thu, 20 Dec 2001 19:50:20 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.11.6/8.11.6) id fBKIaI846300; Thu, 20 Dec 2001 19:36:18 +0100 (MET) (envelope-from j) Date: Thu, 20 Dec 2001 19:36:18 +0100 From: Joerg Wunsch To: Bruce Evans Cc: Ruslan Ermilov , developers@FreeBSD.org, arch@FreeBSD.org Subject: Re: cvs commit: src/sys/isa fd.c Message-ID: <20011220193618.B19756@uriah.heep.sax.de> Reply-To: Joerg Wunsch Mail-Followup-To: Joerg Wunsch , Bruce Evans , Ruslan Ermilov , developers@freebsd.org, arch@freebsd.org References: <20011219095119.B93645@sunbay.com> <20011220235518.V673-100000@gamplex.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: <20011220235518.V673-100000@gamplex.bde.org>; from bde@zeta.org.au on Fri, Dec 21, 2001 at 12:11:13AM +1100 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E 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 Evans wrote: > > This is because _MACHINE_ARCH is a bogus define. > > True. It doesn't seem to be used for anything except to break > netgraph/ng_vjc.c in the same way as fd.c ... > > Then, the #if _MACHINE_ARCH == i386 becomes #if 1 == 1. > > Actually, it becomes `#if 0 == 0' 8-8. Then i vote to either drop the macros _MACHINE and _MACHINE_ARCH completely from /sys/*/include/param.h, or to provide a set of unique constants they will be defined to so they can actually be used in cpp comparisions. What does NetBSD do here? It would surprise me if they didn't have a method to distinguish between their various machines at the cpp level. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 11: 0:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 3109337B41E; Thu, 20 Dec 2001 11:00:12 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011220190011.DGIW6450.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 20 Dec 2001 19:00:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA52167; Thu, 20 Dec 2001 10:51:53 -0800 (PST) Date: Thu, 20 Dec 2001 10:51:52 -0800 (PST) From: Julian Elischer To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: Kernel stack size and stacking: do we have a problem ? In-Reply-To: <600.1008837822@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE 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 Netgraph has a bounding scheme that archie and I came up with, but it has not been committed yet. basically, in the -current version, the mbufs are passed with an itteration counter, and=20 if you directly execute another module you increment it. If you queue the item you clear it to 0. After it reaches a limit of N the subsystem will=20 queue it rather than try run the next layer directly. I have code to do that here and I've been thinking about checking it in.. On Thu, 20 Dec 2001, Poul-Henning Kamp wrote: >=20 > As most of you have probably heard, I'm working on a stacking > disk I/O layer (http://freefall.freebsd.org/~phk/Geom). >=20 > This is as far as I know, only the third freely stackable subsystem > in the kernel, the first two being VFS/filesystems and netgraph. >=20 > The problem with stacking layered systems is that the na=EFve and > simple implementation, just calling into the layer below, has > basically unbounded kernel stack usage. >=20 > Fortunately for us, neither VFS nor netgraph has had too much use > yet, so we have not been excessively bothered by people running > out of kernel-stack. >=20 > It is well documented how to avoid the unbounded stack usage for > such setups: simply queue the requests at each "gadget" and run > a scheduler but this no where near as simple nor as fast as the > direct call. >=20 > So I guess we need to ask our selves the following questions: >=20 > 1. What do we do when people start to run out of kernel stack > because they stack filesystems ? > =09a) Tell them not to. > =09b) Tell them to increase UPAGES. > =09c) Increase default UPAGES. > =09d) Redesign VFS/VOP to avoid the problem. >=20 > 2. Do we in general want to incur the overhead of scheduling > in stacking layers or does increasing the kernel stack as > needed make more sense ? >=20 > 3. Would it be possible to make kernel stack size a sysctl ? >=20 > 4. Would it make sense to build an intelligent kernel-stack > overflow handling into the kernel, rather than "handling" > this with a panic ? >=20 > It should be trivially simple to make a function called > enough_stack() which would return false if we were in the > danger zone. This function could then be used to fail > intelligently at strategic high-risk points in the kernel: >=20 > =09int > =09somefunction(...) > =09{ > =09=09... >=20 > =09=09if (!enough_stack()) > =09=09=09return (ENOMEM); > =09=09... > =09} >=20 > Think about it... >=20 > --=20 > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetenc= e. >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 11:21:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 82BFB37B41E; Thu, 20 Dec 2001 11:20:08 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011220192008.FLSG19716.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 20 Dec 2001 19:20:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA52246; Thu, 20 Dec 2001 11:05:00 -0800 (PST) Date: Thu, 20 Dec 2001 11:04:59 -0800 (PST) From: Julian Elischer To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: Kernel stack size and stacking: do we have a problem ? In-Reply-To: <600.1008837822@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE 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, 20 Dec 2001, Poul-Henning Kamp wrote: >=20 > As most of you have probably heard, I'm working on a stacking > disk I/O layer (http://freefall.freebsd.org/~phk/Geom). >=20 > This is as far as I know, only the third freely stackable subsystem > in the kernel, the first two being VFS/filesystems and netgraph. >=20 > The problem with stacking layered systems is that the na=EFve and > simple implementation, just calling into the layer below, has > basically unbounded kernel stack usage. >=20 > Fortunately for us, neither VFS nor netgraph has had too much use > yet, so we have not been excessively bothered by people running > out of kernel-stack. >=20 > It is well documented how to avoid the unbounded stack usage for > such setups: simply queue the requests at each "gadget" and run > a scheduler but this no where near as simple nor as fast as the > direct call. >=20 > So I guess we need to ask our selves the following questions: >=20 > 1. What do we do when people start to run out of kernel stack > because they stack filesystems ? > =09a) Tell them not to. > =09b) Tell them to increase UPAGES. > =09c) Increase default UPAGES. > =09d) Redesign VFS/VOP to avoid the problem. A couple of points.. Firstly, the stacks were just increased.. with an unmapped guard page at the end (well it's an option). DOesn't solve the problem,.. just related info. Secondly UPAGES will make no difference as it no longer exists.. use KSTACK_PAGES instead. Also we should implement the=20 'stack-hogs' patch for gcc that there are 3 versions around for. Some fs layers are just massive HOGS of space for very little reason. >=20 > 2. Do we in general want to incur the overhead of scheduling > in stacking layers or does increasing the kernel stack as > needed make more sense ? Try an adaptive scheme such as I mentionned above.. 99.99% of the time it avoids scheduling. >=20 > 3. Would it be possible to make kernel stack size a sysctl ? hmmm, it might but it would be tricky because the constant KSTACK_PAGES is used for both allocation and deallocation so if you just changed it to be a variable, and changed it in between...... This is about to change BTW in KSE as there is a kstack per thread and the allocation routines will be different. The problem is that I'm caching threads and their stacks for quick reallocation so I'd have to check each stack as I pass it out and check whether I need to resize it to match the new size.. >=20 > 4. Would it make sense to build an intelligent kernel-stack > overflow handling into the kernel, rather than "handling" > this with a panic ? >=20 Presently we have a guard page (unmapped) We could possibly allocate more pages and fill them in if a page fault occurs. It would be quite a change to the current code but it COULD be done. (but not by me.. you'd have to have a good handle on the in-kernel fault handling, which was hair-raising last time I looked) > It should be trivially simple to make a function called > enough_stack() which would return false if we were in the > danger zone. This function could then be used to fail > intelligently at strategic high-risk points in the kernel: >=20 > =09int > =09somefunction(...) > =09{ > =09=09... >=20 > =09=09if (!enough_stack()) > =09=09=09return (ENOMEM); > =09=09... > =09} >=20 > Think about it... We COULD have a page available to map into the guard page that woudl allow completion but the activation of it would cause such a low-stack state to be entered. >=20 > --=20 > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetenc= e. >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 11:40:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 2B47637B41A; Thu, 20 Dec 2001 11:40:11 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011220194010.JJKB20122.rwcrmhc53.attbi.com@InterJet.elischer.org>; Thu, 20 Dec 2001 19:40:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA52353; Thu, 20 Dec 2001 11:26:17 -0800 (PST) Date: Thu, 20 Dec 2001 11:26:16 -0800 (PST) From: Julian Elischer To: Alfred Perlstein Cc: Poul-Henning Kamp , arch@freebsd.org Subject: Re: Kernel stack size and stacking: do we have a problem In-Reply-To: <20011220094723.B48837@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE 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, 20 Dec 2001, Alfred Perlstein wrote: > * Poul-Henning Kamp [011220 04:46] wrote: > >=20 > > As most of you have probably heard, I'm working on a stacking > > disk I/O layer (http://freefall.freebsd.org/~phk/Geom). > >=20 > > This is as far as I know, only the third freely stackable subsystem > > in the kernel, the first two being VFS/filesystems and netgraph. > >=20 > > The problem with stacking layered systems is that the na=EFve and > > simple implementation, just calling into the layer below, has > > basically unbounded kernel stack usage. > My first version of this tried to not use recursion, but rather iteration, where the output of each layer was supplied back to the caller (the framework), who's job was to then call the next layer. The return could be a linked list of multiple work requests in the case of a raid array, with each item referencing a different 'next' module. The difficulty was in getting the reverse flow of error and status information to flow in exactly the reverse path. I ended up having to pass completed work units back through a second entry point in each case. The returned items from each entry point had been set up during processing with a pointer to=20 the next module that should process them. The layers were connected much like netgraph nodes are now.. (raidgraph anyone?) I ended up just going for stack versions, however that had a lot of problems too. =20 > I think you're thinking way too hard about this, what would make > sense is a near surefire way to catch stack overflow along with a > panic message that was clear like "increase upages in kernel". err upages has been gone for 4 months now.. try KSTACK_PAGES. >=20 > Btw, Windows catches this and somehow assigns additional kernel > stack pages to processes (or at least it seems). Do a search for > "MinSp" or "MinSps". it can be done.. who has the time and interest? >=20 > Lastly I would really avoid redesigning the VOPs however one > suggestion would be to define an entry/exit function so that > instead of having traditional stacking code like so: >=20 > my_layer(void *foo) > { >=20 > if (mytest()) { > NEXT_LAYER(foo); > something; > } > return ERROR; > } >=20 > You could have: >=20 > my_layer_entry(void *foo) > { >=20 > if (mytest()) > return (foo, next_layer_ptr); > else > return ERROR; > } >=20 > my_layer_exit(void *foo) > { >=20 > something; >=20 > } >=20 This is similar to the scheme I originally did and it does work, but it also has a lot of complications.. for example you need to keep track rigidly of how many requests you=20 passed back to process further down and how many you saw coming back up.. in a recursive scheme you get this almost for free but it can get wierd in iterative schemes. > This would keep the stack at a near constant level at the expense > of programming complexity. Netgraph in -current has a hybrid of these two schemes. It queues items AND it runs directly, depending on dynamic state at the time of the execution request. If it queues the data, it also puts the appropriate queue onto a list of queues with work, and it will go service the next entry on that list as soon as it's finished what it's doing now. The same scheme may work for disk layering too. It's implemented in order to make the netgraph capable of optimally running in a true SMP environment, while providing the ability to reconfigure the graph, while data is traversing it. > If you think about it though, it's quite > like how network interrupts are handled, hardware queues the packets > and then software runs after hardware returns. >=20 Though some people are trying to change this, which leads to teh possibility of circular packet paths.. (rcv->ip_input->ip_forward->ip_output->if_loop->ip_input->........) > -Alfred >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 11:51: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 6C75B37B405; Thu, 20 Dec 2001 11:51:05 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 1D48A81D01; Thu, 20 Dec 2001 13:51:05 -0600 (CST) Date: Thu, 20 Dec 2001 13:51:05 -0600 From: Alfred Perlstein To: Julian Elischer Cc: Poul-Henning Kamp , arch@freebsd.org Subject: Re: Kernel stack size and stacking: do we have a problem ? Message-ID: <20011220135105.F48837@elvis.mu.org> References: <600.1008837822@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from julian@elischer.org on Thu, Dec 20, 2001 at 10:51:52AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Julian Elischer [011220 13:00] wrote: > Netgraph has a bounding scheme that archie and I came up with, but > it has not been committed yet. basically, in the -current version, > the mbufs are passed with an itteration counter, and > if you directly execute another module you increment it. If you queue the > item you clear it to 0. After it reaches a limit of N the subsystem will > queue it rather than try run the next layer directly. > I have code to do that here and I've been thinking about checking it in.. That sounds like an excellent idea. You're saying basically switch to phk's thread dispatch method when you hit N levels of nesting, right? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 11:55:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 33A1437B417; Thu, 20 Dec 2001 11:55:41 -0800 (PST) Received: (from dg@localhost) by root.com (8.11.2/8.11.2) id fBKJkR415988; Thu, 20 Dec 2001 11:46:27 -0800 (PST) (envelope-from dg) Date: Thu, 20 Dec 2001 11:46:27 -0800 From: David Greenman To: Julian Elischer Cc: Poul-Henning Kamp , arch@freebsd.org Subject: Re: Kernel stack size and stacking: do we have a problem ? Message-ID: <20011220114627.C15588@nexus.root.com> References: <600.1008837822@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from julian@elischer.org on Thu, Dec 20, 2001 at 11:04:59AM -0800 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 >> 3. Would it be possible to make kernel stack size a sysctl ? > >hmmm, it might but it would be tricky because the constant KSTACK_PAGES >is used for both allocation and deallocation so if you just changed it to >be a variable, and changed it in between...... >This is about to change BTW in KSE as there is a kstack per thread >and the allocation routines will be different. >The problem is that I'm caching threads and their stacks for quick >reallocation so I'd have to check each stack as I pass it out and check >whether I need to resize it to match the new size.. I'd like to point out that having stacks of different sizes is going to cause VM fragmentation problems if VM space for the system maximum size isn't preallocated for everything, and "growing" a stack could be very difficult or impossible if VM space hasn't already been preallocated (since it would have to be copied and fixed up). -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 12:16:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 2C8C237B41B for ; Thu, 20 Dec 2001 12:16:26 -0800 (PST) Received: (qmail 22259 invoked from network); 20 Dec 2001 20:16:25 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 20 Dec 2001 20:16:25 -0000 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: <600.1008837822@critter.freebsd.dk> Date: Thu, 20 Dec 2001 12:16:08 -0800 (PST) From: John Baldwin To: Poul-Henning Kamp Subject: RE: Kernel stack size and stacking: do we have a problem ? Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > 2. Do we in general want to incur the overhead of scheduling > in stacking layers or does increasing the kernel stack as > needed make more sense ? I prefer a method where by when you call into each level, you check enough_stack(), and if it fails, you queue the request so a worker kthread can handle it and wakeup you up with the completion status stored in the item you just queued. This lets us call down directly into the stack as far as we can, but then bail to the asynch model if we run out of stack. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 12:16:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id E984037B416 for ; Thu, 20 Dec 2001 12:16:27 -0800 (PST) Received: (qmail 22275 invoked from network); 20 Dec 2001 20:16:27 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 20 Dec 2001 20:16:27 -0000 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: <616.1008860957@axl.seasidesoftware.co.za> Date: Thu, 20 Dec 2001 12:16:09 -0800 (PST) From: John Baldwin To: Sheldon Hearn Subject: RE: Why special handling of nfsclient kernel support in etc/rc? Cc: freebsd-arch@FreeBSD.org, dougb@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 20-Dec-01 Sheldon Hearn wrote: > > Hi Doug, > > I refer to the following change you made to src/etc/rc: > > revision 1.286 > date: 2001/10/19 06:50:52; author: dougb; state: Exp; lines: +19 -4 > Handle the lack of nfs server or client support in the kernel by > kldload'ing the appropriate modules before enabling the service. > > Why is this needed? Shouldn't the vfsload() code in mount_nfs(1) handle > this? > > error = getvfsbyname("nfs", &vfc); > if (error && vfsisloadable("nfs")) { > if(vfsload("nfs")) > err(EX_OSERR, "vfsload(nfs)"); > endvfsent(); /* clear cache */ > error = getvfsbyname("nfs", &vfc); > } There's no nfs.ko. mount_nfs should be updated to load 'nfsclient' instead. If this happens, then arguably, the nfs_client_enable variable in rc.conf should just go away and not be used. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 12:40: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id AB69E37B416; Thu, 20 Dec 2001 12:40:06 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011220204006.LEAO20122.rwcrmhc53.attbi.com@InterJet.elischer.org>; Thu, 20 Dec 2001 20:40:06 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA52636; Thu, 20 Dec 2001 12:30:46 -0800 (PST) Date: Thu, 20 Dec 2001 12:30:45 -0800 (PST) From: Julian Elischer To: Alfred Perlstein Cc: Poul-Henning Kamp , arch@freebsd.org Subject: Re: Kernel stack size and stacking: do we have a problem ? In-Reply-To: <20011220135105.F48837@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG basically yes, after N levels, switch to what netisr() does. then you get another N levels :-) The reason I hadn't checked it in is because I was thinking about whether it should be N levels or N bytes of stack used.... On Thu, 20 Dec 2001, Alfred Perlstein wrote: > * Julian Elischer [011220 13:00] wrote: > > Netgraph has a bounding scheme that archie and I came up with, but > > it has not been committed yet. basically, in the -current version, > > the mbufs are passed with an itteration counter, and > > if you directly execute another module you increment it. If you queue the > > item you clear it to 0. After it reaches a limit of N the subsystem will > > queue it rather than try run the next layer directly. > > I have code to do that here and I've been thinking about checking it in.. > > That sounds like an excellent idea. > > You're saying basically switch to phk's thread dispatch method when > you hit N levels of nesting, right? > > -Alfred > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 12:41:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 765B637B41B for ; Thu, 20 Dec 2001 12:41:30 -0800 (PST) Received: (qmail 4635 invoked from network); 20 Dec 2001 20:41:29 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 20 Dec 2001 20:41:29 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 20 Dec 2001 12:41:12 -0800 (PST) From: John Baldwin To: Julian Elischer Subject: Re: Kernel stack size and stacking: do we have a problem ? Cc: arch@freebsd.org, Poul-Henning Kamp , Alfred Perlstein Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 20-Dec-01 Julian Elischer wrote: > basically yes, after N levels, switch to what netisr() does. > then you get another N levels :-) The reason I hadn't checked it in is > because I was thinking about whether it should be N levels or N bytes of > stack used.... It should be based on how much stack room is left. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 13: 0:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id EBCEB37B416; Thu, 20 Dec 2001 13:00:20 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011220210020.ISMT19716.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 20 Dec 2001 21:00:20 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA52710; Thu, 20 Dec 2001 12:48:06 -0800 (PST) Date: Thu, 20 Dec 2001 12:48:05 -0800 (PST) From: Julian Elischer To: John Baldwin Cc: arch@freebsd.org, Poul-Henning Kamp , Alfred Perlstein Subject: Re: Kernel stack size and stacking: do we have a problem ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 20 Dec 2001, John Baldwin wrote: > > On 20-Dec-01 Julian Elischer wrote: > > basically yes, after N levels, switch to what netisr() does. > > then you get another N levels :-) The reason I hadn't checked it in is > > because I was thinking about whether it should be N levels or N bytes of > > stack used.... > > It should be based on how much stack room is left. yes that is what I was thinking.. curthread->kstack is the last valid location so it's actually very easy. But I wanted to actually 'drop' the packet if it went through a total of some maximum number of nodes allowed.. e.g. 64.. I can't imagine a practical application that requires a packet to go through 64 successive layers of en(de)capsulation.. :-) It may be worth keeping a counter AND doing the stack check. > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 13:15:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id 66AFE37B417 for ; Thu, 20 Dec 2001 13:15:44 -0800 (PST) Received: (qmail 32377 invoked from network); 20 Dec 2001 21:15:43 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 20 Dec 2001 21:15:43 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 20 Dec 2001 13:15:26 -0800 (PST) From: John Baldwin To: Julian Elischer Subject: Re: Kernel stack size and stacking: do we have a problem ? Cc: Alfred Perlstein , Poul-Henning Kamp , 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 20-Dec-01 Julian Elischer wrote: > > > On Thu, 20 Dec 2001, John Baldwin wrote: > >> >> On 20-Dec-01 Julian Elischer wrote: >> > basically yes, after N levels, switch to what netisr() does. >> > then you get another N levels :-) The reason I hadn't checked it in is >> > because I was thinking about whether it should be N levels or N bytes of >> > stack used.... >> >> It should be based on how much stack room is left. > yes that is what I was thinking.. > > curthread->kstack is the last valid location so it's actually very easy. > > But I wanted to actually 'drop' the packet if it went through > a total of some maximum number of nodes allowed.. > e.g. 64.. I can't imagine a practical application that requires a packet > to go through 64 successive layers of en(de)capsulation.. :-) > > It may be worth keeping a counter AND doing the stack check. The counter is something that is netgraph specific. The idea of checking the stack and pushing the work off onto a thread if we run out of room isn't. :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 13:19:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 49F7537B419; Thu, 20 Dec 2001 13:19:26 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id fBKLHTl02801; Thu, 20 Dec 2001 22:17:29 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Julian Elischer Cc: John Baldwin , arch@FreeBSD.org, Alfred Perlstein Subject: Re: Kernel stack size and stacking: do we have a problem ? In-Reply-To: Your message of "Thu, 20 Dec 2001 12:48:05 PST." Date: Thu, 20 Dec 2001 22:17:29 +0100 Message-ID: <2799.1008883049@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian, doesn't this give you an ordering issue ? Imagine this setup (lots of stuff) | module 1 | module 2 | module 3 With the added information that the path through module 2 can be very short or very long, depending on the packet contents. Now, module 1 sends a request down through module 2 which takes the long path and consequently ends up being queued a module 3. We unwind/return back up through module 2 and module 1 issues another request which happens to take the short path through module 2 and consequently directly calls into module 3. Now the two requests have been reordered without any of the modules having any hint of this. The obvious ways to fix this is to continue to queue once you queue on a module (in other words: always queue if the queue is non-empty) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 13:21:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id BFACD37B405 for ; Thu, 20 Dec 2001 13:21:42 -0800 (PST) Received: (qmail 4103 invoked from network); 20 Dec 2001 21:21:42 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 20 Dec 2001 21:21:42 -0000 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: <2799.1008883049@critter.freebsd.dk> Date: Thu, 20 Dec 2001 13:21:24 -0800 (PST) From: John Baldwin To: Poul-Henning Kamp Subject: Re: Kernel stack size and stacking: do we have a problem ? Cc: Alfred Perlstein , arch@FreeBSD.org, Julian Elischer Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 20-Dec-01 Poul-Henning Kamp wrote: > > Julian, doesn't this give you an ordering issue ? > > Imagine this setup > > (lots of stuff) > | > module 1 > | > module 2 > | > module 3 > > With the added information that the path through module 2 can be very > short or very long, depending on the packet contents. > > Now, module 1 sends a request down through module 2 which takes the > long path and consequently ends up being queued a module 3. We > unwind/return back up through module 2 and module 1 issues another > request which happens to take the short path through module 2 and > consequently directly calls into module 3. > > Now the two requests have been reordered without any of the modules > having any hint of this. > > The obvious ways to fix this is to continue to queue once you queue > on a module (in other words: always queue if the queue is non-empty) Hmm, I was thinking that the original request would block when it queued the request, and would be woken up when the original request was completed by the worker thread. Thus, for each producer, only one item should be in the queue at a time (plus any sub events it may create), but that multiple producers may be putting events onto the queue handled by the worker thread. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 13:33:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by hub.freebsd.org (Postfix) with ESMTP id 6D71D37B419; Thu, 20 Dec 2001 13:33:22 -0800 (PST) Received: from yahoo-inc.com (zoot.corp.yahoo.com [216.145.52.89]) by mrout1.yahoo.com (8.11.6/8.11.6/y.out) with ESMTP id fBKLX7s10603; Thu, 20 Dec 2001 13:33:07 -0800 (PST) Message-ID: <3C225913.ADAE34EF@yahoo-inc.com> Date: Thu, 20 Dec 2001 13:33:07 -0800 From: Doug Barton X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin Cc: Sheldon Hearn , freebsd-arch@FreeBSD.org Subject: Re: Why special handling of nfsclient kernel support in etc/rc? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Baldwin wrote: > > On 20-Dec-01 Sheldon Hearn wrote: > > > > Hi Doug, > > > > I refer to the following change you made to src/etc/rc: > > > > revision 1.286 > > date: 2001/10/19 06:50:52; author: dougb; state: Exp; lines: +19 -4 > > Handle the lack of nfs server or client support in the kernel by > > kldload'ing the appropriate modules before enabling the service. > > > > Why is this needed? Shouldn't the vfsload() code in mount_nfs(1) handle > > this? > > > > error = getvfsbyname("nfs", &vfc); > > if (error && vfsisloadable("nfs")) { > > if(vfsload("nfs")) > > err(EX_OSERR, "vfsload(nfs)"); > > endvfsent(); /* clear cache */ > > error = getvfsbyname("nfs", &vfc); > > } > > There's no nfs.ko. mount_nfs should be updated to load 'nfsclient' instead. > If this happens, then arguably, the nfs_client_enable variable in rc.conf > should just go away and not be used. Yeah, the hack I put into rc was always meant to be temporary until the issue was addressed more progammatically. I just did what I could to make it work. :) -- Doug Barton, Yahoo! DNS Administration and Development If you're never wrong, you're not trying hard enough. Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 13:34:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 1A57A37B417; Thu, 20 Dec 2001 13:33:56 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id fBKLW3l03151; Thu, 20 Dec 2001 22:32:03 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: John Baldwin Cc: Alfred Perlstein , arch@FreeBSD.org, Julian Elischer Subject: Re: Kernel stack size and stacking: do we have a problem ? In-Reply-To: Your message of "Thu, 20 Dec 2001 13:21:24 PST." Date: Thu, 20 Dec 2001 22:32:03 +0100 Message-ID: <3149.1008883923@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , John Baldwin writes: >> Now the two requests have been reordered without any of the modules >> having any hint of this. >> >> The obvious ways to fix this is to continue to queue once you queue >> on a module (in other words: always queue if the queue is non-empty) > >Hmm, I was thinking that the original request would block when it queued the >request, and would be woken up when the original request was completed by the >worker thread. Thus, for each producer, only one item should be in the queue >at a time (plus any sub events it may create), but that multiple producers may >be putting events onto the queue handled by the worker thread. Ahh, but here you run into the zig-zag thing we two have talked about earlier: what if I am running in an interrupt thread at this time ? This could be an incoming packet which triggers an outgoing response or this could be a disk-write complete which triggers the write of the other copy in the mirror. You cannot expect to be moving uniformly up (or down) the tree in these kinds of layers so sleeping would be bad, and as far as my intuition tells me, could lead to starvation and deadlock. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 13:35:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 0CD7137B405 for ; Thu, 20 Dec 2001 13:35:10 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBKLfwI02982; Thu, 20 Dec 2001 13:41:59 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112202141.fBKLfwI02982@mass.dis.org> To: Christoph Hellwig Cc: Warner Losh , Joerg Wunsch , arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/isa fd.c In-Reply-To: Message from Christoph Hellwig of "Thu, 20 Dec 2001 14:08:55 +0100." <20011220140855.A8988@caldera.de> Date: Thu, 20 Dec 2001 13:41:58 -0800 From: Mike Smith 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, Dec 19, 2001 at 01:30:43AM -0700, Warner Losh wrote: > > I don't think we can fix them. There's no pc98/include/param.h. > > There's no pc98/include at all, but instead it uses the i386 ones. > > But we could add the right goo there. > > > > I don't think there will be another IA32 port ever. > > o SGI Visual Workstation > o SUN Roadrunner > o DG NUMA machines I am assuming that this is in support of the assertion, correct? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 13:40:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id C56E437B419; Thu, 20 Dec 2001 13:40:08 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011220214008.HXNV6450.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 20 Dec 2001 21:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA52966; Thu, 20 Dec 2001 13:26:09 -0800 (PST) Date: Thu, 20 Dec 2001 13:26:08 -0800 (PST) From: Julian Elischer To: Poul-Henning Kamp Cc: John Baldwin , arch@FreeBSD.org, Alfred Perlstein Subject: Re: Kernel stack size and stacking: do we have a problem ? In-Reply-To: <2799.1008883049@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 20 Dec 2001, Poul-Henning Kamp wrote: > > Julian, doesn't this give you an ordering issue ? > > Imagine this setup > > (lots of stuff) > | > module 1 > | > module 2 > | > module 3 > > With the added information that the path through module 2 can be very > short or very long, depending on the packet contents. meaning it uses more stack? (I'm assuming that that is what you mean) > > Now, module 1 sends a request down through module 2 which takes the > long path and consequently ends up being queued a module 3. We > unwind/return back up through module 2 and module 1 issues another > request which happens to take the short path through module 2 and > consequently directly calls into module 3. NO, because once an item is queued, all requests will queue behind it until the queue is drained again. What may happen in fact is that packet 2 will be queued and packet 1 dequeued and processed, followed by packet 2 being dequeued and processed. packet 3 may now proceed straight through.. > > Now the two requests have been reordered without any of the modules > having any hint of this. > > The obvious ways to fix this is to continue to queue once you queue > on a module (in other words: always queue if the queue is non-empty) I do.... It's a requirement because of the nature of rteh read/write lock on each node. Exclusive (writer) locks need to ensure that they are not bypassed by readers while they are queued, or they may NEVER get to run.. > > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 13:40:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 06F4537B416; Thu, 20 Dec 2001 13:40:18 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011220214018.HXRO6450.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 20 Dec 2001 21:40:18 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA52968; Thu, 20 Dec 2001 13:29:20 -0800 (PST) Date: Thu, 20 Dec 2001 13:29:20 -0800 (PST) From: Julian Elischer To: John Baldwin Cc: Poul-Henning Kamp , Alfred Perlstein , arch@FreeBSD.org Subject: Re: Kernel stack size and stacking: do we have a problem ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 20 Dec 2001, John Baldwin wrote: > > On 20-Dec-01 Poul-Henning Kamp wrote: > > > > Julian, doesn't this give you an ordering issue ? > > > > Imagine this setup > > > > (lots of stuff) > > | > > module 1 > > | > > module 2 > > | > > module 3 > > > > With the added information that the path through module 2 can be very > > short or very long, depending on the packet contents. > > > > Now, module 1 sends a request down through module 2 which takes the > > long path and consequently ends up being queued a module 3. We > > unwind/return back up through module 2 and module 1 issues another > > request which happens to take the short path through module 2 and > > consequently directly calls into module 3. > > > > Now the two requests have been reordered without any of the modules > > having any hint of this. > > > > The obvious ways to fix this is to continue to queue once you queue > > on a module (in other words: always queue if the queue is non-empty) > > Hmm, I was thinking that the original request would block when it queued the > request, and would be woken up when the original request was completed by the > worker thread. Thus, for each producer, only one item should be in the queue > at a time (plus any sub events it may create), but that multiple producers may > be putting events onto the queue handled by the worker thread. That may be true for a disk layer.. (in fact I doubt that it is true..) but it's not true for network stuff. In a disk layer, though, order isprobably not important. I would doubt that the operations would be synchronous. More likely asynchronous as PHK suggests. > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 13:42:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 859CD37B417; Thu, 20 Dec 2001 13:42:48 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id fBKLerl03483; Thu, 20 Dec 2001 22:40:53 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Julian Elischer Cc: John Baldwin , arch@FreeBSD.org, Alfred Perlstein Subject: Re: Kernel stack size and stacking: do we have a problem ? In-Reply-To: Your message of "Thu, 20 Dec 2001 13:26:08 PST." Date: Thu, 20 Dec 2001 22:40:53 +0100 Message-ID: <3481.1008884453@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Ju lian Elischer writes: >> >> Now, module 1 sends a request down through module 2 which takes the >> long path and consequently ends up being queued a module 3. We >> unwind/return back up through module 2 and module 1 issues another >> request which happens to take the short path through module 2 and >> consequently directly calls into module 3. > >NO, because once an item is queued, all requests will queue behind it >until the queue is drained again. > >What may happen in fact is that packet 2 will be queued and packet 1 >dequeued and processed, followed by packet 2 being dequeued and processed. >packet 3 may now proceed straight through.. Ahh, but now we hit the next problem: For stupid congestion reasons we have N requests queued, and then we happen to come around with N+1 while in an interrupt context and it gets to do all the work... We wouldn't want subject our interrupt contexts to risk that, would we ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 13:57:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id 1749337B416 for ; Thu, 20 Dec 2001 13:57:15 -0800 (PST) Received: (qmail 29758 invoked from network); 20 Dec 2001 21:57:14 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 20 Dec 2001 21:57:14 -0000 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: <3149.1008883923@critter.freebsd.dk> Date: Thu, 20 Dec 2001 13:56:57 -0800 (PST) From: John Baldwin To: Poul-Henning Kamp Subject: Re: Kernel stack size and stacking: do we have a problem ? Cc: Julian Elischer , arch@FreeBSD.org, Alfred Perlstein Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 20-Dec-01 Poul-Henning Kamp wrote: > In message , John Baldwin writes: > >>> Now the two requests have been reordered without any of the modules >>> having any hint of this. >>> >>> The obvious ways to fix this is to continue to queue once you queue >>> on a module (in other words: always queue if the queue is non-empty) >> >>Hmm, I was thinking that the original request would block when it queued the >>request, and would be woken up when the original request was completed by the >>worker thread. Thus, for each producer, only one item should be in the queue >>at a time (plus any sub events it may create), but that multiple producers >>may >>be putting events onto the queue handled by the worker thread. > > Ahh, but here you run into the zig-zag thing we two have talked about > earlier: what if I am running in an interrupt thread at this time ? > > This could be an incoming packet which triggers an outgoing response > or this could be a disk-write complete which triggers the write of > the other copy in the mirror. > > You cannot expect to be moving uniformly up (or down) the tree in > these kinds of layers so sleeping would be bad, and as far as my > intuition tells me, could lead to starvation and deadlock. Interrupts answer requests from the top half, they don't initiate requests on their own AFAIK. If an interrupt needs to initiate a request that it wants return state on, that's a bug I think. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 14: 0:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 0E63B37B417; Thu, 20 Dec 2001 14:00:18 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011220220017.NSBD20122.rwcrmhc53.attbi.com@InterJet.elischer.org>; Thu, 20 Dec 2001 22:00:17 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA53100; Thu, 20 Dec 2001 13:56:43 -0800 (PST) Date: Thu, 20 Dec 2001 13:56:42 -0800 (PST) From: Julian Elischer To: Poul-Henning Kamp Cc: John Baldwin , arch@FreeBSD.org, Alfred Perlstein Subject: Re: Kernel stack size and stacking: do we have a problem ? In-Reply-To: <3481.1008884453@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 20 Dec 2001, Poul-Henning Kamp wrote: > In message , Ju > lian Elischer writes: > >> > >> Now, module 1 sends a request down through module 2 which takes the > >> long path and consequently ends up being queued a module 3. We > >> unwind/return back up through module 2 and module 1 issues another > >> request which happens to take the short path through module 2 and > >> consequently directly calls into module 3. > > > >NO, because once an item is queued, all requests will queue behind it > >until the queue is drained again. > > > >What may happen in fact is that packet 2 will be queued and packet 1 > >dequeued and processed, followed by packet 2 being dequeued and processed. > >packet 3 may now proceed straight through.. > > Ahh, but now we hit the next problem: For stupid congestion reasons > we have N requests queued, and then we happen to come around with N+1 > while in an interrupt context and it gets to do all the work... > > We wouldn't want subject our interrupt contexts to risk that, would we ? That's why I suggest that 'real' devices that run off interrupts set the "should queue and leave" flag before passing the packet to the next layer. It is conceivable that you could have a limit as to how many packet/module processings you allow a single call to the netgraph code to do. Interrupts could set it to '6' or something which would allow the "average" packet to be processed completely. I know where this would go and it would be easy but I already have the "queue and return" flag that I use.. (The flag could be replaced by the number, set to '0') :-) > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 14: 2:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 1CE6437B419; Thu, 20 Dec 2001 14:02:41 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBKM9eI03807; Thu, 20 Dec 2001 14:09:40 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112202209.fBKM9eI03807@mass.dis.org> To: Poul-Henning Kamp Cc: arch@freebsd.org, msmith@mass.dis.org Subject: Re: Kernel stack size and stacking: do we have a problem ? In-Reply-To: Message from Poul-Henning Kamp of "Thu, 20 Dec 2001 09:43:42 +0100." <600.1008837822@critter.freebsd.dk> Date: Thu, 20 Dec 2001 14:09:40 -0800 From: Mike Smith 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 > > The problem with stacking layered systems is that the naïve and > simple implementation, just calling into the layer below, has > basically unbounded kernel stack usage. > > Fortunately for us, neither VFS nor netgraph has had too much use > yet, so we have not been excessively bothered by people running > out of kernel-stack. I think that this is looking for a solution before we have a problem, and realisically in the small number of cases where massive stack usage is actually required rather than simply the result of poor coding, we can look at increasing the stack allocation. There's plenty of stack already for very deep call graphs, and the complexity introduced with the "solutions" currently being thrown around would greatly outweigh the cost of slightly increasing the current stack allocation in the event that it gets blown out. So, in short, stay focussed on the real problems. 8) = Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 14: 5:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 1A25537B41B; Thu, 20 Dec 2001 14:05:27 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id AF90381E0B; Thu, 20 Dec 2001 16:05:26 -0600 (CST) Date: Thu, 20 Dec 2001 16:05:26 -0600 From: Alfred Perlstein To: Mike Smith Cc: Poul-Henning Kamp , arch@freebsd.org, msmith@mass.dis.org Subject: Re: Kernel stack size and stacking: do we have a problem ? Message-ID: <20011220160526.K48837@elvis.mu.org> References: <200112202209.fBKM9eI03807@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112202209.fBKM9eI03807@mass.dis.org>; from msmith@freebsd.org on Thu, Dec 20, 2001 at 02:09:40PM -0800 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 re: complex fixes for theoretical problems... * Mike Smith [011220 16:02] wrote: > > So, in short, stay focussed on the real problems. 8) I agree. :) Although the current discussion seems to have come to a useful conclusion. We only have to implement it if we see a need. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 14: 8:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id E16A637B416; Thu, 20 Dec 2001 14:08:09 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id fBKM6Gl03956; Thu, 20 Dec 2001 23:06:17 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: John Baldwin Cc: Julian Elischer , arch@FreeBSD.org, Alfred Perlstein Subject: Re: Kernel stack size and stacking: do we have a problem ? In-Reply-To: Your message of "Thu, 20 Dec 2001 13:56:57 PST." Date: Thu, 20 Dec 2001 23:06:16 +0100 Message-ID: <3954.1008885976@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , John Baldwin writes: >Interrupts answer requests from the top half, they don't initiate requests on >their own AFAIK. If an interrupt needs to initiate a request that it wants >return state on, that's a bug I think. Ahh, I see a misunderstanding here: in VOP_ you have return state because the calls are synchronous, but netgraph and Geom are both asynchronous by design. The fact that VOP_ is synchrnous is also what makes it so hard to fix, and why I was kind of hoping for people to say "Don't worry about kernel stack, RAM is dirt cheap!" :-) Anyway, I guess the conclusion on this thread will be: A) We should probably implement int enough_stack() and apply it in some strategic places so we can fail gracely rather than panic when we run out of kernel stack. B) We have no idea how to sanely fix VOP_ since it is synchronous. When I say "sanely" I'm referring to the fact that the VOP code is scary enough as it is and we don't want to make it even hairier, lest we loose the few filesystem hackers we have, not to mention the fact that we would probably never complete the conversion in the first place (see sys/vnode.h::IS_LOCKING_VFS() for precedent.) C) Variant size kernel stacks are probably not worth the bother, but sysctl variable kernel stacks might be a good investment. C) Netgraph and Geom will use scheduling, possibly with a direct call optimization to avoid the issue. Julian hybrid scheme could possibly be adapted to Geom, if it can be made to maintain ordering (think: softupdates). Thanks for your input gentlemen. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 14:12:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 40F8F37B41B; Thu, 20 Dec 2001 14:12:31 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id D670381E0C; Thu, 20 Dec 2001 16:12:30 -0600 (CST) Date: Thu, 20 Dec 2001 16:12:30 -0600 From: Alfred Perlstein To: Poul-Henning Kamp Cc: John Baldwin , Julian Elischer , arch@FreeBSD.org Subject: Re: Kernel stack size and stacking: do we have a problem ? Message-ID: <20011220161230.L48837@elvis.mu.org> References: <3954.1008885976@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3954.1008885976@critter.freebsd.dk>; from phk@critter.freebsd.dk on Thu, Dec 20, 2001 at 11:06:16PM +0100 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 * Poul-Henning Kamp [011220 16:08] wrote: > > B) We have no idea how to sanely fix VOP_ since it is synchronous. > When I say "sanely" I'm referring to the fact that the VOP > code is scary enough as it is and we don't want to make it even > hairier, lest we loose the few filesystem hackers we have, not > to mention the fact that we would probably never complete the > conversion in the first place (see sys/vnode.h::IS_LOCKING_VFS() > for precedent.) Wait, when you almost run out of stack what's stopping you from queuing the vop data to a thread and then sleeping? I know that sleeping in certain VOPs isn't allowed, but maybe we could somehow switch stacks temporarily via some sort of continuation system... http://people.freebsd.org/~alfred/zbthreads/ -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 14:19: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 80EA537B416; Thu, 20 Dec 2001 14:18:59 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id fBKMH5l04238; Thu, 20 Dec 2001 23:17:05 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein Cc: John Baldwin , Julian Elischer , arch@FreeBSD.org Subject: Re: Kernel stack size and stacking: do we have a problem ? In-Reply-To: Your message of "Thu, 20 Dec 2001 16:12:30 CST." <20011220161230.L48837@elvis.mu.org> Date: Thu, 20 Dec 2001 23:17:05 +0100 Message-ID: <4236.1008886625@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011220161230.L48837@elvis.mu.org>, Alfred Perlstein writes: >* Poul-Henning Kamp [011220 16:08] wrote: >> >> B) We have no idea how to sanely fix VOP_ since it is synchronous. >> When I say "sanely" I'm referring to the fact that the VOP >> code is scary enough as it is and we don't want to make it even >> hairier, lest we loose the few filesystem hackers we have, not >> to mention the fact that we would probably never complete the >> conversion in the first place (see sys/vnode.h::IS_LOCKING_VFS() >> for precedent.) > >Wait, when you almost run out of stack what's stopping you from >queuing the vop data to a thread and then sleeping? The fact that we have nobody who would pick up the queued request and process it and that you would run into all sorts of locking, deadlock and starvation issues. >I know that >sleeping in certain VOPs isn't allowed, but maybe we could >somehow switch stacks temporarily via some sort of continuation >system... Some kind of "can I borrow a cup of kernel-stack" method might be an option, but I'd far rather just fail the VOP and tell the user to increase the kernel-stack size. As I said: The key to this question is that very few of the global changes to the VOP API have ever been completed entirely and consequently we should have a major good reason to start another one. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 14:21:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id 5DA7337B41B for ; Thu, 20 Dec 2001 14:21:50 -0800 (PST) Received: (qmail 16617 invoked from network); 20 Dec 2001 22:21:49 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 20 Dec 2001 22:21:49 -0000 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: <20011220161230.L48837@elvis.mu.org> Date: Thu, 20 Dec 2001 14:21:32 -0800 (PST) From: John Baldwin To: Alfred Perlstein Subject: Re: Kernel stack size and stacking: do we have a problem ? Cc: arch@FreeBSD.org, Julian Elischer , Poul-Henning Kamp 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 20-Dec-01 Alfred Perlstein wrote: > * Poul-Henning Kamp [011220 16:08] wrote: >> >> B) We have no idea how to sanely fix VOP_ since it is synchronous. >> When I say "sanely" I'm referring to the fact that the VOP >> code is scary enough as it is and we don't want to make it even >> hairier, lest we loose the few filesystem hackers we have, not >> to mention the fact that we would probably never complete the >> conversion in the first place (see sys/vnode.h::IS_LOCKING_VFS() >> for precedent.) > > Wait, when you almost run out of stack what's stopping you from > queuing the vop data to a thread and then sleeping? I know that > sleeping in certain VOPs isn't allowed, but maybe we could > somehow switch stacks temporarily via some sort of continuation > system... That was basically my suggestion. Your original thread puts the request on a queue and blocks waiting for completion status. The worker thread grabs the event off the queue and finishes returning the completion status to the original thread. Note that if the worker kproc grows threads in a KSE-like manner when blocking, then you can end up chaining several threads if you ever get really deep nesting (although arguably a worker thread should just panic if it runs out of stack as we are probably stuck in an infinite recursion.) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 14:40:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 1E0D737B428; Thu, 20 Dec 2001 14:40:12 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011220224011.LNTT19716.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 20 Dec 2001 22:40:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA53345; Thu, 20 Dec 2001 14:26:26 -0800 (PST) Date: Thu, 20 Dec 2001 14:26:24 -0800 (PST) From: Julian Elischer To: Poul-Henning Kamp Cc: John Baldwin , arch@FreeBSD.org, Alfred Perlstein Subject: Re: Kernel stack size and stacking: do we have a problem ? In-Reply-To: <3954.1008885976@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 20 Dec 2001, Poul-Henning Kamp wrote: > > A) We should probably implement > int enough_stack() a full unoptimised but correct version would be: int enough_stack(u_int needed) { caddr_t addr, addr2; if needed > KSTACK_PAGES * PAGESIZE return 0; /* catch stupid values */ addr1 = &needed; addr2 = (caddr_t)curthread->td_kstack + needed; return (addr1 > addr2) } > and apply it in some strategic places so we can fail gracely > rather than panic when we run out of kernel stack. > > B) We have no idea how to sanely fix VOP_ since it is synchronous. > When I say "sanely" I'm referring to the fact that the VOP > code is scary enough as it is and we don't want to make it even > hairier, lest we loose the few filesystem hackers we have, not > to mention the fact that we would probably never complete the > conversion in the first place (see sys/vnode.h::IS_LOCKING_VFS() > for precedent.) > > C) Variant size kernel stacks are probably not worth the bother, > but sysctl variable kernel stacks might be a good investment. > > C) Netgraph and Geom will use scheduling, possibly with a direct > call optimization to avoid the issue. > Julian hybrid scheme could possibly be adapted to Geom, if it > can be made to maintain ordering (think: softupdates). it does.. > > Thanks for your input gentlemen. The netgraph locking/queueing is an integrated set of code that does both functions. The queing is part and parcel of the locking. it wouldn't work if it were not an async system. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 15:58:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from watery.cc.kogakuin.ac.jp (watery.cc.kogakuin.ac.jp [133.80.152.80]) by hub.freebsd.org (Postfix) with ESMTP id EBE8A37B405 for ; Thu, 20 Dec 2001 15:58:38 -0800 (PST) Received: from localhost (localhost [::1]) by watery.cc.kogakuin.ac.jp (8.11.5/8.11.5) with ESMTP id fBKNwIT29334; Fri, 21 Dec 2001 08:58:19 +0900 (JST) (envelope-from nyan@FreeBSD.org) Date: Fri, 21 Dec 2001 08:58:00 +0900 (JST) Message-Id: <20011221.085800.59482063.yosihiro@cc.kogakuin.ac.jp> To: hch@caldera.de Cc: imp@harmony.village.org, joerg_wunsch@uriah.heep.sax.de, arch@FreeBSD.org Subject: Re: cvs commit: src/sys/isa fd.c From: Takahashi Yoshihiro In-Reply-To: <20011220140855.A8988@caldera.de> References: <20011219090256.E97821@uriah.heep.sax.de> <200112190830.fBJ8UhM25504@harmony.village.org> <20011220140855.A8988@caldera.de> X-Mailer: Mew version 2.1 on Emacs 20.7 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <20011220140855.A8988@caldera.de> Christoph Hellwig writes: > > I don't think there will be another IA32 port ever. > > o SGI Visual Workstation > o SUN Roadrunner > o DG NUMA machines o Fujitsu FM-R/FM-TOWNS --- TAKAHASHI Yoshihiro THE CENTER for INFORMATION SCIENCE, Kogakuin Univ. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 20 23:31:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 83F1A37B419; Thu, 20 Dec 2001 23:31:09 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBL7UV041888; Fri, 21 Dec 2001 09:30:31 +0200 (EET) (envelope-from ru) Date: Fri, 21 Dec 2001 09:30:30 +0200 From: Ruslan Ermilov To: The Anarcat Cc: freebsd-arch@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: making /usr/share/mk apps PREFIX-independant??? Message-ID: <20011221093030.D39918@sunbay.com> References: <20011220183103.GH2956@shall.anarcat.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011220183103.GH2956@shall.anarcat.dyndns.org> User-Agent: Mutt/1.3.23i 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, Dec 20, 2001 at 01:31:04PM -0500, The Anarcat wrote: > [posted to -arch, and CC'd to hackers since I have no idea as to where > this belongs, please redirect if necessary] > > Hi. > > As a developper working in the FreeBSD/ports paradigm, and developping > exclusively for FreeBSD through the libh project, it has come to my > attention that applications developped through /usr/share/mk Makefiles > (in particular bsd.prog.mk and bsd.lib.mk) do not respect PREFIX. > > That is, the libh Makefiles, as set now, install in /usr no matter what. > There is no real alternative. Setting DESTDIR will install in > /${DESTDIR}/usr, without changing the PREFIX (/usr). > > In other words, apps developped using /usr/share/mk makefiles are > incompatible with the ports collection PREFIX-independance paradigm. > > That sucks. > > This is a problem which must be solved. As a hack, the libh port uses a > custom install target in the ports skeleton (ie, it doesn't use libh > install targets). > > How I see it, the .mk files must be hacked. One could try such a replace > pattern, I guess: s!install(.*)${DESTDIR}!install\1${PREFIX}/${DESTDIR}! > > I tried to produce a significant patch, and I failed. I do not > understand how some files end up in /bin and some other in /usr/bin. > > If someone can help me with that, I will happily start hacking on the mk > files, but in the meantime, I'm lost. > I'm against PREFIX in share/mk files. Instead, just setting DESTDIR=${PREFIX} should (almost) be enough. Another set of "hacks" might be required for *DIR settings, like LIBDIR=/lib, MANDIR=/man, etc. Just adding the PREFIX wouldn't solve these differences between / and /usr/local anyway. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 21 0:47:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 16A2E37B416; Fri, 21 Dec 2001 00:47:25 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16HLMf-000CyH-00; Fri, 21 Dec 2001 10:49:13 +0200 From: Sheldon Hearn To: Ruslan Ermilov Cc: The Anarcat , freebsd-arch@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: making /usr/share/mk apps PREFIX-independant??? In-reply-to: Your message of "Fri, 21 Dec 2001 09:30:30 +0200." <20011221093030.D39918@sunbay.com> Date: Fri, 21 Dec 2001 10:49:13 +0200 Message-ID: <49864.1008924553@axl.seasidesoftware.co.za> 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, 21 Dec 2001 09:30:30 +0200, Ruslan Ermilov wrote: > I'm against PREFIX in share/mk files. Instead, just setting > DESTDIR=${PREFIX} should (almost) be enough. I agree. See ports/mail/popd/Makefile for an example of a port that uses a pure bsd.prog.mk-driven Makefile for ${PREFIX}-sensitive installation. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 21 2:27:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (pc-62-31-42-140-hy.blueyonder.co.uk [62.31.42.140]) by hub.freebsd.org (Postfix) with ESMTP id F35B537B405; Fri, 21 Dec 2001 02:27:27 -0800 (PST) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.6/8.11.6) id fBLA6xx99232; Fri, 21 Dec 2001 10:06:59 GMT (envelope-from nik) Date: Fri, 21 Dec 2001 10:06:58 +0000 From: Nik Clayton To: Sheldon Hearn Cc: Ruslan Ermilov , The Anarcat , freebsd-arch@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: making /usr/share/mk apps PREFIX-independant??? Message-ID: <20011221100658.M51511@clan.nothing-going-on.org> References: <20011221093030.D39918@sunbay.com> <49864.1008924553@axl.seasidesoftware.co.za> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="9Jdw4pA1x1k2W7MG" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <49864.1008924553@axl.seasidesoftware.co.za>; from sheldonh@starjuice.net on Fri, Dec 21, 2001 at 10:49:13AM +0200 Organization: FreeBSD Project 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 --9Jdw4pA1x1k2W7MG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 21, 2001 at 10:49:13AM +0200, Sheldon Hearn wrote: > On Fri, 21 Dec 2001 09:30:30 +0200, Ruslan Ermilov wrote: > > I'm against PREFIX in share/mk files. Instead, just setting > > DESTDIR=3D${PREFIX} should (almost) be enough. >=20 > I agree. See ports/mail/popd/Makefile for an example of a port that > uses a pure bsd.prog.mk-driven Makefile for ${PREFIX}-sensitive > installation. Doesn't it strike anyone as being a bit, well, icky, that we have to do this for software developed on this platform, using this platform's standard infrastructure for defining Makefiles? Perhaps just a "USES_BSD_MK=3Dyes" flag to wrap this for other ports as well (I'm thinking specifically of the scr* stuff I wrote, but there may be others). N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- --9Jdw4pA1x1k2W7MG 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 iEYEARECAAYFAjwjCcIACgkQk6gHZCw343UN1QCePR2IcXqJIWZDodHNzuyJe3QV 62MAn2d8JRD80+Vh7w6aPTaVTDN7Yh8E =0JiC -----END PGP SIGNATURE----- --9Jdw4pA1x1k2W7MG-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 21 2:34:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 0330337B419; Fri, 21 Dec 2001 02:34:17 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16HN26-000DLF-00; Fri, 21 Dec 2001 12:36:06 +0200 From: Sheldon Hearn To: Nik Clayton Cc: Ruslan Ermilov , The Anarcat , freebsd-arch@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: making /usr/share/mk apps PREFIX-independant??? In-reply-to: Your message of "Fri, 21 Dec 2001 10:06:58 GMT." <20011221100658.M51511@clan.nothing-going-on.org> Date: Fri, 21 Dec 2001 12:36:06 +0200 Message-ID: <51288.1008930966@axl.seasidesoftware.co.za> 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, 21 Dec 2001 10:06:58 GMT, Nik Clayton wrote: > Perhaps just a "USES_BSD_MK=yes" flag to wrap this for other ports as > well (I'm thinking specifically of the scr* stuff I wrote, but there may > be others). That sounds like a good idea. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 21 3:17:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id AD25337B416; Fri, 21 Dec 2001 03:16:56 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBLBGfg73736; Fri, 21 Dec 2001 13:16:41 +0200 (EET) (envelope-from ru) Date: Fri, 21 Dec 2001 13:16:41 +0200 From: Ruslan Ermilov To: Nik Clayton Cc: Sheldon Hearn , The Anarcat , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: making /usr/share/mk apps PREFIX-independant??? Message-ID: <20011221131641.A66666@sunbay.com> References: <20011221093030.D39918@sunbay.com> <49864.1008924553@axl.seasidesoftware.co.za> <20011221100658.M51511@clan.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011221100658.M51511@clan.nothing-going-on.org> User-Agent: Mutt/1.3.23i 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, Dec 21, 2001 at 10:06:58AM +0000, Nik Clayton wrote: > On Fri, Dec 21, 2001 at 10:49:13AM +0200, Sheldon Hearn wrote: > > On Fri, 21 Dec 2001 09:30:30 +0200, Ruslan Ermilov wrote: > > > I'm against PREFIX in share/mk files. Instead, just setting > > > DESTDIR=${PREFIX} should (almost) be enough. > > > > I agree. See ports/mail/popd/Makefile for an example of a port that > > uses a pure bsd.prog.mk-driven Makefile for ${PREFIX}-sensitive > > installation. > > Doesn't it strike anyone as being a bit, well, icky, that we have to do > this for software developed on this platform, using this platform's > standard infrastructure for defining Makefiles? > > Perhaps just a "USES_BSD_MK=yes" flag to wrap this for other ports as > well (I'm thinking specifically of the scr* stuff I wrote, but there may > be others). > You don't listen. :-) Just adding PREFIX won't solve anything, as you still need to supply the correct BINDIR (which is, for the main src/ tree makefiles, initialized by the root Makefile.inc in each subtree), and provide the correct MANDIR, LIBDIR, etc. In the port I maintain (ports/net/tcpmssd), the main program's Makefile looks like this: : PROG= tcpmssd : PREFIX?= /usr/local : BINDIR= ${PREFIX}/bin : MAN8= tcpmssd.8 : MANDIR= ${PREFIX}/man/man : : .include If you modify it to look like this (that's the goal?): : PROG= tcpmssd : MAN8= tcpmssd.8 : : .include You still need to supply BINDIR and MANDIR somehow. The following worked for my port flawlessly, but it's a prototype only, and the complete version should cover all bsd.own.mk defines: --- bsd.port.mk~ Wed Nov 28 07:00:36 2001 +++ bsd.port.mk Fri Dec 21 12:58:53 2001 @@ -1158,6 +1158,10 @@ MAKE_ENV+= ${INSTALL_MACROS} SCRIPTS_ENV+= ${INSTALL_MACROS} +.if defined(USE_BSD_MAKE) +MAKE_ENV+= BINDIR=${PREFIX}/bin MANDIR=${PREFIX}/man/man +.endif + # The user can override the NO_PACKAGE by specifying this from # the make command line .if defined(FORCE_PACKAGE) This should work for both /usr/local and /usr/X11R6 prefixes. I don't pretend that this solution is ideal, as a port may need different BINDIR settings for its different parts. I have given a little thinking to this, just to demonstrate that the "fixes" should go into ports/Mk, not into the base .mk files. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 21 3:57:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (pc-62-31-42-140-hy.blueyonder.co.uk [62.31.42.140]) by hub.freebsd.org (Postfix) with ESMTP id A142D37B405; Fri, 21 Dec 2001 03:57:20 -0800 (PST) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.6/8.11.6) id fBLBsdJ00201; Fri, 21 Dec 2001 11:54:39 GMT (envelope-from nik) Date: Fri, 21 Dec 2001 11:54:39 +0000 From: Nik Clayton To: Ruslan Ermilov Cc: Nik Clayton , Sheldon Hearn , The Anarcat , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: making /usr/share/mk apps PREFIX-independant??? Message-ID: <20011221115439.O51511@clan.nothing-going-on.org> References: <20011221093030.D39918@sunbay.com> <49864.1008924553@axl.seasidesoftware.co.za> <20011221100658.M51511@clan.nothing-going-on.org> <20011221131641.A66666@sunbay.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="da9oBGf5DLtF9ehv" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011221131641.A66666@sunbay.com>; from ru@freebsd.org on Fri, Dec 21, 2001 at 01:16:41PM +0200 Organization: FreeBSD Project 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 --da9oBGf5DLtF9ehv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 21, 2001 at 01:16:41PM +0200, Ruslan Ermilov wrote: > You don't listen. :-) > I don't pretend that this solution is ideal, as a port may > need different BINDIR settings for its different parts. I > have given a little thinking to this, just to demonstrate > that the "fixes" should go into ports/Mk, not into the base > .mk files. That's what I meant. We're in violent agreement :-) N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- --da9oBGf5DLtF9ehv 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 iEYEARECAAYFAjwjIv8ACgkQk6gHZCw343X5/ACcCyM36B7X4spk6y1eXyIbd8sp 6s4An1wxQQ3l1lcWa4kDz2JO+qcLAPZz =U9fE -----END PGP SIGNATURE----- --da9oBGf5DLtF9ehv-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 21 6:45:26 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 1E2A537B416; Fri, 21 Dec 2001 06:45:23 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id BAA09323; Sat, 22 Dec 2001 01:45:20 +1100 Date: Sat, 22 Dec 2001 01:45:23 +1100 (EST) From: Bruce Evans X-X-Sender: To: John Baldwin Cc: Sheldon Hearn , , Subject: RE: Why special handling of nfsclient kernel support in etc/rc? In-Reply-To: Message-ID: <20011222013124.S4898-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 20 Dec 2001, John Baldwin wrote: > On 20-Dec-01 Sheldon Hearn wrote: > > Why is this needed? Shouldn't the vfsload() code in mount_nfs(1) handle > > this? > > > > error = getvfsbyname("nfs", &vfc); > > if (error && vfsisloadable("nfs")) { > > if(vfsload("nfs")) > > err(EX_OSERR, "vfsload(nfs)"); > > endvfsent(); /* clear cache */ > > error = getvfsbyname("nfs", &vfc); > > } > > There's no nfs.ko. mount_nfs should be updated to load 'nfsclient' instead. > If this happens, then arguably, the nfs_client_enable variable in rc.conf > should just go away and not be used. The above code (and similar code in N other mount utilities) has been undead for more than 3 years now. vfs modules should be automatically loaded by mount(2) if the above code doesn't do it first. Presumably mount(2) also fails to load nfs due to similar naming problems. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 21 8:59:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 3170337B41A; Fri, 21 Dec 2001 08:59:29 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011221165929.PEFA20122.rwcrmhc53.attbi.com@peter3.wemm.org>; Fri, 21 Dec 2001 16:59:29 +0000 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 fBLGxSs82396; Fri, 21 Dec 2001 08:59:28 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 9CC8238CC; Fri, 21 Dec 2001 08:59:28 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: John Baldwin Cc: Sheldon Hearn , freebsd-arch@FreeBSD.ORG, dougb@FreeBSD.ORG Subject: Re: Why special handling of nfsclient kernel support in etc/rc? In-Reply-To: Date: Fri, 21 Dec 2001 08:59:28 -0800 From: Peter Wemm Message-Id: <20011221165928.9CC8238CC@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 John Baldwin wrote: > > On 20-Dec-01 Sheldon Hearn wrote: > > > > Hi Doug, > > > > I refer to the following change you made to src/etc/rc: > > > > revision 1.286 > > date: 2001/10/19 06:50:52; author: dougb; state: Exp; lines: +19 -4 > > Handle the lack of nfs server or client support in the kernel by > > kldload'ing the appropriate modules before enabling the service. > > > > Why is this needed? Shouldn't the vfsload() code in mount_nfs(1) handle > > this? > > > > error = getvfsbyname("nfs", &vfc); > > if (error && vfsisloadable("nfs")) { > > if(vfsload("nfs")) > > err(EX_OSERR, "vfsload(nfs)"); > > endvfsent(); /* clear cache */ > > error = getvfsbyname("nfs", &vfc); > > } > > There's no nfs.ko. mount_nfs should be updated to load 'nfsclient' instead. > If this happens, then arguably, the nfs_client_enable variable in rc.conf > should just go away and not be used. But "nfs" is exported via kldxref and should be loadable via "kldload nfs". Secondly, this is why I did not remove nfsiod to start with. I was planning to redo it as a wrapper that did the module load, and emulated the arguments by translating them into a sysctl to set the number of kernel nfsiod's and then exiting. This would solve the ordering problem entirely and wouldn't depend on actually having nfs file systems in fstab in order to set the sysctl's. 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 Fri Dec 21 20: 0:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 4301937B41B for ; Fri, 21 Dec 2001 20:00:10 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011222040009.GFEW20122.rwcrmhc53.attbi.com@InterJet.elischer.org> for ; Sat, 22 Dec 2001 04:00:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id TAA60313 for ; Fri, 21 Dec 2001 19:53:06 -0800 (PST) Date: Fri, 21 Dec 2001 19:53:05 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: blurk! KSE vs the X86 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ok so we have this wonderful thing called a TSS there is one per CPU by default, but you can ask that your process has it own.. that would be one per process.. it has such things as the address to load the system stack pointer from when running your process and take a trap e.g. syscall. This is in the PCB extension area. At this time there is only the capacity to set an extension into the single thread that would want it, and it isn't associated with the process as such via the proc structure, just via the PCB extension pointer. So since threads are transient in KSE processes when the thread migrates away (almost immediatly in some cases) you have no trace of your extension area (hense TSS) so at teh next swtch() it'll be gone again.. the QUICK answer is to say that vm86 and KSE can't be mixed, but is that the best solution we can do? who should inherrit a changed TSS? I an guessing that a KSEGROUP might have it's TSS changed and all threads instantiated thereafter could inherrit the new extension area, but unfortunatly there'd have to be as many as there were KSE's in that KSEGRP. Maybe they are hung off the KSEs? Now we are talking.. You could hang a separate one of each KSE, and the running thread on that KSE would use it... hmmmm that actually makes sense. It's even easy enough that swtch() could get it easily in Assembler. anyone up on this stuff..? what's the normal way these things are set? (the various fields in the extension pcb and the ldt etc.) Is there a connection between the pcb extension and the LDT? we could (as I showed before) have a per-KSE PCB extension in a KSEGRP which would make that work, but can you have per thread LGTs? They are pointed to by the per process mdproc structure at teh moment. is that good enough? probably... I haven't actually found the LDT itself being alocated.. yet :-) enough of this rant.. who's up on this stuff? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 21 21:51:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id ED86037B405 for ; Fri, 21 Dec 2001 21:51:12 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011222055112.BCCY19716.rwcrmhc51.attbi.com@peter3.wemm.org> for ; Sat, 22 Dec 2001 05:51:12 +0000 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 fBM5pBs84315 for ; Fri, 21 Dec 2001 21:51:11 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id C28FA38CC; Fri, 21 Dec 2001 21:51:11 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Julian Elischer Cc: arch@FreeBSD.ORG Subject: Re: blurk! KSE vs the X86 In-Reply-To: Date: Fri, 21 Dec 2001 21:51:11 -0800 From: Peter Wemm Message-Id: <20011222055111.C28FA38CC@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 Julian Elischer wrote: > > Ok so we have this wonderful thing called a TSS > there is one per CPU by default, but you can ask that your process has it > own.. that would be one per process.. it has such things as the address > to load the system stack pointer from when running your process and take a > trap e.g. syscall. > > This is in the PCB extension area. At this time there is only the > capacity to set an extension into the single thread that would want it, > and it isn't associated with the process as such via the proc structure, > just via the PCB extension pointer. So since threads are transient in KSE > processes when the thread migrates away (almost immediatly in some cases) > you have no trace of your extension area (hense TSS) so at teh next > swtch() it'll be gone again.. > the QUICK answer is to say that vm86 and KSE can't be mixed, but > is that the best solution we can do? Do not worry about the "best" yet. Lets get a functional baseline code set that can actually do an upcall and actually do something useful before worrying about this sort of thing. ie: until we have something functional in the tree, the policy should be: KSE is not allowed with {VM86, local LDT, PCB extensions [io port access], etc.} The "best" solution will be apparent after we have got the basics working. 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 Sat Dec 22 12:13:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from titanic.uninet.kiev.ua (titanic.uninet.kiev.ua [193.125.78.35]) by hub.freebsd.org (Postfix) with ESMTP id 411AD37B405 for ; Sat, 22 Dec 2001 12:13:23 -0800 (PST) Received: (from uucp@localhost) by titanic.uninet.kiev.ua (8.11.1/8.11.1) with UUCP id fBMKDDQ70486 for freebsd-arch@freebsd.org; Sat, 22 Dec 2001 22:13:13 +0200 (EET) (envelope-from ura@sphinx.univ.kiev.ua) Received: by sphinx.univ.kiev.ua (Postfix, from userid 1001) id 00A4C59201; Sat, 22 Dec 2001 15:20:30 +0200 (EET) Date: Sat, 22 Dec 2001 15:20:30 +0200 From: Yuri Karaban To: freebsd-arch@freebsd.org Subject: gnu getopt in libc Message-ID: <20011222132030.GA19596@sphinx.univ.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.24i 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 gnu getopt supports long options and can reorder option keys so i can write: some_program -a -b -c file1 file2 -d -e -f FreeBSD getopt in libc very simple it can recoginze only one letter arguments, does not support optional arguments and arguments to program may appear only at the beginning. so why dont replace libc/stdlib/getopt.c by gnu version ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 22 12:19:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id F11BF37B419 for ; Sat, 22 Dec 2001 12:19:31 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011222201931.NGCY19716.rwcrmhc51.attbi.com@peter3.wemm.org> for ; Sat, 22 Dec 2001 20:19:31 +0000 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 fBMKJUs88821 for ; Sat, 22 Dec 2001 12:19:30 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id B9DEF38CC; Sat, 22 Dec 2001 12:19:30 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Yuri Karaban Cc: freebsd-arch@FreeBSD.ORG Subject: Re: gnu getopt in libc In-Reply-To: <20011222132030.GA19596@sphinx.univ.kiev.ua> Date: Sat, 22 Dec 2001 12:19:30 -0800 From: Peter Wemm Message-Id: <20011222201930.B9DEF38CC@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 Yuri Karaban wrote: > gnu getopt supports long options and can reorder option keys > so i can write: > some_program -a -b -c file1 file2 -d -e -f > > FreeBSD getopt in libc very simple it can recoginze only one letter > arguments, does not support optional arguments and arguments to > program may appear only at the beginning. > > so why dont replace libc/stdlib/getopt.c by gnu version ? 1) because it is nonstandard 2) it is GPL contaminated which we cannot use in libc. 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 Sat Dec 22 15: 8:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tomts14-srv.bellnexxia.net (tomts14.bellnexxia.net [209.226.175.35]) by hub.freebsd.org (Postfix) with ESMTP id EE3DA37B405; Sat, 22 Dec 2001 15:08:08 -0800 (PST) Received: from khan.anarcat.dyndns.org ([65.94.189.35]) by tomts14-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20011222230808.TITR6216.tomts14-srv.bellnexxia.net@khan.anarcat.dyndns.org>; Sat, 22 Dec 2001 18:08:08 -0500 Received: from shall.anarcat.dyndns.org (shall.anarcat.dyndns.org [192.168.0.1]) by khan.anarcat.dyndns.org (Postfix) with ESMTP id 5B0121B43; Sat, 22 Dec 2001 18:08:03 -0500 (EST) Received: by shall.anarcat.dyndns.org (Postfix, from userid 1000) id 7998720ACB; Sat, 22 Dec 2001 18:08:01 -0500 (EST) Date: Sat, 22 Dec 2001 18:08:00 -0500 From: The Anarcat To: arch@freebsd.org Cc: jkh@freebsd.org Subject: sysctl kern.disks shouldn't have to sort its output Message-ID: <20011222230759.GD530@shall.anarcat.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3O1VwFp74L81IIeR" Content-Disposition: inline User-Agent: Mutt/1.3.24i 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 --3O1VwFp74L81IIeR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi. I'm struggling with a breakage in libh which is due to some code committed recently to -stable libdisk and then MFS'd to -current: -- snip -- revision 1.50.2.14 date: 2001/09/18 06:47:30; author: jkh; state: Exp; lines: +2 -2 Temporarily disable the use of kern.disks - it returns the disk devices in the wrong order and causes them to be displayed out of sequence in sysinstall. The right fix is to sort that info in the kernel, this is just a stop-gap measure which falls back to the code which always ran prior to kern.disks existing. This deliberately not committed to -current because we have aple time to pursue the right fix in that branch. -- snip -- The breakage is that the "alternate drive detection routine" uses a open call on the drive device to verify that it exists. It is not only inefficient, but also disables detection for non-root processes. Ok, now, i'm not sure about that, but looking at how kern.disks is implemented (a simple list to which disks are added one by one) and how sysctl_disks is implemented (iteration through that list), it seems a pain to sort these entries there. To me, the sorting belongs to libdisk at most, or to the user app. Not in the kernel. Of course, one might wonder why the entries in kern.disks are not sorted. This, I do not know. It might depend on how the disks are detected. For example, here, sysctl kern.disks gives: kern.disks: cd0 ad3 ad1 ad0 md0 ad3 is on ata1. So maybe ata1 is detected first and that's why the disk ends up there. I don't know. Anyways. If the sorting belongs to the kernel, I could do it. However, I think it belongs to libdisk, so I'll start working on a patch there. Just FYI, a. --3O1VwFp74L81IIeR 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 iEYEARECAAYFAjwlEkwACgkQttcWHAnWiGfq9gCdE67OTyktP7Ec2nv5JiY/Qjom RaoAn2ztR7R2b3Qp9Q1gTf0Z10RSmUV3 =u5Qh -----END PGP SIGNATURE----- --3O1VwFp74L81IIeR-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 22 16:21:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id ABB8637B417; Sat, 22 Dec 2001 16:21:33 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fBN0LHG33487; Sat, 22 Dec 2001 16:21:18 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: The Anarcat Cc: arch@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: sysctl kern.disks shouldn't have to sort its output In-Reply-To: Message from The Anarcat of "Sat, 22 Dec 2001 18:08:00 EST." <20011222230759.GD530@shall.anarcat.dyndns.org> Date: Sat, 22 Dec 2001 16:21:16 -0800 Message-ID: <33483.1009066876@winston.freebsd.org> From: Jordan Hubbard 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 > Anyways. If the sorting belongs to the kernel, I could do it. > > However, I think it belongs to libdisk, so I'll start working on a patch > there. The sorting could be in libdisk, I just suggested the kernel so that other consumers of the kern.disks sysctl variable wouldn't have to sort it as well. One assumes that more than libdisk might want to get at this data. In any case, for this particular case doing it in libdisk would be fine. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 22 16:55:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tomts11-srv.bellnexxia.net (tomts11.bellnexxia.net [209.226.175.55]) by hub.freebsd.org (Postfix) with ESMTP id 3FB6A37B416; Sat, 22 Dec 2001 16:55:09 -0800 (PST) Received: from khan.anarcat.dyndns.org ([65.94.189.35]) by tomts11-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20011223005507.IENR8040.tomts11-srv.bellnexxia.net@khan.anarcat.dyndns.org>; Sat, 22 Dec 2001 19:55:07 -0500 Received: from shall.anarcat.dyndns.org (shall.anarcat.dyndns.org [192.168.0.1]) by khan.anarcat.dyndns.org (Postfix) with ESMTP id D0EA11B38; Sat, 22 Dec 2001 19:55:03 -0500 (EST) Received: by shall.anarcat.dyndns.org (Postfix, from userid 1000) id A632F20ACB; Sat, 22 Dec 2001 19:54:50 -0500 (EST) Date: Sat, 22 Dec 2001 19:54:50 -0500 From: The Anarcat To: Jordan Hubbard Cc: arch@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: sysctl kern.disks shouldn't have to sort its output Message-ID: <20011223005449.GE530@shall.anarcat.dyndns.org> References: <20011222230759.GD530@shall.anarcat.dyndns.org> <33483.1009066876@winston.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7uYPyRQQ5N0D02nI" Content-Disposition: inline In-Reply-To: <33483.1009066876@winston.freebsd.org> User-Agent: Mutt/1.3.24i 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 --7uYPyRQQ5N0D02nI Content-Type: multipart/mixed; boundary="bGR76rFJjkSxVeRa" Content-Disposition: inline --bGR76rFJjkSxVeRa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat Dec 22, 2001 at 04:21:16PM -0800, Jordan Hubbard wrote: > > Anyways. If the sorting belongs to the kernel, I could do it. > >=20 > > However, I think it belongs to libdisk, so I'll start working on a patch > > there. >=20 > The sorting could be in libdisk, I just suggested the kernel so that > other consumers of the kern.disks sysctl variable wouldn't have to > sort it as well.=20 Yes, of course. But I wonder how best it would be implemented... By controlling how entries are added to the list, or by controlling how he prints those entries? Because it is a list, sorting it is not very efficient. At the output though (outside sysctl_disks and therefore outside the kernel), it's a string, so it's easier to manipulate. I think a list-sorting algorithm for that little thing would be a bloat in the kernel. Also, if we can figure out where the order comes from, we might want to keep it unsorted, as a feature. :P Am I wrong? > One assumes that more than libdisk might want to get > at this data.=20 Then these consumers have to assume that the data is unsorted. Anyways, it's much easier to do it oustide the kernel. > In any case, for this particular case doing it in > libdisk would be fine. Here is a quick hack on libdisk to deal with this. It uses qsort since I wanted to see how it works but anyone is free to implement its own algorithm. ;) And actually, it might be best to use mergesort since the entries are likely to be sorted. This patches changes a meaningless variable name, adds a auxiliary comparaison function (since strcmp doesn't take **char pointers), and removes extra return's to leave just one at the end. A. --bGR76rFJjkSxVeRa Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch1 Content-Transfer-Encoding: quoted-printable Index: Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/lib/libdisk/Makefile,v retrieving revision 1.27.2.5 diff -u -r1.27.2.5 Makefile --- Makefile 18 Sep 2001 06:47:30 -0000 1.27.2.5 +++ Makefile 22 Dec 2001 23:58:22 -0000 @@ -6,7 +6,7 @@ INCS=3D libdisk.h =20 # Remove KERN_DISKS_BROKEN when kern.disks sysctl returns disks in sorted = order -CFLAGS+=3D -Wall -DKERN_DISKS_BROKEN +CFLAGS+=3D -Wall .if ${MACHINE} =3D=3D "pc98" CFLAGS+=3D -DPC98 .endif Index: disk.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/lib/libdisk/disk.c,v retrieving revision 1.50.2.14 diff -u -r1.50.2.14 disk.c --- disk.c 18 Sep 2001 06:47:30 -0000 1.50.2.14 +++ disk.c 23 Dec 2001 00:43:01 -0000 @@ -483,10 +483,18 @@ static char * device_list[] =3D {"aacd", "ad", "da", "afd", "fla", "idad",= "mlxd", "amrd", "twed", "ar", "fd", 0}; #endif =20 +int qstrcmp(const void* a, const void* b) { + + char *str1 =3D *(char**)a; + char *str2 =3D *(char**)b; + return strcmp(str1, str2); + +} + char ** Disk_Names() { - int i,j,k; + int i,j,disk_cnt; char disk[25]; char diskname[25]; struct stat st; @@ -506,14 +514,16 @@ error =3D sysctlbyname("kern.disks", disklist, &listsize, NULL, 0); if (error)=20 return NULL; - k =3D 0; - for (dp =3D disks; ((*dp =3D strsep(&disklist, " ")) !=3D NULL) && k = < MAX_NO_DISKS; k++, dp++); - return disks; - } + disk_cnt =3D 0; + for (dp =3D disks; ((*dp =3D strsep(&disklist, " ")) !=3D NULL) &&=20 + disk_cnt < MAX_NO_DISKS; disk_cnt++, dp++); + } else { warn("kern.disks sysctl not available"); #endif - k =3D 0; + disk_cnt =3D 0; for (j =3D 0; device_list[j]; j++) { + if(disk_cnt >=3D MAX_NO_DISKS) + break; for (i =3D 0; i < MAX_NO_DISKS; i++) { sprintf(diskname, "%s%d", device_list[j], i); sprintf(disk, _PATH_DEV"%s", diskname); @@ -529,12 +539,17 @@ continue; } close(fd); - disks[k++] =3D strdup(diskname); - if(k =3D=3D MAX_NO_DISKS) - return disks; + disks[disk_cnt++] =3D strdup(diskname); + if(disk_cnt >=3D MAX_NO_DISKS) + break; } } - return disks; +#if !defined(PC98) && !defined(KERN_DISKS_BROKEN) + } +#endif + qsort(disks, disk_cnt, sizeof(char*), qstrcmp); + =20 + return disks; } =20 #ifdef PC98 --bGR76rFJjkSxVeRa-- --7uYPyRQQ5N0D02nI 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 iEYEARECAAYFAjwlK1gACgkQttcWHAnWiGcJjACgh5WL5wD85/hyrMCIzYBl26xI g9QAnA2E4wU1jxvU/lVCG43UbfhP24PX =S4yR -----END PGP SIGNATURE----- --7uYPyRQQ5N0D02nI-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 22 17: 2:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tomts9-srv.bellnexxia.net (tomts9.bellnexxia.net [209.226.175.53]) by hub.freebsd.org (Postfix) with ESMTP id E6A9037B416; Sat, 22 Dec 2001 17:02:16 -0800 (PST) Received: from khan.anarcat.dyndns.org ([65.94.189.35]) by tomts9-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20011223010215.PMYB3274.tomts9-srv.bellnexxia.net@khan.anarcat.dyndns.org>; Sat, 22 Dec 2001 20:02:15 -0500 Received: from shall.anarcat.dyndns.org (shall.anarcat.dyndns.org [192.168.0.1]) by khan.anarcat.dyndns.org (Postfix) with ESMTP id A0DDB1AB9; Sat, 22 Dec 2001 20:02:12 -0500 (EST) Received: by shall.anarcat.dyndns.org (Postfix, from userid 1000) id 7749020ACB; Sat, 22 Dec 2001 20:02:04 -0500 (EST) Date: Sat, 22 Dec 2001 20:02:03 -0500 From: The Anarcat To: gnats-admin@FreeBSD.org, freebsd-bugs@FreeBSD.org Cc: freebsd-gnats-submit@freebsd.org, arch@freebsd.org Subject: Re: bin/33070: libdisk::Disk_Names() returns empty strings Message-ID: <20011223010203.GF530@shall.anarcat.dyndns.org> References: <20011221220558.8DEB020ACD@shall.anarcat.dyndns.org> <200112212210.fBLMA1N83908@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112212210.fBLMA1N83908@freefall.freebsd.org> User-Agent: Mutt/1.3.24i 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 because of a commit to libdisk which disables the use of kern.disks because it doesn't sort its output. The alternate method of getting the disk list is to stat devices and try to open them which fails if you're a regular user. Here is a proper fix that sort the output of kern.disks in Disk_Names() instead. Index: Makefile =================================================================== RCS file: /home/ncvs/src/lib/libdisk/Makefile,v retrieving revision 1.27.2.5 diff -u -r1.27.2.5 Makefile --- Makefile 18 Sep 2001 06:47:30 -0000 1.27.2.5 +++ Makefile 22 Dec 2001 23:58:22 -0000 @@ -6,7 +6,7 @@ INCS= libdisk.h -# Remove KERN_DISKS_BROKEN when kern.disks sysctl returns disks in sorted order -CFLAGS+= -Wall -DKERN_DISKS_BROKEN +CFLAGS+= -Wall .if ${MACHINE} == "pc98" CFLAGS+= -DPC98 .endif Index: disk.c =================================================================== RCS file: /home/ncvs/src/lib/libdisk/disk.c,v retrieving revision 1.50.2.14 diff -u -r1.50.2.14 disk.c --- disk.c 18 Sep 2001 06:47:30 -0000 1.50.2.14 +++ disk.c 23 Dec 2001 00:43:01 -0000 @@ -483,10 +483,18 @@ static char * device_list[] = {"aacd", "ad", "da", "afd", "fla", "idad", "mlxd", "amrd", "twed", "ar", "fd", 0}; #endif +int qstrcmp(const void* a, const void* b) { + + char *str1 = *(char**)a; + char *str2 = *(char**)b; + return strcmp(str1, str2); + +} + char ** Disk_Names() { - int i,j,k; + int i,j,disk_cnt; char disk[25]; char diskname[25]; struct stat st; @@ -506,14 +514,16 @@ error = sysctlbyname("kern.disks", disklist, &listsize, NULL, 0); if (error) return NULL; - k = 0; - for (dp = disks; ((*dp = strsep(&disklist, " ")) != NULL) && k < MAX_NO_DISKS; k++, dp++); - return disks; - } + disk_cnt = 0; + for (dp = disks; ((*dp = strsep(&disklist, " ")) != NULL) && + disk_cnt < MAX_NO_DISKS; disk_cnt++, dp++); + } else { warn("kern.disks sysctl not available"); #endif - k = 0; + disk_cnt = 0; for (j = 0; device_list[j]; j++) { + if(disk_cnt >= MAX_NO_DISKS) + break; for (i = 0; i < MAX_NO_DISKS; i++) { sprintf(diskname, "%s%d", device_list[j], i); sprintf(disk, _PATH_DEV"%s", diskname); @@ -529,12 +539,17 @@ continue; } close(fd); - disks[k++] = strdup(diskname); - if(k == MAX_NO_DISKS) - return disks; + disks[disk_cnt++] = strdup(diskname); + if(disk_cnt >= MAX_NO_DISKS) + break; } } - return disks; +#if !defined(PC98) && !defined(KERN_DISKS_BROKEN) + } +#endif + qsort(disks, disk_cnt, sizeof(char*), qstrcmp); + + return disks; } #ifdef PC98 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 22 18: 7:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 2C0A737B405; Sat, 22 Dec 2001 18:07:18 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fBN270G33803; Sat, 22 Dec 2001 18:07:00 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: The Anarcat Cc: arch@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: sysctl kern.disks shouldn't have to sort its output In-Reply-To: Message from The Anarcat of "Sat, 22 Dec 2001 19:54:50 EST." <20011223005449.GE530@shall.anarcat.dyndns.org> Date: Sat, 22 Dec 2001 18:07:00 -0800 Message-ID: <33799.1009073220@winston.freebsd.org> From: Jordan Hubbard 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 > Yes, of course. But I wonder how best it would be implemented... By > controlling how entries are added to the list, or by controlling how he > prints those entries? It's only useful if you control how the entries are added to the Disks ** structure. > Because it is a list, sorting it is not very efficient. At the output It's small. You can bubble sort it for all we care. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 22 18:12:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tomts14-srv.bellnexxia.net (tomts14.bellnexxia.net [209.226.175.35]) by hub.freebsd.org (Postfix) with ESMTP id 531E937B417; Sat, 22 Dec 2001 18:12:56 -0800 (PST) Received: from khan.anarcat.dyndns.org ([65.94.189.35]) by tomts14-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20011223021255.VHNU6216.tomts14-srv.bellnexxia.net@khan.anarcat.dyndns.org>; Sat, 22 Dec 2001 21:12:55 -0500 Received: from shall.anarcat.dyndns.org (shall.anarcat.dyndns.org [192.168.0.1]) by khan.anarcat.dyndns.org (Postfix) with ESMTP id B80BA1B1D; Sat, 22 Dec 2001 21:12:51 -0500 (EST) Received: by shall.anarcat.dyndns.org (Postfix, from userid 1000) id 6138C20ACB; Sat, 22 Dec 2001 21:12:45 -0500 (EST) Date: Sat, 22 Dec 2001 21:12:45 -0500 From: The Anarcat To: Jordan Hubbard Cc: arch@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: sysctl kern.disks shouldn't have to sort its output Message-ID: <20011223021244.GG530@shall.anarcat.dyndns.org> References: <20011223005449.GE530@shall.anarcat.dyndns.org> <33799.1009073220@winston.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dMyqICaxQaaUjrCL" Content-Disposition: inline In-Reply-To: <33799.1009073220@winston.freebsd.org> User-Agent: Mutt/1.3.24i 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 --dMyqICaxQaaUjrCL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat Dec 22, 2001 at 06:07:00PM -0800, Jordan Hubbard wrote: > > Yes, of course. But I wonder how best it would be implemented... By > > controlling how entries are added to the list, or by controlling how he > > prints those entries? >=20 > It's only useful if you control how the entries are added to the Disks ** > structure. hmm.. yes, of course. my mind is going blur. > > Because it is a list, sorting it is not very efficient. At the output >=20 > It's small. You can bubble sort it for all we care. :) yeah, I guess. So one could just implement sorting stuff in disk_create... Insert the item in a proper place in the list instead of just putting it on top... yes-yes... I'll take a look at this again. a. --dMyqICaxQaaUjrCL 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 iEYEARECAAYFAjwlPZcACgkQttcWHAnWiGfQpQCeIun/8EhWedszBsa4OiWRz/n5 fwwAnRmC367EDU8dsC3CgblXssm5A2lC =F0tz -----END PGP SIGNATURE----- --dMyqICaxQaaUjrCL-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 22 21:25:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id E665F37B405 for ; Sat, 22 Dec 2001 21:25:10 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.6/8.11.4) id fBN5Or691318; Sat, 22 Dec 2001 21:24:53 -0800 (PST) (envelope-from kris) Date: Sat, 22 Dec 2001 21:24:53 -0800 From: Kris Kennaway To: Peter Wemm Cc: Yuri Karaban , freebsd-arch@FreeBSD.ORG Subject: Re: gnu getopt in libc Message-ID: <20011222212453.A91247@citusc17.usc.edu> References: <20011222132030.GA19596@sphinx.univ.kiev.ua> <20011222201930.B9DEF38CC@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011222201930.B9DEF38CC@overcee.netplex.com.au>; from peter@wemm.org on Sat, Dec 22, 2001 at 12:19:30PM -0800 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 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 22, 2001 at 12:19:30PM -0800, Peter Wemm wrote: > Yuri Karaban wrote: > > gnu getopt supports long options and can reorder option keys > > so i can write: > > some_program -a -b -c file1 file2 -d -e -f > >=20 > > FreeBSD getopt in libc very simple it can recoginze only one letter > > arguments, does not support optional arguments and arguments to > > program may appear only at the beginning. > >=20 > > so why dont replace libc/stdlib/getopt.c by gnu version ? >=20 > 1) because it is nonstandard > 2) it is GPL contaminated which we cannot use in libc. NetBSD have a BSDL'ed getopt_long() in their libc. It's required for GNU tar longopt support in pax(1) - I have an almost complete port of both in my tree. Kris --AqsLC8rIMeq19msA 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 iD8DBQE8JWqjWry0BWjoQKURAilQAKC2i9ZoLwYs1TFjq0ehNJTfLvlReACeLTgM wOrUSXOuRiS4FYT+yBWIQRI= =7TwO -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message