On Thu, Mar 15, 2007 at 03:10:20PM +0900, Akira Iguchi wrote:
Al wrote:
quoted
Eh... You still need dependency on IDE=y; otherwise you'll get configs
with IDE=m, BLK_DEV_IDE_CELLEB=y and those won't link. BLK_DEV_IDEDMA_PCI
is selectable just fine with IDE=m.
It's the same problem as with ps3 fb.
I'm sorry I missed this case.
Using some configurations, I found BLK_DEV_IDE=y was better.
(I failed to link when IDE=y and BLK_DEV_IDE=m.)
Umm... Point taken. After looking at the entire thing... well.
a) BLK_DEV_IDE_PMAC has bogus dependency on IDE=y. If anything, that
should've been BLK_DEV_IDE=y; however, it *does* build with ide modular -
it doesn't generate a separate module and its initialization is called
explicitly from ide one. AFAICS, we can simply drop that dependency.
b) BLK_DEV_IDE_PMAC does *not* build without BLK_DEV_IDEDMA_PMAC. Quoting
benh, "I don't see any reason to keep that dma thingy optional anyway".
c) BLK_DEV_MPC8xx_IDE depends on BLK_DEV_IDE=y *and* IDE=y. The latter is
obviously redundant. The former... No idea, 8xx is currently b0rken in
ARCH=powerpc and I can't be arsed to wade through arch/ppc bitrot. As it
is, driver definitely wants ARCH=ppc stuff (__res, for one thing).
Now, BLK_DEV_IDE_CELLEB looks interesting. The nature of breakage is not
the same as usual (non-modular driver depends on stuff that might be built
modular); what's going on here is funnier. If you get ide-core modular,
you'll have BLK_DEV_IDE_CELLEB code *linked* *into* ide-core.ko. Unlike
the rest of its ilk, however, it doesn't have its init called directly from
ide init. It uses module_init(), which happens to work when it goes into
the kernel image (ide-core.o has several initcalls, not a problem), but breaks
when it goes into a modular ide-core.ko; there multiple module_init() are
fatal.
So AFAICS the minimal fix for that sucker is dependency on BLK_DEV_IDE=y;
however, I really wonder if
* it needs to be linked into ide-core (as opposed to being a normal
module of its own)
* alternatively, its init should be called explicitly.
Comments?
On Thursday 15 March 2007, Al Viro wrote:
On Thu, Mar 15, 2007 at 03:10:20PM +0900, Akira Iguchi wrote:
quoted
Al wrote:
quoted
Eh... You still need dependency on IDE=y; otherwise you'll get configs
with IDE=m, BLK_DEV_IDE_CELLEB=y and those won't link. BLK_DEV_IDEDMA_PCI
is selectable just fine with IDE=m.
It's the same problem as with ps3 fb.
I'm sorry I missed this case.
Using some configurations, I found BLK_DEV_IDE=y was better.
(I failed to link when IDE=y and BLK_DEV_IDE=m.)
Umm... Point taken. After looking at the entire thing... well.
a) BLK_DEV_IDE_PMAC has bogus dependency on IDE=y. If anything, that
should've been BLK_DEV_IDE=y; however, it *does* build with ide modular -
it doesn't generate a separate module and its initialization is called
explicitly from ide one. AFAICS, we can simply drop that dependency.
agreed
b) BLK_DEV_IDE_PMAC does *not* build without BLK_DEV_IDEDMA_PMAC. Quoting
benh, "I don't see any reason to keep that dma thingy optional anyway".
ditto
c) BLK_DEV_MPC8xx_IDE depends on BLK_DEV_IDE=y *and* IDE=y. The latter is
obviously redundant. The former... No idea, 8xx is currently b0rken in
ditto
ARCH=powerpc and I can't be arsed to wade through arch/ppc bitrot. As it
is, driver definitely wants ARCH=ppc stuff (__res, for one thing).
Now, BLK_DEV_IDE_CELLEB looks interesting. The nature of breakage is not
the same as usual (non-modular driver depends on stuff that might be built
modular); what's going on here is funnier. If you get ide-core modular,
you'll have BLK_DEV_IDE_CELLEB code *linked* *into* ide-core.ko. Unlike
the rest of its ilk, however, it doesn't have its init called directly from
ide init. It uses module_init(), which happens to work when it goes into
the kernel image (ide-core.o has several initcalls, not a problem), but breaks
when it goes into a modular ide-core.ko; there multiple module_init() are
fatal.
So AFAICS the minimal fix for that sucker is dependency on BLK_DEV_IDE=y;
however, I really wonder if
* it needs to be linked into ide-core (as opposed to being a normal
module of its own)
AFAICS there are no legacy device ordering issues with scc_pata so it doesn't
need to be linked into ide-core but I'll leave the definitive answer to Akira
* alternatively, its init should be called explicitly.
Comments?
Care to provide patch for non-scc_pata issues that you've discovered? :-)
Thanks,
Bart
Hi,
Bart wrote:
quoted
Al wrote:
So AFAICS the minimal fix for that sucker is dependency on BLK_DEV_IDE=y;
however, I really wonder if
* it needs to be linked into ide-core (as opposed to being a normal
module of its own)
AFAICS there are no legacy device ordering issues with scc_pata so it doesn't
need to be linked into ide-core but I'll leave the definitive answer to Akira
quoted
* alternatively, its init should be called explicitly.
I don't have the answer why scc_pata is linked into ide-core.
Reviewing your comments and codes, I will make the following fixes:
* remove link to ide-core and make normal module
* move from ide/ppc to ide/pci
I will send these patches later.
Best regards,
Akira Iguchi