| TODO (98530) | TODO (172677) |
|---|---|
| 1 TODO list for libpcap 2======================= 3 4Important stuff (to be done before the next release) 5--------------- 6 7General 8 9- configure should not be in the CVS. Most open source projects have an 10 autogen.sh script to run autoconf etc. after checkout. I think we 11 should stick to the standard. 12 13- The source files should be better documented. There is no official 14 design guideline for what is done where. There should be a common coding 15 style (okay, you can guess that by looking at the code) and a guide for 16 what needs to be documented. 17 | 1 TODO list for libpcap 2======================= 3 4Important stuff (to be done before the next release) 5--------------- 6 7General 8 9- configure should not be in the CVS. Most open source projects have an 10 autogen.sh script to run autoconf etc. after checkout. I think we 11 should stick to the standard. 12 13- The source files should be better documented. There is no official 14 design guideline for what is done where. There should be a common coding 15 style (okay, you can guess that by looking at the code) and a guide for 16 what needs to be documented. 17 |
| 18Linux kernel interface 19 20- Currently there is a race condition in that a socket is activated at the 21 same time it is opened - before applying a filter. This has to 22 be corrected so that capture starts when pcap_read is called for the 23 first time. 24 | |
| 25Less urgent items 26----------------- 27 28- Better documentation and cleanup of the interface. I am seeing a few 29 problems at the first glance which needs fixing: 30 + pcap_lookupnet makes little to no sense with protocols != IPv4 31 + not very well suited for interactive programs (think ethereal). There 32 should be a way for the application to get a file descriptor which it 33 has to monitor and a callback in pcap which has to be called on 34 activity (XXX - "pcap_fileno()" handles the first part, although 35 "select()" and "poll()" don't work on BPF devices on most BSDs, and 36 you can call "pcap_dispatch()" as the dispatch routine after putting 37 the descriptor into non-blocking mode) 38 + too many functions. There are a lot of functions for everything which 39 violates the KISS principle. Why do we need pcap_strerror, pcap_perror 40 and pcap_geterr? 41 + the manpage has a brief description of each function but where is the 42 big picture? Seems like you need to buy UNP for that... | 18Less urgent items 19----------------- 20 21- Better documentation and cleanup of the interface. I am seeing a few 22 problems at the first glance which needs fixing: 23 + pcap_lookupnet makes little to no sense with protocols != IPv4 24 + not very well suited for interactive programs (think ethereal). There 25 should be a way for the application to get a file descriptor which it 26 has to monitor and a callback in pcap which has to be called on 27 activity (XXX - "pcap_fileno()" handles the first part, although 28 "select()" and "poll()" don't work on BPF devices on most BSDs, and 29 you can call "pcap_dispatch()" as the dispatch routine after putting 30 the descriptor into non-blocking mode) 31 + too many functions. There are a lot of functions for everything which 32 violates the KISS principle. Why do we need pcap_strerror, pcap_perror 33 and pcap_geterr? 34 + the manpage has a brief description of each function but where is the 35 big picture? Seems like you need to buy UNP for that... |