#define DRM(x) r128_##x
module_init( DRM(init) );
#define __define_initcall(level,fn) \
static initcall_t __initcall_##fn __attribute_used__ \
__attribute__((__section__(".initcall" level ".init"))) = fn
This gives the error:
{standard input}: Assembler messages:
{standard input}:104: Error: junk at end of line, first unrecognized
character is `('
I believe this is because the C macro is not being expanded in the
assembler context of the section with the fn assignment.
Any ideas on how to fix this?
--
Jon Smirl
[email protected]
On Sat, Sep 25, 2004 at 01:57:37PM -0400, Jon Smirl wrote:
> #define DRM(x) r128_##x
> module_init( DRM(init) );
>
> #define __define_initcall(level,fn) \
> static initcall_t __initcall_##fn __attribute_used__ \
> __attribute__((__section__(".initcall" level ".init"))) = fn
>
> This gives the error:
> {standard input}: Assembler messages:
> {standard input}:104: Error: junk at end of line, first unrecognized
> character is `('
>
> I believe this is because the C macro is not being expanded in the
> assembler context of the section with the fn assignment.
BS. In non-modular case (quoted above) DRM(init) will be expanded _long_
before you get to __define_initcall() expansion.
In the modular case, OTOH, it will _not_. There you get
module_init(DRM(init)) =>
static inline initcall_t __inittest(void) { return initfn; } int init_module(void) __attribute__((alias("DRM(init)")));
since # suppresses expansion of argument. Which leaves you with
.globl init_module
.set init_module, DRM(init)
in assembler output. Which is not going to make as(1) happy.
> Any ideas on how to fix this?
To fix what, exactly? Your beliefs? DRM abuse of cpp? For the former I'd
suggest learning C (or learning to use -S to see what exactly as(1) gets to
deal with). For the latter...
#define DRM_abuses_cpp_too_fscking_much(x) module_init(x)
DRM_abuses_cpp_too_fscking_much(DRM(init))
will force the expansion before it gets to module_init(), which will result in
acceptable alias.
Sorry for bothering you. I'm trying to work out a scheme for
transitioning most of the DRM() macros out of the DRM source without
breaking everything. Right now I can get rid of all but six uses. I
was going to fix this one in the next pass and I needed a solution to
keep everything working for the moment. I was focused on the point of
the error and didn't think about fixing it at a higher level.
--
Jon Smirl
[email protected]
To start off with, I didn't write the DRM macros, I'm just trying to
work with the code that is already there. Here's my understanding of
the state of the macros...
The DRM macros are there because of the way DRM is built. There are
two pieces of DRM, the core and the chip drivers. Most drivers, like
fbdev, make the core into one module and the chip drivers into others.
This allows the chip drivers to share the core code.
DRM is built differently. The core is linked into each chip driver.
This lets you get drivers from different places (ATI) that might use a
core that doesn't match the one in your kernel. If you load two DRM
drivers you will get two copies of the core.
With modules this doesn't make a difference. But instead, if you link
these drivers into the kernel you get a bunch of symbol conflicts from
the duplicated cores. This is where the DRM() macro come into play.
The DRM() macros give the radeon driver core distinct symbol names
from the other drivers. This lets you link in drivers for all of the
chips if you want to without causing symbol conflicts.
I'm building a test version of DRM that uses a core model like fbdev
does. Doing this allows me to remove the DRM() macros.
However this has a side effect. DRM drivers are distributed outside of
the kernel. This leads to the possibility of wanting two drivers
simultaneously loaded that need different versions of the core.
Without the DRM macros we can only have one version of the core
loaded. What are you going to do?
One response is to build a stable API for the core. This may come over
time but right now this interface is very volatile. It's also obvious
that vendors shouldn't build DRM core into the kernel in case an
outside driver needs to replace it.
So it looks like the downside to getting rid of the macros is that
people who are running multiple video cards can't mix drivers with
drivers from outside the tree. This used to work but creating DRM core
will break it. The solution to this seems to be for vendors with
drivers outside of the tree to add the DRM macros to their derivative
code base in order to stop the symbol conflicts.
The new DRM core version for Linux 2.6 that I'm building also
incorporates GPL code. It's unclear how that is going to impact
outside drivers.
--
Jon Smirl
[email protected]
On Sat, Sep 25, 2004 at 03:17:14PM -0400, Jon Smirl wrote:
> However this has a side effect. DRM drivers are distributed outside of
> the kernel. This leads to the possibility of wanting two drivers
> simultaneously loaded that need different versions of the core.
> Without the DRM macros we can only have one version of the core
> loaded. What are you going to do?
Stop distributing the drivers outside of the kernel?
> One response is to build a stable API for the core.
This has absolutely zero chance to happen, as the evolution of the
kernel has proven time and again. The internal APIs of the kernel
aren't stable, however much we'd like them to be, because the best way
to do something at time t isn't the best way to do it at time t+1.
The best that is done is to try to change the drivers at the time the
core changes, and that only happens if the source of the drivers is
there along with the rest of the kernel.
OG.
Salut,
On Sun, Sep 26, 2004 at 07:21:04PM +0200, Olivier Galibert wrote:
> > One response is to build a stable API for the core.
>
> This has absolutely zero chance to happen, as the evolution of the
> kernel has proven time and again. The internal APIs of the kernel
> aren't stable, however much we'd like them to be, because the best way
> to do something at time t isn't the best way to do it at time t+1.
> The best that is done is to try to change the drivers at the time the
> core changes, and that only happens if the source of the drivers is
> there along with the rest of the kernel.
That'd be true if fact were fiction and TV reality.
Actually, lots of drivers that *are* in the kernel are pretty much
broken.
And I don't think putting more drivers into the mainline kernel will
fix this problem.
The only thing that will is doing stable and development trees in
different places. We ceased to do that, and *it's* *no* *good*.
Tonnerre
On Sun, Sep 26, 2004 at 07:24:29PM +0200, Tonnerre wrote:
> Actually, lots of drivers that *are* in the kernel are pretty much
> broken.
Sure. OTOH you can count the non-broken drivers outside the kernel tree
with your fingers..
> And I don't think putting more drivers into the mainline kernel will
> fix this problem.
Actually it does. It keeps them uptodate on API changes, and more important
gets them additional review.
On Sun, 26 Sep 2004, Tonnerre wrote:
> Actually, lots of drivers that *are* in the kernel are pretty much
> broken.
I don't disagree with that...
> And I don't think putting more drivers into the mainline kernel will
> fix this problem.
But the One True Path to guaranteed brokenness somewhere in time leads through
drivers that are not in the standard kernel tree...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds