netdev - Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)

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]

Date:	Fri, 9 Nov 2007 12:06:48 +0000
From:	Ben Dooks <ben@...ff.org>
To:	Al Viro <viro@....linux.org.uk>
Cc:	Magnus Damm <magnus.damm@...il.com>, netdev@...r.kernel.org,
	lethal@...ux-sh.org, ben-linux@...ff.org,
	akpm@...ux-foundation.org, jeff@...zik.org,
	linux-arch@...r.kernel.org
Subject: Re: [RFC] dependencies for platform drivers (was Re: ax88796: add
	superh to kconfig dependencies)

On Thu, Nov 08, 2007 at 08:18:54AM +0000, Al Viro wrote:
> On Thu, Nov 08, 2007 at 04:31:05PM +0900, Magnus Damm wrote:
> >  config AX88796
> >  	tristate "ASIX AX88796 NE2000 clone support"
> > -	depends on ARM || MIPS
> > +	depends on ARM || MIPS || SUPERH
> 
> You know, that really sucks more and more.  How about doing the following:
> 	a) making it depend on PLAT_HAS_AX88796
> 	b) adding selects for all subarchitectures that have the corresponding
> platform device
> and setting that as a uniform policy for platform drivers?  For things like
> SM501 we would do
> config MFD_SM501
> 	depends on PCI || PLAT_HAS_SM501
> etc.

The PLAT_HAS_xxx method is nice, and I would like it applied to other places
in the kernel (see libata arugment below), and would have acked
this patch if it hadn't already been applied by Jeff.

The only reservation is that this doesn't show up the posibilty
of having the driver in the menuconfig, but anyone adding new
board support (should) be bright enough to look through the
Kconfig scripts before deciding they need to write an entirely
new driver.

I would note you may want to do PLAT_HAS_NET_AX88796 as there is
entirely a posibility of confusing this with the simple parallel
port driver which a board may not have support for.

> Seriously, folks, we are getting shitloads of platform drivers with no
> dependencies whatsoever, needed on a handful of targets and occasionally
> failing to build on unrelated architectures.  Moreover, having a list
> of architectures in dependencies for each of those suckers is a PITA
> from the conflict POV.  Not to mention platform drivers that fall into
> the mainline kernel with not a single platform device for them, etc.

There is a general problem with chicken-vs-egg here, how do you submit
support for a machine's platform device without the platform device
being there (and vice-versa) with seperate maintainers for network
and machine support?

One of my colleagues has passed along comments you made about a pair
of the simtec drivers (simtec-i2c and simtec-ide) which have been
added, but have no current users as patches have been stalled either
in submission process, or awaiting for an resolution. In the case
of simtec-ide, I would like to replace it with platform-ata, but
the libata maintainers seem wholy un-interested in
PLAT_HAS_PLATFORM_ATA or similar.

-- 
Ben (ben@...ff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html