lxr.xensource.com-lxr

lxr.xensource.com-lxr

[ted]

Re: http://lxr.xensource.com/lxr/

This index to Xen source code was apparently loaded into a general 
hypertext cross-referencing tool. This tool was apparently written in perl..

" The Linux Cross-Reference project is the testbed application of a 
general hypertext cross-referencing tool. (Or the other way around.)

The main goal of the project is to create a versatile cross-referencing 
tool for relatively large code repositories. The project is based on 
stock web technology, so the codeview client may be chosen from the full 
range of available web browsers. On the server side, any Unix-based web 
server with cgi-script capability should do nicely.'

Some "reservations" were expressed by the authors regarding the display 
of "source code".  

I notice the entire source code is numbered and one can reference that 
code by number and module being extensively cross-referenced.  What 
exactly are the "reservations" expressed -- something to do with "sloppy 
labelling" being less than a "full code parser".

Do the Xen developers make frequent use of this cross reference tool?
Where would I obtain the perl code for this general hypertext 
cross-referencing tool?
Would it not be possible to create a hierarchical tree structure of Xen 
by parsing this display presented by the general hypertext 
cross-referencing tool???

Thanks -- Ted

Re: lxr.xensource.com-lxr

[James Bulpin]

On Fri, 1 Apr 2005, ted wrote:

:>Where would I obtain the perl code for this general hypertext
:>cross-referencing tool?

We use LXR version 0.3. This can still be found at http://lxr.linux.no/
(which is where your quote came from). There is a newer version available
that uses a database backend for the xref database. I think the "general
hypertext cross-referencing tool" refers to libraries within the LXR
package rather than a separate tool.

:>Would it not be possible to create a hierarchical tree structure of Xen
:>by parsing this display presented by the general hypertext
:>cross-referencing tool???

Isn't that what LXR does - or have I missed the point?

Regards,

James

Re: lxr.xensource.com-lxr

[Ted Hilts]

James:

Kind of you to reply James.

Several months ago I queried the list for a hierarchical tree of 
functions associated with the execution of Xen and was told there was no 
such thing.  

Cross Referencing is nice but is not a hierarchical tree like display of 
 the dependent order of execution of all functions.  Essentially there 
is the "main" module which calls subordinate modules which in turn call 
their subordinante modules and the entire scenario can be graphically 
displayed  in connecting lines to box like structures that identify the 
function called and it's purpose and data passed back and forth if any. 
 The graphic is most often layered with the top layer being the main 
routine, the next layer being the routines called by the main routine, 
the next layer down  has the routines called by the second layer and so 
on.  This graphic gives a good idea of the software architecturee and is 
invaluable if there are parallel streams of execution.  Often, software 
development builds stubs for unwritten code and works from the top down 
according to a design plan in the graphical form I have explained.

There are many brilliant code hackers that only need a starting point in 
the code and they are away.  They build (compile and link) the code with 
a debugger, make notes, and change (add, delete, modify) on that basis 
until they get the required results from their testing.  There is no 
question they are good at this as they generally live and breath every 
day doing this. But these sort in general may never have a comprehensive 
or top level down appreciation for the code or it's design. And that is 
the exact reason why such a graphic as explained above is needed.  A 
"data dictionary" defining words and processes is also of great benefit. 
As soon as those brilliant hackers disappear into the land of 
opportunity and advancement no one understands the code or the overall 
integration of functionality because there is no such graphic.  The Open 
and sometimes Free Software development would really benefit from this 
kind of documentation.  Then , just maybe, people like me could jump in 
and really help.  My experience in IT for many years (now retired) has 
taught me that there is nothing worse than jumping into a development 
group of these kind of hackers that know "their" way around the code 
"blind-folded" but cannot or will not pass that knowledge on to the 
"newbie" in the group in a documented way that facilitates rapid catchup 
to the other members in the group.

I'm not accusing anyone of anything in the Xen development group -- I am 
simply answering your question "Isn't that what LXR does - or have I 
missed the point?"  You tell me as you obviously know more about LXR 
than I currently know.  I have been away from software development now 
for many years and things have radically changed so I am still in the 
catchup mode and have to ask questions which are at times very 
elementary like my question about GRUB.  I used to code my brains out in 
C and worked with other languages, Operating Systems, SQL and databases 
and that sort of thing.  Now there is python matured, java this and java 
that, PHP in wide use, and so on.  For another example, MySQL apparently 
has matured into a professional database technology where before I 
retired it was a laughing matter to use MySQL.  So I have a lot of 
catching up to do and I'm on my way.

Thanks again for your email, posted in [Xen-devel] because it is a 
development issue.

Thanks, Ted


James Bulpin wrote:

>On Fri, 1 Apr 2005, ted wrote:
>
>:>Where would I obtain the perl code for this general hypertext
>:>cross-referencing tool?
>
>We use LXR version 0.3. This can still be found at http://lxr.linux.no/
>(which is where your quote came from). There is a newer version available
>that uses a database backend for the xref database. I think the "general
>hypertext cross-referencing tool" refers to libraries within the LXR
>package rather than a separate tool.
>
>:>Would it not be possible to create a hierarchical tree structure of Xen
>:>by parsing this display presented by the general hypertext
>:>cross-referencing tool???
>
>Isn't that what LXR does - or have I missed the point?
>
>Regards,
>
>James
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>
>  
>

Re: lxr.xensource.com-lxr

[James Bulpin]

On Fri, 1 Apr 2005, Ted Hilts wrote:

:>Cross Referencing is nice but is not a hierarchical tree like display of
:> the dependent order of execution of all functions.  Essentially there
:>is the "main" module which calls subordinate modules which in turn call
:>their subordinante modules and the entire scenario can be graphically
:>displayed  in connecting lines to box like structures that identify the
:>function called and it's purpose and data passed back and forth if any.

Ah, a graphical representation of the call graph?

:> The graphic is most often layered with the top layer being the main
:>routine, the next layer being the routines called by the main routine,
:>the next layer down  has the routines called by the second layer and so
:>on.  This graphic gives a good idea of the software architecturee and is
:>invaluable if there are parallel streams of execution.  Often, software
:>development builds stubs for unwritten code and works from the top down
:>according to a design plan in the graphical form I have explained.

I suspect that for such a graphic to be truly useful it would have to be
(at least partially) manually created. The event driven nature of an
system software is such that the call graph is not a nice, clean tree of
multiple separate layers. An additional problem is that static analysis of
the code would not give the full call graph because of things like
dynamically registered handlers, callbacks etc..

So I guess there are two possible documents that fit what you are looking
for:

 - a high level architecture overview - we generally rely on the papers
   written about Xen for this
 - a low level call graph representation, automatically generated, i.e.
   LXR++

I'm happy to take suggestions for tools for the latter which we may be
able to host in a similar way to the existing LXR.

:>I am simply answering your question "Isn't that what LXR does - or have
:>I missed the point?"

Thanks. I hadn't quite unerstood what you meant "tree" - I assumed
directory tree.

James