On 05/18/2015 04:18 PM, Stefan Agner wrote:
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).
Nope, mac_pton() accepts only strlen(s) < 3 * ETH_ALEN - 1 strings what
means that we need to have \0 right after last character of MAC address.
Before calling this function we have to replace \n with \0
what requires to strdup() the buffer as it is const.
The only constraint which I see is . instead of :. Currently it is
possible to use . in MAC address but mac_pton() accepts only :. I'm not
sure if it is necessary to support it or if anyone is using this format.
I just say that it is currently possible to use it.
I think that I'm not a good person to decide if we should still support
MAC address format with . as a separator or we can drop this and allow
to use only : as mac_pton() does. Philipe, what do you think?
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
