When to hide kernel structures from userspace and when to not hide them?

Newer versions of our linux distributions had their includes revised: A lot of kernel structures that were previously exported to userspace now are not exported anymore. To take an example, definitions of page size (macro PAGE_SIZE), usually found on asm/page.h, that used to be available when one installed the kernel-headers (or equivalent) package.

I see the point of hiding internal kernel structures from most userspace programs, usually they shouldn’t mess with such structures. But if your userspace program is actually a test for a kernel feature? Tests that are designed to test the kernel should be able to access those structures, otherwise we won’t be accurate and portable on our tests.

Example: I am getting the cerberus testsuite to compile under ubuntu 9.04 and opensuse 11. They both don’t have asm/page.h anymore and some of the code of the cerberus test suite use the PAGE_SIZE macro. Doing a bit of research points out to the fact that I should be using the getpagesize() function from unistd.h. Should I really?

unistd.h code:

/* Return the number of bytes in a page.  This is the system's page size,
which is not necessarily the same as the hardware page size.  */
extern int getpagesize (void)  __THROW __attribute__ ((__const__));

An inspection on the testsuite code shows me that the authors really meant to use the hardware page sizes:

/* Takes aligned buffers. Finds an arbitrary location in memory of a
* user process (must be passed as an array of ints) and translates
* it to physical memory location. All this without kernel support
* (besides /proc/kcore). Optionally specify a character alignment in
* case the memory buffer is not byte-aligned. */
/* Now compute the offset (in chars) of the error from the page
boundary. */
fail_page_offset = ((int) (&nbuf[offset])) % PAGE_SIZE

So, how do we handle ‘special’ userspace programs that are intended to test kernel and hardware? Do we still enforce this restriction of not being able to access kernel structures or we do have an alternative solution? Comments are very very much appreciated, I would like to get some ideas before I start to fix those suites…


Finding the firmware level of the power machine from your linux lpar

When you are working with IBM system p machines you frequently need to get the firmware level for the machine you are running. You can get that information from HMC or the FSP web interface, but you can also get it from your linux lpar installed.

I knew that lsmcode would return that information for power machines not managed by HMCs For machines managed by HMCs, that is not possible. What would I do in this case? . Reading the man page for lsmcode, I knew that the information I was looking for was under /proc/device-tree/. A little bit of find on a one liner (the good ol’ brute force method) showed me the info I was looking for:

Disclaimer: The one liner below is known to eat small puppies and kittens. I told you!

# cd /proc/device-tree
# for file in $(find . | grep fw); do echo "$file contents:"; cat $file; echo; done
output ommited

Alas, I found it 🙂

# cat /proc/device-tree/openprom/ibm,fw-vernum_encoded

Back to work…