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: <200703152048.42972.bzolnier@gmail.com>
Date:	Thu, 15 Mar 2007 20:48:42 +0100
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	Al Viro <viro@....linux.org.uk>
Cc:	Akira Iguchi <akira2.iguchi@...hiba.co.jp>,
	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 Thursday 15 March 2007, Al Viro wrote:
> 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.

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
-
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/