Date: Fri, 24 Oct 2014 15:03:52 -0400 From: John Baldwin <jhb@freebsd.org> To: Rui Paulo <rpaulo@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r273598 - in head: include sys/dev/acpica Message-ID: <21470251.4Nq3ilUAWE@ralph.baldwin.cx> In-Reply-To: <201410241839.s9OIdG0E077139@svn.freebsd.org> References: <201410241839.s9OIdG0E077139@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, October 24, 2014 06:39:16 PM Rui Paulo wrote: > Author: rpaulo > Date: Fri Oct 24 18:39:15 2014 > New Revision: 273598 > URL: https://svnweb.freebsd.org/changeset/base/273598 > > Log: > HPET: create /dev/hpetN as a way to access HPET from userland. > > In some cases, TSC is broken and special applications might benefit > from memory mapping HPET and reading the registers to count time. > Most often the main HPET counter is 32-bit only[1], so this only gives > the application a 300 second window based on the default HPET > interval. > Other applications, such as Intel's DPDK, expect /dev/hpet to be > present and use it to count time as well. > > Although we have an almost userland version of gettimeofday() which > uses rdtsc in userland, it's not always possible to use it, depending > on how broken the multi-socket hardware is. > > Install the acpi_hpet.h so that applications can use the HPET register > definitions. > > [1] I haven't found a system where HPET's main counter uses more than > 32 bit. There seems to be a discrepancy in the Intel documentation > (claiming it's a 64-bit counter) and the actual implementation (a > 32-bit counter in a 64-bit memory area). > > MFC after: 1 week > Relnotes: yes > > Modified: > head/include/Makefile > head/sys/dev/acpica/acpi_hpet.c > > Modified: head/sys/dev/acpica/acpi_hpet.c > ============================================================================== > --- head/sys/dev/acpica/acpi_hpet.c Fri Oct 24 17:40:32 2014 (r273597) > +++ head/sys/dev/acpica/acpi_hpet.c Fri Oct 24 18:39:15 2014 (r273598) > +static struct cdevsw hpet_cdevsw = { > + .d_version = D_VERSION, > + .d_flags = D_TRACKCLOSE, > + .d_name = "hpet", > + .d_open = hpet_open, > + .d_close = hpet_close, D_TRACKCLOSE isn't really reliable, and in this case it probably isn't what you want anyway (you want last close I think). If a process opens /dev/hpetN and then forks a child that calls closefrom() and then exec, close() from Closefrom() will invoke hpet_close() and clear devinuse even though the parent is still using it. Removing D_TRACKCLOSE would defer hpet_close() until all references to the fd were dropped. Alternatively, you might consider dropping the devinuse stuff entirely if you don't need it. It doesn't prevent the fd from being shared with child processes across fork(). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?21470251.4Nq3ilUAWE>