|
About ::
TODO ::
Blog ::
RSS ::
Old blog ::
Projects ::
GIT ::
Gallery ::
Notes
Tue, 15 May 2007
Kevent/eventfd/pollfs discussion thread. Monolitic and interface-centric solutions, or better, solutions in search of a problemgetting into account that each kevent kernel user is about 300 lines of code including comments and its registration is completely plugable even in run-time and its memory overhead is several times less. I'm sitting and wondering... And to start the day, two citations from that thread: Yes, of course. If we're heading to yet-another monolitic interface, we're heading with no valid reasons given if other than some handwaving. While there are quite a few (modularity, compatibilty, plus the other ones that came in my mind and that I explained in the way-too-many emails) to back a file-based approach.... That's my point. I think we ultimately have to have something like kevent and then all this *fd() work is unnecessary and just adds code to the kernel which has to be kept around and which might hinder further work in this area.But actually who cares? I've just looked into mainline git tree and found, that the whole eventfd patchset is already committed into the tree. Personally I completely do not care. Actually my massive kevent spambombing resulted in some changes in people's minds - I see a lot of kernel projects started to add 'takeN' to theirs short descriptions to show iteration number, which I did not see before. /devel/kevent :: Link / Comments (0) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||