linux-kernel - Re: [PATCH 10/13] BLK_DEV_IDE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070315084645.GR4095@ftp.linux.org.uk>
Date:	Thu, 15 Mar 2007 08:46:45 +0000
From:	Al Viro <viro@....linux.org.uk>
To:	Akira Iguchi <akira2.iguchi@...hiba.co.jp>
Cc:	torvalds@...ux-foundation.org, linuxppc-dev@...abs.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 10/13] BLK_DEV_IDE_CELLEB dependency fix

On Thu, Mar 15, 2007 at 03:10:20PM +0900, Akira Iguchi wrote:
> Al wrote:
> >
> >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?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/