Re: CVS commit: src/distrib/common

[Masao Uebayashi]

With tarballs the latest timestamp of them, with source tree I don't know.
:)

I'm only pointing out an interesting, reasonable idea, not asking you to
implement it right now.

On Wednesday, 25 November 2015, Christos Zoulas <chris...@astron.com> wrote:

> In article <
> cadbf7ee9mruyyct+97v1bjh_0nh9tqltr-rm5bprgl+knb2...@mail.gmail.com
> <javascript:;>>,
> Masao Uebayashi  <uebay...@gmail.com <javascript:;>> wrote:
> >bapt@freebsd taught me that FreeBSD uses ((the newest timestamp in the
> >source files) + 1sec) in places where appropriate for reproducible
> >build.  It might have been about Ports, but idea is it.
>
> That's a nice way to do it. How do they compute that?
>
> christos
>
>

Re: CVS commit: src/distrib/common

[Masao Uebayashi]

bapt@freebsd taught me that FreeBSD uses ((the newest timestamp in the
source files) + 1sec) in places where appropriate for reproducible
build.  It might have been about Ports, but idea is it.

On Wed, Nov 25, 2015 at 9:50 AM, Christos Zoulas  wrote:
> Module Name:src
> Committed By:   christos
> Date:   Wed Nov 25 00:50:57 UTC 2015
>
> Modified Files:
> src/distrib/common: Makefile.bootcd
> src/distrib/common/bootimage: Makefile.bootimage
>
> Log Message:
> PR/50360: Thomas Klausner: if MKREPRO is set, provide a consistent timestamp
> for the files in the cdroms to be built. For now we copy the timestamp of
> . We could set an absolute timestamp too like -T 0 for the epoch.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.32 -r1.33 src/distrib/common/Makefile.bootcd
> cvs rdiff -u -r1.11 -r1.12 src/distrib/common/bootimage/Makefile.bootimage
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>

Re: CVS commit: src/sys/arch/amd64/conf

[Masao Uebayashi]

On Sun, Sep 6, 2015 at 4:17 PM, Masao Uebayashi <uebay...@netbsd.org> wrote:
> Module Name:src
> Committed By:   uebayasi
> Date:   Sun Sep  6 07:17:14 UTC 2015
>
> Modified Files:
> src/sys/arch/amd64/conf: Makefile.amd64 files.amd64
>
> Log Message:
> Define MD start code at the top of files.${MACHINE} relying on config(1)'s
> deterministic file output order.  No need to define ${MD_OBJS} and its 
> useless,
> explicit compile rules.

Although it was true that config(1) preserves file order, I have
mistakenly reordered files in ${OBJS}, that is passed to ${LD}, and
the first file (locore.o) has been mistakenly linked after all *.o
files derived from *.c.  Just fixed now in sys/conf/Makefile.kern.inc
Rev. 1.244.

(Kernel booted because boot loader honored ELF entry address.)

Re: CVS commit: src/share/mk

[Masao Uebayashi]

On Tue, Sep 8, 2015 at 1:33 AM, Joerg Sonnenberger
<jo...@britannica.bec.de> wrote:
> On Mon, Sep 07, 2015 at 06:42:07AM +0000, Masao Uebayashi wrote:
>> Module Name:  src
>> Committed By: uebayasi
>> Date: Mon Sep  7 06:42:07 UTC 2015
>>
>> Modified Files:
>>   src/share/mk: bsd.lib.mk
>>
>> Log Message:
>> Order object build alphabetically.
>
> Given that we are still tsorting things: this change is wrong.

Could you elaborate more?  What I see is that, ${.ALLSRC:O} is
lorder(1)'ed, and then tsort(1)'ed.

Re: CVS commit: src/sys/arch/m68k/fpsp

[Masao Uebayashi]

On Mon, Sep 7, 2015 at 7:01 AM, David Laight <da...@l8s.co.uk> wrote:
> On Sat, Sep 05, 2015 at 09:39:43AM +0900, Masao Uebayashi wrote:
>> The reason of this is that config(1) have no idea of library at this
>> moment.  Makefile.kern.inc has also a convention that all *.o files
>> have to be built under the top of kernel build directory.  libkern &
>> libcompat have speicalized make(1) rules, that work but look ugly.
>> I'd consider to extend config(1) to support library...

The first `this' referred to a rule I added to fix build:

fpsp.o: ${FPSP}
ln -sf ${FPSP} fpsp.o

where ${FPSP} is an absolute path to ${.OBJDIR}/lib/fpsp/fpsp.o.

m68k defined ${FPSP} as ${MD_OBJS}, but I changed paths in ${MD_OBJS}
to be normalized to just file names (no /) to simplify explicit rule
generation.  Now that I introduced ${MD_LIBS}, whose paths are not
normalized, that symlink is no longer needed & removed.

(As a bonus, fpsp.o is linked at last, not just after start code.
Like other libraries.)

> Please can you keep some context in your emails.
> The 'this' is the first line is a reference to something unknown.
>
> Oh, and one historic reason for the kernel objects being in a .a
> file was to allow builds on systems with short command line length
> limits.
>
> David
>
> --
> David Laight: da...@l8s.co.uk

Re: CVS commit: src/sys/arch/m68k/fpsp

[Masao Uebayashi]

The reason of this is that config(1) have no idea of library at this
moment.  Makefile.kern.inc has also a convention that all *.o files
have to be built under the top of kernel build directory.  libkern &
libcompat have speicalized make(1) rules, that work but look ugly.
I'd consider to extend config(1) to support library...

Re: CVS commit: src/sys/conf

[Masao Uebayashi]

I got some errors from common/lib/libc/arch/arm/features.mk.  Will
revisit later.

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

[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/sys/conf

[Masao Uebayashi]

On Thu, Sep 3, 2015 at 11:32 PM, Joerg Sonnenberger
<jo...@britannica.bec.de> wrote:
> On Thu, Sep 03, 2015 at 02:56:35PM +0900, Masao Uebayashi wrote:
>> Because ${OBJS} affects not only build order but also link order.
>
> and that's exactly why it *should* be sorted. Please don't introduce
> sources of instability to the build process.

config(1) outputs ${CFILES}/${SFILES} in the order it parses files.*
and sees "file ...".  It is stable.

Re: CVS commit: src

[Masao Uebayashi]

I will bring this back to track once things will settle.

Re: CVS commit: src/sys/conf

[Masao Uebayashi]

My plan is to order objects following module dependency for kernel constructors.

Re: CVS commit: src/sys/conf

[Masao Uebayashi]

Because ${OBJS} affects not only build order but also link order.

Re: CVS commit: src/sys/conf

[Masao Uebayashi]

According to make(1), $< (${.IMPSRC}) is not set in explicit rules.
If so, existing logic of using explicit rules around ${NORMAL_C} can
be said to be just wrong.

Re: CVS commit: src/sys/conf

[Masao Uebayashi]

Fallouts should not happen.

Re: CVS commit: src/sys

[Masao Uebayashi]

sys/netinet/in.c calls a function in sys/net/if_llatbl.c
sys/net/if_llatbl.c calls a function in sys/net/if_arp.c

This doesn't look very good from modularity POV.  Maybe if_llatbl.c
should not directly refer to if_arp.c functions.

Re: CVS commit: src/sys

[Masao Uebayashi]

Off course you can do "file if_llatbl.c a|b|c" and leave the burden of
fixing modularity for future people. :)

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

[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

[Masao Uebayashi]

And there is $S/../common.  Need more thought..

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

[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/sys/conf

[Masao Uebayashi]

Sorry, my bad. :(

There seems an evaluation order problem around ${SYSTEM_DEP} ... it is
added to `netbsd' as a dependency much earlier than
`sys/conf/Makefile.kern.inc' is included.  I'll simply redo by adding
netbsd: netbsd.ldscript in `sys/conf/Makefile.kern.inc' instead of
relying on ${SYSTEM_DEP}.

On Tue, Aug 25, 2015 at 3:02 AM, Christos Zoulas chris...@netbsd.org wrote:
 Module Name:src
 Committed By:   christos
 Date:   Mon Aug 24 18:02:55 UTC 2015

 Modified Files:
 src/sys/conf: Makefile.kern.inc

 Log Message:
 Fix the build: provide compatibility with ports that define KERNLDSCRIPT to
 a file?


 To generate a diff of this commit:
 cvs rdiff -u -r1.188 -r1.189 src/sys/conf/Makefile.kern.inc

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

Re: CVS commit: src/sys/arch/evbarm/conf

[Masao Uebayashi]

Although I confirmed that all kernels of evbearmv7hf-el had no binary
changes after this change, I am a bit confused by [1].  According to
[1], at that time, this linker script was used by hpcboot (of
hpcarm?).  Now I see that hpcarm doesn't seem to use linker script at
all.

Anyway, load addresses, set in the ELF program header, are for
external boot loaders.  Which means that linker script should be used
depending on a boot loader used for a built kernel.  There is also a
need for linker scripts to be shared as much as possible.  Thus
separating the SECTIONS command to program load addresses should have
some sense.

[1] 
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/evbarm/conf/ldscript.evbarm?rev=1.5content-type=text/x-cvsweb-markup

Re: CVS commit: src/sys/arch/netwinder/conf

[Masao Uebayashi]

netwinder is strange in that it wants .data aligned to 0x8000, but it
also specifies physical/virtual load addresses as
0xc000/0xf000c000, that are obviously not aligned to 0x8000!  Can
someone check if other load addresses work?  For example
0x0001/0xf001?

Re: CVS commit: src/sys/kern

[Masao Uebayashi]

Can compilers warn that `variables that should not be used are
mistakenly used'?  If not, marking with `__unused' does not prove that
those variables are really unused.

Re: CVS commit: src/sys/kern

[Masao Uebayashi]

Of course I can revert changes but I'd point out that pseudo attach
functions were already inconsistent, and I want to fix that
inconsistency.

Could you list a number of other instances that use `int n'?

On Wed, Aug 19, 2015 at 11:34 AM, matthew green m...@eterna.com.au wrote:
 Masao Uebayashi writes:
 On Wed, Aug 19, 2015 at 10:27 AM, Paul Goyette p...@vps1.whooppee.com 
 wrote:
 (snip)
  Wasn't the 'n' parameter supposed to be used to tell the driver how many
  instances of the pseudo-device should be instantiated?  At least, for those
  drivers which do not automatically clone?

 Yes.

  Have all of the pseudo-devices been modified to clone?

 As I said in another mail, not yet.

 it looks like raidframe was updated.

 either way, please revert your change.  what you have now is
 inconsistent and we have two prototypes for the same function
 in different headers that conflict.

 that's just confusing.  until everything is converted (and
 this is a good thing), the current system should remain.


 .mrg.

Re: CVS commit: src/sys/kern

[Masao Uebayashi]

On Wed, Aug 19, 2015 at 10:27 AM, Paul Goyette p...@vps1.whooppee.com wrote:
(snip)
 Wasn't the 'n' parameter supposed to be used to tell the driver how many
 instances of the pseudo-device should be instantiated?  At least, for those
 drivers which do not automatically clone?

Yes.

 Have all of the pseudo-devices been modified to clone?

As I said in another mail, not yet.

Re: CVS commit: src/sys/kern

[Masao Uebayashi]

On Wed, Aug 19, 2015 at 5:31 AM, matthew green m...@eterna.com.au wrote:
 Masao Uebayashi writes:
 Module Name:  src
 Committed By: uebayasi
 Date: Tue Aug 18 13:46:20 UTC 2015

 Modified Files:
   src/sys/kern: kern_cpu.c kern_drvctl.c

 Log Message:
 Convert pseudo attach functions to take no arguments, as some functions
 (pppattach(), putterattach(), etc.) already do.  This means that pseudo
 attach function will be able to become a constructor.

 how does this work?

 these functions are called by ioconf.c that generated by config(1),
 so i'm not sure how this can not be a build break, or at least a
 confusing and inconsistent.

 ioconf.c:void drvctlattach(int);
 ioconf.c:const struct pdevinit pdevinit[] = {
 ...
 ioconf.c:   { drvctlattach, 1 },

 subr_autoconf.c: for (pdev = pdevinit; pdev-pdev_attach != NULL; pdev++)
 subr_autoconf.c: (*pdev-pdev_attach)(pdev-pdev_count);

 what's the plan here?  this reduction won't work for a number of
 basic pdevs (like raid(4)) without updating it to not use the
 count argument.

o I admit I did not check all, but 95% of pseudo attach functions do
not use `int n'.

o I assume that passing an `int' that is ignored by the callee
(func(void)) has proven to be harmless on all CPUs, because it has
worked.

o Killing `int n' is good for reducing kernel build complexity, and
reducing combinations of kernel configs.

o I am (too) optimistic that those pseudo attach functions that use
`int n' can be converted rather easily.

o For the first step, make it clear which functions use `int n' and not.

o If you are really unhappy of the `(void)', I can use `int n __unused'.

Re: CVS commit: src/sys/kern

[Masao Uebayashi]

raidattach() doesn't seem to use `int num':

http://nxr.netbsd.org/xref/src/sys/dev/raidframe/rf_netbsdkintf.c#395

Re: CVS commit: src/sys

[Masao Uebayashi]

Which ELF section are splash images located?

Are splash images written while running?

Re: CVS commit: src/sys/arch

[Masao Uebayashi]

On Wed, Apr 29, 2015 at 5:32 PM, Hikaru Abe hik...@netbsd.org wrote:
 Log Message:
 Initial import of Cavium Octeon and Octeon Plus SoC and
 specifically Ubiquiti Networks EdgeRouter LITE support.
 Currently the ethernet and uart of are worked.
 This support was contributed by Internet Initiative Japan Inc.

USB is working with dwc2 code base on OpenBSD.  FYI.

Re: CVS commit: src/share/misc

[Masao Uebayashi]

Are you removing any inappropriate/hostile words in the tree (if exists)?

Re: CVS commit: src

[Masao Uebayashi]

On Mon, Apr 6, 2015 at 7:02 PM, Martin Husemann mar...@duskware.de wrote:
 On Sun, Apr 05, 2015 at 09:40:22AM -0400, Christos Zoulas wrote:
 Hmm, it is building things twice... I am trying to figure out why but I can't
 reproduce it.

Not surprising at all if multiple output hack (*.y) is involved.

 Not sure, but it basically fails for me on all build machines if using low
 values for -j. I can get past it by doing a cleandir and dependall without
 -j.

 Also below is a log of a non-cleandir'd build failing, but that looks mostly
 the same now.

If I were you, I'd look at make -dm output.

(Remember that make(1) has no idea that foo.c and ./foo.c are
identical; they are just strings for make(1).)

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

[Masao Uebayashi]

Looking.  At least, on amd64, the failing tests don't touch config
at all, according to ktrace(1)...

Re: CVS commit: [nick-nhusb] src/sys/dev/usb

[Masao Uebayashi]

On Sun, Nov 30, 2014 at 10:46 PM, Nick Hudson sk...@netbsd.org wrote:
 Module Name:src
 Committed By:   skrll
 Date:   Sun Nov 30 13:46:00 UTC 2014

 Modified Files:
 src/sys/dev/usb [nick-nhusb]: ehci.c ehcireg.h ehcivar.h

 Log Message:
 Add full speed isoc support to ehci(4). Based on the patch posted in

 https://mail-index.netbsd.org/port-arm/2013/04/14/msg001842.html

 From Masao Uebayashi via Sebastien Bocahu

The work was actually done by Tsubai Masanari, and also heavily based
on FreeBSD's USB stack at that time.

Re: CVS commit: src/sys/net

[Masao Uebayashi]

I predict that in the near future the network stack will act like a
batch manner; instead of moving layers for a single packet, pass a
batch of packets to the next layer; each layer processes a batch of
packets in a loop and stay longer (than now) holding a relevant
context object cached.  In such a model the relative cost of
indirection will become nothing.

Re: CVS commit: src/sys/net

[Masao Uebayashi]

Maybe adding a few spare members, like 5 pointers, to reduce # of bumps ... ?

Re: CVS commit: src/sys/net

[Masao Uebayashi]

On Thu, Nov 27, 2014 at 10:51 AM, Masao Uebayashi uebay...@gmail.com wrote:
 Maybe adding a few spare members, like 5 pointers, to reduce # of bumps ... ?

Or completely hide sizeof(struct ifnet) by forcing use of if_alloc(),
as struct device did.

Re: CVS commit: src/sys/net

[Masao Uebayashi]

On Thu, Nov 27, 2014 at 11:39 AM, matthew green m...@eterna.com.au wrote:
 hiding stuff inside an alloc doesn't really help much when the
 kernel code needs to access the structure anyway, unless you
 also hide all accesses to the structure inside functions.

Right.  And some members, including this if_slowtimo_ch, are internal
to if.c, which don't affect ABI except struct size.

Re: CVS commit: src/sys/net

[Masao Uebayashi]

On Thu, Nov 27, 2014 at 4:20 PM, Matt Thomas m...@3am-software.com wrote:
 Or completely hide sizeof(struct ifnet) by forcing use of if_alloc(),
 as struct device did.

 Doesn't work since struct ifnet is embedded in ethercom/fddicom

Right.  I mean, I want to make them alloc'ed to improve modlarity in
the long run.

CONFIGOPTS

[Masao Uebayashi]

- Add new CONFIGOPTS make variable
  - Use CONFIGOPTS where TOOL_CONFIG is used
- Put CONFIGOPTS args first so that other args win
- Revert mkernel/mkernels

