[Bug 226289] [igb] [netmap] Kernel NIC Driver conflict

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226289

Rodney W. Grimes  changed:

   What|Removed |Added

 CC||vmaffi...@freebsd.org

--- Comment #4 from Rodney W. Grimes  ---
Adding vmaffi...@freebsd.org, to cc: list as the netmap expert.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 226289] [igb] [netmap] Kernel NIC Driver conflict

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226289

Rodney W. Grimes  changed:

   What|Removed |Added

Version|11.1-RELEASE|11.2-RELEASE
 CC||rgri...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

IP_BINDANY(SYN_SENT ): return packets not accepted by kernel

[star]

Hello all, 

I am testing IP_BINDANY functionality with a small C program. I can 
bind to a foreign (non existing) address, and syn packets are being 
sent with the bound source IP address and port. Return (ACK) packets 
are reaching the host (I can see the SYN-ACK packet in tcpdump), but 
the third packet in TCP handshake is not getting generated. It looks 
like the second SYN-ACK is not getting accepted by the kernel. 


 


My ipfw:
root@bsd:~ # ipfw list
00100 fwd 127.0.0.1,3128 tcp from any to any 80 in recv igb1
00300 fwd 127.0.0.1 ip from any  to any uid 0  in recv igb0
65534 allow ip from any to any
65535 deny ip from any to any


Refer to other pages: 
http://freebsd.1045724.x6.nabble.com/IP-BINDANY-return-packets-not-accepted-by-kernel-td4017905.html

but not work!

can anybody help me? Thanks





--
Sent from: http://freebsd.1045724.x6.nabble.com/freebsd-net-f4005075.html
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 226289] [igb] [netmap] Kernel NIC Driver conflict

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226289

--- Comment #3 from wings1...@gmail.com ---
(In reply to Eric Joyner from comment #2)
I'm not using jumbo frames at the moment.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: IP_BINDANY: return packets not accepted by kernel

[star]

Hello, I have the same problem with you, according to your method, I still
can not be accepted by the kernel.



--
Sent from: http://freebsd.1045724.x6.nabble.com/freebsd-net-f4005075.html
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 226289] [igb] [netmap] Kernel NIC Driver conflict

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226289

Eric Joyner  changed:

   What|Removed |Added

 CC||e...@freebsd.org

--- Comment #2 from Eric Joyner  ---
(In reply to wings1446 from comment #1)

Are you using jumbo frames?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 226289] [igb] [netmap] Kernel NIC Driver conflict

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226289

wings1...@gmail.com changed:

   What|Removed |Added

 CC||wings1...@gmail.com

--- Comment #1 from wings1...@gmail.com ---
This is still occurring in FreeBSD 11.2-RELEASE-p3.  Please see the following
URL on the FreeBSD support forum: 
https://forums.freebsd.org/threads/intel-ethernet-adapter-with-intel-82580-controller.67988/.
 Can someone please take a look.  Thank you.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

RFC 5549?

[Donald Sharp]

All -

The FRRouting project has some basic support for rfc 5549 and I've
been asked to see if it is possible to get this bit of code working
with the FRRouting freebsd kernel interface.  What is RFC 5549 you
ask?  The tl;dr of it is that you have v4 prefixes w/ a v6 gateway.
For some more background the linux implementation cheats ( and I would
like to emphatically point out that I'm not suggesting this solution,
I'm giving the linux solution to the problem as a data point to how it
was solved in one instance ) by installing a neighbor entry for
`169.254.0.1  ` and
when installing the v4 prefix we see the v6 nexthop and replace it
with `169.254.0.1 ` in the netlink message to the
kernel.  Is support of RFC 5549 possible in Freebsd?

thanks!

donald
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Rodney W. Grimes]

> Rodney W. Grimes wrote this message on Wed, Oct 24, 2018 at 05:19 -0700:
> > And I have read case law that boiled down to the presents vs absence
> > of a comma in an agreement that had results far beyond "minor".
> 
> For those currious about this case:
> https://www.bostonglobe.com/business/2017/03/16/lack-oxford-comma-costs-maine-company-millions-overtime-dispute/BIxK837fA2C06qavQMDs5J/story.html

For those more interested:
https://law.justia.com/cases/federal/appellate-courts/ca1/16-1901/16-1901-2017-03-13.html

And I was wrong, it is a US case, though I am sure there is other
similiar case law on other books.

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Brooks Davis]

