Re: picking a new AF_* number for NETLINK ?
On Fri, Jan 17, 2014 at 12:19:02AM +0100, Luigi Rizzo wrote: In porting the kernel openvswitch code to FreeBSD we have implemented netlink sockets, so we need to pick a number to use for AF_NETLINK/PF_NETLINK in the messages. Obviously we'd like ovs to be loadable as a module on existing kernels, so i wonder if there are any restrictions on what we can use -- specifically, whether we should make sure that AF_NETLINK AF_MAX or that is irrelevant. I asked this question a couple of month ago to Alfred (who did the reservation stuff) exactly for AF_NETLINK which I planned to implement here is his answer: | You want to take 38. | | The next person should take 40. | | All odds until 133 are allocated for vendors and should not be used by FreeBSD | code. regards, Bapt pgpUQ5rzen58H.pgp Description: PGP signature
binary-only modules with SDT
Does anybody know if there are any third-party binary-only modules that use SDT? -- Andriy Gapon ___ 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
[CFT] updated ofwfb driver vt(9)
Hello hackers!
I did updated version of vt's ofwfb driver, but have no HW to test.
It will be very nice if someone try it on ppc/sparc device.
Instructions on how to enable vt(9) (newcons) can be found here:
https://wiki.freebsd.org/Newcons
Patch to HEAD in attachment. (hope it will not be stripped)
xf86-video-scfb expected to work too :)
Many-many thanks!
WBW
--
Aleksandr Rybalko r...@freebsd.org
Index: ofwfb.c
===
--- ofwfb.c (revision 260753)
+++ ofwfb.c (working copy)
@@ -30,8 +30,10 @@
#include sys/param.h
#include sys/kernel.h
#include sys/systm.h
+#include sys/fbio.h
#include dev/vt/vt.h
+#include dev/vt/hw/fb/vt_fb.h
#include dev/vt/colors/vt_termcolors.h
#include vm/vm.h
@@ -47,25 +49,19 @@
#include dev/ofw/ofw_pci.h
struct ofwfb_softc {
+ struct fb_info info;
+
+ /* Own variables. */
phandle_t sc_node;
-
- intptr_t sc_addr;
- int sc_depth;
- int sc_stride;
-
- bus_space_tag_t sc_memt;
-
- uint32_t sc_colormap[16];
+ bus_space_tag_t sc_memt;
};
static vd_init_t ofwfb_init;
-static vd_blank_t ofwfb_blank;
-static vd_bitbltchr_t ofwfb_bitbltchr;
static const struct vt_driver vt_ofwfb_driver = {
.vd_init = ofwfb_init,
- .vd_blank = ofwfb_blank,
- .vd_bitbltchr = ofwfb_bitbltchr,
+ .vd_blank = vt_fb_blank,
+ .vd_bitbltchr = vt_fb_bitbltchr,
.vd_priority = VD_PRIORITY_GENERIC+1,
};
@@ -75,86 +71,8 @@
/* XXX: hardcoded max size */
static void
-ofwfb_blank(struct vt_device *vd, term_color_t color)
+ofwfb_initialize(struct ofwfb_softc *sc)
{
- struct ofwfb_softc *sc = vd-vd_softc;
- u_int ofs;
- uint32_t c;
-
- switch (sc-sc_depth) {
- case 8:
- for (ofs = 0; ofs sc-sc_stride*vd-vd_height; ofs++)
- *(uint8_t *)(sc-sc_addr + ofs) = color;
- break;
- case 32:
- c = sc-sc_colormap[color];
- for (ofs = 0; ofs sc-sc_stride*vd-vd_height; ofs++)
- *(uint32_t *)(sc-sc_addr + 4*ofs) = c;
- break;
- default:
- /* panic? */
- break;
- }
-}
-
-static void
-ofwfb_bitbltchr(struct vt_device *vd, const uint8_t *src, const uint8_t *mask,
-int bpl, vt_axis_t top, vt_axis_t left, unsigned int width,
-unsigned int height, term_color_t fg, term_color_t bg)
-{
- struct ofwfb_softc *sc = vd-vd_softc;
- u_long line;
- uint32_t fgc, bgc;
- int c;
- uint8_t b, m;
-
- fgc = sc-sc_colormap[fg];
- bgc = sc-sc_colormap[bg];
- b = m = 0;
-
- /* Don't try to put off screen pixels */
- if (((left + width) vd-vd_width) || ((top + height)
- vd-vd_height))
- return;
-
- line = (sc-sc_stride * top) + left * sc-sc_depth/8;
- for (; height 0; height--) {
- for (c = 0; c width; c++) {
- if (c % 8 == 0)
-b = *src++;
- else
-b = 1;
- if (mask != NULL) {
-if (c % 8 == 0)
- m = *mask++;
-else
- m = 1;
-/* Skip pixel write, if mask has no bit set. */
-if ((m 0x80) == 0)
- continue;
- }
- switch(sc-sc_depth) {
- case 8:
-*(uint8_t *)(sc-sc_addr + line + c) =
-b 0x80 ? fg : bg;
-break;
- case 32:
-*(uint32_t *)(sc-sc_addr + line + 4*c) =
-(b 0x80) ? fgc : bgc;
-break;
- default:
-/* panic? */
-break;
- }
- }
- line += sc-sc_stride;
- }
-}
-
-static void
-ofwfb_initialize(struct vt_device *vd)
-{
- struct ofwfb_softc *sc = vd-vd_softc;
char name[64];
ihandle_t ih;
int i;
@@ -170,16 +88,16 @@
* Set up the color map
*/
- switch (sc-sc_depth) {
+ switch (sc-info.fb_bpp) {
case 8:
- vt_generate_vga_palette(sc-sc_colormap, COLOR_FORMAT_RGB, 255,
+ vt_generate_vga_palette(sc-info.fb_cmap, COLOR_FORMAT_RGB, 255,
0, 255, 8, 255, 16);
for (i = 0; i 16; i++) {
OF_call_method(color!, ih, 4, 1,
- (cell_t)((sc-sc_colormap[i] 16) 0xff),
- (cell_t)((sc-sc_colormap[i] 8) 0xff),
- (cell_t)((sc-sc_colormap[i] 0) 0xff),
+ (cell_t)((sc-info.fb_cmap[i] 16) 0xff),
+ (cell_t)((sc-info.fb_cmap[i] 8) 0xff),
+ (cell_t)((sc-info.fb_cmap[i] 0) 0xff),
(cell_t)i, retval);
}
break;
@@ -192,24 +110,22 @@
* endianness slightly different. Figure out the host-view
* endianness of the frame buffer.
*/
- oldpix = bus_space_read_4(sc-sc_memt, sc-sc_addr, 0);
- bus_space_write_4(sc-sc_memt, sc-sc_addr, 0, 0xff00);
- if (*(uint8_t *)(sc-sc_addr) == 0xff)
- vt_generate_vga_palette(sc-sc_colormap,
+ oldpix = bus_space_read_4(sc-sc_memt, sc-info.fb_vbase, 0);
+ bus_space_write_4(sc-sc_memt, sc-info.fb_vbase, 0, 0xff00);
+ if (*(uint8_t *)(sc-info.fb_vbase) == 0xff)
+ vt_generate_vga_palette(sc-info.fb_cmap,
COLOR_FORMAT_RGB, 255, 16, 255, 8, 255, 0);
else
- vt_generate_vga_palette(sc-sc_colormap,
+ vt_generate_vga_palette(sc-info.fb_cmap,
COLOR_FORMAT_RGB, 255, 0, 255, 8, 255, 16);
- bus_space_write_4(sc-sc_memt, sc-sc_addr, 0, oldpix);
+ bus_space_write_4(sc-sc_memt, sc-info.fb_vbase, 0, oldpix);
break;
default:
- panic(Unknown color space depth %d, sc-sc_depth);
+ panic(Unknown color space depth
Re: picking a new AF_* number for NETLINK ?
On 17.01.2014 03:19, Luigi Rizzo wrote: In porting the kernel openvswitch code to FreeBSD we have implemented netlink sockets, so we need to pick a Wow, great! How deep you're planning to go with netlink support? E.g. sockets with NETLINK_GENERIC OVS-related CMDs, or NETLINK_ROUTE (and other families like FW) as well? number to use for AF_NETLINK/PF_NETLINK in the messages. Obviously we'd like ovs to be loadable as a module on existing kernels, so i wonder if there are any restrictions on what we can use -- specifically, whether we should make sure that AF_NETLINK AF_MAX or that is irrelevant. cheers luigi ___ 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: picking a new AF_* number for NETLINK ?
On Fri, Jan 17, 2014 at 7:57 AM, Alexander V. Chernikov melif...@freebsd.org wrote: On 17.01.2014 03:19, Luigi Rizzo wrote: In porting the kernel openvswitch code to FreeBSD we have implemented netlink sockets, so we need to pick a Wow, great! How deep you're planning to go with netlink support? E.g. sockets with NETLINK_GENERIC OVS-related CMDs, or NETLINK_ROUTE (and other families like FW) as well? for the time being we focus on the ovs-related commands. Our initial prototype overloaded PF_ROUTE: if the first message on a socket carried a PF_NETLINK identifier then all subsequent i/o is routed to the netlink routines. However this required small changes to route.c so now we are going to do the real thing (using a PF_NETLINK domain). cheers luigi ___ 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
svn 260311 breaks gcc builds on releng9 ?
Hi, I am seeing an odd problem which seems to be triggered by svn260311 I have two machines running snapshots of stable/9 from last fall (one 255898 sep.26, the other 258126 nov.14). All is amd64 Build a recent head (260311 and newer) with gcc fails on the sep.26 machine: ... 19:51:22 === gnu/usr.bin/cc/cc1plus (all) PROG CC /media/bsd10/usr/home/luigi/FreeBSD/head/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/main.c ... PROG CC /media/bsd10/usr/home/luigi/FreeBSD/head/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/except.c parser.o: In function `cp_parser_objc_tentative_protocol_refs_opt': parser.c:(.text+0x14665): undefined reference to `cp_objc_protocol_id_list' *** [cc1plus-dummy] Error code 1 1 error but works on the newer one. svn 260310 builds on both. I am a bit unclear on what is going on because the missing symbol (cp_objc_protocol_id_list) only appears in the source file parser.c and in a ChangeLog.apple file, so maybe it is generated and the actual failure is at some earlier stage. Hope this helps tracking the problem. thanks luigi ___ 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: svn 260311 breaks gcc builds on releng9 ?
Hello Luigi; On 17.01.2014 15:18, Luigi Rizzo wrote: Hi, I am seeing an odd problem which seems to be triggered by svn260311 I have two machines running snapshots of stable/9 from last fall (one 255898 sep.26, the other 258126 nov.14). All is amd64 Build a recent head (260311 and newer) with gcc fails on the sep.26 machine: ... 19:51:22 === gnu/usr.bin/cc/cc1plus (all) PROG CC /media/bsd10/usr/home/luigi/FreeBSD/head/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/main.c ... PROG CC /media/bsd10/usr/home/luigi/FreeBSD/head/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/except.c parser.o: In function `cp_parser_objc_tentative_protocol_refs_opt': parser.c:(.text+0x14665): undefined reference to `cp_objc_protocol_id_list' *** [cc1plus-dummy] Error code 1 1 error but works on the newer one. svn 260310 builds on both. I am a bit unclear on what is going on because the missing symbol (cp_objc_protocol_id_list) only appears in the source file parser.c and in a ChangeLog.apple file, so maybe it is generated and the actual failure is at some earlier stage. Thanks for the report. Of course gcc can also have bugs but it would look like you may not be doing a clean build or that some how object code from two different builds got mixed up. JIC, the cp_obj_protocol_id_list stuff is obviously objc stuff that we don't need at all and that crept in along with other changes from Apple so I will remove it to see if it helps somehow. Pedro. ___ 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
[head tinderbox] failure on i386/pc98
TB --- 2014-01-17 19:57:58 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-17 19:57:58 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-01-17 19:57:58 - starting HEAD tinderbox run for i386/pc98 TB --- 2014-01-17 19:57:58 - cleaning the object tree TB --- 2014-01-17 19:57:58 - /usr/local/bin/svn stat /src TB --- 2014-01-17 19:58:15 - At svn revision 260825 TB --- 2014-01-17 19:58:16 - building world TB --- 2014-01-17 19:58:16 - CROSS_BUILD_TESTING=YES TB --- 2014-01-17 19:58:16 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-17 19:58:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-17 19:58:16 - SRCCONF=/dev/null TB --- 2014-01-17 19:58:16 - TARGET=pc98 TB --- 2014-01-17 19:58:16 - TARGET_ARCH=i386 TB --- 2014-01-17 19:58:16 - TZ=UTC TB --- 2014-01-17 19:58:16 - __MAKE_CONF=/dev/null TB --- 2014-01-17 19:58:16 - cd /src TB --- 2014-01-17 19:58:16 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Fri Jan 17 19:58:24 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools [...] c++ -O2 -pipe -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/include -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/lib/CodeGen/SelectionDAG -I. -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\/obj/pc98.i386/src/tmp\ -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmselectiondag/../../../contrib/llvm/lib/CodeGen/SelectionDAG/ScheduleDAGVLIW.cpp -o ScheduleDAGVLIW.o c++ -O2 -pipe -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/include -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/lib/CodeGen/SelectionDAG -I. -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\/obj/pc98.i386/src/tmp\ -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmselectiondag/../../../contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp -o SelectionDAG.o c++ -O2 -pipe -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/include -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/lib/CodeGen/SelectionDAG -I. -I/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\/obj/pc98.i386/src/tmp\ -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmselectiondag/../../../contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp -o SelectionDAGBuilder.o /src/lib/clang/libllvmselectiondag/../../../contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp: In member function 'std::pairllvm::SDValue, llvm::SDValue llvm::TargetLowering::LowerCallTo(llvm::TargetLowering::CallLoweringInfo) const': /src/lib/clang/libllvmselectiondag/../../../contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:6397: internal compiler error: in var_ann, at tree-flow-inline.h:128 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 Stop. bmake[3]: stopped in /src/lib/clang/libllvmselectiondag *** Error code 1 Stop. bmake[2]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-01-17 20:56:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-17 20:56:49 - ERROR: failed to build world TB --- 2014-01-17 20:56:49 - 3033.79 user 342.02 system 3530.47 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To
Re: svn 260311 breaks gcc builds on releng9 ?
On Fri, Jan 17, 2014 at 12:50 PM, Pedro Giffuni p...@freebsd.org wrote: Hello Luigi; On 17.01.2014 15:18, Luigi Rizzo wrote: Hi, I am seeing an odd problem which seems to be triggered by svn260311 I have two machines running snapshots of stable/9 from last fall (one 255898 sep.26, the other 258126 nov.14). All is amd64 Build a recent head (260311 and newer) with gcc fails on the sep.26 machine: ... 19:51:22 === gnu/usr.bin/cc/cc1plus (all) PROG CC /media/bsd10/usr/home/luigi/ FreeBSD/head/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/main.c ... PROG CC /media/bsd10/usr/home/luigi/ FreeBSD/head/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/except.c parser.o: In function `cp_parser_objc_tentative_ protocol_refs_opt': parser.c:(.text+0x14665): undefined reference to `cp_objc_protocol_id_list' *** [cc1plus-dummy] Error code 1 1 error but works on the newer one. svn 260310 builds on both. I am a bit unclear on what is going on because the missing symbol (cp_objc_protocol_id_list) only appears in the source file parser.c and in a ChangeLog.apple file, so maybe it is generated and the actual failure is at some earlier stage. Thanks for the report. Of course gcc can also have bugs but it would look like you may not be doing a clean build or that some how object code from two different builds got mixed up. i thought so too, but i am building in a completely new dir and i retried some 10 times rm -rf on the output dir, resyncing the repo and checking diffs, etc. Also it is very suspicious that going back to 260310 makes the problem disappear, and 260311 brings it back in. Anyways, it is very confusing indeed. JIC, the cp_obj_protocol_id_list stuff is obviously objc stuff that we don't need at all and that crept in along with other changes from Apple so I will remove it to see if it helps somehow. ok thanks. let me know if you want me to test a patch before committing, since I have a way to reproduce the error (i am not upgrading the offending system on purpose). cheers luigi ___ 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: svn 260311 breaks gcc builds on releng9 ?
On 17.01.2014 16:07, Luigi Rizzo wrote: On Fri, Jan 17, 2014 at 12:50 PM, Pedro Giffuni p...@freebsd.org mailto:p...@freebsd.org wrote: Hello Luigi; On 17.01.2014 15:18, Luigi Rizzo wrote: Hi, I am seeing an odd problem which seems to be triggered by svn260311 I have two machines running snapshots of stable/9 from last fall (one 255898 sep.26, the other 258126 nov.14). All is amd64 Build a recent head (260311 and newer) with gcc fails on the sep.26 machine: ... 19:51:22 === gnu/usr.bin/cc/cc1plus (all) PROG CC /media/bsd10/usr/home/luigi/FreeBSD/head/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/main.c ... PROG CC /media/bsd10/usr/home/luigi/FreeBSD/head/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/except.c parser.o: In function `cp_parser_objc_tentative_protocol_refs_opt': parser.c:(.text+0x14665): undefined reference to `cp_objc_protocol_id_list' *** [cc1plus-dummy] Error code 1 1 error but works on the newer one. svn 260310 builds on both. I am a bit unclear on what is going on because the missing symbol (cp_objc_protocol_id_list) only appears in the source file parser.c and in a ChangeLog.apple file, so maybe it is generated and the actual failure is at some earlier stage. Thanks for the report. Of course gcc can also have bugs but it would look like you may not be doing a clean build or that some how object code from two different builds got mixed up. i thought so too, but i am building in a completely new dir and i retried some 10 times rm -rf on the output dir, resyncing the repo and checking diffs, etc. Also it is very suspicious that going back to 260310 makes the problem disappear, and 260311 brings it back in. Anyways, it is very confusing indeed. JIC, the cp_obj_protocol_id_list stuff is obviously objc stuff that we don't need at all and that crept in along with other changes from Apple so I will remove it to see if it helps somehow. ok thanks. let me know if you want me to test a patch before committing, since I have a way to reproduce the error (i am not upgrading the offending system on purpose). The Apple change was incomplete so I guess the compiler in head is not being strict enough. I removed the dead code and rebuilt. Should be fixed as r260831. Thank you for the report! Pedro. ___ 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: svn 260311 breaks gcc builds on releng9 ?
On Fri, Jan 17, 2014 at 04:26:30PM -0500, Pedro Giffuni wrote: On 17.01.2014 16:07, Luigi Rizzo wrote: ... The Apple change was incomplete so I guess the compiler in head is not being strict enough. I removed the dead code and rebuilt. Should be fixed as r260831. Thank you for the report! thank you for the quick fix. cheers luigi ___ 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
