linux-kernel - RE: A better interface, perhaps: a timed signal flag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:	Wed, 26 Jul 2006 11:15:16 -0400
From:	"Brown, Len" <len.brown@...el.com>
To:	"Theodore Tso" <tytso@....edu>,
	"Neil Horman" <nhorman@...driver.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	"Segher Boessenkool" <segher@...nel.crashing.org>,
	"Dave Airlie" <airlied@...il.com>, <linux-kernel@...r.kernel.org>,
	<a.zummo@...ertech.it>, <jg@...edesktop.org>
Subject: RE: A better interface, perhaps: a timed signal flag

>if the application doesn't need to
>know exactly how many microseconds have gone by, but just whether or
>not 150us has ellapsed, why calculate the necessary time?  (Especially
>if it requires using some ACPI interface...)

Yes, ACPI is involved in the boot-time enumeration of various timers
and counters.  But at run-time; the use of any and all of them
(including the PM_TIMER supplied by ACPI hardware itself) could/should
appear generic to kernel users, who should not have to directly call
any routine with an "acpi" in it.

I believe that this is true today, and can/should stay true.

-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/