On Tue, 2004-11-23 at 01:20 +0100, Adrian Bunk wrote: > On Mon, Nov 22, 2004 at 08:37:00PM +0300, Evgeniy Polyakov wrote: > > On Mon, 2004-11-22 at 18:19 +0100, Adrian Bunk wrote: > > > On Mon, Nov 22, 2004 at 08:05:09PM +0300, Evgeniy Polyakov wrote: > > > > On Mon, 2004-11-22 at 17:51 +0100, Adrian Bunk wrote: > > > > > On Mon, Nov 22, 2004 at 07:25:45PM +0300, Evgeniy Polyakov wrote: > > > > > > > > > > > > > How would a different w1 bus master chip look like in > > > > > > > drivers/w1/Makefile? > > > > > > > > > > > > obj-m: proprietary_module.o > > > > > > proprietary_module-objs: dscore.o proprietary_module_init.o > > > > > > > > > > > > Actually it will live outside the kernel tree, but will require ds2490 > > > > > > driver. > > > > > > It could be called ds2490.c but I think dscore is better name. > > > > > > > > > > Why are you talking about proprietary modules living outside the kernel > > > > > tree? > > > > > > > > > > The only interesting case is the one of modules shipped with the kernel. > > > > > And for them, this will break at link time if two such modules are > > > > > included statically into the kernel. > > > > > > > > If we _currently_ do not have any open hw/module that depends on ds2490 > > > > core then it does not > > > > mean that tomorrow noone will add it. > > > > > > Once again: > > > _this will break at link time if two such modules are included > > > statically into the kernel_ > > > > > > obj-$(CONFIG_W1_DS9490) += ds9490r.o > > > ds9490r-objs := dscore.o > > > > > > obj-$(CONFIG_W1_FOO) += foo.o > > > foo-objs := dscore.o > > > > > > > that should be follwing: > > > > Kconfig: > > foo depends on ds9490r > > > > obj-$() += foo.o > > foo-objs := foo_1.o foo_2.o > > > > It just happened that ds9490r does not need any other parts but > > dscore.o. > > That is why ds9490r.o have only dscore.o in it's dependency. > > If foo_1 or foo_2 is dscore, you get exactly the compile breakage I > described. foo_1 and foo_2 will not be dscore, since foo depends on ds9490 and thus dscore must be already built. It looks like you were confused by dscore vs. ds9490 names. Probably it was not a good idea to call it in a such way, but it was done and it works. > > > This will break with CONFIG_W1_DS9490=y and CONFIG_W1_FOO=y. > > > > > > > > > That drivers/w1/ contains many EXPORT_SYMBOL's with no in-kernel users > > > is a different issue I might send a separate patch for (that besides > > > proprietary modules there might come some day open source drivers using > > > them is not a reason). > > > > Why remove existing non disturbing set of exported functions? > > Are they violate some unknown issues? > > If an export is currently unused, there's no need to export it. > > If an export is only used for proprietary modules, that's a reason for > an immediate removal of this export. Sigh. It can be used by anyone who want to use it. I will take more carefull look at it later, thank you. > cu > Adrian > -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20041123/034276b8/attachment.bin