SPARC64: Modular floppy?

SPARC64: Modular floppy?

[Horst von Brand]

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

Re: SPARC64: Modular floppy?

[David S. Miller]

On Mon, 28 Feb 2005 17:07:43 -0300
Horst von Brand <vonbrand@inf.utfsm.cl> 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.

Re: SPARC64: Modular floppy?

[Horst von Brand]

"David S. Miller" <davem@davemloft.net> said:
> On Mon, 28 Feb 2005 17:07:43 -0300
> Horst von Brand <vonbrand@inf.utfsm.cl> 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

Re: SPARC64: Modular floppy?

[Randy.Dunlap]

Horst von Brand wrote:
> "David S. Miller" <davem@davemloft.net> said:
> 
>>On Mon, 28 Feb 2005 17:07:43 -0300
>>Horst von Brand <vonbrand@inf.utfsm.cl> 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

Re: SPARC64: Modular floppy?

[Horst von Brand]

"Randy.Dunlap" <rddunlap@osdl.org> said:
> Horst von Brand wrote:
> > "David S. Miller" <davem@davemloft.net> said:
> >>On Mon, 28 Feb 2005 17:07:43 -0300
> >>Horst von Brand <vonbrand@inf.utfsm.cl> 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

Re: SPARC64: Modular floppy?

[Randy.Dunlap]

Horst von Brand wrote:
> "Randy.Dunlap" <rddunlap@osdl.org> said:
> 
>>Horst von Brand wrote:
>>
>>>"David S. Miller" <davem@davemloft.net> said:
>>>
>>>>On Mon, 28 Feb 2005 17:07:43 -0300
>>>>Horst von Brand <vonbrand@inf.utfsm.cl> 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

Re: SPARC64: Modular floppy?

[David S. Miller]

On Tue, 01 Mar 2005 16:26:05 -0300
Horst von Brand <vonbrand@inf.utfsm.cl> 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.

Re: SPARC64: Modular floppy?

[Randy.Dunlap]

(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