Re: sensors fun..

On Thursday 18 October 2007 07:39:49 am Alexander Leidinger wrote:
To me it looks like your proposal spans more than one of the above
described layers in one package. It seems you describe what I call
single-system sensors framework above. It looks like you want to have
this with parts of it in the kernel. I don't think this is a good idea
as I don't think userland data should be feed into the kernel. Could
you please describe where you see benefits of your architecture
compared to the description I provided above?

Nowhere do I suggest to feed userland data into the kernel just so it can be
reexported to userland. Instead, I think the "public" interface that systat,
monitoring daemons, SNMP, etc. should be a userland interface that can have
multiple backends. It can pull data from a sensor implemented in userland or
a sensor implemented in the kernel.

--
John Baldwin
_______________________________________________
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: sensors framework continued (architecture)
    ... This sounds like you propose more than one kernel access point for all ... I was talking about the one fd per sensor part here, ... With just one syscall (see above for the sysctl approach) you can not ... do latency measurement in userland. ...
    (freebsd-arch)
  • Re: Porting OpenBSDs sysctl hw.sensors framework to FreeBSD
    ... Sensor hardware is not context-free and selfidentifying like PCI and ... I put my focus on the kernel framework ... needs to be handled in userland. ... cam to use the sensors framework to present interesting data of SCSI ...
    (freebsd-arch)
  • Re: sensors fun..
    ... as I don't think userland data should be feed into the kernel. ... a sensor implemented in the kernel. ... Now I think that you talk more or less about something which could be implemented e.g., as an userland library which not only polls the kernel sensors framework, but provides the single-system sensor data. ...
    (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)