From: Brian Gerst <bgerst@didntduck.org>
To: Terence Ripperda <tripperda@nvidia.com>
Cc: Jon Smirl <jonsmirl@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Dave Airlie <airlied@linux.ie>
Subject: Re: inter_module_get and __symbol_get
Date: Wed, 12 Jan 2005 17:21:42 -0500 [thread overview]
Message-ID: <41E5A2F6.8070704@didntduck.org> (raw)
In-Reply-To: <20050112193727.GM1933@hygelac>
Terence Ripperda wrote:
> it would seem like the old mechanism was preferable, but perhaps I'm
> missing something. in this particular case, there are times when a user
> wants to avoid using agp at all for testing purposes, but if I
> understand correctly, we'll be forced to load agpgart anyways due to
> unresolved symbols.
In 2.6, the "agpgart" module is just the core. Without a gart driver
loaded (via-agp for example), it does nothing. If you really don't want
to have the hard dependency on agpgart, make the code using it
conditionally compile on CONFIG_AGP or something.
> but I think Keith Owens was correct in his larger picture view that
> this mechanism is useful for much more than just agp. I'm just
> confused why it was regressed from a non-gpl symbol to a gpl symbol
> (or more appropriately why the non-gpl symbol was regressed in favor
> of a gpl-only symbol).
symbol_get in it's current form is hard-coded to look for GPL symbols,
hence it is exported GPL only. I have a rough patch that will allow
symbol_get to use the license status of its caller to determine which
symbols it can find. However this depends on whether or not
symbol_get() is removed like some people want.
--
Brian Gerst
next prev parent reply other threads:[~2005-01-12 22:32 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-06 21:32 inter_module_get and __symbol_get Terence Ripperda
2005-01-06 21:57 ` Brian Gerst
2005-01-06 22:51 ` Terence Ripperda
2005-01-08 4:00 ` Jon Smirl
2005-01-12 19:37 ` Terence Ripperda
2005-01-12 22:21 ` Brian Gerst [this message]
2005-01-08 3:10 ` Keith Owens
2005-01-24 22:36 ` David Mosberger
2005-01-24 22:44 ` Keith Owens
2005-01-24 22:52 ` David Mosberger
2005-01-24 22:54 ` Keith Owens
2005-01-24 22:58 ` David Mosberger
2005-01-24 23:03 ` Keith Owens
2005-01-25 0:51 ` patch to enable Nvidia v5336 on v2.6.11 kernel (was Re: inter_module_get and __symbol_get) David Mosberger
2005-01-25 0:51 ` David Mosberger
2005-01-25 12:56 ` J.A. Magallon
2005-01-25 20:50 ` Zephaniah E. Hull
2005-01-26 0:02 ` J.A. Magallon
2005-01-26 0:25 ` Zephaniah E. Hull
2005-01-26 0:25 ` J.A. Magallon
2005-01-25 1:01 ` inter_module_get and __symbol_get Jon Smirl
2005-01-24 23:19 ` Jon Smirl
2005-01-24 23:23 ` David Mosberger
2005-01-25 5:31 ` Terence Ripperda
2005-01-25 5:59 ` Chris Wedgwood
-- strict thread matches above, loose matches on Subject: below --
2005-07-31 4:27 D. ShadowWolf
2005-08-01 1:04 ` Alan Cox
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=41E5A2F6.8070704@didntduck.org \
--to=bgerst@didntduck.org \
--cc=airlied@linux.ie \
--cc=jonsmirl@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tripperda@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.