As things stand today, floppy can't be modular (even though the
configuration allows it!) because drivers/block/floppy.c references stuff
in arch/sparc64/kernel/entry.S which isn't included if the floppy
isn't. But that same code references symbols in floppy.c, so it doesn't
help making it depend on floppy (modular or not).
So, either the dependencies have to get fixed so floppy can't be modular
for this architecture, or the relevant functions have to move from entry.S
to the module. Last looks like a mess, splattering .S for sparc64 into
drivers, or moving it to arch. Or is there some way of building a module
from pieces in different directories under architecture control?
Or this can be declared an endearing quirk of Linux on SPARC ;-)
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
On Mon, 28 Feb 2005 17:07:43 -0300
Horst von Brand <[email protected]> wrote:
> So, either the dependencies have to get fixed so floppy can't be modular
> for this architecture, or the relevant functions have to move from entry.S
> to the module.
I think the former is the best solution. The assembler code really
needs to get at floppy.c symbols.
"David S. Miller" <[email protected]> said:
> On Mon, 28 Feb 2005 17:07:43 -0300
> Horst von Brand <[email protected]> wrote:
[...]
> > So, either the dependencies have to get fixed so floppy can't be modular
> > for this architecture, or the relevant functions have to move from entry.S
> > to the module.
> I think the former is the best solution. The assembler code really
> needs to get at floppy.c symbols.
>From my cursory look the stuff depending on the floppy.c symbols is just
in the floppy-related code. Can't that be just included in floppy.c?
(Could be quite a mess, but it looks like short stretches).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Horst von Brand wrote:
> "David S. Miller" <[email protected]> said:
>
>>On Mon, 28 Feb 2005 17:07:43 -0300
>>Horst von Brand <[email protected]> wrote:
>
>
> [...]
>
>
>>>So, either the dependencies have to get fixed so floppy can't be modular
>>>for this architecture, or the relevant functions have to move from entry.S
>>>to the module.
>
>
>>I think the former is the best solution. The assembler code really
>>needs to get at floppy.c symbols.
>
>
>>From my cursory look the stuff depending on the floppy.c symbols is just
> in the floppy-related code. Can't that be just included in floppy.c?
> (Could be quite a mess, but it looks like short stretches).
The code in entry.S looks self-contained (to me:), so moving it
somewhere else should just be a SMOP (mostly kbuild stuff)....
--
~Randy
"Randy.Dunlap" <[email protected]> said:
> Horst von Brand wrote:
> > "David S. Miller" <[email protected]> said:
> >>On Mon, 28 Feb 2005 17:07:43 -0300
> >>Horst von Brand <[email protected]> wrote:
> > [...]
> >>>So, either the dependencies have to get fixed so floppy can't be modular
> >>>for this architecture, or the relevant functions have to move from entry.S
> >>>to the module.
> >>I think the former is the best solution. The assembler code really
> >>needs to get at floppy.c symbols.
> >>From my cursory look the stuff depending on the floppy.c symbols is just
> > in the floppy-related code. Can't that be just included in floppy.c?
> > (Could be quite a mess, but it looks like short stretches).
> The code in entry.S looks self-contained (to me:), so moving it
> somewhere else should just be a SMOP (mostly kbuild stuff)....
Right. But where? I was thinking under arch/sparc64/drivers/floppy.S or
such. And then there would need to be some make magic for it to get picked
up and included only for sparc64. Sounds doable, if somewhat messy.
But thinking a bit farther, if every arch and random driver starts playing
this kind of games, we'll soon be in a world of hurt. Not sure if it is
worth it.
Other solution was to #ifdef that stuff into floppy.c, but again at the
end of that way lies madness.
I'll see what I come up with. Recomended reading on the whole kbuild stuff?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Horst von Brand wrote:
> "Randy.Dunlap" <[email protected]> said:
>
>>Horst von Brand wrote:
>>
>>>"David S. Miller" <[email protected]> said:
>>>
>>>>On Mon, 28 Feb 2005 17:07:43 -0300
>>>>Horst von Brand <[email protected]> wrote:
>
>
>>>[...]
>
>
>>>>>So, either the dependencies have to get fixed so floppy can't be modular
>>>>>for this architecture, or the relevant functions have to move from entry.S
>>>>>to the module.
>
>
>>>>I think the former is the best solution. The assembler code really
>>>>needs to get at floppy.c symbols.
>
>
>>>>From my cursory look the stuff depending on the floppy.c symbols is just
>>>in the floppy-related code. Can't that be just included in floppy.c?
>>>(Could be quite a mess, but it looks like short stretches).
>
>
>>The code in entry.S looks self-contained (to me:), so moving it
>>somewhere else should just be a SMOP (mostly kbuild stuff)....
>
>
> Right. But where? I was thinking under arch/sparc64/drivers/floppy.S or
> such. And then there would need to be some make magic for it to get picked
> up and included only for sparc64. Sounds doable, if somewhat messy.
>
> But thinking a bit farther, if every arch and random driver starts playing
> this kind of games, we'll soon be in a world of hurt. Not sure if it is
> worth it.
Then go with Dave's suggestion: don't allow modular floppy
in Kconfig.
> Other solution was to #ifdef that stuff into floppy.c, but again at the
> end of that way lies madness.
>
> I'll see what I come up with. Recomended reading on the whole kbuild stuff?
It's all in Documentation/kbuild/
--
~Randy
(Sam, your From: From: Sam Ravnborg <> really trips thunderbird.)
Sam wrote:
Documentation/kbuild/makefiles.txt is a good start.
For specific questions I can help out.
For this specific case the problem seems to me that you in the ppc64
case want to include floppy-ppc64.S in the build for the PPC64 case.
So something as simple as:
1) rename floppy.c to floppy-core.c
2) Change Makefile to look like:
floppy-y := floppy-core.o
floppy-$(PPC64) += floppy-ppc64.o
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Minor detail, This is for sparc64 (see Subject).
I also see that arch/arm[26]/lib/ has special handling for
floppydma.S, so there'a a model to consider also.
--
~Randy
On Tue, 01 Mar 2005 16:26:05 -0300
Horst von Brand <[email protected]> wrote:
> Right. But where? I was thinking under arch/sparc64/drivers/floppy.S or
> such. And then there would need to be some make magic for it to get picked
> up and included only for sparc64. Sounds doable, if somewhat messy.
Sparc 32-bit has the same problem btw. It's a direct IRQ handler that
doesn't need to save any trap state.