Re: CVS commit: src/external/gpl3
On Tue, 11 Aug 2015, David Laight wrote: The system should probably clean 'turds' from both /tmp and /var/tmp. That would be surprising, at least to me. I rely on /var/tmp/vi.recover being persistent, and I often use /var/tmp as a place to stash work in progress that should survive a reboot. --apb (Alan Barrett)
Re: CVS commit: src/share/misc
On Fri, 24 Apr 2015, Taylor R Campbell wrote: Modified Files: src/share/misc: acronyms acronyms-o.real Log Message: Per discussion with board@, remove inappropriate, hostile acronyms. Thank you. --apb (Alan Barrett)
Re: CVS commit: src/share/misc
On Sat, 25 Apr 2015, rod...@netbsd.org wrote: I'm responding to the recent posts ITT, because it seems there's some misunderstanding: I had no idea what ITT meant, until I looked it up. (ITT = in this thread, apparently). 1) What has been committed is no more offensive than the existing material in wtf and fortune. Please, review fortune's data files if any doubts exist; 2) wtf and fortune have existed in source since $TIME without any uproar; 3) There aren't any rules documenting appending entries to either; 4) We don't tend to make up rules as we go along committing; We have a rule or at least a convention that things that are likely to be controversial should be discussed first. If you don't realise that something is controversial, and commit without discussion, then the appropriate response is to engage in discussion as soon as you learn that the issue was controversial. Continuing without discussion is not appropriate. I think that NetBSD's acronyms file should be for acronyms that ordinary people are likely to encounter in ordinary situations; not for acronyms used in some small subculture. --apb (Alan Barrett)
Re: CVS commit: src/external/cddl/osnet
On Sat, 11 Apr 2015, Taylor R Campbell wrote: Date: Sat, 11 Apr 2015 15:12:01 +1000 from: matthew green m...@eterna.com.au Taylor R Campbell writes: When modifying, double-check that libnvpair.so defines no xdr_* symbols, only _solaris_xdr_*. (XXX Put this note somewhere...) somewhere == doc/HACKS. It's not really a hack, though. This is just the way we have to make colliding symbols not collide. What we don't have is a way to automate it so you don't have to write `#define xdr_foo _solaris_xdr_foo', or so the toolchain will notify you if you forgot to. You could write a test that uses nm|awk to check that all externally visible symbols have some desired prefix. --apb (Alan Barrett)
Re: CVS commit: src/lib/libc/time
On Mon, 06 Apr 2015, Brian Ginsbach wrote: Module Name:src Committed By: ginsbach Date: Mon Apr 6 14:38:22 UTC 2015 Modified Files: src/lib/libc/time: strptime.3 strptime.c Log Message: Add UTC as a synonym for GMT (%Z). [from FreeBSD] The %z format (which is distinct from %Z) already accepts GMT and UT. If we are going to accept UTC as well, which I think is a good idea, then please allow both %z and %Z to accept all three of UT, UTC, and GMT. --apb (Alan Barrett)
Re: CVS commit: src/usr.sbin/service
On Wed, 01 Apr 2015, Adrian Steinmann wrote: Please could this be fixed to use shell quoting in a safe way. OK, if that'll unstall the pullup-7. I don't know. Are you implying that the /etc/rc.d/ system supports space in filenames? No, I am implying that somebody could create a file whose name contains a space. Whether or not it's supported is separate from whether or not the service(8) script does strange things when it happens. --apb (Alan Barrett)
Re: CVS commit: src
On Fri, 02 Jan 2015, Christos Zoulas wrote: Log Message: Implement DIOCGMEDIASIZE and DIOCGSECTORSIZE from FreeBSD. This needs compat32 handling, at least for the u_int arg to DIOCGSECTORSIZE. Why not make it a fixed size, like uint32_t, so compat32 handling will not be needed? I think it was made u_int to match previous art by FreeBSD. Can you please explain why it needs compat32 handling? Sorry, it doesn't need compat32 handling, because all existing NetBSD platforms have 32-bit int, and all exiting NetBSD platforms have 64-bit off_t. --apb (Alan Barrett)
Re: CVS commit: src
On Mon, 29 Dec 2014, Michael van Elst wrote: Log Message: Implement DIOCGMEDIASIZE and DIOCGSECTORSIZE from FreeBSD. This needs compat32 handling, at least for the u_int arg to DIOCGSECTORSIZE. Why not make it a fixed size, like uint32_t, so compat32 handling will not be needed? --apb (Alan Barrett)
Re: CVS commit: src
On Mon, 17 Nov 2014, Masao Uebayashi wrote: How about adding a new make variable CONFIGOPTS, which is passed to config(1)? This name is similar to COPTS and works similarly too. Yes, that could work. --apb (Alan Barrett)
Re: CVS commit: src
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/usr.bin/config
On Thu, 30 Oct 2014, Taylor R Campbell wrote: It seems to me that while depending on ordering for definitions, files, c., may be no good, for selections the language of include GENERIC no options DIAGNOSTIC no agp* is still valuable. I don't mind how it's implemented, but my main concern is that I want an example like the above to work. I want it to mean: my kernel should be based on GENERIC with some changes; whether or not options DIAGNOSTIC is present in GENERIC, my kernel should not have options DIAGNOSTIC; and whether or not anything related to agp is present in GENERIC, my kernel should not have any agp devices (and should not have anything that depends on agp). I do not want error messages like options DIAGNOSTIC was already off, so you are not allowed to try to turn it off again or there were no agp devices, so you are not allowed to try to remove agp devices. So config(1) ought to choose whatever is the last yes/no answer for a selection in order to decide what things are really enabled or disabled, and then process dependencies recursively from there, rather than incrementally processing dependencies as the parser makes progress. That sounds as though it would do what I want. --apb (Alan Barrett)
Re: CVS commit: src/usr.bin/config
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. --apb (Alan Barrett)
Re: CVS commit: othersrc/external/bsd/multigest
On Tue, 28 Oct 2014, Alistair Crooks wrote:
+.ifndef PRINTOBJDIR
+PRINTOBJDIR=${MAKE} -V .OBJDIR
+.endif
At least for NetBSD's make(1), you need ${MAKE} -V '${.OBJDIR}' to
get the recursively-expanded value of .OBJDIR. ${MAKE} -V .OBJDIR
would print the unexpanded value.
Oh, you'd better fix it in NetBSD's bsd.own.mk then, which was where I took
the definition above from.
It probably works because .OBJDIR is magic, and is unlikely to need
recursive expansion.
--apb (Alan Barrett)
Re: CVS commit: othersrc/external/bsd/multigest
On Tue, 28 Oct 2014, Alistair G. Crooks wrote:
Modified Files:
othersrc/external/bsd/multigest/bin: Makefile
othersrc/external/bsd/multigest/lib: Makefile
+.ifndef PRINTOBJDIR
+PRINTOBJDIR=${MAKE} -V .OBJDIR
+.endif
At least for NetBSD's make(1), you need ${MAKE} -V '${.OBJDIR}' to
get the recursively-expanded value of .OBJDIR. ${MAKE} -V .OBJDIR
would print the unexpanded value.
--apb (Alan Barrett)
Re: CVS commit: src/distrib/sets
On Fri, 24 Oct 2014, Jeff Rizzo wrote: Modified Files: src/distrib/sets: join.awk Log Message: Back out previous until it can be fixed - it was causing all sets to contain all files, which made a full build of all arches over 150GB! Sorry, I'll try to fix it soon, but it may have to wait a few days. Meanwhile, backing out the problematic revision should be fine. --apb (Alan Barrett)
Re: CVS commit: src/bin/sh
On Wed, 15 Oct 2014, Christos Zoulas wrote: Modified Files: src/bin/sh: redir.c Log Message: PR/48201: Miwa Susumu: Fix set -C (no clobber) for POSIX; from FreeBSD Can't use O_EXCL because of device nodes; also truncate. There are some TOCTOU races in this code, where something about the file could change in between the stat() and the open(). Some ideas: 1. Keep the new code, with its races, but also verify that st_dev and st_ino values remain unchanged between the stat() before opening the file, and fstat() after opening the file. 2. Try open() with O_EXCL first, and fall back to racy code with stat() only if the first open(O_EXCL) fails. Also use fstat() to check that st_dev/st_ino do not change. 3. Invent one or more open(2) flags, such as O_SPECIAL for must be a device or other special file, must not be a plain file or a directory. First try open(O_EXCL), and if that fails then try open(O_SPECIAL). --apb (Alan Barrett)
Re: CVS commit: src/sys/fs/puffs
On Wed, 15 Oct 2014, David Laight wrote:
Consider what happens if you write:
if (error)
DPRINTF((...));
else
fubar();
When DPRINTF() expands 'if (xxx) yyy' it all goes horribly wrong.
That's why I changed it to
do { if (xxx) yyy; } while (0)
a week or two ago. (That change was not pulled up to netbsd-7,
although other changes made around the same time were pulled up.)
Do we need to support any compilers that don't support __VA_ARGS__ ?
Even microsoft's compiler almost supports it.
I don't know.
--apb (Alan Barrett)
Re: CVS commit: src/tools
On Tue, 30 Sep 2014, Joerg Sonnenberger wrote: Modified Files: src/tools: README Log Message: Say that tools should use C89, not C99; Given the state of the toolchain with effectively requiring C++ for both GCC 4.8 and Clang, does this really still make sense? The only relevant semi-modern toolchain I can think of without C99 support is MSVC and we don't support that anyway. Perhaps it does make sense to allow C99 in tools, but I think we have tried to avoid it until now. --apb (Alan Barrett)
Re: CVS commit: src/lib/libc/stdio
On Mon, 29 Sep 2014, Martin Husemann wrote: On Mon, Sep 29, 2014 at 08:29:10PM +0200, Steffen Nurpmeso wrote: (And also i would place a link to the current pull-ups (to the wiki) on www.netbsd.org/developers/releng/pullups.html, since Google shows the latter first, yet that is astonishing empty.) Can you say that again, please? I think he means: Please add links from http://www.netbsd.org/developers/releng/pullups.html to https://releng.netbsd.org/index-7.html, https://releng.netbsd.org/index-6.html, and https://releng.netbsd.org/index-5.html. --apb (Alan Barrett)
Re: CVS commit: src/lib/libc/gen
On Fri, 26 Sep 2014, Roy Marples wrote: Log Message: Remove \$ as a hidden marker as vis(3) wasn't setting it and it clobbered VIS_SHELL | VIS_CSTYLE. This is wrong. vis -l outputs \$, and with this change, unvis won't correctly handle it. unvis is not intended to reverse shell-style escapes. You can use the shell's eval command for that. Doesn't eval kind of defeat the purpose of shell sanitisation which VIS_SHELL is supposed to achieve? I can always add $ to the don't encode this list for VIS_CSTYLE. Yes, eval should be avoided if the input in untrusted. If unvis needs to handle both meanings of \$ (end of line for output from vis -l, or '$' for output from the new shell escaping variant of vis) then it will need a flag to distinguish the cases. Or vis can be changed to use \044 instead of \$ in the shell escaping case, which I guess is what you meant by the don't encode this list. --apb (Alan Barrett)
Re: CVS commit: src/lib/libc/gen
On Fri, 26 Sep 2014, Roy Marples wrote: Modified Files: src/lib/libc/gen: unvis.c Log Message: Remove \$ as a hidden marker as vis(3) wasn't setting it and it clobbered VIS_SHELL | VIS_CSTYLE. This is wrong. vis -l outputs \$, and with this change, unvis won't correctly handle it. unvis is not intended to reverse shell-style escapes. You can use the shell's eval command for that. --apb (Alan Barrett)
Re: CVS commit: src/distrib
On Fri, 12 Sep 2014, Roy Marples wrote: Modified Files: src/distrib/evbsh3/rom/ramdiskcommon: ramdiskbin.conf src/distrib/notes/common: main src/distrib/sets/lists/debug: mi Log Message: Remove more rtsol references. In distrib/notes, please don't just remove rtsol from the section about things that may be removed in the future. Please also add rtsol to the section about things that have been removed. --apb (Alan Barrett)
Re: CVS commit: src/usr.sbin/sysinst
On Fri, 12 Sep 2014, Roy Marples wrote: Modified Files: src/usr.sbin/sysinst: net.c + /* +* Start dhcpcd quietly and in master mode, but restrict +* it to our interface +*/ + add_rc_conf(dhcpcd=YES\n); + add_rc_conf(dhcpcd_flags=\-qM %s\\n, net_dev); This setting of dhcpcd_flags in /etc/rc.conf will restrict dhcpcd to only one interface. That might be what people want during the installation process, but it's not always what they want during future operations. For example, if I install on a laptop over a wired ethernet interface, I nevertheless want dhcpcd to work on the wifi interface later. I suspect that a more appropriate default would be for dhcpcd to run on all appropriate interfaces, unless the user deliberately restricts it. If you do want to restrict it by default, then please also write a comment to rc.conf to explain the consequences of this setting. In a hypothetical future where sysinst has a simple mode and an expert mode, I think simple mode should just let dhcpcd run on all interfaces, and expert mode should let the user choose a set of interfaces. Also, should we add -M to dhcpcd_flags in etc/defaults/rc.conf? Users typically customise those variables by copying the default settings from /etc/defaults/rc.conf to /etc/rc.conf and then adding additional options, so it's helpful if -M is already there before the user adds their own restricted list of interface names. --apb (Alan Barrett)
Re: CVS commit: src
On Thu, 11 Sep 2014, Roy Marples wrote: Log Message: Remove rtsol(8) and rtsold(8) as their functionality is in dhcpcd(8). Remove rtsol(8) from rc.d/network. Add -w seconds command to ifconfig to wait for N seconds for until DAD has finished on all addresses. Use ifconfig -w in rc.d/network instead of a forced sleep. This should have been at least three separate commits, more likely four. 1. add -w option to ifconfig; 2. use ifconfig -w option in rc.d/network; 3. stop using rtsol in rc.d/network; 4. remove rtsol and rtsold. With it all as one commit, it's unnecessarily difficult to pull up the ifconfig -w change and the rc.d/network changes to other branches. --apb (Alan Barrett)
Re: CVS commit: src/usr.bin/flock
On Mon, 18 Aug 2014, Christos Zoulas wrote: Module Name:src Committed By: christos Date: Mon Aug 18 09:14:03 UTC 2014 Modified Files: src/usr.bin/flock: flock.c Log Message: make this behave like linux. Please describe the actual change, which seems to have something to do with changing defaults. Also, it probably needs a man page update. --apb (Alan Barrett)
Re: CVS commit: src/lib/libc/time
On Sat, 16 Aug 2014, Christos Zoulas wrote: Module Name:src Committed By: christos Date: Sat Aug 16 10:38:43 UTC 2014 Modified Files: src/lib/libc/time: zic.c Log Message: gcc on the sparc needs help with variables it thinks are unitialized, but are not. INITIALIZE(ktime); + ktime = 0; /* XXX: gcc */ The #define GNUC_or_lint and #ifdef GNUC_or_lint in time/private.h should have made it so INITIALIZE(ktime) was enough. --apb (Alan Barrett)
Re: CVS commit: src/sys/fs/ptyfs
On Wed, 13 Aug 2014, Juergen Hannken-Illjes wrote: Modified Files: src/sys/fs/ptyfs: ptyfs.h ptyfs_subr.c ptyfs_vfsops.c ptyfs_vnops.c Log Message: - Add a map of active controlling ptys per mount and no longer abuse the vnode lifecycle. - No longer set recycle on VOP_INACTIVE(). - Make ptyfs_used_get() private to ptyfs_subr.c - Stop copying device attributes from traditional ptys on first allocation. - Remove unneeded argument lwp from ptyfs_allocvp() and ptyfs_free_get(). Please could you update the mount_ptyfs(8) man page to explain the new behaviour. --apb (Alan Barrett)
Re: CVS commit: src
On Fri, 08 Aug 2014, John Nemeth wrote: } +++ src/distrib/sets/lists/base/miFri Aug 8 19:38:47 2014 } @@ -1,4 +1,4 @@ } -# $NetBSD: mi,v 1.1084 2014/08/08 19:34:35 apb Exp $ } +# $NetBSD: mi,v 1.1085 2014/08/08 19:38:47 apb Exp $ } # } # Note: Don't delete entries from here - mark them as obsolete instead, } #unless otherwise stated below. ^ Heh, thanks for the reminder. I'll fix it. --apb (Alan Barrett)
Re: CVS commit: src/sys/external/bsd/drm2/include/linux
On Sat, 26 Jul 2014, Taylor R Campbell wrote:
Make Linux usecs_to_jiffies work with hz up to 2000.
usecs_to_jiffies(unsigned int usec)
{
- return mstohz((usec + (1000 / hz) - 1) / (1000 / hz));
+ if (hz = 100)
+ return mstohz(roundup(usec, (1000 / hz)));
+
+ /*
+* Avoid integer overflow on 32-bit platforms. The cutoff is
+* kinda arbitrary; for hz = 2000, 0x20 is safe, but both
+* values could wiggle around a little.
+*/
+ KASSERT(hz = 2000);
+ if (usec = 0x20)
+ return ((usec * hz) / 100);
+ else
+ return ((usec / 100) * hz);
}
You could just populate a struct timeval, and call tvtohz(9).
What is the desired behaviour for small inputs? The code quoted
above appears to round up when hz = 100 (and to return 1 for very
small but non-zero inputs) but to round down (and to return 0 for
very small inputs) when hz 100. Once the desired behaviour is
clarified, you could implement it by making adjustments to the
value before or after calling tvtohz.
--apb (Alan Barrett)
Re: CVS commit: src/sys/dev/ata
On Fri, 25 Jul 2014, David A. Holland wrote:
Modified Files:
src/sys/dev/ata: wd.c
Log Message:
Drop the old discard/trim ioctls from wd.c.
- case DIOCGDISCARDPARAMS: {
- case DIOCDISCARD: {
These never appeared in a release, so I suppose there's no need to
implement these ioctls in any compat code.
--apb (Alan Barrett)
Re: CVS commit: src
On Sat, 19 Jul 2014, Lourival Vieira Neto wrote: lua: updated from 5.1 to 5.3 work3 Is this a well-planned and well-tested update, or does it feel rushed to get it done before the netbsd-7 branch? I think this was as planned and as tested as Lua 5.1 import. However, maybe, I'm missing something. I don't see any recent discussion in public mailing lists. It was discussed on tech-kern [1] and also on icb/irc. [1] http://mail-index.netbsd.org/tech-kern/2014/07/12/msg017341.html Thanks. I had forgotten about that discussion. Two things that bothered me were that the version appears to be a pre-release, not the official Lua 5.3 release, and that the import is being done a very short time before the netbsd-7 branch is planned to be created. What I see in the brief discussion in tech-kern is reassuring, so I have no objection to this update. Also, if this doesn't get reverted for being rushed, then please import it on a vendor branch as per the usual practice. Did you mean moving it from -current to a specific branch? No, I mean using cvs import the way we usually do it. I'll explain in more detail in a private message. --apb (Alan Barrett)
Re: CVS commit: src/lib/libc
On Tue, 24 Jun 2014, David Holland wrote:
On Mon, Jun 23, 2014 at 07:46:15PM +, Taylor R Campbell
wrote:
Read from /dev/urandom.
...ugh. Can we provide a wrapper around this for transparent
casual use? (Even if it's in libutil and marked not for general
consumption?)
Yes please. Note that we already have cprng_{fast,strong}{,32,64}
functions in the kernel.
Or it may be worthwhile to mostly keep the way arc4random(3)
works but replace the PRNG, as in the first reimplementation of
arc4random(3) above, but rename it.
yes please
Yes, I think that's what we are getting at. Keep the way the
interface works, to make it easy for callers to adapt to the new
way, reimplement the internals, and rename to something that does
not embed an algorithm name in the function name.
With either of the later two cases, perhaps we ought to just
coopt random(3) for the purpose.
no please (random(3) is not expected to be cryptographically
strong, so code that assumes it is becomes unportable in a
subtle and dangerous way)
Also I think there's code out there that saves and restores the
random(3) state and expects to get repeatable results.
Yes, the random(3) functions need to be able to provide repeatable
results, and state save/restore functionality.
I am not sure about repeatability requirements across OS
upgrades. I think it may be acceptable for different versions of
the random(3) implementation (say before and after an OS upgrade)
to produce different output streams from the same initial seed or
state.
--apb (Alan Barrett)
Re: CVS commit: src/lib/librumpuser
On Mon, 16 Jun 2014, Alexander Nasonov wrote: Log Message: Add __RCSID. +#if !defined(lint) +__RCSID($NetBSD: rumpuser_bio.c,v 1.8 2014/06/16 21:07:28 alnsn Exp $); +#endif /* !lint */ Some historical uses of __RCSID have an unnecessary #if/#endif wrapper around them, but for new uses, please just write __RCSID(...); without any #if/#endif wrapper. --apb (Alan Barrett)
Re: CVS commit: src
On Tue, 10 Jun 2014, Joerg Sonnenberger wrote: Log Message: Introduce new sysctls for obtaining interface-specific addresses: - net.sdl for the active link-layer adddress (the MAC) - net.ether.multicast for the Ethernet multicast addresses - net.inet6.multicast for the IPv6 multicast groups - net.inet6.multicast_kludge for temporarily removed multicast groups Please document these in sysctl(7). --apb (Alan Barrett)
Re: CVS commit: src/distrib/sets
On Sat, 24 May 2014, Masao Uebayashi wrote: Log Message: Unbreak syspkg by escaping '[' by vis(1) to match the new mtree(8) format. I'd prefer to escape using TOOL_SED so we don't need to add a new TOOL_VIS. --apb (Alan Barrett)
Re: CVS commit: src/share/zoneinfo
On Sat, 17 May 2014, Christos Zoulas wrote: Add tzdata2netbsd, a script to help import new versions of tzdata. Why all the || exit $? instead of set -e set -e would probably be better. --apb (Alan Barrett)
Re: CVS commit: src/usr.bin/xlint/lint1
On Fri, 18 Apr 2014, matthew green wrote: don't include fmemopen in tools builds. Since tools does not define _NETBSD_SOURCE, we don't get the fmemopen prototype hmm is that because we define _SOMEOTHER_SOURCE? _NETBSD_SOURCE should be defined normally, unless you start to ask for restricted namespaces... src/tools/compat/compat_defs.h goes to a lot of trouble to ensure that _NETBSD_SOURCE does not get defined. I don't understand why that is done. --apb (Alan Barrett)
Re: CVS commit: src/common/lib/libc/string
On Mon, 14 Apr 2014, Joerg Sonnenberger wrote: Modified Files: src/common/lib/libc/string: bcopy.c Log Message: Using bcopy/memcpy with NULL arguments is valid as long as the size is also 0. No, it's undefined behaviour. C99 section 7.21.1: Unless explicitly stated otherwise in the description of a particular function in this subclause, pointer arguments on such a call shall still have valid values, as described in 7.1.4. and 7.1.4 says: If an argument to a function has an invalid value (such as ... a null pointer ...) ..., the behavior is undefined. and 7.21.2.1 The memcpy function does not give any explicit permission for use of null pointers. I don't object if the implementation wants to allow null pointers with zero size as an extension, but it should be clear that this is non-standard. --apb (Alan Barrett)
Re: CVS commit: [tls-earlyentropy] src/distrib/utils/sysinst
On Wed, 09 Apr 2014, Thor Lancelot Simon wrote: Modified Files: src/distrib/utils/sysinst [tls-earlyentropy]: util.c Log Message: Try to persistently gather some entropy at install time, to give the fresh system a better chance of not doing awful things like generating guessable SSH host keys. Handles both systems with /var on / and /var on its own filesystem. Tries to preserve old saved entropy when upgrading. I see that you chose to use /etc/entropy-file when /var/db/entropy-file is not on the root file system. Some other locations that I would consider include: /stand/ -- the entropy file may be used by the boot loader before a kernel is running, so that fits, but it's not a program, so that doesn't fit the description in hier(7). /libdata/ -- the entropy file is a non-executable file that is required at boot time, which seems to match the description in hier(7) perfectly. --apb (Alan Barrett)
Re: CVS commit: src/sys/sys
On Fri, 14 Mar 2014, Joerg Sonnenberger wrote: Modified Files: src/sys/sys: cdefs.h Log Message: For compilers without __COUNTER__, make the ctassert name contain __INCLUDE_LEVEL__ ## _ ## __LINE__. It's not perfect, but at least it's better than just __LINE__ since it avoids collisions between .c's and .h's. This is wrong, __INCLUDE_LEVEL__ does not exist unconditionally. You could define a special token in each include file, and then use that token if it is defined. You could also use __INCLUDE_LEVEL__ only if it's defined. Something like this (untested): /* in foo/bar.h: */ #ifndef _FOO_BAR_H #define _FOO_BAR_H #undef __HEADER_NAME_TOKEN #define __HEADER_NAME_TOKEN _FOO_BAR_H /* insert real content here */ #endif /* _FOO_BAR_H */ /* in sys/cdefs.h: */ #define __CTASSERT0(x, y, z1, z2, z3)__CTASSERT1(x, y, z1, z2, z3) #define __CTASSERT1(x, y, z) \ typedef char y ## z1 ## z2 ## z3[/*CONSTCOND*/(x) ? 1 : -1] __unused #if defined(__COUNTER__) # define __CTASSERT(x) __CTASSERT0(x, __ctassert, __COUNTER__,,) #else # if defined(__INCLUDE_LEVEL__) # define __tmp_z1 __INCLUDE_LEVEL__ # else # define __tmp_z1 /* Empty */ # endif # if defined(__HEADER_NAME_TOKEN) # define __tmp_z2 __HEADER_NAME_TOKEN # else # define __tmp_z2 /* Empty */ # endif # define __CTASSERT(x) _CTASSERT0(x, __ctassert, __tmp_z1, __tmp_z2, __LINE__) # undef __tmp_z1 # undef __tmp_z2 #endif --apb (Alan Barrett)
Re: CVS commit: src/sys/kern
On Wed, 05 Mar 2014, Andreas Gustafsson wrote: Changing the types of existing sysctl variables breaks both source and binary compatibility and should not be done lightly; Changing the types without sufficient care can break source and binary compatibility. With sufficient care, compatibility can be maintained, and I thought that dsl had attempted to do that. However, I think that a change like that should have been discussed first. that's why we have both both hw.physmem and hw.physmem64, for example. I think that it was a mistake (made several years ago) to introduce hw.physmem64, and that hw.physmem should have been extended to allow larger values, in a backward compatible way, very much like whay dsl has attempted to do now. Some details might be wrong, and it should have been discussed first, but the principle of returning what the caller expects seems reasonable to me. I believe the harm caused by the incompatible type change far outweighs the cost of a few added lines of code, and would like the original types to be restored. I agree that an incompatible type change would be harmful. If that problem exists, then it could be fixed either by changing the types back, or by fixing the compatibility. Without knowing the reason for the type change, I don't know which of those options I prefer in the long term. For the short term, read on. 2. I also object to the change of kern_syctl.c 1.247. This change attempts to work around the problems caused by the changes to the variable types by making sysctl() return different types depending on the value of the *oldlenp argument. IMO, this is a bad idea. The *oldlenp argument does *not* specify the size of the data type expected by the caller, but rather the size of a buffer. The sysctl() API allows the caller to pass a buffer larger than the variable being read, and conversely, guarantees that passing a buffer that is too small results in ENOMEM. Both of these aspects of the API are now broken: reading a 4-byte CTLTYPE_INT variable now works for any buffer size = 4 *except* 8, and attempting to read an 8-byte CTLTYPE_QUAD variable into a buffer of less than 8 bytes is now guaranteed to yield ENOMEM *except* if the buffer size happens to be 4. IMO, this behavior violates both the letter of the sysctl() man page and the principle of least astonishment. Also, the work-around is ineffective in the case of a caller that allocates the buffer dynamically using the size given by an initial sysctl() call with oldp = NULL. Yes, I think you are right about the details, and we should probably revert the change, at least until a design is discussed that meets all reasonable requirements for compatibility. --apb (Alan Barrett)
Re: CVS commit: src/sys/kern
On Thu, 27 Feb 2014, David Laight wrote:
Modified Files:
src/sys/kern: kern_sysctl.c
+ case CTLTYPE_INT:
+ /* Allow for 64bit read of 32bit value */
+ if (*oldlenp == sizeof (uint64_t)) {
+ qval = *(int *)d;
+ d_out = qval;
+ sz = sizeof (uint64_t);
+ }
+ break;
+ case CTLTYPE_QUAD:
+ /* Allow for 32bit read of 64bit value */
+ if (*oldlenp == sizeof (int)) {
+ qval = *(uint64_t *)d;
+ ival = qval 0x1 ? qval : 0x;
+ d_out = ival;
+ sz = sizeof (int);
+ }
+ break;
This will fail if int is not a 32-bit type, because it uses hardcoded
masks instead of adapting to the actual size.
--apb (Alan Barrett)
Re: CVS commit: src/sys/uvm
On Wed, 26 Feb 2014, Matt Thomas wrote: Modified Files: src/sys/uvm: uvm_meter.c uvm_param.h Log Message: Add vm.min_address and vm.max_address which return VM_MIN_ADDRESS and VM_MAXUSER_ADDRESS. Do these need to use the old style #define constants instead of the new style (since 2005) CTL_CREATE idiom? --apb (Alan Barrett)
Re: CVS commit: src/sys/dev/pci
On Thu, 27 Feb 2014, Joerg Sonnenberger wrote: Modified Files: src/sys/dev/pci: if_ti.c Log Message: Remove impossible checks. If new bugs are introduced in the future, then these tests might no longer be impossible. So I'd prefer to change them to KASSERT or KDASSERT rather than deleting them. --apb (Alan Barrett)
Re: CVS commit: src/bin/ls
On Thu, 20 Feb 2014, Christos Zoulas wrote: Modified Files: src/bin/ls: ls.1 ls.c ls.h print.c Log Message: Add -O (only leaf files) and -P (print full path), from tls@ Do any other ls implementations have such options? I like the idea of being able to run ls -ROP1 . instead of find . type f -print, but I'd like the options to be compatible with other operating systems. --apb (Alan Barrett)
Re: CVS import: src/external/bsd/atf/dist
On Tue, 11 Feb 2014, Julio Merino wrote: Log Message: Import atf-0.20: [...] * Removed the deprecated tools. This includes atf-config, atf-report, atf-run and atf-version. When were those tools deprecated (or, for how long have we had both the deprecated old tools and their new replacements), and what are the replacements? I see no mention of deprecation in the man page for a version of atf-run from November 2013. --apb (Alan Barrett)
Re: CVS commit: src/sys/arch/arm/include
On Wed, 29 Jan 2014, Matt Thomas wrote:
Modified Files:
src/sys/arch/arm/include: int_fmtio.h int_mwgwtypes.h
Log Message:
Make {,u}int{8,16,32} be of type int.
I think you mean:
Make {,u}int_fast{8,16,32} be of type int.
--apb (Alan Barrett)
Re: CVS commit: src/sys/arch/i386/include
On Mon, 27 Jan 2014, Christos Zoulas wrote: Modified Files: src/sys/arch/i386/include: vmparam.h Log Message: Cut down MAXDSIZE from 3G to 2.5G otherwise bottomup allocation ends up supplying an out of bounds hint for sigcode (c001e000 bf00). Makes a.out binaries work again. Will this make malloc fail 0.5GB earlier than before? The data size limits on i386 are already annoyingly small, and I would prefer not to make them smaller. Please could you find a way to penalise only a.out programs. --apb (Alan Barrett)
Re: CVS commit: src/distrib/sets
On Fri, 24 Jan 2014, Masao Uebayashi wrote: 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. You could extract that from METALOG. If something is built twice, it will have two entries in METALOG, but only one entry in METALOG.sanitised. Depending on the host platform, there might not be any timestamps in METALOG. On a NetBSD host, I see time= keywords in METALOG, but on a Linux host, I do not see them. --apb (Alan Barrett)
Re: CVS commit: src/share/mk
On Tue, 21 Jan 2014, Matt Thomas wrote: Module Name:src Committed By: matt Date: Tue Jan 21 16:40:24 UTC 2014 Modified Files: src/share/mk: bsd.own.mk Log Message: Make MKGCCCMDS default mirror MKGCC. (if MKGCC is no, MKGCCCMDS must be no). If that's true, then please adjust bsd.README to say so. Currently, they are documented as being independent (but there seem to be some accidental yes/no inversions in the documentation). --apb (Alan Barrett)
Re: CVS commit: src/share/mk
On Wed, 22 Jan 2014, Christos Zoulas wrote: 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=20 | 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. In the common case, all this linking is happening in an OBJDIR which either started off empty, or started off with the correct symlinks. It might be possible to detect this common case and arrange for it to be race-free. I don't think ln -sf is so bad. The first time, you get the desired symlink: /dirname/linkname - destination then the second time, if you lose the race, you get a useless and mostly harmless extra link: /dirname/destination/destination - destination My tests suggest that the third time, and every other time you run ln -sf destination /dirname/linkname, nothing really changes. /dirname/destination/destination might be deleted and re-created, but (at least on NetBSD and Linux) nothing worse happens. If the extra link is offensive, then just delete it, making the entire sequence like this: # remove old symlink rm -f /dirname/linkname # create desired new symlink, # or create bogus extra link (if we lose the race) ln -sf destination /dirname/linkname # remove bogus extra link (if it exists) rm -f /dirname/destination/destination ln -sfh is not portable, so we can't use that. --apb (Alan Barrett)
Re: CVS commit: src/external/bsd/file/dist/src
On Thu, 16 Jan 2014, Joerg Sonnenberger wrote: Module Name:src Committed By: joerg Date: Thu Jan 16 23:36:52 UTC 2014 Modified Files: src/external/bsd/file/dist/src: file.c Log Message: Only use __dead if it exists. I think the code would be easier to read with #ifndef __dead #define __dead /* nothing */ #endif --apb (Alan Barrett)
use of bsd.sys.mk
On Fri, 10 Jan 2014, Christos Zoulas wrote: Module Name:src Committed By: christos Date: Fri Jan 10 15:50:34 UTC 2014 Modified Files: src/external/mit/xorg/server/xorg-server/hw/xfree86/common: Makefile Log Message: don't include bsd.sys.mk bsd.sys.mk is needed to get the value of HOST_SH, which is used in a != line. At present, Makefiles that use assorted HOST_* tools in != lines usually include bsd.sys.mk to get the variable definitions sufficiently early. If you don't want them to do that, then we need to find a way that works. Perhaps a lot of the variable definitions from bsd.sys.mk can be moved to bsd.own.mk, or a file that's included by bsd.own.mk. Also, if you think that Makefiles should not include bsd.sys.mk, then please edit share/mk/bsd.README to document how things should be done. --apb (Alan Barrett)
ntp.conf
On Mon, 06 Jan 2014, Alan Barrett wrote: On Mon, 06 Jan 2014, Erik Fair wrote: Unless I misunderstand NTP configuration semantics, your additional restrict statements for the NTP pool names will do the wrong thing, in that each reference to a given netbsd.pool.ntp.org name returns multiple IP addresses, in apparently random order, i.e. an attempt to guarantee no two queries return the same data. Ergo, those restrict statements will most probably not end up with the same IP address as their preceding server statements, as was presumably your intent. Yes, you are correct. What should we do? 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 propose to remove the commented-out restrict default ignore, remove the various restrict *.netbsd.pool.ntp.org lines, and remove all mention of special restrict lines for each peer or server, and change a few comments. That will leave the restrict-related part of the default configuration like this: [[[ # Access control restrictions. # See /usr/share/doc/html/ntp/accopt.html for syntax. # See http://support.ntp.org/bin/view/Support/AccessRestrictions for advice. # Last match wins. # # Some of the more common keywords are: # ignore Deny packets of all kinds. # kod Send kiss-o'-death packets if clients exceed rate # limits. # nomodifyDeny attempts to modify the state of the server via # ntpq or ntpdc queries. # noquery Deny all ntpq and ntpdc queries. Does not affect time # synchronisation. # nopeer Prevent establishing new peer associations. # Does not affect peers configured using peer lines. # Does not affect client/server time synchronisation. # noserve Deny all time synchronisation. Does not affect ntpq or # ntpdc queries. # notrap Deny the trap subset of the ntpdc control message protocol. # notrust Deny packets that are not cryptographically authenticated. # # By default, allow client/server time exchange without prior # arrangement, but deny configuration changes, queries, and peer # associations that were not explicitly configured. # restrict default kod nopeer noquery # Fewer restrictions for the local subnet. # (Uncomment and adjust as appropriate.) # #restrict 192.0.2.0 mask 255.255.255.0 kod nomodify notrap nopeer #restrict 2001:db8:: mask ::: kod nomodify notrap nopeer # No restrictions for localhost. # restrict 127.0.0.1 restrict ::1 ]]] Does that sound OK? --apb (Alan Barrett)
Re: CVS commit: src/etc
On Mon, 06 Jan 2014, Erik Fair wrote: Unless I misunderstand NTP configuration semantics, your additional restrict statements for the NTP pool names will do the wrong thing, in that each reference to a given netbsd.pool.ntp.org name returns multiple IP addresses, in apparently random order, i.e. an attempt to guarantee no two queries return the same data. Ergo, those restrict statements will most probably not end up with the same IP address as their preceding server statements, as was presumably your intent. Yes, you are correct. What should we do? 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. --apb (Alan Barrett)
Re: CVS commit: src
On Mon, 02 Dec 2013, Lourival Pereira Vieira Neto wrote: Module Name:src Committed By: lneto Date: Mon Dec 2 04:39:10 UTC 2013 Modified Files: src/lib/libc/stdlib: Makefile.inc src/sys/lib/libkern: Makefile.libkern libkern.h src/sys/modules/lua: Makefile luaconf.h Added Files: src/common/lib/libc/stdlib: strtoimax.c Removed Files: src/lib/libc/stdlib: strtoimax.c Log Message: changed lua_Number to int64_t This was actually two logical changes: * move strtoimax from the userland-only part of libc to the common part that's also usable by the kernel. * change lua_Number to int64_t for the kernel Lua implementation. I would have preferred to see two separate commits. Even with only one commit, the log message should have described both changes. --apb (Alan Barrett)
Re: CVS commit: src/sys/arch/i386/conf
On Fri, 22 Nov 2013, Jeff Rizzo wrote: Modified Files: src/sys/arch/i386/conf: ALL Log Message: Comment out npf for now, as we can't have both NPF and PF in the same kernel It used to be possible to have npf and pf in the same kernel. The kernel I am running now (built a few weeks ago) has both. I think it's important for users to be able to have both. If I want to migrate from pf to npf, then part of my testing would probably involve switching back and forth a few times to check that the npf rules do the same job as the pf rules, and I would want to be able to do that without booting a different kernel for every test. - rmind has said he'll address this eventually, OK. --apb (Alan Barrett)
Re: CVS commit: src/sys/compat/linux
On Mon, 18 Nov 2013, Chuck Silvers wrote: Module Name:src Committed By: chs Date: Mon Nov 18 01:32:22 UTC 2013 Modified Files: src/sys/compat/linux/arch/amd64: linux_exec.h linux_exec_machdep.c src/sys/compat/linux/common: linux_exec.h linux_exec_elf32.c Log Message: implement AT_RANDOM. random() returns a predictable value based on a seed. Given the supposed use of AT_RANDOM for security, I think that it would be more appropriate to use a stronger source, such as cprng_strong32(). --apb (Alan Barrett)
Re: CVS commit: src/sys/modules/lua
On Thu, 31 Oct 2013, Marc Balmer wrote:
Modified Files:
src/sys/modules/lua: Makefile
Log Message:
fix build on arm
Please describe the actual change, not just the reason for it.
Fopr example:
Move -include ${.CURDIR}/luaconf.h from CPPFLAGS to CFLAGS.
--apb (Alan Barrett)
Re: CVS commit: src
On Mon, 28 Oct 2013, Marc Balmer wrote: Modified Files: src/distrib/sets/lists/modules: mi src/sys/modules: Makefile Log Message: linke pmf(9l) to the build Messages like this would be more useful if they said 9lua instyead of 9l. --apb (Alan Barrett)
Re: CVS commit: src/sys/sys
On Fri, 25 Oct 2013, Jukka Ruohonen wrote: src/sys/sys: cdefs.h Log Message: Add __diagused and __debugused. These are for marking variables that are used only in diagnotic or debug code, but unused when NDEBUG is defined, or DIAGNOSTIC is not defined, or DEBUG is not defined. I tried to collect some of these to attribute(3), which might be worth updating (or not). Thank you! I didn't know about attribute(3). --apb (Alan Barrett)
Re: CVS commit: src/sys/arch/sparc
On Mon, 21 Oct 2013, matthew green wrote:
#define raise_ipi(cpi,lvl) do {\
- volatile int x; \
+ int x; \
(cpi)-intreg_4m-pi_set = PINTR_SINTRLEV(lvl); \
- x = (cpi)-intreg_4m-pi_pend;\
+ x = (cpi)-intreg_4m-pi_pend; __USE(x); \
} while (0)
I think that the change from the use of volatile to the use of
__USE() is a change from reliance on the C standard's guarantee
that the memory location behind (cpi)-intreg_4m-pi_pend
really will be accessed, to a reliance on what a particular
compiler happens to do in this situation.
the volatile applies to the access to pi_pend, which is marked a
volatile (via the whole intreg_4m pointer.)
Oh, if cpi, or intreg_4m, or pi_pend, is volatile, then it's fine,
and that would be the best way to deal with the issue. In such a
case, there's no need to use x at all.
i'm not sure that volatile int x; actually means anything
useful. it's pointer accesses that matter. i could be wrong;
volatile is a pretty tricky area.
Yes, the pointer access is the thing that really needs to be
volatile, but I previously thought that it was not, and then I
thought (incorrectly, I now believe) that making x volatile would
be sufficient.
certainly, the generated code is fine (and in most cases,
identical).
My concern was with other compilers in the future. If the pointer
access is volatile, then I think it's fine.
--apb (Alan Barrett)
Re: CVS commit: xsrc/external/mit/xdm/dist/xdm
On Fri, 18 Oct 2013, Christos Zoulas wrote: The result from strlen() has type size_t, so print it with %zd format. %zu is correct. Fixed, thanks.
Re: CVS commit: src/sys/modules/lua
On Fri, 18 Oct 2013, Marc Balmer wrote: Did you get core approval for this? The public discussion is still ongoing, and still lacking in evidence, and there has been no public statement by core as far as I am aware, nor did any members of core I asked have any recollection of approving this. Please don't steamroll over public discussions like this. Just for the record, yes, I got core's approval. Could you tell us approximately when you got that approval? It wasn't in the past two years while I have been a member of core. --apb (Alan Barrett)
Re: CVS commit: src/crypto/external/bsd/openssh/dist
On Sun, 06 Oct 2013, Jean-Yves Migeon wrote: Modified Files: src/crypto/external/bsd/openssh/dist: ssh_config Log Message: Enable VerifyHostKeyDNS (SSHFP records verification) from DNS for hosts under NetBSD.org domain. Thank you. I think this is an improvement. Notified on netbsd-users@, no objection after a week -- committed. Please discuss such things in the relevant tech-* list (tech-net or tech-userlevel in this case, I suppose). +# NetBSD.org DNS provides SSHFP records - use them when possible +Host *.netbsd.org *.NetBSD.org +VerifyHostKeyDNS ask I have been running similar configuration for some time, but with with VerifyHostKeyDNS yes (not ask), and I have had no problems. The difference between yes and ask arises only when the ssh client can be sure that the DNS answer was secured by DNSSEC; in such a case, yes means accept the result silently, while ask means ask the user (the first time). If the DNS answer was not secured by DNSSEC, then both yes and ask end up asking the user. By the way, I think that's a bug in ssh that the Host patterns are case sensitive. --apb (Alan Barrett)
Re: CVS import: src/external/gpl3/binutils/dist
On Sun, 29 Sep 2013, Christos Zoulas wrote: | Log Message: | from ftp.gnu.org | | Status: | | Vendor Tag: FSF | Release Tags:binutils-2-23-2 | | thanks for working on this. please include a real commit log | next time. this one doesn't even mention what package or | version, let alone a simple list of changes since our last | update. So next time: I mention that it is binutils.2.23.2 like it says above, and I copy the ChangeLog? Yes, please mention that it is binutils-2.32.2. The existence of the binutils-2-23-2 tag, or the fact that it corresponds to this import, will not be obvious to future users of cvs log. If the ChangeLog is small, then pasting it into the commit log is useful. If the ChangeLog is large, then please extract only the highlights. --apb (Alan Barrett)
Re: CVS commit: src/usr.bin/make
On Mon, 02 Sep 2013, Simon J. Gerraty wrote: Modified Files: src/usr.bin/make: compat.c Log Message: Do not apply shellErrFlag unless errCheck is true. To generate a diff of this commit: cvs rdiff -u -r1.92 -r1.93 src/usr.bin/make/compat.c Will this fix PR 45356? --apb (Alan Barrett)
Re: CVS commit: src/bin/csh
On Tue, 06 Aug 2013, Christos Zoulas wrote: Module Name:src Committed By: christos Date: Tue Aug 6 05:42:43 UTC 2013 Modified Files: src/bin/csh: lex.c Log Message: CID 1060854: Wrong sizeof argument (SIZEOF_MISMATCH) Does everybody know what CID means? I'd be inclined to say Coverity CID instead of just CID in these log messages. --apb (Alan Barrett)
Re: CVS commit: src/lib/libc/time
On Wed, 31 Jul 2013, David Holland wrote: On Tue, Jul 30, 2013 at 03:30:37PM +, Joerg Sonnenberger wrote: Modified Files: src/lib/libc/time: localtime.c Log Message: Don't depend on implicit rounding from non-integral float constant. what on earth is that code trying to do? If time_t is a floating point type, then round to the nearest second. If time_t is an integral type, then do nothing. There really should be a comment to explain that. --apb (Alan Barrett)
Re: CVS commit: [riastradh-drm2] src/sys/external/bsd/drm2/include/linux
On Wed, 24 Jul 2013, Taylor R Campbell wrote:
Modified Files:
src/sys/external/bsd/drm2/include/linux [riastradh-drm2]: kernel.h
Log Message:
Implement bogus max_t in linux/kernel.h.
+/* XXX These will multiply evaluate their arguments. */
+#definemax_t(T, X, Y) MAX(X, Y)
#define min_t(T, X, Y) MIN(X, Y)
If we are willing to use the non-standard ({ ... }) syntax, then
these can be written to evaluate their arguments only once, like
this:
#define max_t(T, X, Y) ({ T _x = (X), _y = (Y); (_x _y ? _x : _y); })
#define min_t(T, X, Y) ({ T _x = (X), _y = (Y); (_x _y ? _x : _y); })
--apb (Alan Barrett)
Re: CVS commit: src/bin/hostname
On Fri, 19 Jul 2013, Erik Fair wrote: Modified Files: src/bin/hostname: hostname.1 hostname.c Log Message: Add the following options -A Display the FQDN of each address on all interfaces. -a Display alias name(s) of the host. -d Display the DNS domain. -f Display the FQDN for the hostname. -I Display each IP address on all interfaces. -i Display the IP address(es) for the hostname. Not to go all Rob Pike on you (cf. cat -v considered harmful), but what the heck is all this for? And also: Where was this change discussed? --apb (Alan Barrett)
Re: CVS commit: src/bin/hostname
On Fri, 19 Jul 2013, Roy Marples wrote: Module Name:src Committed By: roy Date: Fri Jul 19 10:34:51 UTC 2013 Modified Files: src/bin/hostname: hostname.1 hostname.c If we want these changes (which is by no means clear -- I can't find any discussion of these new options, what they are good for, or why we want them), then we should at least document them better. +.It Fl A +Display the FQDN of each address on all interfaces. +.It Fl a +Display alias name(s) of the host. +.It Fl d +Display the DNS domain. +.It Fl f +Display the FQDN for the hostname. +.It Fl I +Display each IP address on all interfaces. +.It Fl i +Display the IP address(es) for the hostname. .It Fl s -Trims off any domain information from the printed -name. +Display the short hostname. The man page should define all these terms, and explain how they are related to each other. --apb (Alan Barrett)
Re: CVS commit: src/share/zoneinfo
On Sun, 07 Jul 2013, Erik Fair wrote: Pullup request to netbsd-6 and netbsd-5? Yes, I always request such pullups. I like to wait a day or two, but it's occasionally taken me much longer than that. --apb (Alan Barrett)
Re: CVS commit: src
On Sun, 23 Jun 2013, Taylor R Campbell wrote: From: chris...@astron.com (Christos Zoulas) We should not be creating new interfaces based on obsolete ones. I'd rather we have consttime_memcmp() and explicit_memset(). I don't care if we rename them to consttime_memeq and explicit_memzero instead, but these are absolutely the operations that real crypto applications need. consttime_memcmp and explicit_memset are not, and are needlessly complicated. I see the point about avoiding names that resemble the deprecated functions bcmp() and bzero(). I also agree with the point that the memcmp() interface is not what is wanted here. I don't care so much about the difference between the bzero() and memset() interfaces. Because the implementation of consttime_memcmp() would be complex, I'd object to adding it unless there's a caller that needs the three-state return value. I think that the names explicit_memzero() and consttime_memeq() are fine, but I'd expect consttime_memeq() have the opposite polarity from consttime_bcmp(), because it should be answering the question are they equal? (1 for true), not in what order do they compare for sorting? (0 for equal). By the way, I have an implementation of consttime_memcmp() at ftp://ftp.netbsd.org/pub/NetBSD/misc/apb/consttime_memcmp.c. --apb (Alan Barrett)
Re: CVS commit: src/lib/libc/string
On Mon, 24 Jun 2013, Taylor R Campbell wrote: Discuss on tech-userlevel? Yes please. --apb (Alan Barrett)
Re: CVS commit: xsrc/external/mit/xauth/dist
On Mon, 03 Jun 2013, Christos Zoulas wrote: | Well, there is an advantage that the FreeBSD one has over ours. It can be | used in c++ with -Wold-style-cast, if defined as: | | #define __DECONST(t, a) const_castt(a) | | That, and why is it cast to an unsigned long and not uintptr_t? So that it does not bring in another header to define uintptr_t. unsigned long might not be long enough. I'd rather bring in another header than have code that might do the wrong thing on some future platform. We should probably have a header that defines __ versions of some useful types without polluting the namespace, and then use __intptr_t. --apb (Alan Barrett)
Re: CVS commit: src
On Wed, 29 May 2013, Thomas Klausner wrote:
Modified Files:
src: BUILDING
Log Message:
regen (using mandoc doc/BUILDING.mdoc BUILDING -- let me know
if a different way is preferred, I see that it now contains formatting).
make regen in src/doc. If there's a mandoc equivalent for the
${TOOL_GROFF} command there, feel free to edit the Makefile.
--apb (Alan Barrett)
Re: CVS commit: src/lib/libc/iconv
On Sat, 11 May 2013, Blue Rats wrote: .Fn iconv_close , and .Fn iconv -conform to +conforms to .St -p1003.1-2001 . conform was correct, and conforms is wrong. Please reinstate the correct wording. --apb (Alan Barrett)
Re: CVS commit: src/tools/host-mkdep
On Fri, 15 Mar 2013, Christos Zoulas wrote: I still don't understand how a missing include does not cause an error in the compilation phase, but it can be ignore in the dependency generation. tools/compat creates a dummy include file, if necessary. This is good enough for the compilation phase. I am not sure why it's not good enough for host-mkdep, but two ideas spring to mind: perhaps host-mkdep is run before the dummy include file is created, or perhaps host-mkdep is run without the -I flags that would allow it to find the dummy include file. --apb (Alan Barrett)
Re: CVS commit: src/usr.bin/make
On Tue, 05 Mar 2013, Christos Zoulas wrote: Modified Files: src/usr.bin/make: dir.c job.c job.h make.1 parse.c Log Message: Add a .STALE special target that gets invoked when dependency files contain stail entries. Please discuss this sort of thing first. There may be a way to solve the underlying problem without adding a new special target, such as using the newish meta mode. Also, a better name than .STALE might have been suggested. --apb (Alan Barrett)
Re: CVS commit: src/usr.bin/vis
On Thu, 14 Feb 2013, Christos Zoulas wrote: Modified Files: src/usr.bin/vis: vis.c More fixes from J.R. Oldroyd: - In the call to strvisx() the count must be 1, not mbilen which can be 2 or 3 etc for a multibyte character. This value is a count of characters - not bytes - to process. It even says characters in the man page. In vis(3) I am interpreting this value to mean multibyte characters. In general, the caller of str[n]vis[x] knows how many bytes of data they have, but they do not know how many multibyte characters that might represent. If the man page talks about characters, that's because it was written at a time when vis did not attempt to deal with multibyte characters. I think that we should revert to the original semantics of lengths being measured in bytes, and adjust both the man pages and callers appropriately. --apb (Alan Barrett)
Re: CVS commit: src/sys/arch/sparc64
On Mon, 04 Feb 2013, Michael Lorenz wrote: Modified Files: src/sys/arch/sparc64/include: cpu.h src/sys/arch/sparc64/sparc64: machdep.c Log Message: add a sysctl.vis node that indicated which version of the VIS instruction set is supported. Currently this will be 1 for UltraSPARC I and II, 2 for UltraSPARC-III and up Does this need to use #define CPU_VIS, or could it use a new-style dynamic MIB entry, passing CTL_CREATE to sysctl_createv(9)? --apb (Alan Barrett)
Re: CVS commit: src/lib/librumpclient
On Thu, 17 Jan 2013, Antti Kantee wrote: Module Name:src Committed By: pooka Date: Thu Jan 17 20:47:44 UTC 2013 Modified Files: src/lib/librumpclient: rumpclient.c rumpclient.h Log Message: Solaris 10 fixes Please describe the actual changes. e.g. use foo instead of bar. --apb (Alan Barrett)
Re: CVS commit: src/lib/libutil
On Mon, 31 Dec 2012, Joerg Sonnenberger wrote: Log Message: If malloc, calloc, or realloc returns NULL when a size of 0 was requested, which is allowed by pertinent standards, honor it instead of bombing. Do not do this for calloc(x, y) where x != 0 y != 0 but x*y == 0; in that case bomb. The commit message is misleading. We expect calloc(x,y) to return NULL if x!=0 y!=0 x*y==0. (x!=0 y!=0 x*y==0) can be true only if calculating x*y results in what would loosely be called integer overflow; since the types are unsigned, it's a well-defined kind of wraparound, not the undefined kind of overflow. I'd expect an error like EINVAL rather than an error like ENOMEM for this case. --apb (Alan Barrett)
Re: CVS commit: src/usr.bin/units
On Sat, 29 Dec 2012, Robert Elz wrote: | because unit names cannot contain hyphens. Should that not be mentioned in the man page? Perhaps together with a suggestion that if the name the user requires should have hyphens, it simply be entered with the hyphens deleted ... perhaps even using tappit-hen as an example. Good idea. --apb (Alan Barrett)
Re: CVS commit: src/share/mk
On Mon, 10 Dec 2012, Antti Kantee wrote:
+# If the toolchain does not know about a file, --print-file-name echoes
+# the input file name (why??). In that case we want an empty string for
+# dependencies to work correctly. Note: do _not_ use TOOL_SED here because
+# this file is used before TOOL_SED is built.
It's probably a bug if bsd.gcc.mk is used before TOOL_SED is
built. However, you have to .include bsd.own.mk before you try
to use any of its variables in a != line.
+_GCC_CRTBEGINS!= ${CC} --print-file-name=crtbeginS.o \
+ | sed 's|^crtbeginS.o$$||'
You can remove the dependency on sed by using make :C/// variable
modifiers, like this (untested):
_GCC_CRTBEGINS!=${CC} --print-file-name=crtbeginS.o
_GCC_CRTENDS!= ${CC} --print-file-name=crtendS.o
_GCC_CRTI!= ${CC} --print-file-name=crti.o
_GCC_CRTN!= ${CC} --print-file-name=crtn.o
.for v in _GCC_CRTBEGINS _GCC_CRTENDS _GCC_CRTI _GCC_CRTN
# If the value does not contain '/' then replace it with the empty string
${v} := ${${v}:C,^[^/]*$,,}
.endfor
--apb (Alan Barrett)
Re: CVS commit: src/gnu/dist/gcc4/libcpp
On Sun, 25 Nov 2012, Iain Hibbert wrote: Log Message: Teach gcc4.1's cpp about the magic __COUNTER__ macro, which returns a unique integer each time it is expanded. This code was written without reference to any other implementation of the same feature. out of interest, what code uses this? __COUNTER__ is used by the definition of __CTASSERT in sys/cdefs.h. If __COUNTER__ is not available, it falls back to using __LINE__, but that's not necessarily unique. --apb (Alan Barrett)
Re: CVS commit: xsrc/external/mit/xf86-video-xgi/dist/src
On Fri, 09 Nov 2012, David Holland wrote: On Fri, Nov 09, 2012 at 07:00:22AM +, Alan Barrett wrote: Log Message: printf format fix: cast to (long) when printing with %lX format. You mean (unsigned long), right? :-) Thanks, fixed. --apb (Alan Barrett)
Re: CVS commit: xsrc/external/mit/libpciaccess/dist/src
On Fri, 02 Nov 2012, David Young wrote: Modified Files: xsrc/external/mit/libpciaccess/dist/src: common_interface.c Log Message: Remove useless extra const in const sometype const * var = value;. Foundusing clang -Wduplicate-decl-specifier. Maybe 'const sometype * const var' was intended, i.e., a single assignment semantic? I've probably mistyped that myself several times. The variable is assigned only once, so that would work, but it's in a small block where I don't think it would add any clarity. --apb (Alan Barrett)
Re: CVS commit: src/lib/libc/time
On Thu, 25 Oct 2012, Martin Husemann wrote:
Modified Files:
src/lib/libc/time: zic.c
Log Message:
Add a few casts to avoid (IMHO bogus) gcc warnings breaking the vax build.
- if (dayoff min_time / SECSPERDAY) {
+ if (dayoff (long)(min_time / SECSPERDAY)) {
time_t and zic_t are 64 bit types, and max_time and min_time
are the largest possible positive and negative 64-bit values.
max_time / SECSPERDAY or min_time / SECSPERDAY will be much too
large to fit in a 32-bit int, and casting to int will cause overflow.
Does adding a /*CONSTCOND*/ comment work? If so, I'd prefer that
to a cast. If you do need a cast, then I think you should cast
dayoff to zic_t.
--apb (Alan Barrett)
Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs
On Mon, 15 Oct 2012, Taylor R Campbell wrote:
@@ -796,7 +794,11 @@ zfs_link_destroy(zfs_dirlock_t *dl, znod
if (zp_is_dir !zfs_dirempty(zp)) { /* dir not empty */
mutex_exit(zp-z_lock);
vn_vfsunlock(vp);
+#ifdef __NetBSD__ /* XXX Make our dumb tests happier... */
+ return (ENOTEMPTY);
+#else
return (EEXIST);
+#endif
}
I'd suggest using ifdef ENOTEMPTY instead of ifdef __NetBSD__ here.
(And the log message did not mention this change.)
--apb (Alan Barrett)
Re: CVS commit: src/share/man/man3
On Tue, 16 Oct 2012, SAITOH Masanobu wrote: Modified Files: src/share/man/man3: bits.3 Log Message: Return value of __BIT() and __BITS() is not uint32_t but uint64_t. No, they are uintmax_t. uintmax_t happens to be the same as uint64_t on all present day NetBSD platforms, but a new platform with a larger uintmax_t could appear one day. --apb (Alan Barrett)
Re: CVS commit: src/share/zoneinfo
On Thu, 27 Sep 2012, Alan Barrett wrote: Module Name:src Committed By: apb Date: Thu Sep 27 15:51:48 UTC 2012 Update of /cvsroot/src/share/zoneinfo In directory ivanova.netbsd.org:/tmp/cvs-serv19934 Log Message: Import tzdata2012f from http://www.iana.org/time-zones/repository/releases/tzdata2012f.tar.gz [...] N src/share/zoneinfo/tzdata2012f.tar.gz That file was not supposed to be imported. It has been deleted from the repository. If you updated your working copy (via cvs update or cvs checkout or similar commands) in the ten minute window between the import and the file being removed from the repository, then you may have to manually delete the tzdata2012f.tar.gz file, or the corresponding line in the CVS/Entries file, or both. --apb (Alan Barrett)
Re: CVS commit: src/etc
On Sat, 15 Sep 2012, Martin Husemann wrote:
On Sat, Sep 15, 2012 at 12:35:26PM +0200, Alan Barrett wrote:
Under what circumstances is it useful for MAKEDEV to mount
ptyfs? Why can't we rely on other code to mount it later?
We can - this is just a very central place to catch them all
easily. I don't mind doing it explicitly elsewehere.
Can we at least make this conditional on the -M flag being
specified twice, as happens when init(8) invokes MAKEDEV?
Isn't that already the case? I thought the $do_create_mfs would
only be set in that case.
do_create_mfs is set when MAKEDEV gets the -M flag. init(8)
invokes MAKEDEV with -MM, which causes MAKEDEV to do some extra
stuff that is doesn't do when there's only one -M flag. This is
intended to allow callers other than init(8) to use -M, in case
anything ever wants to do that. At present, the only extra thing
that MAKEDEV does when given two -M flags is to redirect its
output to the newly-created /dev/console as early as posible, but
any special handling of ptyfs could also be linked to that.
I should probably use a variable with a better name than
do_redirect to remember whether we got two -M flags. Perhaps
like this:
--- MAKEDEV.tmpl13 Aug 2012 08:30:51 - 1.157
+++ MAKEDEV.tmpl15 Sep 2012 11:14:15 -
@@ -427,6 +427,7 @@ setup()
: ${TOOL_PAX:=pax}
status=0
do_create_mfs=false
+ do_extra_for_init=false
do_force=false
do_mknod=false
do_pax=false
@@ -441,8 +442,8 @@ setup()
case ${ch} in
M)
# -M sets do_create_mfs;
- # -M -M is for use from init(8), and sets do_redirect
- do_redirect=$do_create_mfs
+ # -M -M is for use from init(8).
+ do_extra_for_init=$do_create_mfs
do_create_mfs=true
;;
f) do_force=true
@@ -529,6 +530,11 @@ setup()
esac
fi
+ # Extra things to do when invoked by init(8) with two -M flags
+ if $do_extra_for_init; then
+ do_redirect=true
+ fi
+
# do_force requires mknod
if $do_force; then
if $do_mtree || $do_pax || $do_specfile; then
Re: CVS commit: src/share/misc
On Fri, 07 Sep 2012, Brian Ginsbach wrote: Modified Files: src/share/misc: country +Cura?aoCW CUW 531 UC Do we really want non-ASCII characters in this file? Could we just spell it Curacao with latin small letter c instead of attempting to represent latin small letter c with cedilla in an unspecified encoding? --apb (Alan Barrett)
Re: CVS commit: src/etc
On Tue, 05 Jun 2012, Aleksej Saushev wrote: if [ -n $count_nodes ]; then count_nodes=$((count_nodes + \ - $(linecount $(sh $0.local $opts -s all)) )) + $(linecount $($HOST_SH $0.local $opts -s all)) )) Are \\s really not needed here? $() and $(()) constructs nest correctly without needing any backslashes. $opts will be a problem if it contains -m PATH_TO_MKNOD and PATH_TO_MKNOD contains spaces or other special characters, but backslashes here won't fix that. --apb (Alan Barrett)
Re: CVS commit: src/tools/compat
On Sun, 03 Jun 2012, Joerg Sonnenberger wrote: Log Message: Add __predict_true / __predict_false definitions. +#undef __predict_false +#define __predict_false(x) x +#undef __predict_true +#define __predict_true(x) x Please parenthesise the definitions. I don't know whether it's worth defining them in a compiler-dependent way, or using #ifndef to pick up any definition provided by the host system. --apb (Alan Barrett)
Re: CVS commit: src
On Wed, 28 Mar 2012, Jukka Ruohonen wrote:
+ATF_TC_BODY(random_zero, tc)
+{
+ const size_t n = 100;
+ size_t i, j;
+ long x;
+
+ srandom(0);
+
+ for (i = j = 0; i n; i++) {
+
+ if ((x = random()) == 0)
+ j++;
+ }
+
+ ATF_REQUIRE(j != n);
+}
n=4 would probably be enough iterations, and I'd suggest checking
whether all values are the same as each other, rather than
checking whether all values are zero.
--apb (Alan Barrett)
From: Alan Barrett a...@cequrux.com
To: source-changes-d@NetBSD.org
Cc:
Bcc:
Subject: Re: CVS commit: src
Reply-To:
In-Reply-To: 20120328103358.4bb3317...@cvs.netbsd.org
On Wed, 28 Mar 2012, Jukka Ruohonen wrote:
+ATF_TC_BODY(random_zero, tc)
+{
+ const size_t n = 100;
+ size_t i, j;
+ long x;
+
+ srandom(0);
+
+ for (i = j = 0; i n; i++) {
+
+ if ((x = random()) == 0)
+ j++;
+ }
+
+ ATF_REQUIRE(j != n);
+}
n=4 would probably be enough iterations, and I'd suggest requiring all
values to be different, rather than requiring at least one non-zero
value.
--apb (Alan Barrett)
Re: CVS commit: src/tests/ipf
On Tue, 27 Mar 2012, Jukka Ruohonen wrote: Modified Files: src/tests/ipf: t_filter_exec.sh t_filter_parse.sh t_nat_exec.sh t_nat_ipf_exec.sh Log Message: Mark the failing tests as broken. XXX: If no one is willing to maintain the ipf tests, these should be removed. I object to this. If ipf fails its tests, then the fact should be made clear in the test reports, not hidden by disabling the tests. I don't know whether the bugs are in ipf or in the tests, but either way, removing or disabling the tests seems to me to be counter-productive. --apb (Alan Barrett)
Re: CVS commit: src/lib/libarch/alpha
On Thu, 22 Mar 2012, Havard Eidnes wrote: Modified Files: src/lib/libarch/alpha: alpha_pci_io.c Log Message: Add a cast of the shift count to int32_t, so that we don't try to do int32_t long, since ANSI C doesn't perform balancing before the shift operation according to lint. Should not make a difference, offset is limited to 0..3 anyway. I don't know what balancing means, but this seems bogus to me. The type of the right hand operand of the operator is irrelevant; only its value is important. (See sectiopn 6.5.7 of the C99 standard.) I think it's fine to add casts that are not really nbecessary, if they improve the readability or portability of the code. The cast here does not do that, and I think it should not be added. --apb (Alan Barrett)
