Re: CVS commit: src/lib/libc
On Wed, Nov 07, 2018 at 01:34:18PM +1100, matthew green wrote: > "Maya Rashish" writes: > > Module Name:src > > Committed By: maya > > Date: Mon Nov 5 04:08:40 UTC 2018 > > > > Modified Files: > > src/lib/libc: shlib_version > > > > Log Message: > > Suggest to remove lfs_ stubs on a major bump. > > they're deprecated, ioctl is used instead. > > please revert this, or, convince everyone it's OK to remove the > old support entirely. > > either the support is useful and the libc syscall entry points > should remain (debateable, seems unlikely), or, the whole lot > is not worth keeping (yay!). > > thanks! I can point to https://gnats.netbsd.org/50131 for a well-reasoned lengthy discussion of the various points. Seems to say "just kill it now", but I usually read that interpretation of things even when it isn't the author's intention.
Re: CVS commit: src/sys/sys
On 07.11.2018 00:55, m...@netbsd.org wrote: > On Tue, Nov 06, 2018 at 11:15:11PM +0300, Valery Ushakov wrote: >> On Tue, Nov 06, 2018 at 16:26:44 +, Maya Rashish wrote: >> >>> Module Name:src >>> Committed By: maya >>> Date: Tue Nov 6 16:26:44 UTC 2018 >>> >>> Modified Files: >>> src/sys/sys: stdint.h types.h >>> >>> Log Message: >>> Guard from type redefinition (needed by pre-C11 C) in a safer way. >>> >>> The existing way causes problems like: >>> https://mail-index.netbsd.org/tech-pkg/2018/10/25/msg020395.html >>> https://mail-index.netbsd.org/tech-userlevel/2018/09/08/msg011381.html >> >> I would argue that the first example is, if not outright wrong, then >> at the very minimum unhygienic, as it doesn't use the same >> preprocessor nesting for the definition of the name and the use of the >> name, i.e. it incorrectly assumes that the function will be named >> "something_uint32_t". >> >> Also your change breaks redefining intN_t types with the preprocessor. >> E.g. >> >> #define uint32_t unsigned long long >> #include >> >> is now broken with your change. >> >> -uwe > > This fails with glibc too. I don't expect to find real users for that > behaviour... > intN_t is C99, C++11, POSIX/UNIX standard Our previous behavior was barely compliant and not understood by some of toolchain developers (it was discussed by LLVM developers just few days ago) and they prompted me/us to switch it. Some of new UBSan tests broke only on NetBSD because we were the only tested OS that mangled the intN_t names and we had to deteriorate the tests because of unrolling intN_t types to anything. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/lib/libc
On 07.11.2018 03:34, matthew green wrote: > "Maya Rashish" writes: >> Module Name: src >> Committed By:maya >> Date:Mon Nov 5 04:08:40 UTC 2018 >> >> Modified Files: >> src/lib/libc: shlib_version >> >> Log Message: >> Suggest to remove lfs_ stubs on a major bump. >> they're deprecated, ioctl is used instead. > > please revert this, or, convince everyone it's OK to remove the > old support entirely. > I've found it myself quite odd that we use(d) generic syscall entry table for particular filesystem calls. ioctl(2) looks like a better match. > either the support is useful and the libc syscall entry points > should remain (debateable, seems unlikely), or, the whole lot > is not worth keeping (yay!). > What else is not worth keeping? > thanks! > > > .mrg. > signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/sys/sys
On Nov 6, 4:26pm, "Maya Rashish" wrote: } } Module Name: src } Committed By: maya } Date: Tue Nov 6 16:26:44 UTC 2018 } } Modified Files: } src/sys/sys: stdint.h types.h } } Log Message: } Guard from type redefinition (needed by pre-C11 C) in a safer way. Why was this committed with only one day of discussion? When you post something for discussion, allowing only one day is extremely inappropriate! It is appropriate to state when you intend to make the commit which be an ABSOLUTE MINIMUM of one week. Please revert and allow for proper discussion. }-- End of excerpt from "Maya Rashish"
re: CVS commit: src/lib/libc
"Maya Rashish" writes: > Module Name: src > Committed By: maya > Date: Mon Nov 5 04:08:40 UTC 2018 > > Modified Files: > src/lib/libc: shlib_version > > Log Message: > Suggest to remove lfs_ stubs on a major bump. > they're deprecated, ioctl is used instead. please revert this, or, convince everyone it's OK to remove the old support entirely. either the support is useful and the libc syscall entry points should remain (debateable, seems unlikely), or, the whole lot is not worth keeping (yay!). thanks! .mrg.
Re: CVS commit: src/sys/sys
On Tue, Nov 06, 2018 at 11:15:11PM +0300, Valery Ushakov wrote: > On Tue, Nov 06, 2018 at 16:26:44 +, Maya Rashish wrote: > > > Module Name:src > > Committed By: maya > > Date: Tue Nov 6 16:26:44 UTC 2018 > > > > Modified Files: > > src/sys/sys: stdint.h types.h > > > > Log Message: > > Guard from type redefinition (needed by pre-C11 C) in a safer way. > > > > The existing way causes problems like: > > https://mail-index.netbsd.org/tech-pkg/2018/10/25/msg020395.html > > https://mail-index.netbsd.org/tech-userlevel/2018/09/08/msg011381.html > > I would argue that the first example is, if not outright wrong, then > at the very minimum unhygienic, as it doesn't use the same > preprocessor nesting for the definition of the name and the use of the > name, i.e. it incorrectly assumes that the function will be named > "something_uint32_t". > > Also your change breaks redefining intN_t types with the preprocessor. > E.g. > > #define uint32_t unsigned long long > #include > > is now broken with your change. > > -uwe This fails with glibc too. I don't expect to find real users for that behaviour...
Re: CVS commit: src/sys/sys
On Tue, Nov 06, 2018 at 16:26:44 +, Maya Rashish wrote: > Module Name: src > Committed By: maya > Date: Tue Nov 6 16:26:44 UTC 2018 > > Modified Files: > src/sys/sys: stdint.h types.h > > Log Message: > Guard from type redefinition (needed by pre-C11 C) in a safer way. > > The existing way causes problems like: > https://mail-index.netbsd.org/tech-pkg/2018/10/25/msg020395.html > https://mail-index.netbsd.org/tech-userlevel/2018/09/08/msg011381.html I would argue that the first example is, if not outright wrong, then at the very minimum unhygienic, as it doesn't use the same preprocessor nesting for the definition of the name and the use of the name, i.e. it incorrectly assumes that the function will be named "something_uint32_t". Also your change breaks redefining intN_t types with the preprocessor. E.g. #define uint32_t unsigned long long #include is now broken with your change. -uwe
Re: CVS commit: src/etc/etc.evbarm
On Mon, 05 Nov 2018 22:37:31 +0100, Nick Hudson wrote:
>
> On 05/11/2018 20:45, Herbert J. Skuhra wrote:
> > On Mon, Nov 05, 2018 at 09:11:02AM -0500, Greg Troxel wrote:
> >> "Herbert J. Skuhra" writes:
> >>
> >>> On Sun, 04 Nov 2018 22:41:12 +0100, "Nick Hudson" wrote:
>
> Module Name: src
> Committed By:skrll
> Date:Sun Nov 4 21:41:12 UTC 2018
>
> Modified Files:
> src/etc/etc.evbarm: Makefile.inc
>
> Log Message:
> Only add GENERIC to earmv6 and earmv7 builds
> >>>
> >>> This change obviously breaks "./build.sh -m evbarm -a earmv7hf -U
> >>> release".
>
> fixed. (I hope)
>
> > My Raspberry boots, grows /, reboots and then panics. This happens for
> > several days now. :-(
>
> What's the panic message and backtrace?
[ 13.5062763] Fatal kernel mode prefetch abort at 0x
[ 13.5062763] trapframe: 0xb9b45ef0, spsr=a0090013
[ 13.5062763] r0 =742871c8, r1 =f2a00e00, r2 =b9b45fb0, r3 =0010
[ 13.5062763] r4 =80799648, r5 =, r6 =b9b45fb0, r7 =742871c8
[ 13.5062763] r8 =0010, r9 =f2a00e00, r10=ba87a920, r11=b9b45fac
[ 13.5062763] r12=b9b45f40, ssp=b9b45f40, slr=80023890, pc =
Stopped in pid 191.1 (syslogd) at 0: address 0x0 is invalid
andeq r0, r0, r0
db{2}> bt
0xb9b45fac: netbsd:undefinedinstruction+0xc
If I disable syslogd I get a similar error with makemandb.
--
Herbert
