Date: Wed, 30 Apr 1997 22:13:16 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: avalon@coombs.anu.edu.au (Darren Reed) Cc: bde@zeta.org.au, hackers@FreeBSD.org Subject: Re: Unloading LKMs (was Re: A Desparate Plea for Help...) Message-ID: <199704301243.WAA28705@genesis.atrad.adelaide.edu.au> In-Reply-To: <199704301148.EAA22561@hub.freebsd.org> from Darren Reed at "Apr 30, 97 09:47:37 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Darren Reed stands accused of saying: > > > > _lkm_dev() shouldn't be touching the devsw's. Drivers need to manage > > the devsw's directly for the non-LKM case and should use identical > > code for the LKM case. This is debatable. > Why ? Why do we need to change something that already works ? The issue is that in 2.1.x, devsw entries were members of a compile-time-defined array. This is the traditional *nix edit-conf.c approach. 2.2 builds the devsw tables at link time using linker sets, and as such the devsw arrays are now arrays of pointers to devsw structures. This is a huge plus, in that one no longer has to mung the stuff in conf.c in order to add a new driver. Bruce's argument is that drivers should do their own management of devsw entries. I'm inclined to disagree, especially as there is no API for doing this; you are expected to grovel directly. It's probably worth checking with the last people that had their hands dirty in the LKM stuff. Rest assured though that the idea here is not to make any 'ad hoc' changes. 8) > With people suggesting more and more ad hoc changes, that mean more > work for me, I seriously have to wonder "is it worth the effort ?" *ahem* That's entirely the wrong attitude to be taking in a forum where improvement of the system is a principal issue. As a vendor representative, you're welcome (and expected) to stick up for your preferences; but intimating that we're all picking on you and that you might as well just pack up your toys and go home isn't very helpful. If you have a genuine beef with something that's proposed, make some noise about it. Chances are that if you get involved in the design phase, you can save yourself some work instead 8) Don't be afraid to suggest stuff either; input is _always_ welcome. > Darren -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704301243.WAA28705>