On Tue, Jun 21, 2011 at 06:34:48AM -0700, Dmitry Torokhov wrote: > On Jun 21, 2011 3:46 PM, "Mark Brown" <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> > > On Mon, Jun 20, 2011 at 01:45:12AM -0700, Dmitry Torokhov wrote: > > Like Grant says this really isn't terribly sustainable - it's not just > > the device registration you need to sort out, it's also the registration > > of the drivers so things actually get bound and handing of any delays in > > the process of getting things to appear. > If devices are registered only when they are fully usable then driver > registration does not matter. Right, but this is something that it's not reasonable to implement in board code - if nothing else implementing it in board code would mean we'd got lots of repitition of common patterns. > > It's not trivial to get this > > right in the general case and it's not reasonable to expect individual > > boards to open code things, > Board code has the ultimate knowledge about connected devices though. Absolutely, board code or data should provide the information about how things are wired up. It's the acting on it bit that's the issue. > > > How about we do not register device until all resources are ready? This > > > is pretty simple concept - do not create an object until it is usable. > Then > > > nobody needs to bother with -EAGAIN or -ENOTYET or any other similar > > > garbage. > > As soon as you let the user build drivers modular this goes out of the > > window. > Why is that? If device is registered only when it is ready to be bound to > then it does not matter when the driver is registered and whether it is > built into the kernel or as a module. Originally you were talking about registration ordering - solving the module load issues also requires dynamic delays and rollbacks when things get unregisterd, something that goes well beyond simple ordering of the registrations. > > All the faff with initcall ordering that we do at the minute is > > essentially trying to implement this mechanism. > No, what you are doing is creating devices before they are usable and > postponing the driver registration in hopes that devices will be ready by > that time. Right, which is controlling the ordering of registration so that things generally work out OK as described above. Nobody's arguing that we don't want to solve this in a better way, we're just saying that actually doing that requires improvements in both core infrastructure and the data we've got available to the infrastructure so there's no reasonable solutions that we can deploy which are better than the initcall ordering stuff we're doing at the minute. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
