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

? ? 于是我再次尋找，發(fā)現(xiàn)了eventfd這個(gè)神器，在KVM與Qemu的通信之間，eventfd被大牛使用的出神入化，仔細(xì)地分析了一下源碼，發(fā)現(xiàn)這個(gè)東西就如名字所說(shuō)，純是為了通知而存在的。
? ? 作為一個(gè)file（linux里有不是file的東西么～～），它的private_data結(jié)構(gòu)體?eventfd_ctx只有可憐的四個(gè)變量。
struct eventfd_ctx {
????struct kref kref; ? /* 這個(gè)就不多說(shuō)了，file計(jì)數(shù)用的，用于get/put?*/
????wait_queue_head_t wqh; /* 這個(gè)用來(lái)存放用戶(hù)態(tài)的進(jìn)程wait項(xiàng)，有了它通知機(jī)制才成為可能?*/
/*
* 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; ?/* 這個(gè)就是一個(gè)技術(shù)器，應(yīng)用程序可以自己看著辦，read就是取出然后清空，write就是把value加上?*/
????unsigned int flags; ?/* 所有的file都有的吧，用來(lái)存放阻塞/非阻塞標(biāo)識(shí)或是O_CLOEXEC之類(lèi)的東西?*/
};

我之所以選用它是因?yàn)樗?eventfd_signal 這個(gè)特地為內(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).
????其實(shí)看代碼會(huì)更清晰一些

點(diǎn)擊(此處)折疊或打開(kāi)

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


?