Re: svn commit: r368714 - head/lib/libc/string
On Thu, Dec 17, 2020 at 9:33 AM Ian Lepore wrote:
> On Thu, 2020-12-17 at 18:22 +0200, Konstantin Belousov wrote:
> > On Thu, Dec 17, 2020 at 01:01:01PM +, Jessica Clarke wrote:
> > > On 17 Dec 2020, at 12:53, Konstantin Belousov
> > > wrote:
> > > >
> > > > On Thu, Dec 17, 2020 at 12:41:47PM +, Mateusz Piotrowski
> > > > wrote:
> > > > > Author: 0mp (doc,ports committer)
> > > > > Date: Thu Dec 17 12:41:47 2020
> > > > > New Revision: 368714
> > > > > URL: https://svnweb.freebsd.org/changeset/base/368714
> > > > >
> > > > > Log:
> > > > > strerror.3: Add an example for perror()
> > > > >
> > > > > This is a nice and quick reference.
> > > > >
> > > > > Reviewed by: jilles, yuripv
> > > > > MFC after: 2 weeks
> > > > > Differential Revision: https://reviews.freebsd.org/D27623
> > > > >
> > > > > Modified:
> > > > > head/lib/libc/string/strerror.3
> > > > >
> > > > > Modified: head/lib/libc/string/strerror.3
> > > > > ===
> > > > > ===
> > > > > --- head/lib/libc/string/strerror.3 Thu Dec 17 03:42:54
> > > > > 2020(r368713)
> > > > > +++ head/lib/libc/string/strerror.3 Thu Dec 17 12:41:47
> > > > > 2020(r368714)
> > > > > @@ -32,7 +32,7 @@
> > > > > .\" @(#)strerror.3 8.1 (Berkeley) 6/9/93
> > > > > .\" $FreeBSD$
> > > > > .\"
> > > > > -.Dd December 7, 2020
> > > > > +.Dd December 17, 2020
> > > > > .Dt STRERROR 3
> > > > > .Os
> > > > > .Sh NAME
> > > > > @@ -170,6 +170,31 @@ The use of these variables is deprecated;
> > > > > or
> > > > > .Fn strerror_r
> > > > > should be used instead.
> > > > > +.Sh EXAMPLES
> > > > > +The following example shows how to use
> > > > > +.Fn perror
> > > > > +to report an error.
> > > > > +.Bd -literal -offset 2n
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +
> > > > > +int
> > > > > +main(void)
> > > > > +{
> > > > > + int fd;
> > > > > +
> > > > > + if ((fd = open("/nonexistent", O_RDONLY)) == -1) {
> > > > > + perror("open()");
> > > > > + exit(1);
> > > > > + }
> > > > > +printf("File descriptor: %d\en", fd);
> > > >
> > > > This lines is indented with spaces, while other lines have tabs.
> > > >
> > > > > + return (0);
> > > >
> > > > return (0) is redundand.
> > >
> > > It's not required as per the standard, but omitting it is needlessly
> > > obfuscating it and bad practice. C lets you do a whole load of things
> > > that are a bad idea, and whilst this one is harmless, it is nonetheless
> > > confusing to anyone who is not intimately acquainted quirks like this
> > > special case in the standard.
> >
> > Why it is bad practice ?
> >
> > C is a small language, and while knowing some quirks (like this one)
> > seems to be optional, others are not. And worse, that other quirks are
> > essential for writing correct code at all. Consequence is that ignoring
> > details indicates insufficient knowledge of the fundamentals and lowers
> > the trust in the provided suggestion.
>
> I completely disagree. Writing example code where you fail to return a
> value and just fall out the bottom of some function that declares it
> returns an int is just Bad Code. Using some obscure quirk of the
> language as justification for that bad code doesn't help the situation
> at all.
>
> How obscure is this quirk? I've been writing C code since 1983,
> including having released a freeware compiler (pre-gcc days) and
> working on a commercial C compiler. I used to moderate the c_language
> conference on BIX (back when that was a thing). I make my living
> writing C and C++ code every day. And yet, I had completely forgotten
> about this quirk.
>
> Example code shouldn't be used to establish how much more clever you
> are than the reader, it should be as easy to understand as possible.
>
> -- Ian
In Kib’s defense I think this is commonly mentioned in C99 books (at least
that’s where I learned of it) so it depends on when and where someone
learned. There are merits approaches of being explicit or brief. I have
no preference directly but we should probably try to be uniform in our
examples with whatever is most common in the docs already.
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r367343 - in head/sys/contrib/openzfs/include/os: freebsd/zfs/sys linux/zfs/sys
This doesn't answer all of your questions but one important thing to point out is that Mateusz is in communication with the OpenZFS and iX folks to coordinate these changes and avoid expected merge conflicts. The idealized workflow is that a change goes into OZFS first, but as long as folks are in agreement that can be expedited. Once src is on git, it is expected this type of cherry-pick in both directions will be easier to formally define. Regards, Kevin On Wed, Nov 4, 2020 at 2:36 PM Andriy Gapon wrote: > > On 04/11/2020 23:33, Mateusz Guzik wrote: > > Well, should you check OpenZFS github you will find I post pull > > request there as well. So whatever conflicts arise for people merging > > stuff back are to be just whacked in favor in what's in upstream. > > I certainly would, but how would I know that I should? > Any cross-reference would be of help both now and for the future code history > archaeology. > > > On 11/4/20, Andriy Gapon wrote: > >> On 04/11/2020 23:18, Mateusz Guzik wrote: > >>> Author: mjg > >>> Date: Wed Nov 4 21:18:51 2020 > >>> New Revision: 367343 > >>> URL: https://svnweb.freebsd.org/changeset/base/367343 > >>> > >>> Log: > >>> zfs: add branch prediction to ZFS_ENTER and ZFS_VERIFY_ZP macros > >>> > >>> They are expected to fail only in corner cases. > >>> > >>> Modified: > >>> head/sys/contrib/openzfs/include/os/freebsd/zfs/sys/zfs_znode_impl.h > >>> head/sys/contrib/openzfs/include/os/linux/zfs/sys/zfs_znode_impl.h > >> > >> Picking a random commit of many, is this how we do ZFS/OpenZFS changes now? > >> Can I do the same? > >> Who will be resolving any merge conflicts resulting from my changes? > >> > >> -- > >> Andriy Gapon > >> > > > > > > > -- > Andriy Gapon > ___ > svn-src-head@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r365071 - in head/sys: net net/altq net/route net80211 netgraph netgraph/atm netgraph/atm/ccatm netgraph/atm/sscfu netgraph/atm/sscop netgraph/atm/uni netgraph/bluetooth/common netgrap
On Fri, Sep 4, 2020 at 10:30 PM Warner Losh wrote: > > > > On Fri, Sep 4, 2020, 11:24 PM Kevin Bowling wrote: >> >> It's happening right now, and a few times a year at minimum from my >> memory. > > > Can I get a pointer? >From recent lossy memory, intel networking drivers (multiply), and the TCP stacks which are not very conforming. If click differential in phab and insert the query "style" you can see a lot of patches to fix things incrementally, as well as people commenting about it in review (usually respectfully as part of other review), or asking for people to break style changes out of behavior changes. > Warner > >> Any time someone proposes a formatter they are thrown shade, >> so the lack of progress there isn't surprising since the current >> culture would require a flame proof suit to make progress. It's kind >> of tautological that the status quo doesn't bother long time >> contributors due to selection bias, and doesn't mean for instance the >> lack of modern tooling is not off putting to younger developers that >> learn new tools and wonder why >> >> we remain in the stone age. An example >> we are finally overcoming is the git migration. Must we drag our feet >> every opportunity given to modernize ourselves from the other popular >> open source OS, or can we make obvious decisions to get ahead of them? >> I think if you ask anyone under the age of 30 you will get a pretty >> unanimous desire for automatic formatting. > > > Why strictly enforce anything is my point? It's one more thing to bounce a > commit for an issue that's about 30th on the list of problems. Why put any > energy at all into this when there is all cost and no benefit. Is this a common opinion? If people are this relaxed about it then I agree with you. > Warner > > Warner > >> On Fri, Sep 4, 2020 at 8:48 PM Warner Losh wrote: >> > >> > >> > >> > On Fri, Sep 4, 2020, 9:11 PM Kevin Bowling >> > wrote: >> >> >> >> I disagree that the problem is intractable. It's just a decision and >> >> it has a one time cost with long term benefits like paying off a high >> >> interest loan. The intractability opinion seemed justifiable for a >> >> long time but it's been proven false by other communities, >> >> particularly Go and Rust and there is nothing syntactically special >> >> about these languages that enable this; it's just a decision to make >> >> the style fit an extant formatter. An arbitrary formater may leave a >> >> little bit of annoyance to each person's taste, but that is a tiny >> >> drop in the bucket compared to never having to discuss and especially >> >> correct (which may /seem/ helpful but is pretty offputting to >> >> newcomers). A tool does it, and it takes the wind out of any passive >> >> aggressive bike shed opportunities from either maintainer or >> >> contributor. It sucks that downstreams have to fall in line, but that >> >> doesn't stop progress on any other major changes in FreeBSD. >> > >> > >> > How often are there really such bikesheds these days? I've seen no >> > evidence of them in the hundreds of phab reviews I've seen. It is the >> > ghost of the past when 10 or 15 years ago it was a big deal. Why bother >> > creating yet another barrier to commits because we used to suck, but now >> > have barely a rumble of bad behavior around it... >> > >> > Warner >> > >> >> On Fri, Sep 4, 2020 at 7:57 PM Warner Losh wrote: >> >> > >> >> > On Fri, Sep 4, 2020, 7:05 PM Mark Linimon wrote: >> >> > >> >> > > On Fri, Sep 04, 2020 at 02:15:04PM -0400, Andrew Gallatin wrote: >> >> > > > and I also anticipate it will cause problems with MFCs >> >> > > >> > >> > >> >> > > And existing PRs and DRs. >> >> > > >> >> > >> >> > Or we could just not bother we these changes at all. It's a pipe dream >> >> > we >> >> > will ever be style(9) compliant in all our code, or that we can >> >> > magically >> >> > have a tool to enforce in new commits. We have better things to worry >> >> > about. We should continue to ignore this non problem and for new users >> >> > point them at the 95% correct format thing to run their submitted >> >> > patches >> >> > if they submit something too far out of whack. >
Re: svn commit: r365071 - in head/sys: net net/altq net/route net80211 netgraph netgraph/atm netgraph/atm/ccatm netgraph/atm/sscfu netgraph/atm/sscop netgraph/atm/uni netgraph/bluetooth/common netgrap
It's happening right now, and a few times a year at minimum from my memory. Any time someone proposes a formatter they are thrown shade, so the lack of progress there isn't surprising since the current culture would require a flame proof suit to make progress. It's kind of tautological that the status quo doesn't bother long time contributors due to selection bias, and doesn't mean for instance the lack of modern tooling is not off putting to younger developers that learn new tools and wonder why we remain in the stone age. An example we are finally overcoming is the git migration. Must we drag our feet every opportunity given to modernize ourselves from the other popular open source OS, or can we make obvious decisions to get ahead of them? I think if you ask anyone under the age of 30 you will get a pretty unanimous desire for automatic formatting. On Fri, Sep 4, 2020 at 8:48 PM Warner Losh wrote: > > > > On Fri, Sep 4, 2020, 9:11 PM Kevin Bowling wrote: >> >> I disagree that the problem is intractable. It's just a decision and >> it has a one time cost with long term benefits like paying off a high >> interest loan. The intractability opinion seemed justifiable for a >> long time but it's been proven false by other communities, >> particularly Go and Rust and there is nothing syntactically special >> about these languages that enable this; it's just a decision to make >> the style fit an extant formatter. An arbitrary formater may leave a >> little bit of annoyance to each person's taste, but that is a tiny >> drop in the bucket compared to never having to discuss and especially >> correct (which may /seem/ helpful but is pretty offputting to >> newcomers). A tool does it, and it takes the wind out of any passive >> aggressive bike shed opportunities from either maintainer or >> contributor. It sucks that downstreams have to fall in line, but that >> doesn't stop progress on any other major changes in FreeBSD. > > > How often are there really such bikesheds these days? I've seen no evidence > of them in the hundreds of phab reviews I've seen. It is the ghost of the > past when 10 or 15 years ago it was a big deal. Why bother creating yet > another barrier to commits because we used to suck, but now have barely a > rumble of bad behavior around it... > > Warner > >> On Fri, Sep 4, 2020 at 7:57 PM Warner Losh wrote: >> > >> > On Fri, Sep 4, 2020, 7:05 PM Mark Linimon wrote: >> > >> > > On Fri, Sep 04, 2020 at 02:15:04PM -0400, Andrew Gallatin wrote: >> > > > and I also anticipate it will cause problems with MFCs >> > > > > >> > > And existing PRs and DRs. >> > > >> > >> > Or we could just not bother we these changes at all. It's a pipe dream we >> > will ever be style(9) compliant in all our code, or that we can magically >> > have a tool to enforce in new commits. We have better things to worry >> > about. We should continue to ignore this non problem and for new users >> > point them at the 95% correct format thing to run their submitted patches >> > if they submit something too far out of whack. >> > >> > The last sweep deleted a boatload of blank lines that were in there on >> > purpose. Not worth adding them back, but still annoying to no real benefit. >> > >> > I just don't see the benefits at all of doing anything here. The few >> > reviews that I've seen mention it seem to be the right level of effort. >> > >> > Warner >> > >> > > >> > ___ >> > svn-src-head@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/svn-src-head >> > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r365071 - in head/sys: net net/altq net/route net80211 netgraph netgraph/atm netgraph/atm/ccatm netgraph/atm/sscfu netgraph/atm/sscop netgraph/atm/uni netgraph/bluetooth/common netgrap
I disagree that the problem is intractable. It's just a decision and it has a one time cost with long term benefits like paying off a high interest loan. The intractability opinion seemed justifiable for a long time but it's been proven false by other communities, particularly Go and Rust and there is nothing syntactically special about these languages that enable this; it's just a decision to make the style fit an extant formatter. An arbitrary formater may leave a little bit of annoyance to each person's taste, but that is a tiny drop in the bucket compared to never having to discuss and especially correct (which may /seem/ helpful but is pretty offputting to newcomers). A tool does it, and it takes the wind out of any passive aggressive bike shed opportunities from either maintainer or contributor. It sucks that downstreams have to fall in line, but that doesn't stop progress on any other major changes in FreeBSD. On Fri, Sep 4, 2020 at 7:57 PM Warner Losh wrote: > > On Fri, Sep 4, 2020, 7:05 PM Mark Linimon wrote: > > > On Fri, Sep 04, 2020 at 02:15:04PM -0400, Andrew Gallatin wrote: > > > and I also anticipate it will cause problems with MFCs > > > > And existing PRs and DRs. > > > > Or we could just not bother we these changes at all. It's a pipe dream we > will ever be style(9) compliant in all our code, or that we can magically > have a tool to enforce in new commits. We have better things to worry > about. We should continue to ignore this non problem and for new users > point them at the 95% correct format thing to run their submitted patches > if they submit something too far out of whack. > > The last sweep deleted a boatload of blank lines that were in there on > purpose. Not worth adding them back, but still annoying to no real benefit. > > I just don't see the benefits at all of doing anything here. The few > reviews that I've seen mention it seem to be the right level of effort. > > Warner > > > > ___ > svn-src-head@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r361872 - head/sys/netinet
Out of curiosity what is panda?
On Sat, Jun 6, 2020 at 11:20 AM Michael Tuexen wrote:
>
> Author: tuexen
> Date: Sat Jun 6 18:20:09 2020
> New Revision: 361872
> URL: https://svnweb.freebsd.org/changeset/base/361872
>
> Log:
> Non-functional changes due to cleanup (upstream removing of Panda support)
> of the code
>
> MFC after:1 week
>
> Modified:
> head/sys/netinet/sctp_constants.h
> head/sys/netinet/sctp_indata.c
> head/sys/netinet/sctp_os.h
> head/sys/netinet/sctp_output.c
> head/sys/netinet/sctp_pcb.c
> head/sys/netinet/sctp_usrreq.c
>
> Modified: head/sys/netinet/sctp_constants.h
> ==
> --- head/sys/netinet/sctp_constants.h Sat Jun 6 17:48:55 2020
> (r361871)
> +++ head/sys/netinet/sctp_constants.h Sat Jun 6 18:20:09 2020
> (r361872)
> @@ -576,7 +576,6 @@ __FBSDID("$FreeBSD$");
> */
> #define SCTP_ASOC_MAX_CHUNKS_ON_QUEUE 512
>
> -
> /*
> * Basically the minimum amount of time before I do a early FR. Making this
> * value to low will cause duplicate retransmissions.
> @@ -756,9 +755,8 @@ __FBSDID("$FreeBSD$");
> #define SCTP_FROM_SCTP_ASCONF 0x8000
> #define SCTP_FROM_SCTP_OUTPUT 0x9000
> #define SCTP_FROM_SCTP_PEELOFF 0xa000
> -#define SCTP_FROM_SCTP_PANDA0xb000
> -#define SCTP_FROM_SCTP_SYSCTL 0xc000
> -#define SCTP_FROM_SCTP_CC_FUNCTIONS 0xd000
> +#define SCTP_FROM_SCTP_SYSCTL 0xb000
> +#define SCTP_FROM_SCTP_CC_FUNCTIONS 0xc000
>
> /* Location ID's */
> #define SCTP_LOC_1 0x0001
>
> Modified: head/sys/netinet/sctp_indata.c
> ==
> --- head/sys/netinet/sctp_indata.c Sat Jun 6 17:48:55 2020
> (r361871)
> +++ head/sys/netinet/sctp_indata.c Sat Jun 6 18:20:09 2020
> (r361872)
> @@ -2721,8 +2721,7 @@ sctp_process_data(struct mbuf **mm, int iphlen, int *o
> * cluster... i.e. it is a small packet sent in and yet the driver
> * underneath allocated a full cluster for it. If so we must copy it
> * to a smaller mbuf and free up the cluster mbuf. This will help
> -* with cluster starvation. Note for __Panda__ we don't do this
> -* since it has clusters all the way down to 64 bytes.
> +* with cluster starvation.
> */
> if (SCTP_BUF_LEN(m) < (long)MLEN && SCTP_BUF_NEXT(m) == NULL) {
> /* we only handle mbufs that are singletons.. not chains */
>
> Modified: head/sys/netinet/sctp_os.h
> ==
> --- head/sys/netinet/sctp_os.h Sat Jun 6 17:48:55 2020(r361871)
> +++ head/sys/netinet/sctp_os.h Sat Jun 6 18:20:09 2020(r361872)
> @@ -67,7 +67,6 @@ __FBSDID("$FreeBSD$");
>
>
>
> -
> /* All os's must implement this address gatherer. If
> * no VRF's exist, then vrf 0 is the only one and all
> * addresses and ifn's live here.
>
> Modified: head/sys/netinet/sctp_output.c
> ==
> --- head/sys/netinet/sctp_output.c Sat Jun 6 17:48:55 2020
> (r361871)
> +++ head/sys/netinet/sctp_output.c Sat Jun 6 18:20:09 2020
> (r361872)
> @@ -6475,8 +6475,7 @@ error_out:
> appendchain = clonechain;
> } else {
> if (!copy_by_ref &&
> - (sizeofcpy <=
> (int)SCTP_BASE_SYSCTL(sctp_mbuf_threshold_count) - 1) * MLEN) + MHLEN)))
> - ) {
> + (sizeofcpy <=
> (int)SCTP_BASE_SYSCTL(sctp_mbuf_threshold_count) - 1) * MLEN) + MHLEN
> {
> /* Its not in a cluster */
> if (*endofchain == NULL) {
> /* lets get a mbuf cluster */
> @@ -13526,12 +13525,6 @@ skip_preblock:
> error = sctp_msg_append(stcb, net, top, srcv, 0);
> top = NULL;
> if (sinfo_flags & SCTP_EOF) {
> - /*
> -* This should only happen for Panda for the mbuf
> -* send case, which does NOT yet support EEOR mode.
> -* Thus, we can just set this flag to do the proper
> -* EOF handling.
> -*/
> got_all_of_the_send = 1;
> }
> }
>
> Modified: head/sys/netinet/sctp_pcb.c
> ==
> --- head/sys/netinet/sctp_pcb.c Sat Jun 6 17:48:55 2020(r361871)
> +++ head/sys/netinet/sctp_pcb.c Sat Jun 6 18:20:09 2020(r361872)
> @@ -749,8 +749,7 @@ sctp_del_addr_from_vrf(uint32_t vrf_id, struct sockadd
>
> /*-
> * The name has priority over the ifn_index
> -
Re: svn commit: r360887 - in head/sys: conf powerpc/aim powerpc/booke powerpc/include powerpc/powerpc vm
Were there any major changes you can summarize from the P9BSD
integration, and any TODO list (perhaps wiki for this question)?
On Sun, May 10, 2020 at 7:33 PM Justin Hibbits wrote:
>
> Author: jhibbits
> Date: Mon May 11 02:33:37 2020
> New Revision: 360887
> URL: https://svnweb.freebsd.org/changeset/base/360887
>
> Log:
> powerpc64: Implement Radix MMU for POWER9 CPUs
>
> Summary:
> POWER9 supports two MMU formats: traditional hashed page tables, and Radix
> page tables, similar to what's presesnt on most other architectures. The
> PowerISA also specifies a process table -- a table of page table pointers--
> which on the POWER9 is only available with the Radix MMU, so we can take
> advantage of it with the Radix MMU driver.
>
> Written by Matt Macy.
>
> Differential Revision: https://reviews.freebsd.org/D19516
>
> Added:
> head/sys/powerpc/aim/mmu_radix.c (contents, props changed)
> Modified:
> head/sys/conf/files.powerpc
> head/sys/powerpc/aim/aim_machdep.c
> head/sys/powerpc/aim/mmu_oea.c
> head/sys/powerpc/aim/mmu_oea64.c
> head/sys/powerpc/booke/pmap.c
> head/sys/powerpc/include/cpufunc.h
> head/sys/powerpc/include/mmuvar.h
> head/sys/powerpc/include/param.h
> head/sys/powerpc/include/pmap.h
> head/sys/powerpc/include/proc.h
> head/sys/powerpc/include/pte.h
> head/sys/powerpc/include/spr.h
> head/sys/powerpc/include/sr.h
> head/sys/powerpc/include/vmparam.h
> head/sys/powerpc/powerpc/machdep.c
> head/sys/powerpc/powerpc/mmu_if.m
> head/sys/powerpc/powerpc/pmap_dispatch.c
> head/sys/powerpc/powerpc/trap.c
> head/sys/vm/vm_fault.c
>
> Modified: head/sys/conf/files.powerpc
> ==
> --- head/sys/conf/files.powerpc Mon May 11 01:20:40 2020(r360886)
> +++ head/sys/conf/files.powerpc Mon May 11 02:33:37 2020(r360887)
> @@ -135,6 +135,7 @@ powerpc/aim/locore.Soptionalaim
> no-obj
> powerpc/aim/aim_machdep.c optionalaim
> powerpc/aim/mmu_oea.c optionalaim powerpc
> powerpc/aim/mmu_oea64.coptionalaim
> +powerpc/aim/mmu_radix.coptionalaim powerpc64
> powerpc/aim/moea64_if.moptionalaim
> powerpc/aim/moea64_native.coptionalaim
> powerpc/aim/mp_cpudep.coptionalaim
>
> Modified: head/sys/powerpc/aim/aim_machdep.c
> ==
> --- head/sys/powerpc/aim/aim_machdep.c Mon May 11 01:20:40 2020
> (r360886)
> +++ head/sys/powerpc/aim/aim_machdep.c Mon May 11 02:33:37 2020
> (r360887)
> @@ -136,6 +136,8 @@ __FBSDID("$FreeBSD$");
> struct bat battable[16];
> #endif
>
> +int radix_mmu = 0;
> +
> #ifndef __powerpc64__
> /* Bits for running on 64-bit systems in 32-bit mode. */
> extern void*testppc64, *testppc64size;
> @@ -451,7 +453,14 @@ aim_cpu_init(vm_offset_t toc)
> * in case the platform module had a better idea of what we
> * should do.
> */
> - if (cpu_features & PPC_FEATURE_64)
> + if (cpu_features2 & PPC_FEATURE2_ARCH_3_00) {
> + radix_mmu = 0;
> + TUNABLE_INT_FETCH("radix_mmu", _mmu);
> + if (radix_mmu)
> + pmap_mmu_install(MMU_TYPE_RADIX, BUS_PROBE_GENERIC);
> + else
> + pmap_mmu_install(MMU_TYPE_G5, BUS_PROBE_GENERIC);
> + } else if (cpu_features & PPC_FEATURE_64)
> pmap_mmu_install(MMU_TYPE_G5, BUS_PROBE_GENERIC);
> else
> pmap_mmu_install(MMU_TYPE_OEA, BUS_PROBE_GENERIC);
>
> Modified: head/sys/powerpc/aim/mmu_oea.c
> ==
> --- head/sys/powerpc/aim/mmu_oea.c Mon May 11 01:20:40 2020
> (r360886)
> +++ head/sys/powerpc/aim/mmu_oea.c Mon May 11 02:33:37 2020
> (r360887)
> @@ -322,6 +322,7 @@ void moea_dumpsys_map(mmu_t mmu, vm_paddr_t pa, size_t
> void moea_scan_init(mmu_t mmu);
> vm_offset_t moea_quick_enter_page(mmu_t mmu, vm_page_t m);
> void moea_quick_remove_page(mmu_t mmu, vm_offset_t addr);
> +boolean_t moea_page_is_mapped(mmu_t mmu, vm_page_t m);
> static int moea_map_user_ptr(mmu_t mmu, pmap_t pm,
> volatile const void *uaddr, void **kaddr, size_t ulen, size_t *klen);
> static int moea_decode_kernel_ptr(mmu_t mmu, vm_offset_t addr,
> @@ -364,6 +365,7 @@ static mmu_method_t moea_methods[] = {
> MMUMETHOD(mmu_page_set_memattr, moea_page_set_memattr),
> MMUMETHOD(mmu_quick_enter_page, moea_quick_enter_page),
> MMUMETHOD(mmu_quick_remove_page, moea_quick_remove_page),
> + MMUMETHOD(mmu_page_is_mapped, moea_page_is_mapped),
>
> /* Internal interfaces */
> MMUMETHOD(mmu_bootstrap,moea_bootstrap),
> @@ -1102,6 +1104,12 @@ moea_quick_enter_page(mmu_t
Re: svn commit: r355837 - head/sys/cam
On Mon, Dec 16, 2019 at 5:44 PM Steven Hartland <
steven.hartl...@multiplay.co.uk> wrote:
> Sticky keyboard there Warner?
LOL
> On a more serious note the fact that the controllers lie about the
> underlying
> location of data, the impact of skipping the TRIM requests can have a
> much more
> serious impact than one might think depending on the drive, so this type of
> optimisation can significantly harm performance instead of increasing it.
>
> This was the main reasons we sponsored the initial ZFS TRIM
> implementation; as
> drive performance go so bad with no TRIM that SSD's performed worse than
> HDD's.
Have you been able to test the new OpenZFS/ZoF TRIM?
I notice the current FBSD one gets quite beleaguered with highly concurrent
poudriere as the snapshots are being reaped, I.e TRIMs totally swamp r/w
ops on the Plextor PCIe SSD I have. I haven’t tried ZoF on this machine
yet since it is my main workstation but will do so once it is ready for
mainline.
> Now obviously this was some time ago, but I wouldn't be surprised if
> there's bad
> hardware / firmware like this still being produced.
>
> Given that might be a good idea to make this optional, possibly even opt
> in not opt
> out?
>
> Regards
> Steve
>
> On 17/12/2019 00:13, Warner Losh wrote:
> > Author: imp
> > Date: Tue Dec 17 00:13:45 2019
> > New Revision: 355837
> > URL: https://svnweb.freebsd.org/changeset/base/355837
> >
> > Log:
> >Implement bio_speedup
> >
> >React to the BIO_SPEED command in the cam io scheduler by completing
> >as successful BIO_DELETE commands that are pending, up to the length
> >passed down in the BIO_SPEEDUP cmomand. The length passed down is a
> >hint for how much space on the drive needs to be recovered. By
> >completing the BIO_DELETE comomands, this allows the upper layers to
> >allocate and write to the blocks that were about to be trimmed. Since
> >FreeBSD implements TRIMSs as advisory, we can eliminliminate them and
> >go directly to writing.
> >
> >The biggest benefit from TRIMS coomes ffrom the drive being able t
> >ooptimize its free block pool inthe log run. There's little nto no
> >bene3efit in the shoort term. , sepeciall whn the trim is followed by
> >a write. Speedup lets us make this tradeoff.
> >
> >Reviewed by: kirk, kib
> >Sponsored by: Netflix
> >Differential Revision: https://reviews.freebsd.org/D18351
> >
> > Modified:
> >head/sys/cam/cam_iosched.c
> >
> > Modified: head/sys/cam/cam_iosched.c
> >
> ==
> > --- head/sys/cam/cam_iosched.cTue Dec 17 00:13:40 2019
> (r355836)
> > +++ head/sys/cam/cam_iosched.cTue Dec 17 00:13:45 2019
> (r355837)
> > @@ -1534,6 +1534,41 @@ cam_iosched_queue_work(struct cam_iosched_softc
> *isc,
> > {
> >
> > /*
> > + * A BIO_SPEEDUP from the uppper layers means that they have a
> block
> > + * shortage. At the present, this is only sent when we're trying to
> > + * allocate blocks, but have a shortage before giving up.
> bio_length is
> > + * the size of their shortage. We will complete just enough
> BIO_DELETEs
> > + * in the queue to satisfy the need. If bio_length is 0, we'll
> complete
> > + * them all. This allows the scheduler to delay BIO_DELETEs to
> improve
> > + * read/write performance without worrying about the upper layers.
> When
> > + * it's possibly a problem, we respond by pretending the
> BIO_DELETEs
> > + * just worked. We can't do anything about the BIO_DELETEs in the
> > + * hardware, though. We have to wait for them to complete.
> > + */
> > + if (bp->bio_cmd == BIO_SPEEDUP) {
> > + off_t len;
> > + struct bio *nbp;
> > +
> > + len = 0;
> > + while (bioq_first(>trim_queue) &&
> > + (bp->bio_length == 0 || len < bp->bio_length)) {
> > + nbp = bioq_takefirst(>trim_queue);
> > + len += nbp->bio_length;
> > + nbp->bio_error = 0;
> > + biodone(nbp);
> > + }
> > + if (bp->bio_length > 0) {
> > + if (bp->bio_length > len)
> > + bp->bio_resid = bp->bio_length - len;
> > + else
> > + bp->bio_resid = 0;
> > + }
> > + bp->bio_error = 0;
> > + biodone(bp);
> > + return;
> > + }
> > +
> > + /*
> >* If we get a BIO_FLUSH, and we're doing delayed BIO_DELETEs then
> we
> >* set the last tick time to one less than the current ticks minus
> the
> >* delay to force the BIO_DELETEs to be presented to the client
> driver.
> > @@ -1919,8 +1954,8 @@ DB_SHOW_COMMAND(iosched, cam_iosched_db_show)
> > db_printf("Trim Q len %d\n", biolen(>trim_queue));
> >
Re: svn commit: r354283 - in head: stand/libsa/zfs sys/cddl/boot/zfs
Yes, some systems with two disks in a mirror and an ssd as slog. What are you trying to guard against? I have never seen an issue but would like to be aware of potential problems with that system. On Sun, Nov 3, 2019 at 2:32 PM Toomas Soome wrote: > > > > On 3. Nov 2019, at 22:39, Kevin Bowling > wrote: > > > > I believe this is/was a common configuration, at least the few > > spinning disk based systems I have left have a slog. > > > > On boot pool? um. well, I’ll kick out that return then. > > rgds, > toomas > > > On Sun, Nov 3, 2019 at 10:55 AM Andriy Gapon wrote: > >> > >> On 03/11/2019 15:25, Toomas Soome wrote: > >>> Author: tsoome > >>> Date: Sun Nov 3 13:25:47 2019 > >>> New Revision: 354283 > >>> URL: https://svnweb.freebsd.org/changeset/base/354283 > >>> > >>> Log: > >>> loader: we do not support booting from pool with log device > >>> > >>> If pool has log device, stop there and tell about it. > >> > >> Why? > >> > >>> Modified: > >>> head/stand/libsa/zfs/zfs.c > >>> head/stand/libsa/zfs/zfsimpl.c > >>> head/sys/cddl/boot/zfs/zfsimpl.h > >> > >> > >> > >> -- > >> Andriy Gapon > >> ___ > >> svn-src-head@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/svn-src-head > >> To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" > > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r354283 - in head: stand/libsa/zfs sys/cddl/boot/zfs
I believe this is/was a common configuration, at least the few spinning disk based systems I have left have a slog. On Sun, Nov 3, 2019 at 10:55 AM Andriy Gapon wrote: > > On 03/11/2019 15:25, Toomas Soome wrote: > > Author: tsoome > > Date: Sun Nov 3 13:25:47 2019 > > New Revision: 354283 > > URL: https://svnweb.freebsd.org/changeset/base/354283 > > > > Log: > > loader: we do not support booting from pool with log device > > > > If pool has log device, stop there and tell about it. > > Why? > > > Modified: > > head/stand/libsa/zfs/zfs.c > > head/stand/libsa/zfs/zfsimpl.c > > head/sys/cddl/boot/zfs/zfsimpl.h > > > > -- > Andriy Gapon > ___ > svn-src-head@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344648 - in head: . sys/kern sys/sys
The vast majority of contributors don't enjoy nit-picking on these trivialities. If the broader developer community is not rallying for the revert and some core conspiracy doesn't care about it either, that forms the de facto opinion of the FreeBSD community of today that this is trivial and irrelevant. Yes, there is vocal absolutism on the fringes about SHALLS and MUSTS about all sorts of things aside from modernizing FreeBSD and making it viable on current generation hardware. These parties might be happier and better aligned with OpenBSD ideologically as well as personalities. Regards, Kevin On Fri, May 31, 2019 at 3:17 PM Rodney W. Grimes wrote: > > > I know of several people that have blocked your mail. Maybe a moment > > for reflection on your attitude and approach if you want to be taken > > seriously. > > I would consider repository damange and abuse to be VERY serious. > I would also consider the treatmeant I am seeing of danfe boarder > line on contempt. > But then I also know there are probably some that have blocked me. > The project, sadly is spiraling around a toilet, and someone is about to > flush > > It is not what you hear, it is what you are not hearing that makes me say > these things... > And espcially what core seams to not be willing to hear, and is literly (I > can proove this) > paying lip service to "solicited feedback". > > I asked about some of my solicited feedback, and a core member said he > could not find it in his inbox and that I needed to locate and provide > him a pointer to it. THAT my friends is not solicited feedback, that is > /dev/null of feedback and just plain out right unexcusable. > > And note above all else the "product" of the FreeBSD project is NOT > releases, it IS the repository, and if we get sloppy with that product > it makes life harder for our consumers. If you have ever tried to > find the history of a deleted object (which is what the process being > complained about here creaetes) it is a royal PITA. > > Regards, > Rod > > > On Fri, May 31, 2019 at 8:50 AM Alexey Dokuchaev wrote: > > > > > > On Fri, May 31, 2019 at 03:20:50PM +, Brooks Davis wrote: > > > > On Fri, May 24, 2019 at 09:11:36AM +, Alexey Dokuchaev wrote: > > > > > On Sun, Mar 10, 2019 at 03:11:40PM +, Alexey Dokuchaev wrote: > > > > > > On Thu, Feb 28, 2019 at 07:47:51AM +, Alexey Dokuchaev wrote: > > > > > > > On Wed, Feb 27, 2019 at 10:56:55PM +, Mateusz Guzik wrote: > > > > > > > > New Revision: 344648 > > > > > > > > URL: https://svnweb.freebsd.org/changeset/base/344648 > > > > > > > > > > > > > > > > Log: > > > > > > > > Rename seq to seqc to avoid namespace clashes with Linux > > > > > > > > > > > > > > > > ... > > > > > > > > Added: > > > > > > > > head/sys/sys/seqc.h (contents, props changed) > > > > > > > > Deleted: > > > > > > > > head/sys/sys/seq.h > > > > > > > > > > > > > > Why it was deleted and added as new file instead of being > > > > > > > repocopied? > > > > > > > > > > > > Retransmit. > > > > > > > > > > Ping! > > > > > > > > Do you have nothing better to do? > > > > > > Oh, I have a lot on my plate, thanks for asking. Now, back to the > > > subject: > > > > > > - I think that this commit was executed badly (not via repocopy) > > > - I've been trying to contact mjg@ for several weeks, to no avail :( > > > - All I get in return is an email from a fellow committer asking me > > > if I have anything better to do > > > > > > Sorry, I don't understand this. I don't understand why we ignore email > > > from our own community. I don't understand why we do not correct or at > > > least explain why what looks like a mistake is actually not(?). I don't > > > understand why I'm being ridiculed, not those who make dubious commits > > > and fail to defend them. > > > > > > ./danfe > > > ___ > > > svn-src-head@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/svn-src-head > > > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" > > > > > > -- > Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344648 - in head: . sys/kern sys/sys
I know of several people that have blocked your mail. Maybe a moment for reflection on your attitude and approach if you want to be taken seriously. On Fri, May 31, 2019 at 8:50 AM Alexey Dokuchaev wrote: > > On Fri, May 31, 2019 at 03:20:50PM +, Brooks Davis wrote: > > On Fri, May 24, 2019 at 09:11:36AM +, Alexey Dokuchaev wrote: > > > On Sun, Mar 10, 2019 at 03:11:40PM +, Alexey Dokuchaev wrote: > > > > On Thu, Feb 28, 2019 at 07:47:51AM +, Alexey Dokuchaev wrote: > > > > > On Wed, Feb 27, 2019 at 10:56:55PM +, Mateusz Guzik wrote: > > > > > > New Revision: 344648 > > > > > > URL: https://svnweb.freebsd.org/changeset/base/344648 > > > > > > > > > > > > Log: > > > > > > Rename seq to seqc to avoid namespace clashes with Linux > > > > > > > > > > > > ... > > > > > > Added: > > > > > > head/sys/sys/seqc.h (contents, props changed) > > > > > > Deleted: > > > > > > head/sys/sys/seq.h > > > > > > > > > > Why it was deleted and added as new file instead of being repocopied? > > > > > > > > Retransmit. > > > > > > Ping! > > > > Do you have nothing better to do? > > Oh, I have a lot on my plate, thanks for asking. Now, back to the subject: > > - I think that this commit was executed badly (not via repocopy) > - I've been trying to contact mjg@ for several weeks, to no avail :( > - All I get in return is an email from a fellow committer asking me > if I have anything better to do > > Sorry, I don't understand this. I don't understand why we ignore email > from our own community. I don't understand why we do not correct or at > least explain why what looks like a mistake is actually not(?). I don't > understand why I'm being ridiculed, not those who make dubious commits > and fail to defend them. > > ./danfe > ___ > svn-src-head@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r343125 - head/sys/dev/ioat
Out of curiosity are you using this driver? Any performance data? On Thu, Jan 17, 2019 at 4:21 PM Conrad Meyer wrote: > Author: cem > Date: Thu Jan 17 23:21:02 2019 > New Revision: 343125 > URL: https://svnweb.freebsd.org/changeset/base/343125 > > Log: > ioat(4): Set __result_use_check on ioat_acquire_reserve > > Even M_WAITOK callers must check for failure. For example, if the > device is > quiescing, either due to automatic error-recovery induced reset, or due > to > administrative detach, the routine will return ENXIO and the acquire > reference will not be held. So, there is no mode in which it is safe to > assume the routine succeeds without checking. > > Sponsored by: Dell EMC Isilon > > Modified: > head/sys/dev/ioat/ioat.h > > Modified: head/sys/dev/ioat/ioat.h > > == > --- head/sys/dev/ioat/ioat.hThu Jan 17 22:00:02 2019(r343124) > +++ head/sys/dev/ioat/ioat.hThu Jan 17 23:21:02 2019(r343125) > @@ -173,7 +173,8 @@ void ioat_release(bus_dmaengine_t dmaengine); > * > * On failure, the caller does not hold the dmaengine. > */ > -int ioat_acquire_reserve(bus_dmaengine_t dmaengine, unsigned n, int > mflags); > +int ioat_acquire_reserve(bus_dmaengine_t dmaengine, unsigned n, int > mflags) > +__result_use_check; > > /* > * Issue a blockfill operation. The 64-bit pattern 'fillpattern' is > written to > ___ > svn-src-head@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r342057 - head/crypto/openssl/crypto/engine
But why, you can trivially see the open() call with truss or more advanced
tracers if you are debugging this
On Thu, Dec 13, 2018 at 6:39 PM Kubilay Kocak wrote:
> On 14/12/2018 12:06 pm, Jung-uk Kim wrote:
> > Author: jkim
> > Date: Fri Dec 14 01:06:34 2018
> > New Revision: 342057
> > URL: https://svnweb.freebsd.org/changeset/base/342057
> >
> > Log:
> >Do not complain when /dev/crypto does not exist.
> >
> >Now the new devcrypto engine is enabled since r342009, many users
> started
> >seeing "Could not open /dev/crypto: No such file or directory".
> Disable
> >the annoying error message as it is not very useful anyway.
> >
> >Note the patch was submitted upstream.
> >
> >https://github.com/openssl/openssl/pull/7896
> >
> > Modified:
> >head/crypto/openssl/crypto/engine/eng_devcrypto.c
> >
> > Modified: head/crypto/openssl/crypto/engine/eng_devcrypto.c
> >
> ==
> > --- head/crypto/openssl/crypto/engine/eng_devcrypto.c Fri Dec 14
> 00:40:38 2018(r342056)
> > +++ head/crypto/openssl/crypto/engine/eng_devcrypto.c Fri Dec 14
> 01:06:34 2018(r342057)
> > @@ -24,6 +24,8 @@
> >
> > #include "internal/engine.h"
> >
> > +/* #define ENGINE_DEVCRYPTO_DEBUG */
> > +
> > #ifdef CRYPTO_ALGORITHM_MIN
> > # define CHECK_BSD_STYLE_MACROS
> > #endif
> > @@ -615,6 +617,9 @@ void engine_load_devcrypto_int()
> > ENGINE *e = NULL;
> >
> > if ((cfd = open("/dev/crypto", O_RDWR, 0)) < 0) {
> > +#ifndef ENGINE_DEVCRYPTO_DEBUG
> > +if (errno != ENOENT)
> > +#endif
> > fprintf(stderr, "Could not open /dev/crypto: %s\n",
> strerror(errno));
> > return;
> > }
>
> How trivially could devcrypto_debug be modified to be a runtime
> configuration (say sysctl) setting?
> ___
> svn-src-head@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r341682 - head/sys/sys
Humor me with a kernel feature that will sue 64b atomics while both instruction streams are ping ponging on the hypothetical lock because this thread is getting pretty far out there.. On Mon, Dec 10, 2018 at 5:27 PM Justin Hibbits wrote: > > > > On Mon, Dec 10, 2018, 17:57 Ian Lepore > >> On Mon, 2018-12-10 at 14:15 -0800, John Baldwin wrote: >> > On 12/8/18 7:43 PM, Warner Losh wrote: >> > > >> > > >> > > >> > > On Sat, Dec 8, 2018, 8:36 PM Kevin Bowling > > > m <mailto:kevin.bowl...@kev009.com> wrote: >> > > >> > > On Sat, Dec 8, 2018 at 12:09 AM Mateusz Guzik > > > m <mailto:mjgu...@gmail.com>> wrote: >> > > >> > > > >> > > > Fully satisfying solution would be that all architectures get >> > > 64-bit >> > > > ops, even if in the worst case they end up taking a lock. >> > > Then >> > > > subsystems would not have to ifdef on anything. However, >> > > there >> > > > was some opposition to this proposal and I don't think this >> > > is >> > > > important enough to push. >> > > >> > > Mateusz, >> > > >> > > Who is opposing this particular polyfill solution? Scott Long >> > > brought >> > > up a situation in driver development where this would be useful >> > > as >> > > well. The polyfills lower the cognitive load and #ifdef soup >> > > which >> > > are the right call here regardless of performance on toy ports. >> > > >> > > >> > > I don't recall seeing the opposition either. It would have to be a >> > > global lock for all 64bit atomics but I think it would only be >> > > 2 atomics on those architectures. >> > It would have to be a spin lock, so in the case of unrl you would be >> > trading >> > an operation on one of N regular mutexes for a single spin lock that >> > was >> > also contested by other things. This would be pretty crappy. For >> > drivers >> > that aren't actually used on platforms without 32-bit atomics we can >> > simply >> > not build them in sys/modules/Makefile or not put them in >> > GENERIC. For >> > something in the core kernel like unrl I think we will have to do >> > what >> > Mateusz has done here. >> > >> >> On a single-core system all you need to implement 64-bit atomics in the >> kernel is to disable interrupts around using normal load/store >> operations on the values. Do we have any platforms that are SMP but >> don't have hardware primitives for 64-bit atomics? >> >> -- Ian > > > There were some dual processor G4 machines. I have one. It doesn't have 64 > bit atomics. > > - Justin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r341682 - head/sys/sys
Right we are talking about a polyfill for systems that have 1-2 cores in practice. You're not going to crank high parallelism on these global locks in practice and the common lock may help performance due to cache residence for all we know. This is a lot of ballyhoo for a decision that should favor the reduction of complexity, clean KPIs, and overwhelming majority of machines that have 64b atomics, not scattering ifdefs in the code for niche performance. Regards, Kevin On Mon, Dec 10, 2018 at 4:57 PM Ian Lepore wrote: > > On Mon, 2018-12-10 at 14:15 -0800, John Baldwin wrote: > > On 12/8/18 7:43 PM, Warner Losh wrote: > > > > > > > > > > > > On Sat, Dec 8, 2018, 8:36 PM Kevin Bowling > > m <mailto:kevin.bowl...@kev009.com> wrote: > > > > > > On Sat, Dec 8, 2018 at 12:09 AM Mateusz Guzik > > m <mailto:mjgu...@gmail.com>> wrote: > > > > > > > > > > > Fully satisfying solution would be that all architectures get > > > 64-bit > > > > ops, even if in the worst case they end up taking a lock. > > > Then > > > > subsystems would not have to ifdef on anything. However, > > > there > > > > was some opposition to this proposal and I don't think this > > > is > > > > important enough to push. > > > > > > Mateusz, > > > > > > Who is opposing this particular polyfill solution? Scott Long > > > brought > > > up a situation in driver development where this would be useful > > > as > > > well. The polyfills lower the cognitive load and #ifdef soup > > > which > > > are the right call here regardless of performance on toy ports. > > > > > > > > > I don't recall seeing the opposition either. It would have to be a > > > global lock for all 64bit atomics but I think it would only be > > > 2 atomics on those architectures. > > It would have to be a spin lock, so in the case of unrl you would be > > trading > > an operation on one of N regular mutexes for a single spin lock that > > was > > also contested by other things. This would be pretty crappy. For > > drivers > > that aren't actually used on platforms without 32-bit atomics we can > > simply > > not build them in sys/modules/Makefile or not put them in > > GENERIC. For > > something in the core kernel like unrl I think we will have to do > > what > > Mateusz has done here. > > > > On a single-core system all you need to implement 64-bit atomics in the > kernel is to disable interrupts around using normal load/store > operations on the values. Do we have any platforms that are SMP but > don't have hardware primitives for 64-bit atomics? > > -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r341682 - head/sys/sys
On Sat, Dec 8, 2018 at 12:09 AM Mateusz Guzik wrote: > > Fully satisfying solution would be that all architectures get 64-bit > ops, even if in the worst case they end up taking a lock. Then > subsystems would not have to ifdef on anything. However, there > was some opposition to this proposal and I don't think this is > important enough to push. Mateusz, Who is opposing this particular polyfill solution? Scott Long brought up a situation in driver development where this would be useful as well. The polyfills lower the cognitive load and #ifdef soup which are the right call here regardless of performance on toy ports. Regards, Kevin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r340591 - in head/sys: kern sys
Author: kbowling (ports committer)
Date: Mon Nov 19 00:54:31 2018
New Revision: 340591
URL: https://svnweb.freebsd.org/changeset/base/340591
Log:
Retire sbsndptr() KPI
As of r340465 all consumers use sbsndptr_adv and sbsndptr_noadv
Reviewed by: gallatin
Approved by: krion (mentor)
Differential Revision:https://reviews.freebsd.org/D17998
Modified:
head/sys/kern/uipc_sockbuf.c
head/sys/sys/sockbuf.h
Modified: head/sys/kern/uipc_sockbuf.c
==
--- head/sys/kern/uipc_sockbuf.cMon Nov 19 00:49:08 2018
(r340590)
+++ head/sys/kern/uipc_sockbuf.cMon Nov 19 00:54:31 2018
(r340591)
@@ -1224,53 +1224,6 @@ sbdrop(struct sockbuf *sb, int len)
m_freem(mfree);
}
-/*
- * Maintain a pointer and offset pair into the socket buffer mbuf chain to
- * avoid traversal of the entire socket buffer for larger offsets.
- */
-struct mbuf *
-sbsndptr(struct sockbuf *sb, u_int off, u_int len, u_int *moff)
-{
- struct mbuf *m, *ret;
-
- KASSERT(sb->sb_mb != NULL, ("%s: sb_mb is NULL", __func__));
- KASSERT(off + len <= sb->sb_acc, ("%s: beyond sb", __func__));
- KASSERT(sb->sb_sndptroff <= sb->sb_acc, ("%s: sndptroff broken",
__func__));
-
- /*
-* Is off below stored offset? Happens on retransmits.
-* Just return, we can't help here.
-*/
- if (sb->sb_sndptroff > off) {
- *moff = off;
- return (sb->sb_mb);
- }
-
- /* Return closest mbuf in chain for current offset. */
- *moff = off - sb->sb_sndptroff;
- m = ret = sb->sb_sndptr ? sb->sb_sndptr : sb->sb_mb;
- if (*moff == m->m_len) {
- *moff = 0;
- sb->sb_sndptroff += m->m_len;
- m = ret = m->m_next;
- KASSERT(ret->m_len > 0,
- ("mbuf %p in sockbuf %p chain has no valid data", ret, sb));
- }
-
- /* Advance by len to be as close as possible for the next transmit. */
- for (off = off - sb->sb_sndptroff + len - 1;
-off > 0 && m != NULL && off >= m->m_len;
-m = m->m_next) {
- sb->sb_sndptroff += m->m_len;
- off -= m->m_len;
- }
- if (off > 0 && m == NULL)
- panic("%s: sockbuf %p and mbuf %p clashing", __func__, sb, ret);
- sb->sb_sndptr = m;
-
- return (ret);
-}
-
struct mbuf *
sbsndptr_noadv(struct sockbuf *sb, uint32_t off, uint32_t *moff)
{
Modified: head/sys/sys/sockbuf.h
==
--- head/sys/sys/sockbuf.h Mon Nov 19 00:49:08 2018(r340590)
+++ head/sys/sys/sockbuf.h Mon Nov 19 00:54:31 2018(r340591)
@@ -163,8 +163,6 @@ voidsbrelease_locked(struct sockbuf *sb, struct
socke
intsbsetopt(struct socket *so, int cmd, u_long cc);
intsbreserve_locked(struct sockbuf *sb, u_long cc, struct socket *so,
struct thread *td);
-struct mbuf *
- sbsndptr(struct sockbuf *sb, u_int off, u_int len, u_int *moff);
void sbsndptr_adv(struct sockbuf *sb, struct mbuf *mb, u_int len);
struct mbuf *
sbsndptr_noadv(struct sockbuf *sb, u_int off, u_int *moff);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r340393 - head/sys/powerpc/conf
Author: kbowling (ports committer) Date: Tue Nov 13 09:19:07 2018 New Revision: 340393 URL: https://svnweb.freebsd.org/changeset/base/340393 Log: powerpc64: reduce GENERIC64 diff versus amd64 GENERIC Reviewed by: jhibbits Approved by: timur (mentor) Differential Revision:https://reviews.freebsd.org/D17515 Modified: head/sys/powerpc/conf/GENERIC64 Modified: head/sys/powerpc/conf/GENERIC64 == --- head/sys/powerpc/conf/GENERIC64 Tue Nov 13 04:34:30 2018 (r340392) +++ head/sys/powerpc/conf/GENERIC64 Tue Nov 13 09:19:07 2018 (r340393) @@ -39,6 +39,10 @@ options PREEMPTION #Enable kernel thread preemption optionsVIMAGE # Subsystem virtualization, e.g. VNET optionsINET#InterNETworking optionsINET6 #IPv6 communications protocols +optionsIPSEC # IP (v4/v6) security +optionsIPSEC_SUPPORT # Allow kldload of ipsec and tcpmd5 +optionsTCP_OFFLOAD # TCP offload +optionsTCP_BLACKBOX# Enhanced TCP event logging optionsTCP_HHOOK # hhook(9) framework for TCP optionsTCP_RFC7413 # TCP Fast Open optionsSCTP#Stream Control Transmission Protocol @@ -83,6 +87,9 @@ options MAC # TrustedBSD MAC Framework optionsKDTRACE_HOOKS # Kernel DTrace hooks optionsDDB_CTF # Kernel ELF linker loads CTF data optionsINCLUDE_CONFIG_FILE # Include this file in kernel +optionsRACCT # Resource accounting framework +optionsRACCT_DEFAULT_TO_DISABLED # Set kern.racct.enable=0 by default +optionsRCTL# Resource limits # Debugging support. Always need this: optionsKDB # Enable kernel debugger support. @@ -136,10 +143,12 @@ devicesym # NCR/Symbios/LSI Logic 53C8XX/53C1010/53 # ATA/SCSI peripherals device scbus # SCSI bus (required for ATA/SCSI) +device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct ATA/SCSI access) +device ses # Enclosure Service (SES and SAF-TE) # vt is the default console driver, resembling an SCO console device vt # Core console driver @@ -168,6 +177,7 @@ device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 # Pseudo devices. +device crypto # core crypto support device loop# Network loopback device random # Entropy device device ether # Ethernet support @@ -193,10 +203,8 @@ device usb # USB Bus (required) device uhid# "Human Interface Devices" device ukbd# Keyboard optionsKBD_INSTALL_CDEV # install a CDEV entry in /dev -device ulpt# Printer device umass # Disks/Mass storage - Requires scbus and da0 device ums # Mouse -device urio# Diamond Rio 500 MP3 player # USB Ethernet device aue # ADMtek USB Ethernet device axe # ASIX Electronics USB Ethernet @@ -236,3 +244,5 @@ device sound # Generic sound driver (required) device snd_ai2s# Apple I2S audio device snd_uaudio # USB Audio +# Netmap provides direct access to TX/RX rings on supported NICs +device netmap # netmap(4) support ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r340387 - in head/sys: amd64/conf i386/conf
ppc64 will be the next arch after amd64 to get modern graphics (https://github.com/POWER9BSD/freebsd/commits/projects/lkpi) but we like the tier-2 status for now and will replay changes from amd64 GENERIC once I'm able to test. FWIW evdev is the standard with libinput for X11 under Linux. It's useful for modern trackpads and has no downsides for traditional keyboards and mice under X11. It's also a requisite for Wayland. So I am happy to see this change, thanks Niclas!. Regards, Kevin On Mon, Nov 12, 2018 at 5:50 PM Warner Losh wrote: > > On Mon, Nov 12, 2018 at 5:30 PM Rodney W. Grimes < > free...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > On Mon, Nov 12, 2018, 3:12 PM Rodney W. Grimes < > > > free...@pdx.rh.cn85.dnsmgr.net wrote: > > > > > > > > Author: zeising (doc,ports committer) > > > > > Date: Mon Nov 12 21:01:28 2018 > > > > > New Revision: 340387 > > > > > URL: https://svnweb.freebsd.org/changeset/base/340387 > > > > > > > > > > Log: > > > > > Add evdev support to amd64 and i386 kernels > > > > > > > > > > Include evdev support and drivers in the amd64 and i386 GENERIC and > > > > MINIMAL > > > > > kernels. Evdev is used by X and wayland to handle input devices, > > and > > > > this > > > > > change, together with upcomming changes in ports will make us > > handle > > > > input > > > > > devices better in graphical UIs. > > > > > > > > Well these "upcomming" changes in ports effect aarch64 and powerpc > > > > who are also consumers of X? > > > > > > > > > > Likely. Though there is little experience with them, so we don't know if > > it > > > is even safe to turn them on there yet. This has taken 6 months to get > > > stable on x86 due to its fragile console locking protocol. Similar time > > has > > > not been invested elsewhere, so until that happens, we should keep them > > off > > > by default. Otherwise we run the risk of destabilizing these platforms, > > > even for people who don't use X. As tier 2 platforms, this has been how > > > we've traditionally approached risk. Even though aarch64 is approaching > > > tier1 status overall, in graphics it is still lagging. > > > > From some place aarch64 is already a tier1 platform, specifically > > it is listed as such in the pkg.freebsd.org package download page. > > > > Graphics on aarch64 is tier 2, and will remain tier 2 for the foreseeable > future. Tier 1 support requires that we leverage other people's drivers, > and we can't easily do that w/o a good linux compat layer. The structure of > FreeBSD and Linux are just enough different that doing so is somewhat > tricky and labor intensive. This is especially true for the acceleration > features. Basic framebuffer support isn't terribly hard, but to get good 2d > and 3d acceleration, we'll likely need to run upstream vendor's code (which > in many cases is available only as a binary blob + linux glue). > > > > My real concern here is that it sounded like changes to what are > > in the ports/packages are going to be made in such a way that you > > are required to have evdev to use them. If this suddently becomes > > mandatory to be able to use X we need to ensure that this code > > (evdev) does infact work on aarch64 and others before such changes are > > put in place. My reading here is that this code is only avaliable > > as static compile into the kernel, aka no moduleto load, making this > > a non-trivial road block to rpi3, etc users. > > > > This is just for touchscreen support on x86, which requires evdev to work > well. Whatever works today won't change. However, without a lot of testing, > I'm hesitant to blindly enable it on aarch64. Once that changes, we can > turn it on, but until then it would be unwise. And evdev can be turned off > on a per-platform basis in the packages / ports tree should the need arise. > I don't think this is going to be an issue. > > Warner > > > > > Warner > > > > > > > > > > Reviewed by:wulf, bapt, imp > > > > > Approved by:imp > > > > > Differential Revision: https://reviews.freebsd.org/D17912 > > > > > > > > > > Modified: > > > > > head/sys/amd64/conf/GENERIC > > > > > head/sys/amd64/conf/MINIMAL > > > > > head/sys/i386/conf/GENERIC > > > > > head/sys/i386/conf/MINIMAL > > > > > > > > > > Modified: head/sys/amd64/conf/GENERIC > > > > > > > > > > > == > > > > > --- head/sys/amd64/conf/GENERIC Mon Nov 12 20:44:22 2018 > > > > (r340386) > > > > > +++ head/sys/amd64/conf/GENERIC Mon Nov 12 21:01:28 2018 > > > > (r340387) > > > > > @@ -372,3 +372,8 @@ devicevmx # > > VMware > > > > VMXNET3 Ethernet > > > > > > > > > > # Netmap provides direct access to TX/RX rings on supported NICs > > > > > device netmap # netmap(4) support > > > > > + > > > > > +# evdev interface > > > > > +options EVDEV_SUPPORT # evdev support in legacy > > drivers > > > > >
Re: a word of caution about the new default of so-reuseport on FreeBSD
Without looking at the unbound source, I assume they want the semantics of what we call SO_REUSEPORT_LB in FreeBSD >= 12.0. See setsockopt(2) for a brief description. Whether it makes sense to conditionalize that or simply disable the sockopt I have no opinion on just sharing the above knowledge. Regards, On Wed, Oct 10, 2018 at 1:26 PM Dag-Erling Smørgrav wrote: > > Harry Schmalzbauer writes: > > Most likely you are aware about the "so-reuseport" topic via Unbound-users. > > I didn't follow the diff/issue at all, just wanted to point it out, so > > somebody from the experts team can decide if 1.8.1 is suitable (with > > the 1.8.1 defaults) for shipping... > > I'll apply the upstream patch (r4932) before the release. Right now I > need to focus on DNS-over-TLS support. > > DES > -- > Dag-Erling Smørgrav - d...@des.no > ___ > svn-src-head@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r339098 - in head: . sys/powerpc/conf
Author: kbowling (ports committer) Date: Tue Oct 2 21:36:00 2018 New Revision: 339098 URL: https://svnweb.freebsd.org/changeset/base/339098 Log: Use nda(4) on powerpc64 Approved by: re@ (kib), krion (mentor), imp Differential Revision:https://reviews.freebsd.org/D17368 Modified: head/UPDATING head/sys/powerpc/conf/GENERIC64 Modified: head/UPDATING == --- head/UPDATING Tue Oct 2 21:20:45 2018(r339097) +++ head/UPDATING Tue Oct 2 21:36:00 2018(r339098) @@ -31,6 +31,13 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12.x IS SLOW: disable the most expensive debugging functionality run "ln -s 'abort:false,junk:false' /etc/malloc.conf".) +20181002: + The cam(4) based nda(4) driver will be used over nvd(4) by default on + powerpc64. You may set 'options NVME_USE_NVD=1' in your kernel conf or + loader tunable 'hw.nvme.use_nvd=1' if you wish to use the existing + driver. Make sure to edit /boot/etc/kboot.conf and fstab to use the + nda device name. + 20180913: Reproducible build mode is now on by default, in preparation for FreeBSD 12.0. This eliminates build metadata such as the user, Modified: head/sys/powerpc/conf/GENERIC64 == --- head/sys/powerpc/conf/GENERIC64 Tue Oct 2 21:20:45 2018 (r339097) +++ head/sys/powerpc/conf/GENERIC64 Tue Oct 2 21:36:00 2018 (r339098) @@ -120,6 +120,7 @@ device siis# SiliconImage SiI3124/SiI3132/SiI3531 S # NVM Express (NVMe) support device nvme# base NVMe driver +optionsNVME_USE_NVD=0 # prefer the cam(4) based nda(4) driver device nvd # expose NVMe namespaces as disks, depends on nvme # SCSI Controllers ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r338465 - in head: share/misc usr.bin/calendar/calendars
Author: kbowling (ports committer) Date: Wed Sep 5 01:46:27 2018 New Revision: 338465 URL: https://svnweb.freebsd.org/changeset/base/338465 Log: Add kbowling to ports committer list and calendar Approved by: re (rgrimes), timur (mentor), krion (mentor) Differential Revision:https://reviews.freebsd.org/D17021 Modified: head/share/misc/committers-ports.dot head/usr.bin/calendar/calendars/calendar.freebsd Modified: head/share/misc/committers-ports.dot == --- head/share/misc/committers-ports.dotWed Sep 5 01:33:30 2018 (r338464) +++ head/share/misc/committers-ports.dotWed Sep 5 01:46:27 2018 (r338465) @@ -149,6 +149,7 @@ jsm [label="Jesper Schmitz Mouridsen\n...@freebsd.org\ junovitch [label="Jason Unovitch\njunovi...@freebsd.org\n2015/07/27"] jylefort [label="Jean-Yves Lefort\njylef...@freebsd.org\n2005/04/12"] kami [label="Dominic Fandrey\nk...@freebsd.org\n2014/09/09"] +kbowling [label="Kevin Bowling\nkbowl...@freebsd.org\n2018/09/02"] kevlo [label="Kevin Lo\nke...@freebsd.org\n2003/02/21"] kmoore [label="Kris Moore\nkmo...@freebsd.org\n2009/04/14"] knu [label="Akinori Musha\n...@freebsd.org\n2000/03/22"] @@ -487,6 +488,7 @@ koobs -> xmj krion -> "0mp" krion -> brooks +krion -> kbowling krion -> miwi krion -> novel krion -> philip @@ -703,6 +705,8 @@ tcberner -> arrowd thierry -> jadawin thierry -> riggs + +timur -> kbowling tmclaugh -> itetcu tmclaugh -> xride Modified: head/usr.bin/calendar/calendars/calendar.freebsd == --- head/usr.bin/calendar/calendars/calendar.freebsdWed Sep 5 01:33:30 2018(r338464) +++ head/usr.bin/calendar/calendars/calendar.freebsdWed Sep 5 01:46:27 2018(r338465) @@ -87,6 +87,7 @@ 02/23 Mathieu Arnold born in Champigny sur Marne, Val de Marne, France, 1978 02/24 Johan Karlsson born in Mariannelund, Sweden, 1974 02/24 Colin Percival born in Burnaby, Canada, 1981 +02/24 Kevin Bowling born in Scottsdale, Arizona, United States, 1989 02/26 Pietro Cerutti born in Faido, Switzerland, 1984 02/28 Daichi GOTO born in Shimizu Suntou, Shizuoka, Japan, 1980 02/28 Ruslan Makhmatkhanov born in Rostov-on-Don, USSR, 1984 ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r338348 - in head/sys/dev: drm drm2
Legacy would be needed by existing these existing ppc64 at the moment
and I pointed out in the review that LP64 is not the correct heuristic
but was dismissed without understanding the point.
On Tue, Aug 28, 2018 at 10:36 AM, Mark Millard via svn-src-head
wrote:
> For the below I wonder if graphics/drm-stable-kmod
> would be correct for old powerpc64 PowerMac's and
> such.
>
> Presuming graphics/drm-legacy-kmod (I do not know):
> Tier 2, old equipment, etc. so it may just be an item
> for handling questions on the lists rather than making
> a mess instead of the below to cover sufficient
> alternatives.
>
>> Modified: head/sys/dev/drm2/drm_os_freebsd.h
>> ==
>> --- head/sys/dev/drm2/drm_os_freebsd.hTue Aug 28 14:46:49 2018
>> (r338347)
>> +++ head/sys/dev/drm2/drm_os_freebsd.hTue Aug 28 14:46:55 2018
>> (r338348)
>> @@ -154,6 +154,20 @@ typedef void irqreturn_t;
>> *(volatile u_int64_t *)(((vm_offset_t)(map)->handle) + \
>> (vm_offset_t)(offset)) = htole64(val)
>>
>> +#ifdef __LP64__
>> +#define DRM_PORT "graphics/drm-stable-kmod"
>> +#else
>> +#define DRM_PORT "graphics/drm-legacy-kmod"
>> +#endif
>> +
>> +#define DRM_OBSOLETE(dev)
>> \
>> +do {
>> \
>> + device_printf(dev,
>> "===\n"); \
>> + device_printf(dev, "This code is obsolete abandonware. Install the "
>> DRM_PORT " pkg\n"); \
>> + device_printf(dev,
>> "===\n"); \
>> + gone_in_dev(dev, 13, "drm2 drivers");
>> \
>> +} while (0)
>> +
>> /* DRM_READMEMORYBARRIER() prevents reordering of reads.
>> * DRM_WRITEMEMORYBARRIER() prevents reordering of writes.
>> * DRM_MEMORYBARRIER() prevents reordering of reads and writes.
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>
> ___
> svn-src-head@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r338172 - Now deprecating DRM
On Thu, Aug 23, 2018 at 10:55 AM, Rodney W. Grimes wrote: > [ Charset UTF-8 unsupported, converting... ] >> On Wed, Aug 22, 2018 at 10:08 AM Rodney W. Grimes < >> free...@pdx.rh.cn85.dnsmgr.net> wrote: >> >> > I think this deprecation is a rather serious deviation >> > from the stated policy, in that 0 notification was >> > made, core IMHO, has overstepped some boundaries in >> > that respect. These policies are promises to the >> > downstream consumers, and violating them is very >> > poor planning. >> > >> >> Despite what the commit said, core didn't actually formally approve it >> before the fact. That was one of the many miscommunications surrounding >> this episode. > > Well I would say inlight of that fact a revert should be a no questions > asked, doing much else risks build breakage within hours of code freeze. > > >> I don't think you'll find anybody who would say this was well planned or >> well executed. > > Agreed, so lets be simple in correcting it? This is feeding more unnecessary inflammation. I disagree with this statement and so do a lot of other people including multiple on core. There is certainly an opportunity to do better, but the policy and procedures being spoken are not installed yet, we're under hard deadline to lock down the 12.x ABI and the proposed review for a tegra124-private drm2 addresses all who have standing in the matter. Matt Joras offered a very professional and rational take on things on developers@. I would encourage people to noodle on that before continuing to inflame the issues. > From some investigation even the claim that "in base drm conflicts with > ports drm" is not totally true, you just have to take a few steps to > be sure you do not load the base versions, and do load the ports version. It does. The graphics team unilaterally agrees. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r338172 - Now deprecating DRM
Your fundamental premise is off base, drm is not gone, it's been moved. Regards, Kevin On Wed, Aug 22, 2018 at 9:08 AM, Rodney W. Grimes wrote: >> > >> > Could you please create a stable/11 deprecation change. >> > >> >> What does that entail other than an update to UPDATING in stable/11? > > I see some others have answered on this, so I'll just summarize. > > 1) Calls to gone_in should be added to the stable/11 drm modules >so that when they are loaded a message informs the user of >the deprecation. >Please be sure to tag this commit with Relnotes: Y > > 2) No note is needed in UPDATING, as there is not any action for >the user to take in stable/11, the UPDATING note was done in >head, which is correct. > > 3) If for some reason you make another DRM removal related >commit to head please add a tag for Relnotes: Y as this >needs to be in the 12.0 release notes too. > > Thats all I can think of right now, as a future request, > and IMHO, all deprecations should have a formal review > process, no mater who approved it. There are just so > many bits and pieces that need done to make sure these > work smoothly as possible. > > For example, the gone_in stuff was desinged so that > should of been the first commit, in ^head, and then > merged to stable/11. All commits adding gone_in should be > tagged with relnotes Y so good notification goes out. > > Desirably these gone-in's should be in existing > for a full point release, so that we do not abondon > uses that was not considered, this DRM one seems to > have rather serious impacts on a couple of users. > > I think this deprecation is a rather serious deviation > from the stated policy, in that 0 notification was > made, core IMHO, has overstepped some boundaries in > that respect. These policies are promises to the > downstream consumers, and violating them is very > poor planning. > > -- > Rod Grimes rgri...@freebsd.org > ___ > svn-src-head@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
