head	1.34;
access;
symbols
	netbsd-11-0-RELEASE:1.34
	netbsd-11-0-RC7:1.34
	netbsd-11-0-RC6:1.34
	netbsd-11-0-RC5:1.34
	netbsd-11-0-RC4:1.34
	netbsd-11-0-RC3:1.34
	netbsd-11-0-RC2:1.34
	netbsd-11-0-RC1:1.34
	perseant-exfatfs-base-20250801:1.34
	netbsd-11:1.34.0.6
	netbsd-11-base:1.34
	netbsd-10-1-RELEASE:1.34
	perseant-exfatfs-base-20240630:1.34
	perseant-exfatfs:1.34.0.4
	perseant-exfatfs-base:1.34
	netbsd-8-3-RELEASE:1.31
	netbsd-9-4-RELEASE:1.31.18.1
	netbsd-10-0-RELEASE:1.34
	netbsd-10-0-RC6:1.34
	netbsd-10-0-RC5:1.34
	netbsd-10-0-RC4:1.34
	netbsd-10-0-RC3:1.34
	netbsd-10-0-RC2:1.34
	netbsd-10-0-RC1:1.34
	netbsd-10:1.34.0.2
	netbsd-10-base:1.34
	netbsd-9-3-RELEASE:1.31.18.1
	cjep_sun2x-base1:1.32
	cjep_sun2x:1.32.0.4
	cjep_sun2x-base:1.32
	cjep_staticlib_x-base1:1.32
	netbsd-9-2-RELEASE:1.31.18.1
	cjep_staticlib_x:1.32.0.2
	cjep_staticlib_x-base:1.32
	netbsd-9-1-RELEASE:1.31.18.1
	phil-wifi-20200421:1.32
	phil-wifi-20200411:1.32
	is-mlppp:1.31.0.20
	is-mlppp-base:1.31
	phil-wifi-20200406:1.32
	netbsd-8-2-RELEASE:1.31
	netbsd-9-0-RELEASE:1.31
	netbsd-9-0-RC2:1.31
	netbsd-9-0-RC1:1.31
	phil-wifi-20191119:1.31
	netbsd-9:1.31.0.18
	netbsd-9-base:1.31
	phil-wifi-20190609:1.31
	netbsd-8-1-RELEASE:1.31
	netbsd-8-1-RC1:1.31
	pgoyette-compat-merge-20190127:1.31
	pgoyette-compat-20190127:1.31
	pgoyette-compat-20190118:1.31
	pgoyette-compat-1226:1.31
	pgoyette-compat-1126:1.31
	pgoyette-compat-1020:1.31
	pgoyette-compat-0930:1.31
	pgoyette-compat-0906:1.31
	netbsd-7-2-RELEASE:1.14.2.2
	pgoyette-compat-0728:1.31
	netbsd-8-0-RELEASE:1.31
	phil-wifi:1.31.0.16
	phil-wifi-base:1.31
	pgoyette-compat-0625:1.31
	netbsd-8-0-RC2:1.31
	pgoyette-compat-0521:1.31
	pgoyette-compat-0502:1.31
	pgoyette-compat-0422:1.31
	netbsd-8-0-RC1:1.31
	pgoyette-compat-0415:1.31
	pgoyette-compat-0407:1.31
	pgoyette-compat-0330:1.31
	pgoyette-compat-0322:1.31
	pgoyette-compat-0315:1.31
	netbsd-7-1-2-RELEASE:1.14.2.2
	pgoyette-compat:1.31.0.14
	pgoyette-compat-base:1.31
	netbsd-7-1-1-RELEASE:1.14.2.2
	matt-nb8-mediatek:1.31.0.12
	matt-nb8-mediatek-base:1.31
	perseant-stdc-iso10646:1.31.0.10
	perseant-stdc-iso10646-base:1.31
	netbsd-8:1.31.0.8
	netbsd-8-base:1.31
	prg-localcount2-base3:1.31
	prg-localcount2-base2:1.31
	prg-localcount2-base1:1.31
	prg-localcount2:1.31.0.6
	prg-localcount2-base:1.31
	pgoyette-localcount-20170426:1.31
	bouyer-socketcan-base1:1.31
	pgoyette-localcount-20170320:1.31
	netbsd-7-1:1.14.2.2.0.6
	netbsd-7-1-RELEASE:1.14.2.2
	netbsd-7-1-RC2:1.14.2.2
	netbsd-7-nhusb-base-20170116:1.14.2.2
	bouyer-socketcan:1.31.0.4
	bouyer-socketcan-base:1.31
	pgoyette-localcount-20170107:1.31
	netbsd-7-1-RC1:1.14.2.2
	pgoyette-localcount-20161104:1.31
	netbsd-7-0-2-RELEASE:1.14.2.2
	localcount-20160914:1.31
	netbsd-7-nhusb:1.14.2.2.0.4
	netbsd-7-nhusb-base:1.14.2.2
	pgoyette-localcount-20160806:1.31
	pgoyette-localcount-20160726:1.31
	pgoyette-localcount:1.31.0.2
	pgoyette-localcount-base:1.31
	netbsd-7-0-1-RELEASE:1.14.2.2
	netbsd-7-0:1.14.2.2.0.2
	netbsd-7-0-RELEASE:1.14.2.2
	netbsd-7-0-RC3:1.14.2.2
	netbsd-7-0-RC2:1.14.2.2
	netbsd-7-0-RC1:1.14.2.2
	netbsd-7:1.14.0.2;
