On 2015-05-18 14:57, Bjørn Mork wrote: > Stefan Agner <stefan@xxxxxxxx> writes: > >> I agree that using a common implementation makes sense, however that >> implementation does not support the central idea of that patch: >> supporting the standard format which is created by libc's >> ether_ntoa_r... > > "standard" format, at best. I cannot think of a single commonly used > Linux tool actually using that format. Most people just use the proper > format string... Do you have an example of source code using > ether_ntoa_r() (or ether_ntoa)? Beside libusbg there are others, e.g. ebtables. It's a libc function I guess there are application using it... However, probably most people prefer the fixed width format anyway. > > In any case, adding parser complexity in the kernel just to accommodate > some rarely used userspace library function, which is easily and usually > replaced by a printf anyway, seems utterly pointless. > > If you are still going to do this, then please justify the change for > the mac_pton() function. There are zilch reasons why mac parsing in the > usb subsystem should be different from the rest of the kernel. Since we anyway changed the behavior of libusbg, I'm also fine by only supporting the two digit format, as it was before. IMHO, the main problem of the function is the parsing beyond the end of the string anyway. We could still add the single digit/libc compatible format to mac_pton as a second change... Krzysztof, beside the two digit format, I don't see a really problematic constraint which would be added by switching to mac_pton. A MAC address with the newline character would still be valid (echo case). -- Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
