On Tue, 3 Jun 2003, [iso-8859-15] José Fonseca wrote:
>
> IIUC, at least for modules, the symbols which we want to make available
> to other modules usually have to be specificaly declared (with
> EXPORT_SYMBOL). Therefore each module it's "own namespace", i.e., two
> different modules with some public symbol with the same name on each
> module doesn't lead to a duplicate symbol unless they both are exported.
No.
Exactly because both modules may be linked into the kernel, and the way C
linkers work, there is only two namespaces: the per-file ("static") one,
and the global one.
> But for statically linked kernels, can we or not have two equally named
> non-static not-exported symbols living in two different source files?
No, we can NOT have that.
If they have the same name, they must be the same function. It's that
simple. And if it's the same function and used by multiple different
drivers, then it MUST NOT have CONFIG_xxx dependencies.
This is exactly what was wrong with the old pre-DRM(xxx) code.
So I would suggest:
- create a new module, called "drm", which holds truly generic functions.
It gets linked in only _once_, and drm module users have to load it
explicitly (possibly though "modprobe", which knows about module
dependencies, but _not_ by doing some kind of "request_module()" crap)
Sane setups will just link this module directly into the kernel.
This module does not know (or care) about what DRI drivers there are.
It doesn't have a list of supported drivers, and it only has generic
infrastructure stuff.
Quite frankly, looking at the current DRI tree, there's not a lot of
code like this there that I can see. Almost every single "library"
function has intimate details about the hardware through macro
expansion.
- any "library" functions that behave differently for different cards
must continue to use a card-specific prefix. So for example, the
function DRM(setup)() is clearly _different_ for a Radeon card, since
the radeon driver has a different DRIVER_PRESETUP() thing etc. As a
result, it must not be called "drm_setup()", since it is clearly
"radeon_setup()".
The files I see that look like they could be true DRM library functions
(without any major surgery, at least) are
- drm_agpsupport.h
- drm_lock.h
- drm_memory.h
but I may be misreading something.
Linus
-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
