Re: CVS commit: src/sys/conf

[Izumi Tsutsui]

> Modified Files:
>   src/sys/conf: copyright
> 
> Log Message:
> Welcome to 2023.  Wrap lines so the years fit in to 80 columns with
> a leading kernel log timestamp.

Please don't forget requesting pullup to all release branches.

Thanks,
---
Izumi Tsutsui

Re: CVS commit: src/sys/conf

[Izumi Tsutsui]

> Modified Files:
>   src/sys/conf: copyright
> 
> Log Message:
> Welcome to 2022!

Please don't forget pullup requests for release branches.
(looks 2021 was missed in 9.2)

---
Izumi Tsutsui

re: CVS commit: src/sys/conf

[matthew green]

> - We only make a debuginstall rule to install netbsd-${KERNEL_CONFIG}.debug
>   if MKDEBUG=yes

this part pollutes my $DESTDIR with non-distrib kernel info still,
which also means it requires a $DESTDIR to build a kernel now.

i think that we should not do this in the kernel build but inside
the sets build, and create the set with ./netbsd and the
./usr/libdata/debug/netbsd-$KERNEL.debug path stored in some temp
dir of distrib/sets/.  that avoids issues of building stuff being
all different now, while allowing this to create sets  sanely.


.mrg.

Re: CVS commit: src/sys/conf

[Simon Burge]

"Christos Zoulas" wrote:

> Module Name:  src
> Committed By: christos
> Date: Mon Apr  5 22:52:03 UTC 2021
>
> Modified Files:
>
>   src/sys/conf: Makefile.kern.inc
>
> Log Message:
>
> Don't use /usr/bin/time (it is not portable)

Oops, that bit wasn't meant to sneak in.  Thanks for noticing and
fixing.

Cheers,
Simon.

Re: CVS commit: src/sys/conf

[Simon Burge]

"Valeriy E. Ushakov" wrote:

> Module Name:  src
> Committed By: uwe
> Date: Wed Jul  8 19:39:22 UTC 2020
>
> Modified Files:
>
>   src/sys/conf: assym.mk
>
> Log Message:
>
> Drop -fstack-usage* from CFLAGS passed genassym.
> We don't want it to create a "-.su" file.

Thanks!

Cheers,
Simon.

Re: CVS commit: src/sys/conf

[Valery Ushakov]

On Sat, Mar 07, 2020 at 19:18:41 -0500, Christos Zoulas wrote:

> Module Name:  src
> Committed By: christos
> Date: Sun Mar  8 00:18:41 UTC 2020
> 
> Modified Files:
>   src/sys/conf: files
> 
> Log Message:
> undo previous since config has been fixed

It's still not.  Nested ifdefs are not handled correctly.

-uwe

Re: CVS commit: src/sys/conf

[Ryo Shimizu]

>OK, I reproduced it, and have commited a fix for aarch64.  I will also
>include this in the pullup requests for -9 and -8

with sys/conf/files r1.1259, build successfully and it works fine.
thanks!

-- 
ryo shimizu

re: CVS commit: src/sys/conf

[Paul Goyette]

On Fri, 6 Mar 2020, matthew green wrote:


Paul Goyette writes:

On Thu, 5 Mar 2020, Paul Goyette wrote:


also aarch64 has no EXEC_AOUT.


Does aarch64 have COMPAT_NETBSD32?  If so, I will adjust my fix.  (I
built 67 different architectures, including all of the ones that the
releng build cluster is building, and did not have any problems with
aarch64 or any other.)


As near as I can tell, aarch64 sets MACHINE_CPU to "aarch64", so it
will not try to build COMPAT_NETBSD32 due to the following tests in
$SRC/sys/compat/netbsd32/netbsd32.mk

.if ${MACHINE_ARCH} == "x86_64" \
 || ${MACHINE_CPU} == "arm" \
 || ${MACHINE_ARCH} == "sparc64" \
 || (!empty(MACHINE_ARCH:Mmips64*) && !defined(BSD_MK_COMPAT_FILE))
COMPAT_USE_NETBSD32?=yes
.else
COMPAT_USE_NETBSD32?=no
.endif


Perhaps the  line should be changed to "aarch64" instead of "arm" ?


what <<< line? :-)

arm64 should be adde here, yes.  arm should remain -- it's
a fake netbsd32 in that it handles the old 32 bit ABI on
32 bit arm systems, so it's still useful.  we're not able
to support both that and EABI on arm64 currently (not sure
how it would be easy without making it possible to compile
the netbsd32 code twice, since there are additional layout
differences that are difficult to handle without letting
the compiler do it for you.)

sorry, i should have added arm64 here when i was looking
at it but i missed it.


Ooopppsss, forgot to tag the <<< line!

Anyway, I actually fixed it differently, in sys/conf/files
rev 1.1259


++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+

re: CVS commit: src/sys/conf

[matthew green]

Paul Goyette writes:
> On Thu, 5 Mar 2020, Paul Goyette wrote:
> 
> >> also aarch64 has no EXEC_AOUT.
> >
> > Does aarch64 have COMPAT_NETBSD32?  If so, I will adjust my fix.  (I
> > built 67 different architectures, including all of the ones that the
> > releng build cluster is building, and did not have any problems with
> > aarch64 or any other.)
> 
> As near as I can tell, aarch64 sets MACHINE_CPU to "aarch64", so it
> will not try to build COMPAT_NETBSD32 due to the following tests in
> $SRC/sys/compat/netbsd32/netbsd32.mk
> 
> .if ${MACHINE_ARCH} == "x86_64" \
>  || ${MACHINE_CPU} == "arm" \
>  || ${MACHINE_ARCH} == "sparc64" \
>  || (!empty(MACHINE_ARCH:Mmips64*) && !defined(BSD_MK_COMPAT_FILE))
> COMPAT_USE_NETBSD32?=yes
> .else
> COMPAT_USE_NETBSD32?=no
> .endif
> 
> 
> Perhaps the  line should be changed to "aarch64" instead of "arm" ?

what <<< line? :-)

arm64 should be adde here, yes.  arm should remain -- it's
a fake netbsd32 in that it handles the old 32 bit ABI on
32 bit arm systems, so it's still useful.  we're not able
to support both that and EABI on arm64 currently (not sure
how it would be easy without making it possible to compile
the netbsd32 code twice, since there are additional layout
differences that are difficult to handle without letting
the compiler do it for you.)

sorry, i should have added arm64 here when i was looking
at it but i missed it.

Re: CVS commit: src/sys/conf

[Paul Goyette]

OK, I reproduced it, and have commited a fix for aarch64.  I will also
include this in the pullup requests for -9 and -8

On Thu, 5 Mar 2020, Paul Goyette wrote:


On Fri, 6 Mar 2020, Ryo Shimizu wrote:




also aarch64 has no EXEC_AOUT.


Does aarch64 have COMPAT_NETBSD32?  If so, I will adjust my fix.  (I
built 67 different architectures, including all of the ones that the
releng build cluster is building, and did not have any problems with
aarch64 or any other.)


it seems that releng build was failed. 
http://releng.netbsd.org/builds/HEAD/202003050510Z/evbarm-aarch64.build.failed


Hmmm, I wonder why I didn't see this.  I have another build running to
reproduce.


Yes, optinos COMPAT_NETBSD32 is exists in sys/arch/evbarm/conf/GENERIC64.
but EXEC_AOUT is not supported. (yet?)


OK, I'll get this all fixed up as soon as I can.


++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+

!DSPAM:5e614c09108991373011237!




++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+

Re: CVS commit: src/sys/conf

[Paul Goyette]

On Fri, 6 Mar 2020, Ryo Shimizu wrote:




also aarch64 has no EXEC_AOUT.


Does aarch64 have COMPAT_NETBSD32?  If so, I will adjust my fix.  (I
built 67 different architectures, including all of the ones that the
releng build cluster is building, and did not have any problems with
aarch64 or any other.)


it seems that releng build was failed. 
http://releng.netbsd.org/builds/HEAD/202003050510Z/evbarm-aarch64.build.failed


Hmmm, I wonder why I didn't see this.  I have another build running to
reproduce.


Yes, optinos COMPAT_NETBSD32 is exists in sys/arch/evbarm/conf/GENERIC64.
but EXEC_AOUT is not supported. (yet?)


OK, I'll get this all fixed up as soon as I can.


++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+

Re: CVS commit: src/sys/conf

[Ryo Shimizu]

>> also aarch64 has no EXEC_AOUT.
>
>Does aarch64 have COMPAT_NETBSD32?  If so, I will adjust my fix.  (I
>built 67 different architectures, including all of the ones that the
>releng build cluster is building, and did not have any problems with
>aarch64 or any other.)

it seems that releng build was failed. 
http://releng.netbsd.org/builds/HEAD/202003050510Z/evbarm-aarch64.build.failed

Yes, optinos COMPAT_NETBSD32 is exists in sys/arch/evbarm/conf/GENERIC64.
but EXEC_AOUT is not supported. (yet?)

-- 
ryo shimizu

Re: CVS commit: src/sys/conf

[Paul Goyette]

On Thu, 5 Mar 2020, Paul Goyette wrote:


also aarch64 has no EXEC_AOUT.


Does aarch64 have COMPAT_NETBSD32?  If so, I will adjust my fix.  (I
built 67 different architectures, including all of the ones that the
releng build cluster is building, and did not have any problems with
aarch64 or any other.)


As near as I can tell, aarch64 sets MACHINE_CPU to "aarch64", so it
will not try to build COMPAT_NETBSD32 due to the following tests in
$SRC/sys/compat/netbsd32/netbsd32.mk

.if ${MACHINE_ARCH} == "x86_64" \
|| ${MACHINE_CPU} == "arm" \
|| ${MACHINE_ARCH} == "sparc64" \
|| (!empty(MACHINE_ARCH:Mmips64*) && !defined(BSD_MK_COMPAT_FILE))
COMPAT_USE_NETBSD32?=yes
.else
COMPAT_USE_NETBSD32?=no
.endif


Perhaps the  line should be changed to "aarch64" instead of "arm" ?


++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+

Re: CVS commit: src/sys/conf

[Paul Goyette]

On Thu, 5 Mar 2020, Ryo Shimizu wrote:




Module Name:src
Committed By:   pgoyette
Date:   Wed Mar  4 02:20:57 UTC 2020

Modified Files:
src/sys/conf: files

Log Message:
mips64 has compat_netbsd32 but cannot have exec_aout; all other users
of compat_netbsd32 need exec_aout

Addresses PR kern/55037.

XXX pullup-9


also aarch64 has no EXEC_AOUT.


Does aarch64 have COMPAT_NETBSD32?  If so, I will adjust my fix.  (I
built 67 different architectures, including all of the ones that the
releng build cluster is building, and did not have any problems with
aarch64 or any other.)


BTW, s/COMPAT_NETBSD64/COMPAT_NETBSD32/ in comment?


Ooops!  I just fixed that, and will add it to the pull-up requests.


++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+

re: CVS commit: src/sys/conf

[matthew green]

Ryo Shimizu writes:
> also aarch64 has no EXEC_AOUT.

that's a pity -- we do have 32 bit a.out binaries from the past ;-)


.mrg.

Re: CVS commit: src/sys/conf

[Ryo Shimizu]

>Module Name:   src
>Committed By:  pgoyette
>Date:  Wed Mar  4 02:20:57 UTC 2020
>
>Modified Files:
>   src/sys/conf: files
>
>Log Message:
>mips64 has compat_netbsd32 but cannot have exec_aout; all other users
>of compat_netbsd32 need exec_aout
>
>Addresses PR kern/55037.
>
>XXX pullup-9

also aarch64 has no EXEC_AOUT.
BTW, s/COMPAT_NETBSD64/COMPAT_NETBSD32/ in comment?

-- 
ryo shimizu

Re: CVS commit: src/sys/conf

[Paul Goyette]

On Wed, 4 Mar 2020, Paul Goyette wrote:


Module Name:src
Committed By:   pgoyette
Date:   Wed Mar  4 02:20:57 UTC 2020

Modified Files:
src/sys/conf: files

Log Message:
mips64 has compat_netbsd32 but cannot have exec_aout; all other users
of compat_netbsd32 need exec_aout

Addresses PR kern/55037.

XXX pullup-9


Also XXX pullup-8

Re: CVS commit: src/sys/conf

[Ryo ONODERA]

Hi,

chris...@zoulas.com (Christos Zoulas) writes:

> On Jun 18,  9:37pm, r...@tetera.org (Ryo ONODERA) wrote:
> -- Subject: Re: CVS commit: src/sys/conf
>
> | chris...@astron.com (Christos Zoulas) writes:
> | 
> | > Yes, the question becomes should be part of the default GENERIC build?
> | > I think not (like before).
> | 
> | I feel that chfs should be disabled by default.
> | And hopefully it should be documented that flash(4) is required
> | in filesystems.config or similar place.
>
> Yes, I agree. Can you supply a patch (documentation)?
> - there is no nand9 man page?

I will try to write the man page.

Thank you.

> christos

-- 
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

Re: CVS commit: src/sys/conf

[Christos Zoulas]

On Jun 18,  9:37pm, r...@tetera.org (Ryo ONODERA) wrote:
-- Subject: Re: CVS commit: src/sys/conf

| chris...@astron.com (Christos Zoulas) writes:
| 
| > Yes, the question becomes should be part of the default GENERIC build?
| > I think not (like before).
| 
| I feel that chfs should be disabled by default.
| And hopefully it should be documented that flash(4) is required
| in filesystems.config or similar place.

Yes, I agree. Can you supply a patch (documentation)?
- there is no nand9 man page?

christos

Re: CVS commit: src/sys/conf

[Ryo ONODERA]

chris...@astron.com (Christos Zoulas) writes:

> Yes, the question becomes should be part of the default GENERIC build?
> I think not (like before).

I feel that chfs should be disabled by default.
And hopefully it should be documented that flash(4) is required
in filesystems.config or similar place.

Thank you.

> christos
>

-- 
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

Re: CVS commit: src/sys/conf

[Christos Zoulas]

In article <87muigi0qk@brownie.elements.tetera.org>,
Ryo ONODERA   wrote:
>Hi,
>
>"Christos Zoulas"  writes:
>
>> Module Name: src
>> Committed By:christos
>> Date:Mon Jun 17 17:06:39 UTC 2019
>>
>> Modified Files:
>>  src/sys/conf: filesystems.config
>>
>> Log Message:
>> comment out CHFS to fix build issues
>
>I have the following lines in my local kernel config file
>and it fixes the build issue.
>
>+# Flash subsystem
>+flash* at flashbus?
>+
>+# NAND subsystem
>+nand* at nandbus?
>+
>+pseudo-device  nandemulator

Yes, the question becomes should be part of the default GENERIC build?
I think not (like before).

christos

Re: CVS commit: src/sys/conf

[Ryo ONODERA]

Hi,

"Christos Zoulas"  writes:

> Module Name:  src
> Committed By: christos
> Date: Mon Jun 17 17:06:39 UTC 2019
>
> Modified Files:
>   src/sys/conf: filesystems.config
>
> Log Message:
> comment out CHFS to fix build issues

I have the following lines in my local kernel config file
and it fixes the build issue.

+# Flash subsystem
+flash* at flashbus?
+
+# NAND subsystem
+nand* at nandbus?
+
+pseudo-device  nandemulator

dmesg -t:
nandemulator0: NAND emulator
nand0 at nandemulator0: ONFI NAND Flash
nand0: vendor: NETBSD, model: NANDEMULATOR
nand0: manufacturer id: 0x00 (Unknown), device id: 0x00
nand0: page size: 2048 bytes, spare size: 64 bytes, block size: 131072 bytes
nand0: LUN size: 256 blocks, LUNs: 1, total storage size: 32 MB
nand0: column cycles: 2, row cycles: 3, width: x16
flash0 at nand0: partition, size 32 MB, offset 0
flash0: erase size 128 KB, page size 2048 bytes, write size 2048 bytes

So it seems that chfs requires flash(4) device.

Thank you.

> To generate a diff of this commit:
> cvs rdiff -u -r1.12 -r1.13 src/sys/conf/filesystems.config
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
> Modified files:
>
> Index: src/sys/conf/filesystems.config
> diff -u src/sys/conf/filesystems.config:1.12 
> src/sys/conf/filesystems.config:1.13
> --- src/sys/conf/filesystems.config:1.12  Sun Jun 16 23:34:01 2019
> +++ src/sys/conf/filesystems.config   Mon Jun 17 13:06:39 2019
> @@ -1,10 +1,10 @@
> -# $NetBSD: filesystems.config,v 1.12 2019/06/17 03:34:01 christos Exp $
> +# $NetBSD: filesystems.config,v 1.13 2019/06/17 17:06:39 christos Exp $
>  #file-system ADOSFS  # AmigaDOS-compatible file system
>  #options APPLE_UFS   # Apple UFS support in FFS
>  #file-system AUTOFS  # Automounter Filesystem
>  #pseudo-device   autofs  # experimental - AUTOFS
>  file-system  CD9660  # ISO 9660 + Rock Ridge file system
> -file-system  CHFS# Chip File System
> +#file-system CHFS# Chip File System
>  file-system  CODA# Coda File System; also needs vcoda (below)
>  pseudo-devicevcoda   # coda minicache <-> venus comm.
>  file-system  EFS # Silicon Graphics Extent File System
>

-- 
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

Re: CVS commit: src/sys/conf

[Izumi Tsutsui]

> Module Name:  src
> Committed By: jnemeth
> Date: Tue Jan  1 01:52:40 UTC 2019
> 
> Modified Files:
>   src/sys/conf: copyright
> 
> Log Message:
> Welcome to 2019!

Could you please send pullup requests for netbsd-7 and netbsd-8?

Thanks,

---
Izumi Tsutsui

Re: CVS commit: src/sys/conf

[Christos Zoulas]

In article <20171220051944.ga22...@homeworld.netbsd.org>,
  wrote:
>On Sun, Dec 03, 2017 at 11:36:05AM -0500, Christos Zoulas wrote:
>> +@ln -sf ../$S/external/gpl2/dts/dist/arch/${_arch}/boot/dts dts/${_arch}
>
>this is causing unclear failures in autobuilds (seems to make a link in
>src and doesn't work with ro src?), but strangely I can't reproduce
>this.
>
>Could you have a look?

Yes, but it is not a failure since the command is -@ln

christos

Re: CVS commit: src/sys/conf

[maya]

On Sun, Dec 03, 2017 at 11:36:05AM -0500, Christos Zoulas wrote:
> + @ln -sf ../$S/external/gpl2/dts/dist/arch/${_arch}/boot/dts dts/${_arch}

this is causing unclear failures in autobuilds (seems to make a link in
src and doesn't work with ro src?), but strangely I can't reproduce
this.

Could you have a look?

Thanks.

Re: CVS commit: src/sys/conf

[Robert Elz]

Date:Mon, 9 Oct 2017 14:37:00 +0200
From:Joerg Sonnenberger 
Message-ID:  <20171009123700.gb7...@britannica.bec.de>

  | It would help if you wrote what problem you actually tried to fix :)

Oh ... sorry, but it is in the b5 build log for evbarm-earmv7hf at
http://releng.netbsd.org/b5reports/evbarm-earmv7hf/\
build/2017.10.08.21.33.38/build.log.tail

mvsata.o: In function `mvsata_edma_setup_crqb_gen2e':
mvsata.c:(.text+0x1fb4): undefined reference to `satafis_rhd_construct_bio'

kre

Re: CVS commit: src/sys/conf

[Christos Zoulas]

In article <20170108175946.gb5...@britannica.bec.de>,
Joerg Sonnenberger   wrote:
>On Sun, Jan 08, 2017 at 12:02:08AM -0500, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Sun Jan  8 05:02:08 UTC 2017
>> 
>> Modified Files:
>>  src/sys/conf: Makefile.kern.inc
>> 
>> Log Message:
>> Add COPTS for xhci.c, since the do_command_locked causes a spurious stack
>> proector warning.
>
>Please restrict that to GCC.

We apparently have a /usr/src/sys/conf/ssp.mk; perhaps look if there are
any others that are not needed for !GCC.

christos

Re: CVS commit: src/sys/conf

[Joerg Sonnenberger]

On Sun, Jan 08, 2017 at 12:02:08AM -0500, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Sun Jan  8 05:02:08 UTC 2017
> 
> Modified Files:
>   src/sys/conf: Makefile.kern.inc
> 
> Log Message:
> Add COPTS for xhci.c, since the do_command_locked causes a spurious stack
> proector warning.

Please restrict that to GCC.

Joerg

Re: CVS commit: src/sys/conf

[John Nemeth]

On Dec 31,  3:23pm, "matthew green" wrote:
} 
} Module Name:  src
} Committed By: mrg
} Date: Thu Dec 31 15:23:07 UTC 2015
} 
} Modified Files:
}   src/sys/conf: copyright
} 
} Log Message:
} WELCOME 2016!

 Bad boy!  That is serious cheating...  Not supposed to do it
until midnight UTC!

}-- End of excerpt from "matthew green"

Re: CVS commit: src/sys/conf

[Joerg Sonnenberger]

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.

Joerg

Re: CVS commit: src/sys/conf

[David Holland]

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 this matters why, in the absence of e.g. profile-driven function
layout?

(although it might be interesting to see if running ${OBJS} through
lorder/tsort improves the output kernel)

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

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

[Masao Uebayashi]

On Thu, Sep 3, 2015 at 11:32 PM, Joerg Sonnenberger
 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/sys/conf

[Masao Uebayashi]

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

re: CVS commit: src/sys/conf

[matthew green]

"Masao Uebayashi" writes:
> Module Name:  src
> Committed By: uebayasi
> Date: Thu Sep  3 01:30:18 UTC 2015
> 
> Modified Files:
>   src/sys/conf: Makefile.kern.inc
> 
> Log Message:
> Stop ordering objects alphabetically now that I am sure I can fix fallouts.

what's this about?  why are you commiting something that you
believe has fallout coming.


.mrg.

Re: CVS commit: src/sys/conf

[David Holland]

On Thu, Sep 03, 2015 at 01:30:18AM +, Masao Uebayashi wrote:
 > Module Name: src
 > Committed By:uebayasi
 > Date:Thu Sep  3 01:30:18 UTC 2015
 > 
 > Modified Files:
 >  src/sys/conf: Makefile.kern.inc
 > 
 > Log Message:
 > Stop ordering objects alphabetically now that I am sure I can fix fallouts.

Why change this? It is useful to be able to estimate how far along
your build is by what's being built.

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

re: CVS commit: src/sys/conf

[matthew green]

"Masao Uebayashi" writes:
> Module Name:  src
> Committed By: uebayasi
> Date: Thu Sep  3 04:17:55 UTC 2015
> 
> Modified Files:
>   src/sys/conf: Makefile.kern.inc
> 
> Log Message:
> Rename ${COMPILE.c} to ${KCOMPILE.c} to avoid potential conflicts with those
> in sys.mk.  Define .go/.po suffix rules.

isn't the goal to *replace* what sys.mk has?


.mrg.

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

[Izumi Tsutsui]

uebayasi@ wrote:

  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'm not sure about your goal, but anyway it should be proposed
and discussed proper lists before commit.

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.

---
Izumi Tsutsui

Re: CVS commit: src/sys/conf

[Christos Zoulas]

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

christos

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

[Christos Zoulas]

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.

christos

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

[Izumi Tsutsui]

uebayasi@ wrote:

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

The review is held not for you but other developers and users.

http://www.netbsd.org/developers/commit-guidelines.html
 Obvious fixes can be committed without any prior discussion or review.
 (The definition of obvious in the GCC Project is: could not possibly
 cause anyone to object. We adopt this definition here)
 
 All other (i. e. non-obvious) fixes should have a review.

It looks there are so many blames for your recent changes.

---
Izumi Tsutsui

Re: CVS commit: src/sys/conf

[Christos Zoulas]

On Nov 13, 10:49pm, uebay...@gmail.com (Masao Uebayashi) wrote:
-- Subject: Re: CVS commit: src/sys/conf

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

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.

christos

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

[Christos Zoulas]

In article 
CADbF7edbi1NG5O2LZqoh42zoAMvdEYoMF3bLyr=Pynu0PZx9=q...@mail.gmail.com,
Masao Uebayashi  uebay...@gmail.com wrote:
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.

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

christos

Re: CVS commit: src/sys/conf

[Christos Zoulas]

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?

christos

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

[Christos Zoulas]

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?

christos

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

[John Nemeth]

On Nov 13, 10:28pm, Masao Uebayashi wrote:
} 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:
} 
}  | 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.

 It has nothing to do with whether or not you have questions.
Others have questions.  It is customary, and in many cases, required
to discuss things before doing massive rototills that affect
important parts of the system.  Also, when multiple people object
to something you don't get to just ignore the objections.  They
need to be addressed properly.  Not to mention that if you were to
explain what you are doing, what you're plans and goals are, some
of the objections might go away.

}-- End of excerpt from Masao Uebayashi

Re: CVS commit: src/sys/conf

[Izumi Tsutsui]

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

[Christos Zoulas]

In article 141112200516.m0117...@mirage.ceres.dti.ne.jp,
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?

I grepped -R and used nxr but found nothing. I did not think
of using cvs log.

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

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)

Anyway, it should be trivial to amend to work again for shark, and I'll
do it.

christos

Re: CVS commit: src/sys/conf

[Izumi Tsutsui]

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

---
Izumi Tsutsui

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

[Christos Zoulas]

Not to worry, I fixed it already. And I will improve it further.

christos 


 On Nov 12, 2014, at 6:51 AM, Masao Uebayashi uebay...@gmail.com wrote:
 
 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
 sanitizer.log

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

[David Holland]

On Fri, Sep 19, 2014 at 09:05:23AM +, Matt Thomas wrote:
  Added Files:
   src/sys/conf: filesystems.config
  
  Log Message:
  include for configs which includes all file-systems and any dependent
  pseudo-devices

Was this discussed anywhere?

I'm not saying it's a bad idea; I'm just not convinced this is how we
want to do it.

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

Re: CVS commit: src/sys/conf

[Matt Thomas]

On Sep 26, 2014, at 12:32 AM, David Holland dholland-sourcechan...@netbsd.org 
wrote:

 On Fri, Sep 19, 2014 at 09:05:23AM +, Matt Thomas wrote:
 Added Files:
  src/sys/conf: filesystems.config
 
 Log Message:
 include for configs which includes all file-systems and any dependent
 pseudo-devices
 
 Was this discussed anywhere?

