From: "John W. Linville" <linville@tuxdriver.com>
To: Jean Tourrilhes <jt@hpl.hp.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCH 9/9] net_device: dont include wext bits if not required
Date: Thu, 26 Apr 2007 20:50:13 -0400 [thread overview]
Message-ID: <20070427005013.GA25332@tuxdriver.com> (raw)
In-Reply-To: <20070426165304.GC22576@bougret.hpl.hp.com>
On Thu, Apr 26, 2007 at 09:53:04AM -0700, Jean Tourrilhes wrote:
> On Tue, Apr 24, 2007 at 08:07:41PM +0200, Johannes Berg wrote:
> > This patch makes the wext bits in struct net_device depend on
> > CONFIG_WIRELESS_EXT.
> >
> > Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
>
> I personally would not do that. Having conditional fields in
> "struct net_device" is very bad, it's a sure way to crash on modules
> in some cases. If I remember well, Jeff Garzik has been fighting those
> over the years.
I'm not sure I understand the reasoning here. Without a doubt kernel
modules need to be built against the same configuration as the kernels
that are loading them. So, conditional component of net_device should
not cause crashes.
FWIW, there are other conditionally compiled portions of net_device
(NETPOLL, NET_POLL_CONTROLLER). I don't see the harm here.
John
--
John W. Linville
linville@tuxdriver.com
WARNING: multiple messages have this Message-ID (diff)
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
To: Jean Tourrilhes <jt-sDzT885Ts8HQT0dZR+AlfA@public.gmane.org>
Cc: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>,
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 9/9] net_device: dont include wext bits if not required
Date: Thu, 26 Apr 2007 20:50:13 -0400 [thread overview]
Message-ID: <20070427005013.GA25332@tuxdriver.com> (raw)
In-Reply-To: <20070426165304.GC22576-yAE0UhLNZJawPNPzzlOzwdBPR1lH4CV8@public.gmane.org>
On Thu, Apr 26, 2007 at 09:53:04AM -0700, Jean Tourrilhes wrote:
> On Tue, Apr 24, 2007 at 08:07:41PM +0200, Johannes Berg wrote:
> > This patch makes the wext bits in struct net_device depend on
> > CONFIG_WIRELESS_EXT.
> >
> > Signed-off-by: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
>
> I personally would not do that. Having conditional fields in
> "struct net_device" is very bad, it's a sure way to crash on modules
> in some cases. If I remember well, Jeff Garzik has been fighting those
> over the years.
I'm not sure I understand the reasoning here. Without a doubt kernel
modules need to be built against the same configuration as the kernels
that are loading them. So, conditional component of net_device should
not cause crashes.
FWIW, there are other conditionally compiled portions of net_device
(NETPOLL, NET_POLL_CONTROLLER). I don't see the harm here.
John
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
next prev parent reply other threads:[~2007-04-27 1:33 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-24 18:07 [PATCH 0/9] various wext cleanups Johannes Berg
2007-04-24 18:07 ` [PATCH 1/9] wext: move to net/wireless Johannes Berg
2007-04-24 18:07 ` [PATCH 2/9] wext: clean up how wext is called Johannes Berg
2007-04-24 18:07 ` Johannes Berg
2007-04-24 18:07 ` [PATCH 3/9] wext: remove dead debug code Johannes Berg
2007-04-24 18:07 ` Johannes Berg
2007-04-26 16:46 ` Jean Tourrilhes
2007-04-26 16:46 ` Jean Tourrilhes
2007-04-27 0:55 ` John W. Linville
2007-04-27 0:55 ` John W. Linville
2007-04-24 18:07 ` [PATCH 4/9] wext: remove options Johannes Berg
2007-04-24 18:07 ` Johannes Berg
2007-04-24 18:07 ` [PATCH 5/9] wext: cleanup early ioctl call path Johannes Berg
2007-04-24 18:07 ` Johannes Berg
2007-04-24 18:07 ` [PATCH 6/9] wext: move EXPORT_SYMBOL statements where they belong Johannes Berg
2007-04-24 18:07 ` Johannes Berg
2007-04-24 18:07 ` [PATCH 7/9] wext: reduce inline abuse Johannes Berg
2007-04-24 18:07 ` Johannes Berg
2007-04-26 16:50 ` Jean Tourrilhes
2007-04-26 17:03 ` Michael Buesch
2007-04-26 17:15 ` Jean Tourrilhes
2007-04-26 17:15 ` Jean Tourrilhes
2007-04-26 21:37 ` David Miller
2007-04-26 17:14 ` Johannes Berg
2007-04-26 17:14 ` Johannes Berg
2007-04-24 18:07 ` [PATCH 8/9] wext: misc code cleanups Johannes Berg
2007-04-24 18:07 ` Johannes Berg
2007-04-24 18:07 ` [PATCH 9/9] net_device: dont include wext bits if not required Johannes Berg
2007-04-24 18:07 ` Johannes Berg
2007-04-26 16:53 ` Jean Tourrilhes
2007-04-26 16:53 ` Jean Tourrilhes
2007-04-26 17:08 ` Johannes Berg
2007-04-27 0:50 ` John W. Linville [this message]
2007-04-27 0:50 ` John W. Linville
2007-04-26 10:15 ` [PATCH 0/9] various wext cleanups Johannes Berg
2007-04-26 10:15 ` Johannes Berg
2007-04-26 10:18 ` David Miller
2007-04-26 11:05 ` Johannes Berg
2007-04-26 11:05 ` Johannes Berg
2007-04-26 10:19 ` David Miller
2007-04-26 10:19 ` David Miller
2007-04-27 1:12 ` John W. Linville
2007-04-27 1:12 ` John W. Linville
2007-04-27 2:36 ` David Miller
2007-04-27 3:48 ` David Miller
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=20070427005013.GA25332@tuxdriver.com \
--to=linville@tuxdriver.com \
--cc=davem@davemloft.net \
--cc=johannes@sipsolutions.net \
--cc=jt@hpl.hp.com \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@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 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.