From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: The list for a Better Approach To Mobile Ad-hoc Networking
<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] [PATCH] batman-adv: compat: Substitute compat code for netlink constification
Date: Thu, 20 Oct 2016 20:33:03 +0200 [thread overview]
Message-ID: <20161020183303.GD32033@otheros> (raw)
In-Reply-To: <9062705.AOdrQGRa4W@bentobox>
On Wed, Oct 19, 2016 at 08:31:03AM +0200, Sven Eckelmann wrote:
> On Mittwoch, 19. Oktober 2016 01:22:39 CEST Linus Lüssing wrote:
> > On Tue, Oct 18, 2016 at 11:28:23PM +0200, Sven Eckelmann wrote:
> > > Doesn't seem to scale. Especially when we think about batadv_netlink_ops
> > > which should also be const. It is currently not const because of the
> > > Linux <= 3.13 workaround.
> >
> > Hm, okay, batadv_netlink_ops is a little more tricky/larger, yes.
> > What about a memcpy'ing approach with BUILD_BUG_ON()'s as
> > safe-guards like this:
>
> Yes, this would also be an idea. But I would personally just use the
> coccinelle approach because it needs less extra hacks. Or do you have any
> problems with coccinelle?
Hm, no, dunno. Just haven't really looked at coccinelle yet and
thought your point 3. (cocinelle) were on place 4. instead.
Besides, I had fun creating this compat patch and was marvelled
that the BUILD_BUG_ON() worked even with function parameters :D
(maybe, actually because they were const now? You clever compiler
:D).
Also, it looks like the whole compat infrastructure is growing and
I'm wondering whether it is easier to maintain slightly larger
compat-includes vs. then two more places where compat changes
could come from.
But I don't feel strongly about it, if others think coccinelle is
easier to review and maintain, then I'm fine with it and will have
a closer look at coccinelle :).
prev parent reply other threads:[~2016-10-20 18:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-18 21:21 [B.A.T.M.A.N.] [PATCH] batman-adv: compat: Substitute compat code for netlink constification Linus Lüssing
2016-10-18 21:24 ` Linus Lüssing
2016-10-18 21:28 ` Sven Eckelmann
2016-10-18 23:22 ` Linus Lüssing
2016-10-19 6:31 ` Sven Eckelmann
2016-10-20 18:33 ` Linus Lüssing [this message]
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=20161020183303.GD32033@otheros \
--to=linus.luessing@c0d3.blue \
--cc=b.a.t.m.a.n@lists.open-mesh.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