On Mon, Apr 30, 2007 at 06:18:56PM +0100, Antoine Martin wrote: > Full marks for number of lines of code changed! (1!)
Yeah, I thought that was a plus. > On the plus side, it only adds the parameter at the end, but it does > keep some code in there to deal with variable number/order for > [no]promisc and [no]optimized options, so I would prefer something like > this one - not just because I wrote it ;) > http://uml.nagafix.co.uk/pcap-macaddr.patch > Where the only required option is the pcap filter (which is harder to > move around since it doesn't have a fixed set of options - or does it?). On the negative side - I dislike assumptions like this: + //a mac address is always 17 characters long Suppose someone uses 2:1:2:3:4:5 (11 chars), which I did for testing? This is also conflating a MAC address with a pcap option, which it isn't. So what happens when someone adds more options to libpcap and UML users start wanting to use them? I would say that we add 'eth0=pcapv1,if,mac,filter,opt1,opt2,...' and futureproof this wrt pcap options. People will have to rearrange their command lines in order to use this, but they already are in order to use the new options. Everyone else will stick with the current 'eth0=pcap,...' format. So, unless you have strenuous objections, I think I will stick with my patch and wait for pcap to come up with more options. Jeff -- Work email - jdike at linux dot intel dot com ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ User-mode-linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
