[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] build: sync Kconfig with Linux v4.17

> On Jun 21, 2018, at 4:37 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 21.06.18 at 10:28, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 21/06/18 16:13, Jan Beulich wrote:
>>>>>> On 21.06.18 at 04:10, <dougtrav@xxxxxxxxxx> wrote:
>>>> From: Doug Goldstein <cardoe@xxxxxxxxxx>
>>>> From: Doug Goldstein <cardoe@xxxxxxxxxx>
>>>> Import the following files and directories from the Linux v4.17 tag
>>>> (commit id 29dcea88779c856c7dc92040a0c01233263101d4):
>>>> - scripts/kconfig/ -> xen/tools/kconfig/
>>>> - scripts/Makefile.host -> xen/tools/kconfig/Makefile.host
>>>> - Documentation/kbuild/kconfig{,-language}.txt ->
>>>>  docs/misc/kconfig{-language}.txt
>>>> - include/linux/kconfig.h -> xen/include/xen/kconfig.h
>>>> Pulled in parts of scripts/Makefile.lib into
>>>> xen/tools/kconfig/Makefile.kconfig
>>>> Side effect of this change is that flex and bison are required to build
>>>> Kconfig. Linux has switched from shipping the pre-generated files to
>>>> always generating them with flex and bison.
>>>> Signed-off-by: Doug Goldstein <cardoe@xxxxxxxxxx>
>>> What I'm missing (and what I think is a requirement for this to go in) is
>>> the "why" part: What do we gain from doing the update? Besides that
>>> I think that in general it would be better to pull in Linux commits one
>>> by one, rather than combining everything into a giant patch. That
>>> might even already address part of my question, as it could highlight
>>> bug fixes and/or enhancements which are of interest to us.
>> As a first pass, "because multiple people specifically asked about when
>> we were going to update the version of Kconfig".
> Okay, I must have missed every one of these. And hence I'm unaware
> of the "why" parts of these requests.

It was asked during multiple sessions at the Xen Developer Summit in Nanjing by 
audience members.

>> Working patch by patch isn't feasible because of the renames.
> I don't understand - how does path/file naming conflict with working
> patch by patch? Surely a relatively simple sed command could be used
> to change the paths in each patch according to our tree layout. That's
> basically what I'm doing with the MWAIT idle driver; granted, that's just
> a single file.

Its 106 commits between the last time I got this in sync. We also don’t have 
kbuild and we have a little shim file to map things to our build system so for 
each patch I would have to implement some of those regressions.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.