Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In this comment someone tries to justify its design, citing a lwn article: https://github.com/rex-rs/rex/issues/2#issuecomment-26965339...


I think this is a fair take:

> We currently do not support unprivileged use case (same as BPF). Basically, Rex extensions are expected to be loaded by privileged context only.

As I understand it, in privileged context would be one where one is also be able to load new kernel modules, that also don't have any limitations, although I suppose the system could be configured otherwise as well for some reasons.

So this is like a more convenient way to inject kernel code at runtime than kernel modules or eBPF modules are, with some associated downsides (such as being less safe than eBPF; the question about non-termination seems apt at the end of the thread). It doesn't seem like they are targeting to actually put this into mainstream kernel, and I doubt it could really happen anyway..


Yeah I agree with this assessment. It is not an eBPF replacement for many reasons. But could be a slightly safer alternative to kernel modules.


That's one aspect of the design. Again, complexity requirements are there for a reason. No explanation seen for why this eschews them.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: