Linux ATA/IDE development
 help / color / mirror / Atom feed
From: Jon Masters <jonathan@jonmasters.org>
To: Matt Domsch <Matt_Domsch@dell.com>
Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
	Adrian Bunk <bunk@kernel.org>,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] ide: use MODULE_VERSION()
Date: Wed, 02 Jan 2008 00:46:30 -0500	[thread overview]
Message-ID: <1199252790.3300.77.camel@perihelion> (raw)
In-Reply-To: <20080102044620.GB10762@auslistsprd01.us.dell.com>


On Tue, 2008-01-01 at 22:46 -0600, Matt Domsch wrote:
> On Tue, Jan 01, 2008 at 09:32:36PM -0500, Jon Masters wrote:
> > On Tue, 2008-01-01 at 19:33 +0100, Bartlomiej Zolnierkiewicz wrote:
> > 
> > > On the second thought: maybe we will be better off with limiting
> > > MODULE_VERSION() to the device drivers and the IDE core module for now,
> > > and just removing all these private version numbers from host drivers
> > > (with one or two exceptions they are not printed or exported currently,
> > > moreover exceptions are the cases like stale version numbers from 199x)?
> > 
> > Things like checkpatch could help advise people to bump the version
> > number, but it's a bit iffy. Matt D. actually uses the special source
> > version modinfo for DKMS - which is different - but it makes me wonder
> > whether dynamically generating a version based on source SHA1 wouldn't
> > be a better idea in most cases than an outdated hard-coded one.
> 
> We've got that already, it's called 'srcversion', and it's a CRC32
> IIRC after some limited parsing to let it ignore whitspace changes and
> comment changes only.  
> 
> $ modinfo dell_rbu | grep version
> version:        3.2
> srcversion:     1D4815D7D6FBEE6612F3C18

Right. And I was referring to the is above (I forgot it's a CRC32 and
not a SHA1). But my point is why not codify some "policy" here with
respect to module versioning, rather than have the latter exist to
workaround the case that module versions aren't bumped manually.

(I'm not arguing to remove srcversion, just asking whether that might be
a better approach in general - perhaps allow a module to print this
version string at init time also, rather than just be in modinfo?)

Jon.



  reply	other threads:[~2008-01-02  5:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-01 17:40 [PATCH 1/3] ide: use MODULE_VERSION() Bartlomiej Zolnierkiewicz
2008-01-01 17:53 ` Adrian Bunk
2008-01-01 18:33   ` Bartlomiej Zolnierkiewicz
2008-01-02  2:32     ` Jon Masters
2008-01-02  4:46       ` Matt Domsch
2008-01-02  5:46         ` Jon Masters [this message]
2008-01-02 14:40           ` Stefan Richter
2008-01-02 22:45         ` Bartlomiej Zolnierkiewicz
2008-01-02 22:40           ` Matt Domsch

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=1199252790.3300.77.camel@perihelion \
    --to=jonathan@jonmasters.org \
    --cc=Matt_Domsch@dell.com \
    --cc=bunk@kernel.org \
    --cc=bzolnier@gmail.com \
    --cc=linux-ide@vger.kernel.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