On Wed, Oct 24, 2018 at 06:54:01AM -0700, Rodney W. Grimes wrote:
> > On Wed, Oct 24, 2018 at 05:19:33AM -0700, Rodney W. Grimes wrote:
> > > And I have read case law that boiled down to the presents vs absence
> > > of a comma
> > 
> > If we are now going to evaluate all proposed changes to FreeBSD on the
> > same rigid principles as the US legal system, I'm done.
> 
> I do not think "all" is in scope here,
> but I do feel should excercise care about procedure.
> And FYI, the case law above I am pretty sure was not US.
> 
> I also believe that what is at issue here can be fixed
> rather easily without ever going down the minor vs major
> slippery slope by some rather simple changes to order
> of events and careful steps.
> 
> Warner came very close, I think he just applied his correct
> "fix" to 1/2 of the problem.
> 
> There is the stage where the FCP is before core being voted
> on, and there is the stage that the FCP has been approved.
> He only addressed 1 of those, and he did so by allowing core
> to trivially modify the document during the voting process,
> and I am actually fine with that idea, its good, it is what
> should be allowed.  I trust core to know what is minor vs
> major.
> 
> BUTT it still does not cover the issue of the author/submitter
> modifying the document while it is in core being reviewed and
> possibly modified.  I have issue with that.  It is very hard
> to vote/formally review on something that is fluid.
> I have not been asked to trust these people with the trust I
> give core, so I would like to remove that.

There are technical measures in place that do much of this already.
Right now, authors can't directly change the documents (unless they are
repo admins which means core and former core members in practice).  We
require that pull requests be reviewed before they are merged and random
people don't have commit access.  We could make the restriction to core
members or core members and fcp-editors explicit if that was desirable.

> We could add that once the document is submitted to core
> any change to it between submitting and vote by core requires
> core to be involved, even if it is simply an ack of a change
> has been made to what was submitted.

I agree.  We'll need to think on how best to do this.

-- Brooks


signature.asc
Description: PGP signature

[Bug 227654] Reproducible crash with lagg+vlan+em

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227654

Kristof Provost  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|In Progress |Closed
  Flags|mfc-stable11?,  |mfc-stable11+,
   |mfc-stable12?   |mfc-stable12+

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 227654] Reproducible crash with lagg+vlan+em

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227654

--- Comment #12 from commit-h...@freebsd.org ---
A commit references this bug:

Author: kp
Date: Wed Oct 24 18:19:32 UTC 2018
New revision: 339691
URL: https://svnweb.freebsd.org/changeset/base/339691

Log:
  MFC r339547:

  vlan: Fix panic with lagg and vlan

  vlan_lladdr_fn() is called from taskqueue, which means there's no vnet
context
  set. We can end up trying to send ARP messages (through the iflladdr_event
  event), which requires a vnet context.

  PR:   227654

Changes:
_U  stable/11/
  stable/11/sys/net/if_vlan.c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[John-Mark Gurney]

Rodney W. Grimes wrote this message on Wed, Oct 24, 2018 at 05:19 -0700:
> And I have read case law that boiled down to the presents vs absence
> of a comma in an agreement that had results far beyond "minor".

For those currious about this case:
https://www.bostonglobe.com/business/2017/03/16/lack-oxford-comma-costs-maine-company-millions-overtime-dispute/BIxK837fA2C06qavQMDs5J/story.html

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Alexey Dokuchaev]

On Thu, Oct 04, 2018 at 11:38:46AM -0600, Warner Losh wrote:
> ...
> I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc,
> sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and
> which I doubt are in use in any FreeBSD system of any age today.

Warner, I had mentioned [*] that I'm using sf(4), would you please be more
careful when collecting "NICs still in use" data?  We really do need a wiki
page and carefully relect all the feedback we've received so far and also
upcoming one.

./danfe

[*] Message-ID: <20181004084411.ga50...@freebsd.org>
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 227654] Reproducible crash with lagg+vlan+em

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227654

--- Comment #11 from commit-h...@freebsd.org ---
A commit references this bug:

Author: kp
Date: Wed Oct 24 17:32:31 UTC 2018
New revision: 339690
URL: https://svnweb.freebsd.org/changeset/base/339690

Log:
  MFC r339547:

  vlan: Fix panic with lagg and vlan

  vlan_lladdr_fn() is called from taskqueue, which means there's no vnet
context
  set. We can end up trying to send ARP messages (through the iflladdr_event
  event), which requires a vnet context.

  PR:   227654
  Approved by:  re (kib)

Changes:
_U  stable/12/
  stable/12/sys/net/if_vlan.c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Very high lock contention in tcp_usr_send() which looks to limit if_gif performance with standard MTU

[Lev Serebryakov]

 I've benchmarked if_gre and if_gif encapsulation on not-so-powerful
hardware. Test is very simple: single as-fast-as-possible TCP stream via
tunnel to much-more performant server over 1G physical interface.

 I was surprised by very high price of encapsulation with standard MTU
