Date: Wed, 30 Apr 1997 21:47:37 +1000 (EST) From: Darren Reed <avalon@coombs.anu.edu.au> To: bde@zeta.org.au (Bruce Evans) Cc: hackers@FreeBSD.org Subject: Re: Unloading LKMs (was Re: A Desparate Plea for Help...) Message-ID: <199704301148.EAA22561@hub.freebsd.org> In-Reply-To: <199704301005.UAA15798@godzilla.zeta.org.au> from "Bruce Evans" at Apr 30, 97 08:05:42 pm
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from Bruce Evans, sie said: > > >Hmm, I didn't see that before. It doesn't look like it's used > >correctly though; eg. the qcam module hooks itself in rather than > >letting _lkm_dev() do it. > > > >Then when its load function returns happily, the bogus entries its > >made in the cdevsw are saved as the 'old' values, and thus when it's > >unloaded the saved values are restored and everything is spam. > > Right (except _lkm_dev() shouldn't do it). > > The olddev stuff is bogus except in 2.1.x. The `old' pointer is > guaranteed to be null, or at least should have been null (SYSINIT() is > misused to initiate the devsw entries for unattached drivers). There > are no functions to remove devsw entries, but "add"ing null entries > works. > > _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. Why ? Why do we need to change something that already works ? Especially since all other LKM implementations do what 2.1.x does now anyway. If you want to do something, fix post 2.1.x to work safely in the same fashion as 2.1.x. IMHO, the driver should need to know zero about devsw tables, etc. 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 ?" Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704301148.EAA22561>