All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <randy.dunlap@oracle.com>
To: jt@hpl.hp.com
Cc: Johannes Berg <johannes@sipsolutions.net>,
	Jouni Malinen <jkm@devicescape.com>,
	Michael Buesch <mb@bu3sch.de>,
	linux-wireless@vger.kernel.org, netdev <netdev@vger.kernel.org>,
	Jeff Garzik <jgarzik@pobox.com>, Dan Williams <dcbw@redhat.com>
Subject: Re: wireless extensions vs. 64-bit architectures
Date: Thu, 8 Mar 2007 14:17:56 -0800	[thread overview]
Message-ID: <20070308141756.efdfd6da.randy.dunlap@oracle.com> (raw)
In-Reply-To: <20070308221128.GA24884@bougret.hpl.hp.com>

On Thu, 8 Mar 2007 14:11:28 -0800 Jean Tourrilhes wrote:

> On Thu, Mar 08, 2007 at 08:40:01PM +0100, Johannes Berg wrote:
> > On Thu, 2007-03-08 at 11:34 -0800, Jouni Malinen wrote:
> > 
> > > Yes, workaround in just iwlib is not enough. If the only possible
> > > solution is user space workaround, it better be documented (and
> > > communicated to maintainers of user space apps) well so that
> > > all user space programs not using iwlib can be modified, too.
> > 
> > The more I think about it the worse it gets. Think about wireless events
> > where both 32 and 64-bit userspace programs may be listening... That
> > means we can't even fix it in the kernel without breaking something.
> > 
> > johannes
> 
> 	This is exactly what I was pointing out earlier. Well,
> actually, there may be ways of fixing it in the kernel, but that would
> be real ugly, and I don't want to go there.
> 
> 	I've just released wireless_tools.29.pre15.tar.gz. This is
> supposed to include a "band-aid" for that problem. To the best of my
> knowledge, it should catch the problem and not introduce false
> positive. I would be glad if you guys would have a quick look into it,
> because obviously I can't test it.
> 
> 	Now, about the way forward...
> 	First possiblity, we could stick with this band-aid
> permanently.
> 
> 	Second possiblity : we do the right thing and plan a API
> change to return struct always aligned on 32 bits. This way, when we
> get 128 bit processor, we don't have to add another band aid ;-)
> 	It would work like the ESSID changeover. We pick a WE version
> changeover. We introduce userspace that can deal with before and
> after. After 1 or 2 years, we flip the switch. After another 1 or 2
> years, we get rid of backward compatibility.
> 
> 	Third possibility : we declare 32 bit userspace on 64 bit
> kernel as not supported and advise users to get a 64 bit
> userspace. The number of bug report on that issue would suggest that
> very few users are in this case.

I think that this is not actually an option since
powerpc64 is all 32-bit userspace.
Maybe some other arch-es are like this also (?).

> 	I know the userspace guys will hate (1) and hate even more (2).
> 
> 	Regards,
> 
> 	Jean



---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

WARNING: multiple messages have this Message-ID (diff)
From: Randy Dunlap <randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
To: jt-sDzT885Ts8HQT0dZR+AlfA@public.gmane.org
Cc: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>,
	Jouni Malinen <jkm-r/za7OOdgF0ztatW0fm/fQ@public.gmane.org>,
	Michael Buesch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	netdev <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Jeff Garzik <jgarzik-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>,
	Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: wireless extensions vs. 64-bit architectures
Date: Thu, 8 Mar 2007 14:17:56 -0800	[thread overview]
Message-ID: <20070308141756.efdfd6da.randy.dunlap@oracle.com> (raw)
In-Reply-To: <20070308221128.GA24884-yAE0UhLNZJawPNPzzlOzwdBPR1lH4CV8@public.gmane.org>

On Thu, 8 Mar 2007 14:11:28 -0800 Jean Tourrilhes wrote:

> On Thu, Mar 08, 2007 at 08:40:01PM +0100, Johannes Berg wrote:
> > On Thu, 2007-03-08 at 11:34 -0800, Jouni Malinen wrote:
> > 
> > > Yes, workaround in just iwlib is not enough. If the only possible
> > > solution is user space workaround, it better be documented (and
> > > communicated to maintainers of user space apps) well so that
> > > all user space programs not using iwlib can be modified, too.
> > 
> > The more I think about it the worse it gets. Think about wireless events
> > where both 32 and 64-bit userspace programs may be listening... That
> > means we can't even fix it in the kernel without breaking something.
> > 
> > johannes
> 
> 	This is exactly what I was pointing out earlier. Well,
> actually, there may be ways of fixing it in the kernel, but that would
> be real ugly, and I don't want to go there.
> 
> 	I've just released wireless_tools.29.pre15.tar.gz. This is
> supposed to include a "band-aid" for that problem. To the best of my
> knowledge, it should catch the problem and not introduce false
> positive. I would be glad if you guys would have a quick look into it,
> because obviously I can't test it.
> 
> 	Now, about the way forward...
> 	First possiblity, we could stick with this band-aid
> permanently.
> 
> 	Second possiblity : we do the right thing and plan a API
> change to return struct always aligned on 32 bits. This way, when we
> get 128 bit processor, we don't have to add another band aid ;-)
> 	It would work like the ESSID changeover. We pick a WE version
> changeover. We introduce userspace that can deal with before and
> after. After 1 or 2 years, we flip the switch. After another 1 or 2
> years, we get rid of backward compatibility.
> 
> 	Third possibility : we declare 32 bit userspace on 64 bit
> kernel as not supported and advise users to get a 64 bit
> userspace. The number of bug report on that issue would suggest that
> very few users are in this case.

