Re: Building with external toolchain was broken 6 months ago with r255187

2014-03-18 Thread Lev Serebryakov 
Hello, John-Mark.
You wrote 19 марта 2014 г., 2:01:40:

JMG> 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/../../crypto/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 
>>  ^
>> 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?

JMG> Sounds like your tool chain doesn't have the necessary support for
JMG> AES-NI...  Are you using gcc as cc?  If so, do you have the necessary
JMG> tool chain work that I did in r255185 in your local tree?
  I use clang from world based on r263296 (amd64) to build world and kernel
 from same r263296 (amd64) (as indicated earlier).

JMG> Can you compile this test program?
 Yes, of course. But kernel and modules are built with "-sysroot" option,
you know? And my "-sysroot" doesn't contains clang tree (and
"/usr/include/clang/3.4"), because it points to fresh world (in
OBJDIRPREFIX) and clang was not built for this world, I'm using "system"
one. It works for world, GENERIC kernel and all modules but aesni.

JMG> -- tsse.c start 
JMG> #include 

JMG> __m128i foo;
JMG> --  tsse.c end --

JMG> With the command:
JMG> ${XCC} -c -maes tsse.c

JMG> If you can't, then the problem is your toolchain, and you need to fix
 I can.

JMG> it...  Try also w/:
JMG> clang -c -maes tsse.c
JMG> and it's also helpful to know more info, like: ${XCC} --version

> /usr/bin/cc --version
FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216
Target: x86_64-unknown-freebsd11.0
Thread model: posix

-- 
// Black Lion AKA Lev Serebryakov 

___
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 #308

2014-03-18 Thread jenkins-admin 
See 

___
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

2014-03-18 Thread Warren Block 

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.


textproc/igor can identify some problems with wording.  It also checks 
for rudimentary mdoc(7) requirements.


If desired, I'm willing to edit this man page.  (I've learned far too 
recently that most people do not want to be consulted on wording, they 
just want it fixed.  That's now the approach I take: make all the 
corrections and return it, rather than a back-and-forth with the danger 
of edit fatigue.)

___
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 #307

2014-03-18 Thread jenkins-admin 
See 

Changes:

[marcel] Fix and improve exception tracing:
1.  Name the kernel option XTRACE instead of EXCEPTION_TRACING
2.  Put support functions in ia64/ia64/xtrace.c
3.  Make it work with SMP by giving each CPU its own buffer
4.  Save 16 key registers in the buffer for every exception
5.  In ia64_handle_intr() and trap() transfer the trace record
to the KTR trace buffer using CTRx() and with some basic
information for now
6.  Use a tunable to anble tracing and stop tracing as soon as
we enter the debugger

Room for improvements:
1.  Transferring exception-relevant information to KTR
2.  Add a sysctl to enable/disable tracing

[tychon] Don't reissue in-flight commands.

Approved by:neel (co-mentor)

[ray] Switch kern.vt.suspendswitch to 0 by default (disabled).
kern.vt.suspendswitch - sysctl/tunable which enable switch to VT0 before going
to suspend and switch back after resume.

MFC after:  7 days

[dim] Add separate patch files for all the customizations we have currently
applied to our copy of llvm/clang.  These can be applied in alphabetical
order to a pristine llvm/clang 3.4 release source tree, to result in the
same version used in FreeBSD.

This is intended to clearly document all the changes until now, which
mostly consist of cherry pickings from the respective upstream trunks,
plus a number of hand-written FreeBSD-specific ones.  Hopefully those
can eventually be cleaned up and sent upstream too.

MFC after:  1 week
X-MFC-With: r263313

[attilio] Regen per r263318.

Sponsored by:   EMC / Isilon storage division

[attilio] Remove dead code from umtx support:
- Retire long time unused (basically always unused) sys__umtx_lock()
  and sys__umtx_unlock() syscalls
- struct umtx and their supporting definitions
- UMUTEX_ERROR_CHECK flag
- Retire UMTX_OP_LOCK/UMTX_OP_UNLOCK from _umtx_op() syscall

__FreeBSD_version is not bumped yet because it is expected that further
breakages to the umtx interface will follow up in the next days.
However there will be a final bump when necessary.

Sponsored by:   EMC / Isilon storage division
Reviewed by:jhb

--
[...truncated 220209 lines...]
cc  -c -O2 -pipe -fno-strict-aliasing  -std=c99 -gdwarf-2 -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   -nostdinc  -I. 
-I 
-I 
-I 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx 
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float  
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror  

ctfconvert -L VERSION -g uart_subr.o
--- ehci.o ---
cc  -c -O2 -pipe -fno-strict-aliasing  -std=c99 -gdwarf-2 -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   -nostdinc  -I. 
-I 
-I 
-I 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx 
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float  
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror  

--- syscons.o ---
ctfconvert -L VERSION -g syscons.o
--- modules-all ---
--- bxe_stats.o ---
cc  -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc  
-I
 -DHAVE_KERNEL_OPTION_HEADERS -include 
/usr/obj
 -I. -I@ -I@/contrib/altq -fno-common -gdwarf-2 -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer 
-I/usr/obj 
 -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float 
 -fno-asynchronous-unwind-tables -ffreestanding -fstac

Re: Building with external toolchain was broken 6 months ago with r255187

2014-03-18 Thread John-Mark Gurney 
Bjoern A. Zeeb wrote this message on Tue, Mar 18, 2014 at 22:20 +:
> 
> On 18 Mar 2014, at 22:01 , John-Mark Gurney  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/../../c
 ryp
> > 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 
> >> ^
> >> 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:

This still sounds like the compiler being used isn't installed
properly...  I've never had a problem when a proper kernel-toolchain
is available to build the kernel with...

If someone is willing to provide me w/ detailed instructions or an image
that reproduces the issue, I'm willing to look at it...

> Index: sys/modules/aesni/Makefile
> ===
> --- sys/modules/aesni/Makefile(revision 263176)
> +++ sys/modules/aesni/Makefile(working copy)
> @@ -11,7 +11,8 @@ OBJS+=  aesni_wrap.o
>  
>  # Remove -nostdinc so we can get the intrinsics.
>  aesni_wrap.o: aesni_wrap.c
> - ${CC} -c ${CFLAGS:C/^-O2$/-O3/:N-nostdinc} ${WERROR} ${PROF} \
> + ${CC} -I${.CURDIR}/../../../contrib/llvm/tools/clang/lib/Headers \
> +  -c ${CFLAGS:C/^-O2$/-O3/:N-nostdinc} ${WERROR} ${PROF} \
>-mmmx -msse -maes ${.IMPSRC}
>   ${CTFCONVERT_CMD}

This change breaks building w/ gcc

-- 
  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: [rfc] /dev/devstat permissions patch

2014-03-18 Thread Xin Li 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Adding phk@ to cc since the 400 is from his changeset (r112001).

On 03/18/14 12:29, Maksim Yevmenkin wrote:
> hello,
> 
> would anyone object to the following patch?
> 
> ==
> 
> Index: subr_devstat.c 
> ===
>
> 
- --- subr_devstat.c (revision 263311)
> +++ subr_devstat.c (working copy) @@ -503,7 +503,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; }
> 
> ==
> 
> i'm not sure why /dev/devstat has such restrictive permissions.
> can someone please explain the reason for it? having gstat(8)
> require super-user privilege seems like an overkill me. iostat(8)
> and systat(1) do not require super-user privileges to work.
> 
> and, yes, i know i can override permissions with /etc/devfs.conf,
> just curious what are we protecting from in /dev/devstat

I have similar change locally (except it's GID_OPERATOR and 0440) and
I think your proposed change would be a sensible default.

Cheers,
- -- 
Xin LI https://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)

iQIcBAEBCgAGBQJTKMofAAoJEJW2GBstM+nspPYQAKt8UiAqDBQwe0KTeH+ykpis
4EG4+oM43Ze8WCc3DgsbB+Dnq4en63z3SXyK7b78ZDN9xVzSmR4Cb6N0W63cuACI
4pE2Wl72P7v6eVgOrrgMJoRjI7BwX0nlOXKCvmwkHznbZSmpjgYTzx9ADYl1T4pP
SKtvgOtCyFXdpGP2adE8kJMRcFvBpbs61Y4hiSLwKE1lGywgLwYWfwkZMWFxGaNW
SU3H7qew5SRoFSF7ZhurhKENwyNR1EHEHXW+Se77TcTUzBIGCQop+78Od+Pxwi/v
KJYFKHS+Z72BRVbpaxowxQGRNSPzqC4dB2nMhrcQaOU8gXRret9OXCfBc7Fmrv31
ot0ewo3GapmNh/9ypMuYNQ+3XsjEmx96ckSeS0oX6lKLR2qIu8+JIMd9Oq0ogNHk
tMdjrX0dkpwedN9UiakbQq8Ws7u/XRfkQEUD8nsDu5gK+f3KlRldboA+GFAjYgX6
F+E4JHfRGWCFYQuzcl48Nkzg4Glw/r8HCHHE+cGqwXXPIGfjtwSIyGGZzw0Nb2Nr
jYfs4aYuGCwFmwUO/hVn47Wbbzmpr7rVbf7EW3PXwZuxPKTVxrEUpYklvCUmkDMi
jYEwQMcIfV7pI+nD1M9bocOk3TQ4nYWqlts2E6J+/qEC/ayXpo4kk/93swimj7wP
p6xDXw3sAX6Xaj0bZqcB
=ktrj
-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: Building with external toolchain was broken 6 months ago with r255187

2014-03-18 Thread Bjoern A. Zeeb 

On 18 Mar 2014, at 22:01 , John-Mark Gurney  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 
>> ^
>> 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:

Index: sys/modules/aesni/Makefile
===
--- sys/modules/aesni/Makefile  (revision 263176)
+++ sys/modules/aesni/Makefile  (working copy)
@@ -11,7 +11,8 @@ OBJS+=aesni_wrap.o
 
 # Remove -nostdinc so we can get the intrinsics.
 aesni_wrap.o: aesni_wrap.c
-   ${CC} -c ${CFLAGS:C/^-O2$/-O3/:N-nostdinc} ${WERROR} ${PROF} \
+   ${CC} -I${.CURDIR}/../../../contrib/llvm/tools/clang/lib/Headers \
+-c ${CFLAGS:C/^-O2$/-O3/:N-nostdinc} ${WERROR} ${PROF} \
 -mmmx -msse -maes ${.IMPSRC}
${CTFCONVERT_CMD}


— 
Bjoern A. Zeeb ? ??? ??? ??:
'??? ???  ??  ??? ?? ?? ??? ??? ??? ? ? 
?? ?? ? ',  ? ?, "??? ? ?? ?", ?.???

___
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

2014-03-18 Thread John-Mark Gurney 
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 
>  ^
> 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?

Can you compile this test program?

-- tsse.c start 
#include 

__m128i foo;
--  tsse.c end --

With the command:
${XCC} -c -maes tsse.c

If you can't, then the problem is your toolchain, and you need to fix
it...  Try also w/:
clang -c -maes tsse.c

and it's also helpful to know more info, like: ${XCC} --version

Thanks.

-- 
  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: Hello fdclose

2014-03-18 Thread Bruce Evans 

On Tue, 18 Mar 2014, John Baldwin wrote:


On Monday, March 17, 2014 7:23:19 pm Mariusz Zaborski wrote:
...
I think the code is fine.  I have a few suggestions on the manpage wording:

.Sh RETURN VALUES
-Upon successful completion 0 is returned.
+The
+.Fn fcloseall
+function return no value.
+.Pp
+Upon successful completion
+.Fn fclose
+return 0.
+Otherwise,
+.Dv EOF
+is returned and the global variable
+.Va errno
+is set to indicate the error.


The .Rv macro should be used whenever possible.  Unfortunately, it doesn't
support the EOF return, but only -1, so stdio man pages can rarely use it,
and this one is no exception.  Using it gives standard wording that is
quite different from the above:

standard wording:
 The close() function returns the value 0 if successful; otherwise the
 value -1 is returned and the global variable errno is set to indicate the
 error.
above wording (previous):
 Upon successful completion 0 is returned.Otherwise,
 EOF is returned  and the global variable errno is set to indicate the
 error.
above wording (new):
 Upon successful completion fclose() return [sic] 0.  Otherwise,
 EOF is returned  and the global variable errno is set to indicate the
 error.

These are excessively formal in different ways:
- I don't like "the foo() function".  Why not just "foo()"?  The
  standard wording uses this, and so does the new wording, but the
  previous wording omits the function name (that only works for man pages
  that only have a single function, as they should).
- I don't like "the value N".  Why not just "N"?  The standard wording
  uses this, but the previous and new wordings don't.
- "returns N" is better than "N is returned".  Some man pages use worse
  wordings like "N will be returned".
- "the global variable errno" is excessively detailed/verbose, without
  the details even being correct.  Why not just "errno", with this
  identifier documented elsewhere?  errno isn't a global variable in
  most implementations.  It is can be, and usually is, a macro that
  expands to a modifiable lvalue of type int.  In FreeBSD, the macro
  expands to a function that returns a pointer to int.
- "Upon sucessful completion" is correct but verbose.  The standard
  wording doesn't even use it.
- the standard wording uses a conjunction instead of a new sentence
  before "otherwise" (this is better).  It is missing a comma after
  "otherwise" (this is worse).


+.Pp
+The
+.Fn fdclose
+function return the file descriptor if successfull.
Otherwise,
.Dv EOF


"successfull is consistently misspelled.


One of English's arcane rules is that most verbs append an 's' when used with
singular subjects, so "function returns" shoud be used instead of "function
return", etc.  I do think for this section it would be good to combine the
descriptions of fclose() and fdclose() when possible, so perhaps something
like:

 "The fcloseall() function returns no value.

  Upon successful completion, fclose() returns 0 and fdclose() returns the
  file descriptor of the underlying file.  Otherwise, EOF is returned and
  the global variable errno is set to indicate the error.  In either case
  no further access to the stream is possible."


OK.  You kept "return[s] N" and and deverbosified "the foo() function".
"Upon successful completion" is needed more with several functions.
"the global variable errno" remains consistently bad.

There should be a comma after "In either case".


This allows "in either case" to still read correctly and makes it clear it
applies to both fclose() and fdclose().


Better "In every case".



.Sh ERRORS
+.Bl -tag -width Er
+.It Bq Er EOPNOTSUPP
The
+.Fa _close
+method in
+.Fa stream
+argument to
+.Fn fdclose ,
+was not default.
+.It Bq Er EBADF


The ERRORS section should be sorted.


For the errors section, the first error list needs some sort of introductory
text.  Also, this shouldn't claim that fdclose() can return an errno value for
close(2).

"ERRORS

  The fdclose() function may will fail if:


I don't like the tense given by "will" in man pages.  POSIX says "shall
fail" in similar contexts, and "will fail" is a mistranslation of this
("shall" is a technical term that doesn't suggest future tense).

deshallify.sh does the not-incorrect translation s/shall fail/fails/
(I think this is too simple to always work).  It doesn't translate
anything to "will".

I can't parse "may will" :-).  deshallify.txt doesn't translate "may"
or "should" to anything (these are also technical terms in some
contexts, so they might need translation.  IIRC, "may" is optional
behaviour, mostly for the implementation, while "shall" is required
behaviour, only for the implementation, but "should" is recommended
practice, mostly for applications).  Man pages are very unlikely to
be as consistent as POSIX with these terms.


  [EOPNOTSUPP]   The stream to close uses a non-default close method.

  [EBADF]The stream is not backed by a valid file de

Building with external toolchain was broken 6 months ago with r255187

2014-03-18 Thread Lev Serebryakov 
Hello, Freebsd-current.

 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/../../crypto
 /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 
 ^
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?

-- 
// Black Lion AKA Lev Serebryakov 

___
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

2014-03-18 Thread Jilles Tjoelker 
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.

> [snip]
> --- //depot/user/oshogbo/capsicum/lib/libc/stdio/Symbol.map   2013-06-28 
> 08:51:28.0 
> +++ /home/oshogbo/p4/capsicum/lib/libc/stdio/Symbol.map   2013-06-28 
> 08:51:28.0 
> @@ -156,6 +156,7 @@
>   putwc_l;
>   putwchar_l;
>   fmemopen;
> + fdclose;
>   open_memstream;
>   open_wmemstream;
>  };

This should be in the FBSD_1.4 namespace (which does not exist yet).

> [snip]
> --- //depot/user/oshogbo/capsicum/lib/libc/stdio/fclose.c 2013-06-28 
> 08:51:28.0 
> +++ /home/oshogbo/p4/capsicum/lib/libc/stdio/fclose.c 2013-06-28 
> 08:51:28.0 
> [snip]
> +int
> +fdclose(FILE *fp)
> +{
> + int fd, r, err;
> +
> + if (fp->_flags == 0) {  /* not open! */
> + errno = EBADF;
> + return (EOF);
> + }
> +
> + r = 0;
> + FLOCKFILE(fp);
> + fd = fp->_file;
> + if (fp->_close != __sclose) {
> + r = EOF;
> + errno = EOPNOTSUPP;
> + } else if (fd < 0) {
> + r = EOF;
> + errno = EBADF;
> + }
> + if (r == EOF) {
> + err = errno;
> + (void)cleanfile(fp, true);
> + errno = err;
> + } else {
> + r = cleanfile(fp, false);
> + }
>   FUNLOCKFILE(fp);
> +
> + return (r == 0 ? fd : r);

If a file descriptor would be returned but cleanfile() returns an error
(e.g. write error on flush), the file descriptor is not returned and not
closed.

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.

-- 
Jilles Tjoelker
___
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: r263306: rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/ldconfig'.

2014-03-18 Thread O. Hartmann 
On Tue, 18 Mar 2014 14:01:51 -0600
Alan Somers  wrote:

> On Tue, Mar 18, 2014 at 1:46 PM, O. Hartmann
>  wrote:
> > On CURRENT r263306 I get this weird result when checking the order of the 
> > rc.d scripts
> > with rcorder:
> >
> >  rcorder: Circular dependency on provision `mountcritremote' in file
> > `/etc/rc.d/ldconfig'.
> 
> Are you also including /usr/local/etc/rc.d/ with rcorder?  If so, what

Yes. If not included, the message doesn't show up.

> do you have installed there?  I find that rcorder's error message is
> almost useless for identify the cause of the circular dependency.

I guess you're right. I was a bit confused about that error message.

Oliver

> 
> -Alan
> ___
> 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"




signature.asc
Description: PGP signature

Re: r263306: rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/ldconfig'.

2014-03-18 Thread Alan Somers 
On Tue, Mar 18, 2014 at 1:46 PM, O. Hartmann
 wrote:
> On CURRENT r263306 I get this weird result when checking the order of the 
> rc.d scripts
> with rcorder:
>
>  rcorder: Circular dependency on provision `mountcritremote' in file
> `/etc/rc.d/ldconfig'.

Are you also including /usr/local/etc/rc.d/ with rcorder?  If so, what
do you have installed there?  I find that rcorder's error message is
almost useless for identify the cause of the circular dependency.

-Alan
___
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"

r263306: rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/ldconfig'.

2014-03-18 Thread O. Hartmann 
On CURRENT r263306 I get this weird result when checking the order of the rc.d 
scripts
with rcorder:

 rcorder: Circular dependency on provision `mountcritremote' in file
`/etc/rc.d/ldconfig'.


signature.asc
Description: PGP signature

r263306: boot fails

2014-03-18 Thread O. Hartmann 

r263306 fails to boot properly into multiuser mode (while r262252 does). One 
system gets
stuck showing starting "nfsuserd" on console and never go further, another box 
never
shows up any login but it prints massive ipfw messages,  that packets for 
192.168.01.1:631
is droped. Hitting Ctrl-C shows then that system.dns isn't availabel (I forgot 
the exact
message since I was in a hurry getting the boxes up again).

I rebooted older kernel (r263252) with no problem.

oh


signature.asc
Description: PGP signature

Re: FreeBSD GSOC proposal in 2014

2014-03-18 Thread yan cui 
Really? Maybe I can download his code from previous GSoC.
Actually, before applying for this idea, I did not scan the projects in
previous years and just pick up one which I like.
Are there any possibilities to improve on this part (or this idea should
not be considered any more)?

Yan


2014-03-18 14:26 GMT-04:00 John Baldwin :

> On Friday, March 14, 2014 3:02:18 am Wojciech A. Koszek wrote:
> > On Thu, Mar 13, 2014 at 09:56:35PM -0400, yan cui wrote:
> > > Hi all,
> > >
> > > I write this mail to make my question clear. I know witness can be
> used
> > > to detect wrong lock order in the kernel. However, can it be used to do
> > > lock profiling (what I mean is to report the information such as which
> > > locks are most contended and print some related statistics such as
> calling
> > > graph, etc)?
> > > In other words, is it enough to finish the task by porting witness to
> the
> > > pthread library?
> > >
> >
> > Yan,
> >
> > To my knowledge WITNESS is the only tool for lock order verification.
> >
> > For lock profiling in the FreeBSD kernel there's a KTR subsystem. KTR
> > mechanism is basically like syslog() in the user-space, but for the
> kernel.
> > KTR subsystem will receive messages from KTR API that is placed in the
> > FreeBSD kernel. Messages get stored on the list of some sort. List can be
> > exported to a file. File you can later analyze.
> >
> > Jeff wrote a Python app which can be used for pre-processing the KTR logs
> > from scheduler and protting them visually. Link:
> >
> > http://svnweb.freebsd.org/base/head/tools/sched/schedgraph.py
> >
> > Instead of porting witness to pthreads, maybe we could evaluate expanding
> > WITNESS to cover kern_umtx? This could prove to be more universal.
> >
> > Wojciech
>
> There is a dedicated lock profiler (LOCK_PROFILING) in the kernel.  A
> previous GSoC student from an earlier year has already re-implemented both
> LOCK_PROFILING and WITNESS for pthreads.
>
> --
> John Baldwin
>



-- 
Think big; Dream impossible; Make it happen.
___
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: Newcons with Nvidia

2014-03-18 Thread John Baldwin 
On Tuesday, March 18, 2014 10:29:50 am Jakub Lach wrote:
> Hello.
> 
> I've tried to use vt on 10-STABLE, but had my own problems and 
> abandoned it. From what I've heard, no support for vidcontrol(*)
> is expected at this point.
> 
> * https://wiki.freebsd.org/Newcons

Currently newcons does not support VESA mode changing for it's standard vga 
backend AFAIK.  The default 80x25 console is fine on an Nvidia card (it's what 
I used to test the 10 MFC), but it is slow.

-- 
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: FreeBSD GSOC proposal in 2014

2014-03-18 Thread John Baldwin 
On Friday, March 14, 2014 3:02:18 am Wojciech A. Koszek wrote:
> On Thu, Mar 13, 2014 at 09:56:35PM -0400, yan cui wrote:
> > Hi all,
> > 
> > I write this mail to make my question clear. I know witness can be 
used
> > to detect wrong lock order in the kernel. However, can it be used to do
> > lock profiling (what I mean is to report the information such as which
> > locks are most contended and print some related statistics such as calling
> > graph, etc)?
> > In other words, is it enough to finish the task by porting witness to the
> > pthread library?
> >
> 
> Yan,
> 
> To my knowledge WITNESS is the only tool for lock order verification.
> 
> For lock profiling in the FreeBSD kernel there's a KTR subsystem. KTR
> mechanism is basically like syslog() in the user-space, but for the kernel.
> KTR subsystem will receive messages from KTR API that is placed in the
> FreeBSD kernel. Messages get stored on the list of some sort. List can be
> exported to a file. File you can later analyze. 
> 
> Jeff wrote a Python app which can be used for pre-processing the KTR logs
> from scheduler and protting them visually. Link:
> 
> http://svnweb.freebsd.org/base/head/tools/sched/schedgraph.py
> 
> Instead of porting witness to pthreads, maybe we could evaluate expanding
> WITNESS to cover kern_umtx? This could prove to be more universal.
> 
> Wojciech

There is a dedicated lock profiler (LOCK_PROFILING) in the kernel.  A
previous GSoC student from an earlier year has already re-implemented both
LOCK_PROFILING and WITNESS for pthreads.

-- 
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: vm_map.h

2014-03-18 Thread John Baldwin 
On Thursday, March 13, 2014 6:46:13 pm Bruno Lauzé wrote:
> I suggesting this because it is used more ahead in the same file, but the 
> other way around is fine for me

No need to move them around:

Index: vm_map.h
===
--- vm_map.h(revision 263302)
+++ vm_map.h(working copy)
@@ -188,8 +188,10 @@ struct vm_map {
vm_flags_t flags;   /* flags for this vm_map */
vm_map_entry_t root;/* Root of a binary search tree */
pmap_t pmap;/* (c) Physical map */
+#ifdef _KERNEL
 #definemin_offset  header.start/* (c) */
 #definemax_offset  header.end  /* (c) */
+#endif
int busy;
 };
 
> 
> > From: j...@freebsd.org
> > To: freebsd-current@freebsd.org
> > Subject: Re: vm_map.h
> > Date: Thu, 13 Mar 2014 14:00:59 -0400
> > CC: brunola...@msn.com; a...@freebsd.org
> >
> > On Wednesday, March 12, 2014 5:13:28 pm Bruno Lauzé wrote:
> >> The two defines in vm/vm_map.h
> >>
> >> #define min_offset header.start /* (c) */
> >> #define max_offset header.end /* (c) */
> >>
> >>
> >> are really getting in the way because those words are most likely to be 
> >> used
> > downstream.
> >>
> >> I would suggest renaming those defines to:
> >>
> >> #define vm_min_offset header.start /* (c) */
> >> #define vm_max_offset header.end /* (c) */
> >>
> >> Am I missing something?
> >
> > A simpler fix is probably to put the #define's under #ifdef _KERNEL.
> >
> > --
> > John Baldwin

-- 
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"

[rfc] /dev/devstat permissions patch

2014-03-18 Thread Maksim Yevmenkin 
hello,

would anyone object to the following patch?

==

Index: subr_devstat.c
===
--- subr_devstat.c (revision 263311)
+++ subr_devstat.c (working copy)
@@ -503,7 +503,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;
  }

==

i'm not sure why /dev/devstat has such restrictive permissions. can
someone please explain the reason for it? having gstat(8) require
super-user privilege seems like an overkill me. iostat(8) and
systat(1) do not require super-user privileges to work.

and, yes, i know i can override permissions with /etc/devfs.conf, just
curious what are we protecting from in /dev/devstat

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: File not found in ftp repository

2014-03-18 Thread Nilton Jose Rizzo 
Em Tue, 18 Mar 2014 11:47:04 -0700, Julian Elischer escreveu
> On 3/17/14, 7:54 AM, Thomas Hoffmann wrote:
> > On Sun, Mar 16, 2014 at 11:56 PM, Nilton Jose Rizzo 
> > wrote:
> >
> >>
>  ==> SIZE xfce4-equake-plugin-1.3.4.tar.bz2 ... feito.
>  ==> PASV ... feito.   ==> RETR xfce4-equake-plugin-1.3.4.tar.bz2 ...
>  O arquivo 'xfce4-equake-plugin-1.3.4.tar.bz2' não foi encontrado.
> >> (file
> > not found)
> >
> > this file was required by xfce4 and not found in any repository
> > where can I found it?
> 
> generally if you need to find a distfile that has gone away this site:
> 
>   http://www.filewatcher.com
> 
> will tell you where there are still copies
> >
> > Rizzo
> 
> 

 Thankx
> ___
> 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: File not found in ftp repository

2014-03-18 Thread Julian Elischer 

On 3/17/14, 7:54 AM, Thomas Hoffmann wrote:

On Sun, Mar 16, 2014 at 11:56 PM, Nilton Jose Rizzo wrote:




==> SIZE xfce4-equake-plugin-1.3.4.tar.bz2 ... feito.
==> PASV ... feito.   ==> RETR xfce4-equake-plugin-1.3.4.tar.bz2 ...
O arquivo 'xfce4-equake-plugin-1.3.4.tar.bz2' não foi encontrado.

(file

not found)

this file was required by xfce4 and not found in any repository
where can I found it?


generally if you need to find a distfile that has gone away this site:

 http://www.filewatcher.com

will tell you where there are still copies


Rizzo




___
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

2014-03-18 Thread John Baldwin 
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."

 .Sh RETURN VALUES
-Upon successful completion 0 is returned.
+The
+.Fn fcloseall
+function return no value.
+.Pp
+Upon successful completion
+.Fn fclose
+return 0.
+Otherwise,
+.Dv EOF
+is returned and the global variable
+.Va errno
+is set to indicate the error.
+.Pp
+The
+.Fn fdclose
+function return the file descriptor if successfull.
 Otherwise,
 .Dv EOF

One of English's arcane rules is that most verbs append an 's' when used with 
singular subjects, so "function returns" shoud be used instead of "function 
return", etc.  I do think for this section it would be good to combine the
descriptions of fclose() and fdclose() when possible, so perhaps something
like:

  "The fcloseall() function returns no value.

   Upon successful completion, fclose() returns 0 and fdclose() returns the
   file descriptor of the underlying file.  Otherwise, EOF is returned and
   the global variable errno is set to indicate the error.  In either case
   no further access to the stream is possible."

This allows "in either case" to still read correctly and makes it clear it
applies to both fclose() and fdclose().

 .Sh ERRORS
+.Bl -tag -width Er
+.It Bq Er EOPNOTSUPP
 The
+.Fa _close
+method in
+.Fa stream
+argument to
+.Fn fdclose ,
+was not default.
+.It Bq Er EBADF
+The
+.Fa stream
+argument to
+.Fn fdclose ,
+does not contains valid file descriptor.
+.El
+.Pp
+The
 .Fn fclose
-function
+and
+.Fn fdclose
+functions
 may also fail and set
 .Va errno

For the errors section, the first error list needs some sort of introductory
text.  Also, this shouldn't claim that fdclose() can return an errno value for 
close(2).

"ERRORS

   The fdclose() function may will fail if:

   [EOPNOTSUPP]   The stream to close uses a non-default close method.

   [EBADF]The stream is not backed by a valid file descriptor.

   The fclose() and fdclose() functions may also fail and set errno for any of
   the errors specified for fflush(3).

   The fclose() functino may also fail and set errno for any of the errors
   specified for close(2)."

@@ -84,7 +130,9 @@
 .Sh NOTES
 The
 .Fn fclose
-function
+and
+.Fn fdclose
+functions
 does not handle NULL arguments; they will result in a segmentation
 violation.
 This is intentional - it makes it easier to make sure programs written

"do not handle".

-- 
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: Newcons with Nvidia

2014-03-18 Thread Jakub Lach 
Hello.

I've tried to use vt on 10-STABLE, but had my own problems and 
abandoned it. From what I've heard, no support for vidcontrol(*)
is expected at this point.

* https://wiki.freebsd.org/Newcons



--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/Newcons-with-Nvidia-tp5895287p5895400.html
Sent from the freebsd-current mailing list archive at Nabble.com.
___
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: reproducible panic every day at 03:02, probably triggered by daily periodic scipts - help

2014-03-18 Thread Anton Shterenlikht 
I've spent a lot of time on this.
At some point I started suspecting
disk failures, based on dd errors and smartmontools
reports. So I replaced the disks,
and then replaced the whole box for
another nominally identical SunBlade 1500.
The panics persisted.
I now think that multiple cold reboots
might have damaged disks, not the other
way round.

In the end I had to conclude that this
is not a hardware problem, but the OS issue,
perhaps triggered by some heavy disk I/O.

Various frequent panics exist at least from
r260689 to r263096:

r260689: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/186760
r260914: http://www.freebsd.org/cgi/query-pr.cgi?pr=187219
r261798: http://www.freebsd.org/cgi/query-pr.cgi?pr=187080
r263096: http://www.freebsd.org/cgi/query-pr.cgi?pr=187527

I now reverted as far back as r258000, and
the system seems stable, but I probably
need few more days to be sure.

If the system is indeed stable at r258000,
when I have the time, I'll try to narrow
down the problem revision. But I'd appreciate
any hint that might save time.

Anton

___
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: [HEADSUP] pkg 1.3.0 alpha1: Breath of fresh air from Kirov

2014-03-18 Thread Baptiste Daroussin 
On Tue, Mar 18, 2014 at 01:57:51PM +1300, Andrew Thompson wrote:
> On 18 March 2014 06:21, Baptiste Daroussin  wrote:
> 
> > Hello,
> >
> > I'm really pleased to announce that the release process for the new major
> > version of pkg(8) has started with this first alpha1 release.
> >
> > The main feature for this release is the complete rework of the solver.
> > pkg(8) now features a real SAT solver and uses it for every operations
> > requested
> > by the user that may add, upgrade or remove packages.
> >
> >
> I am sure this has been discussed before but does this release do anything
> to help automating UPDATING or is this a planned feature?
> 
> Taking the last entry which says to "pkg set -o
> misc/p5-OSSP-uuid:misc/ossp-uuid-perl", just do it for me pkg!
> 
The new solver takes care of this without the need of pkg set -o :)
It would be now transparent for users. (all they might discover is that a
conflict is detected then a new pass in the solver is needed and and the
problems is solved properly by the removal of ossp-uuid-perl and installation of
p5-OSSP-uuid.

regards,
Bapt


pgpNHoB84ptG3.pgp
Description: PGP signature