trungnt2910
This paves the way for more FD types to be introduced by drivers without explicit kernel support for them.
So, theoretically, a correctly-coded driver could introduce such things as team and port FDs?
1 reply
This paves the way for more FD types to be introduced by drivers without explicit kernel support for them.
So, theoretically, a correctly-coded driver could introduce such things as team and port FDs?
1 reply
Port FDs are something we should introduce in the kernel itself, as I’ve mentioned before.
I don’t think there is any reason to introduce team FDs, whether in the kernel or in drivers. The concept of having “FDs” for absolutely everything rather than distinct object types is a Linuxism. We already support EVFILT_PROC in kqueue which is the BSD-style way of dealing with this. And likewise, if we need it, we should add EVFILT_SIGNAL rather than signalfd and so on.
Exactly why it should be handled by an external driver for users who somehow want it instead of being introduced to the mainline kernel.
But with the ability to create arbitrary FDs, coupled with the Debugger API’s ability to intercept syscalls, it is now easier to develop a Linux compatibility layer… for those who dare.
1 reply
Ah, yeah, that might be an interesting usecase indeed. But a major disadvantage here is that the FreeBSD Linuxulator can support GUI apps because FreeBSD also uses X11. We don’t (Xlibe doesn’t implement the X11 protocol, only the library). I guess the in-process Wayland server might be of use… but it still sounds like a long shot (given how much effort it appears to be to maintain the Linuxulator on FreeBSD.)
A big thanks to all who contributed again, it certanly has been busy (and we’re not there yet, but getting close to beta5), also a big thanks to all who reported bugs, this also paved the way to Haiku’s current situation. Kudos to all! 