[PATCH] 9p: fix compile error if !CONFIG_SYSCTL

[PATCH] 9p: fix compile error if !CONFIG_SYSCTL

[Andreas Herrmann]

Fix compile error if !CONFIG_SYSCTL:

    ...
  LD      .tmp_vmlinux1
net/built-in.o: In function `init_p9':
net/9p/mod.c:59: undefined reference to `p9_sysctl_register'
net/built-in.o: In function `exit_p9':
net/9p/mod.c:75: undefined reference to `p9_sysctl_unregister'
make: *** [.tmp_vmlinux1] Error 1
    ...

Signed-off-by: Andreas Herrmann <aherrman@arcor.de>
---
 include/net/9p/9p.h |    4 ++++
 net/9p/mod.c        |    4 ++++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/include/net/9p/9p.h b/include/net/9p/9p.h
index 88884d3..f723a03 100644
--- a/include/net/9p/9p.h
+++ b/include/net/9p/9p.h
@@ -412,6 +412,10 @@ int p9_idpool_check(int id, struct p9_idpool *p);
 
 int p9_error_init(void);
 int p9_errstr2errno(char *, int);
+
+#ifdef CONFIG_SYSCTL
 int __init p9_sysctl_register(void);
 void __exit p9_sysctl_unregister(void);
+#endif
+
 #endif /* NET_9P_H */
diff --git a/net/9p/mod.c b/net/9p/mod.c
index 4f9e1d2..b4d435c 100644
--- a/net/9p/mod.c
+++ b/net/9p/mod.c
@@ -56,11 +56,13 @@ static int __init init_p9(void)
 		return ret;
 	}
 
+#ifdef CONFIG_SYSCTL
 	ret = p9_sysctl_register();
 	if (ret) {
 		printk(KERN_WARNING "9p: registering sysctl failed\n");
 		return ret;
 	}
+#endif
 
 	return ret;
 }
@@ -72,7 +74,9 @@ static int __init init_p9(void)
 
 static void __exit exit_p9(void)
 {
+#ifdef CONFIG_SYSCTL
 	p9_sysctl_unregister();
+#endif
 	p9_mux_global_exit();
 }
 
-- 
1.5.3

Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL

[roel]

Andreas Herrmann wrote:
> Fix compile error if !CONFIG_SYSCTL:
> 
>     ...
>   LD      .tmp_vmlinux1
> net/built-in.o: In function `init_p9':
> net/9p/mod.c:59: undefined reference to `p9_sysctl_register'
> net/built-in.o: In function `exit_p9':
> net/9p/mod.c:75: undefined reference to `p9_sysctl_unregister'
> make: *** [.tmp_vmlinux1] Error 1
>     ...
> 
> Signed-off-by: Andreas Herrmann <aherrman@arcor.de>
> ---
>  include/net/9p/9p.h |    4 ++++
>  net/9p/mod.c        |    4 ++++
>  2 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/include/net/9p/9p.h b/include/net/9p/9p.h
> index 88884d3..f723a03 100644
> --- a/include/net/9p/9p.h
> +++ b/include/net/9p/9p.h
> @@ -412,6 +412,10 @@ int p9_idpool_check(int id, struct p9_idpool *p);
>  
>  int p9_error_init(void);
>  int p9_errstr2errno(char *, int);
> +
> +#ifdef CONFIG_SYSCTL
>  int __init p9_sysctl_register(void);
>  void __exit p9_sysctl_unregister(void);
> +#endif
> +
>  #endif /* NET_9P_H */
> diff --git a/net/9p/mod.c b/net/9p/mod.c
> index 4f9e1d2..b4d435c 100644
> --- a/net/9p/mod.c
> +++ b/net/9p/mod.c
> @@ -56,11 +56,13 @@ static int __init init_p9(void)
>  		return ret;
>  	}
>  
> +#ifdef CONFIG_SYSCTL
>  	ret = p9_sysctl_register();
>  	if (ret) {
>  		printk(KERN_WARNING "9p: registering sysctl failed\n");
>  		return ret;
>  	}
> +#endif
>  
>  	return ret;
>  }
> @@ -72,7 +74,9 @@ static int __init init_p9(void)
>  
>  static void __exit exit_p9(void)
>  {
> +#ifdef CONFIG_SYSCTL
>  	p9_sysctl_unregister();
> +#endif
>  	p9_mux_global_exit();
>  }
>  
isn't it nicer to do something like this instead?
diff --git a/net/9p/sysctl.c b/net/9p/sysctl.c
index 8b61027..e199865 100644
--- a/net/9p/sysctl.c
+++ b/net/9p/sysctl.c
@@ -68,14 +68,17 @@ static struct ctl_table_header *p9_table_header;
 
 int __init p9_sysctl_register(void)
 {
+#ifdef CONFIG_SYSCTL
 	p9_table_header = register_sysctl_table(p9_ctl_table);
 	if (!p9_table_header)
 		return -ENOMEM;
-
+#endif
 	return 0;
 }
 
 void __exit p9_sysctl_unregister(void)
 {
+#ifdef CONFIG_SYSCTL
 	 unregister_sysctl_table(p9_table_header);
+#endif
 }

Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL

[Andreas Herrmann]

On Tue, Sep 18, 2007 at 08:53:19PM +0200, roel wrote:
> Andreas Herrmann wrote:
> > Fix compile error if !CONFIG_SYSCTL:
> > 
> >     ...
> >   LD      .tmp_vmlinux1
> > net/built-in.o: In function `init_p9':
> > net/9p/mod.c:59: undefined reference to `p9_sysctl_register'
> > net/built-in.o: In function `exit_p9':
> > net/9p/mod.c:75: undefined reference to `p9_sysctl_unregister'
> > make: *** [.tmp_vmlinux1] Error 1
> >     ...
> >  
> isn't it nicer to do something like this instead?