of 1280 bytes. Performance in such configuration is about 45% of line
speed (440Mbit instead of 1Gbit). I can not believe, that adding one
header to each packet is SO expensive.

  Also, in such case userland thread of benchmark (nuttcp or iperf3)
consumes 100% of CPU (one core) and kernel thread (if_config_tqg_0 or
if_config_tqg_1) consumes 100% of CPY (second core).

 Physical interface with MTU of 1280 and switched off hardware "helpers"
shows 800Mbit/s and CPU is not-so-consumed, userland and kernel consume
about 50% + 50% of CPU, not 100% + 100%, which looks reasonable.

 I've traced down half of problem: userland CPU consumption to lock
contention at "sys/netinet/tcp_usrreq.c:923":

inp = sotoinpcb(so);
KASSERT(inp != NULL, ("tcp_usr_send: inp == NULL"));
INP_WLOCK(inp);
if (inp->inp_flags & (INP_TIMEWAIT | INP_DROPPED)) {

 This line consumes 75% of all time consumed by sosend(), and,
effectively, by userland, via this call chain:

  kernel`sosend+0x79
  kernel`soo_write+0x6b
  kernel`fo_write+0x4a
  kernel`dofilewrite+0xcd
  kernel`kern_writev+0x79
  kernel`sys_write+0x8f

 75% of one core is consumed by this line.

 Unfortunately, other party of this contention is not so obvious.

 Flame graph without TCO could be found here:

 
http://lev.serebryakov.spb.ru/_sklad/gif-stacks/no-tco/gif.1280.nuttcp.send.no-tco.svg

 It looks very suspicious to me.

 BTW, if_gre has exactly same problem.

-- 
// Lev Serebryakov



signature.asc
Description: OpenPGP digital signature

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[rb]

> On 24 Oct 2018, at 14:39, Warner Losh  wrote:
> 
> [stuff trimmed]
> 
>> >> The FCP process itself is unclear on this point,
>> >> I think this should be clarified.
>> >> 
>> >> It is much more clear on post approval:
>> >>Changes after acceptance
>> >> 
>> >>FCPs may need revision after they have been moved into the
>> >>accepted state. In such cases, the author SHOULD update the
>> >>FCP to reflect the final conclusions.
>> >>If the changes are major, the FCP SHOULD be withdrawn
>> >>and restarted.
>> >> 
>> > 
>> > Good point Rod. While common sense suggests that trivial changes during the
>> > voting should be allowed for editorial purposes (eg fix grammar mistakes,
>> > table rendering etc), it's better to spell that out so there's no 
>> > confusion.
>> > 
>> > diff --git a/fcp-.md b/fcp-.md
>> > index b4fe0f3..c8cc6f7 100644
>> > --- a/fcp-.md
>> > +++ b/fcp-.md
>> > @@ -144,7 +144,10 @@ When the discussion of a change has come to a suitable
>> > and acceptable close it
>> > SHOULD be updated to the `vote` state.
>> > 
>> > At this time the FreeBSD Core Team will vote on the subject of the FCP. The
>> > -result of vote moves the FCP into the `accepted` or `rejected` state.
>> > +result of vote moves the FCP into the `accepted` or `rejected` state. The
>> > +core team MAY make minor edits to the FCP to correct minor mistakes. Core
>> > +MAY return the proposal to the submitter if there are major problems that
>> > +need to be addressed.
>> 
>> This is a Bad Idea, because it relies on common understanding of what is 
>> minor. I was once involved with a standards body that had a procedure for 
>> so-called clerical errors intended to deal with typos, punctuation etc; this 
>> worked just fine until somebody claimed that the omission of the word “not” 
>> in a particular place was clearly a clerical error.
> 
> This documents procedure. It's not law. Trying to read it as law is a 
> mistake: it's written to be brief and descriptive, not through and 
> prescriptive. And that's on purpose. Axiom 1 of the bylaws is that you can 
> trust the core team, which is why the power grant is total and unequivocal: 
> Core is the governing body of the project. If you can't trust the core team 
> and need anything more, you've already list. And over the years core's 
> biggest failing isn't some fleet of black helicopters dispatched to take out 
> critics or other shenanigans. It's either been not doing enough for the 
> situation (due to too little time and/or a mistaken impression that they 
> couldn't do anything), or it's lack of clear communication either between the 
> different 'hats' and core or between core and the rest of the project.
> 
> Warner 

No problem with any of that. If the intent is that “core MAY make unrestricted 
changes to the FCP and/or MAY return the proposal to the submitter if there are 
problems that need to be addressed” then say so.

--
Bob Bishop   t: +44 (0)118 940 1243
r...@gid.co.uk m: +44 (0)783 626 4518





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

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Rodney W. Grimes]

> "Rodney W. Grimes" wrote:
> > We could add that once the document is submitted to core
> > any change to it between submitting and vote by core requires
> > core to be involved, even if it is simply an ack of a change
> > has been made to what was submitted.
> 
> Yes !

And to expand on that further since core is under a 2 week
timeline to complete this process any submitted change acceptable
to core resets the 2 week timer, if core rejects the change the
timer continues as original.


-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Mark Linimon]

