On 12/2/15 4:39 AM, Ian Campbell wrote:
> On Tue, 2015-12-01 at 04:00 -0700, Jan Beulich wrote:
>> But not forking doesn't mean importing the whole directory. Some
>> Makefile adjustments will be necessary anyway, so removing some
>> of the frontends wouldn't make things worse. We indeed should
>>
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
>>>
>>
On 12/2/15 3:38 AM, Jan Beulich wrote:
On 01.12.15 at 21:04, 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?
>>>
On Tue, 2015-12-01 at 04:00 -0700, Jan Beulich wrote:
> But not forking doesn't mean importing the whole directory. Some
> Makefile adjustments will be necessary anyway, so removing some
> of the frontends wouldn't make things worse. We indeed should
> avoid editing files we import, but I don't see
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 qu
>>> On 01.12.15 at 21:04, 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
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 opt
>>> On 30.11.15 at 18:00, wrote:
> So you want me to break this patch up to bring in the frontends
> individually? Since there is a request to have KEXEC and the UARTs
> configurable by the user I would bring in all these frontends.
No, I want them to be left out entirely. But it looks like we fi
>>> On 30.11.15 at 18:16, wrote:
> Jan Beulich writes ("Re: [PATCHv6] 01/28] build: import Kbuild/Kconfig from
> Linux 4.2"):
>> On 30.11.15 at 16:42, wrote:
>> > I would go further than this, and wholesale import the relevant files
>> > into a subdirectory in a single commit that contains nothi
On Mon, 2015-11-30 at 17:16 +, Ian Jackson wrote:
> It appears that we do disagree. Perhaps the basic thing is: I don't
> think we want to fork this code. We want to be a downstream of Linux
> for it. If necessary we may edit, to an extent, the parts we import,
> but hopefully we'll keep tha
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
On 11/30/15 11:04 AM, Ian Jackson wrote:
> Doug Goldstein writes ("Re: [PATCHv6] 01/28] build: import Kbuild/Kconfig
> from Linux 4.2"):
>> On 11/30/15 9:55 AM, Jan Beulich wrote:
>>> On 30.11.15 at 16:34, wrote:
>>> Afaic I'd prefer a minimal import as a first step. Adding further
>>> frontends
Jan Beulich writes ("Re: [PATCHv6] 01/28] build: import Kbuild/Kconfig from
Linux 4.2"):
> On 30.11.15 at 16:42, wrote:
> > I would go further than this, and wholesale import the relevant files
> > into a subdirectory in a single commit that contains nothing else, and
> > mention the specific git
Doug Goldstein writes ("Re: [PATCHv6] 01/28] build: import Kbuild/Kconfig from
Linux 4.2"):
> On 11/30/15 9:55 AM, Jan Beulich wrote:
>> On 30.11.15 at 16:34, wrote:
> > Afaic I'd prefer a minimal import as a first step. Adding further
> > frontends - if really needed - could be done later.
>
>
>>> On 30.11.15 at 16:42, wrote:
> Doug Goldstein writes ("Re: [PATCHv6] 01/28] build: import Kbuild/Kconfig
> from Linux 4.2"):
>> The whole point here was to bring in the kconfig bits from Linux 4.2
>> untouched for traceability for where the code came from. By doing it
>> this way it allows Xe
On 11/30/15 9:55 AM, Jan Beulich wrote:
On 30.11.15 at 16:34, wrote:
>> On 11/30/15 7:59 AM, Jan Beulich wrote:
>> On 24.11.15 at 18:51, wrote:
--- /dev/null
+++ b/xen/scripts/kconfig/Makefile.linux
@@ -0,0 +1,317 @@
>>>
>>> This doesn't seem to be referenced anywhere.
>>
>>> On 30.11.15 at 16:34, wrote:
> On 11/30/15 7:59 AM, Jan Beulich wrote:
> On 24.11.15 at 18:51, wrote:
>>> --- /dev/null
>>> +++ b/xen/scripts/kconfig/Makefile.linux
>>> @@ -0,0 +1,317 @@
>>
>> This doesn't seem to be referenced anywhere.
>
> Its the central file for building kconfig. It
On 11/30/15 7:59 AM, Jan Beulich wrote:
On 24.11.15 at 18:51, wrote:
>> --- /dev/null
>> +++ b/xen/include/linux/kconfig.h
>> @@ -0,0 +1,54 @@
>> +#ifndef __LINUX_KCONFIG_H
>> +#define __LINUX_KCONFIG_H
>
> Neither placement in the source tree nor guard variable should say
> "Linux".
This f
Doug Goldstein writes ("Re: [PATCHv6] 01/28] build: import Kbuild/Kconfig from
Linux 4.2"):
> The whole point here was to bring in the kconfig bits from Linux 4.2
> untouched for traceability for where the code came from. By doing it
> this way it allows Xen to rebase kconfig support to a newer ve
>>> On 24.11.15 at 18:51, wrote:
> --- /dev/null
> +++ b/xen/include/linux/kconfig.h
> @@ -0,0 +1,54 @@
> +#ifndef __LINUX_KCONFIG_H
> +#define __LINUX_KCONFIG_H
Neither placement in the source tree nor guard variable should say
"Linux".
> --- /dev/null
> +++ b/xen/scripts/Makefile.host
> @@ -0,
20 matches
Mail list logo
