Date: Mon, 21 Nov 2005 11:39:38 -0700 From: Scott Long <scottl@samsco.org> To: Warner Losh <imp@bsdimp.com> 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 Message-ID: <4382146A.9000006@samsco.org> In-Reply-To: <20051121.112724.41676073.imp@bsdimp.com> References: <4381FEDF.7080607@root.org> <00ff01c5eec3$3b0e6640$0300a8c0@COMETE> <43820C0C.6000001@samsco.org> <20051121.112724.41676073.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4382146A.9000006>