Source-Changes-HG archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
[src/netbsd-7]: src/usr.bin/config Pull up following revision(s) (requested b...
details: https://anonhg.NetBSD.org/src/rev/91d129b16889
branches: netbsd-7
changeset: 799047:91d129b16889
user: snj <snj%NetBSD.org@localhost>
date: Fri Mar 06 21:00:23 2015 +0000
description:
Pull up following revision(s) (requested by mrg in ticket #572):
usr.bin/config/Makefile: up to 1.10
usr.bin/config/TODO: up to 1.14
usr.bin/config/config.1: up to 1.17
usr.bin/config/config.5: up to 1.25
usr.bin/config/defs.h: up to 1.64
usr.bin/config/files.c: up to 1.18
usr.bin/config/gram.y: up to 1.46
usr.bin/config/hash.c: up to 1.11
usr.bin/config/lint.c: up to 1.15
usr.bin/config/main.c: up to 1.74
usr.bin/config/mkdevsw.c: up to 1.12
usr.bin/config/mkheaders.c: up to 1.26
usr.bin/config/mkioconf.c: up to 1.28
usr.bin/config/mkmakefile.c: up to 1.37
usr.bin/config/mkswap.c: up to 1.8
usr.bin/config/pack.c: up to 1.9
usr.bin/config/scan.l: up to 1.22
usr.bin/config/sem.c: up to 1.71
usr.bin/config/sem.h: up to 1.19
usr.bin/config/util.c: up to 1.19
sync config(1) with HEAD.
diffstat:
usr.bin/config/Makefile | 3 +-
usr.bin/config/TODO | 264 ++++++++++++++++++++++++++++
usr.bin/config/config.1 | 12 +-
usr.bin/config/config.5 | 14 +-
usr.bin/config/defs.h | 67 +++++-
usr.bin/config/files.c | 49 ++++-
usr.bin/config/gram.y | 370 ++++++++++++++++++++++++++++----------
usr.bin/config/hash.c | 114 +++++++++--
usr.bin/config/lint.c | 5 +-
usr.bin/config/main.c | 78 +++++++-
usr.bin/config/mkdevsw.c | 82 ++++---
usr.bin/config/mkheaders.c | 23 +-
usr.bin/config/mkioconf.c | 25 +-
usr.bin/config/mkmakefile.c | 366 ++++++++++++++++++++++++--------------
usr.bin/config/mkswap.c | 9 +-
usr.bin/config/pack.c | 7 +-
usr.bin/config/scan.l | 36 ++-
usr.bin/config/sem.c | 414 ++++++++++++++++++++++++++++++++++++-------
usr.bin/config/sem.h | 15 +-
usr.bin/config/util.c | 24 ++-
20 files changed, 1515 insertions(+), 462 deletions(-)
diffs (truncated from 3630 to 300 lines):
diff -r de26908d88c9 -r 91d129b16889 usr.bin/config/Makefile
--- a/usr.bin/config/Makefile Fri Mar 06 20:54:31 2015 +0000
+++ b/usr.bin/config/Makefile Fri Mar 06 21:00:23 2015 +0000
@@ -1,7 +1,8 @@
-# $NetBSD: Makefile,v 1.8 2007/05/13 20:22:45 veego Exp $
+# $NetBSD: Makefile,v 1.8.54.1 2015/03/06 21:00:23 snj Exp $
# from: @(#)Makefile 8.2 (Berkeley) 4/19/94
.include <bsd.own.mk>
+WARNS=6
PROG= config
SRCS= files.c gram.y hash.c lint.c main.c mkdevsw.c mkheaders.c mkioconf.c \
diff -r de26908d88c9 -r 91d129b16889 usr.bin/config/TODO
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/usr.bin/config/TODO Fri Mar 06 21:00:23 2015 +0000
@@ -0,0 +1,264 @@
+o Call module as module.
+
+ Until now, everything is called as attribute. Separate module from it:
+
+ - Module is a collection of code (*.[cSo]), and provides a function.
+ Module can depend on other modules.
+
+ - Attribute provides metadata for modules. One module can have
+ multiple attributes. Attribute doesn't generate a module (*.o,
+ *.ko).
+
+o Emit everything (ioconf.*, Makefile, ...) per-attribute.
+
+ config(9) related metadata (cfdriver, cfattach, cfdata, ...) should be
+ collected using linker. Create ELF sections like
+ .{rodata,data}.config.{cfdriver,cfattach,cfdata}. Provide reference
+ symbols (e.g. cfdriverinit[]) using linker script. Sort entries by name
+ to lookup entries by binary search in kernel.
+
+o Generate modular(9) related information. Especially module dependency.
+
+ At this moment modular(9) modules hardcode dependency in *.c using the
+ MODULE() macro:
+
+ MODULE(MODULE_CLASS_DRIVER, hdaudio, "pci");
+
+ This information already exists in config(5) definitions (files.*).
+ Extend config(5) to be able to specify module's class.
+
+ Ideally these module metadata are kept somewhere in ELF headers, so that
+ loaders (e.g. boot(8)) can easily read. One idea is to abuse DYNAMIC
+ sections to record dependency, as shared library does. (Feasibility
+ unknown.)
+
+o Rename "interface attribute" to "bus".
+
+ Instead of
+
+ define audiobus {}
+ attach audio at audiobus
+
+ Do like this
+
+ defbus audiobus {}
+ attach audio at audiobus
+
+o Retire "attach foo at bar with foo_bar.c"
+
+ Most of these should be rewritten by defining a common interface attribute
+ "foobus", instead of writing multiple attachments. com(4), ld(4), ehci(4)
+ are typical examples. For ehci(4), EHCI-capable controller drivers implement
+ "ehcibus" interface, like:
+
+ defne ehcibus {}
+ device imxehci: ehcibus
+
+ These drivers' attach functions call config_found() to attach ehci(4) via
+ the "ehcibus" interface attribute, instead of calling ehci_init() directly.
+ Same for com(4) (com_attach_subr()) and ld(4) (ldattach()).
+
+o Sort objects in more reasonable order.
+
+ Put machdep.ko in the lowest address. uvm.ko and kern.ko follow.
+
+ Kill alphabetical sort (${OBJS:O} in sys/conf/Makefile.inc.kern.
+
+ Use ldscript. Do like this
+
+ .text :
+ AT (ADDR(.text) & 0x0fffffff)
+ {
+ *(.text.machdep.locore.entry)
+ *(.text.machdep.locore)
+ *(.text.machdep)
+ *(.text)
+ *(.text.*)
+ :
+
+ Kill linker definitions in sys/conf/Makefile.inc.kern.
+
+o Differentiate "options" and "flags"/"params".
+
+ "options" enables features by adding *.c files (via attributes).
+
+ "flags" and "params" are to change contents of *.c files. These don't add
+ *.c files to the result kernel, or don't build attributes (modules).
+
+o Make flags/params per attributes (modules).
+
+ Basically flags and params are cpp(1) #define's generated in opt_*.h. Make
+ them local to one attributes (modules). Flags/params which affects files
+ across attributes (modules) are possible, but should be discouraged.
+
+o Generate things only by definitions.
+
+ In the ideal dynamically modular world, "selection" will be done not at
+ compile time but at runtime. Users select their wanted modules, by
+ dynamically loading them.
+
+ This means that the system provides all choices; that is, build all modules
+ in the source tree. Necessary information is defined in the "definition"
+ part.
+
+o Split cfdata.
+
+ cfdata is a set of pattern matching rules to enable devices at runtime device
+ auto-configuration. It is pure data and can (should) be generated separately
+ from the code.
+
+o Allow easier adding and removing of options.
+
+ It should be possible to add or remove options, flags, etc.,
+ without regard to whether or not they are already defined.
+ For example, a configuration like this:
+
+ include GENERIC
+ options FOO
+ no options BAR
+
+ should work regardless of whether or not options FOO and/or
+ options BAR were defined in GENERIC. It should not give
+ errors like "options BAR was already defined" or "options FOO
+ was not defined".
+
+o Introduce "class".
+
+ Every module should be classified as at least one class, as modular(9)
+ modules already do. For example, file systems are marked as "vfs", network
+ protocols are "netproto".
+
+ Consider to merge "devclass" into "class".
+
+ For syntax clarity, class names could be used as a keyword to select the
+ class's instance module:
+
+ # Define net80211 module as netproto class
+ class netproto
+ define net80211: netproto
+
+ # Select net80211 to be builtin
+ netproto net80211
+
+ Accordingly device/attach selection syntax should be revisited.
+
+o Support kernel constructor/destructor (.kctors/.kdtors)
+
+ Initialization and finalization should be called via constructors and
+ destructors. Don't hardcode those sequences as sys/kern/init_main.c:main()
+ does.
+
+ The order of .kctors/.kdtors is resolved by dependency. The difference from
+ userland is that in kernel depended ones are located in lower addresses;
+ "machdep" module is the lowest. Thus the lowest entry in .ctors must be
+ executed the first.
+
+ The .kctors/.kdtors entries are executed by kernel's main() function, unlike
+ userland where start code executes .ctors/.dtors before main(). The hardcoded
+ sequence of various subsystem initializations in init_main.c:main() will be
+ replaced by an array of .kctors invocations, and #ifdef's there will be gone.
+
+o Hide link-set in the final kernel.
+
+ Link-set is used to collect references (pointers) at link time. It relys on
+ the ld(1) behavior that it automatically generates `__start_X' and `__stop_X'
+ symbols for the section `X' to reduce coding.
+
+ Don't allow kernel subsystems create random ELF sections.
+
+ Pre-define all the available link-set names and pre-generate a linker script
+ to merge them into .rodata.
+
+ (For modular(9) modules, `link_set_modules' is looked up by kernel loader.
+ Provide only it.)
+
+ Provide a way for 3rd party modules to declare extra link-set.
+
+o Shared kernel objects.
+
+ Since NetBSD has not established a clear kernel ABI, every single kernel
+ has to build all the objects by their own. As a result, similar kernels
+ (e.g. evbarm kernels) repeatedly compile similar objects, that is waste of
+ energy & space.
+
+ Share them if possible. For evb* ports, ideally everything except machdep.ko
+ should be shared.
+
+ While leaving optimizations as options (CPU specific optimizations, inlined
+ bus_space(9) operations, etc.) for users, the official binaries build
+ provided by TNF should be as portable as possible.
+
+o Control ELF sections using linker script.
+
+ Now kernel is linked and built directly from object files (*.o). Each port
+ has an MD linker script, which does everything needed to be done at link
+ time. As a result, they do from MI alignment restriction (read_mostly,
+ cacheline_aligned) to load address specification for external boot loaders.
+
+ Make this into multiple stages to make linkage more structural. Especially,
+ reserve the final link for purely MD purpose. Note that in modular build,
+ *.ko are shared between build of kernel and modular(9) modules (*.kmod).
+
+ Monolithic build:
+ *.o ---> netbsd.ko Generic MI linkage
+ netbsd.ko ---> netbsd.ro Kernel MI linkage
+ netbsd.ro ---> netbsd Kernel MD linkage
+
+ Modular build (kernel):
+ *.o ---> *.ko Generic + Per-module MI linkage
+ *.ko ---> netbsd.ro Kernel MI linkage
+ netbsd.ro ---> netbsd Kernel MD linkage
+
+ Modular build (module):
+ *.o ---> *.ko Generic + Per-module MI linkage
+ *.ko ---> *.ro Modular MI linkage
+ *.ro ---> *.kmod Modular MD linkage
+
+ Genric MI linkage is for processing MI linkage that can be applied generally.
+ Data section alignment (.data.read_mostly and .data.cacheline_aligned) is
+ processed here.
+
+ Per-module MI linkage is for modules that want some ordering. For example,
+ machdep.ko wants to put entry code at the top of .text and .data.
+
+ Kernel MI linkage is for collecting kernel global section data, that is what
+ link-set is used for now. Once they are collected and symbols to the ranges
+ are assigned, those sections are merged into the pre-existing sections
+ (.rodata) because link-set sections in "netbsd" will never be interpreted by
+ external loaders.
+
+ Kernel MD linkage is used purely for MD purposes, that is, how kernels are
+ loaded by external loaders. It might be possible that one kernel relocatable
+ (netbsd.ro) is linked into multiple final kernel image (netbsd) for diferent
+ load addresses.
+
+ Modular MI linkage is to prepare a module to be loadable as modular(9). This
+ may add some extra sections and/or symbols.
+
+ Modular MD linkage is again for pure MD purposes like kernel MD linkage.
+ Adjustment and/or optimization may be done.
+
+ Kernel and modular MI linkages may change behavior depending on existence
+ of debug information. In the future .symtab will be copied using linker
+ during this stage.
+
+o Redesign swapnetbsd.c (root/swap device specification)
+
+ Don't build a whole kernel only to specify root/swap devices.
+
+ Make these parameter re-configurable afterwards.
+
+o Namespace.
+
+ Investigate namespace of attributes/modules/options. Figure out the hidden
+ design about these, document it, then re-design it.
+
+ At this moment, all of them share the single "selecttab", which means their
+ namespaces are common, but they also have respective tables (attrtab,
+ opttab, etc.).
+
+ Selecting an option (addoption()), that is also a module name, works only if
+ the module doesn't depend on anything, because addoption() doesn't select
+ module and its dependencies (selectattr()). In other words, an option is
+ only safely converted to a module (define), only if it doesn't depend on
+ anything. (One example is DDB.)
diff -r de26908d88c9 -r 91d129b16889 usr.bin/config/config.1
--- a/usr.bin/config/config.1 Fri Mar 06 20:54:31 2015 +0000
+++ b/usr.bin/config/config.1 Fri Mar 06 21:00:23 2015 +0000
@@ -1,4 +1,4 @@
-.\" $NetBSD: config.1,v 1.15 2014/05/05 20:52:45 wiz Exp $
+.\" $NetBSD: config.1,v 1.15.2.1 2015/03/06 21:00:23 snj Exp $
.\"
.\" Copyright (c) 1980, 1991, 1993
.\" The Regents of the University of California. All rights reserved.
@@ -29,7 +29,7 @@
.\"
.\" from: @(#)config.8 8.2 (Berkeley) 4/19/94
.\"
-.Dd May 5, 2014
+.Dd October 10, 2014
.Dt CONFIG 1
.Os
.Sh NAME
@@ -37,7 +37,7 @@
Home |
Main Index |
Thread Index |
Old Index