Index: build.sh
===
RCS file: /cvsroot/src/build.sh,v
retrieving revision 1.304
diff -p -u -r1.304 build.sh
--- build.sh16 Nov 2014 06:08:13 -  1.304
+++ build.sh25 Nov 2014 08:18:00 -
@@ -1029,8 +1029,6 @@ Usage: ${progname} [-EhnorUuxy] [-a arch
 file \`conf'
 releasekernel=conf  Install kernel built by kernel=conf to RELEASEDIR.
 kernels Build all kernels
-mkernelsBuild all kernels in modular build
-mkernel=confBuild kernel with config file \`conf' in modular build
 installmodules=idir Run make installmodules to \`idir' to install all
 kernel modules.
 modules Build kernel modules.
@@ -1321,7 +1319,7 @@ parseoptions()
exit $?
;;
 
-   kernel=*|releasekernel=*|kernel.gdb=*|mkernel=*)
+   kernel=*|releasekernel=*|kernel.gdb=*)
arg=${op#*=}
op=${op%%=*}
[ -n ${arg} ] ||
@@ -1350,7 +1348,6 @@ parseoptions()
iso-image-source|\
iso-image|\
kernels|\
-   mkernels|\
live-image|\
makewrapper|\
modules|\
@@ -1987,8 +1984,10 @@ buildkernel()
fi
[ -x ${TOOLDIR}/bin/${toolprefix}config ] \
|| bomb ${TOOLDIR}/bin/${toolprefix}config does not exist. You need to 
\$0 tools\ first.
-   ${runcmd} ${TOOLDIR}/bin/${toolprefix}config -b ${kernelbuildpath} \
-   ${configopts} -s ${TOP}/sys ${kernelconfpath} ||
+   CONFIGOPTS=$(getmakevar CONFIGOPTS)
+   ${runcmd} ${TOOLDIR}/bin/${toolprefix}config ${CONFIGOPTS} \
+   -b ${kernelbuildpath} -s ${TOP}/sys ${configopts} \
+   ${kernelconfpath} ||
bomb ${toolprefix}config failed for ${kernelconf}
make_in_dir ${kernelbuildpath} depend
make_in_dir ${kernelbuildpath} all
@@ -2250,11 +2249,6 @@ main()
configopts=-D DEBUG=-g
buildkernel ${arg}
;;
-   mkernel=*)
-   arg=${op#*=}
-   configopts=-M
-   buildkernel ${arg}
-   ;;
releasekernel=*)
arg=${op#*=}
releasekernel ${arg}
@@ -2264,11 +2258,6 @@ main()
buildkernels
;;
 
-   mkernels)
-   configopts=-M
-   buildkernels
-   ;;
-
disk-image=*)
arg=${op#*=}
diskimage ${arg}
Index: doc/BUILDING.mdoc
===
RCS file: /cvsroot/src/doc/BUILDING.mdoc,v
retrieving revision 1.109
diff -p -u -r1.109 BUILDING.mdoc
--- doc/BUILDING.mdoc   16 Nov 2014 06:10:31 -  1.109
+++ doc/BUILDING.mdoc   25 Nov 2014 08:18:05 -
@@ -1526,12 +1526,6 @@ file alongside of the kernel
 which contains a full symbol table and can be used for debugging
 (for example with a cross-gdb built by
 .Sy MKCROSSGDB ) .
-.It Sy mkernel Ns = Ns Ar kconf
-Build a new kernel in modular build.
-Similar to the above
-.Sy kernel Ns = Ns Ar kconf
-operation, but creates intermediate per-module relocatable objects and link
-them to the final kernel.
 .It Sy kernels
 This command will build all kernels defined in port specific release build
 procedure.
@@ -1539,10 +1533,6 @@ procedure.
 This command internally calls the
 .Sy kernel Ns = Ns Ar kconf
 operation for each found kernel configuration file.
-.It Sy mkernels
-Similar to the above
-.Sy kernels
-operation, but builds kernels in modular build.
 .It Sy modules
 This command will build kernel modules and install them into
 .Sy DESTDIR .
Index: etc/Makefile
===
RCS file: /cvsroot/src/etc/Makefile,v
retrieving revision 1.421
diff -p -u -r1.421 Makefile
--- etc/Makefile10 Aug 2014 05:56:36 -  1.421
+++ etc/Makefile25 Nov 2014 08:18:05 -
@@ -578,7 +578,7 @@ build_kernels: .PHONY
 .for configfile in ${ALL_KERNELS}  # {
 build_kernels: kern-${configfile}
 kern-${configfile}: .PHONY .MAKE
-   cd ${KERNCONFDIR}  ${TOOL_CONFIG} -s ${KERNSRCDIR} \
+   cd ${KERNCONFDIR}  ${TOOL_CONFIG} ${CONFIGOPTS} -s ${KERNSRCDIR} \
-U DEBUG -b ${KERNOBJDIR}/${configfile:C/.*\///} ${configfile}
 .if ${MKUPDATE} == no
cd ${KERNOBJDIR}/${configfile:C/.*\///}  ${MAKE} distclean
Index: share/mk/bsd.README

Re: CVS commit: src

[Masao Uebayashi]

On Mon, Nov 17, 2014 at 5:00 PM, Martin Husemann
mar...@homeworld.netbsd.org wrote:
 On Sun, Nov 16, 2014 at 06:08:13AM +, Masao Uebayashi wrote:
 Module Name:  src
 Committed By: uebayasi
 Date: Sun Nov 16 06:08:13 UTC 2014

 Modified Files:
   src: build.sh

 Log Message:
 build.sh mkernels: Build all kernels in modular build

 Sorry to be slow here, but:
 this modular obviously differs from modular kernels (as in: have options
 MODULAR) - so I guess the name is not a good one. I actually have no clue
 what it is supposed to mean.

There is nothing wrong to link modules statically.  Do you have any
suggestion of how to call the process of building those modules?

Re: CVS commit: src

[Masao Uebayashi]

If there is an interface to set arguments to config(1), both mkernel
and mkernels can be reverted.  And kernel.gdb can be also
reverted, I think.

On Mon, Nov 17, 2014 at 5:37 PM, Alan Barrett a...@cequrux.com wrote:
 On Mon, 17 Nov 2014, Martin Husemann wrote:

 On Sun, Nov 16, 2014 at 06:08:13AM +, Masao Uebayashi wrote:

 Modified Files:
 src: build.sh

 Log Message:
 build.sh mkernels: Build all kernels in modular build


 Sorry to be slow here, but:
 this modular obviously differs from modular kernels (as in: have
 options
 MODULAR) - so I guess the name is not a good one. I actually have no clue
 what it is supposed to mean.


 Also, why does it need a new build.sh action?  Why can't the choice of how
 to build kernels be triggered by a variable in a Makefile or in the
 environment or in the kernel configuration?

 Was this discussed anywhere?

 --apb (Alan Barrett)

Re: CVS commit: src

[Masao Uebayashi]

How about adding a new make variable CONFIGOPTS, which is passed to config(1)?

This name is similar to COPTS and works similarly too.

Re: CVS commit: src/sys/conf

[Masao Uebayashi]

On Wed, Nov 12, 2014 at 11:04 PM, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote:
 christos@ wrote:

 I grepped -R and used nxr but found nothing.

 Hmm.
 http://nxr.netbsd.org/search?q=mkldscript.shproject=src
 shows all files..

 I wonder if you need a different script (or proper wrapper)
 for modules..

 Well, it did not have a valid syntax also when I tried it for some
 reason (ld complained). It needed:

   link_set_foo : { *(link_set_foo) }

 instead of:

   *(link_set_foo)

 The initial commit message says:
 http://mail-index.netbsd.org/source-changes/2004/09/13/msg152610.html
 ---
 Modified Files:
 src/sys/arch/cats/conf: Makefile.cats.inc
 src/sys/arch/shark/conf: Makefile.shark.inc
 src/sys/conf: Makefile.kern.inc
 Added Files:
 src/sys/arch/arm/conf: kern.ldscript.head kern.ldscript.tail
 mkldscript.sh

 Log Message:
 work around a binutils bug where converting ELF kernels to a.out with objcopy
 produces corrupted binaries when the link_set_* sections extend into another
 page after the end of the .text section by using a generated an ldscript that
 puts all the link_set_* data into the .text section in the first place.
 ---

 You can see how they can be valid in the Makefiles and
 kern.ldscript.{head,tail} files.

 Anyway, it looks required for a.out only but no one will fix
 a.out features..

IIUC the requirement for mkldscript.sh users is to merge link_set_*
sections.  I'll merge link_set_* into .rodata on all ports.  Then this
hack can go away.

(I also found that arm constructor section (.init_array) can't be
converted to a.out too.)

Re: CVS commit: src/sys/conf

[Masao Uebayashi]

On Thu, Nov 13, 2014 at 10:21 PM, Christos Zoulas chris...@zoulas.com wrote:
 On Nov 13, 10:15pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
 -- Subject: Re: CVS commit: src/sys/conf

 | I'm not sure about your goal, but anyway it should be proposed
 | and discussed proper lists before commit.

I have almost no questions, nothing to discuess except details.

 | In the perfect world, both cats and shark should have native bootloaders
 | that can load native ELF directly and the a.out hack seems a special case.

 The script is also used to produce the __{start,stop}_link_set.* symbols
 for modules now...

I know.

And as I said repeatedly, it moves link_set_* sections at wrong places...

Re: CVS commit: src/sys/conf

[Masao Uebayashi]

On Thu, Nov 13, 2014 at 10:43 PM, Christos Zoulas chris...@zoulas.com wrote:
 On Nov 13, 10:28pm, uebay...@gmail.com (Masao Uebayashi) wrote:
 -- Subject: Re: CVS commit: src/sys/conf

 | On Thu, Nov 13, 2014 at 10:21 PM, Christos Zoulas chris...@zoulas.com 
 wrote:
 |  On Nov 13, 10:15pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
 |  -- Subject: Re: CVS commit: src/sys/conf
 | 
 |  | I'm not sure about your goal, but anyway it should be proposed
 |  | and discussed proper lists before commit.
 |
 | I have almost no questions, nothing to discuess except details.
 |
 |  | In the perfect world, both cats and shark should have native bootloaders
 |  | that can load native ELF directly and the a.out hack seems a special 
 case.
 | 
 |  The script is also used to produce the __{start,stop}_link_set.* symbols
 |  for modules now...
 |
 | I know.
 |
 | And as I said repeatedly, it moves link_set_* sections at wrong places...

 It does not matter currently. It is really simple to move them anywhere
 when it makes a difference.

It does not matter for you, it matters for me.

Re: CVS commit: src/sys/conf

[Masao Uebayashi]

On Thu, Nov 13, 2014 at 11:54 PM, Christos Zoulas chris...@zoulas.com wrote:
 Any solution that involves hard-coding the currently used linksets by
 name is no solution for me. Please come up with a complete solution,
 and present it for discussion. Yes, the current script is a hack, but
 it is a hack we've been using for a while successfully.

I would not call it hard-coding; link-sets are well-known.  All the
used link-sets are known before building.

I'd detect unknown link-set sections and make that build fail.  This
is more strict.

I'd also provide a way to declare extra link-set for 3rd party modules.

Re: CVS commit: src/sys/conf

[Masao Uebayashi]

On Fri, Nov 14, 2014 at 12:43 AM, Christos Zoulas chris...@astron.com wrote:
 In article m42jep$fu6$1...@ger.gmane.org,
 Christos Zoulas chris...@astron.com wrote:
In article 
CADbF7edbi1NG5O2LZqoh42zoAMvdEYoMF3bLyr=Pynu0PZx9=q...@mail.gmail.com,

Can you please explain what you are trying to do and what are your goals?
I am not sure if I agree that the list of link_sets is well known. If
you ask anyone to enumerate them they will probably resort to nm the
kernel...

 Ok, I see the plan in config now, but I'd still prefer that the link
 sets were discovered rather than hard-coded like it has been so far.
 What do others think?

I can't answer everything soon but one reason coming to mind:

I want to hide all link_set_* sections except link_set_modules in
*.kmod.  AFAIK linker script doesn't have a syntax to do ``merge
everything except this pattern''.  Thus I need to know all link-set
sections explicitly.

Re: CVS commit: src/sys/conf

[Masao Uebayashi]

On Fri, Nov 14, 2014 at 1:14 AM, Christos Zoulas chris...@astron.com wrote:
 In article 
 CADbF7edH-=2+az5vahupedqcmm7yt0jxmoc0ahdnfjnfu7a...@mail.gmail.com,
 Masao Uebayashi  uebay...@gmail.com wrote:

I can't answer everything soon but one reason coming to mind:

I want to hide all link_set_* sections except link_set_modules in
*.kmod.  AFAIK linker script doesn't have a syntax to do ``merge
everything except this pattern''.  Thus I need to know all link-set
sections explicitly.

 Ok, but can't you generate a script dynamically that handles that?

I think it is possible.

Re: CVS commit: src/sys/conf

[Masao Uebayashi]

I will look and try to write a separate mkldscript for kmod (but not today).

On Wednesday, November 12, 2014, Izumi Tsutsui tsut...@ceres.dti.ne.jp
wrote:

 christos@ wrote:

  Module Name:  src
  Committed By: christos
  Date: Wed Nov 12 02:15:58 UTC 2014
 
  Modified Files:
src/sys/conf: mkldscript.sh
 
  Log Message:
  I don't know what was using this before

 Christos, could you please try at least cvs log or grep -R
 before writing such commit log?

 http://mail-index.netbsd.org/source-changes/2007/03/04/0006.html
 ---
 Module Name:src
 Committed By:   tsutsui
 Date:   Sun Mar  4 02:35:50 UTC 2007

 Modified Files:
 src/sys/arch/cats/conf: Makefile.cats.inc
 src/sys/arch/shark/conf: Makefile.shark.inc
 Added Files:
 src/sys/conf: mkldscript.sh
 Removed Files:
 src/sys/arch/arm/conf: mkldscript.sh

 Log Message:
 Move mkldscript.sh, which is used to create ldscript dynamically to
 merge link_set_* sections into the text section for a.out kernels,
 from sys/arch/arm/conf/ to sys/conf/ since there is no ARM specific
 stuff in it and other ports would share it.
 ---

 % grep -R mkldscript.sh src/sys
 sys/arch/cats/conf/Makefile.cats.inc: OBJDUMP=${OBJDUMP} ${HOST_SH}
 $S/conf/mkldscript.sh \
 sys/arch/luna68k/conf/Makefile.luna68k:   OBJDUMP=${OBJDUMP} ${HOST_SH}
 $S/conf/mkldscript.sh \
 sys/arch/shark/conf/Makefile.shark.inc:   OBJDUMP=${OBJDUMP} ${HOST_SH}
 $S/conf/mkldscript.sh \
 %

 ---

  (but it did not work since it
  did not produce valid LDSCRIPT code) and now it does.

 It have worked more than ten years for these traditional arm ports
 (luna68k no longer needs it since it got a native bootloader though).

 I wonder if you need a different script (or proper wrapper)
 for modules..

 ---
 Izumi Tsutsui

Re: CVS commit: src/share/mk

[Masao Uebayashi]

It'd be better to always generate kldscript and kill *.mk contionals completely.

Re: CVS commit: src/sys/conf

[Masao Uebayashi]

Now .kmod has

.text
.data
link_set_*
.rodata
:

instead of

.text
.rodata
link_set_*
.data
:

This may work, because modular(9) maps everything as RWX
(uvm_km_alloc(UVM_KMF_WIRED | UVM_KMF_EXEC)).  But still...

Re: CVS commit: src/sys/conf

[Masao Uebayashi]

You need sizeof(ptr) alignment, not 4.

On Wednesday, November 12, 2014, Christos Zoulas chris...@netbsd.org
wrote:

 Module Name:src
 Committed By:   christos
 Date:   Wed Nov 12 02:15:58 UTC 2014

 Modified Files:
 src/sys/conf: mkldscript.sh

 Log Message:
 I don't know what was using this before (but it did not work since it
 did not produce valid LDSCRIPT code) and now it does.


 To generate a diff of this commit:
 cvs rdiff -u -r1.1 -r1.2 src/sys/conf/mkldscript.sh

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

Re: CVS commit: src/sys/dev

[Masao Uebayashi]

For future reference:

I think any xxxbus interface attribute (aka bus) should provide
xxxbusprint (and xxxbussubmatch if multiple children).  I'll probably
change config(1) to extend cfiattrdata like:

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

Then config_found*() can omit print/submatch args.

If the found child is known (e.g., pcibus creating pci):

config_found(self, xxxbus);

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

config_find(self, pci, locs, aux);

Re: CVS commit: src/sys/dev

[Masao Uebayashi]

On Thu, Nov 6, 2014 at 1:54 AM, Masao Uebayashi uebay...@gmail.com wrote:
 struct cfiattrdata {
 const char *ci_name;
 cfprint_t ci_print;
 cfsubmatch_t ci_submatch;
 int ci_loclen;
 const struct cflocdesc ci_locdesc[];
 };

Actually, ci_name, ci_print, ci_submatch are defined in drivers (*.c).
The rest is generated by config(1).  But the idea remains.

Re: CVS commit: src/sys/dev

[Masao Uebayashi]

On Thu, Nov 6, 2014 at 4:03 AM, Taylor R Campbell
campbell+netbsd-source-change...@mumble.net wrote:
 Why use a string-keyed table with run-time lookups instead of a C
 object with a C declaration?

 /* ioconf.h */
 extern struct cfiattrdata xxxbus;

 /* xxx.c */
 config_found(self, xxxbus);

I tend to prefer indirect lookup to direct reference almost everywhere
in config(9).  But in this case reference would be fine.

Re: CVS commit: src

[Masao Uebayashi]

Builders will surely be happy to see how the output of build.sh -m
evbearmv7-el kernels looks like. :)

Re: CVS commit: src/sys/dev

[Masao Uebayashi]

On Mon, Nov 3, 2014 at 9:49 PM, Quentin Garnier c...@cubidou.net wrote:
 On Sat, Nov 01, 2014 at 07:54:18AM +, Masao Uebayashi wrote:
 Module Name:  src
 Committed By: uebayasi
 Date: Sat Nov  1 07:54:18 UTC 2014

 Modified Files:
   src/sys/dev: audio.c audio_if.h

 Log Message:
 Revert previous.

 Not only audio_attach_mi() but also audioprint() have to be separated.
 midi.c has the same problem, and a little more complicated.  These will be
 revisited later.

 It's because they are functions for audiobus (where audio(4) attaches)
 rather than for audio.  So you can split them into a file that depends
 on audiobus.

Understood.

Let me reprase: audiobus is already an interface attribute.  Those
functions (audio_attach_mi(), audioprint(), ...) will belong to
audiobus.c (or .o, or .ko).  Those drivers providing the audiobus
interface (e.g. auich(4)) will depend on audiobus module.  So:

device auich: audiobus, ...

The funny thing here is, the line has two meaning: a) providing
audiobus interface, b) depending on audiobus module.  Due to the
limitation of the config(5) syntax!

One question is, when to unload audiobus-as-a-module.  It is depended
on by audio if drivers, but it does not depend on anything.  When all
audio if drivers are unloaded, there is not reason to keep it in
kernel.  Maybe some (smart) ref-counting is needed.

 Most pseudo-buses have that issue I think.  Probably some actual buses
 too.  I'd not really expect a kernel that has pchb but not pci selected
 to compile.

I've not really looked into pseudos yet...

Re: CVS commit: src/sys/dev

[Masao Uebayashi]

On Tue, Nov 4, 2014 at 1:34 AM, Quentin Garnier c...@cubidou.net wrote:
 On Tue, Nov 04, 2014 at 01:16:40AM +0900, Masao Uebayashi wrote:
 On Mon, Nov 3, 2014 at 9:49 PM, Quentin Garnier c...@cubidou.net wrote:
  On Sat, Nov 01, 2014 at 07:54:18AM +, Masao Uebayashi wrote:
  Module Name:  src
  Committed By: uebayasi
  Date: Sat Nov  1 07:54:18 UTC 2014
 
  Modified Files:
src/sys/dev: audio.c audio_if.h
 
  Log Message:
  Revert previous.
 
  Not only audio_attach_mi() but also audioprint() have to be separated.
  midi.c has the same problem, and a little more complicated.  These will be
  revisited later.
 
  It's because they are functions for audiobus (where audio(4) attaches)
  rather than for audio.  So you can split them into a file that depends
  on audiobus.

 Understood.

 Let me reprase: audiobus is already an interface attribute.  Those
 functions (audio_attach_mi(), audioprint(), ...) will belong to
 audiobus.c (or .o, or .ko).  Those drivers providing the audiobus
 interface (e.g. auich(4)) will depend on audiobus module.  So:

 device auich: audiobus, ...

 The funny thing here is, the line has two meaning: a) providing
 audiobus interface, b) depending on audiobus module.  Due to the
 limitation of the config(5) syntax!

 I don't see how this particular case is a problem.  Why exposing an
 audiobus interface wouldn't imply depending on the audiobus-specific
 functions?

Well, very probably no problem.  It's only that I was not 100% sure.

 One question is, when to unload audiobus-as-a-module.  It is depended
 on by audio if drivers, but it does not depend on anything.  When all
 audio if drivers are unloaded, there is not reason to keep it in
 kernel.  Maybe some (smart) ref-counting is needed.

 So you moved on to loadable modules now?  I thought your intent was
 .text massaging.

Just thinking and making sure that I'm not going to break it by design.

  Most pseudo-buses have that issue I think.  Probably some actual buses
  too.  I'd not really expect a kernel that has pchb but not pci selected
  to compile.

 I've not really looked into pseudos yet...

 I meant audiobus.  There are a lot of such buses that are not really
 anything but a way to attach a generic device.

Sure.  If I find something odd I'll bring up it somewhere.

Re: CVS commit: src/sys/arch

[Masao Uebayashi]

On Mon, Nov 3, 2014 at 12:12 AM, Joerg Sonnenberger
jo...@britannica.bec.de wrote:
 On Sat, Nov 01, 2014 at 11:58:55AM +, Masao Uebayashi wrote:
 Module Name:  src
 Committed By: uebayasi
 Date: Sat Nov  1 11:58:55 UTC 2014

 Modified Files:
   src/sys/arch/amd64/conf: kern.ldscript kern.ldscript.2MB
   kern.ldscript.Xen
   src/sys/arch/i386/conf: kern.ldscript kern.ldscript.4MB
   kern.ldscript.Xen

 Log Message:
 amd64, i386: Don't expose .data.{read_mostly,cacheline_aligned} sections

 Huh? There is no reason for such hacks. Please discuss such changes
 first.

This is how mips ldscript does.

Those two sections are collected and aligned by linker.  After doing
that, is there still any reason to expose the sections?  If you point
out one, I'll revert the changes and document them in the files.

alpha and arm ldscripts don't define .data.{read_mostly,cacheline_alined}, BTW.

Re: CVS commit: src/sys/arch

[Masao Uebayashi]

On Mon, Nov 3, 2014 at 1:51 AM, Joerg Sonnenberger
jo...@britannica.bec.de wrote:
 On Mon, Nov 03, 2014 at 01:24:23AM +0900, Masao Uebayashi wrote:
 On Mon, Nov 3, 2014 at 12:12 AM, Joerg Sonnenberger
 jo...@britannica.bec.de wrote:
  On Sat, Nov 01, 2014 at 11:58:55AM +, Masao Uebayashi wrote:
  Module Name:  src
  Committed By: uebayasi
  Date: Sat Nov  1 11:58:55 UTC 2014
 
  Modified Files:
src/sys/arch/amd64/conf: kern.ldscript kern.ldscript.2MB
kern.ldscript.Xen
src/sys/arch/i386/conf: kern.ldscript kern.ldscript.4MB
kern.ldscript.Xen
 
  Log Message:
  amd64, i386: Don't expose .data.{read_mostly,cacheline_aligned} sections
 
  Huh? There is no reason for such hacks. Please discuss such changes
  first.

 This is how mips ldscript does.

 Those two sections are collected and aligned by linker.  After doing
 that, is there still any reason to expose the sections?  If you point
 out one, I'll revert the changes and document them in the files.

 It makes it harder to look at the kernel image and see which variables
 are already optimised? Your change does not improve anything but saving a
 few Bytes. That's not an improvement.

Is this the only reason you can think of?

Re: CVS commit: src/sys/arch

[Masao Uebayashi]

On Mon, Nov 3, 2014 at 2:20 AM, Joerg Sonnenberger
jo...@britannica.bec.de wrote:
 On Mon, Nov 03, 2014 at 01:56:36AM +0900, Masao Uebayashi wrote:
 On Mon, Nov 3, 2014 at 1:51 AM, Joerg Sonnenberger
 jo...@britannica.bec.de wrote:
  On Mon, Nov 03, 2014 at 01:24:23AM +0900, Masao Uebayashi wrote:
  On Mon, Nov 3, 2014 at 12:12 AM, Joerg Sonnenberger
  jo...@britannica.bec.de wrote:
   On Sat, Nov 01, 2014 at 11:58:55AM +, Masao Uebayashi wrote:
   Module Name:  src
   Committed By: uebayasi
   Date: Sat Nov  1 11:58:55 UTC 2014
  
   Modified Files:
 src/sys/arch/amd64/conf: kern.ldscript kern.ldscript.2MB
 kern.ldscript.Xen
 src/sys/arch/i386/conf: kern.ldscript kern.ldscript.4MB
 kern.ldscript.Xen
  
   Log Message:
   amd64, i386: Don't expose .data.{read_mostly,cacheline_aligned} 
   sections
  
   Huh? There is no reason for such hacks. Please discuss such changes
   first.
 
  This is how mips ldscript does.
 
  Those two sections are collected and aligned by linker.  After doing
  that, is there still any reason to expose the sections?  If you point
  out one, I'll revert the changes and document them in the files.
 
  It makes it harder to look at the kernel image and see which variables
  are already optimised? Your change does not improve anything but saving a
  few Bytes. That's not an improvement.

 Is this the only reason you can think of?

 It is good enough. You haven't given a reason at all so far.

I thought it was a joke.

I made ldscript much simpler.

Although I'm not convinced at all, I can revert for you.

If you know everything about those ldscripts, I'd appreciate you
rewrite all of them.  Thanks.

Re: CVS commit: src/sys/arch

[Masao Uebayashi]

Reverted.

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

[Masao Uebayashi]

On Thu, Oct 30, 2014 at 8:36 PM, Alan Barrett a...@netbsd.org 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

[Masao Uebayashi]

On Thu, Oct 30, 2014 at 10:01 PM, Quentin Garnier c...@cubidou.net 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 a...@netbsd.org 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

[Masao Uebayashi]

On Fri, Oct 31, 2014 at 1:33 AM, Antti Kantee
po...@homeworld.netbsd.org 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 chris...@astron.com 
 wrote:
  In article 20141030012621.0982...@cvs.netbsd.org,
  Masao Uebayashi source-changes-d@NetBSD.org 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

[Masao Uebayashi]

On Fri, Oct 31, 2014 at 2:28 AM, Masao Uebayashi uebay...@gmail.com wrote:
 On Fri, Oct 31, 2014 at 1:33 AM, Antti Kantee
 po...@homeworld.netbsd.org 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 chris...@astron.com 
 wrote:
  In article 20141030012621.0982...@cvs.netbsd.org,
  Masao Uebayashi source-changes-d@NetBSD.org 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

[Masao Uebayashi]

On Fri, Oct 31, 2014 at 3:00 AM, Antti Kantee po...@netbsd.org 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

[Masao Uebayashi]

On Fri, Oct 31, 2014 at 1:49 AM, David Holland
dholland-sourcechan...@netbsd.org 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

[Masao Uebayashi]

On Thu, Oct 30, 2014 at 10:51 AM, Christos Zoulas chris...@astron.com wrote:
 In article 20141030012621.0982...@cvs.netbsd.org,
 Masao Uebayashi source-changes-d@NetBSD.org 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

[Masao Uebayashi]

On Thu, Oct 30, 2014 at 11:38 AM, Matt Thomas m...@3am-software.com 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/sys/arch

[Masao Uebayashi]

On Sun, Oct 19, 2014 at 12:15 PM, John Nemeth jnem...@cue.bc.ca wrote:
 On Oct 18,  4:56pm, Masao Uebayashi wrote:
 }
 } Module Name:  src
 } Committed By: uebayasi
 } Date: Sat Oct 18 16:56:51 UTC 2014
 }
 } Modified Files:
 }   src/sys/arch/amd64/conf: ALL GENERIC XEN3_DOM0
 }   src/sys/arch/i386/conf: ALL GENERIC INSTALL_FLOPPY XEN3_DOM0
 }   src/sys/arch/x86/pci: files.pci
 }
 } Log Message:
 } Install agp_* drivers where pchb(4) is installed except INSTALL_FLOPPY.
 }
 } XXX
 } Config around agp(4) is done in quite wrong direction.
 }   pchb - (agpbus) - agp - agp_*
 } should be:
 }   pchb - (pcibus) - agp_* - (agpbus) - agp

  No, it should NOT!  AGP does NOT hang off a PCI bus.  It is a
 seperate bus that sits beside PCI.

Understood.  But still, agp.c is under sys/dev/pci; and its
configuration is common to PCI, right?

And, agp_* should pass function pointers to agp via attach args so
that #ifdef NAGP_* in agp.c can go away.

Re: CVS commit: src/sys/arch/x86/pci

[Masao Uebayashi]

On Sat, Oct 18, 2014 at 5:55 AM, Masao Uebayashi uebay...@netbsd.org wrote:
 Module Name:src
 Committed By:   uebayasi
 Date:   Fri Oct 17 20:55:21 UTC 2014

 Modified Files:
 src/sys/arch/x86/pci: files.pci

 Log Message:
 Fix another indirect circular dependency (agp_* - (agpbus) - pchb - abp_*).
 Fixes no agp* build.  Reported  build-tested by Kurt Schreiner.

Correction: agp_* - agp - (agpbus) - pchb - agp_*

Here agpbus is an interface attribute (bus).

Re: CVS commit: src/sys/arch/evbarm/conf

[Masao Uebayashi]

Probably the default style attachment (like midi* at midibus?) can
(should) be implicity generated.

Re: CVS commit: src/sys/arch/amd64/conf

[Masao Uebayashi]

On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer bou...@antioche.eu.org wrote:
 On Sat, Oct 11, 2014 at 09:50:03AM +, Masao Uebayashi wrote:
 Module Name:  src
 Committed By: uebayasi
 Date: Sat Oct 11 09:50:03 UTC 2014

 Modified Files:
   src/sys/arch/amd64/conf: XEN3_DOM0 std.xen

 Log Message:
 Don't include std.ath_hal for XEN3_DOMU.

 Why ?
 We still support PCI pass-through, so we could have a ath in a domU

In that case you have to enable xpci/pci at first.

Including std.ath_hal means that you pull in ath device code in your
kernel.  But you don't have no parent buses.  This might be OK for
ath(4), but in general, it means that config(1) doesn't resolve
dependency, and your kernel may be bloated by unnecessary code.

(config(1) is not great in reporting dependency errors yet.)

Re: CVS commit: src/sys/arch/amd64/conf

[Masao Uebayashi]

On Sun, Oct 12, 2014 at 3:06 AM, Manuel Bouyer bou...@antioche.eu.org wrote:
 On Sun, Oct 12, 2014 at 12:17:22AM +0900, Masao Uebayashi wrote:
 On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer bou...@antioche.eu.org 
 wrote:
  On Sat, Oct 11, 2014 at 09:50:03AM +, Masao Uebayashi wrote:
  Module Name:  src
  Committed By: uebayasi
  Date: Sat Oct 11 09:50:03 UTC 2014
 
  Modified Files:
src/sys/arch/amd64/conf: XEN3_DOM0 std.xen
 
  Log Message:
  Don't include std.ath_hal for XEN3_DOMU.
 
  Why ?
  We still support PCI pass-through, so we could have a ath in a domU

 In that case you have to enable xpci/pci at first.

 Including std.ath_hal means that you pull in ath device code in your
 kernel.  But you don't have no parent buses.  This might be OK for
 ath(4), but in general, it means that config(1) doesn't resolve
 dependency, and your kernel may be bloated by unnecessary code.

 why isn't this compiled in only when ath(4) is inclued in config file ?
 isn't that what attributes are for ?

I don't understand.  If you say config file, is it files.*
(definition) or std.* (selection)?

Re: CVS commit: src/sys/arch/amd64/conf

[Masao Uebayashi]

On Sun, Oct 12, 2014 at 3:48 AM, Manuel Bouyer bou...@antioche.eu.org wrote:
 On Sun, Oct 12, 2014 at 03:35:48AM +0900, Masao Uebayashi wrote:
 On Sun, Oct 12, 2014 at 3:06 AM, Manuel Bouyer bou...@antioche.eu.org 
 wrote:
  On Sun, Oct 12, 2014 at 12:17:22AM +0900, Masao Uebayashi wrote:
  On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer bou...@antioche.eu.org 
  wrote:
   On Sat, Oct 11, 2014 at 09:50:03AM +, Masao Uebayashi wrote:
   Module Name:  src
   Committed By: uebayasi
   Date: Sat Oct 11 09:50:03 UTC 2014
  
   Modified Files:
 src/sys/arch/amd64/conf: XEN3_DOM0 std.xen
  
   Log Message:
   Don't include std.ath_hal for XEN3_DOMU.
  
   Why ?
   We still support PCI pass-through, so we could have a ath in a domU
 
  In that case you have to enable xpci/pci at first.
 
  Including std.ath_hal means that you pull in ath device code in your
  kernel.  But you don't have no parent buses.  This might be OK for
  ath(4), but in general, it means that config(1) doesn't resolve
  dependency, and your kernel may be bloated by unnecessary code.
 
  why isn't this compiled in only when ath(4) is inclued in config file ?
  isn't that what attributes are for ?

 I don't understand.  If you say config file, is it files.*
 (definition) or std.* (selection)?

 OK, I see. But I still think config should be able to include theses
 only if ath or athn is there; wouldn't adding   ath at appropriate places
 in files.ath_hal be enough for this to happen ?

Instead of:

ath_common_files.c ath  athn

You can do:

define ath: ath_common
define athn: ath_common
define ath_common
ath_common_files.c ath_common

I don't understand why you need  or | or those expressions.  I think
99% are file with dependency.  Or do you want more complex world like
this?

http://nxr.netbsd.org/source/xref/src-freebsd/sys/conf/files

Re: CVS commit: src/sys/arch/amd64/conf

[Masao Uebayashi]

On Sun, Oct 12, 2014 at 4:35 AM, Manuel Bouyer bou...@antioche.eu.org wrote:
 On Sun, Oct 12, 2014 at 04:23:17AM +0900, Masao Uebayashi wrote:
 On Sun, Oct 12, 2014 at 3:48 AM, Manuel Bouyer bou...@antioche.eu.org 
 wrote:
  On Sun, Oct 12, 2014 at 03:35:48AM +0900, Masao Uebayashi wrote:
  On Sun, Oct 12, 2014 at 3:06 AM, Manuel Bouyer bou...@antioche.eu.org 
  wrote:
   On Sun, Oct 12, 2014 at 12:17:22AM +0900, Masao Uebayashi wrote:
   On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer 
   bou...@antioche.eu.org wrote:
On Sat, Oct 11, 2014 at 09:50:03AM +, Masao Uebayashi wrote:
Module Name:  src
Committed By: uebayasi
Date: Sat Oct 11 09:50:03 UTC 2014
   
Modified Files:
  src/sys/arch/amd64/conf: XEN3_DOM0 std.xen
   
Log Message:
Don't include std.ath_hal for XEN3_DOMU.
   
Why ?
We still support PCI pass-through, so we could have a ath in a domU
  
   In that case you have to enable xpci/pci at first.
  
   Including std.ath_hal means that you pull in ath device code in your
   kernel.  But you don't have no parent buses.  This might be OK for
   ath(4), but in general, it means that config(1) doesn't resolve
   dependency, and your kernel may be bloated by unnecessary code.
  
   why isn't this compiled in only when ath(4) is inclued in config file ?
   isn't that what attributes are for ?
 
  I don't understand.  If you say config file, is it files.*
  (definition) or std.* (selection)?
 
  OK, I see. But I still think config should be able to include theses
  only if ath or athn is there; wouldn't adding   ath at appropriate 
  places
  in files.ath_hal be enough for this to happen ?

 Instead of:

 ath_common_files.c ath  athn

 You can do:

 define ath: ath_common
 define athn: ath_common
 define ath_common
 ath_common_files.c ath_common

 I don't understand why you need  or | or those expressions.  I think
 99% are file with dependency.  Or do you want more complex world like
 this?

 http://nxr.netbsd.org/source/xref/src-freebsd/sys/conf/files

 No, I just want e.g. options ATHHAL_AR5210 to be a noop if
 ath(4) is not inclued in the kernel config file.
 This way you don't need to mess with these options at all, unless
 you really want a stripped-down kernel.

Understood.

The problem is, there are options that select something, and those
that define flags/params.  Attributes (modules) that are neighter
(pseudo) devices or filesystems are selected only by options.
De-selection (no ...) has the same problem  I'll consider this.

Re: CVS commit: src/sys/arch/amd64/conf

[Masao Uebayashi]

I think this can be fixed by providing new selection statements,
flags and/or params, which are meant to enable flags/params, not
options/attributes.

For ath's case, options ATHHAL_AR5210 means that you want to include
more *.c's for that option.  params ATHHAL_DEBUG means that you want
to change *.o with that flags/params set.

In other words, flags ... or params ... never add *.c and
dependencies in your kernel.

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

[Masao Uebayashi]

My bad.  Reproduced here.  Hopefully fixed now.

On Fri, Oct 10, 2014 at 10:55 PM, Jared McNeill jmcne...@netbsd.org 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 uebayasi-s783fymb3ccdnm+yrof...@public.gmane.org
 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/sys/conf

[Masao Uebayashi]

config(5) is made of definitions and selections.  Selections are
basically written in user's config (GENERIC, etc.); commen ones may be
put in sys/conf/std or sys/arch/*/conf/std.*.

To follow that naming convention, how about:

sys/conf/all.filesystems
sys/conf/all.usb

?

Users have to filter unwanted ones by the no ... syntax.  If that
will not work, config(1) needs to be fixed. :)

Re: CVS commit: src/sys

[Masao Uebayashi]

Not objecting this paricular change, but I hope that sys/sysctl.h be
less loaded, ideally porviding only sysctl base definitions, than more
loaded...

Re: CVS commit: src/sys

[Masao Uebayashi]

On Tue, May 27, 2014 at 6:31 AM, Antti Kantee po...@iki.fi wrote:
 On 26/05/14 19:38, David Holland wrote:

 On Sun, May 25, 2014 at 04:31:51PM +, Antti Kantee wrote:
Modified Files:
src/sys/kern: subr_devsw.c vfs_bio.c
src/sys/rump/librump/rumpkern: rump.c
   
Log Message:
Call biodone() in the bdev_strategy() error via a pointer.  Decouples
subr_devsw from VFS -- not that I/O buffers are _VFS_ entities --

 Yes they are... so are devsw entries, for that matter.


 Fact: tcp/ip + bpf (accessed via devsw) works fine without VFS.  Let's keep
 it that way.  E.g. IoT folks looking at using the NetBSD TCP/IP stack in

This is really nice!

 their [high-end] devices wouldn't be too thrilled if the memory requirement
 for networking grew by 100% just because.

If an OS can run with 1/2 memory, the number of (virtual) instances
can be doubled, which is a big win in this era. :)

Re: CVS commit: src/sys/arch/amd64/amd64

[Masao Uebayashi]

On Tue, May 13, 2014 at 2:28 AM, Jonathan A. Kollasch
jakll...@kollasch.net wrote:
 On Mon, May 12, 2014 at 07:05:29PM +0200, Joerg Sonnenberger wrote:
 On Mon, May 12, 2014 at 01:49:24PM +, Masao Uebayashi wrote:
  Module Name:src
  Committed By:   uebayasi
  Date:   Mon May 12 13:49:24 UTC 2014
 
  Modified Files:
  src/sys/arch/amd64/amd64: machdep.c
 
  Log Message:
  Don't reserve space (128) on signal stack for unknown reasons; the actual
  space for struct sigframe_siginfo (+ alignment) is allocated just below.

 AMD64 uses a redzone, so the compiler can put up to 128 Bytes on the
 stack without having to adjust RSP. Please revert immediately.

 Done.

Thanks.  I left a comment there.

Re: CVS commit: src

[Masao Uebayashi]

Thanks.  I will revisit this later.

On Tuesday, April 29, 2014, Antti Kantee po...@homeworld.netbsd.org wrote:

 On Tue, Apr 29, 2014 at 06:51:57AM +, Masao Uebayashi wrote:
  Module Name:  src
  Committed By: uebayasi
  Date: Tue Apr 29 06:51:57 UTC 2014
 
  Modified Files:
src: build.sh
 
  Log Message:
  resolvepath: Resolve .. in absolute paths.
 
 
  To generate a diff of this commit:
  cvs rdiff -u -r1.278 -r1.279 src/build.sh

 This breaks ./build.sh -w

Re: CVS commit: src/sys/arch/powerpc/conf

[Masao Uebayashi]

Hopefully kernel entry (locore.o) is placed using ldscript so that
stupid *.o ordering in makefiles can go away?

On Sat, Apr 19, 2014 at 9:46 PM, Matt Thomas m...@netbsd.org wrote:
 Module Name:src
 Committed By:   matt
 Date:   Sat Apr 19 12:46:04 UTC 2014

 Added Files:
 src/sys/arch/powerpc/conf: kern64.ldscript

 Log Message:
 ldscript for ppc64 kernels


 To generate a diff of this commit:
 cvs rdiff -u -r0 -r1.1 src/sys/arch/powerpc/conf/kern64.ldscript

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

Re: CVS commit: src/sys/kern

[Masao Uebayashi]

On Sun, Apr 13, 2014 at 12:33 AM, Nick Hudson sk...@netbsd.org wrote:
 On 04/12/14 16:08, Masao Uebayashi wrote:

 Module Name:src
 Committed By:   uebayasi
 Date:   Sat Apr 12 15:08:56 UTC 2014

 Modified Files:
 src/sys/kern: kern_exec.c

 Log Message:
 execve_runproc: Correct thinko in Rev. 1.386; the new SP always points to
 after (higher adderss) argc/argv/env/aux/strings regardless of stack
 growing
 direction .

 Doesn't this mean that argc, etc will get overwritten on _rtld_start call
 for stack grows down machines?

 SP needs to point to the first available stack address. On stack grows down
 machines this is a lower value than argc, etc. On stack grows up machines
 this is a higher value.

http://www.netbsd.org/~uebayasi/execve-stack-growdown.pdf
http://www.netbsd.org/~uebayasi/execve-stack-growup.pdf

Initial SP points to STACK_GROW(minsaddr, ssize).  rtld can use the
given stack freely (contradicting obsolete comments found in
kern_exec.c).

stack-growing-up rtld has to figure out argc.  This is possible by
(vaddr_t)ps_argvstr - (vaddr_t)sizeof(argc).  Note that argc on stack
is long (== char *), not int.  hppa's rtld assumes int, which has to
be fixed for hppa64.

http://nxr.netbsd.org/xref/src/libexec/ld.elf_so/arch/hppa/rtld_start.S#88

 btw, why do you keep adding 4 space idented { } ?

To narrow local var scopes.  They should go away eventually...

Re: CVS commit: src/share/mk

[Masao Uebayashi]

Is this all about symlink-to-directory in an OBJDIR, right?  My theory
is that directory creation in OBJDIR is all wrong...

Kernel build *should* include static headers in $DESTDIR (#include
foo.h) or generated headers (#include foo.h) IMO.

Re: CVS commit: src/share/mk

[Masao Uebayashi]

Sorry that I was lost, but I still believe that
creating-directories-as-make-target is to avoid.  Is there any
counter-example (use case) where it should be there?

On Fri, Jan 24, 2014 at 1:30 AM, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote:
 Is this all about symlink-to-directory in an OBJDIR, right?  My theory
 is that directory creation in OBJDIR is all wrong...

 Kernel build *should* include static headers in $DESTDIR (#include
 foo.h) or generated headers (#include foo.h) IMO.

 bsd.klinks.mk is used only for standalone programs
 and it should not require installed DESTDIR.

 For kernel builds, config(1) creates symlinks in compile dirs.

 ---
 Izumi Tsutsui

Re: CVS commit: src/distrib/sets

[Masao Uebayashi]

I agree that in an ideal reproducible world timestamp (== physical
time and its order) has no value.  But it is useful to detect
unnecessary rebuild - reproducible but built repeatedly 
unnecessarily.  I see some value in it.

On Fri, Jan 24, 2014 at 6:45 AM, Alan Barrett a...@netbsd.org wrote:
 Module Name:src
 Committed By:   apb
 Date:   Thu Jan 23 21:45:27 UTC 2014

 Modified Files:
 src/distrib/sets: Makefile

 Log Message:
 Remove time= keywords from METALOG.sanitised.

 The times add unnecessary differences to the DESTDIR trees for MKREPRO
 builds, and they are not needed by anything.  (maketars, the chief
 consumer of METALOG.sanitised, explicitly ignores the time fields.)

 Also factor out some duplicated code and update comments.


 To generate a diff of this commit:
 cvs rdiff -u -r1.91 -r1.92 src/distrib/sets/Makefile

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

Re: CVS commit: src/share/mk

[Masao Uebayashi]

How about kernel modules?

On Fri, Jan 24, 2014 at 1:00 PM, matthew green m...@eterna.com.au wrote:

 Is this all about symlink-to-directory in an OBJDIR, right?  My theory
 is that directory creation in OBJDIR is all wrong...

 Kernel build *should* include static headers in $DESTDIR (#include
 foo.h) or generated headers (#include foo.h) IMO.

 the kernel build 100% does not and should not depend upon $DESTDIR.


 .mrg.

Re: CVS commit: src/share/mk

[Masao Uebayashi]

I wonder if ln -sfh is portable?

On Thu, Jan 23, 2014 at 12:23 PM, Christos Zoulas chris...@zoulas.com wrote:
 On Jan 23,  3:11am, campbell+netbsd-source-change...@mumble.net (Taylor R 
 Campbell) wrote:
 -- Subject: Re: CVS commit: src/share/mk

 |Date: Wed, 22 Jan 2014 13:15:44 -0500
 |From: chris...@zoulas.com (Christos Zoulas)
 |
 |On Jan 22,  7:29am, m...@3am-software.com (Matt Thomas) wrote:
 |-- Subject: Re: CVS commit: src/share/mk
 |
 || I always wondered why we don't use ln -sf
 || and avoid the race.
 |
 |That does not work because if the destnation is a directory it will
 |try to link in the destination directory... (I tried). This is why
 |I suggested that it needs to be done differently.
 |
 | ln -sfh?
 |
 | As an aside, it would be nice if there were an easy way to create a
 | symlink at a temporary location and rename it over the permanent one.
 | `ln -sfh' will unlink instead, and mv(1) is too smart for its own good
 | about directories to be able to rename over a symlink reliably...


 Yes perhaps that will work.

 christos

Re: CVS commit: src/sys/arch

[Masao Uebayashi]

Because I don't want to change resulting binaries (*.o) for now.  I
think I'll switch these when cleaned up and merged and moved to
sys/arch/x86.  How do you think?

On Tue, Jun 25, 2013 at 12:17 PM, YAMAMOTO Takashi
y...@mwd.biglobe.ne.jp wrote:
 hi,

 why do you need to make *.S include another *.S
 rather than tweaking makefile?

 YAMAMOTO Takashi

 Module Name:  src
 Committed By: uebayasi
 Date: Tue Jun 25 00:27:22 UTC 2013

 Modified Files:
   src/sys/arch/amd64/amd64: vector.S
   src/sys/arch/i386/i386: vector.S
 Added Files:
   src/sys/arch/amd64/amd64: amd64_trap.S
   src/sys/arch/i386/i386: i386_trap.S i386_trap_ipkdb.S

 Log Message:
 Split these to improve diffability.


 To generate a diff of this commit:
 cvs rdiff -u -r0 -r1.1 src/sys/arch/amd64/amd64/amd64_trap.S
 cvs rdiff -u -r1.43 -r1.44 src/sys/arch/amd64/amd64/vector.S
 cvs rdiff -u -r0 -r1.1 src/sys/arch/i386/i386/i386_trap.S \
 src/sys/arch/i386/i386/i386_trap_ipkdb.S
 cvs rdiff -u -r1.61 -r1.62 src/sys/arch/i386/i386/vector.S

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

Re: CVS commit: [agc-symver] src/lib/libc

[Masao Uebayashi]

I'm not sure if symbols like _citrus_* are meant to be exported as
global.  Probably not.

Re: CVS commit: [agc-symver] src/lib/libc

[Masao Uebayashi]

How do you generate Version.map?

Can you define symbols per-module (e.g., libc/gen, libc/stdio, ...)?

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

[Masao Uebayashi]

I like make(1) to exit when stale depend is found.

On Tue, Mar 5, 2013 at 11:04 AM, Christos Zoulas chris...@netbsd.orgwrote:

 Module Name:src
 Committed By:   christos
 Date:   Tue Mar  5 02:04:11 UTC 2013

 Modified Files:
 src/usr.bin/make: dir.c job.c parse.c

 Log Message:
 Keep track of the location where a dependency is defined, so we can report
 about it.


 To generate a diff of this commit:
 cvs rdiff -u -r1.65 -r1.66 src/usr.bin/make/dir.c
 cvs rdiff -u -r1.170 -r1.171 src/usr.bin/make/job.c
 cvs rdiff -u -r1.185 -r1.186 src/usr.bin/make/parse.c

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

Re: CVS commit: src/sys/arch/ia64/ia64

[Masao Uebayashi]

On Fri, Aug 31, 2012 at 11:31 PM, Chuck Silvers c...@netbsd.org wrote:
 Log Message:
 fix some confusion about PG_FAKE.

The name is so confusing.  How about changing it to e.g. PG_UNINITED?

Re: CVS commit: src/sys/arch/sparc

[Masao Uebayashi]

Having an MI routine that's called very early, just after C code can be run?

I think kernel bootstrap / initialization needs more granularity.

On Tue, Jul 31, 2012 at 8:56 AM, Christos Zoulas chris...@zoulas.com wrote:
 On Jul 30, 11:37am, m...@3am-software.com (Matt Thomas) wrote:
 -- Subject: Re: CVS commit: src/sys/arch/sparc

 |
 | On Jul 30, 2012, at 10:29 AM, Christos Zoulas wrote:
 |
 |  Module Name:src
 |  Committed By:   christos
 |  Date:   Mon Jul 30 17:29:55 UTC 2012
 |  Modified Files:
 |  src/sys/arch/sparc/dev: kd.c
 |  src/sys/arch/sparc/sparc: machdep.c
 | 
 |  Log Message:
 |  move cn_tab initializationt to cpu_startup
 |
 | cn_tab was used for early console access
 | cpu_startup is too late.
 |
 | it needs to be done sometime before main is
 | called.

 Should we make cn_tab md, and let the ports initialize it themselves?
 Any better ideas?


 christos

Re: CVS commit: src/sys/dev

[Masao Uebayashi]

I think fec(4) is too common.  I'd give SoC periph devs more
descriptive names, like mpc8xxxfec(4).

On Mon, Jul 23, 2012 at 10:05 PM, Matt Thomas m...@netbsd.org wrote:
 Module Name:src
 Committed By:   matt
 Date:   Mon Jul 23 13:05:48 UTC 2012

 Modified Files:
 src/sys/dev: DEVNAMES

 Log Message:
 Add fec (arm) and mdio (powerpc)


 To generate a diff of this commit:
 cvs rdiff -u -r1.277 -r1.278 src/sys/dev/DEVNAMES

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

Re: CVS commit: src

[Masao Uebayashi]

As discussed somewhere some time ago, I think PAGE_SIZE and other
constants should be provided via sysconf(9).

If you don't like indirection, you'd use pre-link binaries (== static kernel).

On Sat, Feb 18, 2012 at 9:14 AM, Julio Merino j...@julipedia.org wrote:
 On 2/17/12 7:11 PM, Julio Merino wrote:

 On 2/17/12 6:42 PM, Matt Thomas wrote:


 On Feb 17, 2012, at 3:11 PM, Julio Merino wrote:

 On 2/17/12 6:06 PM, Matt Thomas wrote:


 On Feb 17, 2012, at 3:02 PM, Julio Merino wrote:

 Aha, I see. Does it make sense to keep the test after renaming
 PAGE_SIZE to uvmexp.pagesize? It's a public symbol after all and we
 really should have tests for these, I think.

 Do we need to go over the broken modules one by one and replace
 PAGE_SIZE with uvmexp.pagesize? (I'm expecting this won't be as
 easy as it sounds due to preprocessor conditionals et. al.)


 They should still use PAGE_SIZE which should evaluate to
 uvmexp.pagesize


 Now you lost me. You started saying that PAGE_SIZE is explicitly not
 available, and now you say that the modules have to use PAGE_SIZE?

 The problem is that PAGE_SIZE is NOT being evaluated to
 uvmexp.pagesize as you mention. It's being evaluated to
 uvmexp_pagesize, which does not exist and thus causes the module to
 not load. And that's what this test is all about.


 Hmmm. I think uvmexp_pagesize, etal is there to avoid needed uvmexp
 defined.

 The problem was:

 --- uvm_param.h 29 Nov 2011 07:43:54 - 1.26
 +++ uvm_param.h 17 Feb 2012 23:40:50 -
 @@ -134,7 +134,7 @@
 * If MIN_PAGE_SIZE and MAX_PAGE_SIZE are not equal, then we must use
 * non-constant PAGE_SIZE, et al for LKMs.
 */
 -#if (MIN_PAGE_SIZE != MAX_PAGE_SIZE) defined(_LKM)
 +#if (MIN_PAGE_SIZE != MAX_PAGE_SIZE) (defined(_LKM) ||
 defined(MODULAR))
 #undef PAGE_SIZE
 #undef PAGE_MASK
 #undef PAGE_SHIFT



 I have applied this patch and rebuilt the affected test module... and it
 still won't load. Wasn't that supposed to be _MODULE instead of MODULAR?


 Oh, but even doing that change, the module won't load either.  PAGE_SIZE
 still ends up being defined as uvmexp_pagesize... which I believe is
 correct, right? because the size must be represented as a variable... but
 that variable is not available in the built kernel.

