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

[Ian Kent <raven@themaw.net>]

On 19/05/18 00:22, Randy Dunlap wrote:
> On 05/17/2018 11:09 PM, Ian Kent wrote:
>> On 18/05/18 12:38, Ian Kent wrote:
>>> 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, akpm@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):
>>>>>> 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."
>>>>
>>>
>>> No doubt that was what happened, unfortunately I forgot to return to it.
>>>
>>> Right, a conditional with a message should work .... thanks.
>>
>> It looks like adding:
>> depends on AUTOFS_FS = n && AUTOFS_FS != m
> 
> Hi.  Is there a typo on the line above?

Don't think so.

This was straight out of:

diff --git a/fs/autofs4/Kconfig b/fs/autofs4/Kconfig
index 53bc592a250d..2f9bafabac1b 100644
--- a/fs/autofs4/Kconfig
+++ b/fs/autofs4/Kconfig
@@ -1,6 +1,7 @@
 config AUTOFS4_FS
        tristate "Kernel automounter version 4 support (also supports v3 and v5)"
        default n
+       depends on AUTOFS_FS = n && AUTOFS_FS != m
        help
          The automounter is a tool to automatically mount remote file systems
          on demand. This implementation is partially kernel-based to reduce
@@ -30,3 +31,10 @@ config AUTOFS4_FS
          - any "alias autofs autofs4" will need to be removed.
 
          Please configure AUTOFS_FS instead of AUTOFS4_FS from now on.
+
+         NOTE: Since the modules autofs and autofs4 use the same file system
+               type name of "autofs" only one can be built. The "depends"
+               above will result in AUTOFS4_FS not appearing in .config for
+               any setting of AUTOFS_FS other than n and AUTOFS4_FS will
+               appear under the AUTOFS_FS entry otherwise which is intended
+               to draw attention to the module rename change.

which appears to do what's needed about as well as can be done and deals
with the AUTOFS4_FS=y && AUTOFS_FS=y case.

Ian