locks; strict;
comment	@# @;


1.34
date	2021.08.02.12.56.25;	author andvar;	state Exp;
branches;
next	1.33;
commitid	yaCLeryH2piJFo3D;

1.33
date	2021.07.24.21.31.39;	author andvar;	state Exp;
branches;
next	1.32;
commitid	VtUn1ZIblDZfMh2D;

1.32
date	2020.03.05.22.44.19;	author wiz;	state Exp;
branches;
next	1.31;
commitid	zvLXw36ZuPi9ugZB;

1.31
date	2015.11.22.01.20.36;	author uebayasi;	state Exp;
branches
	1.31.16.1
	1.31.18.1;
next	1.30;
commitid	H7RfK9bFuR9FG1Ky;

1.30
date	2015.09.11.02.26.22;	author uebayasi;	state Exp;
branches;
next	1.29;
commitid	DBFzl7DzdKhymMAy;

1.29
date	2015.09.08.05.48.07;	author uebayasi;	state Exp;
branches;
next	1.28;
commitid	0dsE5wSCP0QTzpAy;

1.28
date	2015.09.08.02.23.34;	author uebayasi;	state Exp;
branches;
next	1.27;
commitid	uwYDIH6ya0iJroAy;

1.27
date	2015.09.08.00.53.39;	author uebayasi;	state Exp;
branches;
next	1.26;
commitid	JSs8KekFURRSWnAy;

1.26
date	2015.09.03.05.45.16;	author mrg;	state Exp;
branches;
next	1.25;
commitid	8i9GEdZaM5r9ILzy;

1.25
date	2015.08.28.01.01.57;	author uebayasi;	state Exp;
branches;
next	1.24;
commitid	RY6FOkgVFQbElYyy;

1.24
date	2015.08.27.10.22.12;	author uebayasi;	state Exp;
branches;
next	1.23;
commitid	ALvkvysZxYmQtTyy;

1.23
date	2015.08.26.06.38.57;	author uebayasi;	state Exp;
branches;
next	1.22;
commitid	IhF3uFVVmC9fhKyy;

1.22
date	2015.08.25.13.13.54;	author uebayasi;	state Exp;
branches;
next	1.21;
commitid	AkzBIiEZODTIuEyy;

1.21
date	2015.08.25.09.01.28;	author uebayasi;	state Exp;
branches;
next	1.20;
commitid	9XcCDUhfsse86Dyy;

1.20
date	2015.08.23.01.30.21;	author uebayasi;	state Exp;
branches;
next	1.19;
commitid	I4mBLTxlZAomFkyy;

1.19
date	2015.08.22.14.47.05;	author uebayasi;	state Exp;
branches;
next	1.18;
commitid	EkhzKa5LIR6G6hyy;

1.18
date	2015.08.19.03.39.45;	author pgoyette;	state Exp;
branches;
next	1.17;
commitid	jJfjNYBe3yihvPxy;

1.17
date	2015.08.19.03.23.34;	author uebayasi;	state Exp;
branches;
next	1.16;
commitid	XkaWJSLhmmtaqPxy;

1.16
date	2015.04.10.03.51.44;	author uebayasi;	state Exp;
branches;
next	1.15;
commitid	ZqoRcsDe1MYTMZgy;

1.15
date	2015.04.10.03.30.09;	author uebayasi;	state Exp;
branches;
next	1.14;
commitid	RLt2VqUh8BBuFZgy;

