[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160612083432.GC32724@icarus.home.austad.us>
Date: Sun, 12 Jun 2016 10:34:32 +0200
From: Henrik Austad <henrik@...tad.us>
To: Joe Perches <joe@...ches.com>
Cc: linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
alsa-devel@...r.kernel.org, linux-netdev@...r.kernel.org,
henrk@...tad.us, Henrik Austad <haustad@...co.com>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [very-RFC 5/8] Add TSN machinery to drive the traffic from a
shim over the network
On Sun, Jun 12, 2016 at 12:35:10AM -0700, Joe Perches wrote:
> On Sun, 2016-06-12 at 00:22 +0200, Henrik Austad wrote:
> > From: Henrik Austad <haustad@...co.com>
> >
> > In short summary:
> >
> > * tsn_core.c is the main driver of tsn, all new links go through
> > here and all data to/form the shims are handled here
> > core also manages the shim-interface.
> []
> > diff --git a/net/tsn/tsn_configfs.c b/net/tsn/tsn_configfs.c
> []
> > +static inline struct tsn_link *to_tsn_link(struct config_item *item)
> > +{
> > + /* this line causes checkpatch to WARN. making checkpatch happy,
> > + * makes code messy..
> > + */
> > + return item ? container_of(to_config_group(item), struct tsn_link, group) : NULL;
> > +}
>
> How about
>
> static inline struct tsn_link *to_tsn_link(struct config_item *item)
> {
> if (!item)
> return NULL;
> return container_of(to_config_group(item), struct tsn_link, group);
> }
Yes, I mulled over this for a while, but I got the impression that the
ternary-approach was the way used in configfs, and I tried staying in line
with that in tsn_configfs.
If you see other parts of the TSN-code, I tend to use the if (!item) ...
approach. So, I don't have any technical preferences either way really
--
Henrik Austad
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists