libosmocore: patch for big-endian architectures
diff mbox

Message ID 20160526191624.GA23739@macbookair
State New
Headers show

Commit Message

Ruben Undheim May 26, 2016, 7:16 p.m. UTC
Hi,

One test case fails for openbsc on big-endian architectures. This was traced
back to struct erros in libosmocore. Please see patch below:



commit fb3d353ab238a2d14cb8e9704995f14a2acd6c1b
Author: Ruben Undheim <ruben.undheim@gmail.com>
Date:   Mon Dec 7 19:34:28 2015 +0100

    Patched structs for big-endian architectures



I tried 30 seconds to figure out how to use Gerrit, but I couldn't figure out
how to login, so I rather just post here.


Best regards,
Ruben

Comments

Neels Hofmeyr May 27, 2016, 11:47 a.m. UTC | #1
On Thu, May 26, 2016 at 09:16:24PM +0200, Ruben Undheim wrote:
> I tried 30 seconds to figure out how to use Gerrit, but I couldn't figure out
> how to login, so I rather just post here.

Instructions:
http://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit

In short, first be logged in on osmocom.org, then go to gerrit sign-in and
enter this openid url:
https://osmocom.org/openid

I agree that it's somewhat harder than pasting the patch into a mail, but it is
achievable ;)

Call again if you truly can't be bothered and I'll submit your patch for review
-- this once ;)

Thanks!
~Neels
Ruben Undheim May 27, 2016, 7:32 p.m. UTC | #2
> In short, first be logged in on osmocom.org, then go to gerrit sign-in and
> enter this openid url:
> https://osmocom.org/openid

After struggling for some time I was finally able to logon and add the SSH key. I kept
getting a blank window every time I tried to log in, but it worked in the end.

But now I get:

  "Unable to negotiate with 144.76.43.76 port 29418: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1"


Seems to be some compatibility issues with the SSH versions.

> I agree that it's somewhat harder than pasting the patch into a mail, but it is
> achievable ;)

Hmm, it's probably achievable if you are planning on working on the project for
some time, but for me who just want to provide a patch, it appeared to be a bit
of a pain. :)   I'm sure it's great when it works though!
 
> Call again if you truly can't be bothered and I'll submit your patch for review
> -- this once ;)



Best regards,
Ruben
Holger Freyther May 27, 2016, 7:36 p.m. UTC | #3
> On 27 May 2016, at 21:32, Ruben Undheim <ruben.undheim@gmail.com> wrote:
> 
>> In short, first be logged in on osmocom.org, then go to gerrit sign-in and
>> enter this openid url:
>> https://osmocom.org/openid
> 
> After struggling for some time I was finally able to logon and add the SSH key. I kept
> getting a blank window every time I tried to log in, but it worked in the end.
> 
> But now I get:
> 
>  "Unable to negotiate with 144.76.43.76 port 29418: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1"
> 
> 
> Seems to be some compatibility issues with the SSH versions.

not yet on the main page, but if you are willing to create a .ssh/config entry

Host            gerrit.osmocom.org
HostName        gerrit.osmocom.org
Port            29418
User            yourusername
KexAlgorithms        +diffie-hellman-group1-sha1
IdentityFile        ~/.ssh/id_rsa_gerrit.osmocom.org


I will explore if gerrit supports more key exchange algorithms.

holger
Holger Freyther May 27, 2016, 7:39 p.m. UTC | #4
> On 27 May 2016, at 21:36, Holger Freyther <holger@freyther.de> wrote:
> 
> 
> 
> 
> I will explore if gerrit supports more key exchange algorithms.

That was quick. Gerrit offers to download bouncy castle when installing, just that this one version can not be downloaded anymore and I didn't find a copy of that file. *yeah* to stable urls. It seemed to work just but now I have a reason spend more time on it.

holger
Holger Freyther May 27, 2016, 7:46 p.m. UTC | #5
> On 27 May 2016, at 21:39, Holger Freyther <holger@freyther.de> wrote:
> 
> 
> That was quick. Gerrit offers to download bouncy castle when installing, just that this one version can not be downloaded anymore and I didn't find a copy of that file. *yeah* to stable urls. It seemed to work just but now I have a reason spend more time on it.


Can you please try again?

thank you
	holger
Ruben Undheim May 27, 2016, 8:11 p.m. UTC | #6
> Can you please try again?

Thanks! I was able to push. As I said, it's great when it works! Since my key is
now in there, next time will be a lot easier.

