Re: [PATCH 1/3] driver core: Add API to wait for deferred probe tocomplete during init

[Russell King - ARM Linux]

On Thu, May 09, 2013 at 03:37:02PM +0100, Mark Brown wrote:
> On Thu, May 09, 2013 at 03:14:45PM +0100, Russell King - ARM Linux wrote:
> > On Thu, May 09, 2013 at 02:50:17PM +0100, Mark Brown wrote:
> 
> > > Even if the driver copes fine it can still be desirable to avoid the
> > > power down/up cycle if it involves some user visible effect - things
> > > like blinking the display off then on for example.  That said I am a
> > > little suspicious about this approach, it doesn't feel as robust as it
> > > should to go round individual callers.
> 
> > What if the driver for something like your display is a module which
> > needs to be loaded from userland?
> 
> That's clearly a "don't do that then" sort of thing; while we don't want
> to be unhelpful there's no guarantees with this approach.

That's not a "don't do that then" thing, because in this case it's
unreasonable to say that.  The display subsystems like fbdev and
DRM represent quite a sizable chunk:

- Base DRM is around 200k.
- DRM drivers typically around 100k each.
- Base FBdev is around 100k.

It won't take long before you're into the territory of having a
significant portion of your kernel being display drivers of one
type or other, much of which won't be usable on any one specific
platform.  So to say "don't build your display drivers as modules"
is an unreasonable position to take.

> Yes, exactly - all we're trying to do here is cover the 90% case, not
> solve all the possible problems since as you say that's not achievable.  
> There's a clear and reasonable desire to turn off resources we know
> aren't in use at the current time, but equally well doing so as soon as
> we start controlling the resources is pretty much guranteed to introduce
> user visible issues on some systems so it's a question of picking some
> reasonable point after that.

I beg to differ on whether it's possible to solve it completely.

> Another option here which is more in tune with deferred probing and
> hotplugging would be to switch the delay over to be time based rather
> than initcall based; do the shutdown at some point based on the time the
> last resource was registered.  That still won't cover everything
> though we could make the delay tunable.

Yuck.  That's crap design.  Really, time based stuff is crap.  I've seen
this too many times with the gnome crap in Ubuntu 12.04 - where if you
boot this off SD card it will complain that some applets fail to start
(and sure enough, half your panel is missing.)  Boot it off eSATA and
it works 100% reliably.

Time based stuff to guess when stuff has finished is never a good thing
and can never be reliable.

A better solution may be to avoid the problem in kernel space altogether.
That's already done in the past with the scsi_wait_scan module.  Make the
the shutdown of stuff a separate loadable module which userspace can load
at the appropriate time to trigger the shutdown of unused resources.  Or
provide a different method for userspace to trigger that action.

With that kind of solution, it is possible to know that the system has
finished booting (many userspace implementations already do this with
stuff like not permitting login via network until after the system has
finished booting despite sshd et.al. already being started.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/