From owner-freebsd-arch@FreeBSD.ORG Sun May 9 08:35:27 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A36316A4CE; Sun, 9 May 2004 08:35:27 -0700 (PDT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 451B043D53; Sun, 9 May 2004 08:35:26 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i48Jb3Od041913; Sat, 8 May 2004 13:37:04 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 08 May 2004 13:37:47 -0600 (MDT) Message-Id: <20040508.133747.06227857.imp@bsdimp.com> To: marcel@xcllnt.net From: "M. Warner Losh" In-Reply-To: <20040508164334.GA3217@dhcp01.pn.xcllnt.net> References: <20040507231846.F52653@root.org> <20040508164334.GA3217@dhcp01.pn.xcllnt.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: arch@freebsd.org cc: nate@root.org Subject: Re: New ACPI blacklist format X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2004 15:35:27 -0000 The other option is to pick a meta-format and then generate the quirk tables from that. Forcing gcc to bend to your will may be ugly. This would also alow you to subset things for customer kernels. Warner From owner-freebsd-arch@FreeBSD.ORG Sun May 9 08:35:34 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45DE616A4D0; Sun, 9 May 2004 08:35:34 -0700 (PDT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id C68EF43D39; Sun, 9 May 2004 08:35:33 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i48BhhOd037646; Sat, 8 May 2004 05:44:58 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 08 May 2004 05:44:29 -0600 (MDT) Message-Id: <20040508.054429.99235478.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20040507231846.F52653@root.org> References: <20040507231846.F52653@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: arch@freebsd.org Subject: Re: New ACPI blacklist format X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2004 15:35:34 -0000 In message: <20040507231846.F52653@root.org> Nate Lawson writes: : I have extracted a set of known-broken tables/versions from various : sources. Since. as far as I know, C does not allow variable length : initializers, I've settled on the following format: It does. : struct acpi_table_desc { : char *signature; : char *oem_id; : char *oem_table_id; : char *oem_rev_op; : char *oem_revision; : char *creator_id; : char *creator_rev_op; : char *creator_revision; : }; : : struct acpi_blacklist { : int quirk; : struct acpi_table_desc *match; : }; : : #define ACPI_BROKEN 0x1 : : static struct acpi_table_desc Abit_BP6[] = { : { "FACP", "AWARD", "AWRDACPI", "<=", "30302e31", "", "", "" }, : }; { .signature = "FACP", .oem_id="AWARD", .oem_table_id="AWARDACPI", .oem_rev_op = "<=", } :The op values will be "<=", "=", and ">=". These are likely better as a enum. : Is there any better way to compact this? Using shorter structure names would get it all onthe same line. Warner From owner-freebsd-arch@FreeBSD.ORG Sun May 9 08:35:37 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A11516A4D0; Sun, 9 May 2004 08:35:37 -0700 (PDT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4E1B43D39; Sun, 9 May 2004 08:35:36 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i486C9Od031485; Sat, 8 May 2004 00:12:09 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 08 May 2004 00:12:55 -0600 (MDT) Message-Id: <20040508.001255.39158392.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200405071012.34816.jhb@FreeBSD.org> References: <20040507092840.24516.qmail@web14808.mail.yahoo.com> <200405071012.34816.jhb@FreeBSD.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: rosti_bsd@yahoo.com cc: freebsd-arch@freebsd.org Subject: Re: question about "IRQ 2 problem" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2004 15:35:37 -0000 In message: <200405071012.34816.jhb@FreeBSD.org> John Baldwin writes: : On Friday 07 May 2004 05:28 am, Rostislav Krasny wrote: : > Hello everybody. : > : > About 5 monthes ago I wrote to this mailing list about the "IRQ 2 : > problem". You can read that discussion thread by following links: : > : > http://lists.freebsd.org/pipermail/freebsd-arch/2003-December/thread.html : > http://lists.freebsd.org/pipermail/freebsd-arch/2004-January/thread.html : > : > I just want to know what is the satus of this problem now? : > : > Thank you. : : Not fixed yet. Someone needs to sit down and verify if the resource manager : is silently adding in the IRQ 2 resource when it hasn't beek asked to. It seems that it hasn't been added via the normal APIs, but maybe there's some bugs there. I've found out that much. Warner From owner-freebsd-arch@FreeBSD.ORG Sun May 9 08:35:44 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4889F16A4D1 for ; Sun, 9 May 2004 08:35:44 -0700 (PDT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id B148043D55 for ; Sun, 9 May 2004 08:35:43 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i47DmZOd021590; Fri, 7 May 2004 07:48:35 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 07 May 2004 07:44:47 -0600 (MDT) Message-Id: <20040507.074447.99375523.imp@bsdimp.com> To: rosti_bsd@yahoo.com From: "M. Warner Losh" In-Reply-To: <20040507092840.24516.qmail@web14808.mail.yahoo.com> References: <20040507092840.24516.qmail@web14808.mail.yahoo.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: question about "IRQ 2 problem" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2004 15:35:44 -0000 In message: <20040507092840.24516.qmail@web14808.mail.yahoo.com> Rostislav Krasny writes: : Hello everybody. : : About 5 monthes ago I wrote to this mailing list about the "IRQ 2 : problem". You can read that discussion thread by following links: : : http://lists.freebsd.org/pipermail/freebsd-arch/2003-December/thread.html : http://lists.freebsd.org/pipermail/freebsd-arch/2004-January/thread.html : : I just want to know what is the satus of this problem now? It is on my big list of things to work on when I get a minute. But I dispair getting that far down on my list. Warner From owner-freebsd-arch@FreeBSD.ORG Mon May 10 07:06:01 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CD2416A4CE for ; Mon, 10 May 2004 07:06:01 -0700 (PDT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8641443D5D for ; Mon, 10 May 2004 07:06:00 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 13803 invoked from network); 10 May 2004 14:05:58 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 10 May 2004 14:05:58 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i4AE5rmX097375; Mon, 10 May 2004 10:05:53 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-acpi@FreeBSD.org Date: Mon, 10 May 2004 10:06:18 -0400 User-Agent: KMail/1.6 References: <20040507231846.F52653@root.org> <20040508.054429.99235478.imp@bsdimp.com> <20040508113421.R58706@root.org> In-Reply-To: <20040508113421.R58706@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405101006.18787.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: acpi@FreeBSD.org cc: arch@FreeBSD.org cc: Nate Lawson Subject: Re: New ACPI blacklist format X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2004 14:06:01 -0000 On Saturday 08 May 2004 02:37 pm, Nate Lawson wrote: > On Sat, 8 May 2004, M. Warner Losh wrote: > > In message: <20040507231846.F52653@root.org> > > > > Nate Lawson writes: > > : I have extracted a set of known-broken tables/versions from various > > : sources. Since. as far as I know, C does not allow variable length > > : initializers, I've settled on the following format: > > > > It does. > > > > : struct acpi_table_desc { > > : char *signature; > > : char *oem_id; > > : char *oem_table_id; > > : char *oem_rev_op; > > : char *oem_revision; > > : char *creator_id; > > : char *creator_rev_op; > > : char *creator_revision; > > : }; > > : > > : struct acpi_blacklist { > > : int quirk; > > : struct acpi_table_desc *match; > > : }; > > : > > : #define ACPI_BROKEN 0x1 > > : > > : static struct acpi_table_desc Abit_BP6[] = { > > : { "FACP", "AWARD", "AWRDACPI", "<=", "30302e31", "", "", "" }, > > : }; > > > > { .signature = "FACP", .oem_id="AWARD", .oem_table_id="AWARDACPI", > > .oem_rev_op = "<=", } > > > > :The op values will be "<=", "=", and ">=". > > > > These are likely better as a enum. > > > > : Is there any better way to compact this? > > > > Using shorter structure names would get it all onthe same line. > > Sure, good comments. What I meant by compacting was to get a variable > number of acpi_table_desc elements in a single blacklist entry without > defining a separate static. Something like this: > > static struct acpi_blacklist blacklist[] = { > { > .quirk = ACPI_BROKEN, > { > { "FACP", ... }, > { "DSDT", ... } > } > }, > { > .quirk = ... > } > }; > > The compiler didn't allow this. I like the idea of having a flat file that Marcel or Warner suggested and generating the .c code from that file. I also think using enums or #define's for the logical operations is much better than having to do string compares in the kernel. Note that the file parser could translate 'oemrev <= foo' to an appropriate constant. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Tue May 11 07:39:58 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E92916A4CE; Tue, 11 May 2004 07:39:58 -0700 (PDT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id B977E43D41; Tue, 11 May 2004 07:39:57 -0700 (PDT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 28A085309; Tue, 11 May 2004 16:39:56 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 8884A530F; Tue, 11 May 2004 16:39:40 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 6B1EC33CAA; Tue, 11 May 2004 16:39:40 +0200 (CEST) To: arch@freebsd.org From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Tue, 11 May 2004 16:39:40 +0200 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: dfr@freebsd.org Subject: newbus flaw X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2004 14:39:58 -0000 I've found what I believe is a serious flaw in newbus. When a driver that has a DEVICE_IDENTIFY method is loaded, the identify method is called. If it finds supported hardware, it uses BUS_ADD_CHILD to notify the parent bus of the presence of that hardware. At some later point, during a bus rescan, the attach routine is called for each device that was identified in this manner. When the driver is unloaded, the device is detached, but it remains on the bus's list of child devices. The next time the module is loaded, its DEVICE_IDENTIFY method is called again, and incorrectly adds a second child device to the bus, because it does not know that one already exists. There is no way for DEVICE_IDENTIFY to check if a matching child already exists on the bus, or for the module's event handler to unlist the child when unloading. The first time you load the module, you get foo0; the second time, you get foo0 *and* foo1 referencing the same physical device; the third time, you get foo0, foo1, and foo2, etc. I've also seen something similar happen when multiple ndis drivers are loaded; the first one re-attaches to the hardware when the second one is loaded. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue May 11 08:08:13 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 876B116A4CE; Tue, 11 May 2004 08:08:13 -0700 (PDT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1740E43D48; Tue, 11 May 2004 08:08:12 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id i4BF85kM044349; Tue, 11 May 2004 16:08:06 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) i4BF7oON021084; Tue, 11 May 2004 16:08:05 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Message-Id: <1084288070.13434.26.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 11 May 2004 16:07:50 +0100 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: arch@freebsd.org cc: dfr@freebsd.org Subject: Re: newbus flaw X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2004 15:08:13 -0000 On Tue, 2004-05-11 at 15:39, Dag-Erling Smørgrav wrote: > I've found what I believe is a serious flaw in newbus. > > When a driver that has a DEVICE_IDENTIFY method is loaded, the > identify method is called. If it finds supported hardware, it uses > BUS_ADD_CHILD to notify the parent bus of the presence of that > hardware. At some later point, during a bus rescan, the attach > routine is called for each device that was identified in this manner. > > When the driver is unloaded, the device is detached, but it remains on > the bus's list of child devices. The next time the module is loaded, > its DEVICE_IDENTIFY method is called again, and incorrectly adds a > second child device to the bus, because it does not know that one > already exists. > > There is no way for DEVICE_IDENTIFY to check if a matching child > already exists on the bus, or for the module's event handler to unlist > the child when unloading. > > The first time you load the module, you get foo0; the second time, you > get foo0 *and* foo1 referencing the same physical device; the third > time, you get foo0, foo1, and foo2, etc. > > I've also seen something similar happen when multiple ndis drivers are > loaded; the first one re-attaches to the hardware when the second one > is loaded. This is a known problem. The 'right' solution is to add a new static method to the device interface which is the opposite of IDENTIFY (e.g. UNIDENTIFY). One way to get around the problem is to do something like: void foo_identify(driver_t *driver, device_t parent) { device_t child; child = device_find_child(parent, "foo", 0); if (!child) BUS_ADD_CHILD(parent, 0, "foo", 0); } Alternatively, you can add a module handler: static device_t foo; void foo_identify(driver_t *driver, device_t parent) { foo = BUS_ADD_CHILD(parent, 0, "foo", -1); } ... int foo_module_handler(struct module *mod, int what, void *arg) { if (what == MOD_UNLOAD && foo) device_delete_child(device_get_parent(foo), foo); } ... DRIVER_MODULE(foo, bar, foo_driver, foo_devclass, foo_module_handler, 0); From owner-freebsd-arch@FreeBSD.ORG Tue May 11 08:13:04 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1085916A4CE; Tue, 11 May 2004 08:13:04 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0301843D45; Tue, 11 May 2004 08:13:03 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i4BFCsH9014142; Tue, 11 May 2004 17:12:59 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Doug Rabson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 11 May 2004 16:07:50 BST." <1084288070.13434.26.camel@builder02.qubesoft.com> Date: Tue, 11 May 2004 17:12:54 +0200 Message-ID: <14141.1084288374@critter.freebsd.dk> cc: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= cc: dfr@freebsd.org cc: arch@freebsd.org Subject: Re: newbus flaw X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2004 15:13:04 -0000 In message <1084288070.13434.26.camel@builder02.qubesoft.com>, Doug Rabson writ es: >This is a known problem. The 'right' solution is to add a new static >method to the device interface which is the opposite of IDENTIFY (e.g. >UNIDENTIFY). One way to get around the problem is to do something like: That word should be dragged behind the first convenient tree and stabbed to death. The opposite of IDENTIFY would be OBSCURE, but I supposed in this case that FORGET would be appropriate. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue May 11 15:14:52 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D11716A4CF for ; Tue, 11 May 2004 15:14:52 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id E885B43D31 for ; Tue, 11 May 2004 15:14:51 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 77656 invoked by uid 1000); 11 May 2004 22:14:53 -0000 Date: Tue, 11 May 2004 15:14:53 -0700 (PDT) From: Nate Lawson To: Marcel Moolenaar In-Reply-To: <20040508164334.GA3217@dhcp01.pn.xcllnt.net> Message-ID: <20040511151428.P77557@root.org> References: <20040507231846.F52653@root.org> <20040508164334.GA3217@dhcp01.pn.xcllnt.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi@freebsd.org cc: arch@freebsd.org Subject: Re: New ACPI blacklist format X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2004 22:14:52 -0000 On Sat, 8 May 2004, Marcel Moolenaar wrote: > On Fri, May 07, 2004 at 11:28:15PM -0700, Nate Lawson wrote: > > *snip* > > > static struct acpi_table_desc Abit_BP6[] = { > > { "FACP", "AWARD", "AWRDACPI", "<=", "30302e31", "", "", "" }, > > }; > > static struct acpi_table_desc AMI_INT[] = { /* 01/18/00 */ > > { "FACP", "AWARD", "", "<=", "10", "", "", "" }, > > { "DSDT", "", "", "<=", "5", "", "", "" }, > > }; > > static struct acpi_table_desc Compaq_ViperII[] = { > > { "FACP", "COMPAQ", "VIPER II", "<=", "06040000", "PTL", "<=", "000F4240" }, > > }; > > *snip* > > If space is a concern, you can enable (i.e. compile-in) quirks by > using kernel options, like: > > options ACPI_QUIRK_ABIT_BP6 > > and > > #ifdef ACPI_QUIRK_ABIT_BP6 > static struct acpi_table_desc Abit_BP6[] = { > { "FACP", "AWARD", "AWRDACPI", "<=", "30302e31", "", "", "" }, > }; > #endif > > You put all three of them in GENERIC and people can add or remove them > from their own kernel configuration to fit their needs (and save space). > If the quirks are in MI files, then this also avoids that i386 quirks > end up in amd64 or ia64 kernels. There will be about 100-300 of these. :) -Nate From owner-freebsd-arch@FreeBSD.ORG Tue May 11 17:34:44 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D04E116A4CE; Tue, 11 May 2004 17:34:44 -0700 (PDT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4154443D1D; Tue, 11 May 2004 17:34:44 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i4C0YhOd087729; Tue, 11 May 2004 18:34:43 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 11 May 2004 18:35:38 -0600 (MDT) Message-Id: <20040511.183538.13771005.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20040511151428.P77557@root.org> References: <20040507231846.F52653@root.org> <20040508164334.GA3217@dhcp01.pn.xcllnt.net> <20040511151428.P77557@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: arch@freebsd.org cc: marcel@xcllnt.net Subject: Re: New ACPI blacklist format X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2004 00:34:45 -0000 In message: <20040511151428.P77557@root.org> Nate Lawson writes: : On Sat, 8 May 2004, Marcel Moolenaar wrote: : > On Fri, May 07, 2004 at 11:28:15PM -0700, Nate Lawson wrote: : > : > *snip* : > : > > static struct acpi_table_desc Abit_BP6[] = { : > > { "FACP", "AWARD", "AWRDACPI", "<=", "30302e31", "", "", "" }, : > > }; : > > static struct acpi_table_desc AMI_INT[] = { /* 01/18/00 */ : > > { "FACP", "AWARD", "", "<=", "10", "", "", "" }, : > > { "DSDT", "", "", "<=", "5", "", "", "" }, : > > }; : > > static struct acpi_table_desc Compaq_ViperII[] = { : > > { "FACP", "COMPAQ", "VIPER II", "<=", "06040000", "PTL", "<=", "000F4240" }, : > > }; : > : > *snip* : > : > If space is a concern, you can enable (i.e. compile-in) quirks by : > using kernel options, like: : > : > options ACPI_QUIRK_ABIT_BP6 : > : > and : > : > #ifdef ACPI_QUIRK_ABIT_BP6 : > static struct acpi_table_desc Abit_BP6[] = { : > { "FACP", "AWARD", "AWRDACPI", "<=", "30302e31", "", "", "" }, : > }; : > #endif : > : > You put all three of them in GENERIC and people can add or remove them : > from their own kernel configuration to fit their needs (and save space). : > If the quirks are in MI files, then this also avoids that i386 quirks : > end up in amd64 or ia64 kernels. : : There will be about 100-300 of these. :) All the more reason to have them in a form that can easily be subset and takes the tedium (== error possibilities) out of the loop :-) Warner From owner-freebsd-arch@FreeBSD.ORG Tue May 11 17:59:36 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDD5716A4CE; Tue, 11 May 2004 17:59:36 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 797F843D1F; Tue, 11 May 2004 17:59:36 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i4C0xPUY041050; Tue, 11 May 2004 17:59:25 -0700 (PDT) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.12.11/8.12.11/Submit) id i4C0xP7H041049; Tue, 11 May 2004 17:59:25 -0700 (PDT) (envelope-from marcel) Date: Tue, 11 May 2004 17:59:25 -0700 From: Marcel Moolenaar To: "M. Warner Losh" Message-ID: <20040512005925.GA40996@ns1.xcllnt.net> References: <20040507231846.F52653@root.org> <20040508164334.GA3217@dhcp01.pn.xcllnt.net> <20040511151428.P77557@root.org> <20040511.183538.13771005.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040511.183538.13771005.imp@bsdimp.com> User-Agent: Mutt/1.5.5.1i cc: acpi@freebsd.org cc: arch@freebsd.org cc: nate@root.org Subject: Re: New ACPI blacklist format X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2004 00:59:36 -0000 On Tue, May 11, 2004 at 06:35:38PM -0600, M. Warner Losh wrote: > : > > : > You put all three of them in GENERIC and people can add or remove them > : > from their own kernel configuration to fit their needs (and save space). > : > If the quirks are in MI files, then this also avoids that i386 quirks > : > end up in amd64 or ia64 kernels. > : > : There will be about 100-300 of these. :) > > All the more reason to have them in a form that can easily be subset > and takes the tedium (== error possibilities) out of the loop :-) Agreed. The compactness and syntax of the source code can then be optimized for readability and editability. The generated quirks can be optimized for speed and space. With that many quirk entries, I think that's important enough to the offset the added complexity... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Tue May 11 18:02:44 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EC8416A4CE for ; Tue, 11 May 2004 18:02:44 -0700 (PDT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84AC643D3F for ; Tue, 11 May 2004 18:02:43 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 30474 invoked from network); 12 May 2004 01:02:43 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 May 2004 01:02:43 -0000 Received: from hydrogen.funkthat.com (felopi@localhost.funkthat.com [127.0.0.1])i4C12fEx098411; Tue, 11 May 2004 18:02:42 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i4C12eDq098410; Tue, 11 May 2004 18:02:40 -0700 (PDT) Date: Tue, 11 May 2004 18:02:40 -0700 From: John-Mark Gurney To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20040512010240.GD601@funkthat.com> Mail-Followup-To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , arch@freebsd.org, dfr@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: arch@freebsd.org cc: dfr@freebsd.org Subject: Re: newbus flaw X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2004 01:02:44 -0000 Dag-Erling Smørgrav wrote this message on Tue, May 11, 2004 at 16:39 +0200: > When the driver is unloaded, the device is detached, but it remains on > the bus's list of child devices. The next time the module is loaded, > its DEVICE_IDENTIFY method is called again, and incorrectly adds a > second child device to the bus, because it does not know that one > already exists. > > There is no way for DEVICE_IDENTIFY to check if a matching child > already exists on the bus, or for the module's event handler to unlist > the child when unloading. As someone else points out, this is already a known case and was discusses on -arch a while back. You are incorrect in assuming you can't find out if another child already exists.. Usually this is a problem of properly allocating resources so that you know the other child exists. Since you are using identify, you already don't have a "self describing" bus, which means that you have to either use hints, or another method to make sure that your device doesn't already exist. For example, in my adv717xa driver, part of the zoran driver, I do the following in my _probe routine to prevent probing and attaching to the same chip. /* Make sure this isn't already attached */ if (sibs == NULL) device_get_children(iicbus, &sibs, &sibcnt); for (j = 0; j < sibcnt; j++) { if (device_get_state(sibs[j]) >= DS_ATTACHED && device_get_driver(sibs[j]) == drv && ((struct adv717xa_softc *) device_get_softc(sibs[j]))->adv_slvaddr == chips[i].addr) { device_printf(dev, "already attached at %s\n", device_get_nameunit(sibs[j])); break; } } This should not be a problem because the i2c bus should either do proper resource allocation for the id, which when I try to probe, I allocate the chip id, and that fails, preventing it's creation... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Wed May 12 06:27:06 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 671F516A4CE; Wed, 12 May 2004 06:27:06 -0700 (PDT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAD0F43D55; Wed, 12 May 2004 06:27:05 -0700 (PDT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id A401E530D; Wed, 12 May 2004 15:27:04 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id C3E6D5309; Wed, 12 May 2004 15:26:57 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 6967833CAA; Wed, 12 May 2004 15:26:57 +0200 (CEST) To: arch@freebsd.org References: <20040512010240.GD601@funkthat.com> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Wed, 12 May 2004 15:26:57 +0200 In-Reply-To: <20040512010240.GD601@funkthat.com> (John-Mark Gurney's message of "Tue, 11 May 2004 18:02:40 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: dfr@freebsd.org Subject: Re: newbus flaw X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2004 13:27:06 -0000 John-Mark Gurney writes: > You are incorrect in assuming you can't find out if another child already > exists.. Usually this is a problem of properly allocating resources so > that you know the other child exists. Since you are using identify, you > already don't have a "self describing" bus, which means that you have > to either use hints, or another method to make sure that your device > doesn't already exist. It's not quite that simple. See the block comment at the top of src/sys/dev/ichwd/ichwd.c for an explanation. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Wed May 12 10:41:53 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDC6816A4CE for ; Wed, 12 May 2004 10:41:53 -0700 (PDT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 566BE43D49 for ; Wed, 12 May 2004 10:41:53 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 8045 invoked from network); 12 May 2004 17:41:52 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 May 2004 17:41:52 -0000 Received: from hydrogen.funkthat.com (lqnune@localhost.funkthat.com [127.0.0.1])i4CHfnEx012673; Wed, 12 May 2004 10:41:51 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i4CHfnvL012672; Wed, 12 May 2004 10:41:49 -0700 (PDT) Date: Wed, 12 May 2004 10:41:48 -0700 From: John-Mark Gurney To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20040512174148.GE601@funkthat.com> Mail-Followup-To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , arch@freebsd.org, dfr@freebsd.org References: <20040512010240.GD601@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: arch@freebsd.org cc: dfr@freebsd.org Subject: Re: newbus flaw X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2004 17:41:53 -0000 Dag-Erling Smørgrav wrote this message on Wed, May 12, 2004 at 15:26 +0200: > John-Mark Gurney writes: > > You are incorrect in assuming you can't find out if another child already > > exists.. Usually this is a problem of properly allocating resources so > > that you know the other child exists. Since you are using identify, you > > already don't have a "self describing" bus, which means that you have > > to either use hints, or another method to make sure that your device > > doesn't already exist. > > It's not quite that simple. See the block comment at the top of > src/sys/dev/ichwd/ichwd.c for an explanation. I couldn't find ichwd, but I could find ichsmb? In ichsmb.c, doing the device_add_child in _probe is not correct. It should be done at attach time, and removed at detach time. The probe maybe be called multiple times. As far as the assumption of only one process calling methods, I would enforce it by making sure that once a device is attached, any other attempts to attach fail.. That should also solve the problem. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Wed May 12 10:49:00 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D38A416A4CE; Wed, 12 May 2004 10:49:00 -0700 (PDT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CFF943D4C; Wed, 12 May 2004 10:49:00 -0700 (PDT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id E2BBE530D; Wed, 12 May 2004 19:48:58 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 4E0575309; Wed, 12 May 2004 19:48:52 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 0BF9833CAA; Wed, 12 May 2004 19:48:52 +0200 (CEST) To: arch@freebsd.org References: <20040512010240.GD601@funkthat.com> <20040512174148.GE601@funkthat.com> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Wed, 12 May 2004 19:48:51 +0200 In-Reply-To: <20040512174148.GE601@funkthat.com> (John-Mark Gurney's message of "Wed, 12 May 2004 10:41:48 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: dfr@freebsd.org Subject: Re: newbus flaw X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2004 17:49:00 -0000 John-Mark Gurney writes: > Dag-Erling Sm=F8rgrav wrote this message on Wed, May 12, 2004 at 15:26 +0= 200: > > It's not quite that simple. See the block comment at the top of > > src/sys/dev/ichwd/ichwd.c for an explanation. > I couldn't find ichwd, but I could find ichsmb? Update your tree. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Wed May 12 10:53:54 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C46C16A4CE for ; Wed, 12 May 2004 10:53:54 -0700 (PDT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B9E743D31 for ; Wed, 12 May 2004 10:53:53 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 2818 invoked from network); 12 May 2004 17:53:52 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 May 2004 17:53:52 -0000 Received: from hydrogen.funkthat.com (ryjgxw@localhost.funkthat.com [127.0.0.1])i4CHrpEx012903; Wed, 12 May 2004 10:53:52 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i4CHrp9r012902; Wed, 12 May 2004 10:53:51 -0700 (PDT) Date: Wed, 12 May 2004 10:53:51 -0700 From: John-Mark Gurney To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20040512175351.GF601@funkthat.com> Mail-Followup-To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , arch@freebsd.org, dfr@freebsd.org References: <20040512010240.GD601@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: arch@freebsd.org cc: dfr@freebsd.org Subject: Re: newbus flaw X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2004 17:53:54 -0000 Dag-Erling Smørgrav wrote this message on Wed, May 12, 2004 at 15:26 +0200: > John-Mark Gurney writes: > > You are incorrect in assuming you can't find out if another child already > > exists.. Usually this is a problem of properly allocating resources so > > that you know the other child exists. Since you are using identify, you > > already don't have a "self describing" bus, which means that you have > > to either use hints, or another method to make sure that your device > > doesn't already exist. > > It's not quite that simple. See the block comment at the top of > src/sys/dev/ichwd/ichwd.c for an explanation. Sorry, I had an out of date cvsup and hadn't received ichwd yet. You're always going to be a child of nexus, and since I assume from the comment that there can only ever be one child. Also, why do you find_child w/ unit number 0, but then add a child with unit -1? Why not add it unit 0, and make it fail if that already exists? Also, it seems to me that if dev already exists, that you shouldn't reset the driver and desc. This should be harmless, but if for some reason you are called on an attached device, it could cause problems. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Wed May 12 13:30:25 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75C8316A4CE; Wed, 12 May 2004 13:30:25 -0700 (PDT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0FFB43D4C; Wed, 12 May 2004 13:30:24 -0700 (PDT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id A90B55309; Wed, 12 May 2004 22:30:23 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 87C40530D; Wed, 12 May 2004 22:30:16 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 70B5833CAA; Wed, 12 May 2004 22:30:16 +0200 (CEST) To: arch@freebsd.org References: <20040512010240.GD601@funkthat.com> <20040512175351.GF601@funkthat.com> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Wed, 12 May 2004 22:30:16 +0200 In-Reply-To: <20040512175351.GF601@funkthat.com> (John-Mark Gurney's message of "Wed, 12 May 2004 10:53:51 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: dfr@freebsd.org Subject: Re: newbus flaw X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2004 20:30:25 -0000 John-Mark Gurney writes: > You're always going to be a child of nexus, and since I assume from > the comment that there can only ever be one child. Also, why do you > find_child w/ unit number 0, but then add a child with unit -1? Why > not add it unit 0, and make it fail if that already exists? just didn't think about it. the documentation is somewhat lacking, so some of the code is based on examining existing code and headers and guessing at what it all means. > Also, it seems to me that if dev already exists, that you shouldn't > reset the driver and desc. This should be harmless, but if for some > reason you are called on an attached device, it could cause problems. it'll all go pear-shaped if you don't. if an ichwd device already exists, it is a leftover from a previous module load / unload cycle and the driver_t it references no longer exists. ichwd_identify() should probably KASSERT that the device it finds isn't attached - I'm pretty sure it can't happen. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Wed May 12 19:08:20 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF0DC16A4D1; Wed, 12 May 2004 19:08:19 -0700 (PDT) Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id B663043D49; Wed, 12 May 2004 19:08:19 -0700 (PDT) (envelope-from tedu@stanford.edu) Received: from elaine22.Stanford.EDU (elaine22.Stanford.EDU [171.64.15.87]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with ESMTP id i4D28HbN012177; Wed, 12 May 2004 19:08:17 -0700 Date: Wed, 12 May 2004 19:08:17 -0700 (PDT) From: Ted Unangst To: Michael Bushkov In-Reply-To: <20040305114316.K19883@stinger.cc.rsu.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: bork@rsu.ru cc: arch@freebsd.org cc: os@rsu.ru cc: hackers@freebsd.org cc: and@rsu.ru Subject: Re: IPC nsswitch implementation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2004 02:08:20 -0000 On Fri, 5 Mar 2004, Michael Bushkov wrote: > Some time ago there was a discussion concerning in-process vs. IPC > nsswitch implementation. We agreed that we should develop an example of > IPC implementation and ask for a discussion. We are glad to present you > sample implementation of the IPC nsswitch model. can you release a new version with copyright and license information for each source file? has any further work been done since the original release? -- From owner-freebsd-arch@FreeBSD.ORG Thu May 13 01:15:44 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE29A16A4CE; Thu, 13 May 2004 01:15:44 -0700 (PDT) Received: from asterix.rsu.ru (asterix.rsu.ru [195.208.245.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9066743D53; Thu, 13 May 2004 01:15:43 -0700 (PDT) (envelope-from bushman@rsu.ru) Received: from stinger.cc.rsu.ru (stinger.cc.rsu.ru [195.208.252.82]) by asterix.rsu.ru (8.12.11/8.12.11) with ESMTP id i4D8FUNH087535; Thu, 13 May 2004 12:15:30 +0400 (MSD) (envelope-from bushman@rsu.ru) Date: Thu, 13 May 2004 12:19:58 +0400 (MSD) From: Michael Bushkov X-X-Sender: bushman@stinger.cc.rsu.ru To: Ted Unangst In-Reply-To: <20040513113902.N65696@brain.cc.rsu.ru> Message-ID: <20040513121153.X12892@stinger.cc.rsu.ru> References: <20040513113902.N65696@brain.cc.rsu.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=KOI8-R Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Status: No, hits=-104.9 required=5.0 tests=BAYES_00,USER_IN_WHITELIST autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on asterix.rsu.ru cc: bork@rsu.ru cc: arch@freebsd.org cc: os@rsu.ru cc: hackers@freebsd.org cc: and@rsu.ru Subject: Re: IPC nsswitch implementation (fwd) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2004 08:15:44 -0000 > On Fri, 5 Mar 2004, Michael Bushkov wrote: > > > Some time ago there was a discussion concerning in-process vs. IPC > > nsswitch implementation. We agreed that we should develop an example of > > IPC implementation and ask for a discussion. We are glad to present you > > sample implementation of the IPC nsswitch model. > > can you release a new version with copyright and license information for > each source file? > > has any further work been done since the original release? Of course we can. We will release the new version approxim=C6tely in the en= d of the next week. It will be under BSD license. It changed much from the original release. We added caching and ported PADL nss_ldap module (changes are minimal, and they mostly reside in bsdnss.c file, which is FreeBSD specific). We are currently working on get**ent functions. And we will include them in the new release. The new FreeBSD committer, Christian Peron also has worked on project, related to the LookupD. And we are currently discussing the future of our projects. -- Michael Bushkov Software Engineer, Rostov State University From owner-freebsd-arch@FreeBSD.ORG Thu May 13 01:27:16 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42EE616A4CE; Thu, 13 May 2004 01:27:16 -0700 (PDT) Received: from herring.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id D65EC43D1D; Thu, 13 May 2004 01:27:13 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [10.0.0.2]) by herring.rabson.org (8.12.11/8.12.11) with ESMTP id i4D8R1XX037364; Thu, 13 May 2004 09:27:01 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Thu, 13 May 2004 09:27:01 +0100 User-Agent: KMail/1.6.1 References: <20040512175351.GF601@funkthat.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200405130927.01034.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on herring.rabson.org X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: arch@freebsd.org cc: dfr@freebsd.org Subject: Re: newbus flaw X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2004 08:27:16 -0000 On Wednesday 12 May 2004 21:30, Dag-Erling Sm=F8rgrav wrote: > John-Mark Gurney writes: > > You're always going to be a child of nexus, and since I assume from > > the comment that there can only ever be one child. Also, why do > > you find_child w/ unit number 0, but then add a child with unit -1? > > Why not add it unit 0, and make it fail if that already exists? > > just didn't think about it. the documentation is somewhat lacking, > so some of the code is based on examining existing code and headers > and guessing at what it all means. > > > Also, it seems to me that if dev already exists, that you shouldn't > > reset the driver and desc. This should be harmless, but if for > > some reason you are called on an attached device, it could cause > > problems. > > it'll all go pear-shaped if you don't. if an ichwd device already > exists, it is a leftover from a previous module load / unload cycle > and the driver_t it references no longer exists. ichwd_identify() > should probably KASSERT that the device it finds isn't attached - I'm > pretty sure it can't happen. When the old module unloaded, its driver will have detached from the=20 device which it created. There is no reference to an old driver_t. Its=20 perfectly safe for the new driver to use the old device. From owner-freebsd-arch@FreeBSD.ORG Thu May 13 03:46:29 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E91916A4CE; Thu, 13 May 2004 03:46:29 -0700 (PDT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5145343D2F; Thu, 13 May 2004 03:46:28 -0700 (PDT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 3E86A530F; Thu, 13 May 2004 12:46:27 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 845565309; Thu, 13 May 2004 12:46:20 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 35FED33CAA; Thu, 13 May 2004 12:46:20 +0200 (CEST) To: Doug Rabson References: <20040512175351.GF601@funkthat.com> <200405130927.01034.dfr@nlsystems.com> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Thu, 13 May 2004 12:46:19 +0200 In-Reply-To: <200405130927.01034.dfr@nlsystems.com> (Doug Rabson's message of "Thu, 13 May 2004 09:27:01 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: arch@freebsd.org cc: dfr@freebsd.org Subject: Re: newbus flaw X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2004 10:46:29 -0000 Doug Rabson writes: > When the old module unloaded, its driver will have detached from the=20 > device which it created. There is no reference to an old driver_t. Its=20 > perfectly safe for the new driver to use the old device. so why do you say I "shouldn't reset the old driver and desc"? DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu May 13 05:34:40 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D401A16A4CE; Thu, 13 May 2004 05:34:40 -0700 (PDT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9E8543D2F; Thu, 13 May 2004 05:34:39 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id i4DCYXkM021633; Thu, 13 May 2004 13:34:33 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) i4DCYWON067231; Thu, 13 May 2004 13:34:32 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: References: <20040512175351.GF601@funkthat.com> <200405130927.01034.dfr@nlsystems.com> Content-Type: text/plain; charset=UTF-8 Message-Id: <1084451672.14878.5.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 13 May 2004 13:34:32 +0100 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: arch@freebsd.org cc: dfr@freebsd.org Subject: Re: newbus flaw X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2004 12:34:40 -0000 On Thu, 2004-05-13 at 11:46, Dag-Erling Smørgrav wrote: > Doug Rabson writes: > > When the old module unloaded, its driver will have detached from the > > device which it created. There is no reference to an old driver_t. Its > > perfectly safe for the new driver to use the old device. > > so why do you say I "shouldn't reset the old driver and desc"? I didn't say that (that was John-Mark). When you create a device using something like device_add_child(parent, "foo", unit), the new device is just labelled as a 'fooN' - it has no reference to any 'foo' driver and should have since there may be several. The 'foo'ness of the device is used to match the device against a suitable driver at probe time. From owner-freebsd-arch@FreeBSD.ORG Thu May 13 09:06:37 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E46916A4CE; Thu, 13 May 2004 09:06:37 -0700 (PDT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE9B443D66; Thu, 13 May 2004 09:06:36 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i4DG6ROd013225; Thu, 13 May 2004 10:06:27 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 13 May 2004 09:54:00 -0600 (MDT) Message-Id: <20040513.095400.26471613.imp@bsdimp.com> To: des@des.no From: "M. Warner Losh" In-Reply-To: References: <200405130927.01034.dfr@nlsystems.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: arch@freebsd.org cc: dfr@freebsd.org Subject: Re: newbus flaw X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2004 16:06:37 -0000 In message: des@des.no (Dag-Erling Sm=F8rgrav) writes: : Doug Rabson writes: : > When the old module unloaded, its driver will have detached from th= e = : > device which it created. There is no reference to an old driver_t. = Its = : > perfectly safe for the new driver to use the old device. : = : so why do you say I "shouldn't reset the old driver and desc"? subr_bus.c does that already on detach. The association between devclass and device_t is done just prior to probe being called on a per device basis. Warner From owner-freebsd-arch@FreeBSD.ORG Fri May 14 01:30:28 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B130016A4CE for ; Fri, 14 May 2004 01:30:28 -0700 (PDT) Received: from web21103.mail.yahoo.com (web21103.mail.yahoo.com [216.136.227.105]) by mx1.FreeBSD.org (Postfix) with SMTP id E52EA43D48 for ; Fri, 14 May 2004 01:30:27 -0700 (PDT) (envelope-from materribile@yahoo.com) Message-ID: <20040514083027.38172.qmail@web21103.mail.yahoo.com> Received: from [24.228.74.10] by web21103.mail.yahoo.com via HTTP; Fri, 14 May 2004 01:30:27 PDT Date: Fri, 14 May 2004 01:30:27 -0700 (PDT) From: Mark Terribile To: arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: Garrett Wollman Subject: Re: kqueue giant-locking (&kq_Giant, locking) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2004 08:30:28 -0000 Sirs, Please excuse my coming in late on this; I don't ordinarily follow this list. Brian F. Feldman writes > I can't imagine a well-designed applications has kqueues of kqueues. I > didn't remove the file descriptor polling interface, I removed the file > descriptor kqueue interface. I took over a server to which I added a kqueue of kqueues. It used separate kqueues as priority queues, with controls on starvation. I found this essential for getting full performance out of the box. It was a caching web proxy running on a 1 GHz PIII, serving about 1,500 requests per second. That actually meant about 7,200 stimuli/second, including disk completion, TCP connects, TCP disconnects, TCP read data available, and TCP write buffer space available. It did its own async DNS, with caching. We often ran with 40,000 file descriptors open. After tuning of IP buffer space and connect queues, it withstood a 20 percent overload with graceful degradation, load shedding, and no lockup. Without multiple kqueues, this would have been far more difficult--or impossible. Roughly 70% of the processor was spent in the kernel, and measurements with different load mixes indicated the bulk of that was in the TCP stack. This means that the average service time at user level was about 40 usec. FreeBSD and recursive kqueue deserve a lot of the performance credit. I consider the server well-designed. When I was doing this, other developers at other companies were getting similar results from similar hardware, some of them using FreeBSD and kqueue. I have reason to believe that they were using similar priority schemes. I recommend allowing kqueues of kqueues. Mark Terribile __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ From owner-freebsd-arch@FreeBSD.ORG Sat May 15 02:21:19 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C87016A4CE; Sat, 15 May 2004 02:21:19 -0700 (PDT) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13E5D43D2F; Sat, 15 May 2004 02:21:18 -0700 (PDT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.9p2/8.12.9) with ESMTP id i4F9LF3F069170; Sat, 15 May 2004 13:21:15 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.9p2/8.12.9/Submit) id i4F9LF4J069169; Sat, 15 May 2004 13:21:15 +0400 (MSD) (envelope-from yar) Date: Sat, 15 May 2004 13:21:14 +0400 From: Yar Tikhiy To: arch@freebsd.org, hackers@freebsd.org Message-ID: <20040515092114.GB67531@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: Interoperation of flock(2), fcntl(2), and lockf(3) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2004 09:21:19 -0000 Hi folks, I've always been confused by the following sentence from the lockf(3) manpage: The lockf(), fcntl(2) and flock(2) locks may be safely used concurrently. Does that mean that each of those calls uses a locking mechanism of its own? Of course, in practice those calls use a mutual mechanism, thus allowing serial access to a file from applications using different calls. However, there's an oddity: While it's possible for a process to obtain the same lock several times w/o error (it's a no-op case of upgrading the lock,) intermixing flock(2) and fcntl(2), or flock(2) and lockf(3), within the same process results in EAGAIN upon the second locking attempt. That's while mixing fcntl(2) and lockf(3) is all right as long as the latter call is just a wrapper for the former one. Of course, intermixing different lock calls within one process is a poor idea at the first place, but I can imagine some mail application that tries to coax all the mailbox locking schemes at once. Considering all the above, I'd like to add the following paragraph to the flock(2), lockf(3), and fcntl(2) man pages (replacing the sentence quoted from lockf(3)): The flock(2), fcntl(2), and lockf(3) locks are compatible. Processes using different locking interfaces can cooperate over the same file safely. However, only one of such interfaces should be used within a process. If a file is locked by a process through flock(2), any record within the file will be seen as locked from the viewpoint of another process using fcntl(2) or lockf(3), and vice versa. Any objections or comments? -- Yar From owner-freebsd-arch@FreeBSD.ORG Sat May 15 04:00:16 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF22916A4CE; Sat, 15 May 2004 04:00:16 -0700 (PDT) Received: from huva.hittite.isp.9tel.net (huva.hittite.isp.9tel.net [62.62.156.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 414FC43D53; Sat, 15 May 2004 04:00:16 -0700 (PDT) (envelope-from clefevre-lists@9online.fr) Received: from pc2k (178-116-118-80.kaptech.net [80.118.116.178]) by huva.hittite.isp.9tel.net (Postfix) with SMTP id 83E8B9D971; Sat, 15 May 2004 13:01:38 +0200 (CEST) Message-ID: <042601c43a6b$cd1cb9a0$7890a8c0@dyndns.org> From: "Cyrille Lefevre" To: "Yar Tikhiy" , , References: <20040515092114.GB67531@comp.chem.msu.su> Date: Sat, 15 May 2004 13:00:13 +0200 Organization: ACME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: Re: Interoperation of flock(2), fcntl(2), and lockf(3) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2004 11:00:17 -0000 "Yar Tikhiy" wrote: [snip] > Considering all the above, I'd like to add the following paragraph > to the flock(2), lockf(3), and fcntl(2) man pages (replacing the > sentence quoted from lockf(3)): > > The flock(2), fcntl(2), and lockf(3) locks are compatible. > Processes using different locking interfaces can cooperate > over the same file safely. However, only one of such > interfaces should be used within a process. If a file is s/a process/the same process/ ? > locked by a process through flock(2), any record within the > file will be seen as locked from the viewpoint of another > process using fcntl(2) or lockf(3), and vice versa. Cyrille Lefevre. -- home: mailto:cyrille.lefevre@laposte.net From owner-freebsd-arch@FreeBSD.ORG Sat May 15 09:28:43 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0B1316A4CE for ; Sat, 15 May 2004 09:28:43 -0700 (PDT) Received: from beastie.mckusick.com (dsl081-247-227.sfo1.dsl.speakeasy.net [64.81.247.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id B93E843D1F for ; Sat, 15 May 2004 09:28:42 -0700 (PDT) (envelope-from mckusick@mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.8/8.12.9) with ESMTP id i4FGS7U9092172; Sat, 15 May 2004 09:28:10 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200405151628.i4FGS7U9092172@beastie.mckusick.com> To: Yar Tikhiy In-Reply-To: Your message of "Sat, 15 May 2004 13:21:14 +0400." <20040515092114.GB67531@comp.chem.msu.su> Date: Sat, 15 May 2004 09:28:07 -0700 From: Kirk McKusick cc: arch@freebsd.org Subject: Re: Interoperation of flock(2), fcntl(2), and lockf(3) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2004 16:28:43 -0000 As the author of the original sentence, I concur that your proposed change is an improvement. I suggest that you make it. Kirk McKusick =-=-=-=-=-= Date: Sat, 15 May 2004 13:21:14 +0400 From: Yar Tikhiy To: arch@freebsd.org, hackers@freebsd.org Subject: Interoperation of flock(2), fcntl(2), and lockf(3) Hi folks, I've always been confused by the following sentence from the lockf(3) manpage: The lockf(), fcntl(2) and flock(2) locks may be safely used concurrently. Does that mean that each of those calls uses a locking mechanism of its own? Of course, in practice those calls use a mutual mechanism, thus allowing serial access to a file from applications using different calls. However, there's an oddity: While it's possible for a process to obtain the same lock several times w/o error (it's a no-op case of upgrading the lock,) intermixing flock(2) and fcntl(2), or flock(2) and lockf(3), within the same process results in EAGAIN upon the second locking attempt. That's while mixing fcntl(2) and lockf(3) is all right as long as the latter call is just a wrapper for the former one. Of course, intermixing different lock calls within one process is a poor idea at the first place, but I can imagine some mail application that tries to coax all the mailbox locking schemes at once. Considering all the above, I'd like to add the following paragraph to the flock(2), lockf(3), and fcntl(2) man pages (replacing the sentence quoted from lockf(3)): The flock(2), fcntl(2), and lockf(3) locks are compatible. Processes using different locking interfaces can cooperate over the same file safely. However, only one of such interfaces should be used within a process. If a file is locked by a process through flock(2), any record within the file will be seen as locked from the viewpoint of another process using fcntl(2) or lockf(3), and vice versa. Any objections or comments? -- Yar _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Sat May 15 11:22:01 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F43116A4CE; Sat, 15 May 2004 11:22:01 -0700 (PDT) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36B9E43D45; Sat, 15 May 2004 11:22:00 -0700 (PDT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.9p2/8.12.9) with ESMTP id i4FILw3F092103; Sat, 15 May 2004 22:21:58 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.9p2/8.12.9/Submit) id i4FILvqB092102; Sat, 15 May 2004 22:21:57 +0400 (MSD) (envelope-from yar) Date: Sat, 15 May 2004 22:21:57 +0400 From: Yar Tikhiy To: arch@freebsd.org, net@freebsd.org Message-ID: <20040515182157.GB89625@comp.chem.msu.su> References: <20040508034514.GA937@grosbein.pp.ru> <20040508132354.GB44214@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040508132354.GB44214@comp.chem.msu.su> User-Agent: Mutt/1.5.6i cc: Eugene Grosbein Subject: Re: bin/65928: [PATCH] stock ftpd uses superuser credentials for active mode sockets X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2004 18:22:01 -0000 Hi folks, Attached below is a patch addressing the issue of the inability to reuse a local IP:port couple occupied by an established TCP connection from another user, but by no listeners. Could anybody with fair understanding of our TCP/IP stack review it please? Thanks. -- Yar Index: in_pcb.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in_pcb.c,v retrieving revision 1.146 diff -u -p -r1.146 in_pcb.c --- in_pcb.c 23 Apr 2004 23:29:49 -0000 1.146 +++ in_pcb.c 15 May 2004 17:37:18 -0000 @@ -340,6 +340,8 @@ in_pcbbind_setup(inp, nam, laddrp, lport return (EADDRINUSE); } else if (t && + (so->so_type != SOCK_STREAM || + ntohl(t->inp_faddr.s_addr) == INADDR_ANY) && (ntohl(sin->sin_addr.s_addr) != INADDR_ANY || ntohl(t->inp_laddr.s_addr) != INADDR_ANY || (t->inp_socket->so_options &