I think that this is not actually an option since
powerpc64 is all 32-bit userspace.
Maybe some other arch-es are like this also (?).

> 	I know the userspace guys will hate (1) and hate even more (2).
> 
> 	Regards,
> 
> 	Jean



---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

  reply	other threads:[~2007-03-08 22:27 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-06  1:27 wireless extensions vs. 64-bit architectures Johannes Berg
2007-03-06 14:31 ` Johannes Berg
2007-03-06 17:13 ` Jean Tourrilhes
2007-03-06 18:43   ` Michael Buesch
2007-03-06 18:43     ` Michael Buesch
2007-03-07  1:42     ` Jean Tourrilhes
2007-03-07  1:42       ` Jean Tourrilhes
2007-03-07  2:03     ` Jean Tourrilhes
2007-03-08 14:39       ` Johannes Berg
2007-03-08 14:39         ` Johannes Berg
2007-03-08 16:51         ` Johannes Berg
2007-03-08 16:51           ` Johannes Berg
2007-03-08 17:37         ` Johannes Berg
2007-03-08 17:37           ` Johannes Berg
2007-03-08 18:49         ` Jean Tourrilhes
2007-03-08 19:08           ` Johannes Berg
2007-03-08 19:13             ` Jean Tourrilhes
2007-03-08 19:13               ` Jean Tourrilhes
2007-03-08 19:23               ` Johannes Berg
2007-03-08 19:27           ` Johannes Berg
2007-03-08 19:27             ` Johannes Berg
2007-03-08 19:34             ` Jouni Malinen
2007-03-08 19:40               ` Johannes Berg
2007-03-08 19:40                 ` Johannes Berg
2007-03-08 22:11                 ` Jean Tourrilhes
2007-03-08 22:11                   ` Jean Tourrilhes
2007-03-08 22:17                   ` Randy Dunlap [this message]
2007-03-08 22:17                     ` Randy Dunlap
2007-03-08 22:30                     ` Jean Tourrilhes
2007-03-08 22:30                       ` Jean Tourrilhes
2007-03-08 22:36                       ` Johannes Berg
2007-03-08 22:36                         ` Johannes Berg
2007-03-08 22:34                     ` David Miller
2007-03-08 22:34                       ` David Miller
2007-03-08 22:49                     ` Pavel Roskin
2007-03-08 22:22                   ` Johannes Berg
2007-03-08 22:22                     ` Johannes Berg
2007-03-08 22:36                     ` Jean Tourrilhes
2007-03-08 22:36                       ` Jean Tourrilhes
2007-03-08 22:35                   ` Johannes Berg
2007-03-08 22:35                     ` Johannes Berg
2007-03-09 21:35                     ` Jean Tourrilhes
2007-03-09 23:19                       ` Jouni Malinen
2007-03-09 23:19                         ` Jouni Malinen
2007-03-10  1:01                         ` Jean Tourrilhes
2007-03-10  1:01                           ` Jean Tourrilhes
2007-03-11 17:40                       ` Johannes Berg
2007-03-11 17:40                         ` Johannes Berg
2007-03-11 20:11                         ` Ulrich Kunitz
2007-03-11 20:11                           ` Ulrich Kunitz
2007-03-11 20:30                           ` Michael Buesch
2007-03-11 20:30                             ` Michael Buesch
2007-03-12 17:56                         ` Jean Tourrilhes
2007-03-12 17:56                           ` Jean Tourrilhes
2007-03-12 18:21                           ` Jouni Malinen
2007-03-12 20:34                             ` Jean Tourrilhes
2007-03-12 20:34                               ` Jean Tourrilhes
2007-03-13 19:42                           ` Johannes Berg
2007-03-13 19:42                             ` Johannes Berg
2007-03-13 21:30                             ` Jean Tourrilhes
2007-03-13 21:30                               ` Jean Tourrilhes

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=20070308141756.efdfd6da.randy.dunlap@oracle.com \
    --to=randy.dunlap@oracle.com \
    --cc=dcbw@redhat.com \
    --cc=jgarzik@pobox.com \
    --cc=jkm@devicescape.com \
    --cc=johannes@sipsolutions.net \
    --cc=jt@hpl.hp.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mb@bu3sch.de \
    --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.