That to some extent makes sense, but then you loose the stuff
that arrived before you start the daemon; it is easy to make
> > don't need to make it more complex - this is also the reason
> > to force reading whole messages and having the length in the
> > header - it's a poor's man rcvmsg()).
> except you're layering it on read() which has very different semantics.
It does - however, that is the price to pay to not be dependent
on the socket interface (so you can skip if for example, you
have some system that does not require it).
> I read(1) should I get back a 0-length read or a special ERRNO?
Hmm, ok, right now I am returning -EFBIG - but you are right, it makes
sense to be able to at least get the size. Now that I think about it,
it should not be too difficult to add an offset by the kue_fd structure
that stores what was the last offset that was read of the current
message, and once you read it all, it advances to the next one - in
the same style, it'd be easy to make that configurable.
> if I want
> to read the length, then read the buffer, how do I?
Simple answer right now is to double the buffer, try again, but
as I said above, it is kind of counterproductive ...
What about this?: If you read less than the next message's full
size, you get -EFBIG but as much data as buffer is provided is
copied, and until you provide a buffer big enough for holding the
whole message, it doesn't consider it read and moves along.
This way you can get the size [by reading the first four bytes].
And it does not make the code more complex [as would do the first
option I suggested].
Or forget -EFBIG - you get the actual length you asked for, but
the read msg pointer only advances when you read the whole msg
in a single shot.
> > And then, providing small buffers is also kind of underperforming;
> > you want to maximize how much events you get in a single shot per
> > system call, to minimize the system call overhead - that means a
> > bigger buffer; your granularity in time is what will determine it.
> Another difference of opinion - you should never deliver more than one
> - regardless of how much you have read.
My point here is efficiency - I think it makes sense to assume that
you can get a good rate of msg/second in depending what kind of
loads (imagine, for example, for network packet inspection), so reading
them all in a single shot instead of one by one is more efficient.
Especially when they are all small messages.
> > plugged into, for example /sysfs [add to my stuff a declare message
> > queue, and export it in /sysfs as a file] - Will look into that
> yeah, sysfs is becoming procfs - just throw everything in there.
> There also exists netlink which does multiple readers in a packetized
> already. It's not too bad.
Need to take a look into that.
Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/