Unit Tests for FreeBSD Kernel APIs?
Hello, exists there some unit tests for FreeBSD kernel APIs, e.g. mutex(9), condvar(9), etc.? Have a nice day! -- Sebastian Huber, embedded brains GmbH Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany Phone : +49 89 18 90 80 79-6 Fax : +49 89 18 90 80 79-9 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: misc/157903: automated kldload for USB class devices
On Friday 24 June 2011 09:22:57 Robert Millan wrote: 2011/6/24 Hans Petter Selasky hsela...@c2i.net: Updated bus_auto.conf: http://hselasky.homeunix.org:8192/bus_auto.conf Very nice. But why not use variable names instead of hardcoding numbers? It makes the output much easier to understand. To save memory. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: misc/157903: automated kldload for USB class devices
2011/6/23 Warner Losh i...@bsdimp.com: How'd you go about generating all these .conf files? I have to admit it was quite boring, lots of grep sed, different regex for each file, then some manual editting. But I see that someone has found a better way. I'll look into testing that :-) I don't see where you defined USB_* as variables in them either. Maybe you could point me at it? Autogenerated from usbdevs, see: # USB vendor ids and product ids. usb_ids.conf: genusbdevs.sh ../../sys/dev/usb/usbdevs sh genusbdevs.sh $@ -- Robert Millan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: misc/157903: automated kldload for USB class devices
2011/6/24 Hans Petter Selasky hsela...@c2i.net: Updated bus_auto.conf: http://hselasky.homeunix.org:8192/bus_auto.conf Very nice. But why not use variable names instead of hardcoding numbers? It makes the output much easier to understand. -- Robert Millan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: misc/157903: automated kldload for USB class devices
On Friday 24 June 2011 14:59:37 Robert Millan wrote: 2011/6/24 Hans Petter Selasky hsela...@c2i.net: Very nice. But why not use variable names instead of hardcoding numbers? It makes the output much easier to understand. To save memory. I haven't inspected devd code, but I was under the assumption that variables only lived untill resolved. What would be the point of keeping them in memory after devd has finished parsing the config files? Hi, I haven't checked that, though if you want the readable version, then you need to check the source code. However I could add some code to print a vendor ID comment, based on usbdevs. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Unit Tests for FreeBSD Kernel APIs?
On Friday, June 24, 2011 3:23:11 am Sebastian Huber wrote: Hello, exists there some unit tests for FreeBSD kernel APIs, e.g. mutex(9), condvar(9), etc.? Have a nice day! Hmm, I have a kernel module that does some tests, but it is not in the tree. One of the issues is that many of the tests you want to do for some of these APIs involve timing. For rwlocks, for example, I used KTR traces and used a kernel module that forked 4 threads to all compete over a single lock. I then verified via KTR traces that every branch was taken (and made liberal use of KASSERT()s which caught a few edge cases I had missed initially). -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: misc/157903: automated kldload for USB class devices
2011/6/24 Hans Petter Selasky hsela...@c2i.net: Very nice. But why not use variable names instead of hardcoding numbers? It makes the output much easier to understand. To save memory. I haven't inspected devd code, but I was under the assumption that variables only lived untill resolved. What would be the point of keeping them in memory after devd has finished parsing the config files? -- Robert Millan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Unit Tests for FreeBSD Kernel APIs?
On Fri, Jun 24, 2011 at 6:14 AM, John Baldwin j...@freebsd.org wrote: On Friday, June 24, 2011 3:23:11 am Sebastian Huber wrote: Hello, exists there some unit tests for FreeBSD kernel APIs, e.g. mutex(9), condvar(9), etc.? Have a nice day! Hmm, I have a kernel module that does some tests, but it is not in the tree. One of the issues is that many of the tests you want to do for some of these APIs involve timing. For rwlocks, for example, I used KTR traces and used a kernel module that forked 4 threads to all compete over a single lock. I then verified via KTR traces that every branch was taken (and made liberal use of KASSERT()s which caught a few edge cases I had missed initially). At $WORK we have a generic TEST_THREAD interface which allows for calling essentially random kernel code (whatever a dev codes up) with arguments. At the shell one types test_thread foobar(12345, \string\) or whatever args. The test_thread syscall looks in the set of registered functions for foobar, and passes off a string with (12345, \string\) to the function. Each function is responsible for parsing its own arguments. The args for the test_thread function pointer are the $WORK equivalent of and input sbuf and and output sbuf, which is copyout'd to the calling binary. If there's interest I can clean up the patch a little to show proof-of-concept that builds without all the $WORK gorp. We use this for a few things: unit-testing kernel code, hand-editing of filesystem data to recover customer sites from kernel bugs (sometimes this is possible), etc. Cheers, matthew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: misc/157903: automated kldload for USB class devices
On Jun 24, 2011, at 7:11 AM, Hans Petter Selasky wrote: On Friday 24 June 2011 14:59:37 Robert Millan wrote: 2011/6/24 Hans Petter Selasky hsela...@c2i.net: Very nice. But why not use variable names instead of hardcoding numbers? It makes the output much easier to understand. To save memory. I haven't inspected devd code, but I was under the assumption that variables only lived untill resolved. What would be the point of keeping them in memory after devd has finished parsing the config files? Hi, I haven't checked that, though if you want the readable version, then you need to check the source code. However I could add some code to print a vendor ID comment, based on usbdevs. devd keeps them in memory and expands them when the commands are executed. It will use more memory and be slower if you have lots of variables. Now much more memory and how much slower? I kinda doubt you'd notice on modern gear. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
IPv4 socket bind using IPv6 socket on openjdk6 breaks udp send
We're trying to get our machines IPv6 enabled but in doing so this
seems to break java apps using openjdk6 for UDP sends.
The server seems quite happy to send and receive TCP packets on
IPv6 socket that are bound to IPv4 addresses, but the same is not
true for UDP.
The socket bind works fine and the packets sent to the server arrive
and are processed by the app but when it tries to reply using
send the result is:-
java.io.IOException: Invalid argument
at java.net.PlainDatagramSocketImpl.send(Native Method)
at java.net.DatagramSocket.send(DatagramSocket.java:629)
using truss we see the following:-
socket(PF_INET6,SOCK_DGRAM,0)= 20 (0x14)
setsockopt(0x14,0x29,0x1b,0x7edf0318,0x4,0x0) = 0 (0x0)
setsockopt(0x14,0x,0x20,0x7edf031c,0x4,0x0) = 0 (0x0)
bind(20,{ AF_INET6 [3800::10:0:0:0]:20736 },28) = 0 (0x0)
..
recvfrom(20,0x7eaeb580,1460,0x0,0x7eaed580,0x7eaed5ac) ERR#60
'Operation timed out'
..
sendto(20,\M^?\M^?\M^?\M^?I\aMultiplay :: ...,82,0x0,{ AF_INET6
[3800::10:0:0:0]:20736 },0x1c) ERR#22 'Invalid argument'
sockstat shows it binding correctly
root java 894 21 tcp4 85.236.109.212:25675 *:*
The following PR seems relevant but also seems to indicate it was
fixed back in 2006
http://www.freebsd.org/cgi/query-pr.cgi?pr=92620
Setting -Djava.net.preferIPv4Stack=true does workaround the issue
but when we come to support IPv6 as well as IPv4 this won't work.
Note: net.inet6.ip6.v6only was set to the default 1 but changing
it to 0 has no effect on the issue.
An ideas why tcp in this setup works fine for udp fails only on
send?
Not sure which list is best for this so sorry about the cross
posting.
Regards
Steve
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IPv4 socket bind using IPv6 socket on openjdk6 breaks udp send
Removing -java@ list because the VM is an application on top of the
kernel's network stack, and the issue isn't Java-specific.
Am 24.06.2011 23:11, schrieb Steven Hartland:
We're trying to get our machines IPv6 enabled but in doing so this
seems to break java apps using openjdk6 for UDP sends.
The server seems quite happy to send and receive TCP packets on
IPv6 socket that are bound to IPv4 addresses, but the same is not
true for UDP.
Coincidence, and not guaranteed to work, and possibly using IPv4-mapped
IPv4 addresses (i. e. :::10.11.12.13 style).
See the v6-related sections of
http://www.freebsd.org/doc/en/books/developers-handbook/ipv6.html
The socket bind works fine and the packets sent to the server arrive
and are processed by the app but when it tries to reply using
send the result is:-
java.io.IOException: Invalid argument
at java.net.PlainDatagramSocketImpl.send(Native Method)
at java.net.DatagramSocket.send(DatagramSocket.java:629)
using truss we see the following:-
socket(PF_INET6,SOCK_DGRAM,0)= 20 (0x14)
setsockopt(0x14,0x29,0x1b,0x7edf0318,0x4,0x0) = 0 (0x0)
setsockopt(0x14,0x,0x20,0x7edf031c,0x4,0x0) = 0 (0x0)
bind(20,{ AF_INET6 [3800::10:0:0:0]:20736 },28) = 0 (0x0)
..
sendto(20,\M^?\M^?\M^?\M^?I\aMultiplay :: ...,82,0x0,{ AF_INET6
[3800::10:0:0:0]:20736 },0x1c) ERR#22 'Invalid argument'
You're trying to send to your own address, but you're likely not using
the loopback interface for that. Is that permitted by your firewall
configuration and routing?
sockstat shows it binding correctly
root java 894 21 tcp4 85.236.109.212:25675 *:*
This is unrelated, as it has fd #21 not #20 as in the socket/bind/sendto
calls. You've quoted the wrong line from sockstat output.
Note: net.inet6.ip6.v6only was set to the default 1 but changing
it to 0 has no effect on the issue.
You aren't using IPv4 mapped addresses, and you haven't stated whether
you're using wildcard listeners. Only in that case would it matter.
inet6(4) reads:
IPV6CTL_V6ONLY(ip6.v6only) Boolean: enable/disable the prohib-
ited use of IPv4 mapped address on AF_INET6 sock-
ets. Defaults to on.
An ideas why tcp in this setup works fine for udp fails only on
send?
Are you sure that's what you seeing? It's not a match for what you give
above, but anyways it's an implementation artifact because the tcp code
for v4 and v6 used to be shared and the udp code separate.
It is best to set up one IPv4 and one IPv6 listening socket.
Check the URL above, perhaps that helps your understanding a bit. I
presume 3800::10:0:0:0 is your server?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