Cheers
Ruben
Holger Freyther May 27, 2016, 8:13 p.m. UTC | #7
> On 27 May 2016, at 22:11, Ruben Undheim <ruben.undheim@gmail.com> wrote:
> 
> 
>> Can you please try again?
> 
> Thanks! I was able to push. As I said, it's great when it works! Since my key is
> now in there, next time will be a lot easier.

yes, sorry it was not as smooth as it could have been. I will CC you on the debian package changes when merging your work into our repository.

have a nice weekend

	holger
Neels Hofmeyr May 30, 2016, 10:39 a.m. UTC | #8
On Fri, May 27, 2016 at 09:32:41PM +0200, Ruben Undheim wrote:
> > I agree that it's somewhat harder than pasting the patch into a mail, but it is
> > achievable ;)
> 
> Hmm, it's probably achievable if you are planning on working on the project for
> some time, but for me who just want to provide a patch, it appeared to be a bit
> of a pain. :)   I'm sure it's great when it works though!

My humble opinion for the last time: gerrit has overly complicated nearly every
aspect of working on the code. The web ui is bloated and cumbersome to
navigate, and every commit and push needs goofy hacks just for gerrit :(

It does add handy features of tracking patches and managing reviews, yet it
kind of removes the concept of patch-set grouping. Of course, the integrated
jenkins build is excellent to have (though would be sufficient after pushing).

I submit to the community's decision to use gerrit, and I don't think it would
be worth the trouble to switch yet again (if I'm the only one moaning), but I
wouldn't introduce gerrit a second time.

End-Of-Rant for all eternity ;)

~Neels
Holger Freyther May 30, 2016, 11:56 a.m. UTC | #9
> On 30 May 2016, at 12:39, Neels Hofmeyr <nhofmeyr@sysmocom.de> wrote:
> 
> 
> My humble opinion for the last time: gerrit has overly complicated nearly every
> aspect of working on the code. The web ui is bloated and cumbersome to
> navigate, and every commit and push needs goofy hacks just for gerrit :(

Can you elaborate? What are the goofy hacks? There is the sign-up (but compared to two days of SSL issues to submit emails) OpenID + username + setting ssh key is more quick? And then to download the hook to generate a Change-Id on commits?



> It does add handy features of tracking patches and managing reviews, yet it
> kind of removes the concept of patch-set grouping. Of course, the integrated
> jenkins build is excellent to have (though would be sufficient after pushing).

The main advantages for a reviewer:

	* I don't have to look at stuff that doesn't compile
	* I don't have to see if I need to download the mbox or the patch
	* I can easily submit the resulting change

In fact reviewing has been more pleasant for me than before (besides the pain of having to wrangle with Java and doing a FreeBSD port of buck to build and debug it)

> 
> I submit to the community's decision to use gerrit, and I don't think it would
> be worth the trouble to switch yet again (if I'm the only one moaning), but I
> wouldn't introduce gerrit a second time.

For patch-series: Either way, sending a 40 patches en-block is not well received. This wouldn't be any better with git dump-email. ;)


> End-Of-Rant for all eternity ;)

Besides the smiley I think you could have been more constructive, e.g you have admin rights and shell access to the system and I have already pointed you to the "Submit Type" in the project settings. Did you have a look at it to see if for your workflow we are using the wrong "type"?

In osmo-sip-connector.git I changed from cherry-oick to always merge (probably fast-forward is closer to what we want in our change history) and pushed two changes. The last patch can be seen here https://gerrit.osmocom.org/#/c/127/1.

It shows "Related changes" for both of them and for the second (and probably third) it has "Submitted Together" that shows my entire "series". After +2/+1 on them I have a button called "Submit including parents".

Is this closer to what you want? I have picked "Cherry Pick" as many times there is a patch series but only a few commits are actually ready to be merged. To reduce work it seemed good to accept the raisins more quickly.

cheers
	holger
Neels Hofmeyr May 30, 2016, 4:56 p.m. UTC | #10
On Mon, May 30, 2016 at 01:56:08PM +0200, Holger Freyther wrote:
> Can you elaborate? What are the goofy hacks?

Before it was just git, now gerrit has its tag on near everything I do with the
code. I wish gerrit were less visible:

- add gerrit remote
  - two upstream repos to sync to (origin and gerrit)
  - gitk shows every branch twice, once for each remote
  - checking out a new branch is more complex; because of two remotes, one
    needs to use the full 'git co -b <localname> --track <remote>/<name>'
    instead of just 'git co -b <name>'
  (I could probably work with just the gerrit remote, but then I wouldn't
  see what our public master repositories are up to)
- commit id. I can't just clone, I have to do extra cycles for each clone.
- access rules = obstructed access to branches = add 'users/' to all private branches
  = we have scores of old branches now in a namespace we can't use anymore
- elaborate command line args instead of simple pushes

Things just got so much more noisy on the git end.

> In fact reviewing has been more pleasant for me than before (besides the pain of having to wrangle with Java and doing a FreeBSD port of buck to build and debug it)

ok, that's a good thing.

My position + smiley means: I found it a hard process but it works the way it
is now; I'd have liked gerrit to be less visible in the daily workflows, but
whatever. If it's better for your reviewing, it's an improvement.

> For patch-series: Either way, sending a 40 patches en-block is not well received. This wouldn't be any better with git dump-email. ;)

It doesn't make much sense to split the IuPS dev into separate bits...
The branch makes sense as a whole. This is not a typical patch submission,
right?

Subdividing would be artificial, but ok, can do, if that helps reviewing.

> Besides the smiley I think you could have been more constructive, e.g you have admin rights and shell access to the system and I have already pointed you to the "Submit Type" in the project settings. Did you have a look at it to see if for your workflow we are using the wrong "type"?

I've spent enough time on gerrit overhead. Do I have to understand this? At
least I would prefer not to, to use my resources for the tasks "piling up on my
desk" instead.

> In osmo-sip-connector.git I changed from cherry-oick to always merge (probably fast-forward is closer to what we want in our change history) and pushed two changes. The last patch can be seen here https://gerrit.osmocom.org/#/c/127/1.

yes, that kind of makes sense, but how does this work. I go to the website,
reconfigure the project, submit my branch so it comes in as <type> and then
configure the project back to what it was? :P

What was your <type>, "always merge"?
Well, as I said, I hope I don't need to explore that right now...

Please confirm that I should/can just push the first handful of IuPS changes to
for/master.

~Neels
Holger Freyther May 30, 2016, 7 p.m. UTC | #11
> On 30 May 2016, at 18:56, Neels Hofmeyr <nhofmeyr@sysmocom.de> wrote:
> 
> 
> On Mon, May 30, 2016 at 01:56:08PM +0200, Holger Freyther wrote:
>> Can you elaborate? What are the goofy hacks?
> 
> Before it was just git, now gerrit has its tag on near everything I do with the
> code. I wish gerrit were less visible:
> 
> - add gerrit remote
>  - two upstream repos to sync to (origin and gerrit)

Do you know you can directly clone from ssh (one command)? You can also define one _remote_ and have different pull/push urls (okay would require post-clone work but maybe a script)?

>  - gitk shows every branch twice, once for each remote
>  - checking out a new branch is more complex; because of two remotes, one
>    needs to use the full 'git co -b <localname> --track <remote>/<name>'
>    instead of just 'git co -b <name>'

>  (I could probably work with just the gerrit remote, but then I wouldn't
>  see what our public master repositories are up to)
> - commit id. I can't just clone, I have to do extra cycles for each clone.

Okay, maybe a clone script? I assume you have one already? Yes, a small change in workflow but should be manageable?

git config remote.origin.pushurl ssh://<GERRIT_HOST>:29418/<PROJECT_PATH>.git
git config remote.origin.push refs/heads/*:refs/for/*
git push origin

imaginary script (typos..):

$ cat git gerrit-clone git://git.osmocom.org/libosmocore
#!/bin/sh
set -e
git clone $1
cd `basename $1 git`
git config remote.origin.pushurl ...
git config remote.origin.push..
scp .. .git/hooks
echo "tada"


yes, a change in muscle memory. When cloning you have to remember your gerrit username and that the repository was using gerrit. But from daily workflow it doesn't look that bad?

Either way you have to make the mental decision if you push a wip branch or if you want to have review. 



> - access rules = obstructed access to branches = add 'users/' to all private branches
>  = we have scores of old branches now in a namespace we can't use anymore

Then let's create one group like you did and allow everything for that group again? So one manual intervention and one can push to everything again. No issue with that.



> - elaborate command line args instead of simple pushes
> 
> Things just got so much more noisy on the git end.

Can you try with the above options? Does it make more natural again?




>> For patch-series: Either way, sending a 40 patches en-block is not well received. This wouldn't be any better with git dump-email. ;)
> 
> It doesn't make much sense to split the IuPS dev into separate bits...
> The branch makes sense as a whole. This is not a typical patch submission,
> right?
> 
> Subdividing would be artificial, but ok, can do, if that helps reviewing.

Nobody will review 40 patches with full mental power. I didn't peek at the branch yet but I assume there are some general changes to the structure first, or adding Iu support first before using it? So start with something one can review within 30 minutes?


> I've spent enough time on gerrit overhead. Do I have to understand this? At
> least I would prefer not to, to use my resources for the tasks "piling up on my
> desk" instead.

We are stronger together. I certainly don't know everything about gerrit, I have not looked at which submit type makes the most sense for us, I picked one that looked reasonable (from allowing to pick patches of a series because we are picky). So try fast-forward only or merge or rebase if necessary. :)



>> In osmo-sip-connector.git I changed from cherry-oick to always merge (probably fast-forward is closer to what we want in our change history) and pushed two changes. The last patch can be seen here https://gerrit.osmocom.org/#/c/127/1.
> 
> yes, that kind of makes sense, but how does this work. I go to the website,
> reconfigure the project, submit my branch so it comes in as <type> and then
> configure the project back to what it was? :P
> 
> What was your <type>, "always merge"?
> Well, as I said, I hope I don't need to explore that right now...
> 
> Please confirm that I should/can just push the first handful of IuPS changes to
> for/master.

Under Projects -> "openbsc.git" change it to "Rebase if necessary" and give it a small try (push a slightly outdated commit so we can see
Neels Hofmeyr May 31, 2016, 10 a.m. UTC | #12
On Mon, May 30, 2016 at 09:00:05PM +0200, Holger Freyther wrote:
> Do you know you can directly clone from ssh (one command)?

like, use the ssh shell access and then I get the hook cloned along??


> You can also define one _remote_ and have different pull/push urls (okay would require post-clone work but maybe a script)?
> 
> git config remote.origin.pushurl ssh://<GERRIT_HOST>:29418/<PROJECT_PATH>.git
> git config remote.origin.push refs/heads/*:refs/for/*
> git push origin

Ah ok, that would be better.
Can I also push -f to users/* branches in a similar fashion?

> Okay, maybe a clone script? I assume you have one already?

not yet, I have only put openbsc and libosmocore on gerrit so far.

> $ cat git gerrit-clone git://git.osmocom.org/libosmocore

interesting, you can cat git URLs these days! ;)

> #!/bin/sh
> set -e
> git clone $1
> cd `basename $1 git`
> git config remote.origin.pushurl ...
> git config remote.origin.push..
> scp .. .git/hooks
> echo "tada"

heh "tada"
If we can have the users branch push enabled I'll complete the script and
put it in the Gerrit wiki page.

> yes, a change in muscle memory. When cloning you have to remember your gerrit username and that the repository was using gerrit. But from daily workflow it doesn't look that bad?

I have to type "users/" a lot more :P  (ok see below)
But it would help to get rid of the duplicate remotes = duplicate
branches.

For me personally, the gerrit username matches my shell username, so no
problem there.

> Either way you have to make the mental decision if you push a wip branch or if you want to have review. 

that's not a problem.

But one more thing here: pushing a branch to gerrit is slightly easier
than format-patch, but what is really cumbersome now is to push just one
commit from a private branch (cherry pick to for/master).

With git format-patch I could just supply a range 123abc..ef0987,
with gerrit I first need to create a fresh branch with just that commit.

Especially if I have a couple of unrelated commits sitting in line on a
private branch and I want to submit them separately, I have to create a
new branch for each single commit to push for/master. Do I?

> > - access rules = obstructed access to branches = add 'users/' to all private branches
> >  = we have scores of old branches now in a namespace we can't use anymore
> 
> Then let's create one group like you did and allow everything for that group again? So one manual intervention and one can push to everything again. No issue with that.

agreed.
I have allowed global push permission for the "known users" group.

Since we already have a sysmocom group, sysmocom/* push permission is
still exclusive for the sysmocom group.

I also made push to master exclusive to admins as a gimmick. I hope it
doesn't interfere with the normal merges, we can just drop the rule again
if it does.

> Under Projects -> "openbsc.git" change it to "Rebase if necessary" and give it a small try (push a slightly outdated commit so we can see

I did that and submitted two test branches with two commits each:

One should not have any conflicts during a rebase:
https://gerrit.osmocom.org/130
https://gerrit.osmocom.org/131

The other should have a conflict on the first commit:
https://gerrit.osmocom.org/132
https://gerrit.osmocom.org/133

For some reason both the second commits on the branches also show a
conflict.

changed back to 'cherry pick' for now.

~Neels
Neels Hofmeyr May 31, 2016, 10:14 a.m. UTC | #13
On Tue, May 31, 2016 at 12:00:26PM +0200, Neels Hofmeyr wrote:
> I did that and submitted two test branches with two commits each:
> 
> One should not have any conflicts during a rebase:
> https://gerrit.osmocom.org/130
> https://gerrit.osmocom.org/131
> 
> The other should have a conflict on the first commit:
> https://gerrit.osmocom.org/132
> https://gerrit.osmocom.org/133
> 
> For some reason both the second commits on the branches also show a
> conflict.
> 
> changed back to 'cherry pick' for now.

Did another branch commit without conflict in cherry pick mode, and the
commits show as "Related" but not "Submitted together"...
That's not news I guess.

~Neels
Neels Hofmeyr May 31, 2016, 10:18 a.m. UTC | #14
On Tue, May 31, 2016 at 12:00:26PM +0200, Neels Hofmeyr wrote:
> One should not have any conflicts during a rebase:
> https://gerrit.osmocom.org/130
> https://gerrit.osmocom.org/131

There's a conflict on 131 that shouldn't happen. Does anyone know how to
see gerrit's problem with this commit?

~Neels

Patch
diff mbox

diff --git a/include/osmocom/gsm/protocol/gsm_04_08.h b/include/osmocom/gsm/protocol/gsm_04_08.h
index 4800b48..0c2fcf2 100644
--- a/include/osmocom/gsm/protocol/gsm_04_08.h
+++ b/include/osmocom/gsm/protocol/gsm_04_08.h
@@ -4,6 +4,8 @@ 
 #include <stdbool.h>
 
 #include <osmocom/core/utils.h>
+#include <osmocom/core/endian.h>
+
 
 /* GSM TS 04.08  definitions */
 struct gsm_lchan;
@@ -42,6 +44,7 @@  struct gsm48_classmark2 {
 } __attribute__ ((packed));
 
 /* Chapter 10.5.2.1b.3 */
+#if OSMO_IS_LITTLE_ENDIAN == 1
 struct gsm48_range_1024 {
 	uint8_t	w1_hi:2,
 		 f0:1,
@@ -75,8 +78,44 @@  struct gsm48_range_1024 {
 	uint8_t	w16:6,
 		 w15_lo:2;
 } __attribute__ ((packed));
+#else
+struct gsm48_range_1024 {
+	uint8_t	 form_id:5,
+		f0:1,
+		w1_hi:2;
+	uint8_t	w1_lo;
+	uint8_t	w2_hi;
+	uint8_t	 w2_lo:1,
+		w3_hi:7;
+	uint8_t	 w3_lo:2,
+		w4_hi:6;
+	uint8_t	 w4_lo:2,
+		w5_hi:6;
+	uint8_t	 w5_lo:2,
+		w6_hi:6;
+	uint8_t	 w6_lo:2,
+		w7_hi:6;
+	uint8_t	 w7_lo:2,
+		w8_hi:6;
+	uint8_t	 w8_lo:1,
+		w9:7;
+	uint8_t	 w10:7,
+		w11_hi:1;
+	uint8_t	 w11_lo:6,
+		w12_hi:2;
+	uint8_t	 w12_lo:5,
+		w13_hi:3;
+	uint8_t	 w13_lo:4,
+		w14_hi:4;
+	uint8_t	 w14_lo:3,
+		w15_hi:5;
+	uint8_t	 w15_lo:2,
+		w16:6;
+} __attribute__ ((packed));
+#endif
 
 /* Chapter 10.5.2.1b.4 */
+#if OSMO_IS_LITTLE_ENDIAN == 1
 struct gsm48_range_512 {
 	uint8_t	orig_arfcn_hi:1,
 		 form_id:7;
@@ -110,8 +149,44 @@  struct gsm48_range_512 {
 	uint8_t	w17:5,
 		 w16_lo:3;
 } __attribute__ ((packed));
+#else
+struct gsm48_range_512 {
+	uint8_t	 form_id:7,
+		orig_arfcn_hi:1;
+	uint8_t	orig_arfcn_mid;
+	uint8_t	 orig_arfcn_lo:1,
+		w1_hi:7;
+	uint8_t	 w1_lo:2,
+		w2_hi:6;
+	uint8_t	 w2_lo:2,
+		w3_hi:6;
+	uint8_t	 w3_lo:2,
+		w4_hi:6;
+	uint8_t	 w4_lo:1,
+		w5:7;
+	uint8_t	 w6:7,
+		w7_hi:1;
+	uint8_t	 w7_lo:6,
+		w8_hi:2;
+	uint8_t	 w8_lo:4,
+		w9_hi:4;
+	uint8_t	 w9_lo:2,
+		w10:6;
+	uint8_t	 w11:6,
+		w12_hi:2;
+	uint8_t	 w12_lo:4,
+		w13_hi:4;
+	uint8_t	 w13_lo:2,
+		w14:6;
+	uint8_t	 w15:6,
+		w16_hi:2;
+	uint8_t	 w16_lo:3,
+		w17:5;
+} __attribute__ ((packed));
+#endif
 
 /* Chapter 10.5.2.1b.5 */
+#if OSMO_IS_LITTLE_ENDIAN == 1
 struct gsm48_range_256 {
 	uint8_t	orig_arfcn_hi:1,
 		 form_id:7;
@@ -151,8 +226,50 @@  struct gsm48_range_256 {
 		 w21:4,
 		 w20_lo:3;
 } __attribute__ ((packed));
+#else
+struct gsm48_range_256 {
+	uint8_t	 form_id:7,
+		orig_arfcn_hi:1;
+	uint8_t	orig_arfcn_mid;
+	uint8_t	 orig_arfcn_lo:1,
+		w1_hi:7;
+	uint8_t	 w1_lo:1,
+		w2:7;
+	uint8_t	 w3:7,
+		w4_hi:1;
+	uint8_t	 w4_lo:5,
+		w5_hi:3;
+	uint8_t	 w5_lo:3,
+		w6_hi:5;
+	uint8_t	 w6_lo:1,
+		 w7:6,
+		w8_hi:1;
+	uint8_t	 w8_lo:4,
+		w9_hi:4;
+	uint8_t	 w9_lo:1,
+		 w10:5,
+		w11_hi:2;
+	uint8_t	 w11_lo:3,
+		w12:5;
+	uint8_t	 w13:5,
+		w14_hi:3;
+	uint8_t	 w14_lo:2,
+		 w15:5,
+		w16_hi:1;
+	uint8_t	 w16_lo:3,
+		 w17:4,
+		w18_hi:1;
+	uint8_t	 w18_lo:3,
+		 w19:4,
+		w20_hi:1;
+	uint8_t	 w20_lo:3,
+		 w21:4,
+		spare:1;
+} __attribute__ ((packed));
+#endif
 
 /* Chapter 10.5.2.1b.6 */
+#if OSMO_IS_LITTLE_ENDIAN == 1
 struct gsm48_range_128 {
 	uint8_t	orig_arfcn_hi:1,
 		 form_id:7;
@@ -194,6 +311,49 @@  struct gsm48_range_128 {
 		 w27:3,
 		 w26_lo:1;
 } __attribute__ ((packed));
+#else
+struct gsm48_range_128 {
+	uint8_t	 form_id:7,
+		orig_arfcn_hi:1;
+	uint8_t	orig_arfcn_mid;
+	uint8_t	 orig_arfcn_lo:1,
+		w1:7;
+	uint8_t	 w2:6,
+		w3_hi:2;
+	uint8_t	 w3_lo:4,
+		w4_hi:4;
+	uint8_t	 w4_lo:1,
+		 w5:5,
+		w6_hi:2;
+	uint8_t	 w6_lo:3,
+		w7:5;
+	uint8_t	 w8:4,
+		w9:4;
+	uint8_t	 w10:4,
+		w11:4;
+	uint8_t	 w12:4,
+		w13:4;
+	uint8_t	 w14:4,
+		w15:4;
+	uint8_t	 w16:3,
+		 w17:3,
+		w18_hi:2;
+	uint8_t	 w18_lo:1,
+		 w19:3,
+		 w20:3,
+		w21_hi:1;
+	uint8_t	 w21_lo:2,
+		 w22:3,
+		w23:3;
+	uint8_t	 w24:3,
+		 w25:3,
+		w26_hi:2;
+	uint8_t	 w26_lo:1,
+		 w27:3,
+		 w28:3,
+		spare:1;
+} __attribute__ ((packed));
+#endif
 
 /* Chapter 10.5.2.1b.7 */
 struct gsm48_var_bit {