linux-kernel - Re: [PATCH] AT91: add AT91SAM9X5 dummy configuration variable

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: <201107021149.41703.arnd@arndb.de>
Date:	Sat, 2 Jul 2011 11:49:41 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Nicolas Ferre <nicolas.ferre@...el.com>
Cc:	balbi@...com, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, plagnioj@...osoft.com,
	avictor.za@...il.com
Subject: Re: [PATCH] AT91: add AT91SAM9X5 dummy configuration variable

On Wednesday 29 June 2011 17:24:42 Nicolas Ferre wrote:
> > Here are a few questions:
> > i) The drivers you're willing to send, are those for Atmel's IPs or are
> >       the IPs sourced from some other company ?
> > ii) Even if they are Atmel-specific, do you see the possibility of Atmel
> >       licensing them ?
> > iii) Does your driver current depend on asm/ or mach/ headers ?
> > iv) Is there a generic header which you could use instead of asm/ mach/ ?
> 
> I just want to hide drivers that are not relevant for others: I have the feeling
> that it is a good practice. This tiny patch will ease this during my publication
> flow. Do you seriously care?

I think Felipe is right on this one, but both views are common in the kernel
today: Some people want dependencies to mean "you cannot build this driver
unless the dependencies are fulfilled", others like them more broadly to
mean "there is no point to ever enable this driver because I know you won't
need it".

Both views are understandable, but I favor the first one because

* it's the more common view these days and we should be consistent

* it exposes drivers to more build testing. If something changes in
  the kernel that exposes new warnings in your driver or causes a
  build error, that is more likely to get fixed when more people
  find it by doing allyesconfig or randconfig builds.

* If there is an actual build dependency between the driver and the
  platform that causes you to need the explicit Kconfig depends, that
  is in many cases a hint that the driver author is doing something
  wrong, like hardcoding MMIO addresses or referencing custom
  symbols exported by the platform.

I don't think anyone really objects your patch to introduce the extra
Kconfig symbol, but I'd hope that we can eventually get a consensus
on the idea that you shouldn't use Kconfig dependencies based on
whether a driver is relevant or not.

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