From: "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Carsten Andrich
<carsten.andrich-hs6bpBdVsEZfm0AUMx9V0g@public.gmane.org>,
Willem de Bruijn
<willemb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
Daniel Borkmann
<dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [patch] packet.7: PACKET_LOSS has inverse meaning
Date: Wed, 23 Apr 2014 08:06:42 +0200 [thread overview]
Message-ID: <53575872.6080403@gmail.com> (raw)
In-Reply-To: <1398200019.5031.24.camel-FQO4gtnRtnzkVFMGpb/cPg@public.gmane.org>
On 04/22/2014 10:53 PM, Carsten Andrich wrote:
> @Willem: Sorry for being a smart ass ;)
>> I interpreted this as the tp_status field of the malformed packets. To
>> make clear that it does not refer to the "following packets", it could
>> be revised to
>>
>> "is set, transmission continues, skipping over any malformed packets. The
>> status of the malformed packets is reset to TP_STATUS_AVAILABLE."
> There's no need to emphasize that "only" malformed packets have their
> tp_status set to TP_STATUS_AVAILABLE, since the following packets will
> share that fate (by being either skipped or actually sent).
> If this were not the case the ring would be broken, due to multiple
> non-consecutive occurrences of the same TP_STATUS_xyz. This is why the
> transmission must be immediately aborted on encountering a malformed
> packet if PACKET_LOSS is not set.
>
> Aside from this purely academical know-it-all remark (sorry, again),
> your suggested change is fine, of course. As an alternative, I simply
> stripped the "theirs" from my initial suggestion:
> ---
> However if
> .BR PACKET_LOSS
> is set, any malformed packet will be skipped, its status reset to
> .BR TP_STATUS_AVAILABLE
> and the transmission process continued.
> ---
How would adding just a little more precision be:
[[
However, if
.BR PACKET_LOSS
is set, any malformed packet will be skipped, its status
.RI ( tp_status
in the
.I tpacket_hdr
structure) reset to
.BR TP_STATUS_AVAILABLE ,
and the transmission process continued.
]]
?
Cheers,
Michael
> -------- Weitergeleitete Nachricht --------
> Von: Willem de Bruijn <willemb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> An: Michael Kerrisk (man-pages) <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Kopie: Carsten Andrich <carsten.andrich-hs6bpBdVsEZfm0AUMx9V0g@public.gmane.org>, Daniel Borkmann
> <dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Betreff: Re: [patch] packet.7: PACKET_LOSS has inverse meaning
> Datum: Tue, 22 Apr 2014 15:14:53 -0400
>
> On Tue, Apr 22, 2014 at 2:55 PM, Michael Kerrisk (man-pages)
> <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> [...]
>> @Carsten: I've applied your patch, but I have a question. You wrote:
>>
>> [[
>> However if
>> .BR PACKET_LOSS
>> is set, malformed packets will be skipped, their status reset to
>> .BR TP_STATUS_AVAILABLE
>> ]]
>>
>> What does "their" in "their status" refer to?
>
> I interpreted this as the tp_status field of the malformed packets. To
> make clear that it does not refer to the "following packets", it could
> be revised to
>
> "is set, transmission continues, skipping over any malformed packets. The
> status of the malformed packets is reset to TP_STATUS_AVAILABLE."
>
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-04-23 6:06 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-22 16:01 [patch] packet.7: PACKET_LOSS has inverse meaning Carsten Andrich
2014-04-22 18:23 ` Michael Kerrisk (man-pages)
[not found] ` <5356B3BA.7050401-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-04-22 18:36 ` Willem de Bruijn
[not found] ` <CA+FuTSc=4fwH=+jX58teeQHrRse718qLBOLzAcrZJSYug2TfSw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-04-22 18:55 ` Michael Kerrisk (man-pages)
[not found] ` <5356BB3F.4030502-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-04-22 19:06 ` Carsten Andrich
2014-04-22 19:14 ` Willem de Bruijn
[not found] ` <CA+FuTScUexjc6bETYMVgPUgmN5CSR40=UrELT9N363Tvk1+waA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-04-22 20:53 ` Carsten Andrich
[not found] ` <1398200019.5031.24.camel-FQO4gtnRtnzkVFMGpb/cPg@public.gmane.org>
2014-04-23 6:06 ` Michael Kerrisk (man-pages) [this message]
[not found] ` <53575872.6080403-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-04-23 8:51 ` Carsten Andrich
2014-04-23 10:12 ` Michael Kerrisk (man-pages)
[not found] ` <53579224.3060006-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-04-23 19:10 ` Carsten Andrich
[not found] ` <1398280218.2416.18.camel-FQO4gtnRtnzkVFMGpb/cPg@public.gmane.org>
2014-04-24 8:20 ` Michael Kerrisk (man-pages)
[not found] ` <5358C957.8080402-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-04-24 9:39 ` Carsten Andrich
2014-04-24 10:21 ` Michael Kerrisk (man-pages)
[not found] ` <5358E59E.2000207-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-04-24 10:45 ` Daniel Borkmann
[not found] ` <CA+FuTSf6_Lvs_Nht7TXPUT973rePz9hKEqv+YvPwXSq+kOoiyQ@mail.gmail.com>
[not found] ` <CA+FuTSf6_Lvs_Nht7TXPUT973rePz9hKEqv+YvPwXSq+kOoiyQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-04-24 19:07 ` Carsten Andrich
[not found] ` <1398366446.2647.4.camel-FQO4gtnRtnzkVFMGpb/cPg@public.gmane.org>
2014-04-25 11:20 ` Neil Horman
2014-04-24 10:59 ` Neil Horman
2014-04-23 20:53 ` Stefan Puiu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53575872.6080403@gmail.com \
--to=mtk.manpages-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=carsten.andrich-hs6bpBdVsEZfm0AUMx9V0g@public.gmane.org \
--cc=dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=willemb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.