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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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, but in any case I'd like to
prevent mandatory size increases wherever possible.  I'd love to see the
size of "allnoconfig" getting *smaller* over time, not larger.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux