From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: Adrian Bunk <bunk@stusta.de>
Cc: sensors@stimpy.netroedge.com, linux-kernel@vger.kernel.org
Subject: Re: drivers/w1/: why is dscore.c not ds9490r.c ?
Date: Tue, 23 Nov 2004 13:34:12 +0300 [thread overview]
Message-ID: <1101206052.9784.26.camel@uganda> (raw)
In-Reply-To: <20041123002028.GN19419@stusta.de>
[-- Attachment #1: Type: text/plain, Size: 3115 bytes --]
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
>
--
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-11-23 10:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-21 22:02 drivers/w1/: why is dscore.c not ds9490r.c ? Adrian Bunk
2004-11-22 7:31 ` Evgeniy Polyakov
2004-11-22 13:33 ` Adrian Bunk
2004-11-22 16:25 ` Evgeniy Polyakov
2004-11-22 16:51 ` Adrian Bunk
2004-11-22 17:05 ` Evgeniy Polyakov
2004-11-22 17:19 ` Adrian Bunk
2004-11-22 17:37 ` Evgeniy Polyakov
2004-11-23 0:20 ` Adrian Bunk
2004-11-23 10:34 ` Evgeniy Polyakov [this message]
2004-11-25 15:56 ` Adrian Bunk
2004-11-29 1:52 ` [2.6 patch] drivers/w1/: possible cleanups Adrian Bunk
2004-11-29 5:12 ` Evgeniy Polyakov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1101206052.9784.26.camel@uganda \
--to=johnpol@2ka.mipt.ru \
--cc=bunk@stusta.de \
--cc=linux-kernel@vger.kernel.org \
--cc=sensors@stimpy.netroedge.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox