head@r263419: buildworld is broken with WITHOUT_BSNMP
Hello, I'm trying to build r263419 and got following error: === sbin/atm/atmconfig (depend) cat /usr/src/sbin/atm/atmconfig/../../../contrib/ngatm/snmp_atm/atm_tree.def /usr/src/sbin/atm/atmconfig/../../../usr.sbin/bsnmpd/modules/snmp_atm/atm_freebsd.def | gensnmptree -e `tail -n +2 /usr/src/sbin/atm/atmconfig/atm_oid.list` /usr/obj/usr/src/sbin/atm/atmconfig/oid.h rm -f .depend CC='cc ' mkdep -f .depend -a-I/usr/obj/usr/src/sbin/atm/atmconfig -std=gnu99 /usr/src/sbin/atm/atmconfig/main.c /usr/src/sbin/atm/atmconfig/diag.c /usr/src/sbin/atm/atmconfig/natm.c /usr/src/sbin/atm/atmconfig/atmconfig_device.c /usr/src/sbin/atm/atmconfig/main.c:42:10: fatal error: 'bsnmp/asn1.h' file not found #include bsnmp/asn1.h ^ 1 error generated. /usr/src/sbin/atm/atmconfig/atmconfig_device.c:41:10: fatal error: 'bsnmp/asn1.h' file not found #include bsnmp/asn1.h ^ 1 error generated. mkdep: compile failed *** Error code 1 Stop. make[5]: stopped in /usr/src/sbin/atm/atmconfig [tiger@laptop]:~cat /etc/src.conf WITH_SVN=yes WITH_LLDB=yes WITHOUT_BLUETOOTH=yes WITHOUT_BSNMP=yes WITHOUT_DICT=yes WITHOUT_FLOPPY=yes WITHOUT_FREEBSD_UPDATE=yes WITHOUT_GAMES=yes WITHOUT_HTML=yes WITHOUT_IPFILTER=yes WITHOUT_LPR=yes WITHOUT_NDIS=yes WITHOUT_PORTSNAP=yes WITHOUT_QUOTAS=yes -- wbr, tiger ___ 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: Hello fdclose
On Tuesday, March 18, 2014 5:35:16 pm Jilles Tjoelker wrote: On Tue, Mar 18, 2014 at 12:23:19AM +0100, Mariusz Zaborski wrote: After our previous discuss [1] I prepare fdclosedir(3) function which was committed by Pawel (cc'ed) in commit r254499. A while ago I also prepare the fdclose function. Unfortunately, this new function is a little bit more tricky then previous one. Can I ask you for a review of this patch? Does this patch allow perl to stop writing to FILE._file? As pointed out in http://lists.freebsd.org/pipermail/freebsd-current/2013-January/039024.html perlio.c in the perl source contains a function PerlIOStdio_invalidate_fileno() that should modify a FILE such that fclose() does not close the file descriptor but still frees all memory (Perl has already called fflush()). Although using fdclose() could solve this without touching the internals of FILE, this will make perlio.c uglier with even more #ifdefs. I hope it does. I want to have some sort of API for Perl to use so it stops (ab)using _file before I move forward with full int _file. I think that in cases where fdclose() would be used, it is essential that the file descriptor is never closed. This means that the API needs to be different so it can report a write error but still return a file descriptor. One way to do this is to return the file descriptor by reference. Another is to expect the application to call fileno() and not return the descriptor from the new function. I would prefer the latter of requiring the application to use fileno(). -- 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: [rfc] /dev/devstat permissions patch
On Tuesday, March 18, 2014 3:29:32 pm Maksim Yevmenkin wrote:
hello,
would anyone object to the following patch?
I think this is fine.
While you are at it, can you test this patch to remove D_NEEDGIANT?
Index: subr_devstat.c
===
--- subr_devstat.c (revision 263302)
+++ subr_devstat.c (working copy)
@@ -460,7 +460,6 @@ static d_mmap_t devstat_mmap;
static struct cdevsw devstat_cdevsw = {
.d_version =D_VERSION,
- .d_flags = D_NEEDGIANT,
.d_mmap = devstat_mmap,
.d_name = devstat,
};
@@ -482,13 +481,16 @@ devstat_mmap(struct cdev *dev, vm_ooffset_t offset
if (nprot != VM_PROT_READ)
return (-1);
+ mtx_lock(devstat_mutex);
TAILQ_FOREACH(spp, pagelist, list) {
if (offset == 0) {
*paddr = vtophys(spp-stat);
+ mtx_unlock(devstat_mutex);
return (0);
}
offset -= PAGE_SIZE;
}
+ mtx_unlock(devstat_mutex);
return (-1);
}
--
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: Building with external toolchain was broken 6 months ago with r255187
On Tuesday, March 18, 2014 6:20:50 pm Bjoern A. Zeeb wrote: On 18 Mar 2014, at 22:01 , John-Mark Gurney j...@funkthat.com wrote: Lev Serebryakov wrote this message on Wed, Mar 19, 2014 at 01:37 +0400: I did't build my NanoBSD images for almost year, and in this time our not-finished and fragile support for using external toolchain is rotten, due to r255187 (and, may meb, some other commits too). I have very fresh -CURRENT (r263296) I have these settings for my buildworld buildkernel targets: XCC=/usr/bin/cc XCXX=/usr/bin/c++ XCPP=/usr/bin/cpp XAS=/usr/bin/as XAR=/usr/bin/ar XLD=/usr/bin/ld XNM=/usr/bin/nm XOBJDUMP=/usr/bin/objdump XRANLIB=/usr/bin/ranlib XSTRINGS=/usr/bin/strings COMPILER_TYPE=clang WITHOUT_CROSS_COMPILER=yes WITHOUT_BINUTILS=yes WITHOUT_CLANG=yes It worked 7 months ago. Now it works for buildworld but not for buildkernel: --- aeskeys_amd64.o --- /usr/bin/cc --sysroot=/data/obj.nano/gateway.v2/data/src/tmp - B/data/obj.nano/gateway.v2/data/src/tmp/usr/bin -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS - include /data/obj.nano/gateway.v2/data/src/sys/D2500CC/opt_global.h -I. -I@ - I@/contrib/altq -fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame- pointer -I/data/obj.nano/gateway.v2/data/src/sys/D2500CC -mno-aes -mno-avx - mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno- asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -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-unused-function-c /data/src/sys/modules/aesni/../../cryp to/aesni/aeskeys_amd64.S --- aesni_wrap.o --- In file included from /data/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:40: /data/src/sys/modules/aesni/../../crypto/aesni/aesencdec.h:30:10: fatal error: 'wmmintrin.h' file not found #include wmmintrin.h ^ 1 error generated. *** [aesni_wrap.o] Error code 1 It could not find header file with intrinsics from system (external) clang. I could disable building of this module with WITHOUT_MODULES=aesni, and it works, but what if I need this module? Could it be fixed, pleeease? Sounds like your tool chain doesn't have the necessary support for AES-NI... Are you using gcc as cc? If so, do you have the necessary tool chain work that I did in r255185 in your local tree? The problem is that the kernel is deepening on a compiler header which is not in the right place in objdir if the compiler is not built. I thought I had reported this before (maybe just informally). I have been helping myself locally using this: No, the compiler should provide a working wmmintrin.h header in one of its built-in paths if it supports the AES instructions. This is akin to saying that code that uses stdio.h should use -I/usr/src/include. -- 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: Hello fdclose
On Wednesday, March 19, 2014 4:28:15 pm Warren Block wrote: On Wed, 19 Mar 2014, John Baldwin wrote: On Wednesday, March 19, 2014 12:38:57 am Warren Block wrote: On Tue, 18 Mar 2014, John Baldwin wrote: On Monday, March 17, 2014 7:23:19 pm Mariusz Zaborski wrote: Hi, After our previous discuss [1] I prepare fdclosedir(3) function which was committed by Pawel (cc'ed) in commit r254499. A while ago I also prepare the fdclose function. Unfortunately, this new function is a little bit more tricky then previous one. Can I ask you for a review of this patch? I think the code is fine. I have a few suggestions on the manpage wording: The +.Fn fdclose +function is equivalent to the +.Fn fclose +function except that this function returns file descriptor instead of +closing it. +.Pp +The I would move fdclose() to its own paragraph and reword this sentence as: The fdclose() function is equivalent to fclose() except that it does not close the underlying file descriptor. .Fn fdclose is equivalent to .Fn fclose , but the file descriptor is returned rather than closed. Likewise in other sections, the markup is supposed to do the job of pointing out that something is a function. Yes, but this has the 'no capital letter at the start of a sentence' problem. I've heard that mentioned before, but have never seen any actual rule regarding it. All of my rules for that come from elementary school. :) -- 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: Building with external toolchain was broken 6 months ago with r255187
On 20 Mar 2014, at 14:08, John Baldwin j...@freebsd.org wrote: No, the compiler should provide a working wmmintrin.h header in one of its built-in paths if it supports the AES instructions. This is akin to saying that code that uses stdio.h should use -I/usr/src/include. It does, however our build system then explicitly says to the compiler 'don't use your built-it paths because they may contain declarations that contradict the FreeBSD ones' by means of the sysroot argument. When not using an external toolchain, we put the compiler's internal headers inside the sysroot. 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: Building with external toolchain was broken 6 months ago with r255187
On Thu, 2014-03-20 at 10:08 -0400, John Baldwin wrote: On Tuesday, March 18, 2014 6:20:50 pm Bjoern A. Zeeb wrote: On 18 Mar 2014, at 22:01 , John-Mark Gurney j...@funkthat.com wrote: Lev Serebryakov wrote this message on Wed, Mar 19, 2014 at 01:37 +0400: I did't build my NanoBSD images for almost year, and in this time our not-finished and fragile support for using external toolchain is rotten, due to r255187 (and, may meb, some other commits too). I have very fresh -CURRENT (r263296) I have these settings for my buildworld buildkernel targets: XCC=/usr/bin/cc XCXX=/usr/bin/c++ XCPP=/usr/bin/cpp XAS=/usr/bin/as XAR=/usr/bin/ar XLD=/usr/bin/ld XNM=/usr/bin/nm XOBJDUMP=/usr/bin/objdump XRANLIB=/usr/bin/ranlib XSTRINGS=/usr/bin/strings COMPILER_TYPE=clang WITHOUT_CROSS_COMPILER=yes WITHOUT_BINUTILS=yes WITHOUT_CLANG=yes It worked 7 months ago. Now it works for buildworld but not for buildkernel: --- aeskeys_amd64.o --- /usr/bin/cc --sysroot=/data/obj.nano/gateway.v2/data/src/tmp - B/data/obj.nano/gateway.v2/data/src/tmp/usr/bin -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS - include /data/obj.nano/gateway.v2/data/src/sys/D2500CC/opt_global.h -I. -I@ - I@/contrib/altq -fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame- pointer -I/data/obj.nano/gateway.v2/data/src/sys/D2500CC -mno-aes -mno-avx - mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno- asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -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-unused-function-c /data/src/sys/modules/aesni/../../cryp to/aesni/aeskeys_amd64.S --- aesni_wrap.o --- In file included from /data/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:40: /data/src/sys/modules/aesni/../../crypto/aesni/aesencdec.h:30:10: fatal error: 'wmmintrin.h' file not found #include wmmintrin.h ^ 1 error generated. *** [aesni_wrap.o] Error code 1 It could not find header file with intrinsics from system (external) clang. I could disable building of this module with WITHOUT_MODULES=aesni, and it works, but what if I need this module? Could it be fixed, pleeease? Sounds like your tool chain doesn't have the necessary support for AES-NI... Are you using gcc as cc? If so, do you have the necessary tool chain work that I did in r255185 in your local tree? The problem is that the kernel is deepening on a compiler header which is not in the right place in objdir if the compiler is not built. I thought I had reported this before (maybe just informally). I have been helping myself locally using this: No, the compiler should provide a working wmmintrin.h header in one of its built-in paths if it supports the AES instructions. This is akin to saying that code that uses stdio.h should use -I/usr/src/include. But it's a module, built with -nostdinc, so the appropriate -I has to be on the command line. I notice that -no-aes is also on the command line, which seems like a strange thing for compiling a file named aeskeys_amd64. -- Ian ___ 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: [rfc] /dev/devstat permissions patch
On Thu, Mar 20, 2014 at 7:05 AM, John Baldwin j...@freebsd.org wrote:
On Tuesday, March 18, 2014 3:29:32 pm Maksim Yevmenkin wrote:
hello,
would anyone object to the following patch?
I think this is fine.
While you are at it, can you test this patch to remove D_NEEDGIANT?
Index: subr_devstat.c
===
--- subr_devstat.c (revision 263302)
+++ subr_devstat.c (working copy)
@@ -460,7 +460,6 @@ static d_mmap_t devstat_mmap;
static struct cdevsw devstat_cdevsw = {
.d_version =D_VERSION,
- .d_flags = D_NEEDGIANT,
.d_mmap = devstat_mmap,
.d_name = devstat,
};
@@ -482,13 +481,16 @@ devstat_mmap(struct cdev *dev, vm_ooffset_t offset
if (nprot != VM_PROT_READ)
return (-1);
+ mtx_lock(devstat_mutex);
TAILQ_FOREACH(spp, pagelist, list) {
if (offset == 0) {
*paddr = vtophys(spp-stat);
+ mtx_unlock(devstat_mutex);
return (0);
}
offset -= PAGE_SIZE;
}
+ mtx_unlock(devstat_mutex);
return (-1);
}
seems to work fine for me. so, i guess, i will commit combined patch, then
==
Index: subr_devstat.c
===
--- subr_devstat.c (revision 3427)
+++ subr_devstat.c (working copy)
@@ -462,7 +462,6 @@
static struct cdevsw devstat_cdevsw = {
.d_version = D_VERSION,
- .d_flags = D_NEEDGIANT,
.d_mmap = devstat_mmap,
.d_name = devstat,
};
@@ -484,13 +483,16 @@
if (nprot != VM_PROT_READ)
return (-1);
+ mtx_lock(devstat_mutex);
TAILQ_FOREACH(spp, pagelist, list) {
if (offset == 0) {
*paddr = vtophys(spp-stat);
+ mtx_unlock(devstat_mutex);
return (0);
}
offset -= PAGE_SIZE;
}
+ mtx_unlock(devstat_mutex);
return (-1);
}
@@ -505,7 +507,7 @@
mtx_assert(devstat_mutex, MA_NOTOWNED);
if (!once) {
make_dev_credf(MAKEDEV_ETERNAL | MAKEDEV_CHECKNAME,
-devstat_cdevsw, 0, NULL, UID_ROOT, GID_WHEEL, 0400,
+devstat_cdevsw, 0, NULL, UID_ROOT, GID_WHEEL, 0444,
DEVSTAT_DEVICE_NAME);
once = 1;
}
==
thanks
max
___
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: Building with external toolchain was broken 6 months ago with r255187
On Mar 20, 2014, at 8:25 AM, David Chisnall thera...@freebsd.org wrote: On 20 Mar 2014, at 14:08, John Baldwin j...@freebsd.org wrote: No, the compiler should provide a working wmmintrin.h header in one of its built-in paths if it supports the AES instructions. This is akin to saying that code that uses stdio.h should use -I/usr/src/include. It does, however our build system then explicitly says to the compiler 'don't use your built-it paths because they may contain declarations that contradict the FreeBSD ones' by means of the sysroot argument. When not using an external toolchain, we put the compiler's internal headers inside the sysroot. Sounds like we’re building the sysroot wrong then. Warner ___ 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: panic: vm_fault: fault on nofault entry
On Mon, 2014-03-10 at 15:10 -0400, Glen Barber wrote:
On Mon, Mar 10, 2014 at 09:01:12PM +0200, Konstantin Belousov wrote:
On Mon, Mar 10, 2014 at 02:05:08PM -0400, Glen Barber wrote:
Unread portion of the kernel message buffer:
Sleeping thread (tid 100702, pid 24712) owns a non-sleepable lock
Would be nice to see the full message before and panic from the console.
I will include it in the future.
From what I see, this is a lock leak, I forgot to unlock the map.
It is nice that it is so simple to reproduce the issue in your setup.
Try this update.
I will have the machine updated with this patch in the next few minutes.
Thank you.
Glen
All 4 machines have been patched and have been grinding away for several
days now. I'd say this is a good test and we should commit this.
$ for i in 1 2 3 4; do ssh redbuild0${i} uptime; done
5:47PM up 1 day, 23:22, 1 user, load averages: 1.36, 1.10, 0.57
5:47PM up 1 day, 23:23, 1 user, load averages: 4.33, 3.87, 2.08
5:47PM up 3 days, 22:45, 1 user, load averages: 16.87, 12.47, 10.11
5:47PM up 9 days, 20:10, 1 user, load averages: 11.58, 12.34, 10.93
sean
signature.asc
Description: This is a digitally signed message part
Re: Building with external toolchain was broken 6 months ago with r255187
Ian Lepore wrote this message on Thu, Mar 20, 2014 at 08:29 -0600: On Thu, 2014-03-20 at 10:08 -0400, John Baldwin wrote: On Tuesday, March 18, 2014 6:20:50 pm Bjoern A. Zeeb wrote: On 18 Mar 2014, at 22:01 , John-Mark Gurney j...@funkthat.com wrote: Lev Serebryakov wrote this message on Wed, Mar 19, 2014 at 01:37 +0400: I did't build my NanoBSD images for almost year, and in this time our not-finished and fragile support for using external toolchain is rotten, due to r255187 (and, may meb, some other commits too). I have very fresh -CURRENT (r263296) I have these settings for my buildworld buildkernel targets: XCC=/usr/bin/cc XCXX=/usr/bin/c++ XCPP=/usr/bin/cpp XAS=/usr/bin/as XAR=/usr/bin/ar XLD=/usr/bin/ld XNM=/usr/bin/nm XOBJDUMP=/usr/bin/objdump XRANLIB=/usr/bin/ranlib XSTRINGS=/usr/bin/strings COMPILER_TYPE=clang WITHOUT_CROSS_COMPILER=yes WITHOUT_BINUTILS=yes WITHOUT_CLANG=yes It worked 7 months ago. Now it works for buildworld but not for buildkernel: --- aeskeys_amd64.o --- /usr/bin/cc --sysroot=/data/obj.nano/gateway.v2/data/src/tmp - B/data/obj.nano/gateway.v2/data/src/tmp/usr/bin -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS - include /data/obj.nano/gateway.v2/data/src/sys/D2500CC/opt_global.h -I. -I@ - I@/contrib/altq -fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame- pointer -I/data/obj.nano/gateway.v2/data/src/sys/D2500CC -mno-aes -mno-avx - mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno- asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -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-unused-function-c /data/src/sys/modules/aesni/../../cryp to/aesni/aeskeys_amd64.S --- aesni_wrap.o --- In file included from /data/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:40: /data/src/sys/modules/aesni/../../crypto/aesni/aesencdec.h:30:10: fatal error: 'wmmintrin.h' file not found #include wmmintrin.h ^ 1 error generated. *** [aesni_wrap.o] Error code 1 It could not find header file with intrinsics from system (external) clang. I could disable building of this module with WITHOUT_MODULES=aesni, and it works, but what if I need this module? Could it be fixed, pleeease? Sounds like your tool chain doesn't have the necessary support for AES-NI... Are you using gcc as cc? If so, do you have the necessary tool chain work that I did in r255185 in your local tree? The problem is that the kernel is deepening on a compiler header which is not in the right place in objdir if the compiler is not built. I thought I had reported this before (maybe just informally). I have been helping myself locally using this: No, the compiler should provide a working wmmintrin.h header in one of its built-in paths if it supports the AES instructions. This is akin to saying that code that uses stdio.h should use -I/usr/src/include. But it's a module, built with -nostdinc, so the appropriate -I has to be on the command line. Actually, the above quoted text mixes two different files... aeskeys_amd64 is an assembly file so doesn't need the header... I notice that -no-aes is also on the command line, which seems like a strange thing for compiling a file named aeskeys_amd64. That's could be a bug in the assembler for allowing aes instructions when they are turned off... If it gets fixed, it isn't hard to enable them for this specific file.. If you look at aesni_wrap.c's build, you'll see it looks somethingl like: /usr/bin/cc -B/usr/obj/usr/src/tmp/usr/bin -c -O3 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -gdwarf-2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/obj/usr/src/sys/GENERIC -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -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-unused-function -Werror -mmmx -msse -maes
geli TRIM support
A while back there was talk of adding TRIM support to geli(8) [1]. Does anyone know if progress has been made or if there are still plans for it? [1] http://lists.freebsd.org/pipermail/freebsd-fs/2013-March/016773.html -- Greg Rivers ___ 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: Building with external toolchain was broken 6 months ago with r255187
Warner Losh wrote this message on Thu, Mar 20, 2014 at 11:30 -0600: On Mar 20, 2014, at 8:25 AM, David Chisnall thera...@freebsd.org wrote: On 20 Mar 2014, at 14:08, John Baldwin j...@freebsd.org wrote: No, the compiler should provide a working wmmintrin.h header in one of its built-in paths if it supports the AES instructions. This is akin to saying that code that uses stdio.h should use -I/usr/src/include. It does, however our build system then explicitly says to the compiler 'don't use your built-it paths because they may contain declarations that contradict the FreeBSD ones' by means of the sysroot argument. When not using an external toolchain, we put the compiler's internal headers inside the sysroot. Sounds like we?re building the sysroot wrong then. I'm not familar w/ cross tools, are cross tools suppose to just work, or do you still require building kernel-toolchain? The wiki doesn't talk about buildkernel... If it's still required to build kernel-toolchain before buildkernel, one option is to remove the exclusion of the _includes target from kernel-toolchain, though _includes doesn't appear to install the header... It looks like it never goes into lib/clang to install them, though I'm not sure if it is suppose to or not.. If you use COMPILER_TYPE=gcc, it doesn't go into the proper gcc subdir to install them either... In investigating this, it looks like we might have a make rule conflict in usr.sbin/bsdconfig... It has a subdir includes, but bsd.subdir.mk also defines a rule includes (for building inclues) which results in this: make[4]: /usr/src/share/mk/bsd.subdir.mk line 85: warning: duplicate script for target includes ignored make[4]: /usr/src/share/mk/bsd.subdir.mk line 69: warning: using previous script for includes defined here -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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: geli TRIM support
I was actually googling about this yesterday and found no more info then the thread you posted. So its seems that nothing was done related to this so far? Which means using trim+geli is problematic. I was using my ssd with UFS+trim+geli in my laptop. But even before noticing the lack of support changed my setup... since the laptop has both a ssd and hdd I am now using zfs+geli in the hdd. I have 2 partitions in the ssd and I'm using it for log/cache. But for laptops with 1ssd only this is a problem I also read that new ssd's depending on the vendor might not need trim at all, but I'm not really sure how to tell. On 20 March 2014 18:21:51 WET, Greg Rivers gcr+freebsd-curr...@tharned.org wrote: A while back there was talk of adding TRIM support to geli(8) [1]. Does anyone know if progress has been made or if there are still plans for it? [1] http://lists.freebsd.org/pipermail/freebsd-fs/2013-March/016773.html -- Greg Rivers ___ 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 -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ 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: Hello fdclose
Warren Block wbl...@wonkity.com writes: John Baldwin j...@freebsd.org writes: Warren Block wbl...@wonkity.com writes: .Fn fdclose is equivalent to .Fn fclose , but the file descriptor is returned rather than closed. Yes, but this has the 'no capital letter at the start of a sentence' problem. I've heard that mentioned before, but have never seen any actual rule regarding it. And we do have actual rules about avoiding redundant phrases: http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/book.html#writing-style-guidelines We always use The .Nm foo utility or The .Fn foo function instead of just .Nm or .Fn at the start of a sentence, but never (or rarely) within a sentence. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Building with external toolchain was broken 6 months ago with r255187
On Mar 20, 2014, at 12:24 PM, John-Mark Gurney j...@funkthat.com wrote: Warner Losh wrote this message on Thu, Mar 20, 2014 at 11:30 -0600: On Mar 20, 2014, at 8:25 AM, David Chisnall thera...@freebsd.org wrote: On 20 Mar 2014, at 14:08, John Baldwin j...@freebsd.org wrote: No, the compiler should provide a working wmmintrin.h header in one of its built-in paths if it supports the AES instructions. This is akin to saying that code that uses stdio.h should use -I/usr/src/include. It does, however our build system then explicitly says to the compiler 'don't use your built-it paths because they may contain declarations that contradict the FreeBSD ones' by means of the sysroot argument. When not using an external toolchain, we put the compiler's internal headers inside the sysroot. Sounds like we?re building the sysroot wrong then. I'm not familar w/ cross tools, are cross tools suppose to just work, or do you still require building kernel-toolchain? The wiki doesn't talk about buildkernel... If it's still required to build kernel-toolchain before buildkernel, one option is to remove the exclusion of the _includes target from kernel-toolchain, though _includes doesn't appear to install the header... It looks like it never goes into lib/clang to install them, though I'm not sure if it is suppose to or not.. If you use COMPILER_TYPE=gcc, it doesn't go into the proper gcc subdir to install them either… I’m saying that whatever is building the sysroot is building it wrong. I haven’t looked at the details enough to know where the fault lies. If the files aren’t there, that’s a bug and adding hacks for clang is not the right way to fix the bug. In investigating this, it looks like we might have a make rule conflict in usr.sbin/bsdconfig... It has a subdir includes, but bsd.subdir.mk also defines a rule includes (for building inclues) which results in this: make[4]: /usr/src/share/mk/bsd.subdir.mk line 85: warning: duplicate script for target includes ignored make[4]: /usr/src/share/mk/bsd.subdir.mk line 69: warning: using previous script for includes defined here That’s likely an orthogonal issue… Warner ___ 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: Building with external toolchain was broken 6 months ago with r255187
On Thu, Mar 20, 2014 at 02:16:08PM -0600, Warner Losh wrote: On Mar 20, 2014, at 12:24 PM, John-Mark Gurney j...@funkthat.com wrote: In investigating this, it looks like we might have a make rule conflict in usr.sbin/bsdconfig... It has a subdir includes, but bsd.subdir.mk also defines a rule includes (for building inclues) which results in this: make[4]: /usr/src/share/mk/bsd.subdir.mk line 85: warning: duplicate script for target includes ignored make[4]: /usr/src/share/mk/bsd.subdir.mk line 69: warning: using previous script for includes defined here That’s likely an orthogonal issue… This is because usr.sbin/bsdconfig has an 'includes' SUBDIR entry. Glen pgpbV_Erz1qqa.pgp Description: PGP signature
Re: Scripts for booting FreeBSD images from the install ISO for use in Jenkins?
Am Mon, 17 Mar 2014 19:30:01 -0700 schrieb Craig Rodrigues rodr...@freebsd.org: Hi, For the BSD DevSummit in May, one of the items on our agenda: https://wiki.freebsd.org/201405DevSummit/Jenkins is to talk about writing scripts which can take a FreeBSD ISO image, and then boot it and run it on a remote system or in a VM to install the OS. After the OS is up, we would like to run tests. All of this would be triggered from Jenkins. Does anyone have scripts which can do this? Can they be contributed to the Jenkins effort on FreeBSD? If you have scripts in Python, Ruby, Bourne shell, etc. are all fine, or even recipes in automation frameworks like Puppet, Ansible, Chef, SaltStack, etc., please let us know! :) I would have loved to attend this talk: http://2014.asiabsdcon.org/timetable.html.en#P7A Hopefully, more documentation and/or the slides/the video for this talk will become available. ___ 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: Scripts for booting FreeBSD images from the install ISO for use in Jenkins?
On Tue, Mar 18, 2014 at 2:26 AM, Rainer Duffner rai...@ultra-secure.de wrote: Am Mon, 17 Mar 2014 19:30:01 -0700 schrieb Craig Rodrigues rodr...@freebsd.org: Hi, For the BSD DevSummit in May, one of the items on our agenda: https://wiki.freebsd.org/201405DevSummit/Jenkins is to talk about writing scripts which can take a FreeBSD ISO image, and then boot it and run it on a remote system or in a VM to install the OS. After the OS is up, we would like to run tests. All of this would be triggered from Jenkins. Does anyone have scripts which can do this? Can they be contributed to the Jenkins effort on FreeBSD? If you have scripts in Python, Ruby, Bourne shell, etc. are all fine, or even recipes in automation frameworks like Puppet, Ansible, Chef, SaltStack, etc., please let us know! :) I would have loved to attend this talk: http://2014.asiabsdcon.org/timetable.html.en#P7A Hopefully, more documentation and/or the slides/the video for this talk will become available. Rainer, Thanks for posting that link! It is highly relevant to my original posting. That looks like a really good presentation, and I also wish I could have attended the talk! There seem to be many automation frameworks for provisioning and booting VM's and real machines. I just need to learn one of them. :) -- Craig ___ 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: Scripts for booting FreeBSD images from the install ISO for use in Jenkins?
On 2014-03-20 22:40, Craig Rodrigues wrote: On Tue, Mar 18, 2014 at 2:26 AM, Rainer Duffner rai...@ultra-secure.de wrote: Am Mon, 17 Mar 2014 19:30:01 -0700 schrieb Craig Rodrigues rodr...@freebsd.org: Hi, For the BSD DevSummit in May, one of the items on our agenda: https://wiki.freebsd.org/201405DevSummit/Jenkins is to talk about writing scripts which can take a FreeBSD ISO image, and then boot it and run it on a remote system or in a VM to install the OS. After the OS is up, we would like to run tests. All of this would be triggered from Jenkins. Does anyone have scripts which can do this? Can they be contributed to the Jenkins effort on FreeBSD? If you have scripts in Python, Ruby, Bourne shell, etc. are all fine, or even recipes in automation frameworks like Puppet, Ansible, Chef, SaltStack, etc., please let us know! :) I would have loved to attend this talk: http://2014.asiabsdcon.org/timetable.html.en#P7A Hopefully, more documentation and/or the slides/the video for this talk will become available. Rainer, Thanks for posting that link! It is highly relevant to my original posting. That looks like a really good presentation, and I also wish I could have attended the talk! There seem to be many automation frameworks for provisioning and booting VM's and real machines. I just need to learn one of them. :) -- Craig ___ 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 Yeah, Martin's talk was good. Jenkins does the installation and bootstraps puppet (installs it from pkg) and then things go from there. I have the beginnings of a puppet script to use http://www.bhyve.org/vmrc/ to deploy FreeBSD VMs (it is a script that installs to an image or zvol then boots it in bhyve) There is a talk partially based on it here: http://www.bhyvecon.org/ bhyve Provisioning and Monitoring I'll see what I can come up with for you tomorrow. -- Allan Jude signature.asc Description: OpenPGP digital signature
