On Thu, Apr 24, 2014 at 12:21:18PM +0200, Michael Kerrisk (man-pages) wrote: > 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. > of course, I'll be happy to review/consult on documentation changes. I'm happy to contribute for that matter, as time allows, but my plate is unfortunately a bit full at the moment, so I might be limited to answering questions for a bit. > >>> 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
