On Mon, 2011-08-01 at 19:38 +0200, Stefan Richter wrote:
> On Aug 01 Dan Williams wrote:
> > On Sat, Jul 30, 2011 at 9:55 AM, Stefan Richter
> > <stefanr@xxxxxxxxxxxxxxxxx> wrote:
> > > On Jul 29 Dan Williams wrote:
> > >> @@ -540,7 +548,8 @@ static __init int isci_init(void)
> > >> {
> > >> int err;
> > >>
> > >> - pr_info("%s: Intel(R) C600 SAS Controller Driver\n", DRV_NAME);
> > >> + pr_info("%s: Intel(R) C600 SAS Controller Driver - version %s\n",
> > >> + DRV_NAME, DRV_VERSION);
> > >
> > > Why? There is already a version number. Like 2.6.39, 3.0, 3.1.
> >
> > This is for tracking driver versions across distributions and driver
> > update packages as they sync with upstream on different cadences.
>
> If they "synced with upstream", they had just the kernel version number.
> You mean they "backport new drivers from current upstream into their branch
> with an old core".
This isn't good enough for distros, who often pretend to be on one
kernel version yet have the driver backported from another.
> The mainline doesn't generally carry stubs and macros that are only there
> for backporting. Well, I guess SCSI drivers are different in that regard.
This is hardly a stub for a backport. It's a printk printing the
version. At least 25% of drivers seem to do this (not that I entirely
approve ... it does tend to clutter the boot sequence a bit)
The whole reason for MODULE_VERSION() is to mark this correctly.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
