From: Michael Buesch <mb@bu3sch.de>
To: Ulrich Kunitz <kune@deine-taler.de>
Cc: Johannes Berg <johannes@sipsolutions.net>,
jt@hpl.hp.com, Jouni Malinen <jkm@devicescape.com>,
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: Sun, 11 Mar 2007 21:30:05 +0100 [thread overview]
Message-ID: <200703112130.05717.mb@bu3sch.de> (raw)
In-Reply-To: <20070311201148.GA25938@p15091797.pureserver.info>
On Sunday 11 March 2007 21:11, Ulrich Kunitz wrote:
> > I'm still not convinced that papering over the problem in userspace is a
> > real solution.
> >
> > johannes
>
> Just my 2 cents. I support this. What are the options? I see only
> two:
>
> 1. Use different magic numbers for 32 bit and 64 bit structures. A
> flag is an alternative, but will be more difficult to debug.
> Generation of the magic should be easy, use sizeof(unsigned
> long) as test. User space has to care than for the rest.
>
> 2. Make the data representation identical in 32 bit and 64 bit.
>
> This shouldn't be to difficult, if only u8, u16 and u32 types
> are used.
> Pointers should be given as offsets.
Offsets to what?
> If necessary
> align and/or packed attributes could be used.
>
> If the kernel interface can be changed, I vote for option 2,
> because user space has then to deal with a unique data layout.
> If the wext kernel interface cannot be changed to maintain
> backward compatibility, then I have to admit band-aids in user
> space are needed. However cfg80211 must not suffer from the same issues.
All your suggestions break the userspace ABI on all machines,
which is a thing we _really_ want to avoid.
The right fix is to have a compatibility wrapper in the kernel,
but it turns out to be hard to implement. I don't think we want
to change the structures layout and break ABI.
--
Greetings Michael.
WARNING: multiple messages have this Message-ID (diff)
From: Michael Buesch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
To: Ulrich Kunitz <kune-hUSrv6EASfkEnNRfnnE9gw@public.gmane.org>
Cc: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>,
jt-sDzT885Ts8HQT0dZR+AlfA@public.gmane.org,
Jouni Malinen <jkm-r/za7OOdgF0ztatW0fm/fQ@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: Sun, 11 Mar 2007 21:30:05 +0100 [thread overview]
Message-ID: <200703112130.05717.mb@bu3sch.de> (raw)
In-Reply-To: <20070311201148.GA25938-WhJF3imHnk+bHbQv0o6mQ2hcgWyyV7dXYZdqe9AaVak@public.gmane.org>
On Sunday 11 March 2007 21:11, Ulrich Kunitz wrote:
> > I'm still not convinced that papering over the problem in userspace is a
> > real solution.
> >
> > johannes
>
> Just my 2 cents. I support this. What are the options? I see only
> two:
>
> 1. Use different magic numbers for 32 bit and 64 bit structures. A
> flag is an alternative, but will be more difficult to debug.
> Generation of the magic should be easy, use sizeof(unsigned
> long) as test. User space has to care than for the rest.
>
> 2. Make the data representation identical in 32 bit and 64 bit.
>
> This shouldn't be to difficult, if only u8, u16 and u32 types
> are used.
> Pointers should be given as offsets.
Offsets to what?
> If necessary
> align and/or packed attributes could be used.
>
> If the kernel interface can be changed, I vote for option 2,
> because user space has then to deal with a unique data layout.
> If the wext kernel interface cannot be changed to maintain
> backward compatibility, then I have to admit band-aids in user
> space are needed. However cfg80211 must not suffer from the same issues.
All your suggestions break the userspace ABI on all machines,
which is a thing we _really_ want to avoid.
The right fix is to have a compatibility wrapper in the kernel,
but it turns out to be hard to implement. I don't think we want
to change the structures layout and break ABI.
--
Greetings Michael.
next prev parent reply other threads:[~2007-03-11 20:31 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
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 [this message]
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=200703112130.05717.mb@bu3sch.de \
--to=mb@bu3sch.de \
--cc=dcbw@redhat.com \
--cc=jgarzik@pobox.com \
--cc=jkm@devicescape.com \
--cc=johannes@sipsolutions.net \
--cc=jt@hpl.hp.com \
--cc=kune@deine-taler.de \
--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.