netdev - epoll, missed opportunity?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 18 Sep 2015 22:51:08 -0600
From:	Jonathan Marler <johnnymarler@...il.com>
To:	netdev@...r.kernel.org
Subject: epoll, missed opportunity?

I'm curious why there wasn't another field added to the epoll_event
struct for the application to store the descriptor's context. Any
useful multi-plexing application will have a context that will need to
be retrieved every time a descriptor needs to be serviced. Since the
epoll api has no way of storing this context, it has to be looked up
using the descriptor, which will take more time/memory as the number
of descriptors increase. The memory saved from omitting this context
can't be worth it since you'll have to allocate the memory in the
application anyway, plus you're now adding the extra lookup.

This "lookup" problem has always existed in multi-plexed applications.
It was impossible to fix with older polling interfaces, however, since
epoll is stateful, it provides an opportunity to fix this problem by
storing the descriptor context in epoll's "state". What was the reason
for not doing this?  Was it an oversight or am I missing something?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html