tsp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tsp-devel] Re: Problème de sampling.


From: Erk
Subject: Re: [Tsp-devel] Re: Problème de sampling.
Date: Sun, 27 Nov 2005 15:13:46 +0100

2005/11/27, STEF <address@hidden>:
>
> Il y a bien un moment où il va falloir demander tous les symboles
> de tous les providers, ne serait-ce que pour aider l'utilisateur à bâtir
> une configuration from scratch.

Oui et non.

En fait les requetes filtrées:
TSP_consumer_request_filtered_information(
     TSP_provider_t provider,
     int filter_kind,
     char* filter_string)

sont/seront là pour répondre à ce besoin.

Aujourd'hui il y 3 types de requêtes (filter_kind):

FILTER_NONE: on ne filtre rien donc on obtient TOUS les symboles
MINIMAL: on renvoie les infos provider mais rien
                   sur les symboles (pas même le nombre total de symboles)

voir  tsp/src/core/ctrl/tsp_filter_symbol.c

TSP_FILTER_SIMPLE: on passe une chaine en deuxième argument
(filter_string) et cette requête renvoie tous les symboles qui matchent
(strstr) la filter_string, dans ce cas le bombre de symboles indiqués
est celui qui est renvoyé et pas le nombre total côté provider.

voir tsp/src/core/ctrl/tsp_default_glu.c

Pour tester ça j'ai fait une petit ligne de commande:
(exemple avec un stub)
address@hidden tsp]$ tsp_request_generic
request_filtered_information SIMPLE t
Provider::base frequency      = 100.000000
Provider::max period          = 100000
Provider::max consumer        = 100
Provider::current consumer nb = 1
Provider <symbols list begin>
    pgi = 00000000, t
Provider <symbols list end>.
address@hidden tsp]$ tsp_request_generic
request_filtered_information SIMPLE t

ou encore
address@hidden tsp]$ tsp_request_generic
request_filtered_information SIMPLE Symbol19
Provider::base frequency      = 100.000000
Provider::max period          = 100000
Provider::max consumer        = 100
Provider::current consumer nb = 1
Provider <symbols list begin>
    pgi = 00000019, Symbol19
    pgi = 00000190, Symbol190
    pgi = 00000191, Symbol191
    pgi = 00000192, Symbol192
    pgi = 00000193, Symbol193
    pgi = 00000194, Symbol194
    pgi = 00000195, Symbol195
    pgi = 00000196, Symbol196
    pgi = 00000197, Symbol197
    pgi = 00000198, Symbol198
    pgi = 00000199, Symbol199
Provider <symbols list end>.
address@hidden tsp]$

On peut rajouter autant de méthode de filtrage que l'on veut,
si on veut que tous les provider en dispose il faut le coder
dans  tsp/src/core/ctrl/tsp_default_glu.c

Par exemple un filtre du genre
"donne moi les N symboles max en partant du PGI=P".
ce qui permettrait de demander des "pages" de symboles
de taille raisonnable.

Sinon les GLU spécifiques peuvent se coder des filtrages
plus "malins" si ils ont des capacités particulières.

>
> Peut-être quand on fait une "new session" dans GDisp+...

Je dirais que gdisp+ devrait offrir quelques choix
au moment d'un new session:

0) Restauration d'une session sauvegardée dans "toto.xml"
1) Donnes-moi la liste de tous les symboles du "provider_url"
2) Donnes-moi une string et je te ramène tous les symboles
    "provider_url" qui matchent la string "filter_string"

et + tard les autres types de filtres

>
> Y aurait-il un moyen de récupérer juste le nombre de symboles (sans la
> table
> des symboles) histoire de savoir s'il faut afficher une progress-box pour
> faire patienter l'utilisateur le temps du rapatriement de la table ?

Pour l'instant aucune requête filtrée ne permet de faire ça.
J'avais projeté de faire une requête "MINIMAL+" qui fasse ça
mais ....
ben je l'ai pas encore codée...
si y'a des volontaires :))

--
Erk




reply via email to

[Prev in Thread] Current Thread [Next in Thread]