From: Ben Hutchings <bhutchings@solarflare.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: Andrea Shepard <andrea@persephoneslair.org>,
<linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
<khc@pm.waw.pl>, <davem@davemloft.net>, <mmarek@suse.cz>,
<jkosina@suse.cz>, <joe@perches.com>, <justinmattock@gmail.com>,
<gregkh@suse.de>, <alan@linux.intel.com>, <jdmason@kudzu.us>
Subject: RE: [07/22] Cyclades PC300 driver: ioctl() fixes for mixed 64/32-bit systems
Date: Mon, 30 Jan 2012 14:37:47 +0000 [thread overview]
Message-ID: <1327934267.5400.445.camel@deadeye> (raw)
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B6E3F@saturn3.aculab.com>
On Mon, 2012-01-30 at 11:44 +0000, David Laight wrote:
> > +struct pc300_net_stats {
> > + u64 rx_packets;
> ...
> > + u64 rx_compressed;
> > + u64 tx_compressed;
> > +};
> > +
> > typedef struct pc300stats {
> > int hw_type;
> > u32 line_on;
> > u32 line_off;
> > - struct net_device_stats gen_stats;
> > + /* Use this instead of net_device_stats, since passing
> > + * net_device_stats breaks 32-bit user processes on
> > 64-bit kernels,
> > + * and rtnetlink is unreasonably complicated just to get
> > + * some statistics.
> > + */
> > + struct pc300_net_stats net_stats;
> > falc_t te_stats;
> > } pc300stats_t;
>
> Since 'struct net_device_stats' looks like a common structure,
> maybe the 64bit version should be added in the same place??
[...]
It's called struct rtnl_link_stats64 and is already defined in
<linux/rtnetlink.h> (where it must remain).
This change doesn't seem to be a proper fix. If the ioctl interface to
this driver uses struct net_device_stats (which I didn't realise,
otherwise I would have left that structure exported from
<linux/netdevice.h>) then it should continue doing so to maintain
compatibility. The driver will have to fix up the outgoing structure
with the aid of is_compat_task().
If backward-compatibility is really not a concern for the driver then
this ioctl should be completely removed in favour of ethtool extended
stats.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
prev parent reply other threads:[~2012-01-30 14:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-30 2:49 [07/22] Cyclades PC300 driver: ioctl() fixes for mixed 64/32-bit systems Andrea Shepard
2012-01-30 11:44 ` David Laight
2012-01-30 14:37 ` Ben Hutchings
2012-01-30 14:37 ` Ben Hutchings [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=1327934267.5400.445.camel@deadeye \
--to=bhutchings@solarflare.com \
--cc=David.Laight@ACULAB.COM \
--cc=alan@linux.intel.com \
--cc=andrea@persephoneslair.org \
--cc=davem@davemloft.net \
--cc=gregkh@suse.de \
--cc=jdmason@kudzu.us \
--cc=jkosina@suse.cz \
--cc=joe@perches.com \
--cc=justinmattock@gmail.com \
--cc=khc@pm.waw.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=mmarek@suse.cz \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).