Message ID | 20220719214449.2520-1-w@1wt.eu |
---|---|
Headers | show |
Series | nolibc: add preliminary self tests | expand |
On Tue, Jul 19, 2022 at 03:49:47PM -0700, Paul E. McKenney wrote: > But I do get "71 test(s) passed." when running on x86. I will let you > decide whether that constitutes all being well or indicates a bug in > the tests. ;-) Technically speaking both are possible, but one is more likely :-) > > The program can automatically modulate QEMU's return value on x86 when > > QEMU is run with the appropriate options, but for now I'm not using it > > as I felt like it didn't bring much value, and the output is more useful. > > That's debatable, and maybe some might want to use it in bisect scripts > > for example. It's too early to say IMHO. > > For the moment, grepping the output works. And perhaps indefinitely. That's my intuition as well, given that there will always be a bit of scripting around that anyway. > This series is now on the -rcu tree's "dev" branch. Thank you! > I got two almost > identical copies of patch 7, so I took the later of the two. Please let > me know if I guessed wrong. Oh you're right, I'm sorry about that. I adjusted one commit message late and failed to erase the previous one from the directory. In either case we really don't care but I thought that the one mentioning "stdlib" which is the term used in the test was better. Thanks again for your time, Willy
On 7/20/22 4:44 AM, Willy Tarreau wrote: > I'm obviously interested in comments, but really, I don't want to > overdesign something for a first step, it remains a very modest test > program and I'd like that it remains easy to hack on it and to contribute > new tests that are deemed useful. I personally hate how the test framework mandates: "There must be exactly one test per line." which makes the test case, for example, one long liner like this: if ((p1 = p2 = sbrk(4096)) != (void *)-1) p2 = sbrk(-4096); EXPECT_SYSZR(1, (p2 == (void *)-1) || p2 == p1); break; that's ugly and hard to read. Can we get rid of this "one test per line" rule? It would be great if we followed the documented coding style that says: "Statements longer than 80 columns should be broken into sensible chunks, unless exceeding 80 columns significantly increases readability and does not hide information." [1] What we have here doesn't really increase the readability at all. Maybe it's too late for 5.20, just for next in case we want to fix it. Willy? [1]: https://www.kernel.org/doc/html/v5.15/process/coding-style.html#breaking-long-lines-and-strings
On 7/20/22 11:20 PM, Willy Tarreau wrote: > What I certainly don't want to do is to have to cross-reference IDs > with arrays, nor start to stack endless if/else that are even more > painful to deal with, or have to renumber everything by hand once in > a while. Noted. > But again, I'm open to better proposals. I reached the limits of my > imagination there, but I do value the ability to "yyp" one line, change > two arguments and gain one extra test for a different combination, and > I really do not want to lose that simplicity. Note that for more complex > tests, it's trivial to add a dedicated function and that's what was done > for getdents64() which also serves as an example. OK, I understand the reason behind this now. I and Fernanda will try to visit this again at around 5.20-rc. *If* we can find a better design that matches your requirements, we will send you an RFC to improve it too. Thank you!