Re: [HEADSUP] pkg 1.3.0 alpha1: Breath of fresh air from Kirov
On Tue, Mar 18, 2014 at 01:57:51PM +1300, Andrew Thompson wrote: On 18 March 2014 06:21, Baptiste Daroussin b...@freebsd.org 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
Re: reproducible panic every day at 03:02, probably triggered by daily periodic scipts - help
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: Newcons with Nvidia
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: Hello fdclose
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: File not found in ftp repository
On 3/17/14, 7:54 AM, Thomas Hoffmann wrote: On Sun, Mar 16, 2014 at 11:56 PM, Nilton Jose Rizzo ri...@i805.com.brwrote: == 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: File not found in ftp repository
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 ri...@i805.com.brwrote: == 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
[rfc] /dev/devstat permissions patch
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: vm_map.h
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
Re: FreeBSD GSOC proposal in 2014
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: Newcons with Nvidia
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
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 j...@freebsd.org: 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
r263306: boot fails
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
r263306: rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/ldconfig'.
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
Re: r263306: rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/ldconfig'.
On Tue, Mar 18, 2014 at 1:46 PM, O. Hartmann ohart...@zedat.fu-berlin.de 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
Re: r263306: rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/ldconfig'.
On Tue, 18 Mar 2014 14:01:51 -0600 Alan Somers asom...@freebsd.org wrote: On Tue, Mar 18, 2014 at 1:46 PM, O. Hartmann ohart...@zedat.fu-berlin.de 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: Hello fdclose
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
Building with external toolchain was broken 6 months ago with r255187
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 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? -- // Black Lion AKA Lev Serebryakov l...@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: Hello fdclose
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 descriptor. The fclose() and fdclose() functions may also fail and
Re: Building with external toolchain was broken 6 months ago with r255187
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?
Can you compile this test program?
-- tsse.c start
#include wmmintrin.h
__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: Building with external toolchain was broken 6 months ago with r255187
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:
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: [rfc] /dev/devstat permissions patch
-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 delp...@delphij.nethttps://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
Bjoern A. Zeeb wrote this message on Tue, Mar 18, 2014 at 22:20 +:
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/../../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 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:
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
Build failed in Jenkins: FreeBSD_HEAD #307
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/307/changes 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. -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/altq -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/dev/uart/uart_subr.c 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. -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/altq -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/dev/usb/controller/ehci.c --- 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 -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/modules/bxe/../../dev/bxe -DHAVE_KERNEL_OPTION_HEADERS -include /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/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/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
Re: Hello fdclose
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
Jenkins build is back to normal : FreeBSD_HEAD #308
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/308/changes ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
