From: "Grant Likely" <grant.likely@secretlab.ca>
To: "David H. Lynch Jr." <dhlii@dlasys.net>
Cc: linuxppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: Re: Kernel symbol version history
Date: Wed, 5 Dec 2007 09:49:35 -0700 [thread overview]
Message-ID: <fa686aa40712050849j2da48e9eq3e46b20bc1d72b45@mail.gmail.com> (raw)
In-Reply-To: <4756CF15.2090805@dlasys.net>
On 12/5/07, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> This might be slightly OT here, but would anyone know where there
> might be a reference that indicates at precisely what version a given
> symbol either appeared or disappeared within the Linux kernel ?
>
> As an example if a driver is supposed to work for 2.6 and 2.4 and
> uses sysfs, or cdev, or alloc_chr_dev_region or ...
> How can one tell at what point that api or symbol appeared so that
> the proper conditionals appear within the driver.
the 'gitk' tool allows you to search for the addition or removal of a
string. You
>
> The last one that bit me was I made a collection of casting changes
> to address 64bit vs. 32bit targets, and found that using the C99 fixed
> size types - uint32_t, ... made life much more pleasant, after putting
> them I nobody else could build because uintptr_t did not appear until
> 2.6.24, and I still have not figured out exactly when uint32_t etc.
> appeared.
>
> I would think there ought to be some resource besides group memory
> to look this up ?
> Is there a way to use git to look back through the history of a
> symbol rather than a file.
grant@trillian:~/hacking/linux-2.6$ grep "uint32_t" include/* -r | grep typedef
include/linux/types.h:typedef __u32 uint32_t;
grant@trillian:~/hacking/linux-2.6$ git log -p include/linux/types.h | vim -
(Search for the string uint32_t)
Looks like it was there before Linus started using git.
>
>
>
> --
> Dave Lynch DLA Systems
> Software Development: Embedded Linux
> 717.627.3770 dhlii@dlasys.net http://www.dlasys.net
> fax: 1.253.369.9244 Cell: 1.717.587.7774
> Over 25 years' experience in platforms, languages, and technologies too numerous to list.
>
> "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
> Albert Einstein
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
next prev parent reply other threads:[~2007-12-05 16:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-05 16:17 Kernel symbol version history David H. Lynch Jr.
2007-12-05 16:49 ` Grant Likely [this message]
2007-12-05 17:07 ` Jean-Christophe Dubois
2007-12-09 16:41 ` David H. Lynch Jr.
2007-12-06 13:08 ` David Woodhouse
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=fa686aa40712050849j2da48e9eq3e46b20bc1d72b45@mail.gmail.com \
--to=grant.likely@secretlab.ca \
--cc=dhlii@dlasys.net \
--cc=linuxppc-embedded@ozlabs.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;
as well as URLs for NNTP newsgroup(s).