From: Paul Moore <paul.moore@hp.com>
To: Thomas Graf <tgraf@suug.ch>
Cc: "David S. Miller" <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [NETLINK]: Do precise netlink message allocations where possible
Date: Fri, 10 Nov 2006 23:06:31 -0500 [thread overview]
Message-ID: <45554C47.9020709@hp.com> (raw)
In-Reply-To: <20061110221640.GN8693@postel.suug.ch>
Thomas Graf wrote:
> * Paul Moore <paul.moore@hp.com> 2006-11-10 11:04
>
>>I like this approach, it makes much more sense to me then the previous
>>implementation which was a simple "alias" to alloc_skb(). Also, the NetLabel
>>relevant sections look fine to me.
>
> Question is wheter to do the same for genetlink and add genlmsg_new().
If it makes sense to modify nlmsg_new() I think it makes sense modify
genlmsg_new(). My vote is for "yes".
> I'm currently thinking about this and also about some _reply() function
> which takes a struct genl_info so a genetlink module doesn't have to
> know about how to address the client by pid anymore.
Hmm, interesting idea. I've only thought about it for a few minutes now but it
might be nice to do something like the following:
* genlmsg_put_reply()
- write the message headers using genlmsg_put()
+ take the snd_pid and snd_seq from the genl_info struct
+ ?lookup the hdrlen based on the genl family info in the message
headers in the genl_info struct?
* genlmsg_new_reply()
- allocate a buffer using genlmsg_new()
- call genlmsg_put_reply()
* genlmsg_{unicast,multicast}_reply()
- take the pid from the genl_info struct
I think this would simply the genetlink handlers job a little bit.
> Ideas or even patches very welcome.
If that sounds reasonable I can put together a patch sometime next week,
although it will probably be later in the week as I have some NetLabel stuff I
want to get done for 2.6.20.
--
paul moore
linux security @ hp
prev parent reply other threads:[~2006-11-11 4:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-10 12:17 [NETLINK]: Do precise netlink message allocations where possible Thomas Graf
2006-11-10 16:04 ` Paul Moore
2006-11-10 22:10 ` David Miller
2006-11-10 22:16 ` Thomas Graf
2006-11-11 4:06 ` Paul Moore [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=45554C47.9020709@hp.com \
--to=paul.moore@hp.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=tgraf@suug.ch \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.