1.14
date	2014.11.16.07.12.34;	author uebayasi;	state Exp;
branches
	1.14.2.1;
next	1.13;
commitid	yfoIRKjJQMALynYx;

1.13
date	2014.11.16.04.28.09;	author uebayasi;	state Exp;
branches;
next	1.12;
commitid	1dXEP3lUhYxmEmYx;

1.12
date	2014.11.13.15.25.48;	author uebayasi;	state Exp;
branches;
next	1.11;
commitid	uDGliFvt97IMn2Yx;

1.11
date	2014.11.08.05.57.41;	author uebayasi;	state Exp;
branches;
next	1.10;
commitid	eUKBI2aBY1j1plXx;

1.10
date	2014.11.07.16.41.17;	author uebayasi;	state Exp;
branches;
next	1.9;
commitid	5WaAxtCvk8UNZgXx;

1.9
date	2014.11.01.14.15.31;	author uebayasi;	state Exp;
branches;
next	1.8;
commitid	XTVpAFnVkHtLnuWx;

1.8
date	2014.11.01.08.13.11;	author uebayasi;	state Exp;
branches;
next	1.7;
commitid	j9BzkrCah57snsWx;

1.7
date	2014.10.30.23.18.02;	author wiz;	state Exp;
branches;
next	1.6;
commitid	4POI2ujyPAbRrhWx;

1.6
date	2014.10.30.08.20.15;	author uebayasi;	state Exp;
branches;
next	1.5;
commitid	iw9NZYYs1NIRtcWx;

1.5
date	2014.10.30.01.26.20;	author uebayasi;	state Exp;
branches;
next	1.4;
commitid	hGlHnbWWlt1SbaWx;

1.4
date	2014.10.12.15.54.19;	author apb;	state Exp;
branches;
next	1.3;
commitid	9LK0EuQgoJCezVTx;

1.3
date	2014.10.12.08.04.30;	author wiz;	state Exp;
branches;
next	1.2;
commitid	UAVpdLztrOQkYSTx;

1.2
date	2014.10.12.04.23.46;	author uebayasi;	state Exp;
branches;
next	1.1;
commitid	97tQ8DYNge5CKRTx;

1.1
date	2014.10.10.11.38.42;	author uebayasi;	state Exp;
branches;
next	;
commitid	EWLAk5Yn7wRNdETx;

1.31.16.1
date	2020.04.08.14.09.15;	author martin;	state Exp;
branches;
next	;
commitid	Qli2aW9E74UFuA3C;

1.31.18.1
date	2020.03.09.15.22.21;	author martin;	state Exp;
branches;
next	;
commitid	bKwrK4UggBJkUJZB;

1.14.2.1
date	2014.11.16.07.12.34;	author snj;	state dead;
branches;
next	1.14.2.2;
commitid	sNpCHqjpCWd6AAcy;

1.14.2.2
date	2015.03.06.21.00.23;	author snj;	state Exp;
branches;
next	;
commitid	sNpCHqjpCWd6AAcy;


desc
@@


1.34
log
@fix various typos in comments and log messages.
@
text
@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

  Always provide xxxbusprint() (and xxxbussubmatch if multiple children).
  Extend struct cfiattrdata like:

	struct cfiattrdata {
		const char *ci_name;
		cfprint_t ci_print;
		cfsubmatch_t ci_submatch;
		int ci_loclen;
		const struct cflocdesc ci_locdesc[];
	};

o Simplify child configuration API

  With said struct cfiattrdata extension, config_found*() can omit
  print/submatch args.  If the found child is known (e.g., "pcibus" creating
  "pci"):

	config_found(self, "pcibus");

  If finding unknown children (e.g. "pci" finding pci devices):

	config_find(self, "pci", locs, aux);

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:

	define	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 Always use explicit kernel linker script.

  ld(1) has an option -T <ldscript> to use a given linker script.  If not
  specified, a default, built-in linker script, mainly meant for userland
  programs, is used.

  Currently m68k, sh3, and vax don't have kernel linker scripts.  These work
  because these have no constraints about page boundary; they map and access
  kernel .text/.data in the same way.

o Pass input files to ${LD} via linker script.

  Instead of passing input files on command-line, output "INPUT(xxx.o)"
  commands, and include it from generated linker scripts.

