From owner-freebsd-arch@FreeBSD.ORG Sun Nov 20 13:40:26 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org 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 2846416A42B; Sun, 20 Nov 2005 13:40:26 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id C23F143D60; Sun, 20 Nov 2005 13:40:20 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring [10.0.0.2]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id jAKDe47l039404; Sun, 20 Nov 2005 13:40:04 GMT (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-arch@freebsd.org Date: Sun, 20 Nov 2005 13:40:02 +0000 User-Agent: KMail/1.8.2 References: <200511121042.42425.dfr@nlsystems.com> In-Reply-To: <200511121042.42425.dfr@nlsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511201340.02934.dfr@nlsystems.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (itchy.rabson.org [80.177.232.242]); Sun, 20 Nov 2005 13:40:08 +0000 (GMT) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on itchy.rabson.org X-Virus-Scanned: ClamAV 0.83/1180/Sun Nov 20 10:20:28 2005 on itchy.rabson.org X-Virus-Status: Clean Cc: arch@freebsd.org, Love =?iso-8859-1?q?H=F6rnquist_=C5strand?= Subject: Re: New extensible GSSAPI implementation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2005 13:40:26 -0000 On Saturday 12 November 2005 10:42, Doug Rabson wrote: > The patch is too large to post here but you can find it at > http://people.freebsd.org/~dfr/gss-12112005.diff. It has survived > limited buildworld testing on one architecture and limited testing on > a newly install FreeBSD-current machine. I have not attempted to > build any GSS-API using ports and I expect there to be problems in > that area due to the moved header file and changed linking > requirements. > > Any comments, feedback, patches welcome... I've put up a new iteration of the patch at http://people.freebsd.org/~dfr/gss-20112005.diff which fixes a number of problems with the manpages and some issues that showed up while testing with ssh/sshd. It also adds an implementation of gss_add_cred which I managed to miss out before. From owner-freebsd-arch@FreeBSD.ORG Sun Nov 20 13:40:26 2005 Return-Path: X-Original-To: arch@freebsd.org 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 2846416A42B; Sun, 20 Nov 2005 13:40:26 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id C23F143D60; Sun, 20 Nov 2005 13:40:20 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring [10.0.0.2]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id jAKDe47l039404; Sun, 20 Nov 2005 13:40:04 GMT (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-arch@freebsd.org Date: Sun, 20 Nov 2005 13:40:02 +0000 User-Agent: KMail/1.8.2 References: <200511121042.42425.dfr@nlsystems.com> In-Reply-To: <200511121042.42425.dfr@nlsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511201340.02934.dfr@nlsystems.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (itchy.rabson.org [80.177.232.242]); Sun, 20 Nov 2005 13:40:08 +0000 (GMT) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on itchy.rabson.org X-Virus-Scanned: ClamAV 0.83/1180/Sun Nov 20 10:20:28 2005 on itchy.rabson.org X-Virus-Status: Clean Cc: arch@freebsd.org, Love =?iso-8859-1?q?H=F6rnquist_=C5strand?= Subject: Re: New extensible GSSAPI implementation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2005 13:40:27 -0000 On Saturday 12 November 2005 10:42, Doug Rabson wrote: > The patch is too large to post here but you can find it at > http://people.freebsd.org/~dfr/gss-12112005.diff. It has survived > limited buildworld testing on one architecture and limited testing on > a newly install FreeBSD-current machine. I have not attempted to > build any GSS-API using ports and I expect there to be problems in > that area due to the moved header file and changed linking > requirements. > > Any comments, feedback, patches welcome... I've put up a new iteration of the patch at http://people.freebsd.org/~dfr/gss-20112005.diff which fixes a number of problems with the manpages and some issues that showed up while testing with ssh/sshd. It also adds an implementation of gss_add_cred which I managed to miss out before. From owner-freebsd-arch@FreeBSD.ORG Mon Nov 21 18:04:02 2005 Return-Path: X-Original-To: arch@freebsd.org 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 6802816A420 for ; Mon, 21 Nov 2005 18:04:02 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC0FC43D49 for ; Mon, 21 Nov 2005 18:03:59 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jALI3uJO021468; Mon, 21 Nov 2005 11:03:56 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43820C0C.6000001@samsco.org> Date: Mon, 21 Nov 2005 11:03:56 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Damien Bergamini References: <20051119165547.0A4BD16A43D@hub.freebsd.org> <00ca01c5ed4a$86b0e570$0300a8c0@COMETE> <20051119.144210.122123926.imp@bsdimp.com> <200511211015.27879.jhb@freebsd.org> <8664qmja7y.fsf@xps.des.no> <4381F060.5040107@samsco.org> <4381FEDF.7080607@root.org> <00ff01c5eec3$3b0e6640$0300a8c0@COMETE> In-Reply-To: <00ff01c5eec3$3b0e6640$0300a8c0@COMETE> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: arch@freebsd.org, Nate Lawson Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 18:04:02 -0000 Damien Bergamini wrote: > I don't like the idea of keeping the firmware in kernel memory. > It's a rather big file (~200KB). > And there is one for each operating mode (BSS, IBSS, monitor). > > The second reason why I don't like KLDs is because they require > user intervention and users must know which KLD to load for the > mode they want to operate in. And if you put all firmwares in > the same KLD, you end up with a big fat 1MB file. > The isp driver knows how to unload the ispfw module after it's done with it, so it doesn't stay resident in memory. > I won't go back to anything based on iwicontrol. People simply > don't know how to use it. Trust me. There is not a single day > where I don't get email from people complaining about it. I would be nice to have a single interface for loading data into the kernel from within the kernel, but there are complicating factors. On one side you have storage drivers like isp that need firmware in order to run (yeah, the isp hardware does have a basic firmware load, but it's pretty much useless), therefore you can't wait until the filesystem is available. On the other side you have devices that need to load fairly arbitrary data files, but only after boot. Loading files into the kernel manually has all sorts of problems. VFS is very hard to work with in its 'raw' API form because just about every operation has locking side effects that are hard to predict. A vput() call might simply lower the refcount on a vnode, or it might wind up calling VOP_INACTIVE and going into the bufcache. It's hard to handle this correctly, and it's it's not something that should be duplicated all over the kernel. I know that Windows and Linux have kernel APIs for reading files, but it's simply not a good idea to do it. Also, putting hardcoded paths into the driver is very unmaintainable. I guess my vote would be to have a devd mechanism where the kernel can ask for a module via a particular key, devd maps the key to a file via its config file and loads it into kernel space as a KLD, and then the kernel unloads the KLD when its done with it. For things like isp, nothing would change, and for iwi you'd get a reliable way of getting bits into the kernel that doesn't require messing with the VFS layer or hard-coding knowledge of the filesystem layout into the driver. Scott > > Damien > > | > Or have the firmware be embedded in a KLD, like ispfw. > | > | I think I've now been repeated by everyone in the conversation. :) > | > | So maybe it's time to solve this? Move discussion to arch@? > | > | -- > | Nate > From owner-freebsd-arch@FreeBSD.ORG Mon Nov 21 18:21:02 2005 Return-Path: X-Original-To: arch@freebsd.org 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 D610E16A41F for ; Mon, 21 Nov 2005 18:21:02 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A69843D76 for ; Mon, 21 Nov 2005 18:20:36 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jALIJtsS044178; Mon, 21 Nov 2005 11:19:55 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 21 Nov 2005 11:19:55 -0700 (MST) Message-Id: <20051121.111955.74713410.imp@bsdimp.com> To: nate@root.org From: Warner Losh In-Reply-To: <4381FEDF.7080607@root.org> References: <8664qmja7y.fsf@xps.des.no> <4381F060.5040107@samsco.org> <4381FEDF.7080607@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=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 21 Nov 2005 11:19:55 -0700 (MST) Cc: arch@freebsd.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 18:21:03 -0000 jhb>John Baldwin jhb> The easiest way to accomplish this is for your driver to send a jhb> message to devd requesting that the firmware be reloaded on jhb> resume since devd won't run until the kernel is fully back up. des>Dag-Erling Sm=F8rgrav des> ...or keep the firmware image in memory after loading it the first= des> time around. scottl>Scott Long scottl> Or have the firmware be embedded in a KLD, like ispfw. nate>Nate Lawson nate> I think I've now been repeated by everyone in the conversation. = :) Only those people that think it is a good idea have repeated it. nate> So maybe it's time to solve this? Move discussion to arch@? I don't like the kld option. People have been talking about doing this since about 4.2 and nothing has happened to make it generic. The good things about it are that the driver can request that modules be loaded and unloaded. Once loaded, the driver can go directly to a binary representation of the firmware. These are both good points. The bad points about this is that you have to generate the firmware kld module. This will require a per-driver program to parse the firmware and some design to place the data into data structures that the driver can use to bang the data into the card. It would mean creating two copies of the firmware because most people will install the new firmware, then run this program and install the new kld (maybe the kld generation program would run each installkernel, since you never know what it depends on and when that might change). Also, you have the potential for version skew between the kld and the firmware. There's one more level of indirection that you need to worry about when you go the kld route. The firmware parsing code tends to be relatively simple and may need access to multiple files, as well as the actual hardware. The wi firmware loader, for example, needs to patch certain values from the card into the wi images before they will work (the current hand-tweaked symbol CF card has had these re-applied). To solve the race with "/", one could easily just queue the driver loading to a taskqueue. I don't think that the taskqueues aren't running until after the resume process is complete. Even if they are, and you block waiting for / to come back, it wouldn't be the resume path that's blocking. One could also use devd for this, but if the driver already knows how to loads its firmware, that seems like an overly complicated solution. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Nov 21 18:25:59 2005 Return-Path: X-Original-To: arch@freebsd.org 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 7C20A16A41F for ; Mon, 21 Nov 2005 18:25:59 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11D8D43D6D for ; Mon, 21 Nov 2005 18:25:58 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jALIPu8U021631; Mon, 21 Nov 2005 11:25:56 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43821134.6040306@samsco.org> Date: Mon, 21 Nov 2005 11:25:56 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Warner Losh References: <8664qmja7y.fsf@xps.des.no> <4381F060.5040107@samsco.org> <4381FEDF.7080607@root.org> <20051121.111955.74713410.imp@bsdimp.com> In-Reply-To: <20051121.111955.74713410.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: arch@freebsd.org, nate@root.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 18:25:59 -0000 Warner Losh wrote: > jhb>John Baldwin > jhb> The easiest way to accomplish this is for your driver to send a > jhb> message to devd requesting that the firmware be reloaded on > jhb> resume since devd won't run until the kernel is fully back up. > > des>Dag-Erling Smørgrav > des> ...or keep the firmware image in memory after loading it the first > des> time around. > > scottl>Scott Long > scottl> Or have the firmware be embedded in a KLD, like ispfw. > > nate>Nate Lawson > nate> I think I've now been repeated by everyone in the conversation. :) > > Only those people that think it is a good idea have repeated it. > > nate> So maybe it's time to solve this? Move discussion to arch@? > > I don't like the kld option. People have been talking about doing > this since about 4.2 and nothing has happened to make it generic. > > The good things about it are that the driver can request that modules > be loaded and unloaded. Once loaded, the driver can go directly to a > binary representation of the firmware. These are both good points. > > The bad points about this is that you have to generate the firmware > kld module. This will require a per-driver program to parse the > firmware and some design to place the data into data structures that > the driver can use to bang the data into the card. It would mean > creating two copies of the firmware because most people will install > the new firmware, then run this program and install the new kld (maybe > the kld generation program would run each installkernel, since you > never know what it depends on and when that might change). Also, you > have the potential for version skew between the kld and the firmware. > There's one more level of indirection that you need to worry about > when you go the kld route. > > The firmware parsing code tends to be relatively simple and may need > access to multiple files, as well as the actual hardware. The wi > firmware loader, for example, needs to patch certain values from the > card into the wi images before they will work (the current > hand-tweaked symbol CF card has had these re-applied). > > To solve the race with "/", one could easily just queue the driver > loading to a taskqueue. I don't think that the taskqueues aren't > running until after the resume process is complete. Even if they are, > and you block waiting for / to come back, it wouldn't be the resume > path that's blocking. One could also use devd for this, but if the > driver already knows how to loads its firmware, that seems like an > overly complicated solution. > > Warner Making the driver aware of the filesystem layout is a bad idea. Encapsulating data into a KLD is not hard to do. Scott From owner-freebsd-arch@FreeBSD.ORG Mon Nov 21 18:30:13 2005 Return-Path: X-Original-To: arch@FreeBSD.ORG 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 8D9F616A420 for ; Mon, 21 Nov 2005 18:30:13 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id E11FD43D4C for ; Mon, 21 Nov 2005 18:30:12 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jALIRO9v044301; Mon, 21 Nov 2005 11:27:24 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 21 Nov 2005 11:27:24 -0700 (MST) Message-Id: <20051121.112724.41676073.imp@bsdimp.com> To: scottl@samsco.org From: Warner Losh In-Reply-To: <43820C0C.6000001@samsco.org> References: <4381FEDF.7080607@root.org> <00ff01c5eec3$3b0e6640$0300a8c0@COMETE> <43820C0C.6000001@samsco.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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 21 Nov 2005 11:27:24 -0700 (MST) Cc: arch@FreeBSD.ORG, damien.bergamini@free.fr, nate@root.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 18:30:13 -0000 scottl> Scott Long scottl> I guess my vote would be to have a devd mechanism where the kernel scottl> can ask for a module via a particular key, devd maps the key to a file scottl> via its config file and loads it into kernel space as a KLD, and then scottl> the kernel unloads the KLD when its done with it. For things like isp, scottl> nothing would change, and for iwi you'd get a reliable way of getting scottl> bits into the kernel that doesn't require messing with the VFS layer scottl> or hard-coding knowledge of the filesystem layout into the driver. Apart from my other objections to kld, I really don't like getting devd involved in this. devd is a passive listener. It listens for events and then runs programs. It is not there to interact with the kernel in synchronous manner. Everything is queued and there's deliberately no meachanism for a reply. There's also no reason to have a third party involved to load the module. None of the other automatic kldload parts of the kernel need this. Why is driver firmware any different? You can easily define the interface to be load module "$driver-fw-$type" and the driver can take care of the sprintf to fill in the string. A carefully chosen interface here can help eliminate the extra layers of complexity. How the heck would devd know how to convert the particular key into something meaningful? How would concentrating the quirks of all possible drivers in devd be better than localizing them in the driver itself? Warner From owner-freebsd-arch@FreeBSD.ORG Mon Nov 21 18:33:05 2005 Return-Path: X-Original-To: arch@freebsd.org 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 6D28216A420 for ; Mon, 21 Nov 2005 18:33:05 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05E8243D49 for ; Mon, 21 Nov 2005 18:33:03 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jALIUqrI044333; Mon, 21 Nov 2005 11:30:52 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 21 Nov 2005 11:30:52 -0700 (MST) Message-Id: <20051121.113052.71133065.imp@bsdimp.com> To: scottl@samsco.org From: Warner Losh In-Reply-To: <43821134.6040306@samsco.org> References: <4381FEDF.7080607@root.org> <20051121.111955.74713410.imp@bsdimp.com> <43821134.6040306@samsco.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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 21 Nov 2005 11:30:52 -0700 (MST) Cc: arch@freebsd.org, nate@root.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 18:33:05 -0000 > Making the driver aware of the filesystem layout is a bad idea. Your opinion has been noted. Repeating it often isn't going to help. It has its advantages from the user point of view (I put a file here and it is used, my tool of choice can always be "cp"). > Encapsulating data into a KLD is not hard to do. Neither is a dozen other things that we do automatically for the user. From a user point of view this is a pita. I put this file here, and then I have to remember which magic tool to run to convert the iwi firmware into a kld. But that's a different tool from the wi driver and that's different from the iwp driver, etc. Each approach has its pro's and con's. Getting dogmatic about 'X is a bad idea, therefor you must do Y' without looking at why 'Y' might be a worse alternative to 'X' isn't going to help this discussion. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Nov 21 18:39:42 2005 Return-Path: X-Original-To: arch@FreeBSD.ORG 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 A5B6016A41F for ; Mon, 21 Nov 2005 18:39:42 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2BDC43D4C for ; Mon, 21 Nov 2005 18:39:41 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jALIdcOu021737; Mon, 21 Nov 2005 11:39:38 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4382146A.9000006@samsco.org> Date: Mon, 21 Nov 2005 11:39:38 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Warner Losh References: <4381FEDF.7080607@root.org> <00ff01c5eec3$3b0e6640$0300a8c0@COMETE> <43820C0C.6000001@samsco.org> <20051121.112724.41676073.imp@bsdimp.com> In-Reply-To: <20051121.112724.41676073.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: arch@FreeBSD.ORG, damien.bergamini@free.fr, nate@root.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 18:39:42 -0000 Warner Losh wrote: > scottl> Scott Long > scottl> I guess my vote would be to have a devd mechanism where the kernel > scottl> can ask for a module via a particular key, devd maps the key to a file > scottl> via its config file and loads it into kernel space as a KLD, and then > scottl> the kernel unloads the KLD when its done with it. For things like isp, > scottl> nothing would change, and for iwi you'd get a reliable way of getting > scottl> bits into the kernel that doesn't require messing with the VFS layer > scottl> or hard-coding knowledge of the filesystem layout into the driver. > > Apart from my other objections to kld, I really don't like getting > devd involved in this. devd is a passive listener. yes, it passively listens to requests for firmware. > It listens for > events and then runs programs. Excellent! Exactly that is needed! > It is not there to interact with the > kernel in synchronous manner. Everything is queued and there's > deliberately no meachanism for a reply. > > There's also no reason to have a third party involved to load the > module. Maybe you want a program that can on-the-fly patch the wi firmware? > None of the other automatic kldload parts of the kernel need > this. Why is driver firmware any different? Why hack the kernel module loader? > You can easily define > the interface to be load module "$driver-fw-$type" and the driver can > take care of the sprintf to fill in the string. A carefully chosen > interface here can help eliminate the extra layers of complexity. How > the heck would devd know how to convert the particular key into > something meaningful? Maybe via some sort of configuration file? I thought that devd had one of those. Guess I'm wrong? > How would concentrating the quirks of all > possible drivers in devd be better than localizing them in the driver > itself? Why put a lot of complexity into a program that corrupts your data when it has a bug? Scott From owner-freebsd-arch@FreeBSD.ORG Mon Nov 21 18:41:31 2005 Return-Path: X-Original-To: arch@freebsd.org 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 3A26516A41F for ; Mon, 21 Nov 2005 18:41:31 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 891D643D46 for ; Mon, 21 Nov 2005 18:41:30 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jALIfStG021762; Mon, 21 Nov 2005 11:41:28 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <438214D8.1000203@samsco.org> Date: Mon, 21 Nov 2005 11:41:28 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Warner Losh References: <4381FEDF.7080607@root.org> <20051121.111955.74713410.imp@bsdimp.com> <43821134.6040306@samsco.org> <20051121.113052.71133065.imp@bsdimp.com> In-Reply-To: <20051121.113052.71133065.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: arch@freebsd.org, nate@root.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 18:41:31 -0000 Warner Losh wrote: >>Making the driver aware of the filesystem layout is a bad idea. > > > Your opinion has been noted. Repeating it often isn't going to help. > It has its advantages from the user point of view (I put a file here > and it is used, my tool of choice can always be "cp"). > > >>Encapsulating data into a KLD is not hard to do. > > > Neither is a dozen other things that we do automatically for the > user. From a user point of view this is a pita. I put this file > here, and then I have to remember which magic tool to run to convert > the iwi firmware into a kld. But that's a different tool from the wi > driver and that's different from the iwp driver, etc. > > Each approach has its pro's and con's. Getting dogmatic about 'X is a > bad idea, therefor you must do Y' without looking at why 'Y' might be > a worse alternative to 'X' isn't going to help this discussion. > > Warner Lack of useful content noted. Thanks. Scott From owner-freebsd-arch@FreeBSD.ORG Mon Nov 21 18:44:47 2005 Return-Path: X-Original-To: arch@freebsd.org 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 4069116A41F for ; Mon, 21 Nov 2005 18:44:47 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5B7E43D45 for ; Mon, 21 Nov 2005 18:44:46 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id jALIibWL028804; Mon, 21 Nov 2005 13:44:37 -0500 (EST) Date: Mon, 21 Nov 2005 13:44:37 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Warner Losh In-Reply-To: <20051121.113052.71133065.imp@bsdimp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: arch@freebsd.org, nate@root.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 18:44:47 -0000 On Mon, 21 Nov 2005, Warner Losh wrote: > > Making the driver aware of the filesystem layout is a bad idea. > > Your opinion has been noted. Repeating it often isn't going to help. > It has its advantages from the user point of view (I put a file here > and it is used, my tool of choice can always be "cp"). > > > Encapsulating data into a KLD is not hard to do. > > Neither is a dozen other things that we do automatically for the > user. From a user point of view this is a pita. I put this file > here, and then I have to remember which magic tool to run to convert > the iwi firmware into a kld. But that's a different tool from the wi > driver and that's different from the iwp driver, etc. Not taking one side or the other... Can we use a common tool to convert firmware to a kld? Just pass it the symbol name or whatever else you need? I guess this makes the assumption that most firmware consists of just one object file. -- DE From owner-freebsd-arch@FreeBSD.ORG Mon Nov 21 18:50:37 2005 Return-Path: X-Original-To: arch@freebsd.org 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 0BBBD16A41F for ; Mon, 21 Nov 2005 18:50:37 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89C0843D4C for ; Mon, 21 Nov 2005 18:50:36 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jALIlabN044531; Mon, 21 Nov 2005 11:47:36 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 21 Nov 2005 11:47:36 -0700 (MST) Message-Id: <20051121.114736.74706734.imp@bsdimp.com> To: scottl@samsco.org From: Warner Losh In-Reply-To: <438214D8.1000203@samsco.org> References: <43821134.6040306@samsco.org> <20051121.113052.71133065.imp@bsdimp.com> <438214D8.1000203@samsco.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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 21 Nov 2005 11:47:36 -0700 (MST) Cc: arch@freebsd.org, nate@root.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 18:50:37 -0000 > Lack of useful content noted. Thanks. Thank you for your opinion. It has been noted. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Nov 21 18:54:11 2005 Return-Path: X-Original-To: arch@freebsd.org 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 A9CE816A41F for ; Mon, 21 Nov 2005 18:54:11 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 230BB43D45 for ; Mon, 21 Nov 2005 18:54:11 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jALIqbDJ044556; Mon, 21 Nov 2005 11:52:37 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 21 Nov 2005 11:52:37 -0700 (MST) Message-Id: <20051121.115237.41677576.imp@bsdimp.com> To: scottl@samsco.org From: Warner Losh In-Reply-To: <4382146A.9000006@samsco.org> References: <43820C0C.6000001@samsco.org> <20051121.112724.41676073.imp@bsdimp.com> <4382146A.9000006@samsco.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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 21 Nov 2005 11:52:38 -0700 (MST) Cc: arch@freebsd.org, damien.bergamini@free.fr, nate@root.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 18:54:11 -0000 > > None of the other automatic kldload parts of the kernel need > > this. Why is driver firmware any different? > > Why hack the kernel module loader? No need to hack the kernel loader. It already will load a kloader of a given name. Driver says load iwi-firmware-ibss and away you go. That's all I'm saying. Why make things more complicated than necessary? Anyway, your tone has totally pissed me off. Was that really necessary? Warner From owner-freebsd-arch@FreeBSD.ORG Mon Nov 21 19:19:03 2005 Return-Path: X-Original-To: arch@FreeBSD.ORG 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 0261B16A42A for ; Mon, 21 Nov 2005 19:19:02 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms046pub.verizon.net (vms046pub.verizon.net [206.46.252.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F7AF43DBB for ; Mon, 21 Nov 2005 19:18:27 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms068.mailsrvcs.net ([192.168.1.1]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IQB00GDQK995231@vms046.mailsrvcs.net> for arch@FreeBSD.ORG; Mon, 21 Nov 2005 13:17:33 -0600 (CST) Date: Mon, 21 Nov 2005 13:17:33 -0600 (CST) From: Sergey Babkin To: Warner Losh , scottl@samsco.org Message-id: <23495346.1132600653230.JavaMail.root@vms068.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: arch@FreeBSD.ORG, damien.bergamini@free.fr, nate@root.org Subject: Re: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwi X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: babkin@users.sf.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 19:19:03 -0000 >From: Warner Losh >scottl> Scott Long >scottl> I guess my vote would be to have a devd mechanism where the kernel >scottl> can ask for a module via a particular key, devd maps the key to a file >scottl> via its config file and loads it into kernel space as a KLD, and then >scottl> the kernel unloads the KLD when its done with it. For things like isp, >scottl> nothing would change, and for iwi you'd get a reliable way of getting >scottl> bits into the kernel that doesn't require messing with the VFS layer >scottl> or hard-coding knowledge of the filesystem layout into the driver. > >Apart from my other objections to kld, I really don't like getting >devd involved in this. devd is a passive listener. It listens for >events and then runs programs. It is not there to interact with the >kernel in synchronous manner. Everything is queued and there's >deliberately no meachanism for a reply. A rather stupid question: Why not just make the loader able to load an arbitrary file? Through a separate call, obviously. It's the same thing, only with the linking stage skipped, and calling a pointer received as an argument of the call instead of the module's load routine. Then the drivers couls just get the path from sysconf and happily load whatever files they need. -SB From owner-freebsd-arch@FreeBSD.ORG Mon Nov 21 19:22:46 2005 Return-Path: X-Original-To: arch@FreeBSD.ORG 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 A04A516A41F for ; Mon, 21 Nov 2005 19:22:46 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49DC943D78 for ; Mon, 21 Nov 2005 19:21:44 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jALJLYnM021995; Mon, 21 Nov 2005 12:21:34 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43821E3E.3000106@samsco.org> Date: Mon, 21 Nov 2005 12:21:34 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: babkin@users.sourceforge.net References: <23495346.1132600653230.JavaMail.root@vms068.mailsrvcs.net> In-Reply-To: <23495346.1132600653230.JavaMail.root@vms068.mailsrvcs.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: arch@FreeBSD.ORG, damien.bergamini@free.fr, nate@root.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwi X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 19:22:46 -0000 Sergey Babkin wrote: >>From: Warner Losh > > >>scottl> Scott Long >>scottl> I guess my vote would be to have a devd mechanism where the kernel >>scottl> can ask for a module via a particular key, devd maps the key to a file >>scottl> via its config file and loads it into kernel space as a KLD, and then >>scottl> the kernel unloads the KLD when its done with it. For things like isp, >>scottl> nothing would change, and for iwi you'd get a reliable way of getting >>scottl> bits into the kernel that doesn't require messing with the VFS layer >>scottl> or hard-coding knowledge of the filesystem layout into the driver. >> >>Apart from my other objections to kld, I really don't like getting >>devd involved in this. devd is a passive listener. It listens for >>events and then runs programs. It is not there to interact with the >>kernel in synchronous manner. Everything is queued and there's >>deliberately no meachanism for a reply. > > > A rather stupid question: > Why not just make the loader able to load an arbitrary > file? Through a separate call, obviously. > It's the same thing, only with the linking stage > skipped, and calling a pointer received as an > argument of the call instead of the module's load > routine. Then the drivers couls just get the path from > sysconf and happily load whatever files they need. > > -SB The loader can, that's how the mfsroot.gz file gets loaded during install. Scott From owner-freebsd-arch@FreeBSD.ORG Mon Nov 21 19:41:46 2005 Return-Path: X-Original-To: arch@freebsd.org 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 192DA16A41F; Mon, 21 Nov 2005 19:41:46 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id A13EE43D78; Mon, 21 Nov 2005 19:41:45 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jALJdnaA045219; Mon, 21 Nov 2005 12:39:49 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 21 Nov 2005 12:39:48 -0700 (MST) Message-Id: <20051121.123948.39201087.imp@bsdimp.com> To: deischen@freebsd.org From: Warner Losh In-Reply-To: References: <20051121.113052.71133065.imp@bsdimp.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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 21 Nov 2005 12:39:49 -0700 (MST) Cc: arch@freebsd.org, nate@root.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 19:41:46 -0000 > Not taking one side or the other... Can we use a common > tool to convert firmware to a kld? Just pass it the > symbol name or whatever else you need? The answer is 'it depends'... > I guess this makes the assumption that most firmware consists > of just one object file. The object files vary somewhat as to what is in the file. Some are S records in text format, while otherrs are COFF or some other format in binary form. I had assumed that each driver would want to parse things out into a useful form in the conversion program to keep the kernel portion as small as possible. This is inharently driver dependent. However, if we wanted to have a raw bits into the kernel conduit, then we could have a tool, so long as it handled an arbitrary number of files. Many drivers have a 'primary' and a 'secondary' firmware to load. But presenting an array to the driver, or having the driver load multiple files is a way around this. Having the kernel loader be able to load arbitrary files would be even better... Warner From owner-freebsd-arch@FreeBSD.ORG Mon Nov 21 19:45:25 2005 Return-Path: X-Original-To: arch@freebsd.org 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 4498716A41F for ; Mon, 21 Nov 2005 19:45:25 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF88C43D5D for ; Mon, 21 Nov 2005 19:45:21 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jALJiEQf045255; Mon, 21 Nov 2005 12:44:14 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 21 Nov 2005 12:44:13 -0700 (MST) Message-Id: <20051121.124413.59698313.imp@bsdimp.com> To: scottl@samsco.org From: Warner Losh In-Reply-To: <43821E3E.3000106@samsco.org> References: <23495346.1132600653230.JavaMail.root@vms068.mailsrvcs.net> <43821E3E.3000106@samsco.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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 21 Nov 2005 12:44:14 -0700 (MST) Cc: arch@freebsd.org, babkin@users.sourceforge.net, damien.bergamini@free.fr, nate@root.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwi X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 19:45:25 -0000 > The loader can, that's how the mfsroot.gz file gets loaded > during install. /boot/loader can do this certainly. And you can lookup a file based on its name from the in-kernel loader. However, there doesn't appear to be a linker class that can load arbitrary files. The in-kernel linker can only lookup things loaded at boot time. I think that creating a link_file might be a good alternative to having drivers do vfs operations directly. The kernel would load it safely and hand a reference to the file to the driver. The driver can then frob it into the hardware and unload the module. The problem would be that you'd want to make sure that the elf loader got a chance to reject the module before the arbitrary file loader, or you'd need to make the arbitrary file loader not load elf. We may be able to 'widen' the interface to drivers a bit by exposing linker_load_file to the outside world. We could then have the arbitrary file loader 'fail' the LINKER_LOOKUP_SET method fail so that linker_load_module would still give the current behavior. That might be better than a priority scheme, and would answer my main objection to kld modules... Warner From owner-freebsd-arch@FreeBSD.ORG Mon Nov 21 23:45:26 2005 Return-Path: X-Original-To: arch@freebsd.org 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 564B416A442 for ; Mon, 21 Nov 2005 23:45:26 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 295D043D45 for ; Mon, 21 Nov 2005 23:45:09 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from verizon.net ([141.153.249.163]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IQB00M5MWN14UO2@vms044.mailsrvcs.net> for arch@freebsd.org; Mon, 21 Nov 2005 17:45:05 -0600 (CST) Date: Mon, 21 Nov 2005 18:45:01 -0500 From: Sergey Babkin Sender: root To: Warner Losh Message-id: <43825BFD.70B5E055@verizon.net> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.7-RELEASE i386) Content-type: text/plain; charset=koi8-r Content-transfer-encoding: 7bit X-Accept-Language: en, ru References: <23495346.1132600653230.JavaMail.root@vms068.mailsrvcs.net> <43821E3E.3000106@samsco.org> <20051121.124413.59698313.imp@bsdimp.com> Cc: damien.bergamini@free.fr, arch@freebsd.org, babkin@users.sourceforge.net, nate@root.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.cif_iwi X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: babkin@users.sf.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 23:45:26 -0000 Warner Losh wrote: > > > The loader can, that's how the mfsroot.gz file gets loaded > > during install. > > /boot/loader can do this certainly. And you can lookup a file based > on its name from the in-kernel loader. > > However, there doesn't appear to be a linker class that can load > arbitrary files. The in-kernel linker can only lookup things loaded > at boot time. > > I think that creating a link_file might be a good alternative to > having drivers do vfs operations directly. The kernel would load it > safely and hand a reference to the file to the driver. The driver can > then frob it into the hardware and unload the module. I didn't get the e-mails in between yet, so maybe this has been already mentioned, but I'd also have the offset in the file and maximal length to read as arguments. This would allow the drivers to read large files by loading a reasonably small portion at a time. -SB From owner-freebsd-arch@FreeBSD.ORG Tue Nov 22 00:53:52 2005 Return-Path: X-Original-To: arch@freebsd.org 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 53EC816A41F for ; Tue, 22 Nov 2005 00:53:52 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9C5143D45 for ; Tue, 22 Nov 2005 00:53:51 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jAM0qxkd048361; Mon, 21 Nov 2005 17:52:59 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 21 Nov 2005 17:53:15 -0700 (MST) Message-Id: <20051121.175315.56348077.imp@bsdimp.com> To: babkin@users.sourceforge.net, babkin@verizon.net From: "M. Warner Losh" In-Reply-To: <43825BFD.70B5E055@verizon.net> References: <43821E3E.3000106@samsco.org> <20051121.124413.59698313.imp@bsdimp.com> <43825BFD.70B5E055@verizon.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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 21 Nov 2005 17:52:59 -0700 (MST) Cc: arch@freebsd.org, damien.bergamini@free.fr, nate@root.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.cif_iwi X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2005 00:53:52 -0000 In message: <43825BFD.70B5E055@verizon.net> Sergey Babkin writes: : Warner Losh wrote: : > : > > The loader can, that's how the mfsroot.gz file gets loaded : > > during install. : > : > /boot/loader can do this certainly. And you can lookup a file based : > on its name from the in-kernel loader. : > : > However, there doesn't appear to be a linker class that can load : > arbitrary files. The in-kernel linker can only lookup things loaded : > at boot time. : > : > I think that creating a link_file might be a good alternative to : > having drivers do vfs operations directly. The kernel would load it : > safely and hand a reference to the file to the driver. The driver can : > then frob it into the hardware and unload the module. : : I didn't get the e-mails in between yet, so maybe this has been : already mentioned, but I'd also have the offset in the file and : maximal length to read as arguments. This would allow the drivers : to read large files by loading a reasonably small portion at a time. That might be an interesting optimization. I'm not sure that it would necessarily be all that useful. The firmware images currently are in the 32-256k range each. The ispfw driver is only 450k total (and has several firmware images, iirc). While it is desirable to be able to use this extra memory all the time, this isn't so much memory that we couldn't allocate and free it as needed. The only gotcha would be to make sure that our linker doesn't suffer address space leakage because these files would be mapped and unmapped a lot more often than a normal module. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Nov 23 06:23:06 2005 Return-Path: X-Original-To: arch@freebsd.org 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 04BFF16A41F for ; Wed, 23 Nov 2005 06:23:06 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from gate.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E71643D64 for ; Wed, 23 Nov 2005 06:23:05 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by gate.bitblocks.com (8.13.4/8.13.1) with ESMTP id jAN6MtZ9094323; Tue, 22 Nov 2005 22:22:55 -0800 (PST) (envelope-from bakul@bitblocks.com) Message-Id: <200511230622.jAN6MtZ9094323@gate.bitblocks.com> To: "M. Warner Losh" In-reply-to: Your message of "Mon, 21 Nov 2005 17:53:15 MST." <20051121.175315.56348077.imp@bsdimp.com> Date: Tue, 22 Nov 2005 22:22:55 -0800 From: Bakul Shah Cc: arch@freebsd.org, babkin@users.sourceforge.net, babkin@verizon.net, damien.bergamini@free.fr, nate@root.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.cif_iwi X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2005 06:23:06 -0000 Right now suspend/resume is broken due to the iwi driver loading firmware. While you guys hash this out would it be possible to put in an interim simple fix? I can live with 200KB+ bloat while you guys hash out a more comple{x,ete} fix! As it is I kldload as much as possible so as to run the same static image on all machines so overall I still don't use up as much space as GENERIC. Thanks! From owner-freebsd-arch@FreeBSD.ORG Wed Nov 23 06:57:54 2005 Return-Path: X-Original-To: arch@freebsd.org 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 B2F5416A420 for ; Wed, 23 Nov 2005 06:57:54 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EA3743D49 for ; Wed, 23 Nov 2005 06:57:53 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jAN6vq9Z033777; Tue, 22 Nov 2005 23:57:52 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <438412F0.8040901@samsco.org> Date: Tue, 22 Nov 2005 23:57:52 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bakul Shah References: <200511230622.jAN6MtZ9094323@gate.bitblocks.com> In-Reply-To: <200511230622.jAN6MtZ9094323@gate.bitblocks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: babkin@verizon.net, damien.bergamini@free.fr, arch@freebsd.org, babkin@users.sourceforge.net, nate@root.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.cif_iwi X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2005 06:57:54 -0000 Bakul Shah wrote: > Right now suspend/resume is broken due to the iwi driver > loading firmware. While you guys hash this out would it be > possible to put in an interim simple fix? I can live with > 200KB+ bloat while you guys hash out a more comple{x,ete} > fix! As it is I kldload as much as possible so as to run > the same static image on all machines so overall I still > don't use up as much space as GENERIC. > > Thanks! Does the NDIS driver support suspend/resume better on this hardware? If so then I'd suggest using it for now (I use it for my iwi hardware). Scott From owner-freebsd-arch@FreeBSD.ORG Wed Nov 23 17:12:37 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org 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 27FD516A41F for ; Wed, 23 Nov 2005 17:12:37 +0000 (GMT) (envelope-from damien.bergamini@free.fr) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB7BB43D55 for ; Wed, 23 Nov 2005 17:12:33 +0000 (GMT) (envelope-from damien.bergamini@free.fr) Received: from COMETE (pas38-1-82-67-68-158.fbx.proxad.net [82.67.68.158]) by smtp5-g19.free.fr (Postfix) with SMTP id 81EB69696; Wed, 23 Nov 2005 18:12:29 +0100 (CET) Message-ID: <00c401c5f050$f4a10390$0300a8c0@COMETE> From: "Damien Bergamini" To: Date: Wed, 23 Nov 2005 18:11:33 +0100 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.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Cc: freebsd-arch@freebsd.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2005 17:12:37 -0000 This is FreeBSD 7. If you can't afford temporary breakage, use RELENG_6. Are you sure your suspend/resume problem comes from iwi ? Does it happen if you ifconfig iwi0 down before suspending ? Was suspend/resume working with the old iwicontrol stuff ? Damien | Right now suspend/resume is broken due to the iwi driver | loading firmware. While you guys hash this out would it be | possible to put in an interim simple fix? I can live with | 200KB+ bloat while you guys hash out a more comple{x,ete} | fix! As it is I kldload as much as possible so as to run | the same static image on all machines so overall I still | don't use up as much space as GENERIC. | | Thanks! From owner-freebsd-arch@FreeBSD.ORG Wed Nov 23 18:03:40 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org 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 1AD2C16A420 for ; Wed, 23 Nov 2005 18:03:40 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from gate.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id C95A543D81 for ; Wed, 23 Nov 2005 18:03:31 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by gate.bitblocks.com (8.13.4/8.13.1) with ESMTP id jANI3Qkp097690; Wed, 23 Nov 2005 10:03:26 -0800 (PST) (envelope-from bakul@bitblocks.com) Message-Id: <200511231803.jANI3Qkp097690@gate.bitblocks.com> To: "Damien Bergamini" In-reply-to: Your message of "Wed, 23 Nov 2005 18:11:33 +0100." <00c401c5f050$f4a10390$0300a8c0@COMETE> Date: Wed, 23 Nov 2005 10:03:26 -0800 From: Bakul Shah Cc: freebsd-arch@freebsd.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2005 18:03:40 -0000 > This is FreeBSD 7. > If you can't afford temporary breakage, use RELENG_6. Temporaray breakage is fine but I was hoping it didn't extend too long while people were hashing out different ideas :-) For now I have just reverted to an older kernel. But since you bring this up, as a general rule, IMHO even if this is -current every effort needs to be made to keep things running. And I think this is true by and large. > Are you sure your suspend/resume problem comes from iwi ? It paniced in iwi_init() or something (I was in a hurry so didn't pay much attention). If it will help, I can certainly retry it and send you the details. > Does it happen if you ifconfig iwi0 down before suspending ? No idea. > Was suspend/resume working with the old iwicontrol stuff ? Yes. This is why I suspect the fix is probably very simple. Thanks for your & Scott's response. -- bakul