CVS commit: src/usr.bin/config

2024-08-13 Thread Valery Ushakov
Module Name:src
Committed By:   uwe
Date:   Tue Aug 13 23:24:23 UTC 2024

Modified Files:
src/usr.bin/config: config.5

Log Message:
config(5): bump date for and fix typo in previous

PR bin/58583


To generate a diff of this commit:
cvs rdiff -u -r1.49 -r1.50 src/usr.bin/config/config.5

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/usr.bin/config/config.5
diff -u src/usr.bin/config/config.5:1.49 src/usr.bin/config/config.5:1.50
--- src/usr.bin/config/config.5:1.49	Tue Aug 13 15:01:52 2024
+++ src/usr.bin/config/config.5	Tue Aug 13 23:24:23 2024
@@ -1,4 +1,4 @@
-.\" $NetBSD: config.5,v 1.49 2024/08/13 15:01:52 uwe Exp $
+.\" $NetBSD: config.5,v 1.50 2024/08/13 23:24:23 uwe Exp $
 .\"
 .\"  Copyright (c) 2006, 2007 The NetBSD Foundation.
 .\"  All rights reserved.
@@ -24,7 +24,7 @@
 .\"  ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 .\"  POSSIBILITY OF SUCH DAMAGE.
 .\"
-.Dd January 17, 2024
+.Dd August 13, 2024
 .Dt CONFIG 5
 .Os
 .Sh NAME
@@ -744,7 +744,7 @@ Used instead of
 .Ic machine
 in config file snippets for kernel modules to generate just the
 .Pa ioconf.c
-definions.
+definitions.
 The generated file contains subtrees that start with attachments
 declared with
 .Ic pseudo-root .



CVS commit: src/usr.bin/config

2024-08-13 Thread Valery Ushakov
Module Name:src
Committed By:   uwe
Date:   Tue Aug 13 23:24:23 UTC 2024

Modified Files:
src/usr.bin/config: config.5

Log Message:
config(5): bump date for and fix typo in previous

PR bin/58583


To generate a diff of this commit:
cvs rdiff -u -r1.49 -r1.50 src/usr.bin/config/config.5

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/usr.bin/config

2024-08-13 Thread Valery Ushakov
Module Name:src
Committed By:   uwe
Date:   Tue Aug 13 15:01:52 UTC 2024

Modified Files:
src/usr.bin/config: config.5

Log Message:
config(5): mention ioconf and pseudo-root

Add barebones descriptions for ioconf and pseudo-root added by pooka@
long time ago for rump and kmods.  Definitely could be improved and
expanded, so feel free...

PR bin/58583


To generate a diff of this commit:
cvs rdiff -u -r1.48 -r1.49 src/usr.bin/config/config.5

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/usr.bin/config/config.5
diff -u src/usr.bin/config/config.5:1.48 src/usr.bin/config/config.5:1.49
--- src/usr.bin/config/config.5:1.48	Thu Jan 18 04:41:37 2024
+++ src/usr.bin/config/config.5	Tue Aug 13 15:01:52 2024
@@ -1,4 +1,4 @@
-.\" $NetBSD: config.5,v 1.48 2024/01/18 04:41:37 thorpej Exp $
+.\" $NetBSD: config.5,v 1.49 2024/08/13 15:01:52 uwe Exp $
 .\"
 .\"  Copyright (c) 2006, 2007 The NetBSD Foundation.
 .\"  All rights reserved.
@@ -739,6 +739,16 @@ the
 and each of the
 .Ar subarch .
 .\"
+.It Ic ioconf Ar name
+Used instead of
+.Ic machine
+in config file snippets for kernel modules to generate just the
+.Pa ioconf.c
+definions.
+The generated file contains subtrees that start with attachments
+declared with
+.Ic pseudo-root .
+.\"
 .It Ic package Ar path
 Simpler version of:
 .Bd -literal -offset indent
@@ -844,6 +854,24 @@ Removes
 .Ar name
 from the list of kernel binaries to compile from the configuration file.
 .\"
+.It Ic pseudo-root Ar instance
+Used in conjunction with
+.Ic ioconf
+in kernel modules.
+Declares an instance of a device that serves as the root for a subtree
+described in the module config.
+The declared
+.Ar instance
+can then be used as an
+.Ar attachment
+for devices in the kernel module.
+Multiple such attachment points may be declared in the config file.
+.Ar instance
+may name a device
+.Pq e.g. Ql pci*
+an interface attribute
+.Pq e.g. Ql audiobus*
+.\"
 .It Ar instance Ic at Ar attachment Op Ar locator-specifications ...
 Configures an instance of a device attaching at a specific location in the
 device tree.



CVS commit: src/usr.bin/config

2024-08-13 Thread Valery Ushakov
Module Name:src
Committed By:   uwe
Date:   Tue Aug 13 15:01:52 UTC 2024

Modified Files:
src/usr.bin/config: config.5

Log Message:
config(5): mention ioconf and pseudo-root

Add barebones descriptions for ioconf and pseudo-root added by pooka@
long time ago for rump and kmods.  Definitely could be improved and
expanded, so feel free...

PR bin/58583


To generate a diff of this commit:
cvs rdiff -u -r1.48 -r1.49 src/usr.bin/config/config.5

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/usr.bin/config

2024-08-13 Thread Valery Ushakov
Module Name:src
Committed By:   uwe
Date:   Tue Aug 13 10:14:04 UTC 2024

Modified Files:
src/usr.bin/config: scan.l

Log Message:
config: fix ctype(3) argument casts

See CAVEATS.  Doesn't matter here in practice, but that's not an
excuse to set a bad example.


To generate a diff of this commit:
cvs rdiff -u -r1.35 -r1.36 src/usr.bin/config/scan.l

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/usr.bin/config/scan.l
diff -u src/usr.bin/config/scan.l:1.35 src/usr.bin/config/scan.l:1.36
--- src/usr.bin/config/scan.l:1.35	Thu Jan 18 04:41:37 2024
+++ src/usr.bin/config/scan.l	Tue Aug 13 10:14:04 2024
@@ -1,5 +1,5 @@
 %{
-/*	$NetBSD: scan.l,v 1.35 2024/01/18 04:41:37 thorpej Exp $	*/
+/*	$NetBSD: scan.l,v 1.36 2024/08/13 10:14:04 uwe Exp $	*/
 
 /*
  * Copyright (c) 1992, 1993
@@ -42,7 +42,7 @@
  */
 
 #include 
-__RCSID("$NetBSD: scan.l,v 1.35 2024/01/18 04:41:37 thorpej Exp $");
+__RCSID("$NetBSD: scan.l,v 1.36 2024/08/13 10:14:04 uwe Exp $");
 
 #include 
 #include 
@@ -575,9 +575,9 @@ getincludepath(void)
 	ptrdiff_t len;
 	const char *e;
 
-	while (*p && isascii((unsigned int)*p) && !isspace((unsigned int)*p))
+	while (*p && isascii((unsigned char)*p) && !isspace((unsigned char)*p))
 		p++;
-	while (*p && isascii((unsigned int)*p) && isspace((unsigned int)*p))
+	while (*p && isascii((unsigned char)*p) && isspace((unsigned char)*p))
 		p++;
 	if (!*p)
 		return 0;
@@ -587,8 +587,8 @@ getincludepath(void)
 		if (!e) return 0;
 	} else {
 		e = p;
-		while (*e && isascii((unsigned int)*e)
-		&& !isspace((unsigned int)*e))
+		while (*e && isascii((unsigned char)*e)
+		&& !isspace((unsigned char)*e))
 			e++;
 	}
 
@@ -649,12 +649,12 @@ getcurifdef(void)
 {
 	char *p = yytext, *q;
 
-	while (*p && isascii((unsigned int)*p) && !isspace((unsigned int)*p))
+	while (*p && isascii((unsigned char)*p) && !isspace((unsigned char)*p))
 		p++;
-	while (*p && isascii((unsigned int)*p) && isspace((unsigned int)*p))
+	while (*p && isascii((unsigned char)*p) && isspace((unsigned char)*p))
 		p++;
 	q = p;
-	while (*q && isascii((unsigned int)*q) && !isspace((unsigned int)*q))
+	while (*q && isascii((unsigned char)*q) && !isspace((unsigned char)*q))
 		q++;
 	*q = '\0';
 



CVS commit: src/usr.bin/config

2024-08-13 Thread Valery Ushakov
Module Name:src
Committed By:   uwe
Date:   Tue Aug 13 10:14:04 UTC 2024

Modified Files:
src/usr.bin/config: scan.l

Log Message:
config: fix ctype(3) argument casts

See CAVEATS.  Doesn't matter here in practice, but that's not an
excuse to set a bad example.


To generate a diff of this commit:
cvs rdiff -u -r1.35 -r1.36 src/usr.bin/config/scan.l

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/usr.bin/config

2024-04-04 Thread Taylor R Campbell
Module Name:src
Committed By:   riastradh
Date:   Fri Apr  5 00:43:42 UTC 2024

Modified Files:
src/usr.bin/config: defs.h files.c mkioconf.c mkmakefile.c pack.c

Log Message:
config(1): Make sort order deterministic.

Ensure we break ties in every case.  This way, even though we use the
unstable qsort(3) library routine, the output is reproducible, no
matter what algorithm is behind qsort(3).

It would be nice if we could just use a stable sort function here,
but mergesort(3) is nonstandard, so we'd have to add it to
tools/compat, which is a big pain.

Instead, put a tie-breaking rule in every comparison function we use
with qsort, and abort() in the event of ties -- that way, we noisily
refuse to rely on unstable sort order.

While here, dispense with any question of integer overflow, and
sprinkle comments.

PR bin/58115


To generate a diff of this commit:
cvs rdiff -u -r1.108 -r1.109 src/usr.bin/config/defs.h
cvs rdiff -u -r1.37 -r1.38 src/usr.bin/config/files.c
cvs rdiff -u -r1.35 -r1.36 src/usr.bin/config/mkioconf.c
cvs rdiff -u -r1.72 -r1.73 src/usr.bin/config/mkmakefile.c
cvs rdiff -u -r1.10 -r1.11 src/usr.bin/config/pack.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/usr.bin/config/defs.h
diff -u src/usr.bin/config/defs.h:1.108 src/usr.bin/config/defs.h:1.109
--- src/usr.bin/config/defs.h:1.108	Thu Jan 18 05:41:38 2024
+++ src/usr.bin/config/defs.h	Fri Apr  5 00:43:42 2024
@@ -1,4 +1,4 @@
-/*	$NetBSD: defs.h,v 1.108 2024/01/18 05:41:38 thorpej Exp $	*/
+/*	$NetBSD: defs.h,v 1.109 2024/04/05 00:43:42 riastradh Exp $	*/
 
 /*
  * Copyright (c) 1992, 1993
@@ -207,6 +207,8 @@ struct attr {
 	/* "device class" */
 	const char *a_devclass;		/* device class described */
 	struct where a_where;
+
+	size_t	a_idx;			/* index to break sorting ties */
 };
 
 /*

Index: src/usr.bin/config/files.c
diff -u src/usr.bin/config/files.c:1.37 src/usr.bin/config/files.c:1.38
--- src/usr.bin/config/files.c:1.37	Sat Mar  7 19:26:13 2020
+++ src/usr.bin/config/files.c	Fri Apr  5 00:43:42 2024
@@ -1,4 +1,4 @@
-/*	$NetBSD: files.c,v 1.37 2020/03/07 19:26:13 christos Exp $	*/
+/*	$NetBSD: files.c,v 1.38 2024/04/05 00:43:42 riastradh Exp $	*/
 
 /*
  * Copyright (c) 1992, 1993
@@ -45,7 +45,7 @@
 #endif
 
 #include 
-__RCSID("$NetBSD: files.c,v 1.37 2020/03/07 19:26:13 christos Exp $");
+__RCSID("$NetBSD: files.c,v 1.38 2024/04/05 00:43:42 riastradh Exp $");
 
 #include 
 #include 
@@ -281,9 +281,9 @@ cmpfiles(const void *a, const void *b)
 	if (sa < sb)
 		return -1;
 	else if (sa > sb)
-		return 1;
+		return +1;
 	else
-		return 0;
+		abort();	/* no ties possible */
 }
 
 /*

Index: src/usr.bin/config/mkioconf.c
diff -u src/usr.bin/config/mkioconf.c:1.35 src/usr.bin/config/mkioconf.c:1.36
--- src/usr.bin/config/mkioconf.c:1.35	Sun Nov 19 01:46:29 2017
+++ src/usr.bin/config/mkioconf.c	Fri Apr  5 00:43:42 2024
@@ -1,4 +1,4 @@
-/*	$NetBSD: mkioconf.c,v 1.35 2017/11/19 01:46:29 christos Exp $	*/
+/*	$NetBSD: mkioconf.c,v 1.36 2024/04/05 00:43:42 riastradh Exp $	*/
 
 /*
  * Copyright (c) 1992, 1993
@@ -45,7 +45,7 @@
 #endif
 
 #include 
-__RCSID("$NetBSD: mkioconf.c,v 1.35 2017/11/19 01:46:29 christos Exp $");
+__RCSID("$NetBSD: mkioconf.c,v 1.36 2024/04/05 00:43:42 riastradh Exp $");
 
 #include 
 #include 
@@ -136,7 +136,12 @@ cforder(const void *a, const void *b)
 
 	n1 = (*(const struct devi * const *)a)->i_cfindex;
 	n2 = (*(const struct devi * const *)b)->i_cfindex;
-	return (n1 - n2);
+	if (n1 < n2)
+		return -1;
+	else if (n1 > n2)
+		return +1;
+	else
+		abort();	/* no ties possible */
 }
 
 static void

