linux-kernel - Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism

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: <20111008181829.GB15617@leaf>
Date:	Sat, 8 Oct 2011 11:18:29 -0700
From:	Josh Triplett <josh@...htriplett.org>
To:	Greg KH <greg@...ah.com>
Cc:	"G, Manjunath Kondaiah" <manjugk@...com>,
	linux-arm-kernel@...ts.infradead.org,
	Grant Likely <grant.likely@...retlab.ca>,
	linux-omap@...r.kernel.org, linux-mmc@...r.kernel.org,
	linux-kernel@...r.kernel.org, Dilan Lee <dilee@...dia.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Manjunath@...per.es
Subject: Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism

On Sat, Oct 08, 2011 at 08:55:02AM -0700, Greg KH wrote:
> On Fri, Oct 07, 2011 at 09:03:51PM -0700, Josh Triplett wrote:
> > On Fri, Oct 07, 2011 at 02:23:26PM -0700, Greg KH wrote:
> > > On Fri, Oct 07, 2011 at 01:57:15PM -0700, Josh Triplett wrote:
> > > > On Thu, Oct 06, 2011 at 11:49:28PM -0700, Greg KH wrote:
> > > > > On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
> > > > > > +config PROBE_DEFER
> > > > > > +	bool "Deferred Driver Probe"
> > > > > > +	default y
> > > > > > +	help
> > > > > > +	  This option provides deferring driver probe if it has dependency on
> > > > > > +	  other driver. Without this feature, initcall ordering should be done
> > > > > > +	  manually to resolve driver dependencies. This feature completely side
> > > > > > +	  steps the issues by allowing driver registration to occur in any
> > > > > > +	  order, and any driver can request to be retried after a few more other
> > > > > > +	  drivers get probed.
> > > > > 
> > > > > Why is this even an option?  Why would you ever want it disabled?  Why
> > > > > does it need to be selected?
> > > > > 
> > > > > If you are going to default something to 'y' then just make it so it
> > > > > can't be turned off any other way by just not making it an option at
> > > > > all.
> > > > 
> > > > Given that the drivers which use this mechanism will not necessarily get
> > > > built into the kernel, I'd suggest that it should remain optional and
> > > > default to n.  Those drivers can then add a dependency on PROBE_DEFER.
> > > > Let's try to avoid adding more infrastructure to the kernel that takes
> > > > up space even when unused; certainly embedded will appreciate not having
> > > > this feature unless a driver needs it.
> > > 
> > > How much extra space is this "feature" really?
> > 
> > Just checked: 776 bytes, 640 of text and 136 of data.  We have kconfig
> > options for comparable amounts.
> > 
> > > I don't see it being
> > > anything larger than the amount of memory increase that just happened as
> > > I typed this email as part of the ongoing memory density changes.
> > 
> > I don't know about the changes you mean
> 
> Moore's law.

Ah, I see.  For new systems, sure; for systems or mechanisms with a
pre-existing size constraint, that doesn't help.

> Really, 776 bytes, just always enable it, it's not worth it.

776 bytes alone, no; 776 bytes times the next (or previous) thousand
features, yes.

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