Re: CVS commit: src/common/lib/libc/arch/arm
On 17 May 2015 at 22:19, Justin Cormack jus...@specialbusservice.com wrote: On 17 May 2015 at 22:02, Matt Thomas m...@3am-software.com wrote: On May 17, 2015, at 1:57 PM, Justin Cormack jus...@netbsd.org wrote: Module Name: src Committed By: justin Date: Sun May 17 20:57:12 UTC 2015 Modified Files: src/common/lib/libc/arch/arm/atomic: atomic_op_asm.h atomic_swap.S atomic_swap_16.S atomic_swap_64.S sync_bool_compare_and_swap_1.S sync_bool_compare_and_swap_2.S sync_bool_compare_and_swap_4.S sync_bool_compare_and_swap_8.S sync_fetch_and_add_8.S sync_fetch_and_and_8.S sync_fetch_and_nand_8.S sync_fetch_and_or_8.S sync_fetch_and_sub_8.S sync_fetch_and_xor_8.S src/common/lib/libc/arch/arm/string: ffs.S Most of these changes should have been in Makefile.inc, not in the sources themselves. Ok fixed now, sorry about that. justin
Re: CVS commit: src/common/lib/libc/arch/arm
On 17 May 2015 at 22:02, Matt Thomas m...@3am-software.com wrote: On May 17, 2015, at 1:57 PM, Justin Cormack jus...@netbsd.org wrote: Module Name: src Committed By: justin Date: Sun May 17 20:57:12 UTC 2015 Modified Files: src/common/lib/libc/arch/arm/atomic: atomic_op_asm.h atomic_swap.S atomic_swap_16.S atomic_swap_64.S sync_bool_compare_and_swap_1.S sync_bool_compare_and_swap_2.S sync_bool_compare_and_swap_4.S sync_bool_compare_and_swap_8.S sync_fetch_and_add_8.S sync_fetch_and_and_8.S sync_fetch_and_nand_8.S sync_fetch_and_or_8.S sync_fetch_and_sub_8.S sync_fetch_and_xor_8.S src/common/lib/libc/arch/arm/string: ffs.S Most of these changes should have been in Makefile.inc, not in the sources themselves. Ok, will rework those ones. Justin
Re: CVS commit: src/sys/net
On Mon, Dec 1, 2014 at 12:15 PM, Antti Kantee po...@netbsd.org wrote: Antti, Justin, can we separate the rump userland from the rump kernel binaries easily and put them in different sets, and then run the userland from -6 or -7 against the (rump-)kernel from -current? Copying prebuilt userland tarballs around sounds suboptimal. Unless you want to go cherry-picking every time something changes in the tests, you'd need all of bins/libs. And then you'd probably need to carefully tune your PATH for the tests to still work. Instead, I'd go the opposite route which allows for straightforward, self-contained automation: You can use buildrump.sh (*) with a -6 or -7 toolchain to get a -current rump kernel. Theoretically speaking, you can then run the -current tests as an additional part of -6 and -7 test runs with LD_LIBRARY_PATH set to buildrump.sh/rump/lib. I doubt anyone has run /usr/tests with host != rump kernel since I was working on NetBSD 5.0 and testing -current, um, 4 years ago (and I was just installing -current to /), so expect some tuning to be necessary. Well I have now, the buildrump snapshot (ie current a month or so ago) on 6.1.5/amd64. There are about 110 more test fails than there are on my install, will look into what type of thing is failing and why. A lot (most) seem to be puffs/p2k related. Justni
Re: CVS commit: src/sys
On Sun, Nov 16, 2014 at 12:21 AM, Takeshi Nakayama t...@catvmics.ne.jp wrote:
Takeshi Nakayama t...@catvmics.ne.jp wrote
Justin Cormack jus...@specialbusservice.com wrote
Er, you can't do that.
1. It breaks the rump builds on most platforms
http://build.myriabit.eu:8012/waterfall as the prototypes dont match
eg see
http://build.myriabit.eu:8012/builders/ppc64-cross/builds/5585/steps/shell_3/logs/stdio
It seems that posix says 2nd arg of iconv(3) is char **, but
NetBSD's one is const char **.
2. There is no requirement that rump runs on a platform that has iconv
anyway, it may be running on bare metal, or non Posix platform.
Not sure what the intention was though - I am sure we can find a way
around it...
I would like to include this at least on NetBSD host since we don't
have kernel iconv and then mount_smbfs(8) is useless for filename
conversions.
So is it ok to add a compile-time option as below and define it
somewhere? Or are there any more appropriate make variables to
detect host OS?
On second thought, it seems user component can use __NetBSD__
definition, how about this change?
You also need to wrap the #include iconv.h in sys/netsmb/iconv.c in
#ifdef as well, as some platforms do not have the header.
How does it work when not using rump? Do we really need in kernel iconv?
Justin
-- Takeshi Nakayama
Index: netsmb_user.c
===
RCS file: /cvsroot/src/sys/rump/dev/lib/libnetsmb/netsmb_user.c,v
retrieving revision 1.1
diff -u -d -r1.1 netsmb_user.c
--- netsmb_user.c 15 Nov 2014 18:49:04 - 1.1
+++ netsmb_user.c 16 Nov 2014 00:21:28 -
@@ -36,6 +36,7 @@
int
rumpcomp_netsmb_iconv_open(const char *to, const char *from, void **handle)
{
+#ifdef __NetBSD__
iconv_t cd;
int rv;
@@ -49,11 +50,16 @@
}
return rumpuser_component_errtrans(rv);
+#else
+ /* fallback to use stub functions */
+ return 0;
+#endif
}
int
rumpcomp_netsmb_iconv_close(void *handle)
{
+#ifdef __NetBSD__
int rv;
if (iconv_close((iconv_t)handle) == -1)
@@ -62,12 +68,17 @@
rv = 0;
return rumpuser_component_errtrans(rv);
+#else
+ /* do nothing */
+ return 0;
+#endif
}
int
rumpcomp_netsmb_iconv_conv(void *handle, const char **inbuf,
size_t *inbytesleft, char **outbuf, size_t *outbytesleft)
{
+#ifdef __NetBSD__
int rv;
if (iconv((iconv_t)handle, inbuf, inbytesleft, outbuf, outbytesleft)
@@ -77,5 +88,9 @@
rv = 0;
return rumpuser_component_errtrans(rv);
+#else
+ /* do nothing */
+ return 0;
+#endif
}
#endif
Re: CVS commit: src/sys
On Sat, Nov 15, 2014 at 6:49 PM, Takeshi Nakayama nakay...@netbsd.org wrote: Module Name:src Committed By: nakayama Date: Sat Nov 15 18:49:05 UTC 2014 Modified Files: src/sys/netsmb: iconv.c src/sys/rump/dev/lib/libnetsmb: Makefile Added Files: src/sys/rump/dev/lib/libnetsmb: netsmb_iconv.c netsmb_user.c netsmb_user.h Log Message: Make rump_smbfs(8) uses host iconv(3) to convert filenames character set. Er, you can't do that. 1. It breaks the rump builds on most platforms http://build.myriabit.eu:8012/waterfall as the prototypes dont match eg see http://build.myriabit.eu:8012/builders/ppc64-cross/builds/5585/steps/shell_3/logs/stdio 2. There is no requirement that rump runs on a platform that has iconv anyway, it may be running on bare metal, or non Posix platform. Not sure what the intention was though - I am sure we can find a way around it... Justin
Re: CVS commit: src/tests/lib/libc/gen
On Sun, Oct 12, 2014 at 11:33 PM, Christos Zoulas chris...@netbsd.org wrote: Module Name:src Committed By: christos Date: Sun Oct 12 22:33:41 UTC 2014 Modified Files: src/tests/lib/libc/gen: t_fnmatch.c Log Message: You need double the number of backslashes in a pattern, since \\ - '\' in the string which means escape. Now the tests don't fail. To generate a diff of this commit: cvs rdiff -u -r1.5 -r1.6 src/tests/lib/libc/gen/t_fnmatch.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Not sure about this. See http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html#tag_09_03_05 The special characters '.', '*', '[', and '\' (period, asterisk, left-bracket, and backslash, respectively) shall lose their special meaning within a bracket expression. So I think the original version of the test is in fact correct with a single \ in the actual string within the bracket expression. This test passes in a very few implementations. I might be wrong though... Justin
Re: CVS commit: src/tests/lib/libc/gen
On Mon, Oct 13, 2014 at 2:26 PM, Christos Zoulas chris...@zoulas.com wrote: On Oct 13, 2:23pm, jus...@specialbusservice.com (Justin Cormack) wrote: -- Subject: Re: CVS commit: src/tests/lib/libc/gen | You can have a ] by having it as the first character that is made explicit. | And if the / is not special then that is no problem either. Yes, '/' is the problem. | Let me read through the spec again. We are not alone in not passing this | test eg glibc). I can't remember what FreeBSD does will check again. I couldn't find a place where it said how to quote /. Well also there is the bit thats says http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13_01 When pattern matching is used where shell quote removal is not performed (such as in the argument to the find - name primary when find is being called using one of the exec functions as defined in the System Interfaces volume of IEEE Std 1003.1-2001, or in the pattern argument to the fnmatch() function), special characters can be escaped to remove their special meaning by preceding them with a backslash character. This escaping backslash is discarded. The sequence \\ represents one literal backslash. All of the requirements and effects of quoting on ordinary, shell special, and special pattern characters shall apply to escaping in this context. Which seems to suggest your change is correct... will see if can get agreement. The / handling for fnmatch seems to be covered by http://pubs.opengroup.org/onlinepubs/009695399/functions/fnmatch.html The flags argument shall modify the interpretation of pattern and string. It is the bitwise-inclusive OR of zero or more of the flags defined in fnmatch.h. If the FNM_PATHNAME flag is set in flags, then a slash character ( '/' ) in string shall be explicitly matched by a slash in pattern; it shall not be matched by either the asterisk or question-mark special characters, nor by a bracket expression. If the FNM_PATHNAME flag is not set, the slash character shall be treated as an ordinary character. Which suggests \/ is not allowed, you are matching pathnames or not and cannot escape a / Justin
Re: CVS commit: src/lib/librumpuser
On Tue, Oct 7, 2014 at 10:19 AM, Marc Balmer m...@msys.ch wrote: -/* NetBSD is the only(?) platform with getenv_r() */ -#if !defined(__NetBSD__) +/* NetBSD is almost the only platform with getenv_r() */ +#if !(defined(__NetBSD__) || defined(__minix__)) Minix defines __minix, not __minix__, though. My compiler (cross compiler from git head recently) defines both, but you are right the standard one used seems to be __minix... Justin
Re: CVS commit: src/lib/librumpuser
On Mon, Mar 10, 2014 at 8:38 AM, Martin Husemann mar...@homeworld.netbsd.org wrote: On Sun, Mar 09, 2014 at 11:01:11PM +, Justin Cormack wrote: Module Name: src Committed By: justin Date: Sun Mar 9 23:01:11 UTC 2014 Modified Files: src/lib/librumpuser: rumpuser_pth.c Log Message: Use __thread rather than pthread_getspecific for rumpuser curlwp. This has better performance and curlwp is a performance bottleneck in rump kernel code. You can't do this, it breaks the build on non TLS supporting platforms. Argh sorry. Will make it conditional on TLS support. I misread the gcc docs. Justin
Re: CVS commit: src/external/bsd/file
On Sat, Jan 18, 2014 at 10:33 AM, Martin Husemann mar...@duskware.de wrote: On Fri, Jan 17, 2014 at 11:32:29PM +, David Laight wrote: If the problem actually caused by gcc failing to pair all the conditionals? Compiling with 'clazz' a compile-time constant might show things. I don't think so, and I'll leave a final fix to Christos as maintainer. Or, if memcpy() is defined in a header file and uses casts to optimise inlined copies of fixed sizes it might be that the pointer-aliasing rules mean that the actual structure might not have been written. The copy is of the full size of the relevant structure, but through a (void*) pointer - sounds more like a gcc bug to me. I believe gcc is correct here, you are only allowed to alias via a char pointer or the original type. Because you put a void pointer in instead gcc is right to complain. Justin
Re: CVS commit: src/tests/lib/libc/net
On Thu, Jan 9, 2014 at 2:18 AM, Christos Zoulas chris...@netbsd.org wrote: Module Name:src Committed By: christos Date: Thu Jan 9 02:18:10 UTC 2014 Modified Files: src/tests/lib/libc/net: Makefile h_dns_server.c h_hostent.c t_hostent.sh Added Files: src/tests/lib/libc/net: resolv.conf Log Message: Use our own resolv.conf file simplifying the test to not need rump_vfs. Add debugging on the dns server One test fails (gethostbyaddr6) why? It runs without rump As of a week or so ago all inet6 tests on rump also need to be linked against -lrumpnet_netinet6 as well as -lrumpnet_netinet as inet/inet6 are now modular. Justin
Re: CVS commit: src
On 3 Dec 2013 16:02, Christos Zoulas chris...@zoulas.com wrote: On Dec 3, 11:45am, ln...@netbsd.org (Lourival Vieira Neto) wrote: -- Subject: Re: CVS commit: src | Also, moving to intmax_t, would help in string library. It needs a | length modifier for string.format (LUA_INTFRMLEN). AFAIK, there is no | length modifier defined for int64_t. Using intmax_t we could just use | j. Yes, the other good side effect of intmax_t is that this is the best the machine can do in terms of integer range. No that is a bad side effect. It must always be 64 bits. In the kernel you have to deal with uint64_t which will behave differently if intmax_t is ever bigger than 64 bits, so code will break. So either use int64_t or what Lua uses and assert that that is 64 bits. Justin
Re: CVS commit: src
On 3 Dec 2013 22:16, Lourival Vieira Neto ln...@netbsd.org wrote: Hi Justin, On Tue, Dec 3, 2013 at 8:04 PM, Justin Cormack jus...@specialbusservice.com wrote: On 3 Dec 2013 16:02, Christos Zoulas chris...@zoulas.com wrote: On Dec 3, 11:45am, ln...@netbsd.org (Lourival Vieira Neto) wrote: -- Subject: Re: CVS commit: src | Also, moving to intmax_t, would help in string library. It needs a | length modifier for string.format (LUA_INTFRMLEN). AFAIK, there is no | length modifier defined for int64_t. Using intmax_t we could just use | j. Yes, the other good side effect of intmax_t is that this is the best the machine can do in terms of integer range. No that is a bad side effect. It must always be 64 bits. In the kernel you have to deal with uint64_t which will behave differently if intmax_t is ever bigger than 64 bits, so code will break. So either use int64_t or what Lua uses and assert that that is 64 bits. What side effect? Why it must always be 64 bit? Also, I don't get the unsigned problem. What it will break? Moreover, if we don't have a 64-bit int type, what we should do? Disable Lua? If the Lua int type was 128 bit uint64_t would convert differently. More correctly even as it would remain unsigned rather than wrapping to signed. This means code will break as the kernel uses uint64_t. We always have a 64 bit type as you need it to eg read a filesystem. It may be emulated by the compiler but it works.
Re: CVS commit: src/lib/lua/syslog
On Tue, Nov 12, 2013 at 4:29 PM, Marc Balmer m...@msys.ch wrote: Am 12.11.13 17:04, schrieb Christos Zoulas: In article 20131112143203.8cd3...@cvs.netbsd.org, Marc Balmer source-changes-d@NetBSD.org wrote: -=-=-=-=-=- Module Name: src Committed By:mbalmer Date:Tue Nov 12 14:32:03 UTC 2013 Added Files: src/lib/lua/syslog: Makefile syslog.c Log Message: Add a syslog(3) binding for Lua (not yet linked to the build.) Is there any reason not to use the modern syslog (thread-safe) functions openlog_r(), syslog_r(), syslogp_r()? Good question. We would have to keep the context somewhere (certainly solvable), then, I wonder I Lua is ever used threaded? Could the problem arise in reality (it did not in our stuff since Jan 1st 2009) Maybe if two threads create separate states, and then both threads use syslog at the same time? (can not happen at this moment). People do use it threaded sometimes. I would just return a userdata with a _gc method to the user. Justin
