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@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." > No doubt that was what happened, unfortunately I forgot to return to it. Right, a conditional with a message should work .... thanks. Ian
