On Fri, 7 Dec 2001, Tim Waugh wrote:
> On Thu, Dec 06, 2001 at 09:26:47PM -0500, Kipp Cannon wrote:
>
> > The HP interface driver keeps track of which ports it owns by maintaining
> > a private linked list of them. This could be done in every low-level
> > driver but it's a lot of code duplication. My own preference would be to
> > add the field
> >
> > struct module *owner
> >
> > to one of the parport structures, either struct parport or maybe struct
> > parport_operations (a la file_operations). It's then trivial to set the
> > pointer to THIS_MODULE and check it against THIS_MODULE before removing
> > the port. I don't know if this method of keeping track of ownership is
> > smiled upon or frowned upon by the kernel upper-ups but it can't be beaten
> > for simplicity at the driver level. Any thoughts?
>
> This is an excellent way of doing it IMHO. Care to write the patch
> (you're in a better position to test it than I am)?
Hi,
Good to hear there's interest in doing this and, yeah, I'd be glad to come
up with a patch. Sooo, I did some reading through the kernel source and
it looks like my idea to use THIS_MODULE to keep track of ownership won't
work afterall. When code isn't compiled as a module, THIS_MODULE reduces
to simply NULL so again the low-level drivers wouldn't be able to to tell
themselves apart. Although the drivers can't be unloaded in this case,
there would still be problems at shutdown/reboot.
So I guess I don't know what to do. I'm doing more poking around to see
if any other portions of the kernel have had to solve this problem.
Using THIS_MODULE to set an owner field is so simple that it's tempting to
do something similar by having each driver pick some address from within
their code as an id (maybe the location of their exit function) but this
feels ugly. Any ideas?
-Kipp
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Wed Dec 12 2001 - 20:19:17 EST