一般來說：Linux進程間通信有五大方案：管道，消息隊列，信號量，共享內(nèi)存，套接字。
????管道我不是很熟，只了解一般管道局限與父子進程之間，首先就被我排除了，因為我要做的是相互獨立的進程間通信，命名管道似乎不局限于父子進程，但在內(nèi)核態(tài)怎么使用不清楚。?消息隊列完全不了解。
????信號量的核心是一個內(nèi)核變量的原子操作，但接口只體現(xiàn)在用戶態(tài)，而且信號量的P V操作更多做的好像是互斥，而不是我想要的通知喚醒機制。
????共享內(nèi)存就更麻煩了，接口只在用戶態(tài)，如果自己想做內(nèi)核態(tài)與用戶態(tài)之間的共享內(nèi)存，得自己寫file，然后提供mmap接口。
? ? 套接字之前只是用過af_inet的tcp/udp與af_unix的dgram，還是上面的那個問題，內(nèi)核沒有明確的接口提供，雖然可以自己去用比如sock->ops->recvmsg這樣的函數(shù)去調(diào)用，但畢竟需要自己構(gòu)造入?yún)ⅲ杏X還是不太安全。
? ??
? ? 那么剩下的似乎只有netlink了，這個socket明確地提供了內(nèi)核的發(fā)包函數(shù)，因為它明確地export出了netlink_kernel_create函數(shù)，所以內(nèi)核態(tài)的函數(shù)得以用這個sock來進行發(fā)包。但是一個是用戶態(tài)需要注冊收包函數(shù)，另一個內(nèi)核態(tài)發(fā)包還是免不了要組裝skb，對于我單純地只想進行通知喚醒來說還是過于復(fù)雜了。

? ? 于是我再次尋找，發(fā)現(xiàn)了eventfd這個神器，在KVM與Qemu的通信之間，eventfd被大牛使用的出神入化，仔細地分析了一下源碼，發(fā)現(xiàn)這個東西就如名字所說，純是為了通知而存在的。
? ? 作為一個file（linux里有不是file的東西么～～），它的private_data結(jié)構(gòu)體?eventfd_ctx只有可憐的四個變量。
struct eventfd_ctx {
????struct kref kref; ? /* 這個就不多說了，file計數(shù)用的，用于get/put?*/
????wait_queue_head_t wqh; /* 這個用來存放用戶態(tài)的進程wait項，有了它通知機制才成為可能?*/
/*
* Every time that a write(2) is performed on an eventfd, the
* value of the __u64 being written is added to "count" and a
* wakeup is performed on "wqh". A read(2) will return the "count"
* value to userspace, and will reset "count" to zero. The kernel
* side eventfd_signal() also, adds to the "count" counter and
* issue a wakeup.
*/
????__u64 count; ?/* 這個就是一個技術(shù)器，應(yīng)用程序可以自己看著辦，read就是取出然后清空，write就是把value加上?*/
????unsigned int flags; ?/* 所有的file都有的吧，用來存放阻塞/非阻塞標(biāo)識或是O_CLOEXEC之類的東西?*/
};

我之所以選用它是因為它有?eventfd_signal 這個特地為內(nèi)核態(tài)提供的接口，下面的是注釋。

* This function is supposed to be called by the kernel in paths that do not
?* allow sleeping. In this function we allow the counter to reach the ULLONG_MAX
?* value, and we signal this as overflow condition by returining a POLLERR? to poll(2).
????其實看代碼會更清晰一些

點擊(此處)折疊或打開

int?eventfd_signal(struct eventfd_ctx?*ctx,?int?n)

{

unsigned long flags;

if?(n?

return?-EINVAL;

spin_lock_irqsave(&ctx->wqh.lock,?flags);

if?(ULLONG_MAX?-?ctx->count?

n?=?(int)?(ULLONG_MAX?-?ctx->count);

ctx->count?+=?n;

if?(waitqueue_active(&ctx->wqh))

wake_up_locked_poll(&ctx->wqh,?POLLIN);

spin_unlock_irqrestore(&ctx->wqh.lock,?flags);

return n;

}

本質(zhì)就是做一次喚醒，不用read，也不用write，與eventfd_write的區(qū)別是不用阻塞
????
? ? 下面說一下我的具體用法：
? ? 內(nèi)核態(tài)是一個模塊，注冊一個misc設(shè)備，創(chuàng)建內(nèi)核線程工作(參數(shù)為模塊的file->private_data)。提供ioctl接口供用戶態(tài)進程下發(fā)自己eventfd創(chuàng)建的fd，保存在內(nèi)核線程可以訪問到的file->private_data中。
? ? 當(dāng)內(nèi)核態(tài)想通知用戶態(tài)時，直接使用eventfd_signal，此時用戶態(tài)線程需要先把自己放在eventfd_ctx->wqh上，有兩種方案，一個是調(diào)用read，一個是調(diào)用poll。 如果是read，之后會將eventfd_ctx->count清零，下次還能阻塞住。但是如果使用poll，之后count并未清零，導(dǎo)致再次poll時，即使內(nèi)核態(tài)沒有eventfd_signal，poll也會即時返回。
? ? 用戶態(tài)通知內(nèi)核態(tài)稍微麻煩一點，，首先需要再創(chuàng)建一個eventfd，然后下發(fā)給file->private_data（這里的操作同上面），額外需要在模塊里做一個iotcl，專門負責(zé)用戶態(tài)來通知內(nèi)核態(tài)，函數(shù)里就做eventfd_signal，內(nèi)核態(tài)線程需要先放在eventfd_ctx->wqh上，可以利用vfs_read，或者自己在內(nèi)核態(tài)做一次poll（似乎又麻煩了）。


?