Re: svn commit: r345171 - head/usr.sbin/bhyve

[Conrad Meyer]

On Thu, Mar 14, 2019 at 8:06 PM Andrew Thompson  wrote:
>
> On Fri, 15 Mar 2019 at 15:11, Chuck Tuffli  wrote:
>> bzero(, sizeof(pciecap));
...
>> +   pciecap.dev_capabilities = PCIEM_CAP_ROLE_ERR_RPT;
>
> If the message you say 'set the bit' but you are overwriting the whole 
> variable, is this intended?

Looks like it was zero before.  So yeah, it sets the bit.
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Enji Cooper]

Before all of the uuencoded files get decoded in the tree.. are we sure that 
non-uuencoded binary files will be proper identified if the mime type is 
nonexistent in svn? What about other VCSes like hg?

I’m asking, because not all downstream vendors have the newest versions of svn, 
once upon a time, may have mashed mime types, etc, which may have interesting 
downstream effects if the binary type isn’t detected properly.

Thank you,
-Enji
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Enji Cooper]

> On Mar 14, 2019, at 20:26, Warner Losh  wrote:
> 
> 
> 
>> On Thu, Mar 14, 2019 at 9:14 PM Ed Maste  wrote:
>> On Thu, 14 Mar 2019 at 22:46, Warner Losh  wrote:
>> >
>> > Libarchive tests and a few bzip2 files are all that is left in contrib. 
>> > All can be converted without hassle from what I can see.
>> 
>> But these (libarchive at least) are uuencoded in the upstream repo,
>> and we won't make a local change to undo that. Perhaps libarchive's
>> upstream developers will decide that there's no need to uuencode the
>> test files any longer, though
> 
> Fair enough, I didn't check upstream. I'd have thought that libarchive was 
> new enough, but I concur: if they are upstream that way, then it's fine. So 
> it looks like we're down to a few stragglers that are still uuencoded, but we 
> don't need to do that any more. And there's hundreds of files in the tree 
> that are binaries already.

Libarchive implements uuencode file type detection, FYI.
-Enji
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Warner Losh]

On Thu, Mar 14, 2019 at 9:36 PM Rodney W. Grimes 
wrote:

> [ Charset UTF-8 unsupported, converting... ]
> > On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes
> >  wrote:
> > >
> > > 4. There is no easy way to show
> > >"changed byte at offset 0x432 from 0xef to 0xfe"
>
> How do we represent Copyright and License in such objects?
> This is an issue that is totally left out of even .uu version.
>

By indirect means. Usually an auxiliary file that describes permissions,
when we bother at all.

Warner


> > But this is not that easy with uuencoded files, either - I'd just end
> > up uudecoding both files before running cmp -x. And for the case under
> > discussion here (firmware files) we treat them as opaque binary
> > objects; comparing them is generally not interesting anyway.
> >
> > > Do we have a decent binary diff and binary patch tool?
> >
> > We have bsdiff and bspatch, but their output is not designed for human
> > consumption or editing.
> >
>
> --
> Rod Grimes
> rgri...@freebsd.org
>
>
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Warner Losh]

On Thu, Mar 14, 2019 at 9:31 PM Ed Maste  wrote:

> On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes
>  wrote:
> >
> > 4. There is no easy way to show
> >"changed byte at offset 0x432 from 0xef to 0xfe"
>
> But this is not that easy with uuencoded files, either - I'd just end
> up uudecoding both files before running cmp -x. And for the case under
> discussion here (firmware files) we treat them as opaque binary
> objects; comparing them is generally not interesting anyway.
>

All binaries in the tree are versioned opaque objects. #4 isn't a use case
we care about, nor is it something we can to today.


> > Do we have a decent binary diff and binary patch tool?
>
> We have bsdiff and bspatch, but their output is not designed for human
> consumption or editing.
>

IIRC, git also has a way to transition from one binary to another in an
externalized fashion.

Warner
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes
>  wrote:
> >
> > 4. There is no easy way to show
> >"changed byte at offset 0x432 from 0xef to 0xfe"

How do we represent Copyright and License in such objects?
This is an issue that is totally left out of even .uu version.


> But this is not that easy with uuencoded files, either - I'd just end
> up uudecoding both files before running cmp -x. And for the case under
> discussion here (firmware files) we treat them as opaque binary
> objects; comparing them is generally not interesting anyway.
> 
> > Do we have a decent binary diff and binary patch tool?
> 
> We have bsdiff and bspatch, but their output is not designed for human
> consumption or editing.
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Ed Maste]

On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes
 wrote:
>
> 4. There is no easy way to show
>"changed byte at offset 0x432 from 0xef to 0xfe"

But this is not that easy with uuencoded files, either - I'd just end
up uudecoding both files before running cmp -x. And for the case under
discussion here (firmware files) we treat them as opaque binary
objects; comparing them is generally not interesting anyway.

> Do we have a decent binary diff and binary patch tool?

We have bsdiff and bspatch, but their output is not designed for human
consumption or editing.
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Warner Losh]

On Thu, Mar 14, 2019 at 9:14 PM Ed Maste  wrote:

> On Thu, 14 Mar 2019 at 22:46, Warner Losh  wrote:
> >
> > Libarchive tests and a few bzip2 files are all that is left in contrib.
> All can be converted without hassle from what I can see.
>
> But these (libarchive at least) are uuencoded in the upstream repo,
> and we won't make a local change to undo that. Perhaps libarchive's
> upstream developers will decide that there's no need to uuencode the
> test files any longer, though


Fair enough, I didn't check upstream. I'd have thought that libarchive was
new enough, but I concur: if they are upstream that way, then it's fine. So
it looks like we're down to a few stragglers that are still uuencoded, but
we don't need to do that any more. And there's hundreds of files in the
tree that are binaries already.
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Ed Maste]

On Thu, 14 Mar 2019 at 22:46, Warner Losh  wrote:
>
> Libarchive tests and a few bzip2 files are all that is left in contrib. All 
> can be converted without hassle from what I can see.

But these (libarchive at least) are uuencoded in the upstream repo,
and we won't make a local change to undo that. Perhaps libarchive's
upstream developers will decide that there's no need to uuencode the
test files any longer, though.
___
svn-src-all@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"

Re: svn commit: r345171 - head/usr.sbin/bhyve

[Andrew Thompson]

On Fri, 15 Mar 2019 at 15:11, Chuck Tuffli  wrote:

> Author: chuck
> Date: Fri Mar 15 02:11:28 2019
> New Revision: 345171
> URL: https://svnweb.freebsd.org/changeset/base/345171
>
> Log:
>   Fix bhyve PCIe capability emulation
>
>   PCIe devices starting with version 1.1 must set the Role-Based Error
>   Reporting bit.
>
>   And while we're in the neighborhood, generalize the code assigning the
>   device type.
>
>   Reviewed by:  imp, araujo, rgrimes
>   Approved by:  imp (mentor)
>   MFC after:1 week
>   Differential Revision: https://reviews.freebsd.org/D19580
>
> Modified:
>   head/usr.sbin/bhyve/pci_emul.c
>
> Modified: head/usr.sbin/bhyve/pci_emul.c
>
> ==
> --- head/usr.sbin/bhyve/pci_emul.c  Fri Mar 15 02:11:27 2019
> (r345170)
> +++ head/usr.sbin/bhyve/pci_emul.c  Fri Mar 15 02:11:28 2019
> (r345171)
> @@ -953,7 +953,10 @@ pci_emul_add_pciecap(struct pci_devinst *pi, int type)
> bzero(, sizeof(pciecap));
>
> pciecap.capid = PCIY_EXPRESS;
> -   pciecap.pcie_capabilities = PCIECAP_VERSION | PCIEM_TYPE_ROOT_PORT;
> +   pciecap.pcie_capabilities = PCIECAP_VERSION | type;
> +   /* Devices starting with version 1.1 must set the RBER bit */
> +   if (PCIECAP_VERSION >= 1)
> +   pciecap.dev_capabilities = PCIEM_CAP_ROLE_ERR_RPT;
> pciecap.link_capabilities = 0x411;  /* gen1, x1 */
> pciecap.link_status = 0x11; /* gen1, x1 */
>

If the message you say 'set the bit' but you are overwriting the whole
variable, is this intended?


Andrew
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Ed Maste]

On Thu, 14 Mar 2019 at 22:34, Rodney W. Grimes
 wrote:
>
> > We definitely don't want to change files in contrib/ - that's up to
> > the upstreams.
>
> I think you miss understood, I belive in the paste, and possibly even
> still, that prep work was done to vendor code before import.  We use
> to have shell scripts and such to deal with things like having to
> .uu files, remove stuff you dont want, etc.

Ah, I did misunderstand what you meant. Those sorts of
scripts/processes are unique per vendor tree; uuencoding steps could
be removed from any that have it (along with changes to our build
infrastructure). I have a subset of the vendor tree checked out
locally and none of the FreeBSD-Upgrade files I have reference
uuencoding -- but I did not check everything. Note that we already
have several vendor src trees that have verbatim binary files - for
one example, contrib/file/tests/JW07022A.mp3.testfile.

> I suspect some of that is inplace and we probably do not want to just
> undo it without some careful thought.

Fair point; I would leave process changes for vendor/contrib to the
individual maintainers.
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Warner Losh]

On Thu, Mar 14, 2019, 8:35 PM Rodney W. Grimes 
wrote:

> > On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes
> >  wrote:
> > >
> > > Covered this in my reply to Warners reply.  I think we also need to
> > > look at how this might affect vendor imported stuff, is there some if
> > > it that was .uu'ed before import?
> >
> > We definitely don't want to change files in contrib/ - that's up to
> > the upstreams.
>
> I think you miss understood, I belive in the paste, and possibly even
> still, that prep work was done to vendor code before import.  We use
> to have shell scripts and such to deal with things like having to
> .uu files, remove stuff you dont want, etc.
>
> I suspect some of that is inplace and we probably do not want to just
> undo it without some careful thought.
>

Libarchive tests and a few bzip2 files are all that is left in contrib. All
can be converted without hassle from what I can see. Anything that used to
be done seems to be gone. Sys/config only has firmware in it, none of which
is native format. Some of which can be converted, but there are build fixes
that would be needed too.

Warner


> --
> Rod Grimes
> rgri...@freebsd.org
>
>
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Rodney W. Grimes]

> On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes
>  wrote:
> >
> > > The reason not to do it is uuencoding adds about a 40% space penalty,
> > > adds to the build time (to uudecode), and makes changes harder to
> > > review. In my mind dropping the unnecessary uuencoding is similar to
> > > dropping build-time patching of files in the source tree (another
> > > workaround we used to have for limitations of our older VCS).
> >
> > I think I covered all the above in other replies.
> 
> So:
> 1. We used to use a VCS which does not support binary files well, but
> have not used it for years.
> 2. Another source delivery tool (ctm) previously did not support
> binary files, but has for some time.
> 3. There may have been other reasons, but none that anyone can recall
> (at present).

4. There is no easy way to show
   "changed byte at offset 0x432 from 0xef to 0xfe"

So far, that looks right.
Do we have a decent binary diff and binary patch tool?

> > > Yes, we should look at the other cases where we unnecessarily uuencode
> > > things. I'm not quite sure where we would document high level things
> > > like this though, do you have a suggestion?  I could see a case for
> > > somewhat similra topics (e.g. 7-bit ASCII/UTF-8/ISO-8859 guidance)
> > > fitting into style.9, but I'm not sure this one does.
> >
> > I think the committers guide, which needs a revamp.  That
> > should also cover the 7-bit/...
> 
> Probably, yes. That said, I'm very much in favour of having the
> documentation in the tree itself, for those topics pertaining to the
> software in that tree (e.g. style(9), ports(7), development(7),
> arch(7)).

I do not have much problem with it being multiple places,
so long as they are all cross referenced either directly
in words, or at least in markup comments so that when one
place is changed the others are too.

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Ed Maste]

On Thu, 14 Mar 2019 at 22:05, Rodney W. Grimes
 wrote:
>
> How do the tools today deal with taking a binary off the vendor branch?
> Isn't this still a for-ever night mare merge thing to deal with?

There isn't really the concept of taking a file off the vendor branch
in the same way as with CVS, although it's still prudent to limit
changes to vendor/contrib files to avoid conflicts during future
imports.

Modifying binary contrib files is a different matter, but that would
be difficult to deal with regardless of whether they're uuencoded or
not. Anyway, I'm not aware of us having done that before.
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Rodney W. Grimes]

> On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes
>  wrote:
> >
> > Covered this in my reply to Warners reply.  I think we also need to
> > look at how this might affect vendor imported stuff, is there some if
> > it that was .uu'ed before import?
> 
> We definitely don't want to change files in contrib/ - that's up to
> the upstreams.

I think you miss understood, I belive in the paste, and possibly even
still, that prep work was done to vendor code before import.  We use
to have shell scripts and such to deal with things like having to
.uu files, remove stuff you dont want, etc.

I suspect some of that is inplace and we probably do not want to just
undo it without some careful thought.


-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@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"

Re: svn commit: r345171 - head/usr.sbin/bhyve

[Rodney W. Grimes]

> Author: chuck
> Date: Fri Mar 15 02:11:28 2019
> New Revision: 345171
> URL: https://svnweb.freebsd.org/changeset/base/345171
> 
> Log:
>   Fix bhyve PCIe capability emulation
>   
>   PCIe devices starting with version 1.1 must set the Role-Based Error
>   Reporting bit.
>   
>   And while we're in the neighborhood, generalize the code assigning the
>   device type.
>   
>   Reviewed by:imp, araujo, rgrimes
>   Approved by:imp (mentor)
>   MFC after:  1 week
>   Differential Revision: https://reviews.freebsd.org/D19580

This code requires maintainer approval before a commit,
though this was well reviewed that doesnt exclude it
from the MAINTAINERS entry.

Leave it for now, I am sure jhb or thyco are fine with it,
this is just a heads up FYI for future commits.

Bhyve code has been and still is under a fairly tight
MAINTAINER status.

> Modified:
>   head/usr.sbin/bhyve/pci_emul.c
> 
> Modified: head/usr.sbin/bhyve/pci_emul.c
> ==
> --- head/usr.sbin/bhyve/pci_emul.cFri Mar 15 02:11:27 2019
> (r345170)
> +++ head/usr.sbin/bhyve/pci_emul.cFri Mar 15 02:11:28 2019
> (r345171)
> @@ -953,7 +953,10 @@ pci_emul_add_pciecap(struct pci_devinst *pi, int type)
>   bzero(, sizeof(pciecap));
>  
>   pciecap.capid = PCIY_EXPRESS;
> - pciecap.pcie_capabilities = PCIECAP_VERSION | PCIEM_TYPE_ROOT_PORT;
> + pciecap.pcie_capabilities = PCIECAP_VERSION | type;
> + /* Devices starting with version 1.1 must set the RBER bit */
> + if (PCIECAP_VERSION >= 1)
> + pciecap.dev_capabilities = PCIEM_CAP_ROLE_ERR_RPT;
>   pciecap.link_capabilities = 0x411;  /* gen1, x1 */
>   pciecap.link_status = 0x11; /* gen1, x1 */
>  
> 
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@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"

Re: svn commit: r345168 - head/share/misc

[Rodney W. Grimes]

> Author: ygy (doc committer)
> Date: Fri Mar 15 00:20:28 2019
> New Revision: 345168
> URL: https://svnweb.freebsd.org/changeset/base/345168
> 
> Log:
>   Add myself to committers-doc.dot.
>   
>   Reminded by:rgrimes

Thank you

> Modified:
>   head/share/misc/committers-doc.dot
> 
> Modified: head/share/misc/committers-doc.dot
> ==
> --- head/share/misc/committers-doc.dotThu Mar 14 23:05:59 2019
> (r345167)
> +++ head/share/misc/committers-doc.dotFri Mar 15 00:20:28 2019
> (r345168)
> @@ -92,6 +92,7 @@ skreuzer [label="Steven Kreuzer\nskreu...@freebsd.org\
>  taras [label="Taras Korenko\nta...@freebsd.org\n2010/06/25"]
>  trhodes [label="Tom Rhodes\ntrho...@freebsd.org\n2002/03/25"]
>  wblock [label="Warren Block\nwbl...@freebsd.org\n2011/09/12"]
> +ygy [label="Guangyuan Yang\n...@freebsd.org\n2017/09/18"]
>  zeising [label="Niclas Zeising\nzeis...@freebsd.org\n2012/07/03"]
>  
>  # Here are the mentor/mentee relationships.
> 
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Ed Maste]

On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes
 wrote:
>
> > The reason not to do it is uuencoding adds about a 40% space penalty,
> > adds to the build time (to uudecode), and makes changes harder to
> > review. In my mind dropping the unnecessary uuencoding is similar to
> > dropping build-time patching of files in the source tree (another
> > workaround we used to have for limitations of our older VCS).
>
> I think I covered all the above in other replies.

So:
1. We used to use a VCS which does not support binary files well, but
have not used it for years.
2. Another source delivery tool (ctm) previously did not support
binary files, but has for some time.
3. There may have been other reasons, but none that anyone can recall
(at present).

> > Yes, we should look at the other cases where we unnecessarily uuencode
> > things. I'm not quite sure where we would document high level things
> > like this though, do you have a suggestion?  I could see a case for
> > somewhat similra topics (e.g. 7-bit ASCII/UTF-8/ISO-8859 guidance)
> > fitting into style.9, but I'm not sure this one does.
>
> I think the committers guide, which needs a revamp.  That
> should also cover the 7-bit/...

Probably, yes. That said, I'm very much in favour of having the
documentation in the tree itself, for those topics pertaining to the
software in that tree (e.g. style(9), ports(7), development(7),
arch(7)).
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Ed Maste]

On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes
 wrote:
>
> Covered this in my reply to Warners reply.  I think we also need to
> look at how this might affect vendor imported stuff, is there some if
> it that was .uu'ed before import?

We definitely don't want to change files in contrib/ - that's up to
the upstreams.
___
svn-src-all@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 commit: r345170 - head/usr.sbin/bhyve

[Chuck Tuffli]

Author: chuck
Date: Fri Mar 15 02:11:27 2019
New Revision: 345170
URL: https://svnweb.freebsd.org/changeset/base/345170

Log:
  Fix bhyve's NVMe Identify Namespace data
  
  The NVMe Identify Namespace data structure's Number of LBA Formats
  (NLBAF) field is a 0's based value (i.e. 0x0 means 1). Since the
  emulation only supports a single format, set NLBAF to 0x0, not 1.
  
  Reviewed by:  imp, araujo, rgrimes
  Approved by:  imp (mentor)
  MFC after:  1 week
  Differential Revision: https://reviews.freebsd.org/D19579

Modified:
  head/usr.sbin/bhyve/pci_nvme.c

Modified: head/usr.sbin/bhyve/pci_nvme.c
==
--- head/usr.sbin/bhyve/pci_nvme.c  Fri Mar 15 01:26:10 2019
(r345169)
+++ head/usr.sbin/bhyve/pci_nvme.c  Fri Mar 15 02:11:27 2019
(r345170)
@@ -358,7 +358,7 @@ pci_nvme_init_nsdata(struct pci_nvme_softc *sc)
nd->nuse = nd->nsze;
 
/* Get LBA and backstore information from backing store */
-   nd->nlbaf = 1;
+   nd->nlbaf = 0; /* NLBAF is a 0's based value (i.e. 1 LBA Format) */
/* LBA data-sz = 2^lbads */
nd->lbaf[0] = sc->nvstore.sectsz_bits << NVME_NS_DATA_LBAF_LBADS_SHIFT;
 
___
svn-src-all@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 commit: r345171 - head/usr.sbin/bhyve

[Chuck Tuffli]

Author: chuck
Date: Fri Mar 15 02:11:28 2019
New Revision: 345171
URL: https://svnweb.freebsd.org/changeset/base/345171

Log:
  Fix bhyve PCIe capability emulation
  
  PCIe devices starting with version 1.1 must set the Role-Based Error
  Reporting bit.
  
  And while we're in the neighborhood, generalize the code assigning the
  device type.
  
  Reviewed by:  imp, araujo, rgrimes
  Approved by:  imp (mentor)
  MFC after:1 week
  Differential Revision: https://reviews.freebsd.org/D19580

Modified:
  head/usr.sbin/bhyve/pci_emul.c

Modified: head/usr.sbin/bhyve/pci_emul.c
==
--- head/usr.sbin/bhyve/pci_emul.c  Fri Mar 15 02:11:27 2019
(r345170)
+++ head/usr.sbin/bhyve/pci_emul.c  Fri Mar 15 02:11:28 2019
(r345171)
@@ -953,7 +953,10 @@ pci_emul_add_pciecap(struct pci_devinst *pi, int type)
bzero(, sizeof(pciecap));
 
pciecap.capid = PCIY_EXPRESS;
-   pciecap.pcie_capabilities = PCIECAP_VERSION | PCIEM_TYPE_ROOT_PORT;
+   pciecap.pcie_capabilities = PCIECAP_VERSION | type;
+   /* Devices starting with version 1.1 must set the RBER bit */
+   if (PCIECAP_VERSION >= 1)
+   pciecap.dev_capabilities = PCIEM_CAP_ROLE_ERR_RPT;
pciecap.link_capabilities = 0x411;  /* gen1, x1 */
pciecap.link_status = 0x11; /* gen1, x1 */
 
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Warner Losh]

On Thu, Mar 14, 2019, 7:38 PM Rodney W. Grimes 
wrote:

> > I think maybe there was also a limitation on the
> (repo-replication-over-email?) mechanism that we used to use? That rings a
> very faint bell for me for some reason, even though I'm pretty sure it was
> dead long before I got my bit.
>
> CTM is still in use today, in a recent action to depricate it in base
> it was found that there are infact users, and users who wish to maintain
> it.  I do not know of CTM is impacted by this, that group would need
> to respond.
>

CTM  handles binaries just fine these days. We have dozens of binaries in
the tree already. In the 90s there was an issue, but that was fixed well
before we migrated to subversion.

Warner

>
> > -Ravi (rpokala@)
> >
> > ?-Original Message-
> > From:  on behalf of Ed Maste <
> ema...@freebsd.org>
> > Date: 2019-03-14, Thursday at 12:21
> > To: "Rodney W. Grimes" 
> > Cc: src-committers , <
> svn-src-all@freebsd.org>, 
> > Subject: Re: svn commit: r345138 - head/share/man/man9
> >
> > On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
> >  wrote:
> > >
> > > [ Charset UTF-8 unsupported, converting... ]
> > > > Author: emaste
> > > > Date: Thu Mar 14 17:09:07 2019
> > > > New Revision: 345138
> > > > URL: https://svnweb.freebsd.org/changeset/base/345138
> > > >
> > > > Log:
> > > >   firmware(9): remove uuencoded example
> > > >
> > > >   We can (should) just commit the binary files to the source tree.
> > >
> > > This change could use wider discussion.
> >
> > If you or others have a reason to prefer having uuencoded files in the
> > src tree I'll happily revert. I was aware only of CVS limitations as a
> > reason for uuencoding.
> That was only one of the reasons IIRC.
>
> > We have many binary files in the tree already (e.g. GIF PNG and JPEG
> > images, ELF and PE32 binaries, Berkeley DB files, and various
> > compressed formats). I count 430 uuencoded files in the tree, with 328
> > of those coming from libarchive and 64 from sys/*/dev/
>
> Why didnt you also count the "binary" files in the tree?
> Where are they?
>
> --
> Rod Grimes
> rgri...@freebsd.org
>
>
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Rodney W. Grimes]

> On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
>  wrote:
> >
> > We should of documented what the decision process and criteria was
> > that lead to the decission to uuencode the files.
> 
> Doing some archaeology, the first instance of a uuencoded file I can
> find is r1796, "Got rid of a couple of binary files by uuencoding.  49
> more to go." There's no explanation of why the change was made.
> Evidence suggests that in 1994 it was just accepted as impossible or
> not permitted to have binary files in the tree, but this has not been
> the case for quite some time.
> 
> > Thus we could easily revist that criteria, see how much of it no
> > longer applies, possible add counter criteria, and change this
> > decision, with it documented as to why it changed.
> 
> With none of this documented anywhere I'm going to rely on oral
> history from you, phk, or other FreeBSD committers active in the mid
> 90s to provide guidance on what we can revisit and what to check if it
> no longer applies.
> 
> The reason not to do it is uuencoding adds about a 40% space penalty,
> adds to the build time (to uudecode), and makes changes harder to
> review. In my mind dropping the unnecessary uuencoding is similar to
> dropping build-time patching of files in the source tree (another
> workaround we used to have for limitations of our older VCS).

I think I covered all the above in other replies.

> > As is this is just another semi documented project guideline change,
> > I believe there are more than just the firmware files that this
> > change needs noted on.
> 
> Yes, we should look at the other cases where we unnecessarily uuencode
> things. I'm not quite sure where we would document high level things
> like this though, do you have a suggestion?  I could see a case for
> somewhat similra topics (e.g. 7-bit ASCII/UTF-8/ISO-8859 guidance)
> fitting into style.9, but I'm not sure this one does.

I think the committers guide, which needs a revamp.  That
should also cover the 7-bit/...

> > We should also note that if they are already in uuencode state
> > to leave them in uuencode state, or do we intened to convert
> > them on next commit, or ???
> 
> Good point, converting existing .uu files to binary is just
> unnecessary churn and is not recommended. If someone is going to make
> a change it can be done with the next update.

Covered this in my reply to Warners reply.  I think we also need to
look at how this might affect vendor imported stuff, is there some if
it that was .uu'ed before import?

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Rodney W. Grimes]

> On Thu, Mar 14, 2019 at 3:43 PM Ed Maste  wrote:
> 
> > On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
> >  wrote:
> > >
> > > We should of documented what the decision process and criteria was
> > > that lead to the decission to uuencode the files.
> >
> > Doing some archaeology, the first instance of a uuencoded file I can
> > find is r1796, "Got rid of a couple of binary files by uuencoding.  49
> > more to go." There's no explanation of why the change was made.
> > Evidence suggests that in 1994 it was just accepted as impossible or
> > not permitted to have binary files in the tree, but this has not been
> > the case for quite some time.
> >
> 
> CVS had issues with them. sup had issues with them (remember sup?). CTM
> originally didn't cope but does now (not sure when that changed).

Diff and patch had issues with them, and still do?

> By the time I joined in 95 or so, it was already part of the oral
> tradition. It was all over the mailing lists and just something you were
> expected to know. I even have a recollection of people screwing up and
> there being CVS repo surgery to remove the binary version and bring forward
> only the .uu versions. But that was 20ish years ago, so I'm not certain.

Yes, there was some cvs admin and/or rm's done, not exactly repo surgery,
which did occur on other types of repairs, some very poorly.

> > > Thus we could easily revist that criteria, see how much of it no
> > > longer applies, possible add counter criteria, and change this
> > > decision, with it documented as to why it changed.
> >
> > With none of this documented anywhere I'm going to rely on oral
> > history from you, phk, or other FreeBSD committers active in the mid
> > 90s to provide guidance on what we can revisit and what to check if it
> > no longer applies.
> >
> 
> It no longer applies. svn copes well, git copes well, perforce coped well
> (though not too relevant these days).
> 
> IIRC, there used to be something about it in the CVS section of one of the
> handbook chapters, but all that stuff was removed a long time ago and may
> be hard to find today.
This rings a bell.

> > The reason not to do it is uuencoding adds about a 40% space penalty,
> > adds to the build time (to uudecode), and makes changes harder to
> > review. In my mind dropping the unnecessary uuencoding is similar to
> > dropping build-time patching of files in the source tree (another
> > workaround we used to have for limitations of our older VCS).
> >
> 
> Yes. Bringing a file off a vendor branch was generally greeted with much
> gnashing of teeth and much bile. And for good reason: the person taking it
> off the vendor branch was trivial, but it caused real and lasting conflicts
> for every single new import after that. The pain was real, and borne by the
> maintainer, not by the taker-off-the-brancher.

How do the tools today deal with taking a binary off the vendor branch?
Isn't this still a for-ever night mare merge thing to deal with?

> > > As is this is just another semi documented project guideline change,
> > > I believe there are more than just the firmware files that this
> > > change needs noted on.
> >
> > Yes, we should look at the other cases where we unnecessarily uuencode
> > things. I'm not quite sure where we would document high level things
> > like this though, do you have a suggestion?  I could see a case for
> > somewhat similra topics (e.g. 7-bit ASCII/UTF-8/ISO-8859 guidance)
> > fitting into style.9, but I'm not sure this one does.
> >
> 
> This feels more like committer guide material, not style.9 to me. The
> committer guide is showing its age and collection of random detritus that
> we need to reorganize and update. This is one of the many issues.

I agree on location, in or near the committers guide.  It may be
time to expand that to have a procedures section (how to vendor import,
how to MFC, etc), and a guidelines section (commit messages, must/should/
can/shall not etc)

> 
> 
> > > We should also note that if they are already in uuencode state
> > > to leave them in uuencode state, or do we intened to convert
> > > them on next commit, or ???
> >
> > Good point, converting existing .uu files to binary is just
> > unnecessary churn and is not recommended. If someone is going to make
> > a change it can be done with the next update.
> >
> 
> I'd convert them when there's some other reason to handle them. I'm not
> swayed by the churn argument, but more because there's little gain here, at
> the moment, and it would take someone's time. But if someone takes the
> time, I wouldn't stand in the way.

Agree, and that is probably all the document should say on that subject.

> Warner
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@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"

Re: svn commit: r345158 - head/usr.sbin/bhyve

[Ed Maste]

On Thu, 14 Mar 2019 at 21:51, Marcelo Araujo  wrote:
>
> So there is some license concern around this patch, core@ reverted my first 
> attempt to import this patch from Illumos.

Conrad wrote the patch based on the description I posted on twitter,
it's not imported from anywhere.

However, I was not aware of the history here, and with a patch already
accepted in review we should take it; although the description of the
bug and the patch itself are both trivial there was clearly a
substantial effort involved in taking the bug to root cause.
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Rodney W. Grimes]

> 
> In message 
> 
> , Ed Maste writes:
> >On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
> 
> >Doing some archaeology, the first instance of a uuencoded file I can
> >find is r1796, "Got rid of a couple of binary files by uuencoding.  49
> >more to go." There's no explanation of why the change was made.
> 
> I am pretty sure that we discussed the question of binary files in
> the tree on either core@ or hackers@ (not much difference back
> then), but that probably predates the "Dont mount the projects mail
> archives on /tmp/something" incident.
It would of been hackers@, this would of not been a core discussion.

> The first versions of CTM used diff -e and ed(1) to transmit changes,
> and that choked up on binary files.  We didn't have patch in the
> tree back then.
patch has always been in the tree.
https://github.com/sergev/4.4BSD-Lite2/tree/master/usr/src/usr.bin/patch

> 
> I can't answer definitively if modern CTM has any such restrictions,
> but I would not expect so, either way, it should not matter.
Warner said in another reply it does not, but this should be
listed in the decision criteral, with a "not effected or
formally effected" state.
 
> >> We should also note that if they are already in uuencode state
> >> to leave them in uuencode state, or do we intened to convert
> >> them on next commit, or ???
> >
> >Good point, converting existing .uu files to binary is just
> >unnecessary churn and is not recommended. If someone is going to make
> >a change it can be done with the next update.
> 
> Agreed.

So is it leave them forever .uu, on next import/whatever bring
in the binary and remove the .uu, Or ?

> p...@freebsd.org | TCP/IP since RFC 956
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@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"

Re: svn commit: r345158 - head/usr.sbin/bhyve

[Marcelo Araujo]

Em sex, 15 de mar de 2019 às 05:09, Conrad Meyer  escreveu:

> Author: cem
> Date: Thu Mar 14 21:08:48 2019
> New Revision: 345158
> URL: https://svnweb.freebsd.org/changeset/base/345158
>
> Log:
>   bhyve(8): Fix uart emulation bug
>
>   THRE is always asserted in LSR reads, so REG_IER writes that raise
>   IER_ETXRDY must also set thre_int_pending.
>
>   Reported by:  Illumos, according to emaste@
> https://twitter.com/ed_maste/status/1106195949087584258
>   MFC after:2 weeks
>
> Modified:
>   head/usr.sbin/bhyve/uart_emul.c
>
> Modified: head/usr.sbin/bhyve/uart_emul.c
>
> ==
> --- head/usr.sbin/bhyve/uart_emul.c Thu Mar 14 20:32:48 2019
> (r345157)
> +++ head/usr.sbin/bhyve/uart_emul.c Thu Mar 14 21:08:48 2019
> (r345158)
> @@ -431,6 +431,9 @@ uart_write(struct uart_softc *sc, int offset, uint8_t
> sc->thre_int_pending = true;
> break;
> case REG_IER:
> +   /* Set pending when IER_ETXRDY is raised (edge-triggered).
> */
> +   if ((sc->ier & IER_ETXRDY) == 0 && (value & IER_ETXRDY) !=
> 0)
> +   sc->thre_int_pending = true;
> /*
>  * Apply mask so that bits 4-7 are 0
>  * Also enables bits 0-3 only if they're 1
>
>
Hi cem@,

FYI: https://svnweb.freebsd.org/base?view=revision=344057

So there is some license concern around this patch, core@ reverted my first
attempt to import this patch from Illumos.

I guess core@ will ping you soon to do the same.

There is a review made by the Illumos guys:
https://reviews.freebsd.org/D19499
Pending now bhyve maintainer to approve it.

Dark days, we had 2 committers trying to fix the same thing and our hands
are tied.


Best,
-- 

-- 
Marcelo Araujo(__)ara...@freebsd.org
\\\'',)http://www.FreeBSD.org    \/  \ ^
Power To Server. .\. /_)
___
svn-src-all@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"

Re: svn commit: r345158 - head/usr.sbin/bhyve

[Rodney W. Grimes]

> Author: cem
> Date: Thu Mar 14 21:08:48 2019
> New Revision: 345158
> URL: https://svnweb.freebsd.org/changeset/base/345158
> 
> Log:
>   bhyve(8): Fix uart emulation bug
>   
>   THRE is always asserted in LSR reads, so REG_IER writes that raise
>   IER_ETXRDY must also set thre_int_pending.
>   
>   Reported by:Illumos, according to emaste@
>   https://twitter.com/ed_maste/status/1106195949087584258
>   MFC after:  2 weeks

Per MAINTAINERS this should of had a formal review.
And this is already in process from Patrick Mooney
via the bhyve developemnt group.
Revert this please.


> Modified:
>   head/usr.sbin/bhyve/uart_emul.c
> 
> Modified: head/usr.sbin/bhyve/uart_emul.c
> ==
> --- head/usr.sbin/bhyve/uart_emul.c   Thu Mar 14 20:32:48 2019
> (r345157)
> +++ head/usr.sbin/bhyve/uart_emul.c   Thu Mar 14 21:08:48 2019
> (r345158)
> @@ -431,6 +431,9 @@ uart_write(struct uart_softc *sc, int offset, uint8_t 
>   sc->thre_int_pending = true;
>   break;
>   case REG_IER:
> + /* Set pending when IER_ETXRDY is raised (edge-triggered). */
> + if ((sc->ier & IER_ETXRDY) == 0 && (value & IER_ETXRDY) != 0)
> + sc->thre_int_pending = true;
>   /*
>* Apply mask so that bits 4-7 are 0
>* Also enables bits 0-3 only if they're 1

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Rodney W. Grimes]

> I think maybe there was also a limitation on the 
> (repo-replication-over-email?) mechanism that we used to use? That rings a 
> very faint bell for me for some reason, even though I'm pretty sure it was 
> dead long before I got my bit.

CTM is still in use today, in a recent action to depricate it in base
it was found that there are infact users, and users who wish to maintain
it.  I do not know of CTM is impacted by this, that group would need
to respond.

> 
> -Ravi (rpokala@)
> 
> ?-Original Message-
> From:  on behalf of Ed Maste 
> 
> Date: 2019-03-14, Thursday at 12:21
> To: "Rodney W. Grimes" 
> Cc: src-committers , , 
> 
> Subject: Re: svn commit: r345138 - head/share/man/man9
> 
> On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
>  wrote:
> >
> > [ Charset UTF-8 unsupported, converting... ]
> > > Author: emaste
> > > Date: Thu Mar 14 17:09:07 2019
> > > New Revision: 345138
> > > URL: https://svnweb.freebsd.org/changeset/base/345138
> > >
> > > Log:
> > >   firmware(9): remove uuencoded example
> > >
> > >   We can (should) just commit the binary files to the source tree.
> >
> > This change could use wider discussion.
> 
> If you or others have a reason to prefer having uuencoded files in the
> src tree I'll happily revert. I was aware only of CVS limitations as a
> reason for uuencoding.
That was only one of the reasons IIRC.

> We have many binary files in the tree already (e.g. GIF PNG and JPEG
> images, ELF and PE32 binaries, Berkeley DB files, and various
> compressed formats). I count 430 uuencoded files in the tree, with 328
> of those coming from libarchive and 64 from sys/*/dev/

Why didnt you also count the "binary" files in the tree?
Where are they?

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@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 commit: r345169 - stable/12/sys/sys

[Matt Macy]

Author: mmacy
Date: Fri Mar 15 01:26:10 2019
New Revision: 345169
URL: https://svnweb.freebsd.org/changeset/base/345169

Log:
  bump version to reflect MFC of CCM for the benefit of the ZoF port
  
  Sponsored by: iX Systems

Modified:
  stable/12/sys/sys/param.h

Modified: stable/12/sys/sys/param.h
==
--- stable/12/sys/sys/param.h   Fri Mar 15 00:20:28 2019(r345168)
+++ stable/12/sys/sys/param.h   Fri Mar 15 01:26:10 2019(r345169)
@@ -60,7 +60,7 @@
  * in the range 5 to 9.
  */
 #undef __FreeBSD_version
-#define __FreeBSD_version 1200503  /* Master, propagated to newvers */
+#define __FreeBSD_version 1200504  /* Master, propagated to newvers */
 
 /*
  * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD,
___
svn-src-all@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 commit: r345168 - head/share/misc

[Guangyuan Yang]

Author: ygy (doc committer)
Date: Fri Mar 15 00:20:28 2019
New Revision: 345168
URL: https://svnweb.freebsd.org/changeset/base/345168

Log:
  Add myself to committers-doc.dot.
  
  Reminded by:  rgrimes

Modified:
  head/share/misc/committers-doc.dot

Modified: head/share/misc/committers-doc.dot
==
--- head/share/misc/committers-doc.dot  Thu Mar 14 23:05:59 2019
(r345167)
+++ head/share/misc/committers-doc.dot  Fri Mar 15 00:20:28 2019
(r345168)
@@ -92,6 +92,7 @@ skreuzer [label="Steven Kreuzer\nskreu...@freebsd.org\
 taras [label="Taras Korenko\nta...@freebsd.org\n2010/06/25"]
 trhodes [label="Tom Rhodes\ntrho...@freebsd.org\n2002/03/25"]
 wblock [label="Warren Block\nwbl...@freebsd.org\n2011/09/12"]
+ygy [label="Guangyuan Yang\n...@freebsd.org\n2017/09/18"]
 zeising [label="Niclas Zeising\nzeis...@freebsd.org\n2012/07/03"]
 
 # Here are the mentor/mentee relationships.
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Warner Losh]

On Thu, Mar 14, 2019 at 3:43 PM Ed Maste  wrote:

> On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
>  wrote:
> >
> > We should of documented what the decision process and criteria was
> > that lead to the decission to uuencode the files.
>
> Doing some archaeology, the first instance of a uuencoded file I can
> find is r1796, "Got rid of a couple of binary files by uuencoding.  49
> more to go." There's no explanation of why the change was made.
> Evidence suggests that in 1994 it was just accepted as impossible or
> not permitted to have binary files in the tree, but this has not been
> the case for quite some time.
>

CVS had issues with them. sup had issues with them (remember sup?). CTM
originally didn't cope but does now (not sure when that changed).

By the time I joined in 95 or so, it was already part of the oral
tradition. It was all over the mailing lists and just something you were
expected to know. I even have a recollection of people screwing up and
there being CVS repo surgery to remove the binary version and bring forward
only the .uu versions. But that was 20ish years ago, so I'm not certain.


> > Thus we could easily revist that criteria, see how much of it no
> > longer applies, possible add counter criteria, and change this
> > decision, with it documented as to why it changed.
>
> With none of this documented anywhere I'm going to rely on oral
> history from you, phk, or other FreeBSD committers active in the mid
> 90s to provide guidance on what we can revisit and what to check if it
> no longer applies.
>

It no longer applies. svn copes well, git copes well, perforce coped well
(though not too relevant these days).

IIRC, there used to be something about it in the CVS section of one of the
handbook chapters, but all that stuff was removed a long time ago and may
be hard to find today.


> The reason not to do it is uuencoding adds about a 40% space penalty,
> adds to the build time (to uudecode), and makes changes harder to
> review. In my mind dropping the unnecessary uuencoding is similar to
> dropping build-time patching of files in the source tree (another
> workaround we used to have for limitations of our older VCS).
>

Yes. Bringing a file off a vendor branch was generally greeted with much
gnashing of teeth and much bile. And for good reason: the person taking it
off the vendor branch was trivial, but it caused real and lasting conflicts
for every single new import after that. The pain was real, and borne by the
maintainer, not by the taker-off-the-brancher.


> > As is this is just another semi documented project guideline change,
> > I believe there are more than just the firmware files that this
> > change needs noted on.
>
> Yes, we should look at the other cases where we unnecessarily uuencode
> things. I'm not quite sure where we would document high level things
> like this though, do you have a suggestion?  I could see a case for
> somewhat similra topics (e.g. 7-bit ASCII/UTF-8/ISO-8859 guidance)
> fitting into style.9, but I'm not sure this one does.
>

This feels more like committer guide material, not style.9 to me. The
committer guide is showing its age and collection of random detritus that
we need to reorganize and update. This is one of the many issues.


> > We should also note that if they are already in uuencode state
> > to leave them in uuencode state, or do we intened to convert
> > them on next commit, or ???
>
> Good point, converting existing .uu files to binary is just
> unnecessary churn and is not recommended. If someone is going to make
> a change it can be done with the next update.
>

I'd convert them when there's some other reason to handle them. I'm not
swayed by the churn argument, but more because there's little gain here, at
the moment, and it would take someone's time. But if someone takes the
time, I wouldn't stand in the way.

Warner
___
svn-src-all@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"

Re: svn commit: r332100 - in head: . lib/libc/gen sys/sys

[Oliver Pinter]

On Friday, April 6, 2018, Ed Schouten  wrote:

> Author: ed
> Date: Fri Apr  6 13:00:45 2018
> New Revision: 332100
> URL: https://svnweb.freebsd.org/changeset/base/332100
>
> Log:
>   Let syslog(3) use RFC 5424.
>
>   With r332099 changing syslogd(8) to parse RFC 5424 formatted syslog
>   messages, go ahead and also change the syslog(3) libc function to
>   generate them. Compared to RFC 3164, RFC 5424 has various advantages,
>   such as sub-second precision for log entry timestamps.
>
>   As this change could have adverse effects when not updating syslogd(8)
>   or using a different system logging daemon, add a notice to UPDATING and
>   increase __FreeBSD_version.
>
>   Differential Revision:https://reviews.freebsd.org/D14926


+= relnotes = yes


>
> Modified:
>   head/UPDATING
>   head/lib/libc/gen/syslog.3
>   head/lib/libc/gen/syslog.c
>   head/sys/sys/param.h
>
> Modified: head/UPDATING
> 
> ==
> --- head/UPDATING   Fri Apr  6 12:57:01 2018(r332099)
> +++ head/UPDATING   Fri Apr  6 13:00:45 2018(r332100)
> @@ -51,6 +51,45 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12.x IS SLOW:
>
>  ** SPECIAL WARNING:
> **
>
> +20180406:
> +   In addition to supporting RFC 3164 formatted messages, the
> +   syslogd(8) service is now capable of parsing RFC 5424 formatted
> +   log messages. The main benefit of using RFC 5424 is that clients
> +   may now send log messages with timestamps containing year numbers,
> +   microseconds and time zone offsets.
> +
> +   Similarly, the syslog(3) C library function has been altered to
> +   send RFC 5424 formatted messages to the local system logging
> +   daemon. On systems using syslogd(8), this change should have no
> +   negative impact, as long as syslogd(8) and the C library are
> +   updated at the same time. On systems using a different system
> +   logging daemon, it may be necessary to make configuration
> +   adjustments, depending on the software used.
> +
> +   When using syslog-ng, add the 'syslog-protocol' flag to local
> +   input sources to enable parsing of RFC 5424 formatted messages:
> +
> +   source src {
> +   unix-dgram("/var/run/log" flags(syslog-protocol));
> +   }
> +
> +   When using rsyslog, disable the 'SysSock.UseSpecialParser' option
> +   of the 'imuxsock' module to let messages be processed by the
> +   regular RFC 3164/5424 parsing pipeline:
> +
> +   module(load="imuxsock" SysSock.UseSpecialParser="off")
> +
> +   Do note that these changes only affect communication between local
> +   applications and syslogd(8). The format that syslogd(8) uses to
> +   store messages on disk or forward messages to other systems
> +   remains unchanged. syslogd(8) still uses RFC 3164 for these
> +   purposes. Options to customize this behaviour will be added in the
> +   future. Utilities that process log files stored in /var/log are
> +   thus expected to continue to function as before.
> +
> +   __FreeBSD_version has been incremented to 1200061 to denote this
> +   change.
> +
>  20180328:
> Support for token ring networks has been removed. If you
> have "device token" in your kernel config you should remove
>
> Modified: head/lib/libc/gen/syslog.3
> 
> ==
> --- head/lib/libc/gen/syslog.3  Fri Apr  6 12:57:01 2018(r332099)
> +++ head/lib/libc/gen/syslog.3  Fri Apr  6 13:00:45 2018(r332100)
> @@ -28,7 +28,7 @@
>  .\" @(#)syslog.3   8.1 (Berkeley) 6/4/93
>  .\" $FreeBSD$
>  .\"
> -.Dd November 5, 2017
> +.Dd April 6, 2018
>  .Dt SYSLOG 3
>  .Os
>  .Sh NAME
> @@ -156,6 +156,9 @@ Write the message to standard error output as well to
>  .It Dv LOG_PID
>  Log the process id with each message: useful for identifying
>  instantiations of daemons.
> +On
> +.Fx ,
> +this option is enabled by default.
>  .El
>  .Pp
>  The
>
> Modified: head/lib/libc/gen/syslog.c
> 
> ==
> --- head/lib/libc/gen/syslog.c  Fri Apr  6 12:57:01 2018(r332099)
> +++ head/lib/libc/gen/syslog.c  Fri Apr  6 13:00:45 2018(r332100)
> @@ -36,9 +36,10 @@ static char sccsid[] = "@(#)syslog.c 8.5 (Berkeley) 4/
>  __FBSDID("$FreeBSD$");
>
>  #include "namespace.h"
> -#include 
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -134,11 +135,13 @@ syslog(int pri, const char *fmt, ...)
>  static void
>  vsyslog1(int pri, const char *fmt, va_list ap)
>  {
> -   int cnt;
> +   struct timeval now;
> +   struct tm tm;
> char ch, *p;
> -   time_t now;
> -   int fd, saved_errno;
> -   char *stdp, tbuf[2048], 

svn commit: r345166 - head/sys/netpfil/ipfw

[Gleb Smirnoff]

Author: glebius
Date: Thu Mar 14 22:52:16 2019
New Revision: 345166
URL: https://svnweb.freebsd.org/changeset/base/345166

Log:
  PFIL_MEMPTR for ipfw link level hook
  
  With new pfil(9) KPI it is possible to pass a void pointer with length
  instead of mbuf pointer to a packet filter. Until this commit no filters
  supported that, so pfil run through a shim function pfil_fake_mbuf().
  
  Now the ipfw(4) hook named "default-link", that is instantiated when
  net.link.ether.ipfw sysctl is on, supports processing pointer/length
  packets natively.
  
  - ip_fw_args now has union for either mbuf or void *, and if flags have
non-zero length, then we use the void *.
  - through ipfw_chk() we handle mem/mbuf cases differently.
  - ether_header goes away from args. It is ipfw_chk() responsibility
to do parsing of Ethernet header.
  - ipfw_log() now uses different bpf APIs to log packets.
  
  Although ipfw_chk() is now capable to process pointer/length packets,
  this commit adds support for the link level hook only, see
  ipfw_check_frame(). Potentially the IP processing hook ipfw_check_packet()
  can be improved too, but that requires more changes since the hook
  supports more complex actions: NAT, divert, etc.
  
  Reviewed by:  ae
  Differential Revision:https://reviews.freebsd.org/D19357

Modified:
  head/sys/netpfil/ipfw/ip_fw2.c
  head/sys/netpfil/ipfw/ip_fw_bpf.c
  head/sys/netpfil/ipfw/ip_fw_log.c
  head/sys/netpfil/ipfw/ip_fw_pfil.c
  head/sys/netpfil/ipfw/ip_fw_private.h

Modified: head/sys/netpfil/ipfw/ip_fw2.c
==
--- head/sys/netpfil/ipfw/ip_fw2.c  Thu Mar 14 22:32:50 2019
(r345165)
+++ head/sys/netpfil/ipfw/ip_fw2.c  Thu Mar 14 22:52:16 2019
(r345166)
@@ -1258,7 +1258,6 @@ jump_linear(struct ip_fw_chain *chain, struct ip_fw *f
  *
  * args->m (in/out) The packet; we set to NULL when/if we nuke it.
  * Starts with the IP header.
- * args->eh (in)   Mac header if present, NULL for layer3 packet.
  * args->L3offset  Number of bytes bypassed if we came from L2.
  * e.g. often sizeof(eh)  ** NOTYET **
  * args->ifp   Incoming or outgoing interface.
@@ -1297,23 +1296,19 @@ ipfw_chk(struct ip_fw_args *args)
 * the implementation of the various instructions to make sure
 * that they still work.
 *
-* args->eh The MAC header. It is non-null for a layer2
-*  packet, it is NULL for a layer-3 packet.
-* **notyet**
-* args->L3offset Offset in the packet to the L3 (IP or equiv.) header.
-*
 * m | args->m  Pointer to the mbuf, as received from the caller.
 *  It may change if ipfw_chk() does an m_pullup, or if it
 *  consumes the packet because it calls send_reject().
 *  XXX This has to change, so that ipfw_chk() never modifies
 *  or consumes the buffer.
-* ip   is the beginning of the ip(4 or 6) header.
-*  Calculated by adding the L3offset to the start of data.
-*  (Until we start using L3offset, the packet is
-*  supposed to start with the ip header).
+*  OR
+* args->memPointer to contigous memory chunk.
+* ip   Is the beginning of the ip(4 or 6) header.
+* eh   Ethernet header in case if input is Layer2.
 */
-   struct mbuf *m = args->m;
-   struct ip *ip = mtod(m, struct ip *);
+   struct mbuf *m;
+   struct ip *ip;
+   struct ether_header *eh;
 
/*
 * For rules which contain uid/gid or jail constraints, cache
@@ -1370,7 +1365,6 @@ ipfw_chk(struct ip_fw_args *args)
struct in_addr src_ip, dst_ip;  /* NOTE: network format */
int iplen = 0;
int pktlen;
-   uint16_t etype; /* Host order stored ether type */
 
struct ipfw_dyn_info dyn_info;
struct ip_fw *q = NULL;
@@ -1394,14 +1388,45 @@ ipfw_chk(struct ip_fw_args *args)
 
int done = 0;   /* flag to exit the outer loop */
IPFW_RLOCK_TRACKER;
+   bool mem;
 
-   if (m->m_flags & M_SKIP_FIREWALL || (! V_ipfw_vnet_ready))
-   return (IP_FW_PASS);/* accept */
+   if ((mem = (args->flags & IPFW_ARGS_LENMASK))) {
+   if (args->flags & IPFW_ARGS_ETHER) {
+   eh = (struct ether_header *)args->mem;
+   if (eh->ether_type == htons(ETHERTYPE_VLAN))
+   ip = (struct ip *)
+   ((struct ether_vlan_header *)eh + 1);
+   else
+   ip = (struct ip *)(eh + 1);
+   } else {
+   eh = NULL;
+   ip = (struct ip *)args->mem;
+   }
+   pktlen = IPFW_ARGS_LENGTH(args->flags);
+   args->f_id.fib = 

Re: svn commit: r345138 - head/share/man/man9

[Poul-Henning Kamp]

In message 
, Ed Maste writes:
>On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes

>Doing some archaeology, the first instance of a uuencoded file I can
>find is r1796, "Got rid of a couple of binary files by uuencoding.  49
>more to go." There's no explanation of why the change was made.

I am pretty sure that we discussed the question of binary files in
the tree on either core@ or hackers@ (not much difference back
then), but that probably predates the "Dont mount the projects mail
archives on /tmp/something" incident.

The first versions of CTM used diff -e and ed(1) to transmit changes,
and that choked up on binary files.  We didn't have patch in the
tree back then.

I can't answer definitively if modern CTM has any such restrictions,
but I would not expect so, either way, it should not matter.

>> We should also note that if they are already in uuencode state
>> to leave them in uuencode state, or do we intened to convert
>> them on next commit, or ???
>
>Good point, converting existing .uu files to binary is just
>unnecessary churn and is not recommended. If someone is going to make
>a change it can be done with the next update.

Agreed.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
svn-src-all@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 commit: r345165 - in head/sys: netinet netpfil/ipfw

[Gleb Smirnoff]

Author: glebius
Date: Thu Mar 14 22:32:50 2019
New Revision: 345165
URL: https://svnweb.freebsd.org/changeset/base/345165

Log:
  Remove 'dir' argument from dummynet_io(). This makes it possible to make
  dn_dir flags private to dummynet. There is still some room for improvement.

Modified:
  head/sys/netinet/ip_var.h
  head/sys/netinet/raw_ip.c
  head/sys/netpfil/ipfw/ip_dn_io.c
  head/sys/netpfil/ipfw/ip_dn_private.h
  head/sys/netpfil/ipfw/ip_fw2.c
  head/sys/netpfil/ipfw/ip_fw_pfil.c
  head/sys/netpfil/ipfw/ip_fw_private.h

Modified: head/sys/netinet/ip_var.h
==
--- head/sys/netinet/ip_var.h   Thu Mar 14 22:31:12 2019(r345164)
+++ head/sys/netinet/ip_var.h   Thu Mar 14 22:32:50 2019(r345165)
@@ -296,7 +296,7 @@ extern void (*ip_divert_ptr)(struct mbuf *m, bool inco
 /* ng_ipfw hooks -- XXX make it the same as divert and dummynet */
 extern int (*ng_ipfw_input_p)(struct mbuf **, struct ip_fw_args *, bool);
 extern int (*ip_dn_ctl_ptr)(struct sockopt *);
-extern int (*ip_dn_io_ptr)(struct mbuf **, int, struct ip_fw_args *);
+extern int (*ip_dn_io_ptr)(struct mbuf **, struct ip_fw_args *);
 #endif /* _KERNEL */
 
 #endif /* !_NETINET_IP_VAR_H_ */

Modified: head/sys/netinet/raw_ip.c
==
--- head/sys/netinet/raw_ip.c   Thu Mar 14 22:31:12 2019(r345164)
+++ head/sys/netinet/raw_ip.c   Thu Mar 14 22:32:50 2019(r345165)
@@ -100,7 +100,7 @@ VNET_DEFINE(ip_fw_chk_ptr_t, ip_fw_chk_ptr) = NULL;
 VNET_DEFINE(ip_fw_ctl_ptr_t, ip_fw_ctl_ptr) = NULL;
 
 int(*ip_dn_ctl_ptr)(struct sockopt *);
-int(*ip_dn_io_ptr)(struct mbuf **, int, struct ip_fw_args *);
+int(*ip_dn_io_ptr)(struct mbuf **, struct ip_fw_args *);
 void   (*ip_divert_ptr)(struct mbuf *, bool);
 int(*ng_ipfw_input_p)(struct mbuf **, struct ip_fw_args *, bool);
 

Modified: head/sys/netpfil/ipfw/ip_dn_io.c
==
--- head/sys/netpfil/ipfw/ip_dn_io.cThu Mar 14 22:31:12 2019
(r345164)
+++ head/sys/netpfil/ipfw/ip_dn_io.cThu Mar 14 22:32:50 2019
(r345165)
@@ -854,22 +854,27 @@ tag_mbuf(struct mbuf *m, int dir, struct ip_fw_args *f
  * We use the argument to locate the flowset fs and the sched_set sch
  * associated to it. The we apply flow_mask and sched_mask to
  * determine the queue and scheduler instances.
- *
- * dir where shall we send the packet after dummynet.
- * *m0 the mbuf with the packet
- * ifp the 'ifp' parameter from the caller.
- * NULL in ip_input, destination interface in ip_output,
  */
 int
-dummynet_io(struct mbuf **m0, int dir, struct ip_fw_args *fwa)
+dummynet_io(struct mbuf **m0, struct ip_fw_args *fwa)
 {
struct mbuf *m = *m0;
struct dn_fsk *fs = NULL;
struct dn_sch_inst *si;
struct dn_queue *q = NULL;  /* default */
+   int fs_id, dir;
 
-   int fs_id = (fwa->rule.info & IPFW_INFO_MASK) +
+   fs_id = (fwa->rule.info & IPFW_INFO_MASK) +
((fwa->rule.info & IPFW_IS_PIPE) ? 2*DN_MAX_ID : 0);
+   /* XXXGL: convert args to dir */
+   if (fwa->flags & IPFW_ARGS_IN)
+   dir = DIR_IN;
+   else
+   dir = DIR_OUT;
+   if (fwa->flags & IPFW_ARGS_ETHER)
+   dir |= PROTO_LAYER2;
+   else if (fwa->flags & IPFW_ARGS_IP6)
+   dir |= PROTO_IPV6;
DN_BH_WLOCK();
io_pkt++;
/* we could actually tag outside the lock, but who cares... */

Modified: head/sys/netpfil/ipfw/ip_dn_private.h
==
--- head/sys/netpfil/ipfw/ip_dn_private.h   Thu Mar 14 22:31:12 2019
(r345164)
+++ head/sys/netpfil/ipfw/ip_dn_private.h   Thu Mar 14 22:32:50 2019
(r345165)
@@ -387,11 +387,26 @@ struct dn_pkt_tag {
uint16_t iphdr_off; /* IP header offset for mtodo() */
 };
 
+/*
+ * Possible values for dn_dir. XXXGL: this needs to be reviewed
+ * and converted to same values ip_fw_args.flags use.
+ */
+enum {
+   DIR_OUT =   0,
+   DIR_IN =1,
+   DIR_FWD =   2,
+   DIR_DROP =  3,
+   PROTO_LAYER2 =  0x4, /* set for layer 2 */
+   PROTO_IPV4 =0x08,
+   PROTO_IPV6 =0x10,
+   PROTO_IFB = 0x0c, /* layer2 + ifbridge */
+};
+
 extern struct dn_parms dn_cfg;
 //VNET_DECLARE(struct dn_parms, _base_dn_cfg);
 //#define dn_cfg   VNET(_base_dn_cfg)
 
-int dummynet_io(struct mbuf **, int , struct ip_fw_args *);
+int dummynet_io(struct mbuf **, struct ip_fw_args *);
 void dummynet_task(void *context, int pending);
 void dn_reschedule(void);
 struct dn_pkt_tag * dn_tag_get(struct mbuf *m);

Modified: head/sys/netpfil/ipfw/ip_fw2.c
==
--- 

svn commit: r345164 - head/sys/netpfil/ipfw

[Gleb Smirnoff]

Author: glebius
Date: Thu Mar 14 22:31:12 2019
New Revision: 345164
URL: https://svnweb.freebsd.org/changeset/base/345164

Log:
  Reduce argument list to ipfw_divert(), as args holds the rule ref and
  the direction. While here make 'tee' a bool.

Modified:
  head/sys/netpfil/ipfw/ip_fw_pfil.c

Modified: head/sys/netpfil/ipfw/ip_fw_pfil.c
==
--- head/sys/netpfil/ipfw/ip_fw_pfil.c  Thu Mar 14 22:30:05 2019
(r345163)
+++ head/sys/netpfil/ipfw/ip_fw_pfil.c  Thu Mar 14 22:31:12 2019
(r345164)
@@ -85,7 +85,7 @@ VNET_DEFINE_STATIC(int, fwlink_enable) = 0;
 int ipfw_chg_hook(SYSCTL_HANDLER_ARGS);
 
 /* Forward declarations. */
-static int ipfw_divert(struct mbuf **, bool, struct ipfw_rule_ref *, int);
+static int ipfw_divert(struct mbuf **, struct ip_fw_args *, bool);
 
 #ifdef SYSCTL_NODE
 
@@ -281,8 +281,7 @@ again:
break;
}
MPASS(args.flags & IPFW_ARGS_REF);
-   (void )ipfw_divert(m0, dir == DIR_IN, ,
-   (ipfw == IP_FW_TEE) ? 1 : 0);
+   (void )ipfw_divert(m0, , ipfw == IP_FW_TEE);
/* continue processing for the original packet (tee). */
if (*m0)
goto again;
@@ -441,8 +440,7 @@ again:
 
 /* do the divert, return 1 on error 0 on success */
 static int
-ipfw_divert(struct mbuf **m0, bool incoming, struct ipfw_rule_ref *rule,
-   int tee)
+ipfw_divert(struct mbuf **m0, struct ip_fw_args *args, bool tee)
 {
/*
 * ipfw_chk() has already tagged the packet with the divert tag.
@@ -454,7 +452,7 @@ ipfw_divert(struct mbuf **m0, bool incoming, struct ip
struct m_tag *tag;
 
/* Cloning needed for tee? */
-   if (tee == 0) {
+   if (tee == false) {
clone = *m0;/* use the original mbuf */
*m0 = NULL;
} else {
@@ -474,7 +472,7 @@ ipfw_divert(struct mbuf **m0, bool incoming, struct ip
 * Note that we now have the 'reass' ipfw option so if we care
 * we can do it before a 'tee'.
 */
-   if (!tee) switch (ip->ip_v) {
+   if (tee == false) switch (ip->ip_v) {
case IPVERSION:
if (ntohs(ip->ip_off) & (IP_MF | IP_OFFMASK)) {
int hlen;
@@ -523,11 +521,11 @@ ipfw_divert(struct mbuf **m0, bool incoming, struct ip
FREE_PKT(clone);
return 1;
}
-   *((struct ipfw_rule_ref *)(tag+1)) = *rule;
+   *((struct ipfw_rule_ref *)(tag+1)) = args->rule;
m_tag_prepend(clone, tag);
 
/* Do the dirty job... */
-   ip_divert_ptr(clone, incoming);
+   ip_divert_ptr(clone, args->flags & IPFW_ARGS_IN);
return 0;
 }
 
___
svn-src-all@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 commit: r345163 - in head/sys: netgraph netinet netpfil/ipfw

[Gleb Smirnoff]

Author: glebius
Date: Thu Mar 14 22:30:05 2019
New Revision: 345163
URL: https://svnweb.freebsd.org/changeset/base/345163

Log:
  Remove 'dir' argument in ng_ipfw_input, since ip_fw_args now has this info.
  While here make 'tee' boolean.

Modified:
  head/sys/netgraph/ng_ipfw.c
  head/sys/netinet/ip_var.h
  head/sys/netinet/raw_ip.c
  head/sys/netpfil/ipfw/ip_fw_pfil.c

Modified: head/sys/netgraph/ng_ipfw.c
==
--- head/sys/netgraph/ng_ipfw.c Thu Mar 14 22:28:50 2019(r345162)
+++ head/sys/netgraph/ng_ipfw.c Thu Mar 14 22:30:05 2019(r345163)
@@ -72,8 +72,7 @@ static ng_rcvdata_t   ng_ipfw_rcvdata;
 static ng_disconnect_t ng_ipfw_disconnect;
 
 static hook_p  ng_ipfw_findhook1(node_p, u_int16_t );
-static int ng_ipfw_input(struct mbuf **, int, struct ip_fw_args *,
-   int);
+static int ng_ipfw_input(struct mbuf **, struct ip_fw_args *, bool);
 
 /* We have only one node */
 static node_p  fw_node;
@@ -285,7 +284,7 @@ ng_ipfw_rcvdata(hook_p hook, item_p item)
 }
 
 static int
-ng_ipfw_input(struct mbuf **m0, int dir, struct ip_fw_args *fwa, int tee)
+ng_ipfw_input(struct mbuf **m0, struct ip_fw_args *fwa, bool tee)
 {
struct mbuf *m;
hook_p  hook;
@@ -303,7 +302,7 @@ ng_ipfw_input(struct mbuf **m0, int dir, struct ip_fw_
 * important to return packet back to IP stack. In tee mode we make
 * a copy of a packet and forward it into netgraph without a tag.
 */
-   if (tee == 0) {
+   if (tee == false) {
struct m_tag *tag;
struct ipfw_rule_ref *r;
m = *m0;
@@ -318,7 +317,8 @@ ng_ipfw_input(struct mbuf **m0, int dir, struct ip_fw_
r = (struct ipfw_rule_ref *)(tag + 1);
*r = fwa->rule;
r->info &= IPFW_ONEPASS;  /* keep this info */
-   r->info |= dir ? IPFW_INFO_IN : IPFW_INFO_OUT;
+   r->info |= (fwa->flags & IPFW_ARGS_IN) ?
+   IPFW_INFO_IN : IPFW_INFO_OUT;
m_tag_prepend(m, tag);
 
} else

Modified: head/sys/netinet/ip_var.h
==
--- head/sys/netinet/ip_var.h   Thu Mar 14 22:28:50 2019(r345162)
+++ head/sys/netinet/ip_var.h   Thu Mar 14 22:30:05 2019(r345163)
@@ -294,9 +294,7 @@ VNET_DECLARE(ip_fw_ctl_ptr_t, ip_fw_ctl_ptr);
 /* Divert hooks. */
 extern void(*ip_divert_ptr)(struct mbuf *m, bool incoming);
 /* ng_ipfw hooks -- XXX make it the same as divert and dummynet */
-extern int (*ng_ipfw_input_p)(struct mbuf **, int,
-   struct ip_fw_args *, int);
-
+extern int (*ng_ipfw_input_p)(struct mbuf **, struct ip_fw_args *, bool);
 extern int (*ip_dn_ctl_ptr)(struct sockopt *);
 extern int (*ip_dn_io_ptr)(struct mbuf **, int, struct ip_fw_args *);
 #endif /* _KERNEL */

Modified: head/sys/netinet/raw_ip.c
==
--- head/sys/netinet/raw_ip.c   Thu Mar 14 22:28:50 2019(r345162)
+++ head/sys/netinet/raw_ip.c   Thu Mar 14 22:30:05 2019(r345163)
@@ -102,8 +102,7 @@ VNET_DEFINE(ip_fw_ctl_ptr_t, ip_fw_ctl_ptr) = NULL;
 int(*ip_dn_ctl_ptr)(struct sockopt *);
 int(*ip_dn_io_ptr)(struct mbuf **, int, struct ip_fw_args *);
 void   (*ip_divert_ptr)(struct mbuf *, bool);
-int(*ng_ipfw_input_p)(struct mbuf **, int,
-   struct ip_fw_args *, int);
+int(*ng_ipfw_input_p)(struct mbuf **, struct ip_fw_args *, bool);
 
 #ifdef INET
 /*

Modified: head/sys/netpfil/ipfw/ip_fw_pfil.c
==
--- head/sys/netpfil/ipfw/ip_fw_pfil.c  Thu Mar 14 22:28:50 2019
(r345162)
+++ head/sys/netpfil/ipfw/ip_fw_pfil.c  Thu Mar 14 22:30:05 2019
(r345163)
@@ -296,8 +296,7 @@ again:
break;
}
MPASS(args.flags & IPFW_ARGS_REF);
-   (void )ng_ipfw_input_p(m0, dir, ,
-   (ipfw == IP_FW_NGTEE) ? 1 : 0);
+   (void )ng_ipfw_input_p(m0, , ipfw == IP_FW_NGTEE);
if (ipfw == IP_FW_NGTEE) /* ignore errors for NGTEE */
goto again; /* continue with packet */
ret = PFIL_CONSUMED;
@@ -421,8 +420,7 @@ again:
break;
}
MPASS(args.flags & IPFW_ARGS_REF);
-   (void )ng_ipfw_input_p(m0, (dir & PFIL_IN) ? DIR_IN : DIR_OUT,
-   , (i == IP_FW_NGTEE) ? 1 : 0);
+   (void )ng_ipfw_input_p(m0, , i == IP_FW_NGTEE);
if (i == IP_FW_NGTEE) /* ignore errors for NGTEE */
goto again; /* continue with packet */
ret = PFIL_CONSUMED;
___
svn-src-all@freebsd.org 

svn commit: r345162 - head/sys/netpfil/ipfw

[Gleb Smirnoff]

Author: glebius
Date: Thu Mar 14 22:28:50 2019
New Revision: 345162
URL: https://svnweb.freebsd.org/changeset/base/345162

Log:
  - Add more flags to ip_fw_args. At this changeset only IPFW_ARGS_IN and
IPFW_ARGS_OUT are utilized. They are intented to substitute the "dir"
parameter that is often passes together with args.
  - Rename ip_fw_args.oif to ifp and now it is set to either input or
output interface, depending on IPFW_ARGS_IN/OUT bit set.

Modified:
  head/sys/netpfil/ipfw/ip_dn_io.c
  head/sys/netpfil/ipfw/ip_fw2.c
  head/sys/netpfil/ipfw/ip_fw_dynamic.c
  head/sys/netpfil/ipfw/ip_fw_log.c
  head/sys/netpfil/ipfw/ip_fw_nat.c
  head/sys/netpfil/ipfw/ip_fw_pfil.c
  head/sys/netpfil/ipfw/ip_fw_private.h

Modified: head/sys/netpfil/ipfw/ip_dn_io.c
==
--- head/sys/netpfil/ipfw/ip_dn_io.cThu Mar 14 22:23:09 2019
(r345161)
+++ head/sys/netpfil/ipfw/ip_dn_io.cThu Mar 14 22:28:50 2019
(r345162)
@@ -841,7 +841,7 @@ tag_mbuf(struct mbuf *m, int dir, struct ip_fw_args *f
dt->rule = fwa->rule;
dt->rule.info &= IPFW_ONEPASS;  /* only keep this info */
dt->dn_dir = dir;
-   dt->ifp = fwa->oif;
+   dt->ifp = fwa->flags & IPFW_ARGS_OUT ? fwa->ifp : NULL;
/* dt->output tame is updated as we move through */
dt->output_time = dn_cfg.curr_time;
dt->iphdr_off = (dir & PROTO_LAYER2) ? ETHER_HDR_LEN : 0;

Modified: head/sys/netpfil/ipfw/ip_fw2.c
==
--- head/sys/netpfil/ipfw/ip_fw2.c  Thu Mar 14 22:23:09 2019
(r345161)
+++ head/sys/netpfil/ipfw/ip_fw2.c  Thu Mar 14 22:28:50 2019
(r345162)
@@ -1080,13 +1080,11 @@ check_uidgid(ipfw_insn_u32 *insn, struct ip_fw_args *a
struct inpcbinfo *pi;
struct ipfw_flow_id *id;
struct inpcb *pcb, *inp;
-   struct ifnet *oif;
int lookupflags;
int match;
 
id = >f_id;
inp = args->inp;
-   oif = args->oif;
 
/*
 * Check to see if the UDP or TCP stack supplied us with
@@ -1124,16 +1122,16 @@ check_uidgid(ipfw_insn_u32 *insn, struct ip_fw_args *a
if (*ugid_lookupp == 0) {
if (id->addr_type == 6) {
 #ifdef INET6
-   if (oif == NULL)
+   if (args->flags & IPFW_ARGS_IN)
pcb = in6_pcblookup_mbuf(pi,
>src_ip6, htons(id->src_port),
>dst_ip6, htons(id->dst_port),
-   lookupflags, oif, args->m);
+   lookupflags, NULL, args->m);
else
pcb = in6_pcblookup_mbuf(pi,
>dst_ip6, htons(id->dst_port),
>src_ip6, htons(id->src_port),
-   lookupflags, oif, args->m);
+   lookupflags, args->ifp, args->m);
 #else
*ugid_lookupp = -1;
return (0);
@@ -1141,16 +1139,16 @@ check_uidgid(ipfw_insn_u32 *insn, struct ip_fw_args *a
} else {
src_ip.s_addr = htonl(id->src_ip);
dst_ip.s_addr = htonl(id->dst_ip);
-   if (oif == NULL)
+   if (args->flags & IPFW_ARGS_IN)
pcb = in_pcblookup_mbuf(pi,
src_ip, htons(id->src_port),
dst_ip, htons(id->dst_port),
-   lookupflags, oif, args->m);
+   lookupflags, NULL, args->m);
else
pcb = in_pcblookup_mbuf(pi,
dst_ip, htons(id->dst_port),
src_ip, htons(id->src_port),
-   lookupflags, oif, args->m);
+   lookupflags, args->ifp, args->m);
}
if (pcb != NULL) {
INP_RLOCK_ASSERT(pcb);
@@ -1263,8 +1261,7 @@ jump_linear(struct ip_fw_chain *chain, struct ip_fw *f
  * args->eh (in)   Mac header if present, NULL for layer3 packet.
  * args->L3offset  Number of bytes bypassed if we came from L2.
  * e.g. often sizeof(eh)  ** NOTYET **
- * args->oif   Outgoing interface, NULL if packet is incoming.
- * The incoming interface is in the mbuf. (in)
+ * args->ifp   Incoming or outgoing interface.
  * args->divert_rule (in/out)
  * Skip up to the first rule past this rule number;
  * upon return, non-zero port number for divert or tee.
@@ -1331,17 +1328,9 @@ ipfw_chk(struct ip_fw_args *args)
struct ucred 

svn commit: r345161 - in head/sys: netinet netpfil/ipfw netpfil/pf

[Gleb Smirnoff]

Author: glebius
Date: Thu Mar 14 22:23:09 2019
New Revision: 345161
URL: https://svnweb.freebsd.org/changeset/base/345161

Log:
  Make second argument of ip_divert(), that specifies packet direction a bool.
  This allows pf(4) to avoid including ipfw(4) private files.

Modified:
  head/sys/netinet/ip_divert.c
  head/sys/netinet/ip_var.h
  head/sys/netinet/raw_ip.c
  head/sys/netpfil/ipfw/ip_fw_pfil.c
  head/sys/netpfil/pf/pf.c

Modified: head/sys/netinet/ip_divert.c
==
--- head/sys/netinet/ip_divert.cThu Mar 14 22:20:48 2019
(r345160)
+++ head/sys/netinet/ip_divert.cThu Mar 14 22:23:09 2019
(r345161)
@@ -184,7 +184,7 @@ div_input(struct mbuf **mp, int *offp, int proto)
  * then pass them along with mbuf chain.
  */
 static void
-divert_packet(struct mbuf *m, int incoming)
+divert_packet(struct mbuf *m, bool incoming)
 {
struct ip *ip;
struct inpcb *inp;

Modified: head/sys/netinet/ip_var.h
==
--- head/sys/netinet/ip_var.h   Thu Mar 14 22:20:48 2019(r345160)
+++ head/sys/netinet/ip_var.h   Thu Mar 14 22:23:09 2019(r345161)
@@ -292,7 +292,7 @@ VNET_DECLARE(ip_fw_ctl_ptr_t, ip_fw_ctl_ptr);
 #defineV_ip_fw_ctl_ptr VNET(ip_fw_ctl_ptr)
 
 /* Divert hooks. */
-extern void(*ip_divert_ptr)(struct mbuf *m, int incoming);
+extern void(*ip_divert_ptr)(struct mbuf *m, bool incoming);
 /* ng_ipfw hooks -- XXX make it the same as divert and dummynet */
 extern int (*ng_ipfw_input_p)(struct mbuf **, int,
struct ip_fw_args *, int);

Modified: head/sys/netinet/raw_ip.c
==
--- head/sys/netinet/raw_ip.c   Thu Mar 14 22:20:48 2019(r345160)
+++ head/sys/netinet/raw_ip.c   Thu Mar 14 22:23:09 2019(r345161)
@@ -101,7 +101,7 @@ VNET_DEFINE(ip_fw_ctl_ptr_t, ip_fw_ctl_ptr) = NULL;
 
 int(*ip_dn_ctl_ptr)(struct sockopt *);
 int(*ip_dn_io_ptr)(struct mbuf **, int, struct ip_fw_args *);
-void   (*ip_divert_ptr)(struct mbuf *, int);
+void   (*ip_divert_ptr)(struct mbuf *, bool);
 int(*ng_ipfw_input_p)(struct mbuf **, int,
struct ip_fw_args *, int);
 

Modified: head/sys/netpfil/ipfw/ip_fw_pfil.c
==
--- head/sys/netpfil/ipfw/ip_fw_pfil.c  Thu Mar 14 22:20:48 2019
(r345160)
+++ head/sys/netpfil/ipfw/ip_fw_pfil.c  Thu Mar 14 22:23:09 2019
(r345161)
@@ -85,7 +85,7 @@ VNET_DEFINE_STATIC(int, fwlink_enable) = 0;
 int ipfw_chg_hook(SYSCTL_HANDLER_ARGS);
 
 /* Forward declarations. */
-static int ipfw_divert(struct mbuf **, int, struct ipfw_rule_ref *, int);
+static int ipfw_divert(struct mbuf **, bool, struct ipfw_rule_ref *, int);
 
 #ifdef SYSCTL_NODE
 
@@ -282,7 +282,7 @@ again:
break;
}
MPASS(args.flags & IPFW_ARGS_REF);
-   (void )ipfw_divert(m0, dir, ,
+   (void )ipfw_divert(m0, dir == DIR_IN, ,
(ipfw == IP_FW_TEE) ? 1 : 0);
/* continue processing for the original packet (tee). */
if (*m0)
@@ -443,7 +443,7 @@ again:
 
 /* do the divert, return 1 on error 0 on success */
 static int
-ipfw_divert(struct mbuf **m0, int incoming, struct ipfw_rule_ref *rule,
+ipfw_divert(struct mbuf **m0, bool incoming, struct ipfw_rule_ref *rule,
int tee)
 {
/*

Modified: head/sys/netpfil/pf/pf.c
==
--- head/sys/netpfil/pf/pf.cThu Mar 14 22:20:48 2019(r345160)
+++ head/sys/netpfil/pf/pf.cThu Mar 14 22:23:09 2019(r345161)
@@ -91,8 +91,6 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 
-#include  /* XXX: only for DIR_IN/DIR_OUT */
-
 #ifdef INET6
 #include 
 #include 
@@ -6184,7 +6182,7 @@ done:
m->m_flags &= ~M_FASTFWD_OURS;
}
}
-   ip_divert_ptr(*m0, dir ==  PF_IN ? DIR_IN : DIR_OUT);
+   ip_divert_ptr(*m0, dir == PF_IN);
*m0 = NULL;
 
return (action);
___
svn-src-all@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 commit: r345160 - head/sys/netpfil/ipfw

[Gleb Smirnoff]

Author: glebius
Date: Thu Mar 14 22:20:48 2019
New Revision: 345160
URL: https://svnweb.freebsd.org/changeset/base/345160

Log:
  Simplify ipfw_bpf_mtap2(). No functional change.

Modified:
  head/sys/netpfil/ipfw/ip_fw_bpf.c

Modified: head/sys/netpfil/ipfw/ip_fw_bpf.c
==
--- head/sys/netpfil/ipfw/ip_fw_bpf.c   Thu Mar 14 22:08:09 2019
(r345159)
+++ head/sys/netpfil/ipfw/ip_fw_bpf.c   Thu Mar 14 22:20:48 2019
(r345160)
@@ -163,22 +163,27 @@ ipfwlog_clone_create(struct if_clone *ifc, int unit, c
 void
 ipfw_bpf_mtap2(void *data, u_int dlen, struct mbuf *m)
 {
+   struct ifnet *logif;
LOGIF_RLOCK_TRACKER;
 
LOGIF_RLOCK();
-   if (dlen == ETHER_HDR_LEN) {
-   if (V_log_if == NULL) {
-   LOGIF_RUNLOCK();
-   return;
-   }
-   BPF_MTAP2(V_log_if, data, dlen, m);
-   } else if (dlen == PFLOG_HDRLEN) {
-   if (V_pflog_if == NULL) {
-   LOGIF_RUNLOCK();
-   return;
-   }
-   BPF_MTAP2(V_pflog_if, data, dlen, m);
+   switch (dlen) {
+   case (ETHER_HDR_LEN):
+   logif = V_log_if;
+   break;
+   case (PFLOG_HDRLEN):
+   logif = V_pflog_if;
+   break;
+   default:
+#ifdef INVARIANTS
+   panic("%s: unsupported len %d", __func__, dlen);
+#endif
+   logif = NULL;
}
+
+   if (logif != NULL)
+   BPF_MTAP2(logif, data, dlen, m);
+
LOGIF_RUNLOCK();
 }
 
___
svn-src-all@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 commit: r345159 - head

[Emmanuel Vadot]

Author: manu
Date: Thu Mar 14 22:08:09 2019
New Revision: 345159
URL: https://svnweb.freebsd.org/changeset/base/345159

Log:
  pkgbase: Use uname as ABI_FILE
  
  uname is always rebuild on FreeBSD so use this as ABI_FILE for pkg when
  building pkg for pkgbase.
  pkg uses uname too as default ABI_FILE as of commit 
d8bbf980b7f6f424fb7cc672c23ab2dfc82b6599
  https://github.com/freebsd/pkg/commit/d8bbf980b7f6f424fb7cc672c23ab2dfc82b6599
  
  Discussed with:   bapt
  MFC after:1 week

Modified:
  head/Makefile.inc1

Modified: head/Makefile.inc1
==
--- head/Makefile.inc1  Thu Mar 14 21:08:48 2019(r345158)
+++ head/Makefile.inc1  Thu Mar 14 22:08:09 2019(r345159)
@@ -1864,11 +1864,11 @@ create-world-package-${pkgname}: .PHONY
@if [ "${pkgname}" == "runtime" ]; then \
sed -i '' -e "s/%VCS_REVISION%/${VCS_REVISION}/" 
${WSTAGEDIR}/${pkgname}.ucl ; \
fi
-   ${PKG_CMD} -o ABI_FILE=${WSTAGEDIR}/bin/sh -o ALLOW_BASE_SHLIBS=yes \
+   ${PKG_CMD} -o ABI_FILE=${WSTAGEDIR}/usr/bin/uname -o 
ALLOW_BASE_SHLIBS=yes \
create -M ${WSTAGEDIR}/${pkgname}.ucl \
-p ${WSTAGEDIR}/${pkgname}.plist \
-r ${WSTAGEDIR} \
-   -o ${REPODIR}/$$(${PKG_CMD} -o ABI_FILE=${WSTAGEDIR}/bin/sh 
config ABI)/${PKG_VERSION}
+   -o ${REPODIR}/$$(${PKG_CMD} -o 
ABI_FILE=${WSTAGEDIR}/usr/bin/uname config ABI)/${PKG_VERSION}
 .endfor
 
 _default_flavor=   -default
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Ed Maste]

On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
 wrote:
>
> We should of documented what the decision process and criteria was
> that lead to the decission to uuencode the files.

Doing some archaeology, the first instance of a uuencoded file I can
find is r1796, "Got rid of a couple of binary files by uuencoding.  49
more to go." There's no explanation of why the change was made.
Evidence suggests that in 1994 it was just accepted as impossible or
not permitted to have binary files in the tree, but this has not been
the case for quite some time.

> Thus we could easily revist that criteria, see how much of it no
> longer applies, possible add counter criteria, and change this
> decision, with it documented as to why it changed.

With none of this documented anywhere I'm going to rely on oral
history from you, phk, or other FreeBSD committers active in the mid
90s to provide guidance on what we can revisit and what to check if it
no longer applies.

The reason not to do it is uuencoding adds about a 40% space penalty,
adds to the build time (to uudecode), and makes changes harder to
review. In my mind dropping the unnecessary uuencoding is similar to
dropping build-time patching of files in the source tree (another
workaround we used to have for limitations of our older VCS).

> As is this is just another semi documented project guideline change,
> I believe there are more than just the firmware files that this
> change needs noted on.

Yes, we should look at the other cases where we unnecessarily uuencode
things. I'm not quite sure where we would document high level things
like this though, do you have a suggestion?  I could see a case for
somewhat similra topics (e.g. 7-bit ASCII/UTF-8/ISO-8859 guidance)
fitting into style.9, but I'm not sure this one does.

> We should also note that if they are already in uuencode state
> to leave them in uuencode state, or do we intened to convert
> them on next commit, or ???

Good point, converting existing .uu files to binary is just
unnecessary churn and is not recommended. If someone is going to make
a change it can be done with the next update.
___
svn-src-all@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 commit: r345158 - head/usr.sbin/bhyve

[Conrad Meyer]

Author: cem
Date: Thu Mar 14 21:08:48 2019
New Revision: 345158
URL: https://svnweb.freebsd.org/changeset/base/345158

Log:
  bhyve(8): Fix uart emulation bug
  
  THRE is always asserted in LSR reads, so REG_IER writes that raise
  IER_ETXRDY must also set thre_int_pending.
  
  Reported by:  Illumos, according to emaste@
https://twitter.com/ed_maste/status/1106195949087584258
  MFC after:2 weeks

Modified:
  head/usr.sbin/bhyve/uart_emul.c

Modified: head/usr.sbin/bhyve/uart_emul.c
==
--- head/usr.sbin/bhyve/uart_emul.c Thu Mar 14 20:32:48 2019
(r345157)
+++ head/usr.sbin/bhyve/uart_emul.c Thu Mar 14 21:08:48 2019
(r345158)
@@ -431,6 +431,9 @@ uart_write(struct uart_softc *sc, int offset, uint8_t 
sc->thre_int_pending = true;
break;
case REG_IER:
+   /* Set pending when IER_ETXRDY is raised (edge-triggered). */
+   if ((sc->ier & IER_ETXRDY) == 0 && (value & IER_ETXRDY) != 0)
+   sc->thre_int_pending = true;
/*
 * Apply mask so that bits 4-7 are 0
 * Also enables bits 0-3 only if they're 1
___
svn-src-all@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"

Re: svn commit: r332100 - in head: . lib/libc/gen sys/sys

[Colin Percival]

On 4/6/18 6:00 AM, Ed Schouten wrote:
> Author: ed
> Date: Fri Apr  6 13:00:45 2018
> New Revision: 332100
> URL: https://svnweb.freebsd.org/changeset/base/332100
> 
> Log:
>   Let syslog(3) use RFC 5424.
>   
>   With r332099 changing syslogd(8) to parse RFC 5424 formatted syslog
>   messages, go ahead and also change the syslog(3) libc function to
>   generate them. Compared to RFC 3164, RFC 5424 has various advantages,
>   such as sub-second precision for log entry timestamps.
>   
>   As this change could have adverse effects when not updating syslogd(8)
>   or using a different system logging daemon, add a notice to UPDATING and
>   increase __FreeBSD_version.
>   
>   Differential Revision:  https://reviews.freebsd.org/D14926

It looks like this changes the format in which messages are written to
stderr via the LOG_PERROR flag; this is visible if you run
# echo foo | logger -s
which used to print "root: foo" but now prints "root 40038 - - foo".

Was this intentional?

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Warner Losh]

CTM was fixed years ago...

Warner

On Thu, Mar 14, 2019, 1:32 PM Ravi Pokala  wrote:

> I think maybe there was also a limitation on the
> (repo-replication-over-email?) mechanism that we used to use? That rings a
> very faint bell for me for some reason, even though I'm pretty sure it was
> dead long before I got my bit.
>
> -Ravi (rpokala@)
>
> -Original Message-
> From:  on behalf of Ed Maste <
> ema...@freebsd.org>
> Date: 2019-03-14, Thursday at 12:21
> To: "Rodney W. Grimes" 
> Cc: src-committers , ,
> 
> Subject: Re: svn commit: r345138 - head/share/man/man9
>
> On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
>  wrote:
> >
> > [ Charset UTF-8 unsupported, converting... ]
> > > Author: emaste
> > > Date: Thu Mar 14 17:09:07 2019
> > > New Revision: 345138
> > > URL: https://svnweb.freebsd.org/changeset/base/345138
> > >
> > > Log:
> > >   firmware(9): remove uuencoded example
> > >
> > >   We can (should) just commit the binary files to the source tree.
> >
> > This change could use wider discussion.
>
> If you or others have a reason to prefer having uuencoded files in the
> src tree I'll happily revert. I was aware only of CVS limitations as a
> reason for uuencoding.
>
> We have many binary files in the tree already (e.g. GIF PNG and JPEG
> images, ELF and PE32 binaries, Berkeley DB files, and various
> compressed formats). I count 430 uuencoded files in the tree, with 328
> of those coming from libarchive and 64 from sys/*/dev/
>
>
>
>
>
___
svn-src-all@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 commit: r345156 - vendor/llvm-openmp/dist-release_80/runtime/src

[Dimitry Andric]

Author: dim
Date: Thu Mar 14 20:32:46 2019
New Revision: 345156
URL: https://svnweb.freebsd.org/changeset/base/345156

Log:
  Vendor import of LLVM openmp release_80 branch r356034:
  https://llvm.org/svn/llvm-project/openmp/branches/release_80@356034

Modified:
  vendor/llvm-openmp/dist-release_80/runtime/src/ompt-general.cpp

Modified: vendor/llvm-openmp/dist-release_80/runtime/src/ompt-general.cpp
==
--- vendor/llvm-openmp/dist-release_80/runtime/src/ompt-general.cpp Thu Mar 
14 20:11:46 2019(r345155)
+++ vendor/llvm-openmp/dist-release_80/runtime/src/ompt-general.cpp Thu Mar 
14 20:32:46 2019(r345156)
@@ -450,9 +450,6 @@ OMPT_API_ROUTINE ompt_set_result_t ompt_set_callback(o
 
 OMPT_API_ROUTINE int ompt_get_callback(ompt_callbacks_t which,
ompt_callback_t *callback) {
-  if (!ompt_enabled.enabled)
-return ompt_get_callback_failure;
-
   switch (which) {
 
 #define ompt_event_macro(event_name, callback_type, event_id)  
\
@@ -460,7 +457,7 @@ OMPT_API_ROUTINE int ompt_get_callback(ompt_callbacks_
 if (ompt_event_implementation_status(event_name)) {
\
   ompt_callback_t mycb =   
\
   (ompt_callback_t)ompt_callbacks.ompt_callback(event_name);   
\
-  if (ompt_enabled.event_name && mycb) {   
\
+  if (mycb) {  
\
 *callback = mycb;  
\
 return ompt_get_callback_success;  
\
   }
\
@@ -483,15 +480,11 @@ OMPT_API_ROUTINE int ompt_get_callback(ompt_callbacks_
 OMPT_API_ROUTINE int ompt_get_parallel_info(int ancestor_level,
 ompt_data_t **parallel_data,
 int *team_size) {
-  if (!ompt_enabled.enabled)
-return 0;
   return __ompt_get_parallel_info_internal(ancestor_level, parallel_data,
team_size);
 }
 
 OMPT_API_ROUTINE int ompt_get_state(ompt_wait_id_t *wait_id) {
-  if (!ompt_enabled.enabled)
-return ompt_state_work_serial;
   int thread_state = __ompt_get_state_internal(wait_id);
 
   if (thread_state == ompt_state_undefined) {
@@ -506,8 +499,6 @@ OMPT_API_ROUTINE int ompt_get_state(ompt_wait_id_t *wa
  /
 
 OMPT_API_ROUTINE ompt_data_t *ompt_get_thread_data(void) {
-  if (!ompt_enabled.enabled)
-return NULL;
   return __ompt_get_thread_data_internal();
 }
 
@@ -516,8 +507,6 @@ OMPT_API_ROUTINE int ompt_get_task_info(int ancestor_l
 ompt_frame_t **task_frame,
 ompt_data_t **parallel_data,
 int *thread_num) {
-  if (!ompt_enabled.enabled)
-return 0;
   return __ompt_get_task_info_internal(ancestor_level, type, task_data,
task_frame, parallel_data, thread_num);
 }
@@ -592,7 +581,7 @@ OMPT_API_ROUTINE int ompt_get_place_num(void) {
 #if !KMP_AFFINITY_SUPPORTED
   return -1;
 #else
-  if (!ompt_enabled.enabled || __kmp_get_gtid() < 0)
+  if (__kmp_get_gtid() < 0)
 return -1;
 
   int gtid;
@@ -613,7 +602,7 @@ OMPT_API_ROUTINE int ompt_get_partition_place_nums(int
 #if !KMP_AFFINITY_SUPPORTED
   return 0;
 #else
-  if (!ompt_enabled.enabled || __kmp_get_gtid() < 0)
+  if (__kmp_get_gtid() < 0)
 return 0;
 
   int i, gtid, place_num, first_place, last_place, start, end;
@@ -648,7 +637,7 @@ OMPT_API_ROUTINE int ompt_get_partition_place_nums(int
  /
 
 OMPT_API_ROUTINE int ompt_get_proc_id(void) {
-  if (!ompt_enabled.enabled || __kmp_get_gtid() < 0)
+  if (__kmp_get_gtid() < 0)
 return -1;
 #if KMP_OS_LINUX
   return sched_getcpu();
___
svn-src-all@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 commit: r345157 - vendor/llvm-openmp/openmp-release_80-r356034

[Dimitry Andric]

Author: dim
Date: Thu Mar 14 20:32:48 2019
New Revision: 345157
URL: https://svnweb.freebsd.org/changeset/base/345157

Log:
  Tag LLVM openmp release_80 branch r356034.

Added:
  vendor/llvm-openmp/openmp-release_80-r356034/
 - copied from r345156, vendor/llvm-openmp/dist-release_80/
___
svn-src-all@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 commit: r345154 - vendor/llvm-openmp/openmp-trunk-r351319

[Dimitry Andric]

Author: dim
Date: Thu Mar 14 20:10:27 2019
New Revision: 345154
URL: https://svnweb.freebsd.org/changeset/base/345154

Log:
  Tag LLVM openmp trunk r351319 (just before the release_80 branch point).

Added:
  vendor/llvm-openmp/openmp-trunk-r351319/
 - copied from r345153, vendor/llvm-openmp/dist/
___
svn-src-all@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"

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

[Bjoern A. Zeeb]

On 14 Mar 2019, at 19:48, Kyle Evans wrote:


Author: kevans
Date: Thu Mar 14 19:48:43 2019
New Revision: 345151
URL: https://svnweb.freebsd.org/changeset/base/345151

Log:
  ether_fakeaddr: Use 'b' 's' 'd' for the prefix

  This has the advantage of being obvious to sniff out the designated 
prefix

  by eye and it has all the right bits set. Comment stolen from ffec.

  I've removed bryanv@'s pending question of using the FreeBSD OUI 
range --
  no one has followed up on this with a definitive action, and there's 
no
  particular reason to shoot for it and the administrative overhead 
that comes

  with deciding exactly how to use it.


Yay.  iflib_gen_mac() has already thought kind-of similar and just took 
the entire(?) FreeBSD space for doing the same.  That code should be 
merged as well.


Bhyve is using a good chunk from the FreeBSD allocation; see 
sys/net/ieee_oui.h also for allocation guidelines (if I don’t 
misremember).


The fact that it might need figuring out should not prevent us from 
doing it right .. the third time .. maybe .. this time?


epair(4) is yet another one of the cloned interfaces which does magic 
for the ethernet addresses, not sure what else.



/bz
___
svn-src-all@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 commit: r345155 - vendor/llvm-openmp/dist-release_80

[Dimitry Andric]

Author: dim
Date: Thu Mar 14 20:11:46 2019
New Revision: 345155
URL: https://svnweb.freebsd.org/changeset/base/345155

Log:
  Branch vendor/llvm-openmp/dist to vendor/llvm-openmp/dist-release_80, to
  allow for independent merges of the upstream trunk and release_80
  branches.

Added:
  vendor/llvm-openmp/dist-release_80/
 - copied from r345153, vendor/llvm-openmp/dist/
___
svn-src-all@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 commit: r345153 - in vendor/llvm-openmp: . dist dist/runtime dist/runtime/src dist/runtime/src/i18n dist/runtime/src/include dist/runtime/src/include/30 dist/runtime/src/include/40 dist/runtime...

[Dimitry Andric]

Author: dim
Date: Thu Mar 14 20:09:10 2019
New Revision: 345153
URL: https://svnweb.freebsd.org/changeset/base/345153

Log:
  Vendor import of LLVM openmp trunk r351319 (just before the release_80
  branch point):
  https://llvm.org/svn/llvm-project/openmp/trunk@351319

Added:
  vendor/llvm-openmp/
  vendor/llvm-openmp/dist/
  vendor/llvm-openmp/dist/CREDITS.txt   (contents, props changed)
  vendor/llvm-openmp/dist/LICENSE.txt   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/
  vendor/llvm-openmp/dist/runtime/src/
  vendor/llvm-openmp/dist/runtime/src/dllexports
  vendor/llvm-openmp/dist/runtime/src/exports_so.txt   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/extractExternal.cpp   (contents, props 
changed)
  vendor/llvm-openmp/dist/runtime/src/i18n/
  vendor/llvm-openmp/dist/runtime/src/i18n/en_US.txt   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/include/
  vendor/llvm-openmp/dist/runtime/src/include/30/
  vendor/llvm-openmp/dist/runtime/src/include/30/omp.h.var
  vendor/llvm-openmp/dist/runtime/src/include/30/omp_lib.f.var
  vendor/llvm-openmp/dist/runtime/src/include/30/omp_lib.f90.var
  vendor/llvm-openmp/dist/runtime/src/include/30/omp_lib.h.var
  vendor/llvm-openmp/dist/runtime/src/include/40/
  vendor/llvm-openmp/dist/runtime/src/include/40/omp.h.var
  vendor/llvm-openmp/dist/runtime/src/include/40/omp_lib.f.var
  vendor/llvm-openmp/dist/runtime/src/include/40/omp_lib.f90.var
  vendor/llvm-openmp/dist/runtime/src/include/40/omp_lib.h.var
  vendor/llvm-openmp/dist/runtime/src/include/45/
  vendor/llvm-openmp/dist/runtime/src/include/45/omp.h.var
  vendor/llvm-openmp/dist/runtime/src/include/45/omp_lib.f.var
  vendor/llvm-openmp/dist/runtime/src/include/45/omp_lib.f90.var
  vendor/llvm-openmp/dist/runtime/src/include/45/omp_lib.h.var
  vendor/llvm-openmp/dist/runtime/src/include/50/
  vendor/llvm-openmp/dist/runtime/src/include/50/omp-tools.h.var
  vendor/llvm-openmp/dist/runtime/src/include/50/omp.h.var
  vendor/llvm-openmp/dist/runtime/src/include/50/omp_lib.f.var
  vendor/llvm-openmp/dist/runtime/src/include/50/omp_lib.f90.var
  vendor/llvm-openmp/dist/runtime/src/include/50/omp_lib.h.var
  vendor/llvm-openmp/dist/runtime/src/kmp.h   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_affinity.cpp   (contents, props 
changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_affinity.h   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_alloc.cpp   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_atomic.cpp   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_atomic.h   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_barrier.cpp   (contents, props 
changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_cancel.cpp   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_config.h.cmake
  vendor/llvm-openmp/dist/runtime/src/kmp_csupport.cpp   (contents, props 
changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_debug.cpp   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_debug.h   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_debugger.cpp   (contents, props 
changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_debugger.h   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_dispatch.cpp   (contents, props 
changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_dispatch.h   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_dispatch_hier.h   (contents, props 
changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_environment.cpp   (contents, props 
changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_environment.h   (contents, props 
changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_error.cpp   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_error.h   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_ftn_cdecl.cpp   (contents, props 
changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_ftn_entry.h   (contents, props 
changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_ftn_extra.cpp   (contents, props 
changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_ftn_os.h   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_ftn_stdcall.cpp   (contents, props 
changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_global.cpp   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_gsupport.cpp   (contents, props 
changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_i18n.cpp   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_i18n.h   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_import.cpp   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_io.cpp   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_io.h   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_itt.cpp   (contents, props changed)
  vendor/llvm-openmp/dist/runtime/src/kmp_itt.h   (contents, props 

svn commit: r345152 - in head: contrib/llvm/tools/clang/lib/AST lib/clang/include/clang/Basic lib/clang/include/lld/Common lib/clang/include/llvm/Support

[Dimitry Andric]

Author: dim
Date: Thu Mar 14 19:52:12 2019
New Revision: 345152
URL: https://svnweb.freebsd.org/changeset/base/345152

Log:
  Merge llvm, clang, compiler-rt, libc++, libunwind, lld, and lldb
  release_80 branch r356034 (effectively, 8.0.0 rc5), resolve conflicts,
  and bump version numbers.
  
  PR:   236062
  MFC after:1 month
  X-MFC-With:   r344779

Modified:
  head/contrib/llvm/tools/clang/lib/AST/ExprConstant.cpp
  head/lib/clang/include/clang/Basic/Version.inc
  head/lib/clang/include/lld/Common/Version.inc
  head/lib/clang/include/llvm/Support/VCSRevision.h
Directory Properties:
  head/contrib/compiler-rt/   (props changed)
  head/contrib/libc++/   (props changed)
  head/contrib/libunwind/   (props changed)
  head/contrib/llvm/   (props changed)
  head/contrib/llvm/tools/clang/   (props changed)
  head/contrib/llvm/tools/lld/   (props changed)
  head/contrib/llvm/tools/lldb/   (props changed)

Modified: head/contrib/llvm/tools/clang/lib/AST/ExprConstant.cpp
==
--- head/contrib/llvm/tools/clang/lib/AST/ExprConstant.cpp  Thu Mar 14 
19:48:43 2019(r345151)
+++ head/contrib/llvm/tools/clang/lib/AST/ExprConstant.cpp  Thu Mar 14 
19:52:12 2019(r345152)
@@ -10985,6 +10985,7 @@ bool Expr::EvaluateAsConstantExpr(EvalResult , 
   const ASTContext ) const {
   EvalInfo::EvaluationMode EM = EvalInfo::EM_ConstantExpression;
   EvalInfo Info(Ctx, Result, EM);
+  Info.InConstantContext = true;
   if (!::Evaluate(Result.Val, Info, this))
 return false;
 
@@ -11625,6 +11626,7 @@ bool Expr::EvaluateWithSubstitution(APValue , AS
 const Expr *This) const {
   Expr::EvalStatus Status;
   EvalInfo Info(Ctx, Status, EvalInfo::EM_ConstantExpressionUnevaluated);
+  Info.InConstantContext = true;
 
   LValue ThisVal;
   const LValue *ThisPtr = nullptr;
@@ -11708,6 +11710,7 @@ bool Expr::isPotentialConstantExprUnevaluated(Expr *E,
 
   EvalInfo Info(FD->getASTContext(), Status,
 EvalInfo::EM_PotentialConstantExpressionUnevaluated);
+  Info.InConstantContext = true;
 
   // Fabricate a call stack frame to give the arguments a plausible cover 
story.
   ArrayRef Args;

Modified: head/lib/clang/include/clang/Basic/Version.inc
==
--- head/lib/clang/include/clang/Basic/Version.inc  Thu Mar 14 19:48:43 
2019(r345151)
+++ head/lib/clang/include/clang/Basic/Version.inc  Thu Mar 14 19:52:12 
2019(r345152)
@@ -8,4 +8,4 @@
 
 #defineCLANG_VENDOR"FreeBSD "
 
-#defineSVN_REVISION"355677"
+#defineSVN_REVISION"356034"

Modified: head/lib/clang/include/lld/Common/Version.inc
==
--- head/lib/clang/include/lld/Common/Version.inc   Thu Mar 14 19:48:43 
2019(r345151)
+++ head/lib/clang/include/lld/Common/Version.inc   Thu Mar 14 19:52:12 
2019(r345152)
@@ -7,4 +7,4 @@
 
 #define LLD_REPOSITORY_STRING "FreeBSD"
 // -
-#define LLD_REVISION_STRING "355677-132"
+#define LLD_REVISION_STRING "356034-132"

Modified: head/lib/clang/include/llvm/Support/VCSRevision.h
==
--- head/lib/clang/include/llvm/Support/VCSRevision.h   Thu Mar 14 19:48:43 
2019(r345151)
+++ head/lib/clang/include/llvm/Support/VCSRevision.h   Thu Mar 14 19:52:12 
2019(r345152)
@@ -1,2 +1,2 @@
 /* $FreeBSD$ */
-#define LLVM_REVISION "svn-r355677"
+#define LLVM_REVISION "svn-r356034"
___
svn-src-all@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 commit: r345151 - head/sys/net

[Kyle Evans]

Author: kevans
Date: Thu Mar 14 19:48:43 2019
New Revision: 345151
URL: https://svnweb.freebsd.org/changeset/base/345151

Log:
  ether_fakeaddr: Use 'b' 's' 'd' for the prefix
  
  This has the advantage of being obvious to sniff out the designated prefix
  by eye and it has all the right bits set. Comment stolen from ffec.
  
  I've removed bryanv@'s pending question of using the FreeBSD OUI range --
  no one has followed up on this with a definitive action, and there's no
  particular reason to shoot for it and the administrative overhead that comes
  with deciding exactly how to use it.

Modified:
  head/sys/net/if_ethersubr.c

Modified: head/sys/net/if_ethersubr.c
==
--- head/sys/net/if_ethersubr.c Thu Mar 14 19:41:34 2019(r345150)
+++ head/sys/net/if_ethersubr.c Thu Mar 14 19:48:43 2019(r345151)
@@ -1406,13 +1406,14 @@ ether_fakeaddr(struct ether_addr *hwaddr)
 {
 
/*
-* Generate a non-multicast, locally administered address.
-*
-* BMV: Should we use the FreeBSD OUI range instead?
+* Generate a convenient locally administered address,
+* 'bsd' + random 24 low-order bits.  'b' is 0x62, which has the locally
+* assigned bit set, and the broadcast/multicast bit clear.
 */
arc4rand(hwaddr->octet, ETHER_ADDR_LEN, 1);
-   hwaddr->octet[0] &= ~1;
-   hwaddr->octet[0] |= 2;
+   hwaddr->octet[0] = 'b';
+   hwaddr->octet[1] = 's';
+   hwaddr->octet[2] = 'd';
 }
 
 DECLARE_MODULE(ether, ether_mod, SI_SUB_INIT_IF, SI_ORDER_ANY);
___
svn-src-all@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 commit: r345145 - vendor/clang/clang-release_80-r356034

[Dimitry Andric]

Author: dim
Date: Thu Mar 14 19:41:20 2019
New Revision: 345145
URL: https://svnweb.freebsd.org/changeset/base/345145

Log:
  Tag clang release_80 branch r356034.

Added:
  vendor/clang/clang-release_80-r356034/
 - copied from r345144, vendor/clang/dist-release_80/
___
svn-src-all@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 commit: r345150 - vendor/lldb/lldb-release_80-r356034

[Dimitry Andric]

Author: dim
Date: Thu Mar 14 19:41:34 2019
New Revision: 345150
URL: https://svnweb.freebsd.org/changeset/base/345150

Log:
  Tag lldb release_80 branch r356034.

Added:
  vendor/lldb/lldb-release_80-r356034/
 - copied from r345149, vendor/lldb/dist-release_80/
___
svn-src-all@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 commit: r345149 - vendor/lld/lld-release_80-r356034

[Dimitry Andric]

Author: dim
Date: Thu Mar 14 19:41:31 2019
New Revision: 345149
URL: https://svnweb.freebsd.org/changeset/base/345149

Log:
  Tag lld release_80 branch r356034.

Added:
  vendor/lld/lld-release_80-r356034/
 - copied from r345148, vendor/lld/dist-release_80/
___
svn-src-all@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 commit: r345142 - vendor/llvm/dist-release_80/docs

[Dimitry Andric]

Author: dim
Date: Thu Mar 14 19:41:10 2019
New Revision: 345142
URL: https://svnweb.freebsd.org/changeset/base/345142

Log:
  Vendor import of llvm release_80 branch r356034:
  https://llvm.org/svn/llvm-project/llvm/branches/release_80@356034

Modified:
  vendor/llvm/dist-release_80/docs/ReleaseNotes.rst

Modified: vendor/llvm/dist-release_80/docs/ReleaseNotes.rst
==
--- vendor/llvm/dist-release_80/docs/ReleaseNotes.rst   Thu Mar 14 19:07:41 
2019(r345141)
+++ vendor/llvm/dist-release_80/docs/ReleaseNotes.rst   Thu Mar 14 19:41:10 
2019(r345142)
@@ -95,6 +95,22 @@ Changes to the LLVM IR
   `_ must be enabled for the function body.
 
 
+Changes to the JIT APIs
+---
+
+The ORC (On Request Compilation) JIT APIs have been updated to support
+concurrent compilation. The existing (non-concurrent) ORC layer classes and
+related APIs are deprecated, have been renamed with a "Legacy" prefix (e.g.
+LegacyIRCompileLayer). The deprecated clasess will be removed in LLVM 9.
+
+An example JIT stack using the concurrent ORC APIs, called LLJIT, has been
+added (see include/llvm/ExecutionEngine/Orc/LLJIT.h). The lli tool has been
+updated to use LLJIT.
+
+MCJIT and ExecutionEngine continue to be supported, though ORC should be
+preferred for new projects.
+
+
 Changes to the AArch64 Target
 -
 
@@ -171,6 +187,26 @@ Changes to the PowerPC Target
 * Completed support in LLD for ELFv2
 
 * Enabled llvm-exegesis latency mode for PPC
+
+
+Changes to the SystemZ Target
+-
+
+* A number of bugs related to C/C++ language vector extension support were
+  fixed: the ``-mzvector`` option now actually enables the ``__vector`` and
+  ``__bool`` keywords, the ``vec_step`` intrinsic now works, and the
+  ``vec_insert_and_zero`` and ``vec_orc`` intrinsics now generate correct code.
+
+* The ``__float128`` keyword, which had been accidentally enabled in some
+  earlier releases, is now no longer supported.  On SystemZ, the ``long 
double``
+  data type itself already uses the IEEE 128-bit floating-point format.
+
+* When the compiler inlines ``strcmp`` or ``memcmp``, the generated code no
+  longer returns ``INT_MIN`` as the negative result value under any
+  circumstances.
+
+* Various code-gen improvements, in particular related to improved
+  auto-vectorization, inlining, and instruction scheduling.
 
 
 Changes to the X86 Target
___
svn-src-all@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 commit: r345147 - vendor/libc++/libc++-release_80-r356034

[Dimitry Andric]

Author: dim
Date: Thu Mar 14 19:41:26 2019
New Revision: 345147
URL: https://svnweb.freebsd.org/changeset/base/345147

Log:
  Tag libc++ release_80 branch r356034.

Added:
  vendor/libc++/libc++-release_80-r356034/
 - copied from r345146, vendor/libc++/dist-release_80/
___
svn-src-all@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 commit: r345148 - vendor/llvm-libunwind/libunwind-release_80-r356034

[Dimitry Andric]

Author: dim
Date: Thu Mar 14 19:41:28 2019
New Revision: 345148
URL: https://svnweb.freebsd.org/changeset/base/345148

Log:
  Tag LLVM libunwind release_80 branch r356034.

Added:
  vendor/llvm-libunwind/libunwind-release_80-r356034/
 - copied from r345147, vendor/llvm-libunwind/dist-release_80/
___
svn-src-all@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 commit: r345144 - in vendor/clang/dist-release_80: lib/AST test/SemaCXX

[Dimitry Andric]

Author: dim
Date: Thu Mar 14 19:41:16 2019
New Revision: 345144
URL: https://svnweb.freebsd.org/changeset/base/345144

Log:
  Vendor import of clang release_80 branch r356034:
  https://llvm.org/svn/llvm-project/cfe/branches/release_80@356034

Modified:
  vendor/clang/dist-release_80/lib/AST/ExprConstant.cpp
  vendor/clang/dist-release_80/test/SemaCXX/constant-expression-cxx1y.cpp
  vendor/clang/dist-release_80/test/SemaCXX/enable_if.cpp

Modified: vendor/clang/dist-release_80/lib/AST/ExprConstant.cpp
==
--- vendor/clang/dist-release_80/lib/AST/ExprConstant.cpp   Thu Mar 14 
19:41:13 2019(r345143)
+++ vendor/clang/dist-release_80/lib/AST/ExprConstant.cpp   Thu Mar 14 
19:41:16 2019(r345144)
@@ -10985,6 +10985,7 @@ bool Expr::EvaluateAsConstantExpr(EvalResult , 
   const ASTContext ) const {
   EvalInfo::EvaluationMode EM = EvalInfo::EM_ConstantExpression;
   EvalInfo Info(Ctx, Result, EM);
+  Info.InConstantContext = true;
   if (!::Evaluate(Result.Val, Info, this))
 return false;
 
@@ -11625,6 +11626,7 @@ bool Expr::EvaluateWithSubstitution(APValue , AS
 const Expr *This) const {
   Expr::EvalStatus Status;
   EvalInfo Info(Ctx, Status, EvalInfo::EM_ConstantExpressionUnevaluated);
+  Info.InConstantContext = true;
 
   LValue ThisVal;
   const LValue *ThisPtr = nullptr;
@@ -11708,6 +11710,7 @@ bool Expr::isPotentialConstantExprUnevaluated(Expr *E,
 
   EvalInfo Info(FD->getASTContext(), Status,
 EvalInfo::EM_PotentialConstantExpressionUnevaluated);
+  Info.InConstantContext = true;
 
   // Fabricate a call stack frame to give the arguments a plausible cover 
story.
   ArrayRef Args;

Modified: 
vendor/clang/dist-release_80/test/SemaCXX/constant-expression-cxx1y.cpp
==
--- vendor/clang/dist-release_80/test/SemaCXX/constant-expression-cxx1y.cpp 
Thu Mar 14 19:41:13 2019(r345143)
+++ vendor/clang/dist-release_80/test/SemaCXX/constant-expression-cxx1y.cpp 
Thu Mar 14 19:41:16 2019(r345144)
@@ -1135,3 +1135,27 @@ constexpr bool indirect_builtin_constant_p(const char 
   return __builtin_constant_p(*__s);
 }
 constexpr bool n = indirect_builtin_constant_p("a");
+
+__attribute__((enable_if(indirect_builtin_constant_p("a") == n, "OK")))
+int test_in_enable_if() { return 0; }
+int n2 = test_in_enable_if();
+
+template 
+int test_in_template_param() { return 0; }
+int n3 = test_in_template_param();
+
+void test_in_case(int n) {
+  switch (n) {
+case indirect_builtin_constant_p("abc"):
+break;
+  }
+}
+enum InEnum1 {
+  ONE = indirect_builtin_constant_p("abc")
+};
+enum InEnum2 : int {
+  TWO = indirect_builtin_constant_p("abc")
+};
+enum class InEnum3 {
+  THREE = indirect_builtin_constant_p("abc")
+};

Modified: vendor/clang/dist-release_80/test/SemaCXX/enable_if.cpp
==
--- vendor/clang/dist-release_80/test/SemaCXX/enable_if.cpp Thu Mar 14 
19:41:13 2019(r345143)
+++ vendor/clang/dist-release_80/test/SemaCXX/enable_if.cpp Thu Mar 14 
19:41:16 2019(r345144)
@@ -514,3 +514,11 @@ namespace TypeOfFn {
 
   static_assert(is_same<__typeof__(foo)*, decltype()>::value, "");
 }
+
+namespace InConstantContext {
+void foo(const char *s) 
__attribute__((enable_if(((void)__builtin_constant_p(*s), true), "trap"))) {}
+
+void test() {
+  InConstantContext::foo("abc");
+}
+} // namespace InConstantContext
___
svn-src-all@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 commit: r345143 - vendor/llvm/llvm-release_80-r356034

[Dimitry Andric]

Author: dim
Date: Thu Mar 14 19:41:13 2019
New Revision: 345143
URL: https://svnweb.freebsd.org/changeset/base/345143

Log:
  Tag llvm release_80 branch r356034.

Added:
  vendor/llvm/llvm-release_80-r356034/
 - copied from r345142, vendor/llvm/dist-release_80/
___
svn-src-all@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 commit: r345146 - vendor/compiler-rt/compiler-rt-release_80-r356034

[Dimitry Andric]

Author: dim
Date: Thu Mar 14 19:41:22 2019
New Revision: 345146
URL: https://svnweb.freebsd.org/changeset/base/345146

Log:
  Tag compiler-rt release_80 branch r356034.

Added:
  vendor/compiler-rt/compiler-rt-release_80-r356034/
 - copied from r345145, vendor/compiler-rt/dist-release_80/
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Ravi Pokala]

I think maybe there was also a limitation on the (repo-replication-over-email?) 
mechanism that we used to use? That rings a very faint bell for me for some 
reason, even though I'm pretty sure it was dead long before I got my bit.

-Ravi (rpokala@)

-Original Message-
From:  on behalf of Ed Maste 

Date: 2019-03-14, Thursday at 12:21
To: "Rodney W. Grimes" 
Cc: src-committers , , 

Subject: Re: svn commit: r345138 - head/share/man/man9

On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
 wrote:
>
> [ Charset UTF-8 unsupported, converting... ]
> > Author: emaste
> > Date: Thu Mar 14 17:09:07 2019
> > New Revision: 345138
> > URL: https://svnweb.freebsd.org/changeset/base/345138
> >
> > Log:
> >   firmware(9): remove uuencoded example
> >
> >   We can (should) just commit the binary files to the source tree.
>
> This change could use wider discussion.

If you or others have a reason to prefer having uuencoded files in the
src tree I'll happily revert. I was aware only of CVS limitations as a
reason for uuencoding.

We have many binary files in the tree already (e.g. GIF PNG and JPEG
images, ELF and PE32 binaries, Berkeley DB files, and various
compressed formats). I count 430 uuencoded files in the tree, with 328
of those coming from libarchive and 64 from sys/*/dev/



___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Ed Maste]

On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
 wrote:
>
> [ Charset UTF-8 unsupported, converting... ]
> > Author: emaste
> > Date: Thu Mar 14 17:09:07 2019
> > New Revision: 345138
> > URL: https://svnweb.freebsd.org/changeset/base/345138
> >
> > Log:
> >   firmware(9): remove uuencoded example
> >
> >   We can (should) just commit the binary files to the source tree.
>
> This change could use wider discussion.

If you or others have a reason to prefer having uuencoded files in the
src tree I'll happily revert. I was aware only of CVS limitations as a
reason for uuencoding.

We have many binary files in the tree already (e.g. GIF PNG and JPEG
images, ELF and PE32 binaries, Berkeley DB files, and various
compressed formats). I count 430 uuencoded files in the tree, with 328
of those coming from libarchive and 64 from sys/*/dev/
___
svn-src-all@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 commit: r345141 - head/sys/mips/mips

[Konstantin Belousov]

Author: kib
Date: Thu Mar 14 19:07:41 2019
New Revision: 345141
URL: https://svnweb.freebsd.org/changeset/base/345141

Log:
  mips: remove dead comment and definitions.
  
  Reviewed by:  brooks, jhb
  Sponsored by: The FreeBSD Foundation
  MFC after:3 days
  Differential revision:https://reviews.freebsd.org/D19584

Modified:
  head/sys/mips/mips/vm_machdep.c

Modified: head/sys/mips/mips/vm_machdep.c
==
--- head/sys/mips/mips/vm_machdep.c Thu Mar 14 17:20:24 2019
(r345140)
+++ head/sys/mips/mips/vm_machdep.c Thu Mar 14 19:07:41 2019
(r345141)
@@ -454,14 +454,6 @@ cpu_set_upcall(struct thread *td, void (*entry)(void *
 }
 
 /*
- * Implement the pre-zeroed page mechanism.
- * This routine is called from the idle loop.
- */
-
-#defineZIDLE_LO(v) ((v) * 2 / 3)
-#defineZIDLE_HI(v) ((v) * 4 / 5)
-
-/*
  * Software interrupt handler for queued VM system processing.
  */
 void
___
svn-src-all@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"

Re: svn commit: r345138 - head/share/man/man9

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> Author: emaste
> Date: Thu Mar 14 17:09:07 2019
> New Revision: 345138
> URL: https://svnweb.freebsd.org/changeset/base/345138
> 
> Log:
>   firmware(9): remove uuencoded example
>   
>   We can (should) just commit the binary files to the source tree.

We should of documented what the decision process and criteria was
that lead to the decission to uuencode the files.

I do not believe it was just that the VCS could not handle them,
that there was some other reasoning as well.  There is also down
streams to consider, does this in any way effect things outside
the project.

Thus we could easily revist that criteria, see how much of it no
longer applies, possible add counter criteria, and change this
decision, with it documented as to why it changed.

As is this is just another semi documented project guideline change,
I believe there are more than just the firmware files that this
change needs noted on.

We should also note that if they are already in uuencode state
to leave them in uuencode state, or do we intened to convert
them on next commit, or ???

This change could use wider discussion.

>   Reviewed by:bz, imp, 0mp
>   Differential Revision:  https://reviews.freebsd.org/D19581
> 
> Modified:
>   head/share/man/man9/firmware.9
> 
> Modified: head/share/man/man9/firmware.9
> ==
> --- head/share/man/man9/firmware.9Thu Mar 14 17:05:46 2019
> (r345137)
> +++ head/share/man/man9/firmware.9Thu Mar 14 17:09:07 2019
> (r345138)
> @@ -23,7 +23,7 @@
>  .\"
>  .\" $FreeBSD$
>  .\"
> -.Dd August 2, 2008
> +.Dd March 14, 2019
>  .Dt FIRMWARE 9
>  .Os
>  .Sh NAME
> @@ -248,12 +248,11 @@ IxNpeMicrocode.fwo  optional npe_fw 
> \\
>   -r -d -o ${.TARGET} IxNpeMicrocode.dat" \\
>  no-implicit-rule\\
>  clean   "IxNpeMicrocode.fwo"
> -IxNpeMicrocode.dat  optional npe_fw \\
> -dependency  ".PHONY"\\
> -compile-with"uudecode < 
> $S/contrib/dev/npe/IxNpeMicrocode.dat.uu" \\
> -no-obj no-implicit-rule \\
> -clean   "IxNpeMicrocode.dat"
>  .Ed
> +.Pp
> +Firmware was previously committed to the source tree as uuencoded files,
> +but this is no longer required; the binary firmware file should be committed
> +to the tree as provided by the vendor.
>  .Pp
>  Note that generating the firmware modules in this way requires
>  the availability of the following tools:
> 
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@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 commit: r345139 - head/sys/net

[Kyle Evans]

Author: kevans
Date: Thu Mar 14 17:18:00 2019
New Revision: 345139
URL: https://svnweb.freebsd.org/changeset/base/345139

Log:
  ether: centralize fake hwaddr generation
  
  We currently have two places with identical fake hwaddr generation --
  if_vxlan and if_bridge. Lift it into if_ethersubr for reuse in other
  interfaces that may also need a fake addr.
  
  Reviewed by:  bryanv, kp, philip
  Differential Revision:https://reviews.freebsd.org/D19573

Modified:
  head/sys/net/ethernet.h
  head/sys/net/if_bridge.c
  head/sys/net/if_ethersubr.c
  head/sys/net/if_vxlan.c

Modified: head/sys/net/ethernet.h
==
--- head/sys/net/ethernet.h Thu Mar 14 17:09:07 2019(r345138)
+++ head/sys/net/ethernet.h Thu Mar 14 17:18:00 2019(r345139)
@@ -422,6 +422,7 @@ voidether_vlan_mtap(struct bpf_if *, struct mbuf *,
 struct mbuf  *ether_vlanencap(struct mbuf *, uint16_t);
 bool   ether_8021q_frame(struct mbuf **mp, struct ifnet *ife, struct ifnet *p,
uint16_t vid, uint8_t pcp);
+void   ether_fakeaddr(struct ether_addr *hwaddr);
 
 #ifdef _SYS_EVENTHANDLER_H_
 /* new ethernet interface attached event */

Modified: head/sys/net/if_bridge.c
==
--- head/sys/net/if_bridge.cThu Mar 14 17:09:07 2019(r345138)
+++ head/sys/net/if_bridge.cThu Mar 14 17:18:00 2019(r345139)
@@ -226,7 +226,7 @@ struct bridge_softc {
struct bstp_state   sc_stp; /* STP state */
uint32_tsc_brtexceeded; /* # of cache drops */
struct ifnet*sc_ifaddr; /* member mac copied from */
-   u_char  sc_defaddr[6];  /* Default MAC address */
+   struct ether_addr   sc_defaddr; /* Default MAC address */
 };
 
 VNET_DEFINE_STATIC(struct mtx, bridge_list_mtx);
@@ -670,16 +670,14 @@ bridge_clone_create(struct if_clone *ifc, int unit, ca
getcredhostid(curthread->td_ucred, );
do {
if (fb || hostid == 0) {
-   arc4rand(sc->sc_defaddr, ETHER_ADDR_LEN, 1);
-   sc->sc_defaddr[0] &= ~1;/* clear multicast bit */
-   sc->sc_defaddr[0] |= 2; /* set the LAA bit */
+   ether_fakeaddr(>sc_defaddr);
} else {
-   sc->sc_defaddr[0] = 0x2;
-   sc->sc_defaddr[1] = (hostid >> 24) & 0xff;
-   sc->sc_defaddr[2] = (hostid >> 16) & 0xff;
-   sc->sc_defaddr[3] = (hostid >> 8 ) & 0xff;
-   sc->sc_defaddr[4] =  hostid& 0xff;
-   sc->sc_defaddr[5] = ifp->if_dunit & 0xff;
+   sc->sc_defaddr.octet[0] = 0x2;
+   sc->sc_defaddr.octet[1] = (hostid >> 24) & 0xff;
+   sc->sc_defaddr.octet[2] = (hostid >> 16) & 0xff;
+   sc->sc_defaddr.octet[3] = (hostid >> 8 ) & 0xff;
+   sc->sc_defaddr.octet[4] =  hostid& 0xff;
+   sc->sc_defaddr.octet[5] = ifp->if_dunit & 0xff;
}
 
fb = 1;
@@ -687,7 +685,7 @@ bridge_clone_create(struct if_clone *ifc, int unit, ca
BRIDGE_LIST_LOCK();
LIST_FOREACH(sc2, _bridge_list, sc_list) {
bifp = sc2->sc_ifp;
-   if (memcmp(sc->sc_defaddr,
+   if (memcmp(sc->sc_defaddr.octet,
IF_LLADDR(bifp), ETHER_ADDR_LEN) == 0) {
retry = 1;
break;
@@ -697,7 +695,7 @@ bridge_clone_create(struct if_clone *ifc, int unit, ca
} while (retry == 1);
 
bstp_attach(>sc_stp, _ops);
-   ether_ifattach(ifp, sc->sc_defaddr);
+   ether_ifattach(ifp, sc->sc_defaddr.octet);
/* Now undo some of the damage... */
ifp->if_baudrate = 0;
ifp->if_type = IFT_BRIDGE;
@@ -1018,7 +1016,7 @@ bridge_delete_member(struct bridge_softc *sc, struct b
 */
if (V_bridge_inherit_mac && sc->sc_ifaddr == ifs) {
if (LIST_EMPTY(>sc_iflist)) {
-   bcopy(sc->sc_defaddr,
+   bcopy(>sc_defaddr,
IF_LLADDR(sc->sc_ifp), ETHER_ADDR_LEN);
sc->sc_ifaddr = NULL;
} else {
@@ -1189,7 +1187,7 @@ bridge_ioctl_add(struct bridge_softc *sc, void *arg)
 * the default randomly generated one.
 */
if (V_bridge_inherit_mac && LIST_EMPTY(>sc_iflist) &&
-   !memcmp(IF_LLADDR(sc->sc_ifp), sc->sc_defaddr, ETHER_ADDR_LEN)) {
+   !memcmp(IF_LLADDR(sc->sc_ifp), sc->sc_defaddr.octet, 
ETHER_ADDR_LEN)) {
bcopy(IF_LLADDR(ifs), IF_LLADDR(sc->sc_ifp), ETHER_ADDR_LEN);
sc->sc_ifaddr = ifs;
 

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

[Ed Maste]

Author: emaste
Date: Thu Mar 14 17:09:07 2019
New Revision: 345138
URL: https://svnweb.freebsd.org/changeset/base/345138

Log:
  firmware(9): remove uuencoded example
  
  We can (should) just commit the binary files to the source tree.
  
  Reviewed by:  bz, imp, 0mp
  Differential Revision:https://reviews.freebsd.org/D19581

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

Modified: head/share/man/man9/firmware.9
==
--- head/share/man/man9/firmware.9  Thu Mar 14 17:05:46 2019
(r345137)
+++ head/share/man/man9/firmware.9  Thu Mar 14 17:09:07 2019
(r345138)
@@ -23,7 +23,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd August 2, 2008
+.Dd March 14, 2019
 .Dt FIRMWARE 9
 .Os
 .Sh NAME
@@ -248,12 +248,11 @@ IxNpeMicrocode.fwo  optional npe_fw   
\\
-r -d -o ${.TARGET} IxNpeMicrocode.dat" \\
 no-implicit-rule\\
 clean   "IxNpeMicrocode.fwo"
-IxNpeMicrocode.dat  optional npe_fw \\
-dependency  ".PHONY"\\
-compile-with"uudecode < $S/contrib/dev/npe/IxNpeMicrocode.dat.uu" 
\\
-no-obj no-implicit-rule \\
-clean   "IxNpeMicrocode.dat"
 .Ed
+.Pp
+Firmware was previously committed to the source tree as uuencoded files,
+but this is no longer required; the binary firmware file should be committed
+to the tree as provided by the vendor.
 .Pp
 Note that generating the firmware modules in this way requires
 the availability of the following tools:
___
svn-src-all@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 commit: r345137 - head/sys/contrib/dev/drm2

[Ed Maste]

Author: emaste
Date: Thu Mar 14 17:05:46 2019
New Revision: 345137
URL: https://svnweb.freebsd.org/changeset/base/345137

Log:
  Remove radeonkmsfw firmware files
  
  The drivers were removed in r344299 so there is no need to keep the
  firmware files in the src tree.
  
  Reviewed by:  imp, jhibbits, johalun
  Sponsored by: The FreeBSD Foundation
  Differential Revision:https://reviews.freebsd.org/D19583

Deleted:
  head/sys/contrib/dev/drm2/
___
svn-src-all@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 commit: r345136 - head/sys/mips/mips

[Brooks Davis]

Author: brooks
Date: Thu Mar 14 15:56:34 2019
New Revision: 345136
URL: https://svnweb.freebsd.org/changeset/base/345136

Log:
  Style(9): add a missing space between argument declerations.

Modified:
  head/sys/mips/mips/vm_machdep.c

Modified: head/sys/mips/mips/vm_machdep.c
==
--- head/sys/mips/mips/vm_machdep.c Thu Mar 14 15:55:30 2019
(r345135)
+++ head/sys/mips/mips/vm_machdep.c Thu Mar 14 15:56:34 2019
(r345136)
@@ -88,7 +88,7 @@ __FBSDID("$FreeBSD$");
  * ready to run and return to user mode.
  */
 void
-cpu_fork(struct thread *td1, struct proc *p2, struct thread *td2,int flags)
+cpu_fork(struct thread *td1, struct proc *p2, struct thread *td2, int flags)
 {
struct pcb *pcb2;
 
___
svn-src-all@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 commit: r345135 - head/sys/mips/mips

[Brooks Davis]

Author: brooks
Date: Thu Mar 14 15:55:30 2019
New Revision: 345135
URL: https://svnweb.freebsd.org/changeset/base/345135

Log:
  Remove an unused struct proc *p1 in cpu_fork().
  
  The only reference to p1 after a dead store was in a comment so update
  the comment to refer to td1.
  
  Submitted by: sbruno
  Differential Revision:https://reviews.freebsd.org/D16226

Modified:
  head/sys/mips/mips/vm_machdep.c

Modified: head/sys/mips/mips/vm_machdep.c
==
--- head/sys/mips/mips/vm_machdep.c Thu Mar 14 15:07:46 2019
(r345134)
+++ head/sys/mips/mips/vm_machdep.c Thu Mar 14 15:55:30 2019
(r345135)
@@ -90,10 +90,8 @@ __FBSDID("$FreeBSD$");
 void
 cpu_fork(struct thread *td1, struct proc *p2, struct thread *td2,int flags)
 {
-   struct proc *p1;
struct pcb *pcb2;
 
-   p1 = td1->td_proc;
if ((flags & RFPROC) == 0)
return;
/* It is assumed that the vm_thread_alloc called
@@ -103,7 +101,7 @@ cpu_fork(struct thread *td1, struct proc *p2, struct t
/* Point the pcb to the top of the stack */
pcb2 = td2->td_pcb;
 
-   /* Copy p1's pcb, note that in this case
+   /* Copy td1's pcb, note that in this case
 * our pcb also includes the td_frame being copied
 * too. The older mips2 code did an additional copy
 * of the td_frame, for us that's not needed any
___
svn-src-all@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 commit: r345132 - head/usr.sbin/chroot

[Mateusz Piotrowski]

Author: 0mp (ports committer)
Date: Thu Mar 14 14:34:36 2019
New Revision: 345132
URL: https://svnweb.freebsd.org/changeset/base/345132

Log:
  chroot.8: Add examples & clean up
  
  - Sort arguments in synopsis.
  - Clarify that it is possible to specify arguments to the command (and that
they could be passed as further arguments to chroot(1)).
  - Standardize the description of the flags.
  - Improve formatting (e.g., do not use macros in strings specifying width).
  - Add examples.
  
  Reviewed by:  bcr
  Approved by:  bcr (doc)
  Approved by:  krion (mentor, implicit), mat (mentor, implicit)
  Differential Revision:https://reviews.freebsd.org/D19582

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

Modified: head/usr.sbin/chroot/chroot.8
==
--- head/usr.sbin/chroot/chroot.8   Thu Mar 14 13:28:21 2019
(r345131)
+++ head/usr.sbin/chroot/chroot.8   Thu Mar 14 14:34:36 2019
(r345132)
@@ -28,7 +28,7 @@
 .\" @(#)chroot.8   8.1 (Berkeley) 6/9/93
 .\" $FreeBSD$
 .\"
-.Dd June 7, 2003
+.Dd March 14, 2019
 .Dt CHROOT 8
 .Os
 .Sh NAME
@@ -36,36 +36,36 @@
 .Nd change root directory
 .Sh SYNOPSIS
 .Nm
-.Op Fl u Ar user
+.Op Fl G Ar group Ns Op Cm \&, Ns Ar group  ...
 .Op Fl g Ar group
-.Op Fl G Ar group,group,...
+.Op Fl u Ar user
 .Ar newroot
-.Op Ar command
+.Op Ar command Op Ar arg ...
 .Sh DESCRIPTION
 The
 .Nm
 utility changes its current and root directories to the supplied directory
 .Ar newroot
 and then exec's
-.Ar command ,
-if supplied,
+.Ar command
+with provided arguments, if supplied,
 or an interactive copy of the user's login shell.
 .Pp
-If the
-.Fl u ,
-.Fl g
-or
-.Fl G
-options are given,
-the user,
-group and group list of the process are set to
-these values after the
-.Nm
-has taken place.
+The options are as follows:
+.Bl -tag -width "-G group[,group ...]"
+.It Fl G Ar group Ns Op Cm \&, Ns Ar group  ...
+Run the command with the permissions of the specified groups.
+.It Fl g Ar group
+Run the command with the permissions of the specified
+.Ar group .
+.It Fl u Ar user
+Run the command as the
+.Ar user .
+.El
 .Sh ENVIRONMENT
 The following environment variable is referenced by
 .Nm :
-.Bl -tag -width ".Ev SHELL"
+.Bl -tag -width "SHELL"
 .It Ev SHELL
 If set,
 the string specified by
@@ -77,6 +77,28 @@ If the variable
 is not set,
 .Pa /bin/sh
 is used.
+.El
+.Sh EXAMPLES
+.Bl -tag -width 0n
+.It Sy Example 1\&: No Chrooting into a New Root Directory
+.Pp
+The following command opens the
+.Xr csh 1
+shell after chrooting to the standard root directory.
+.Bd -literal -offset 2n
+.Li # Ic chroot / /bin/csh
+.Ed
+.It Sy Example 2\&: No Execution of a Command with a Changed Root Directory
+.Pp
+The following command changes a root directory with
+.Nm
+and then runs
+.Xr ls 1
+to list the contents of
+.Pa /sbin .
+.Bd -literal -offset 2n
+.Li # Ic chroot /tmp/testroot ls /sbin
+.Ed
 .El
 .Sh SEE ALSO
 .Xr chdir 2 ,
___
svn-src-all@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 commit: r345131 - head/sys/contrib/dev/npe

[Ed Maste]

Author: emaste
Date: Thu Mar 14 13:28:21 2019
New Revision: 345131
URL: https://svnweb.freebsd.org/changeset/base/345131

Log:
  Remove npe microcode
  
  The driver was removed in r336436.

Deleted:
  head/sys/contrib/dev/npe/
___
svn-src-all@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 commit: r345130 - head/usr.sbin/trim

[Eugene Grosbein]

Author: eugen
Date: Thu Mar 14 12:25:16 2019
New Revision: 345130
URL: https://svnweb.freebsd.org/changeset/base/345130

Log:
  trim(8): add another safety net
  
  It is quite easy make a mistake and run something like this:
  
trim -f /dev/da0 -r rfile
  
  This would trim the whole device then emit an error on non-existing file -r.
  
  Add another check to prevent this while allowing this form still
  for real object names beginning from dash:
  
trim -f -- /dev/da0 -r rfile
  
  MFC after:1 week

Modified:
  head/usr.sbin/trim/trim.c

Modified: head/usr.sbin/trim/trim.c
==
--- head/usr.sbin/trim/trim.c   Thu Mar 14 10:06:46 2019(r345129)
+++ head/usr.sbin/trim/trim.c   Thu Mar 14 12:25:16 2019(r345130)
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -103,6 +104,23 @@ main(int argc, char **argv)
usage(name);
/* NOTREACHED */
}
+
+   /*
+* Safety net: do not allow mistakes like
+*
+*  trim -f /dev/da0 -r rfile
+*
+* This would trim whole device then error on non-existing file -r.
+* Following check prevents this while allowing this form still:
+*
+*  trim -f -- /dev/da0 -r rfile
+*/
+   
+   if (strcmp(argv[optind-1], "--") != 0) {
+   for (ch = optind; ch < argc; ch++)
+   if (argv[ch][0] == '-')
+   usage(name);
+   }
 
argv += optind;
argc -= optind;
___
svn-src-all@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"

Re: svn commit: r345103 - head/sys/compat/linuxkpi/common/include/linux

[Konstantin Belousov]

On Thu, Mar 14, 2019 at 12:04:30PM +, Johannes Lundberg wrote:
> 
> On 3/14/19 11:45 AM, Konstantin Belousov wrote:
> > On Thu, Mar 14, 2019 at 11:07:50AM +, Johannes Lundberg wrote:
> >> On 3/13/19 11:39 PM, John Baldwin wrote:
> >>> On 3/13/19 1:36 PM, Conrad Meyer wrote:
>  Hi,
> 
>  A lot of the information about PCIe devices is read by PCI probe and
>  cached on the (BSD) device.  You could access it out of
>  device_get_ivars(bsddev)->cfg.pcie and avoid the MMIO latency.
> >>> Agreed when possible, though I'm not sure caching lnkcap is really
> >>> all that useful.
> >>>
>  On Wed, Mar 13, 2019 at 12:15 PM Hans Petter Selasky
>   wrote:
> > +static inline enum pci_bus_speed
> > +pcie_get_speed_cap(struct pci_dev *dev)
> > +{
> > +   device_t root;
> > +   uint32_t lnkcap, lnkcap2;
> > +   int error, pos;
> > +
> > +   root = device_get_parent(dev->dev.bsddev);
> > +   if (root == NULL)
> > +   return (PCI_SPEED_UNKNOWN);
> > +   root = device_get_parent(root);
> > +   if (root == NULL)
> > +   return (PCI_SPEED_UNKNOWN);
> > +   root = device_get_parent(root);
> > +   if (root == NULL)
> > +   return (PCI_SPEED_UNKNOWN);
>  What is this mechanism trying to accomplish?  It seems incredibly
>  fragile.  Looking for pci0? pcib0?
> >>> It does seem broken, or maybe that it only works for DRM drivers and 
> >>> nothing else.
> >>> For non-DRM drivers, 'bsddev' is a PCI-e endpoint.  You would then go up 
> >>> two layers
> >>> (pciX and pcibX) to get to the parent bridge.  However, this is assuming 
> >>> a DRM layout
> >>> where it has to go drm0 -> vgapci0 -> pciX -> pcibX due to the vgapci 
> >>> pseudo-driver.
> >>> As a result, this function can't possibly work on anything other than a 
> >>> DRM driver.
> >>> Since it would try to use pci ivars on some PCI bus instance (or worse), 
> >>> it's likely
> >>> to cause random panics if used from a non-DRM driver.
> >>>
> >>> Furthermore, it's not at all clear to me why you can't just read 
> >>> lnkcap/lnkcap2 from
> >>> the endpoint device directly vs heading up to the parent bridge though.  
> >>> Hmm, I guess
> >>> it's trying to infer the capabilities of the "slot", so that's why it 
> >>> needs the
> >>> grandparent.  You will have to do something less fragile to find the 
> >>> grandparent.
> >>> The simplest way may be to walk up to the first "pcib" device you see and 
> >>> then
> >>> stop.  You will still want to see if it's a "real" PCI device by seeing 
> >>> if it's
> >>> parent is a "pci" device (meaning that the "pcib" device will have valid 
> >>> PCI IVARs
> >>> and PCI config registers you can read).  pci_find_pcie_root_port has some 
> >>> similar
> >>> code for this, but that function would walk too far up for what you want 
> >>> here, so you
> >>> can't reuse it as-is.
> >>>
> > +   if ((error = pci_find_cap(root, PCIY_EXPRESS, )) != 0)
> > +   return (PCI_SPEED_UNKNOWN);
>  Cached as non-zero cfg.pcie.pcie_location value in ivars.
> 
> > +   lnkcap2 = pci_read_config(root, pos + PCIER_LINK_CAP2, 4);
>  This one we don't cache, unfortunately, but could.  Ditto LINK_CAP
>  below.  Usually "pos + PCIEfoo" is spelled "pcie_read_config(...,
>  PCIEfoo...)."
> >>> Yes, pcie_read_config is what you normally would use.  That uses the 
> >>> cached
> >>> pcie_location for you.
> >>>
> >>>  pcie_read_config(dev->dev.bsddev, PCIER_LINK_CAP2, 2);
> >>>
> >>> But also, you should be checking the PCIe version to see if this register
> >>> exists instead of reading it unconditionally.  Specifically, you should 
> >>> read
> >>> the version field (PCIEM_FLAGS_VERSION) from PCIER_FLAGS.  LINK_CAP2 only
> >>> exists if the version >= 2.
> >>>
> > +
> > +   if (lnkcap2) {  /* PCIe r3.0-compliant */
> > +   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_2_5GB)
> > +   return (PCIE_SPEED_2_5GT);
>  Seems like these definitions would be better suited as native
>  PCIEM_LINK_CAP2_foo definitions in pcireg.h
> >>> I feel less strongly about those since we have to provide the constants
> >>> anyway for consumers to use.
> >>>
> > +   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_5_0GB)
> > +   return (PCIE_SPEED_5_0GT);
> > +   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_8_0GB)
> > +   return (PCIE_SPEED_8_0GT);
> > +   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_16_0GB)
> > +   return (PCIE_SPEED_16_0GT);
> > +   } else {/* pre-r3.0 */
> > +   lnkcap = pci_read_config(root, pos + PCIER_LINK_CAP, 4);
> > +   if (lnkcap & PCI_EXP_LNKCAP_SLS_2_5GB)
> > +   return (PCIE_SPEED_2_5GT);
> > +   if (lnkcap & 

Re: svn commit: r345103 - head/sys/compat/linuxkpi/common/include/linux

[Johannes Lundberg]

On 3/14/19 11:45 AM, Konstantin Belousov wrote:
> On Thu, Mar 14, 2019 at 11:07:50AM +, Johannes Lundberg wrote:
>> On 3/13/19 11:39 PM, John Baldwin wrote:
>>> On 3/13/19 1:36 PM, Conrad Meyer wrote:
 Hi,

 A lot of the information about PCIe devices is read by PCI probe and
 cached on the (BSD) device.  You could access it out of
 device_get_ivars(bsddev)->cfg.pcie and avoid the MMIO latency.
>>> Agreed when possible, though I'm not sure caching lnkcap is really
>>> all that useful.
>>>
 On Wed, Mar 13, 2019 at 12:15 PM Hans Petter Selasky
  wrote:
> +static inline enum pci_bus_speed
> +pcie_get_speed_cap(struct pci_dev *dev)
> +{
> +   device_t root;
> +   uint32_t lnkcap, lnkcap2;
> +   int error, pos;
> +
> +   root = device_get_parent(dev->dev.bsddev);
> +   if (root == NULL)
> +   return (PCI_SPEED_UNKNOWN);
> +   root = device_get_parent(root);
> +   if (root == NULL)
> +   return (PCI_SPEED_UNKNOWN);
> +   root = device_get_parent(root);
> +   if (root == NULL)
> +   return (PCI_SPEED_UNKNOWN);
 What is this mechanism trying to accomplish?  It seems incredibly
 fragile.  Looking for pci0? pcib0?
>>> It does seem broken, or maybe that it only works for DRM drivers and 
>>> nothing else.
>>> For non-DRM drivers, 'bsddev' is a PCI-e endpoint.  You would then go up 
>>> two layers
>>> (pciX and pcibX) to get to the parent bridge.  However, this is assuming a 
>>> DRM layout
>>> where it has to go drm0 -> vgapci0 -> pciX -> pcibX due to the vgapci 
>>> pseudo-driver.
>>> As a result, this function can't possibly work on anything other than a DRM 
>>> driver.
>>> Since it would try to use pci ivars on some PCI bus instance (or worse), 
>>> it's likely
>>> to cause random panics if used from a non-DRM driver.
>>>
>>> Furthermore, it's not at all clear to me why you can't just read 
>>> lnkcap/lnkcap2 from
>>> the endpoint device directly vs heading up to the parent bridge though.  
>>> Hmm, I guess
>>> it's trying to infer the capabilities of the "slot", so that's why it needs 
>>> the
>>> grandparent.  You will have to do something less fragile to find the 
>>> grandparent.
>>> The simplest way may be to walk up to the first "pcib" device you see and 
>>> then
>>> stop.  You will still want to see if it's a "real" PCI device by seeing if 
>>> it's
>>> parent is a "pci" device (meaning that the "pcib" device will have valid 
>>> PCI IVARs
>>> and PCI config registers you can read).  pci_find_pcie_root_port has some 
>>> similar
>>> code for this, but that function would walk too far up for what you want 
>>> here, so you
>>> can't reuse it as-is.
>>>
> +   if ((error = pci_find_cap(root, PCIY_EXPRESS, )) != 0)
> +   return (PCI_SPEED_UNKNOWN);
 Cached as non-zero cfg.pcie.pcie_location value in ivars.

> +   lnkcap2 = pci_read_config(root, pos + PCIER_LINK_CAP2, 4);
 This one we don't cache, unfortunately, but could.  Ditto LINK_CAP
 below.  Usually "pos + PCIEfoo" is spelled "pcie_read_config(...,
 PCIEfoo...)."
>>> Yes, pcie_read_config is what you normally would use.  That uses the cached
>>> pcie_location for you.
>>>
>>>  pcie_read_config(dev->dev.bsddev, PCIER_LINK_CAP2, 2);
>>>
>>> But also, you should be checking the PCIe version to see if this register
>>> exists instead of reading it unconditionally.  Specifically, you should read
>>> the version field (PCIEM_FLAGS_VERSION) from PCIER_FLAGS.  LINK_CAP2 only
>>> exists if the version >= 2.
>>>
> +
> +   if (lnkcap2) {  /* PCIe r3.0-compliant */
> +   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_2_5GB)
> +   return (PCIE_SPEED_2_5GT);
 Seems like these definitions would be better suited as native
 PCIEM_LINK_CAP2_foo definitions in pcireg.h
>>> I feel less strongly about those since we have to provide the constants
>>> anyway for consumers to use.
>>>
> +   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_5_0GB)
> +   return (PCIE_SPEED_5_0GT);
> +   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_8_0GB)
> +   return (PCIE_SPEED_8_0GT);
> +   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_16_0GB)
> +   return (PCIE_SPEED_16_0GT);
> +   } else {/* pre-r3.0 */
> +   lnkcap = pci_read_config(root, pos + PCIER_LINK_CAP, 4);
> +   if (lnkcap & PCI_EXP_LNKCAP_SLS_2_5GB)
> +   return (PCIE_SPEED_2_5GT);
> +   if (lnkcap & PCI_EXP_LNKCAP_SLS_5_0GB)
> +   return (PCIE_SPEED_5_0GT);
> +   if (lnkcap & PCI_EXP_LNKCAP_SLS_8_0GB)
> +   return (PCIE_SPEED_8_0GT);
> +   if (lnkcap & PCI_EXP_LNKCAP_SLS_16_0GB)
> +   

Re: svn commit: r345103 - head/sys/compat/linuxkpi/common/include/linux

[Konstantin Belousov]

On Thu, Mar 14, 2019 at 11:07:50AM +, Johannes Lundberg wrote:
> 
> On 3/13/19 11:39 PM, John Baldwin wrote:
> > On 3/13/19 1:36 PM, Conrad Meyer wrote:
> >> Hi,
> >>
> >> A lot of the information about PCIe devices is read by PCI probe and
> >> cached on the (BSD) device.  You could access it out of
> >> device_get_ivars(bsddev)->cfg.pcie and avoid the MMIO latency.
> > Agreed when possible, though I'm not sure caching lnkcap is really
> > all that useful.
> >
> >> On Wed, Mar 13, 2019 at 12:15 PM Hans Petter Selasky
> >>  wrote:
> >>> +static inline enum pci_bus_speed
> >>> +pcie_get_speed_cap(struct pci_dev *dev)
> >>> +{
> >>> +   device_t root;
> >>> +   uint32_t lnkcap, lnkcap2;
> >>> +   int error, pos;
> >>> +
> >>> +   root = device_get_parent(dev->dev.bsddev);
> >>> +   if (root == NULL)
> >>> +   return (PCI_SPEED_UNKNOWN);
> >>> +   root = device_get_parent(root);
> >>> +   if (root == NULL)
> >>> +   return (PCI_SPEED_UNKNOWN);
> >>> +   root = device_get_parent(root);
> >>> +   if (root == NULL)
> >>> +   return (PCI_SPEED_UNKNOWN);
> >> What is this mechanism trying to accomplish?  It seems incredibly
> >> fragile.  Looking for pci0? pcib0?
> > It does seem broken, or maybe that it only works for DRM drivers and 
> > nothing else.
> > For non-DRM drivers, 'bsddev' is a PCI-e endpoint.  You would then go up 
> > two layers
> > (pciX and pcibX) to get to the parent bridge.  However, this is assuming a 
> > DRM layout
> > where it has to go drm0 -> vgapci0 -> pciX -> pcibX due to the vgapci 
> > pseudo-driver.
> > As a result, this function can't possibly work on anything other than a DRM 
> > driver.
> > Since it would try to use pci ivars on some PCI bus instance (or worse), 
> > it's likely
> > to cause random panics if used from a non-DRM driver.
> >
> > Furthermore, it's not at all clear to me why you can't just read 
> > lnkcap/lnkcap2 from
> > the endpoint device directly vs heading up to the parent bridge though.  
> > Hmm, I guess
> > it's trying to infer the capabilities of the "slot", so that's why it needs 
> > the
> > grandparent.  You will have to do something less fragile to find the 
> > grandparent.
> > The simplest way may be to walk up to the first "pcib" device you see and 
> > then
> > stop.  You will still want to see if it's a "real" PCI device by seeing if 
> > it's
> > parent is a "pci" device (meaning that the "pcib" device will have valid 
> > PCI IVARs
> > and PCI config registers you can read).  pci_find_pcie_root_port has some 
> > similar
> > code for this, but that function would walk too far up for what you want 
> > here, so you
> > can't reuse it as-is.
> >
> >>> +   if ((error = pci_find_cap(root, PCIY_EXPRESS, )) != 0)
> >>> +   return (PCI_SPEED_UNKNOWN);
> >> Cached as non-zero cfg.pcie.pcie_location value in ivars.
> >>
> >>> +   lnkcap2 = pci_read_config(root, pos + PCIER_LINK_CAP2, 4);
> >> This one we don't cache, unfortunately, but could.  Ditto LINK_CAP
> >> below.  Usually "pos + PCIEfoo" is spelled "pcie_read_config(...,
> >> PCIEfoo...)."
> > Yes, pcie_read_config is what you normally would use.  That uses the cached
> > pcie_location for you.
> >
> >  pcie_read_config(dev->dev.bsddev, PCIER_LINK_CAP2, 2);
> >
> > But also, you should be checking the PCIe version to see if this register
> > exists instead of reading it unconditionally.  Specifically, you should read
> > the version field (PCIEM_FLAGS_VERSION) from PCIER_FLAGS.  LINK_CAP2 only
> > exists if the version >= 2.
> >
> >>> +
> >>> +   if (lnkcap2) {  /* PCIe r3.0-compliant */
> >>> +   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_2_5GB)
> >>> +   return (PCIE_SPEED_2_5GT);
> >> Seems like these definitions would be better suited as native
> >> PCIEM_LINK_CAP2_foo definitions in pcireg.h
> > I feel less strongly about those since we have to provide the constants
> > anyway for consumers to use.
> >
> >>> +   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_5_0GB)
> >>> +   return (PCIE_SPEED_5_0GT);
> >>> +   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_8_0GB)
> >>> +   return (PCIE_SPEED_8_0GT);
> >>> +   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_16_0GB)
> >>> +   return (PCIE_SPEED_16_0GT);
> >>> +   } else {/* pre-r3.0 */
> >>> +   lnkcap = pci_read_config(root, pos + PCIER_LINK_CAP, 4);
> >>> +   if (lnkcap & PCI_EXP_LNKCAP_SLS_2_5GB)
> >>> +   return (PCIE_SPEED_2_5GT);
> >>> +   if (lnkcap & PCI_EXP_LNKCAP_SLS_5_0GB)
> >>> +   return (PCIE_SPEED_5_0GT);
> >>> +   if (lnkcap & PCI_EXP_LNKCAP_SLS_8_0GB)
> >>> +   return (PCIE_SPEED_8_0GT);
> >>> +   if (lnkcap & PCI_EXP_LNKCAP_SLS_16_0GB)
> >>> +   return (PCIE_SPEED_16_0GT);
> >>> +   }
> >>> +  

Re: svn commit: r345103 - head/sys/compat/linuxkpi/common/include/linux

[Johannes Lundberg]

On 3/13/19 11:39 PM, John Baldwin wrote:
> On 3/13/19 1:36 PM, Conrad Meyer wrote:
>> Hi,
>>
>> A lot of the information about PCIe devices is read by PCI probe and
>> cached on the (BSD) device.  You could access it out of
>> device_get_ivars(bsddev)->cfg.pcie and avoid the MMIO latency.
> Agreed when possible, though I'm not sure caching lnkcap is really
> all that useful.
>
>> On Wed, Mar 13, 2019 at 12:15 PM Hans Petter Selasky
>>  wrote:
>>> +static inline enum pci_bus_speed
>>> +pcie_get_speed_cap(struct pci_dev *dev)
>>> +{
>>> +   device_t root;
>>> +   uint32_t lnkcap, lnkcap2;
>>> +   int error, pos;
>>> +
>>> +   root = device_get_parent(dev->dev.bsddev);
>>> +   if (root == NULL)
>>> +   return (PCI_SPEED_UNKNOWN);
>>> +   root = device_get_parent(root);
>>> +   if (root == NULL)
>>> +   return (PCI_SPEED_UNKNOWN);
>>> +   root = device_get_parent(root);
>>> +   if (root == NULL)
>>> +   return (PCI_SPEED_UNKNOWN);
>> What is this mechanism trying to accomplish?  It seems incredibly
>> fragile.  Looking for pci0? pcib0?
> It does seem broken, or maybe that it only works for DRM drivers and nothing 
> else.
> For non-DRM drivers, 'bsddev' is a PCI-e endpoint.  You would then go up two 
> layers
> (pciX and pcibX) to get to the parent bridge.  However, this is assuming a 
> DRM layout
> where it has to go drm0 -> vgapci0 -> pciX -> pcibX due to the vgapci 
> pseudo-driver.
> As a result, this function can't possibly work on anything other than a DRM 
> driver.
> Since it would try to use pci ivars on some PCI bus instance (or worse), it's 
> likely
> to cause random panics if used from a non-DRM driver.
>
> Furthermore, it's not at all clear to me why you can't just read 
> lnkcap/lnkcap2 from
> the endpoint device directly vs heading up to the parent bridge though.  Hmm, 
> I guess
> it's trying to infer the capabilities of the "slot", so that's why it needs 
> the
> grandparent.  You will have to do something less fragile to find the 
> grandparent.
> The simplest way may be to walk up to the first "pcib" device you see and then
> stop.  You will still want to see if it's a "real" PCI device by seeing if 
> it's
> parent is a "pci" device (meaning that the "pcib" device will have valid PCI 
> IVARs
> and PCI config registers you can read).  pci_find_pcie_root_port has some 
> similar
> code for this, but that function would walk too far up for what you want 
> here, so you
> can't reuse it as-is.
>
>>> +   if ((error = pci_find_cap(root, PCIY_EXPRESS, )) != 0)
>>> +   return (PCI_SPEED_UNKNOWN);
>> Cached as non-zero cfg.pcie.pcie_location value in ivars.
>>
>>> +   lnkcap2 = pci_read_config(root, pos + PCIER_LINK_CAP2, 4);
>> This one we don't cache, unfortunately, but could.  Ditto LINK_CAP
>> below.  Usually "pos + PCIEfoo" is spelled "pcie_read_config(...,
>> PCIEfoo...)."
> Yes, pcie_read_config is what you normally would use.  That uses the cached
> pcie_location for you.
>
>  pcie_read_config(dev->dev.bsddev, PCIER_LINK_CAP2, 2);
>
> But also, you should be checking the PCIe version to see if this register
> exists instead of reading it unconditionally.  Specifically, you should read
> the version field (PCIEM_FLAGS_VERSION) from PCIER_FLAGS.  LINK_CAP2 only
> exists if the version >= 2.
>
>>> +
>>> +   if (lnkcap2) {  /* PCIe r3.0-compliant */
>>> +   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_2_5GB)
>>> +   return (PCIE_SPEED_2_5GT);
>> Seems like these definitions would be better suited as native
>> PCIEM_LINK_CAP2_foo definitions in pcireg.h
> I feel less strongly about those since we have to provide the constants
> anyway for consumers to use.
>
>>> +   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_5_0GB)
>>> +   return (PCIE_SPEED_5_0GT);
>>> +   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_8_0GB)
>>> +   return (PCIE_SPEED_8_0GT);
>>> +   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_16_0GB)
>>> +   return (PCIE_SPEED_16_0GT);
>>> +   } else {/* pre-r3.0 */
>>> +   lnkcap = pci_read_config(root, pos + PCIER_LINK_CAP, 4);
>>> +   if (lnkcap & PCI_EXP_LNKCAP_SLS_2_5GB)
>>> +   return (PCIE_SPEED_2_5GT);
>>> +   if (lnkcap & PCI_EXP_LNKCAP_SLS_5_0GB)
>>> +   return (PCIE_SPEED_5_0GT);
>>> +   if (lnkcap & PCI_EXP_LNKCAP_SLS_8_0GB)
>>> +   return (PCIE_SPEED_8_0GT);
>>> +   if (lnkcap & PCI_EXP_LNKCAP_SLS_16_0GB)
>>> +   return (PCIE_SPEED_16_0GT);
>>> +   }
>>> +   return (PCI_SPEED_UNKNOWN);
>>> +}
>>> +
>>> +static inline enum pcie_link_width
>>> +pcie_get_width_cap(struct pci_dev *dev)
>>> +{
>>> +   uint32_t lnkcap;
>>> +
>>> +   pcie_capability_read_dword(dev, PCI_EXP_LNKCAP, );
>> Better spelled as PCIER_LINK_CAP.
>>
>>> +   

svn commit: r345129 - stable/12/stand/libsa/zfs

[Steven Hartland]

Author: smh
Date: Thu Mar 14 10:06:46 2019
New Revision: 345129
URL: https://svnweb.freebsd.org/changeset/base/345129

Log:
  Revert zfsimpl.c accidentally committed in r345128
  
  Revert an unrelated change to zfsimpl.c accidentally committed in r345128.
  
  Sponsored by: Multiplay

Modified:
  stable/12/stand/libsa/zfs/zfsimpl.c

Modified: stable/12/stand/libsa/zfs/zfsimpl.c
==
--- stable/12/stand/libsa/zfs/zfsimpl.c Thu Mar 14 10:03:04 2019
(r345128)
+++ stable/12/stand/libsa/zfs/zfsimpl.c Thu Mar 14 10:06:46 2019
(r345129)
@@ -2076,7 +2076,6 @@ zfs_mount_dataset(const spa_t *spa, uint64_t objnum, o
 {
dnode_phys_t dataset;
dsl_dataset_phys_t *ds;
-   int err;
 
if (objset_get_dnode(spa, >spa_mos, objnum, )) {
printf("ZFS: can't find dataset %ju\n", (uintmax_t)objnum);
@@ -2084,9 +2083,9 @@ zfs_mount_dataset(const spa_t *spa, uint64_t objnum, o
}
 
ds = (dsl_dataset_phys_t *) _bonus;
-   if ((err = zio_read(spa, >ds_bp, objset)) != 0) {
-   printf("ZFS: can't read object set for dataset %ju (error 
%d)\n",
-   (uintmax_t)objnum, err);
+   if (zio_read(spa, >ds_bp, objset)) {
+   printf("ZFS: can't read object set for dataset %ju\n",
+   (uintmax_t)objnum);
return (EIO);
}
 
___
svn-src-all@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 commit: r345128 - in stable/12: sbin/camcontrol stand/libsa/zfs

[Steven Hartland]

Author: smh
Date: Thu Mar 14 10:03:04 2019
New Revision: 345128
URL: https://svnweb.freebsd.org/changeset/base/345128

Log:
  MFC r344701: Fix incorrect / unused sector_count for identify requests
  
  Fix unused sector_count for identify requests from camcontrol by changing
  to zero which is a more appropriate value when the parameter is unused.
  
  Sponsored by: Multiplay

Modified:
  stable/12/sbin/camcontrol/camcontrol.c
  stable/12/stand/libsa/zfs/zfsimpl.c
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sbin/camcontrol/camcontrol.c
==
--- stable/12/sbin/camcontrol/camcontrol.c  Thu Mar 14 09:18:54 2019
(r345127)
+++ stable/12/sbin/camcontrol/camcontrol.c  Thu Mar 14 10:03:04 2019
(r345128)
@@ -2292,7 +2292,7 @@ ata_do_identify(struct cam_device *device, int retry_c
 /*command*/command,
 /*features*/0,
 /*lba*/0,
-/*sector_count*/(u_int8_t)sizeof(struct 
ata_params),
+/*sector_count*/0,
 /*data_ptr*/(u_int8_t *)ptr,
 /*dxfer_len*/sizeof(struct ata_params),
 /*timeout*/timeout ? timeout : 30 * 1000,
@@ -2312,8 +2312,7 @@ ata_do_identify(struct cam_device *device, int retry_c
 /*command*/retry_command,
 /*features*/0,
 /*lba*/0,
-/*sector_count*/(u_int8_t)
-sizeof(struct ata_params),
+/*sector_count*/0,
 /*data_ptr*/(u_int8_t *)ptr,
 /*dxfer_len*/sizeof(struct ata_params),
 /*timeout*/timeout ? timeout : 30 * 
1000,

Modified: stable/12/stand/libsa/zfs/zfsimpl.c
==
--- stable/12/stand/libsa/zfs/zfsimpl.c Thu Mar 14 09:18:54 2019
(r345127)
+++ stable/12/stand/libsa/zfs/zfsimpl.c Thu Mar 14 10:03:04 2019
(r345128)
@@ -2076,6 +2076,7 @@ zfs_mount_dataset(const spa_t *spa, uint64_t objnum, o
 {
dnode_phys_t dataset;
dsl_dataset_phys_t *ds;
+   int err;
 
if (objset_get_dnode(spa, >spa_mos, objnum, )) {
printf("ZFS: can't find dataset %ju\n", (uintmax_t)objnum);
@@ -2083,9 +2084,9 @@ zfs_mount_dataset(const spa_t *spa, uint64_t objnum, o
}
 
ds = (dsl_dataset_phys_t *) _bonus;
-   if (zio_read(spa, >ds_bp, objset)) {
-   printf("ZFS: can't read object set for dataset %ju\n",
-   (uintmax_t)objnum);
+   if ((err = zio_read(spa, >ds_bp, objset)) != 0) {
+   printf("ZFS: can't read object set for dataset %ju (error 
%d)\n",
+   (uintmax_t)objnum, err);
return (EIO);
}
 
___
svn-src-all@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 commit: r345127 - head/sys/compat/linuxkpi/common/include/linux

[Hans Petter Selasky]

Author: hselasky
Date: Thu Mar 14 09:18:54 2019
New Revision: 345127
URL: https://svnweb.freebsd.org/changeset/base/345127

Log:
  Revert r345102 until the DRM next port issues are resolved.
  
  Requested by: Johannes Lundberg 
  MFC after:1 week
  Sponsored by: Mellanox Technologies

Modified:
  head/sys/compat/linuxkpi/common/include/linux/kernel.h

Modified: head/sys/compat/linuxkpi/common/include/linux/kernel.h
==
--- head/sys/compat/linuxkpi/common/include/linux/kernel.h  Thu Mar 14 
08:27:01 2019(r345126)
+++ head/sys/compat/linuxkpi/common/include/linux/kernel.h  Thu Mar 14 
09:18:54 2019(r345127)
@@ -130,11 +130,9 @@
 #defineALIGN(x, y) roundup2((x), (y))
 #undef PTR_ALIGN
 #definePTR_ALIGN(p, a) ((__typeof(p))ALIGN((uintptr_t)(p), 
(a)))
-#defineIS_ALIGNED(x, a)(((x) & ((__typeof(x))(a) - 1)) == 0)
 #defineDIV_ROUND_UP(x, n)  howmany(x, n)
 #define__KERNEL_DIV_ROUND_UP(x, n) howmany(x, n)
 #defineDIV_ROUND_UP_ULL(x, n)  DIV_ROUND_UP((unsigned long long)(x), 
(n))
-#defineDIV_ROUND_DOWN_ULL(x, n) (((unsigned long long)(x) / (n)) * (n))
 #defineFIELD_SIZEOF(t, f)  sizeof(((t *)0)->f)
 
 #defineprintk(...) printf(__VA_ARGS__)
___
svn-src-all@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 commit: r345126 - in stable/11/sys: amd64/amd64 i386/i386

[Andrey V. Elsukov]

Author: ae
Date: Thu Mar 14 08:27:01 2019
New Revision: 345126
URL: https://svnweb.freebsd.org/changeset/base/345126

Log:
  MFC r344873:
Fix typo.

Modified:
  stable/11/sys/amd64/amd64/vm_machdep.c
  stable/11/sys/i386/i386/vm_machdep.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/amd64/amd64/vm_machdep.c
==
--- stable/11/sys/amd64/amd64/vm_machdep.c  Thu Mar 14 08:25:28 2019
(r345125)
+++ stable/11/sys/amd64/amd64/vm_machdep.c  Thu Mar 14 08:27:01 2019
(r345126)
@@ -85,7 +85,7 @@ _Static_assert(OFFSETOF_CURTHREAD == offsetof(struct p
 _Static_assert(OFFSETOF_CURPCB == offsetof(struct pcpu, pc_curpcb),
 "OFFSETOF_CURPCB does not correspond with offset of pc_curpcb.");
 _Static_assert(OFFSETOF_MONITORBUF == offsetof(struct pcpu, pc_monitorbuf),
-"OFFSETOF_MONINORBUF does not correspond with offset of pc_monitorbuf.");
+"OFFSETOF_MONITORBUF does not correspond with offset of pc_monitorbuf.");
 
 struct savefpu *
 get_pcb_user_save_td(struct thread *td)

Modified: stable/11/sys/i386/i386/vm_machdep.c
==
--- stable/11/sys/i386/i386/vm_machdep.cThu Mar 14 08:25:28 2019
(r345125)
+++ stable/11/sys/i386/i386/vm_machdep.cThu Mar 14 08:27:01 2019
(r345126)
@@ -98,7 +98,7 @@ _Static_assert(OFFSETOF_CURTHREAD == offsetof(struct p
 _Static_assert(OFFSETOF_CURPCB == offsetof(struct pcpu, pc_curpcb),
 "OFFSETOF_CURPCB does not correspond with offset of pc_curpcb.");
 _Static_assert(__OFFSETOF_MONITORBUF == offsetof(struct pcpu, pc_monitorbuf),
-"__OFFSETOF_MONINORBUF does not correspond with offset of pc_monitorbuf.");
+"__OFFSETOF_MONITORBUF does not correspond with offset of pc_monitorbuf.");
 
 union savefpu *
 get_pcb_user_save_td(struct thread *td)
___
svn-src-all@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 commit: r345125 - in stable/12/sys: amd64/amd64 i386/i386

[Andrey V. Elsukov]

Author: ae
Date: Thu Mar 14 08:25:28 2019
New Revision: 345125
URL: https://svnweb.freebsd.org/changeset/base/345125

Log:
  MFC r344873:
Fix typo.

Modified:
  stable/12/sys/amd64/amd64/vm_machdep.c
  stable/12/sys/i386/i386/vm_machdep.c
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/amd64/amd64/vm_machdep.c
==
--- stable/12/sys/amd64/amd64/vm_machdep.c  Thu Mar 14 02:46:03 2019
(r345124)
+++ stable/12/sys/amd64/amd64/vm_machdep.c  Thu Mar 14 08:25:28 2019
(r345125)
@@ -86,7 +86,7 @@ _Static_assert(OFFSETOF_CURTHREAD == offsetof(struct p
 _Static_assert(OFFSETOF_CURPCB == offsetof(struct pcpu, pc_curpcb),
 "OFFSETOF_CURPCB does not correspond with offset of pc_curpcb.");
 _Static_assert(OFFSETOF_MONITORBUF == offsetof(struct pcpu, pc_monitorbuf),
-"OFFSETOF_MONINORBUF does not correspond with offset of pc_monitorbuf.");
+"OFFSETOF_MONITORBUF does not correspond with offset of pc_monitorbuf.");
 
 struct savefpu *
 get_pcb_user_save_td(struct thread *td)

Modified: stable/12/sys/i386/i386/vm_machdep.c
==
--- stable/12/sys/i386/i386/vm_machdep.cThu Mar 14 02:46:03 2019
(r345124)
+++ stable/12/sys/i386/i386/vm_machdep.cThu Mar 14 08:25:28 2019
(r345125)
@@ -95,7 +95,7 @@ _Static_assert(OFFSETOF_CURTHREAD == offsetof(struct p
 _Static_assert(OFFSETOF_CURPCB == offsetof(struct pcpu, pc_curpcb),
 "OFFSETOF_CURPCB does not correspond with offset of pc_curpcb.");
 _Static_assert(__OFFSETOF_MONITORBUF == offsetof(struct pcpu, pc_monitorbuf),
-"__OFFSETOF_MONINORBUF does not correspond with offset of pc_monitorbuf.");
+"__OFFSETOF_MONITORBUF does not correspond with offset of pc_monitorbuf.");
 
 union savefpu *
 get_pcb_user_save_td(struct thread *td)
___
svn-src-all@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"