From: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
To: Dmitry Eremin-Solenikov
<dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
slapin-9cOl001CZnBAfugRpC6u6w@public.gmane.org,
maxim.osipov-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org,
dmitry.baryshkov-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org,
oliver.fendt-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org,
dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Subject: Re: [PATCH 03/10] net: add IEEE 802.15.4 socket family implementation
Date: Wed, 3 Jun 2009 17:32:14 -0700 [thread overview]
Message-ID: <20090603173214.6d3997f7.akpm@linux-foundation.org> (raw)
In-Reply-To: <1243868091-5315-4-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, 1 Jun 2009 18:54:44 +0400
Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Add support for communication over IEEE 802.15.4 networks. This implementation
> is neither certified nor complete, but aims to that goal. This commit contains
> only the socket interface for communication over IEEE 802.15.4 networks.
> One can either send RAW datagrams or use SOCK_DGRAM to encapsulate data
> inside normal IEEE 802.15.4 packets.
>
> Configuration interface, drivers and software MAC 802.15.4 implementation will
> follow.
>
> Initial implementation was done by Maxim Gorbachyov, Maxim Osipov and Pavel
> Smolensky as a research project at Siemens AG. Later the stack was heavily
> reworked to better suit the linux networking model, and is now maitained
> as an open project partially sponsored by Siemens.
>
Some drive-by nitpicking, and I saw a bug...
> ...
>
> +#define MAC_CB(skb) ((struct ieee802154_mac_cb *)(skb)->cb)
At present this macro can be passed a variable of any type at all.
It would be better to implement this as a (probably inlined) C
function, so the compiler can check that it was indeed passed a `struct
sk_buff *' (or whatever type it's supposed to be).
And regular C functions are typically in lower case..
I have a feeling that this unnecessary macro pattern is used in other
places in networking, and there's an argument that new code should copy
the old code. It's not a terribly good argument, IMO - the defeating
of type-safety does rather suck.
> +#define MAC_CB_FLAG_TYPEMASK ((1 << 3) - 1)
> +
> +#define MAC_CB_FLAG_ACKREQ (1 << 3)
> +#define MAC_CB_FLAG_SECEN (1 << 4)
> +#define MAC_CB_FLAG_INTRAPAN (1 << 5)
> +
> +#define MAC_CB_IS_ACKREQ(skb) (MAC_CB(skb)->flags & MAC_CB_FLAG_ACKREQ)
> +#define MAC_CB_IS_SECEN(skb) (MAC_CB(skb)->flags & MAC_CB_FLAG_SECEN)
> +#define MAC_CB_IS_INTRAPAN(skb) (MAC_CB(skb)->flags & MAC_CB_FLAG_INTRAPAN)
> +#define MAC_CB_TYPE(skb) (MAC_CB(skb)->flags & MAC_CB_FLAG_TYPEMASK)
These didn't need to be implemented as macros either.
> +#define IEEE802154_MAC_SCAN_ED 0
> +#define IEEE802154_MAC_SCAN_ACTIVE 1
> +#define IEEE802154_MAC_SCAN_PASSIVE 2
> +#define IEEE802154_MAC_SCAN_ORPHAN 3
> +
> +/*
> + * This should be located at net_device->ml_priv
> + */
> +struct ieee802154_mlme_ops {
> + int (*assoc_req)(struct net_device *dev, struct ieee802154_addr *addr, u8 channel, u8 cap);
> + int (*assoc_resp)(struct net_device *dev, struct ieee802154_addr *addr, u16 short_addr, u8 status);
> + int (*disassoc_req)(struct net_device *dev, struct ieee802154_addr *addr, u8 reason);
> + int (*start_req)(struct net_device *dev, struct ieee802154_addr *addr, u8 channel,
> + u8 bcn_ord, u8 sf_ord, u8 pan_coord, u8 blx,
> + u8 coord_realign);
> + int (*scan_req)(struct net_device *dev, u8 type, u32 channels, u8 duration);
> +
> + /*
> + * FIXME: these should become the part of PIB/MIB interface.
> + * However we still don't have IB interface of any kind
> + */
> + u16 (*get_pan_id)(struct net_device *dev);
> + u16 (*get_short_addr)(struct net_device *dev);
> + u8 (*get_dsn)(struct net_device *dev);
> + u8 (*get_bsn)(struct net_device *dev);
> +};
> +
> +#define IEEE802154_MLME_OPS(dev) ((struct ieee802154_mlme_ops *) dev->ml_priv)
Nor did this.
>
> ...
>
> + int i; \
> + pr_debug("file %s: function: %s: data: len %d:\n", __FILE__, __func__, len); \
> + for (i = 0; i < len; i++) {\
> + pr_debug("%02x: %02x\n", i, (data)[i]); \
> + } \
> +}
Could perhaps use lib/hexdump.c
Will do weird things if passed a pointer whcih has type other than char*.
> +/*
> + * Utility function for families
> + */
> +struct net_device *ieee802154_get_dev(struct net *net, struct ieee802154_addr *addr)
> +{
> + struct net_device *dev = NULL;
> +
> + switch (addr->addr_type) {
> + case IEEE802154_ADDR_LONG:
> + rtnl_lock();
> + dev = dev_getbyhwaddr(net, ARPHRD_IEEE802154, addr->hwaddr);
> + if (dev)
> + dev_hold(dev);
> + rtnl_unlock();
> + break;
> + case IEEE802154_ADDR_SHORT:
> + if (addr->pan_id != 0xffff && addr->short_addr != IEEE802154_ADDR_UNDEF && addr->short_addr != 0xffff) {
> + struct net_device *tmp;
> +
> + rtnl_lock();
> +
> + for_each_netdev(net, tmp) {
> + if (tmp->type == ARPHRD_IEEE802154) {
> + if (IEEE802154_MLME_OPS(tmp)->get_pan_id(tmp) == addr->pan_id
> + && IEEE802154_MLME_OPS(tmp)->get_short_addr(tmp) == addr->short_addr) {
You must use very wide xterms :(
> + dev = tmp;
> + dev_hold(dev);
> + break;
> + }
> + }
> + }
> +
> + rtnl_unlock();
> + }
> + break;
> + default:
> + pr_warning("Unsupported ieee802154 address type: %d\n", addr->addr_type);
> + break;
> + }
> +
> + return dev;
> +}
> +
>
> ...
>
> +static int ieee802154_create(struct net *net, struct socket *sock, int protocol)
> +{
> + struct sock *sk;
> + int rc;
> + struct proto *proto;
> + const struct proto_ops *ops;
> +
> + /* FIXME: init_net */
> + if (net != &init_net)
> + return -EAFNOSUPPORT;
yeah, I was going to ask about that. What's the problem here?
> + switch (sock->type) {
> + case SOCK_RAW:
> + proto = &ieee802154_raw_prot;
> + ops = &ieee802154_raw_ops;
> + break;
> + case SOCK_DGRAM:
> + proto = &ieee802154_dgram_prot;
> + ops = &ieee802154_dgram_ops;
> + break;
> + default:
> + rc = -ESOCKTNOSUPPORT;
> + goto out;
> + }
> +
> + rc = -ENOMEM;
> + sk = sk_alloc(net, PF_IEEE802154, GFP_KERNEL, proto);
> + if (!sk)
> + goto out;
> + rc = 0;
> +
> + sock->ops = ops;
> +
> + sock_init_data(sock, sk);
> + /* FIXME: sk->sk_destruct */
?
> + sk->sk_family = PF_IEEE802154;
> +
> + /* Checksums on by default */
> + sock_set_flag(sk, SOCK_ZAPPED);
> +
> + if (sk->sk_prot->hash)
> + sk->sk_prot->hash(sk);
> +
> + if (sk->sk_prot->init) {
> + rc = sk->sk_prot->init(sk);
> + if (rc)
> + sk_common_release(sk);
> + }
> +out:
> + return rc;
> +}
> +
>
> ...
>
> +static void af_ieee802154_remove(void)
Could be __exit, althugh __exit doesn't do much (it used to be
implemented on UML and might still be).
> +{
> + dev_remove_pack(&ieee802154_packet_type);
> + sock_unregister(PF_IEEE802154);
> + proto_unregister(&ieee802154_dgram_prot);
> + proto_unregister(&ieee802154_raw_prot);
> +}
> +
> +module_init(af_ieee802154_init);
> +module_exit(af_ieee802154_remove);
>
> ...
>
> +static inline struct dgram_sock *dgram_sk(const struct sock *sk)
> +{
> + return (struct dgram_sock *)sk;
Better to use container_of() - it's clearer and doesn't assume that
dgram_sock.sk is the first member.
> +}
>
> ...
>
> +static int dgram_bind(struct sock *sk, struct sockaddr *uaddr, int len)
> +{
> + struct sockaddr_ieee802154 *addr = (struct sockaddr_ieee802154 *)uaddr;
sigh, more casting. Often these things can be done in ways which are
nicer to the C type system.
> + struct dgram_sock *ro = dgram_sk(sk);
> + int err = 0;
> + struct net_device *dev;
> +
> + ro->bound = 0;
> +
> + if (len < sizeof(*addr))
> + return -EINVAL;
> +
> + if (addr->family != AF_IEEE802154)
> + return -EINVAL;
> +
> + lock_sock(sk);
> +
> + dev = ieee802154_get_dev(sock_net(sk), &addr->addr);
> + if (!dev) {
> + err = -ENODEV;
> + goto out;
> + }
> +
> + if (dev->type != ARPHRD_IEEE802154) {
> + err = -ENODEV;
> + goto out_put;
> + }
> +
> + memcpy(&ro->src_addr, &addr->addr, sizeof(struct ieee802154_addr));
> +
> + ro->bound = 1;
> +out_put:
> + dev_put(dev);
> +out:
> + release_sock(sk);
> +
> + return err;
> +}
> +
>
> ...
>
> +static int dgram_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
> + size_t size)
> +{
> + struct net_device *dev;
> + unsigned mtu;
> + struct sk_buff *skb;
> + struct dgram_sock *ro = dgram_sk(sk);
> + int err;
> +
> + if (msg->msg_flags & MSG_OOB) {
> + pr_debug("msg->msg_flags = 0x%x\n", msg->msg_flags);
> + return -EOPNOTSUPP;
> + }
> +
> + if (!ro->bound)
> + dev = dev_getfirstbyhwtype(sock_net(sk), ARPHRD_IEEE802154);
> + else
> + dev = ieee802154_get_dev(sock_net(sk), &ro->src_addr);
> +
> + if (!dev) {
> + pr_debug("no dev\n");
> + return -ENXIO;
> + }
> + mtu = dev->mtu;
> + pr_debug("name = %s, mtu = %u\n", dev->name, mtu);
> +
> + skb = sock_alloc_send_skb(sk, LL_ALLOCATED_SPACE(dev) + size, msg->msg_flags & MSG_DONTWAIT,
> + &err);
> + if (!skb) {
> + dev_put(dev);
> + return err;
> + }
> + skb_reserve(skb, LL_RESERVED_SPACE(dev));
> +
> + skb_reset_network_header(skb);
> +
> + MAC_CB(skb)->flags = IEEE802154_FC_TYPE_DATA | MAC_CB_FLAG_ACKREQ;
> + MAC_CB(skb)->seq = IEEE802154_MLME_OPS(dev)->get_dsn(dev);
> + err = dev_hard_header(skb, dev, ETH_P_IEEE802154, &ro->dst_addr, ro->bound ? &ro->src_addr : NULL, size);
> + if (err < 0) {
> + kfree_skb(skb);
> + dev_put(dev);
> + return err;
> + }
> +
> + skb_reset_mac_header(skb);
> +
> + err = memcpy_fromiovec(skb_put(skb, size), msg->msg_iov, size);
> + if (err < 0) {
> + kfree_skb(skb);
> + dev_put(dev);
> + return err;
> + }
It would be better to convert this function (and any similar
occurences) to the `goto foo;' unwinding approach. The
multiple-return-statements-per-C-function is not a favoured approach.
It leads to code duplication and it leads to bugs.
> + if (size > mtu) {
> + pr_debug("size = %u, mtu = %u\n", size, mtu);
> + return -EINVAL;
See, a bug.
> + }
> +
> + skb->dev = dev;
> + skb->sk = sk;
> + skb->protocol = htons(ETH_P_IEEE802154);
> +
> + err = dev_queue_xmit(skb);
> +
> + dev_put(dev);
> +
> + if (err)
> + return err;
> +
> + return size;
> +}
> +
>
> ...
>
> +struct proto ieee802154_dgram_prot = {
I suspect this could/should be const.
> + .name = "IEEE-802.15.4-MAC",
> + .owner = THIS_MODULE,
> + .obj_size = sizeof(struct dgram_sock),
> + .init = dgram_init,
> + .close = dgram_close,
> + .bind = dgram_bind,
> + .sendmsg = dgram_sendmsg,
> + .recvmsg = dgram_recvmsg,
> + .hash = dgram_hash,
> + .unhash = dgram_unhash,
> + .connect = dgram_connect,
> + .disconnect = dgram_disconnect,
> + .ioctl = dgram_ioctl,
> +};
> +
>
> ...
>
> +struct proto ieee802154_raw_prot = {
const?
>
> ...
>
--
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:[~2009-06-04 0:32 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-01 14:54 [RFC][WIP] IEEE 802.15.4 implementation for Linux v1 Dmitry Eremin-Solenikov
2009-06-01 14:54 ` [PATCH 01/10] crc-itu-t: add bit-reversed calculation Dmitry Eremin-Solenikov
2009-06-01 14:54 ` [PATCH 02/10] Add constants for the ieee 802.15.4/ZigBee stack Dmitry Eremin-Solenikov
2009-06-01 14:54 ` [PATCH 03/10] net: add IEEE 802.15.4 socket family implementation Dmitry Eremin-Solenikov
[not found] ` <1243868091-5315-4-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2009-06-01 14:54 ` [PATCH 04/10] net: add NL802154 interface for configuration of 802.15.4 devices Dmitry Eremin-Solenikov
2009-06-01 14:54 ` [PATCH 05/10] ieee802154: add simple HardMAC driver sample Dmitry Eremin-Solenikov
2009-06-01 14:54 ` [PATCH 06/10] mac802154: add a software MAC 802.15.4 implementation Dmitry Eremin-Solenikov
[not found] ` <1243868091-5315-7-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2009-06-01 14:54 ` [PATCH 07/10] ieee802154: add virtual loopback driver Dmitry Eremin-Solenikov
[not found] ` <1243868091-5315-8-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2009-06-01 14:54 ` [PATCH 08/10] tty_io: export tty_class Dmitry Eremin-Solenikov
[not found] ` <1243868091-5315-9-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2009-06-01 14:54 ` [PATCH 09/10] ieee802154: add serial dongle driver Dmitry Eremin-Solenikov
[not found] ` <1243868091-5315-10-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2009-06-01 14:54 ` [PATCH 10/10] ieee802154: add at86rf230/rf231 spi driver Dmitry Eremin-Solenikov
[not found] ` <1243868091-5315-11-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2009-06-01 16:21 ` Gábor Stefanik
[not found] ` <69e28c910906010921r56cf7017gc858cb7ba819c385-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-06-01 20:33 ` Dmitry Eremin-Solenikov
[not found] ` <20090601203348.GC7143-nIupHZaCssqR2kOLt6zJ8ErlnG4Plg33XqFh9Ls21Oc@public.gmane.org>
2009-06-02 8:10 ` Holger Schurig
[not found] ` <200906021010.49613.hs4233-x6+DxXLjN1AJvtFkdXX2Hg4jNU5vUVPG@public.gmane.org>
2009-06-02 8:21 ` Marcel Holtmann
[not found] ` <1243930893.3192.62.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2009-06-02 8:29 ` Ответ: " Dmitry Eremin-Solenikov
2009-06-02 8:36 ` Marcel Holtmann
2009-06-02 8:46 ` Florian Fainelli
2009-06-02 8:49 ` Maxim Osipov
[not found] ` <6097c490906020149j5d614064ied2a4bfebd13ddb0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-06-02 9:15 ` Holger Schurig
2009-06-02 9:29 ` ?????: " Jonathan Cameron
[not found] ` <4A24F106.5040704-KWPb1pKIrIJaa/9Udqfwiw@public.gmane.org>
2009-06-02 11:42 ` Dmitry Eremin-Solenikov
[not found] ` <1243931809.3192.68.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2009-06-02 8:52 ` Ответ: " Sergey Lapin
2009-06-01 15:27 ` [PATCH 09/10] ieee802154: add serial dongle driver Alan Cox
2009-06-01 20:29 ` Dmitry Eremin-Solenikov
[not found] ` <20090601202946.GB7143-nIupHZaCssqR2kOLt6zJ8ErlnG4Plg33XqFh9Ls21Oc@public.gmane.org>
2009-06-01 21:52 ` Alan Cox
[not found] ` <20090601225205.1e7e8944-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
2009-06-02 14:43 ` Sergey Lapin
2009-06-01 15:07 ` [PATCH 08/10] tty_io: export tty_class Alan Cox
2009-06-01 15:10 ` Dmitry Eremin-Solenikov
2009-06-01 15:34 ` Alan Cox
[not found] ` <20090601163418.465be751-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
2009-06-02 14:22 ` Dmitry Eremin-Solenikov
2009-06-02 14:35 ` Alan Cox
2009-06-05 12:24 ` [PATCH 06/10] mac802154: add a software MAC 802.15.4 implementation Pavel Machek
2009-06-04 0:32 ` Andrew Morton [this message]
[not found] ` <20090603173214.6d3997f7.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2009-06-04 11:16 ` [PATCH 03/10] net: add IEEE 802.15.4 socket family implementation Dmitry Eremin-Solenikov
[not found] ` <20090604111634.GA28064-nIupHZaCssqR2kOLt6zJ8ErlnG4Plg33XqFh9Ls21Oc@public.gmane.org>
2009-06-04 13:46 ` John W. Linville
[not found] ` <20090604134455.GB2839-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
2009-06-04 14:10 ` Dmitry Eremin-Solenikov
[not found] ` <bc64b4640906040710p5c7c941fi3341599bc3157b79-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-06-04 14:15 ` Johannes Berg
2009-06-04 0:05 ` [PATCH 01/10] crc-itu-t: add bit-reversed calculation Andrew Morton
2009-06-05 4:03 ` [RFC][WIP] IEEE 802.15.4 implementation for Linux v1 Jon Smirl
[not found] ` <9e4733910906042103q6c21886cia02d33cb278cef1e-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-06-05 4:49 ` Dmitry Eremin-Solenikov
[not found] ` <bc64b4640906042149pb83911bk4e0397da11f9fde6-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-06-05 12:58 ` Jon Smirl
2009-06-13 3:21 ` Jon Smirl
[not found] ` <9e4733910906122021k4568df6rd80fb915b64ac12-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-06-13 5:37 ` Maxim Osipov
2009-06-13 12:39 ` Jon Smirl
2009-06-21 6:40 ` Pavel Machek
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=20090603173214.6d3997f7.akpm@linux-foundation.org \
--to=akpm-de/tnxtf+jlsfhdxvbkv3wd2fqjk+8+b@public.gmane.org \
--cc=dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=dmitry.baryshkov-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=maxim.osipov-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=oliver.fendt-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org \
--cc=slapin-9cOl001CZnBAfugRpC6u6w@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).