On Wed, Oct 24, 2018 at 05:19:33AM -0700, Rodney W. Grimes wrote:
> And I have read case law that boiled down to the presents vs absence
> of a comma

If we are now going to evaluate all proposed changes to FreeBSD on the
same rigid principles as the US legal system, I'm done.

mcl
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Rodney W. Grimes]

> On Wed, Oct 24, 2018 at 05:19:33AM -0700, Rodney W. Grimes wrote:
> > And I have read case law that boiled down to the presents vs absence
> > of a comma
> 
> If we are now going to evaluate all proposed changes to FreeBSD on the
> same rigid principles as the US legal system, I'm done.

I do not think "all" is in scope here,
but I do feel should excercise care about procedure.
And FYI, the case law above I am pretty sure was not US.

I also believe that what is at issue here can be fixed
rather easily without ever going down the minor vs major
slippery slope by some rather simple changes to order
of events and careful steps.

Warner came very close, I think he just applied his correct
"fix" to 1/2 of the problem.

There is the stage where the FCP is before core being voted
on, and there is the stage that the FCP has been approved.
He only addressed 1 of those, and he did so by allowing core
to trivially modify the document during the voting process,
and I am actually fine with that idea, its good, it is what
should be allowed.  I trust core to know what is minor vs
major.

BUTT it still does not cover the issue of the author/submitter
modifying the document while it is in core being reviewed and
possibly modified.  I have issue with that.  It is very hard
to vote/formally review on something that is fluid.
I have not been asked to trust these people with the trust I
give core, so I would like to remove that.

We could add that once the document is submitted to core
any change to it between submitting and vote by core requires
core to be involved, even if it is simply an ack of a change
has been made to what was submitted.

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Warner Losh]

On Wed, Oct 24, 2018 at 5:02 AM Bob Bishop  wrote:

>
> > On 24 Oct 2018, at 01:23, Warner Losh  wrote:
> >
> > On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes <
> > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> >
> >> -- Start of PGP signed section.
> >>> On Tue, Oct 23, 2018 at 04:26:45PM -0700, Rodney W. Grimes wrote:
> > On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes <
> > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> >
> >>> On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote:
> > I'd also suggest that rl stands in stark contrast to the cs,
> >> wb, sn,
> >> smc,
> > sf, tl, tx and vr drivers, which nobody has mentioned in this
> >> thread, and
> > which I doubt are in use in any FreeBSD system of any age
> >> today.
> 
>  vr is used by my TV driver laptop:
>  http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/
>  vr0: flags=8843 metric
> >> 0 mtu
> >> 1500
> options=82808
> ether 00:40:d0:5e:26:38
> inet 192.168.91.65 netmask 0xff00 broadcast
> >> 192.168.91.255
> media: Ethernet autoselect (100baseTX
> >> )
> status: active
> 
>  Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade
> >> soon
>  when I also configure it to receive from a raspberry-pi TV VPN
> >> server.
> >>>
> >>> The above was a typo.  vr is on the the STAY list.
> >>>
> >>> -- Brooks
> >> Brooks,
> >>Is there a public revised version of FCP-0101 that
> >> reflects the
> >> feedback which is what core is voting on?
> >>
> >
> > Its on github, just like it's been the whole time for anybody to see,
> > submit pull requests against and track:
> 
>  I have no gh account, desires no gh account, so have no way to
>  submit a change request other than through direct email to
>  brooks or another gh user.  This is fundementally flawed.
> 
> > https://github.com/freebsd/fcp/blob/master/fcp-0101.md
> 
>  Thank you for the link, I had looked at it before MeetBSD,
>  which did not have most of the recent changes done "a day ago".
> 
>  Isnt this document now in a frozen state while core reviews/votes?
> >>>
> >>> I sent it to a vote at c224c67557297d7cba909ad008542cb60980cc6b only
> >>> to notice a bug in table rendering.  I submitted a pull request fix
> >>> that and a missing word which was merged since neither was material.  I
> >>> suppose they could have waited or been skipped, but there's no value in
> >>> the FCP process being bound by the sort of pointless rigidity that led
> >>> to -DPOSIX_MISTAKE in every libc compile line.
> >>
> >> The FCP process itself is unclear on this point,
> >> I think this should be clarified.
> >>
> >> It is much more clear on post approval:
> >>Changes after acceptance
> >>
> >>FCPs may need revision after they have been moved into the
> >>accepted state. In such cases, the author SHOULD update the
> >>FCP to reflect the final conclusions.
> >>If the changes are major, the FCP SHOULD be withdrawn
> >>and restarted.
> >>
> >
> > Good point Rod. While common sense suggests that trivial changes during
> the
> > voting should be allowed for editorial purposes (eg fix grammar mistakes,
> > table rendering etc), it's better to spell that out so there's no
> confusion.
> >
> > diff --git a/fcp-.md b/fcp-.md
> > index b4fe0f3..c8cc6f7 100644
> > --- a/fcp-.md
> > +++ b/fcp-.md
> > @@ -144,7 +144,10 @@ When the discussion of a change has come to a
> suitable
> > and acceptable close it
> > SHOULD be updated to the `vote` state.
> >
> > At this time the FreeBSD Core Team will vote on the subject of the FCP.
> The
> > -result of vote moves the FCP into the `accepted` or `rejected` state.
> > +result of vote moves the FCP into the `accepted` or `rejected` state.
> The
> > +core team MAY make minor edits to the FCP to correct minor mistakes.
> Core
> > +MAY return the proposal to the submitter if there are major problems
> that
> > +need to be addressed.
>
> This is a Bad Idea, because it relies on common understanding of what is
> minor. I was once involved with a standards body that had a procedure for
> so-called clerical errors intended to deal with typos, punctuation etc;
> this worked just fine until somebody claimed that the omission of the word
> “not” in a particular place was clearly a clerical error.
>

This documents procedure. It's not law. Trying to read it as law is a
mistake: it's written to be brief and descriptive, not through and
prescriptive. And that's on purpose. Axiom 1 of the bylaws is that you can
trust the core team, which is why the power grant is total and unequivocal:
Core is the governing body of the project. If you can't trust the core team
and need anything more, you've already list. And over the years cor

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Bob Bishop]

> On 24 Oct 2018, at 01:23, Warner Losh  wrote:
> 
> On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes <
> freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> 
>> -- Start of PGP signed section.
>>> On Tue, Oct 23, 2018 at 04:26:45PM -0700, Rodney W. Grimes wrote:
> On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes <
> freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> 
>>> On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote:
> I'd also suggest that rl stands in stark contrast to the cs,
>> wb, sn,
>> smc,
> sf, tl, tx and vr drivers, which nobody has mentioned in this
>> thread, and
> which I doubt are in use in any FreeBSD system of any age
>> today.
 
 vr is used by my TV driver laptop:
 http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/
 vr0: flags=8843 metric
>> 0 mtu
>> 1500
options=82808
ether 00:40:d0:5e:26:38
inet 192.168.91.65 netmask 0xff00 broadcast
>> 192.168.91.255
media: Ethernet autoselect (100baseTX
>> )
status: active
 
 Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade
>> soon
 when I also configure it to receive from a raspberry-pi TV VPN
>> server.
>>> 
>>> The above was a typo.  vr is on the the STAY list.
>>> 
>>> -- Brooks
>> Brooks,
>>Is there a public revised version of FCP-0101 that
>> reflects the
>> feedback which is what core is voting on?
>> 
> 
> Its on github, just like it's been the whole time for anybody to see,
> submit pull requests against and track:
 
 I have no gh account, desires no gh account, so have no way to
 submit a change request other than through direct email to
 brooks or another gh user.  This is fundementally flawed.
 
> https://github.com/freebsd/fcp/blob/master/fcp-0101.md
 
 Thank you for the link, I had looked at it before MeetBSD,
 which did not have most of the recent changes done "a day ago".
 
 Isnt this document now in a frozen state while core reviews/votes?
