> There are lots of issues with using a dev/sysfs interface instead of > system calls and trying to support chroot... Not sure how rdmacm > works, but verbs returns event channel FDs directly 'in-band' which > avoids further use of dev..
The rdmacm calls open() in rdma_create_event_channel()... > Even better would be to use eventfd() to have user space create the > event channel and pass that FD up into the kernel for this sort of > stuff, but I'm not sure if eventfd() can replace all the use cases of > event channels, though they are very similar. This looks promising as a way to merge together all these different RDMA related FDs. It's a significant change and more of a long term solution though. On the surface, it looks like a better approach than trying to fix rdma_create_event_channel directly. > Symlinks? You can bind mount sysfs and create a mini /dev/ in the > chroot and things should work OK, but obviously exposing those items > to the chroot significantly defeats the point of the chroot in the > first place. softlinks using 'ln -s'. bind --mount didn't work either. I'll have to look deeper into the code. This is really more about having fork support with rsockets and uncovering/fixing the problems than seriously trying to get vsftp to run. I'm already forced to use 'one process' mode. If I can get vsftp to run, that would be great, but I hesitant to intercept and discard chroot calls just to make that happen. - Sean -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
