On Tue, 2015-12-01 at 14:04 -0600, Doug Goldstein wrote: > On 11/30/15 11:19 AM, Ian Campbell wrote: > > On Mon, 2015-11-30 at 11:00 -0600, Doug Goldstein wrote: > > > Since there is a request to have KEXEC and the UARTs > > > configurable by the user > > > > Who asked for this? > > > > I have quite a strong preference for not adding _any_ new[*] user > > configurable options in this first pass, since I think those need to be > > considered quite carefully whereas this first series should be largely > > about the mechanics of introducing Kconfig files. > > > > Ian. > > > > [*] i.e. anything which is not already controllable by the current > > .config > > driven thing. > > > > The ARM UARTs are the take away I had from conversations with Julien > Grall
AIUI all Julien was asking for was that the same set of UARTs should be enabled for arm32 or arm64 both before and after this series, not that they should be user configurable (in this first pass at least). TBH I think this series is getting bogged down in trying to do much all at the same time, switching to Kconfig, making things newly user-selectable, arranging for out of tree builds, some of which are either (potentially) controversial or simply result in apparently unnecessary changes if the reviewer is only expecting a subset of those changes (especially those only expecting the first), leading to a few RTTs of back and forth with reviewers. I would encourage you to par this first series back to the simplest possible "switch to Kconfig, retaining the exact same set of user facing options as today" and avoid feature creep from people requesting new and exciting things which the switch to Kconfig makes possible. That way we can make progress on a mostly mechanical switch to Kconfig without continuously getting side tracked on questions like whether this or that should be user selectable or not. All of the "feature-creep" (which I don't mean in the pejorative sense) things can easily be done in a follow up series. > and reading past comments on the ML how people can change the ARM > UARTs. Obviously if that's not desired I can drop that. I originally had > them enabled as they are in config/arm{32,64}.mk and changed them to be > user configurable later in the series. > > As far as KEXEC goes, its a user configurable option now in Rules.mk. > You can build "make kexec=n" and it will disable it. I chose that one as > an original example in v1 of how a user configurable option would look > in this scheme. I don't have a problem with converting existing user-configurable options into Kconfig in the first pass, that seems natural/justifiable enough to me, and doing it in the final patch as you have done seems sensible. Treading very carefully around the creeping-featuritis trap (:-)), it does seem that if one of the user options from xen/Rules.mk is going to be converted then they all ought to be. Perhaps that's a topic for a followup series though. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel