Re: svn commit: r366949 - head/usr.sbin/nfsd

[Benjamin Kaduk]

On Thu, Oct 22, 2020 at 12:25 PM Gordon Bergling  wrote:

> Author: gbe (doc committer)
> Date: Thu Oct 22 19:25:01 2020
> New Revision: 366949
> URL: https://svnweb.freebsd.org/changeset/base/366949
>
> Log:
>   stablerestart(5): Fix some issues reported by mandoc
>
>   - New sentence, new line
>
> Modified:
>   head/usr.sbin/nfsd/stablerestart.5
>
> Modified: head/usr.sbin/nfsd/stablerestart.5
>
> ==
> --- head/usr.sbin/nfsd/stablerestart.5  Thu Oct 22 19:22:34 2020
> (r366948)
> +++ head/usr.sbin/nfsd/stablerestart.5  Thu Oct 22 19:25:01 2020
> (r366949)
> @@ -52,18 +52,18 @@ first record.
>  The lease duration is used to set the grace period.
>  The boot times
>  are used to avoid the unlikely occurrence of a boot time being reused,
> -due to a TOD clock going backwards. This record and the previous boot
> times with this boot time added is re-written at the
> -end of the grace period.
> +due to a TOD clock going backwards.
> +This record and the previous boot times with this boot time
> +added is re-written at the end of the grace period.
>  .Pp
>  The rest of the file are appended records, as defined by
> -struct nfst_rec in /usr/include/fs/nfs/nfsrvstate.h and are used
> -represent one of two things. There are records which indicate that a
> +struct nfst_rec in /usr/include/fs/nfs/nfsrvstate.h and are used
> represent one of two things.
>
>
There are some more markup options here, like  (IIRC) .Fa for struct
nfst_rec, and .Pa for /usr/include/fs/nfs/nfsrvstate.h

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r365643 - head/bin/cp

[Benjamin Kaduk]

On Sat, Sep 26, 2020 at 12:35 PM Warner Losh  wrote:

>
>
> On Sat, Sep 26, 2020 at 12:58 PM Benjamin Kaduk  wrote:
>
>> On Sat, Sep 26, 2020 at 11:55 AM Warner Losh  wrote:
>>
>>> And there's the rub: how did this file come to exist? I'm certain it
>>> isn't
>>> booting or shutting down the system based on when devfs is mounted
>>> (before
>>> init) and unmounted (it's not done by the shutdown scripts). Now, it's
>>> always possible there's a hole in my understanding of the sequence of
>>> events. But given the examination of code, it's crazy to think this could
>>> be created by anything but some weird bug. That's why a step-by-step from
>>> scratch guide is needed. Im happy to look into it, but I need a bit more
>>> to
>>> go on.
>>>
>>>
>> I don't think it's terribly complicated; either set up a multi-boot
>> system or
>> pull the physical drive with / from one machine, and mount it while booted
>> into a different environment.  Then, chroot into it and do ... just about
>> anything.
>> If you didn't mount devfs before chrooting, then you get a file /dev/null
>> (and some
>> really confused errors from, e.g., buildworld!).
>>
>
> I think there's two different things that are being talked about here.
> Let's not confuse the two.
>
>
I agree there are two different things going on here.  My apologies for
using buildworld as an example of "something that writes to /dev/null" when
any other example would have done just as well.


> The first is making the build system not depend on /dev/null. You'll find
> that's hard to do if you and try to do it since /dev/null is used about 200
> times in the current build system in about a dozen different ways. Some are
> easy, most are a bit tricky since you can't just close stdout/stderr
> because then any files opened by the program will get those FDs and
> printf/fprint(stderr, will collide.  This dependency won't be fixed any
> time soon, though I could add a seatbelt to buildworld/buildkernel that
> ensures that /dev/null is a character device.
>
> The second is a report that /dev/null is created all the time through
> normal means before devfs can be mounted.  However, several people have
> looked and found no evidence on their system. This means there's something
> special / unique to Rod's setup that's generating them (assuming it isn't a
> simple chroot without devfs). What that is, and how they come to be, hasn't
> been explained in enough detail to reproduce. That's what people are asking
> Rod about: how do we get there? How did it happen? Once we know those
> answers, we can fix it.
>
>
I was reading the thread differently than that.  In particular, I saw
observations that some people had a file /dev/null on their root
filesystem, and speculation that it appeared during early boot or
shutdown.  In particular, I did not see specific reports that it was
created during early shutdown, just speculation.  Such speculation has
since been thoroughly debunked, but the observations of a /dev/null file
remain.  It is easy to get such a /dev/null file on your root filesystem,
you just have to arrange for that filesystem to not actually *be* the root
filesystem when the file is created.  So ... "nothing to see here"?

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r365643 - head/bin/cp

[Benjamin Kaduk]

On Sat, Sep 26, 2020 at 11:55 AM Warner Losh  wrote:

> And there's the rub: how did this file come to exist? I'm certain it isn't
> booting or shutting down the system based on when devfs is mounted (before
> init) and unmounted (it's not done by the shutdown scripts). Now, it's
> always possible there's a hole in my understanding of the sequence of
> events. But given the examination of code, it's crazy to think this could
> be created by anything but some weird bug. That's why a step-by-step from
> scratch guide is needed. Im happy to look into it, but I need a bit more to
> go on.
>
>
I don't think it's terribly complicated; either set up a multi-boot system
or
pull the physical drive with / from one machine, and mount it while booted
into a different environment.  Then, chroot into it and do ... just about
anything.
If you didn't mount devfs before chrooting, then you get a file /dev/null
(and some
really confused errors from, e.g., buildworld!).

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r365052 - head/usr.bin/script

[Benjamin Kaduk]

On Tue, Sep 1, 2020 at 9:11 AM Warner Losh  wrote:

> Author: imp
> Date: Tue Sep  1 16:11:23 2020
> New Revision: 365052
> URL: https://svnweb.freebsd.org/changeset/base/365052
>
> Log:
>   Have script accept and ignore -e for Linux compat
>
>   In the util-linux version of script, it will always exit with succes.
>   Except when run with -e, in which case it will have the exit value of
>   the child. BSD Script already uses the child's exit value for its exit
>   value. Some config and other helper scripts depend on being able to
>   specify -e. Accept it for compatibility since we'll already to the
>   right thing, but otherwise we ignore it.
>
>
What kind of usage is not currently portable but becomes portable as a
result
of this change?  I thought the BSD and GNU syntax was inherently pretty
different,
e.g., with '-c' for the command to run vs. implicit positional arguments,
and would
love to be able to retrain myself to something that works everywhere...

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r364822 - in head/crypto/openssl/crypto: aes/asm bn/asm chacha/asm ec/asm modes/asm poly1305/asm sha/asm

[Benjamin Kaduk]

On Thu, Aug 27, 2020 at 1:25 PM John Baldwin  wrote:

> On 8/26/20 9:55 AM, Jung-uk Kim wrote:
> > Author: jkim
> > Date: Wed Aug 26 16:55:28 2020
> > New Revision: 364822
> > URL: https://svnweb.freebsd.org/changeset/base/364822
> >
> > Log:
> >   Fix Clang version detection.
> >
> >   We prepend "FreeBSD" to Clang version string.  This broke compiler
> test for
> >   AVX instruction support.
>
> Have you opened a PR upstream to fix this?  They should be willing to
> accept it since it probably affects clang on OS X as well?
>
>
https://github.com/openssl/openssl/pull/12725 should land in a few hours.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r362620 - head/secure/lib/libcrypto

[Benjamin Kaduk]

On Thu, Jun 25, 2020 at 12:35 PM Gordon Tetlow  wrote:

> Author: gordon
> Date: Thu Jun 25 19:35:37 2020
> New Revision: 362620
> URL: https://svnweb.freebsd.org/changeset/base/362620
>
> Log:
>   Revert OPENSSL_NO_SSL3_METHOD to keep ABI compatibility.
>
>   This define caused a couple of symbols to disappear. To keep ABI
>   compatibility, we are going to keep the symbols exposed, but leave SSLv3
> as
>   not in the default config (this is what OPENSSL_NO_SSL3 achieves). The
>   ramifications of this is an application can still use SSLv3 if it
>   specifically calls the SSLv3_method family of APIs.
>
>
I think I've seen some distros that keep the functinos around but just have
them always return failure.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r361839 - head/usr.bin/killall

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Fri Jun  5 16:59:14 2020
New Revision: 361839
URL: https://svnweb.freebsd.org/changeset/base/361839

Log:
  Belatedly bump .Dd for r361783
  
  Reported by:  lwhsu
  Pointy hat to:bjk

Modified:
  head/usr.bin/killall/killall.1

Modified: head/usr.bin/killall/killall.1
==
--- head/usr.bin/killall/killall.1  Fri Jun  5 16:12:21 2020
(r361838)
+++ head/usr.bin/killall/killall.1  Fri Jun  5 16:59:14 2020
(r361839)
@@ -24,7 +24,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd June 30, 2013
+.Dd June 4, 2020
 .Dt KILLALL 1
 .Os
 .Sh NAME
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r361783 - head/usr.bin/killall

[Benjamin Kaduk]

It seems Conrad dropped me from his reply, so I can't include it directly,
but...

On Thu, Jun 04, 2020 at 06:12:05AM -0700, Rodney W. Grimes wrote:
> > 04.06.2020 11:29, Benjamin Kaduk wrote:
> > 
> > > Author: bjk (doc committer)
> > > Date: Thu Jun  4 04:29:43 2020
> > > New Revision: 361783
> > > URL: https://svnweb.freebsd.org/changeset/base/361783
> > > 
> > > Log:
> > >   Add EXAMPLES to killall(1)
> > >   
> > >   Submitted by:   fernape
> > >   Differential Revision:  https://reviews.freebsd.org/D25002
> > > 
> > > Modified:
> > >   head/usr.bin/killall/killall.1
> > > 
> > > Modified: head/usr.bin/killall/killall.1
> > > ==
> > > --- head/usr.bin/killall/killall.1Thu Jun  4 02:36:41 2020
> > > (r361782)
> > > +++ head/usr.bin/killall/killall.1Thu Jun  4 04:29:43 2020
> > > (r361783)
> > > @@ -145,6 +145,50 @@ utility exits 0 if some processes have been found and
> > >  signalled successfully.
> > >  Otherwise, a status of 1 will be
> > >  returned.
> > > +.Sh EXAMPLES
> > > +Send
> > > +.Dv SIGTERM
> > > +to all firefox processes:
> > > +.Bd -literal -offset indent
> > > +killall firefox
> > > +.Ed
> > > +.Pp
> > > +Send
> > > +.Dv SIGTERM
> > > +to firefox processes belonging to
> > > +.Va USER :
> > > +.Bd -literal -offset indent
> > > +killall -u ${USER} firefox
> > > +.Ed
> > > +.Pp
> > > +Stop all firefox processes:
> > > +.Bd -literal -offset indent
> > > +killall -SIGSTOP firefox
> > > +.Ed
> > > +.Pp
> > > +Resume firefox processes:
> > > +.Bd -literal -offset indent
> > > +killall -SIGCONT firefox
> > > +.Ed
> > > +.Pp
> > > +Show what would be done to firefox processes, but do not actually signal 
> > > them:
> > > +.Bd -literal -offset indent
> > > +killall -s firefox
> > > +.Ed
> > > +.Pp
> > > +Send
> > > +.Dv SIGKILL
> > > +to csh process running inside jail ID 282:
> > > +.Bd -literal -offset indent
> > > +killall -9 -j282 csh
> > > +.Ed
> > > +.Pp
> > > +Send
> > > +.Dv SIGTERM
> > > +to all processes matching provided pattern (like vim and vimdiff):
> > > +.Bd -literal -offset indent
> > > +killall -m 'vim*'
> > > +.Ed
> > >  .Sh DIAGNOSTICS
> > >  Diagnostic messages will only be printed if requested by
> > >  .Fl d
> > 
> > "Firefox" is a trade mark (type of intellectual property) of Mozilla 
> > Foundation.
> > Is it OK for us to use this name such way?
> > 
> > Isn't it better using a name of some utility we have in the base system 
> > like systat(1) ?
> 
> Purley out of simple safety I agree here.   Though I doubt a case could
> be made for infringement it is just too easy to do the safe thing.

I'm not aware of any issues with using a trademark-protected term to refer
to the product named by the mark, and don't see how one could claim that
this usage is an attempt to dilute the mark.  I don't currently plan to
make any further changes to this example, myself (though I will not stand
in the way if someone else wants to blandify the example).

Thanks,

Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r361783 - head/usr.bin/killall

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Thu Jun  4 04:29:43 2020
New Revision: 361783
URL: https://svnweb.freebsd.org/changeset/base/361783

Log:
  Add EXAMPLES to killall(1)
  
  Submitted by: fernape
  Differential Revision:https://reviews.freebsd.org/D25002

Modified:
  head/usr.bin/killall/killall.1

Modified: head/usr.bin/killall/killall.1
==
--- head/usr.bin/killall/killall.1  Thu Jun  4 02:36:41 2020
(r361782)
+++ head/usr.bin/killall/killall.1  Thu Jun  4 04:29:43 2020
(r361783)
@@ -145,6 +145,50 @@ utility exits 0 if some processes have been found and
 signalled successfully.
 Otherwise, a status of 1 will be
 returned.
+.Sh EXAMPLES
+Send
+.Dv SIGTERM
+to all firefox processes:
+.Bd -literal -offset indent
+killall firefox
+.Ed
+.Pp
+Send
+.Dv SIGTERM
+to firefox processes belonging to
+.Va USER :
+.Bd -literal -offset indent
+killall -u ${USER} firefox
+.Ed
+.Pp
+Stop all firefox processes:
+.Bd -literal -offset indent
+killall -SIGSTOP firefox
+.Ed
+.Pp
+Resume firefox processes:
+.Bd -literal -offset indent
+killall -SIGCONT firefox
+.Ed
+.Pp
+Show what would be done to firefox processes, but do not actually signal them:
+.Bd -literal -offset indent
+killall -s firefox
+.Ed
+.Pp
+Send
+.Dv SIGKILL
+to csh process running inside jail ID 282:
+.Bd -literal -offset indent
+killall -9 -j282 csh
+.Ed
+.Pp
+Send
+.Dv SIGTERM
+to all processes matching provided pattern (like vim and vimdiff):
+.Bd -literal -offset indent
+killall -m 'vim*'
+.Ed
 .Sh DIAGNOSTICS
 Diagnostic messages will only be printed if requested by
 .Fl d
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r358417 - head/sys/cam

[Benjamin Kaduk]

On Thu, Feb 27, 2020 at 5:18 PM Warner Losh  wrote:

> Author: imp
> Date: Fri Feb 28 01:18:11 2020
> New Revision: 358417
> URL: https://svnweb.freebsd.org/changeset/base/358417
>
> Log:
>   This is a FALLTHROUGH for sure. no need for xxx comment.
>
> Modified:
>   head/sys/cam/cam_xpt.c
>
> Modified: head/sys/cam/cam_xpt.c
>
> ==
> --- head/sys/cam/cam_xpt.c  Fri Feb 28 01:02:01 2020(r358416)
> +++ head/sys/cam/cam_xpt.c  Fri Feb 28 01:18:11 2020(r358417)
> @@ -2690,7 +2690,7 @@ xpt_action_default(union ccb *start_ccb)
> case XPT_NVME_ADMIN:
> /* FALLTHROUGH */
> case XPT_MMC_IO:
> -   /* XXX just like nmve_io? */
> +   /* FALLTHROUGH */
> case XPT_RESET_DEV:
> case XPT_ENG_EXEC:
> case XPT_SMP_IO:
>
>
Okay, I'll bite.  Why do XPT_NVME_ADMIN and XPT_MMC_IO get "FALLTHROUGH"
comments but XPT_RESET_DEV and XPT_ENG_EXEC just get listed as part of the
same grouping as XPT_SMP_IO?

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r355696 - head/lib/libtacplus

[Benjamin Kaduk]

On Thu, Dec 12, 2019 at 9:11 PM Conrad Meyer  wrote:

> Author: cem
> Date: Fri Dec 13 05:11:34 2019
> New Revision: 355696
> URL: https://svnweb.freebsd.org/changeset/base/355696
>
> Log:
>   libtacplus: Remove bogus srandomdev+random
>
>   Replace with arc4random.
>
>   TACAS+ is a 1993 Cisco extension to the 1984 TACAS.  Is this something
> we want
>   in base still?  The directory has been substantively unmaintained since
> 2002,
>   at least.
>
>
It's not as dead as that makes it sound --
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/ is on its way to
becoming an RFC.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r350325 - in head: lib/libc/sys share/man/man9

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Thu Jul 25 15:43:15 2019
New Revision: 350325
URL: https://svnweb.freebsd.org/changeset/base/350325

Log:
  Fix grammar nit in copy_file_range docs
  
  Bytes are countable, so we have fewer of them, not less of them.

Modified:
  head/lib/libc/sys/copy_file_range.2
  head/share/man/man9/VOP_COPY_FILE_RANGE.9

Modified: head/lib/libc/sys/copy_file_range.2
==
--- head/lib/libc/sys/copy_file_range.2 Thu Jul 25 15:31:15 2019
(r350324)
+++ head/lib/libc/sys/copy_file_range.2 Thu Jul 25 15:43:15 2019
(r350325)
@@ -110,7 +110,7 @@ arguments and this system call for the
 data ranges found.
 .Pp
 .Sh RETURN VALUES
-If it succeeds, the call returns the number of bytes copied, which can be less
+If it succeeds, the call returns the number of bytes copied, which can be fewer
 than
 .Fa len .
 .Fn copy_file_range

Modified: head/share/man/man9/VOP_COPY_FILE_RANGE.9
==
--- head/share/man/man9/VOP_COPY_FILE_RANGE.9   Thu Jul 25 15:31:15 2019
(r350324)
+++ head/share/man/man9/VOP_COPY_FILE_RANGE.9   Thu Jul 25 15:43:15 2019
(r350325)
@@ -93,7 +93,7 @@ It should be reduced by the number of bytes copied, wh
 the value pointed to by
 .Fa len
 will normally be zero for a non-error return.
-However, a copy of less bytes than requested is permitted.
+However, a copy of fewer bytes than requested is permitted.
 .Sh LOCKS
 The vnode are unlocked on entry and must be unlocked on return.
 The byte ranges for both
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r349589 - in head: sbin/mount sys/sys sys/ufs/ffs

[Benjamin Kaduk]

On Mon, Jul 1, 2019 at 8:33 PM Kirk McKusick via svn-src-all <
svn-src-...@freebsd.org> wrote:

> Author: mckusick
> Date: Mon Jul  1 23:22:26 2019
> New Revision: 349589
> URL: https://svnweb.freebsd.org/changeset/base/349589
>
> Log:
>   Add a new "untrusted" option to the mount command. Its purpose
>   is to notify the kernel that the file system is untrusted and it
>   should use more extensive checks on the file-system's metadata
>   before using it. This option is intended to be used when mounting
>   file systems from untrusted media such as USB memory sticks or other
>   externally-provided media.
>
>
Are these additional extensive checks supposed to be computationally
expensive
in some regard, that we would not want to just always perform them?

Thanks,

Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r349133 - head/share/man/man4

[Benjamin Kaduk]

On Sun, Jun 16, 2019 at 10:42 PM Niclas Zeising  wrote:

> Author: zeising (doc,ports committer)
> Date: Mon Jun 17 05:41:47 2019
> New Revision: 349133
> URL: https://svnweb.freebsd.org/changeset/base/349133
>
> Log:
>   pci(4): Document PCIOCATTACHED
>
>   Document the PCIOCATTACHED ioctl(2) in the pci(4) manual.
>   PCIOCATTACHED is used to query if a driver has attached to a PCI.
>
>   Reviewed by:  bcr, imp
>   MFC after:2 weeks
>   Differential Revision:https://reviews.freebsd.org/D20652
>
> Modified:
>   head/share/man/man4/pci.4
>
> Modified: head/share/man/man4/pci.4
>
> ==
> --- head/share/man/man4/pci.4   Mon Jun 17 03:48:44 2019(r349132)
> +++ head/share/man/man4/pci.4   Mon Jun 17 05:41:47 2019(r349133)
> @@ -24,7 +24,7 @@
>  .\"
>  .\" $FreeBSD$
>  .\"
> -.Dd June 14, 2018
> +.Dd June 17, 2019
>  .Dt PCI 4
>  .Os
>  .Sh NAME
> @@ -333,6 +333,26 @@ The limitations on data width described for
>  reading registers, above, also apply to writing
>  .Tn PCI
>  configuration registers.
> +.It PCIOCATTACHED
> +This
> +.Xr ioctl 2
> +allows users to query if a driver is attached to the
> +.Tn PCI
> +specified in the passed-in
>

Is there a missing word like "device" here?

Thanks,

Ben


> +.Va pci_io
> +structure.
> +The
> +.Va pci_io
> +structure is described above, however, the
> +.Va pi_reg
> +and
> +.Va pi_width
> +fields are not used.
> +The status of the device is stored in the
> +.Va pi_data
> +field.
> +A value of 0 indicates no driver is attached, while a value larger than 0
> +indicates that a driver is attached.
>  .It PCIOCBARMMAP
>  This
>  .Xr ioctl 2
> ___
> svn-src-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r348421 - head/sys/kern

[Benjamin Kaduk]

On Thu, May 30, 2019 at 8:04 AM Konstantin Belousov  wrote:

> Author: kib
> Date: Thu May 30 15:04:09 2019
> New Revision: 348421
> URL: https://svnweb.freebsd.org/changeset/base/348421
>
> Log:
>   Silence witness warning about duplicated mutex type.
>
>   The order is correct, it is nullfs vnode interlock -> lower vnode
>   interlock.  vop_stdadd_writecount() is called from nullfs
>   VOP_ADD_WRITECOUNT() and both take interlocks.
>
>   Requested by: markj
>   Sponsored by: The FreeBSD Foundation
>   MFC after:2 weeks
>
> Modified:
>   head/sys/kern/vfs_default.c
>
> Modified: head/sys/kern/vfs_default.c
>
> ==
> --- head/sys/kern/vfs_default.c Thu May 30 14:40:23 2019(r348420)
> +++ head/sys/kern/vfs_default.c Thu May 30 15:04:09 2019(r348421)
> @@ -1113,7 +1113,7 @@ vop_stdadd_writecount(struct vop_add_writecount_args
> *
> int error;
>
> vp = ap->a_vp;
> -   VI_LOCK(vp);
> +   VI_LOCK_FLAGS(vp, MTX_DUPOK);
> if (vp->v_writecount < 0) {
> error = ETXTBSY;
> } else {
>
>
Does this merit a comment justifying the use of DUPOK?

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r344569 - in head/cddl/contrib/opensolaris: cmd/zfs lib/libzfs/common

[Benjamin Kaduk]

On Tue, Feb 26, 2019 at 11:19 AM John Baldwin  wrote:

> On 2/26/19 8:59 AM, Rodney W. Grimes wrote:
> >> On Tue, Feb 26, 2019 at 10:14 AM Cy Schubert  >
> >> wrote:
> >>
> >>> On February 26, 2019 7:48:27 AM PST, Cy Schubert <
> >>> cy.schub...@cschubert.com> wrote:
>  On February 26, 2019 12:18:35 AM PST, Baptiste Daroussin
>   wrote:
> >>>
> >>
> >> [trimming the unneeded pile of commit body]
> >>
> >>
>  This broke my systems, many filesystems fail to mount causing nullfs
>  late mounts to fail. No details now until tonight.
> 
>  Suggest we back this out until it is properly tested.
> >>>
> >>> Nested zfs filesystems seem not to be handled properly or possibly not
> >>> supported any more. This explains my mail gateway also not mounting all
> >>> filesystems in /home. It was odd that dovecot stopped working.
> >>>
> >>> The symptom of the problem is zfs mount -a no longer mounts all
> >>> filesystems. Zfs mount fails saying the filesystem is already mounted.
> The
> >>> workaround is to zfs umount each affected zfs dataset by hand and zfs
> mount
> >>> it by hand.
> >>>
> >>> Generally this has screwed up sites that have hundreds (in my case 122)
> >>> zfs datasets. The work around might be to script testing each mount,
> >>> unmounting and remounting if necessary.
> >>>
> >>> I'm being sarcastic about creating an rc script to clean this up. This
> >>> needs to be backed out and tested properly before being committed.
> >>>
> >>>
> >> I don't know what you mean by "nested zfs filesystems" -- do you mean a
> >> zpool within a zvol?
> >> That has been unsupported for a long time, IIRC.  And
> > That had better not be unsupported, that is the prefered technology
> > for all of the virtualization stuff, bhyve, virtualbox, qemu, etc.
>
> I think Ben is referring to using the nested zpool on the host itself
> rather
> than in the guest.  We do actually let you do such crazy things I think (I
> use UFS in my VMs usually and fsck on the host against
> /dev/zvol/bhyve/p2
> can be faster than fsck in the booted guest), but normally the host just
> hosts
> the zvol and the guest manages filesystems in the volume.  Mounting the
> nested zpool on the host is probably best characterized as running with
> scissors.
>
>
Exactly so; thanks for clarifying.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r344569 - in head/cddl/contrib/opensolaris: cmd/zfs lib/libzfs/common

[Benjamin Kaduk]

On Tue, Feb 26, 2019 at 10:14 AM Cy Schubert 
wrote:

> On February 26, 2019 7:48:27 AM PST, Cy Schubert <
> cy.schub...@cschubert.com> wrote:
> >On February 26, 2019 12:18:35 AM PST, Baptiste Daroussin
> > wrote:
>

[trimming the unneeded pile of commit body]


> >This broke my systems, many filesystems fail to mount causing nullfs
> >late mounts to fail. No details now until tonight.
> >
> >Suggest we back this out until it is properly tested.
>
> Nested zfs filesystems seem not to be handled properly or possibly not
> supported any more. This explains my mail gateway also not mounting all
> filesystems in /home. It was odd that dovecot stopped working.
>
> The symptom of the problem is zfs mount -a no longer mounts all
> filesystems. Zfs mount fails saying the filesystem is already mounted. The
> workaround is to zfs umount each affected zfs dataset by hand and zfs mount
> it by hand.
>
> Generally this has screwed up sites that have hundreds (in my case 122)
> zfs datasets. The work around might be to script testing each mount,
> unmounting and remounting if necessary.
>
> I'm being sarcastic about creating an rc script to clean this up. This
> needs to be backed out and tested properly before being committed.
>
>
I don't know what you mean by "nested zfs filesystems" -- do you mean a
zpool within a zvol?  That has been unsupported for a long time, IIRC.  And
I'm not sure what else "nested filesystems" would be, since having (e.g.)
separate zfs filesystems for /usr and /usr/ports is so common that surely
it has already been tested...

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r339565 - in head: share/man/man4 share/man/man4/man4.i386 sys/conf sys/dev/aha sys/kern sys/modules sys/modules/aha sys/sparc64/conf

[Benjamin Kaduk]

On Sun, Oct 21, 2018 at 9:53 PM Warner Losh  wrote:

>
>
> On Sun, Oct 21, 2018 at 8:47 PM Benjamin Kaduk  wrote:
>
>> On Sun, Oct 21, 2018 at 9:35 PM Warner Losh  wrote:
>>
>>> Author: imp
>>> Date: Mon Oct 22 02:34:25 2018
>>> New Revision: 339565
>>> URL: https://svnweb.freebsd.org/changeset/base/339565
>>>
>>> Log:
>>>   Remove aha(4) from the tree.
>>>
>>>
>> The documentation build is now failing, as there's an entity reference to
>> the autogenerated
>> hardware list, which does not exist anymore.  Will you be able to look at
>> those as part of your
>> removals or does someone from the doc team need to handle it?
>>
>
> I'll take a look. What exactly is failing? The only place I see aha.4 is
> in doc/head/share/xml/man-refs.ent but there's several other drivers that
> have been removed that are in there... So I'm confused and need some
> additional guidance.
>

The build log is mailed out at (e.g.)
https://lists.freebsd.org/pipermail/freebsd-doc/2018-October/031621.html
Though looking slightly more closely, it seems to be complaining about the
12.0 release notes (!), which might both (1) be awkward to solve, and (2)
be in re@'s territory.
(I would not be surprised if it only shows errors for the first couple
problems, in alphabetical order, and there are more issues lingering.)

Thanks,

Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r339565 - in head: share/man/man4 share/man/man4/man4.i386 sys/conf sys/dev/aha sys/kern sys/modules sys/modules/aha sys/sparc64/conf

[Benjamin Kaduk]

On Sun, Oct 21, 2018 at 9:35 PM Warner Losh  wrote:

> Author: imp
> Date: Mon Oct 22 02:34:25 2018
> New Revision: 339565
> URL: https://svnweb.freebsd.org/changeset/base/339565
>
> Log:
>   Remove aha(4) from the tree.
>
>
The documentation build is now failing, as there's an entity reference to
the autogenerated
hardware list, which does not exist anymore.  Will you be able to look at
those as part of your
removals or does someone from the doc team need to handle it?

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r337936 - in head/sys/contrib/libsodium: . builds builds/msvc builds/msvc/build builds/msvc/properties builds/msvc/vs2010 builds/msvc/vs2010/libsodium builds/msvc/vs2012 builds/msvc/vs

[Benjamin Kaduk]

On Fri, Aug 17, 2018 at 11:04 AM, Conrad Meyer  wrote:

> On Thu, Aug 16, 2018 at 10:03 PM, Cy Schubert 
> wrote:
> > In message <201808170023.w7h0np0h027...@repo.freebsd.org>, Conrad Meyer
> > writes:
> >> Author: cem
> >> Date: Fri Aug 17 00:23:50 2018
> >> New Revision: 337936
> >> URL: https://svnweb.freebsd.org/changeset/base/337936
> >>
> >> Log:
> >>   Bring in libsodium to sys/contrib
> >> ...
> >
> > Why wasn't this imported into vendor-sys first? Especially if we intend
> > on tailoring it over time.
>
> We don't intent on tailoring it at all.
>

Sorry, who is "we"?   I did not find any "discussed with" or "reviewed by"
or similar
in the commit message (nor an indication of what intended uses in the base
system
were already known).

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r337535 - head/sbin/init

[Benjamin Kaduk]

On Thu, Aug 9, 2018 at 11:03 AM, Conrad Meyer  wrote:

> On Thu, Aug 9, 2018 at 5:52 AM, Benjamin Kaduk  wrote:
> > On Thu, Aug 9, 2018 at 7:17 AM, Edward Tomasz Napierala <
> tr...@freebsd.org>
> > wrote:
> >>   Use NULLs instead of casted zeroes, for consistency.
> >
> > It's probably helpful to note explicitly that these are not in arguments
> to
> > varargs functions,
>
> I don't think it's helpful.
>
> > in which case the explicit cast is needed in order to produce a program
> that
> > will have
> > correct behavior on all compliant compilers/systems.
>
> Here "compliant" means "minimally compliant to the C standard."  Use
> of NULL in varargs is functionally correct on all FreeBSD systems.
>
> >  (We do define NULL to
> > be a zero-with-cast,
> > but programs
>
> (Ones that care about portability to weird systems.)  I don't think
> BSD's 500 line init — hyper local to FreeBSD — is a strong candidate
> for portability.
>
> > should not assume that NULL will be of pointer type -- "An
> > integer constant
> > expression with the value 0, or such an expression cast to type void *,
> is
> > called a null pointer constant".)
>
> Right.  The problem only arises when both conditions are met:
>
> 1. The system's varargs representation is smaller than the pointer
> representation, and
> 2. The runtime headers do not defined NULL as a pointer-typed value.
> (3. The function being invoked is actually varargs?)
>
> Neither is true on FreeBSD and v7-style init is not a useful place to
> call for portability.
>

I don't really feel a need to continue the discussion that was already
started in response
to  r336835 (in addition to the current thread), so I'll limit myself to
asking whether we
want to be writing standard C or a FreeBSD-specific dialect of C.  My
understanding was
that we had some experience with the latter (e.g., heavy patching of the
compiler) and
it ended up with us in a bad place, which would tend to support writing
standard C or
as close to it as we can.  (Yes, I know that we have non-standard printf
specifiers and the like.)

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r337535 - head/sbin/init

[Benjamin Kaduk]

On Thu, Aug 9, 2018 at 7:17 AM, Edward Tomasz Napierala 
wrote:

> Author: trasz
> Date: Thu Aug  9 12:17:03 2018
> New Revision: 337535
> URL: https://svnweb.freebsd.org/changeset/base/337535
>
> Log:
>   Use NULLs instead of casted zeroes, for consistency.
>

It's probably helpful to note explicitly that these are not in arguments to
varargs functions,
in which case the explicit cast is needed in order to produce a program
that will have
correct behavior on all compliant compilers/systems.  (We do define NULL to
be a zero-with-cast,
but programs should not assume that NULL will be of pointer type -- "An
integer constant
expression with the value 0, or such an expression cast to type void *, is
called a null pointer constant".)

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r335402 - head/sbin/veriexecctl

[Benjamin Kaduk]

On Wed, Jun 20, 2018 at 1:21 AM, Simon J. Gerraty  wrote:

> Conrad Meyer  wrote:
>
> > There's absolutely no reason to use sha1 or ripemd in new designs.
> > These should be removed.
>
> Sorry I disagree - not with ripem (we never supported that or any of the
> non-NIST approved hashes), but sha1 is still approved by NIST for
> firmware integrity checks - which is what this is, and sha1 is cheaper
> than sha256.
>
> As I mentioned in my talk we've included support for sha256 for 10+
> years, but do not plan to drop sha1 until NIST deprecate it for that
> purpose since boot time is a very sensitive subject for us.
>


With all due respect, NIST is hardly the sole authority on this topic.
Over in the IETF, we have the SUIT working group that is even considering
hash-based signatures for firmware updates for post-quantum resistance
(so that devices can be shipped now that have 20-year lifecycles can have
some expectation of retaining the ability to securely take updates over that
lifecycle, admittedly).

With my IETF Security Area Director hat on, any greenfield proposal coming
in
to the IESG that included sha1 support would get extremely strong pushback,
and I don't expect that "reducing boot time" would be seen as sufficiently
compelling.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r334702 - head/sys/sys

[Benjamin Kaduk]

On Wed, Jun 6, 2018 at 6:35 AM, Ravi Pokala  wrote:

> Hi Mateusz,
>
> -Original Message-
> From:  on behalf of Mateusz Guzik
> 
> Date: 2018-06-06, Wednesday at 01:08
> To: , , <
> svn-src-head@freebsd.org>
> Subject: svn commit: r334702 - head/sys/sys
>
> > ...
> >  #ifdef _KERNEL
> >  #define  malloc(size, type, flags) ({
>   \
>
> Now that I'm taking another look at this, I'm confused as to why the
> entire macro expansion is inside parentheses? (The braces make sense, since
> this is a block with local variables which need to be contained.)
>

This is a gcc (and clang) extension to allow the macro body to be a code
block -- standard C gets unhappy with just the curly braces.
https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html is a maybe-relevant
page that google found me.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: Deorbiting i386

[Benjamin Kaduk]

So, when do we get to reprise this thread on -arch instead of svn-src-head?

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r334073 - head

[Benjamin Kaduk]

On Tue, May 22, 2018 at 11:09 PM, Eitan Adler  wrote:

> Author: eadler
> Date: Wed May 23 04:09:01 2018
> New Revision: 334073
> URL: https://svnweb.freebsd.org/changeset/base/334073
>
> Log:
>   README: Reduce the textdump; describe the project
>
>   Rework the README to make it a little easier for new users. This is the
>   first file many will see when persuing the FreeBSD source code so
>
>   - remove some of the text describes how to build. This is better covered
>   in the linked documentation.
>   - add a small blurb for what FreeBSD is. Some users might find this
>   document through features such as github search so they may not even
>   know what the project is
>
>   generally, gear this file for the new, accidental, or casual user rather
>   than towards someone seeking fuller documentation.
>
> Modified:
>   head/README
>   head/README.md
>

Changes to "the first file many will see when perusing the FreeBSD source
code" seem like something sufficiently impactful that pre-commit review
and/or
consultation with other committers would be advised.

(That said, these changes do seem reasonable, on a quick read.)

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r333306 - head/usr.bin/fetch

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Sun May  6 15:59:03 2018
New Revision: 06
URL: https://svnweb.freebsd.org/changeset/base/06

Log:
  Fix spelling of --output long option in fetch.1
  
  PR:   228017
  Reported by:  rff1...@yahoo.com

Modified:
  head/usr.bin/fetch/fetch.1

Modified: head/usr.bin/fetch/fetch.1
==
--- head/usr.bin/fetch/fetch.1  Sun May  6 14:37:11 2018(r05)
+++ head/usr.bin/fetch/fetch.1  Sun May  6 15:59:03 2018(r06)
@@ -30,7 +30,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd March 18, 2016
+.Dd May 6, 2018
 .Dt FETCH 1
 .Os
 .Sh NAME
@@ -241,7 +241,7 @@ certificate presented by the server.
 .It Fl -no-verify-peer
 [SSL]
 Do not verify the peer certificate against trusted CAs.
-.It Fl o Ar file , Fl output= Ns Ar file
+.It Fl o Ar file , Fl -output= Ns Ar file
 Set the output file name to
 .Ar file .
 By default, a ``pathname'' is extracted from the specified URI, and
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r332512 - head/sys/conf

[Benjamin Kaduk]

On Sun, Apr 15, 2018 at 10:13 AM, Brooks Davis  wrote:

> On Sun, Apr 15, 2018 at 03:06:07PM +, Brooks Davis wrote:
> > Author: brooks
> > Date: Sun Apr 15 15:06:07 2018
> > New Revision: 332512
> > URL: https://svnweb.freebsd.org/changeset/base/332512
> >
> > Log:
> >   Remove device cm which was removed in r332490.
>
> I'm quite confused by the fact that tinderbox didn't trip on this when I
> ran it.  Are -DNO_CLEAN tinderbox builds insufficent for device removal?
>

Given that they would leave around the old object files needed to resolve
stale
references to removed driver components, it seems likely.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r331892 - head/share/man/man4

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Mon Apr  2 22:59:33 2018
New Revision: 331892
URL: https://svnweb.freebsd.org/changeset/base/331892

Log:
  Fix formatting in snd_hda.4
  
  Submitted by: 0mp
  Reviewed by:  skreuzer
  Differential Revision:https://reviews.freebsd.org/D14922

Modified:
  head/share/man/man4/snd_hda.4

Modified: head/share/man/man4/snd_hda.4
==
--- head/share/man/man4/snd_hda.4   Mon Apr  2 22:16:19 2018
(r331891)
+++ head/share/man/man4/snd_hda.4   Mon Apr  2 22:59:33 2018
(r331892)
@@ -25,7 +25,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd January 25, 2012
+.Dd April 1, 2018
 .Dt SND_HDA 4
 .Os
 .Sh NAME
@@ -564,7 +564,7 @@ input mix
 first external or second internal microphone input
 .It Va monitor
 first internal or second external microphone input
-.It Va line , Va line1 , Va line2, Va line3
+.It Va line , Va line1 , Va line2 , Va line3
 analog (line) inputs
 .It Va dig1 , Va dig2 , Va dig3
 digital (S/PDIF, HDMI or DisplayPort) inputs
@@ -572,7 +572,7 @@ digital (S/PDIF, HDMI or DisplayPort) inputs
 CD input
 .It Va speaker
 PC speaker input
-.It Va phin , Va phout , Va radio . Va video
+.It Va phin , Va phout , Va radio , Va video
 other random inputs
 .El
 .Pp
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r331618 - head/share/man/man7

[Benjamin Kaduk]

On Tue, Mar 27, 2018 at 9:57 AM, Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:

> > Author: trasz
> > Date: Tue Mar 27 14:51:19 2018
> > New Revision: 331618
> > URL: https://svnweb.freebsd.org/changeset/base/331618
> >
> > Log:
> >   Use https:// instead of http://.
> >
> >   MFC after:  2 weeks
> >
> > Modified:
> >   head/share/man/man7/development.7
> >
> > Modified: head/share/man/man7/development.7
> > 
> ==
> > --- head/share/man/man7/development.7 Tue Mar 27 14:50:12 2018
> (r331617)
> > +++ head/share/man/man7/development.7 Tue Mar 27 14:51:19 2018
> (r331618)
> > @@ -57,7 +57,7 @@ can be found at:
> >  FreeBSD src development takes place in the CURRENT branch in Subversion,
> >  located at:
> >  .Pp
> > -.Lk http://svn.FreeBSD.org/base/head
> > +.Lk https://svn.FreeBSD.org/base/head
> >  .Pp
> >  There is also a read-only GitHub mirror at:
> >  .Pp
>
> Why do we want to run the load of TLS for what are public bits?
> And fyi a default install of FreeBSD can not use https, you have
> to install certs from ports before any of these https links
> can even work, and that can be a royal pita in some situations.
>

Many of us are used to thinking of the network as controlled by an attacker.
Running http-not-s to fetch the sources lets "the attacker" supply an
arbitrary
collection of bits under the name FreeBSD without a good way for the user to
check that the bits on their disk match what the FreeBSD Project expects
them to be.
TLS provides data integrity as well as confidentiality...

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r331510 - in head: share/man/man4 sys/conf sys/dev/vmware/vmci sys/modules/vmware sys/modules/vmware/vmci

[Benjamin Kaduk]

I am surprised that no one has yet quoted the commit message from r325966
when the first SPDX tags appear to have been added to base:

  We are gradually adopting the specification, noting
  that the tags are considered only advisory and do not, in any way,
  superceed or replace the license texts.

(There was also some internal discussion around the same time, which I of
course cannot quote here.)

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r330602 - head/sys/compat/cloudabi

[Benjamin Kaduk]

On Wed, Mar 7, 2018 at 9:44 AM, Ed Maste  wrote:

> On 7 March 2018 at 09:47, Eitan Adler  wrote:
> > Author: eadler
> > Date: Wed Mar  7 14:47:43 2018
> > New Revision: 330602
> > URL: https://svnweb.freebsd.org/changeset/base/330602
> >
> > Log:
> >   sys/cloudabi: Avoid relying on GNU specific extensions
> >
> >   An empty initializer list is not technically valid C grammar.
> >
> >   MFC After:1 week
> >
> > -   cloudabi_fdstat_t fsb = {};
> > +   cloudabi_fdstat_t fsb = {0};
>
> In practice it appears initializing via { 0 } also zeros any padding
> in the struct, but I do not believe it's required by the C standard.
> Perhaps a language lawyer can weigh in?
>
> Commenting on this commit just because it's highlighted by this
> change; I do not believe there's a difference between the GNU
> extension { } and { 0 } here.
>
>
The C spec says that if an incomplete initializer is given, then all other
fields
of the structure are initialized to zero.  The state of padding is
unspecified,
whether a complete or incomplete initializer is given.

The "issue" being "fixed" here is that the formal C grammar does not
admit a totally empty initializer, so at least one element of the
initializer
needs to be given in order to satisfy the grammar.  This is pretty silly,
and the extension to allow a totally empty initializer a quite natural one
to make.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r328159 - head/sys/modules

[Benjamin Kaduk]

On Thu, Jan 18, 2018 at 10:49 PM, Conrad Meyer  wrote:

> No.  It is the only logical result of a logical right shift larger
> than the left operand.  The C standard may claim that is undefined,
> but that does not change the only logical result (zero).
>
>
My point is that the compiler does not arbitrarily decide that this
behavior merits
a warning; the compiler is thoroughly grounded in the C language
specification
to do so.  The compiler does not adhere to our human standard of "logic";
it follows
the language spec, warts and all.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r328159 - head/sys/modules

[Benjamin Kaduk]

On Thu, Jan 18, 2018 at 10:34 PM, Conrad Meyer  wrote:

> Author: cem
> Date: Fri Jan 19 04:34:06 2018
> New Revision: 328159
> URL: https://svnweb.freebsd.org/changeset/base/328159
>
> Log:
>   Unbreak i386 build
>
>   The logical result of a right shift >= the width of a type is zero, but
> our
>   compiler decides this is a warning (and thus, error).  Just remove ccp(4)
>   from i386.
>

That may seem like the logical result, but this is actually undefined
behavior.  Per n1256.pdf, section 6.5.7:

The integer promotions are performed on each of the operands. The type of
the result is that of the promoted left operand. If the value of the right
operand is negative or is greater than or equal to the width of the
promoted left operand, the behavior is undefined.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r326651 - in head/bin: cat date kenv setfacl sh

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Thu Dec  7 01:57:27 2017
New Revision: 326651
URL: https://svnweb.freebsd.org/changeset/base/326651

Log:
  Fix mandoc -Tlint warnings in bin/
  
  Many style-level issues are still reported.
  
  Submitted by: Yuri Pankov 
  Reviewed by:  jilles (previous revision)
  Differential Revision:https://reviews.freebsd.org/D13334

Modified:
  head/bin/cat/cat.1
  head/bin/date/date.1
  head/bin/kenv/kenv.1
  head/bin/setfacl/setfacl.1
  head/bin/sh/sh.1

Modified: head/bin/cat/cat.1
==
--- head/bin/cat/cat.1  Thu Dec  7 01:50:17 2017(r326650)
+++ head/bin/cat/cat.1  Thu Dec  7 01:57:27 2017(r326651)
@@ -195,8 +195,8 @@ utility appeared in
 .At v1 .
 .An Dennis Ritchie
 designed and wrote the first man page.
-It appears to have been
-.Xr cat 1 .
+It appears to have been for
+.Nm .
 .Sh BUGS
 Because of the shell language mechanism used to perform output
 redirection, the command

Modified: head/bin/date/date.1
==
--- head/bin/date/date.1Thu Dec  7 01:50:17 2017(r326650)
+++ head/bin/date/date.1Thu Dec  7 01:57:27 2017(r326651)
@@ -131,7 +131,8 @@ The
 option suppresses this behavior and causes the time to be set only on the
 current machine.
 .It Fl R
-Use RFC 2822 date and time output format. This is equivalent to use
+Use RFC 2822 date and time output format.
+This is equivalent to using
 .Dq Li %a, %d %b %Y \&%T %z
 as
 .Ar output_fmt

Modified: head/bin/kenv/kenv.1
==
--- head/bin/kenv/kenv.1Thu Dec  7 01:50:17 2017(r326650)
+++ head/bin/kenv/kenv.1Thu Dec  7 01:57:27 2017(r326651)
@@ -91,11 +91,17 @@ The file can contain lines of the form
 .Pp
 .Dl name = "value"  # this is a comment
 .Pp
-where whitespace around name and '=', and
-everything after a '#' character, are ignored.  Almost any printable
-character except '=' is acceptable as part of a name.  Quotes
-are optional and necessary only if the value contains
-whitespace.
+where whitespace around
+.Sq name
+and
+.Sq = ,
+and everything after a
+.Sq #
+character, are ignored.
+Almost any printable character except
+.Sq =
+is acceptable as part of a name.
+Quotes are optional and necessary only if the value contains whitespace.
 .Sh SEE ALSO
 .Xr kenv 2 ,
 .Xr config 5 ,

Modified: head/bin/setfacl/setfacl.1
==
--- head/bin/setfacl/setfacl.1  Thu Dec  7 01:50:17 2017(r326650)
+++ head/bin/setfacl/setfacl.1  Thu Dec  7 01:57:27 2017(r326651)
@@ -114,7 +114,8 @@ is
 the input is taken from stdin.
 .It Fl n
 Do not recalculate the permissions associated with the ACL
-mask entry.  This option is not applicable to NFSv4 ACLs.
+mask entry.
+This option is not applicable to NFSv4 ACLs.
 .It Fl x Ar entries | position
 If
 .Ar entries
@@ -291,7 +292,8 @@ specifying the access granted to the owner of the file
 .Dq Li group@
 specifying the access granted to the file owning group;
 .Dq Li everyone@
-specifying everyone.  Note that
+specifying everyone.
+Note that
 .Dq Li everyone@
 is not the same as traditional Unix
 .Dq Li other
@@ -301,8 +303,8 @@ literally, everyone, including file owner and owning g
 The ACL qualifier field describes the user or group associated with
 the ACL entry.
 It may consist of one of the following: uid or
-user name, or gid or group name.  In entries whose tag type is
-one of
+user name, or gid or group name.
+In entries whose tag type is one of
 .Dq Li owner@ ,
 .Dq Li group@ ,
 or

Modified: head/bin/sh/sh.1
==
--- head/bin/sh/sh.1Thu Dec  7 01:50:17 2017(r326650)
+++ head/bin/sh/sh.1Thu Dec  7 01:57:27 2017(r326651)
@@ -1033,7 +1033,7 @@ The syntax of the
 command is:
 .Bd -unfilled -offset indent -compact
 .Ic case Ar word Ic in
-.Ar pattern Ns ) Ar list Li ;;
+.Ar pattern ) Ar list Li ;;
 .Ar ...
 .Ic esac
 .Ed
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r326650 - head/lib/libc/sys

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Thu Dec  7 01:50:17 2017
New Revision: 326650
URL: https://svnweb.freebsd.org/changeset/base/326650

Log:
  Note that old sys/event.h required manual sys/types.h inclusion
  
  ed fixed this in r313704 but older versions are still affected.

Modified:
  head/lib/libc/sys/kqueue.2

Modified: head/lib/libc/sys/kqueue.2
==
--- head/lib/libc/sys/kqueue.2  Thu Dec  7 01:49:35 2017(r326649)
+++ head/lib/libc/sys/kqueue.2  Thu Dec  7 01:50:17 2017(r326650)
@@ -782,8 +782,9 @@ The
 value is limited to 24 hours; longer timeouts will be silently
 reinterpreted as 24 hours.
 .Pp
-Previous versions of
+In versions older than 
+.Fx 12.0 ,
 .In sys/event.h
-fail to parse without including
+failed to parse without including
 .In sys/types.h
 manually.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326039 - in head: etc/mtree usr.bin/head usr.bin/head/tests

[Benjamin Kaduk]

On Mon, Nov 20, 2017 at 7:36 PM, Alan Somers  wrote:
>
>
> Are there any automated tools that care about the "Differential
> Revision" field?  If so, they should be able to tell the difference
> between GitHub revisions and Phabricator revisions based on the URL.
>


Yes, Phabricator itself uses the link to close out the review.



> Using "Differential Revision" instead of "Pull request" is handy,
> because it's part of the standard commit template, which encourages
> consistency.
>

As Warner says, we could just add a new thing to the template instead
of overloading an existing one for convenience.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r318751 - in head/sys: kern sys

[Benjamin Kaduk]

On Mon, Oct 23, 2017 at 8:31 AM, Steve Wills  wrote:

>
> Note too that security.bsd.see_jail_proc is partially a work around for
> the fact that security.bsd.see_other_* doesn't work as you might expect.
> It's literally the UID/GID, rather than the username, so
> security.bsd.see_other_* has no idea that the users in the jail are not the
> same users on the host, which is unexpected and counter-intuitive at best
> and dangerous at worst. (Even if that were changed,
> security.bsd.see_jail_proc is still useful for the potential scenario where
> you don't want/need to set security.bsd.see_other_* but don't want users to
> see processes in jails.)


security.bsd.see_other_* cannot do anything *but* UID/GID -- note that it
is supported to have multiple user entries on a single system that share a
UID, and the username used to log in is not tracked by the kernel.  (E.g.,
root and toor.)

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r324732 - head/usr.sbin/jail

[Benjamin Kaduk]

That's a fair point.  I didn't want Steve's report to get lost on the
mailing list but didn't have time to look very hard yesterday, so I
just put something quick in (as the old verison is obviously wrong).

There's also some mandoc -Tling nits reported in this page, so hopefully
I'll get some time to make further improvements this weekend.  Unless you
wanted to fix it yourself?

Thanks,

Ben

On Wed, Oct 18, 2017 at 09:12:02PM -0700, Nathan Whitehorn wrote:
> Is this even true? Don't you want to run bsdconfig? We split that 
> functionality out from the installer when sysinstall was replaced.
> -Nathan
> 
> On 10/18/17 15:56, Benjamin Kaduk wrote:
> > Author: bjk (doc committer)
> > Date: Wed Oct 18 22:56:46 2017
> > New Revision: 324732
> > URL: https://svnweb.freebsd.org/changeset/base/324732
> >
> > Log:
> >Adopt jail.8 to our brave new bsdinstall world
> >
> >Submitted by:Steve Kargl
> >MFC after:   3 days
> >
> > Modified:
> >head/usr.sbin/jail/jail.8
> >
> > Modified: head/usr.sbin/jail/jail.8
> > ==
> > --- head/usr.sbin/jail/jail.8   Wed Oct 18 22:00:44 2017
> > (r324731)
> > +++ head/usr.sbin/jail/jail.8   Wed Oct 18 22:56:46 2017
> > (r324732)
> > @@ -1006,7 +1006,7 @@ jail -c path=/data/jail/testjail mount.devfs \\
> >   .Pp
> >   Assuming no errors, you will end up with a shell prompt within the jail.
> >   You can now run
> > -.Pa /usr/sbin/sysinstall
> > +.Pa /usr/sbin/bsdinstall
> >   and do the post-install configuration to set various configuration 
> > options,
> >   or perform these actions manually by editing
> >   .Pa /etc/rc.conf ,
> >
> 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r324732 - head/usr.sbin/jail

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Wed Oct 18 22:56:46 2017
New Revision: 324732
URL: https://svnweb.freebsd.org/changeset/base/324732

Log:
  Adopt jail.8 to our brave new bsdinstall world
  
  Submitted by: Steve Kargl
  MFC after:3 days

Modified:
  head/usr.sbin/jail/jail.8

Modified: head/usr.sbin/jail/jail.8
==
--- head/usr.sbin/jail/jail.8   Wed Oct 18 22:00:44 2017(r324731)
+++ head/usr.sbin/jail/jail.8   Wed Oct 18 22:56:46 2017(r324732)
@@ -1006,7 +1006,7 @@ jail -c path=/data/jail/testjail mount.devfs \\
 .Pp
 Assuming no errors, you will end up with a shell prompt within the jail.
 You can now run
-.Pa /usr/sbin/sysinstall
+.Pa /usr/sbin/bsdinstall
 and do the post-install configuration to set various configuration options,
 or perform these actions manually by editing
 .Pa /etc/rc.conf ,
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r324458 - head/share/man/man4

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Tue Oct 10 00:26:44 2017
New Revision: 324458
URL: https://svnweb.freebsd.org/changeset/base/324458

Log:
  Add Asus USB-N13, rev. B1 to the rtwn_usb hardware list
  
  Reported by:  Patrik Horst 

Modified:
  head/share/man/man4/rtwn_usb.4

Modified: head/share/man/man4/rtwn_usb.4
==
--- head/share/man/man4/rtwn_usb.4  Mon Oct  9 22:27:38 2017
(r324457)
+++ head/share/man/man4/rtwn_usb.4  Tue Oct 10 00:26:44 2017
(r324458)
@@ -29,7 +29,7 @@
 .\"
 .\" $FreeBSD$
 .\"/
-.Dd January 24, 2017
+.Dd October 9, 2017
 .Dt RTWN_USB 4
 .Os
 .Sh NAME
@@ -64,6 +64,7 @@ based USB wireless network adapters, including:
 .It "Alfa AWUS036NHR v2" Ta USB 2.0
 .It "ASUS USB-AC56" Ta USB 3.0
 .It "ASUS USB-N10 NANO" Ta USB 2.0
+.It "Asus USB-N13, rev. B1" Ta USB 2.0
 .It "Belkin F7D1102 Surf Wireless Micro" Ta USB 2.0
 .It "Buffalo WI-U2-433DM" Ta USB 2.0
 .It "Buffalo WI-U3-866D" Ta USB 3.0
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r324249 - head/lib/libc/net

[Benjamin Kaduk]

On Wed, Oct 4, 2017 at 10:10 AM, Ngie Cooper  wrote:

>
> > On Oct 3, 2017, at 23:06, Cy Schubert  wrote:
> >
> > @@ -189,19 +189,18 @@ function
> > may be used to request the use of a connected
> > .Tn TCP
> > socket for queries.
> > -If the
> > +Queries will by defaulat use
> > +.Tn UDP
> > +datagrams. If the
>
> manlint: new sentences must start on new lines.
>

See  r324277.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r324277 - head/lib/libc/net

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Wed Oct  4 12:58:30 2017
New Revision: 324277
URL: https://svnweb.freebsd.org/changeset/base/324277

Log:
  mdoc style: start new sentence on new line

Modified:
  head/lib/libc/net/gethostbyname.3

Modified: head/lib/libc/net/gethostbyname.3
==
--- head/lib/libc/net/gethostbyname.3   Wed Oct  4 12:25:39 2017
(r324276)
+++ head/lib/libc/net/gethostbyname.3   Wed Oct  4 12:58:30 2017
(r324277)
@@ -191,11 +191,13 @@ may be used to request the use of a connected
 socket for queries.
 Queries will by default use
 .Tn UDP
-datagrams. If the
+datagrams.
+If the
 .Fa stayopen
 flag is non-zero, a
 .Tn TCP
-connection to the name server will be used. It will remain open after calls to
+connection to the name server will be used.
+It will remain open after calls to
 .Fn gethostbyname ,
 .Fn gethostbyname2
 or
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r323122 - head/usr.sbin/autofs

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Fri Sep  1 22:04:45 2017
New Revision: 323122
URL: https://svnweb.freebsd.org/changeset/base/323122

Log:
  Fix mdoc typo in auto_master.5
  
  There needs to be a space after the no-space macro in order for it
  to be interpreted.
  
  PR:   221986
  Submitted by: Paul Townsend 

Modified:
  head/usr.sbin/autofs/auto_master.5

Modified: head/usr.sbin/autofs/auto_master.5
==
--- head/usr.sbin/autofs/auto_master.5  Fri Sep  1 21:48:36 2017
(r323121)
+++ head/usr.sbin/autofs/auto_master.5  Fri Sep  1 22:04:45 2017
(r323122)
@@ -253,7 +253,7 @@ Query the remote NFS server and map exported shares.
 This map is traditionally mounted on
 .Pa /net .
 Access to files on a remote NFS server is provided through the
-.Pf /net/ Ar nfs-server-ip Ns / Ns Ar share-name Ns/
+.Pf /net/ Ar nfs-server-ip Ns / Ns Ar share-name Ns /
 directory without any additional configuration.
 Directories for individual NFS servers are not present until the first access,
 when they are automatically created.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r318699 - head/lib/libc/gen

[Benjamin Kaduk]

On Tue, May 23, 2017 at 1:55 AM, Ngie Cooper  wrote:

> Author: ngie
> Date: Tue May 23 06:55:51 2017
> New Revision: 318699
> URL: https://svnweb.freebsd.org/changeset/base/318699
>
> Log:
>   directory(3): delete trailing whitespace and rewrite `E.g.` as `e.g.`
>

 FWIW, it is better-still written as "e.g.,", i.e., with trailing comma as
well as leading comma.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r318643 - head/usr.sbin/efivar

[Benjamin Kaduk]

On Mon, May 22, 2017 at 8:56 AM, Glen Barber  wrote:

> Author: gjb
> Date: Mon May 22 13:55:59 2017
> New Revision: 318643
> URL: https://svnweb.freebsd.org/changeset/base/318643
>
> Log:
>   Correct the "first appeared in" version for efivar(8).
>

Hmm, I guess I should have put an MFC note for r318599, then.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r318599 - head/usr.sbin/efivar

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Sun May 21 22:10:08 2017
New Revision: 318599
URL: https://svnweb.freebsd.org/changeset/base/318599

Log:
  Updates for efivar.8
  
  Fix spelling [1], appease igor and mandoc -Tlint, and adopt the
  language style to be more consistent with our corpus.
  
  PR:   219434 [1]
  Submitted by: olgeni [1]

Modified:
  head/usr.sbin/efivar/efivar.8

Modified: head/usr.sbin/efivar/efivar.8
==
--- head/usr.sbin/efivar/efivar.8   Sun May 21 21:33:15 2017
(r318598)
+++ head/usr.sbin/efivar/efivar.8   Sun May 21 22:10:08 2017
(r318599)
@@ -24,12 +24,12 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd March 4, 2017
+.Dd May 21, 2017
 .Dt EFIVAR 8
 .Os
 .Sh NAME
 .Nm efivar
-.Nd UEFI environemnt variable interaction
+.Nd UEFI environment variable interaction
 .Sh SYNOPSIS
 .Nm
 .Op Fl abdDHlLNpRtw
@@ -58,7 +58,7 @@ This program manages
 .Pq UEFI
 environment variables.
 UEFI variables have three part: A namespace, a name and a value.
-The namespace is a GUID that's self assigned by the group defining the
+The namespace is a GUID that is self assigned by the group defining the
 variables.
 The name is a Unicode name for the variable.
 The value is binary data.
@@ -70,7 +70,7 @@ The following options are available:
 Specify the name of the variable to operate on.
 The
 .Ar name
-argument is the GUID of variable, followed by a dash, followed by the
+argument is the GUID of the variable, followed by a dash, followed by the
 UEFI variable name.
 The GUID may be in numeric format, or may be one of the well known
 symbolic name (see
@@ -86,19 +86,19 @@ This flag implies
 unless the
 .Fl -append
 flag is given.
-This is not well understood and currently unimplemented.
+This behavior is not well understood and is currently unimplemented.
 .It Fl a Fl -append
 Append the specified value to the UEFI variable rather than replacing
-it.p
+it.
 .It Fl t Ar attr Fl -attributes Ar attr
-Specify, in user hostile hexidecimal, the attributes for this
+Specify, in hexadecimal, the attributes for this
 variable.
 See section 7.2 (GetVariable subsection, Related Definitions) of the
 UEFI Specification for hex values to use.
 .It Fl A Fl -ascii
 Display the variable data as modified ascii: All printable characters
 are printed, while unprintable characters are rendered as a two-digit
-hexadecimal number preceeded by a % character.
+hexadecimal number preceded by a % character.
 .It Fl b Fl -binary
 Display the variable data as binary data.
 Usually will be used with the
@@ -155,29 +155,27 @@ can be used to specify simple strings.
 Display the
 .Ar name
 environment variable.
+.El
 .Sh COMPATIBILITY
 The
 .Nm
-program is intended to be compatible (strict superset) with a progam
-of the same name included in the Red Hat libefivar package.
-.Pp
-Except the
+program is intended to be compatible (strict superset) with a program
+of the same name included in the Red Hat libefivar package,
+but the
 .Fl d
 and
 .Fl -print-decimal
-flags are not implmenented and never will be.
+flags are not implemented and never will be.
+.Pp
 The
 .Fl d
-flag is a short-hand for
+flag is short for
 .Fl -device-path .
 .Sh SEE ALSO
 Appendix A of the UEFI specification has the format for GUIDs.
 All GUIDs
 .Dq Globally Unique Identifiers
 have the format described in RFC 4122.
-.El
-.Pp
-.Xr efivar 8
 .Sh HISTORY
 The
 .Nm
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r305177 - head/sys/net

[Benjamin Kaduk]

On Thu, May 18, 2017 at 10:00 AM, Oleg Bulyzhin  wrote:

> On Thu, May 18, 2017 at 04:25:01PM +0200, Hans Petter Selasky wrote:
> >
> > Can you explain a bit more what is wrong?
> >
> > > If you care about readability it should be:
> > > pri) & 7) << 13) | (((cfi) & 1) << 12) | ((vlid) & EVL_VLID_MASK))
> >
> > Isn't this exactly what the patch is doing? -R ???
>
> Current version is shifting pri out of uint16. If you examine parentheses:
> pri is shifted left 13, then 12.
> Original version did it right (shift 1, then 12 (total 13)).
>

Calculations in the C abstract machine would be performed in the 'int' type
to which uint16 operands are promoted, though.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r317910 - head/share/man/man9

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Sun May  7 19:01:08 2017
New Revision: 317910
URL: https://svnweb.freebsd.org/changeset/base/317910

Log:
  Bring VOP_GETPAGES.9 more up-to-date
  
  Attempt to catch up to the KPI changes from r292373, and perform
  some other tidying while in the area.
  
  Reviewed by:  kib
  Differential Revision:https://reviews.freebsd.org/D10579

Modified:
  head/share/man/man9/VOP_GETPAGES.9

Modified: head/share/man/man9/VOP_GETPAGES.9
==
--- head/share/man/man9/VOP_GETPAGES.9  Sun May  7 17:21:22 2017
(r317909)
+++ head/share/man/man9/VOP_GETPAGES.9  Sun May  7 19:01:08 2017
(r317910)
@@ -29,7 +29,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd December 16, 2015
+.Dd May 7, 2017
 .Dt VOP_GETPAGES 9
 .Os
 .Sh NAME
@@ -41,9 +41,21 @@
 .In sys/vnode.h
 .In vm/vm.h
 .Ft int
-.Fn VOP_GETPAGES "struct vnode *vp" "vm_page_t *ma" "int count" "int *rbehind" 
"int *rahead"
+.Fo VOP_GETPAGES
+.Fa "struct vnode *vp"
+.Fa "vm_page_t *ma"
+.Fa "int count"
+.Fa "int *rbehind"
+.Fa "int *rahead"
+.Fc
 .Ft int
-.Fn VOP_PUTPAGES "struct vnode *vp" "vm_page_t *ma" "int count" "int sync" 
"int *rtvals"
+.Fo VOP_PUTPAGES
+.Fa "struct vnode *vp"
+.Fa "vm_page_t *ma"
+.Fa "int bytecount"
+.Fa "int flags"
+.Fa "int *rtvals"
+.Fc
 .Sh DESCRIPTION
 The
 .Fn VOP_GETPAGES
@@ -70,10 +82,32 @@ The file to access.
 Pointer to the first element of an array of pages representing a
 contiguous region of the file to be read or written.
 .It Fa count
-The number of bytes that should be read into the pages of the array.
-.It Fa sync
+The length of the
+.Fa ma
+array.
+.It Fa bytecount
+The number of bytes that should be written from the pages of the array.
+.It Fa flags
+A bitfield of flags affecting the function operation.
+If
 .Dv VM_PAGER_PUT_SYNC
-if the write should be synchronous.
+is set, the write should be synchronous; control must not be returned
+to the caller until after the write is finished.
+If
+.Dv VM_PAGER_PUT_INVAL
+is set, the pages are to be invalidated after being written.
+If
+.Dv VM_PAGER_PUT_NOREUSE
+is set, the I/O performed should set the IO_NOREUSE flag, to indicate
+to the filesystem that pages should be marked for fast reuse if needed.
+This could occur via a call to
+.Xr vm_page_deactivate_noreuse 9 ,
+which puts such pages onto the head of the inactive queue.
+If
+.Dv VM_PAGER_CLUSTER_OK
+is set, writes may be performed asynchronously, so that related writes
+can be coalesced for efficiency, e.g.,
+using the clustering mechanism of the buffer cache.
 .It Fa rtvals
 An array of VM system result codes indicating the status of each
 page written by
@@ -127,32 +161,33 @@ The page was not handled by this request
 .Pp
 The
 .Fn VOP_GETPAGES
-method is expected to release any pages in
+method must populate and validate all requested pages in order to
+return success.
+It is expected to release any pages in
 .Fa ma
 that it does not successfully handle, by calling
 .Xr vm_page_free 9 .
 When it succeeds,
 .Fn VOP_GETPAGES
 must set the valid bits appropriately.
+Upon entry to
+.Fn VOP_GETPAGES ,
+all pages in
+.Fa ma
+are busied exclusively.
+Upon successful return, the pages must all be busied exclusively
+as well, but pages may be unbusied during processing.
+The filesystem is responsible for activating paged-out pages, but this
+does not necessarily need to be done within
 .Fn VOP_GETPAGES
-must keep
-.Fa reqpage
-busy.
-It must unbusy all other successfully handled pages and put them
-on appropriate page queue(s).
-For example,
-.Fn VOP_GETPAGES
-may either activate a page (if its wanted bit is set)
-or deactivate it (otherwise), and finally call
-.Xr vm_page_xunbusy 9
-to arouse any threads currently waiting for the page to be faulted in.
+depending on the architecture of the particular filesystem.
 .Sh RETURN VALUES
-If it successfully reads
-.Fa ma[reqpage] ,
+If it successfully reads all pages in
+.Fa ma ,
 .Fn VOP_GETPAGES
 returns
 .Dv VM_PAGER_OK ;
-otherwise,
+otherwise, it returns
 .Dv VM_PAGER_ERROR .
 By convention, the return value of
 .Fn VOP_PUTPAGES
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r317809 - head/share/man/man7

[Benjamin Kaduk]

On Fri, May 5, 2017 at 8:39 AM, Bruce Evans  wrote:

> On Fri, 5 May 2017, Konstantin Belousov wrote:
>
>
>> So the phrase is correct, and the below reformulation really removes the
>> content.
>>
>
> "integrity" isn't correct since it has nothing to do with integers.
> "mechanisms" doesn't make much sens either.  Use the standard term
> "representation".


No, "integrity" is correct; CHERI provides integrity protection for
pointers to ensure
that they do not get modified in unpermitted ways.  Nothing to do with
representation
as integers, linguistically.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r317409 - head/contrib/tcpdump

[Benjamin Kaduk]

On Tue, Apr 25, 2017 at 3:28 PM, John Baldwin  wrote:

>
> I do think that when referring to a Git hash the citation should also
> include
> something to identify which repository it came from.  It doesn't have to
> be a
> URL per se (we just use 'NetBSD' for makefs, not a full URL to NetBSD's
> cvsweb), but it should be clear enough that one can find the corresponding
> repository.  Probably that information belongs in 'Obtained From'.
>

Since Rodney asked and I already have the svn log up, here are some existing
commits that are doing similar sorts of things:
r317267 is typical of the illumos/ZFS imports
though sometimes a full github URL is used, as in r316695
r316665 pulls from Concurrency Kit (I think; CK was not expanded in the
commit message :( )
r315947 from libcxxrt
r315926 and a few previous revisions from dragonflybsd.git
r315745 from libcxxrt
r314435 again from CK

and we're not even out of 2017 yet.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r317409 - head/contrib/tcpdump

[Benjamin Kaduk]

On Tue, Apr 25, 2017 at 2:07 PM, Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:

> [ Charset UTF-8 unsupported, converting... ]
> >
> > On the contrary, a git SHA1 seems like an eminently stable and unique
> > search parameter!
> > I agree that a commit log should inline some summary of the change as
> well
> > as provide a
> > link to the external source, but I am not worried that a future reader
> will
> > be unable to find
> > the referenced commit.
>
> There is no administrative policy in place that says github users shall
> maintain there history.
>
>
That is correct.  Nor should there be!

(However, even if they change their history, the direct link to a commit
will still work,
due to the way the github implementation works -- you have to delete and
recreate
a repository in order to fully expunge a commit.)

I don't expect the previous parenthetical to provide any persuasive value,
of course,
as you have to know where to look before it's useful.  But, right now there
are some
300-odd forks of tcpdump on github, no doubt including Gleb.  If
the-tcpdump-group
goes away, there's a lot of backups, not just in github forks but also the
local clones
of people using github.  Do you really think that the collapse of such a
prominent
project would leave an unarchived void?  I don't understand what scenario
you're trying
to protect against, basically.


> I had too many indirections to find this change on github:
> commitlog -> google -> wrong article that references this sha1 -> actual
> commit
>
> I re-iterate lets NOT start to use git hashes in our commit messages.
>

I'm sorry, but I must continue to oppose this sentiment.  I would prefer a
full
(github or otherwise) URL including the commit hash to just a bare commit
hash,
but find either acceptable and adequate for the purpose.  (FWIW, the
correct commit
was the top google hit for me.)

I hope we are in agreement that commit messages ought to still include some
description of what change is being brought in, in addition to the
hash/link, though.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r317409 - head/contrib/tcpdump

[Benjamin Kaduk]

On Tue, Apr 25, 2017 at 1:30 PM, Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:

> [ Charset UTF-8 unsupported, converting... ]
> > Author: glebius
> > Date: Tue Apr 25 15:56:46 2017
> > New Revision: 317409
> > URL: https://svnweb.freebsd.org/changeset/base/317409
> >
> > Log:
> >   Cherry-pick 5d3c5151c2b885aab36627bafb8539238da27b2d, it fixes use
> after free
>
> Lets not use git hashes as references in commit messages,
> it has very little value for someone reading a log of changes
> looking for something.  There is no promise that it can be
> found later (github can go Poof).
>

On the contrary, a git SHA1 seems like an eminently stable and unique
search parameter!
I agree that a commit log should inline some summary of the change as well
as provide a
link to the external source, but I am not worried that a future reader will
be unable to find
the referenced commit.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r315528 - in head/share/man: man5 man9

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Sun Mar 19 01:24:18 2017
New Revision: 315528
URL: https://svnweb.freebsd.org/changeset/base/315528

Log:
  Tidy up mdoc formatting for "etc.)" at end of line
  
  man(1) has some logic to use two spaces after a full stop, which is
  useful for spotting sentence breaks in monospace fonts.  However,
  this logic is very simple, treating almost all '.' characters as
  end-of-sentence markers, unless followed by certain other
  characters.  For example, '.,' is not end-of-sentence, and neither
  is ".) ", but ".)" at the end of a line triggers the sentence-end
  detection.
  
  Apply a zero-width space to a few instances of this in share/man,
  and also supply a missing full stop for an instance that occurred at
  the end of a sentence.
  
  Leave untouched several instances that are at the end of a sentence
  or list element.
  
  Reported by:  0mp (ieee80211.9)

Modified:
  head/share/man/man5/stab.5
  head/share/man/man9/ieee80211.9
  head/share/man/man9/ieee80211_vap.9
  head/share/man/man9/taskqueue.9
  head/share/man/man9/vnode.9

Modified: head/share/man/man5/stab.5
==
--- head/share/man/man5/stab.5  Sun Mar 19 00:54:24 2017(r315527)
+++ head/share/man/man5/stab.5  Sun Mar 19 01:24:18 2017(r315528)
@@ -42,7 +42,7 @@ The file
 defines some of the symbol table
 .Fa n_type
 field values for a.out files.
-These are the types for permanent symbols (i.e., not local labels, etc.)
+These are the types for permanent symbols (i.e., not local labels, etc.\&)
 used by the old debugger
 .Em sdb
 and the Berkeley Pascal compiler

Modified: head/share/man/man9/ieee80211.9
==
--- head/share/man/man9/ieee80211.9 Sun Mar 19 00:54:24 2017
(r315527)
+++ head/share/man/man9/ieee80211.9 Sun Mar 19 01:24:18 2017
(r315528)
@@ -59,7 +59,7 @@ device driver implements a virtual radio
 users through network interfaces (aka vaps) that are cloned from the
 underlying device.
 These interfaces have an operating mode
-(station, adhoc, hostap, wds, monitor, etc.)
+(station, adhoc, hostap, wds, monitor, etc.\&)
 that is fixed for the lifetime of the interface.
 Devices that can support multiple concurrent interfaces allow
 multiple vaps to be cloned.

Modified: head/share/man/man9/ieee80211_vap.9
==
--- head/share/man/man9/ieee80211_vap.9 Sun Mar 19 00:54:24 2017
(r315527)
+++ head/share/man/man9/ieee80211_vap.9 Sun Mar 19 01:24:18 2017
(r315528)
@@ -62,7 +62,7 @@ a virtual radio API that is exported to
 users through network interfaces (aka vaps) that are cloned from the
 underlying device.
 These interfaces have an operating mode
-(station, adhoc, hostap, wds, monitor, etc.)
+(station, adhoc, hostap, wds, monitor, etc.\&)
 that is fixed for the lifetime of the interface.
 Devices that can support multiple concurrent interfaces allow
 multiple vaps to be cloned.

Modified: head/share/man/man9/taskqueue.9
==
--- head/share/man/man9/taskqueue.9 Sun Mar 19 00:54:24 2017
(r315527)
+++ head/share/man/man9/taskqueue.9 Sun Mar 19 01:24:18 2017
(r315528)
@@ -404,7 +404,7 @@ the
 .Va init
 argument to the macro is executed as a C statement,
 allowing any further initialisation to be performed
-(such as registering an interrupt handler etc.)
+(such as registering an interrupt handler, etc.).
 .Pp
 The
 .Fn TASKQUEUE_DEFINE_THREAD

Modified: head/share/man/man9/vnode.9
==
--- head/share/man/man9/vnode.9 Sun Mar 19 00:54:24 2017(r315527)
+++ head/share/man/man9/vnode.9 Sun Mar 19 01:24:18 2017(r315528)
@@ -82,7 +82,7 @@ system calls.
 Any call which returns a vnode (e.g.,\&
 .Xr vget 9 ,
 .Xr VOP_LOOKUP 9 ,
-etc.)
+etc.\&)
 will increase the
 .Va v_usecount
 of the vnode by one.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r315318 - in head/sys: kern vm

[Benjamin Kaduk]

Should __FreeBSD_version be bumped, e.g., for out-of-tree filesystems that
have custom vop_advise?

-Ben

On Wed, Mar 15, 2017 at 12:43 PM, Alan Cox  wrote:

> Author: alc
> Date: Wed Mar 15 17:43:45 2017
> New Revision: 315318
> URL: https://svnweb.freebsd.org/changeset/base/315318
>
> Log:
>   Relax the locking requirements for vm_object_page_noreuse().  While
>   reviewing all uses of OFF_TO_IDX(), I observed that
>   vm_object_page_noreuse() is requiring an exclusive lock on the object
>   when, in fact, a shared lock suffices.
>
>   Reviewed by:  kib, markj
>   MFC after:3 days
>   Differential Revision:https://reviews.freebsd.org/D10011
>
> Modified:
>   head/sys/kern/vfs_default.c
>   head/sys/vm/vm_object.c
>
> Modified: head/sys/kern/vfs_default.c
> 
> ==
> --- head/sys/kern/vfs_default.c Wed Mar 15 17:26:19 2017(r315317)
> +++ head/sys/kern/vfs_default.c Wed Mar 15 17:43:45 2017(r315318)
> @@ -1100,10 +1100,10 @@ vop_stdadvise(struct vop_advise_args *ap
> if (vp->v_object != NULL) {
> start = trunc_page(ap->a_start);
> end = round_page(ap->a_end);
> -   VM_OBJECT_WLOCK(vp->v_object);
> +   VM_OBJECT_RLOCK(vp->v_object);
> vm_object_page_noreuse(vp->v_object,
> OFF_TO_IDX(start),
> OFF_TO_IDX(end));
> -   VM_OBJECT_WUNLOCK(vp->v_object);
> +   VM_OBJECT_RUNLOCK(vp->v_object);
> }
>
> bo = >v_bufobj;
>
> Modified: head/sys/vm/vm_object.c
> 
> ==
> --- head/sys/vm/vm_object.c Wed Mar 15 17:26:19 2017(r315317)
> +++ head/sys/vm/vm_object.c Wed Mar 15 17:43:45 2017(r315318)
> @@ -1978,7 +1978,7 @@ vm_object_page_noreuse(vm_object_t objec
> struct mtx *mtx, *new_mtx;
> vm_page_t p, next;
>
> -   VM_OBJECT_ASSERT_WLOCKED(object);
> +   VM_OBJECT_ASSERT_LOCKED(object);
> KASSERT((object->flags & (OBJ_FICTITIOUS | OBJ_UNMANAGED)) == 0,
> ("vm_object_page_noreuse: illegal object %p", object));
> if (object->resident_page_count == 0)
> ___
> svn-src-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r315165 - head/sys/kern

[Benjamin Kaduk]

On Sun, Mar 12, 2017 at 12:43 PM, Ian Lepore  wrote:

> Author: ian
> Date: Sun Mar 12 17:43:45 2017
> New Revision: 315165
> URL: https://svnweb.freebsd.org/changeset/base/315165
>
> Log:
>   Correct the abbreviations for microseconds (us, not ms), and for Hz (not
> HZ).
>
> Modified:
>   head/sys/kern/vfs_subr.c
>
> Modified: head/sys/kern/vfs_subr.c
> 
> ==
> --- head/sys/kern/vfs_subr.cSun Mar 12 17:41:51 2017(r315164)
> +++ head/sys/kern/vfs_subr.cSun Mar 12 17:43:45 2017(r315165)
> @@ -767,7 +767,7 @@ enum { TSP_SEC, TSP_HZ, TSP_USEC, TSP_NS
>  static int timestamp_precision = TSP_USEC;
>  SYSCTL_INT(_vfs, OID_AUTO, timestamp_precision, CTLFLAG_RW,
>  _precision, 0, "File timestamp precision (0: seconds, "
> -"1: sec + ns accurate to 1/HZ, 2: sec + ns truncated to ms, "
> +"1: sec + ns accurate to 1/Hz, 2: sec + ns truncated to us, "
>

HZ looks like the kernel configuration parameter here, not the unit.

-Ben


>  "3+: sec + ns (max. precision))");
>
>  /*
> ___
> svn-src-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r314373 - in head: . etc/defaults etc/rc.d lib/libc/regex share/man/man4/man4.i386 share/man/man5 sys/amd64/conf sys/boot/forth sys/compat/svr4 sys/conf sys/dev/streams sys/i386/conf s

[Benjamin Kaduk]

On Tue, Feb 28, 2017 at 3:30 PM, Gleb Smirnoff <gleb...@freebsd.org> wrote:

> On Tue, Feb 28, 2017 at 01:39:12PM -0600, Benjamin Kaduk wrote:
> B> > I don't think this deserves UPDATING entry, since it doesn't require
> B> > any action from a person who updates from sources.
> B> >
> B> > I don't think this requires __FreeBSD_version bump, since the latter
> B> > is used to assist compilation of open source application that use
> B> > changed API. The change removed support to run binaries.
> B> >
> B>
> B> That is not the only use of __FreeBSD_version, which is (at least)
> exposed
> B> to the ports collection and can cause conditional changes in what are
> B> shipped by ports.
> B> Which is not to say that any current ports ship affected binaries, of
> B> course, but just to point out that the scope of the symbol is broader
> than
> B> stated.
>
> How can I check the __FreeBSD_version in a port Makefile? My understanding
> is that there is no standard way for such thing. Of course I can parse
> /usr/include/sys/param.h...
>
> My understanding is that the constant is for sources only:
>
> https://www.freebsd.org/doc/en/books/porters-handbook/
> porting-versions.html
>
>
Look for OSVERSION in /usr/ports/Mk/bsd.port.mk

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r314373 - in head: . etc/defaults etc/rc.d lib/libc/regex share/man/man4/man4.i386 share/man/man5 sys/amd64/conf sys/boot/forth sys/compat/svr4 sys/conf sys/dev/streams sys/i386/conf s

[Benjamin Kaduk]

On Tue, Feb 28, 2017 at 1:36 PM, Gleb Smirnoff  wrote:

>   Ravi,
>
>   this should go into Relnotes, my failure that I didn't put the tag.
>
> I don't think this deserves UPDATING entry, since it doesn't require
> any action from a person who updates from sources.
>
> I don't think this requires __FreeBSD_version bump, since the latter
> is used to assist compilation of open source application that use
> changed API. The change removed support to run binaries.
>

That is not the only use of __FreeBSD_version, which is (at least) exposed
to the ports collection and can cause conditional changes in what are
shipped by ports.
Which is not to say that any current ports ship affected binaries, of
course, but just to point out that the scope of the symbol is broader than
stated.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r314142 - head/sys/dev/ce

[Benjamin Kaduk]

On Thu, Feb 23, 2017 at 9:30 AM, Pedro F. Giffuni  wrote:

> Author: pfg
> Date: Thu Feb 23 15:30:21 2017
> New Revision: 314142
> URL: https://svnweb.freebsd.org/changeset/base/314142
>
> Log:
>   dev/ce: double assignment.
>
>   The code is not operational right now so just comment away an obviously
>   useless assignment. Fix some typos while here.
>
>   Found with: coccinelle (da.cocci)
>
> Modified:
>   head/sys/dev/ce/ceddk.c
>
> Modified: head/sys/dev/ce/ceddk.c
> 
> ==
> --- head/sys/dev/ce/ceddk.c Thu Feb 23 15:10:46 2017(r314141)
> +++ head/sys/dev/ce/ceddk.c Thu Feb 23 15:30:21 2017(r314142)
> @@ -632,8 +632,8 @@ void ce_stop_chan (ce_chan_t *c)
>   "UserRequest (%s:%d)\n", __FUNCTION__,
> __LINE__));
> return;
> }
> -   req->Command = TAU32_Configure_Commit |
> -  TAU32_Tx_Stop | TAU32_Rx_Stop;
> +// req->Command = TAU32_Configure_Commit |
> +//TAU32_Tx_Stop | TAU32_Rx_Stop;
>

Should probably stick to C-style comments, though.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Benjamin Kaduk]

On Tue, Jan 17, 2017 at 10:57 AM, Ian Lepore  wrote:

> In my experience, enums are a superior way to define integer constants
> (compared to #define), but they are pure poison as variable types in
> APIs and structures because their size is a compiler implementation
> choice.
>

Well, to some extent. For example, the amd64 sysV ABI says that enum types
are signed fourbyte, with a footnote that "C++ and some implementations of
C permit enums larger than an int. The underlying type is bumped to an
unsigned int, long int or unsigned long int, in that order."

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r312234 - in head: sbin/camcontrol share/man/man4 share/man/man9 sys/arm/arm sys/arm/freescale/imx sys/arm/mv sys/cam sys/dev/bhnd sys/dev/fdt sys/dev/isp sys/dev/mmc sys/dev/mpt sys/d

[Benjamin Kaduk]

On Sun, Jan 15, 2017 at 11:54 AM, Conrad E. Meyer  wrote:

> Author: cem
> Date: Sun Jan 15 17:54:01 2017
> New Revision: 312234
> URL: https://svnweb.freebsd.org/changeset/base/312234
>
> Log:
>   "Buses" is the preferred plural of "bus"
>
>   Replace archaic "busses" with modern form "buses."
>
>
The link intending to support this assertion refers to the motor vehicle,
which does not necessarily have the same usage as the hardware nexus.  It
would have been nice to see some discussion on -doc or similar before
making a sweeping change like this, as I am not sure that the consensus of
our team is for the "buses" spelling in this usage.

-Ben


>   Intentionally excluded:
>   * Old/random drivers I didn't recognize
> * Old hardware in general
>   * Use of "busses" in code as identifiers
>
>   No functional change.
>
>   http://grammarist.com/spelling/buses-busses/
>
>   PR:   216099
>   Reported by:  bltsrc at mail.ru
>   Sponsored by: Dell EMC Isilon
>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r311171 - head/share/man/man9

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Tue Jan  3 21:11:30 2017
New Revision: 311171
URL: https://svnweb.freebsd.org/changeset/base/311171

Log:
  Fix typo

Modified:
  head/share/man/man9/atomic.9

Modified: head/share/man/man9/atomic.9
==
--- head/share/man/man9/atomic.9Tue Jan  3 21:02:30 2017
(r311170)
+++ head/share/man/man9/atomic.9Tue Jan  3 21:11:30 2017
(r311171)
@@ -402,7 +402,7 @@ The
 .Fn atomic_fcmpset
 function returns
 .Dv true
-if the operationg succeeded.
+if the operation succeeded.
 Otherwise it returns
 .Dv false
 and sets
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r309109 - head/lib/libutil

[Benjamin Kaduk]

I'm happy to have a comment noting the extreme subtleties in play and
calling you out as the domain expert to contact.  However, I don't think
that the "UNDER PAIN OF DEATH" is appropriate, even jocularly; there are
other ways to express the needed sentiment that do not cause one to think
about the code of conduct.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r307539 - head/release/doc/en_US.ISO8859-1/hardware

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Mon Oct 17 22:48:29 2016
New Revision: 307539
URL: https://svnweb.freebsd.org/changeset/base/307539

Log:
  Fix relnotes build of supported hardware list after r307529
  
  urtwn is merged into rtwn, so there is not a separate hardware list
  to include anymore.

Modified:
  head/release/doc/en_US.ISO8859-1/hardware/article.xml

Modified: head/release/doc/en_US.ISO8859-1/hardware/article.xml
==
--- head/release/doc/en_US.ISO8859-1/hardware/article.xml   Mon Oct 17 
22:37:07 2016(r307538)
+++ head/release/doc/en_US.ISO8859-1/hardware/article.xml   Mon Oct 17 
22:48:29 2016(r307539)
@@ -1013,8 +1013,6 @@
 
   
 
-  
-
   [, , ] Lucent
Technologies WaveLAN/IEEE 802.11b wireless network adapters
and workalikes using the Lucent Hermes, Intersil PRISM-II,
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys

[Benjamin Kaduk]

On Mon, Aug 29, 2016 at 2:10 PM, Konstantin Belousov 
wrote:

> On Mon, Aug 29, 2016 at 09:16:29PM +0300, Andrey Chernov wrote:
> > Previous text is documented everywhere and describing usual good
> > practice, so it should remains in place, in that means r304928 should be
> > reverted, because replace proper way of doing things with obsoleted
> > feature description.
> >
> > What I suggest is not _replace_ old text with new, but _add_ new text as
> > describing current and not recommended way, with the direct mention that
> > this feature is obsoleted and not recommended for relay on it.
> >
>
> diff --git a/lib/libc/sys/ptrace.2 b/lib/libc/sys/ptrace.2
> index 48802f4..d406efc 100644
> --- a/lib/libc/sys/ptrace.2
> +++ b/lib/libc/sys/ptrace.2
> @@ -2,7 +2,7 @@
>  .\"$NetBSD: ptrace.2,v 1.2 1995/02/27 12:35:37 cgd Exp $
>  .\"
>  .\" This file is in the public domain.
> -.Dd August 28, 2016
> +.Dd August 29, 2016
>  .Dt PTRACE 2
>  .Os
>  .Sh NAME
> @@ -900,19 +900,29 @@ argument is ignored.
>  .Pp
>  Additionally, other machine-specific requests can exist.
>  .Sh RETURN VALUES
> +Most requests return 0 on success and \-1 on error.
>  Some requests can cause
>  .Fn ptrace
>  to return
>  \-1
> -as a non-error value; to disambiguate,
> +as a non-error value, among them are
> +.Dv PT_READ_I
> +and
> +.Dv PT_READ_D ,
> +which return the value read from the process memory on success.
> +To disambiguate,
>  .Va errno
> -is set to 0 in the libc wrapper for the
> -.Fn ptrace
> -system call and
> +can be set to 0 before the call and checked afterwards.
> +.Pp
> +Current
>

The current


>  .Fn ptrace
> -callers can reliably check
> +implementation always sets
> +.Va errno
> +to 0 before calling into kernel, both for historic reasons and for
>

the kernel


> +consistency with other operating systems.
> +It is recommended to assign zero to
>  .Va errno
> -for non-zero value afterwards.
> +explicitely for future compatibility.
>

"explicitly" (only one 'e')

Maybe forward compatibility instead of future compatibility, but either is
fine.

Feel free to commit with reviewed-by: bjk

-Ben


>  .Sh ERRORS
>  The
>  .Fn ptrace
> ___
> svn-src-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r304560 - head/release/doc/en_US.ISO8859-1/hardware

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Sun Aug 21 15:39:46 2016
New Revision: 304560
URL: https://svnweb.freebsd.org/changeset/base/304560

Log:
  Remove the ie(4) hardware list from the release documentation
  
  The driver was removed by jhb in r304513, and the  entity
  is no longer generated, causing the website build to fail.

Modified:
  head/release/doc/en_US.ISO8859-1/hardware/article.xml

Modified: head/release/doc/en_US.ISO8859-1/hardware/article.xml
==
--- head/release/doc/en_US.ISO8859-1/hardware/article.xml   Sun Aug 21 
15:37:49 2016(r304559)
+++ head/release/doc/en_US.ISO8859-1/hardware/article.xml   Sun Aug 21 
15:39:46 2016(r304560)
@@ -836,8 +836,6 @@
 
   
 
-  
-
   
 
   
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r304505 - head/release/doc/en_US.ISO8859-1/hardware

[Benjamin Kaduk]

On Fri, Aug 19, 2016 at 5:13 PM, John Baldwin  wrote:

> Author: jhb
> Date: Fri Aug 19 22:13:01 2016
> New Revision: 304505
> URL: https://svnweb.freebsd.org/changeset/base/304505
>
> Log:
>   Remove mentions of the mcd(4), scd(4), and si(4) drivers.
>

Hmm, looks like ie(4) also needs removal (in order to fix the build)?

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r303801 - head/share/man/man3

[Benjamin Kaduk]

Indeed; it seems I was not checking what I thought I was checking in
sys/queue.h; fix incoming.

-Ben

On Sat, 6 Aug 2016, Conrad Meyer wrote:

> Hey Benjamin,
>
> The submitter notes that this wider change isn't quite right in
> https://reviews.freebsd.org/D7428 — LIST_SWAP and TAILQ_SWAP both need
> the "entry" parameter.
>
> Best,
> Conrad
>
> On Sat, Aug 6, 2016 at 10:27 AM, Benjamin Kaduk <b...@freebsd.org> wrote:
> > Author: bjk (doc committer)
> > Date: Sat Aug  6 17:27:07 2016
> > New Revision: 303801
> > URL: https://svnweb.freebsd.org/changeset/base/303801
> >
> > Log:
> >   Correct the documentation of the 'type' parameter for the _SWAP
> >   macros from sys/queue.h
> >
> >   Submitted by: akshay1994.leo_gmail.com (for STAILQ)
> >   Differential Revision:https://reviews.freebsd.org/D7428
> >
> > Modified:
> >   head/share/man/man3/queue.3
> >
> > Modified: head/share/man/man3/queue.3
> > ==
> > --- head/share/man/man3/queue.3 Sat Aug  6 17:24:35 2016(r303800)
> > +++ head/share/man/man3/queue.3 Sat Aug  6 17:27:07 2016(r303801)
> > @@ -141,7 +141,7 @@ lists and tail queues
> >  .Fn SLIST_REMOVE "SLIST_HEAD *head" "TYPE *elm" "TYPE" "SLIST_ENTRY NAME"
> >  .Fn SLIST_REMOVE_AFTER "TYPE *elm" "SLIST_ENTRY NAME"
> >  .Fn SLIST_REMOVE_HEAD "SLIST_HEAD *head" "SLIST_ENTRY NAME"
> > -.Fn SLIST_SWAP "SLIST_HEAD *head1" "SLIST_HEAD *head2" "SLIST_ENTRY NAME"
> > +.Fn SLIST_SWAP "SLIST_HEAD *head1" "SLIST_HEAD *head2" "TYPE"
> >  .\"
> >  .Fn STAILQ_CLASS_ENTRY "CLASSTYPE"
> >  .Fn STAILQ_CLASS_HEAD "HEADNAME" "CLASSTYPE"
> > @@ -164,7 +164,7 @@ lists and tail queues
> >  .Fn STAILQ_REMOVE "STAILQ_HEAD *head" "TYPE *elm" "TYPE" "STAILQ_ENTRY 
> > NAME"
> >  .Fn STAILQ_REMOVE_AFTER "STAILQ_HEAD *head" "TYPE *elm" "STAILQ_ENTRY NAME"
> >  .Fn STAILQ_REMOVE_HEAD "STAILQ_HEAD *head" "STAILQ_ENTRY NAME"
> > -.Fn STAILQ_SWAP "STAILQ_HEAD *head1" "STAILQ_HEAD *head2" "STAILQ_ENTRY 
> > NAME"
> > +.Fn STAILQ_SWAP "STAILQ_HEAD *head1" "STAILQ_HEAD *head2" "TYPE"
> >  .\"
> >  .Fn LIST_CLASS_ENTRY "CLASSTYPE"
> >  .Fn LIST_CLASS_HEAD "HEADNAME" "CLASSTYPE"
> > @@ -184,7 +184,7 @@ lists and tail queues
> >  .Fn LIST_NEXT "TYPE *elm" "LIST_ENTRY NAME"
> >  .Fn LIST_PREV "TYPE *elm" "LIST_HEAD *head" "TYPE" "LIST_ENTRY NAME"
> >  .Fn LIST_REMOVE "TYPE *elm" "LIST_ENTRY NAME"
> > -.Fn LIST_SWAP "LIST_HEAD *head1" "LIST_HEAD *head2" "TYPE" "LIST_ENTRY 
> > NAME"
> > +.Fn LIST_SWAP "LIST_HEAD *head1" "LIST_HEAD *head2" "TYPE"
> >  .\"
> >  .Fn TAILQ_CLASS_ENTRY "CLASSTYPE"
> >  .Fn TAILQ_CLASS_HEAD "HEADNAME" "CLASSTYPE"
> > @@ -211,7 +211,7 @@ lists and tail queues
> >  .Fn TAILQ_NEXT "TYPE *elm" "TAILQ_ENTRY NAME"
> >  .Fn TAILQ_PREV "TYPE *elm" "HEADNAME" "TAILQ_ENTRY NAME"
> >  .Fn TAILQ_REMOVE "TAILQ_HEAD *head" "TYPE *elm" "TAILQ_ENTRY NAME"
> > -.Fn TAILQ_SWAP "TAILQ_HEAD *head1" "TAILQ_HEAD *head2" "TYPE" "TAILQ_ENTRY 
> > NAME"
> > +.Fn TAILQ_SWAP "TAILQ_HEAD *head1" "TAILQ_HEAD *head2" "TYPE"
> >  .\"
> >  .Sh DESCRIPTION
> >  These macros define and operate on four types of data structures which
> >
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r303805 - head/share/man/man3

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Sat Aug  6 19:12:23 2016
New Revision: 303805
URL: https://svnweb.freebsd.org/changeset/base/303805

Log:
  Re-correct the documentation for the 'type' parameter of the _SWAP
  macros from sys/queue.h -- only the singly-linked forms do not need
  the 'field' argument.
  
  Pointy Hat to:bjk
  Reported by:  akshay1994.leo_gmail.com

Modified:
  head/share/man/man3/queue.3

Modified: head/share/man/man3/queue.3
==
--- head/share/man/man3/queue.3 Sat Aug  6 19:05:01 2016(r303804)
+++ head/share/man/man3/queue.3 Sat Aug  6 19:12:23 2016(r303805)
@@ -184,7 +184,7 @@ lists and tail queues
 .Fn LIST_NEXT "TYPE *elm" "LIST_ENTRY NAME"
 .Fn LIST_PREV "TYPE *elm" "LIST_HEAD *head" "TYPE" "LIST_ENTRY NAME"
 .Fn LIST_REMOVE "TYPE *elm" "LIST_ENTRY NAME"
-.Fn LIST_SWAP "LIST_HEAD *head1" "LIST_HEAD *head2" "TYPE"
+.Fn LIST_SWAP "LIST_HEAD *head1" "LIST_HEAD *head2" "TYPE" "LIST_ENTRY NAME"
 .\"
 .Fn TAILQ_CLASS_ENTRY "CLASSTYPE"
 .Fn TAILQ_CLASS_HEAD "HEADNAME" "CLASSTYPE"
@@ -211,7 +211,7 @@ lists and tail queues
 .Fn TAILQ_NEXT "TYPE *elm" "TAILQ_ENTRY NAME"
 .Fn TAILQ_PREV "TYPE *elm" "HEADNAME" "TAILQ_ENTRY NAME"
 .Fn TAILQ_REMOVE "TAILQ_HEAD *head" "TYPE *elm" "TAILQ_ENTRY NAME"
-.Fn TAILQ_SWAP "TAILQ_HEAD *head1" "TAILQ_HEAD *head2" "TYPE"
+.Fn TAILQ_SWAP "TAILQ_HEAD *head1" "TAILQ_HEAD *head2" "TYPE" "TAILQ_ENTRY 
NAME"
 .\"
 .Sh DESCRIPTION
 These macros define and operate on four types of data structures which
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r303755 - head/sys/kern

[Benjamin Kaduk]

On Fri, Aug 5, 2016 at 8:06 AM, John Baldwin  wrote:

>
> It would be possible if both used the same versioning.  Looks like
> base on my desktop (10.3) is not using versioning, so if the version
> map is provided by openssl we could in theory just use their version
> map when building base openssl.  That is actually the far easier
> problem to solve (using upstream-maintained version map vs trying to
> maintain a local version map that has to be updated manually whenever
> upstream changes).
>

Upstream does not supply a version map for the 1.0.2 releases and older; it
will be new in 1.1.0 (due out in a few weeks, last we heard).

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r303716 - head/crypto/openssh

[Benjamin Kaduk]

On Wed, Aug 3, 2016 at 11:08 AM, Dag-Erling Smørgrav 
wrote:

> Author: des
> Date: Wed Aug  3 16:08:21 2016
> New Revision: 303716
> URL: https://svnweb.freebsd.org/changeset/base/303716
>
> Log:
>   Remove DSA from default cipher list and disable SSH1.
>
>   Upstream did this a long time ago, but we kept DSA and SSH1 in FreeBSD
> for
>   reasons which boil down to POLA.  Now is a good time to catch up.
>
>   MFC after:3 days
>

Which branch(es) are MFC targets?  (Does POLA no longer apply to them?)

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r303484 - head/usr.bin/indent

[Benjamin Kaduk]

On Fri, Jul 29, 2016 at 11:17 AM, Pedro F. Giffuni  wrote:

> Author: pfg
> Date: Fri Jul 29 16:17:54 2016
> New Revision: 303484
> URL: https://svnweb.freebsd.org/changeset/base/303484
>
> Log:
>   indent(1): Fix breakage caused by single comment following "else".
>
>   indent(1) simply wasn't taught that "else" may be followed by a comment
>   without any opening brace anywhere on the line, so it was very confused
>   in such cases.
>
>
Wrong commit message?  I see no 'else' in this change.
(I guess core's guidance is to revert and recommit with correct message,
these days.)

-Ben



>   Differential Revision: https://reviews.freebsd.org/D6966 (Partial)
>   Obtained from:Piotr Stefaniak
>
> Modified:
>   head/usr.bin/indent/indent.c
>
> Modified: head/usr.bin/indent/indent.c
>
> ==
> --- head/usr.bin/indent/indent.cFri Jul 29 16:14:03 2016
> (r303483)
> +++ head/usr.bin/indent/indent.cFri Jul 29 16:17:54 2016
> (r303484)
> @@ -319,6 +319,8 @@ main(int argc, char **argv)
> switch (type_code) {
> case newline:
> ++line_no;
> +   if (sc_end != NULL)
> +   goto sw_buffer; /* dump comment, if any */
> flushed_nl = true;
> case form_feed:
> break;  /* form feeds and newlines found here will
> be
> ___
> svn-src-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r303484 - head/usr.bin/indent

[Benjamin Kaduk]

On Fri, Jul 29, 2016 at 11:20 AM, Benjamin Kaduk <bjkf...@gmail.com> wrote:

> On Fri, Jul 29, 2016 at 11:17 AM, Pedro F. Giffuni <p...@freebsd.org>
> wrote:
>
>> Author: pfg
>> Date: Fri Jul 29 16:17:54 2016
>> New Revision: 303484
>> URL: https://svnweb.freebsd.org/changeset/base/303484
>>
>> Log:
>>   indent(1): Fix breakage caused by single comment following "else".
>>
>>   indent(1) simply wasn't taught that "else" may be followed by a comment
>>   without any opening brace anywhere on the line, so it was very confused
>>   in such cases.
>>
>>
> Wrong commit message?  I see no 'else' in this change.
> (I guess core's guidance is to revert and recommit with correct message,
> these days.)
>

Nevermind, I think I see what's going on here, now.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r303342 - in head: include lib/libc/stdlib

[Benjamin Kaduk]

On Tue, Jul 26, 2016 at 3:11 PM, Ed Schouten  wrote:

> Author: ed
> Date: Tue Jul 26 20:11:29 2016
> New Revision: 303342
> URL: https://svnweb.freebsd.org/changeset/base/303342
>
> Log:
>   Fix typing of srandom() and initstate().
>
>   POSIX requires that these functions have an unsigned int for their first
>   argument; not an unsigned long.
>
>   My reasoning is that we can safely change these functions without
>   breaking the ABI. As far as I know, our supported architectures either
>   use registers for passing function arguments that are at least as big as
>   long (e.g., amd64), or int and long are of the same size (e.g., i386).
>

Is a __FreeBSD_version bump planned?  (Third-party software might want to
be warning-clean.)

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r302252 - head/sys/kern

[Benjamin Kaduk]

On Sat, Jul 2, 2016 at 3:04 AM, Bruce Evans  wrote:

> +   .th_counter = _timecounter,
>> +   .th_scale = (uint64_t)-1 / 100,
>> +   .th_offset = {1, 0},
>>
>
> Is there a syntax for avoiding the explicit 0 in a nested initializer?
> Something like th_offset.tv_sec = 1.


C99 does not require complete initializers (though my habit of running with
clang -Weverything does).  Just .th_offset = {1} should give the desired
result here.  I did not think that .th_offset.tv_sec was valid, though, so
when not-the-initial element is nonzero some zeros would still be needed.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r298537 - head/etc/rc.d

[Benjamin Kaduk]

On Sun, Apr 24, 2016 at 12:01 PM, Jan Beich  wrote:

> Jens Schweikhardt  writes:
>
> >  - parenthesize the "case" string for symmetry and improved
> >search for matching paren (e.g. with vi's %)
> [...]
> >   case "${state}" in
> > - [oO][nN])
> > + ([oO][nN])
> >   swapon /dev/zvol/${name}
> >   ;;
>
> For style consistency is more important. Why this case is special unlike
> the rest of rc.d/* or rc.subr ?
>


Coming in quite late, I agree.  I think this part should be reverted.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r302210 - head/sys/fs/nfsclient

[Benjamin Kaduk]

On Sun, Jun 26, 2016 at 9:18 AM, Konstantin Belousov 
wrote:

> Author: kib
> Date: Sun Jun 26 14:18:28 2016
> New Revision: 302210
> URL: https://svnweb.freebsd.org/changeset/base/302210
>
> Log:
>   Clean other flags in ncl_inactive, only.  Add comment explaining why
> other
>   flags should be unset.
>
[...]

> +
> +   /*
> +* NMODIFIED means that there might be dirty/stale buffers
> +* associated with the NFS vnode.  None of the other flags are
> +* meaningful after the vnode is unused.
> +*/
> +   np->n_flag &= NMODIFIED;
>

Maybe I am confused, but the commit message reads like this should be '=',
not '&='.

-Ben


> +   mtx_unlock(>n_mtx);
> return (0);
>  }
>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r299831 - head/usr.sbin/bsnmpd/bsnmpd

[Benjamin Kaduk]

On Sat, May 14, 2016 at 10:38 PM, Garrett Cooper  wrote:

> Author: ngie
> Date: Sun May 15 03:38:40 2016
> New Revision: 299831
> URL: https://svnweb.freebsd.org/changeset/base/299831
>
> Log:
>   Remove NO_WERROR and add WARNS?= 6
>

I thought WARNS=6 was already the default.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r299218 - head/usr.bin/sdiff

[Benjamin Kaduk]

On Sat, May 7, 2016 at 1:48 PM, Baptiste Daroussin  wrote:

> Author: bapt
> Date: Sat May  7 18:48:48 2016
> New Revision: 299218
> URL: https://svnweb.freebsd.org/changeset/base/299218
>
> Log:
>   Only use EDITOR as a variable to specify which text editor to use
>
>
Why?  VISUAL can still be terminal-based, as I understand it.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r298924 - head/usr.bin/sdiff

[Benjamin Kaduk]

On Mon, 2 May 2016, Bjoern A. Zeeb wrote:

>
> > On 02 May 2016, at 16:08 , Conrad Meyer <c...@freebsd.org> wrote:
> >
> > On Mon, May 2, 2016 at 8:57 AM, Benjamin Kaduk <bjkf...@gmail.com> wrote:
> >> On Mon, May 2, 2016 at 10:54 AM, Bjoern A. Zeeb <b...@freebsd.org> wrote:
> >>>> On 02 May 2016, at 15:32 , Conrad Meyer <c...@freebsd.org> wrote:
> >>>>
> >>>> Clang should really catch this too.  Why didn’t it?
> >>>
> >>> It was only powerpc;  sparc64 and mips were good as well.
> >>
> >> 'char' being signed vs. unsigned?
> >
> > Yeah, that occurred to me, but EOF should be out of range for any char
> > type.  I'd like ((char)getchar() == EOF) to warn on all platforms.
>
> I think we just define EOF to be -1.  Someone should check, and that the 
> warning message might be misleading.

Yeah, stdio.h has:

#define EOF (-1)

If char is signed, that gets more exciting, due to the value-preserving
promotion rule (after the char cast, it gets converted back to int for the
comparison operation).

Also, -1 is assumed to be EOF in external code, e.g.,
contrib/top/getopt.c.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r298924 - head/usr.bin/sdiff

[Benjamin Kaduk]

On Mon, May 2, 2016 at 10:54 AM, Bjoern A. Zeeb  wrote:

>
> > On 02 May 2016, at 15:32 , Conrad Meyer  wrote:
> >
> > Clang should really catch this too.  Why didn’t it?
>
> It was only powerpc;  sparc64 and mips were good as well.
>
>
'char' being signed vs. unsigned?

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r298036 - head/sys/cam

[Benjamin Kaduk]

On Fri, Apr 15, 2016 at 8:26 AM, Warner Losh  wrote:

> On Fri, Apr 15, 2016 at 12:05 AM, Howard Su  wrote:
>
> >> I suggest to remove NETFLIX from the name.
> >
>
> It's the Netflix I/O scheduler as opposed to the default one. So the
> name is appropriate. It's better than CAM_WARNER_AWESOME_IOSCHED
> which is the only other choice possible... :)
>


Surely there are other options ... who wouldn't want to have a scheduler
with imps in it? :)

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r297481 - head/sys/kern

[Benjamin Kaduk]

On Fri, Apr 1, 2016 at 1:12 AM, Mateusz Guzik  wrote:

> Author: mjg
> Date: Wed Apr  1 08:10:00 2016
> New Revision: 280963
>

Next year should probably update the "New Revision" line...


> URL: https://svnweb.freebsd.org/changeset/base/297481
>
> Log:
>   Increase responsiveness under load by being more aggressive with
>   priority changes.
>
>   MFC after:1 week
>
> Modified:
>   head/sys/kern/sched_ule.c
>
> Modified: head/sys/kern/sched_ule.c
> ===
> --- sys/kern/sched_ule.c(revision 297480)
> +++ sys/kern/sched_ule.c(working copy)
>

...and use the version number instead of "working copy".

-Ben


> @@ -1696,15 +1696,10 @@
> }
> ts = td->td_sched;
> THREAD_LOCK_ASSERT(td, MA_OWNED);
> -   if (td->td_priority == prio)
> -   return;
> /*
> -* If the priority has been elevated due to priority
> -* propagation, we may have to move ourselves to a new
> -* queue.  This could be optimized to not re-add in some
> -* cases.
> +* DOES THIS WORK LOL
>  */
> -   if (TD_ON_RUNQ(td) && prio < td->td_priority) {
> +   if (TD_ON_RUNQ(td) && prio != td->td_priority) {
> sched_rem(td);
> td->td_priority = prio;
> sched_add(td, SRQ_BORROWING);
> ___
> svn-src-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r297201 - in head: share/man/man4 sys/dev/filemon

[Benjamin Kaduk]

On Tue, Mar 22, 2016 at 9:11 PM, Bryan Drewery  wrote:

>
>
>
> The manpage for close(2) does document some errors, one being ENOSPC.  The
> close(2) behavior of returning write(2), really VOP_WRITE(9), errors though
> is specific to filemon since all of the writes are hidden and this is the
> only place to return an error.  I have a review open to resolve a similar
> issue in alq(9) as well since all of the writes are asynchronous and
> there's no API to retrieve any error from.
>

filemon is not unique in this regard; the AFS filesystem buffers writes
locally and in some cases errors writing to the remote server can be
delayed until close().  Of course, very few softwares actually check the
return value of close, so this can cause trouble sometimes...

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r297025 - head/sbin/ping

[Benjamin Kaduk]

On Fri, Mar 18, 2016 at 10:07 AM, Maxim Konovalov  wrote:

> Author: maxim
> Date: Fri Mar 18 15:07:43 2016
> New Revision: 297025
> URL: https://svnweb.freebsd.org/changeset/base/297025
>
> Log:
>   o Kill EoL whitespaces.
>
> Modified:
>   head/sbin/ping/ping.c
>
> Modified: head/sbin/ping/ping.c
>
> ==
> --- head/sbin/ping/ping.c   Fri Mar 18 15:06:50 2016(r297024)
> +++ head/sbin/ping/ping.c   Fri Mar 18 15:07:43 2016(r297025)
> @@ -794,7 +794,7 @@ main(int argc, char *const *argv)
>  #endif
> if (sweepmax) {
> if (sweepmin > sweepmax)
> -   errx(EX_USAGE, "Maximum packet size must be no
> less than the minimum packet size");
> +   errx(EX_USAGE,"Maximum packet size must be no less
> than the minimum packet size");
>

Looks like the space immediately after the comma was also lost.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r295768 - head/usr.sbin/iostat

[Benjamin Kaduk]

On Fri, Feb 19, 2016 at 5:06 PM, Gleb Smirnoff  wrote:

> On Fri, Feb 19, 2016 at 08:49:43AM -0700, Alan Somers wrote:
> A> On Fri, Feb 19, 2016 at 5:24 AM, Sergey Kandaurov 
> wrote:
> A> Yeah, it was being implicitly zeroized before.  But Clang complained
> A> about the structures being only partially initialized.  Since the
> A> whole point of my commit was to increase the WARNS level, I explicitly
> A> zeroed the zero fields to silence Clang.
>
> Isn't zero filling part of the standard? I don't see why lack of
> explicit zeroing is a warning? Looks a false warning to me.
>

It is not quite as simple as this would make it sound.  The elements or
members of an aggregate (e.g.) structure type are initialized as if it were
an object of static storage duration (i.e., to zero) if the initializer
list does not contain enough initializers for all members of the aggregate
type, per item 21 of section 6.7.8 of n1256.pdf.  However, such
initialization does not necessarily need to zero any padding bytes that are
present, which may take unspecified values.  Personally, I think this
particular clang warning can be too aggressive, especially for complex
structs, but on the other hand given the indeterminateness of padding,
bzero/memset are often a better choice anyway.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r295765 - head/lib/libc/sys

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Thu Feb 18 18:50:03 2016
New Revision: 295765
URL: https://svnweb.freebsd.org/changeset/base/295765

Log:
  Bump .Dd for r295764
  
  Also fix a spelling and grammar nit while here.

Modified:
  head/lib/libc/sys/lseek.2

Modified: head/lib/libc/sys/lseek.2
==
--- head/lib/libc/sys/lseek.2   Thu Feb 18 18:41:40 2016(r295764)
+++ head/lib/libc/sys/lseek.2   Thu Feb 18 18:50:03 2016(r295765)
@@ -28,7 +28,7 @@
 .\" @(#)lseek.28.3 (Berkeley) 4/19/94
 .\" $FreeBSD$
 .\"
-.Dd May 26, 2012
+.Dd February 18, 2016
 .Dt LSEEK 2
 .Os
 .Sh NAME
@@ -134,9 +134,9 @@ find all such ranges in a file.
 Each file is presented as having a zero-size virtual hole at the very
 end of the file.
 The existence of a hole at the end of every data region allows for easy
-programming and also provides compatibility to the original imlementation
+programming and also provides compatibility to the original implementation
 in Solaris.
-It also causes the current file size (i.e. end-of-file offset) to be returned
+It also causes the current file size (i.e., end-of-file offset) to be returned
 to indicate that there are no more holes past the supplied
 .Fa offset .
 Applications should use
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r295566 - head/share/man/man4

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Fri Feb 12 17:03:24 2016
New Revision: 295566
URL: https://svnweb.freebsd.org/changeset/base/295566

Log:
  Update .Dd for r295565

Modified:
  head/share/man/man4/ds3231.4

Modified: head/share/man/man4/ds3231.4
==
--- head/share/man/man4/ds3231.4Fri Feb 12 16:59:42 2016
(r295565)
+++ head/share/man/man4/ds3231.4Fri Feb 12 17:03:24 2016
(r295566)
@@ -24,7 +24,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd March 6, 2015
+.Dd February 12, 2016
 .Dt DS3231 4
 .Os
 .Sh NAME
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r295566 - head/share/man/man4

[Benjamin Kaduk]

On Fri, 12 Feb 2016, Ian Lepore wrote:

> On Fri, 2016-02-12 at 17:03 +0000, Benjamin Kaduk wrote:
> > Author: bjk (doc committer)
> > Date: Fri Feb 12 17:03:24 2016
> > New Revision: 295566
> > URL: https://svnweb.freebsd.org/changeset/base/295566
> >
> > Log:
> >   Update .Dd for r295565
> >
> > Modified:
> >   head/share/man/man4/ds3231.4
>
> I thought .Dd only got bumped for significant revisions?

Basically, yes.  The threshold for "significant" has been going down over
time, though; some people use a threshold of "changes the rendered
output", even.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r294327 - in head/sys: dev/cxgb dev/cxgbe dev/e1000 dev/hyperv/netvsc dev/ixgbe dev/mxge netinet sys

[Benjamin Kaduk]

On Thu, Feb 11, 2016 at 10:47 AM, Warner Losh  wrote:

> On Wed, Feb 10, 2016 at 8:08 AM, Pedro Giffuni  wrote:
>
>
> If it is faster, is there any good reason to maintain both qsort and
> mergesort
> in the kernel then?
>

qsort is not stable; mergesort is.
(It's a shame that glibc didn't pick up mergesort.)

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r295169 - head/usr.sbin/sysrc

[Benjamin Kaduk]

On Tue, Feb 2, 2016 at 3:58 PM, Devin Teske  wrote:

> Author: dteske
> Date: Tue Feb  2 21:58:17 2016
> New Revision: 295169
> URL: https://svnweb.freebsd.org/changeset/base/295169
>
> Log:
>   Replace (Qo \  Qc) with (Qo (space) Qc)
>
>   When using col(1) piped to vim(1) as pager for man(1), the former
> sequence
>   of (Qo \  Qc) renders as "" without the space. Replace with (Qo (space)
> Qc)
>   which renders properly in more (all?) pagers.
>

mdoc(7) also suggests using double-quotes (" ") to escape literal spaces;
did you try that?

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r295169 - head/usr.sbin/sysrc

[Benjamin Kaduk]

On Tue, Feb 2, 2016 at 5:50 PM, Devin Teske <dte...@freebsd.org> wrote:

> On Tue, 2016-02-02 at 16:03 -0600, Benjamin Kaduk wrote:
>
> On Tue, Feb 2, 2016 at 3:58 PM, Devin Teske <dte...@freebsd.org> wrote:
>
> Author: dteske
> Date: Tue Feb  2 21:58:17 2016
> New Revision: 295169
> URL: https://svnweb.freebsd.org/changeset/base/295169
>
> Log:
>   Replace (Qo \  Qc) with (Qo (space) Qc)
>
>   When using col(1) piped to vim(1) as pager for man(1), the former
> sequence
>   of (Qo \  Qc) renders as "" without the space. Replace with (Qo (space)
> Qc)
>   which renders properly in more (all?) pagers.
>
>
> mdoc(7) also suggests using double-quotes (" ") to escape literal spaces;
> did you try that?
>
>
> Did not try -- tried just now and it works. Will update with a commit.
>
> However... /me opens "man mdoc"
> (20 minutes later; confused as to where)
>
> I've read mdoc(7) several times and have never seen such a clarification.
> (which I might add; would be mighty useful if you can find it)
>
>
The shame is on me; I had opened the system mdoc(7) on OS X, which is
actually groff_mdoc(7).  There is a subsection therein "Passing Space
Characters in an Argument" which has the text in question.  I guess I need
to spend more time with the mdocml mdoc(7) to get used to what it contains
(and does not contain).

Sorry for sending you down the wrong rabbit hole...

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r294638 - head/share/man/man9

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Sat Jan 23 20:01:46 2016
New Revision: 294638
URL: https://svnweb.freebsd.org/changeset/base/294638

Log:
  Document that hashinit(9) can wait for memory to be available
  
  Also tweak nearby grammar while here.
  
  Submitted by: Daniel O'Connor (original version)

Modified:
  head/share/man/man9/hashinit.9

Modified: head/share/man/man9/hashinit.9
==
--- head/share/man/man9/hashinit.9  Sat Jan 23 19:13:48 2016
(r294637)
+++ head/share/man/man9/hashinit.9  Sat Jan 23 20:01:46 2016
(r294638)
@@ -25,7 +25,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd October 10, 2004
+.Dd January 23, 2016
 .Dt HASHINIT 9
 .Os
 .Sh NAME
@@ -102,9 +102,11 @@ Any malloc performed by the
 .Fn hashinit_flags
 function will not be allowed to wait, and therefore may fail.
 .It Dv HASH_WAITOK
-Any malloc performed by the
+Any malloc performed by
 .Fn hashinit_flags
 function is allowed to wait for memory.
+This is also the behavior of
+.Fn hashinit .
 .El
 .Sh IMPLEMENTATION NOTES
 The largest prime hash value chosen by
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r294579 - head/usr.bin/whois

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Fri Jan 22 17:17:27 2016
New Revision: 294579
URL: https://svnweb.freebsd.org/changeset/base/294579

Log:
  Bump .Dd after r294575

Modified:
  head/usr.bin/whois/whois.1

Modified: head/usr.bin/whois/whois.1
==
--- head/usr.bin/whois/whois.1  Fri Jan 22 17:03:32 2016(r294578)
+++ head/usr.bin/whois/whois.1  Fri Jan 22 17:17:27 2016(r294579)
@@ -28,7 +28,7 @@
 .\" From: @(#)whois.1  8.1 (Berkeley) 6/6/93
 .\" $FreeBSD$
 .\"
-.Dd May 14, 2015
+.Dd January 22, 2016
 .Dt WHOIS 1
 .Os
 .Sh NAME
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r294023 - head/share/man/man4

[Benjamin Kaduk]

Author: bjk (doc committer)
Date: Thu Jan 14 17:16:47 2016
New Revision: 294023
URL: https://svnweb.freebsd.org/changeset/base/294023

Log:
  Update .Dd, missed in r294011

Modified:
  head/share/man/man4/ddb.4

Modified: head/share/man/man4/ddb.4
==
--- head/share/man/man4/ddb.4   Thu Jan 14 16:55:07 2016(r294022)
+++ head/share/man/man4/ddb.4   Thu Jan 14 17:16:47 2016(r294023)
@@ -60,7 +60,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd November 5, 2015
+.Dd January 14, 2016
 .Dt DDB 4
 .Os
 .Sh NAME
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r292120 - in head/contrib/elftoolchain: addr2line common elfcopy libelf readelf

[Benjamin Kaduk]

On Sun, Dec 13, 2015 at 3:13 AM, Dimitry Andric  wrote:

> On 13 Dec 2015, at 09:43, Kai Wang  wrote:
> >
> > 2015-12-13 7:04 GMT+01:00 Adrian Chadd :
> > cc1: warnings being treated as errors
> >
> /usr/home/adrian/work/freebsd/head-embedded/src/usr.bin/readelf/../../contrib/elftoolchain/readelf/readelf.c:
> > In function 'dump_dwarf':
> >
> /usr/home/adrian/work/freebsd/head-embedded/src/usr.bin/readelf/../../contrib/elftoolchain/readelf/readelf.c:7479:
> > warning: 'b' may be used uninitialized in this function
> >
> /usr/home/adrian/work/freebsd/head-embedded/src/usr.bin/readelf/../../contrib/elftoolchain/readelf/readelf.c:7479:
> > note: 'b' was declared here
> >
> /usr/home/adrian/work/freebsd/head-embedded/src/usr.bin/readelf/../../contrib/elftoolchain/readelf/readelf.c:4758:
> > warning: 'pe' may be used uninitialized in this function
> >
> /usr/home/adrian/work/freebsd/head-embedded/src/usr.bin/readelf/../../contrib/elftoolchain/readelf/readelf.c:4758:
> > note: 'pe' was declared here
> >
> > .. these both seem like legit.
> >
> >
> > Hi,
> >
> > Sorry about the breakage. Should be fixed by r292158.
> > Somehow clang didn't catch this. Had to use gcc to see this warning.
>
> Indeed, this is interesting.  For clang to warn similarly, the
> -Wconditional-uninitialized option has to be enabled explicitly, and
> then you get a lot of them (this is from just before your commit):
>
> /usr/src/usr.bin/readelf/../../contrib/elftoolchain/readelf/readelf.c:4861:33:
> error: variable 'pe' may be uninitialized when used here
> [-Werror,-Wconditional-uninitialized]
> dirndx = _decode_uleb128(, pe);
> [...]
> I'll check if there is a specific reason upstream does not enable this
> warning by default for -Wall.  Maybe there is a risk of false positives.
>
> -Dimitry
>
>
I'm pretty sure I've seen lots of false positives from
-Wconditional-uninitialized in the krb5 and openafs codebases.  I either
set -Wno-error=conditional-uninitialized or -Wno-conditional-uninitialized
depending on how distracting they are in my build logs.

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r291860 - in head/tools/tools/nanobsd: . embedded

[Benjamin Kaduk]

On Sat, Dec 5, 2015 at 10:28 AM, Warner Losh  wrote:

> Author: imp
> Date: Sat Dec  5 16:28:14 2015
> New Revision: 291860
> URL: https://svnweb.freebsd.org/changeset/base/291860
>
> Log:
>   Stupid last minute changes: Add missing } and fi
>
>   Pointed out by: Howard Su
>
> Modified:
>   head/tools/tools/nanobsd/defaults.sh   (contents, props changed)
>   head/tools/tools/nanobsd/embedded/common
>
> Modified: head/tools/tools/nanobsd/defaults.sh
>
> ==
> --- head/tools/tools/nanobsd/defaults.shSat Dec  5 15:09:19 2015
>   (r291859)
> +++ head/tools/tools/nanobsd/defaults.shSat Dec  5 16:28:14 2015
>   (r291860)
> @@ -961,7 +961,7 @@ set_defaults_and_export ( ) {
> [ ! -d "${NANO_TOOLS}" ] && [ -d "${NANO_SRC}/${NANO_TOOLS}" ] && \
> NANO_TOOLS="${NANO_SRC}/${NANO_TOOLS}" || true
>
> -   [ ! -z "${NANO_NOPRIV_BUILD" ] && [ -z "${NANO_METALOG}"] && \
> +   [ ! -z "${NANO_NOPRIV_BUILD}" ] && [ -z "${NANO_METALOG}"] && \
>

Hmm, is there still a missing space between '"' and ']' in the second
clause?

-Ben


> NANO_METALOG=${NANO_OBJ}/_.metalog || true
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r291637 - head/cddl/contrib/opensolaris/cmd/plockstat

[Benjamin Kaduk]

On Tue, Dec 1, 2015 at 10:18 PM, Craig Rodrigues 
wrote:

> On Tue, Dec 1, 2015 at 6:11 PM, Bryan Drewery 
> wrote:
>
> > -   (void) snprintf(buf, size, "%#lx", addr);
> > +   (void) snprintf(buf, size, "%#lx", (unsigned long)addr);
> > return (0);
> >
>
> In the past when I've hit these types of problems,
> I have found that using %#jx and casting to (uintmax_t) instead seemed to
> work
> consistently across different platforms, so you might want to do that here.
> There are lots of examples in the tree of this pattern.
>

Any sort of cast will usually work, provided the casted-to type matches the
format string.
The main issue is when one tries to avoid a cast, in which case the
fundamental type corresponding to the abstract type of the variable being
printed can be different across different platforms.  (Some sense is needed
to ensure that the cast does not truncate the range of accessible values,
of course, which is where [u]intmax_t comes in.)

-Ben
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r291197 - head/lib/libc/stdio

[Benjamin Kaduk]

On Mon, Nov 23, 2015 at 6:47 AM, Dag-Erling Smørgrav 
wrote:

> Author: des
> Date: Mon Nov 23 12:47:08 2015
> New Revision: 291197
> URL: https://svnweb.freebsd.org/changeset/base/291197
>
> Log:
>   markup fixes
>
> Modified:
>   head/lib/libc/stdio/fopen.3
>
> Modified: head/lib/libc/stdio/fopen.3
>
> ==
> --- head/lib/libc/stdio/fopen.3 Mon Nov 23 12:19:36 2015(r291196)
> +++ head/lib/libc/stdio/fopen.3 Mon Nov 23 12:47:08 2015(r291197)
> @@ -120,7 +120,9 @@ This is strictly for compatibility with
>  .St -isoC
>  and has effect only for
>  .Fn fmemopen
> -; otherwise the ``b'' is ignored.
> +; otherwise
>

Hmm, I would have expected that the semicolon could go on the previous
line, as is normally
the case for punctuation following macros.  Is this not the case here?

-Ben


> +.Dq Li b
> +is ignored.
>  .Pp
>  Any created files will have mode
>  .Do Dv S_IRUSR
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r290259 - head/usr.sbin/makefs

[Benjamin Kaduk]

On Mon, Nov 2, 2015 at 1:36 AM, Garrett Cooper  wrote:

> Author: ngie
> Date: Mon Nov  2 07:36:42 2015
> New Revision: 290259
> URL: https://svnweb.freebsd.org/changeset/base/290259
>
> Log:
>   Sync makefs(8) content a bit with src/usr.sbin/makefs/makefs.8@1.53
>
>   Sections involving unimplemented filesystems (chfs, msdosfs, udf, v7fs)
> and
>   options have been omitted.
>
>   MFC after: 1 week
>   Obtained from: NetBSD
>   Sponsored by: EMC / Isilon Storage Division
>
> Modified:
>   head/usr.sbin/makefs/makefs.8
>
> Modified: head/usr.sbin/makefs/makefs.8
>
> ==
> --- head/usr.sbin/makefs/makefs.8   Mon Nov  2 03:36:15 2015
> (r290258)
> +++ head/usr.sbin/makefs/makefs.8   Mon Nov  2 07:36:42 2015
> (r290259)
> @@ -339,7 +341,7 @@ Load a generic boot image into the first
>  .It Sy hard-disk-boot
>  Boot image is a hard disk image.
>  .It Sy keep-bad-images
> -Do not throw away images whose write was aborted due to an error.
> +Don't throw away images whose write was aborted due to an error.
>

Documentation style is to not use contractions.  (Also, "discard" might be
better than "throw away", while you're on this line.)


>  For debugging purposes.
>  .It Sy label
>  Label name of the image.
> @@ -372,11 +374,12 @@ The
>  utility appeared in
>  .Nx 1.6 .
>  .Sh AUTHORS
> -.An Luke Mewburn Aq Mt lu...@netbsd.org
> -(original program)
> -.An Daniel Watt
> -.An Walter Deignan
> -.An Ryan Gabrys
> -.An Alan Perez-Rathke
> +.An Luke Mewburn
> +.Aq lu...@netbsd.org
>

mdoc(7) itself lists An ... Aq ... on the same line; please do not split
them like this.

-Ben


> +(original program),
> +.An Daniel Watt ,
> +.An Walter Deignan ,
> +.An Ryan Gabrys ,
> +.An Alan Perez-Rathke ,
>  .An Ram Vedam
>  (cd9660 support)
> ___
> svn-src-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"