Index: src/usr.bin/config/mkmakefile.c
diff -u src/usr.bin/config/mkmakefile.c:1.72 src/usr.bin/config/mkmakefile.c:1.73
--- src/usr.bin/config/mkmakefile.c:1.72	Thu Jan 18 04:41:37 2024
+++ src/usr.bin/config/mkmakefile.c	Fri Apr  5 00:43:42 2024
@@ -1,4 +1,4 @@
-/*	$NetBSD: mkmakefile.c,v 1.72 2024/01/18 04:41:37 thorpej Exp $	*/
+/*	$NetBSD: mkmakefile.c,v 1.73 2024/04/05 00:43:42 riastradh Exp $	*/
 
 /*
  * Copyright (c) 1992, 1993
@@ -45,7 +45,7 @@
 #endif
 
 #include 
-__RCSID("$NetBSD: mkmakefile.c,v 1.72 2024/01/18 04:41:37 thorpej Exp $");
+__RCSID("$NetBSD: mkmakefile.c,v 1.73 2024/04/05 00:43:42 riastradh Exp $");
 
 #include 
 #include 
@@ -413,6 +413,7 @@ emitallkobjscb(const char *name, void *v
 		return 0;
 	if (TAILQ_EMPTY(&a->a_files))
 		return 0;
+	a->a_idx = attridx;
 	attrbuf[attridx++] = a;
 	/* XXX nattrs tracking is not exact yet */
 	if (attridx == nattrs) {
@@ -447,7 +448,21 @@ attrcmp(const void *l, const void *r)
 {
 	const struct attr * const *a = l, * const *b = r;
 	const int wa = (*a)->a_weight, wb = (*b)->a_weight;
-	return (wa > wb) ? -1 : (wa < wb) ? 1 : 0;
+
+	/*
+	 * Higher-weight first; then, among equal weights, earlier
+	 * index first.
+	 */
+	if (wa > wb)
+		return -1;
+	else if (wa < wb)
+		return +1;
+	else if ((*a)->a_idx < (*b)->a_idx)
+		return -1;
+	else i

CVS commit: src/usr.bin/config

2024-04-04 Thread Taylor R Campbell
Module Name:src
Committed By:   riastradh
Date:   Fri Apr  5 00:43:42 UTC 2024

Modified Files:
src/usr.bin/config: defs.h files.c mkioconf.c mkmakefile.c pack.c

Log Message:
config(1): Make sort order deterministic.

Ensure we break ties in every case.  This way, even though we use the
unstable qsort(3) library routine, the output is reproducible, no
matter what algorithm is behind qsort(3).

It would be nice if we could just use a stable sort function here,
but mergesort(3) is nonstandard, so we'd have to add it to
tools/compat, which is a big pain.

Instead, put a tie-breaking rule in every comparison function we use
with qsort, and abort() in the event of ties -- that way, we noisily
refuse to rely on unstable sort order.

While here, dispense with any question of integer overflow, and
sprinkle comments.

PR bin/58115


To generate a diff of this commit:
cvs rdiff -u -r1.108 -r1.109 src/usr.bin/config/defs.h
cvs rdiff -u -r1.37 -r1.38 src/usr.bin/config/files.c
cvs rdiff -u -r1.35 -r1.36 src/usr.bin/config/mkioconf.c
cvs rdiff -u -r1.72 -r1.73 src/usr.bin/config/mkmakefile.c
cvs rdiff -u -r1.10 -r1.11 src/usr.bin/config/pack.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/usr.bin/config

2024-01-17 Thread Jason R Thorpe
Module Name:src
Committed By:   thorpej
Date:   Thu Jan 18 05:41:38 UTC 2024

Modified Files:
src/usr.bin/config: defs.h

Log Message:
Bump version.


To generate a diff of this commit:
cvs rdiff -u -r1.107 -r1.108 src/usr.bin/config/defs.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/usr.bin/config/defs.h
diff -u src/usr.bin/config/defs.h:1.107 src/usr.bin/config/defs.h:1.108
--- src/usr.bin/config/defs.h:1.107	Thu Jan 18 04:41:37 2024
+++ src/usr.bin/config/defs.h	Thu Jan 18 05:41:38 2024
@@ -1,4 +1,4 @@
-/*	$NetBSD: defs.h,v 1.107 2024/01/18 04:41:37 thorpej Exp $	*/
+/*	$NetBSD: defs.h,v 1.108 2024/01/18 05:41:38 thorpej Exp $	*/
 
 /*
  * Copyright (c) 1992, 1993
@@ -107,7 +107,7 @@ extern const char *progname;
  * The next two lines define the current version of the config(1) binary,
  * and the minimum version of the configuration files it supports.
  */
-#define CONFIG_VERSION		20180827
+#define CONFIG_VERSION		20240118
 #define CONFIG_MINVERSION	0
 
 struct where {



CVS commit: src/usr.bin/config

2024-01-17 Thread Jason R Thorpe
Module Name:src
Committed By:   thorpej
Date:   Thu Jan 18 05:41:38 UTC 2024

Modified Files:
src/usr.bin/config: defs.h

Log Message:
Bump version.


To generate a diff of this commit:
cvs rdiff -u -r1.107 -r1.108 src/usr.bin/config/defs.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/usr.bin/config

2024-01-17 Thread Jason R Thorpe
Module Name:src
Committed By:   thorpej
Date:   Thu Jan 18 04:41:38 UTC 2024

Modified Files:
src/usr.bin/config: config.5 defs.h gram.y main.c mkmakefile.c scan.l
util.c

Log Message:
With config(1) as it exists today, a kernel Makefile is able to implement
logic on kernel options so long as those options are not defflag'd or
defparam'd.  This works because such options are automatally added to the
IDENT var in the kernel Makefile as a preprocessor define, and the Makefile
can then do an operation like:

.if !empty(IDENT:M-DSOMECOOLCPUOPTION)
CFLAGS+= -mcpu=somecoolcpu
.endif

Unfortunately, this precludes making it possible to generate a compile-time
dependency on SOMECOOLCPUOPTION, or having SOMECOOLCPUOPTION imply another
kernel config option using the normal config(1) option dependency function.

Fix this by introducing a new option description keyword: mkflagvar.  This
keyword marks an already defflag'd option as wanting a kernel Makefile var
defined if that option is selected in the kernel config file.  So:

defflag opt_coolcpu.h SOMECOOLCPUOPTION ANOTHERCOOLCPUOPTION
mkflagvar SOMECOOLCPUOPTION ANOTHERCOOLCPUOPTION

will cause:

KERNEL_OPT_SOMECOOLCPUOPTION="1"
KERNEL_OPT_ANOTHERCOOLCPUOPTION="1"

...to be emitted into the kernel Makefile if those options are, in fact,
selected with "options ..." in the kernel config file, thus allowing for
a compile-time dependency on the option to be generated in addition to
Makefile logic, which now looks like:

.if !empty(KERNEL_OPT_SOMECOOLCPUOPTION)
CFLAGS+= -mcpu=somecoolcpu
.endif


To generate a diff of this commit:
cvs rdiff -u -r1.47 -r1.48 src/usr.bin/config/config.5
cvs rdiff -u -r1.106 -r1.107 src/usr.bin/config/defs.h
cvs rdiff -u -r1.56 -r1.57 src/usr.bin/config/gram.y
cvs rdiff -u -r1.100 -r1.101 src/usr.bin/config/main.c
cvs rdiff -u -r1.71 -r1.72 src/usr.bin/config/mkmakefile.c
cvs rdiff -u -r1.34 -r1.35 src/usr.bin/config/scan.l
cvs rdiff -u -r1.21 -r1.22 src/usr.bin/config/util.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/usr.bin/config/config.5
diff -u src/usr.bin/config/config.5:1.47 src/usr.bin/config/config.5:1.48
--- src/usr.bin/config/config.5:1.47	Mon Oct  4 14:35:20 2021
+++ src/usr.bin/config/config.5	Thu Jan 18 04:41:37 2024
@@ -1,4 +1,4 @@
-.\" $NetBSD: config.5,v 1.47 2021/10/04 14:35:20 andvar Exp $
+.\" $NetBSD: config.5,v 1.48 2024/01/18 04:41:37 thorpej Exp $
 .\"
 .\"  Copyright (c) 2006, 2007 The NetBSD Foundation.
 .\"  All rights reserved.
@@ -24,7 +24,7 @@
 .\"  ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 .\"  POSSIBILITY OF SUCH DAMAGE.
 .\"
-.Dd July 19, 2016
+.Dd January 17, 2024
 .Dt CONFIG 5
 .Os
 .Sh NAME
@@ -459,6 +459,24 @@ The optional
 argument should match the original definition of the option.
 .\"
 .Pp
+.It Ic mkflagvar \
+Ar option ...
+Specifes that an option previously defined with
+.Ic defflag
+should have a variable created in the kernel Makefile if the option
+is selection with an
+.Ic options
+statement.
+No variable is created if the option is not selected.
+The Makefile variable will have the name
+.Li KERNEL_OPT_ Ns Aq Ar option
+and, because options defined with
+.Ic defflag
+are boolean, 
+the variable will have the value
+.Dq 1 .
+.\"
+.Pp
 .It Ic define \
 Ar attribute \
 Oo Ic \&{ Ar locators Ic \&} Oc \

Index: src/usr.bin/config/defs.h
diff -u src/usr.bin/config/defs.h:1.106 src/usr.bin/config/defs.h:1.107
--- src/usr.bin/config/defs.h:1.106	Fri Apr  3 19:53:41 2020
+++ src/usr.bin/config/defs.h	Thu Jan 18 04:41:37 2024
@@ -1,4 +1,4 @@
-/*	$NetBSD: defs.h,v 1.106 2020/04/03 19:53:41 joerg Exp $	*/
+/*	$NetBSD: defs.h,v 1.107 2024/01/18 04:41:37 thorpej Exp $	*/
 
 /*
  * Copyright (c) 1992, 1993
@@ -151,6 +151,7 @@ struct defoptlist {
 	const char *dl_value;
 	const char *dl_lintvalue;
 	int dl_obsolete;
+	int dl_mkvar;
 	struct nvlist *dl_depends;
 	struct where	dl_where;
 };
@@ -591,10 +592,12 @@ void	delfsoption(const char *, int);
 void	delmkoption(const char *, int);
 int	devbase_has_instances(struct devbase *, int);
 struct where *find_declared_option(const char *);
+struct defoptlist *find_declared_option_option(const char *name);
 int	deva_has_instances(struct deva *, int);
 void	setupdirs(void);
 void	fixmaxusers(void);
 void	fixmkoption(void);
+void	mkflagvar(struct defoptlist *);
 const char *strtolower(const char *);
 
 /* tests on option types */

Index: src/usr.bin/config/gram.y
diff -u src/usr.bin/config/gram.y:1.56 src/usr.bin/config/gram.y:1.57
--- src/usr.bin/config/gram.y:1.56	Sun Jul 26 22:40:52 2020
+++ src/usr.bin/config/gram.y	Thu Jan 18 04:41:37 2024
@@ -1,5 +1,5 @@
 %{
-/*	$NetBSD: gram.y,v 1.56 2020/07/26 22:40:52 uwe Exp $	*/
+/*	$NetBSD: gram.y,v 1.57 2024/01/18 04:41:37 thorpej Exp $	*/
 
 /*
  * Copyright (c) 1992, 1993
@@ -42,7 +42,7 @@
  */
 
 #include 
-__RCSID("$NetBSD: gram.y,v 1.56 2020/0

CVS commit: src/usr.bin/config

2024-01-17 Thread Jason R Thorpe
Module Name:src
Committed By:   thorpej
Date:   Thu Jan 18 04:41:38 UTC 2024

Modified Files:
src/usr.bin/config: config.5 defs.h gram.y main.c mkmakefile.c scan.l
util.c

Log Message:
With config(1) as it exists today, a kernel Makefile is able to implement
logic on kernel options so long as those options are not defflag'd or
defparam'd.  This works because such options are automatally added to the
IDENT var in the kernel Makefile as a preprocessor define, and the Makefile
can then do an operation like:

.if !empty(IDENT:M-DSOMECOOLCPUOPTION)
CFLAGS+= -mcpu=somecoolcpu
.endif

Unfortunately, this precludes making it possible to generate a compile-time
dependency on SOMECOOLCPUOPTION, or having SOMECOOLCPUOPTION imply another
kernel config option using the normal config(1) option dependency function.

Fix this by introducing a new option description keyword: mkflagvar.  This
keyword marks an already defflag'd option as wanting a kernel Makefile var
defined if that option is selected in the kernel config file.  So:

defflag opt_coolcpu.h SOMECOOLCPUOPTION ANOTHERCOOLCPUOPTION
mkflagvar SOMECOOLCPUOPTION ANOTHERCOOLCPUOPTION

will cause:

KERNEL_OPT_SOMECOOLCPUOPTION="1"
KERNEL_OPT_ANOTHERCOOLCPUOPTION="1"

...to be emitted into the kernel Makefile if those options are, in fact,
selected with "options ..." in the kernel config file, thus allowing for
a compile-time dependency on the option to be generated in addition to
Makefile logic, which now looks like:

.if !empty(KERNEL_OPT_SOMECOOLCPUOPTION)
CFLAGS+= -mcpu=somecoolcpu
.endif


To generate a diff of this commit:
cvs rdiff -u -r1.47 -r1.48 src/usr.bin/config/config.5
cvs rdiff -u -r1.106 -r1.107 src/usr.bin/config/defs.h
cvs rdiff -u -r1.56 -r1.57 src/usr.bin/config/gram.y
cvs rdiff -u -r1.100 -r1.101 src/usr.bin/config/main.c
cvs rdiff -u -r1.71 -r1.72 src/usr.bin/config/mkmakefile.c
cvs rdiff -u -r1.34 -r1.35 src/usr.bin/config/scan.l
cvs rdiff -u -r1.21 -r1.22 src/usr.bin/config/util.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/usr.bin/config

2021-10-12 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Tue Oct 12 17:14:10 UTC 2021

Modified Files:
src/usr.bin/config: lint.c

Log Message:
PR/56453: Wataru Ashihara: config(1): Assertion fails in config -L
Only compare pointers when one is found.


To generate a diff of this commit:
cvs rdiff -u -r1.15 -r1.16 src/usr.bin/config/lint.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/usr.bin/config

2021-10-12 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Tue Oct 12 17:14:10 UTC 2021

Modified Files:
src/usr.bin/config: lint.c

Log Message:
PR/56453: Wataru Ashihara: config(1): Assertion fails in config -L
Only compare pointers when one is found.


To generate a diff of this commit:
cvs rdiff -u -r1.15 -r1.16 src/usr.bin/config/lint.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/usr.bin/config/lint.c
diff -u src/usr.bin/config/lint.c:1.15 src/usr.bin/config/lint.c:1.16
--- src/usr.bin/config/lint.c:1.15	Wed Oct 29 13:14:50 2014
+++ src/usr.bin/config/lint.c	Tue Oct 12 13:14:10 2021
@@ -1,4 +1,4 @@
-/*	$NetBSD: lint.c,v 1.15 2014/10/29 17:14:50 christos Exp $	*/
+/*	$NetBSD: lint.c,v 1.16 2021/10/12 17:14:10 christos Exp $	*/
 
 /*
  *  Copyright (c) 2007 The NetBSD Foundation.
@@ -31,7 +31,7 @@
 #endif
 
 #include 
-__RCSID("$NetBSD: lint.c,v 1.15 2014/10/29 17:14:50 christos Exp $");
+__RCSID("$NetBSD: lint.c,v 1.16 2021/10/12 17:14:10 christos Exp $");
 
 #include 
 #include 
@@ -80,11 +80,11 @@ do_emit_option(const char *name, struct 
 	printf("%s\t%s", ot->ot_name, dl->dl_name);
 	if (ot->ot_type == OT_PARAM) {
 		struct defoptlist *dl2 = dlhash_lookup(defoptlint, dl->dl_name);
-		if (dl2 != NULL)
+		if (dl2 != NULL) {
+			assert(dl2 == dl);
 			value = dl2->dl_lintvalue;
-		else
+		} else
 			value = dl->dl_value;
-		assert(dl2 == dl);
 		printf("=\"%s\"", value ? value : "1");
 	}
 	printf("\n");



CVS commit: src/usr.bin/config

2021-08-25 Thread Roland Illig
Module Name:src
Committed By:   rillig
Date:   Wed Aug 25 23:07:34 UTC 2021

Modified Files:
src/usr.bin/config: sem.c

Log Message:
config: remove unused local variable


To generate a diff of this commit:
cvs rdiff -u -r1.85 -r1.86 src/usr.bin/config/sem.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/usr.bin/config/sem.c
diff -u src/usr.bin/config/sem.c:1.85 src/usr.bin/config/sem.c:1.86
--- src/usr.bin/config/sem.c:1.85	Tue Apr 13 03:09:42 2021
+++ src/usr.bin/config/sem.c	Wed Aug 25 23:07:34 2021
@@ -1,4 +1,4 @@
-/*	$NetBSD: sem.c,v 1.85 2021/04/13 03:09:42 mrg Exp $	*/
+/*	$NetBSD: sem.c,v 1.86 2021/08/25 23:07:34 rillig Exp $	*/
 
 /*
  * Copyright (c) 1992, 1993
@@ -45,7 +45,7 @@
 #endif
 
 #include 
-__RCSID("$NetBSD: sem.c,v 1.85 2021/04/13 03:09:42 mrg Exp $");
+__RCSID("$NetBSD: sem.c,v 1.86 2021/08/25 23:07:34 rillig Exp $");
 
 #include 
 #include 
@@ -950,7 +950,7 @@ resolve(struct nvlist **nvp, const char 
 	const char *cp;
 	devmajor_t maj;
 	devminor_t min;
-	size_t i, l;
+	size_t l;
 	int unit;
 	char buf[NAMESIZE];
 
@@ -1000,7 +1000,7 @@ resolve(struct nvlist **nvp, const char 
 	 * suffix, remove it if there, and split into name ("ra") and
 	 * unit (2).
 	 */
-	l = i = strlen(nv->nv_str);
+	l = strlen(nv->nv_str);
 	cp = &nv->nv_str[l];
 	if (l > 1 && *--cp >= 'a' && *cp < 'a' + maxpartitions &&
 	isdigit((unsigned char)cp[-1])) {



CVS commit: src/usr.bin/config

2021-08-25 Thread Roland Illig
Module Name:src
Committed By:   rillig
Date:   Wed Aug 25 23:07:34 UTC 2021

Modified Files:
src/usr.bin/config: sem.c

Log Message:
config: remove unused local variable


To generate a diff of this commit:
cvs rdiff -u -r1.85 -r1.86 src/usr.bin/config/sem.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



Re: CVS commit: src/usr.bin/config

2016-09-13 Thread Roy Marples
On 09/09/2016 22:09, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Fri Sep  9 21:09:11 UTC 2016
> 
> Modified Files:
>   src/usr.bin/config: defs.h files.c sem.c
> 
> Log Message:
> Make attribute deselection work:
> - when deselecting attributes, remove files that depend on them
> - when deselecting attributes, remove devices that depend on them
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.97 -r1.98 src/usr.bin/config/defs.h
> cvs rdiff -u -r1.35 -r1.36 src/usr.bin/config/files.c
> cvs rdiff -u -r1.75 -r1.76 src/usr.bin/config/sem.c

#   compile  config/sem.o
/home/roy/tools/amd64/bin/x86_64--netbsd-clang -O2 -g -fPIE
-fstack-protector -Wstack-protector  --param ssp-buffer-size=1
-std=gnu99 -Wno-sign-compare -Wno-pointer-sign  -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-sign-compare  -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow
-Wcast-
qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare
-Wold-style-definition -Wconversion -Wsign-compare -Wformat=2
-Wpointer-sign -Wmissing-no
return  -Werror -Wno-format-y2k  -pipe
--sysroot=/home/roy/src/src/obj/destdir.amd64
-I/home/roy/src/src/usr.bin/config -I. -I/home/roy/src/src/usr.bin/cksum
-D_FORTIFY_SOURCE=2 -c/home/roy/src/src/usr.bin/config/sem.c
/home/roy/src/src/usr.bin/config/sem.c:351:29: error: variable 'a' is
uninitialized when used here [-Werror,-Wuninitialized]
addvalue(V_ATTRIBUTE, a, dep));
  ^
/home/roy/src/src/usr.bin/config/defs.h:528:68: note: expanded from
macro 'ht_insert2'
#define ht_insert2(ht, nam1, nam2, val) ht_insrep2(ht, nam1, nam2, val, 0)
   ^~~
/home/roy/src/src/usr.bin/config/sem.c:336:16: note: initialize the
variable 'a' to silence this warning
struct attr *a, *dep;
  ^
   = NULL
1 error generated.
*** [sem.o] Error code 1


re: CVS commit: src/usr.bin/config

2015-09-03 Thread matthew green
Masao Uebayashi writes:
> On Fri, Sep 4, 2015 at 4:10 AM, matthew green  wrote:
> > Masao Uebayashi writes:
> >> They were intentionally overly strict.  Please put them back.  Or
> >> change them to not overly strict.
> >
> > there's no good reason to change either makeoptions to to force all options
> > to be listed in the files files.  like most of the items in config/TODO,
> > there is no rationale why these changes should be made.  i removed these
> > two items because they are things people *want* to remain.
> 
> I reread this sentence 5 times and found zero technical reasoning.

if you want to make a change it is up to you to show why it is
useful.  instead, you make a claim about purity, and want to
remove features people use.  please stop assuming that you know
every use-case and that everyone wants to be hampered by the tools
in this way.

the fact i use this feature *is* the reasoning.

> >> You make me wonder if I should add this to Makefile.kern.nc:
> >>
> >> ${SYSTEM_OBJ}: Makefile
> >
> > this is ridiculous.
> 
> What happens if you change maxusers and rebuild your kernel?

i don't know off hand.

i don't see what it has to do with the ridiculous suggestion
above, which if implemented would mean we should just go rip
out all opt_*.h support, and anything else like it.

ie, sure, it might get "correct" builds, but the cost is that
every time i run config, everything is rebuilt.  that's not a
sane suggestion.


.mrg.


Re: CVS commit: src/usr.bin/config

2015-09-03 Thread Masao Uebayashi
On Fri, Sep 4, 2015 at 4:10 AM, matthew green  wrote:
> Masao Uebayashi writes:
>> They were intentionally overly strict.  Please put them back.  Or
>> change them to not overly strict.
>
> there's no good reason to change either makeoptions to to force all options
> to be listed in the files files.  like most of the items in config/TODO,
> there is no rationale why these changes should be made.  i removed these
> two items because they are things people *want* to remain.

I reread this sentence 5 times and found zero technical reasoning.

>> You make me wonder if I should add this to Makefile.kern.nc:
>>
>> ${SYSTEM_OBJ}: Makefile
>
> this is ridiculous.

What happens if you change maxusers and rebuild your kernel?


re: CVS commit: src/usr.bin/config

2015-09-03 Thread matthew green
Masao Uebayashi writes:
> They were intentionally overly strict.  Please put them back.  Or
> change them to not overly strict.

there's no good reason to change either makeoptions to to force all options
to be listed in the files files.  like most of the items in config/TODO,
there is no rationale why these changes should be made.  i removed these
two items because they are things people *want* to remain.

> You make me wonder if I should add this to Makefile.kern.nc:
> 
> ${SYSTEM_OBJ}: Makefile

this is ridiculous.


.mrg.


Re: CVS commit: src/usr.bin/config

2015-09-03 Thread Masao Uebayashi
They were intentionally overly strict.  Please put them back.  Or
change them to not overly strict.

You make me wonder if I should add this to Makefile.kern.nc:

${SYSTEM_OBJ}: Makefile


Re: CVS commit: src/usr.bin/config

2015-08-31 Thread David Laight
On Sat, Aug 29, 2015 at 12:03:51PM +0900, Masao Uebayashi wrote:
> Such a hack is needed because config(1) has to generate rules
> explicitly for each *.[cS].  If you try to override a rule (e.g.
> compile this pmap_bootstrap.c with ${NOPROF_C}), it will be a
> duplicated rule.
> 
> If *.[cS] -> *.o will be written using suffix rules, you can safely
> override rules.  No order constraint too.

You may want to define an explicit dependency foo.o: foo.[cS] and then
rely on the suffix rule to supply the commands.
This saves make from having to hunt for the appropriate source file
and (probably) makes it easier to have MI fallback sources.

David

-- 
David Laight: da...@l8s.co.uk


re: CVS commit: src/usr.bin/config

2015-08-29 Thread matthew green
"Masao Uebayashi" writes:
> Module Name:  src
> Committed By: uebayasi
> Date: Fri Aug 28 08:31:28 UTC 2015
> 
> Modified Files:
>   src/usr.bin/config: mkmakefile.c
> 
> Log Message:
> Accept only relative paths (from $S) for `file' and `object'.  Simplify code.
> config(1) does not need to be super-smart about path handling, because it is
> usually used with make(1), that is much smarter.
> 
> Pre-compiled object files, specified using `object', are regarded as read-only
> input, thus they should be put under $S (or $S/..), as part of a source tree.

what is your reason for being so strict?

not being under $S was actually an original design point of
the "object" support, as i recall, so unless there's a really
good reason to be this strict, i would like you to revert this.


.mrg.


Re: CVS commit: src/usr.bin/config

2015-08-28 Thread Masao Uebayashi
Such a hack is needed because config(1) has to generate rules
explicitly for each *.[cS].  If you try to override a rule (e.g.
compile this pmap_bootstrap.c with ${NOPROF_C}), it will be a
duplicated rule.

If *.[cS] -> *.o will be written using suffix rules, you can safely
override rules.  No order constraint too.



Re: CVS commit: src/usr.bin/config

2015-08-28 Thread Quentin Garnier
On Fri, Aug 28, 2015 at 08:31:28AM +, Masao Uebayashi wrote:
> Module Name:  src
> Committed By: uebayasi
> Date: Fri Aug 28 08:31:28 UTC 2015
> 
> Modified Files:
>   src/usr.bin/config: mkmakefile.c
> 
> Log Message:
> Accept only relative paths (from $S) for `file' and `object'.  Simplify code.
> config(1) does not need to be super-smart about path handling, because it is
> usually used with make(1), that is much smarter.
> 
> Pre-compiled object files, specified using `object', are regarded as read-only
> input, thus they should be put under $S (or $S/..), as part of a source tree.

I'm pretty sure the original intent was to allow 3rd party drivers to be
distributed as an object file and a relevant config(5) file to be
included by the user in their GENERIC.  Which is why all the definition
gear is still allowed in the selection phase.  That also mean that
absolute paths for 'file' and 'object' have (had?) merit.

So, if you're discarding that code (I haven't looked at the actual diff)
you might want to consider bumping the syntax version and refusing older
versions.  That would probably get you some anger but hey, at this point
for you it's probably a drop in the ocean :-)

-- 
Quentin Garnier - c...@cubidou.net
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.


pgpNp7AJzrQHS.pgp
Description: PGP signature


Re: CVS commit: src/usr.bin/config

2015-08-28 Thread Masao Uebayashi
And there is $S/../common.  Need more thought..


Re: CVS commit: src/usr.bin/config

2015-08-28 Thread Masao Uebayashi
I will probably allow $S/.. only for `object' paths.  To realize
suffix rules, I have to dig subdirectories under kernel build
directory.  But that is only for files that are compiled.  I don't
need to dig subdirectories for objects whose relative path is
`../../../a/b/c'.


Re: CVS commit: src/usr.bin/config

2014-12-16 Thread Masao Uebayashi
Looking.  At least, on amd64, the failing tests don't touch "config"
at all, according to ktrace(1)...


Re: CVS commit: src/usr.bin/config

2014-12-16 Thread Ryota Ozaki
On Tue, Dec 16, 2014 at 12:49 AM, Masao Uebayashi  wrote:
> Module Name:src
> Committed By:   uebayasi
> Date:   Mon Dec 15 15:49:25 UTC 2014
>
> Modified Files:
> src/usr.bin/config: mkmakefile.c
>
> Log Message:
> Revert debug code.  Simplify.

http://releng.netbsd.org/b5reports/i386/commits-2014.12.html#2014.12.15.15.49.25

It seems this commit (and/or the previous commit) increases failures of ATF.

Regards,
  ozaki-r

>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.36 -r1.37 src/usr.bin/config/mkmakefile.c
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>


Re: CVS commit: src/usr.bin/config

2014-10-31 Thread Alan Barrett

On Thu, 30 Oct 2014, Taylor R Campbell wrote:

It seems to me that while depending on ordering for definitions,
files, &c., may be no good, for selections the language of

include "GENERIC"
no options DIAGNOSTIC
no agp*

is still valuable.


I don't mind how it's implemented, but my main concern is that I 
want an example like the above to "work".  I want it to mean: my 
kernel should be based on GENERIC with some changes; whether or 
not "options DIAGNOSTIC" is present in GENERIC, my kernel should 
not have "options DIAGNOSTIC"; and whether or not anything related 
to agp is present in GENERIC, my kernel should not have any agp 
devices (and should not have anything that depends on agp).  I 
do not want error messages like "options DIAGNOSTIC was already 
off, so you are not allowed to try to turn it off again" or "there 
were no agp devices, so you are not allowed to try to remove agp 
devices".


So config(1) ought to choose whatever is the last yes/no answer 
for a selection in order to decide what things are really 
enabled or disabled, and then process dependencies recursively 
from there, rather than incrementally processing dependencies as 
the parser makes progress.


That sounds as though it would do what I want.

--apb (Alan Barrett)


Re: CVS commit: src/usr.bin/config

2014-10-30 Thread Taylor R Campbell
   Date: Fri, 31 Oct 2014 03:36:45 +0900
   From: Masao Uebayashi 

   On Fri, Oct 31, 2014 at 1:49 AM, David Holland
wrote:
   > On Thu, Oct 30, 2014 at 09:27:06PM +0900, Masao Uebayashi wrote:
   >  > At this moment, "no" are evaluated when it's parsed.  Those "no agp*"
   >  > fallouts happened because agp is re-selected while resolving
   >  > dependency after all parsing is done.  IMO anything relying on order
   >  > tends to be broken by design.  For example: if BAR depends on FOO, "no
   >  > options FOO" has to disable BAR too, because BAR can't be enabled
   >  > without FOO.  But when you re-enable FOO, BAR is not enabled.  Is this
   >  > really what you're expecting?
   >
   > I think it's important not to break the semantics of this.

   Sure, but this makes me rather depressive.

It seems to me that while depending on ordering for definitions,
files, &c., may be no good, for selections the language of

include "GENERIC"
no options DIAGNOSTIC
no agp*

is still valuable.  So config(1) ought to choose whatever is the last
yes/no answer for a selection in order to decide what things are
really enabled or disabled, and then process dependencies recursively
from there, rather than incrementally processing dependencies as the
parser makes progress.

(But I've only been vaguely following from the sidelines, so feel free
to disregard me if that doesn't make any sense given how config(1)
works.)


Re: CVS commit: src/usr.bin/config

2014-10-30 Thread Masao Uebayashi
On Fri, Oct 31, 2014 at 1:49 AM, David Holland
 wrote:
> On Thu, Oct 30, 2014 at 09:27:06PM +0900, Masao Uebayashi wrote:
>  > So, while you expect that "options" works before it's defined, you
>  > also expect the order is honored for "no" use.  I'm not sure how it
>  > can work internally.
>  >
>  > At this moment, "no" are evaluated when it's parsed.  Those "no agp*"
>  > fallouts happened because agp is re-selected while resolving
>  > dependency after all parsing is done.  IMO anything relying on order
>  > tends to be broken by design.  For example: if BAR depends on FOO, "no
>  > options FOO" has to disable BAR too, because BAR can't be enabled
>  > without FOO.  But when you re-enable FOO, BAR is not enabled.  Is this
>  > really what you're expecting?
>
> I think it's important not to break the semantics of this.

Sure, but this makes me rather depressive.


Re: CVS commit: src/usr.bin/config

2014-10-30 Thread Masao Uebayashi
On Fri, Oct 31, 2014 at 3:00 AM, Antti Kantee  wrote:
> On 30/10/14 17:28, Masao Uebayashi wrote:
>>>
>>> Is there a problem rototilling config is going to solve over what
>>> is possible with the existing mechanism (*)?
>>
>>
>> You're welcomed to fix any problems without rotorill and/or breakage.
>
>
> You're not answering the question.

For one, to localize related objects (*.o).  Now config(1) just
collects all *.o and link them into "netbsd".  I want to collect for
example machdep related objects to be located in the lower address.
There might be a way to achieve this without touching config(1).  But
I think reusing information in config(1) definitions is the most
straightforward.

(I'll try to state this more clearly in TODO.)

>>> *) you probably also heard that rump kernels have constructors with
>>> priority levels, implemented using link sets
>>
>>
>> Do you hardcode the priority?
>
> Yes.  They are easy to hardcode, as you can observe from working code, and I
> don't see the need for a complex mechanism.  There's really only ~10, and
> even less for the full kernel, since you don't need to worry about things
> like "will vfs be present" or "when do i configure the address for lo0".
> Even if you'd want to worry about for example the latter one, how would you
> express it with config?

The latter is impossible.  Module dependency is only about init code order.

> But let's consider some magic values are generated by config in a fashion
> which works in a non-monolithic build.  How will anything be different if
> you touch or don't touch linksets, i.e. how is your question relevant in
> this discussion?
>
> Cleaning up init_main() is an ambitious project.  I don't know if config is
> the right tool for that (I don't know it's _not_, either).  I do know that
> it's complete orthogonal to how linksets are implemented.

I'm discussing multiple things and confusing contexts.

My question about linkset is more like: "using linker is good, but why
should it be linkset?".  I don't understand why their sections are not
under .text/.data/.bss.  I don't get why their section names have to
be exposed in the resulting "netbsd".

In any case I'll remove "linkset" part from TODO to not confuse people.


Re: CVS commit: src/usr.bin/config

2014-10-30 Thread Masao Uebayashi
On Fri, Oct 31, 2014 at 2:28 AM, Masao Uebayashi  wrote:
> On Fri, Oct 31, 2014 at 1:33 AM, Antti Kantee
>  wrote:
>> On Thu, Oct 30, 2014 at 11:14:50AM +0900, Masao Uebayashi wrote:
>>> On Thu, Oct 30, 2014 at 10:51 AM, Christos Zoulas  
>>> wrote:
>>> > In article <20141030012621.0982...@cvs.netbsd.org>,
>>> > Masao Uebayashi  wrote:
>>> >
>>> > Re: constructors/destructors:
>>> >
>>> > Using them will create a portability constraint on elf. This has
>>> > the implication that rump will not work on some platforms.
>>>
>>> Could you show me an example failure senario?  What do you propose instead?
>>>
>>> I heard that rump fixed linkset problem using .ctors/.dtors.
>>
>> I heard something different.
>>
>> A toolchain problem was fixed by using __attribute__((constructor))
>> to reach the contents of link sets in userspace dynamically linked
>> environments where generating __start/__stop was not possible.
>> Regular link sets are still preferred, as they require less magic
>> from the runtime.
>
> OK.
>
>> Is there a problem rototilling config is going to solve over what
>> is possible with the existing mechanism (*)?
>
> You're welcomed to fix any problems without rotorill and/or breakage.
>
>> The problem TODO lists
>> is "random ELF sections (with potentially long names) in the final
>> kernel".  Is that a problem?
>
> I may misremember it but was it Mach-O specific?  The "long name" part
> may be irrelevant.  But I still *feel* linkset should be done in a
> better way.  I'll revisit this when I will look closer at moduler vs.
> sysctl.

pooka@ is always far ahead & already fixed modular-vs-sysctl problems.

Now my complaint about linkset is that it doesn't properly put linkset
sections under .text/.data/.bss, etc.

I also want to utilize linker script in general, as said in TODO.


Re: CVS commit: src/usr.bin/config

2014-10-30 Thread Antti Kantee

On 30/10/14 17:28, Masao Uebayashi wrote:

Is there a problem rototilling config is going to solve over what
is possible with the existing mechanism (*)?


You're welcomed to fix any problems without rotorill and/or breakage.


You're not answering the question.


*) you probably also heard that rump kernels have constructors with
priority levels, implemented using link sets


Do you hardcode the priority?


Yes.  They are easy to hardcode, as you can observe from working code, 
and I don't see the need for a complex mechanism.  There's really only 
~10, and even less for the full kernel, since you don't need to worry 
about things like "will vfs be present" or "when do i configure the 
address for lo0".  Even if you'd want to worry about for example the 
latter one, how would you express it with config?


But let's consider some magic values are generated by config in a 
fashion which works in a non-monolithic build.  How will anything be 
different if you touch or don't touch linksets, i.e. how is your 
question relevant in this discussion?


Cleaning up init_main() is an ambitious project.  I don't know if config 
is the right tool for that (I don't know it's _not_, either).  I do know 
that it's complete orthogonal to how linksets are implemented.


Re: CVS commit: src/usr.bin/config

2014-10-30 Thread Masao Uebayashi
On Fri, Oct 31, 2014 at 1:33 AM, Antti Kantee
 wrote:
> On Thu, Oct 30, 2014 at 11:14:50AM +0900, Masao Uebayashi wrote:
>> On Thu, Oct 30, 2014 at 10:51 AM, Christos Zoulas  
>> wrote:
>> > In article <20141030012621.0982...@cvs.netbsd.org>,
>> > Masao Uebayashi  wrote:
>> >
>> > Re: constructors/destructors:
>> >
>> > Using them will create a portability constraint on elf. This has
>> > the implication that rump will not work on some platforms.
>>
>> Could you show me an example failure senario?  What do you propose instead?
>>
>> I heard that rump fixed linkset problem using .ctors/.dtors.
>
> I heard something different.
>
> A toolchain problem was fixed by using __attribute__((constructor))
> to reach the contents of link sets in userspace dynamically linked
> environments where generating __start/__stop was not possible.
> Regular link sets are still preferred, as they require less magic
> from the runtime.

OK.

> Is there a problem rototilling config is going to solve over what
> is possible with the existing mechanism (*)?

You're welcomed to fix any problems without rotorill and/or breakage.

> The problem TODO lists
> is "random ELF sections (with potentially long names) in the final
> kernel".  Is that a problem?

I may misremember it but was it Mach-O specific?  The "long name" part
may be irrelevant.  But I still *feel* linkset should be done in a
better way.  I'll revisit this when I will look closer at moduler vs.
sysctl.

> *) you probably also heard that rump kernels have constructors with
> priority levels, implemented using link sets

Do you hardcode the priority?


Re: CVS commit: src/usr.bin/config

2014-10-30 Thread Masao Uebayashi
On Thu, Oct 30, 2014 at 10:01 PM, Quentin Garnier  wrote:
> On Thu, Oct 30, 2014 at 09:27:06PM +0900, Masao Uebayashi wrote:
>> On Thu, Oct 30, 2014 at 8:36 PM, Alan Barrett  wrote:
>> > On Thu, 30 Oct 2014, Masao Uebayashi wrote:
>> >>
>> >> What do you expect by doing:
>> >>
>> >>  options FOO
>> >>  no options FOO
>> >>  options FOO
>> >
>> > I expect it to be equivalent to just one "options FOO".
>> >
>> > The "no options FOO" in line 2 should cancel the "options FOO" in line 1,
>> > and then the "options FOO" in line 3 should put it back.
>> >
>> > In the cases that I care about, the "options" and "no options" lines will 
>> > be
>> > in different files, referenced via "include" directives.
>>
>> So, while you expect that "options" works before it's defined, you
>> also expect the order is honored for "no" use.  I'm not sure how it
>> can work internally.
>>
>> At this moment, "no" are evaluated when it's parsed.  Those "no agp*"
>> fallouts happened because agp is re-selected while resolving
>> dependency after all parsing is done.  IMO anything relying on order
>> tends to be broken by design.  For example: if BAR depends on FOO, "no
>> options FOO" has to disable BAR too, because BAR can't be enabled
>> without FOO.  But when you re-enable FOO, BAR is not enabled.  Is this
>> really what you're expecting?
>
> I don't know how it is right now, but options didn't use to depend on
> other options so with "options" the case is moot and I would expect the
> behaviour Alan describes as correct (this is how it worked the last time
> I touched config(1), or at least, was meant to work).

OK, my example was confusing, I meant module (attribute-as-module) by
"options FOO".  Because config(1) has had no way to directly select a
module, I abused/extended "options" to select a module.  I'm reverting
it and adding a generic "select" directive which selects a specified
module and its dependency modules.

For options, you're right, options (flags/params) don't have
dependency.  I don't mean to extend it too.  I try to address apb@'s
item.

> For devices, I spent quite a bit of effort making sure "no" behaved the
> way Alan expects it.  For instance:
>
> include "GENERIC"
>
> this* at pci? dev ? fun ?
> no device pci
> that* at pci? dev ? fun ?
>
> would emit an error for "that*" but not for "this*".  Moreover, without
> the last line, none of "this*" or anything pci-related in GENERIC would
> actually be selected.

I don't fully understand the device part (especially "no" behavior),
but I assume they basically expect things are already defined, right?

> So if you start making defopt more equivalent to define and allow
> "options BAR" to depend on "options FOO", then I would expect
> "no options FOO" to cancel a previous "options BAR".
>
> Otherwise defopt and define used to have very different semantics.

I don't mean to make "defopt" (flags/params) to be like "define".
(Said so in TODO.)

I mean to make "device" (and hopefully "attach") to be more like
"define" though.


Re: CVS commit: src/usr.bin/config

2014-10-30 Thread David Holland
On Thu, Oct 30, 2014 at 09:27:06PM +0900, Masao Uebayashi wrote:
 > So, while you expect that "options" works before it's defined, you
 > also expect the order is honored for "no" use.  I'm not sure how it
 > can work internally.
 > 
 > At this moment, "no" are evaluated when it's parsed.  Those "no agp*"
 > fallouts happened because agp is re-selected while resolving
 > dependency after all parsing is done.  IMO anything relying on order
 > tends to be broken by design.  For example: if BAR depends on FOO, "no
 > options FOO" has to disable BAR too, because BAR can't be enabled
 > without FOO.  But when you re-enable FOO, BAR is not enabled.  Is this
 > really what you're expecting?

I think it's important not to break the semantics of this.

-- 
David A. Holland
dholl...@netbsd.org


Re: CVS commit: src/usr.bin/config

2014-10-30 Thread Antti Kantee
On Thu, Oct 30, 2014 at 11:14:50AM +0900, Masao Uebayashi wrote:
> On Thu, Oct 30, 2014 at 10:51 AM, Christos Zoulas  wrote:
> > In article <20141030012621.0982...@cvs.netbsd.org>,
> > Masao Uebayashi  wrote:
> >
> > Re: constructors/destructors:
> >
> > Using them will create a portability constraint on elf. This has
> > the implication that rump will not work on some platforms.
> 
> Could you show me an example failure senario?  What do you propose instead?
> 
> I heard that rump fixed linkset problem using .ctors/.dtors.

I heard something different.

A toolchain problem was fixed by using __attribute__((constructor))
to reach the contents of link sets in userspace dynamically linked
environments where generating __start/__stop was not possible.
Regular link sets are still preferred, as they require less magic
from the runtime.

Is there a problem rototilling config is going to solve over what
is possible with the existing mechanism (*)?  The problem TODO lists
is "random ELF sections (with potentially long names) in the final
kernel".  Is that a problem?

*) you probably also heard that rump kernels have constructors with
priority levels, implemented using link sets


Re: CVS commit: src/usr.bin/config

2014-10-30 Thread Christos Zoulas
In article <54522b88.7060...@gmail.com>,
Takahiro HAYASHI   wrote:
>On 10/30/14 10:36, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Thu Oct 30 01:36:13 UTC 2014
>>
>> Modified Files:
>>  src/usr.bin/config: mkheaders.c
>>
>> Log Message:
>> print more info about the overflow
>
>It panics on amd64 when negative value is specified like RTC_OFFSET=-540.
>
>/build/head/obj.amd64/tooldir.NetBSD-7.99.1-amd64/bin/nbconfig: panic:
>overflow -540 = 0xfde4

Fixed, thanks!

christos



Re: CVS commit: src/usr.bin/config

2014-10-30 Thread Quentin Garnier
On Thu, Oct 30, 2014 at 09:27:06PM +0900, Masao Uebayashi wrote:
> On Thu, Oct 30, 2014 at 8:36 PM, Alan Barrett  wrote:
> > On Thu, 30 Oct 2014, Masao Uebayashi wrote:
> >>
> >> What do you expect by doing:
> >>
> >>  options FOO
> >>  no options FOO
> >>  options FOO
> >
> > I expect it to be equivalent to just one "options FOO".
> >
> > The "no options FOO" in line 2 should cancel the "options FOO" in line 1,
> > and then the "options FOO" in line 3 should put it back.
> >
> > In the cases that I care about, the "options" and "no options" lines will be
> > in different files, referenced via "include" directives.
> 
> So, while you expect that "options" works before it's defined, you
> also expect the order is honored for "no" use.  I'm not sure how it
> can work internally.
> 
> At this moment, "no" are evaluated when it's parsed.  Those "no agp*"
> fallouts happened because agp is re-selected while resolving
> dependency after all parsing is done.  IMO anything relying on order
> tends to be broken by design.  For example: if BAR depends on FOO, "no
> options FOO" has to disable BAR too, because BAR can't be enabled
> without FOO.  But when you re-enable FOO, BAR is not enabled.  Is this
> really what you're expecting?

I don't know how it is right now, but options didn't use to depend on
other options so with "options" the case is moot and I would expect the
behaviour Alan describes as correct (this is how it worked the last time
I touched config(1), or at least, was meant to work).

For devices, I spent quite a bit of effort making sure "no" behaved the
way Alan expects it.  For instance:

include "GENERIC"

this* at pci? dev ? fun ?
no device pci
that* at pci? dev ? fun ?

would emit an error for "that*" but not for "this*".  Moreover, without
the last line, none of "this*" or anything pci-related in GENERIC would
actually be selected.

So if you start making defopt more equivalent to define and allow
"options BAR" to depend on "options FOO", then I would expect
"no options FOO" to cancel a previous "options BAR".

Otherwise defopt and define used to have very different semantics.

-- 
Quentin Garnier - c...@cubidou.net
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.


pgpH8ruph4GRz.pgp
Description: PGP signature


Re: CVS commit: src/usr.bin/config

2014-10-30 Thread Masao Uebayashi
On Thu, Oct 30, 2014 at 8:36 PM, Alan Barrett  wrote:
> On Thu, 30 Oct 2014, Masao Uebayashi wrote:
>>
>> What do you expect by doing:
>>
>>  options FOO
>>  no options FOO
>>  options FOO
>
> I expect it to be equivalent to just one "options FOO".
>
> The "no options FOO" in line 2 should cancel the "options FOO" in line 1,
> and then the "options FOO" in line 3 should put it back.
>
> In the cases that I care about, the "options" and "no options" lines will be
> in different files, referenced via "include" directives.

So, while you expect that "options" works before it's defined, you
also expect the order is honored for "no" use.  I'm not sure how it
can work internally.

At this moment, "no" are evaluated when it's parsed.  Those "no agp*"
fallouts happened because agp is re-selected while resolving
dependency after all parsing is done.  IMO anything relying on order
tends to be broken by design.  For example: if BAR depends on FOO, "no
options FOO" has to disable BAR too, because BAR can't be enabled
without FOO.  But when you re-enable FOO, BAR is not enabled.  Is this
really what you're expecting?


Re: CVS commit: src/usr.bin/config

2014-10-30 Thread Takahiro HAYASHI

On 10/30/14 10:36, Christos Zoulas wrote:

Module Name:src
Committed By:   christos
Date:   Thu Oct 30 01:36:13 UTC 2014

Modified Files:
src/usr.bin/config: mkheaders.c

Log Message:
print more info about the overflow


It panics on amd64 when negative value is specified like RTC_OFFSET=-540.

/build/head/obj.amd64/tooldir.NetBSD-7.99.1-amd64/bin/nbconfig: panic: overflow 
-540 = 0xfde4

Thanks,
--
t-hash


Re: CVS commit: src/usr.bin/config

2014-10-30 Thread Alan Barrett

On Thu, 30 Oct 2014, Masao Uebayashi wrote:

What do you expect by doing:

 options FOO
 no options FOO
 options FOO


I expect it to be equivalent to just one "options FOO".

The "no options FOO" in line 2 should cancel the "options FOO" in 
line 1, and then the "options FOO" in line 3 should put it back.


In the cases that I care about, the "options" and "no options" 
lines will be in different files, referenced via "include" 
directives.


--apb (Alan Barrett)


Re: CVS commit: src/usr.bin/config

2014-10-29 Thread Masao Uebayashi
On Thu, Oct 30, 2014 at 11:38 AM, Matt Thomas  wrote:
> arm doesn’t use .ctors/.dtors
>
> it has init/fini array instead.

The section names don't really matter.  Probably .kctors/.kdtors are
less confusing (+ to avoid confliction with rump).

> and where would they be executed?

Somewhere in sys/kern/init_main.c:main().  Kernel executes modules'
constructors.  I believe that Linux has already done the same way.


Re: CVS commit: src/usr.bin/config

2014-10-29 Thread Matt Thomas

> On Oct 29, 2014, at 7:30 PM, Christos Zoulas  wrote:
> 
> On Oct 30, 11:14am, uebay...@gmail.com (Masao Uebayashi) wrote:
> -- Subject: Re: CVS commit: src/usr.bin/config
> 
> | Could you show me an example failure senario?  What do you propose instead?
> 
> I don't have anything *better* to propose. I think mach-o constructors
> are different.
> 
> | I heard that rump fixed linkset problem using .ctors/.dtors.
> | 
> | But .ctors/.dtors in kernel is just analogy of the userland one; it
> | may use the same section names but the internal behavior can be
> | defferent.
> 
> Sure, I am not sure that all the object formats support them though.

arm doesn’t use .ctors/.dtors 

it has init/fini array instead.

and where would they be executed?

Re: CVS commit: src/usr.bin/config

2014-10-29 Thread Christos Zoulas
On Oct 30, 11:14am, uebay...@gmail.com (Masao Uebayashi) wrote:
-- Subject: Re: CVS commit: src/usr.bin/config

| Could you show me an example failure senario?  What do you propose instead?

I don't have anything *better* to propose. I think mach-o constructors
are different.

| I heard that rump fixed linkset problem using .ctors/.dtors.
| 
| But .ctors/.dtors in kernel is just analogy of the userland one; it
| may use the same section names but the internal behavior can be
| defferent.

Sure, I am not sure that all the object formats support them though.

christos


Re: CVS commit: src/usr.bin/config

2014-10-29 Thread Masao Uebayashi
What do you expect by doing:

  options FOO
  no options FOO
  options FOO

?


Re: CVS commit: src/usr.bin/config

2014-10-29 Thread Masao Uebayashi
On Thu, Oct 30, 2014 at 10:51 AM, Christos Zoulas  wrote:
> In article <20141030012621.0982...@cvs.netbsd.org>,
> Masao Uebayashi  wrote:
>
> Re: constructors/destructors:
>
> Using them will create a portability constraint on elf. This has
> the implication that rump will not work on some platforms.

Could you show me an example failure senario?  What do you propose instead?

I heard that rump fixed linkset problem using .ctors/.dtors.

But .ctors/.dtors in kernel is just analogy of the userland one; it
may use the same section names but the internal behavior can be
defferent.


Re: CVS commit: src/usr.bin/config

2014-10-29 Thread Christos Zoulas
In article <20141030012621.0982...@cvs.netbsd.org>,
Masao Uebayashi  wrote:

Re: constructors/destructors:

Using them will create a portability constraint on elf. This has
the implication that rump will not work on some platforms.

christos



Re: CVS commit: src/usr.bin/config

2014-10-10 Thread Masao Uebayashi
My bad.  Reproduced here.  Hopefully fixed now.

On Fri, Oct 10, 2014 at 10:55 PM, Jared McNeill  wrote:
> Are you able to build the arch/evbarm/conf/CUBIEBOARD kernel with these
> changes?
>
> The kernel config has "options CPU_CORTEXA7", which depends on CPU_CORTEX,
> which depends on CPU_ARMV7. Neither CPU_CORTEX nor CPU_ARMV7 are defined in
> opt_cputypes.h
>
> On Fri, 10 Oct 2014, Masao Uebayashi wrote:
>
>> Date: Fri, 10 Oct 2014 10:22:49 +
>> From: Masao Uebayashi 
>> Reply-To: source-changes-d-qavaossjccednm+yrof...@public.gmane.org
>> To: source-changes-full-qavaossjccednm+yrof...@public.gmane.org
>> Newsgroups: gmane.os.netbsd.devel.cvs.full
>> Followup-To: gmane.os.netbsd.devel.cvs.discuss
>> Subject: CVS commit: src/usr.bin/config
>>
>>
>> Module Name:src
>> Committed By:   uebayasi
>> Date:   Fri Oct 10 10:22:49 UTC 2014
>>
>> Modified Files:
>> src/usr.bin/config: main.c
>>
>> Log Message:
>> If an option is selected, select the matching (lowercased) attribute.
>> Handle
>> dependencies too.
>>
>>
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.60 -r1.61 src/usr.bin/config/main.c
>>
>> Please note that diffs are not public domain; they are subject to the
>> copyright notices on the relevant files.
>>
>>
>


Re: CVS commit: src/usr.bin/config

2014-10-10 Thread Jared McNeill
Are you able to build the arch/evbarm/conf/CUBIEBOARD kernel with these 
changes?


The kernel config has "options CPU_CORTEXA7", which depends on 
CPU_CORTEX, which depends on CPU_ARMV7. Neither CPU_CORTEX nor CPU_ARMV7 
are defined in opt_cputypes.h


On Fri, 10 Oct 2014, Masao Uebayashi wrote:


Date: Fri, 10 Oct 2014 10:22:49 +
From: Masao Uebayashi 
Reply-To: source-changes-d-qavaossjccednm+yrof...@public.gmane.org
To: source-changes-full-qavaossjccednm+yrof...@public.gmane.org
Newsgroups: gmane.os.netbsd.devel.cvs.full
Followup-To: gmane.os.netbsd.devel.cvs.discuss
Subject: CVS commit: src/usr.bin/config

Module Name:src
Committed By:   uebayasi
Date:   Fri Oct 10 10:22:49 UTC 2014

Modified Files:
src/usr.bin/config: main.c

Log Message:
If an option is selected, select the matching (lowercased) attribute.  Handle
dependencies too.


To generate a diff of this commit:
cvs rdiff -u -r1.60 -r1.61 src/usr.bin/config/main.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




Re: CVS commit: src/usr.bin/config

2014-10-10 Thread Thomas Klausner
On Thu, Oct 09, 2014 at 07:20:56PM +, Masao Uebayashi wrote:
> Module Name:  src
> Committed By: uebayasi
> Date: Thu Oct  9 19:20:56 UTC 2014
> 
> Modified Files:
>   src/usr.bin/config: defs.h main.c mkmakefile.c
> 
> Log Message:
> Steal -M to enable "modular" build.

Can you please document this in the manpage?

Thanks,
 Thomas

> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.50 -r1.51 src/usr.bin/config/defs.h
> cvs rdiff -u -r1.57 -r1.58 src/usr.bin/config/main.c
> cvs rdiff -u -r1.20 -r1.21 src/usr.bin/config/mkmakefile.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 


Re: CVS commit: src/usr.bin/config

2013-11-01 Thread Christos Zoulas
On Nov 1, 11:04pm, u...@stderr.spb.ru (Valery Ushakov) wrote:
-- Subject: Re: CVS commit: src/usr.bin/config

| On Fri, Nov 01, 2013 at 13:09:59 -0400, Christos Zoulas wrote:
| 
| > Module Name:src
| > Committed By:   christos
| > Date:   Fri Nov  1 17:09:59 UTC 2013
| > 
| > Modified Files:
| > src/usr.bin/config: main.c util.c
| > 
| > Log Message:
| > make config errors look more like other programs: ,:
| > instead of ::
| 
| Eh?  Most programs use file:line:

I got that backwards, I will revert.

christos


Re: CVS commit: src/usr.bin/config

2013-11-01 Thread Valery Ushakov
On Fri, Nov 01, 2013 at 13:09:59 -0400, Christos Zoulas wrote:

> Module Name:  src
> Committed By: christos
> Date: Fri Nov  1 17:09:59 UTC 2013
> 
> Modified Files:
>   src/usr.bin/config: main.c util.c
> 
> Log Message:
> make config errors look more like other programs: ,:
> instead of ::

Eh?  Most programs use file:line:

-uwe


Re: CVS commit: src/usr.bin/config

2012-08-30 Thread Christos Zoulas
On Aug 31, 12:02am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/usr.bin/config

| Probably it's better to use #if !defined(HAVE_NBTOOL_CONFIG_H)
| rather than #ifdef __NetBSD__ ?

I'll have to think about it a little more (i.e. what's the scenario
of building NetBSD on NetBSD and does the cross config work?), but
I don't mind if it is ok.

christos


Re: CVS commit: src/usr.bin/config

2012-08-30 Thread Izumi Tsutsui
> Modified Files:
>   src/usr.bin/config: config.1 main.c
> 
> Log Message:
> make config -x look at the booted kernel first.

Probably it's better to use #if !defined(HAVE_NBTOOL_CONFIG_H)
rather than #ifdef __NetBSD__ ?

---
Izumi Tsutsui


CVS commit: src/usr.bin/config

2010-03-08 Thread Antti Kantee
Module Name:src
Committed By:   pooka
Date:   Mon Mar  8 11:12:32 UTC 2010

Modified Files:
src/usr.bin/config: gram.y

Log Message:
print ioconf WARNING in caps too


To generate a diff of this commit:
cvs rdiff -u -r1.22 -r1.23 src/usr.bin/config/gram.y

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/usr.bin/config

2010-03-08 Thread Antti Kantee
Module Name:src
Committed By:   pooka
Date:   Mon Mar  8 11:12:32 UTC 2010

Modified Files:
src/usr.bin/config: gram.y

Log Message:
print ioconf WARNING in caps too


To generate a diff of this commit:
cvs rdiff -u -r1.22 -r1.23 src/usr.bin/config/gram.y

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/usr.bin/config/gram.y
diff -u src/usr.bin/config/gram.y:1.22 src/usr.bin/config/gram.y:1.23
--- src/usr.bin/config/gram.y:1.22	Mon Mar  8 10:19:14 2010
+++ src/usr.bin/config/gram.y	Mon Mar  8 11:12:32 2010
@@ -1,5 +1,5 @@
 %{
-/*	$NetBSD: gram.y,v 1.22 2010/03/08 10:19:14 pooka Exp $	*/
+/*	$NetBSD: gram.y,v 1.23 2010/03/08 11:12:32 pooka Exp $	*/
 
 /*
  * Copyright (c) 1992, 1993
@@ -621,7 +621,7 @@
 	struct nvlist *nv;
 
 	if (isioconf) {
-		fprintf(stderr, "warning: ioconf is an experimental feature\n");
+		fprintf(stderr, "WARNING: ioconf is an experimental feature\n");
 		if (include(_PATH_DEVNULL, ENDDEFS, 0, 0) != 0)
 			exit(1);
 		ioconfname = mch;



CVS commit: src/usr.bin/config

2010-03-08 Thread Antti Kantee
Module Name:src
Committed By:   pooka
Date:   Mon Mar  8 10:19:15 UTC 2010

Modified Files:
src/usr.bin/config: defs.h gram.y main.c pack.c scan.l sem.c sem.h

Log Message:
Add a highly experimental pseudo-root feature to be used in conjuction
with the also-experimental ioconf keyword.  pseudo-root allows to
specify a root at any point in the device tree without having
attachments from the actual root.

For example, instead of having a config file like this:
mainbus0 at root
bus_a? at mainbus0
bus_b? at bus_a*
device7 at bus_b?

You can have one like this:
pseudo-root bus_b*
device7 at bus_b?

This will produce the relevant ioconf.c glue for device number 7
only instead of the whole 9 yards from root.  Perhaps needless to
say, this can be used to generate snippets of config glue for
modules and, let's not deny that my main motivation for doing this,
rump components.

This is part 2/3 of my modifications to config (the last part is
autogenerating source file lists and component Makefiles).

No strong objection from cube (after a little pressuring ;), but
like he said, the implementation will most likely need some more
tweaking and may not work correctly under all pseudo-root uses yet.


To generate a diff of this commit:
cvs rdiff -u -r1.32 -r1.33 src/usr.bin/config/defs.h
cvs rdiff -u -r1.21 -r1.22 src/usr.bin/config/gram.y
cvs rdiff -u -r1.40 -r1.41 src/usr.bin/config/main.c
cvs rdiff -u -r1.7 -r1.8 src/usr.bin/config/pack.c
cvs rdiff -u -r1.14 -r1.15 src/usr.bin/config/scan.l
cvs rdiff -u -r1.33 -r1.34 src/usr.bin/config/sem.c
cvs rdiff -u -r1.5 -r1.6 src/usr.bin/config/sem.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/usr.bin/config/defs.h
diff -u src/usr.bin/config/defs.h:1.32 src/usr.bin/config/defs.h:1.33
--- src/usr.bin/config/defs.h:1.32	Wed Mar  3 13:53:22 2010
+++ src/usr.bin/config/defs.h	Mon Mar  8 10:19:14 2010
@@ -1,4 +1,4 @@
-/*	$NetBSD: defs.h,v 1.32 2010/03/03 13:53:22 pooka Exp $	*/
+/*	$NetBSD: defs.h,v 1.33 2010/03/08 10:19:14 pooka Exp $	*/
 
 /*
  * Copyright (c) 1992, 1993
@@ -260,6 +260,7 @@
 #define	DEVI_ACTIVE	1	/* instance has an active parent */
 #define	DEVI_IGNORED	2	/* instance's parent has been removed */
 #define DEVI_BROKEN	3	/* instance is broken (syntax error) */
+	int	i_pseudoroot;	/* instance is pseudoroot */
 
 	/* created during packing or ioconf.c generation */
 	short	i_collapsed;	/* set => this alias no longer needed */

Index: src/usr.bin/config/gram.y
diff -u src/usr.bin/config/gram.y:1.21 src/usr.bin/config/gram.y:1.22
--- src/usr.bin/config/gram.y:1.21	Wed Mar  3 13:53:22 2010
+++ src/usr.bin/config/gram.y	Mon Mar  8 10:19:14 2010
@@ -1,5 +1,5 @@
 %{
-/*	$NetBSD: gram.y,v 1.21 2010/03/03 13:53:22 pooka Exp $	*/
+/*	$NetBSD: gram.y,v 1.22 2010/03/08 10:19:14 pooka Exp $	*/
 
 /*
  * Copyright (c) 1992, 1993
@@ -111,7 +111,7 @@
 %token	XMACHINE MAJOR MAKEOPTIONS MAXUSERS MAXPARTITIONS MINOR
 %token	NEEDS_COUNT NEEDS_FLAG NO
 %token	XOBJECT OBSOLETE ON OPTIONS
-%token	PACKAGE PLUSEQ PREFIX PSEUDO_DEVICE
+%token	PACKAGE PLUSEQ PREFIX PSEUDO_DEVICE PSEUDO_ROOT
 %token	ROOT
 %token	SOURCE
 %token	TYPE
@@ -464,6 +464,7 @@
 	NO CONFIG WORD			{ delconf($3); } |
 	NO PSEUDO_DEVICE WORD		{ delpseudo($3); } |
 	PSEUDO_DEVICE WORD npseudo	{ addpseudo($2, $3); } |
+	PSEUDO_ROOT device_instance	{ addpseudoroot($2); } |
 	NO device_instance AT attachment
 	{ deldevi($2, $4); } |
 	NO DEVICE AT attachment		{ deldeva($4); } |

Index: src/usr.bin/config/main.c
diff -u src/usr.bin/config/main.c:1.40 src/usr.bin/config/main.c:1.41
--- src/usr.bin/config/main.c:1.40	Wed Mar  3 13:56:29 2010
+++ src/usr.bin/config/main.c	Mon Mar  8 10:19:14 2010
@@ -1,4 +1,4 @@
-/*	$NetBSD: main.c,v 1.40 2010/03/03 13:56:29 pooka Exp $	*/
+/*	$NetBSD: main.c,v 1.41 2010/03/08 10:19:14 pooka Exp $	*/
 
 /*
  * Copyright (c) 1992, 1993
@@ -1026,8 +1026,14 @@
 {
 	struct devi *i;
 
+	/*
+	 * EHAMMERTOOBIG: we shouldn't check i_pseudoroot here.
+	 * What we want by this check is them to appear non-present
+	 * except for purposes of other devices being able to attach
+	 * to them.
+	 */
 	for (i = deva->d_ihead; i != NULL; i = i->i_asame)
-		if (i->i_active == DEVI_ACTIVE &&
+		if (i->i_active == DEVI_ACTIVE && i->i_pseudoroot == 0 &&
 		(unit == WILD || unit == i->i_unit || i->i_unit == STAR))
 			return (1);
 	return (0);

Index: src/usr.bin/config/pack.c
diff -u src/usr.bin/config/pack.c:1.7 src/usr.bin/config/pack.c:1.8
--- src/usr.bin/config/pack.c:1.7	Thu Jan 21 18:06:38 2010
+++ src/usr.bin/config/pack.c	Mon Mar  8 10:19:14 2010
@@ -1,4 +1,4 @@
-/*	$NetBSD: pack.c,v 1.7 2010/01/21 18:06:38 pooka Exp $	*/
+/*	$NetBSD: pack.c,v 1.8 2010/03/08 10:19:14 pooka Exp $	*/
 
 /*
  * Copyright (c) 1992, 1993
@@ -187,7 +187,8 @@
 		for (i = d->d_ihead; i != NULL; i = i->i_bsame) {
 			m = n;
 			for (l = i; l != NULL; l = l->i_alias) {
-if (l->i_active != DEVI_ACTIVE)
+if (l->

CVS commit: src/usr.bin/config

2010-03-08 Thread Antti Kantee
Module Name:src
Committed By:   pooka
Date:   Mon Mar  8 10:19:15 UTC 2010

Modified Files:
src/usr.bin/config: defs.h gram.y main.c pack.c scan.l sem.c sem.h

Log Message:
Add a highly experimental pseudo-root feature to be used in conjuction
with the also-experimental ioconf keyword.  pseudo-root allows to
specify a root at any point in the device tree without having
attachments from the actual root.

For example, instead of having a config file like this:
mainbus0 at root
bus_a? at mainbus0
bus_b? at bus_a*
device7 at bus_b?

You can have one like this:
pseudo-root bus_b*
device7 at bus_b?

This will produce the relevant ioconf.c glue for device number 7
only instead of the whole 9 yards from root.  Perhaps needless to
say, this can be used to generate snippets of config glue for
modules and, let's not deny that my main motivation for doing this,
rump components.

This is part 2/3 of my modifications to config (the last part is
autogenerating source file lists and component Makefiles).

No strong objection from cube (after a little pressuring ;), but
like he said, the implementation will most likely need some more
tweaking and may not work correctly under all pseudo-root uses yet.


To generate a diff of this commit:
cvs rdiff -u -r1.32 -r1.33 src/usr.bin/config/defs.h
cvs rdiff -u -r1.21 -r1.22 src/usr.bin/config/gram.y
cvs rdiff -u -r1.40 -r1.41 src/usr.bin/config/main.c
cvs rdiff -u -r1.7 -r1.8 src/usr.bin/config/pack.c
cvs rdiff -u -r1.14 -r1.15 src/usr.bin/config/scan.l
cvs rdiff -u -r1.33 -r1.34 src/usr.bin/config/sem.c
cvs rdiff -u -r1.5 -r1.6 src/usr.bin/config/sem.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/usr.bin/config

2010-03-03 Thread Antti Kantee
Module Name:src
Committed By:   pooka
Date:   Wed Mar  3 13:56:30 UTC 2010

Modified Files:
src/usr.bin/config: main.c

Log Message:
reflect previous change in comment


To generate a diff of this commit:
cvs rdiff -u -r1.39 -r1.40 src/usr.bin/config/main.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/usr.bin/config

2010-03-03 Thread Antti Kantee
Module Name:src
Committed By:   pooka
Date:   Wed Mar  3 13:56:30 UTC 2010

Modified Files:
src/usr.bin/config: main.c

Log Message:
reflect previous change in comment


To generate a diff of this commit:
cvs rdiff -u -r1.39 -r1.40 src/usr.bin/config/main.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/usr.bin/config/main.c
diff -u src/usr.bin/config/main.c:1.39 src/usr.bin/config/main.c:1.40
--- src/usr.bin/config/main.c:1.39	Wed Mar  3 13:53:22 2010
+++ src/usr.bin/config/main.c	Wed Mar  3 13:56:29 2010
@@ -1,4 +1,4 @@
-/*	$NetBSD: main.c,v 1.39 2010/03/03 13:53:22 pooka Exp $	*/
+/*	$NetBSD: main.c,v 1.40 2010/03/03 13:56:29 pooka Exp $	*/
 
 /*
  * Copyright (c) 1992, 1993
@@ -603,10 +603,7 @@
 }
 
 /*
- * Define one or more file systems.  If file system options file name is
- * specified, a preprocessor #define for that file system will be placed
- * in that file.  In this case, only one file system may be specified.
- * Otherwise, no preprocessor #defines will be generated.
+ * Define one or more file systems.
  */
 void
 deffilesystem(struct nvlist *fses, struct nvlist *deps)



CVS commit: src/usr.bin/config

2010-03-03 Thread Antti Kantee
Module Name:src
Committed By:   pooka
Date:   Wed Mar  3 13:53:22 UTC 2010

Modified Files:
src/usr.bin/config: config.5 defs.h gram.y main.c

Log Message:
Remove fs_foo.h support from deffs now that nothing uses it.


To generate a diff of this commit:
cvs rdiff -u -r1.20 -r1.21 src/usr.bin/config/config.5 \
src/usr.bin/config/gram.y
cvs rdiff -u -r1.31 -r1.32 src/usr.bin/config/defs.h
cvs rdiff -u -r1.38 -r1.39 src/usr.bin/config/main.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/usr.bin/config/config.5
diff -u src/usr.bin/config/config.5:1.20 src/usr.bin/config/config.5:1.21
--- src/usr.bin/config/config.5:1.20	Fri Feb 20 05:26:51 2009
+++ src/usr.bin/config/config.5	Wed Mar  3 13:53:22 2010
@@ -1,4 +1,4 @@
-.\" $NetBSD: config.5,v 1.20 2009/02/20 05:26:51 cube Exp $
+.\" $NetBSD: config.5,v 1.21 2010/03/03 13:53:22 pooka Exp $
 .\"
 .\"  Copyright (c) 2006, 2007 The NetBSD Foundation.
 .\"  All rights reserved.
@@ -24,7 +24,7 @@
 .\"  ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 .\"  POSSIBILITY OF SUCH DAMAGE.
 .\"
-.Dd February 20, 2009
+.Dd March 3, 2010
 .Dt CONFIG 5
 .Os
 .Sh NAME
@@ -355,7 +355,7 @@
 will use it as a value when generating a lint configuration with
 .Fl L ,
 and ignore it in all other cases.
-.It Ic deffs Oo Ar file Oc Ar name Op Ar name Op Ar ...
+.It Ic deffs Ar name Op Ar name Op Ar ...
 Defines a file-system name.
 It is no more than a regular option, as defined by
 .Ic defflag ,
Index: src/usr.bin/config/gram.y
diff -u src/usr.bin/config/gram.y:1.20 src/usr.bin/config/gram.y:1.21
--- src/usr.bin/config/gram.y:1.20	Wed Feb  3 21:00:49 2010
+++ src/usr.bin/config/gram.y	Wed Mar  3 13:53:22 2010
@@ -1,5 +1,5 @@
 %{
-/*	$NetBSD: gram.y,v 1.20 2010/02/03 21:00:49 pooka Exp $	*/
+/*	$NetBSD: gram.y,v 1.21 2010/03/03 13:53:22 pooka Exp $	*/
 
 /*
  * Copyright (c) 1992, 1993
@@ -147,7 +147,6 @@
 %type		flags_opt
 %type		deffs
 %type		deffses
-%type		fsoptfile_opt
 %type		defopt
 %type		defopts
 %type		optdep
@@ -277,8 +276,7 @@
 	device_major			{ do_devsw = 1; } |
 	prefix |
 	DEVCLASS WORD			{ (void)defattr($2, NULL, NULL, 1); } |
-	DEFFS fsoptfile_opt deffses defoptdeps
-	{ deffilesystem($2, $3, $4); } |
+	DEFFS deffses defoptdeps	{ deffilesystem($2, $3); } |
 	DEFINE WORD interface_opt attrs_opt
 	{ (void)defattr($2, $3, $4, 0); } |
 	DEFOPT optfile_opt defopts defoptdeps
@@ -391,10 +389,6 @@
 locdefaults:
 	'=' '{' values '}'		{ $$ = $3; };
 
-fsoptfile_opt:
-	filename			{ $$ = $1; } |
-	/* empty */			{ $$ = NULL; };
-
 optfile_opt:
 	filename			{ $$ = $1; } |
 	/* empty */			{ $$ = NULL; };

Index: src/usr.bin/config/defs.h
diff -u src/usr.bin/config/defs.h:1.31 src/usr.bin/config/defs.h:1.32
--- src/usr.bin/config/defs.h:1.31	Wed Feb  3 21:00:49 2010
+++ src/usr.bin/config/defs.h	Wed Mar  3 13:53:22 2010
@@ -1,4 +1,4 @@
-/*	$NetBSD: defs.h,v 1.31 2010/02/03 21:00:49 pooka Exp $	*/
+/*	$NetBSD: defs.h,v 1.32 2010/03/03 13:53:22 pooka Exp $	*/
 
 /*
  * Copyright (c) 1992, 1993
@@ -494,7 +494,7 @@
 void	addmkoption(const char *, const char *);
 void	appendmkoption(const char *, const char *);
 void	appendcondmkoption(struct nvlist *, const char *, const char *);
-void	deffilesystem(const char *, struct nvlist *, struct nvlist *);
+void	deffilesystem(struct nvlist *, struct nvlist *);
 void	defoption(const char *, struct nvlist *, struct nvlist *);
 void	defflag(const char *, struct nvlist *, struct nvlist *, int);
 void	defparam(const char *, struct nvlist *, struct nvlist *, int);

Index: src/usr.bin/config/main.c
diff -u src/usr.bin/config/main.c:1.38 src/usr.bin/config/main.c:1.39
--- src/usr.bin/config/main.c:1.38	Sat Feb 13 22:57:03 2010
+++ src/usr.bin/config/main.c	Wed Mar  3 13:53:22 2010
@@ -1,4 +1,4 @@
-/*	$NetBSD: main.c,v 1.38 2010/02/13 22:57:03 pooka Exp $	*/
+/*	$NetBSD: main.c,v 1.39 2010/03/03 13:53:22 pooka Exp $	*/
 
 /*
  * Copyright (c) 1992, 1993
@@ -609,7 +609,7 @@
  * Otherwise, no preprocessor #defines will be generated.
  */
 void
-deffilesystem(const char *fname, struct nvlist *fses, struct nvlist *deps)
+deffilesystem(struct nvlist *fses, struct nvlist *deps)
 {
 	struct nvlist *nv;
 
@@ -632,23 +632,6 @@
 			panic("file system `%s' already in table?!",
 			nv->nv_name);
 
-		if (fname != NULL) {
-			/*
-			 * Only one file system allowed in this case.
-			 */
-			if (nv->nv_next != NULL) {
-cfgerror("only one file system per option "
-"file may be specified");
-return;
-			}
-
-			if (ht_insert(optfiletab, fname, nv)) {
-cfgerror("option file `%s' already exists",
-fname);
-return;
-			}
-		}
-
 		add_dependencies(nv, deps);
 	}
 }



CVS commit: src/usr.bin/config

2010-03-03 Thread Antti Kantee
Module Name:src
Committed By:   pooka
Date:   Wed Mar  3 13:53:22 UTC 2010

Modified Files:
src/usr.bin/config: config.5 defs.h gram.y main.c

Log Message:
Remove fs_foo.h support from deffs now that nothing uses it.


To generate a diff of this commit:
cvs rdiff -u -r1.20 -r1.21 src/usr.bin/config/config.5 \
src/usr.bin/config/gram.y
cvs rdiff -u -r1.31 -r1.32 src/usr.bin/config/defs.h
cvs rdiff -u -r1.38 -r1.39 src/usr.bin/config/main.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



Re: CVS commit: src/usr.bin/config

2010-03-01 Thread Masao Uebayashi
>   if_fxp_pci.kmod -> pci.kmod

This should have been:

if_fxp_pci.kmod -> pciif.kmod

Device modules have dependency on an interface.  But the instances (fxp0)
are attached to parent devices (fxp0 at pci0).  Problem is when you load
if_fxp_pci.kmod without having pci.kmod or something providing pciif.kmod.
Auto-loading dependency won't work...

Masao

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635


Re: CVS commit: src/usr.bin/config

2010-03-01 Thread Masao Uebayashi
> That there should be a way to inject cfdata at run-time (well, along
> with loading a module), yes.

Good.

> That anything should be moved back to drivers' .c file, not really.  The
> information carried by a line like "device pci { dev = -1,
> function = -1 }" is no different to a function prototype in a .h.

Yes, it's an interface.

What I'm thinking of now is to make interfaces (struct cfiattrdata) modules.
For the pci case, the pci interface is only used by pci itself.  In cases
like mii or ata, one interface is provided by multiple devices.  To consistently
deal with these cases, always separate device and interface.  Changing

device pci { ... }

to

define pciif { ... }
device pci: pciif

Interfaces (like pciif) will end up in a single module, like pciif.kmod.

pci.kmod depends on pciif.kmod.  AND pci.kmod provides an interface, pciif.
When pci.kmod is loaded, it in turn loads pciif.kmod, meaning pci.kmod depends
on pciif.kmod.  When a pci device kmod (say, if_fxp_pci.kmod) is loaded &
configured, it will look up pciif and attaches to a pci device, which is a
pci device, not pciif.

pci.kmod -> pciif.kmod
if_fxp_pci.kmod -> pci.kmod

(This means we need some changes to module framework to deal with interface
modules specially.)

Masao


Re: CVS commit: src/usr.bin/config

2010-03-01 Thread Quentin Garnier
On Tue, Mar 02, 2010 at 10:10:15AM +0900, Masao Uebayashi wrote:
> > > I'm considering to move cfdata[] and *_iattrdata to each driver's *.c.  
> > > Maybe
> > 
> > That would be a huge step back.  Do *NOT* do that.
> 
> Oops.  I meant s/cfdata/cfdriver/.
> 
> In the long run, templates are moved into *.c, and true configuration (direct
> config / user config == cfdata) is loaded at run-time.  Does this make sense?

That there should be a way to inject cfdata at run-time (well, along
with loading a module), yes.

That anything should be moved back to drivers' .c file, not really.  The
information carried by a line like "device pci { dev = -1,
function = -1 }" is no different to a function prototype in a .h.

-- 
Quentin Garnier - c...@cubidou.net - c...@netbsd.org
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.


pgpk0pVG6ri3l.pgp
Description: PGP signature


Re: CVS commit: src/usr.bin/config

2010-03-01 Thread Masao Uebayashi
> > I'm considering to move cfdata[] and *_iattrdata to each driver's *.c.  
> > Maybe
> 
> That would be a huge step back.  Do *NOT* do that.

Oops.  I meant s/cfdata/cfdriver/.

In the long run, templates are moved into *.c, and true configuration (direct
config / user config == cfdata) is loaded at run-time.  Does this make sense?

Masao


Re: CVS commit: src/usr.bin/config

2010-03-01 Thread Quentin Garnier
On Mon, Mar 01, 2010 at 05:28:15PM +0900, Masao Uebayashi wrote:
[...]
> I'm considering to move cfdata[] and *_iattrdata to each driver's *.c.  Maybe

That would be a huge step back.  Do *NOT* do that.

-- 
Quentin Garnier - c...@cubidou.net - c...@netbsd.org
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.


pgpcXcHxw1FZu.pgp
Description: PGP signature


Re: CVS commit: src/usr.bin/config

2010-03-01 Thread Antti Kantee
On Mon Mar 01 2010 at 17:28:15 +0900, Masao Uebayashi wrote:
> > Log Message:
> > Introduce experimental support for ioconf-only configuration files.
> > This is done by giving the "ioconf" keyword in the config file.
> > As a result, config produces only ioconf.c and locators.h.  Currently,
> > only "monolithic" configurations with the device path starting from
> > root are supported.  Eventually, the goal is to support a local
> > root in the input file from any point along the device tree using
> > files.* in our kernel tree.  This will make autogenerating the
> > config glue for device modules possible instead of having to write
> > it by hand like is currently required (yes, it sounds simple to
> > implement, but ...).
> > 
> > reviewed by cube.
> > (the next part will demand major discussions with you, so prepare ;)
> 
> What's the next step?
> 
> I'm considering to move cfdata[] and *_iattrdata to each driver's *.c.  Maybe
> split ioconf.c (like ioconf_cfdriver_decl_audio.c) and #include it from *.c
> (audio.c).  In the long run, the "template" part is always statically 
> generated.
> Direct configuration / user configuration parts are read from / at run-time.

