Re: [PARPORT] multiple low-level drivers

From: Kipp Cannon (
Date: Wed Dec 12 2001 - 20:14:28 EST

  • Next message: Tim Waugh: "Re: [PARPORT] multiple low-level drivers"

    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)?


    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?


    -- To unsubscribe, send mail to: --
    -- 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