Greg KH wrote:
On Tue, Jun 21, 2005 at 08:44:18PM -0600, Jim Cromie wrote:
PS. Its beyond the scope of this thread, and probably beyond the kenn
of this mailing list (the newbies at least0, but what about a
intermodule-shared-lock service module, to fill the gap between a
one-off shared-lock module like the above, and a full-blown
cluster-ready Distributed lock manager
Ok, now you've just gone too far :)
No, that's not needed, and neither is your "put a lock in a module"
stuff. Just put the lock in the module you need it in, and make the
other module depend on it. It's ok to load more than one module (as you
are going to do anyway.)
In short, don't try to make it so hard...
its easy when you know what youre doing..
the i2c driver has its locks buried in a static structure, so I have to
move them
up to file variables and export-symbol them. Ok easy enough.
And having a new module depend on several old/solid ones,
in a separate subsystem, isnt so bad I suppose.
soekris:~# lsmod
Module Size Used by
pc87360 35612 0
i2c_sensor 3712 1 pc87360
i2c_isa 2304 0
i2c_core 21264 3 pc87360,i2c_sensor,i2c_isa
So, perhaps you'll help me sort out some other dependencies.
the pc87366 GPIOs are similar to those on the SC-1100,
so I can borrow routines from scx200 and scx200_gpio.
But that will make pc87366_gpio dependent upon them,
and therefore useless when those drivers fail to load,
(ie when the board doesnt have the PCI device ids
that the scx200 driver expects )
So, my choice here is:
a. accept the dependence and use the routines
(works for me, I have a board with both parts)
b. duplicate the code, avoid the dependence
c. pull the code into a 3rd module, used by both.
( nsc_gpio, nsc='national semiconductor corp' )
thanks,
greg k-h
thank you
Jim Cromie
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