No.  But follows in the of dev/usb/usbdevices.config

 I'm not saying it's a bad idea; I'm just not convinced this is how we
 want to do it.

I haven't changed any configs to use it.  Rather than cutting and pasting
the same list in every kernel, sometime that list is incomplete, I think
it's better to include a standard list and then no ... disable ones you
don't want.

Re: CVS commit: src/sys/conf

[Joerg Sonnenberger]

On Sun, Aug 24, 2014 at 04:42:46PM +, Matt Thomas wrote:
 Module Name:  src
 Committed By: matt
 Date: Sun Aug 24 16:42:46 UTC 2014
 
 Modified Files:
   src/sys/conf: files
 
 Log Message:
 Add entry for kern/kern_ksyms_buf.c

This is wrong, the file is explicitly compiled as part of the kernel
linking step and must *not* appear separately on the object list.

Joerg

Re: CVS commit: src/sys/conf

[Jeff Rizzo]

On 8/24/14 10:54 AM, Joerg Sonnenberger wrote:

On Sun, Aug 24, 2014 at 04:42:46PM +, Matt Thomas wrote:

Module Name:src
Committed By:   matt
Date:   Sun Aug 24 16:42:46 UTC 2014

Modified Files:
src/sys/conf: files

Log Message:
Add entry for kern/kern_ksyms_buf.c

This is wrong, the file is explicitly compiled as part of the kernel
linking step and must *not* appear separately on the object list.

Joerg


...except that, without this, many arm kernel builds (BEAGLEBONE, 
MIRABOX, probably others) fail with:


kern_ksyms.o: In function `ksyms_init':
/home/riz/src/sys/kern/kern_ksyms.c:224: undefined reference to `db_symtab'
/home/riz/src/sys/kern/kern_ksyms.c:224: undefined reference to `db_symtab'
/home/riz/src/sys/kern/kern_ksyms.c:225: undefined reference to 
`db_symtabsize'
/home/riz/src/sys/kern/kern_ksyms.c:225: undefined reference to 
`db_symtabsize'

Re: CVS commit: src/sys/conf

[Christoph Egger]

On 07/04/11 15:00, matthew green wrote:

Module Name:src
Committed By:   mrg
Date:   Mon Jul  4 13:00:19 UTC 2011

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

Log Message:
apply some -Wno-foo to 3 files that are non-trivial to solve, for GCC 4.5.


To generate a diff of this commit:
cvs rdiff -u -r1.140 -r1.141 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.




Modified files:

Index: src/sys/conf/Makefile.kern.inc
diff -u src/sys/conf/Makefile.kern.inc:1.140 
src/sys/conf/Makefile.kern.inc:1.141
--- src/sys/conf/Makefile.kern.inc:1.140Mon Jun 20 06:52:38 2011
+++ src/sys/conf/Makefile.kern.inc  Mon Jul  4 13:00:19 2011
@@ -1,4 +1,4 @@
-#  $NetBSD: Makefile.kern.inc,v 1.140 2011/06/20 06:52:38 mrg Exp $
+#  $NetBSD: Makefile.kern.inc,v 1.141 2011/07/04 13:00:19 mrg Exp $
  #
  # This file contains common `MI' targets and definitions and it is included
  # at the bottom of each `MD' ${MACHINE}/conf/Makefile.${MACHINE}.
@@ -510,12 +510,19 @@
  uvm/uvm_pager.c dev/ic/aic7xxx.c dev/ic/aic79xx.c arch/xen/i386/gdt.c \
  dev/ofw/ofw_subr.c

-. if defined(HAVE_GCC) || defined(HAVE_PCC)
+.if defined(HAVE_GCC) || defined(HAVE_PCC)


Please revert this part.

Christoph


  .for __varstack in ${VARSTACK}
  COPTS.${__varstack:T} += -Wno-stack-protector
  .endfor
  .endif

+# XXX ugly ugly to fix
+.if defined(HAVE_GCC)  ${HAVE_GCC} == 45
+CWARNFLAGS.tulip.c+=   -Wno-array-bounds
+CWARNFLAGS.radeonfb.c+=-Wno-cast-qual
+CWARNFLAGS.dbcool.c+=  -Wno-cast-qual
+.endif
+
  AFLAGS+=  ${AOPTS.${.IMPSRC:T}}
  CFLAGS+=  ${COPTS.${.IMPSRC:T}} ${CPUFLAGS.${.IMPSRC:T}}
  CPPFLAGS+=${CPPFLAGS.${.IMPSRC:T}}

Re: CVS commit: src/sys/conf

[David Holland]