>>> 
>>> I sent it to a vote at c224c67557297d7cba909ad008542cb60980cc6b only
>>> to notice a bug in table rendering.  I submitted a pull request fix
>>> that and a missing word which was merged since neither was material.  I
>>> suppose they could have waited or been skipped, but there's no value in
>>> the FCP process being bound by the sort of pointless rigidity that led
>>> to -DPOSIX_MISTAKE in every libc compile line.
>> 
>> The FCP process itself is unclear on this point,
>> I think this should be clarified.
>> 
>> It is much more clear on post approval:
>>Changes after acceptance
>> 
>>FCPs may need revision after they have been moved into the
>>accepted state. In such cases, the author SHOULD update the
>>FCP to reflect the final conclusions.
>>If the changes are major, the FCP SHOULD be withdrawn
>>and restarted.
>> 
> 
> Good point Rod. While common sense suggests that trivial changes during the
> voting should be allowed for editorial purposes (eg fix grammar mistakes,
> table rendering etc), it's better to spell that out so there's no confusion.
> 
> diff --git a/fcp-.md b/fcp-.md
> index b4fe0f3..c8cc6f7 100644
> --- a/fcp-.md
> +++ b/fcp-.md
> @@ -144,7 +144,10 @@ When the discussion of a change has come to a suitable
> and acceptable close it
> SHOULD be updated to the `vote` state.
> 
> At this time the FreeBSD Core Team will vote on the subject of the FCP. The
> -result of vote moves the FCP into the `accepted` or `rejected` state.
> +result of vote moves the FCP into the `accepted` or `rejected` state. The
> +core team MAY make minor edits to the FCP to correct minor mistakes. Core
> +MAY return the proposal to the submitter if there are major problems that
> +need to be addressed.

This is a Bad Idea, because it relies on common understanding of what is minor. 
I was once involved with a standards body that had a procedure for so-called 
clerical errors intended to deal with typos, punctuation etc; this worked just 
fine until somebody claimed that the omission of the word “not” in a particular 
place was clearly a clerical error.

> FCPs in the `accepted` state can be updated and corrected.
> See the "Changes after acceptance" section for more information.
> 
> Normally I'd submit that as a pull request, but since I know you don't use
> github, I thought I'd present it here to see if this answers your concerns
> before doing so.
> 
> Warner
> ___
> freebsd-sta...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> 

--
Bob Bishop
r...@gid.co.uk




___
freebsd-net@freebsd.org mailing list
https://lists.fr

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Warner Losh]

On Wed, Oct 24, 2018 at 6:19 AM Rodney W. Grimes <
freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:

> > > On 24 Oct 2018, at 01:23, Warner Losh  wrote:
> > >
> > > On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes <
> > > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> > >
> > >> -- Start of PGP signed section.
> > >>> On Tue, Oct 23, 2018 at 04:26:45PM -0700, Rodney W. Grimes wrote:
> > > On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes <
> > > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> > >
> > >>> On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote:
> > > I'd also suggest that rl stands in stark contrast to the cs,
> > >> wb, sn,
> > >> smc,
> > > sf, tl, tx and vr drivers, which nobody has mentioned in this
> > >> thread, and
> > > which I doubt are in use in any FreeBSD system of any age
> > >> today.
> > 
> >  vr is used by my TV driver laptop:
> >  http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/
> >  vr0: flags=8843 metric
> > >> 0 mtu
> > >> 1500
> > options=82808
> > ether 00:40:d0:5e:26:38
> > inet 192.168.91.65 netmask 0xff00 broadcast
> > >> 192.168.91.255
> > media: Ethernet autoselect (100baseTX
> > >> )
> > status: active
> > 
> >  Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade
> > >> soon
> >  when I also configure it to receive from a raspberry-pi TV VPN
> > >> server.
> > >>>
> > >>> The above was a typo.  vr is on the the STAY list.
> > >>>
> > >>> -- Brooks
> > >> Brooks,
> > >>Is there a public revised version of FCP-0101 that
> > >> reflects the
> > >> feedback which is what core is voting on?
> > >>
> > >
> > > Its on github, just like it's been the whole time for anybody to
> see,
> > > submit pull requests against and track:
> > 
> >  I have no gh account, desires no gh account, so have no way to
> >  submit a change request other than through direct email to
> >  brooks or another gh user.  This is fundementally flawed.
> > 
> > > https://github.com/freebsd/fcp/blob/master/fcp-0101.md
> > 
> >  Thank you for the link, I had looked at it before MeetBSD,
> >  which did not have most of the recent changes done "a day ago".
> > 
> >  Isnt this document now in a frozen state while core reviews/votes?
> > >>>
> > >>> I sent it to a vote at c224c67557297d7cba909ad008542cb60980cc6b only
> > >>> to notice a bug in table rendering.  I submitted a pull request fix
> > >>> that and a missing word which was merged since neither was
> material.  I
> > >>> suppose they could have waited or been skipped, but there's no value
> in
> > >>> the FCP process being bound by the sort of pointless rigidity that
> led
> > >>> to -DPOSIX_MISTAKE in every libc compile line.
> > >>
> > >> The FCP process itself is unclear on this point,
> > >> I think this should be clarified.
> > >>
> > >> It is much more clear on post approval:
> > >>Changes after acceptance
> > >>
> > >>FCPs may need revision after they have been moved into the
> > >>accepted state. In such cases, the author SHOULD update the
> > >>FCP to reflect the final conclusions.
> > >>If the changes are major, the FCP SHOULD be withdrawn
> > >>and restarted.
> > >>
> > >
> > > Good point Rod. While common sense suggests that trivial changes
> during the
> > > voting should be allowed for editorial purposes (eg fix grammar
> mistakes,
> > > table rendering etc), it's better to spell that out so there's no
> confusion.
> > >
> > > diff --git a/fcp-.md b/fcp-.md
> > > index b4fe0f3..c8cc6f7 100644
> > > --- a/fcp-.md
> > > +++ b/fcp-.md
> > > @@ -144,7 +144,10 @@ When the discussion of a change has come to a
> suitable
> > > and acceptable close it
> > > SHOULD be updated to the `vote` state.
> > >
> > > At this time the FreeBSD Core Team will vote on the subject of the
> FCP. The
> > > -result of vote moves the FCP into the `accepted` or `rejected` state.
> > > +result of vote moves the FCP into the `accepted` or `rejected` state.
> The
> > > +core team MAY make minor edits to the FCP to correct minor mistakes.
> Core
> > > +MAY return the proposal to the submitter if there are major problems
> that
> > > +need to be addressed.
> >
> > This is a Bad Idea, because it relies on common understanding of what is
> minor. I was once involved with a standards body that had a procedure for
> so-called clerical errors intended to deal with typos, punctuation etc;
> this worked just fine until somebody claimed that the omission of the word
> ?not? in a particular place was clearly a clerical error.
>
> And I have read case law that boiled down to the presents vs absence
> of a comma in an agreement that had results far beyond "minor".
>
> Use of words minor and major should be r

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Julian H. Stacey]

"Rodney W. Grimes" wrote:
> We could add that once the document is submitted to core
> any change to it between submitting and vote by core requires
> core to be involved, even if it is simply an ack of a change
> has been made to what was submitted.

Yes !

Cheers,
Julian
-- 
Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich.
 Brexit referendum stole 3,700,000 Brits votes abroad, inc. 700,000 in EU.
 Campaign lies, criminal funding, economy & pound down. Time for an honest ref.
http://exitbrexit.ukhttps://www.peoples-vote.uk/petition
https://eci.ec.europa.eu/002/public/#/initiative
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Julian H. Stacey]

I suggest posters to this lively thread could strip inherited personal
CC addresses .  Then ~/.procmailrc that sorts list mail away from
real personal ~/mail/Inbox will protect xbiff from beeping so much :-)

Cheers,
Julian
-- 
Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich.
 Brexit referendum stole 3,700,000 Brits votes abroad, inc. 700,000 in EU.
 Campaign lies, criminal funding, economy & pound down. Time for an honest ref.
http://exitbrexit.ukhttps://www.peoples-vote.uk/petition
https://eci.ec.europa.eu/002/public/#/initiative
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Rodney W. Grimes]

... deleted ...
... cc list trimmed, getting too many recepient gripes from mailman ...

> > > > diff --git a/fcp-.md b/fcp-.md
> > > > index b4fe0f3..c8cc6f7 100644
> > > > --- a/fcp-.md
> > > > +++ b/fcp-.md
> > > > @@ -144,7 +144,10 @@ When the discussion of a change has come to a
> > suitable
> > > > and acceptable close it
> > > > SHOULD be updated to the `vote` state.
> > > >
> > > > At this time the FreeBSD Core Team will vote on the subject of the
> > FCP. The
> > > > -result of vote moves the FCP into the `accepted` or `rejected` state.
> > > > +result of vote moves the FCP into the `accepted` or `rejected` state.
> > The
> > > > +core team MAY make minor edits to the FCP to correct minor mistakes.
> > Core
> > > > +MAY return the proposal to the submitter if there are major problems
> > that
> > > > +need to be addressed.
> > >
> > > This is a Bad Idea, because it relies on common understanding of what is
> > minor. I was once involved with a standards body that had a procedure for
> > so-called clerical errors intended to deal with typos, punctuation etc;
> > this worked just fine until somebody claimed that the omission of the word
> > ?not? in a particular place was clearly a clerical error.
> >
> > And I have read case law that boiled down to the presents vs absence
> > of a comma in an agreement that had results far beyond "minor".
> >
> > Use of words minor and major should be red flags unless both
> > or explicitly defined, and even then those definitions often
> > have issues themselves.
> >
> 
> I'm not going to define every single word. FCP documents describe process.
> They are not legal documents, nor should they be. Major and minor have
> common enough meanings, and the basis of bylaws is that we trust core@.

The trust isssue is not core (though in this specific case it is
a core member submitting the FCP, that is not going to be the
case always).  The trust issue is do we allow the Author to make
this minor/major change decission and how does core get informed
that it has happened?

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Rodney W. Grimes]

