9p: fix compile error if !CONFIG_SYSCTL

PATCH In review Andreas Herrmann 11 participants 24 messages Sep 18, 2007 – Oct 8, 2007

Subsystems (2)

Networking 9P file system

lore

Share & tools

lore

Andreas Herrmann

author

2007-09-18 08:04 UTC #0 lore raw

PATCH 1/1 9p: fix compile error if !CONFIG_SYSCTL

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 <[email protected]>

---
 include/net/9p/9p.h |    4 ++++
 net/9p/mod.c        |    4 ++++
 2 files changed, 8 insertions(+), 0 deletions(-)

include/net/9p/9p.h +4 -0

index 88884d3..f723a03 100644
@@ -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 */

net/9p/mod.c +4 -0

index 4f9e1d2..b4d435c 100644
@@ -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();
 }

Signature · 1 line

1.5.3

roel

2007-09-18 19:23 UTC #1 lore raw

Quoted 51 lines · Andreas Herrmann

Fix compile error if !CONFIG_SYSCTL:

...

...

Signed-off-by Andreas Herrmann <[email protected]>

---
 include/net/9p/9p.h |    4 ++++
 net/9p/mod.c        |    4 ++++
 2 files changed, 8 insertions(+), 0 deletions(-)

include/net/9p/9p.h +4 -0

index 88884d3..f723a03 100644
@@ -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 */

net/9p/mod.c +2 -0

index 4f9e1d2..b4d435c 100644
@@ -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;
 }

net/9p/mod.c static int __init init_p9(void) · line 82

Quoted 9 lines

net/9p/mod.c +2 -0

@@ -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?

net/9p/sysctl.c +4 -1

index 8b61027..e199865 100644
@@ -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
 }

Andreas Herrmann

author

2007-09-18 20:14 UTC #2 lore raw

Quoted 12 lines · roel

Quoted 11 lines · 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
    ...

Quoted 1 line

isn't it nicer to do something like this instead?

No.

Quoted 13 lines

net/9p/sysctl.c +1 -1

index 8b61027..e199865 100644
@@ -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;
-

net/9p/sysctl.c static struct ctl_table_header *p9_table_header; · line 84

Quoted 10 lines

net/9p/sysctl.c +3 -0

+#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

Andrew Morton

2007-09-20 06:31 UTC #3 lore raw

In reply to Andreas Herrmann

Quoted 10 lines · On Tue, 18 Sep 2007 10:05:37 +0200 Andreas Herrmann <[email protected]> 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

include/net/9p/9p.h renamed from include/net/9p/9p.h~9p-fix-compile-error-if-config_sysctl +11 -0

@@ -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.

Andreas Herrmann

author

2007-09-20 07:22 UTC #4 lore raw

Quoted 13 lines · Andrew Morton

Quoted 10 lines · On Tue, 18 Sep 2007 10:05:37 +0200 Andreas Herrmann <[email protected]> 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
    ...

Quoted 1 line

A better fix would be

But only if you add another

    #endif /* CONFIG_SYSCTL */

Right?
;-)

Quoted 24 lines

include/net/9p/9p.h renamed from include/net/9p/9p.h~9p-fix-compile-error-if-config_sysctl +11 -0

@@ -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 _

Quoted 4 lines

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 <[email protected]>

---
 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

include/net/9p/9p.h +0 -2

index 88884d3..f69992f 100644
@@ -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 */

net/9p/Makefile +1 -3

index 85b3a78..488026a 100644
@@ -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

net/9p/mod.c +47 -7

81 lines not on this page · raw message

net/9p/sysctl.c deleted +0 ~~-81~~

81 lines not on this page · raw message

Signature · 1 line

1.5.3

Nick Piggin

2007-09-28 14:12 UTC #5 lore raw

In reply to Andrew Morton

Quoted 4 lines · Andrew Morton

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.

Linus Torvalds

2007-09-28 14:35 UTC #6 lore raw

Quoted 7 lines · Nick Piggin

Quoted 2 lines
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

Nick Piggin

2007-09-28 16:37 UTC #7 lore raw

Quoted 11 lines · Linus Torvalds

Quoted 6 lines · Nick Piggin
Quoted 1 line
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.

Quoted 8 lines

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 ;)

Quoted 8 lines

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

Arjan van de Ven

2007-09-28 17:12 UTC #8 lore raw

On Fri, 28 Sep 2007 10:05:33 +1000

Quoted 7 lines

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

Elyse M. Grasso

2007-09-28 17:31 UTC #9 lore raw

In reply to Nick Piggin

Quoted 5 lines · Nick Piggin

Quoted 4 lines · Linus Torvalds
Quoted 3 lines · Nick Piggin
Quoted 1 line
God I hate select.
IMO a better implementation would result in a notification /

confirmation

Quoted 32 lines

Quoted 7 lines
Quoted 3 lines
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.
Quoted 8 lines
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 ;)
Quoted 7 lines
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?)

Quoted 7 lines

Quoted 1 line
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
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?

Signature · 5 lines

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

Oleg Verych

2007-10-01 07:13 UTC #10 lore raw

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

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

