@ljs pretty cool
i think large parts of netbsd can be compiled in to run in userspace, iirc usb drivers, made to run atop libusb or filesystems with libfuse. i think there was even a similar sort of effort for linux?
like this: https://lwn.net/Articles/639333/
@ljs that's beautiful. it reminds me of how much I wish more huge programs were split into little independently usable and testable libraries. web browsers in particular would benefit themselves (from targeted testing/fuzzing) and the world (by being able to reuse all the interesting shims from inside FF and Chrome) so much from this approach
@ljs it's definitely the type of thing for which you should to sound your own horn, more than it seems reasonable to you (i.e with talks, article, toots, private discussions, bathroom stickers…).
@ljs That's great stuff :) I had a similar situation where the best way to debug a tree-based data structure was to copy out the relevant code and stub it to run in userspace, and then write a script to generate the specific data structure from the data in the core dump. That way I could step through & instrument the code and quickly fix the issue!
https://github.com/brenns10/kernel_stuff/tree/master/assoc_array_gc
@ljs Yeah, races are possible (and likely in some cases). For some subsystems, mm & slab for example, the act of reading /proc/kcore will cause side effects that alter state... But it still works well enough for most things.
If you do end up playing with drgn let me know, I'd be glad to help out!