o Directly generate `*.d' files.

  Output source/object files in raw texts instead of `Makefile'.  Generate
  `*.d' (make(1) depend) files.  make(1) knows which object files are to be
  compiled.  With "INPUT(xxx.o)" linker scripts, either generated `Makefile'
  or `Makefile.kern.inc' don't need to keep source/object files in variables.

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

  Generic 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 different
  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 Fix db_symtab copying (COPY_SYMTAB)

  o Collect all objects and create a relocatable (netbsd.ro).  At this point,
    the number of symbols is known.

  o Relink and allocate .rodata.symtab with the calculated size of .symtab.
    Linker recalculates symbol addresses.

  o Embed the .symtab into .rodata.symtab.

  o Link the final netbsd ELF.

  The make(1) rule (dependency graph) should be identical with/without
  COPY_SYMTAB.  Kill .ifdef COPY_SYMTAB from $S/conf/Makefile.kern.inc.

o Preprocess and generate linker scripts dynamically.

  Include opt_xxx.h and replace some constant values (e.g. COHERENCY_UNIT,
  PAGE_SIZE, KERNEL_BASE_PHYS, KERNEL_BASE_VIRT, ...) with cpp(1).

  Don't unnecessarily define symbols.  Don't use sed(1).

o Clean up linker scripts.

  o Don't specify OUTPUT_FORMAT()/OUTPUT_ARCH()

    These are basically set in compilers/linkers.  If non-default ABI is used,
    command-line arguments should be specified.

  o Remove .rel/.rela handlings.

    These are set in relocatable objects, and handled by dynamic linkers.
    Totally irrelevant for kernels.

  o Clean up debug section handlings.

  o Document (section boundary) symbols set in linker scripts.

    There must be a reason why symbols are defined and exported.

    PROVIDE() is to define internal symbols.

  o Clean up load addresses.

  o Program headers.

  o According to matt@@, .ARM.extab/.ARM.exidx sections are no longer needed.

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

o Convert pseudo(dev) attach functions to take (void) (== kernel ctors).

  The pseudo attach function was originally designed to take `int n' as
  the number of instances of the pseudo device.  Now most of pseudo
  devices have been converted to be `cloneable', meaning that their
  instances are dynamically allocated at run-time, because guessing how
  much instances are needed for users at compile time is almost impossible.
  Restricting such a pure software resource at compile time is senseless,
  considering that the rest of the world is dynamic.

  If pseudo attach functions once become (void), config(1) no longer
  has to generate iteration to call those functions, by making them part
  of kernel constructors, that are a list of (void) functions.

  Some pseudo devices may have dependency/ordering problems, because
  pseudo attach functions have no choice when to be called.  This could
  be solved by converting to kctors, where functions are called in order
  by dependency.

o Enhance ioconf behavior for pseudo-devices

  See "bin/48571: config(1) ioconf is insufficient for pseudo-devices" for
  more details.  In a nutshell, it would be "useful" for config to emit
  the necessary stuff in the generated ioconf.[ch] to enable use of
  config_{init,fini}_component() for attaching and detaching pseudodev's.

  Currently, you need to manually construct your own data structures, and
  manually "attach" them, one at a time.  This leads to duplication of
  code (where multiple drivers contain the same basic logic), and doesn't
  necessarily handle all of the "frobbing" of the kernel lists.

o Don't use -Ttext ${TEXTADDR}.

  Although ld(1)'s `-Ttext ${TEXTADDR}' is an easy way to specify the virtual
  base address of .text at link time, it needs to change command-line; in
  kernel build, Makefile needs to change to reflect kernel's configuration.
  It is simpler to reflect kernel configuration using linker script via assym.h.

o Convert ${DIAGNOSTIC} and ${DEBUG} as flags (defflag).

  Probably generate opt_diagnostic.h/opt_debug.h and include them in
  sys/param.h.

o Strictly define DIAGNOSTIC.

  It is possible to make DIAGNOSTIC kernel and modules binary-compatible with
  non-DIAGNOSTIC ones.  In that case, debug type information should match
  theoretically (not confirmed).

