Re: mmotm 2018-05-17-16-26 uploaded (autofs)
On 21/05/18 08:43, Ian Kent wrote: >>> >>> It looks like adding: >>> depends on AUTOFS_FS = n && AUTOFS_FS != m >> >> Hi. Is there a typo on the line above? LOL, but your point is what does the AUTOFS_FS != m do! The answer should be nothing but . I'll have to play a little more. > > 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 >
Re: mmotm 2018-05-17-16-26 uploaded (autofs)
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, 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--mm-dd-hh-mm-ss. Both contain the string -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
Re: mmotm 2018-05-17-16-26 uploaded (autofs)
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, 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--mm-dd-hh-mm-ss. Both contain the string -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? > to autofs4/Kconfig results in autofs4 appearing under the autofs entry > if AUTOFS_FS is not set which should call attention to it. > > It also results in AUTOFS4_FS=n for any setting of AUTOFS_FS except n. > > Together with some words about it in the AUTOFS4_FS help it should be > enough to raise awareness of the change. Sounds good. thanks, -- ~Randy
Re: mmotm 2018-05-17-16-26 uploaded (autofs)
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, 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--mm-dd-hh-mm-ss. Both contain the string -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 to autofs4/Kconfig results in autofs4 appearing under the autofs entry if AUTOFS_FS is not set which should call attention to it. It also results in AUTOFS4_FS=n for any setting of AUTOFS_FS except n. Together with some words about it in the AUTOFS4_FS help it should be enough to raise awareness of the change. Ian
Re: mmotm 2018-05-17-16-26 uploaded (autofs)
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--mm-dd-hh-mm-ss. Both contain the string -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. Ian
Re: mmotm 2018-05-17-16-26 uploaded (autofs)
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--mm-dd-hh-mm-ss. Both contain the string -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
Re: mmotm 2018-05-17-16-26 uploaded (autofs)
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--mm-dd-hh-mm-ss. Both contain the string -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? Thanks, Ian
Re: mmotm 2018-05-17-16-26 uploaded (autofs)
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--mm-dd-hh-mm-ss. Both contain the string -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 fs/autofs/inode.o: In function `autofs_new_ino': inode.c:(.text+0x1b0): multiple definition of `autofs_new_ino' fs/autofs/inode.o:inode.c:(.text+0x1b0): first defined here fs/autofs/inode.o: In function `autofs_clean_ino': inode.c:(.text+0x220): multiple definition of `autofs_clean_ino' fs/autofs/inode.o:inode.c:(.text+0x220): first defined here fs/autofs/inode.o: In function `autofs_free_ino': inode.c:(.text+0x250): multiple definition of `autofs_free_ino' fs/autofs/inode.o:inode.c:(.text+0x250): first defined here fs/autofs/inode.o: In function `autofs_kill_sb': inode.c:(.text+0x260): multiple definition of `autofs_kill_sb' fs/autofs/inode.o:inode.c:(.text+0x260): first defined here fs/autofs/inode.o: In function `autofs_get_inode': inode.c:(.text+0x310): multiple definition of `autofs_get_inode' fs/autofs/inode.o:inode.c:(.text+0x310): first defined here fs/autofs/inode.o: In function `autofs_fill_super': inode.c:(.text+0x410): multiple definition of `autofs_fill_super' fs/autofs/inode.o:inode.c:(.text+0x410): first defined here fs/autofs/root.o: In function `is_autofs_dentry': root.c:(.text+0x1b80): multiple definition of `is_autofs_dentry' fs/autofs/root.o:root.c:(.text+0x1b80): first defined here fs/autofs/root.o:(.rodata+0x140): multiple definition of `autofs_dentry_operations' fs/autofs/root.o:(.rodata+0x140): first defined here fs/autofs/root.o:(.rodata+0x1c0): multiple definition of `autofs_dir_inode_operations' fs/autofs/root.o:(.rodata+0x1c0): first defined here fs/autofs/root.o:(.rodata+0x280): multiple definition of `autofs_dir_operations' fs/autofs/root.o:(.rodata+0x280): first defined here fs/autofs/root.o:(.rodata+0x380): multiple definition of `autofs_root_operations' fs/autofs/root.o:(.rodata+0x380): first defined here fs/autofs/symlink.o:(.rodata+0x0): multiple definition of `autofs_symlink_inode_operations' fs/autofs/symlink.o:(.rodata+0x0): first defined here fs/autofs/waitq.o: In function `autofs_catatonic_mode': waitq.c:(.text+0x60): multiple definition of `autofs_catatonic_mode' fs/autofs/waitq.o:waitq.c:(.text+0x60): first defined here fs/autofs/waitq.o: In function `autofs_wait_release': waitq.c:(.text+0x180): multiple definition of `autofs_wait_release' fs/autofs/waitq.o:waitq.c:(.text+0x180): first defined here fs/autofs/waitq.o: In function `autofs_wait': waitq.c:(.text+0x5f0): multiple definition of `autofs_wait' fs/autofs/waitq.o:waitq.c:(.text+0x5f0): first defined here fs/autofs/expire.o: In function `autofs_expire_direct': expire.c:(.text+0x920): multiple definition of `autofs_expire_direct' fs/autofs/expire.o:expire.c:(.text+0x920): first defined here fs/autofs/expire.o: In function `autofs_expire_indirect': expire.c:(.text+0xa40): multiple definition of `autofs_expire_indirect' fs/autofs/expire.o:expire.c:(.text+0xa40): first defined here fs/autofs/expire.o: In function `autofs_expire_wait': expire.c:(.text+0xd10): multiple definition of `autofs_expire_wait' fs/autofs/expire.o:expire.c:(.text+0xd10): first defined here fs/autofs/expire.o: In function `autofs_expire_run': expire.c:(.text+0xeb0): multiple definition of `autofs_expire_run' fs/autofs/expire.o:expire.c:(.text+0xeb0): first defined here fs/autofs/expire.o: In function `autofs_do_expire_