Date: Wed, 5 Mar 2014 10:08:49 -0700 From: Alan Somers <asomers@freebsd.org> To: Peter Holm <peter@holm.cc> Cc: "freebsd-testing@freebsd.org" <freebsd-testing@freebsd.org> Subject: Re: Test scenario for sysctl kern.maxfiles Message-ID: <CAOtMX2hUJ2Hc62bG1jitbQbiHtb8b8Jm8iWaP4VaJPuADXR=Kw@mail.gmail.com> In-Reply-To: <20140305085806.GA70478@x2.osted.lan> References: <20140305085806.GA70478@x2.osted.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 5, 2014 at 1:58 AM, Peter Holm <peter@holm.cc> wrote: > Here's an attempt to verify that increasing kern.maxfiles works as > expected. > > http://people.freebsd.org/~pho/kern_descrip_test-v3.diff > -- > Peter 1) done should be of type "static volatile sig_atomic_t", not int, because it's set by signal handlers. 2) using atexit() to register a cleanup routing is a hack. No doubt you already noticed that it's difficult to use Kyua's builtin cleanup capabilities because of the need to pass the value of oldmaxfiles. I too have experienced that frustration. Is there any way to pass values from the body of a testcase to its cleanup? Using atf_tc_set_md_var() would be one way, but the man page suggests that that function cannot be called from the body. Julio, is there a better way to do this? 3) Why do you openfiles(oldmaxfiles + 50, 0) instead of just openfiles(oldmaxfiles) ? It seems that the latter would also verify the assertion. 4) openfiles(oldmaxfiles + 50, 0) will fail if there are already 950 open files. A quick check on freefall showed that kern.openfiles was 935. Perhaps you should try opening openfiles(oldmaxfiles - kern.openfiles + 50, 0). That wouldn't be perfect, due to races, but it would be better. -Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2hUJ2Hc62bG1jitbQbiHtb8b8Jm8iWaP4VaJPuADXR=Kw>