Re: [patch] packet.7: PACKET_LOSS has inverse meaning

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/24/2014 11:39 AM, Carsten Andrich wrote:
> "Michael Kerrisk (man-pages)" schrieb:
>> On 04/23/2014 09:10 PM, Carsten Andrich wrote:
>>> [...]
>>> Unfortunately my experience with Linux packet sockets is very limited. I
>>> messed with them a few times, but only really started using SOCK_RAW
>>> packet sockets (including PACKET_MMAP) a few weeks ago (as a part of my
>>> Bachelor's thesis). I haven't looked at the linux (networking) code
>>> before Monday, when I tried to figure out if either packet.7 or I was
>>> wrong regarding PACKET_LOSS. And I've never even touched SOCK_DGRAM.
>>>
>>> All this doesn't exactly qualify me for the job :)
>>
>> Maybe, maybe not. On the other hand, I have the idea (may be wrong) 
>> that Vince Weaver was a beginner with perf_event_open() when he
>> started sending me patches. He's continued doing so with a vengeance
>> (thanks again Vince!). That has been a great help, since 
>> perf_event_open() is a complex, constantly evolving API surface, and
>> I just don't have the time to track the details. The API described in 
>> packet.7 has not changed much over time, but the man page has seen
>> little love over the years. An inquiring mind, willing to test things
>> and read code are the main prerequisites. ANd it sounds like some 
>> others might chip with help and Acks.
> 
> We could give it a shot. It may be of an advantage to not have a deep
> understanding of the code driving the interface one is trying to
> document, as to not leave out aspects which appear to be self-evident.

(Nod.)

> It would make sense to limit our efforts to getting the PACKET_MMAP
> documentation in good shape, at least for now.
> I'd definitely require a reviewer (who's willing to answer some
> questions in advance) with a good understanding of at_packet.c and since
> I've already mentioned the need for synchronizing packet.7 and
> packet_mmap.txt we'd also need a decent plan how to distribute/share
> information among both.

I'd leave that plan largely to you. It sounds like Willem and
Daniel are willing to help out. 

> I'll try to come up with some ideas once I've handed in my Bachelor's
> thesis (deadline ends 3 weeks from now).
> Is there anyone else from the kernel-side we'd need to involve besides
> Willem and Daniel?

Maybe even Neil and Andi (CCed) might chip in from time to time.

>>> Maybe we should continue this discussion in private, so we don't bore
>>> everyone to death.
>>
>> Drop me a private mail if you want, but there are also benefits 
>> to public conversations ;-).
> I just don't want to annoy anyone, since we kinda force Willem, Daniel
> and now Vince to read this :)

So it goes...

Thanks, Carsten.

Cheers,

Michael



-- 
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux