On Mon, Aug 17, 2020 at 1:43 PM Randy Dunlap <rdun...@infradead.org> wrote: > > On 8/17/20 1:29 PM, Cong Wang wrote: > > On Mon, Aug 17, 2020 at 12:55 PM Randy Dunlap <rdun...@infradead.org> wrote: > >> > >> TIPC=m and IPV6=m builds just fine. > >> > >> Having tipc autoload ipv6 is a different problem. (IMO) > >> > >> > >> This Kconfig entry: > >> menuconfig TIPC > >> tristate "The TIPC Protocol" > >> depends on INET > >> + depends on IPV6 || IPV6=n > >> > >> says: > >> If IPV6=n, TIPC can be y/m/n. > >> If IPV6=y/m, TIPC is limited to whatever IPV6 is set to. > > > > Hmm, nowadays we _do_ have IPV6=y on popular distros. > > So this means TIPC would have to be builtin after this patch?? > > No, it does not mean that. We can still have IPV6=y and TIPC=m. > > Hm, maybe I should have said this instead: > > If IPV6=y/m, TIPC is limited _by_ whatever IPV6 is set to. > (instead of _to_ ) > > Does that help any? > > The "limited" in Kconfig rules is a "less than or equal to" > limit, where 'm' < 'y'.
Yeah, this is more clear now. If so, that means all the symbols we have in ipv6_stub can be gone now, assuming module dependency is automatically solved when both are modules. Is this a new Kconfig feature? ipv6_stub was introduced for VXLAN, at that time I don't remember we have such kind of Kconfig rules, otherwise it would not be needed. I also glanced at Documentation/kbuild/kconfig-language.txt, I do not see such a rule, I guess the doc is not updated. > > Still sounds harsh, right? > > > > At least on my OpenSUSE I have CONFIG_IPV6=y and > > CONFIG_TIPC=m. > > > >> TIPC cannot be =y unless IPV6=y. > > > > Interesting, I never correctly understand that "depends on" > > behavior. > > > > But even if it builds, how could TIPC module find and load > > IPV6 module? Does IPV6 module automatically become its > > dependency now I think? > > Sorry, I don't know about this. You can check `modinfo tipc` output after compiling both as modules. (Sorry that I only have CONFIG_MODULES=n here.) Thanks.
