Re: CVS commit: src/lib/libc/stdlib
Module Name: src Committed By: christos Date: Wed Jan 8 02:15:42 UTC 2014 Modified Files: src/lib/libc/stdlib: Makefile.inc ptsname.3 pty.c Log Message: add ptsname_r Needs libc minor bump? --- Izumi Tsutsui
re: CVS commit: src/sys/arch/sparc64
Module Name: src Committed By: palle Date: Tue Jan 7 20:11:35 UTC 2014 Modified Files: src/sys/arch/sparc64/include: cpu.h sparc64.h src/sys/arch/sparc64/sparc64: cpu.c genassym.cf locore.s ofw_machdep.c pmap.c Log Message: sun4v: trap table setup - currently populated with dummy entries which will be properly implemented later - parts from OpenBSD - OK martin@ hi. thanks for working on this. looks pretty good. there are a couple of minor things i'd like seen cleaned up here: + #ifdef SUN4V + /* MMU Fault Status Area. Will be initialized to the physical + address of the bottom of the interrupt stack */ + paddr_t ci_mmfsa; + #endif in struct cpu_info -- please make it always present, so that struct cpu_info doesn't change size/placement/etc. this also makes it more possible to have modules shared between sun4u and sun4v (we just have to make sure everything is accessed via a function if it isn't already.) + if ( CPU_ISSUN4V ) please remove the extra spaces around the macro in a couple of places. thanks! .mrg.
Re: CVS commit: src/lib/libc/stdlib
On Jan 8, 7:25pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/lib/libc/stdlib | Module Name:src | Committed By: christos | Date: Wed Jan 8 02:15:42 UTC 2014 | | Modified Files: | src/lib/libc/stdlib: Makefile.inc ptsname.3 pty.c | | Log Message: | add ptsname_r | | Needs libc minor bump? I thought about it, but really ~nothing uses it. christos
Re: CVS commit: src/lib/libc/stdlib
| Module Name: src | Committed By: christos | Date: Wed Jan 8 02:15:42 UTC 2014 | | Modified Files: |src/lib/libc/stdlib: Makefile.inc ptsname.3 pty.c | | Log Message: | add ptsname_r | | Needs libc minor bump? I thought about it, but really ~nothing uses it. Then why do you add it if it will be never used? --- Izumi Tsutsui
re: CVS commit: src/lib/libc/stdlib
| Module Name: src | Committed By: christos | Date: Wed Jan 8 02:15:42 UTC 2014 | | Modified Files: |src/lib/libc/stdlib: Makefile.inc ptsname.3 pty.c | | Log Message: | add ptsname_r | | Needs libc minor bump? I thought about it, but really ~nothing uses it. i don't see why this matters. libc grew a symbol? it needs a minor bump. .rg.
Re: CVS commit: src/lib/libc/stdlib
On Jan 8, 8:52pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/lib/libc/stdlib | Then why do you add it if it will be never used? It will be never used != is not currently being used. I was reading the linux man page and it seemed easy to implement. christos
Re: CVS commit: src/lib/libc/stdlib
On Jan 8, 8:52pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/lib/libc/stdlib | Then why do you add it if it will be never used? It will be never used != is not currently being used. Then you must bump minor otherwise future binaries will fail silently. --- Izumi Tsutusi
Re: CVS commit: src/sys/fs/tmpfs
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote: On Jan 8, 2014, at 5:11 PM, pedro martelletto pe...@netbsd.org wrote: Module Name:src Committed By: pedro Date: Wed Jan 8 16:11:04 UTC 2014 Modified Files: src/sys/fs/tmpfs: tmpfs_subr.c Log Message: Allocate direntp on the stack in tmpfs_dir_getdents(), thus saving calls to kmem_zalloc() and kmem_free(); OK rmind@. From OpenBSD. Is it really a good idea to allocate 528 bytes on the kernel stack? File systems nest and already use much stack space. It is harmless in this case since we get a few or more pages for the stack. Looks better to use a pool_cache. It is worth to create a separate pool_cache(9) only if the allocations can potentially be very intensive. -- Mindaugas
Re: CVS commit: src/sys/fs/tmpfs
On Jan 8, 2014, at 5:11 PM, pedro martelletto pe...@netbsd.org wrote: Module Name: src Committed By: pedro Date: Wed Jan 8 16:11:04 UTC 2014 Modified Files: src/sys/fs/tmpfs: tmpfs_subr.c Log Message: Allocate direntp on the stack in tmpfs_dir_getdents(), thus saving calls to kmem_zalloc() and kmem_free(); OK rmind@. From OpenBSD. Is it really a good idea to allocate 528 bytes on the kernel stack? File systems nest and already use much stack space. Looks better to use a pool_cache. -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Re: CVS commit: src/etc
Alan Barrett a...@netbsd.org writes: If you have restrict default nopeer noquery (the uncommented line in my commit), then time service will still work, but the configured servers will be denied query permission. If you use restrict default ignore, then time service does not work. I have found the ntp restrict situation very confusing. I think that all we need to do is something like: restrict default noquery nomodify notrap restrict -6 default noquery nomodify notrap restrict 127.0.0.1 restrict -6 ::1 and leave it at that. The real issue is amplification via monlist. I don't understand the apparent leap from that to almost completely firewalling ntp. Why do you think the configured servers should be given query permission? Is that a sense of courtesy to the pool operators that they should be able to run ntpdc -c monlist and ntpq -p at machines that are syncing from them? pgpfSjBwi1PQ5.pgp Description: PGP signature
