linux WTFs

Long have I been noticing things in linux that just don't make sense. I've not always submitted bug reports for these things and instead quickly noted them down so I could fix them later, some rainy day.  Many could involve big long discussions or otherwise warrant an RFC. Others I just need to notify the maintainer or otherwise submit a patch.  Here is my unordered list as of today:

1. filesystem does not support epoll/poll - only select - breaks lots of software such as epoll reactors
2. select and poll use different backends in the kernel
3. no way to dequeue a randomly sized network packet without doing 1+ MSG_PEEK reads until success, and then it's messy because another msgrecv is needed to dequeue those bytes but this does a second copy! The "discarding read" is only supported with sock_dgram and socket_seqpacket (when not SCTP). An approach with SCTP and socket_seqpacket also dequeues x bytes at a time. For all protocols, the size of the packet/message is in the packet/protocol headers... pass it up!  Let the application decide of the packet is of reasonable size to be acceptable more directly.
4. no way to know of crc failures in sockets api
5. CLOCK_MONOTONIC_RAW is what you really mean - CLOCK_MONOTONIC is not monotonic
6. timerfd doesn't support CLOCK_MONOTONIC_RAW
7. pthread blocking calls are non cancelable/interruptable. They should be like poll and return EINTR or some such, instead utilizing software becomes prone to deadlock.  Posix is stupid if it disagrees.
8. No way to get kernel buffers / physical memory in userspace. something close to malloc in use. Integration to write etc also needed. Idea is to have DMAable memory so there's no copying being done.  The idea is also to be integrated with the ecosystem and not so much a stand alone kernel module. You might quickly spout mmap, but it doesn't solve everything...  For instance, there's no way to hand off one buffer to say the write system call and guarantee there's no copying going on.  Perhaps the buffer came from another device's DMA memory so it is something that shouldn't be allocated from the write device either.
9. opening a file can have large latency, even for O_NONBLOCK
10. No separation between UART driver and console stack - they are tightly coupled together.  And ancient.
11. No reliable way of allocating a large chunk of memory from kernel. Think image processing situations from a camera... big chunks are needed.
12. libgomp: active and default consume too much cpu! passive also sucks... needs to use syscalls or something to minimize latency and cpu consumption.  Say with eventfd.
13. GCC packed struct fields: can't take the address of them with const &? They have an address usually... how is this wrong (except for when bit fields are present). How about an unpacked packed and packed version for free so we don't need to write both.

not quite wtf or gnu:

• qlz or lz4 for realtime usable compression (much better than lzo, zfs has included lz4).  Mostly looking at kernel inclusion, especially for btrfs, although these days I only care about zfs on linux.
• openssh: no modularization for key authentication - ie one could tie into an sql or otherwise external authenticator/key database

To blog someday:

• headaches with rs485 or transceivers after rs232? make sure to reset and lower rts...
• how I got 900 MB per second with no latency through the XFS filesystem
• how to survive sigbus in a multithreaded environment - say from mmap'd files
• the glory that is ppoll/epoll & how eventfd kicks pthread condition's ass
• the awesomeness that is pc104e? for io needs at least
• the situation with framegrabbing and poll... rather its absense and buffer management.
• how to implement a camera framebuffer management ie with doubly linked lists
• matlab with numtraits and create_scalar