[kbuild-devel] howto define one var. to another's value (y/n/m)
Hi, I see this in drivers/parport/Config.in (2.4.19) [not picking on parport; this occurs in many places]. define_tristate CONFIG_PARPORT_PC_CML1 $CONFIG_PARPORT_PC gcml2 (Greg Banks) checker program flags this with: warning:drivers/parport/Config.in:18:symbol CONFIG_PARPORT_PC_CML1 defined to non-literal expression CONFIG_PARPORT_PC and indeed linux/Documentation/kbuild/config-language.txt says that 'define_tristate' takes a value of y, m, or n. [and not variables that have those values, right ??] Is there a simple, clean way to assign one tristate value to another one? Instead of having to do something like: if [ $CONFIG_PARPORT_PC = y ]; then define_tristate CONFIG_PARPORT_PC_CML1 y else if [ $CONFIG_PARPORT_PC = m ]; then define_tristate CONFIG_PARPORT_PC_CML1 m fi fi Thanks, -- ~Randy In general, avoiding problems is better than solving them. -- from #ifdef Considered Harmful, Spencer Collyer, USENIX 1992. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] howto define one var. to another's value (y/n/m)
Randy.Dunlap wrote: Is there a simple, clean way to assign one tristate value to another one? Instead of having to do something like: if [ $CONFIG_PARPORT_PC = y ]; then define_tristate CONFIG_PARPORT_PC_CML1 y else if [ $CONFIG_PARPORT_PC = m ]; then define_tristate CONFIG_PARPORT_PC_CML1 m fi fi Not AFAICT. This is one case where the language spec forbids a useful construct that mostly works. Greg. -- the price of civilisation today is a courageous willingness to prevail, with force, if necessary, against whatever vicious and uncomprehending enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: linux kernel conf 0.8
Hi, On Wed, 9 Oct 2002, Jeff Garzik wrote: Well, my basic preference is * something other than Config.new (the original name in your config system) * something other than Config.in I think it is a mistake to name a totally different format the same name as an older format... even config.in would be better than Config.in... My first plan was to use Config.in, but I can't overwrite the old files yet, so I named it Config.new. Personally I only prefer that it starts with a capital letter (like Makefile, Readme), so it's at the top of a dir listing, but otherwise I don't care much about the name. bye, Roman --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: linux kernel conf 0.8
Roman Zippel wrote: Well, my basic preference is * something other than Config.new (the original name in your config system) * something other than Config.in I think it is a mistake to name a totally different format the same name as an older format... even config.in would be better than Config.in... My first plan was to use Config.in, but I can't overwrite the old files yet, so I named it Config.new. Personally I only prefer that it starts with a capital letter (like Makefile, Readme), so it's at the top of a dir listing, but otherwise I don't care much about the name. Simple and boring but how about Config2.in or Config-2.in ??? Regards, Brendan Simon. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: linux kernel conf 0.8
Hi, On Thu, 10 Oct 2002, Brendan J Simon wrote: As you can see there are soo many guis to choose/use and everyone has there favourite. I suggest that the real work be done outside of the GUI program. ie. seperate GUI and application guts as much as possible. I would use python as the main language but C or even C++ could be used instead as a lot of people hate interpreters, or hate python (prefer perl, php or something else). I'm pretty sure there is no one solution and it comes down to the politics and preferences of the final decision makers up the heirarchy. Because of this I'm planning to make the config backend available as shared library, so it can be loaded by external programs. My QT app then would be basically just the reference implementation. I also want to add a SWIG interface file, so you can even access the config database with your preferred script language. bye, Roman --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: linux kernel conf 0.8
Hi, On Wed, 9 Oct 2002, J.A. Magallon wrote: stick with TCL/TK, like xconfig currently uses ? or is it not sufficient? or just too ugly? What is linux kernel conf written in ? - perl: use perl-gtk (I think there is also a perl-qt) - python: use py-gtk... Use whatever the language gives. I never undestook why use tcl/tk on a perl/python config system. With the exception of the X interface everything is in C, what makes it difficult to use script languages, one always needs some extra development package installed. That's the main reason for creating a library backend, a lot can already be packaged by distributions and only the library needs to be built from the current kernel. bye, Roman --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: linux kernel conf 0.8
On Wed, 9 Oct 2002, Randy.Dunlap wrote: stick with TCL/TK, like xconfig currently uses ? Too ugly. I actually think QT is a fine choice, I just suspect that it's going to cause political issues. My favourite approach by far is to actually not ship anything graphical with the kernel at all, and just hope that the config language syntax is stable enough that different groups can do their own as external packages. The kernel would ship with just the text-based reference implementation (if even that - we could just have a few supporting packages). The only thing I personally really care about is the Config language, since that _has_ to ship with the kernel. Linus PS. And while we're talking about the language - I'd actually prefer the syntax depends on or requires instead of depends, to make it grammatically more correct. And those help-texts should be separated some way so that they don't blend in quite as badly with the command section. Maybe something really syntactic like just replacing the help keyword with a ---help--- keyword. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: linux kernel conf 0.8
Hi, On Wed, 9 Oct 2002, Randy.Dunlap wrote: So I think that you and Roman are close to agreement, when Roman has the library backend ready. Of course someone needs to do a reference implementation with it also, but it doesn't need to ship with the kernel. We ship BK documentation, so shipping a small QT app can't be that problematic. :) Creating the library isn't that difficult (kbuild is currently my problem here) and I'll still have to write some API documentation for it and some glue code to load the library. bye, Roman --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: linux kernel conf 0.8
On Wed, Oct 09, 2002 at 06:29:03PM +0200, Roman Zippel wrote:
Hi,
On Wed, 9 Oct 2002, Randy.Dunlap wrote:
So I think that you and Roman are close to agreement, when Roman
has the library backend ready. Of course someone needs to do a
reference implementation with it also, but it doesn't need to
ship with the kernel.
We ship BK documentation, so shipping a small QT app can't be that
problematic. :)
Creating the library isn't that difficult (kbuild is currently my
problem here) and I'll still have to write some API documentation for it
and some glue code to load the library.
Why don't you just separate the library from the kernel at all, making
it a similar package. We depend on a few external, kernel-specific
packages anyway, and depending on libkconfig wouldn't make the situation
worse. Instead people could keep their tools build one time around in
/usr/{local/,}bin (especially important with qt-monsters :)) and if
there is a change in the language Documentation/Changes would get
updated to the new required version and people had to update it,
similar to the gcc situation for a new development kernel.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: linux kernel conf 0.8
On Wed, Oct 09, 2002 at 02:01:50PM +0200, Roman Zippel wrote: On Tue, 8 Oct 2002, Linus Torvalds wrote: Some things made me go eww (but on the whole details): - I'd prefer the Config.in name, since this has nothing to do with building, and everything to do with configuration. Another suggestion about naming: Take for example drivers/net: cat Config.* | wc = 2149 lines A bit a structure could be needed here. Net.conf = Name equals directory with upper-case first letter - Cover the whole directory, and either implicit or explicit include other .conf files in that directory 3c5xx.conf = All the configuration for the 3c5xxx chipset drivers rrunner.conf = All configuration for rrunner driver So letting the naming convention be directory name with upper-case start letter - as the entry to a directory. Additional configuration in sensibly named configuration files. I do not see the split of configuration happen before 2.6, except in some special cases though. But I wanted to let the naming convention support that. source statements could look like: source driver/net = since Net.conf is implicit But I would prefer the files spelled out. On Tue, 8 Oct 2002, Linus Torvalds wrote: - I assume that the scripts are generated from the current Config.in and Config.help files, and it would make me slightly happier to see the diff as a automatic script + diff to fix it up, just for doc purposes. All this is in the archive. Keep both versions please. It's much easier just to apply a patch, but I see why Linus ask for the other solution. I know what version has preference ;-) Sam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: linux kernel conf 0.8
On Wed, 9 Oct 2002, Sam Ravnborg wrote: Another suggestion about naming: Take for example drivers/net: cat Config.* | wc = 2149 lines A bit a structure could be needed here. Net.conf = Name equals directory with upper-case first letter - Cover the whole directory, and either implicit or explicit include other .conf files in that directory 3c5xx.conf = All the configuration for the 3c5xxx chipset drivers rrunner.conf = All configuration for rrunner driver Good point. Splitting up the big Config.in files is a good idea anyway, and it becomes even more important when the Config.help information was included in the file. However, I disagree with the naming - I'd rather have one common name for the main directory entry than have magic rules like basename of the directory capitalized. I don't want to have to search for it. I also think I'd perfer to have them all start with the same thing, so that (again) it's clear when a directory has multiple configuration files. So instead: how about just Config for the main per-directory configuration file, with sub-config's being Config.3c5xx and Config.rrunner. Linus --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: linux kernel conf 0.8
Hi, On Wed, 9 Oct 2002, Christoph Hellwig wrote: Why don't you just separate the library from the kernel at all, making it a similar package. We depend on a few external, kernel-specific packages anyway, and depending on libkconfig wouldn't make the situation worse. The problem is that the config syntax will continue to evolve and currently I prefer to keep the library close to the matching config files. I think I can keep the basic structure constant, but new options will be added, so IMO it's more likely that a front end works with a newer library than that a library can understand a newer syntax. bye, Roman --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: linux kernel conf 0.8
On Wed, 9 Oct 2002, Sam Ravnborg wrote: ls rrunner* should show me not only the implementation [.c + .h] but also the configuration. I agree with you, but only if we _always_ have one config file per driver. Which is not necessarily the wrong thing to do. But as long as most drivers are in grouped config files, they should be things like Config.3com etc. Looking at existing big config files (video, networking), they do _not_ group according to driver, but according to other criteria (ie PCI card, 100/1000 Mbit, 3com, Sparc-specific etc). Linus --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: linux kernel conf 0.8
[Roman Zippel] The problem is that the config syntax will continue to evolve and currently I prefer to keep the library close to the matching config files. I think I can keep the basic structure constant, but new options will be added, so IMO it's more likely that a front end works with a newer library than that a library can understand a newer syntax. Besides which, I think it is ridiculous that one would have to download and install a kernel configurator just to build a kernel. Current minimum requirements for compiling the thing are gcc, binutils and GNU make. The kernel can't very well ship a copy of any of those, because (a) they're huge and (b) they're useful for many things other than building kernels. Roman's library is neither. (And no, modutils isn't a counterexample - you can build, install and run a kernel without it.) Peter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: linux kernel conf 0.8
On Wed, Oct 09, 2002 at 11:47:16AM -0700, Linus Torvalds wrote: On Wed, 9 Oct 2002, Sam Ravnborg wrote: ls rrunner* should show me not only the implementation [.c + .h] but also the configuration. I agree with you, but only if we _always_ have one config file per driver. Which is not necessarily the wrong thing to do. The question here is what we aim at. And we aim at getting the configuration less centralized as compared with what we have today. I still remember the thread were you suggested the drivers.conf principle. And I liked it then, and I like it today. What I had to add a new driver to the kernel was to add the following three files: driver.c, driver,h driver.conf Even the makefile stuff could be retreived from driver.conf. But as long as most drivers are in grouped config files, they should be things like Config.3com etc. Looking at existing big config files (video, networking), they do _not_ group according to driver, but according to other criteria (ie PCI card, 100/1000 Mbit, 3com, Sparc-specific etc). But there is a good reason why they do it. Take a look at dirvers/video/Config.in for example. See the size of the big if's. They span several pages if not the whole file. Why they do this is simple. Only check for PCI once, and group all PCI stuff there. With the syntax Roman propose we see instead that _each_ config option check for PCI. Which is good IMHO. The most logical grouping should be utilised, and grouping based on bustype is not the grouping that we aim for. We aim to group similar drivers together, if they happens to be for the same bus or not should not matter. But the whole argumentation boils down to something rahter simple: 1) Shall we group configuration files together 2) Shall we group related files together And in mu opinion, if we decide not to use the filesystem namespace to group similar files, then the incentive to break things out in smaller files are mostly gone. Except in the case where I sumbit a new driver and want to keep my changes to the kernel file to a bare minimum, but then why not let the config file be grouped with the rest of the driver. Well I have raised my points, if you still prefer Config.* then let's stick to that. This should but be the reason to delay lkc-roman. Sam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: linux kernel conf 0.8
On Wed, Oct 09, 2002 at 12:28:44PM -0700, Randy.Dunlap wrote: The kernel would still have the text-mode configurator. The way I read the original post by Christoph Hellwig - nope. If the kernel config library is outside the kernel then the text-mode versions will fail as well. Recall that the text-mode version are no longer shell scripts, but based on a nice YACC grammar and coded in C. I do not want to go somewhere for special tools just to configure the kernel. Basic stuff such as make and gcc is ok to locate elsewhere - in specific versions as well. But not some basic kernel only configurator. Sam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