o Use suffix rules.

  Build objects following suffix rules.  Source files are defined as relative to
  $S (e.g. sys/kern/init_main.c) and objects are generated in the corresponding
  subdirectories under kernel build directories (e.g.
  .../compile/GENERIC/sys/kern/init_main.o).  Dig subdirectories from within
  config(1).

  Debugging (-g) and profiling (-pg) objects could be generated with *.go/*.po
  suffixes as userland libraries do.  Maybe something similar for
  DIAGNOSTIC/DEBUG.

  genassym(1) definitions will be split into per-source instead of the single
  assym.h.  Dependencies are corrected and some of mysterious dependencies on
  `Makefile' in sys/conf/Makefile.kern.inc can go away.

o Define genassym(1) symbols per file.

  Have each file define symbols that have to be generated by genassym(1) so
  that more accurate dependency is reflected.

  For example, if foo.S needs some symbols, it defines them in foo.assym,
  declaring that foo.S depends on foo.assym.h, and includes foo.assym.h.
  foo.assym.h is generated by following the suffix rule of .assym -> .assym.h.
  When one header is updated, only related *.assym.h files are regenerated,
  instead of rebuilding all MD/*.S files that depend on the global, single
  assym.h.

o Support library.

  Provide a consistent way to build library either as .o or .a.

  Build libraries in sub-make.  Don't include library makefiles.  Don't
  pollute search path (.PATH).  libkern does too much.

o Accept `.a' suffix.

  Make "file" command accept `.a' suffix.  Handle it the same way as `.o'.

o Clean up ${MD_OBJS} and friends in Makefile.${MACHINE}.

  Don't use ${MD_OBJS}, ${MD_LIBS}, ${MD_SFILES}, and ${MD_CFILES}.

  List files in config(5)'s "file".  Override build rules only when necessary.

  Rely on the fact that config(1) parses files.${MACHINE} first, outputs
  files in the order it parses files.* (actually include depth), and
  `Makefile.kern.inc' preserve file order to pass to ${LD}.

o Clean up CTF-related rules.

  Don't overwrite compile/link rules conditionally by existence of
  ${CTFCONVERT}/${CTFMERGE}.  Give a separate suffix (*.ctfo) and define its
  rules (.c -> .ctfo).

o Consider using cpp -MD instead of ${MKDEP}.

o Make "make depend" mandatory.

  Automatically execute "make depend".
@


1.33
log
@Fix all remaining typos, mainly in comments but also in few definitions and log messages, reported by me in PR kern/54889.
Also fixed some additional typos in comments, found on review of same files or typos.
@
text
@d277 1
a277 1
  (netbsd.ro) is linked into multiple final kernel image (netbsd) for diferent
@


1.32
log
@genric -> generic
@
text
@d77 1
a77 1
	defne	ehcibus {}
d322 1
a322 1
    Totally irrelefant for kernels.
d395 1
a395 1
  It is simpler to reflect kenel configuration using linker script via assym.h.
d405 1
a405 1
  non-DIAGNOSTIC ones.  In that case, debug type informations should match
d421 1
a421 1
  assym.h.  Dependencies are corrected and some of misterious dependencies on
d451 1
a451 1
  List files in config(5)'s "file".  Override build rules only when neccesary.
@


1.31
log
@A few more.
@
text
@d262 1
a262 1
  Genric MI linkage is for processing MI linkage that can be applied generally.
@


1.31.16.1
log
@Merge changes from current as of 20200406
@
text
@d262 1
a262 1
  Generic MI linkage is for processing MI linkage that can be applied generally.
@


1.31.18.1
log
@Pull up the following, requested by christos in ticket #776:

	usr.bin/config/TODO                             up to 1.32
	usr.bin/config/defs.h                           up to 1.105
	usr.bin/config/files.c                          up to 1.37
	usr.bin/config/gram.y                           up to 1.55
	usr.bin/config/main.c                           up to 1.99
	usr.bin/config/scan.l                           up to 1.30
	usr.bin/config/sem.c                            up to 1.84
	usr.bin/config/util.c                           up to 1.21

config(1): fix issue with incorrect handling of elifdef statements.
@
text
@d262 1
a262 1
  Generic MI linkage is for processing MI linkage that can be applied generally.
@


1.30
log
@Libraries should be built in sub-make.  libkern is polluting .PATH too much.
@
text
@d229 1
a229 1
o Generate `*.d' files.
d462 6
@


1.29
log
@About ${CTFCONVERT}.
@
text
@d440 3
@


1.28
log
@${MD_OBJS} and friends.
@
text
@d453 6
@


1.27
log
@${LD} input files and library (*.a) support.
@
text
@d443 10
@


1.26
log
@remove these items:

 o Disallow unknown options.
 o Kill makeoptions.

because they're overly strict and i use these both regularly
to do stuff that isn't in the base src, and i'm quite sure
i am not the only one.
@
text
@d224 12
d435 8
@


1.25
log
@+ suffix rules
@
text
@a377 12
o Disallow unknown options.

  Don't accept options that are not defined as either defflag or defparam.
  Report them and exit.  Don't set ${IDENT} in the generated Makefile.

o Kill makeoptions.

  It adds a variable defined in the generated `Makefile'.  While it looks
  useful, it is too flexible and easy to abuse.  The `Makefile' should be
  kept as simple as possible and have nothing that affects output contents.
  Consider to kill `makeoptions' totally, replace existing ones with `options'.

@


1.24
log
@+ copy symtab
@
text
@d408 16
@


1.23
log
@One more about linker script, another about genassym.
@
text
@d278 15
@


1.22
log
@I don't like -Ttext .
@
text
@d214 10
d392 12
@


1.21
log
@+ kill makeoptions
@
text
@d365 7
@


1.20
log
@TODOs about kernel options.
@
text
@d358 7
@


1.19
log
@Linker script TODO items.
@
text
@d352 16
@


1.18
log
@Insert comment regarding PR/48571 so it doesn't get lost.

	config(1) ioconf is insufficient for pseudo-devices

config_{init,fini}_component
@
text
@d268 33
@


1.17
log
@+ pseudo(dev) attach
@
text
@d307 12
@


1.16
log
@Typo in previous.
@
text
@d288 19
@


1.15
log
@More about attribute -> bus, and child configuration.
@
text
@d64 1
a64 1
	config_found(self, "xxxbus");
@


1.14
log
@config(1): TODO about namespace (esp. options vs. module)
@
text
@d47 23
@


1.14.2.1
log
@file TODO was added on branch netbsd-7 on 2015-03-06 21:00:23 +0000
@
text
@d1 264
@


1.14.2.2
log
@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.
@
text
@a0 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.)
@


1.13
log
@config(1): TODO item about swapnetbsd.c
@
text
@d250 15
@


1.12
log
@Revise a plan about link-set.

(I was ignorant 2 weeks ago.)
@
text
@d244 6
@


1.11
log
@config(1): Note a little more about linkage
@
text
@d161 1
a161 1
o Replace linkset.
d163 13
a175 9
  Don't allow kernel subsystems create random ELF sections (with potentially
  long names) in the final kernel.  To collect some data in statically linked
  modules, creating intermediate sections (e.g. .data.linkset.sysctl) and
  exporting the start/end symbols (e.g. _data_linkset_sysctl_{start,end})
  using linker script should be fine.

  Dynamically loaded modules have to register those entries via constructors
  (functions).  This means that dynamically loaded modules are flexible but
  come with overhead.
@


1.10
log
@config(1): TODO about kernel linkage
@
text
@d195 2
a196 1
  reserve the final link for purely MD purpose.
d231 9
a239 2
  XXX Modular MI linkage 
  XXX Modular MD linkage
@


1.9
log
@config(1): More TODO description.
@
text
@d186 46
@


1.8
log
@config(1): One more TODO about retiring direct attachment
@
text
@d14 6
d22 13
@


1.7
log
@Spelling fixes.
@
text
@d28 14
d87 1
a87 1
  cfdata is pattern matching rules to enable devices at runtime device
@


1.6
log
@config(1): More TODO
@
text
@d94 2
a95 2
  Every module should be classfied as at least one class, as modular(9)
  modules already do.  For example, filesystems are marked as "vfs", network
d126 1
a126 1
  replaced by an array of .kctors invocaions, and #ifdef's there will be gone.
d142 1
a142 1
  Since NetBSD has not established a clear kernek ABI, every single kernel
@


1.5
log
@config(1): More TODO items
@
text
@d112 1
a112 1
o Support kernel constructor/destructor (.ctors/.dtors)
d118 1
a118 1
  The order of .ctors/.dtors is resolved by dependency.  The difference from
d123 5
d139 14
@


1.4
log
@Allow easier adding/removing of options without regard to
whether or not they were already defined.
@
text
@d1 11
d92 42
@


1.3
log
@Spelling.
@
text
@d65 16
@


1.2
log
@More TODOs.
@
text
@d37 1
a37 1
o Differenciate "options" and "flags"/"params".
d39 1
a39 1
  "options" enables featurs by adding *.c files (via attributes).
d42 1
a42 1
  *.c files to the result kernek, or don't build attributes (modules).
d63 1
a63 1
  auto-configuration.  It is pure data and can (should) be generated separatedly
@


1.1
log
@Put TODO ideas (to keep your fun).
@
text
@d36 29
@