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

? ? 于是我再次尋找，發現了eventfd這個神器，在KVM與Qemu的通信之間，eventfd被大牛使用的出神入化，仔細地分析了一下源碼，發現這個東西就如名字所說，純是為了通知而存在的。
? ? 作為一個file（linux里有不是file的東西么～～），它的private_data結構體?eventfd_ctx只有可憐的四個變量。
struct eventfd_ctx {
????struct kref kref; ? /* 這個就不多說了，file計數用的，用于get/put?*/
????wait_queue_head_t wqh; /* 這個用來存放用戶態的進程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; ?/* 這個就是一個技術器，應用程序可以自己看著辦，read就是取出然后清空，write就是把value加上?*/
????unsigned int flags; ?/* 所有的file都有的吧，用來存放阻塞/非阻塞標識或是O_CLOEXEC之類的東西?*/
};

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

* 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;

}

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


?