From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Goldstein Subject: Re: [PATCHv6] 01/28] build: import Kbuild/Kconfig from Linux 4.2 Date: Wed, 2 Dec 2015 08:33:40 -0600 Message-ID: <565F0144.2060202@cardoe.com> References: <1448387538-12208-1-git-send-email-cardoe@cardoe.com> <1448387538-12208-2-git-send-email-cardoe@cardoe.com> <565C645C02000078000BA3AD@prv-mh.provo.novell.com> <565C6C7B.4060600@cardoe.com> <565C7F8402000078000BA5C5@prv-mh.provo.novell.com> <565C80C8.9010704@cardoe.com> <1448903970.15768.59.camel@citrix.com> <565DFD30.8070504@cardoe.com> <1449049676.15768.173.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7930644872861768291==" Return-path: In-Reply-To: <1449049676.15768.173.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Jan Beulich Cc: Keir Fraser , Tim Deegan , Ian Jackson , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============7930644872861768291== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="X0lI3U91k89BtitOH8GNPde8P0iFJlT5V" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --X0lI3U91k89BtitOH8GNPde8P0iFJlT5V Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/2/15 3:47 AM, Ian Campbell wrote: > 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 largel= y >>> 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 >=20 > 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). >=20 > 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-selectabl= e, > 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. >=20 > I would encourage you to par this first series back to the simplest > possible "switch to Kconfig, retaining the exact same set of user facin= g > options as today" and avoid feature creep from people requesting new an= d > exciting things which the switch to Kconfig makes possible. That I can do. I always expected that I would have a follow on series (maybe even multiples) as I was able to tease out some of the dependencies better. e.g. converting some of include/asm-ARCH/config.h I would also happily add myself to MAINTAINERS for the Kconfig parts and would ensure some kind of periodic sync up with Linux upstream. I'm not looking at doing this conversion as a one and done but sticking around for the long haul. >=20 > That way we can make progress on a mostly mechanical switch to Kconfig > without continuously getting side tracked on questions like whether thi= s or > that should be user selectable or not. >=20 > All of the "feature-creep" (which I don't mean in the pejorative sense)= > things can easily be done in a follow up series. >=20 >> 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 h= ad >> them enabled as they are in config/arm{32,64}.mk and changed them to b= e >> 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=3Dn" and it will disable it. I chose that on= e as >> an original example in v1 of how a user configurable option would look= >> in this scheme. >=20 > I don't have a problem with converting existing user-configurable optio= ns > into Kconfig in the first pass, that seems natural/justifiable enough t= o > me, and doing it in the final patch as you have done seems sensible. >=20 > Treading very carefully around the creeping-featuritis trap (:-)), it d= oes > 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 follo= wup > series though. >=20 > Ian. >=20 Sure thing. I'll break that out. My plan was to convert them all. The patch that does KEXEC was actually from the original RFC/v1 series where it was just an example one and I never dropped it in later series because it was useful for testing. I've got a follow on that converts all the items in xen/Rules.mk that I have not posted to the list and I can move the KEXEC into that series. --=20 Doug Goldstein --X0lI3U91k89BtitOH8GNPde8P0iFJlT5V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWXwFHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNTM5MEQ2RTNFMTkyNzlCNzVDMzIwOTVB MkJDMDNEQzg3RUQxQkQ0AAoJEKK8A9yH7RvUhn8QAJe+1TB3vwXccQt4t21ReYX5 ENcOO/zt5cUdKiguY9OB/8WPdObPc63XrXnDcvFVZVtF5wutB71F8rDfwIZfgN3j jwZ3UkvG74tLdQZ+DQIAnOENi86h2q9P8MLCrl3vj3qm8vrpA/AJrdaH+tpygXBZ f12B9B1dQTuMfUWUjwwcefDNnCDRU432EmJrwRochknUdGIPLfHOadzgz/3dDUA8 oEVN1cjDdKVnB1ePOkXzJYN/ySH2PePFSlBoULaYA8DHBN6bzr2xmoh+3FN1ErI8 lxeS0fjbpvg+8R2kEP/LFqX86MbYQO5ybjKOt7k2Z4t8d8hnbgTDpDlfj8m4aDFF WWZyebYeQ3AbgibNkKV7eIKQosu2HII78tc3jlLBNY0Vkgkj1i3v00b7v1v11V6b CVi02jCem8Ecx8TsIvHiSotchPnTYQ4E4pdidXw4l4e+j7yertuejOc/WgSmPPpA 80hXwvQkGG0MpzTpZHJ7AljZc/FT1M8g+EjaY7plhtV8Y8eT7QC4SHnHKAMNOtem GJ/zk9cpmqMs9SQCObQBmrHnuLJHGL5q/Fwv2jAvssdNvWfnIt3wJUJWMVjZ9o6h xBf6lAuulgqlFWqNdIlTgTOD7AjU3nuSq2i08Hi2Qq/rx9ZF25Xz2XwDYnsN1NH3 aUa7bErLsKMGsSFWXAkP =FS1g -----END PGP SIGNATURE----- --X0lI3U91k89BtitOH8GNPde8P0iFJlT5V-- --===============7930644872861768291== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7930644872861768291==--