Re: CVS commit: src/lib/librumpuser/build-aux
On 19/10/16 06:05, co...@sdf.org wrote: Maybe I should revert it because I misunderstood things and it does not matter... sorry for the noise Yes. I was trying to do something about the random failures in builds http://releng.netbsd.org/builds/netbsd-6/201610160430Z/ews4800mips.build.failed http://releng.netbsd.org/builds/netbsd-6/201610181650Z/sbmips-mipsel.build.failed No idea about the cause, but there seem to be other variants of the same theme in the build logs, suggesting a more general problem, e.g.: https://releng.netbsd.org/builds/HEAD/201610171520Z/sbmips-mipseb.build.failed In all of the cases I looked at, it was a lib, but don't know if that holds universally. thanks, antti
Re: CVS commit: src/lib/librumpuser/build-aux
On 17/10/16 18:24, Maya Rashish wrote: Module Name:src Committed By: maya Date: Mon Oct 17 18:24:42 UTC 2016 Modified Files: src/lib/librumpuser/build-aux: install-sh Log Message: use mktemp instead of $RANDOM for tmpdir ..$RANDOM won't work with our /bin/sh. unsure if this script is used, but it is wrong. might help the spurious build failures that occasionally show up on autobuilds. Are you planning to adjust all of the unused install-sh files around the tree to make them consistently less wrong?
Re: CVS commit: src
On 25/01/16 00:10, Antti Kantee wrote: On 25/01/16 00:04, Christos Zoulas wrote: On Jan 24, 10:48pm, po...@iki.fi (Antti Kantee) wrote: -- Subject: Re: CVS commit: src | It's definitely a bug if librumpuser, client and hijack depend on NetBSD | kernel types. All of those libs build fine for me without _KERNTYPES. | Is there some non-obvious problem? If so, I'd like to know about it so | that I can fix it. They use register_t... They built for me for Linux because register_t on that target doesn't come from NetBSD. In fact, my NetBSD targeted build just hit that problem just now. Humh. "Humh" is short for "sorry for the noise", in case someone was wondering ;)
Re: CVS commit: src
On 25/01/16 00:04, Christos Zoulas wrote: On Jan 24, 10:48pm, po...@iki.fi (Antti Kantee) wrote: -- Subject: Re: CVS commit: src | It's definitely a bug if librumpuser, client and hijack depend on NetBSD | kernel types. All of those libs build fine for me without _KERNTYPES. | Is there some non-obvious problem? If so, I'd like to know about it so | that I can fix it. They use register_t... They built for me for Linux because register_t on that target doesn't come from NetBSD. In fact, my NetBSD targeted build just hit that problem just now. Humh.
Re: CVS commit: src
On 23/01/16 21:22, Christos Zoulas wrote: Module Name:src Committed By: christos Date: Sat Jan 23 21:22:50 UTC 2016 Modified Files: [snip] src/lib/librumpclient: Makefile src/lib/librumphijack: Makefile src/lib/librumpuser: Makefile Log Message: Define _KERNTYPES for things that need it. It's definitely a bug if librumpuser, client and hijack depend on NetBSD kernel types. All of those libs build fine for me without _KERNTYPES. Is there some non-obvious problem? If so, I'd like to know about it so that I can fix it.
Re: CVS commit: src/share/mk
On 19/10/15 17:08, David A. Holland wrote: Module Name:src Committed By: dholland Date: Mon Oct 19 17:08:11 UTC 2015 Modified Files: src/share/mk: bsd.man.mk Log Message: because I'm feeling tetchy, implement "make describe" for everything that has man pages. That tetchiness is causing conflicts, e.g. nbmake[1]: "/home/pooka/src/nbsrc/src/share/mk/bsd.man.mk" line 300: warning: duplicate script for target "describe" ignored nbmake[1]: "/home/pooka/src/nbsrc/src/lib/librumpvfs/../../sys/rump/Makefile.rump" line 247: warning: using previous script for "describe" defined here
Re: CVS commit: src/sys/dev/pci
On 25/08/15 06:54, matthew green wrote: "Antti Kantee" writes: Module Name:src Committed By: pooka Date: Mon Aug 24 23:52:18 UTC 2015 Modified Files: src/sys/dev/pci: if_iwn.c Log Message: Remove "#ifdef INET" code. Por que? Because opt_inet.h was not included and "#ifdef INET" was just a fancy way of saying "#ifndef NetBSD". h, while the code wasn't used before, are you sure it isn't actually what we would rather be using? i ask because i count 57 calls to arp_ifinit() in our tree today (including this removed one), so i'm mostly convinced that it should be called, but the failure mode of not doing so is less severe than fails to work. I assume that they're drivers which want to catch SIOCINITIFADDR instead of letting it pass through to ether_ioctl(). The call is 99% likely a leftover of porting the driver from OpenBSD. At least when I ported iwm from NetBSD to OpenBSD, I added an #ifdef __OpenBSD__ block to call to arp_ifinit() from SIOCSIFADDR. So, no, I don't think arp_ifinit() should be called from that driver.
Re: CVS commit: src/lib/libpthread
On 24/08/15 14:36, Joerg Sonnenberger wrote: On Mon, Aug 24, 2015 at 02:20:55PM +, Antti Kantee wrote: On 24/08/15 13:26, Joerg Sonnenberger wrote: On Mon, Aug 24, 2015 at 12:45:15PM +, Antti Kantee wrote: I started work on this again by doing a web search for the error, and found this: http://bugs.musicpd.org/view.php?id=4110 There you argue that using constexpr for PTHREAD_MUTEX_INITIALIZER is broken. So if we assume that you are correct, shouldn't we remove the "constexpr"s from libc++/dist/libcxx/include/__mutex_base? Except that the standard requires it. So are you now saying that that what you said in the above URL is wrong and that the NetBSD headers are broken? Let me quote the relevant part of what you said: Stop inventing things, please. A simple "yes/no[, because ...]" is more effective than evading the question. I'm still not sure which one it is. "Nothing in ISO C11, ISO C++11 or POSIX requires PTHREAD_MUTEX_INITIALIZER to qualify for constexpr." But now you are saying that "the standard" does require PTHREAD_MUTEX_INITIALIZER to qualify for constexpr. A mutex has to be constexpr constructable. That's in the standard. How a mutex is implemented is not. Nothing in mpd requires the constexpr property, so requiring it just makes things more difficult for no good reason. What I understand from that response: the same code is wrong in mpd (and presumably every other application) but right in libc++; it's standard-compliant to implement mutex in a way which does not compile.
Re: CVS commit: src/lib/libpthread
On 24/08/15 13:26, Joerg Sonnenberger wrote: On Mon, Aug 24, 2015 at 12:45:15PM +, Antti Kantee wrote: I started work on this again by doing a web search for the error, and found this: http://bugs.musicpd.org/view.php?id=4110 There you argue that using constexpr for PTHREAD_MUTEX_INITIALIZER is broken. So if we assume that you are correct, shouldn't we remove the "constexpr"s from libc++/dist/libcxx/include/__mutex_base? Except that the standard requires it. So are you now saying that that what you said in the above URL is wrong and that the NetBSD headers are broken? Let me quote the relevant part of what you said: "Nothing in ISO C11, ISO C++11 or POSIX requires PTHREAD_MUTEX_INITIALIZER to qualify for constexpr." But now you are saying that "the standard" does require PTHREAD_MUTEX_INITIALIZER to qualify for constexpr. Feel free to reply in a fashion where you actually explain your stance instead of just dropping some facts. Otherwise I'll have to guess what you mean, and that prevents me from fixing things the right way.
Re: CVS commit: src/lib/libpthread
Returning to this pickle.
On 26/06/15 18:24, Joerg Sonnenberger wrote:
On Fri, Jun 26, 2015 at 12:49:09PM +, Antti Kantee wrote:
This is the simplest program to repeat the problem with g++ 5.1 and NetBSD's
pthread_types.h:
#include
class foo {
pthread_mutex_t m;
public:
constexpr foo() : m(PTHREAD_MUTEX_INITIALIZER) {}
};
(plus or minus typos since I typed it by hand from the virtual machine
console)
If there's some way to say "pthread_types.h is even more of a system header
than with -isystem and compilers should not generate errors", then I'd like
to hear it.
You don't understand. The system header is not pthread_types.h, it is
.
Also, if this is really the correct DR, I'm not sure how a flaw in the
standard translates to "gcc bug"
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1911
(especially when there's no fix for the defect in the standard)
The fix is to apply the C++14 rules, which is more relaxed.
So, I really don't see how to sweep the issue under the rug except by a)
figuring out a workaround b) labeling all C++ compilers which happen to
implement the current standard as incompatible with NetBSD.
DRs are retroactive, e.g. bug fixes and corrections. As such they are
part of "the current standard" (and of course, it is not the current
standard, since that would be C++14).
I started work on this again by doing a web search for the error, and
found this:
http://bugs.musicpd.org/view.php?id=4110
There you argue that using constexpr for PTHREAD_MUTEX_INITIALIZER is
broken. So if we assume that you are correct, shouldn't we remove the
"constexpr"s from libc++/dist/libcxx/include/__mutex_base?
Re: CVS commit: src/lib/libpthread
This is the simplest program to repeat the problem with g++ 5.1 and
NetBSD's pthread_types.h:
#include
class foo {
pthread_mutex_t m;
public:
constexpr foo() : m(PTHREAD_MUTEX_INITIALIZER) {}
};
(plus or minus typos since I typed it by hand from the virtual machine
console)
If there's some way to say "pthread_types.h is even more of a system
header than with -isystem and compilers should not generate errors",
then I'd like to hear it.
Also, if this is really the correct DR, I'm not sure how a flaw in the
standard translates to "gcc bug"
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1911
(especially when there's no fix for the defect in the standard)
So, I really don't see how to sweep the issue under the rug except by a)
figuring out a workaround b) labeling all C++ compilers which happen to
implement the current standard as incompatible with NetBSD.
Re: CVS commit: src/lib/libpthread
On 26/06/15 11:53, Joerg Sonnenberger wrote: That said, have you verified why it doesn't happen with libstdc++ itself? I would somewhat suspect that the threatment of the header as system header hides the problem for libstdc++, I can't imagine that it can correctly implement the constexpr constructor without performance penalties otherwise... I don't speak C++, but a grep-based guess coupled with common sense suggests that libstdc++ is fine because it doesn't use PTHREAD_MUTEX_INITIALIZER. Not that you can use common sense to reason about C++, but anyway. Also, most likely nobody has tried compiling libstdc++ for NetBSD with the g++ 5 series, and therefore we don't know if it fails or not. Finally, I don't understand why this would be an issue with just libstdc++/libc++ as opposed to any C++ compiled code which uses PTHREAD_X_INITIALIZER (lack of understanding again based on common sense instead of C++ sense).
Re: CVS commit: src/lib/libpthread
On 26/06/15 06:02, Martin Husemann wrote: On Fri, Jun 26, 2015 at 01:38:45AM +, Antti Kantee wrote: On Fri, Jun 26, 2015 at 01:33:09AM +, Antti Kantee wrote: Module Name:src Committed By: pooka Date: Fri Jun 26 01:33:09 UTC 2015 Modified Files: src/lib/libpthread: pthread_types.h Log Message: C++ (namely libc++) expects to be using PTHREAD_FOO_INITIALIZER as a member initializer. This does not work for volatile types. Since C++ does not touch the guts of those types, redefine them as non-volatile. Fixes libc++ compilation with g++ 5.1, as reported in PR lib/49989. Forgot to mention: the patch is from christos (thanks!) Please document this in doc/HACKS, it is an evil hack and IMHO working around a g++ bug. Done, rev 1.160 of doc/HACKS.
Re: CVS commit: src/lib/libpthread
On 26/06/15 07:04, Nick Hudson wrote: On 06/26/15 02:33, Antti Kantee wrote: +# ifdef __CPU_SIMPLE_LOCK_PAD +# define __pthread_spin_t unsigned char +# else +# define __pthread_spin_t unsigned int +# endif Are you sure this "works" for hppa which has funky __cpu_simple_lock_t? Slightly related. arch/arm has: /* * This should have always been an 8-bit type, but since it's been exposed * to user-space, we don't want ABI breakage there. */ #if defined(_KERNEL) typedef volatile unsigned char __cpu_simple_lock_t; #else typedef volatile int__cpu_simple_lock_t; #endif /* _KERNEL */ Should that be no ifdef & __CPU_SIMPLE_LOCK_PAD like everywhere else?
Re: CVS commit: src/lib/libpthread
On 26/06/15 09:14, Joerg Sonnenberger wrote: On Fri, Jun 26, 2015 at 01:33:09AM +, Antti Kantee wrote: Module Name:src Committed By: pooka Date: Fri Jun 26 01:33:09 UTC 2015 Modified Files: src/lib/libpthread: pthread_types.h Log Message: C++ (namely libc++) expects to be using PTHREAD_FOO_INITIALIZER as a member initializer. This does not work for volatile types. Since C++ does not touch the guts of those types, redefine them as non-volatile. Fixes libc++ compilation with g++ 5.1, as reported in PR lib/49989. Please revert this. It is ugly, it breaks the abstraction of the system headers and it is a hackaround for a GCC bug. This should be handled by GCC and only by GCC. The relevant DR against C++11 is core issue #1911. As long as NetBSD's goals include "interoperates well with other systems" and "conforms to open systems standards as much as is practical", the workaround is mandated. It fixes source level interoperation with a contemporary release of a major compiler (fact) and given that it's a few lines to a single file, it's practical (subjective). Of course, I'd *like* to go back in time to fix all bugs, but I'm not high on hopes with that being possible.
Re: CVS commit: src/lib/libpthread
On 26/06/15 07:04, Nick Hudson wrote: On 06/26/15 02:33, Antti Kantee wrote: +# ifdef __CPU_SIMPLE_LOCK_PAD +# define __pthread_spin_t unsigned char +# else +# define __pthread_spin_t unsigned int +# endif Are you sure this "works" for hppa which has funky __cpu_simple_lock_t? You're right, it doesn't, I should've checked more carefully before commit. I improved the definition to not depend on __CPU_SIMPLE_LOCK_PAD and use sizeof+alignof instead. That will keep all ports happy, regardless of how they define __cpu_simple_lock_t and assume it to be aligned. Thanks for catching it.
Re: CVS commit: src/lib/libpthread
On Fri, Jun 26, 2015 at 01:33:09AM +, Antti Kantee wrote: > Module Name: src > Committed By: pooka > Date: Fri Jun 26 01:33:09 UTC 2015 > > Modified Files: > src/lib/libpthread: pthread_types.h > > Log Message: > C++ (namely libc++) expects to be using PTHREAD_FOO_INITIALIZER as a > member initializer. This does not work for volatile types. Since C++ > does not touch the guts of those types, redefine them as non-volatile. > > Fixes libc++ compilation with g++ 5.1, as reported in PR lib/49989. Forgot to mention: the patch is from christos (thanks!)
Re: CVS commit: src/sys
[like pros, we were talking on source-changes list. that wasn't very useful] On 02/12/14 04:28, Ryota Ozaki wrote: On Tue, Dec 2, 2014 at 12:39 PM, Antti Kantee wrote: On 02/12/14 03:30, Ryota Ozaki wrote: The problem is that the real if_drain_all() will never be called in environments with the weak alias problem even if the non-stub implementation is present and it should be called. I'm getting the problem, but I have still one question; why ifnet_list works while if_drain_all doesn't? If you are asking about the linker, ifnet_list is a common symbol, not a weak alias. If you are asking about traversing ifnet_list, semi-accidentally -- the tailq macros happen to work for zero-filled heads unless you try to tailq_insert_tail. I meant the former. Anyway I got it. rumpnet doesn't add any items to ifnet_list, so it works without rumpnet_net. Right, because interfaces don't exist in net, only in net_net (it makes sense if you think about sys vs. sys/net). Actually, looking more closely, it is currently a problem for _all_ platforms since you stubbed it to a panic instead of a nop. Oh, right. I just followed bridge ones... If you look at the history of that file, you will notice that I have been removing __weak_alias() instances. bridge/agr not working on platforms without weak alias support is acceptable (because it never has worked). I hope bridge/agr can be fixed some day, but perhaps they will fix themselves with a more modular networking stack ;) We can get rid of __weak_alias(bridge_input) already :) The other two are...I don't know when it's done :-/ Oh, nice! Can you remove the now-unnecessary weak aliases?
Re: CVS commit: src/sys/net
On 01/12/14 08:01, Martin Husemann wrote: On Mon, Dec 01, 2014 at 11:54:23AM +0900, Ryota Ozaki wrote: BTW, we may need ATF tests to ring the bell for such regressions. This is a bit tricky to do as we do not expose a sane api to create "old binaries" from source. It would boil down to copy & paste of the old structure definition and some magic to test ioctls with them. Testing the ioctls itself against a rump kernel is very simple. But then you'll have to install helpers (like rump.ifconfig but for various ioctl versions) and it quickly gets messy. So no easy/safe/scalable way there that I can see. The other option that comes to mind is running a -current kernel and doing a -7 and -6 release branch test run. Unfortunately that will include all RUMP components from that branch as well, so not test the compatibility we are looking for either. But I guess we should think about rearrangements in this direction to make it easier in the future - starting with a separate rump.tgz set, or maybe a few of them, not sure what granularity would be needed there. 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. The downside to the above approach is that if you want to manually run the tests, you need a -6/-7 installation, but once in the blue moon when it's necessary to run the tests manually instead of relying on automation, you'd just run anita and wait a few minutes. *) ./checkout cvs src HEAD ; ./buildrump.sh fullbuild ^ assuming _on_ -6/-7. Otherwise you also need to set $CC to the appropriate cross compiler before running buildrump.sh.
Re: CVS commit: src/sys/rump/dev
On 18/11/14 09:27, matthew green wrote: "Antti Kantee" writes: Module Name:src Committed By: pooka Date: Tue Nov 18 08:43:03 UTC 2014 Modified Files: src/sys/rump/dev: Makefile.rumpdevcomp Added Files: src/sys/rump/dev/lib/libpci_eap: Makefile PCI_EAP.ioconf eap_at_pci.c joy_eap.h shlib_version Log Message: Add eap PCI audio driver. tested by playing audio with rump kernel booted on qemu with -soundhw es1370 i'm disappointed in you, son, that you don't have the real hardware anymore. Are you upset that I didn't fix the "second DAC sounds like a fish" problem yet? Ask me again in 2024. By then the sea levels will have risen enough that we'll all be talking fish anyway.
Re: CVS commit: src/sys
On 15/11/14 23:46, Takeshi Nakayama wrote: Justin Cormack 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? Is the effect that the smbfs driver has more functionality when it is run in a rump kernel than when it is run in the NetBSD kernel? That is not a good change. In addition to reason "2" cited above, there is a usability problem: mount with and without "-o rump" is supposed to provide the same functionality. If "-o rump" starts meaning "with working iconv", it will make configuration and documentation difficult. While it is possible to add compile-time conditionals to the effect that your change does not per se break anything, I would rather see a fix which also works with mount_smbfs.
Re: CVS commit: src/usr.bin/config
On 30/10/14 17:28, Masao Uebayashi wrote: Is there a problem rototilling config is going to solve over what is possible with the existing mechanism (*)? You're welcomed to fix any problems without rotorill and/or breakage. You're not answering the question. *) you probably also heard that rump kernels have constructors with priority levels, implemented using link sets Do you hardcode the priority? Yes. They are easy to hardcode, as you can observe from working code, and I don't see the need for a complex mechanism. There's really only ~10, and even less for the full kernel, since you don't need to worry about things like "will vfs be present" or "when do i configure the address for lo0". Even if you'd want to worry about for example the latter one, how would you express it with config? But let's consider some magic values are generated by config in a fashion which works in a non-monolithic build. How will anything be different if you touch or don't touch linksets, i.e. how is your question relevant in this discussion? Cleaning up init_main() is an ambitious project. I don't know if config is the right tool for that (I don't know it's _not_, either). I do know that it's complete orthogonal to how linksets are implemented.
Re: CVS commit: src/usr.bin/config
On Thu, Oct 30, 2014 at 11:14:50AM +0900, Masao Uebayashi wrote: > On Thu, Oct 30, 2014 at 10:51 AM, Christos Zoulas wrote: > > In article <20141030012621.0982...@cvs.netbsd.org>, > > Masao Uebayashi wrote: > > > > Re: constructors/destructors: > > > > Using them will create a portability constraint on elf. This has > > the implication that rump will not work on some platforms. > > Could you show me an example failure senario? What do you propose instead? > > I heard that rump fixed linkset problem using .ctors/.dtors. I heard something different. A toolchain problem was fixed by using __attribute__((constructor)) to reach the contents of link sets in userspace dynamically linked environments where generating __start/__stop was not possible. Regular link sets are still preferred, as they require less magic from the runtime. Is there a problem rototilling config is going to solve over what is possible with the existing mechanism (*)? The problem TODO lists is "random ELF sections (with potentially long names) in the final kernel". Is that a problem? *) you probably also heard that rump kernels have constructors with priority levels, implemented using link sets
Re: CVS commit: src/lib/librumpuser
On 17/06/14 11:52, Alexander Nasonov wrote: That's one more indication that "sync icache" is the wrong level of problem to represent at the interface level. Existence of __clear_cache is an indication of the opposite. Let's be thankful we're not discussing implementing a compiler. If it were a high-level, holistic interface, both the caller and callee would what needs to be done, and the caller could perhaps implement the same with a alternative method. A low-level interface like "sync icache for this memory range" leaves no room for interpretation, even if it will ever be used for only one purpose. Not quite sure what you're saying because no room for interpretation is a good thing in general and using something for one purpose is even better ;-) Ok, one more try, this time with an example: * fact: interface will be used to say "I have loaded code here, please arrange things so that it can be executed" * fact: you want to call the interface "sync icache" and possess those semantics the example: Let's assume some fictional platform where you need to sign newly loaded code before it can execute. Should the implementation of "sync icache" on that platform sign code? If not, you can't execute the code, which was the original purpose. If yes, you've failed to implement the interface correctly, because that might not be what the caller wants at all. Will such a platform be supported? Who knows. Is it cause to leave known problems into the interface? Definitely not! If you don't want to solve anything except your immediate problem, that's more than fair enough (we've all been there), but it needs to be done without breaking things for everyone else or knowingly introducing suboptimal interfaces that everyone else will suffer from.
Re: CVS commit: src/lib/librumpuser
On 17/06/14 11:23, Alexander Nasonov wrote: If you don't have time to wait for discussion or coordination, do everything in the privacy of the sljit component. Please teach me how to create a private component. Use RUMPCOMP_USER_SRCS, several examples under src/sys/rump I'm not saying that librumpuser must be POSIX. I'm not sure where you're getting that from. rumpuser(3): DESCRIPTION The rumpuser hypercall interfaces allow a rump kernel to access host resources. A hypervisor implementation must implement the routines described in this document to allow a rump kernel to run on the host. The implementation included in NetBSD is for POSIX hosts. ^ ^ ic. I'd change that to POSIX-like, but currently I cannot access nbcvs. and it indeed broke buildrump.sh builds on Linux because sysarch stuff isn't available. There is no way I can make this interface POSIX-compatible because POSIX doesn't specify icache sync as far as I know. That's one more indication that "sync icache" is the wrong level of problem to represent at the interface level. If it were a high-level, holistic interface, both the caller and callee would what needs to be done, and the caller could perhaps implement the same with a alternative method. A low-level interface like "sync icache for this memory range" leaves no room for interpretation, even if it will ever be used for only one purpose.
Re: CVS commit: src/lib/librumpuser
On 17/06/14 09:46, Alexander Nasonov wrote: Antti Kantee wrote: To be clear: the objection was to modifying a stable interface without coordination. The hypercall interface is implemented in multiple places outside of the NetBSD tree, including by 3rd parties. Stable interface in -current? How are you supposed to make any significant changes then? > As I stated in the private email to Antti, we need to support two versions: stable for users and current for developers. Otherwise, it will block a development of NetBSD if every time you need to make a change in NetBSD-current, you have to wait for a rumpuser bump for stable users even though many of them are outside of NetBSD. > In other words, don't rely on NetBSD-current being 100% stable, especially for users outside of NetBSD. I don't know enough details about rump to be certain but would splitting only rumpuser into two versions work? If there were two versions of rumpuser I could tweak the makefile to build cpufunc.c only if MKSLJIT=yes and it would solve the problem because MKSLJIT is "no" by default on arm. I think that will be overengineering it, but if you want to come up with a concrete proposal patch, please. I'd simply use discussion and not rushing commits to avoid issues here. If you don't have time to wait for discussion or coordination, do everything in the privacy of the sljit component. In either case, there's no need for the "blocking development" drama card. Another reason for splitting rumpuser is because some hypercalls can't be implemented with POSIX API. I don't think we need to support Linux or Solaris in NetBSD tree, especailly if it depends on OS-specific code. I don't think we need to support Linux or Solaris in the NetBSD tree. Similarly, I don't think we need to make changes which _unnecessarily_ makes supporting them hard. Think of it like changing the libc ABI: no matter the merits of the change itself (which they too remain to be discussed), it will be objected to. I got an impression from your private email yesterday that the approach is correct (you didn't say that librumpuser code must be POSIX while the code I sent to you wasn't as it used NetBSD specific sysarch syscall). For reference, here's what I wrote: === snip === If the problem is syncing icache, the approach is correct. However, I'd argue that the problem is dynamically loading code into a rump kernel, and with that the interface falls somewhat short. What if someone wants W^X? === snip === If you understood that as "go ahead", sorry for not being clear, "falls short" was the comment that I was trying to ease in. I'm not saying that librumpuser must be POSIX. I'm not sure where you're getting that from. What I _am_ saying is that there must be some critical thought going in to the interfaces and their implications. We're several years past the "oh I'll just add this because I need it today" stage of discovery. And because it was a pure addition of a new function and it didn't break NetBSD build, I assumed that it's safe to add it. The only thing I didn't do was rumpuser ABI version bump. It's a pure addition in the same sense as if you made a pure addition to NetBSD's Xen hypercall interface and made guests unconditionally use it. It would not break the NetBSD build. Would you assume that's a safe change to make?
Re: CVS commit: src/lib/librumpuser
On Tue, Jun 17, 2014 at 08:42:35AM +, Alexander Nasonov wrote: > Module Name: src > Committed By: alnsn > Date: Tue Jun 17 08:42:35 UTC 2014 > > Modified Files: > src/lib/librumpuser: Makefile > > Log Message: > Antti objected to including rumpuser_sync_icache. Exclude it from the build. To be clear: the objection was to modifying a stable interface without coordination. The hypercall interface is implemented in multiple places outside of the NetBSD tree, including by 3rd parties. Think of it like changing the libc ABI: no matter the merits of the change itself (which they too remain to be discussed), it will be objected to.
Re: CVS commit: src/sys
On 26/05/14 19:38, David Holland wrote: On Sun, May 25, 2014 at 04:31:51PM +, Antti Kantee wrote: > Modified Files: > src/sys/kern: subr_devsw.c vfs_bio.c > src/sys/rump/librump/rumpkern: rump.c > > Log Message: > Call biodone() in the bdev_strategy() error via a pointer. Decouples > subr_devsw from VFS -- not that I/O buffers are _VFS_ entities -- Yes they are... so are devsw entries, for that matter. Fact: tcp/ip + bpf (accessed via devsw) works fine without VFS. Let's keep it that way. E.g. IoT folks looking at using the NetBSD TCP/IP stack in their [high-end] devices wouldn't be too thrilled if the memory requirement for networking grew by 100% just because. I have no idea how you expect buffer ops to be able to work without biodone I don't expect it to work, it's just to appease linkage for e.g. the above-mentioned bpf+networking case. In the current state of things, you can't create a "struct buf" without vfs_bio.c, so you'll not be calling bdev_strategy().
Re: CVS commit: src
On Tue, Apr 29, 2014 at 06:51:57AM +, Masao Uebayashi wrote: > Module Name: src > Committed By: uebayasi > Date: Tue Apr 29 06:51:57 UTC 2014 > > Modified Files: > src: build.sh > > Log Message: > resolvepath: Resolve .. in absolute paths. > > > To generate a diff of this commit: > cvs rdiff -u -r1.278 -r1.279 src/build.sh This breaks ./build.sh -w
Re: CVS commit: src/include/ssp
On 25/04/14 18:00, Christos Zoulas wrote: In article <20140425171614.ga22...@britannica.bec.de>, Joerg Sonnenberger wrote: On Thu, Apr 24, 2014 at 08:12:56PM +, Antti Kantee wrote: Module Name:src Committed By: pooka Date: Thu Apr 24 20:12:56 UTC 2014 Modified Files: src/include/ssp: string.h Log Message: Wrap stpncpy() iff GNUC_PREREQ(4,8). Fixes USE_SSP=yes builds with gcc 4.5. This produces a regerssion for clang users. Yes, what are you trying to fix? The thing stated in the commit message: "USE_SSP=yes builds with gcc 4.5"
Re: src/sys (removal of sysctl "redundancies" breaks modular spdmem)
On 14/04/14 14:19, Paul Goyette wrote: Module Name:src Committed By: pooka Date: Tue Feb 25 18:30:14 UTC 2014 Modified Files: ... src/sys/dev/ic: an.c ath_netbsd.c bwi.c rtw.c spdmem.c wi.c ... Log Message: Ensure that the top level sysctl nodes (kern, vfs, net, ...) exist before the sysctl link sets are processed, and remove redundancy. Shaves >13kB off of an amd64 GENERIC, not to mention >1k duplicate lines of code. The removal of the SYSCTL_INIT stuff breaks use of (at least) spdmem as a kernel module. The following error occurs during modload: kobj_checksyms, 880: [spdmem]: linker error: symbol `sysctl_spdmem_setup' not found WARNING: module error: unable to affix module `spdmem', error 8 I have not checked any of the other affected files to see if they are also used as modules (and thus would suffer similar breakage). Can you please either come up with an alternative mechanism for the modular version of spdmem, or revert this fix? fixed. thanks for the report.
Re: CVS commit: src/sys
On 01/02/2014 06:48 PM, Valery Ushakov wrote: Log Message: Allow kernels compiled with INET+INET6 to be booted as IPv4-only or IPv6-only. Forgot to explicitly #include ? hpcsh GENERIC fails with: /usr/home/buildbot/slave2/src/sys/netinet/tcp_subr.c: In function 'tcp_init_common': /usr/home/buildbot/slave2/src/sys/netinet/tcp_subr.c:446:3: error: implicit declaration of function 'atomic_cas_uint' --- tcp_subr.o --- *** [tcp_subr.o] Error code 1 Ah, the good old "x86 pmap leaks atomic.h" gotcha. Fixed, thanks.
Re: CVS commit: src
On 16.11.2013 11:06, Alexander Nasonov wrote: +./usr/lib/librumpkern_sljit.so base-rump-shlib rump +./usr/lib/librumpkern_sljit.so.0 base-rump-shlib rump +./usr/lib/librumpkern_sljit.so.0.0 base-rump-shlib rump A similar change was sitting in my local tree for quite a while but sljit API isn't yet stable enough to wrap it into a DSO. I kept bpbfjit and libsljit private (LIBISPRIVATE=yes) and used them only for libsljit and libbpfjit tests. Is it possible to do something similar in rump framework? There is no rump kernel ABI in the normal lib.so.1.2.3 sense. The public ABIs (e.g. syscall) are stable, but any in-kernel ABIs are subject to the same rules as for kernel modules. Technically, it would be more correct to install rump kernel components into something like /usr/lib/x.yy.z (cf. /stand/modules), but so far it hasn't been an issue. So, in my opinion, there is no need to excessively worry about compat in librumpfoo_sl/bpfjit, unless you explicitly want to expose an ABI from there to userspace processes.
Re: CVS commit: src/sys/rump
On 4.7.2013 15:05, Valery Ushakov wrote: Ah, I was confused because just before that I was staring at FreeBSD bsd.sys.mk which does use CWARNFLAGS for -W* and then looked at -Werror in ours. History says: revision 1.26 date: 1998-08-25 18:57:21 +0400; author: tv; state: Exp; lines: +3 -2; Introduce CWARNFLAGS, idea from kernel Makefiles, which goes after "-Wall ..." in the CFLAGS and can be set in directory Makefile or mk.conf. incidentally, the reason I was looking at FreeBSD bsd.sys.mk was precisely that I needed to disable one of the warning options but they append them to CWARNFLAGS overriding your settings instead. I'll see your FreeBSD plight and raise with similar issues in autotools ;) Anyway, thanks for the info, makes sense.
Re: CVS commit: src/sys/rump
On 4.7.2013 14:53, Valery Ushakov wrote:
On Thu, Jul 04, 2013 at 10:14:04 +, Antti Kantee wrote:
Module Name:src
Committed By: pooka
Date: Thu Jul 4 10:14:04 UTC 2013
Modified Files:
src/sys/rump: Makefile.rump
Log Message:
Apparently warning flags are not kept in CWARNFLAGS. Compensate.
Would you care to elaborate? Do you refer to the fact that bsd.sys.mk
adds -Werror to CFLAGS instead of CWARNFLAGS?
CFLAGS+=${${_NOWERROR} == "no" :?-Werror:} ${CWARNFLAGS}
That and this:
.if ${WARNS} > 1
CFLAGS+=-Wreturn-type -Wswitch -Wshadow
.endif
.if ${WARNS} > 2
CFLAGS+=-Wcast-qual -Wwrite-strings
CFLAGS+=-Wextra -Wno-unused-parameter
# Readd -Wno-sign-compare to override -Wextra with clang
CFLAGS+=-Wno-sign-compare
[...]
Re: CVS commit: src/sys/kern
On 11.03.2013 23:56, YAMAMOTO Takashi wrote: Module Name:src Committed By: pooka Date: Mon Mar 11 21:37:54 UTC 2013 Modified Files: src/sys/kern: subr_pool.c Log Message: In pool_cache_put_slow(), pool_get() can block (it does mutex_enter()), so we need to retry if curlwp took a context switch during the call. Otherwise, CPU-local invariants can get screwed up: panic: kernel diagnostic assertion "cur->pcg_avail == cur->pcg_size" failed This is (was) very easy to reproduce by just running: while : ; do RUMP_NCPU=32 ./a.out ; done where a.out only calls rump_init(). But, any situation there's contention and a pool doesn't have emptygroups would do. depending on mutex_init's arguments (type and ipl), a mutex can be spin or adaptive. rump mutex implementation should honor the behaviour, i guess. Oh bummer, forgot that mutex_enter() can be a spin mutex entry. Yea, I'll fix that soon and convert the otherwise harmless back-off to a KASSERT() -- I found some similar invariant failures with a websearch, so it might be a common problem. - antti
Re: CVS commit: src/external/cddl/osnet/sys/sys
On 03.01.2013 17:59, David Laight wrote: On Thu, Jan 03, 2013 at 04:42:55PM +, David Laight wrote: Module Name:src Committed By: dsl Date: Thu Jan 3 16:42:55 UTC 2013 Modified Files: src/external/cddl/osnet/sys/sys: random.h Log Message: Use cprgn_fast() not rnd_extract_data(). The latter isn't in any header files any more. It should be noted that this breaks builds with rump. It also breaks in all other cases. That's what committing broken changes does. I've NFI how to resolve the missing dependency on rumpns_cprng_fast(). Wild idea: spell "rng" correctly.
Re: CVS commit: src/share/mk
On 11.12.2012 00:25, matthew green wrote: Module Name:src Committed By: pooka Date: Mon Dec 10 20:58:55 UTC 2012 Modified Files: src/share/mk: bsd.gcc.mk Log Message: Deal with crti and crtn not present in some EXTERNAL_TOOLCHAIN's. Also, handle "missing" crtstuff internally instead of depending on external intervention. what is this change for? So that you don't get bogus dependencies. using sed here is wrong, irrespective of the comment reason you've given. if TOOL_SED isn't available, we shouldn't even be processing this file yet. that seems like the fix you should look for here. If using sed here is wrong, then using sed instead of TOOL_SED in the multiple configure scripts under src/tools is wrong too. Do you want to fix those first? what is this EXTERNAL_TOOLCHAIN you're using? i'm totally at a loss what this change is useful for besides re-adding a host dependancy on sed. The solaris/cygwin toolchains, e.g.: $ cc --print-file-name=crtbegin.o /usr/local/lib/gcc/sparc-sun-solaris2.10/4.4.4/crtbegin.o $ cc --print-file-name=crtbeginS.o crtbeginS.o
Re: CVS commit: src/include (commaize_number)
On Tue Mar 15 2011 at 05:33:16 -0700, Paul Goyette wrote:
> On Tue, 15 Mar 2011, Antti Kantee wrote:
>
> >On Tue Mar 15 2011 at 05:25:51 -0700, Paul Goyette wrote:
> >>>Module Name:src
> >>>Committed By: pooka
> >>>Date: Tue Mar 15 12:21:08 UTC 2011
> >>>
> >>>Modified Files:
> >>> src/include: stdlib.h
> >>>
> >>>Log Message:
> >>>put in a proto for commaize_number()
> >>>(nb. doing this purely as the minimum work solution to get a working
> >>>build)
> >>
> >>
> >>Maybe we shouldn't fix the build here, since there's also the issue of
> >>bumping the minor version of libc which was not done. With a build
> >>break we don't have any compatability issues, but if we let a working
> >>build "ship" with this, don't we have to keep it ~forever?
> >
> >There's honoring compatibility and then there's just being silly.
>
> OK, color me "silly" !:)
if you want to be colored with a blue ribbon, there's always the option
of backing out the changes -- from what i quickly observed, that's the
current consensus and would also address your ("silly" ;) concern.
--
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/include (commaize_number)
On Tue Mar 15 2011 at 05:25:51 -0700, Paul Goyette wrote: > >Module Name:src > >Committed By: pooka > >Date: Tue Mar 15 12:21:08 UTC 2011 > > > >Modified Files: > >src/include: stdlib.h > > > >Log Message: > >put in a proto for commaize_number() > >(nb. doing this purely as the minimum work solution to get a working build) > > > Maybe we shouldn't fix the build here, since there's also the issue of > bumping the minor version of libc which was not done. With a build > break we don't have any compatability issues, but if we let a working > build "ship" with this, don't we have to keep it ~forever? There's honoring compatibility and then there's just being silly. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/sys/rump/net/lib/libshmif
On Fri Mar 11 2011 at 20:37:47 +0300, Alexander Nasonov wrote: > 11.03.2011, 12:26, "Antti Kantee" : > > Log Message: > > Don't assume rump kernel PAGE_SIZE and host page size are the same. > > Why can they be different? I asked myself this question when I was writing For example on SPARC page size depends on the model of hardware you're running on instead of being a compile-time constant (unless you configure your kernel only for a specific model). Now, since the rump kernel does not manage memory in the same sense as a "regular" kernel does, PAGE_SIZE is totally arbitrary. It's just some unit of granularity for calling the host's malloc() and remains constant throughout the life cycle of the kernel instance. It might as well be defined to be 32k or 1k on all archs, but that means waging war on the arch's headers, so it's just easier to play along with whatever we get. In the shmif initialization routine we are trying to fault in all of the *host's* pages for the bus file. We could add a rumpuser_getpagesize(), but since it makes really no difference if we do 512b or pagesize increments, at least the shmif case doesn't justify adding it. The commit didn't fix any bugs, but it's just "more correct" than going in PAGE_SIZE pieces. > a tests for kern/44310: write to /dev/bpf truncates size_t to int. > In the end, I just used sysconf(_SC_PAGE_SIZE). If rump_sysconf doesn't > exist, should it be added? Since you are calling mmap() on the host, you want to use host's page size (although, i guess, technically it doesn't matter since you can't map less than one page of memory anyway). Technically you should be using the rump kernel's IOV_MAX, though, since you are passing that to rump_sys_writev(). -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Fri Mar 11 2011 at 03:34:47 +0300, Valeriy E. Ushakov wrote: > On Thu, Mar 10, 2011 at 23:02:56 +0000, Antti Kantee wrote: > > > Use rumphijack_dlsym() to figure out where __sysctl() is during > > init. Otherwise powerpc dlsym() DTWT and returns NULL. > > (now i have no idea why dlsym() it works from rcinit(), but i'll > > opt to not care) > > I don't remember if I brought this up here already, but I strongly > suspect suspect that libexec/ld.elf_so/rtld.c > > revision 1.121 > date: 2008/09/27 03:52:05; author: macallan; state: Exp; lines: +15 -3 > avoid usind __builtin_return_address(0) on PowerPC because it fails in > Xorg's module loader. > Should fix PR37812 > > broke it (hi, Mac!). IIRC, it tries to work around dlsym in tail call > position (badness!) and "fixes" it only by chance, causing grief > elsewhere. If there only were a test, someone could try to fix things without worrying about reintroducing the original problem again ... -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src
Actually, I misread some stuff. n/m && sorry for the noise. On Thu, Mar 10, 2011 at 01:50:37PM +0000, Antti Kantee wrote: > On Wed, Mar 09, 2011 at 11:10:09PM +, Joerg Sonnenberger wrote: > > Log Message: > > Add TLS support infrastructure. For dynamic binaries, ld.elf_so exports > > _rtld_tls_allocate and _rtld_tls_free. libpthread uses this functions to > > setup the thread private area of all new threads. ld.elf_so is > > responsible for setting up the private area for the initial thread. > > Similar functions are called from _libc_init for static binaries, using > > dl_iterate_phdr to access the ELF Program Header. > > > > Add test cases to exercise the different TLS storage models. Test cases > > are compiled and installed on all platforms, but are skipped on > > platforms not marked for TLS support. > > You are "skipping" them on all platforms due to using SUBDIR instead > of TESTS_SUBDIR (SUBDIR doesn't get added to Atffile). Was this > your intention?
Re: CVS commit: src
On Wed, Mar 09, 2011 at 11:10:09PM +, Joerg Sonnenberger wrote: > Log Message: > Add TLS support infrastructure. For dynamic binaries, ld.elf_so exports > _rtld_tls_allocate and _rtld_tls_free. libpthread uses this functions to > setup the thread private area of all new threads. ld.elf_so is > responsible for setting up the private area for the initial thread. > Similar functions are called from _libc_init for static binaries, using > dl_iterate_phdr to access the ELF Program Header. > > Add test cases to exercise the different TLS storage models. Test cases > are compiled and installed on all platforms, but are skipped on > platforms not marked for TLS support. You are "skipping" them on all platforms due to using SUBDIR instead of TESTS_SUBDIR (SUBDIR doesn't get added to Atffile). Was this your intention?
Re: CVS commit: src/sys/sys
On Wed Mar 09 2011 at 13:45:37 -0800, Matt Thomas wrote: > > On Mar 9, 2011, at 1:14 PM, matthew green wrote: > > > > >> Module Name: src > >> Committed By: pooka > >> Date: Wed Mar 9 19:02:04 UTC 2011 > >> > >> Modified Files: > >>src/sys/sys: param.h > >> > >> Log Message: > >> Bump version for new quota code -- even if ABIs didn't change, it's > >> still a major feature. > > > > we haven't done this in the past and now i have to rebuild tools and > > my module dirs are out of date again. > > Sigh. param.h is not supposed to reflect features changes only ABI > incompatibilities. are you worried we going to run out of numbers tomorrow? How else should one know the new quotactl is present? running awk on the headers? i could understand whineage if we had the ever-elusive stable kernel ABI, but then we'd have some other method of conveying that information, right? -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/usr.bin/quota
On Sun, Mar 06, 2011 at 09:12:49PM +, Christos Zoulas wrote: > In article <20110306205803.ga15...@antioche.eu.org>, > Manuel Bouyer wrote: > >On Sun, Mar 06, 2011 at 03:48:00PM -0500, Christos Zoulas wrote: > >> Module Name: src > >> Committed By: christos > >> Date: Sun Mar 6 20:47:59 UTC 2011 > >> > >> Modified Files: > >>src/usr.bin/quota: Makefile getvfsquota.c getvfsquota.h printquota.c > >>printquota.h quota.c > >> > >> Log Message: > >> - WARNS=4 > >> - KNF > >> - don't cast malloc > >> - don't use static buffers > >> - fix types > >> - remove extra \n's from errors > >> - fix prototypes > > > >this breaks the build. These utitilies are used bu other quota tools. > >Why did you #if 0 timepprt() ? it's used by edquota > > I'll add them back. Can you also fix fallout so that tests pass once again? http://www.gson.org/netbsd/bugs/build/build/2011.03.07.03.29.26/test.html#failed-tcs-summary tests last passed here: http://www.gson.org/netbsd/bugs/build/build/2011.03.06.20.36.29/test.html
Re: CVS commit: src/sys/arch/amd64/include
On Fri Mar 04 2011 at 13:59:34 +0100, Joerg Sonnenberger wrote:
> > > > >Log Message:
> > > > >Reduce MAXSSIZ to 64MB, otherwise netbsd32 binaries crash in ld.elf_so,
> > > > >including the trivial main(){}. Add a warning to not modify this
> > > > >without
> > > > >testing compatibility mode.
> > > > >
> > > >
> > > > Please revert this. The 32 bit emulation is supposed to be using
> > > > MAXSSIZ32.
> > >
> > > Feel free to revert the change after testing that it actually works.
> > > I've spend enough time looking for the regression.
> >
> > If only we had some infrastructure for periodically testing that a program
> > compiled with -m32 works on amd64! Good thing that it's not my time being
> > wasted or I'd try to prevent it from happening in the future.
>
> You mean like "build i386, copy tests.tgz, done"?
Being lazy, personally I'd start with the minimum effort which would have
caught the regression: a test case which compiles hello.c with -m32 and
runs it.
(I'm not saying that it would not be worthwhile to run all tests with
compat32, but I am saying that it's more important to have some test
today than wait 10 years for the perfect set of tests... because then
we'd need compat64 too ;)
--
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/sys/arch/amd64/include
On Fri Mar 04 2011 at 11:42:10 +0100, Joerg Sonnenberger wrote:
> On Fri, Mar 04, 2011 at 04:33:17AM +, Christos Zoulas wrote:
> > In article <20110304033425.0e01017...@cvs.netbsd.org>,
> > Joerg Sonnenberger wrote:
> > >-=-=-=-=-=-
> > >
> > >Module Name: src
> > >Committed By: joerg
> > >Date: Fri Mar 4 03:34:24 UTC 2011
> > >
> > >Modified Files:
> > > src/sys/arch/amd64/include: vmparam.h
> > >
> > >Log Message:
> > >Reduce MAXSSIZ to 64MB, otherwise netbsd32 binaries crash in ld.elf_so,
> > >including the trivial main(){}. Add a warning to not modify this without
> > >testing compatibility mode.
> > >
> >
> > Please revert this. The 32 bit emulation is supposed to be using MAXSSIZ32.
>
> Feel free to revert the change after testing that it actually works.
> I've spend enough time looking for the regression.
If only we had some infrastructure for periodically testing that a program
compiled with -m32 works on amd64! Good thing that it's not my time being
wasted or I'd try to prevent it from happening in the future.
--
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/sys/fs/msdosfs
On Thu Mar 03 2011 at 09:00:39 +, Matthias Scheler wrote: > On Thu, Mar 03, 2011 at 08:10:45AM +0000, Antti Kantee wrote: > > Module Name:src > > Committed By: pooka > > Date: Thu Mar 3 08:10:45 UTC 2011 > > > > Modified Files: > > src/sys/fs/msdosfs: msdosfs_vnops.c > > > > Log Message: > > In rename, use char[12]?for new names instead of [11]. At least > > one routine called from here (unix2dosfn) expects and uses all of > > a [12]. > > > > This may fix the "stack size exceeded" problem which has been > > triggering in gson's test runs. (i'm not entirely sure why it > > doesn't trigger in anyone else's env) > > Is he perhaps using "USE_SSP=yes"? Isn't that the default? I certainly don't disable it explicitly when I do a build. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Sun Feb 27 2011 at 08:12:37 +0300, Valeriy E. Ushakov wrote:
> On Fri, Feb 25, 2011 at 16:01:42 +0000, Antti Kantee wrote:
>
> > Module Name:src
> > Committed By: pooka
> > Date: Fri Feb 25 16:01:42 UTC 2011
> >
> > Modified Files:
> > src/lib/librumphijack: Makefile hijackdlsym.c
> >
> > Log Message:
> > Ok, for reasons I can't begin to understand, the binaries I tested
> > yesterday on powerpc broke overnight. Apparently adding one more
> > function before the call to dlsym() fixes things again. I hope
> > I don't have to add another one tomorrow
> >
> >
> > To generate a diff of this commit:
> > cvs rdiff -u -r1.7 -r1.8 src/lib/librumphijack/Makefile
> > cvs rdiff -u -r1.1 -r1.2 src/lib/librumphijack/hijackdlsym.c
>
> I think this is caused by revision 1.121 of rtld.c (hi, mac!) that
> added "hackish_return_address" for ppc.
>
> #ifdef __powerpc__
> static void *
> hackish_return_address(void)
> {
> return __builtin_return_address(1);
> }
> #endif
>
> void *
> dlsym(void *handle, const char *name)
> {
> ...
> #ifdef __powerpc__
> retaddr = hackish_return_address();
> #else
> retaddr = __builtin_return_address(0);
> #endif
> ...
> }
>
>
> hackish_return_address will be inlined (simple static function) and,
> as far as I can tell, gcc does NOT adjust the "level" argument to
> __builtin_return_address.
>
> The net effect is that dlsym uses caller's caller address to detect
> which module the call comes from, and if caller's caller is in a
> different module wrong things happen.
>
> That explains why you need an extra frame.
What I really can't understand is that I have a very distinct impression
that things worked on Thursday (and screencaps to show it). Then, after
riz installed a new userland, things were broken on Friday. However,
I was using the same ld.elf_so binary I had compiled for debugging,
so it cannot be that the new toolchain inlined the call while the old
one didn't.
Anyway, apparently I don't have to put yet another callframe there,
since things are still working ;)
http://www.netbsd.org/~riz/macppc-atf/
Btw, if someone is looking for something interesting, look at the
posix_fadvise test.
--
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src
On Fri Feb 25 2011 at 22:06:32 +0100, Joerg Sonnenberger wrote: > On Fri, Feb 25, 2011 at 04:38:54PM +0200, Antti Kantee wrote: > > On Fri Feb 25 2011 at 15:19:30 +0100, Joerg Sonnenberger wrote: > > > I get time outs for stress_long and stress_short (rump/rumpkern/t_sp). > > > > Those are because of, from what I could tell, this: > > > > 0xbbbd45c5 : mov%gs:0x0,%edi > > ==> segfault > > > > Notably, those tests exercise threads and processes more heavily than > > any other test we have: they create 256 concurrent racing threads over > > several processes which are killed and recreated. > > Are you sure about that? libpthread should be the only thing (before the > back out) that touches %gs and the kernel is normally using %fs for CPU > local memory. I'm sure as in "run test, see h_stresscli crash, gdb core, x/i $eip". I didn't examine it any further. The test fails with the lwp fastreg stuff and doesn't fail without it, that i am sure it. ( is probably gdb's imagination, though) -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src
On Fri Feb 25 2011 at 15:19:30 +0100, Joerg Sonnenberger wrote: > I get time outs for stress_long and stress_short (rump/rumpkern/t_sp). Those are because of, from what I could tell, this: 0xbbbd45c5 : mov%gs:0x0,%edi ==> segfault Notably, those tests exercise threads and processes more heavily than any other test we have: they create 256 concurrent racing threads over several processes which are killed and recreated. > I see a number of failing rumphijack test cases (t_vfs cpcopy, mv_nox, > mv_x, paxcopy). Those I didn't investigate because they appear amd64-only. They are new tests, so there might be something else wrong with them too, but I can't see anything else immediately suspicious in the commit window after which they started crashing. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src
On Fri Feb 25 2011 at 12:36:07 +0200, Jukka Ruohonen wrote: > On Thu, Feb 24, 2011 at 04:45:30PM +0100, Joerg Sonnenberger wrote: > > pretty much unchanged. Feel free to perform benchmarks if you want. > > There are also changes to EST in that time window... > > This must be a bad joke. The things I did were just simple refactoring. > As you should be well aware of, with est(4) and powernow(4) the frequencies > are touched only by an explicit request from the system administrator (or > possibly, estd(1)). Nothing like this could have happened from my changes. Don't worry, it is. Andreas performed a run with a more exact timestamp, and everyone can see for themselves: http://www.gson.org/netbsd/bugs/build/commits-2011.02.html Scroll down to 2004.02.24. Our commit guidelines say that changes which cause unhandled test regressions will be backed out, so I want to see the issue investigated and addressed instead of indifference and excuses. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src
On Thu Feb 24 2011 at 04:28:50 +, Joerg Sonnenberger wrote: > Log Message: > Allow storing and receiving the LWP private pointer via ucontext_t > on all platforms except VAX and IA64. Add fast access via register for > AMD64, i386 and SH3 ports. Use this fast access in libpthread to replace > the stack based pthread_self(). Implement skeleton support for Alpha, > HPPA, PowerPC, SPARC and SPARC64, but leave it disabled. > > Ports that support this feature provide __HAVELWP_GETPRIVATE_FAST in > machine/types.h and a corresponding __lwp_getprivate_fast in > machine/mcontext.h. Did you run benchmarks? The initial data is quite alarming: Starting from a window including this commit gson's test run timeouts due to taking too long. Pgoyette's amd64 test run with sources from 2011-02-24 04:20:03 UTC took 1:20h to complete and sources from 2011-02-24 09:20:03 UTC took 1:47h to complete. Also, a few test failures seemed to pop up. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Wed Feb 23 2011 at 01:31:51 +, YAMAMOTO Takashi wrote: > > On Mon Feb 21 2011 at 23:19:47 +, YAMAMOTO Takashi wrote: > >> > Module Name: src > >> > Committed By:pooka > >> > Date:Mon Feb 7 19:34:39 UTC 2011 > >> > > >> > Modified Files: > >> > src/lib/librumphijack: hijack.c > >> > > >> > Log Message: > >> > Force gcc to generate a stack frame for the call to dlsym(RTLD_NEXT). > >> > Without this hack at least amd64 -O2 just used jmp and The Wrong > >> > Thing happened. > >> > >> do you want -fno-optimize-sibling-calls ? > > > > Without doing a test-compile, looks like it. I guess I'll have to move > > that function to its own source module, or is there a way to enable > > it per-function? > > i don't think there's a way for our version of gcc to make it per-function. > later versions have "optimize" function attribute. > the real fix here would be an attibute for dlsym, not for a caller of it, tho. Proposing RTLD_NEXT-FROM-HANDLE was out of the scope of what I wanted to tackle here. If someone implements it, I'll be happy to use it, though ;) Anyway, i'm guessing things work more certainly now that i committed the -fno-sibling stuff. And if they don't (e.g. with other compilers), we have a test which lets us know. thanks -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Mon Feb 21 2011 at 23:19:47 +, YAMAMOTO Takashi wrote: > > Module Name:src > > Committed By: pooka > > Date: Mon Feb 7 19:34:39 UTC 2011 > > > > Modified Files: > > src/lib/librumphijack: hijack.c > > > > Log Message: > > Force gcc to generate a stack frame for the call to dlsym(RTLD_NEXT). > > Without this hack at least amd64 -O2 just used jmp and The Wrong > > Thing happened. > > do you want -fno-optimize-sibling-calls ? Without doing a test-compile, looks like it. I guess I'll have to move that function to its own source module, or is there a way to enable it per-function? -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/sys/arch/amd64/conf
On Sun Feb 20 2011 at 17:15:57 +0100, Jean-Yves Migeon wrote: > => 1.3MiB. So, a total of 1.3M + 700k = 2MiB. Still missing 1.5MiB. > MODULAR options seems to consume ~70kiB , so I would assume that the > rest is due to PIC mode and ELF headers... ? Dunno where the space is going, but it's certainly not PIC overhead, since the kernel or kernel modules are not PIC. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/sys/arch/amd64/conf
On Sun Feb 20 2011 at 07:19:03 -0800, Paul Goyette wrote: > On Sun, 20 Feb 2011, Jukka Ruohonen wrote: > > >On Mon, Feb 21, 2011 at 01:45:01AM +1100, matthew green wrote: > >>well, i dunno about others but i've found that the old modules > >>lying around tends to fill up space pretty quickly, but ignoring > >>that problem and looking at recent i386 builds, i see that the > >>MONOLITHIC kernel set is only 440kb larger than GENERIC, yet the > >>modules set is 3500kb. > > > >This is not a real argument for or against. But the above shouldn't affect > >releases, which is after all the goal of any software project. If you track > >current, you are developing, or at least interested in the development, and > >in that case having modules outweight the potential or real space costs, > >IMO. > >You can always delete the modules, like you presumably delete old kernels > >too. > > "...ignoring [the old modules] problem ..." > > A _single_ instance of modules on amd64 occupies > 11MB > > # du -sk dest/amd64/stand/amd64/5.99.46/ > 11404 dest/amd64/stand/amd64/5.99.46/ > # > > That's nearly as much as the total size of a GENERIC kernel (about 13MB > today). I'll venture a guess that GENERIC doesn't include zfs compiled with -g. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Sun Feb 20 2011 at 04:34:02 +0100, Joerg Sonnenberger wrote: > On Sat, Feb 19, 2011 at 07:54:25PM +0200, Antti Kantee wrote: > > On Sat Feb 19 2011 at 14:58:45 +0100, Joerg Sonnenberger wrote: > > > On Sat, Feb 19, 2011 at 01:10:36PM +, Antti Kantee wrote: > > > > Module Name:src > > > > Committed By: pooka > > > > Date: Sat Feb 19 13:10:35 UTC 2011 > > > > > > > > Modified Files: > > > > src/lib/librumphijack: hijack.c > > > > > > > > Log Message: > > > > hijack __getcwd() > > > > > > Why? > > > > to make it work > > To make *what* work. What is using __getcwd directly and not the > frontends. If this is yet another hack to deal with SSP, please apply > the patch I send to tech-userlevel and test with that first. To make anything that uses the __getcwd() *system call* work, including, but definitely not limited to the getcwd() *library function*, cf. pain-rustique:1:~> wtf rumphijack rumphijack (3) - System call hijack library ^^^ I have no idea about ssp, it's not enabled on my nb5. As usual, I wrote tests so I wouldn't have to waste time guessing if things work or if they don't and so that others wouldn't have to waste their time guessing what some code was originally meant to do. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Sat Feb 19 2011 at 14:58:45 +0100, Joerg Sonnenberger wrote: > On Sat, Feb 19, 2011 at 01:10:36PM +0000, Antti Kantee wrote: > > Module Name:src > > Committed By: pooka > > Date: Sat Feb 19 13:10:35 UTC 2011 > > > > Modified Files: > > src/lib/librumphijack: hijack.c > > > > Log Message: > > hijack __getcwd() > > Why? to make it work -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Wed Feb 09 2011 at 02:32:17 +, Christos Zoulas wrote: > >And, on a tangent, it would really help if we had some mechanism for > >"latest version of symbol exported by libc" (cf. mess with select, > >pollts, kevent and socket). For working compat, I guess we'd need to > >bump rumphijack major every time one of them changes, but I can't think > >of a good mechanism for an application to automatically select the major > >that needs to be used. > > That would be useful. Oh, and one other related thing on my wishlist is having libc export all syscall stubs in WEAKASM _sys style so that use-fd-to-select-kernel can work on static linked binaries which cannot use RTLD_NEXT. I guess another option would be to compile local syscall stubs, but it seems easier to have them popping out of libc. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Tue Feb 08 2011 at 23:04:35 +0100, Joerg Sonnenberger wrote: > > > > No, it wants to override "whatever is the symbol applications are > > > > resolved to". For -current this is "_sys_read" (on nb5 it's "read"). > > > > > > That's not what the library is doing according to nm. It defines "read" > > > and not "_sys_read". > > > > Are you sure you're looking at a current version? > > > > pain-rustique:1:~> nm /usr/lib/librumphijack.so | grep read > > 29d4 T _sys_read > > U pthread_create > > U pthread_join > > 2a42 T readv > > I have different builds arounds. So why is _sys_read special and readv, > write, writev etc are not? Like Christos wrote, only read/readlink/getcwd have been ssp'd. So if you take e.g. httpd which tests/lib/librumphijack/t_tcpip uses and run nm on it, you get: U _sys_read U write -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Tue Feb 08 2011 at 22:41:57 +0100, Joerg Sonnenberger wrote: > On Tue, Feb 08, 2011 at 11:22:44PM +0200, Antti Kantee wrote: > > On Tue Feb 08 2011 at 22:00:49 +0100, Joerg Sonnenberger wrote: > > > On Tue, Feb 08, 2011 at 03:34:54PM -0500, Christos Zoulas wrote: > > > > Still the problem remains, how do we stack the calls to insert the ssp > > > > check at the top level, without resorting to rtld tricks? > > > > > > Let me try to summarize the situation to make sure I get it right: > > > > > > The fortification code wants to provide an inline function "read" that > > > calls the real "read" after doing the argument checks. > > > > > > rumphijack wants to override the "read" symbol, apply some magic and > > > call "_sys_read" for the real system call. > > > > No, it wants to override "whatever is the symbol applications are > > resolved to". For -current this is "_sys_read" (on nb5 it's "read"). > > That's not what the library is doing according to nm. It defines "read" > and not "_sys_read". Are you sure you're looking at a current version? pain-rustique:1:~> nm /usr/lib/librumphijack.so | grep read 29d4 T _sys_read U pthread_create U pthread_join 2a42 T readv -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Tue Feb 08 2011 at 23:22:44 +0200, Antti Kantee wrote: > On Tue Feb 08 2011 at 22:00:49 +0100, Joerg Sonnenberger wrote: > > On Tue, Feb 08, 2011 at 03:34:54PM -0500, Christos Zoulas wrote: > > > Still the problem remains, how do we stack the calls to insert the ssp > > > check at the top level, without resorting to rtld tricks? > > > > Let me try to summarize the situation to make sure I get it right: > > > > The fortification code wants to provide an inline function "read" that > > calls the real "read" after doing the argument checks. > > > > rumphijack wants to override the "read" symbol, apply some magic and > > call "_sys_read" for the real system call. > > No, it wants to override "whatever is the symbol applications are > resolved to". For -current this is "_sys_read" (on nb5 it's "read"). umph, for this case it's always _sys_read since read is just an alias for _sys_read on all branches. However, on -current application linkage "skips" read() (apparently due to the ssp magic). -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Tue Feb 08 2011 at 22:00:49 +0100, Joerg Sonnenberger wrote: > On Tue, Feb 08, 2011 at 03:34:54PM -0500, Christos Zoulas wrote: > > Still the problem remains, how do we stack the calls to insert the ssp > > check at the top level, without resorting to rtld tricks? > > Let me try to summarize the situation to make sure I get it right: > > The fortification code wants to provide an inline function "read" that > calls the real "read" after doing the argument checks. > > rumphijack wants to override the "read" symbol, apply some magic and > call "_sys_read" for the real system call. No, it wants to override "whatever is the symbol applications are resolved to". For -current this is "_sys_read" (on nb5 it's "read"). And, on a tangent, it would really help if we had some mechanism for "latest version of symbol exported by libc" (cf. mess with select, pollts, kevent and socket). For working compat, I guess we'd need to bump rumphijack major every time one of them changes, but I can't think of a good mechanism for an application to automatically select the major that needs to be used. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Tue Feb 08 2011 at 15:03:11 -0500, Christos Zoulas wrote: > [explanation] > > In your c code then in hijack.c you need to define the body of _hijack_read. > You also end up needing to define the bodies of readlink and getcwd, but > that is easily done... > > I hope that helps. The trick to understand here is that you can only do > the ssp check in the inline function, because if you move the check in > the source file, you've lost the information from the caller about the > passed object. > > Please let me know if you have any more questions. E2MAGIC ;) Ok, so it was originally correct (or my code was broken on -current) since hijack needs _sys_read or otherwise the #ifndef __ssp_weak_name branch causes the 3rd party caller to have a reference to _sys_read instead of read. Sorry for bursting out, been working on too many branches and this stuff is fairly hard to tune to work flawlessly ... (I still need to solve compat ... *hrr*) But, since the real caller already does the ssp check, why does it need to be performed again in librumphijack where we, as you state above, no longer have the necessary information. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Tue Feb 08 2011 at 05:15:39 +, Christos Zoulas wrote: > In article <20110207124333.gg15...@cs.hut.fi>, > Antti Kantee wrote: > >On Mon Feb 07 2011 at 11:51:02 +, Antti Kantee wrote: > >> Module Name: src > >> Committed By: pooka > >> Date: Mon Feb 7 11:51:02 UTC 2011 > >> > >> Modified Files: > >>src/lib/librumphijack: hijack.c > >> > >> Log Message: > >> Unbreak the ssp lossage from the default -current build by removing > >> it. I still don't have any idea what the ssp stuff is supposed to > >> do and how it's supposed to even begin to work. If someone wants > >> to change this now, run tests/lib/librumphijack before commit so > >> that I can avoid another multihour debugging session! > > > >In my debugging frenzy I thought that was the ssp stuff caused the > >problem, but in fact it didn't (it doesn't compile, so it cannot cause > >runtime problems). > > It used to compile and it seemed fine. Does it still? I never understood what the ssp code was supposed to do and still don't. If read is changed to _hijack_read() 3rd party callers will not resolved here, and therefore the hijack lib does not do the one thing it is expected to do. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/tests/rump/rumpkern/h_client
On Tue Feb 08 2011 at 07:53:15 +1100, matthew green wrote: > > > Module Name:src > > Committed By: pooka > > Date: Mon Feb 7 20:05:09 UTC 2011 > > > > Modified Files: > > src/tests/rump/rumpkern/h_client: h_sigcli.c > > > > Log Message: > > Limit test duration based on wall time instead of loops > > (took a long time on slow platforms). > > FWIW, i think there should be a total loops count too. i've > had tests programs "hang" on me when "time goes backwards" > at some point and at some point i patched the regress test > that was triggering this for me, but never commited it. atf has a timeout after which a test fails. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Mon Feb 07 2011 at 11:51:02 +, Antti Kantee wrote: > Module Name: src > Committed By: pooka > Date: Mon Feb 7 11:51:02 UTC 2011 > > Modified Files: > src/lib/librumphijack: hijack.c > > Log Message: > Unbreak the ssp lossage from the default -current build by removing > it. I still don't have any idea what the ssp stuff is supposed to > do and how it's supposed to even begin to work. If someone wants > to change this now, run tests/lib/librumphijack before commit so > that I can avoid another multihour debugging session! In my debugging frenzy I thought that was the ssp stuff caused the problem, but in fact it didn't (it doesn't compile, so it cannot cause runtime problems). -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/usr.bin/xlint/lint1
On Mon Feb 07 2011 at 00:00:15 -0800, Matt Thomas wrote: > > Why is lint in tools anyway ?) > > (at least as a non-nop) > > so the build can make lintlibs duh. /brick /me. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/usr.bin/xlint/lint1
On Sun Feb 06 2011 at 19:26:27 -0500, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Mon Feb 7 00:26:27 UTC 2011 > > Modified Files: > src/usr.bin/xlint/lint1: mkops > > Log Message: > provide __arraycount() if not there. What's the point? Now if a (future) third party OS uses the protected namespace to define an __arraycount macro which does not work like our __arraycount things will break. Why is lint in tools anyway ?) (at least as a non-nop) -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/sys/arch/powerpc/ibm4xx
On Mon Feb 07 2011 at 07:02:25 +, Matt Thomas wrote: > Module Name: src > Committed By: matt > Date: Mon Feb 7 07:02:24 UTC 2011 > > Modified Files: > src/sys/arch/powerpc/ibm4xx: pmap.c > > Log Message: > Use EVCNT_ATTACH_STATIC Can't we just: 1) Work toward getting of rid linkset interfaces instead of adding more uses? OR 2) Define a holy set of linksets which must be processed whenever anything is loaded. OR 3) Add some logic to the module build which will cause it to fail in case the module contains any known link sets. (rough order of personal preference) Now we have a bunch of stuff in a broken limbo and no way to verify it. Yes, it's highly unlikely anyone will dynamically load the pmap, but the availability of the interface will attract uses which are less benign. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src
On Fri Jan 28 2011 at 23:40:34 +0900, Izumi Tsutsui wrote: > > Do you have a naming suggestion? mipsebsf? > > hpcmips chose and implemented painful fpemul to avoid such discussion, > IIRC :-) heh. well, in this case I guess we could implement fpu support in the CPU to avoid discussions ;) -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src
On Fri Jan 28 2011 at 16:26:50 +0200, Antti Kantee wrote:
> On Fri Jan 28 2011 at 23:07:37 +0900, Izumi Tsutsui wrote:
> > > additionally, userland is built with MKSOFTFLOAT=yes,
> >
> > Hmm.
> >
> > In that case, shouldn't we have different ${MACHINE_ARCH}
> > for different binaries?
>
> i think you're right. hmm, looking at the build cluster output there
> seem to be very few sets shared between mips archs (i don't know the
> details of how they are selected).
>
> Do you have a naming suggestion? mipsebsf? should the mips64 archs be
> renamed to follow the same convention?
Actually, shouldn't things work even with hardfloat binaries on a nofpu
arch with fpu emul, and softfloat binaries should work on a hardfloat
machine. The performance will not be the same, but isn't that technically
the same thing as compiler optimization for a certain cpu type?
(i never tried building/running non-softfloat binaries on emips)
--
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src
On Fri Jan 28 2011 at 23:07:37 +0900, Izumi Tsutsui wrote:
> > additionally, userland is built with MKSOFTFLOAT=yes,
>
> Hmm.
>
> In that case, shouldn't we have different ${MACHINE_ARCH}
> for different binaries?
i think you're right. hmm, looking at the build cluster output there
seem to be very few sets shared between mips archs (i don't know the
details of how they are selected).
Do you have a naming suggestion? mipsebsf? should the mips64 archs be
renamed to follow the same convention?
--
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src
On Fri Jan 28 2011 at 18:05:50 +0900, Izumi Tsutsui wrote: > > Out of curiosity, was there any thought is adding this to evbmips > > instead of getting its own top-level arch subdir? > > emips already has native bootloader and src/distrib files, > so it's enough reason to have own port dir. additionally, userland is built with MKSOFTFLOAT=yes, and there are several hardware devices the port runs on. also, sysinst has some port-specific tweaks. plus, what was said about a research platform, with implications for teaching too. so, no consideration to evbmips. i think the port is right where it belongs. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Wed Jan 26 2011 at 13:48:32 -0500, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Wed Jan 26 18:48:32 UTC 2011 > > Modified Files: > src/lib/librumphijack: hijack.c > > Log Message: > make SSP friendly Can you add a comment stating why readlink and getcwd are special cases? -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src
On Wed Jan 26 2011 at 20:47:11 +0900, Toru Nishimura wrote: > Antti Kantee said; > > >eMIPS is a platform developed at Microsoft Research for researching > >reconfigurable computing. eMIPS allows dynamic loading and scheduling > >of application-specific circuits for the purpose of accelerating > >computations based on the current workload. > > > >NetBSD eMIPS support for NetBSD 4.x was written at Microsoft Research > >by Alessandro Forin and Neil Pittman. Microsoft Corporation has > >donated full copyright to The NetBSD Foundation. > > Could you provide us the reference pointer to the eMIPS project? It's long > time ago last I saw Mr. Forin name in CS research field. Yes, it's the same Mr. Forin who is the author of some old source files in our tree which date back to Mach code. http://research.microsoft.com/en-us/projects/emips/ That, and a bunch of other links are available on: http://www.netbsd.org/ports/emips/ plus, a(nother?) set of links is available on blog.netbsd.org, but that service appears to be down now. Not to worry, I'm pretty sure you can access all the important pages by starting from one and just traversing the links ;) -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src
On Wed Jan 26 2011 at 19:48:52 +0900, Izumi Tsutsui wrote: > > > > + * Make a kernel mapping valid for I/O, e.g. non-cachable. > > > > + * Alignment and length constraints are as-if NBPG==PAGE_SIZE. > : > > > What is this miracle, however? > > > > IIRC that miracle is about mapping the flash which is not in kseg1. > > The story included lots of details on how mapping an arbitrary physical > > address was much easier on Mach ;) > > Why not simply using bus_space(9) for non-cachable I/O? > (like sys/arch/arc/arc/bus_space_sparse.c) I think the reason for not using was bus space was the lack of an MI tag for physmem. That said, I don't mind if someone wants to convert the driver to dance around bus space or do other kinds of maintenance. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src
On Wed Jan 26 2011 at 02:09:30 +, Mindaugas Rasiukevicius wrote:
> > + * Make a kernel mapping valid for I/O, e.g. non-cachable.
> > + * Alignment and length constraints are as-if NBPG==PAGE_SIZE.
> > + */
> > +int
> > +ioaccess(vaddr_t vaddr, paddr_t paddr, vsize_t len)
> > +{
> > +
> > + while (len > PAGE_SIZE) {
> > + pmap_kenter_pa(vaddr, paddr, VM_PROT_WRITE, 0);
> > + len -= PAGE_SIZE;
> > + vaddr += PAGE_SIZE;
> > + paddr += PAGE_SIZE;
> > + }
> > +
> > + if (len) {
> > + /* We could warn.. */
> > + pmap_kenter_pa(vaddr, paddr, VM_PROT_WRITE, 0);
> > + }
> > +
> > + /* BUGBUG should use pmap_enter() instead and check results! */
> > + return 0;
> > +}
> > +
> > +/*
> > + * Opposite to the above: just forget the mapping.
> > + */
> > +int
> > +iounaccess(vaddr_t vaddr, vsize_t len)
> > +{
> > +
> > + pmap_kremove(vaddr, len);
> > + return 0;
> > +}
>
> What is this miracle, however?
IIRC that miracle is about mapping the flash which is not in kseg1.
The story included lots of details on how mapping an arbitrary physical
address was much easier on Mach ;)
The story was told last summer, though, so if you want more
clarifications, I can ask Sandro for a refresh.
I guess it could call pmap_update() to play nice, though.
--
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/sys
On Wed Jan 19 2011 at 01:33:51 +0900, Izumi Tsutsui wrote: > > Do you want to do the change and test, or should I? > > Please do. (I just see you added sysarghdrextra in cvsweb ;-) > > I'll test it and cleanup other files later. I test-built mac68k GENERIC and committed the fix. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/sys
On Wed Jan 19 2011 at 01:10:10 +0900, Izumi Tsutsui wrote: > > Added Files: > > src/sys/compat/common: kern_select_50.c > > Builds of most m68k ports failed since requires > for cpuset_t. whoops ... > Should we add it to all sources that include syscallargs.h, > or just add into $sysarghdrextra in sys/kern/syscalls.conf? > > Some other files still include and > only for syscallargs.h. I like self-contained headers, so sysarghdrextra has my vote. Do you want to do the change and test, or should I? (on a slight tangent, it is annoying to have MD differences in header auto-inclusion, the most famous one being atomic.h included by x86 pmap.h) -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src
On Tue Jan 18 2011 at 11:34:23 +1100, Simon Burge wrote: > > Log Message: > > > > Remove /usr/share/misc/operator. > > Why was this removed when there was an active discussion about removing > it where no concensus was reached? This sort of thing where commis > occur before a discussion is finished seems to be occurring more and > more often. Speaking as a member of core, but voicing my personal opinion. Please, roughly in the following order, 1) stop proposing changes without impact every proposal should be about fixing a real problem. removing operator cannot be justified by disk space waste or duplicate information going stale. If there is envisioned impact -- i'm having trouble coming up with even a fictional case here -- it needs to be included in the proposal. 2) stop making changes which do not fix problems every change can create a problem, so if a change does not work toward fixing a problem, the change itself is a problem. 3) stop opposing changes without reason This is a live OS, there are changes. if you want everything to stay like in NetBSD 1-4-U, use cvs export -D. If you oppose a change, you need to present a case for a non-trivial problem created by the change. It is unnecessary to call on procedular problems when it is obvious that a discussion can never reach an agreement (cf. "1"). There are no winners here. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/libp2k
On Fri Jan 14 2011 at 14:49:36 +, David Holland wrote: > > Do you have some relevant scenarios where "fses set flags in > > componentname"? > > For example, ufs_lookup sets ISWHITEOUT, which is later checked by > ufs_mkdir and ufs_create and others. ... which is used only with unions which are not supported. I'll take my chances with that one. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/libp2k
On Fri Jan 14 2011 at 08:42:45 +, David Holland wrote: > On Fri, Jan 07, 2011 at 11:15:31AM +0000, Antti Kantee wrote: > > Modified Files: > >src/lib/libp2k: p2k.c > > > > Log Message: > > Remove the componentname-saving code since it was addressing > > SAVENAME/HASBUF/SAVESTART and they don't exist anymore (and the > > removed code didn't compile on nb5). > > Unfortunately, you still need that code for now, because many fses set > flags in the componentname in lookup and expect them to still be there > later. Depending on exactly what you were trying, this may explain > some of the problems you've just seen with whiteouts... It does not explain them for quite a few reasons: 1) this code is not used in the whiteout tests (!!) 2) the now-removed code only affected rename 3) puffs does not support unions, making all debate of support at the server level purely academic Do you have some relevant scenarios where "fses set flags in componentname"? -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/sys/fs/puffs
On Tue Jan 11 2011 at 14:04:54 +, Mihai Chelaru wrote: > Module Name: src > Committed By: kefren > Date: Tue Jan 11 14:04:54 UTC 2011 > > Modified Files: > src/sys/fs/puffs: puffs_sys.h puffs_vnops.c > > Log Message: > add advlock to puffs. ok pooka@ > should fix kern/43321 Thanks! This is a big improvement and fixes the problem in most cases. However, e.g. for distributed file systems it would be good to have an additional mode where the server can decide the locking policy. I'll bump the PR state to analyzed to indicate progress. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/sys/uvm
On Thu Jan 06 2011 at 05:51:57 +, enami tsugutomo wrote: > Module Name: src > Committed By: enami > Date: Thu Jan 6 05:51:57 UTC 2011 > > Modified Files: > src/sys/uvm: uvm_fault.c > > Log Message: > Fix bugs introduced by previous commit; allocated page needs to be bound > with the anon, and uvmfault_anonget may be called with ufi NULL. Thanks. This makes automated tests work again. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/crypto/external/bsd/openssh/dist
On Mon Jan 03 2011 at 18:55:42 +, Arnaud Ysmal wrote: > Module Name: src > Committed By: stacktic > Date: Mon Jan 3 18:55:42 UTC 2011 > > Modified Files: > src/crypto/external/bsd/openssh/dist: sshconnect2.c > > Log Message: > Fixed strvisx usage Didn't you fix that already once before? Can the fix be upstreamed? -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src
On Sun Jan 02 2011 at 12:58:13 +0200, Antti Kantee wrote: > If componentname is guaranteed to be "opaque" (i.e. no "read only" might have been a better term there. (airquotes because of at least cn_consume) -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src
On Sun Jan 02 2011 at 05:04:59 +, David A. Holland wrote: > Module Name: src > Committed By: dholland > Date: Sun Jan 2 05:04:59 UTC 2011 > > Modified Files: > src/lib/libp2k: p2k.c > src/sys/kern: vfs_lookup.c > src/sys/sys: namei.src > > Log Message: > Add an INRELOOKUP namei flag. Sigh. (We don't need more namei flags.) > > However, because of a protocol deficiency puffs relies on being able > to keep track of VOP_LOOKUP calls by inspecting their contents, and > this at least allows it to use something vaguely principled instead of > making wild guesses based on whether SAVESTART is set. Well, not really. That code in libp2k was compensating for file systems wanting to modify some componentname flags in lookup and then expecting them to be there (or not be there) come the time of the op itself. If componentname is guaranteed to be "opaque" (i.e. no HASBUF/SAVENAME/START etc. mucking), you should be able to delete that ugly code and flag and simply construct the componentnames passed to VOP_RENAME from what puffs_rename gives you (but it's been a while, so please test it if you implement it). -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/tests/fs/common
On Fri Dec 31 2010 at 19:45:26 +, David Laight wrote: > On Fri, Dec 31, 2010 at 06:16:41PM +0000, Antti Kantee wrote: > > Module Name:src > > Committed By: pooka > > Date: Fri Dec 31 18:16:41 UTC 2010 > > > > Modified Files: > > src/tests/fs/common: h_fsmacros.h > > > > Log Message: > > Introduce r/o tests. They do two mounts: the first one is r/w and > > runs a generator which primes the fs. The second one is r/o and > > does the actual testing. Also, introduce a nfsro fstype which does > > a clientside r/w mount for a r/o server export. > > > > requested by yamt > > > > (one nfsro test currently fails with EROFS vs. EACCES. Hopefully > > someone else can debate the correct errno) > > >From what I remember of the NFS protocol, the following 'rules' applied: > 1) If you export part of a filesystem, you export all of the filesystem. > 2) If you give anyone access, you give everyone access. > 3) If you give anyone write access, you give everyone write access. > This is all because it is the 'mount' protocol that verifies whether > a client has access - so a client that disobeys the mount protocol, or > fakes up valid nfs file handles can avoid the access checks. > > It is possible that netbsd's nfs server does additional checks but > they are expensive to do on every nfs request. That's good advise to someone who is configuring an nfs server. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/sys/kern
On Mon Dec 27 2010 at 16:29:12 +, Mindaugas Rasiukevicius wrote: > Antti Kantee wrote: > > > Module Name: src > > > Committed By: rmind > > > Date: Sat Dec 18 01:18:48 UTC 2010 > > > > > > Modified Files: > > > src/sys/kern: sys_descrip.c > > > > > > Log Message: > > > do_posix_fadvise: fix and improve previous change - add a comment with > > > some rationale and handle few range overflows. > > > > tests/kernel/t_posix_fadvise now fails and needs attention. > > > > I guess.. atf_tc_expect_signal() line should removed, since it should > no longer crash? Yes. I adjusted the test. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/sys/kern
On Fri Dec 17 2010 at 22:34:04 +, YAMAMOTO Takashi wrote: > Module Name: src > Committed By: yamt > Date: Fri Dec 17 22:34:04 UTC 2010 > > Modified Files: > src/sys/kern: vfs_lookup.c > > Log Message: > - lookup_once: when crossing a mount point, don't keep the parent vnode > locked. > ie. don't lock a vnode while holding another vnode which belongs to a > different filesystem. otherwise we propagate slowness (or deadness) of a > filesystem to another via vnode lock chain. > - lookup_parsepath: don't alter vnode states. let the caller do it instead. > - add comments and assertions. Hi, this breaks the state->dp != ndp->ni_dvp invariant in at least 3 places in vfs_lookup.c: http://www.gson.org/netbsd/bugs/build/build/2010.12.18.09.26.57/test.html#failed-tcs-summary Can you have a look? -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/sys/kern
On Sat Dec 18 2010 at 01:18:49 +, Mindaugas Rasiukevicius wrote: > Module Name: src > Committed By: rmind > Date: Sat Dec 18 01:18:48 UTC 2010 > > Modified Files: > src/sys/kern: sys_descrip.c > > Log Message: > do_posix_fadvise: fix and improve previous change - add a comment with > some rationale and handle few range overflows. tests/kernel/t_posix_fadvise now fails and needs attention. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/libc/time
On Fri Dec 17 2010 at 18:11:57 -0500, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Fri Dec 17 23:11:57 UTC 2010 > > Modified Files: > src/lib/libc/time: localtime.c > > Log Message: > PR/44248: Antti Kantee: Fix multi-threaded localtime hang. Please remember to mirror this in the test mentioned in the PR. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/libc
On Fri Dec 17 2010 at 22:03:46 +0200, Antti Kantee wrote: > On Fri Dec 17 2010 at 21:56:59 +0200, Jukka Ruohonen wrote: > > On Thu, Dec 16, 2010 at 01:38:07PM -0500, Christos Zoulas wrote: > > > Log Message: > > > Provide a re-entrant and thread-safe set of timezone API's that > > > don't require locking and can operate on user-specified timezones > > > as opposed to having to alter the environment to change a timezone. > > > This work was presented to the tzcode folks and it was generally > > > accepted, but there seems to be a lot of inertia. > > > > I am not sure yet, but it may be that this broke for instance lang/python. > > The autoconfiguration process hangs at: > > > > checking for tzset... > > See lib/44246. Err, 44248 -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/libc
On Fri Dec 17 2010 at 21:56:59 +0200, Jukka Ruohonen wrote: > On Thu, Dec 16, 2010 at 01:38:07PM -0500, Christos Zoulas wrote: > > Log Message: > > Provide a re-entrant and thread-safe set of timezone API's that > > don't require locking and can operate on user-specified timezones > > as opposed to having to alter the environment to change a timezone. > > This work was presented to the tzcode folks and it was generally > > accepted, but there seems to be a lot of inertia. > > I am not sure yet, but it may be that this broke for instance lang/python. > The autoconfiguration process hangs at: > > checking for tzset... See lib/44246. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/usr.bin/rump_allserver
On Wed Dec 15 2010 at 09:40:22 +, Thomas Klausner wrote: > Modified Files: > src/usr.bin/rump_allserver: rump_allserver.c > > Log Message: > Sort options in usage same as in man page. > While here, replace \xa0 with ' '. Where do you get these from? Dunno, some weird combination of netbsd/keyboard/vi. Seems to happen especially when showmatch triggers from } and ] -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/share/mk
On Tue Dec 14 2010 at 01:52:50 +0100, Joerg Sonnenberger wrote:
> On Mon, Dec 13, 2010 at 05:22:26PM +0000, Antti Kantee wrote:
> > Module Name:src
> > Committed By: pooka
> > Date: Mon Dec 13 17:22:26 UTC 2010
> >
> > Modified Files:
> > src/share/mk: bsd.own.mk bsd.prog.mk
> >
> > Log Message:
> > Define RUMPPRG, which is just like PROG, except it additionally
> > builds a rump client with the name rump.${PROG}. The rump client
> > is not installed suid/sgid by default even if BINMODE is defined.
>
> Where was this discussed? Why are you renaming a variable that has
> existed for ages to get it to work for your own purpose? Can't you get
> the same behavior by adding a WANT_RUMP=yes flag in the Makefiles?
I've received multiple proposals on how the variable should be used,
all different.
--
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src
On Mon Dec 13 2010 at 23:51:39 +0100, Christoph Egger wrote: > On 13.12.10 22:15, Antti Kantee wrote: > > Module Name:src > > Committed By: pooka > > Date: Mon Dec 13 21:15:31 UTC 2010 > > > > Modified Files: > > src/distrib/sets/lists/base: mi > > src/distrib/sets/lists/comp: mi > > src/usr.bin/netstat: Makefile bpf.c if.c inet.c inet6.c main.c mbuf.c > > show.c unix.c > > Added Files: > > src/usr.bin/netstat: netstat_hostops.c netstat_rumpops.c prog_ops.h > > > > Log Message: > > Add netstat rump client. For now, it always sets -X, i.e. will > > use only sysctl and no kvm (implementing /dev/mem for a rump kernel > > would probably not be hard, but still a non-zero effort). > > > > Note: since there is absolutely no network activity in a fresh rump > > kernel, rump.netstat usually displays exactly nothing when invoked > > without parameters. Arguments like -r, -bi, -p icmp etc. produce > > more stuff. > > > > Does that allow to remove the suid bit from netstat? No, -X is used only for the rump client. There are still some highly useful stats (like ISO stats) which are available only via kvm, and a few others too. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
