All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@osdl.org>
To: James Ketrenos <jketreno@linux.intel.com>
Cc: yi.zhu@intel.com, netdev@vger.kernel.org,
	"John W. Linville" <linville@tuxdriver.com>
Subject: Re: [PATCH 12/18] ipw2200: version string rework
Date: Mon, 17 Apr 2006 09:37:45 -0700	[thread overview]
Message-ID: <20060417093745.6e76b957@localhost.localdomain> (raw)
In-Reply-To: <4443C2EE.6030302@linux.intel.com>

On Mon, 17 Apr 2006 11:31:42 -0500
James Ketrenos <jketreno@linux.intel.com> wrote:

> Stephen Hemminger wrote:
> > On Thu, 13 Apr 2006 17:20:34 +0800
> > Zhu Yi <yi.zhu@intel.com> wrote:
> > 
> > 
> >>Added version string fields so the version string indicates what is
> >>configured (ie, you'll see 1.1.1kpmd if you are using a GIT snapshot
> >>(Kernel.. previously -git), promiscuous (p), monitor (m), debug (d) build.
> > 
> > 
> > No, this is completely the wrong direction.
> > 
> > Stop with the config option nonsense. It makes it impossible for linux distributions
> > and others that want to ship one kernel and modules.
> 
> How does it make it impossible for someone to ship one kernel?
> 
> There are are various configuration options to enable, some of which are
> experimental and/or unstable, some add code and/or impact performance
> when enabled, etc.  Not all users want all features.
> 
> Easily determining what is enabled in the driver is a requirement.
> 
> The distributors should default to not enabling any feature that does
> not default to =y or =m in Kconfig.  In the default configuration, there
> shouldn't be any post-fix fields appended to the version string.  If
> there is, we need to either fix the version string or the default
> Kconfig setting.
> 
> Is there an alternative method for quickly and easily determining what
> all features are enabled in a module--even if the module isn't loaded?
> We didn't see one, and using the fields post-fixed to the version string
> has quickly resolved various support issues.
> 
> Thanks,
> James

The version string is good idea, it is just the NxM complexity of possibilities
that gets nasty.  Also, is this a permanent fixture of these drivers, or just
some transitional stage as new features get added that aren't stable yet?

      reply	other threads:[~2006-04-17 16:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-13  9:20 [PATCH 12/18] ipw2200: version string rework Zhu Yi
2006-04-13 17:28 ` Stephen Hemminger
2006-04-17 16:31   ` James Ketrenos
2006-04-17 16:37     ` Stephen Hemminger [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=20060417093745.6e76b957@localhost.localdomain \
    --to=shemminger@osdl.org \
    --cc=jketreno@linux.intel.com \
    --cc=linville@tuxdriver.com \
    --cc=netdev@vger.kernel.org \
    --cc=yi.zhu@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.