[kbuild-devel] Re: Handling boolean subsets of objects
Allowing a variable number of CONFIGs in commands gives a useful reduction in the number of commands required by kbuild 2.5. select(config objects) -> select(config objects) [ unchanged ] always(objects) -> select(objects) always_mod(objects) -> select(CONFIG_M objects) objlink(objects)-> objlink(objects) [ unchanged ] objlink_cond(config objects)-> objlink(config objects) ifsel(config1) -> select(config2 config1 objects) select(config2 objects) endsel Remove always, always_mod and objlink_cond, just use select and objlink. No config means unconditional. CONFIG_M is set to 'm' if CONFIG_MODULES is true, otherwise it is 'n'. CONFIG_Y also exists, it is always 'y'. When multiple configs occur in select, the first one determines how the objects will be compiled. The other configs must all be selected as 'y' or 'm' to build the objects but they have no effect on how the objects are built. This gives us the ability to do this :- select(CONFIG_M config_list objects) - build the objects as modules as long as the config_list is true, even if all the config_list is built in. Bits of debug code use this, like drivers/acpi/Makefile.in. ifsel(CONFIG_KDB) ifsel(CONFIG_ACPI) always_mod(kdbm_acpi.o) endif endif Replace with select(CONFIG_M CONFIG_KDB CONFIG_ACPI kdbm_acpi.o) select(CONFIG_Y config_list objects) - build the objects into the kernel as long as the config_list is true, even if any of the config_list are set to 'm'. The second construct occurs in a few places where some support code is required in the kernel even if the main code is in a module. Order matters. Peter Samuelson was worried about the principle of least surprise. IMHO the benefits of handling the unusual as well as the usual cases is worth it, we just tell users that the most important config comes first. Even if somebody makes a mistake and reverses the order, the problem will show up immediately. An object that is built in when it should have been a module or vice versa is easy to spot, in many cases it will get unresolved references. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: Handling boolean subsets of objects
[kaos] > If you assume that config1 is always boolean then order does not > matter. If config1 is tristate then order does matter. > > config1 config2 objects > yy y > ym m > my y <=== config2 controls > mm m OK, yes, this is different. The question becomes, which would be the desirable semantics? Most of the time, having multiple config variables means all but one would be bool, but if someone wants to control an object file with more than one tristate variable -- I assumed that in such a case, *any* 'm' should imply a 'not y' result. I assert that this is reasonable for Least Surprise. (And I know I don't have to tell you about Least Surprise, since the kernel hackers are having to learn a whole new set of macros here.) Can you think of a realistic example of having two tristate variables, one of which is set to 'm' and the other to 'y', and wanting the dependent object file compiled as 'y'? Because I can't. > I agree that select() should be extended to take multiple config > options, with at least one being required. Cool. Peter ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Handling boolean subsets of objects
On Mon, 29 Oct 2001 04:30:39 -0600, Peter Samuelson <[EMAIL PROTECTED]> wrote: >[kaos] >> I was hoping to compress the existing three lines to one. >> >> select_cond(CONFIG_SLIP_COMPRESSED CONFIG_SLIP slhc.o) > >Right, and I *still* don't understand why order matters. If either var >is 'n' or '', drop it, else if either var is 'm', compile as module, >else compile as builtin. Ignoring order does not give the exact same syntax as the code it is replacing. ifsel(config1) select(config2 objects) endif If you assume that config1 is always boolean then order does not matter. If config1 is tristate then order does matter. config1 config2 objects yy y ym m my y <=== config2 controls mm m select(config1 config2 objects), ignoring order config1 config2 objects yy y ym m my m<=== different result mm m I know that I raised this question about boolean subsets but there is no guarantee that config1 is always boolean. Someone, somewhere will want to test a tristate config1 when selecting objects. >I think just extending select() to handle a case with more than one >CONFIG_ argument would be the cleanest approach: (a) I doubt the code >to parse this will result in anything significantly harder than just >implementating select_cond(); (b) it's one less function for the end >users to know; (c) you have not yet convinced me that order has to >matter. Ignoring the order question (convinced yet?) I agree that select() should be extended to take multiple config options, with at least one being required. select(config1 config2 config3 ... confign objects) is exactly equivalent to :- ifsel(config2) ifsel(config3) ... ifsel(confign) select(config1 objects)<=== first config controls type endif ... endif endif Since I am extending select() to a variable number of configs, I will do the same to objlink, removing objlink_cond. objlink(config1 config2 config3 ... confign target objects) is exactly equivalent to :- ifsel(config1) ifsel(config2) ifsel(config3) ... ifsel(confign) objlink(target objects) endif ... endif endif endif Configs in select() and objlink() perform an 'and' operation, all must be true for the objects to be selected or linked. Users can get the 'or' operation by listing each config in a separate statement. select(config1 objects) select(config2 objects) ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: Handling boolean subsets of objects
[kaos] > >ifeq(,$(findstring n,$(CONFIG_FOO)$(CONFIG_BAR)) > > ifneq(,$(findstring m,$(CONFIG_FOO)$(CONFIG_BAR))) > ># compile as module > > else > ># compile builtin > > endif > >endif > > That is worse than the existing entries. I was talking about the Makefile implementation, not to be confused with the Makefile.in syntax. The Makefile.in entry would still be one line, select() or select_cond() as you see fit. [See below for why I now vote for select().] > ifsel(CONFIG_SLIP_COMPRESSED) > select(CONFIG_SLIP slhc.o) > endif > > I was hoping to compress the existing three lines to one. > > select_cond(CONFIG_SLIP_COMPRESSED CONFIG_SLIP slhc.o) Right, and I *still* don't understand why order matters. If either var is 'n' or '', drop it, else if either var is 'm', compile as module, else compile as builtin. I think just extending select() to handle a case with more than one CONFIG_ argument would be the cleanest approach: (a) I doubt the code to parse this will result in anything significantly harder than just implementating select_cond(); (b) it's one less function for the end users to know; (c) you have not yet convinced me that order has to matter. > BTW, the test that handles 'n' as well as '' is > ifneq ($(subst n,,$(CONFIG_FOO)$(CONFIG_BAR)),) That works... Peter ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: Handling boolean subsets of objects
On Mon, 29 Oct 2001 01:44:59 -0600, Peter Samuelson <[EMAIL PROTECTED]> wrote: >*If* we can assume that a 'n' variable will not be '' instead [yes, I >know, we can't assume that at present], the makefile implementation is >trivial: > >ifeq(,$(findstring n,$(CONFIG_FOO)$(CONFIG_BAR)) > ifneq(,$(findstring m,$(CONFIG_FOO)$(CONFIG_BAR))) ># compile as module > else ># compile builtin > endif >endif That is worse than the existing entries. Do you really want to replace ifsel(CONFIG_SLIP_COMPRESSED) select(CONFIG_SLIP slhc.o) endif with this? ifeq(,$(findstring n,$(CONFIG_SLIP_COMPRESSED)$(CONFIG_SLIP)) ifneq(,$(findstring m,$(CONFIG_SLIP_COMPRESSED)$(CONFIG_SLIP))) # compile as module else # compile builtin endif endif I was hoping to compress the existing three lines to one. select_cond(CONFIG_SLIP_COMPRESSED CONFIG_SLIP slhc.o) The more standardized formats there are in kbuild, the harder it is for users to make mistakes. What they expand to behind the scenes is a seperate question. BTW, the test that handles 'n' as well as '' is ifneq ($(subst n,,$(CONFIG_FOO)$(CONFIG_BAR)),) ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: Handling boolean subsets of objects
[Peter] > >You can also have a list of CONFIGs, can you not? In which case you > >have a parsing problem either way. [kaos] > select() takes exactly one CONFIG_, select_cond() takes exactly two. > No kbuild 2.5 command takes a variable sized list of CONFIGs. OK, if you say multiple dependent CONFIG_ variables are not needed, I'm happy to take your word for it. > >I still don't see why the code can't just do as dep_tristate does: "if > >there exists an 'n', return 'n', else if there exists an 'm', return > >'m', else return 'y'". > CONFIG_ISDN CONFIG_ISDN_PPP slhc.o > n - n > y n n > y y y > m n n > m y m Uh, I guess we're talking in circles, but AFAICT we are describing the same truth table. The only difference is that your version may be easier to do in a makefile, because you assume the second variable must be a bool. *If* we can assume that a 'n' variable will not be '' instead [yes, I know, we can't assume that at present], the makefile implementation is trivial: ifeq(,$(findstring n,$(CONFIG_FOO)$(CONFIG_BAR)) ifneq(,$(findstring m,$(CONFIG_FOO)$(CONFIG_BAR))) # compile as module else # compile builtin endif endif > The first config has priority, the second only selects a subset. If you can come up with an example where doing it your way with the variables in the correct order (like your table above) produces a different result than my algorithm with the variables in *either* order, I promise to slap myself for being stupid, and then shut up. Peter ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: Handling boolean subsets of objects
On Sun, 28 Oct 2001 20:39:42 -0600, Peter Samuelson <[EMAIL PROTECTED]> wrote: > > [peter] >> >select_cond(CONFIG_ISDN slhc.o CONFIG_ISDN_PPP) > >[kaos] >> That is worse, you can select a list of objects, where does the >> second config go? > >You can also have a list of CONFIGs, can you not? In which case you >have a parsing problem either way. select() takes exactly one CONFIG_, select_cond() takes exactly two. No kbuild 2.5 command takes a variable sized list of CONFIGs. >I still don't see why the code can't just do as dep_tristate does: "if >there exists an 'n', return 'n', else if there exists an 'm', return >'m', else return 'y'". # only included if CONFIG_ISDN != n bool ' Support synchronous PPP' CONFIG_ISDN_PPP CONFIG_ISDN controls if the overall isdn code is built and how it is built. CONFIG_ISDN_PPP selects slhc.o using a boolean statement but the result is really tristate. CONFIG_ISDN CONFIG_ISDN_PPP slhc.o n - n y n n y y y m n n m y m The first config has priority, the second only selects a subset. The dep_tristate rules do not work for this case, we have quite a few in the kernel. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: Handling boolean subsets of objects
[peter] > >select_cond(CONFIG_ISDN slhc.o CONFIG_ISDN_PPP) [kaos] > That is worse, you can select a list of objects, where does the > second config go? You can also have a list of CONFIGs, can you not? In which case you have a parsing problem either way. Distinguishing between a CONFIG option and an object file may not make for a pretty parser, but it is not difficult. Any hacker who names a file CONFIG_FOO.c deserves what he gets. > >Come to think of it, does it really matter what order the CONFIG > >options come in? Isn't this more or less just like dep_tristate, which > >does a boolean AND of the existing options anyway (say m==1, y==3)? > > No, the first config is the main one, the second config selects a > subset of the main code. I still don't see why the code can't just do as dep_tristate does: "if there exists an 'n', return 'n', else if there exists an 'm', return 'm', else return 'y'". Is there a functional reason not to do this, or is it merely a matter of awkwardness in the generated makefile? Peter ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: Handling boolean subsets of objects
On Sun, 28 Oct 2001 20:11:21 -0600, Peter Samuelson <[EMAIL PROTECTED]> wrote: >[kaos] >> select_cond(CONFIG_ISDN CONFIG_ISDN_PPP slhc.o) >> >> Both configs must be selected, either as 'y' or 'm'. The first config >> defined how the object is compiled. I am worried that this might be >> confusing, some users are bound to get the config options in the wrong >> order. Any ideas for a less ambiguous construct? > >select_cond(CONFIG_ISDN slhc.o CONFIG_ISDN_PPP) That is worse, you can select a list of objects, where does the second config go? >Come to think of it, does it really matter what order the CONFIG >options come in? Isn't this more or less just like dep_tristate, which >does a boolean AND of the existing options anyway (say m==1, y==3)? No, the first config is the main one, the second config selects a subset of the main code. CONFIG_FOO=m CONFIG_BAR=y select_cond(CONFIG_FOO CONFIG_BAR object list) is different from select_cond(CONFIG_BAR CONFIG_FOO object list). The first builds the object list as modules, the second as built in. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Handling boolean subsets of objects
[kaos] > select_cond(CONFIG_ISDN CONFIG_ISDN_PPP slhc.o) > > Both configs must be selected, either as 'y' or 'm'. The first config > defined how the object is compiled. I am worried that this might be > confusing, some users are bound to get the config options in the wrong > order. Any ideas for a less ambiguous construct? select_cond(CONFIG_ISDN slhc.o CONFIG_ISDN_PPP) In fact, you *could* overload select() for this, as long as you can differentiate between CONFIG options and targets. Come to think of it, does it really matter what order the CONFIG options come in? Isn't this more or less just like dep_tristate, which does a boolean AND of the existing options anyway (say m==1, y==3)? Peter ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
