On 05/18/2015 02:57 PM, 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)?
libusbg had used ether_ntoa*() since its very beginning. I don't say
that it was good or wrong, I only gave you the example;). Recently this
has been replaced by Stefan with more suitable function which doesn't
have those problems.
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.
MAC parsing for ethernet usb functions is different for many years.
Moreover, current version with all its features (for example with
accepting dots instead of semicolons) has been exposed to userspace when
porting ethernet functions to configfs. Using mac_pton() will not fix
ether_ntoa issue but only add additional constrains to MAC formating.
Best regards,
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
--
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
