Date: Mon, 21 Nov 2005 11:03:56 -0700 From: Scott Long <scottl@samsco.org> To: Damien Bergamini <damien.bergamini@free.fr> Cc: arch@freebsd.org, Nate Lawson <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 Message-ID: <43820C0C.6000001@samsco.org> In-Reply-To: <00ff01c5eec3$3b0e6640$0300a8c0@COMETE> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43820C0C.6000001>