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/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
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 pthread.h
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
mutex.
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
constexprs from libc++/dist/libcxx/include/__mutex_base?
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 constexprs 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
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 constexprs 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 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
This is the simplest program to repeat the problem with g++ 5.1 and
NetBSD's pthread_types.h:
#include pthread.h
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 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 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? 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 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 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 po...@iki.fi 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 jus...@specialbusservice.com wrote Er, you can't do that. 1. It breaks the rump builds on most platforms http://build.myriabit.eu:8012/waterfall as the prototypes dont match eg see http://build.myriabit.eu:8012/builders/ppc64-cross/builds/5585/steps/shell_3/logs/stdio It seems that posix says 2nd arg of iconv(3) is char **, but NetBSD's one is const char **. 2. There is no requirement that rump runs on a platform that has iconv anyway, it may be running on bare metal, or non Posix platform. Not sure what the intention was though - I am sure we can find a way around it... I would like to include this at least on NetBSD host since we don't have kernel iconv and then mount_smbfs(8) is useless for filename conversions. So is it ok to add a compile-time option as below and define it somewhere? Or are there any more appropriate make variables to detect host OS? 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 Thu, Oct 30, 2014 at 11:14:50AM +0900, Masao Uebayashi wrote: On Thu, Oct 30, 2014 at 10:51 AM, Christos Zoulas chris...@astron.com wrote: In article 20141030012621.0982...@cvs.netbsd.org, Masao Uebayashi source-changes-d@NetBSD.org 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/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/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/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 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 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/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 jo...@britannica.bec.de 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 sys/atomic.h? 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 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/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/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: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/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 +, 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/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 po...@netbsd.org: 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
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
Actually, I misread some stuff. n/m sorry for the noise. On Thu, Mar 10, 2011 at 01:50:37PM +, 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/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/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 source-changes-d@NetBSD.org 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/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
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 fcntl+21: 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. (fcntl 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 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 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 fcntl+21: 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 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/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/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/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/lib/librumphijack
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 -- ä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 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 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: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: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/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/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/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/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/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
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
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: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/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 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 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 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
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/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 sys/syscallargs.h requires sys/sched.h for cpuset_t. whoops ... Should we add it to all sources that include syscallargs.h, or just add sys/sched.h into $sysarghdrextra in sys/kern/syscalls.conf? Some other files still include sys/mount.h and sys/sched.h 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/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/lib/libp2k
On Fri Jan 14 2011 at 08:42:45 +, David Holland wrote: On Fri, Jan 07, 2011 at 11:15:31AM +, 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/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/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 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
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/sys/kern
On Mon Dec 27 2010 at 16:29:12 +, Mindaugas Rasiukevicius wrote: Antti Kantee po...@cs.hut.fi 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/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/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/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/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/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 +, 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/sys
On Sat, Dec 11, 2010 at 10:37:47PM +, Matt Thomas wrote: Module Name: src Committed By: matt Date: Sat Dec 11 22:37:47 UTC 2010 Modified Files: src/sys/netinet: in_offload.c in_offload.h ip_input.c src/sys/netinet6: in6_offload.c in6_offload.h Log Message: Add routines to calculate a checkesum if the driver concludes that the h/w can't do it. The change to ip_input.c: 1) looks wrong (ipintr is MPSAFE, so kernel lock should not be held there to begin with) 2) breaks all tests that use IP (*) 3) conflicts with the performance anecdote in rev 1.286 Can you address the above points or back out the change? Thanks. *) http://www.gson.org/netbsd/bugs/build/build/2010.12.13.01.48.50/test.html#failed-tcs-summary http://www.whooppee.com/~paul/amd64-results/566_atf.html#failed-tcs-summary
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
Re: CVS commit: src/sys/dev
On Sat Dec 04 2010 at 18:44:07 +, Christos Zoulas wrote: In article 20101204173951.3ae6e17...@cvs.netbsd.org, Antti Kantee source-changes-d@NetBSD.org wrote: -=-=-=-=-=- Module Name: src Committed By:pooka Date:Sat Dec 4 17:39:51 UTC 2010 Modified Files: src/sys/dev: rnd.c Log Message: Don't allow goes to 11^H^Hhyperspace len field for RNDADDATA. Should be EINVAL; E2BIG has a very specific meaning (unless we want to change that). EINVAL is used too much and I try to pick more descriptive remotely fitting errnos when possible. If someone feels strongly otherwise, please change it. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/share/misc
On Thu Dec 02 2010 at 14:18:15 +0200, Jukka Ruohonen wrote: On Thu, Dec 02, 2010 at 08:31:43AM +, David Holland wrote: On Tue, Nov 30, 2010 at 07:07:15PM +, Jukka Ruohonen wrote: Add numerous entries from Roland Kammerer. Some of these are not acronyms: 1337, FSCK, and NOOB are the most obvious, but perhaps also things like W8 for wait. Should they really be here? This is not supposed to be a general-purpose slang dictionary... To me, acronyms (and not acronyms.comp) has always been a collection of things one might hear on IRC, nothing more, nothing less. I believe this is also the main reason why someone might use wtf(1). But we can of course debate what is an acronym. Sounds like a carefully planned proposal and thorough discussion is necessary. We all need to remember the disaster with acronyms.comp. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src
On Tue Nov 30 2010 at 15:56:26 +0100, haad wrote:
On Tue, Nov 30, 2010 at 3:23 PM, Antti Kantee po...@netbsd.org wrote:
Module Name: src
Committed By: pooka
Date: Tue Nov 30 14:23:24 UTC 2010
Modified Files:
src/lib/librumpuser: Makefile
src/sys/rump/include/rump: rump.h rumpuser.h
src/sys/rump/librump/rumpkern: rump.c
Added Files:
src/lib/librumpuser: rumpuser_daemonize.c
Log Message:
Require server to be explicitly initialized with rump_init_server(url).
Also, add rump_daemonize_begin() / rump_daemonize_end() to help
with the can't daemon() after pthread_create() problem. Applications
could accomplish the same, but since it's such a common operation,
provide a little help.
Can you show some small example how rump server should look like now ?
Just replace rump_init with rump_init_server ? and RUMP_SP_PATH is in url
I'll add some tests/documentation soon when I consider things to be
final enough.
Meanwhile, you can look at tests/dev/md/h_mdserv.c for a real example.
The simplest possible one is something like this:
main() {
rump_init();
rump_init_server(argv[1]);
pause();
}
And then run it ./a.out unix://rumpsock
Re: CVS commit: src/tests/lib/libc/stdio
On Mon Nov 22 2010 at 08:47:58 +, matthew green wrote: Module Name: src Committed By: mrg Date: Mon Nov 22 08:47:58 UTC 2010 Modified Files: src/tests/lib/libc/stdio: t_format.c Log Message: vax doesn't have ieee fp, so, don't try to test ieee fp on vax. Don't we have a more intent-clear macro for this? Modified files: Index: src/tests/lib/libc/stdio/t_format.c diff -u src/tests/lib/libc/stdio/t_format.c:1.1 src/tests/lib/libc/stdio/t_format.c:1.2 --- src/tests/lib/libc/stdio/t_format.c:1.1 Fri Nov 19 18:18:53 2010 +++ src/tests/lib/libc/stdio/t_format.c Mon Nov 22 08:47:58 2010 @@ -46,11 +46,13 @@ ATF_CHECK(sprintf(str, %010f, 0.0) == 10); ATF_REQUIRE_STREQ(str, 000.00); +#ifndef __vax__ /* PR/44113: printf(3) should ignore zero padding for nan/inf */ ATF_CHECK(sprintf(str, %010f, NAN) == 10); ATF_REQUIRE_STREQ(str,nan); ATF_CHECK(sprintf(str, %010f, INFINITY) == 10); ATF_REQUIRE_STREQ(str,inf); +#endif } ATF_TP_ADD_TCS(tp)
Re: CVS commit: src/sys/arch/pmax/stand/common
On Thu Nov 25 2010 at 14:05:28 +, Izumi Tsutsui wrote: Module Name: src Committed By: tsutsui Date: Thu Nov 25 14:05:28 UTC 2010 Modified Files: src/sys/arch/pmax/stand/common: startprog.S Log Message: Fix botch on mips64 merge: - use correct offsets to pass args to loaded kernel in __mips_o32 case Now NetBSD/pmax kernel properly boots, but init(8) still doesn't start on GXemul emulating R3000 3MAX. One remaining problem (which was debugged by Alessandro Forin) is that the post-mips64 brk/sbrk syscall stubs depend on syscall retaining t0, and the kernel doesn't do that. I have this in my local tree and it makes a mips1 platform boot with new userland. See if it helps on pmax too: --- locore_mips1.S 8 Nov 2010 18:09:38 - 1.68 +++ locore_mips1.S 25 Nov 2010 14:15:39 - @@ -418,7 +418,7 @@ NESTED_NOPROFILE(mips1_SystemCall, CALLF sw a3, FRAME_A3(k1) lw a0, CPUVAR(CURLWP) # 1st arg is curlwp mfhiv1 - #sw t0, FRAME_T0(k1)# no need to save temp regs + sw t0, FRAME_T0(k1)# no need to save temp regs #sw t1, FRAME_T1(k1) #sw t2, FRAME_T2(k1) #sw t3, FRAME_T3(k1)
Re: CVS commit: src/sys/arch/pmax/stand/common
On Thu Nov 25 2010 at 23:39:03 +0900, Izumi Tsutsui wrote: One remaining problem (which was debugged by Alessandro Forin) is that the post-mips64 brk/sbrk syscall stubs depend on syscall retaining t0, and the kernel doesn't do that. I have this in my local tree and it makes a mips1 platform boot with new userland. See if it helps on pmax too: --- locore_mips1.S 8 Nov 2010 18:09:38 - 1.68 +++ locore_mips1.S 25 Nov 2010 14:15:39 - @@ -418,7 +418,7 @@ NESTED_NOPROFILE(mips1_SystemCall, CALLF sw a3, FRAME_A3(k1) lw a0, CPUVAR(CURLWP) # 1st arg is curlwp mfhiv1 - #sw t0, FRAME_T0(k1)# no need to save temp regs + sw t0, FRAME_T0(k1)# no need to save temp regs Yeah, it works with 20101117Z snapshot binaries. Thanks. cool But should we rather fix syscall stubs? That was debated a little but undecided. Pros for kernel: * debugging (low-level) over syscall trap doesn't cause debugger confusion * random kernel info not leaked to userland (+ IMHO principle of least surprise) Pros for syscall stub: * faster (but nobody measured it, and most likely the difference is lost in the noise) I don't have a strong prefence for either. The reason I have it that way is because for some reason when testing I forgot to fix my tree before starting a build and when I remembered the build was already past libc, so I figured I might as well fix the kernel ;)
Re: CVS commit: src/sys/arch/pmax/stand/common
On Fri Nov 26 2010 at 03:01:29 +1100, matthew green wrote: --- locore_mips1.S 8 Nov 2010 18:09:38 - 1.68 +++ locore_mips1.S 25 Nov 2010 14:15:39 - @@ -418,7 +418,7 @@ NESTED_NOPROFILE(mips1_SystemCall, CALLF sw a3, FRAME_A3(k1) lw a0, CPUVAR(CURLWP) # 1st arg is curlwp mfhiv1 - #sw t0, FRAME_T0(k1)# no need to save temp regs + sw t0, FRAME_T0(k1)# no need to save temp regs Yeah, it works with 20101117Z snapshot binaries. Thanks. But should we rather fix syscall stubs? if the above is necessary for old binaries then it needs to be done. we should fix the syscall stubs, for sure... but we may need the above as well. Well, it's necessary for libc post-mips64, but I don't think anyone will terribly scream if their not-currently-working libc remains the same. Old (4.0) userland works just fine even without that fix.
Re: CVS commit: src/sys/arch/pmax/stand/common
On Fri Nov 26 2010 at 03:01:29 +1100, matthew green wrote: --- locore_mips1.S 8 Nov 2010 18:09:38 - 1.68 +++ locore_mips1.S 25 Nov 2010 14:15:39 - @@ -418,7 +418,7 @@ NESTED_NOPROFILE(mips1_SystemCall, CALLF sw a3, FRAME_A3(k1) lw a0, CPUVAR(CURLWP) # 1st arg is curlwp mfhiv1 - #sw t0, FRAME_T0(k1)# no need to save temp regs + sw t0, FRAME_T0(k1)# no need to save temp regs Yeah, it works with 20101117Z snapshot binaries. Thanks. But should we rather fix syscall stubs? if the above is necessary for old binaries then it needs to be done. we should fix the syscall stubs, for sure... but we may need the above as well. Actually, I'm not sure on for sure. If we define the kernel to retain t regs over syscall, there is no need to touch the syscall stubs. The problem is essentially that the old stub did this: brk: syscall la t0 _C_LABEL sw v0 0(t0) and the new one: brk: la t0 _C_LABEL syscall sw v0 0(t0)
Re: CVS commit: src/sys/arch/pmax/stand/common
On Fri Nov 26 2010 at 01:50:11 +0900, Izumi Tsutsui wrote: but shouldn't we fix stub first, then discuss pros and blah of the change? Current binaries have not worked at all on MIPS1 since the last December. Like I said, I don't have strong feelings about this. If you want to fix stubs, go for it! (there's no need for a discussion after that, anyway, since the issue is decided and fixed)
Re: CVS commit: src/bin/dd
On Tue Nov 23 2010 at 12:28:48 +, Matthias Scheler wrote: On Mon, Nov 22, 2010 at 09:04:28PM +, Antti Kantee wrote: Module Name:src Committed By: pooka Date: Mon Nov 22 21:04:28 UTC 2010 Modified Files: src/bin/dd: Makefile args.c dd.c dd.h extern.h position.c Log Message: Add two new operands: rif and rof. They operate exactly like if and of with the exception that the communicate with a rump kernel instead of the host kernel. This makes dd unusable if only / but not /usr is mounted because it now depends on /usr/lib/librumpclient.so.0. Utilities in /bin and /sbin are supposed to work without /usr mounted. Good catch. Fixed. Sorry 'bout that oversight. (on a slight tangent, wasn't getting rid of /usr vs. / on the roadmap?)
Re: CVS commit: src/bin/dd
On Tue Nov 23 2010 at 18:41:21 +, David Laight wrote: On Tue, Nov 23, 2010 at 12:19:36AM +0200, Antti Kantee wrote: Surely it would be more appropriate to make thye rump kernel directly forward some paths to the real kernel? Can you explain how that could work? First thoughts are something like the way /../ is used to 'escape' from the emulation root. But maybe just mount the real filesystem within the rump kernel? The client may be on a different machine, so you'd have to, if not invent a completely new protocol, at least include server side functionality on the client and add some weird pingpong/adjust logic into the server. Making something work well enough to copy files is probably not that hard! Adding a ton of special case code to copy files is extremely poor design! Doubly so since the only reason is because you don't happen to like some flags which bring 0 cost when not used. If you don't like them, don't use them. Unless someone can actually name a *problem*, move along.
Re: CVS commit: src/bin/dd
On Mon Nov 22 2010 at 22:09:24 +, David Laight wrote: On Mon, Nov 22, 2010 at 09:04:28PM +, Antti Kantee wrote: Module Name:src Committed By: pooka Date: Mon Nov 22 21:04:28 UTC 2010 Modified Files: src/bin/dd: Makefile args.c dd.c dd.h extern.h position.c Log Message: Add two new operands: rif and rof. They operate exactly like if and of with the exception that the communicate with a rump kernel instead of the host kernel. H this seems like polluting a standard utility to support a very specific use. Surely it would be more appropriate to make thye rump kernel directly forward some paths to the real kernel? Can you explain how that could work?
