Re: [PATCHv6] 00/28] Kconfig conversion

["Jan Beulich" <JBeulich@suse.com>]

>>> On 03.12.15 at 04:02, <cardoe@cardoe.com> wrote:
> There's been quite a few comments on this series and I'll admit I'm a
> bit lost as to the requested direction for the series so just to clear
> things up I'm going to send this out and address all the items before
> the next repost. My goal is to save you all time as reviewers so that
> hopefully you'll only have to review one more series.

My views (already incorporating changes thereto due to feedback
from others):

> 1. Remove the KEXEC patch from this series and add it to the follow-on
> series?

I don't mind it being in the initial series. All I do mind is it being done
in two pieces.

> 2. Drop UART changes and just go back to the mechanical changes that
> enable the UARTs on ARM as they are today.

Yes.

> 3. sync the (A) entire linux/scripts/kconfig directory or (B) basics
> from linux/scripts/kconfig or (C) basics + frontends for future series
> when user-configurable options are presented. Note: Option B will
> require not just copying files but making modifications (read: forking)
> until a more complete copy is brought over.

While mostly moot at this point - what's the difference between (A)
and (C)? Or is (C) meant to represent (A) split into (B) plus a
follow-up?

In any event, with it at the same time getting clarified who is
expected to look after pulling in updates, I won't object to (A)
anymore. With one caveat: I don't recall you pulling over rules to
actually update the *_shipped files if needed. Unless I overlooked
these, I'd like to make it a requirement to have these rules in
place and working (but, just like in Linux, disabled by default).

> 4. Should I rename xen/scripts/kconfig to xen/tools/kconfig?

Definitely. kconfig is not a script, it just deals with scripts (which
are scattered around the tree).

> 5. Should I drop as much $(BASEDIR) usage as possible?

Unless they are required for current functionality, yes.

Jan