Quoted 13 lines · Nick Piggin

Quoted 5 lines · Linus Torvalds
Quoted 4 lines · Nick Piggin
Quoted 3 lines
Quoted 1 line
God I hate select.
IMO a better implementation would result in a notification /
confirmation
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
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.

[]

Quoted 3 lines

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

[]

Quoted 10 lines

Quoted 10 lines
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 ;)
Quoted 1 line

Quoted 7 lines

Quoted 7 lines
Quoted 7 lines
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

[]

Quoted 5 lines

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).

Quoted 3 lines

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

Sam Ravnborg

2007-10-01 08:04 UTC #11 lore raw

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

Hi Oleg.

Quoted 4 lines

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

Elyse M. Grasso

2007-10-01 12:53 UTC #12 lore raw

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

In reply to Oleg Verych

Quoted 10 lines · Oleg Verych

* Fri, 28 Sep 2007 11:12:51 -0600
Quoted 8 lines · Nick Piggin
Quoted 5 lines · Linus Torvalds
Quoted 4 lines · Nick Piggin
Quoted 3 lines
Quoted 1 line
God I hate select.
IMO a better implementation would result in a notification /
confirmation
Quoted 1 line
Quoted 1 line
Quoted 1 line
of turning on new items, and the ability to deselect options which

will

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
also confirm to deselect dependants. Like most other systems that

have

Quoted 22 lines

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
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.
[]
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
	CONFIG_ACPI=y		# selected by X86_64_ACPI_NUMA
	CONFIG_ACPI_PROCFS=y	# user choice
	...
[]
Quoted 13 lines
Quoted 13 lines
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 ;)
Quoted 4 lines
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

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
reports, and is part of distro kernel packages etc, so it would seem to

Quoted 6 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
the right place, no?)
Linus
[]
Quoted 2 lines
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

Quoted 35 lines

Quoted 3 lines
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);

Quoted 10 lines

* 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).
Quoted 1 line
In a case where option A is specified by option B which is specified by

option

Quoted 1 line

Quoted 1 line
C which is specified by option D, should the comment on A mention B, or D

Quoted 5 lines

Quoted 1 line
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:

Quoted 7 lines

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.

Signature · 5 lines

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

Roman Zippel

2007-10-05 02:39 UTC #13 lore raw

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

In reply to Oleg Verych

Hi,

Quoted 3 lines · Oleg Verych

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.

Quoted 4 lines

+ 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

Oleg Verych

2007-10-06 15:12 UTC #14 lore raw

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

Quoted 10 lines · Roman Zippel

Hi,
Quoted 3 lines · Oleg Verych
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...

...

Quoted 8 lines

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).
____

Linus Torvalds

2007-10-06 16:04 UTC #15 lore raw

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

Quoted 4 lines · Oleg Verych

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

Oleg Verych

2007-10-06 17:37 UTC #16 lore raw

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

Quoted 8 lines · Linus Torvalds

Quoted 4 lines · Oleg Verych
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).

Quoted 7 lines

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 :).

Quoted 1 line

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.

Quoted 1 line

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.
____

Sam Ravnborg

2007-10-06 18:57 UTC #17 lore raw

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

Quoted 2 lines

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

Oleg Verych

2007-10-06 20:33 UTC #18 lore raw

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

Quoted 4 lines · Sam Ravnborg

Quoted 2 lines
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: <[email protected]> ==
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.

== * ==

Quoted 2 lines

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) [email protected] ==
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: <[email protected]> ==
From: Linus Torvalds
Subject: Re: Get rid of shell based Config.in parsers?
Date: Thu, 15 Aug 2002 10:51:03 -0700 (PDT)

Quoted 3 lines · Sam Ravnborg

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
== * ==

Quoted 1 line

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.
____

Sam Ravnborg

2007-10-06 21:09 UTC #19 lore raw

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

Quoted 7 lines · Oleg Verych

Quoted 4 lines · Sam Ravnborg
Quoted 2 lines
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

Oleg Verych

2007-10-06 21:54 UTC #20 lore raw

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

Quoted 10 lines · Sam Ravnborg

Quoted 7 lines · Oleg Verych
Quoted 4 lines · Sam Ravnborg
Quoted 2 lines
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.

[]

Quoted 3 lines

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.
____

Geert Uytterhoeven

2007-10-07 09:49 UTC #21 lore raw

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

Quoted 16 lines · Oleg Verych

Quoted 10 lines · Sam Ravnborg
Quoted 7 lines · Oleg Verych
Quoted 4 lines · Sam Ravnborg
Quoted 2 lines
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.
[]

Quoted 8 lines

Quoted 3 lines
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 -- [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

Sam Ravnborg

2007-10-08 20:20 UTC #22 lore raw

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

In reply to Oleg Verych

Quoted 3 lines

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

Oleg Verych

2007-10-08 21:11 UTC #23 lore raw

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

Quoted 8 lines · Sam Ravnborg

Quoted 3 lines
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: <[email protected]>
Archived-At: <http://permalink.gmane.org/gmane.linux.kbuild.devel/1562>
____