On 10/20/15 3:07 AM, Hannes Frederic Sowa wrote:
<off-topic> Just a pretty obvious idea is accurate sampling of flows. </off-topic>
ok, so you want to time out flows. Makes sense, but it should be done by user space with little or none help from the kernel.
fdinfo tells me where my position in a file is and which locks the file have?
obviously not. see the example fdinfo from the other email.
So far, if someone wants to delve into the details of a map my approach would be to take the file descriptor and make it persistence. I have to think about that some more.
nope. you cannot do that. admin should never interfere with running process this way.
Yes, absolutely and I am absolutely against pretty printing key values in kernel domain.
let's table that part. I think it can be useful, but it's irrelevant for this discussion.
So cat-ing them will produce text output with some details about the map? This is what I wanted to avoid. The concept with symlinks and small files seems much cleaner and nicer to me. Also you cannot add writable attributes to this filesystem or you overload stuff heavily?
nope. no writeable stuff. fdinfo is read-only.
It is not a tree but a graph, sure, that's why sysfs allows to break the cyclic dependencies and create symlinks (see holders/ directories). ;)
that's an obvious example of another resource waste. You can do that for real devices, but for thousands of maps and programs it is really a waste.
And if you implement the same set of features IMHO you basically re-implement sysfs. In the beginning we just expose the basic maps and there won't be any features in sysfs, but it will be cheap to have read/write flags on maps etc. etc. (I don't know what people will come up with, yet.). In my opinion those are clearly attributes of a map and should be defined and managed alongside with their holders.
nope. bpf syscall is the only interface to access maps. if we expose them in bpffs it will be read-only for debugging only.
The pinfd feature will provide the future infrastructure alongside to make this usable, so I think it is worth spending time to think about it.
yes. but since we're going in circles, let's have a 'beer call' to resolve it :) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
