The fancy rate limit logic of the journal that takes cgroup info and disk space into account is actually in systemd git master since a while.
And I don't see why timestamping log streams in userspace would be "slow", as the kernel automatically attaches a timestamp to all datagrams anyway, which is accessible via SO_TIMESTAMP/SO_TIMESTAMPNS. Basically on /dev/log the kernel attaches those timestamps it's just a matter of querying them from userspace.
And I don't think Neil Browns file system idea would work, since you'd need to a sane way to communicate the current write and read pointer into those log buffers to userspace (i.e. since we use it as a ring buffer, right?), but that would be necessarily racy, unless the files on those file systems get very very magic seek semantics at which point they'd probably be a lot more like a char device, than a normal file.
Posted Jan 4, 2012 23:21 UTC (Wed) by neilbrown (subscriber, #359)
[Link]
I think /proc and /sys have taught us that many thing are not like "a normal file".
I imagine that when you open and write, the message simply gets appended - i.e. O_APPEND is forced.
When you open and read you just read from the start of the ring. When you get to the end you get EOF, though you can use 'poll' to find out when more data is available (in the same way that various /sys and /proc files support 'poll').
The important difference to a char device is that you can O_CREATE new ones.