On Mon, Oct 28, 2013 at 3:17 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Sat, 2013-10-26 at 11:45 +0200, Luis R. Rodriguez wrote: > >> > Yes moving the dependencies is easier than backporting the code which >> > does not work any more. ;-) The problem here is that the regulator core >> > can not be backported, because it is always build into the kernel and >> > not as a module. > >> As for the issues with some functionality on the regulator >> drivers requiring functionality from future kernels as its always >> built-in, that can be addressed if we add support for non-modular >> solutions on backports. > > I don't think that's actually true - the regulator drivers may require > being built-in, Sorry I didn't mean to say they require, I mean they are typically used in that way, the core of the subsystem is built-in and does require to be built in, but the drivers do not. What I'm saying is that if we had built-in target support we'd be able to backport a more rich feature set of the functionality. > but there are probably good reasons for that like > multiple other modules accessing them. Yeap that too. So updating them in a backport > and building them in wouldn't really help since now you'd have two > identical regulators that conflict and have different users. Its a great point and sets up the expectations of the requirements for how to properly backport this -- not only its users but all of the regulator's users. > And if you tried to backport it into the tree and make it the only > regulator driver, you'd now have to forward-port all the remaining > in-tree users as well, which seems unreasonable too. I'm not sure that's too unreasonable, what other users are there of the regulator subsystem for drivers other than media ? Answering that will answer this question and define the scope of the requirements if this is desirable. > The only usage would seem to be building it including *all* users as > part of the backport, but that seems somewhat unlikely? Ah, yeap, well that's what I mean. This will depend on motivation if the architecture we provide helps with someone's requirements. I contend that backporting in-kernel will be easier given you can backport more features, the major challenge will be having to also include something like module namespaces or backport all dependencies on a core component. Possible -- and IMHO if you look at the way things are currently backported -- its much worse and the gains of alternative approaches are frankly dismal. I see long term architectural gains to just backport automatically, but it does require a bit of kick off work. Luis -- To unsubscribe from this list: send the line "unsubscribe backports" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
