From: "Paul Albrecht" <palbrecht@qwest.net>
To: jonathan@jonmasters.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: yet another c language cross-reference for linux
Date: Fri, 28 Oct 2005 16:12:49 -0500 [thread overview]
Message-ID: <000701c5dc04$5b31d6e0$4bc80443@oemcomputer> (raw)
In-Reply-To: <35fb2e590510280242h53c8c444t8d285198d7c6730f@mail.gmail.com>
From: "Jon Masters" <jonmasters@gmail.com>
Sent: Friday, October 28, 2005 4:42 AM
> On 10/27/05, Paul Albrecht <palbrecht@qwest.net> 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
prev parent reply other threads:[~2005-10-28 21:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-27 12:27 Paul Albrecht
2005-10-27 15:22 ` Jon Masters
2005-10-27 15:26 ` Randy.Dunlap
2005-10-27 22:12 ` Paul Albrecht
2005-10-28 9:42 ` Jon Masters
2005-10-28 21:12 ` Paul Albrecht [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000701c5dc04$5b31d6e0$4bc80443@oemcomputer' \
--to=palbrecht@qwest.net \
--cc=jonathan@jonmasters.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome