View Full Version : Keyboard Interrupt
Salve ragazzi,
dovrei fare una modifica al kernel in modo che mi memorizzi in una variabile globale (creata da me) quanto tempo ci mette il Kernel a gestire una interruzione di tipo KeyBoard.
Credo che dovrò usare il sistema di Timing rdtsc presente sui Pentium:
è una funzione assembler e dovrebbe restituirire il valore di certi registri.
Gli IRQ da tastiera sono i numeri 1, quindi pensavo di vedere il tempo che trascorre da quando l'IRQ1 si presenta in uno dei registri succitati a quando si ri-presenta dopo essere stato interrotto dagli altri IRQ prioritari.
Ma non ho che ho le idee chiarissime..cosa mi consigliate?
Lo so che la questione non è stupida, quindi mi rivolgo agli intenditori del Kernel.
Grazie 1000 ai cervelloni che sapranno rispondere.
ilsensine
05-05-2003, 11:39
Se vuoi misurare il tempo di latenza dell'irq handler, guarda in drivers/char/pc_keyb.c:keyboard_interrupt.
Nota che la gestione degli irq è fatta in due parti; durante l'irq handler (keyboard_interrupt) le irq sono disabilitate; la gestione vera e propria viene fatta da un tasklet (v. drivers/char/keyboard.c, keyboard_tasklet e relativa funzione kbd_bh) che è eseguita al di fuori di keyboard_interrupt, e con gli irq abilitati (come normale).
Tra l'avvento dell'irq e l'avvio del tasklet può ovviamente intercorrere diverso tempo, è questo che devi misurare?
ilsensine
05-05-2003, 11:54
mmm no, ho letto male, il tasklet si occupa solo di gestire i led, la gestione è un pò più complicata e divisa in più parti. Le funzioni salienti sono
handle_scancode in keyboard.c (eseguita in irq context)
console_callback in console.c per la notifica/gestione dei vt (eseguita in process context, con la chiamata schedule_console_callback)
Probabilmente sei interessato solo alla parte eseguita in irq context, quindi puoi mettere la misura direttamente in keyboard_interrupt. Nota che durante la gestione gli irq si mantengono disabilitati (non ho verificato in dettaglio ma mi sembra così).
Ehi! grazie per la risposta..il discorso è abbastanza tecnico e sono felice che qualcuno risponda.
Quello che io devo misurare è il tempo che intercorre da quando premo il pulsante a quando compare il carattere sullo schermo, ovvero tutto il flusso Input/Output:
-Premo tasto
-Interruzione al Kernel
-Gestione Interruzione da parte di Linux e della CPU.
-Ritorno a video di quello che mi aspetto (il carattere premuto appunto)
Stop.
Il tasklet per i leds che segnali, non dovrebbe interessarmi.
Invece l' elenco di operazioni che mi hai elencato nell' ultimo post è interessante.
Io immagino che l' IRW da tastiera sia gestito + o - come gli altri, ma con priorità molto bassa: a questo punto devo misurare il tempo di Control Path, incluse le funzioni differite (se mai ce ne sono).
Non penso sia difficile..se vuoi parlare + in dettaglio (se ti và di aiutarmi :sofico: ) e pensi che il topic sia di poco interesse, possiamo farlo in pvt.
Grazie cmq..
ilsensine
06-05-2003, 16:45
E' un pò complicato quello che vuoi fare. Forse sarebbe meglio misurare il tempo intercorso da quando il tasto viene premuto a quando ad es. un programma utente lo "riceve". Se vai a "cercare" dove e quando viene stampato il carattere sullo schermo, non ne esci più (soprattutto se usi xfree, che non usa il kernel per l'output video).
OK, mi va bene anche come dici tu..tecnicamente quello che mi interessa è il tempo di gestione deel' interrupt..ovvero il tempo di Control Path..non so se mi segui..ciao
ilsensine
07-05-2003, 08:15
Il tempo di gestione dell'irq è semplice da misurare, basta misurare il tempo trascorso dentro pc_keyb.c:keyboard_interrupt().
Nota però che lo smistamento degli eventi della tastiera, una volta gestiti dall'interrupt, è posticipata a un altro kernel task. Quello che farei è:
- Prendere nota del tempo all'_entrata_ di keyboard_interrupt. Questo valore può essere esportato in un file dentro /proc.
- Un apposito programma utente è in read() su /dev/psaux. Appena arriva un tasto, prende nota dell'istante di arrivo, legge il valore scritto in /proc e tramite differenza misura il tempo trascorso.
Questo procedimento funziona sicuramente con XFree _non_ in esecuzione e tastiere ps/2. Se XFree è in esecuzione, potrebbe catturare lui gli eventi della tastiera, col risultato che ti perdi diversi tasti.
OK, ottima soluzione..ricapitoliamo:
-Piazzo una rdtsc (funziona per gli AMD che tu sappia?) in pc_keyb.c:keyboard_interrupt() . Appena arriva un IRQ da tastiera, mi faccio memorizzare dalla rdtsc il tempo dentro ad una variabile di profiling (che preferisco creare io).
- Tu dici: "è in read() su /dev/psaux" . Questa cosa non l'ho mai sentita! Ad intuito, immagino sia il device tastiera e il kernel è in read() ,ovvero in ascolto,degli input su questo device. Intendi questo?
-Ti confermo che non è necessario il funzionamento sotto XFREE..mi basta la shell e tastiera PS2.
Alla prossima. :p
ilsensine
07-05-2003, 09:50
Originally posted by "fedo"
- Tu dici: "è in read() su /dev/psaux" . Questa cosa non l'ho mai sentita! Ad intuito, immagino sia il device tastiera e il kernel è in read() ,ovvero in ascolto,degli input su questo device. Intendi questo?
Sì. Però ho visto ora che /dev/psaux funziona solo col mouse...se aspetti un pò trovo una soluzione alternativa
ilsensine
07-05-2003, 10:05
Ok questo programmino è la soluzione; funziona anche sotto XFree:
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/types.h>
#include <fcntl.h>
#include <termios.h>
int main() {
unsigned char k;
int fd = fileno(stdin);
struct termios tty;
tcgetattr(fd, &tty);
tty.c_lflag &= ~ICANON;
tty.c_lflag &= ~ECHO;
tty.c_cc[VMIN] = 1;
tty.c_cc[VTIME] = 0;
tcsetattr(fd, TCSAFLUSH, &tty);
while(1) {
read(fd, &k, 1);
/* Mettere la misura qui */
fprintf(stderr, "recv %02x\n", k);
}
return 0;
}
Grande!
Che codice ostico...forse perchè non conosco tutte le librerie. (Termios :confused: )
Quindi questo programmino che farebbe?
Si mette in ascolto per eventi da tastiera? come dovrei utilizzarlo?
Scusa per lo stress, ma mai mi sarei sognato di beccare sul forum uno che si "infilava" nell' argomento ;)
ciao
ilsensine
07-05-2003, 10:30
Se skifezze di termios servono semplicemente a disabilitare l'echo, a settare il tempo minimo di delay e a impostare la ricezione dei caratteri appena arrivano (di default stdin è line-buffered).
Il funzionamento è semplice: il programma rimane bloccato sulla read finché non è disponibile un carattere in ingresso.
Nota che:
- Per ogni tasto premuto, vengono generate _più_ interruzioni. Ad es. sul mio sistema la pressione di un tasto normalmente comporta 3 interruzioni.
- I dati ricevuti dalla tastiera vengono smistati dal kernel nel layer console, che li gestisce al di fuori del contesto di interruzione.
- Il layer console provvede a "tradurre" i tasti in base al layout di tastiera impostato. Nota che alcuni tasti funzione generano _più_ di un "carattere".
- Appena un carattere è disponibile nel buffer di lettura, la read() viene "svegliata" e il controllo ripassa al programma.
Ovviamente quello che misureresti è l'intervallo tra l'ultima interruzione avvenuta e quando il carattere, finalmente decodificato e tradotto, viene passato al programma.
OK, ora ci metto le mani e poi ti faccio sapere..per ora sei stato prezioso..thx
Rieccomi qui!
Il file che tu dici pc_keyb.c l' ho beccato ed anche la funzione keyboard_interrupt(). La riporto:
static void keyboard_interrupt(int irq, void *dev_id, struct pt_regs *regs)
{
#ifdef CONFIG_VT
kbd_pt_regs = regs;
#endif
spin_lock_irq(&kbd_controller_lock);
handle_kbd_event();
spin_unlock_irq(&kbd_controller_lock);
}
OK, guardando questo codice si nota che la gestione di un Interrupt di tastiera è gestito dalla funzione handle_kbd_event(), che come dice il nome è il "gestore" degli eventi Keyboard.
Le funzioni spin_lock_irq(&kbd_controller_lock) e spin_unlock_irq(&kbd_controller_lock) mi pare servano a bloccare il keyboard controller affinchè non pervengano altre interruzioni.
Anche qui i conti tornano: essendo un collegamento seriale, il controller deve trattare un tasto alla volta.
Però correggimi se sbaglio...
Tornando alla handle_kbd_event(), si nota questo codice:
if (status & KBD_STAT_MOUSE_OBF)
handle_mouse_event(scancode);
else
handle_keyboard_event(scancode);
dal quale si capisce che la funzione tratta anche il mouse.
...bisogna entrare in quella specifica della tastiera....Entriamoci dunque..
static unsigned char kbd_exists = 1;
static inline void handle_keyboard_event(unsigned char scancode)
{
#ifdef CONFIG_VT
kbd_exists = 1;
if (do_acknowledge(scancode))
handle_scancode(scancode, !(scancode & 0x80));
#endif
tasklet_schedule(&keyboard_tasklet);
}
Bene! E se ora io piazzo le letture del time in questa funzione? Uso una rdtsc o una gettimeofday() .
La questione è che la gestione dell' IRQ è comunque iniziata nelle funzioni precedenti e quel tempo non lo posso buttare. io direi di leggere il time nelle funzioni precedenti e poi, se è il mouse ad aver generato l' IRQ, butto tutto, altrimenti mi prendo quello che volevo.
Ti pare corretto ?
Ciao
ilsensine
19-05-2003, 13:25
sì
Ahò! ma è un forum o una chat? Come hai fatto a rispondermi nel giro di un min? :D :D
Dunque il tempo lo prendo in maniera simile:
if (status & KBD_STAT_MOUSE_OBF)
handle_mouse_event(scancode);
else
{
int inizio = gettimeofday();
handle_keyboard_event(scancode);
int fine = gettimeofday();
proc_var = fine - inizio;
}
Ovviamente è un meta-linguaggio...
ilsensine
19-05-2003, 13:31
Chi o che cosa ti ha messo in testa che in kernel space puoi usare le funzioni delle glibc (tipo gettimeofday)?
:D
OK...sorry...
procedo con l' "ignorantissima" rdtsc corretto questo, la procedura è giusta no?
ilsensine
19-05-2003, 14:11
O rdtsc oppure do_gettimeofday (v. linux/time.h -- credo che sia invocabile anche in irq context)
ilsensine
19-05-2003, 15:27
mmm se riesci a evitare la do_gettimeofday sarebbe meglio...non è precisissima, e da quel che leggo usa un lock (probabilmente non pericoloso, ma dentro un irq handler con uno spinlock già acquisito non si è mai abbastanza prudenti...)
una cosa: se io prima della funzione in questione, ci metto una
printk("ciao") non dovrebbe scrivermi in un file di /proc la scritta "ciao" ogni volta che premo un tasto?
Mica me lo fa :confused:
Invece mi si apre mentre scrivo il gestore dei crash di KDE Mandrake... :confused:
Bye
ilsensine
26-05-2003, 14:09
Originally posted by "fedo"
una cosa: se io prima della funzione in questione, ci metto una
printk("ciao") non dovrebbe scrivermi in un file di /proc la scritta "ciao" ogni volta che premo un tasto?
Mica me lo fa :confused:
http://buffer.antifork.org/linux/procfs-guide.pdf
Originally posted by "ilsensine"
Chi o che cosa ti ha messo in testa che in kernel space puoi usare le funzioni delle glibc (tipo gettimeofday)?
Ascolta approfitto di questo thread per farti una domanda...
Sto studiando il GNU C Library Reference Manual perchè devo fare un progetto.
L'unica cosa che in questo progetto ho dei dubbi che non so se questo manuale chiarirà.
Hai presente la funzione della Bash che con i tasti freccia scorri l'history?
Bene...Io devo fare una cosa analoga. Come faccio a "collegare" i tasti freccia a delle routine di gestione che eventualmente ho scritto io. E soprattutto come faccio a fare l'output di testo su una sola riga! Scusate l'intromissione ma è una cosa importante!!!!
ilsensine
26-05-2003, 15:01
Innanzitutto devi settare l'input come char-buffered, quindi leggere un carattere alla volta e interpretare l'input. Ad alcuni tasti (i tasti funzione, le frecce ecc.) corrisponde una sequenza multicarattere che inizia con <esc>.
Ci sono forse altri metodi, puoi sempre "consultare" i sorgenti di bash ;)
Originally posted by "ilsensine"
Innanzitutto devi settare l'input come char-buffered, quindi leggere un carattere alla volta e interpretare l'input. Ad alcuni tasti (i tasti funzione, le frecce ecc.) corrisponde una sequenza multicarattere che inizia con <esc>.
Ci sono forse altri metodi, puoi sempre "consultare" i sorgenti di bash ;)
Forse è meglio che apro un nuovo thread in programmazione, non mi sembra il caso di rubare il thread a fedo.
:p se sta bene al sensine...
io cmq ancora non riesco a capire dove mi stampa la printk :D
Sensine non mi ammazzare :D
ilsensine
27-05-2003, 07:15
printk finisce sulla console testo di login, se disponibile; inoltre finisce in /proc/kmsg, che viene catturato dal demone syslogd e smistato nei file di log sotto /var/log. Non è quello che ti serve, devi esportare una variabile tramite un file in proc. Guarda agli innumerevoli esempi nei sorgenti di utilizzo del procfs.
Originally posted by "fedo"
:p se sta bene al sensine...
Bene o non bene non sarebbe un atteggiamento corretto. Auguri per il problema. Magari fanne pure a me che ne ho bisogno. :D
Originally posted by "fedo"
ricambio :p
Grazie :D
Ciao,
in allegato ho trovato una procedura di kernel hacking per maneggiare il proc_fs ..
Quella prcedura permette di creare un Kernel con variabili contenute nel proc..
ho visto le funzioni per gestire il tutto e sono uguali a quelle riportate dalla guida pdf che mi hai consigliato...unica cosa è che la procedura implementa solo il metodo di lettura delle variabili, mentre a me serve pure aggiornare i valori..
Quindi dovrò creare la funzione di write_entry (seguo il tuo pdf)..una volta fatto questo, vado in pc_keyb.c e prima della gestione dell' IRQ faccio un write del valore del jiffies in una variabile kdbg ..poi ripeto la cosa dopo la funzione e quindi faccio la differenza dei due valori..direi che ci siamo..
Ehi sensin! ho seguito la procedura per il proc file ed è andata a buon fine..ora devo creare la funzione di scrittura dei valori (in particolare il "jiffies" ). Sto sulla buona strada?
ciao
ilsensine
29-05-2003, 07:46
Scusa, non ho molto tempo per seguirti...cmq la strada è giusta, devi creare un procfile dove "stampi" il valore della variabile che contiene l'ultima misura, così da poterlo leggere in user space. Non mi sembra complicato, se hai capito come creare un file proc non avrai problemi.
Hint: visto che il file in proc deve essere in sola lettura, puoi semplificare un pò la gestione chiamando create_proc_read_entry invece di create_proc_entry (v. linux/proc_fs.h)
OK!
spero che quel file possa ritornarti utile...ci sentiamo..
ari-eccomi qui :) :)
qualcosa ho combinato... in pc_keyb.c ho messo:
//Per usare le mie variabili ProcFile...
extern unsigned long kdbgvar0, kdbgvar1, kdbgvar2, kdbgvar3, kdbgvar4, kdbgvar5;
//Routine IRQ Tastiera e mouse
static unsigned char handle_kbd_event(void)
{ //Due metodi alternativi per misurare il tempo!!!: Con jiffies e con RDTSC
kdbgvar0 = jiffies; //Prendo il jiffies iniziale
unsigned long long my = read_timestamp(); //Questo è per il metodo RDTSC!!
kdbgvar3 = my; //Mi prendo il RDTSC iniziale
//Qui c'è altro codice irrilevante....poi
{
if (status & KBD_STAT_MOUSE_OBF)
handle_mouse_event(scancode); //Routine per il mouse
else
{
handle_keyboard_event(scancode); //Routine IRQ tastiera!!
kdbgvar1 = jiffies //Prendo il jiffies finale..
kdbgvar2 = kdbgvar1 - kdbgvar0; //Ecco qui il Jiffies TOTALE (differenza).
my = read_timestamp(); //Sempre per metodo RDTSC
kdbgvar4 = my; //Mi prendo il RDTSC finale
kdbgvar5 = kdbgvar4 - kdbgvar3; //Ecco RDTSC Totale!!
//Altro codice Irrilevante...
La variabile my riceve il valore dalla funzione read_timestamp() che ho definito in un mio file H di libreria (key_time.h) fatto in questo modo:
#include <asm/msr.h>
/* read the result processor time stamp counter (RDTSC instruction) */
unsigned long long read_timestamp() {
unsigned long long result;
unsigned long ls, ms;
rdtsc(ls, ms); /* /usr/src/linux/include/asm/./msr.h */
result = (unsigned long long) ms;
result <<= 32;
result |= (unsigned long long) ls;
return result;
}
Come vedi ho usato la rdtsc che dovrebbe essere precisissima.
Che succede se compilo questo Kernel e leggo i valori delle kdbgvars? Quando vado a fare > cat /proc/kdbgvars esce fuori:
kdbgvar0= 1d634, kdbgvar1= 1d634, kdbgvar2=0, kdbgvar3= ebc2ec84, kdbgvar4= devo inserirla , kdbgvar5= devo inserirla.
Le variabili 4 e 5 non le ho messe perchè anche se su carta il codice è come ti ho scritto, non ho modificato il procFile per aggiungere queste ultime 2 var.
Quello che mi lascia perplesso è:
-Perchè il metodo Jiffies ritorna lo stesso valore (quindi il totale è 0) ? Mi viene solo in mente che il Jiffies è poco accurato (un tick = 10 ms.) e la routine fa prima di un tick a finire...dimmi se è così..
- I valori che mi vengono restituiti, ma in che formato sono? Esadecimale? oltre al jiffies, la variabile 3 che funziona con la rdtsc, ma che diamine di valore dà? non è un long? e poi che significa che la routine read_timestamp() restituisce un unsigned long long? Sbaglio forse a fare il cast con la kdbgvar3 che è solo unsigned long?
Boh....io vorrei delle variabili temporali (numeri decimali) non esadecimali o che diamine sono...puoi risolvere l' arcano?
Ti piace questo bell' impiccio mooooolto Kernel Hacking? :D :D :D
Non mi ammazzare ;)
Ecco qui un pò di tests + seri:
[root@localhost root]# cat /proc/kdbgvars
kdbgvar0= 5d08, kdbgvar1= 5d08, kdbgvar2= 0,
kdbgvar3= 983c1a58, kdbgvar4= 983d400c, kdbgvar5= 125b4
[root@localhost root]# cat /proc/kdbgvars
kdbgvar0= 61e5, kdbgvar1= 61e5, kdbgvar2= 0,
kdbgvar3= d0df5814, kdbgvar4= d0e052cc, kdbgvar5= fab8
[root@localhost root]# cat /proc/kdbgvars
kdbgvar0= 6292, kdbgvar1= 6292, kdbgvar2= 0,
kdbgvar3= 8be9eb0c, kdbgvar4= 8beaeae0, kdbgvar5= ffd4
[root@localhost root]# cat /proc/kdbgvars
kdbgvar0= 6382, kdbgvar1= 6382, kdbgvar2= 0,
kdbgvar3= 89400a54, kdbgvar4= 89414c64, kdbgvar5= 14210
[root@localhost root]# cat /proc/kdbgvars
kdbgvar0= 644f, kdbgvar1= 644f, kdbgvar2= 0,
kdbgvar3= 664d3a8a, kdbgvar4= 664e358e, kdbgvar5= fb04
[root@localhost root]#
RDTSC pare funzioni...la jiffies no...ma sempre qui valori strani..mi sembrano proprio esadecimali..come li CASTO?
ilsensine
05-06-2003, 18:25
Originally posted by "fedo"
-Perchè il metodo Jiffies ritorna lo stesso valore (quindi il totale è 0) ? Mi viene solo in mente che il Jiffies è poco accurato (un tick = 10 ms.) e la routine fa prima di un tick a finire...dimmi se è così..
Oltre a non essere precisissimo, stai lavorando con gli irq disabilitati! Chi aggiorna jiffies? ;)
- I valori che mi vengono restituiti, ma in che formato sono? Esadecimale? oltre al jiffies, la variabile 3 che funziona con la rdtsc, ma che diamine di valore dà? non è un long? e poi che significa che la routine read_timestamp() restituisce un unsigned long long? Sbaglio forse a fare il cast con la kdbgvar3 che è solo unsigned long?
Una cosa per volta. Che codice usi per scrivere nei procfile?
ti dico che il jiffies lo butto...non mi piace :D
Invece nel proc_file ci scrivo con delle assegnazioni alle variabili kdbgvars che sono appunto del PF..ad esempio
kdbgvar0 = jiffies; //Prendo il jiffies iniziale
unsigned long long my = read_timestamp(); //Questo è per il metodo RDTSC!!
kdbgvar3 = my; //Mi prendo il RDTSC iniziale
vedi come ci scrivo?
invece per leggerle ho la procedura che trovi in allegato + in alto...
Ho notato che se ad una variabile kdbg assegno una costante, del tipo:
kdbgvar1 = 0x111111
il valore stampato dal cat è correttamente 111111 . Quindi secondo me è una questione di Cast tra unsigned long e costante esadecimale..
Ma perchè, non và bene scrivere una variabile procFile con l'assegnazione? devo per forza fare una procedura di write apposita?
thx per l'aiuto..rispondi quando hai tempo..non voglio assillarti
ilsensine
06-06-2003, 07:23
int kdbgvars_read_proc(char *page, char **start, off_t off, int count, int *eof,
void *data)
{
int written;
written = sprintf(page, "kdbgvar0= %x, kdbgvar1= %x, kdbgvar2= %x,
kdbgvar3= %x\n",
kdbgvar0, kdbgvar1, kdbgvar2, kdbgvar3);
return written;
}
Oh mamma....
Sai per caso cosa vuol dire '%x'? ;)
veramente no...la procedura per queste kdbg è fatta così..in effetti mi sono un pò meravigliato perchè conosco solo %i, %d ,%s e qualcun altro carattere di stampa, ma %x non l' ho mai visto...
Penso però che si riferisca alle variabili che poi scrive dopo...tipo quando si usa la printf().
Ehi! ma aspetta un pò!!! :sofico: Sarà mica la stampa esadecimale? :confused: :confused: voglio proprio vedere..
ilsensine
06-06-2003, 08:57
Originally posted by "fedo"
Ehi! ma aspetta un pò!!! :sofico: Sarà mica la stampa esadecimale? :confused: :confused:
Non è per formattare l'hd :muro:
:D
ilsensine
06-06-2003, 09:00
man sprintf ;)
Ora mi dà questo..ho cambiato %x con %d ..mi vedo il man come hai detto..
[root@localhost root]# cat /proc/kdbgvars
kdbgvar0= 17716, kdbgvar1= 17716, kdbgvar2= 0,
kdbgvar3= 212209802, kdbgvar4= 212262094, kdbgvar5= 52292
[root@localhost root]# cat /proc/kdbgvars
kdbgvar0= 18046, kdbgvar1= 18046, kdbgvar2= 0,
kdbgvar3= 1805287378, kdbgvar4= 1805357558, kdbgvar5= 70180
[root@localhost root]# cat /proc/kdbgvars
kdbgvar0= 19464, kdbgvar1= 19464, kdbgvar2= 0,
kdbgvar3= 1585913812, kdbgvar4= 1585979172, kdbgvar5= 65360
[root@localhost root]# cat /proc/kdbgvars
kdbgvar0= 19962, kdbgvar1= 19962, kdbgvar2= 0,
kdbgvar3= 1949784390, kdbgvar4= 1949936474, kdbgvar5= 152084
ilsensine
06-06-2003, 09:19
Qual è il problema?
pare nessuno...ma vorrei capire se è giusto che faccio una assegnazione tra unsigned long long (variabile my) e una unsigned long (kdbgvar) .
Mi perdo qualcosa nel casting? Oppure non vorrei dire frescacce, ma unsigned long long non è una matrice?
Scusa se dico scemenze, ma io non sono programmatore C...
Infine, la rdtsc mi ritorna il numero di colpi di clock no?
Ciao
ilsensine
06-06-2003, 10:35
Sì la rdtsc dovrebbe ritornare i tick di clock.
Fare il cast da long long (intero a 8 byte) a long (intero a 4 byte) ovviamente causa la perdita della "long" più significativa (da qui i valori "minori" che misuri con successive letture); non è un grosso problema in quanto ti interessa la _differenza_ tra due valori, che entra tranquillamente in un long.
Potresti anche cambiare il tipo delle variabili che contengono la lettura da rdtsc in long long, in tal caso devi utilizzare il formato %Lu (unsigned long long ) o %Ld (signed long long) nella sprintf.
Ottima dritta...la provo e ti dico...thx
CMQ sono contento che il topic lo portiamo avanti perchè non ce ne sono molti sul Kernel Hacking riguardo al debug...spero serva ad altri per lavori futuri
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.