openwrt ubus简介


openwrt ubus简介

Ubus Brief

The ubus is designed for providing communication between various daemons and applications.

The architecture as below

Message DispatchUBUS_MSG_INVOKEUBUS_MSG_NOTIFY……UBUS_MSG_DTTARegistered Object TableSubscribed Object TableUbus Connection InstanceUnix SocketUbus DaemonUbus Connection InstanceUnix SocketUbus Connection InstanceRequestReplyresponseUbus Connection InstancecallclientCall MethodserverObject Instance

Objects and Object paths

The Object paths are bindings can name object instances, and allow applications to refer to them.

In OpenWRT, the object path is namespace like network.interface.lan

Methods and Notifications

Methods are operations that can be invoked on an object, with optional input parameters and output.

Notifications are broadcasts from the object to any interested observers of the object. The notifications may contain a data payload

Calling a method

A method call in ubus consists of two messages; A call messages from process A to process B and the reply messages from process B to process A.

The send message and reply messages are both routed through the ubus daemon. The call message contains the method arguments. The reply messages may be error messages, or may contain method returned data.

Call Process

1.The call method messages contains the ubus connection context, the destination object id, the method name, the method arguments. 2. The method call message is send to the ubus daemon

3. The ubus daemon lookup the destination object id, if a process owns the object instance, then the daemon will forward the method call to the find process. Otherwise the ubus daemon creates an error messages and sends the error message back to the message call as reply.

4. The receiving process will parse the ubus object messages, and find the call method and arguments belong to the method. Then match the object methods in object instance, if find matched method, will invoke the method and then send the reply messages.

5. Ubus daemon receive the reply message and forward the reply message to the process that made the method call.

6. The reply messages is transferred as ubus blob messages structure which is TLV (Type-Length-Value) based binary messages type.

7. The process received the reply message should parse the message and format to human-nice message type as JSON or XML.

Notify Notifications

A notification in ubus consists of a single messages, send by one process to any number of other processes, which means the notification is a unidirectional broadcast, no need expected reply message.

The notification sender do not know the notifications recipients, it just send the

notification onto bus The interest recipients should subscribe the sender object with the bus daemon. Notification Process

1. Add notification object onto ubus daemon

2. The notification message contains ubus connection context, the notification sender

object ID, the notification type and optional arguments with the type.

3. Any process on the ubus can subscribe the notification object. The bus may has a list

of subscribers, which will match the observers when daemon handle the notification message.

4. The ubus daemon check the notification and determines which processes are

interested in it. Then send the notification to all of the interested processes. 5. Each subscriber process receiving the notification decides what to do with the

notification message.

Blob_buf structure on ubus Blob_attr

Extended(1bit)ID/Type(7bit)Data_len(24bit)Data Blob_msg




How to use ubus

Server Main process

M1. Define a object with some abstract methods

M2. Connect the server process to ubus daemon and get a ubus_context, the context will contained the connected fd, registered fd callback and an AVL tree to manage all objects information with this connection

M3. Using uloop utilities to add the ubus_context, which is to register the connected fd into epoll set

M4. Add the defined object into ubusd M5. Forever loop to epoll the fd set

What to do in method handler

H1. Parse the blob_attr msg into a blob_attr table, which can easy using by index the table by msg ID

H2. Get the method arguments according to msg id, the handler maybe call method in another objects or invoke a shell script to do some service, etc

H3. Prepare the response msg into blob_buff and send the response to ubus daemon, which will forward the response to request client if not specify “no_reply” or ”deferred” flag H4. If specify “deferred” flag in req context in the method handler, which means the server process will not expect the response in this request handler and just complete this request.

#include #include \

static struct ubus_context *ctx;

static int test_hello(struct ubus_context *ctx, struct ubus_object *obj,


struct hello_request *hreq; struct blob_attr *tb[__HELLO_MAX];

const char *format = \

struct ubus_request_data *req, const char *method, struct blob_attr *msg)

const char *msgstr = \

// H1. Parse the blob_attr msg(blob_data(msg)) into a blob_attr //table (tb), which can easily use by msg ID to index the table

blobmsg_parse(hello_policy, ARRAY_SIZE(hello_policy), tb, blob_data(msg),


// H2. Get method arguments by msg ID

if (tb[HELLO_MSG])

hreq = calloc(1, sizeof(*hreq) + strlen(format) + strlen(obj->name) + strlen(msgstr) + 1); sprintf(hreq->data, format, obj->name, msgstr);

// H4. Defer the reply for the request // The reply will be making in timer callback

ubus_defer_request(ctx, req, &hreq->req); hreq->timeout.cb = test_hello_reply; uloop_timeout_set(&hreq->timeout, 1000); return 0;


// Define hello method with test_hello handle

//hello policy tell ubusd the object method parameters type static const struct ubus_method test_methods[] = {

UBUS_METHOD(\msgstr = blobmsg_data(tb[HELLO_MSG]);

五星文库wxphp.com包含总结汇报、IT计算机、计划方案、办公文档、文档下载、教程攻略以及openwrt ubus简介等内容。