|
[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.
—
Doug
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |