Re: CVS commit: src/lib/librumpuser/build-aux

2016-10-19 Thread Antti Kantee

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

2016-10-18 Thread Antti Kantee

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/share/mk

2015-11-12 Thread Antti Kantee

On 19/10/15 17:08, David A. Holland wrote:

Module Name:src
Committed By:   dholland
Date:   Mon Oct 19 17:08:11 UTC 2015

Modified Files:
src/share/mk: bsd.man.mk

Log Message:
because I'm feeling tetchy, implement "make describe" for everything that
has man pages.


That tetchiness is causing conflicts, e.g.

nbmake[1]: "/home/pooka/src/nbsrc/src/share/mk/bsd.man.mk" line 300: 
warning: duplicate script for target "describe" ignored
nbmake[1]: 
"/home/pooka/src/nbsrc/src/lib/librumpvfs/../../sys/rump/Makefile.rump" 
line 247: warning: using previous script for "describe" defined here


Re: CVS commit: src/sys/dev/pci

2015-08-25 Thread Antti Kantee

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

2015-08-24 Thread Antti Kantee

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

2015-08-24 Thread Antti Kantee

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

2015-08-24 Thread Antti Kantee

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

2015-06-26 Thread Antti Kantee

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

2015-06-26 Thread Antti Kantee
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

2015-06-26 Thread Antti Kantee

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

2015-06-26 Thread Antti Kantee

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

2015-06-26 Thread Antti Kantee

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

2015-06-26 Thread Antti Kantee

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

2015-06-25 Thread Antti Kantee
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

2014-12-02 Thread Antti Kantee
[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

2014-12-01 Thread Antti Kantee

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

2014-11-18 Thread Antti Kantee

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

2014-11-16 Thread Antti Kantee

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

2014-10-30 Thread Antti Kantee
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

2014-10-30 Thread Antti Kantee

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

2014-06-17 Thread Antti Kantee
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

2014-06-17 Thread Antti Kantee

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

2014-06-17 Thread Antti Kantee

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

2014-06-17 Thread Antti Kantee

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

2014-05-26 Thread Antti Kantee

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

2014-04-29 Thread Antti Kantee
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

2014-04-25 Thread Antti Kantee

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)

2014-04-14 Thread Antti Kantee

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

2014-01-02 Thread Antti Kantee

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

2013-11-16 Thread Antti Kantee

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

2013-07-04 Thread Antti Kantee

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

2013-07-04 Thread Antti Kantee

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

2013-03-11 Thread Antti Kantee

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

2013-01-03 Thread Antti Kantee

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

2012-12-10 Thread Antti Kantee

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)

2011-03-15 Thread Antti Kantee
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/include (commaize_number)

2011-03-15 Thread Antti Kantee
On Tue Mar 15 2011 at 05:33:16 -0700, Paul Goyette wrote:
 On Tue, 15 Mar 2011, Antti Kantee wrote:
 
 On Tue Mar 15 2011 at 05:25:51 -0700, Paul Goyette wrote:
 Module Name:src
 Committed By:   pooka
 Date:   Tue Mar 15 12:21:08 UTC 2011
 
 Modified Files:
src/include: stdlib.h
 
 Log Message:
 put in a proto for commaize_number()
 (nb. doing this purely as the minimum work solution to get a working 
 build)
 
 
 Maybe we shouldn't fix the build here, since there's also the issue of
 bumping the minor version of libc which was not done.  With a build
 break we don't have any compatability issues, but if we let a working
 build ship with this, don't we have to keep it ~forever?
 
 There's honoring compatibility and then there's just being silly.
 
 OK, color me silly !:)

if you want to be colored with a blue ribbon, there's always the option
of backing out the changes -- from what i quickly observed, that's the
current consensus and would also address your (silly ;) concern.

-- 
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa


Re: CVS commit: src/lib/librumphijack

2011-03-11 Thread Antti Kantee
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

2011-03-11 Thread Antti Kantee
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

2011-03-10 Thread Antti Kantee
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

2011-03-10 Thread Antti Kantee
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

2011-03-09 Thread Antti Kantee
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

2011-03-04 Thread Antti Kantee
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

2011-03-04 Thread Antti Kantee
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/lib/librumphijack

2011-02-27 Thread Antti Kantee
On Sun Feb 27 2011 at 08:12:37 +0300, Valeriy E. Ushakov wrote:
 On Fri, Feb 25, 2011 at 16:01:42 +, Antti Kantee wrote:
 
  Module Name:src
  Committed By:   pooka
  Date:   Fri Feb 25 16:01:42 UTC 2011
  
  Modified Files:
  src/lib/librumphijack: Makefile hijackdlsym.c
  
  Log Message:
  Ok, for reasons I can't begin to understand, the binaries I tested
  yesterday on powerpc broke overnight.  Apparently adding one more
  function before the call to dlsym() fixes things again.  I hope
  I don't have to add another one tomorrow 
  
  
  To generate a diff of this commit:
  cvs rdiff -u -r1.7 -r1.8 src/lib/librumphijack/Makefile
  cvs rdiff -u -r1.1 -r1.2 src/lib/librumphijack/hijackdlsym.c
 
 I think this is caused by revision 1.121 of rtld.c (hi, mac!) that
 added hackish_return_address for ppc.
 
 #ifdef __powerpc__
 static void *
 hackish_return_address(void)
 {
 return __builtin_return_address(1);
 }
 #endif
 
 void *
 dlsym(void *handle, const char *name)
 {
 ...
 #ifdef __powerpc__
 retaddr = hackish_return_address();
 #else
 retaddr = __builtin_return_address(0);
 #endif
 ...
 }
 
 
 hackish_return_address will be inlined (simple static function) and,
 as far as I can tell, gcc does NOT adjust the level argument to
 __builtin_return_address.
 
 The net effect is that dlsym uses caller's caller address to detect
 which module the call comes from, and if caller's caller is in a
 different module wrong things happen.
 
 That explains why you need an extra frame.

What I really can't understand is that I have a very distinct impression
that things worked on Thursday (and screencaps to show it).  Then, after
riz installed a new userland, things were broken on Friday.  However,
I was using the same ld.elf_so binary I had compiled for debugging,
so it cannot be that the new toolchain inlined the call while the old
one didn't.

Anyway, apparently I don't have to put yet another callframe there,
since things are still working ;)

http://www.netbsd.org/~riz/macppc-atf/

Btw, if someone is looking for something interesting, look at the
posix_fadvise test.

-- 
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa


Re: CVS commit: src

2011-02-26 Thread Antti Kantee
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

2011-02-25 Thread Antti Kantee
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

2011-02-25 Thread Antti Kantee
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

2011-02-24 Thread Antti Kantee
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

2011-02-23 Thread Antti Kantee
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

2011-02-22 Thread Antti Kantee
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

2011-02-20 Thread Antti Kantee
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

2011-02-20 Thread Antti Kantee
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

2011-02-20 Thread Antti Kantee
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

2011-02-19 Thread Antti Kantee
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

2011-02-09 Thread Antti Kantee
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

2011-02-08 Thread Antti Kantee
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

2011-02-08 Thread Antti Kantee
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

2011-02-08 Thread Antti Kantee
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

2011-02-08 Thread Antti Kantee
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

2011-02-07 Thread Antti Kantee
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

2011-02-07 Thread Antti Kantee
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

2011-02-07 Thread Antti Kantee
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

2011-02-06 Thread Antti Kantee
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

2011-02-06 Thread Antti Kantee
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

2011-01-28 Thread Antti Kantee
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

2011-01-28 Thread Antti Kantee
On Fri Jan 28 2011 at 23:07:37 +0900, Izumi Tsutsui wrote:
  additionally, userland is built with MKSOFTFLOAT=yes,
 
 Hmm.
 
 In that case, shouldn't we have different ${MACHINE_ARCH}
 for different binaries?

i think you're right.  hmm, looking at the build cluster output there
seem to be very few sets shared between mips archs (i don't know the
details of how they are selected).

Do you have a naming suggestion?  mipsebsf?  should the mips64 archs be
renamed to follow the same convention?

-- 
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa


Re: CVS commit: src

2011-01-28 Thread Antti Kantee
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

2011-01-28 Thread Antti Kantee
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

2011-01-27 Thread Antti Kantee
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

2011-01-26 Thread Antti Kantee
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

2011-01-26 Thread Antti Kantee
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

2011-01-25 Thread Antti Kantee
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

2011-01-18 Thread Antti Kantee
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

2011-01-18 Thread Antti Kantee
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

2011-01-18 Thread Antti Kantee
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

2011-01-14 Thread Antti Kantee
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

2011-01-14 Thread Antti Kantee
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

2011-01-11 Thread Antti Kantee
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

2011-01-06 Thread Antti Kantee
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

2011-01-04 Thread Antti Kantee
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

2011-01-02 Thread Antti Kantee
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

2011-01-02 Thread Antti Kantee
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/tests/fs/common

2011-01-01 Thread Antti Kantee
On Fri Dec 31 2010 at 19:45:26 +, David Laight wrote:
 On Fri, Dec 31, 2010 at 06:16:41PM +, Antti Kantee wrote:
  Module Name:src
  Committed By:   pooka
  Date:   Fri Dec 31 18:16:41 UTC 2010
  
  Modified Files:
  src/tests/fs/common: h_fsmacros.h
  
  Log Message:
  Introduce r/o tests.  They do two mounts: the first one is r/w and
  runs a generator which primes the fs.  The second one is r/o and
  does the actual testing.  Also, introduce a nfsro fstype which does
  a clientside r/w mount for a r/o server export.
  
  requested by yamt
  
  (one nfsro test currently fails with EROFS vs. EACCES.  Hopefully
  someone else can debate the correct errno)
 
 From what I remember of the NFS protocol, the following 'rules' applied:
 1) If you export part of a filesystem, you export all of the filesystem.
 2) If you give anyone access, you give everyone access.
 3) If you give anyone write access, you give everyone write access.
 This is all because it is the 'mount' protocol that verifies whether
 a client has access - so a client that disobeys the mount protocol, or
 fakes up valid nfs file handles can avoid the access checks.
 
 It is possible that netbsd's nfs server does additional checks but
 they are expensive to do on every nfs request.

That's good advise to someone who is configuring an nfs server.

-- 
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa


Re: CVS commit: src/sys/kern

2010-12-30 Thread Antti Kantee
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

2010-12-18 Thread Antti Kantee
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

2010-12-18 Thread Antti Kantee
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

2010-12-17 Thread Antti Kantee
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

2010-12-17 Thread Antti Kantee
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

2010-12-15 Thread Antti Kantee
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

2010-12-14 Thread Antti Kantee
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

2010-12-13 Thread Antti Kantee
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

2010-12-13 Thread Antti Kantee
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

2010-12-05 Thread Antti Kantee
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

2010-12-02 Thread Antti Kantee
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

2010-11-30 Thread Antti Kantee
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

2010-11-30 Thread Antti Kantee
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

2010-11-25 Thread Antti Kantee
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

2010-11-25 Thread Antti Kantee
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

2010-11-25 Thread Antti Kantee
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.


  1   2   3   4   5   >