[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1160955543.14340.21.camel@localhost>
Date: Mon, 16 Oct 2006 01:39:03 +0200
From: Marcel Holtmann <marcel@...tmann.org>
To: Al Viro <viro@....linux.org.uk>
Cc: Linus Torvalds <torvalds@...l.org>, davem@...emloft.net,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] l2cap endianness annotations
Hi Al,
> @@ -34,7 +34,7 @@ #define L2CAP_CONN_TIMEOUT (HZ * 40)
> /* L2CAP socket address */
> struct sockaddr_l2 {
> sa_family_t l2_family;
> - unsigned short l2_psm;
> + __le16 l2_psm;
> bdaddr_t l2_bdaddr;
> };
this data structure is visible to the userspace (via the Bluetooth
library headers). Do we annotate them, too?
> @@ -205,7 +205,7 @@ #define l2cap_pi(sk) ((struct l2cap_pinf
>
> struct l2cap_pinfo {
> struct bt_sock bt;
> - __u16 psm;
> + __le16 psm;
> __u16 dcid;
> __u16 scid;
>
> @@ -221,7 +221,7 @@ struct l2cap_pinfo {
>
> __u8 ident;
>
> - __u16 sport;
> + __le16 sport;
>
> struct l2cap_conn *conn;
> struct sock *next_c;
These are internal. We should have to annotate them. They should store
it in host order. If not, than that is the problem.
> @@ -1533,7 +1533,7 @@ static inline int l2cap_config_req(struc
> if (!(sk = l2cap_get_chan_by_scid(&conn->chan_list, dcid)))
> return -ENOENT;
>
> - l2cap_parse_conf_req(sk, req->data, cmd->len - sizeof(*req));
> + l2cap_parse_conf_req(sk, req->data, __le16_to_cpu(cmd->len) - sizeof(*req));
I have to look into this change. It basically means that this code never
worked on big endian systems, but it actually does.
Regards
Marcel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists