On 18/05/18 12:23, Randy Dunlap wrote:
> On 05/17/2018 08:50 PM, Ian Kent wrote:
>> On 18/05/18 08:21, Randy Dunlap wrote:
>>> On 05/17/2018 04:26 PM, a...@linux-foundation.org wrote:
>>>> The mm-of-the-moment snapshot 2018-05-17-16-26 has been uploaded to
>>>>    http://www.ozlabs.org/~akpm/mmotm/
>>>> mmotm-readme.txt says
>>>> README for mm-of-the-moment:
>>>> http://www.ozlabs.org/~akpm/mmotm/
>>>> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
>>>> more than once a week.
>>>> You will need quilt to apply these patches to the latest Linus release (4.x
>>>> or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
>>>> http://ozlabs.org/~akpm/mmotm/series
>>>> The file broken-out.tar.gz contains two datestamp files: .DATE and
>>>> .DATE-yyyy-mm-dd-hh-mm-ss.  Both contain the string yyyy-mm-dd-hh-mm-ss,
>>>> followed by the base kernel version against which this patch series is to
>>>> be applied.
>>>> This tree is partially included in linux-next.  To see which patches are
>>>> included in linux-next, consult the `series' file.  Only the patches
>>>> within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
>>>> linux-next.
>>>> A git tree which contains the memory management portion of this tree is
>>>> maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
>>>> by Michal Hocko.  It contains the patches which are between the
>>>> "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
>>>> file, http://www.ozlabs.org/~akpm/mmotm/series.
>>>> A full copy of the full kernel tree with the linux-next and mmotm patches
>>>> already applied is available through git within an hour of the mmotm
>>>> release.  Individual mmotm releases are tagged.  The master branch always
>>>> points to the latest release, so it's constantly rebasing.
>>> on x86_64: with (randconfig):
>> Oh right, I need to make these exclusive.
>> I seem to remember trying to do that along the way, can't remember why
>> I didn't do it in the end.
>> Any suggestions about potential problems when doing it?
> I think that just using "depends on" for each of them will cause kconfig to
> complain about circular dependencies, so probably using "choice" will be
> needed.  Or (since this is just temporary?) just say "don't do that."

No doubt that was what happened, unfortunately I forgot to return to it.

Right, a conditional with a message should work .... thanks.


Reply via email to