My next step is to make the above work without having start from root
(done) and autogenerate the source file list (done apart from some
testing).

Truthfully though, my next step is to have coffee.


Re: CVS commit: src/usr.bin/config

2010-03-01 Thread Masao Uebayashi
> Log Message:
> Introduce experimental support for ioconf-only configuration files.
> This is done by giving the "ioconf" keyword in the config file.
> As a result, config produces only ioconf.c and locators.h.  Currently,
> only "monolithic" configurations with the device path starting from
> root are supported.  Eventually, the goal is to support a local
> root in the input file from any point along the device tree using
> files.* in our kernel tree.  This will make autogenerating the
> config glue for device modules possible instead of having to write
> it by hand like is currently required (yes, it sounds simple to
> implement, but ...).
> 
> reviewed by cube.
> (the next part will demand major discussions with you, so prepare ;)

What's the next step?

I'm considering to move cfdata[] and *_iattrdata to each driver's *.c.  Maybe
split ioconf.c (like ioconf_cfdriver_decl_audio.c) and #include it from *.c
(audio.c).  In the long run, the "template" part is always statically generated.
Direct configuration / user configuration parts are read from / at run-time.

Masao


CVS commit: src/usr.bin/config

2010-02-13 Thread Antti Kantee
Module Name:src
Committed By:   pooka
Date:   Sat Feb 13 22:57:03 UTC 2010

