I've hacked up a version of libpayload which doesn't depend on TSC to get payloads running on my platform. It seems an unnecessary limitation of the library that it needs this, and also that it checks CPU speed before the payload main() is called, meaning you can't avoid it in your payload implementation without recompilation of the lib.
I was just wondering if there would be any interest in a patch to remove the dependency. It doesn't look too tricky, however the ndelay function is hard to implement without TSC. Is this function really needed? Which payloads are likely to suffer if it's inaccurate? mdelay can be pretty accurate using the PIT, udelay could perhaps be based on port 80 reads instead.
A scheme could be put in place to detect the TSC instruction and fall back on alternative routines if it doesn't exist, however as far as I can see this will involve creation of an illegal instruction trap, setting up the IDT etc, which might not be desirable. Removing TSC altogether may be more appropriate, especially if the ndelay() routine isn't really needed (my CPU is 150MHz).
Or we could just add a compilation option, however since libpayload is a library I don't think that's ideal.
Any thoughts?
kind regards, Biff.
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 the ability to deploy a single build of a payload on a highly diverse set of hardware (which hardware doesn't come with TSC these days?)
Patrick
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 missing?
thanks!
ron
-
bifferos -
Patrick Georgi -
Peter Stuge -
ron minnich