Date: Mon, 21 Nov 2005 11:25:56 -0700 From: Scott Long <scottl@samsco.org> To: Warner Losh <imp@bsdimp.com> 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 Message-ID: <43821134.6040306@samsco.org> In-Reply-To: <20051121.111955.74713410.imp@bsdimp.com> References: <8664qmja7y.fsf@xps.des.no> <4381F060.5040107@samsco.org> <4381FEDF.7080607@root.org> <20051121.111955.74713410.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43821134.6040306>