From: "John W. Linville" <linville@tuxdriver.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: David Miller <davem@davemloft.net>,
sam@ravnborg.org, dsd@gentoo.org, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH/RFC v2] introduce ARCH_CAN_UNALIGNED_ACCESS Kconfig symbol
Date: Thu, 20 Mar 2008 18:03:48 -0400 [thread overview]
Message-ID: <20080320220348.GC1330@tuxdriver.com> (raw)
In-Reply-To: <1206048106.16475.161.camel@johannes.berg>
On Thu, Mar 20, 2008 at 10:21:46PM +0100, Johannes Berg wrote:
>
> > I think you're semantically testing the wrong thing.
> >
> > It's not if unaligned accesses are supported, it's if they are
> > efficient enough or not.
> >
> > For example, sparc64 fully handles unaligned accesses but taking the
> > trap to fix it up is slow. So sparc64 "can" handle unaligned
> > accesses, but whether we want to set this symbol or not is another
> > matter.
>
> Yeah, good point. Should I rename it to HAVE_EFFICIENT_UNALIGNED_ACCESS
> or similar? Or have it defined as some sort of number so you can make
> actually make tradeoffs? Like Dave Woodhouse suggested at some point to
> have get_unaligned() take an argument that indicates the probability...
Ugh...that sounds like premature optimization to me...
While I think Dave has a point, I don't think you should labor the word
choice too much. Try to document it as clearly as possible and hope
for the best -- I hear that the arch maintainers are top notch! :-)
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: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Cc: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
sam-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org,
dsd-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH/RFC v2] introduce ARCH_CAN_UNALIGNED_ACCESS Kconfig symbol
Date: Thu, 20 Mar 2008 18:03:48 -0400 [thread overview]
Message-ID: <20080320220348.GC1330@tuxdriver.com> (raw)
In-Reply-To: <1206048106.16475.161.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
On Thu, Mar 20, 2008 at 10:21:46PM +0100, Johannes Berg wrote:
>
> > I think you're semantically testing the wrong thing.
> >
> > It's not if unaligned accesses are supported, it's if they are
> > efficient enough or not.
> >
> > For example, sparc64 fully handles unaligned accesses but taking the
> > trap to fix it up is slow. So sparc64 "can" handle unaligned
> > accesses, but whether we want to set this symbol or not is another
> > matter.
>
> Yeah, good point. Should I rename it to HAVE_EFFICIENT_UNALIGNED_ACCESS
> or similar? Or have it defined as some sort of number so you can make
> actually make tradeoffs? Like Dave Woodhouse suggested at some point to
> have get_unaligned() take an argument that indicates the probability...
Ugh...that sounds like premature optimization to me...
While I think Dave has a point, I don't think you should labor the word
choice too much. Try to document it as clearly as possible and hope
for the best -- I hear that the arch maintainers are top notch! :-)
John
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-03-20 22:08 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-20 14:34 [PATCH/RFC] introduce ARCH_CAN_UNALIGNED_ACCESS Kconfig symbol Johannes Berg
2008-03-20 14:39 ` Will Newton
2008-03-20 14:39 ` Will Newton
2008-03-20 14:58 ` Johannes Berg
2008-03-20 14:58 ` Johannes Berg
2008-03-20 18:13 ` Sam Ravnborg
2008-03-20 18:35 ` Johannes Berg
2008-03-20 18:35 ` Johannes Berg
2008-03-20 18:39 ` [PATCH/RFC v2] " Johannes Berg
2008-03-20 18:45 ` [PATCH/RFC v3] " Johannes Berg
2008-03-20 18:45 ` Johannes Berg
2008-03-20 19:09 ` Harvey Harrison
2008-03-20 19:12 ` Johannes Berg
2008-03-20 19:41 ` Sam Ravnborg
2008-03-20 19:41 ` Sam Ravnborg
2008-03-20 19:50 ` [PATCH/RFC v4] introduce HAVE_UNALIGNED_ACCESS_SUPPORT " Johannes Berg
2008-03-20 19:50 ` Johannes Berg
2008-03-21 8:45 ` Ingo Molnar
2008-03-20 21:13 ` [PATCH/RFC v2] introduce ARCH_CAN_UNALIGNED_ACCESS " David Miller
2008-03-20 21:21 ` Johannes Berg
2008-03-20 21:21 ` Johannes Berg
2008-03-20 21:27 ` David Miller
2008-03-20 21:27 ` David Miller
2008-03-20 22:03 ` John W. Linville [this message]
2008-03-20 22:03 ` John W. Linville
2008-03-20 22:10 ` David Miller
2008-03-20 22:10 ` David Miller
2008-03-25 14:11 ` [PATCH/RFC v5] introduce HAVE_EFFICIENT_UNALIGNED_ACCESS " Johannes Berg
2008-04-02 10:24 ` Johannes Berg
2008-04-02 10:24 ` Johannes Berg
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=20080320220348.GC1330@tuxdriver.com \
--to=linville@tuxdriver.com \
--cc=davem@davemloft.net \
--cc=dsd@gentoo.org \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sam@ravnborg.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.