I have written another cross-referencing tool for the c language because I
have been dissatisfied with existing tools such as ctags and lxr. I'd like
to get some feedback to determine whether other programmers find the program
useful so I'm making the program script and a database for the linux-2.4.31
kernel available for download from my web site http://www.pjalbrecht.com. If you're
interested, download the program script and linux database from my web site;
try the program; and send me your comments. I'm particularly interested in
comparing my approach with other cross-reference programs like ctags and
lxr. I don't usually read the linux-kernel mailing list so please cc me if
you answer/comment to the list in response to this message.
Paul Albrecht
On 10/27/05, Paul Albrecht <[email protected]> wrote:
> I have written another cross-referencing tool for the c language because I
> have been dissatisfied with existing tools such as ctags and lxr.
Ok.
> I'd like to get some feedback to determine whether other programmers
> find the program useful
It seems to be in its very early stages now. I can barely navigate the
2.4.31 source and it doesn't offer anything like the functionality of
lxr. But if you want to, perhaps it's worthwhile developing it further
and releasing it.
Your README file suggests that LXR fails because it requires a
webserver. Personally, I've never seen that to be an issue and find it
very very useful indeed (although it has limitations and doesn't
always index every symbol I would want to lookup), especially with
coywolf keeping an up-to-date lxr for 2.6. Mel Gorman used it for his
ULVMM book and I'm sure others are using LXR extensively - so it might
be worth extending that.
I'd love it if vendors would actually index their kernels with LXR.
Jon.
On Thu, 27 Oct 2005, Jon Masters wrote:
> On 10/27/05, Paul Albrecht <[email protected]> wrote:
>
> > I have written another cross-referencing tool for the c language because I
> > have been dissatisfied with existing tools such as ctags and lxr.
>
> Ok.
>
> > I'd like to get some feedback to determine whether other programmers
> > find the program useful
>
> It seems to be in its very early stages now. I can barely navigate the
> 2.4.31 source and it doesn't offer anything like the functionality of
> lxr. But if you want to, perhaps it's worthwhile developing it further
> and releasing it.
Maybe this is a meta-comment, but I would find it useful
if xvr script (source) files contained (used) some indentation.
I don't see any.
> Your README file suggests that LXR fails because it requires a
> webserver. Personally, I've never seen that to be an issue and find it
> very very useful indeed (although it has limitations and doesn't
> always index every symbol I would want to lookup), especially with
> coywolf keeping an up-to-date lxr for 2.6. Mel Gorman used it for his
> ULVMM book and I'm sure others are using LXR extensively - so it might
> be worth extending that.
>
> I'd love it if vendors would actually index their kernels with LXR.
--
~Randy
From: "Jon Masters" <[email protected]>
Sent: Thursday, October 27, 2005 10:22 AM
> On 10/27/05, Paul Albrecht <[email protected]> wrote:
>
> > I have written another cross-referencing tool for the c language because I
> > have been dissatisfied with existing tools such as ctags and lxr.
>
> Ok.
>
> > I'd like to get some feedback to determine whether other programmers
> > find the program useful
>
> It seems to be in its very early stages now. I can barely navigate the
> 2.4.31 source and it doesn't offer anything like the functionality of
> lxr. But if you want to, perhaps it's worthwhile developing it further
> and releasing it.
>
> Your README file suggests that LXR fails because it requires a
> webserver. Personally, I've never seen that to be an issue and find it
> very very useful indeed (although it has limitations and doesn't
> always index every symbol I would want to lookup), especially with
> coywolf keeping an up-to-date lxr for 2.6. Mel Gorman used it for his
> ULVMM book and I'm sure others are using LXR extensively - so it might
> be worth extending that.
>
> I'd love it if vendors would actually index their kernels with LXR.
>
> Jon.
I simply disagree that the lxr user interface is useable for code study. The
problem with the lxr interface stems from the author's decision to use basic
html for query responses to the database; this severely constrains the
user interface. A better approach would be to use dynamic html or provide
the database access as a service and write the user interface as a mozilla
client application.
Actually, I'm uninterested in data presentation issues or I'd make the
changes myself. What's really different about my cross-reference application
is that the database is generated using compiler output. As a result,
the cross-reference database is coherent in the sense that its derived from
a particular kernel compilation. The advantage of this approach is that it
reduces the size and ensures the integrity of the cross-reference database.
Paul Albrecht
On 10/27/05, Paul Albrecht <[email protected]> wrote:
> I simply disagree that the lxr user interface is useable for code study.
Although many people use it for that, so it must be useable.
> The problem with the lxr interface stems from the author's decision to use basic
> html for query responses to the database;
You don't cite an example of where this fails. The only practical
limitation I've seen in lxr is that it doesn't index certain symbols
which arrive through complex defines (and this is a place where asking
the compiler for help *is* useful).
> Actually, I'm uninterested in data presentation issues or I'd make the
> changes myself. What's really different about my cross-reference application
> is that the database is generated using compiler output.
That is a good idea.
> the cross-reference database is coherent in the sense that its derived from
> a particular kernel compilation. The advantage of this approach is that it
> reduces the size and ensures the integrity of the cross-reference database.
coherency is the wrong term here. The database in both should be as
they're derived from a static kernel tree (if not, then there are
other problems). But I'll agree that your idea (I haven't yet checked
the implementation - it was very short) in theory is a good one. LXR
still works great though :-)
Jon.
From: "Jon Masters" <[email protected]>
Sent: Friday, October 28, 2005 4:42 AM
> On 10/27/05, Paul Albrecht <[email protected]> wrote:
>
> > I simply disagree that the lxr user interface is useable for code study.
>
> Although many people use it for that, so it must be useable.
I don't think lxr is a suitable tool for code study, but if it works for you
that's ok with me.
>
> > The problem with the lxr interface stems from the author's decision to use basic
> > html for query responses to the database;
>
> You don't cite an example of where this fails. The only practical
> limitation I've seen in lxr is that it doesn't index certain symbols
> which arrive through complex defines (and this is a place where asking
> the compiler for help *is* useful).
>
> > Actually, I'm uninterested in data presentation issues or I'd make the
> > changes myself. What's really different about my cross-reference application
> > is that the database is generated using compiler output.
>
> That is a good idea.
>
> > the cross-reference database is coherent in the sense that its derived from
> > a particular kernel compilation. The advantage of this approach is that it
> > reduces the size and ensures the integrity of the cross-reference database.
>
> coherency is the wrong term here. The database in both should be as
> they're derived from a static kernel tree (if not, then there are
> other problems). But I'll agree that your idea (I haven't yet checked
> the implementation - it was very short) in theory is a good one. LXR
> still works great though :-)
>
I'm defining coherency in the sense that the database is derived from a
particular kernel configuration; that is, I'm only considering files compiled or
included for a particular kernel compilation. That's a good thing or a bad thing
depending on what you're trying to accomplish. If, for example, you're only
interested in an i386 kernel configuration, then you're probably not interested
in files and includes for ppc, s390, etc.
Paul Albrecht