The document discusses the Netlink API for inter-process communication between kernel space and user space in Linux. It provides an overview of Netlink, sample code for creating sockets and sending/receiving messages, and analyzes reliability issues with asynchronous message transmission. Specifically: - Netlink allows communication between kernel and user processes by eliminating round trips between spaces but reliability can be an issue with asynchronous messaging. - Sample code demonstrates creating Netlink sockets, binding addresses, packing messages and sending/receiving between kernel and user callback functions. - Reliability is analyzed for various message transmissions, and solutions like acknowledging delivered messages are proposed to ensure successful inter-process communication via Netlink.

1. Outline
• introduction
• Netlink API
• Sample code
• Analysis of reliability issue
0

2. introduction
• Netlink is a ipc mechanism different from
system call
– Advantage
• Eliminate round trip time from user space to kernel
space
• Broadcast message
• Transmission from kernel space to user space
– Shortcoming
• Reliability issue
1

3. User space API
• int socket(int domain, int type, int protocol)
– Domain is AF_NETLINK;
– Type is either SOCK_RAW or SOCK_DGRAM;
– Protocol:
• Except predefined netlink protocol types, 20~31 is
reserved for user-define protocol.
• Netlink_usersock(2) is available for test.
• Each one acts like a physical network.
2

4. User space API
• Bind()
– struct sockaddr_nl {
• sa_family_t nl_family; /* AF_NETLINK */
• unsigned short nl_pad; /* zero */
• __u32 nl_pid; /* process pid */
• __u32 nl_groups; /* group which process belong to */
– } nladdr;
– Netlink address has to be bind with the opened
netlink socket.
• bind(fd, (struct sockaddr*)&src_addr, sizeof(src_addr));
3

5. • Information in socket handle
4
User
process
User
process
User
process
Kernel
Netlink
network
Information in socket handle:
address (process id)
Group number
Protocol number: indicate which netlink
network

6. User space API
• Pack a netlink message into standard socket message
– Pink area deserved extra attention.
– Pid of sender is not really necessary when receiver is not
intended to know
– Unused member shall be zero out.
– Then we can use this message on sendmsg() and recvmsg()
5
Msg_name
Msg_name len
msg_iov
Msg_Iov_len=1
dest
pid
Dest
group
Iov_base
Iov_len
Len of netlink
message
Pid of sender
Payload of
netlink
message

7. kernel space API example – receiving message
• netlink_kernel_create(&init_net, NETLINK_USERSOCK, 0,udp_
receive, NULL, THIS_MODULE);
– NETLINK_USERSOCK is protocol unmber we use.
– 0 is identifier of group unmber.
– udp_receive() is call back function which receive netlink message.
– Return value is kernel socket handle.
• Design strategy of receive call back function
– When it takes long time to message process code, programmer can queue
message and return right away, in order to prevent too many other system
call’s blocking
– Message process code can be placed in other kernel thread for processing
message queued before.
6

8. kernel space API example – sending message
• ret=netlink_unicast(netlink_sock, skb, pid, MSG_DONTWAIT);
– Netlink_sock is opened socket handle.
– Skb carrys netlink message.
– Pid indicates destination process id.
– MSG_DON’TWAIT means non-block when receiving buffer
is full.
• Netlink_broadcast(…)
– It’s deserved our attention that this function has no return
value, we don’t know message delivery is successful or not.
7

9. Sample code: chat room in local machine
• Traditional ipc like message queue is not easy to applied to
implement chat room
8

10. Reliability issue
• Kernel send unicast message:
– Nonblock and check error return, re-send message.
– Block until finish putting message into receiving buffer.
• Kernel broadcast message?
• User send message to kernel
– Kernel has call back receiving function to process right
away.
• User send message to other user
– Sendmsg() don’t guarantee successful delivery.
9

11. Reliability issue
• Reliability solution:
– Ack transmitted message for successful delivery
between user and user.
• If we still want to try netlink messge between user and
user, because that’s unreliable transmission.
– Every receiving thread should queue message for
processing later, then return right away.
10

12. Reliability issue
• Data layout
11
User
process
User
process
User
process
Kernel
Netlink
network
Receiving
queue
Receiving
queue
Receiving
queue
sending
queue
Kernel space
User space

13. Draft of proposed scheme
• Partition of driver in FULL-change scheme
– Framework for netlink feature development and test.
– After development, old cm & bridge still can use new driver through lddb
model.
12
Kernel space
User space
Lddb logic:
Receving soc’s data and queue it.
Sending data to soc.
Soc data forwarding logic
and sdio control logic
Connection
Manager
And bridge
Netlink
message
System call interface
New
Connection
Manager
And new bridge

14. conclusion
– 1. full change or half – further survey in full-change scheme is necessary,
TI’ wifi sdio driver is a reference.
– 2. advantage of half-change scheme : event from kernel to user.
• 1 active error message inform to app
• 2 performance boost in CM query
• 3 minimun modification
– 3. shortcoming of full-change scheme
• 1.kernel sending may have to adjust speed by queuing soc‘s data, otherwise
blocked kernel sending might compromise system performance.
• 2. function return can’t represent execution result anymore, this is a drawback
of asynchronous execution of kernel and user, especially in compare to ioctl
mechanism.(it might be necessary to ack execution result message to sender).
– 4. Other discussion
• 1. debug message option should not be hard-code.
• 2. error handle in driver
13