On Fri, 2021-08-27 at 11:49 +0300, Andy Shevchenko wrote: > On Fri, Aug 27, 2021 at 01:08:10AM -0700, Joe Perches wrote: > > On Fri, 2021-08-27 at 10:48 +0300, Andy Shevchenko wrote: > > > On Thu, Aug 26, 2021 at 11:43:01AM -0700, Joe Perches wrote: > > > > A few sysfs output uses of hex arrays are uppercase and are nominally ABI. > > > > > > > > Add a mechanism to the existing vsprintf %*ph hex output extension to > > > > support upper case hex output. > > > > > > ... > > > > > > > + The preferred output is lowercase > > > > %*ph 00 01 02 ... 3f > > > > %*phC 00:01:02: ... :3f > > > > %*phD 00-01-02- ... -3f > > > > %*phN 000102 ... 3f > > > > + Formats with X are uppercase, used for backwards compatibility > > > > + %*phX 00 01 02 ... 3F > > > > + %*phCX 00:01:02: ... :3F > > > > + %*phDX 00-01-02- ... -3F > > > > + %*phNX 000102 ... 3F > > > > > > Why not using %*pH...? > > > > I find X more intelligible. > > > > > > + char locase = 0x20; /* ASCII OR'd for lower case see: number() */ > > > > > > If you use h vs H, you may derive this from (fmt[...] & SMALL). > > > > It's not necessary to use any more of the rather limited vsprintf > > extension namespace. > > I understand your concern, but %*ph is quite widely used (I guess top 1 or 2 > among all %p extensions), Cumulatively 3rd after %pM and %pOF > its performance degradation with your code may affect > a lot of other users and hence a kernel as a whole. > > So, that's why my proposal stays. Knock yourself out. > Of course you may provide a benchmark (btw, where are the test cases for this?) You are welcome to provide both test cases and benchmarks. I find the whole thing rather dull. > for yours and mine variant and we will see if it makes sense to optimize. It doesn't. Anyone thinking there is a required printf/vsprintf optimization in the kernel is decidedly barking up the wrong tree.
