Re: distributed module configuration
Hi! > > Does this fit what you had in mind? > > Yes it does. > > Now I'll ask if you think embedding this information in one of the C > files for a module would be even nicer? I kind of like to be able to grep over just Kconfig files, to find out what is going on... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: distributed module configuration [Was: Announce: Linux-next (Or Andrew's dream :-))]
On Thu, Feb 14, 2008 at 01:56:13AM +0100, Roman Zippel wrote: > Hi, > > On Wednesday 13. February 2008, Sam Ravnborg wrote: > > > config foo > > tristate "do you want foo?" > > depends on USB && BAR > > module > > obj-$(CONFIG_FOO) += foo.o > > foo-y := file1.o file2.o > > help > > foo will allow you to explode your PC > > I'm more thinking about something like this: > > module foo [FOO] > tristate "do you want foo?" > depends on USB && BAR > source file1.c > source file2.c if BAZ > > Avoiding direct Makefile fragments would give us far more flexibility in the > final Makefile output. Much better and now I see it I recall you posted something along these lines before. Is this something that you plan to look into implementing? I can do the kbuild bits but I need you to do the kconfig stuff (which is by far the biggest effort too). It would be much appreciated to get this. Sam - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: distributed module configuration [Was: Announce: Linux-next (Or Andrew's dream :-))]
On Thu, 14 Feb 2008, Roman Zippel wrote:
> On Wednesday 13. February 2008, Sam Ravnborg wrote:
> > config foo
> > tristate "do you want foo?"
> > depends on USB && BAR
> > module
> > obj-$(CONFIG_FOO) += foo.o
> > foo-y := file1.o file2.o
> > help
> > foo will allow you to explode your PC
>
> I'm more thinking about something like this:
>
> module foo [FOO]
> tristate "do you want foo?"
> depends on USB && BAR
> source file1.c
> source file2.c if BAZ
And we can finally distinguish between
config bar
bool "do you want bar?"
for boolean options and
module baz
bool "do you want baz?"
for modules that cannot be modular?
And we can make `depends on' do the right thing for dependencies on modules
that are modular (cfr. e.g. commit e11a6c236b3070ed05b079f91a9b3defa48b54d3,
[VIDEO]: XVR500 and XVR2500 require FB=y)?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: distributed module configuration [Was: Announce: Linux-next (Or Andrew's dream :-))]
Hi, On Wednesday 13. February 2008, Sam Ravnborg wrote: > config foo > tristate "do you want foo?" > depends on USB && BAR > module > obj-$(CONFIG_FOO) += foo.o > foo-y := file1.o file2.o > help > foo will allow you to explode your PC I'm more thinking about something like this: module foo [FOO] tristate "do you want foo?" depends on USB && BAR source file1.c source file2.c if BAZ Avoiding direct Makefile fragments would give us far more flexibility in the final Makefile output. > And we could introduce support for > > source "drivers/net/Kconfig.*" > > But then we would have to make the kconfig step mandatory > for each build as we would otherwise not know if there > were added any Kconfig files. That's a real problem and it would be a step back of what we have right now, so I'm not exactly comfortable with it. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: distributed module configuration
Sam Ravnborg wrote: On Wed, Feb 13, 2008 at 12:54:33AM -0800, David Miller wrote: From: Sam Ravnborg <[EMAIL PROTECTED]> Date: Wed, 13 Feb 2008 09:45:41 +0100 So we could do: config foo tristate "do you want foo?" depends on USB && BAR module obj-$(CONFIG_FOO) += foo.o foo-y := file1.o file2.o help foo will allow you to explode your PC ... Does this fit what you had in mind? Yes it does. Now I'll ask if you think embedding this information in one of the C files for a module would be even nicer? I have no good idea for the syntax and I and not sure what is gained by reducing a driver with one file. Agreed - simple drivers would then be a single file - and thats a good argument. I like the Sam proposal, but maybe we can simplify the rules on "module" segment: some informations are often redundant, dependencies are sometime calculated by config part and sometime by Makefile (and sometime in the Makefile there are some wrong hacks). I would really like a good section like: module foo : file1.o file2.o and let the complex rules in the normal Makefile (which is also good because the complex rules are often not specific to a single driver). But I don't like merging all info in a single file: - not so clean in case of multiple source-file driver - it would be more complex the "copy and paste" from other drivers: most developers are not comfortable with Kconfig and Makefile, so easy to grep others Kconfig/Makefile could help developers not do do strange/wrong hacks. ciao cate - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: distributed module configuration
From: Sam Ravnborg <[EMAIL PROTECTED]> Date: Wed, 13 Feb 2008 10:04:51 +0100 > On Wed, Feb 13, 2008 at 12:54:33AM -0800, David Miller wrote: > > Also, we need to make sure we can properly handle top-level > > container-like items. For example, where would menuconfigs like > > NETDEV_1 go if we adopt this kind of scheme? > > If it makes sense to group stuff inside a menuconfig it would > also make sense to put the same modules in a subdirectory. > And then we would have the menuconfig in the Kconfig > file that would source the others. Sounds good to me. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: distributed module configuration
On Wed, Feb 13, 2008 at 12:54:33AM -0800, David Miller wrote: > From: Sam Ravnborg <[EMAIL PROTECTED]> > Date: Wed, 13 Feb 2008 09:45:41 +0100 > > > So we could do: > > > > config foo > > tristate "do you want foo?" > > depends on USB && BAR > > module > > obj-$(CONFIG_FOO) += foo.o > > foo-y := file1.o file2.o > > help > > foo will allow you to explode your PC > ... > > Does this fit what you had in mind? > > Yes it does. > > Now I'll ask if you think embedding this information in one of the C > files for a module would be even nicer? I have no good idea for the syntax and I and not sure what is gained by reducing a driver with one file. Agreed - simple drivers would then be a single file - and thats a good argument. > > Also, we need to make sure we can properly handle top-level > container-like items. For example, where would menuconfigs like > NETDEV_1 go if we adopt this kind of scheme? If it makes sense to group stuff inside a menuconfig it would also make sense to put the same modules in a subdirectory. And then we would have the menuconfig in the Kconfig file that would source the others. So I do not see this as an issue for the 'embedded' syntax described above. Sam - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: distributed module configuration
From: Sam Ravnborg <[EMAIL PROTECTED]> Date: Wed, 13 Feb 2008 09:45:41 +0100 > So we could do: > > config foo > tristate "do you want foo?" > depends on USB && BAR > module > obj-$(CONFIG_FOO) += foo.o > foo-y := file1.o file2.o > help > foo will allow you to explode your PC ... > Does this fit what you had in mind? Yes it does. Now I'll ask if you think embedding this information in one of the C files for a module would be even nicer? Also, we need to make sure we can properly handle top-level container-like items. For example, where would menuconfigs like NETDEV_1 go if we adopt this kind of scheme? - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
