From owner-freebsd-arch Sun Jun 11 1:23:20 2000 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by hub.freebsd.org (Postfix) with ESMTP id C806237B57A for ; Sun, 11 Jun 2000 01:23:11 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 13131P-000HIx-0Y; Sun, 11 Jun 2000 09:23:07 +0100 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA73221; Sun, 11 Jun 2000 09:24:11 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 11 Jun 2000 09:27:51 +0100 (BST) From: Doug Rabson To: Luoqi Chen Cc: arch@FreeBSD.ORG Subject: Re: Syscalls and execve In-Reply-To: <200006110059.e5B0xpk14371@lor.watermarkgroup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 10 Jun 2000, Luoqi Chen wrote: > > I think an exec_trampoline might well be the best solution. I can't quite > > see how to work it though. > > > > -- > > Doug Rabson Mail: dfr@nlsystems.com > > Nonlinear Systems Ltd. Phone: +44 20 8442 9037 > > > I would put the trampoline code right below the arguments, so it won't waste > any stack space. I would first place $pc, $a0, $a3 values into $ra, $s0, $s1 > registers in the shorter trapframe, and in the trampoline code, copy from > $s0/1 to $a0/3, clear $s0/1 and other volatile registers, return. That sounds workable. I'll see about doing that - thanks for the idea. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 12 14:44:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 9F98F37BC6A for ; Mon, 12 Jun 2000 14:44:37 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id PAA03316 for ; Mon, 12 Jun 2000 15:44:35 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA09927 for ; Mon, 12 Jun 2000 15:43:32 -0600 (MDT) Message-Id: <200006122143.PAA09927@harmony.village.org> Subject: Re: unknown devices To: arch@freebsd.org In-reply-to: Your message of "Mon, 12 Jun 2000 12:28:38 MDT." <200006121828.MAA09056@harmony.village.org> References: <200006121828.MAA09056@harmony.village.org> <200006121824.OAA95047@khavrinen.lcs.mit.edu> <200006121457.KAA94223@khavrinen.lcs.mit.edu> <200006120151.TAA04709@harmony.village.org> <200006121811.MAA08944@harmony.village.org> Date: Mon, 12 Jun 2000 15:43:32 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It has been suggested that this might be a better place to talk about this. Warner In message <200006121828.MAA09056@harmony.village.org> Warner Losh writes: : In message <200006121824.OAA95047@khavrinen.lcs.mit.edu> Garrett : Wollman writes: : : < said: : : : : > that. With 10 PnP devices in my laptop, I get a full screen of dmesg : : > each time I load/unload... : : : : Only announce the first time? : : I think we could do that. We could put something in the detach : routine so that the device is marked quiet at that point. I'll have : to see if that actually works or not. But there's a catch, if I do : that, then the new device will be marked as quiet and won't print its : probe messages. :-( At least that's what I think would happen. I'll : have to try it out once I unpack the laptop. : : Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 12 23:23: 7 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 8CDAB37B77A; Mon, 12 Jun 2000 23:23:04 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id AAA04942; Tue, 13 Jun 2000 00:23:01 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA12159; Tue, 13 Jun 2000 00:21:57 -0600 (MDT) Message-Id: <200006130621.AAA12159@harmony.village.org> To: Doug Rabson Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h Cc: arch@FreeBSD.org In-reply-to: Your message of "Fri, 09 Jun 2000 09:00:31 PDT." <200006091600.JAA25038@freefall.freebsd.org> References: <200006091600.JAA25038@freefall.freebsd.org> Date: Tue, 13 Jun 2000 00:21:57 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200006091600.JAA25038@freefall.freebsd.org> Doug Rabson writes: : dfr 2000/06/09 09:00:31 PDT : : Modified files: : sys/pci pci.c pcisupport.c pcivar.h : Log: : Nuke the useless chip driver. It gets in the way when you want to load : a functional driver for the device. : : Revision Changes Path : 1.153 +2 -1 src/sys/pci/pci.c : 1.163 +3 -51 src/sys/pci/pcisupport.c : 1.46 +2 -1 src/sys/pci/pcivar.h Personally I think that we should add it back as a "loose" or "generic" device after I finish the work on the unknown driver. This would allow you to do the same thing, and still have decent boot messages. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 0:25:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by hub.freebsd.org (Postfix) with ESMTP id F1E7D37BAB7 for ; Tue, 13 Jun 2000 00:25:20 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 131l4X-000HhD-0Y; Tue, 13 Jun 2000 08:25:17 +0100 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id IAA14192; Tue, 13 Jun 2000 08:26:43 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Tue, 13 Jun 2000 08:29:51 +0100 (BST) From: Doug Rabson To: Daniel Eischen Cc: Bruce Evans , arch@FreeBSD.ORG Subject: Re: Syscalls and execve In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 10 Jun 2000, Daniel Eischen wrote: > On Sat, 10 Jun 2000, Doug Rabson wrote: > > The trapframe which is created for syscall is identical to the trapframe > > for exceptions and interrupts, its just not fully populated with register > > values. > > On a related subject, the alpha sigcontext is different than the > trapframe. This makes implementing {get,set}context slightly more > difficult because they have to know which frame is in the machine > context. For the new threads architecture (similar to scheduler > activations), the context of threads that become unblocked in > the kernel is passed out to the user threads library. I want to > add {get,set}context as library routines and use them to handle > both signal contexts and trapframes as passed out of the kernel. > > This isn't a big deal, we can just have a different set of routines > to handle trapframes for the alpha, but if there is an opportunity > to make trapframes and signal frames consistent (as they are on > i386)... It would be difficult to make trapframe match sigcontext without changing sigcontext to look more like the current trapframe (which is partly dictated by PALcode). I don't think the associated cost of changing the kernel ABI is worth the gain. Also, the fpregs state is totally unneeded for trapframe since the kernel doesn't disturb the fp state during traps. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 1:27:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by hub.freebsd.org (Postfix) with ESMTP id 37D5A37BAED; Tue, 13 Jun 2000 01:27:16 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 131m2V-0006FW-0C; Tue, 13 Jun 2000 08:27:15 +0000 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA84221; Tue, 13 Jun 2000 09:28:59 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Tue, 13 Jun 2000 09:32:07 +0100 (BST) From: Doug Rabson To: Warner Losh Cc: Doug Rabson , arch@FreeBSD.org Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h In-Reply-To: <200006130621.AAA12159@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jun 2000, Warner Losh wrote: > In message <200006091600.JAA25038@freefall.freebsd.org> Doug Rabson writes: > : dfr 2000/06/09 09:00:31 PDT > : > : Modified files: > : sys/pci pci.c pcisupport.c pcivar.h > : Log: > : Nuke the useless chip driver. It gets in the way when you want to load > : a functional driver for the device. > : > : Revision Changes Path > : 1.153 +2 -1 src/sys/pci/pci.c > : 1.163 +3 -51 src/sys/pci/pcisupport.c > : 1.46 +2 -1 src/sys/pci/pcivar.h > > Personally I think that we should add it back as a "loose" or > "generic" device after I finish the work on the unknown driver. This > would allow you to do the same thing, and still have decent boot > messages. The nomatch method already reports the existence of the devices during boot (with correct descriptions for devices which we recognise). -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 1:43:45 2000 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by hub.freebsd.org (Postfix) with ESMTP id 2B92437BD3A; Tue, 13 Jun 2000 01:43:42 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 131mIO-000NRu-0Y; Tue, 13 Jun 2000 09:43:41 +0100 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA05790; Tue, 13 Jun 2000 09:45:23 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Tue, 13 Jun 2000 09:48:31 +0100 (BST) From: Doug Rabson To: Warner Losh Cc: Doug Rabson , arch@freebsd.org Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h In-Reply-To: <200006130621.AAA12159@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jun 2000, Warner Losh wrote: > In message <200006091600.JAA25038@freefall.freebsd.org> Doug Rabson writes: > : dfr 2000/06/09 09:00:31 PDT > : > : Modified files: > : sys/pci pci.c pcisupport.c pcivar.h > : Log: > : Nuke the useless chip driver. It gets in the way when you want to load > : a functional driver for the device. > : > : Revision Changes Path > : 1.153 +2 -1 src/sys/pci/pci.c > : 1.163 +3 -51 src/sys/pci/pcisupport.c > : 1.46 +2 -1 src/sys/pci/pcivar.h > > Personally I think that we should add it back as a "loose" or > "generic" device after I finish the work on the unknown driver. This > would allow you to do the same thing, and still have decent boot > messages. As I said on in a reply to committers, this is probably best handled by the nomatch method of the pci driver. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 1:47:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 91F7537BD3B; Tue, 13 Jun 2000 01:47:14 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id KAA08949; Tue, 13 Jun 2000 10:47:06 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Doug Rabson Cc: Warner Losh , Doug Rabson , arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h In-reply-to: Your message of "Tue, 13 Jun 2000 09:48:31 BST." Date: Tue, 13 Jun 2000 10:47:06 +0200 Message-ID: <8947.960886026@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >As I said on in a reply to committers, this is probably best handled by >the nomatch method of the pci driver. Completely unrelated to where we do this, I have had a fair number of people ask me why we don't say stuff like: "Found Configure \"blaha\" driver in your kernel" I can see all the bloat arguments, but I have to say that the idea has some merit... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | 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 Tue Jun 13 1:56:10 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.sunesi.net (ns1.sunesi.net [196.15.192.194]) by hub.freebsd.org (Postfix) with ESMTP id E2C4F37BD85; Tue, 13 Jun 2000 01:56:02 -0700 (PDT) (envelope-from nbm@sunesi.net) Received: from nbm by ns1.sunesi.net with local (Exim 3.03 #1) id 131mRx-000PV7-00; Tue, 13 Jun 2000 10:53:33 +0200 Date: Tue, 13 Jun 2000 10:53:32 +0200 From: Neil Blakey-Milner To: Poul-Henning Kamp Cc: Doug Rabson , Warner Losh , Doug Rabson , arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h Message-ID: <20000613105332.A97964@mithrandr.moria.org> References: <8947.960886026@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <8947.960886026@critter.freebsd.dk>; from phk@critter.freebsd.dk on Tue, Jun 13, 2000 at 10:47:06AM +0200 Organization: Sunesi Clinical Systems X-Operating-System: FreeBSD 3.3-RELEASE i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue 2000-06-13 (10:47), Poul-Henning Kamp wrote: > >As I said on in a reply to committers, this is probably best handled by > >the nomatch method of the pci driver. > > Completely unrelated to where we do this, I have had a fair number of > people ask me why we don't say stuff like: > > "Found Configure \"blaha\" driver in your kernel" > > I can see all the bloat arguments, but I have to say that the idea > has some merit... It would be nice (as well as in the kernel boot, or as an alternative) if we could do this from userland. Basically just all those PNP and PCI ids cross referenced with the module name, and then we can just click and drool to load the module. As we become more able to use libh, this will become a very useful feature. (which reminds me that I should get back to the sysctl enumeration of newbus devices, which may help in this) Neil -- Neil Blakey-Milner Sunesi Clinical Systems nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 2:35:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 234B337BA5F for ; Tue, 13 Jun 2000 02:35:38 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id FAA24198; Tue, 13 Jun 2000 05:32:33 -0400 (EDT) Date: Tue, 13 Jun 2000 05:32:33 -0400 (EDT) From: Daniel Eischen To: Doug Rabson Cc: Bruce Evans , arch@FreeBSD.ORG Subject: Re: Syscalls and execve In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jun 2000, Doug Rabson wrote: > On Sat, 10 Jun 2000, Daniel Eischen wrote: > > > On Sat, 10 Jun 2000, Doug Rabson wrote: > > > The trapframe which is created for syscall is identical to the trapframe > > > for exceptions and interrupts, its just not fully populated with register > > > values. > > > > On a related subject, the alpha sigcontext is different than the > > trapframe. This makes implementing {get,set}context slightly more > > difficult because they have to know which frame is in the machine > > context. For the new threads architecture (similar to scheduler > > activations), the context of threads that become unblocked in > > the kernel is passed out to the user threads library. I want to > > add {get,set}context as library routines and use them to handle > > both signal contexts and trapframes as passed out of the kernel. > > > > This isn't a big deal, we can just have a different set of routines > > to handle trapframes for the alpha, but if there is an opportunity > > to make trapframes and signal frames consistent (as they are on > > i386)... > > It would be difficult to make trapframe match sigcontext without changing > sigcontext to look more like the current trapframe (which is partly > dictated by PALcode). I don't think the associated cost of changing the > kernel ABI is worth the gain. Also, the fpregs state is totally unneeded > for trapframe since the kernel doesn't disturb the fp state during traps. OK, I've been using a flags word to indicate whether it's a trapframe or a sigcontext. I'm not worried about the fpregs, since they seem to be already flagged as saved or not saved. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 2:57:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 6DF5E37B9D5; Tue, 13 Jun 2000 02:57:28 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id LAA09397; Tue, 13 Jun 2000 11:57:25 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org Cc: wpaul@freebsd.org Subject: space for chip descriptors in mbuf ? From: Poul-Henning Kamp Date: Tue, 13 Jun 2000 11:57:25 +0200 Message-ID: <9395.960890245@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems to me that most of the bus-master based network cards use some kind of "packet descriptor" for describing a slice of data in RAM. At least in the drivers I've been working on, one such descriptor is needed for every mbuf (not per packet!) sent or received. Is it time to add space in the mbuf for this overhead, rather than have every single driver allocate these petite data structures for every mbuf they touch ? Something like 16 bytes should cover most chips I know of, but I'm sure Bill Paul has a better census on what ethernet chips seem to prefer for this size ? I have examined the packet-size histogram of trafic in the AS6785 network and I find: MLEN delta % short packets 236 0 50.8504 220 -16 50.4915 216 -20 50.3645 212 -24 50.2045 208 -28 49.9585 204 -32 49.5745 200 -36 49.3126 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | 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 Tue Jun 13 9: 5:25 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 4E3C537B54F for ; Tue, 13 Jun 2000 09:05:13 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA03333 for ; Tue, 13 Jun 2000 09:05:09 -0700 Date: Tue, 13 Jun 2000 09:05:04 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h In-Reply-To: <20000613105332.A97964@mithrandr.moria.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG We discussed this very extensively during SparcStation-1 development. In fact early SunOS 4.0.3c prior to release had just something like this (the code stayed around for years protected by "DAVE_DOESNT_WANT_THIS_ANY_MORE"). The consensus eventually was that this was pointless because the ultimate goal is to have all possible available drivers sit somewhere and just be loaded if the h/w was present. Once you get even close to the goal of all self-identifying devices (which is pretty darn close now), what's the added advantage of a message that most users won't grok and will generate a support call about (I'm talking commercial space here)? -matt On Tue, 13 Jun 2000, Neil Blakey-Milner wrote: > On Tue 2000-06-13 (10:47), Poul-Henning Kamp wrote: > > >As I said on in a reply to committers, this is probably best handled by > > >the nomatch method of the pci driver. > > > > Completely unrelated to where we do this, I have had a fair number of > > people ask me why we don't say stuff like: > > > > "Found Configure \"blaha\" driver in your kernel" > > > > I can see all the bloat arguments, but I have to say that the idea > > has some merit... > > It would be nice (as well as in the kernel boot, or as an alternative) > if we could do this from userland. Basically just all those PNP and PCI > ids cross referenced with the module name, and then we can just click > and drool to load the module. > > As we become more able to use libh, this will become a very useful > feature. > > (which reminds me that I should get back to the sysctl enumeration of > newbus devices, which may help in this) > > Neil > -- > Neil Blakey-Milner > Sunesi Clinical Systems > nbm@mithrandr.moria.org > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 9:21:35 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id C662037BEFF; Tue, 13 Jun 2000 09:21:31 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id KAA06944; Tue, 13 Jun 2000 10:21:29 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id KAA14918; Tue, 13 Jun 2000 10:20:24 -0600 (MDT) Message-Id: <200006131620.KAA14918@harmony.village.org> To: Poul-Henning Kamp Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h Cc: Doug Rabson , Doug Rabson , arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 13 Jun 2000 10:47:06 +0200." <8947.960886026@critter.freebsd.dk> References: <8947.960886026@critter.freebsd.dk> Date: Tue, 13 Jun 2000 10:20:24 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <8947.960886026@critter.freebsd.dk> Poul-Henning Kamp writes: : "Found Configure \"blaha\" driver in your kernel" : : I can see all the bloat arguments, but I have to say that the idea : has some merit... How could the kernel know all possible device drivers, even third party ones? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 9:26:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id BDC8737BF0B; Tue, 13 Jun 2000 09:26:34 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA03448; Tue, 13 Jun 2000 09:25:45 -0700 Date: Tue, 13 Jun 2000 09:25:40 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Warner Losh Cc: Poul-Henning Kamp , Doug Rabson , Doug Rabson , arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h In-Reply-To: <200006131620.KAA14918@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : "Found Configure \"blaha\" driver in your kernel" > : > : I can see all the bloat arguments, but I have to say that the idea > : has some merit... > > How could the kernel know all possible device drivers, even third > party ones? That's the point about how Solaris does this (or did- originally). I have a card identifying itself as "Fred". At boot (or boot/reconfigure) time, you tentatively load all drivers and enter their identify entry point with a dev_info_t asking, "do you drive this device?". Simple enough. The hard part is to try (if you think it's important) to arbitrate between several different drivers who want to drive that device. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 9:26:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 0C2DE37BF0B for ; Tue, 13 Jun 2000 09:26:47 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id JAA01160; Tue, 13 Jun 2000 09:26:55 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAAgOaGoc; Tue Jun 13 09:26:47 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id JAA08218; Tue, 13 Jun 2000 09:26:33 -0700 (MST) From: Terry Lambert Message-Id: <200006131626.JAA08218@usr05.primenet.com> Subject: Re: Syscalls and execve To: dfr@nlsystems.com (Doug Rabson) Date: Tue, 13 Jun 2000 16:26:33 +0000 (GMT) Cc: eischen@vigrid.com (Daniel Eischen), bde@zeta.org.au (Bruce Evans), arch@FreeBSD.ORG In-Reply-To: from "Doug Rabson" at Jun 13, 2000 08:29:51 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > This isn't a big deal, we can just have a different set of routines > > to handle trapframes for the alpha, but if there is an opportunity > > to make trapframes and signal frames consistent (as they are on > > i386)... > > It would be difficult to make trapframe match sigcontext without changing > sigcontext to look more like the current trapframe (which is partly > dictated by PALcode). I don't think the associated cost of changing the > kernel ABI is worth the gain. Also, the fpregs state is totally unneeded > for trapframe since the kernel doesn't disturb the fp state during traps. What do NetBSD and OSF (DEC UNIX/TRUE64) do? I would think binary compatability with them was more important anyway... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 9:27:36 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 559CA37BF93 for ; Tue, 13 Jun 2000 09:27:33 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id KAA07004; Tue, 13 Jun 2000 10:27:31 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id KAA15017; Tue, 13 Jun 2000 10:26:26 -0600 (MDT) Message-Id: <200006131626.KAA15017@harmony.village.org> To: mjacob@feral.com Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 13 Jun 2000 09:25:40 PDT." References: Date: Tue, 13 Jun 2000 10:26:26 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Matthew Jacob writes: : I have a card identifying itself as "Fred". At boot (or boot/reconfigure) : time, you tentatively load all drivers and enter their identify entry point : with a dev_info_t asking, "do you drive this device?". Simple enough. The hard : part is to try (if you think it's important) to arbitrate between several : different drivers who want to drive that device. Most of this is present in FreeBSD right now, except for load all drivers at boot and unload the ones that don't probe. We're moving away from hard wired configuration, so it becomes more and more possible to have all drivers just load and unload as needed. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 9:29:12 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 6A7A337BF9B; Tue, 13 Jun 2000 09:29:09 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id JAA01736; Tue, 13 Jun 2000 09:29:17 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAApYaywd; Tue Jun 13 09:29:11 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id JAA08308; Tue, 13 Jun 2000 09:28:58 -0700 (MST) From: Terry Lambert Message-Id: <200006131628.JAA08308@usr05.primenet.com> Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Tue, 13 Jun 2000 16:28:58 +0000 (GMT) Cc: dfr@nlsystems.com (Doug Rabson), imp@village.org (Warner Losh), dfr@FreeBSD.ORG (Doug Rabson), arch@FreeBSD.ORG In-Reply-To: <8947.960886026@critter.freebsd.dk> from "Poul-Henning Kamp" at Jun 13, 2000 10:47:06 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Completely unrelated to where we do this, I have had a fair number of > people ask me why we don't say stuff like: > > "Found Configure \"blaha\" driver in your kernel" > > I can see all the bloat arguments, but I have to say that the idea > has some merit... So would just loading the frigging driver from the modules directory, instead of beating the user over the head to do it for you. If you know what the problem is well enough to emit an error message, and you have the code available in the kernel to do what the error message says is the pallative action, then why not just do it, instead of tunneling your instructions through a human to a config prgram, back to the kernel asking for the action? Humans are notoriously lossy data transports. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 9:31:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id B715C37BF2C for ; Tue, 13 Jun 2000 09:31:14 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA03492; Tue, 13 Jun 2000 09:31:09 -0700 Date: Tue, 13 Jun 2000 09:31:05 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h In-Reply-To: <200006131626.KAA15017@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : time, you tentatively load all drivers and enter their identify entry point > : with a dev_info_t asking, "do you drive this device?". Simple enough. The hard > : part is to try (if you think it's important) to arbitrate between several > : different drivers who want to drive that device. > > Most of this is present in FreeBSD right now, except for load all > drivers at boot and unload the ones that don't probe. *cough*. Let me correct myself. Strictly speaking, Solaris doesn't do quite do this. It only loads drivers for which it it finds a binding to a hardware name. I argued strenously for the 'load all' case because if you start with everything loaded, you can sort out, in memory, the bus interconnects, w/o having to do any fancy special case dependencies or any 'side' configs for booting. But I lost that argument back in 1990. > We're moving away from hard wired configuration, so it becomes more and > more possible to have all drivers just load and unload as needed. That's right. That's why I haven't screamed at Peter for all the surprise roto-tilling in config becuase it's the right start in that direction. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 9:35: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 7347837BF2C for ; Tue, 13 Jun 2000 09:34:59 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id KAA07066; Tue, 13 Jun 2000 10:34:57 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id KAA15134; Tue, 13 Jun 2000 10:33:51 -0600 (MDT) Message-Id: <200006131633.KAA15134@harmony.village.org> To: mjacob@feral.com Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 13 Jun 2000 09:31:05 PDT." References: Date: Tue, 13 Jun 2000 10:33:51 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Matthew Jacob writes: : That's right. That's why I haven't screamed at Peter for all the surprise : roto-tilling in config becuase it's the right start in that direction. He's only committed the more minor roto-tilling too... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 9:35:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id C710B37B672 for ; Tue, 13 Jun 2000 09:35:53 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id JAA07452; Tue, 13 Jun 2000 09:35:34 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAAyXayHo; Tue Jun 13 09:35:27 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id JAA08394; Tue, 13 Jun 2000 09:35:43 -0700 (MST) From: Terry Lambert Message-Id: <200006131635.JAA08394@usr05.primenet.com> Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h To: mjacob@feral.com Date: Tue, 13 Jun 2000 16:35:43 +0000 (GMT) Cc: arch@FreeBSD.ORG In-Reply-To: from "Matthew Jacob" at Jun 13, 2000 09:05:04 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > We discussed this very extensively during SparcStation-1 development. In fact > early SunOS 4.0.3c prior to release had just something like this (the code > stayed around for years protected by "DAVE_DOESNT_WANT_THIS_ANY_MORE"). > > The consensus eventually was that this was pointless because the ultimate goal > is to have all possible available drivers sit somewhere and just be loaded if > the h/w was present. > > Once you get even close to the goal of all self-identifying devices (which is > pretty darn close now), what's the added advantage of a message that most > users won't grok and will generate a support call about (I'm talking > commercial space here)? Exactly. The PCI issue is unique, in that PCI devices can be identified by a generic routine. For this to be general, we would need the concept of discaradable vs. non-discardable pages. ELF format actually handles this rather well, and Microsoft uses it to advantage in their portable executable format. In fact, they have the following useful flags, expected to be applied to discrete ELF sections: nonswappable is the code in the swap path? initialization this code only used on module load, and its pages can be recovered afterward relocatable with appropriate locking, you can move this code around to defragment kernel memory, since it is accessed by handle etc. The same for data sections, of course. Looking at the PE documentation on the microsoft.com site would not be a bad idea for people hacking this code; in particular, you can learn from them, even if you consider them your enemy. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 9:38: 8 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp09.phx.gblx.net (smtp09.phx.gblx.net [206.165.6.139]) by hub.freebsd.org (Postfix) with ESMTP id 53ED037BED5; Tue, 13 Jun 2000 09:38:03 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp09.phx.gblx.net (8.9.3/8.9.3) id JAA38864; Tue, 13 Jun 2000 09:37:56 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp09.phx.gblx.net, id smtpdkeAKEa; Tue Jun 13 09:37:50 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id JAA08514; Tue, 13 Jun 2000 09:37:49 -0700 (MST) From: Terry Lambert Message-Id: <200006131637.JAA08514@usr05.primenet.com> Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h To: imp@village.org (Warner Losh) Date: Tue, 13 Jun 2000 16:37:49 +0000 (GMT) Cc: phk@critter.freebsd.dk (Poul-Henning Kamp), dfr@nlsystems.com (Doug Rabson), dfr@FreeBSD.ORG (Doug Rabson), arch@FreeBSD.ORG In-Reply-To: <200006131620.KAA14918@harmony.village.org> from "Warner Losh" at Jun 13, 2000 10:20:24 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <8947.960886026@critter.freebsd.dk> Poul-Henning Kamp writes: > : "Found Configure \"blaha\" driver in your kernel" > : > : I can see all the bloat arguments, but I have to say that the idea > : has some merit... > > How could the kernel know all possible device drivers, even third > party ones? 1) Register them in a file 2) Read the file using kernel level file I/O 3) For simplicity sake, make each line in the file a fixed length; though some additional variable length text record stuff in the kernel would be useful eventually, the "edquota" approach is reasonable. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 9:42:25 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp09.phx.gblx.net (smtp09.phx.gblx.net [206.165.6.139]) by hub.freebsd.org (Postfix) with ESMTP id 32E9037B8F4 for ; Tue, 13 Jun 2000 09:42:22 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp09.phx.gblx.net (8.9.3/8.9.3) id JAA22354; Tue, 13 Jun 2000 09:42:19 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp09.phx.gblx.net, id smtpdGFi_Ma; Tue Jun 13 09:42:17 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id JAA08631; Tue, 13 Jun 2000 09:42:15 -0700 (MST) From: Terry Lambert Message-Id: <200006131642.JAA08631@usr05.primenet.com> Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h To: mjacob@feral.com Date: Tue, 13 Jun 2000 16:42:15 +0000 (GMT) Cc: imp@village.org (Warner Losh), arch@FreeBSD.ORG In-Reply-To: from "Matthew Jacob" at Jun 13, 2000 09:31:05 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Most of this is present in FreeBSD right now, except for load all > > drivers at boot and unload the ones that don't probe. > > *cough*. Let me correct myself. > > Strictly speaking, Solaris doesn't do quite do this. It only loads drivers for > which it it finds a binding to a hardware name. I argued strenously for the > 'load all' case because if you start with everything loaded, you can sort out, > in memory, the bus interconnects, w/o having to do any fancy special case > dependencies or any 'side' configs for booting. But I lost that argument back > in 1990. > > > We're moving away from hard wired configuration, so it becomes more and > > more possible to have all drivers just load and unload as needed. There is the corner case of legacy (non-self-identifying) hardware; for this hardware, you have to load the probe code and activate it. This is not the case for SBUS or PCI hardware, which can be data driven using a table. I think that the active probe case still needs to be dealt with. Windows 95/98/2000/NT handle this by paging in the probe code, running it, and if it probes true, paging in the driver and doing the attach. The probe code is then discarded. Each severable section is in a seperate ELF section, on a 4k page boundary (logical, not physical, in the ELF file). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 9:44:30 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 7CA3037BF4F for ; Tue, 13 Jun 2000 09:44:25 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA03609; Tue, 13 Jun 2000 09:44:19 -0700 Date: Tue, 13 Jun 2000 09:44:14 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h In-Reply-To: <200006131635.JAA08394@usr05.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The PCI issue is unique, in that PCI devices can be identified by > a generic routine. Most devices are self-identifying. It isn't just PCI. It's TurboChannel, SBus, and so on. What with PnP it's now getting to be the case that non-self-id'ing devices are the exception. > For this to be general, we would need the concept of discaradable > vs. non-discardable pages. ELF format actually handles this rather > well, and Microsoft uses it to advantage in their portable executable > format. > > In fact, they have the following useful flags, expected to be applied > to discrete ELF sections: > > > nonswappable is the code in the swap path? > initialization this code only used on module load, and its > pages can be recovered afterward > relocatable with appropriate locking, you can move this > code around to defragment kernel memory, > since it is accessed by handle > > etc. > > The same for data sections, of course. Yes. Further, you can, as I do in Solaris, use weak binding to determine the presence or absence of a (sub)driver as well. > Looking at the PE documentation on the microsoft.com site would not > be a bad idea for people hacking this code; in particular, you can > learn from them, even if you consider them your enemy. Hmph. Betcha it's one of the ex-DEC guys at Microsoft who worked on this. The stuff you describe above is pretty much the same as the .PSECT stuff for DEC PDP-11 executables (who on this list can still remember how to write .ODL files, too?). "Inside every large, fat, and dumb company is a small lean and agile company screaming to get out". -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 10: 9:55 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.cdrom.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id 0668637BC56 for ; Tue, 13 Jun 2000 10:09:51 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA22419; Tue, 13 Jun 2000 10:13:49 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200006131713.KAA22419@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: mjacob@feral.com Cc: arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h In-reply-to: Your message of "Tue, 13 Jun 2000 09:25:40 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jun 2000 10:13:49 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > : "Found Configure \"blaha\" driver in your kernel" > > : > > : I can see all the bloat arguments, but I have to say that the idea > > : has some merit... > > > > How could the kernel know all possible device drivers, even third > > party ones? > > That's the point about how Solaris does this (or did- originally). > > I have a card identifying itself as "Fred". At boot (or boot/reconfigure) > time, you tentatively load all drivers and enter their identify entry point > with a dev_info_t asking, "do you drive this device?". Simple enough. The hard > part is to try (if you think it's important) to arbitrate between several > different drivers who want to drive that device. Our plans already cover this (more or less) - we put metadata in the driver object so you don't actually have to load it to decide whether it's a contender, and we have an arbitration scheme in place already. The issue is - why print a message when you can just load the damn driver already? -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 10:12:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id D175137BFB8; Tue, 13 Jun 2000 10:12:15 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA03809; Tue, 13 Jun 2000 10:12:14 -0700 Date: Tue, 13 Jun 2000 10:12:09 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Mike Smith Cc: arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h In-Reply-To: <200006131713.KAA22419@mass.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Our plans already cover this (more or less) - we put metadata in the > driver object so you don't actually have to load it to decide whether > it's a contender, and we have an arbitration scheme in place already. I'm not sure that metadata is the right thing to do since you can't always statically assign dependencies. But, to be fair, dynamic dependency mechanisms in recent systems haven't been w/o their problems as well. > > The issue is - why print a message when you can just load the damn driver > already? > To take the other side of the argument 'as a transitional feature'? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 10:30:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.cdrom.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id A365F37B649 for ; Tue, 13 Jun 2000 10:30:29 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA22492; Tue, 13 Jun 2000 10:34:28 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200006131734.KAA22492@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h In-reply-to: Your message of "Tue, 13 Jun 2000 16:35:43 -0000." <200006131635.JAA08394@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jun 2000 10:34:28 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The PCI issue is unique, in that PCI devices can be identified by > a generic routine. This is nonsense, and it basically removes the justification for everything else that you've said here. 8) The real situation is, in fact, just the opposite; there are *very* few devices for which it is not possible to obtain, in a generic fashion, a uniquifying token. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 10:34:55 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 63BF137B649; Tue, 13 Jun 2000 10:34:53 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA03956; Tue, 13 Jun 2000 10:34:49 -0700 Date: Tue, 13 Jun 2000 10:34:45 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Mike Smith Cc: arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h In-Reply-To: <200006131734.KAA22492@mass.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The real situation is, in fact, just the opposite; there are *very* few > devices for which it is not possible to obtain, in a generic fashion, a > uniquifying token. > So much so that the real issue now is "which one of 4 different drivers do want for driving your tulip chip based NIC?" -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 10:37:12 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 484CB37B72A; Tue, 13 Jun 2000 10:37:08 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id TAA11714; Tue, 13 Jun 2000 19:37:01 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Mike Smith Cc: Terry Lambert , arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h In-reply-to: Your message of "Tue, 13 Jun 2000 10:34:28 PDT." <200006131734.KAA22492@mass.cdrom.com> Date: Tue, 13 Jun 2000 19:37:01 +0200 Message-ID: <11712.960917821@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200006131734.KAA22492@mass.cdrom.com>, Mike Smith writes: >> The PCI issue is unique, in that PCI devices can be identified by >> a generic routine. And case in point: Just because you have identified a PCI chip doesn't mean that you know what's next to it on the board. The AMCC "PCI Matchmaker" is a very good example. (If you know what this chip is, search ebay for "pci matchmaker" :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | 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 Tue Jun 13 10:37:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.cdrom.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id 8EC8A37B72A for ; Tue, 13 Jun 2000 10:37:15 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA22559; Tue, 13 Jun 2000 10:41:15 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200006131741.KAA22559@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: mjacob@feral.com Cc: arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h In-reply-to: Your message of "Tue, 13 Jun 2000 10:34:45 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jun 2000 10:41:15 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > The real situation is, in fact, just the opposite; there are *very* few > > devices for which it is not possible to obtain, in a generic fashion, a > > uniquifying token. > > So much so that the real issue now is "which one of 4 different drivers do > want for driving your tulip chip based NIC?" The one that's maintained by someone that I can chase around the office with the Damn Thing until he fixes it, of course. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 10:55:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.cdrom.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id 11BC937C00D; Tue, 13 Jun 2000 10:55:17 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA22609; Tue, 13 Jun 2000 10:57:11 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200006131757.KAA22609@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Poul-Henning Kamp Cc: Mike Smith , Terry Lambert , arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h In-reply-to: Your message of "Tue, 13 Jun 2000 19:37:01 +0200." <11712.960917821@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jun 2000 10:57:10 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <200006131734.KAA22492@mass.cdrom.com>, Mike Smith writes: > > >> The PCI issue is unique, in that PCI devices can be identified by > >> a generic routine. > > And case in point: Just because you have identified a PCI chip > doesn't mean that you know what's next to it on the board. > > The AMCC "PCI Matchmaker" is a very good example. > > (If you know what this chip is, search ebay for "pci matchmaker" :-) I've designed hardware using this device (and similar from PLX). In each case, you stuff your new PCI IDs into the EEPROM. More importantly, to comply with PCI 2.1, which is required for the Windows Logo Program, you *have* to have a unique ID. IOW, there is a niche for detecting "bad" hardware, but assuming that it's the default case isn't really a good idea. And in the worst case, you have a small handful of drivers registered and loaded for the 'generic' ID, and each of their probe routines gets a shot at the device. So what? The end result is a loaded and functional driver. As I've said, and keep saying, these are all issues that we've _already_ trampled flat into the mud. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 11:12:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id EA0A837BF73; Tue, 13 Jun 2000 11:12:14 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id UAA11850; Tue, 13 Jun 2000 20:12:10 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Mike Smith Cc: mjacob@feral.com, arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h In-reply-to: Your message of "Tue, 13 Jun 2000 10:41:15 PDT." <200006131741.KAA22559@mass.cdrom.com> Date: Tue, 13 Jun 2000 20:12:10 +0200 Message-ID: <11848.960919930@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200006131741.KAA22559@mass.cdrom.com>, Mike Smith writes: >> >> > The real situation is, in fact, just the opposite; there are *very* few >> > devices for which it is not possible to obtain, in a generic fashion, a >> > uniquifying token. >> >> So much so that the real issue now is "which one of 4 different drivers do >> want for driving your tulip chip based NIC?" > >The one that's maintained by someone that I can chase around the office >with the Damn Thing until he fixes it, of course. 8) Look at sys/dev/lmc and tell me if you want that to drive *your* tulip based card :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | 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 Tue Jun 13 11:14:13 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id AF39937BFA5; Tue, 13 Jun 2000 11:14:02 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id UAA11882; Tue, 13 Jun 2000 20:13:58 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Mike Smith Cc: Terry Lambert , arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h In-reply-to: Your message of "Tue, 13 Jun 2000 10:57:10 PDT." <200006131757.KAA22609@mass.cdrom.com> Date: Tue, 13 Jun 2000 20:13:58 +0200 Message-ID: <11880.960920038@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200006131757.KAA22609@mass.cdrom.com>, Mike Smith writes: >> The AMCC "PCI Matchmaker" is a very good example. >> >> (If you know what this chip is, search ebay for "pci matchmaker" :-) > >I've designed hardware using this device (and similar from PLX). > >In each case, you stuff your new PCI IDs into the EEPROM. > >More importantly, to comply with PCI 2.1, which is required for the >Windows Logo Program, you *have* to have a unique ID. Right, but so far the batting average I've seen is that 1 in 3 uses of the matchmaker doesn't do that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | 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 Tue Jun 13 11:24:20 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.cdrom.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id CB45337C054; Tue, 13 Jun 2000 11:24:14 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id LAA22754; Tue, 13 Jun 2000 11:25:40 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200006131825.LAA22754@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Poul-Henning Kamp Cc: Mike Smith , mjacob@feral.com, arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h In-reply-to: Your message of "Tue, 13 Jun 2000 20:12:10 +0200." <11848.960919930@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jun 2000 11:25:40 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <200006131741.KAA22559@mass.cdrom.com>, Mike Smith writes: > >> > >> > The real situation is, in fact, just the opposite; there are *very* few > >> > devices for which it is not possible to obtain, in a generic fashion, a > >> > uniquifying token. > >> > >> So much so that the real issue now is "which one of 4 different drivers do > >> want for driving your tulip chip based NIC?" > > > >The one that's maintained by someone that I can chase around the office > >with the Damn Thing until he fixes it, of course. 8) > > Look at sys/dev/lmc and tell me if you want that to drive *your* tulip > based card :-) Well, if you bothered to use the right constant (PCIR_SUBVEND_0) you'd realise that you're still using part of the _STANDARD_ PCI technique for uniquely identifying a card. So no, your driver isn't going to match any of my Tulip cards. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 11:42:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 315D437BFA5 for ; Tue, 13 Jun 2000 11:42:45 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA07731; Tue, 13 Jun 2000 12:42:43 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA16197; Tue, 13 Jun 2000 12:41:36 -0600 (MDT) Message-Id: <200006131841.MAA16197@harmony.village.org> To: Terry Lambert Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h Cc: mjacob@feral.com, arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 13 Jun 2000 16:42:15 -0000." <200006131642.JAA08631@usr05.primenet.com> References: <200006131642.JAA08631@usr05.primenet.com> Date: Tue, 13 Jun 2000 12:41:36 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200006131642.JAA08631@usr05.primenet.com> Terry Lambert writes: : This is not the case for SBUS or PCI hardware, which can be data : driven using a table. I think that the active probe case still : needs to be dealt with. The trouble is generating this table. Right now none of the busses have any concept of a table driven approach to plug and play. That has all been moved down into the drivers' probe routines. And some of our probe routines will attach to generic things rather than to things with a certain ID (eg, the serial driver for pci should attach to all communication devices that are serial 16550 compatible). In pccard land, we ant all modems to attach to sio and all fixed disk to attach to ata. In the pccard world things also get complicated by the fact that there are multi-function cards that need some special help as well. These wrinkles make having a single table format for all busses difficult, and may make having some bus tables fairly complex. :-(. : Windows 95/98/2000/NT handle this by paging in the probe code, : running it, and if it probes true, paging in the driver and doing : the attach. The probe code is then discarded. : : Each severable section is in a seperate ELF section, on a 4k page : boundary (logical, not physical, in the ELF file). I like this idea. Too bad we don't have pagable kernel driver support (hint hint). The next best thign would be to load the driver, call its probe routines and then unload it if it didn't attach to anything. You'd want to do this in a lazy way. Load the driver while probing the bus if all drivers currently loaded reject the device as well as deferring unload until all devices on the bus have been probed so that you don't thrash on startup. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 13 11:43:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id CBC6437BC4D for ; Tue, 13 Jun 2000 11:43:53 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA07752; Tue, 13 Jun 2000 12:43:52 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA16232; Tue, 13 Jun 2000 12:42:46 -0600 (MDT) Message-Id: <200006131842.MAA16232@harmony.village.org> To: Terry Lambert Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 13 Jun 2000 16:37:49 -0000." <200006131637.JAA08514@usr05.primenet.com> References: <200006131637.JAA08514@usr05.primenet.com> Date: Tue, 13 Jun 2000 12:42:46 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200006131637.JAA08514@usr05.primenet.com> Terry Lambert writes: : > In message <8947.960886026@critter.freebsd.dk> Poul-Henning Kamp writes: : > : "Found Configure \"blaha\" driver in your kernel" : > : : > : I can see all the bloat arguments, but I have to say that the idea : > : has some merit... : > : > How could the kernel know all possible device drivers, even third : > party ones? : : 1) Register them in a file : : 2) Read the file using kernel level file I/O : : 3) For simplicity sake, make each line in the file a fixed : length; though some additional variable length text : record stuff in the kernel would be useful eventually, : the "edquota" approach is reasonable. I thought we were trying to get away from having all this information in a centralized repository... The drivers already know this and adding an additional file for this info seems to be asking for problems. I know on Solaris it was from time to time... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 14 1:35:17 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.sunesi.net (ns1.sunesi.net [196.15.192.194]) by hub.freebsd.org (Postfix) with ESMTP id E42D437C11B; Wed, 14 Jun 2000 01:34:58 -0700 (PDT) (envelope-from nbm@sunesi.net) Received: from nbm by ns1.sunesi.net with local (Exim 3.03 #1) id 1328aM-0002xv-00; Wed, 14 Jun 2000 10:31:42 +0200 Date: Wed, 14 Jun 2000 10:31:42 +0200 From: Neil Blakey-Milner To: Terry Lambert Cc: Poul-Henning Kamp , Doug Rabson , Warner Losh , Doug Rabson , arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h Message-ID: <20000614103142.A10882@mithrandr.moria.org> References: <8947.960886026@critter.freebsd.dk> <200006131628.JAA08308@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200006131628.JAA08308@usr05.primenet.com>; from tlambert@primenet.com on Tue, Jun 13, 2000 at 04:28:58PM +0000 Organization: Sunesi Clinical Systems X-Operating-System: FreeBSD 3.3-RELEASE i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue 2000-06-13 (16:28), Terry Lambert wrote: > > "Found Configure \"blaha\" driver in your kernel" > So would just loading the frigging driver from the modules directory, > instead of beating the user over the head to do it for you. That would be nice, of course. So long as there's a way from stopping the kernel from loading a module you know is broken, and that will repeatedly crash your system over and over again. Fallback may be: "Uses module \"blaha\", autoloading disabled" with "for this device" or "for this driver" or "globally". Again, it may be better, or also, handled by a userland utility (with extension to a libh interface). Actually, there should probably be a deviceID- and/or driver-specific way of disabling autoloading or loading of the driver for that device, or that driver at all. I positively disliked it when one of my (PCI) network cards froze my personal (multi-booting) machine on detection and then further probe a long long time ago. Draft proposed loader changes: 'autoloadmodules' can be passed to the kernel by loader, could probably default to 'off' in /boot/defaults/loader.conf, and would be set 'on' for the install case (which would generate the necessary /boot/loader.conf magic in sysinstall and/or another utility to save the current module usage there to work on that hardware next time around), and could be turned 'on' or 'off' explicitly in /boot/loader.conf (possibly by a libh application) or during interactive loader usage. 'autoload_disabled_quiet' could be set possibly by default to 'no', and if set to 'no' would mean that you get the "Uses module \"blaha\"" message (how and whether we detect what modules it belongs to is another story). If we export this information via sysctl, we don't need to reboot with changed loader variables, and can comfortably view them from a userland console utility or libh application. Or, we could reuse "*_load" and company in loader.conf, with existing alternatives 'on', 'off', and a new 'autoload' option. 'autoload' is to auto load if found and 'autoloadmodules' is enabled. 'on' always loads, even if detection fails, and 'off' never loads, as before. All "*_load" options in defaults/loader.conf can default to 'autoload', so that the enabling of 'autoloadmodules' is initially global. (of course, this might not be feasible in BootForth, and then we'd have to add usb_auto_load="YES"/"NO", defaulting to "YES".) Neil -- Neil Blakey-Milner Sunesi Clinical Systems nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 15 9: 2:51 2000 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id D56CC37B8EA for ; Thu, 15 Jun 2000 09:02:48 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@trang.nuxi.com [209.152.133.57]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id JAA52056 for ; Thu, 15 Jun 2000 09:02:46 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id JAA32728 for freebsd-arch@freebsd.org; Thu, 15 Jun 2000 09:02:43 -0700 (PDT) (envelope-from obrien) Date: Thu, 15 Jun 2000 09:02:42 -0700 From: "David O'Brien" To: freebsd-arch@freebsd.org Subject: problem building modules for release. Message-ID: <20000615090242.A32679@dragon.nuxi.com> Reply-To: obrien@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As some may know, modules are not winding up in the `bin' distribution in release builds right now. The problem is one may decided they don't want to build modules when they build their kernel, but they cannot decide to do the traditional way of building modules with the world. I am putting back that ability. Now that we've had a taste of both ways, I have two questions of people: 1. Should the symbol be MODULES_WITH_KERNEL or MODULES_WITH_WORLD, (or something else)? 2. Which should be the default? Building modules with world or kernel. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 15 9:31:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id EBD7037BA74; Thu, 15 Jun 2000 09:31:40 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5FGVeU28594; Thu, 15 Jun 2000 09:31:40 -0700 (PDT) Date: Thu, 15 Jun 2000 09:31:40 -0700 From: Alfred Perlstein To: "David O'Brien" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: problem building modules for release. Message-ID: <20000615093140.L18462@fw.wintelcom.net> References: <20000615090242.A32679@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000615090242.A32679@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Thu, Jun 15, 2000 at 09:02:42AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * David O'Brien [000615 09:03] wrote: > As some may know, modules are not winding up in the `bin' distribution in > release builds right now. The problem is one may decided they don't want > to build modules when they build their kernel, but they cannot decide to > do the traditional way of building modules with the world. > I am putting back that ability. > > Now that we've had a taste of both ways, I have two questions of people: > > 1. Should the symbol be MODULES_WITH_KERNEL or MODULES_WITH_WORLD, (or > something else)? > > 2. Which should be the default? Building modules with world or kernel. I haven't see an "oops my modules and kernel are out of sync" mail since the change. The extra time it takes to build is a bit annoying but very worth the protection it allows. I'd stick with building the modules along with the kernel. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 15 9:37: 1 2000 Delivered-To: freebsd-arch@freebsd.org Received: from spirit.jaded.net (shortbus.jaded.net [216.94.132.8]) by hub.freebsd.org (Postfix) with ESMTP id B9AD837BC42; Thu, 15 Jun 2000 09:36:58 -0700 (PDT) (envelope-from dan@spirit.jaded.net) Received: (from dan@localhost) by spirit.jaded.net (8.9.3/8.9.3) id MAA01714; Thu, 15 Jun 2000 12:36:54 -0400 (EDT) (envelope-from dan) Date: Thu, 15 Jun 2000 12:36:54 -0400 From: Dan Moschuk To: Alfred Perlstein Cc: "David O'Brien" , freebsd-arch@FreeBSD.ORG Subject: Re: problem building modules for release. Message-ID: <20000615123654.J1043@spirit.jaded.net> References: <20000615090242.A32679@dragon.nuxi.com> <20000615093140.L18462@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000615093140.L18462@fw.wintelcom.net>; from bright@wintelcom.net on Thu, Jun 15, 2000 at 09:31:40AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | > Now that we've had a taste of both ways, I have two questions of people: | > | > 1. Should the symbol be MODULES_WITH_KERNEL or MODULES_WITH_WORLD, (or | > something else)? | > | > 2. Which should be the default? Building modules with world or kernel. | | I haven't see an "oops my modules and kernel are out of sync" mail since | the change. The extra time it takes to build is a bit annoying but very | worth the protection it allows. | | I'd stick with building the modules along with the kernel. I would definately keep it in the kernel build rather than the world build. Yes, it takes a few more minutes building a kernel, but there is always make -DNO_MODULES. -- Dan Moschuk (TFreak!dan@freebsd.org) "Meep meep!" - Roadrunner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 15 10:44:44 2000 Delivered-To: freebsd-arch@freebsd.org Received: from d135.p6.col.ru (d135.p6.col.ru [212.248.5.135]) by hub.freebsd.org (Postfix) with SMTP id 814B937C382; Thu, 15 Jun 2000 10:44:24 -0700 (PDT) (envelope-from prettylady@freemail.ru) From: To: Date: ×ò, 15 èþí 2000 20:43:24 +0400 Message-ID: <30166255006633880@d135.p6.col.ru> Subject: Hi, its for you ! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! We are Russian girls - Natali, Alla, Vika. We would like to correspond with you. Visit our site and see our photos. http://www.russiangirls.narod.ru/ With interest, Natali,Alla, Vika. P.S. (This is not spam. You can unsubscribe at any time by sending an email to prettylady@freemail.ru with the subject UNSUBSCRIBE.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 15 12:20:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from clk.cirx.org (206.c137.ethome.net.tw [202.178.137.206]) by hub.freebsd.org (Postfix) with ESMTP id F3BAF37BD29 for ; Thu, 15 Jun 2000 12:20:46 -0700 (PDT) (envelope-from clkao@CirX.ORG) Received: (from clkao@localhost) by clk.cirx.org (8.11.0.Beta1/8.11.0.Beta1/Debian 8.11.0-1) id e5FJJuX02775; Fri, 16 Jun 2000 03:19:56 +0800 Date: Fri, 16 Jun 2000 03:19:56 +0800 From: Chia-liang Kao To: Jason Evans Cc: freebsd-arch@freebsd.org Subject: kernel thread support Message-ID: <20000616031956.A2551@genius.cirx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Alright, people brought up discussion about kernel thread once or more every year since '97 but not this year, so I'd like to bring it up again. I spent some time do some kernel hacking and go through the discussion last winter and the SA paper these days. (I didn't find the discussion till recent because in I thought -arch had been quiet for years) And, half year had it been silent after the active discussion. o Is the model for the scenario described in http://www.freebsd.org/~julian/threads/ the final design decision? (then I think it shall be well documented.) o shouldn't KSE to be renamed to something else? It is somewhat confusing, I thought KSEs meant the sub-processes(Q) at a glance. (I think the terms should be frozen ASAP to ease understanding for new developers on this) o What's the current status of implementation (or implementation design)? I suppose the works to be done are: 1) libc threadsafication 2) kernel runqueue runs subproc (orig proc becomes subproc and the grouping concept goes to the new proc) 3) (so called) kse sleep queue(and some modification in syscall stuff?) 4) userland lib support o any timeline on this? I would really like to see the development to be active(perhaps in a branch?) ps. Some time-saving references for late comers to catch up: o Terry's summary about thread programming, and when we really need threads: <199911041804.LAA18253@usr06.primenet.com> o The design goal: o is there anything good to summarize the model we'll be using? o links: http://www.freebsd.org/~julian/threads/ Please let me know if anything above is wrong, I just swallowed -arch these days. Cheers, CLK On Wed, May 31, 2000 at 08:20:26PM -0700, Jason Evans wrote: > There was a lengthy discussion last winter on -arch about improving FreeBSD's > threads support, and the result of the discussion is that we're pursuing > scheduler activations (SAs) rather than LWPs. I'm currently working out > the design on paper, and hope to be coding it soon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 15 15: 2: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 7F59D37B579; Thu, 15 Jun 2000 15:02:02 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id PAA04407; Thu, 15 Jun 2000 15:01:54 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpdAAAtMaWBh; Thu Jun 15 15:00:50 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id PAA12388; Thu, 15 Jun 2000 15:00:43 -0700 (MST) From: Terry Lambert Message-Id: <200006152200.PAA12388@usr08.primenet.com> Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h To: msmith@FreeBSD.ORG (Mike Smith) Date: Thu, 15 Jun 2000 22:00:42 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), arch@FreeBSD.ORG In-Reply-To: <200006131734.KAA22492@mass.cdrom.com> from "Mike Smith" at Jun 13, 2000 10:34:28 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The PCI issue is unique, in that PCI devices can be identified by > > a generic routine. > > This is nonsense, and it basically removes the justification for > everything else that you've said here. 8) > > The real situation is, in fact, just the opposite; there are *very* few > devices for which it is not possible to obtain, in a generic fashion, a > uniquifying token. PCI cards have a card identification register which is per slot relative, and which can be read by a generic routine. EISA and MCA have similar capabilities. ISA cards, you have to go grovelling in a per card way with a passive probe for most cards; but the routine used to do this is _not_ the same for all IS cards, and can not, therefore, be written once per bus, but instead must be written once per card. Some ISA devices require active probing, and can not be identified passively under any circumstances (AMD LANCE ethernet is one such device). I think it's OK to statically compile in a generic PCI probe that then does I/O against a file to identify the driver to load (the ID as the left hand side, the driver module information as the right hand side, in a data table). I _don't_ think it's OK to statically link in all ISA devices, or even to load the full driver for each device before deciding to discard it because the probe failed to find a device. I think instead that the driver module should be divided into a probe section, an attach section, and a driver section; the lattermost can be loaded and discarded with much less potential for kernel memory fragmentation. The latter two can be discarded onces the driver is active. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 15 15: 7:29 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 6C42637B7C1; Thu, 15 Jun 2000 15:07:24 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id PAA19056; Thu, 15 Jun 2000 15:06:51 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpdAAAaja4eL; Thu Jun 15 15:06:37 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id PAA12480; Thu, 15 Jun 2000 15:06:58 -0700 (MST) From: Terry Lambert Message-Id: <200006152206.PAA12480@usr08.primenet.com> Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h To: nbm@mithrandr.moria.org (Neil Blakey-Milner) Date: Thu, 15 Jun 2000 22:06:42 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), phk@critter.freebsd.dk (Poul-Henning Kamp), dfr@nlsystems.com (Doug Rabson), imp@village.org (Warner Losh), dfr@FreeBSD.ORG (Doug Rabson), arch@FreeBSD.ORG In-Reply-To: <20000614103142.A10882@mithrandr.moria.org> from "Neil Blakey-Milner" at Jun 14, 2000 10:31:42 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Tue 2000-06-13 (16:28), Terry Lambert wrote: > > > "Found Configure \"blaha\" driver in your kernel" > > > So would just loading the frigging driver from the modules directory, > > instead of beating the user over the head to do it for you. > > That would be nice, of course. So long as there's a way from stopping > the kernel from loading a module you know is broken, and that will > repeatedly crash your system over and over again. rm /modules/broken.ko > Fallback may be: "Uses module \"blaha\", autoloading disabled" with "for > this device" or "for this driver" or "globally". Again, it may be > better, or also, handled by a userland utility (with extension to a libh > interface). That will not work for boot devices. The current loader scheme will work for boot devices. Ideally, for PC hardware, you would use BIOS I/O until you identified the hardware, and then replaced the drive. Windows has done this since Windows 95. [ ... Draft proposal ... ] Looks good, with the caveats, above. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 15 15:42:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (mg137-048.ricochet.net [204.179.137.48]) by hub.freebsd.org (Postfix) with ESMTP id 0A8F537BD16; Thu, 15 Jun 2000 15:42:41 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id PAA00823; Thu, 15 Jun 2000 15:46:53 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200006152246.PAA00823@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Terry Lambert Cc: msmith@FreeBSD.ORG (Mike Smith), arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h In-reply-to: Your message of "Thu, 15 Jun 2000 22:00:42 -0000." <200006152200.PAA12388@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Jun 2000 15:46:52 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > The PCI issue is unique, in that PCI devices can be identified by > > > a generic routine. > > > > This is nonsense, and it basically removes the justification for > > everything else that you've said here. 8) > > > > The real situation is, in fact, just the opposite; there are *very* few > > devices for which it is not possible to obtain, in a generic fashion, a > > uniquifying token. > > PCI cards have a card identification register which is per slot > relative, and which can be read by a generic routine. EISA and > MCA have similar capabilities. > > ISA cards, you have to go grovelling in a per card way with a > passive probe for most cards; but the routine used to do this is > _not_ the same for all IS cards, and can not, therefore, be > written once per bus, but instead must be written once per card. Not "most cards". These days, "for old cards only". > I think it's OK to statically compile in a generic PCI probe that > then does I/O against a file to identify the driver to load (the > ID as the left hand side, the driver module information as the > right hand side, in a data table). > > I _don't_ think it's OK to statically link in all ISA devices, or > even to load the full driver for each device before deciding to > discard it because the probe failed to find a device. I think there are so few ISA devices left that we care about that it's fine to load their drivers if and when you give a damn about them, and then unload them if you decide they failed to load. It's so rare an event to probe an ISA device that I don't think the difference between paging in the probe vs. just loading the entire driver is so trivial that it's not worth arguing about. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 16 13: 8:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 3090437B562; Fri, 16 Jun 2000 13:08:28 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id NAA28939; Fri, 16 Jun 2000 13:07:50 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpdAAA11aqE4; Fri Jun 16 13:07:41 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id NAA12354; Fri, 16 Jun 2000 13:08:14 -0700 (MST) From: Terry Lambert Message-Id: <200006162008.NAA12354@usr08.primenet.com> Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h To: msmith@FreeBSD.ORG (Mike Smith) Date: Fri, 16 Jun 2000 20:08:14 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), msmith@FreeBSD.ORG (Mike Smith), arch@FreeBSD.ORG In-Reply-To: <200006152246.PAA00823@mass.osd.bsdi.com> from "Mike Smith" at Jun 15, 2000 03:46:52 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I _don't_ think it's OK to statically link in all ISA devices, or > > even to load the full driver for each device before deciding to > > discard it because the probe failed to find a device. > > I think there are so few ISA devices left that we care about that it's > fine to load their drivers if and when you give a damn about them, and > then unload them if you decide they failed to load. It's so rare an > event to probe an ISA device that I don't think the difference between > paging in the probe vs. just loading the entire driver is so trivial that > it's not worth arguing about. You don't know you don't need them until after you load them, and their probe fails. By then, you've already potentially fragmented kernel memory in the process. Unless you are prepared to introduce pageable segments for kernel code, this means that the only way to avoid the fragmentation is to either require that zero allocations take place, or load the drivers and the probe routines seperately. If you _are_ going to introduce pageable segments, I withdraw the objection, since it would be just a small change to move pageable segments around to defrag the VM space. Incidently, this would also allow you to make large post-boot contiguous allocations for things like video capture cards, etc., instead of having them reserve contiguous segments of kernel memory up front, when the card is potentially never used during a boot session Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 16 16: 6:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id 1279737BA4B for ; Fri, 16 Jun 2000 16:06:20 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.9.3/8.9.3) with ESMTP id AAA08983 for ; Sat, 17 Jun 2000 00:03:42 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id AAA43164 for ; Sat, 17 Jun 2000 00:03:40 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200006162303.AAA43164@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: freebsd-arch@FreeBSD.org Subject: configuring periodic services Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 Jun 2000 00:03:39 +0100 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I would like to implement an /etc/periodic.conf, /etc/defaults/periodic.conf scheme that will contain variables to control periodic jobs, in the same way that $clear_daily_* have just started doing in rc.conf. Initially I'll introduce a /etc/defaults/periodic.conf file with a bunch of stuff including replacements for $clear_daily_* and a /etc/periodic.conf (installed by sysinstall, not src/etc/Makefile) that contains a few comments and nothing else. The default file will contain tunables to make periodic jobs behave as they currently do and a man page will describe what's changable. I don't see any disagreement here (hah!), but think that there may be preferences for daily.conf/weekly.conf/monthly.conf instead. Personally I don't think that's necessary - not if the variables in periodic.conf all contain daily/weekly/monthly substrings. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 16 16:20:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rz.fh-wilhelmshaven.de (mail.rz.fh-wilhelmshaven.de [139.13.25.134]) by hub.freebsd.org (Postfix) with ESMTP id ADEEC37B5B2 for ; Fri, 16 Jun 2000 16:20:03 -0700 (PDT) (envelope-from ohoyer@fbwi.fh-wilhelmshaven.de) Received: from fettesau.stuwo.fh-wilhelmshaven.de (stuwopc5.stuwo.fh-wilhelmshaven.de [139.13.209.5]) by mail.rz.fh-wilhelmshaven.de (8.9.3/8.9.3) with SMTP id BAA11957; Sat, 17 Jun 2000 01:19:54 +0200 (MET DST) Message-Id: <4.1.20000617011658.00a5a9a0@mail.rz.fh-wilhelmshaven.de> X-Sender: ohoyer@mail.rz.fh-wilhelmshaven.de X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 17 Jun 2000 01:20:10 +0200 To: Brian Somers From: Olaf Hoyer Subject: Re: configuring periodic services Cc: freebsd-arch@FreeBSD.ORG In-Reply-To: <200006162303.AAA43164@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 00:03 17.06.00 +0100, Brian Somers wrote: >I would like to implement an /etc/periodic.conf, >/etc/defaults/periodic.conf scheme that will contain variables to >control periodic jobs, in the same way that $clear_daily_* have just >started doing in rc.conf. Hi! Please help a poor beginner to understand the differences of the job cron does, and above picture... Or do you intend to help to get rid of cron for certain scenarii, thus increasing security of the system? Regards Olaf Hoyer -------- Olaf Hoyer www.nightfire.de mailto:Olaf.Hoyer@nightfire.de FreeBSD- Turning PC's into workstations ICQ:22838075 Liebe und Hass sind nicht blind, aber geblendet vom Feuer, dass sie selber mit sich tragen. (Nietzsche) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 16 16:35:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 94C2137C14D for ; Fri, 16 Jun 2000 16:35:22 -0700 (PDT) (envelope-from jasone@magnesium.net) Received: (qmail 49784 invoked by uid 1142); 16 Jun 2000 23:35:20 -0000 Date: 16 Jun 2000 16:35:20 -0700 Date: Fri, 16 Jun 2000 14:42:59 -0700 From: Jason Evans To: Chia-liang Kao Cc: freebsd-arch@freebsd.org Subject: Re: kernel thread support Message-ID: <20000616144259.Q47268@blitz.canonware.com> References: <20000616031956.A2551@genius.cirx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000616031956.A2551@genius.cirx.org>; from clkao@CirX.ORG on Fri, Jun 16, 2000 at 03:19:56AM +0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jun 16, 2000 at 03:19:56AM +0800, Chia-liang Kao wrote: > o Is the model for the scenario described in > > http://www.freebsd.org/~julian/threads/ > > the final design decision? (then I think it shall be well documented.) We have made some refinements to the model, but in general, it is the same idea. Daniel Eischen and I are working on a paper that gives a reasonable overview of the current design. Hopefully we can get it to a postable form in the near future. However, we're probably going to concern ourselves primarily with actually doing the work, rather than telling everybody beforehand exactly how we're doing it. > o shouldn't KSE to be renamed to something else? It is somewhat confusing, > I thought KSEs meant the sub-processes(Q) at a glance. > (I think the terms should be frozen ASAP to ease understanding for > new developers on this) Pay no attention to the naming used in the -arch discussion. It will change. =) > o What's the current status of implementation (or implementation design)? The design is basically done. The scheduler activations implementation has a number of interdependencies with the SMP changes that are currently being worked on, so the kernel support for the new threads library is going to take a bit longer than I would like. Still, I think we'll have scheduler activations done for FreeBSD 5.0. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 16 16:43:10 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E01D237B9D4 for ; Fri, 16 Jun 2000 16:43:06 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id QAA06863; Fri, 16 Jun 2000 16:41:41 -0700 Date: Fri, 16 Jun 2000 16:41:34 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Jason Evans Cc: Chia-liang Kao , freebsd-arch@FreeBSD.ORG Subject: Re: kernel thread support In-Reply-To: <20000616144259.Q47268@blitz.canonware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16 Jun 2000, Jason Evans wrote: > On Fri, Jun 16, 2000 at 03:19:56AM +0800, Chia-liang Kao wrote: > > o Is the model for the scenario described in > > > > http://www.freebsd.org/~julian/threads/ > > > > the final design decision? (then I think it shall be well documented.) > > We have made some refinements to the model, but in general, it is the same > idea. Daniel Eischen and I are working on a paper that gives a reasonable > overview of the current design. Hopefully we can get it to a postable form > in the near future. However, we're probably going to concern ourselves > primarily with actually doing the work, rather than telling everybody > beforehand exactly how we're doing it. Can please spend some effort into saying what the intents and architecture is in the paper? The current newbus stuff and CAM stuff horribly suffer from the fact that there aren't such documents. I'm currently tearing my hair out trying to intuit what should have been written down. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 16 16:56:20 2000 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id B60ED37B81B for ; Fri, 16 Jun 2000 16:56:15 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.9.3/8.9.3) with ESMTP id AAA09335; Sat, 17 Jun 2000 00:51:05 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id AAA48925; Sat, 17 Jun 2000 00:51:02 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200006162351.AAA48925@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Olaf Hoyer Cc: Brian Somers , freebsd-arch@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: configuring periodic services In-Reply-To: Message from Olaf Hoyer of "Sat, 17 Jun 2000 01:20:10 +0200." <4.1.20000617011658.00a5a9a0@mail.rz.fh-wilhelmshaven.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 Jun 2000 00:51:00 +0100 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This stuff began as just a bunch of things to do daily. It was split up into the various /etc/periodic scripts and directories some time ago so that it could be managed more easily. Cron runs /usr/sbin/periodic. I have no intentions to change the way /usr/sbin/periodic is invoked. > At 00:03 17.06.00 +0100, Brian Somers wrote: > >I would like to implement an /etc/periodic.conf, > >/etc/defaults/periodic.conf scheme that will contain variables to > >control periodic jobs, in the same way that $clear_daily_* have just > >started doing in rc.conf. > Hi! > > Please help a poor beginner to understand the differences of the job cron > does, and above picture... > > Or do you intend to help to get rid of cron for certain scenarii, thus > increasing security of the system? > > Regards > Olaf Hoyer > -------- > Olaf Hoyer www.nightfire.de mailto:Olaf.Hoyer@nightfire.de > FreeBSD- Turning PC's into workstations ICQ:22838075 > > Liebe und Hass sind nicht blind, aber geblendet vom Feuer, > dass sie selber mit sich tragen. (Nietzsche) -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 16 20:26:13 2000 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 4691537B87F; Fri, 16 Jun 2000 20:25:46 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id VAA57866; Fri, 16 Jun 2000 21:25:45 -0600 (MDT) (envelope-from ken) Date: Fri, 16 Jun 2000 21:25:45 -0600 From: "Kenneth D. Merry" To: net@FreeBSD.ORG Subject: zero copy sockets and NFS code for FreeBSD Message-ID: <20000616212545.A57840@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ This message is BCC'ed to -arch and -current, so it reaches a little wider audience, but since it mostly deals with networking stuff, it should probably be discussed on -net. ] Thanks to the efforts of a number of people, zero copy sockets and NFS patches are available for FreeBSD-current at the URL listed below. These patches include: - Two sets of zero copy send code, written by Drew Gallatin and Robert Picco . - Zero copy receive code, written by Drew Gallatin. - Zero copy NFS code, written by Drew Gallatin. - Header splitting firmware for Alteon's Tigon II boards (written by me), based on version 12.4.11 of their firmware. This is used in combination with the zero copy receive code to guarantee that the payload of TCP or UDP packet is placed into a page-aligned buffer. - Alteon firmware debugging ioctls and supporting routines for the Tigon driver (also written by me). This will help anyone who is doing firmware development under FreeBSD for the Tigon boards. Please note that the code is still in development, and should not be used in a production system. It could crash your system, you could lose data, etc. The Alteon firmware header splitting and debugging code was written for Pluto Technologies (www.plutotech.com), which has kindly agreed to let me release the code. I'm releasing these patches now, so people can take a look at the code, test it out, give feedback and hopefully supply patches for things that are broken. The code is located here: http://people.FreeBSD.ORG/~ken/zero_copy/ The patches are based on -current from early in the day on June 13th, i.e. before Peter's config changes. Frequently Asked Questions: 1. Known Problems. 2. What is "zero copy"? 3. How does zero copy work? 4. What hardware does it work with? 5. Configuration and performance tuning. 6. Benchmarks. 7. Possible future directions. 1. Known Problems: - Robert Picco's zero copy send code (options ZCOPY) corrupts data that it sends. You can verify this with the 'nttcp' port from ports/net, like this: nttcp -c -n 262144 -t -T -w 512k 10.0.0.2 (assuming 10.0.0.2 is the target machine) - Running high volumes of traffic to the local machine can trigger panics. If the machine in question is '10.0.0.2', doing the following is enough to panic it: netperf -H 10.0.0.2 (netperf is in ports/benchmarks) 2. What is "zero copy"? Zero copy is a misnomer, or an accurate description, depending on how you look at things. In the normal case, with network I/O, buffers are copied from the user process into the kernel on the send side, and from the kernel into the user process on the receiving side. That is the copy that is being eliminated in this case. The DMA or copy from the kernel into the NIC, or from the NIC into the kernel is not the copy that is being eliminated. In fact you can't eliminate that copy without taking packet processing out of the kernel altogether. (i.e. the kernel has to see the packet headers in order to determine what to do with the payload) Memory copies from userland into the kernel are one of the largest bottlenecks in network performance on a BSD system, so eliminating them can greatly increase network throughput, and decrease system load when CPU or memory bandwidth isn't the limiting factor. 3. How does zero copy work? The send side and receive side zero copy code work in different ways: The send side code takes pages that the userland program writes to a socket, and puts a COW (Copy On Write) mapping on each page, and stuffs it into a mbuf. The data the user program writes must be page sized and start on a page boundary in order for it to be run through the zero copy send code. If the userland program doesn't write to the page before it has been sent out on the wire and the mbuf freed (and therefore the COW mapping revoked), the page will be copied. For TCP, the mbuf isn't freed until the packet is acknowledged by the receiver. So send side zero copy is only better than the standard case, where userland buffers are copied into kernel buffers, if the userland program doesn't immediately reuse the buffer. Receive side zero copy works in a slightly different manner, and depends in part on the capabilities of the network card in question. One requirement for zero copy receive to work is that the chunks of data passed up the network and socket layers have to be at least page sized, and be aligned on page boundaries. This pretty much means that the card has to have a MTU of 4K or 8K in the case of the Alpha. Gigabit Ethernet cards using Jumbo Frames (9000 byte MTU) fall into this category. More on that below. Another requirement for zero copy receive to work is that the NIC driver needs to allocate receive side pages from a "disposeable" pool. This means allocating memory apart from the normal mbuf memory, and attaching it as an external buffer to the mbuf. It also helps if the NIC can receive packets into multiple buffers, and if the NIC can separate the ethernet, IP, and TCP or UDP headers from the payload. The idea is to get the packet payload into one or more page-sized, page-aligned buffers. The NIC driver receives data into these buffers allocated from a disposeable pool. The mbuf with these buffers attached is then passed up the network stack where the headers are removed. Finally it reaches the socket layer, and waits for the user to read it. Once the user reads the data, the kernel page is then substituted for the user's page, and the user's page is then recycled. This is otherwise known as "page flipping". The page flip can only occur if both the userland buffer and kernel buffer are page aligned, and if there is at least a page worth of data in the source and destination. Otherwise the data will be copied out using copyout() in the normal manner. 4. What hardware does it work with? The send side zero copy code should work with most any network adapter. The receive side code, however, requires an adapter with an MTU that is at least a page size, due to the alignment restrictions for page substitution (or "page flipping"). The zero-copy NFS receive-side code also requires an adapter with an MTU that is at least page-size & which is capable of splitting the NFS rpc header off of the payload. Furthermore, it only works with UDP mounts. The server's zero-copy read response code simply maps kernel memory into mbufs and has no special adapter or protocol requirements. The Alteon firmware debugging code requires an Alteon Tigon II board. If you want the patches to the userland tools and Tigon firmware to debug it and make it compile under FreeBSD, contact ken@FreeBSD.ORG. 5. Configuration and performance tuning. There are a number of options that need to be turned on for various things to work: options ZERO_COPY_SOCKETS # Turn on zero copy send code options ENABLE_VFS_IOOPT # Turn on zero copy receive options NMBCLUSTERS=(512+512*32) # lots of mbuf clusters options TI_JUMBO_HDRSPLIT # Turn on Tigon header splitting To turn on Robert Picco's zero copy send code, substitute: options ZCOPY # Robert Picco's zero copy code for the ZERO_COPY_SOCKETS option above. The number of mbuf clusters above works for me, your mileage may vary. It probably isn't necessary to allocate that many. To get the maximum performance out of the code, here are some suggestions on various sysctl and other parameters. These assume you've got an Alteon-based board, so if you're using something else, you may want to experiment and find the optimum values for some of them: - Make sure the MTU on your Tigon (or other) board is set to 9000. - Enable RFC 1323, which allows your TCP MSS to go above 64KB: sysctl -w net.inet.tcp.rfc1323=1 - Turn on vfs.ioopt to enable zero copy receive: sysctl -w vfs.ioopt=1 - Increase your socket buffer size and send and receive window size for TCP: sysctl -w kern.ipc.maxsockbuf=2097152 sysctl -w net.inet.tcp.sendspace=524288 sysctl -w net.inet.tcp.recvspace=524288 A send window of 512K seems to work well with 1MB Tigon boards, and a send window of 256K seems to work well with 512K Tigon boards. Again, you may want to experiment to find the best settings for your hardware. - Increase UDP send space and maximum datagram size: sysctl -w net.inet.udp.recvspace=65535 sysctl -w net.inet.udp.maxdgram=57344 6. Benchmarks One nice benchmark is netperf (www.netperf.org), which is in the benchmarks subdirectory of the ports tree. Netperf isn't exactly a real world benchmark, since it sends page aligned data that is a multiple of the page size. It is good for trying to determine maximum throughput. Another benchmark to try is nttcp, which is in ports/net. Here is are some netperf numbers for TCP and UDP throughput between two Pentium II 350's with 128MB RAM and 1MB Alteon ACEnics: # ./netperf -H 10.0.0.1 TCP STREAM TEST to 10.0.0.1 : histogram Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 524288 524288 524288 10.01 742.46 # ./netperf -t UDP_STREAM -H 10.0.0.1 -- -m 8192 UDP UNIDIRECTIONAL SEND TEST to 10.0.0.1 : histogram Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 57344 8192 10.01 140396 585086 919.34 65535 10.01 93525 612.42 As you can see, the TCP performance is 742Mbits/sec, or about 93MBytes/sec. Drew Gallatin has achieved much higher performance with faster hardware: This is between 2 Dell PowerEdge 4400 servers using prototype 64-bit, 66MHz PCI Myricom Lanai-9 NICs with a 2.56Gb/sec link speed. The MTU was 32828 bytes. They're both uniprocessor 733MHz Xeons running a heavily patched 4.0-RELEASE & my zero-copy code in conjunction with Duke's Trapeze software (drive & firmware) for Myrinet adapters. The receiver is offloading checksums and is 60% idle, the sender is calculating checksums and is pegged at 100% CPU. <9:12am>wrath/gallatin:~>netperf -Hsloth-my TCP STREAM TEST to sloth-my : histogram Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 524288 524288 524288 10.00 1764.50 7. Possible future directions. Send side zero copy: One of the obvious problems with the current send side approach is that it only works if the userland application doesn't immediately reuse the buffer. In the case of many system applications, though, the application will reuse the buffer immediately, and therefore performance will be no better than the standard case. Many common applications (like ftp) have been written with the current system buffer usage in mind, so they function like this: while !done { read x bytes from disk into buffer y write x bytes from buffer y into the socket } That makes sense if the kernel is only going to copy the data, but it doesn't in the zero copy case. Another problem with the current send side approach is that it requires page sized and page aligned data in order to apply the COW mapping. Not all data sets fit this requirement. One way to address both of the above problems is to implement an alternate zero copy send scheme that uses async I/O. With async I/O semantics, it will be clear to the userland program that the buffer in question is not to be used until it is returned from the kernel. So with that approach, you eliminate the need to map the data copy-on-write, and therefore also eliminate the need for the data to be page sized and page aligned. Receive side zero copy: The main issue with the current receive side zero copy code is the size and alignment restrictions. One way to get around the restriction is if it were possible to do operations similar to a page flip on buffers that are less than a page size. Another way to get around the restriction is to have the receiving client pass buffers into the kernel (perhaps with an async I/O type interface) and have the NIC DMA the data directly into the buffers the user has supplied. One proposal for doing this is called RDMA. There is a draft of the specification here: ftp://ftpeng.cisco.com/pub/rdma/draft-csapuntz-tcprdma-00.txt Essentially RDMA allows for the sender and receiver to negotiate destination buffer locations on the receiver. The sender then includes the buffer locations in a TCP header option, and the NIC can then extract the destination location for the payload and DMA it to the appropriate place. One drawback to this approach is that it requires support for RDMA on both ends of the connection. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 17 10:45:55 2000 Delivered-To: freebsd-arch@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id AB27A37B5D4 for ; Sat, 17 Jun 2000 10:45:50 -0700 (PDT) (envelope-from mckusick@mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id KAA08559; Sat, 17 Jun 2000 10:45:40 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200006171745.KAA08559@beastie.mckusick.com> To: Gregory Neil Shapiro Subject: Re: Broken FreeBSD setuid(2)? Cc: sendmail-questions@Sendmail.ORG, eric@Sendmail.ORG (Eric Allman), arch@freebsd.org In-Reply-To: Your message of "Thu, 15 Jun 2000 12:05:27 PDT." <14665.10487.273074.915885@horsey.gshapiro.net> Date: Sat, 17 Jun 2000 10:45:40 -0700 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG My answer is at the bottom. I am copying the FreeBSD arch group so they can complain if I am misrepresenting how this came to be. > Date: Thu, 15 Jun 2000 12:05:27 -0700 (PDT) > From: Gregory Neil Shapiro > To: sendmail-questions@Sendmail.ORG > Cc: eric@sendmail.com, mckusick@mckusick.com > Subject: Broken FreeBSD setuid(2)? > In-Reply-To: <26017.961092745@ux.cs.niu.edu> > References: <14665.5036.94759.10387@horsey.gshapiro.net> > <25862.961091528@ux.cs.niu.edu> > <14665.6387.591517.166768@horsey.gshapiro.net> > <26017.961092745@ux.cs.niu.edu> > X-Mailer: VM 6.75 under 21.2 (beta34) "Molpe" XEmacs Lucid > > I'm considering sending this off to someone at FreeBSD. Opinions before I > do? > > > I believe we (sendmail-bugs) have found a _possible_ bug in the setuid(2) > implementation on FreeBSD 3.4 (and possibly 4.0). setuid(2) appears to set > the saved uid even if the process is not running as root and not > set-user-id root. For example: > > #include > #include > #include > > int > main(int argc, char **argv) > { > uid_t euid = geteuid(); > uid_t ruid = getuid(); > > printf("Before: ruid=%d euid=%d\n", getuid(), geteuid()); > if (setuid(ruid) < 0) > perror("setuid"); > printf("Middle: ruid=%d euid=%d\n", getuid(), geteuid()); > if (setuid(euid) < 0) > perror("setuid"); > printf("After: ruid=%d euid=%d\n", getuid(), geteuid()); > } > > And an example run: > > > uname -a > FreeBSD horsey.gshapiro.net 3.4-STABLE FreeBSD 3.4-STABLE #51: Sun May 21 22:36:42 PDT 2000 root@horsey.gshapiro.net:/usr/src/sys/compile/HORSEY i386 > > ls -lag try > -rwsr-xr-x 1 generic gshapiro 3731 Jun 15 10:27 try > > id > uid=103(gshapiro) > > id generic > uid=101(generic) > > ./try > Before: ruid=103 euid=101 > Middle: ruid=103 euid=103 > setuid: Operation not permitted > After: ruid=103 euid=103 > > > POSIX Part I, section 4.2.2.2 states: > > If {_POSIX_SAVED_IDS} is defined: > ... > (2) If the process does not have appropriate privileges, but uid is > equal to the real user ID or the saved set-user-ID, the setuid() > function sets the effective user ID to uid; the real user ID and > saved set-user-ID remain unchanged by this function call. > > This is the case demonstrated above. It does not have appropriate privileges > since it is not running as root. The uid is equal to the real UID. > However, the setuid() function is setting the saved set-user-ID and not > leaving it unchanged. If it were unchanged, then the second setuid() > should not fail, again because of this statement and the fact that the uid > is equal to the saved set-user-ID. > > Looking at other implementations, we have found that the second setuid only > fails on FreeBSD. It succeeds and the program works as expected on > Solaris, Linux, and OpenBSD. > > I checked /usr/src/sys/kern/kern_prot.c and see comments about appendix B > but I do not believe they apply to this case. The setuid() man page > states: > > STANDARDS > The setuid() and setgid() functions are compliant with the IEEE > Std1003.1-1990 (``POSIX'') specification with _POSIX_SAVED_IDS not de- > fined with the permitted extensions from Appendix B.4.2.2. The seteuid() > and setegid() functions are extensions based on the POSIX concept of > _POSIX_SAVED_IDS, and have been proposed for a future revision of the > standard. > > It's arguable whether or not you can follow the rules of !_POSIX_SAVED_IDS > while still using saved IDs as it creates a subtle difference between > FreeBSD and other operating systems that more than likely goes unnoticed by > application writers and has the potential of breaking some of these > programs. I agree that FreeBSD does not implement saved id's according to the Posix spec. And indeed they do not claim to do so as {_POSIX_SAVED_IDS} is defined as false (see `sysctl kern.saved_ids'). As released, 4.4BSD defined {_POSIX_SAVED_IDS} as true and had the behavior of NetBSD and OpenBSD. Posix argues that a non-priviledged user should not have the ability to set the saved-id. They further argue that they should never need the ability to set the saved-id since they are only running their own trusted code. They can lose the special priviledge in any sub-processes that they exec simply by setting the real user-id to the effective user-id before doing the exec (since the effective user-id is copied to the saved user-id on exec). What Posix fails to account for is a program that gets corrupted by a stack overflow and wants to guard against it by losing their saved-id before starting to accept outside input. Posix would say that a program with a stack overflow is not compliant with the standard, and hence is outside the scope of the document. The FreeBSD folks decided to change the semantics of setuid to overwrite the saved user-id so that programs could protect themselves from stack overflows, debugger attaches, etc. They argue that seteuid is available if you just want to set the effective user-id and it is stupid to have a second system call (setuid) which does exactly the same thing when you are not root. Since Posix never bought into adding seteuid, they had to overload setuid to get the equivalent functionality. This is a good example of why Posix options were a bad idea. By letting each system ship with different option settings, you end up with very subtilely different semantics. Each vendor is well meaning, but makes for a programming nightmare among application developers that have to deal with all the combinations. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message