Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD

* Alexander Leidinger <Alexander@xxxxxxxxxxxxx> [070711 10:49] wrote:
Quoting "Poul-Henning Kamp" <phk@xxxxxxxxxxxxxx> (Wed, 11 Jul 2007 17:33:51 +0000):

In message <20070711190546.4b202080@deskjail>, Alexander Leidinger writes:
Quoting "Poul-Henning Kamp" <phk@xxxxxxxxxxxxxx> (Wed, 11 Jul 2007 13:54:40 +0000):

You are focusing on physical devices which are specially build as a
sensor for some specific stuff. I put my focus on the kernel framework
which allows to unify the handling of sensoric data from kernel
devices.

I'm trying to point out that your kernel framework belongs in userland.

It's not my framework.

There is no benefit from having it in the kernel.

You need to get some information out of the kernel somehow (you cut
this part of my mail). And as far as I understand the high level
description (presentation in the net) of this framework, this does this
in an unified way. Do you propose to get the information out of the
kernel in a non-uniform way?

Possibly, one way to do that is to provide a well thought out
userland library that can make for a nice interface. If by
doing it userland the kernel implementation can be kept smaller
and more simple it might be a win.

That said, it may be a loss if you wind up having to duplicate
work over and over for different devices it may be a loss.

Remember, once the kernel interface is exposed it has to be there
almost forever, while a userland interface and much more easily
be adapted.

--
- Alfred Perlstein
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Porting OpenBSDs sysctl hw.sensors framework to FreeBSD
    ... I put my focus on the kernel framework ... which allows to unify the handling of sensoric data from kernel ... I'm trying to point out that your kernel framework belongs in userland. ...
    (freebsd-arch)
  • Re: Attempted summary of "RT patch acceptance" thread
    ... tries to keep the userland API as close as possible to the non-RT one, ... by increasing the kernel complexity with relative slowdown. ... RTAI quickly becomes useless (ok it can run nanosleep with fusion fine, ... RTAI/rtlinux as the only hard-RT with guaranteed deadline. ...
    (Linux-Kernel)
  • Re: [RFC] Splitting kernel headers and deprecating __KERNEL__
    ... >> two parties on an ABI doesn't imply that one party gets to define it ... imposition, kernel developers won't care. ... because there's a contract with userland that they don't want to ... change in the copy/extract/whatever of kernel headers that userland is ...
    (Linux-Kernel)
  • Re: "Enhanced" MD code avaible for review
    ... be required to make this work correctly using a userland approach. ... > kernel, and having to try harder to crash the kernel. ... protected *sooner* if the system crashes. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: [PATCH] remove net driver ugliness that sparse complains about
    ... and when it points to kernel space. ... userland ones. ... and userland pointers, and set_fsis not enough to handle that. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)