From: Alexander Aring <alex.aring@gmail.com>
To: Simon Vincent <simon.vincent@xsilon.com>
Cc: linux-wpan@vger.kernel.org
Subject: Re: The 802.15.4 Security Layer
Date: Wed, 24 Jun 2015 16:01:13 +0200 [thread overview]
Message-ID: <20150624140111.GA12381@omega> (raw)
In-Reply-To: <20150624100011.GA21293@omega>
On Wed, Jun 24, 2015 at 12:00:14PM +0200, Alexander Aring wrote:
> Hi,
>
> On Tue, Jun 23, 2015 at 04:34:42PM +0100, Simon Vincent wrote:
> > Hi Alex,
> >
> > Do you have your security/nl802154 work available anywhere I can have a
> > look?
> > I am in the process of getting 802.15.4 security working on our devices. I
> > don't want to implement it using the old interface as I will then have to
> > recode our application when llsec moves over to nl802154.
>
> I think what we do at first is a 1:1 implementation of the old interface
> and the new interface and then look what we can change afterwards if
> needed.
>
> We introduce then some CONFIG_NL802154_EXPERIMENTAL to change the enum
> definition (with security and without). I think then we are somehow
> safe to still change the netlink interface, inside kernelspace, afterwards.
>
What I meant here is something like [0]. We simple let the config add
the end of all declaration, if we add something to mainline then we put
it out of the #ifdef foo. (Above the comments) If we do that then the
CONFIG_NL802154_EXPERIMENTAL will be broken afterwards and the userspace
tool need to be updated. Without CONFIG_NL802154_EXPERIMENTAL it should
always be the same. Just the NL802154_CMD_MAX and NL802154_ATTR_MAX
will be a lesser value than without CONFIG_NL802154_EXPERIMENTAL. The
internal nl802154 framework should not react on these definitions then,
if somebody tries to use CMD's/ATTR's which are inside
CONFIG_NL802154_EXPERIMENTAL.
With CONFIG_NL802154_EXPERIMENTAL then the user need to care about to user
the right userspace nl802154 header in their application.
- Alex
[0] https://github.com/linux-wpan/linux-wpan-next/commit/4522252b9964227d1a3ce0b09c1aa0a6d95c3ba1
next prev parent reply other threads:[~2015-06-24 14:01 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 12:31 The 802.15.4 Security Layer Alexander Aring
2015-06-18 15:42 ` Stefan Schmidt
2015-06-18 15:58 ` Simon Vincent
2015-06-18 19:43 ` Stefan Schmidt
2015-06-23 15:34 ` Simon Vincent
2015-06-23 16:00 ` Simon Vincent
2015-06-24 10:00 ` Alexander Aring
2015-06-24 14:01 ` Alexander Aring [this message]
2015-06-26 8:56 ` Simon Vincent
2015-06-26 9:32 ` Alexander Aring
2015-06-26 9:45 ` Stefan Schmidt
2015-06-26 9:58 ` Alexander Aring
2015-06-26 10:14 ` Stefan Schmidt
2015-06-26 10:24 ` Alexander Aring
2015-06-26 11:20 ` Alexander Aring
2015-06-21 21:12 ` Alexander Aring
2015-06-22 12:33 ` Phoebe Buckheister
2015-06-23 11:03 ` Alexander Aring
2015-06-23 12:46 ` Phoebe Buckheister
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=20150624140111.GA12381@omega \
--to=alex.aring@gmail.com \
--cc=linux-wpan@vger.kernel.org \
--cc=simon.vincent@xsilon.com \
/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