On Mon, Jul 04, 2011 at 03:05:20PM +0200, Christoph Egger wrote:
  -. if defined(HAVE_GCC) || defined(HAVE_PCC)
  +.if defined(HAVE_GCC) || defined(HAVE_PCC)
  
  Please revert this part.

uh why?

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

Re: CVS commit: src/sys/conf

[Christoph Egger]

On 23.02.10 23:21, Darran Hunt wrote:
 Module Name:  src
 Committed By: darran
 Date: Tue Feb 23 22:21:25 UTC 2010
 
 Modified Files:
   src/sys/conf: files

Log Message ?

 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.976 -r1.977 src/sys/conf/files
 
 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

[Darran Hunt]

Missed the log message, fixed with cvs admin -m.

Log message now reads:

DTrace: remove kern_dtrace.c, no longer used

Darran.

On 24/02/2010, at 11:24 AM, Christoph Egger wrote:


On 23.02.10 23:21, Darran Hunt wrote:

Module Name:src
Committed By:   darran
Date:   Tue Feb 23 22:21:25 UTC 2010

Modified Files:
src/sys/conf: files


Log Message ?




To generate a diff of this commit:
cvs rdiff -u -r1.976 -r1.977 src/sys/conf/files

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

[Christoph Egger]

Thanks.

Christoph


On 23.02.10 23:26, Darran Hunt wrote:
 Missed the log message, fixed with cvs admin -m.
 
 Log message now reads:
 
 DTrace: remove kern_dtrace.c, no longer used
 
 Darran.
 
 On 24/02/2010, at 11:24 AM, Christoph Egger wrote:
 
 On 23.02.10 23:21, Darran Hunt wrote:
 Module Name:src
 Committed By:darran
 Date:Tue Feb 23 22:21:25 UTC 2010

 Modified Files:
 src/sys/conf: files

 Log Message ?



 To generate a diff of this commit:
 cvs rdiff -u -r1.976 -r1.977 src/sys/conf/files

 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

[John Nemeth]

On May 23,  6:34pm, John Nemeth wrote:
} 
} Module Name:  src
} Committed By: jnemeth
} Date: Thu Dec 31 23:59:02 UTC 2009

 Bah!  One minute early, got confused.  Mea Culpa.  For penance I
shall remove myself from the race for the next two years.

} Modified Files:
}   src/sys/conf: copyright
} 
} Log Message:
} Welcome to 2010.
} 
} Don't forget to update copyright notices when you add new code.
} 
}-- End of excerpt from John Nemeth

Re: CVS commit: src/sys/conf

[M. Warner Losh]

In message: 201001010039.o010dvjh028...@vtn1.victoria.tc.ca
jnem...@victoria.tc.ca (John Nemeth) writes:
: On May 23,  6:34pm, John Nemeth wrote:
: } 
: } Module Name:src
: } Committed By:   jnemeth
: } Date:   Thu Dec 31 23:59:02 UTC 2009
: 
:  Bah!  One minute early, got confused.  Mea Culpa.  For penance I
: shall remove myself from the race for the next two years.

Generally, copyright in the last half of the year goes to the next
year anyway, so a few seconds is no big deal :)

Warner

Re: CVS commit: src/sys/conf

[David Holland]

On Sun, Nov 15, 2009 at 01:39:00PM +, David Laight wrote:
  Avoids problems with awk processing floating point numbers when LC_NUMERIC
  give a decimal point of ','.

Isn't it a bug in awk for the input language to be broken by locale
settings?

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

Re: CVS commit: src/sys/conf

[David Laight]

On Sun, Nov 15, 2009 at 08:10:20PM +, David Holland wrote:
 On Sun, Nov 15, 2009 at 01:39:00PM +, David Laight wrote:
   Avoids problems with awk processing floating point numbers when LC_NUMERIC
   give a decimal point of ','.
 
 Isn't it a bug in awk for the input language to be broken by locale
 settings?

yes, see PR/42320


David

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

Re: CVS commit: src/sys/conf

[Quentin Garnier]

On Wed, May 06, 2009 at 01:42:06PM +1000, matthew green wrote:
 
Module Name:   src
Committed By:  cube
Date:  Wed May  6 02:52:13 UTC 2009

Modified Files:
   src/sys/conf: files

Log Message:
Bump required config(1) version after files.drm changes [hi mrg!].
 
 
 so, this is because i'm using the new feature you added, for the
 first time in our tree?

Yes.  I could have added the line only to files.drm but doing this can
have side-effects when people forget about it and new versions of the
config syntax come along.

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


pgpWYOFBJdPUr.pgp
Description: PGP signature