Date: Wed, 30 Apr 1997 23:10:06 +1000 (EST) From: Darren Reed <avalon@coombs.anu.edu.au> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: bde@zeta.org.au, hackers@FreeBSD.org Subject: Re: Unloading LKMs (was Re: A Desparate Plea for Help...) Message-ID: <199704301311.GAA05717@who.cdrom.com> In-Reply-To: <199704301243.WAA28705@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Apr 30, 97 10:13:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from Michael Smith, sie said: > > 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. I'd argue that if the kernel is doing it itself, and the table for *devsw is dynamic, then it is outside the scope of an ordinary driver to be making changes. But maybe that is going a bit far... I had a read of kern_lkm.c for 2.2 and the cdevsw_add() was written to work how IP Filter uses it. That is, add an entry if there isn't one there or replace if there is. This has preserved the old behaviour. Whether or not the *devsw created get's freed (and pointer restored to what it was previously) or a null copy is coppied over, I don't care, so long as it is all handled internally to the LKM code. I can't see that there should be an API for this either - it should be the LKM code's job to maintain the table correctly. > 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) [...] > 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) Noise like the comments I made come from also having to deal with include file changes (which don't appear to do anything worthwhile except create compatibility problems). Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704301311.GAA05717>