> > On 24 Oct 2018, at 01:23, Warner Losh  wrote:
> > 
> > On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes <
> > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> > 
> >> -- Start of PGP signed section.
> >>> On Tue, Oct 23, 2018 at 04:26:45PM -0700, Rodney W. Grimes wrote:
> > On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes <
> > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> > 
> >>> On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote:
> > I'd also suggest that rl stands in stark contrast to the cs,
> >> wb, sn,
> >> smc,
> > sf, tl, tx and vr drivers, which nobody has mentioned in this
> >> thread, and
> > which I doubt are in use in any FreeBSD system of any age
> >> today.
>  
>  vr is used by my TV driver laptop:
>  http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/
>  vr0: flags=8843 metric
> >> 0 mtu
> >> 1500
> options=82808
> ether 00:40:d0:5e:26:38
> inet 192.168.91.65 netmask 0xff00 broadcast
> >> 192.168.91.255
> media: Ethernet autoselect (100baseTX
> >> )
> status: active
>  
>  Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade
> >> soon
>  when I also configure it to receive from a raspberry-pi TV VPN
> >> server.
> >>> 
> >>> The above was a typo.  vr is on the the STAY list.
> >>> 
> >>> -- Brooks
> >> Brooks,
> >>Is there a public revised version of FCP-0101 that
> >> reflects the
> >> feedback which is what core is voting on?
> >> 
> > 
> > Its on github, just like it's been the whole time for anybody to see,
> > submit pull requests against and track:
>  
>  I have no gh account, desires no gh account, so have no way to
>  submit a change request other than through direct email to
>  brooks or another gh user.  This is fundementally flawed.
>  
> > https://github.com/freebsd/fcp/blob/master/fcp-0101.md
>  
>  Thank you for the link, I had looked at it before MeetBSD,
>  which did not have most of the recent changes done "a day ago".
>  
>  Isnt this document now in a frozen state while core reviews/votes?
> >>> 
> >>> I sent it to a vote at c224c67557297d7cba909ad008542cb60980cc6b only
> >>> to notice a bug in table rendering.  I submitted a pull request fix
> >>> that and a missing word which was merged since neither was material.  I
> >>> suppose they could have waited or been skipped, but there's no value in
> >>> the FCP process being bound by the sort of pointless rigidity that led
> >>> to -DPOSIX_MISTAKE in every libc compile line.
> >> 
> >> The FCP process itself is unclear on this point,
> >> I think this should be clarified.
> >> 
> >> It is much more clear on post approval:
> >>Changes after acceptance
> >> 
> >>FCPs may need revision after they have been moved into the
> >>accepted state. In such cases, the author SHOULD update the
> >>FCP to reflect the final conclusions.
> >>If the changes are major, the FCP SHOULD be withdrawn
> >>and restarted.
> >> 
> > 
> > Good point Rod. While common sense suggests that trivial changes during the
> > voting should be allowed for editorial purposes (eg fix grammar mistakes,
> > table rendering etc), it's better to spell that out so there's no confusion.
> > 
> > diff --git a/fcp-.md b/fcp-.md
> > index b4fe0f3..c8cc6f7 100644
> > --- a/fcp-.md
> > +++ b/fcp-.md
> > @@ -144,7 +144,10 @@ When the discussion of a change has come to a suitable
> > and acceptable close it
> > SHOULD be updated to the `vote` state.
> > 
> > At this time the FreeBSD Core Team will vote on the subject of the FCP. The
> > -result of vote moves the FCP into the `accepted` or `rejected` state.
> > +result of vote moves the FCP into the `accepted` or `rejected` state. The
> > +core team MAY make minor edits to the FCP to correct minor mistakes. Core
> > +MAY return the proposal to the submitter if there are major problems that
> > +need to be addressed.
> 
> This is a Bad Idea, because it relies on common understanding of what is 
> minor. I was once involved with a standards body that had a procedure for 
> so-called clerical errors intended to deal with typos, punctuation etc; this 
> worked just fine until somebody claimed that the omission of the word ?not? 
> in a particular place was clearly a clerical error.

And I have read case law that boiled down to the presents vs absence
of a comma in an agreement that had results far beyond "minor".

Use of words minor and major should be red flags unless both
or explicitly defined, and even then those definitions often
have issues themselves.

> > FCPs in the `accepted` state can be updated and corrected.
> > See the "Changes after acceptance" section for more information.
> > 
> > Normally I'd submit that as a pull request, but since

RE: Satellite Broadband Internet Modem IP freebsd-net@freebsd.org

[Mark Chen]

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