Re: CVS commit: src/sys

[Masao Uebayashi]

On Sun, Jul 31, 2011 at 2:23 AM, Jean-Yves Migeon
jeanyves.mig...@free.fr wrote:
 On 30.07.2011 19:01, Christos Zoulas wrote:
 Module Name:  src
 Committed By: christos
 Date:         Sat Jul 30 17:01:05 UTC 2011

 Modified Files:
       src/sys/conf: files
       src/sys/kern: init_main.c kern_lwp.c kern_synch.c
 Added Files:
       src/sys/kern: subr_pserialize.c
       src/sys/sys: pserialize.h

 Log Message:
 Add an implementation of passive serialization as described in expired
 US patent 4809168. This is a reader / writer synchronization mechanism,
 designed for lock-less read operations.

 Interesting! What would be the direct consumers of such an
 implementation? For example, can pserialize be a drop-in replacement for
 everything that is rwlock(9) based, or are they limitations?

I plan to use this to protect the vm_physseg array. [1]  It is looked
up thousands of times in every seconds (on busy systems), performance
critical, and very rarely updated (e.g. once a month when a new device
is attached/detached).  Avoiding atomic ops in such a situation is
desirable.

Masao

[1] http://mail-index.netbsd.org/tech-kern/2010/02/08/msg007262.html

 (I am aware that passive serialization is not equivalent to RCU).

 I remember reading articles mentioning how wonderful lockless
 algorithms are, except in situation where the additional bus
 locking/atomic ops involved did not really improve the situation in
 highly concurrent systems (and could even make it worse).

 --
 Jean-Yves Migeon
 jeanyves.mig...@free.fr