...and that is _exactly_ what I propose(d) in the beginning and what OSX already does. Further, keeping the shared page and functions fixed at the end of the memory space has advantages like not needing any special linking, being easily accessible for code jumps or data reads, and so on [1]. The TSC issues are but one part of the puzzle. After this week-long discussion I still can't decide whether this was something that's desirable at all: keeping in mind that it's among the few project ideas tagged as "Suggested for Google Summer of Code 2009" on the FreeBSD website. :-\ Though I've been reading mailing list archives, and the various handbooks, I'm not familiar well enough with other parts of the freebsd kernel to draft another concrete proposal on my own at this time. [1] *Mac OS X Internals: A Systems Approach,* p 595, Amit Singh, ISBN 0321278542 On Tue, Mar 31, 2009 at 12:59 AM, Tim Kientzle <kientzle_at_freebsd.org> wrote: > Poul-Henning Kamp wrote: > >> In message <20090329180745.GB38985_at_server.vk2pj.dyndns.org>, Peter Jeremy >> write >> s: >> >> I'm assuming folks are still in love with the TSC because it still the >>>> cheapest as oppose ACPI-fast or HPET to even contemplate this? >>>> >>> That is its major advantage. It might be feasible to export all the >>> data necessary to implement the complete CLOCK_*_FAST family. >>> >> >> The general attraction is that it can be read from userland by >> unpriviledged >> programs. >> >> On systems where the ACPI or HPET hardware can be memory-mapped, I should >> be equally possible to map those read-only into userland processes. >> >> Now _THAT_ would be interesting. >> > > Which brings us back to having a page of code > provided by the kernel so that the kernel can > determine the appropriate implementation > (depending on the hardware availability) and so > that userland can invoke the functions without > going through a task switch. Libc can then > either invoke these directly or, if the page is > unavailable for any reason, use the system calls. > > Tim > >Received on Mon Mar 30 2009 - 19:32:35 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:45 UTC