Re: mmotm 2018-05-17-16-26 uploaded (autofs)

[Randy Dunlap]

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, akpm@xxxxxxxxxxxxxxxxxxxx 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):
>> CONFIG_AUTOFS_FS=y
>> CONFIG_AUTOFS4_FS=y
> 
> 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."

-- 
~Randy