Re: samba/NSSWITCH interaction in fbsd 10 vs fbsd 8
Do you use net/samba36 port? Looks like you don't... @@ -6336,12 +6373,13 @@ NSSSONAMEVERSIONSUFFIX=.2 WINBIND_NSS_EXTRA_OBJS=../nsswitch/winbind_nss_linux.o ;; - *freebsd[[5-9]]*) + *freebsd*) # FreeBSD winbind client is implemented as a wrapper around # the Linux version. NSSSONAMEVERSIONSUFFIX=.1 WINBIND_NSS_EXTRA_OBJS=../nsswitch/winbind_nss_freebsd.o \ ../nsswitch/winbind_nss_linux.o + WINBIND_WINS_NSS_EXTRA_OBJS=../nsswitch/wins_freebsd.o WINBIND_NSS=../nsswitch/nss_winbind.$SHLIBEXT WINBIND_WINS_NSS=../nsswitch/nss_wins.$SHLIBEXT ;; On Mon, Nov 10, 2014 at 1:14 PM, Julian Elischer jul...@freebsd.org wrote: When I try use the libnss_winbind.so that is generated by samba 3.6 I get the following message: NSSWITCH(nss_load_module): winbind, Undefined symbol nss_module_register. First I have to change its' name to nss_winbins.so.1 however because that is what nsswitch is looking for (BTW where is that documented??) then it finds it but fails as mentioned above. This same samba source generates good nss files in 8.0 but under 10 it fails.. Literally it's the same sources just checked out into a different build system. (10 vs 8). Has there been a change in the API for the nss modules? where it he API for nsswitch files documented? Julian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Changing timezone without reboot/restarting each service?
On 11 Nov 2014, at 03:35, Allan Jude allanj...@freebsd.org wrote: jkh@ mentioned this specifically when he gave his talk at EuroBSDCon and MeetBSD, about how Apple solved this in LaunchD, because apparently originally libc DID check /etc/localtime constantly. Darwin also has the notify(3) interface, which allows one-bit messages to be transmitted either from the kernel to userspace or from userspace to userspace very cheaply. This is ideal for this sort of 'something you've cached is change, go and do something expensive to fix it' use (time zone has changed, network connectivity has changed, power state has changed). You can assign notifications to either file descriptors (that can be monitored with kqueue), to signals, or to flags in memory for things where polling is cheaper (as in this case - the libc functions could just check whether a specific flag is set in memory when accessing the time zone info and load a newer one if changed). David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: MK_ vs. WITH_/WITHOUT_ in release/Makefile
On Mon, Nov 10, 2014 at 12:41 PM, Glen Barber g...@freebsd.org wrote: On Mon, Nov 10, 2014 at 09:38:08AM -0500, Rick Miller wrote: Hi all, release/Makefile in CURRENT utilizes MK_* knobs vs. the WITH_/WITHOUT_* knobs seen in release/Makefile in the STABLE/RELEASE branches. Merging a CURRENT version of the Makefile into a RELEASE branch and executing a release build results in an error citing MK_KERNEL_SYMBOLS can't be set by a user. Comparisons of the Makefile between CURRENT and STABLE/RELEASE exposed the difference and changing the knobs from MK_ to WITHOUT_ resolved the error. I have little familiarity with these knobs, but was under the impression the Makefile would not differ like this. Is there documentation describing the use of these knobs between the varying branches and how they are changed from CURRENT to STABLE/RELEASE? These changes are result of src.opts.mk changes (only available in head/) that allows specifying MK_FOO=no instead of WITHOUT_FOO=yes on the command line. The changes were applied to the release/Makefile because it allows more granular tuning for different stages of the release build. For example, one might want to build userland/kernel with WITH_DEBUG_FILES=yes, but does not want that to apply to the resulting ISOs, so a global WITH_DEBUG_FILES=yes and target-specific MK_DEBUG_FILES=no do not collide. Thanks, Glen Scot... The necessary bits exist in STABLE and were, therefore, merged from there as opposed to CURRENT. Your feedback is appreciated. -- Take care Rick Miller ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS-UP: amd64 UEFI boot is broken
On 10 November 2014 20:17, Ed Maste ema...@freebsd.org wrote: UEFI booting is broken for amd64 as of r273582 (Oct 24). The symptom is an apparent hang after the loader transfers control to the kernel (no output from the kernel is observed). Until this is addressed you can checkout an earlier revision or revert r273582 locally. I have committed a workaround for this issue in r274382. The vt(4) EFI framebuffer driver makes use of kernel infrastructure in a way that is not correct, but works in practice, and this was caught by a new assertion added in r273582. My change loosens the assertion to allow efifb's use for now. We will need to fix the early framebuffer implementation in a subsequent change. -Ed ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Unable to build world w/o clang on 11
On Mon, 10 Nov 2014 19:52:48 -0800 Chris H bsd-li...@bsdforge.com wrote On Mon, 10 Nov 2014 19:22:31 -0800 Steve Kargl s...@troutmask.apl.washington.edu wrote On Mon, Nov 10, 2014 at 06:37:35PM -0800, Chris H wrote: === lib/libdpv (depend) rm -f .depend CC='cc ' mkdep -f .depend -a-I/usr/src/lib/libdpv -std=gnu99 /usr/src/lib /libdpv/dialog_util.c /usr/src/lib/libdpv/dialogrc.c /usr/src/lib/libdpv/dprompt c /usr/src/lib/libdpv/dpv.c /usr/src/lib/libdpv/status.c /usr/src/lib/libdpv/ut il.c In file included from /usr/src/lib/libdpv/dialog_util.c:43: In file included from /usr/src/lib/libdpv/dialog_util.h:34: /usr/src/lib/libdpv/dialogrc.h:34:10: fatal error: 'figpar.h' file not found #include figpar.h ^ 1 error generated. /usr/src/lib/libdpv/dialogrc.c:34:10: fatal error: 'figpar.h' file not found Until such time that you can get the tree to build without -j, don't use it. Now, the obvious question: do you have figpar.h in /usr/src? Ugh... it's been a hectic day. Apparently it wasn't included in Revision: 274349 Last Changed Date: 2014-11-10 10:20:46 -0800 (Mon, 10 Nov 2014) :P I'll blow away src, and ports, and checkout what's ever available now. Hoping it's *now* included. ;) Thank you *very* much rubbing my face in the obvious, Steve. :) --Chris Checked out the current version of src from head, that was available (r274365) and gave it another go. While it *did* have the missing file. The results were less than hoped for: cc -O2 -pipe -I/usr/src/sbin/gbde/../../sys -DRESCUE -std=gnu99 -fstack-prote ctor -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Ws trict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/gbde/../../sys/crypto/rijndael/rijndael-api-fst.c cc1: warnings being treated as errors /usr/src/sbin/gbde/../../sys/crypto/rijndael/rijndael-api-fst.c: In function 'ri jndael_padEncrypt': /usr/src/sbin/gbde/../../sys/crypto/rijndael/rijndael-api-fst.c:236: warning: ca st discards qualifiers from pointer target type /usr/src/sbin/gbde/../../sys/crypto/rijndael/rijndael-api-fst.c:237: warning: ca st discards qualifiers from pointer target type /usr/src/sbin/gbde/../../sys/crypto/rijndael/rijndael-api-fst.c:238: warning: ca st discards qualifiers from pointer target type /usr/src/sbin/gbde/../../sys/crypto/rijndael/rijndael-api-fst.c:239: warning: ca st discards qualifiers from pointer target type *** Error code 1 Stop. make[6]: stopped in /usr/src/sbin/gbde *** Error code 1 Stop. make[5]: stopped in /usr/obj/usr/src/rescue/rescue *** Error code 1 Stop. make[4]: stopped in /usr/src/rescue/rescue *** Error code 1 Stop. make[3]: stopped in /usr/src/rescue *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src While I recognize that -CURRENT is a moving target. Things seem a bit brittle, at the moment. I'll check out what's available now (revision), and hope for the best. --Chris -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Unable to build world w/o clang on 11
On Nov 11, 2014, at 07:51, Chris H bsd-li...@bsdforge.com wrote: On Mon, 10 Nov 2014 19:52:48 -0800 Chris H bsd-li...@bsdforge.com wrote On Mon, 10 Nov 2014 19:22:31 -0800 Steve Kargl s...@troutmask.apl.washington.edu wrote On Mon, Nov 10, 2014 at 06:37:35PM -0800, Chris H wrote: === lib/libdpv (depend) rm -f .depend CC='cc ' mkdep -f .depend -a-I/usr/src/lib/libdpv -std=gnu99 /usr/src/lib /libdpv/dialog_util.c /usr/src/lib/libdpv/dialogrc.c /usr/src/lib/libdpv/dprompt c /usr/src/lib/libdpv/dpv.c /usr/src/lib/libdpv/status.c /usr/src/lib/libdpv/ut il.c In file included from /usr/src/lib/libdpv/dialog_util.c:43: In file included from /usr/src/lib/libdpv/dialog_util.h:34: /usr/src/lib/libdpv/dialogrc.h:34:10: fatal error: 'figpar.h' file not found #include figpar.h ^ 1 error generated. /usr/src/lib/libdpv/dialogrc.c:34:10: fatal error: 'figpar.h' file not found Until such time that you can get the tree to build without -j, don't use it. Now, the obvious question: do you have figpar.h in /usr/src? Ugh... it's been a hectic day. Apparently it wasn't included in Revision: 274349 Last Changed Date: 2014-11-10 10:20:46 -0800 (Mon, 10 Nov 2014) :P I'll blow away src, and ports, and checkout what's ever available now. Hoping it's *now* included. ;) Thank you *very* much rubbing my face in the obvious, Steve. :) Checked out the current version of src from head, that was available (r274365) and gave it another go. While it *did* have the missing file. The results were less than hoped for: This issue was fixed just a few hours ago by des@ Cheers! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Changing timezone without reboot/restarting each service?
On Nov 11, 2014, at 00:56, David Chisnall thera...@freebsd.org wrote: On 11 Nov 2014, at 03:35, Allan Jude allanj...@freebsd.org wrote: jkh@ mentioned this specifically when he gave his talk at EuroBSDCon and MeetBSD, about how Apple solved this in LaunchD, because apparently originally libc DID check /etc/localtime constantly. Darwin also has the notify(3) interface, which allows one-bit messages to be transmitted either from the kernel to userspace or from userspace to userspace very cheaply. This is ideal for this sort of 'something you've cached is change, go and do something expensive to fix it' use (time zone has changed, network connectivity has changed, power state has changed). You can assign notifications to either file descriptors (that can be monitored with kqueue), to signals, or to flags in memory for things where polling is cheaper (as in this case - the libc functions could just check whether a specific flag is set in memory when accessing the time zone info and load a newer one if changed). Except that's not how it works for network events: kernel control sockets are used to communicate between the kernel and userland about the state of the network. Kernel control sockets carry kernel event messages. -- Rui Paulo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS-UP: amd64 UEFI boot is broken
On 11 November 2014 07:12, Ed Maste ema...@freebsd.org wrote: On 10 November 2014 20:17, Ed Maste ema...@freebsd.org wrote: UEFI booting is broken for amd64 as of r273582 (Oct 24). The symptom is an apparent hang after the loader transfers control to the kernel (no output from the kernel is observed). Until this is addressed you can checkout an earlier revision or revert r273582 locally. I have committed a workaround for this issue in r274382. The vt(4) EFI framebuffer driver makes use of kernel infrastructure in a way that is not correct, but works in practice, and this was caught by a new assertion added in r273582. My change loosens the assertion to allow efifb's use for now. We will need to fix the early framebuffer implementation in a subsequent change. Woo, thanks! -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Unable to build world w/o clang on 11
On Tue, 11 Nov 2014 08:08:24 -0800 Garrett Cooper yaneurab...@gmail.com wrote On Nov 11, 2014, at 07:51, Chris H bsd-li...@bsdforge.com wrote: On Mon, 10 Nov 2014 19:52:48 -0800 Chris H bsd-li...@bsdforge.com wrote On Mon, 10 Nov 2014 19:22:31 -0800 Steve Kargl s...@troutmask.apl.washington.edu wrote On Mon, Nov 10, 2014 at 06:37:35PM -0800, Chris H wrote: === lib/libdpv (depend) rm -f .depend CC='cc ' mkdep -f .depend -a-I/usr/src/lib/libdpv -std=gnu99 /usr/src/lib /libdpv/dialog_util.c /usr/src/lib/libdpv/dialogrc.c /usr/src/lib/libdpv/dprompt c /usr/src/lib/libdpv/dpv.c /usr/src/lib/libdpv/status.c /usr/src/lib/libdpv/ut il.c In file included from /usr/src/lib/libdpv/dialog_util.c:43: In file included from /usr/src/lib/libdpv/dialog_util.h:34: /usr/src/lib/libdpv/dialogrc.h:34:10: fatal error: 'figpar.h' file not found #include figpar.h ^ 1 error generated. /usr/src/lib/libdpv/dialogrc.c:34:10: fatal error: 'figpar.h' file not found Until such time that you can get the tree to build without -j, don't use it. Now, the obvious question: do you have figpar.h in /usr/src? Ugh... it's been a hectic day. Apparently it wasn't included in Revision: 274349 Last Changed Date: 2014-11-10 10:20:46 -0800 (Mon, 10 Nov 2014) :P I'll blow away src, and ports, and checkout what's ever available now. Hoping it's *now* included. ;) Thank you *very* much rubbing my face in the obvious, Steve. :) Checked out the current version of src from head, that was available (r274365) and gave it another go. While it *did* have the missing file. The results were less than hoped for: This issue was fixed just a few hours ago by des@ Cheers! Thanks for the info, and the words of hope, Garrett. Indeed des@, *did* fix that, Thanks! But sadly. blowing away ports, src, and obj. Then checking out src r274382, and performing a buildworld. Although I got further. it bombed at: === usr.sbin/hyperv (all) === usr.sbin/hyperv/tools (all) cc -O2 -pipe -I/usr/src/usr.sbin/hyperv/tools/../../../sys/dev/hyperv/utiliti es -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k - W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold -style-definition -Wno-pointer-sign -c /usr/src/usr.sbin/hyperv/tools/../../.. /contrib/hyperv/tools/hv_kvp_daemon.c cc1: warnings being treated as errors /usr/src/usr.sbin/hyperv/tools/../../../contrib/hyperv/tools/hv_kvp_daemon.c: In function 'kvp_get_ip_info': /usr/src/usr.sbin/hyperv/tools/../../../contrib/hyperv/tools/hv_kvp_daemon.c:814 : warning: 'ip_buffer' may be used uninitialized in this function *** Error code 1 Stop. make[5]: stopped in /usr/src/usr.sbin/hyperv/tools *** Error code 1 Stop. make[4]: stopped in /usr/src/usr.sbin/hyperv *** Error code 1 Stop. make[3]: stopped in /usr/src/usr.sbin *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src :( Thanks again, Garrett. For taking the time to reply. --Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Changing timezone without reboot/restarting each service?
On 11 Nov 2014, at 04:28, Mark Felder f...@freebsd.org wrote: On Mon, Nov 10, 2014, at 06:36, Lev Serebryakov wrote: After changing timezones in Russia (with replacing /etc/localtime with new file), I found that cron works in old timezone till restart. And all other services do the same, but cron is most obvious here :) Looks like libc reads timezone only once and it could not be chamged for process without restart (which leads to, effectivly, restart of whole server). Is it known problem? I think, it should be fixed somehow. I understand, that re-check timezone file on each time-related call could be expensive, though :( I think this was one of the crowning achievements of systemd, but I'm sure someone can come up with something much more sane than that to address this problem. Actually, it isn't: http://www.freedesktop.org/wiki/Software/systemd/timedated/ This reads Note that this service will not inform you about system time changes. Use timerfd() with CLOCK_REALTIME and TFD_TIMER_CANCEL_ON_SET for that. So it mostly looks like a shared service to provide the graphical time control panel for GNOME. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Unable to build world w/o clang on 11
On 11 Nov 2014, at 20:04, Chris H bsd-li...@bsdforge.com wrote: ... But sadly. blowing away ports, src, and obj. Then checking out src r274382, and performing a buildworld. Although I got further. it bombed at: === usr.sbin/hyperv (all) === usr.sbin/hyperv/tools (all) cc -O2 -pipe -I/usr/src/usr.sbin/hyperv/tools/../../../sys/dev/hyperv/utiliti es -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k - W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold -style-definition -Wno-pointer-sign -c /usr/src/usr.sbin/hyperv/tools/../../.. /contrib/hyperv/tools/hv_kvp_daemon.c cc1: warnings being treated as errors /usr/src/usr.sbin/hyperv/tools/../../../contrib/hyperv/tools/hv_kvp_daemon.c: In function 'kvp_get_ip_info': /usr/src/usr.sbin/hyperv/tools/../../../contrib/hyperv/tools/hv_kvp_daemon.c:814 : warning: 'ip_buffer' may be used uninitialized in this function Yep, this is another false positive from gcc. I've mailed a proposed workaround to Xin Li, but for now, if you compile world and kernel with gcc, use NO_WERROR= and WERROR= in your make.conf. Especially the kernel still needs a bunch of fixes to make it work with gcc again. It's a pity the gcc tinderboxes have been taken offline. Maybe this can be added to the FreeBSD Jenkins instance now? -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: r273918 buildworld broke at semaphore
On Friday, October 31, 2014 4:08:06 pm Beeblebrox wrote: First breakage in a long time. Error is: In file included from cancelpoints_sem_new.c:47: /usr/src/lib/libc/../../include/semaphore.h:41:16: error: field has incomplete type 'struct _usem2' struct _usem2 _kern; ^ /usr/src/lib/libc/../../include/semaphore.h:41:9: note: forward declaration of 'struct _usem2' struct _usem2 _kern; ^ cancelpoints_sem_new.c:66:33: error: use of undeclared identifier 'USEM_MAX_COUNT' _Static_assert(SEM_VALUE_MAX = USEM_MAX_COUNT, SEM_VALUE_MAX too large); ^ cancelpoints_sem_new.c:335:15: warning: implicit declaration of function 'USEM_COUNT' is invalid in C99 [-Wimplicit-function-declaration] *sval = (int)USEM_COUNT(sem-_kern._count); ^ cancelpoints_sem_new.c:342:23: error: use of undeclared identifier 'UMTX_OP_SEM2_WAKE' return _umtx_op(sem, UMTX_OP_SEM2_WAKE, 0, NULL, NULL); ^ cancelpoints_sem_new.c:361:23: error: use of undeclared identifier 'UMTX_OP_SEM2_WAIT' return _umtx_op(sem, UMTX_OP_SEM2_WAIT, 0, ^ cancelpoints_sem_new.c:445:14: error: use of undeclared identifier 'USEM_HAS_WAITERS' if (count USEM_HAS_WAITERS) ^ 1 warning and 5 errors generated. Seems like your tree is not fully up to date? The changes to sem_new.c were committed in the same commit as the changes to sys/umtx.h. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r273165. ZFS ARC: possible memory leak to Inact
On Wednesday, November 05, 2014 4:52:50 am Andriy Gapon wrote: On 04/11/2014 14:55, Steven Hartland wrote: This is likely spikes in uma zones used by ARC. The VM doesn't ever clean uma zones unless it hits a low memory condition, which explains why your little script helps. Check the output of vmstat -z to confirm. Steve, this is nonsense :-) You know perfectly well that UMA memory is Wired not Inactive. Grab the code at www.freebsd.org/~jhb/vm_objects/. Build and load the kld and then use the vm_objects binary to generate a list of the active VM objects in the system along with counts of how many active / inactive pages each object contains. For your case with lots of inactive memory, you probably want something like 'vm_objects | sort -n -k 2'. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Changing timezone without reboot/restarting each service?
On Monday, November 10, 2014 7:36:19 am Lev Serebryakov wrote: After changing timezones in Russia (with replacing /etc/localtime with new file), I found that cron works in old timezone till restart. And all other services do the same, but cron is most obvious here :) Looks like libc reads timezone only once and it could not be chamged for process without restart (which leads to, effectivly, restart of whole server). Is it known problem? I think, it should be fixed somehow. I understand, that re-check timezone file on each time-related call could be expensive, though :( In practice, timezone changes are very rare, so rechecking the file is quite expensive to do. I think having to restart processes is fine for this. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Unable to build world w/o clang on 11
On Tue, 11 Nov 2014 20:21:48 +0100 Dimitry Andric d...@freebsd.org wrote On 11 Nov 2014, at 20:04, Chris H bsd-li...@bsdforge.com wrote: ... But sadly. blowing away ports, src, and obj. Then checking out src r274382, and performing a buildworld. Although I got further. it bombed at: === usr.sbin/hyperv (all) === usr.sbin/hyperv/tools (all) cc -O2 -pipe -I/usr/src/usr.sbin/hyperv/tools/../../../sys/dev/hyperv/utiliti es -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k - W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold -style-definition -Wno-pointer-sign -c /usr/src/usr.sbin/hyperv/tools/../../.. /contrib/hyperv/tools/hv_kvp_daemon.c cc1: warnings being treated as errors /usr/src/usr.sbin/hyperv/tools/../../../contrib/hyperv/tools/hv_kvp_daemon.c: In function 'kvp_get_ip_info': /usr/src/usr.sbin/hyperv/tools/../../../contrib/hyperv/tools/hv_kvp_daemon.c: 814 : warning: 'ip_buffer' may be used uninitialized in this function Yep, this is another false positive from gcc. I've mailed a proposed workaround to Xin Li, but for now, if you compile world and kernel with gcc, use NO_WERROR= and WERROR= in your make.conf. Especially the kernel still needs a bunch of fixes to make it work with gcc again. It's a pity the gcc tinderboxes have been taken offline. Maybe this can be added to the FreeBSD Jenkins instance now? Thank you *very* much, Dimitry. For the informative reply. Yes. I agree, adding a task for Jenkins seems like a *very* good idea. Well, it looks like a real gamble not going with defaults, for now. I guess attempts using gcc as base compiler is off the table, for now. This must really hit some of the other ARCHS pretty hard. I can't imagine trying to develop under these circumstances. Here's hoping for improvements in this area soon! Thanks again, Dimitry. --Chris -Dimitry ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Changing timezone without reboot/restarting each service?
On Tue, Nov 11, 2014 at 01:57:40PM -0500, John Baldwin wrote: On Monday, November 10, 2014 7:36:19 am Lev Serebryakov wrote: After changing timezones in Russia (with replacing /etc/localtime with new file), I found that cron works in old timezone till restart. And all other services do the same, but cron is most obvious here :) Looks like libc reads timezone only once and it could not be chamged for process without restart (which leads to, effectivly, restart of whole server). Is it known problem? I think, it should be fixed somehow. I understand, that re-check timezone file on each time-related call could be expensive, though :( In practice, timezone changes are very rare, so rechecking the file is quite expensive to do. I think having to restart processes is fine for this. For cron it seems like a neglegable cost as it has to check a file and a directory at each interval. For most other things it seems like a waste of resources to check. Even on systems like MacOS where this is solved better, lots of behavior is application dependent. For example, current versions of Omni Focus behave very oddly when the timezone changes underneath them. In practice you need to restart the application when timezones change (such as after a flight). Just making libc aware isn't a magic bullet. -- Brooks pgpExOQT1Hx1X.pgp Description: PGP signature
Re: Changing timezone without reboot/restarting each service?
On Nov 11, 2014, at 10:57 AM, John Baldwin j...@freebsd.org wrote: On Monday, November 10, 2014 7:36:19 am Lev Serebryakov wrote: After changing timezones in Russia (with replacing /etc/localtime with new file), I found that cron works in old timezone till restart. And all other services do the same, but cron is most obvious here :) Looks like libc reads timezone only once and it could not be chamged for process without restart (which leads to, effectivly, restart of whole server). Is it known problem? I think, it should be fixed somehow. I understand, that re-check timezone file on each time-related call could be expensive, though :( In practice, timezone changes are very rare, so rechecking the file is quite expensive to do. I think having to restart processes is fine for this. In theory, timezone changes should be very rare. We've actually had about ten TZ updates in 2014; the most recent was FET - MSK for Belarus plus minor tweaks to IDT vs ICT. If you're working within the scope of a single country, I suspect that one could ignore the bulk of TZ updates and be fine most of the time. If you're world-wide, however, TZ update frequency becomes more noticeable Regards, -- -Chuck ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Changing timezone without reboot/restarting each service?
On Tue, Nov 11, 2014, at 13:16, Dimitry Andric wrote: On 11 Nov 2014, at 04:28, Mark Felder f...@freebsd.org wrote: On Mon, Nov 10, 2014, at 06:36, Lev Serebryakov wrote: After changing timezones in Russia (with replacing /etc/localtime with new file), I found that cron works in old timezone till restart. And all other services do the same, but cron is most obvious here :) Looks like libc reads timezone only once and it could not be chamged for process without restart (which leads to, effectivly, restart of whole server). Is it known problem? I think, it should be fixed somehow. I understand, that re-check timezone file on each time-related call could be expensive, though :( I think this was one of the crowning achievements of systemd, but I'm sure someone can come up with something much more sane than that to address this problem. Actually, it isn't: http://www.freedesktop.org/wiki/Software/systemd/timedated/ This reads Note that this service will not inform you about system time changes. Use timerfd() with CLOCK_REALTIME and TFD_TIMER_CANCEL_ON_SET for that. So it mostly looks like a shared service to provide the graphical time control panel for GNOME. Aha, I guess the article I read was as reliable as jamming all that code into PID 1. :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Changing timezone without reboot/restarting each service?
On Tuesday, November 11, 2014 3:16:19 pm Charles Swiger wrote: On Nov 11, 2014, at 10:57 AM, John Baldwin j...@freebsd.org wrote: On Monday, November 10, 2014 7:36:19 am Lev Serebryakov wrote: After changing timezones in Russia (with replacing /etc/localtime with new file), I found that cron works in old timezone till restart. And all other services do the same, but cron is most obvious here :) Looks like libc reads timezone only once and it could not be chamged for process without restart (which leads to, effectivly, restart of whole server). Is it known problem? I think, it should be fixed somehow. I understand, that re-check timezone file on each time-related call could be expensive, though :( In practice, timezone changes are very rare, so rechecking the file is quite expensive to do. I think having to restart processes is fine for this. In theory, timezone changes should be very rare. We've actually had about ten TZ updates in 2014; the most recent was FET - MSK for Belarus plus minor tweaks to IDT vs ICT. If you're working within the scope of a single country, I suspect that one could ignore the bulk of TZ updates and be fine most of the time. If you're world-wide, however, TZ update frequency becomes more noticeable The vast majority of updates are historical changes however. Having used a timezone-aware version of cron for an international company so we can schedule jobs across multiple timezones for a single machine (times N machines scattered around the globe) for the last 4 or 5 years, FET - MSK was the first time we had a timezone change in that span that actually impacted our operations (and we've just restarted cron / rebooted to cope). -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
netmap: extension to store user data per packet/slot?
Hi Luigi,
hi all,
so I was running into logistics issues with netmap(4)
with regard to zero-copy and redirection through pipes:
working on a load-balancing framework revealed that it
is very hard to track a packet's origins to later move
it onward to the respective outgoing interface, be it
another device or the host stack.
Long story short: user data needs to be stored for the
packet buffer or slot.
There are three ways that I can see so far:
(1) Allocate a netmap pipe pair for each interface,
in case of transparent mode also a pipe for the
host stack each. That's a lot of pipes and
most likely insane, but it won't extend the ABI.
(2) Store the additional data in the actual buffer.
That is sort of ok, but seems sluggish WRT cache
behaviour -- maybe the buffer won't be read but
it needs to be written. Sure, we can store it at
the end, but there already resides the packet
timestamp if enabled (if I recall correctly).
Wouldn't extend the ABI per se, but might collide
with the timestamping
(3) Make room in struct netmap_slot itself like this:
diff --git a/sys/net/netmap.h b/sys/net/netmap.h
index 15ebf73..d0a9c0e 100644
--- a/sys/net/netmap.h
+++ b/sys/net/netmap.h
@@ -147,6 +147,7 @@ struct netmap_slot {
uint16_t len; /* length for this slot */
uint16_t flags; /* buf changed, etc. */
uint64_t ptr; /* pointer for indirect buffers */
+ uint64_t userdata; /* reserved storage for caller */
};
It could also be broken down in two fields with uint32_t
each; not sure what would be more sensible. This of course
requires an API bump, although it should be backwards
compatible.
Any feedback on this is highly appreciated.
Cheers,
Franco
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: netmap: extension to store user data per packet/slot?
... I'm confused. Do you have the slot id already, right? Why not
allocate an array of userdata pointers somewhere else and just use the
netmap slot id as an indirection into that?
-adrian
On 11 November 2014 13:13, Franco Fichtner fra...@lastsummer.de wrote:
Hi Luigi,
hi all,
so I was running into logistics issues with netmap(4)
with regard to zero-copy and redirection through pipes:
working on a load-balancing framework revealed that it
is very hard to track a packet's origins to later move
it onward to the respective outgoing interface, be it
another device or the host stack.
Long story short: user data needs to be stored for the
packet buffer or slot.
There are three ways that I can see so far:
(1) Allocate a netmap pipe pair for each interface,
in case of transparent mode also a pipe for the
host stack each. That's a lot of pipes and
most likely insane, but it won't extend the ABI.
(2) Store the additional data in the actual buffer.
That is sort of ok, but seems sluggish WRT cache
behaviour -- maybe the buffer won't be read but
it needs to be written. Sure, we can store it at
the end, but there already resides the packet
timestamp if enabled (if I recall correctly).
Wouldn't extend the ABI per se, but might collide
with the timestamping
(3) Make room in struct netmap_slot itself like this:
diff --git a/sys/net/netmap.h b/sys/net/netmap.h
index 15ebf73..d0a9c0e 100644
--- a/sys/net/netmap.h
+++ b/sys/net/netmap.h
@@ -147,6 +147,7 @@ struct netmap_slot {
uint16_t len; /* length for this slot */
uint16_t flags; /* buf changed, etc. */
uint64_t ptr; /* pointer for indirect buffers */
+ uint64_t userdata; /* reserved storage for caller */
};
It could also be broken down in two fields with uint32_t
each; not sure what would be more sensible. This of course
requires an API bump, although it should be backwards
compatible.
Any feedback on this is highly appreciated.
Cheers,
Franco
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r273918 buildworld broke at semaphore
On Tue, Nov 11, 2014 at 1:33 PM, John Baldwin j...@freebsd.org wrote: On Friday, October 31, 2014 4:08:06 pm Beeblebrox wrote: First breakage in a long time. Error is: In file included from cancelpoints_sem_new.c:47: /usr/src/lib/libc/../../include/semaphore.h:41:16: error: field has incomplete type 'struct _usem2' struct _usem2 _kern; ^ /usr/src/lib/libc/../../include/semaphore.h:41:9: note: forward declaration of 'struct _usem2' struct _usem2 _kern; ^ cancelpoints_sem_new.c:66:33: error: use of undeclared identifier 'USEM_MAX_COUNT' _Static_assert(SEM_VALUE_MAX = USEM_MAX_COUNT, SEM_VALUE_MAX too large); ^ cancelpoints_sem_new.c:335:15: warning: implicit declaration of function 'USEM_COUNT' is invalid in C99 [-Wimplicit-function-declaration] *sval = (int)USEM_COUNT(sem-_kern._count); ^ cancelpoints_sem_new.c:342:23: error: use of undeclared identifier 'UMTX_OP_SEM2_WAKE' return _umtx_op(sem, UMTX_OP_SEM2_WAKE, 0, NULL, NULL); ^ cancelpoints_sem_new.c:361:23: error: use of undeclared identifier 'UMTX_OP_SEM2_WAIT' return _umtx_op(sem, UMTX_OP_SEM2_WAIT, 0, ^ cancelpoints_sem_new.c:445:14: error: use of undeclared identifier 'USEM_HAS_WAITERS' if (count USEM_HAS_WAITERS) ^ 1 warning and 5 errors generated. Seems like your tree is not fully up to date? The changes to sem_new.c were committed in the same commit as the changes to sys/umtx.h. Maybe it's another problem. buildworld may be picking up umtx.h from /usr/include which is the old version. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Cheers, Henry ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r273918 buildworld broke at semaphore
Seems like your tree is not fully up to date? The changes to sem_new.c were committed in the same commit as the changes to sys/umtx.h. I deleted the entire contents of /usr/src, then did # svn co svn://svn.freebsd.org/base/head Buildworld breaks at same place (semaphore) This error AFAIK, was already combined with: http://freebsd.1045724.n5.nabble.com/r273910-build-failure-if-lt-sys-umtx-h-gt-is-out-of-date-td5961186.html Speaking of out-of-date, http://freebsd.1045724.n5.nabble.com/version-number-error-with-ports-td5961642.html Regards. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: netmap: extension to store user data per packet/slot?
Hi Adrian, On 11 Nov 2014, at 22:22, Adrian Chadd adr...@freebsd.org wrote: ... I'm confused. Do you have the slot id already, right? Why not allocate an array of userdata pointers somewhere else and just use the netmap slot id as an indirection into that? The slot id is per ring and there are a lot of them. In case of zero-copy the slot changes at least 1. Consider two processes for the load balancing case. Process 1 attaches to the devices and Process 2 only has a a pipe pair for receiving and sending packets back to Process 1 after processing, because only that process has access to the real devices: em0, em1, etc. --RX/TX-- Process 1 --pipe pair-- Process 2 (Hardware)(Balancer) (Worker) There is no way to trace packet origin back to em0 or em1 after pushing the packets through the pipe pair unless either the pipes are unique for each device or there is another means to keep its state. Should, however, the buffer id be unique that would make it easy to do what you suggest, but I don't know the netmap(4) internals by heart. It seems a wee unnatural to rebuild tracing of packets in userland when netmap(4) has all the infrastructure needed to deal with this effectively, but I'm not opposed to doing that to avoid API/ABI changes. Speaking of those, should volatile internals change regarding the buffer id that would also break the attempts to deal with the issue consistently. Cheers, Franco ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: netmap: extension to store user data per packet/slot?
On 11 November 2014 13:41, Franco Fichtner fra...@lastsummer.de wrote: Hi Adrian, On 11 Nov 2014, at 22:22, Adrian Chadd adr...@freebsd.org wrote: ... I'm confused. Do you have the slot id already, right? Why not allocate an array of userdata pointers somewhere else and just use the netmap slot id as an indirection into that? The slot id is per ring and there are a lot of them. In case of zero-copy the slot changes at least 1. Consider two processes for the load balancing case. Process 1 attaches to the devices and Process 2 only has a a pipe pair for receiving and sending packets back to Process 1 after processing, because only that process has access to the real devices: em0, em1, etc. --RX/TX-- Process 1 --pipe pair-- Process 2 (Hardware)(Balancer) (Worker) There is no way to trace packet origin back to em0 or em1 after pushing the packets through the pipe pair unless either the pipes are unique for each device or there is another means to keep its state. Should, however, the buffer id be unique that would make it easy to do what you suggest, but I don't know the netmap(4) internals by heart. It seems a wee unnatural to rebuild tracing of packets in userland when netmap(4) has all the infrastructure needed to deal with this effectively, but I'm not opposed to doing that to avoid API/ABI changes. Speaking of those, should volatile internals change regarding the buffer id that would also break the attempts to deal with the issue consistently. Ah, I see. You're missing some unique identifier for each netmap buffer. I thought there was one already. Silly me. Luigi? -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: netmap: extension to store user data per packet/slot?
On 11 Nov 2014, at 22:48, Adrian Chadd adr...@freebsd.org wrote: Ah, I see. You're missing some unique identifier for each netmap buffer. I thought there was one already. Silly me. Exactly, and, no, thank you for making clear what is needed. :) A little more on this: I think struct netmap_slot is convenient due to the fact that in zero-copy one wouldn't want to mess with the actual buffer for speed and userland code already touches slot internals for each ring transition so there is no performance degradation. The key benefit is that if userland can use this storage freely netmap(4) doesn't get in the way of building complex setups that require decoupled logic and each ring hop may alter the state as required. Cheers, Franco ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Build failed in Jenkins: FreeBSD_HEAD #1820
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/1820/changes Changes: [glebius] Remove SF_KQUEUE code. This code was developed at Netflix, but was not ever used. It didn't go into stable/10, neither was documented. It might be useful, but we collectively decided to remove it, rather leave it abandoned and unmaintained. It is removed in one single commit, so restoring it should be easy, if anyone wants to reopen this idea. Sponsored by: Netflix [jhb] Add device ID for the T502-BT (dual-port 1G) adapter. Reviewed by:np MFC after: 1 week [dteske] Fix whitespace. Thanks to: nwhitehorn [jhb] Move NFS and TFTP filesystems before the synthetic filesystems (bzip, gzip, and split). Real filesystems should always be listed first so that the bare filename is tried before alternate filenames. For PXE booting in particular this can remove a lot of spurious pathname lookups. While here, move splitfs to the bottom after the bzip and gzip filesystems as it is the least often used. Tested by: Prokash Sinha psi...@panasas.com MFC after: 1 week [jkim] Use the correct device. Note this commit complements r274386. PR: 194884 [dteske] Default `bsdconfig timezone' and `tzsetup' to `-s' in a VM. Recommended by: cperciva Reviewed by:cperciva Relnotes: tzsetup and bsdconfig now assume that the hardware clock inside a VM is set to UTC [dim] Change kbdb's kthr::cpu field into an int, to avoid gcc warnings about comparing it with NOCPU, which became -1 recently. While here, avoid using it for address calculations if it is negative. Reviewed by:jhb, adrian MFC after: 1 week -- [...truncated 278416 lines...] ctfconvert -L VERSION -g mv.o --- ioctl.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/altq -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/dev/hptmv/ioctl.c --- hptproc.o --- ctfconvert -L VERSION -g hptproc.o --- hv_net_vsc.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/altq -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/dev/hyperv/netvsc/hv_net_vsc.c --- ioctl.o --- ctfconvert -L VERSION -g ioctl.o --- gui_lib.o --- ctfconvert -L VERSION -g gui_lib.o --- hv_netvsc_drv_freebsd.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/altq -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd. c --- hv_rndis_filter.o
Re: netmap: extension to store user data per packet/slot?
Franco, apparently you want some user-defined metadata to move along with the packet, but i do not think it is reasonable to put it in the slots. If we do that, what about timestamps, flow IDs, interface and queue index and all the rest of the things that we normally find in an mbuf/skbuf ? This is not going to scale. Also consider that at some point you may use a different arrangement (with packets passed along VALE switches or physical interfaces etc.) i believe the most reasonable place to put the extra info is at the end of the packet and possibly bump the length in the slot so you are safe in case the packet is copied. There is no timestamp appended to the packet at the moment, it was a feature i thought somebody may want to have, but between the relative scarcity of hardware that provides per-packet timestamps, and the questionable usefulness of the same, i doubt it will be available. cheers luigi On Tue, Nov 11, 2014 at 2:01 PM, Franco Fichtner fra...@lastsummer.de wrote: On 11 Nov 2014, at 22:48, Adrian Chadd adr...@freebsd.org wrote: Ah, I see. You're missing some unique identifier for each netmap buffer. I thought there was one already. Silly me. Exactly, and, no, thank you for making clear what is needed. :) A little more on this: I think struct netmap_slot is convenient due to the fact that in zero-copy one wouldn't want to mess with the actual buffer for speed and userland code already touches slot internals for each ring transition so there is no performance degradation. The key benefit is that if userland can use this storage freely netmap(4) doesn't get in the way of building complex setups that require decoupled logic and each ring hop may alter the state as required. Cheers, Franco -- -+--- Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/. Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+--- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Jenkins build is back to normal : FreeBSD_HEAD #1821
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/1821/changes ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
buildworld fails: spa_maxblocksize
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So the ztest link fails looking for spa_maxblocksize, which is defined in sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c I don't see which lib it is included in. One of zpool, zfs, or zfs_core, apparently. As my build system is root on zfs, I am a bit nervous about just installing those (shouldn't buildworld take care of this?) It looks to me that my buildworld environment is reaching out to the exterior system, is that right? I have set export MAKEOBJDIRPREFIX=/usr/obj before invoking buildworld, but it doesn't help. Ideas? Thanks, Russell -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUYsW4AAoJEFnLrGVSDFaE6RwP/RL43zI7dIp3Xl3WSEVpCjLH uz7PLKjcHpJoLP8MU4cA6QYB+w2aIT6L5xEwdWDvFJXj1TIV0cgyd9Pn/nSmxKnD 2grZxcHmdKV9Lkmvegb6BaGs0ysSHbaVr95XIpRNCBXM9gE+8HIqLgFhkDPQCaRU OjbOOjLpdfdW5qWlQasMBVwsnLJHpd0TJKwV43NQYMkmohLsQWbPvEA72N5X1131 UzJZGP2SMivNwlyW++V0ZbNflsaR40IsZk+1BJaHS5ywnFVgXqj1uFnv5l0TfzUE nUsIcrQ00/ETpcypCnsHuJyUOKey/OzVyLLlzmSSpxUtDBU/2QKNxeVtkroLvJIf w6IBR9H6mWIzebNKodxnP7jkE59yMpgEzvFzNHwuc3EVhYRLK4eD7TN524DV3/KK 81b2rdpaPXHh+PqFJQ82XHlpV1pCn0JxQNUjVOzuiXchg7HQAJdBrJhTGsb/g0Z/ KxEuk7t+WchcIakemFQNPmvyg3r2UfzMTyrNN2nxyCRSXk94Xgw8GyWl9f+5DmtR m5gIdEVNpIijwBeYZ+ctDjzRrRJ+cwnVq/35Doiot+lvefDo3Ky00+5w8iHwPAmT rJ1X/lX00CmBcaU/bginYBJCSckvBOuoU6pW6W8F3wvsVKCOmBnLTz5e64P/i62R hLnD6BcqlmCORw6FqMaO =totl -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: samba/NSSWITCH interaction in fbsd 10 vs fbsd 8
On 11/11/14, 4:28 PM, Timur I. Bakeyev wrote: Do you use net/samba36 port? Looks like you don't... It occurred to me after posting to check the port and I found this.. The company decided to go the independent route before I joined so they don't use the port. They have a huge set of diffs to samba so it kind of makes sense. @@ -6336,12 +6373,13 @@ NSSSONAMEVERSIONSUFFIX=.2 WINBIND_NSS_EXTRA_OBJS=../nsswitch/winbind_nss_linux.o ;; - *freebsd[[5-9]]*) + *freebsd*) # FreeBSD winbind client is implemented as a wrapper around # the Linux version. NSSSONAMEVERSIONSUFFIX=.1 WINBIND_NSS_EXTRA_OBJS=../nsswitch/winbind_nss_freebsd.o \ ../nsswitch/winbind_nss_linux.o + WINBIND_WINS_NSS_EXTRA_OBJS=../nsswitch/wins_freebsd.o WINBIND_NSS=../nsswitch/nss_winbind.$SHLIBEXT WINBIND_WINS_NSS=../nsswitch/nss_wins.$SHLIBEXT ;; On Mon, Nov 10, 2014 at 1:14 PM, Julian Elischer jul...@freebsd.org mailto:jul...@freebsd.org wrote: When I try use the libnss_winbind.so that is generated by samba 3.6 I get the following message: NSSWITCH(nss_load_module): winbind, Undefined symbol nss_module_register. First I have to change its' name to nss_winbins.so.1 however because that is what nsswitch is looking for (BTW where is that documented??) then it finds it but fails as mentioned above. This same samba source generates good nss files in 8.0 but under 10 it fails.. Literally it's the same sources just checked out into a different build system. (10 vs 8). Has there been a change in the API for the nss modules? where it he API for nsswitch files documented? Julian ___ freebsd-current@freebsd.org mailto:freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org mailto:freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
