[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46A00B48CC54E4468EF6911F877AC4CA018D73BC@blrx3m10.blr.amer.dell.com>
Date: Sat, 23 Aug 2008 14:37:53 +0530
From: <Shyam_Iyer@...l.com>
To: <davem@...emloft.net>
Cc: <akpm@...ux-foundation.org>, <kxie@...lsio.com>,
<netdev@...r.kernel.org>, <open-iscsi@...glegroups.com>,
<linux-scsi@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<jgarzik@...ox.com>, <michaelc@...wisc.edu>,
<swise@...ngridcomputing.com>, <rdreier@...co.com>,
<daisyc@...ibm.com>, <wenxiong@...ibm.com>, <bhua@...ibm.com>,
<divy@...lsio.com>, <dm@...lsio.com>, <leedom@...lsio.com>
Subject: RE: [PATCH 4/4 2.6.28] cxgb3i - cxgb3i iscsi driver
> David Miller wrote:
> > Andrew Morton wrote:
> >I'd suggest that the version number just be removed. It becomes
> meaningless (and often misleading) once a driver is in the mainline
> kernel. People will >update the driver without changing the version
> number. Code external to the driver but which affects it can change.
>I totally disagree. I find it very useful when I get a debugging dump
from the user and they have no idea where their kernel came from nor can
figure
>out how to determine the kernel version.
>Sure it might sometimes not get updated for trivial patches that bypass
the maintainer, but the maintainer is always going to bump it after
non-trivial
>changes.
Exactly. And I am also suggesting that the driver version is not
standard among different vendors. So, why not get them generated in an
automatic build process.
Something like "kernel-version.driver-version". I am just imagining
here. The details can be worked out.
-Shyam
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists