The attached patch is sufficient to make coreinfo run on a machine
without TSC, however while trying to get FILO to run I've realised
this involves more changes than I originally expected.
cpu_khz gets exposed as a global, so it's going to be very difficult
to support CPUs without TSC, without
On Fri, Feb 5, 2010 at 3:12 AM, bifferos biffe...@yahoo.co.uk wrote:
cpu_khz gets exposed as a global, so it's going to be very difficult
to support CPUs without TSC, without changing the mechanisms some
payloads use to do timing. If you don't have TSC, then cpu_khz is
largely irrelevant,
On 2/5/10 5:23 PM, ron minnich wrote:
On Fri, Feb 5, 2010 at 3:12 AM, bifferos biffe...@yahoo.co.uk wrote:
cpu_khz gets exposed as a global, so it's going to be very difficult
to support CPUs without TSC, without changing the mechanisms some
payloads use to do timing. If you don't have
--- On Fri, 5/2/10, Stefan Reinauer ste...@coresystems.de wrote:
There's no way to just make it relevant? Can't a
non-TSC CPU support
something meaningful in that variable?
(I don't know,just asking)
FILO uses this for its timeouts in various places. If there
is a better
way to do
Am 13.01.2010 14:14, schrieb bifferos:
Or we could just add a compilation option, however since
libpayload is a library I don't think that's ideal.
As this is not a library to be installed on any system, a compile time
option should suffice.
The only reason for runtime detection would be
bifferos wrote:
I was just wondering if there would be any interest in a patch
to remove the dependency.
I think so.
Or we could just add a compilation option, however since
libpayload is a library I don't think that's ideal.
I think a config option for this would be fine.
//Peter
--
I'm amazed to hear that there is a CPU without TSC, here in the 21st century :-)
Why not a config option for older CPU that would disable newer
features -- otherwise people are going to have to guess which features
they have and which they don't.
What other modern features is this 150 Mhz CPU
7 matches
Mail list logo