No.

> diff --git a/net/9p/sysctl.c b/net/9p/sysctl.c
> index 8b61027..e199865 100644
> --- a/net/9p/sysctl.c
> +++ b/net/9p/sysctl.c
> @@ -68,14 +68,17 @@ static struct ctl_table_header *p9_table_header;
>  
>  int __init p9_sysctl_register(void)
>  {
> +#ifdef CONFIG_SYSCTL
>  	p9_table_header = register_sysctl_table(p9_ctl_table);
>  	if (!p9_table_header)
>  		return -ENOMEM;
> -
> +#endif
>  	return 0;
>  }
>  
>  void __exit p9_sysctl_unregister(void)
>  {
> +#ifdef CONFIG_SYSCTL
>  	 unregister_sysctl_table(p9_table_header);
> +#endif
>  }

The problem is not that (un)register_sysctl_table were not defined
if !CONFIG_SYSCTL. There are stubs in kernel/sysctl.c for this case.
I.e. your patch is superfluous.

The point is, 9p/sysctl.c is compiled iff CONFIG_SYSCTL is set.
See net/9p/Makefile ...


Regards,

Andreas

Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL

[Andrew Morton]

On Tue, 18 Sep 2007 10:05:37 +0200 Andreas Herrmann <aherrman@arcor.de> wrote:

> Fix compile error if !CONFIG_SYSCTL:
> 
>     ...
>   LD      .tmp_vmlinux1
> net/built-in.o: In function `init_p9':
> net/9p/mod.c:59: undefined reference to `p9_sysctl_register'
> net/built-in.o: In function `exit_p9':
> net/9p/mod.c:75: undefined reference to `p9_sysctl_unregister'
> make: *** [.tmp_vmlinux1] Error 1
>     ...

A better fix would be

--- a/include/net/9p/9p.h~9p-fix-compile-error-if-config_sysctl
+++ a/include/net/9p/9p.h
@@ -412,6 +412,17 @@ int p9_idpool_check(int id, struct p9_id
 
 int p9_error_init(void);
 int p9_errstr2errno(char *, int);
+#ifdef CONFIG_SYSCTL
 int __init p9_sysctl_register(void);
 void __exit p9_sysctl_unregister(void);
+#else
+static inline int p9_sysctl_register(void)
+{
+	return 0;
+}
+
+static inline void p9_sysctl_unregister(void)
+{
+}
+
 #endif /* NET_9P_H */
diff -puN net/9p/mod.c~9p-fix-compile-error-if-config_sysctl net/9p/mod.c
_

I struggled for five minutes trying to work out how to make CONFIG_SYSCTL
go away and gave up in disgust.

God I hate select.

Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL

[Andreas Herrmann]

On Wed, Sep 19, 2007 at 11:31:10PM -0700, Andrew Morton wrote:
> On Tue, 18 Sep 2007 10:05:37 +0200 Andreas Herrmann <aherrman@arcor.de> wrote:
> 
> > Fix compile error if !CONFIG_SYSCTL:
> > 
> >     ...
> >   LD      .tmp_vmlinux1
> > net/built-in.o: In function `init_p9':
> > net/9p/mod.c:59: undefined reference to `p9_sysctl_register'
> > net/built-in.o: In function `exit_p9':
> > net/9p/mod.c:75: undefined reference to `p9_sysctl_unregister'
> > make: *** [.tmp_vmlinux1] Error 1
> >     ...
> 
> A better fix would be

But only if you add another
    #endif /* CONFIG_SYSCTL */

Right?
;-)

> 
> --- a/include/net/9p/9p.h~9p-fix-compile-error-if-config_sysctl
> +++ a/include/net/9p/9p.h
> @@ -412,6 +412,17 @@ int p9_idpool_check(int id, struct p9_id
>  
>  int p9_error_init(void);
>  int p9_errstr2errno(char *, int);
> +#ifdef CONFIG_SYSCTL
>  int __init p9_sysctl_register(void);
>  void __exit p9_sysctl_unregister(void);
> +#else
> +static inline int p9_sysctl_register(void)
> +{
> +	return 0;
> +}
> +
> +static inline void p9_sysctl_unregister(void)
> +{
> +}
> +
>  #endif /* NET_9P_H */
> diff -puN net/9p/mod.c~9p-fix-compile-error-if-config_sysctl net/9p/mod.c
> _
> 
> I struggled for five minutes trying to work out how to make CONFIG_SYSCTL
> go away and gave up in disgust.
> 
> God I hate select.

Hmm, you mean to completely avoid "#ifdef CONFIG_SYSCTL" in the net/p9 code?
How about below patch, which just merges net/9p/sysctl.c into net/9p/mod.c.


Regards,

Andreas

--
Merge net/p9/sysctl.c into net/p9/mod.c to avoid build errors
if !CONFIG_SYSCTL.

Signed-off-by: Andreas Herrmann <aherrman@arcor.de>
---
 include/net/9p/9p.h |    2 -
 net/9p/Makefile     |    4 +--
 net/9p/mod.c        |   54 +++++++++++++++++++++++++++++----
 net/9p/sysctl.c     |   81 ---------------------------------------------------
 4 files changed, 48 insertions(+), 93 deletions(-)
 delete mode 100644 net/9p/sysctl.c

diff --git a/include/net/9p/9p.h b/include/net/9p/9p.h
index 88884d3..f69992f 100644
--- a/include/net/9p/9p.h
+++ b/include/net/9p/9p.h
@@ -412,6 +412,4 @@ int p9_idpool_check(int id, struct p9_idpool *p);
 
 int p9_error_init(void);
 int p9_errstr2errno(char *, int);
-int __init p9_sysctl_register(void);
-void __exit p9_sysctl_unregister(void);
 #endif /* NET_9P_H */
diff --git a/net/9p/Makefile b/net/9p/Makefile
index 85b3a78..488026a 100644
--- a/net/9p/Makefile
+++ b/net/9p/Makefile
@@ -8,6 +8,4 @@ obj-$(CONFIG_NET_9P) := 9pnet.o
 	conv.o \
 	error.o \
 	fcprint.o \
-	util.o \
-
-9pnet-$(CONFIG_SYSCTL) += sysctl.o
+	util.o
diff --git a/net/9p/mod.c b/net/9p/mod.c
index 4f9e1d2..8d4ce1b 100644
--- a/net/9p/mod.c
+++ b/net/9p/mod.c
@@ -24,6 +24,10 @@
  *
  */
 
+#include <linux/kernel.h>
+#include <linux/mm.h>
+#include <linux/sysctl.h>
+#include <linux/init.h>
 #include <linux/module.h>
 #include <linux/moduleparam.h>
 #include <net/9p/9p.h>
@@ -37,8 +41,44 @@ MODULE_PARM_DESC(debug, "9P debugging level");
 
 extern int p9_mux_global_init(void);
 extern void p9_mux_global_exit(void);
-extern int p9_sysctl_register(void);
-extern void p9_sysctl_unregister(void);
+
+static struct ctl_table p9_table[] = {
+#ifdef CONFIG_NET_9P_DEBUG
+	{
+		.ctl_name       = CTL_UNNUMBERED,
+		.procname       = "debug",
+		.data           = &p9_debug_level,
+		.maxlen         = sizeof(int),
+		.mode           = 0644,
+		.proc_handler   = &proc_dointvec
+	},
+#endif
+	{},
+};
+
+static struct ctl_table p9_net_table[] = {
+	{
+		.ctl_name	= CTL_UNNUMBERED,
+		.procname	= "9p",
+		.maxlen		= 0,
+		.mode		= 0555,
+		.child		= p9_table,
+	},
+	{},
+};
+
+static struct ctl_table p9_ctl_table[] = {
+	{
+		.ctl_name	= CTL_NET,
+		.procname	= "net",
+		.maxlen		= 0,
+		.mode		= 0555,
+		.child		= p9_net_table,
+	},
+	{},
+};
+
+static struct ctl_table_header *p9_table_header;
 
 /**
  * v9fs_init - Initialize module
@@ -56,13 +96,13 @@ static int __init init_p9(void)
 		return ret;
 	}
 
-	ret = p9_sysctl_register();
-	if (ret) {
+	p9_table_header = register_sysctl_table(p9_ctl_table);
+	if (!p9_table_header) {
 		printk(KERN_WARNING "9p: registering sysctl failed\n");
-		return ret;
+		return -ENOMEM;
 	}
 
-	return ret;
+	return 0;
 }
 
 /**
@@ -72,7 +112,7 @@ static int __init init_p9(void)
 
 static void __exit exit_p9(void)
 {
-	p9_sysctl_unregister();
+	unregister_sysctl_table(p9_table_header);
 	p9_mux_global_exit();
 }
 
diff --git a/net/9p/sysctl.c b/net/9p/sysctl.c
deleted file mode 100644
index 8b61027..0000000
--- a/net/9p/sysctl.c
+++ /dev/null
@@ -1,81 +0,0 @@
-/*
- *  net/9p/sysctl.c
- *
- *  9P sysctl interface
- *
- *  Copyright (C) 2007 by Latchesar Ionkov <lucho@ionkov.net>
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License version 2
- *  as published by the Free Software Foundation.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to:
- *  Free Software Foundation
- *  51 Franklin Street, Fifth Floor
- *  Boston, MA  02111-1301  USA
- *
- */
-
-#include <linux/kernel.h>
-#include <linux/mm.h>
-#include <linux/sysctl.h>
-#include <linux/init.h>
-#include <net/9p/9p.h>
-
-static struct ctl_table p9_table[] = {
-#ifdef CONFIG_NET_9P_DEBUG
-	{
-		.ctl_name       = CTL_UNNUMBERED,
-		.procname       = "debug",
-		.data           = &p9_debug_level,
-		.maxlen         = sizeof(int),
-		.mode           = 0644,
-		.proc_handler   = &proc_dointvec
-	},
-#endif
-	{},
-};
-
-static struct ctl_table p9_net_table[] = {
-	{
-		.ctl_name	= CTL_UNNUMBERED,
-		.procname	= "9p",
-		.maxlen		= 0,
-		.mode		= 0555,
-		.child		= p9_table,
-	},
-	{},
-};
-
-static struct ctl_table p9_ctl_table[] = {
-	{
-		.ctl_name	= CTL_NET,
-		.procname	= "net",
-		.maxlen		= 0,
-		.mode		= 0555,
-		.child		= p9_net_table,
-	},
-	{},
-};
-
-static struct ctl_table_header *p9_table_header;
-
-int __init p9_sysctl_register(void)
-{
-	p9_table_header = register_sysctl_table(p9_ctl_table);
-	if (!p9_table_header)
-		return -ENOMEM;
-
-	return 0;
-}
-
-void __exit p9_sysctl_unregister(void)
-{
-	 unregister_sysctl_table(p9_table_header);
-}
-- 
1.5.3

Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL

[Nick Piggin]

On Thursday 20 September 2007 16:31, Andrew Morton wrote:

> I struggled for five minutes trying to work out how to make CONFIG_SYSCTL
> go away and gave up in disgust.
>
> God I hate select.

IMO a better implementation would result in a notification / confirmation of
turning on new items, and the ability to deselect options which will also
confirm to deselect dependants. Like most other systems that have similar
problem to solve.

Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL

[Linus Torvalds]

On Fri, 28 Sep 2007, Nick Piggin wrote:
> >
> > God I hate select.
> 
> IMO a better implementation would result in a notification / confirmation of
> turning on new items, and the ability to deselect options which will also
> confirm to deselect dependants. Like most other systems that have similar
> problem to solve.

Actually, the *really* nice thing to do would be to just add the reason 
something got enabled into the ".config" file.

IOW, wouldn't it be nice if the .config file just said

	...
	CONFIG_ACPI=y		# selected by X86_64_ACPI_NUMA
	CONFIG_ACPI_PROCFS=y	# user choice
	...

etc, since the config process actually does know these things?

That way, there's always a fairly straightforward way to see why some 
configuration is the way it is (and the .config file is not only useful 
for "make oldconfig", it's also what normally gets passed around for bug 
reports, and is part of distro kernel packages etc, so it would seem to be 
the right place, no?)

		Linus

Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL

[Nick Piggin]

On Saturday 29 September 2007 00:34, Linus Torvalds wrote:
> On Fri, 28 Sep 2007, Nick Piggin wrote:
> > > God I hate select.
> >
> > IMO a better implementation would result in a notification / confirmation
> > of turning on new items, and the ability to deselect options which will
> > also confirm to deselect dependants. Like most other systems that have
> > similar problem to solve.
>
> Actually, the *really* nice thing to do would be to just add the reason
> something got enabled into the ".config" file.
>
> IOW, wouldn't it be nice if the .config file just said
>
> 	...
> 	CONFIG_ACPI=y		# selected by X86_64_ACPI_NUMA
> 	CONFIG_ACPI_PROCFS=y	# user choice
> 	...
>
> etc, since the config process actually does know these things?

Sure, that would probably be pretty trivial to implement too, and
would solve most problems for kernel devs.

At a level up from that, I think ease of use could be improved with
a package manager-type chained-selection/deselection feature in
the config tools.

Not that I'm volunteering to implement either ;)

>
> That way, there's always a fairly straightforward way to see why some
> configuration is the way it is (and the .config file is not only useful
> for "make oldconfig", it's also what normally gets passed around for bug
> reports, and is part of distro kernel packages etc, so it would seem to be
> the right place, no?)
>
> 		Linus

Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL

[Arjan van de Ven]

On Fri, 28 Sep 2007 10:05:33 +1000
> Sure, that would probably be pretty trivial to implement too, and
> would solve most problems for kernel devs.
> 
> At a level up from that, I think ease of use could be improved with
> a package manager-type chained-selection/deselection feature in
> the config tools.
> 
only if you make it Aunt-Tilly friendly

/me runs like hell

Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL

[Elyse M. Grasso]

On Thursday 27 September 2007, Nick Piggin wrote:
> On Saturday 29 September 2007 00:34, Linus Torvalds wrote:
> > On Fri, 28 Sep 2007, Nick Piggin wrote:
> > > > God I hate select.
> > >
> > > IMO a better implementation would result in a notification / 
confirmation
> > > of turning on new items, and the ability to deselect options which will
> > > also confirm to deselect dependants. Like most other systems that have
> > > similar problem to solve.
> >
> > Actually, the *really* nice thing to do would be to just add the reason
> > something got enabled into the ".config" file.
> >
> > IOW, wouldn't it be nice if the .config file just said
> >
> > 	...
> > 	CONFIG_ACPI=y		# selected by X86_64_ACPI_NUMA
> > 	CONFIG_ACPI_PROCFS=y	# user choice
> > 	...
> >
> > etc, since the config process actually does know these things?
> 
> Sure, that would probably be pretty trivial to implement too, and
> would solve most problems for kernel devs.
> 
> At a level up from that, I think ease of use could be improved with
> a package manager-type chained-selection/deselection feature in
> the config tools.
> 
> Not that I'm volunteering to implement either ;)
> 
> >
> > That way, there's always a fairly straightforward way to see why some
> > configuration is the way it is (and the .config file is not only useful
> > for "make oldconfig", it's also what normally gets passed around for bug
> > reports, and is part of distro kernel packages etc, so it would seem to be
> > the right place, no?)
> >
> > 		Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Adding the comments to the .config files sounds like a good project for a 
comparative newbie. By the end of next week I should have hardware available 
for experimental kernel builds. (And also some free wetware cycles.) 

Are there any other requirements for formatting I should consider? 

In a case where option A is specified by option B which is specified by option 
C which is specified by option D, should the comment on A mention B, or D or 
all three items in the chain? 

-- 
Elyse Grasso

http://www.data-raptors.com    Computers and Technology
http://www.astraltrading.com   Divination and Science Fiction
http://www.data-raptors.com/global-cgi-bin/cgiwrap/emgrasso/blosxom.cgi WebLog

A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

[Oleg Verych]

* Fri, 28 Sep 2007 11:12:51 -0600

> On Thursday 27 September 2007, Nick Piggin wrote:
>> On Saturday 29 September 2007 00:34, Linus Torvalds wrote:
>> > On Fri, 28 Sep 2007, Nick Piggin wrote:
>> > > > God I hate select.
>> > >
>> > > IMO a better implementation would result in a notification / 
> confirmation
>> > > of turning on new items, and the ability to deselect options which will
>> > > also confirm to deselect dependants. Like most other systems that have
>> > > similar problem to solve.
>> >
>> > Actually, the *really* nice thing to do would be to just add the reason
>> > something got enabled into the ".config" file.
[]
>> > 	CONFIG_ACPI=y		# selected by X86_64_ACPI_NUMA
>> > 	CONFIG_ACPI_PROCFS=y	# user choice
>> > 	...
[]
>> Sure, that would probably be pretty trivial to implement too, and
>> would solve most problems for kernel devs.
>> 
>> At a level up from that, I think ease of use could be improved with
>> a package manager-type chained-selection/deselection feature in
>> the config tools.
>> 
>> Not that I'm volunteering to implement either ;)
>> 
>> >
>> > That way, there's always a fairly straightforward way to see why some
>> > configuration is the way it is (and the .config file is not only useful
>> > for "make oldconfig", it's also what normally gets passed around for bug
>> > reports, and is part of distro kernel packages etc, so it would seem to be
>> > the right place, no?)
>> >
>> > 		Linus
[]
> Adding the comments to the .config files sounds like a good project for a 
> comparative newbie. By the end of next week I should have hardware available 
> for experimental kernel builds. (And also some free wetware cycles.) 
>
> Are there any other requirements for formatting I should consider? 

No. Not another semi-newbie and/or semi-halfway done job, please.

I'm pretty sure, that Linus is proposing that only after manual
editing of/looking into the `.config' after `make oldconfig`.

Before you will consider anything, please, check recent LKML (kbuild
rewrite) and kbuild-devel(years 2001-2002) archives (assuming, you have
experience with any build/conf things).

Today's kconfig was proposed and accepted in a very unpleasant
circumstances, has very poor design, development and no working
alternative (for 5+ years now).

The basics, i'm trying to put into design of the new kconfig, as part of
my kbuild (already described a bit)/kconfig rewrite are:

* flexible configuration development(kdevs) and process(kusers)

  + shell-like[0] (not like CML1, which is just shell) scripting, allowing
    to extend easily (if there is no one available) capabilities,
    config values or actions for particular sub-system or compilation
    unit,
    
  [0] if somebody would like to see *a* shell-like scripting:
      ftp://flower.upol.cz/geloiwa/src/usr/local/etc/geloiwa/iwant

  + duplex travelling, multi- looking at/changing of config items,

  + flexible, yet built-able, connections in dependency chain (tree,
    graph, whatever);

* resulting config file capable of producing exact config results of the
  build on any other setup
  (e.g. no ARCH=, CROSS_*, *_FLAGS *kbuild* things);

* checking tool for particular config patterns (for bug reports)

* system itself must be done with minimum requirements for C libraries
  (no ncurses) and tools (no `perl`, no `python`, no `make`).

> In a case where option A is specified by option B which is specified by option 
> C which is specified by option D, should the comment on A mention B, or D or 
> all three items in the chain? 

Fsck it. All must be done by a machine with maximum comfort of users (not
particularly humans), even for those, who like to edit config like so:

`sed -i 's/SYSFS=y/SYSFS="please, NO!!!"/' .config`

--
-o--=O`C
 #oo'L O
<___=E M

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

[Sam Ravnborg]

Hi Oleg.
> 
> Today's kconfig was proposed and accepted in a very unpleasant
> circumstances, has very poor design, development and no working
> alternative (for 5+ years now).

I have read all your mails about this subject - but I still miss what
is so bad about current design.

Could you try to stay down on the earth and be very specific about
what you see as so bad in current design.
"With stay down on earth" I try to say that what I have read before
I could not dechiper so be specific, please.

	Sam

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

[Elyse M. Grasso]

On Monday 01 October 2007, Oleg Verych wrote:
> * Fri, 28 Sep 2007 11:12:51 -0600
> 
> > On Thursday 27 September 2007, Nick Piggin wrote:
> >> On Saturday 29 September 2007 00:34, Linus Torvalds wrote:
> >> > On Fri, 28 Sep 2007, Nick Piggin wrote:
> >> > > > God I hate select.
> >> > >
> >> > > IMO a better implementation would result in a notification / 
> > confirmation
> >> > > of turning on new items, and the ability to deselect options which 
will
> >> > > also confirm to deselect dependants. Like most other systems that 
have
> >> > > similar problem to solve.
> >> >
> >> > Actually, the *really* nice thing to do would be to just add the reason
> >> > something got enabled into the ".config" file.
> []
> >> > 	CONFIG_ACPI=y		# selected by X86_64_ACPI_NUMA
> >> > 	CONFIG_ACPI_PROCFS=y	# user choice
> >> > 	...
> []
> >> Sure, that would probably be pretty trivial to implement too, and
> >> would solve most problems for kernel devs.
> >> 
> >> At a level up from that, I think ease of use could be improved with
> >> a package manager-type chained-selection/deselection feature in
> >> the config tools.
> >> 
> >> Not that I'm volunteering to implement either ;)
> >> 
> >> >
> >> > That way, there's always a fairly straightforward way to see why some
> >> > configuration is the way it is (and the .config file is not only useful
> >> > for "make oldconfig", it's also what normally gets passed around for 
bug
> >> > reports, and is part of distro kernel packages etc, so it would seem to 
be
> >> > the right place, no?)
> >> >
> >> > 		Linus
> []
> > Adding the comments to the .config files sounds like a good project for a 
> > comparative newbie. By the end of next week I should have hardware 
available 
> > for experimental kernel builds. (And also some free wetware cycles.) 
> >
> > Are there any other requirements for formatting I should consider? 
> 
> No. Not another semi-newbie and/or semi-halfway done job, please.
> 
> I'm pretty sure, that Linus is proposing that only after manual
> editing of/looking into the `.config' after `make oldconfig`.
> 
> Before you will consider anything, please, check recent LKML (kbuild
> rewrite) and kbuild-devel(years 2001-2002) archives (assuming, you have
> experience with any build/conf things).
> 
> Today's kconfig was proposed and accepted in a very unpleasant
> circumstances, has very poor design, development and no working
> alternative (for 5+ years now).
> 
> The basics, i'm trying to put into design of the new kconfig, as part of
> my kbuild (already described a bit)/kconfig rewrite are:
> 
> * flexible configuration development(kdevs) and process(kusers)
> 
>   + shell-like[0] (not like CML1, which is just shell) scripting, allowing
>     to extend easily (if there is no one available) capabilities,
>     config values or actions for particular sub-system or compilation
>     unit,
>     
>   [0] if somebody would like to see *a* shell-like scripting:
>       ftp://flower.upol.cz/geloiwa/src/usr/local/etc/geloiwa/iwant
> 
>   + duplex travelling, multi- looking at/changing of config items,
> 
>   + flexible, yet built-able, connections in dependency chain (tree,
>     graph, whatever);
> 
> * resulting config file capable of producing exact config results of the
>   build on any other setup
>   (e.g. no ARCH=, CROSS_*, *_FLAGS *kbuild* things);
> 
> * checking tool for particular config patterns (for bug reports)
> 
> * system itself must be done with minimum requirements for C libraries
>   (no ncurses) and tools (no `perl`, no `python`, no `make`).
> 
> > In a case where option A is specified by option B which is specified by 
option 
> > C which is specified by option D, should the comment on A mention B, or D 
or 
> > all three items in the chain? 
> 
> Fsck it. All must be done by a machine with maximum comfort of users (not
> particularly humans), even for those, who like to edit config like so:
> 
> `sed -i 's/SYSFS=y/SYSFS="please, NO!!!"/' .config`
> 
> --
> -o--=O`C
>  #oo'L O
> <___=E M
> 

I did not see a requirement for a major rewrite for a tool or a toolset. I saw 
a requirement for one specific improvement to the output of one specific 
program. It seems to be an improvement that will provide immediate benefits, 
so is worthwhile even if it will eventually be superceded by a new generation 
of the tool..

After making my living as a software engineer for the past 26 years, I know 
better than to start learning a new environment by setting out to make major 
architectural changes. Or without adequately detailed requirements (even if 
they are self-generated). Apparently the newbies you complain about have not 
learned these lessons yet, leading to incomplete and unfinished projects. 

When I have used this little project as a gateway into the toolset, I might 
consider taking part in your larger redesign project as a follow on, if you 
can provide more detailed and coherent specifications for what you want done. 

Or not. 

In this case, no one is paying me to deal with inadequate specifications and 
rude people, so I may find something else to do with my spare time and 
equipment. 

-- 
Elyse Grasso

http://www.data-raptors.com    Computers and Technology
http://www.astraltrading.com   Divination and Science Fiction
http://www.data-raptors.com/global-cgi-bin/cgiwrap/emgrasso/blosxom.cgi WebLog

Re: [kbuild-devel] A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

[Roman Zippel]

Hi,

On Mon, 1 Oct 2007, Oleg Verych wrote:

> Today's kconfig was proposed and accepted in a very unpleasant
> circumstances, has very poor design, development and no working
> alternative (for 5+ years now).

If you want to make such statements, you have to offer a little more than 
the hot air you're producing right now...
If you want to improve the design, you're more than welcome. I'm the first 
one to admit that there's still lots of room for improvement, but if you 
want to claim this can only be done via a rewrite, then you have to be 
a lot more specific what's wrong the current design and why it's 
unfixable.
Quite some thought has been put into this design and if you were a little 
more specific, I could actually tell you why it is this way and maybe how 
to improve it incrementally instead of trying to reinvent everything.

>   + shell-like[0] (not like CML1, which is just shell) scripting, allowing
>     to extend easily (if there is no one available) capabilities,
>     config values or actions for particular sub-system or compilation
>     unit,

Just to pick this one point as example: I like scripting and maybe I 
should just update the swig wrapper script I already have and merge it, 
which would make it easier to play with the kconfig database in whatever 
language you like.
OTOH due to the necessary build dependencies I don't see this become a 
mandatory feature, so unless there is a compelling reason a certain set of 
base function will remain in C.

bye, Roman

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

[Oleg Verych]

On Fri, Oct 05, 2007 at 04:35:41AM +0200, Roman Zippel wrote:
> Hi,
> 
> On Mon, 1 Oct 2007, Oleg Verych wrote:
> 
> > Today's kconfig was proposed and accepted in a very unpleasant
> > circumstances, has very poor design, development and no working
> > alternative (for 5+ years now).
> 
> If you want to make such statements, you have to offer a little more than 
> the hot air you're producing right now...
...

> If you want to improve the design, you're more than welcome. I'm the first 
> one to admit that there's still lots of room for improvement, but if you 
> want to claim this can only be done via a rewrite, then you have to be 
> a lot more specific what's wrong the current design and why it's 
> unfixable.
> Quite some thought has been put into this design and if you were a little 
> more specific, I could actually tell you why it is this way and maybe how 
> to improve it incrementally instead of trying to reinvent everything.

Thanks. I will be specific, after i will finish, what i already have,
to make air a bit less hot. Of course everything will be back
compatible, so nothing to worry about (the rewrite).
____

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

[Linus Torvalds]

On Sat, 6 Oct 2007, Oleg Verych wrote:
> 
> Thanks. I will be specific, after i will finish, what i already have,
> to make air a bit less hot. Of course everything will be back
> compatible, so nothing to worry about (the rewrite).

Qutie frankly, this kind of "I'll tell you more when I'm done" is not 
generally a very working approach. 

If it's all backwards-compatible with the current Kconfig format, I guess 
it's not too bad, but historically speaking, the people who went off on 
their own and redesigned something from scratch have not been successful 
(and the CML2 thing is a good example of that).

Incremental improvements actually tend to do better than "redesign".  
That's largely true outside of computer science too..

		Linus

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

[Oleg Verych]

On Sat, Oct 06, 2007 at 09:03:00AM -0700, Linus Torvalds wrote:
> 
> 
> On Sat, 6 Oct 2007, Oleg Verych wrote:
> > 
> > Thanks. I will be specific, after i will finish, what i already have,
> > to make air a bit less hot. Of course everything will be back
> > compatible, so nothing to worry about (the rewrite).
> 
> Qutie frankly, this kind of "I'll tell you more when I'm done" is not 
> generally a very working approach. 
> 
> If it's all backwards-compatible with the current Kconfig format, I guess 
> it's not too bad, but historically speaking, the people who went off on 
> their own and redesigned something from scratch have not been successful 
> (and the CML2 thing is a good example of that).

Spent whole September on LKML archive (grave) digging, actually. So,
please, get me right.

If i have finally made statement like that (rewrite with new design),
that basically means, i'll try to bring something, that probably will be
better, not emotionally (CML2 :), but technically (kbuild-2.5's 100%
slowdown of some important functionality :).

> Incremental improvements actually tend to do better than "redesign".  

I'm not going to call (and thus targeting) that thing "kbuild-2.7" or
"kconfig-ng", "CML3000" or anything like that.

If my proposal will fit, i.e. configuring and building something
(anything) becomes more easy, more flexible, etc., then any project can
try and adopt it actually. And this will be a measure of quality.

> That's largely true outside of computer science too..

Will see. If i will fail, who will care; i will not. Somebody spend years
of doing that, what was rejected. More than 5 years of current
kbuild/kconfig "development calmness". So...

Maintenance and acceptance of the m4/make/perl/C/ncurses community of my
mainly `TERM=linux ; sed && sh' approach is more important for me.

Thanks, Linus.
____

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

[Sam Ravnborg]

> Maintenance and acceptance of the m4/make/perl/C/ncurses community of my
> mainly `TERM=linux ; sed && sh' approach is more important for me.

There is noone having trouble with ncurses dependency today.
And perl is not yet mandatory for a kernel build expect
for a few architectures.
m4 is not used by the kernel - to my best knowledge.

	Sam

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

[Oleg Verych]

On Sat, Oct 06, 2007 at 08:59:20PM +0200, Sam Ravnborg wrote:
> > Maintenance and acceptance of the m4/make/perl/C/ncurses community of my
> > mainly `TERM=linux ; sed && sh' approach is more important for me.
> 
> There is noone having trouble with ncurses dependency today.

Who wants to meet a zombie anyway?

== Message-ID: <20051212004606.31263.37616.stgit@machine.or.cz> ==
From: Petr Baudis
Subject: [PATCH 3/3] [kconfig] Direct use of lxdialog routines by menuconfig
Date: Mon, 12 Dec 2005 01:46:06 +0100

After three years, the zombie walks again!  This patch (against the latest
git tree) cleans up interaction between kconfig's mconf (menuconfig
frontend) and lxdialog. Its commandline interface disappears in this patch,
instead a .so is packed from the lxdialog objects and the relevant
functions are called directly from mconf.

== * ==

> And perl is not yet mandatory for a kernel build expect
> for a few architectures.

Not build per se, but perl mind share of the people. Did they ever
looked into `strace`, when running (kind of) `perl simple-regex`?

Maybe there weren't right people to manage things easily in shell?
Reinventing parser was a major step back, whatever anyone can say.

== (seems like not original ID) 17982.5167906985$1029355529@news.gmane.org ==
From: Sam Ravnborg
Subject: Get rid of shell based Config.in parsers?
Date: Wed, 14 Aug 2002 22:14:00 +0200

[...]

I dislike seeing arguments that this is not easy/possible in shell based
parsers. If the chosen technology does not fit the problem domain
then it's about time to shift technology.

        Sam
== * ==

== Message-ID: <Pine.LNX.4.44.0208151048330.3130-100000@home.transmeta.com> ==
From: Linus Torvalds
Subject: Re: Get rid of shell based Config.in parsers?
Date: Thu, 15 Aug 2002 10:51:03 -0700 (PDT)

On Wed, 14 Aug 2002, Sam Ravnborg wrote:
>
> Where comes the requirement that we shall keep the existing shell
> based config parsers?

I use them exclusively.

It is far and away the most convenient parsing - just to do "make
oldconfig"  (possibly by making changes by hand to the .config file
first).

As far as I'm personally concerned, the shell parsers are the _only_
parser that really matter. So if you want to replace them with something
else, that something else had better be pretty much perfect and not take
all that long to build.

                Linus
== * ==

> m4 is not used by the kernel - to my best knowledge.

That was a rhetoric (i guess) statement. But it *is* used to
configure/build almost all tools, currently directly or indirectly
kbuild/kconfig uses.

`m4 'make "shell"'`

*OR*

`To quote lguest 'To quote David Wheeler:

"Any problem in computer science can be solved with
 another layer of indirection."'`

That's my personal view. And after 5-6 years of the "development", i
can see the "results". Again, will see.
____

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

[Sam Ravnborg]

On Sat, Oct 06, 2007 at 10:47:21PM +0200, Oleg Verych wrote:
> On Sat, Oct 06, 2007 at 08:59:20PM +0200, Sam Ravnborg wrote:
> > > Maintenance and acceptance of the m4/make/perl/C/ncurses community of my
> > > mainly `TERM=linux ; sed && sh' approach is more important for me.
> > 
> > There is noone having trouble with ncurses dependency today.
> 
> Who wants to meet a zombie anyway?

Finding quotes from old threads does not in any way prove your point.
And you see to get things wrong too.
There were complains that menuconfig was flickering when it used
lxdialog as a standalone executable which was addressed.
It was not addresses by a tolal rewrite we just integrated the lxdialog
functionality with kconfig - issue closed.
There were talks about shell based parsers or not. We ended up
selecting a design with a common backend shared by several frontends.
The frotends you know as oldconfig, menuconfig, xconfig and gconfig.
And the same backend <-> multiple frontends design you claim are broken
and continue your ranting about shell scripting.

But you have somehow skrewed up the facts here.
There are no one having big issue with netiehr kconfig nor kbuild.
And as being maintainer for kbuild and for some parts of kconfig
I am getting quite feed up with your continous ranting that they
are both in such a bad shape that a rewrite is needed.
And until now you have not given one single example of real
problems that will be solved by a total rewrite and cannot
be solved otherwise.

	Sam

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

[Oleg Verych]

On Sat, Oct 06, 2007 at 11:10:48PM +0200, Sam Ravnborg wrote:
> On Sat, Oct 06, 2007 at 10:47:21PM +0200, Oleg Verych wrote:
> > On Sat, Oct 06, 2007 at 08:59:20PM +0200, Sam Ravnborg wrote:
> > > > Maintenance and acceptance of the m4/make/perl/C/ncurses community of my
> > > > mainly `TERM=linux ; sed && sh' approach is more important for me.
> > > 
> > > There is noone having trouble with ncurses dependency today.
> > 
> > Who wants to meet a zombie anyway?
> 
> Finding quotes from old threads does not in any way prove your point.

This makes air hot for Roman. I want to prove my point not by words. But
have to reply with something on my side, until i have work done.

[]
> And until now you have not given one single example of real
> problems that will be solved by a total rewrite and cannot
> be solved otherwise.

If you didn't see them in that, what i've posted, then i just have to
say: i don't need to give anything. There are kvm, lguest, xen with ext2,
ext3, xfs, etc. And there's no working alternative to build/config
system. Thus, let me have my try OK? Thanks!

Bye.
____

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

[Geert Uytterhoeven]

On Sun, 7 Oct 2007, Oleg Verych wrote:
> On Sat, Oct 06, 2007 at 11:10:48PM +0200, Sam Ravnborg wrote:
> > On Sat, Oct 06, 2007 at 10:47:21PM +0200, Oleg Verych wrote:
> > > On Sat, Oct 06, 2007 at 08:59:20PM +0200, Sam Ravnborg wrote:
> > > > > Maintenance and acceptance of the m4/make/perl/C/ncurses community of my
> > > > > mainly `TERM=linux ; sed && sh' approach is more important for me.
> > > > 
> > > > There is noone having trouble with ncurses dependency today.
> > > 
> > > Who wants to meet a zombie anyway?
> > 
> > Finding quotes from old threads does not in any way prove your point.
> 
> This makes air hot for Roman. I want to prove my point not by words. But
> have to reply with something on my side, until i have work done.
> 
> []
> > And until now you have not given one single example of real
> > problems that will be solved by a total rewrite and cannot
> > be solved otherwise.
> 
> If you didn't see them in that, what i've posted, then i just have to
> say: i don't need to give anything. There are kvm, lguest, xen with ext2,
> ext3, xfs, etc. And there's no working alternative to build/config
> system. Thus, let me have my try OK? Thanks!

<ironic>
Let's add an alternative to the Makefiles, too....
</ironic>

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

[Sam Ravnborg]

> 
> And there's no working alternative to build/config
> system. Thus, let me have my try OK? Thanks!

I would prefer if you used your time to do small incrmental improvements
to what we have today rather then rewriting from scratch.

But it's your decision and not mine.

	Sam

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

[Oleg Verych]

On Mon, Oct 08, 2007 at 10:22:01PM +0200, Sam Ravnborg wrote:
> > 
> > And there's no working alternative to build/config
> > system. Thus, let me have my try OK? Thanks!
> 
> I would prefer if you used your time to do small incrmental improvements
> to what we have today rather then rewriting from scratch.
> 
> But it's your decision and not mine.

In case anybody is interested:

Newsgroups: gmane.linux.kbuild.devel,gmane.linux.kernel
Subject: Re: [RFC/RFT] kbuild: save ARCH & CROSS_COMPILE
Date: Mon, 8 Oct 2007 22:50:48 +0200
Message-ID: <20071008205048.GY22435@flower.upol.cz>
Archived-At: <http://permalink.gmane.org/gmane.linux.kbuild.devel/1562>
____