Followups: performance counters, ksplice, and fsnotify

Posted Dec 18, 2008 15:05 UTC (Thu) by niner (guest, #26151)
In reply to: Followups: performance counters, ksplice, and fsnotify by deater
Parent article: Followups: performance counters, ksplice, and fsnotify

to post comments

Followups: performance counters, ksplice, and fsnotify

Posted Dec 19, 2008 5:02 UTC (Fri) by deater (subscriber, #11746) [Link] (1 responses)

I wonder where this sentiment that hardware specific stuff doesn't belong into the kernel comes from. I thought one of the kernel's main purposes was to abstract the hardware and hide it from user space. Why then put hardware specific stuff into user space libraries instead of the kernel?

The kernel should abstract the hardware, but in as minimal way as possible. With performance counters this means that the kernel should enable starting and stopping of monitoring, enforce some sanity checks, and provide user-space with a common way to set up events.

What it does *not* mean is including 200k of library code that maps meaningful textual names to the numeric counter identifiers, or including all the subtle limitations of the counters (not all counters can count all events, not all counters are available on all steppings of a CPU, etc).

Putting that all into the kernel would definitely be a losing proposition. Perfmon does it from userspace. Ingo's method would have it all in the kernel.

This is a similar argument about whether video4linux should include format conversions into the kernel or not.

It's important to know what the correct level of abstraction for your interface is.

Followups: performance counters, ksplice, and fsnotify

Posted Dec 21, 2008 12:05 UTC (Sun) by Ze (guest, #54182) [Link]

>Putting that all into the kernel would definitely be a losing proposition. Perfmon does it from userspace. Ingo's method would have it all in the kernel.
>This is a similar argument about whether video4linux should include format conversions into the kernel or not.
It seems to me that this is an argument in favour of a microkernel approach.

I mean we've already got loadable kernel modules , fuse , and a move to push usb drivers out of kernel space into libusb.

Personally I can see the day when someone leverages the kernel driver model code but puts it in a kernel based around a microkernel.