Date: Tue, 14 Jan 2014 12:22:49 -0700 From: Alan Somers <asomers@freebsd.org> To: Julio Merino <julio@meroh.net> Cc: "freebsd-testing@freebsd.org" <freebsd-testing@freebsd.org> Subject: Re: Correct src location for kernel ATF tests Message-ID: <CAOtMX2iuUacekAj1JKtnk=-L6Q5-Q-Y_HvbeStmTTm-axnvviw@mail.gmail.com> In-Reply-To: <7D8E1A11-A946-499A-B568-D77D91B49FA6@meroh.net> References: <CAOtMX2hM=GKzsC-eGz8qSzH4OHKuNmHk=mNvJ_S8bj6=AfmkCg@mail.gmail.com> <7D8E1A11-A946-499A-B568-D77D91B49FA6@meroh.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 14, 2014 at 12:12 PM, Julio Merino <julio@meroh.net> wrote: > On Jan 13, 2014, at 22:25, Alan Somers <asomers@freebsd.org> wrote: > >> Where is the correct location within the source tree for ATF tests >> that exercise kernel features? For example, I'm currently trying to >> ATFify tools/regression/sockets/unix_seqpacket_exercise, > > I think it's good practice to _not_ ATFify an existing test at the same t= ime as it's moved. > > I feel it's better to first move the test program "as is" into its new lo= cation, ensure it works, and only then change it to use the ATF libraries. = If done properly (e.g. by maintaining the same binary name pre/post conver= sion), this should cause minimum churn and will allow for easier tracking o= f code changes in the VCS history. In this case, the test doesn't work to begin with. I'm rewriting almost from scratch. But I'll follow your suggestion when I commit to HEAD. I'll move first, then immediately edit to change the contents. > >> but I'm not sure where to put it. > > Ideally tests should live next to the code they exercise, just as we are = doing for user-space applications. This means that, at the very minimum, t= hey should be somewhere within src/sys/. > > Now that's tricky of course. Some thoughts that cross my mind: > > First, I'm not sure about what the implications of putting "user-level" c= ode in src/sys/ are regarding the build infrastructure. I suspect that by = restricting the test code into 'tests' subdirectories and only recursing in= to them with the MK_TESTS knob is good enough, but I don't know for sure at= the moment. > > Second, possibly trickier, is that any kernel tests that currently exist = are integration tests by design: we have no unit-testing framework for the = kernel (such as what rump provides for NetBSD), and as such any test will b= e quite "broad" in scope. This may make it difficult to pinpoint the speci= fic subdirectory in which the test belongs. For your case above, I cannot = tell if any of the src/sys/net*/ subdirectories are relevant and/or specifi= c enough. If they are, then I'd say put the test in one of them using src/= sys/netgraph/tests/unix_seqpacket_exercise to pick an example at random. Sounds good, but the most relevant directory is actually src/sys/kern/, not src/sys/netgraph. > > Lastly, we may need a src/sys/tests/ directory to implement cross-functio= nal tests that don't fit any specific directory, just like we have src/test= s/ for that purpose. Or maybe we can (ab)use the latter instead. We definitely will need some sort of location for cross-functional tests. For example, the STF ZFS tests touch just about everything related to ZFS. But that's a problem for another day. -Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2iuUacekAj1JKtnk=-L6Q5-Q-Y_HvbeStmTTm-axnvviw>