Re: CVS commit: src/etc
Alan Barrett 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
Re: CVS commit: src/sys/fs/tmpfs
On Jan 8, 2014, at 5:11 PM, pedro martelletto 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/sys/fs/tmpfs
"J. Hannken-Illjes" wrote: > On Jan 8, 2014, at 5:11 PM, pedro martelletto 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/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/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
> | > 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
> | > 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
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/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
> 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