Modified Files:
src/usr.bin/config: main.c

Log Message:
Fix off-by-one (config -x works again) and improve editing artifacts
(actually the whole "config -x must be used alone" change was made
unnecessary along the way.  cest la vie).


To generate a diff of this commit:
cvs rdiff -u -r1.37 -r1.38 src/usr.bin/config/main.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/usr.bin/config

2010-02-03 Thread Antti Kantee
Module Name:src
Committed By:   pooka
Date:   Wed Feb  3 21:32:27 UTC 2010

Modified Files:
src/usr.bin/config: mkioconf.c

Log Message:
... aaand make the emit-order slightly more sensible for ioconf.c to
actually work again.


To generate a diff of this commit:
cvs rdiff -u -r1.15 -r1.16 src/usr.bin/config/mkioconf.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/usr.bin/config

2010-02-03 Thread Antti Kantee
Module Name:src
Committed By:   pooka
Date:   Wed Feb  3 21:00:49 UTC 2010

Modified Files:
src/usr.bin/config: defs.h gram.y main.c mkheaders.c mkioconf.c scan.l

Log Message:
Introduce experimental support for ioconf-only configuration files.
This is done by giving the "ioconf" keyword in the config file.
As a result, config produces only ioconf.c and locators.h.  Currently,
only "monolithic" configurations with the device path starting from
root are supported.  Eventually, the goal is to support a local
root in the input file from any point along the device tree using
files.* in our kernel tree.  This will make autogenerating the
config glue for device modules possible instead of having to write
it by hand like is currently required (yes, it sounds simple to
implement, but ...).

reviewed by cube.
(the next part will demand major discussions with you, so prepare ;)


To generate a diff of this commit:
cvs rdiff -u -r1.30 -r1.31 src/usr.bin/config/defs.h
cvs rdiff -u -r1.19 -r1.20 src/usr.bin/config/gram.y
cvs rdiff -u -r1.36 -r1.37 src/usr.bin/config/main.c
cvs rdiff -u -r1.16 -r1.17 src/usr.bin/config/mkheaders.c
cvs rdiff -u -r1.14 -r1.15 src/usr.bin/config/mkioconf.c
cvs rdiff -u -r1.13 -r1.14 src/usr.bin/config/scan.l

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/usr.bin/config

2010-01-21 Thread Antti Kantee
Module Name:src
Committed By:   pooka
Date:   Thu Jan 21 18:06:38 UTC 2010

Modified Files:
src/usr.bin/config: pack.c

Log Message:
Add static to packdevi() like the local prototype says.


To generate a diff of this commit:
cvs rdiff -u -r1.6 -r1.7 src/usr.bin/config/pack.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.