5 ms·

The Unix community tried making one desktop environment better. It was called Motif, which mutated into CDE. Pushing monocultures leads to bland and a lack of c

The Unix community tried making one desktop environment better. It was called Motif, which mutated into CDE. Pushing monocultures leads to bland and a lack of creation, because you end up pissing off end users, like what happens when MS changes the start menu functionality, for example. One kernel is even worse. OS research is still very young, and different types of operations need very different sorts of kernels. For an example based on the original article, getting information from /proc requires three system calls. You have to open the pseudo-file, and in the process allocate memory for a file descriptor, you have to make another system call to get the information, and then a third to close the file after you're done. That's six jumps in and out of kernel space just for one operation. For some tasks, especially when you're starting to get into hard realtime systems, that can lead to unacceptable amounts of delay. After all, would you be satisfied if the one kernel people settled around was the windows kernel?

JoshTriplett 11y ago
> One kernel is even worse. OS research is still very young, and different types of operations need very different sorts of kernels. For an example based on the original article, getting information from /proc requires three system calls. You have to open the pseudo-file, and in the process allocate memory for a file descriptor, you have to make another system call to get the information, and then a third to close the file after you're done. That's six jumps in and out of kernel space just for one operation. As it turns out, I'm working on a solution for that exact problem, within the Linux kernel. I don't see any particular obstacles to doing so. As far as I know, Linux and BSD don't drastically differ from an "OS research" perspective. People doing OS kernel research that needs a "very different sort of kernel" tend to build a custom kernel, or run on L4 or similar. And sometimes that research makes its way into production kernels. > After all, would you be satisfied if the one kernel people settled around was the windows kernel? No, because it isn't Free Software, and nobody outside of Microsoft can change it.
- i336_ 11y ago
  > As it turns out, I'm working on a solution for that exact problem, within the Linux kernel. I don't see any particular obstacles to doing so. oooh. I'd be really interested to learn about this... what exactly are you doing? (What can you do?!)
  - JoshTriplett 11y ago
    Identifying processes with file descriptors instead of PIDs, initially by adding a new flag to clone, CLONE_FD, that gives you back a file descriptor for the new process. The descriptor becomes readable when the process exits, so you can manage a child process and get its status without SIGCHLD. That allows a library to manage child processes without messing with the signal handlers of the parent process using the library. Since the file descriptor holds a reference to the kernel data structure for a process (task_struct), that makes it race-free, unlike a PID (for anyone other than the parent process), and thus unlike a path within /proc (which uses the PID). So after getting CLONE_FD in, and adding ways to use a file descriptor in place of a PID in other syscalls, I'd like to add ways to use that process file descriptor to get back information about the process instead of using /proc (such as via ioctls). While there's sadly no video available, I gave a presentation at Linux Plumbers Conference / LinuxCon that included discussion of CLONE_FD. See the slides at https://events.linuxfoundation.org/sites/events/files/slides/fd_0.pdf https://events.linuxfoundation.org/sites/events/files/slides... .
    - vezzy-fnord 11y ago
      So, similar to pdfork in Capsicum and FreeBSD?
      - JoshTriplett 11y ago
        Similar, and we specifically took pdfork into account by trying to make sure interface-compatible userspace wrappers for pdfork could exist using CLONE_FD. (For instance, we made poll() on a CLONE_FD file descriptor set POLLHUP in addition to POLLIN, since poll() on a pdfork file descriptor sets POLLHUP.) However, last I looked at pdfork, it didn't solve the problems we needed it to: 1) Most critically, processes created with pdfork still get picked up by standard waitpid/wait4 calls when they exit, which means you can't separate them from a global wait loop in the parent process. That makes it impossible to handle the child process from within a library without interfering with the parent process at all. (Similar to the problem that a process can only have a single process-wide SIGCHLD handler; those two problems together motivated the creation of CLONE_FD in the first place.) 2) It requires special calls like pdwait4 rather than just a simple read. 3) It defaults to sending SIGKILL when closing the fd, and with capsicum enabled it only allows that mode. 4) pdwait4 didn't actually exist in a functional form yet, so to work with current BSD you'd have to call pdgetpid and wait4 instead. (Which you can't do in Capsicum mode, or from a process other than the parent process.) This may have been fixed since the last time we looked at it, though. 5) pdfork only provides the semantics of fork, rather than the full semantics of clone. All that said, I'm a big fan of Capsicum and the way it rethinks core APIs and resources to function around file descriptor handles.

JoshTriplett 11y ago

> One kernel is even worse. OS research is still very young, and different types of operations need very different sorts of kernels. For an example based on the original article, getting information from /proc requires three system calls. You have to open the pseudo-file, and in the process allocate memory for a file descriptor, you have to make another system call to get the information, and then a third to close the file after you're done. That's six jumps in and out of kernel space just for one operation. As it turns out, I'm working on a solution for that exact problem, within the Linux kernel. I don't see any particular obstacles to doing so. As far as I know, Linux and BSD don't drastically differ from an "OS research" perspective. People doing OS kernel research that needs a "very different sort of kernel" tend to build a custom kernel, or run on L4 or similar. And sometimes that research makes its way into production kernels. > After all, would you be satisfied if the one kernel people settled around was the windows kernel? No, because it isn't Free Software, and nobody outside of Microsoft can change it.

i336_ 11y ago
> As it turns out, I'm working on a solution for that exact problem, within the Linux kernel. I don't see any particular obstacles to doing so. oooh. I'd be really interested to learn about this... what exactly are you doing? (What can you do?!)
- JoshTriplett 11y ago
  Identifying processes with file descriptors instead of PIDs, initially by adding a new flag to clone, CLONE_FD, that gives you back a file descriptor for the new process. The descriptor becomes readable when the process exits, so you can manage a child process and get its status without SIGCHLD. That allows a library to manage child processes without messing with the signal handlers of the parent process using the library. Since the file descriptor holds a reference to the kernel data structure for a process (task_struct), that makes it race-free, unlike a PID (for anyone other than the parent process), and thus unlike a path within /proc (which uses the PID). So after getting CLONE_FD in, and adding ways to use a file descriptor in place of a PID in other syscalls, I'd like to add ways to use that process file descriptor to get back information about the process instead of using /proc (such as via ioctls). While there's sadly no video available, I gave a presentation at Linux Plumbers Conference / LinuxCon that included discussion of CLONE_FD. See the slides at https://events.linuxfoundation.org/sites/events/files/slides/fd_0.pdf https://events.linuxfoundation.org/sites/events/files/slides... .
  - vezzy-fnord 11y ago
    So, similar to pdfork in Capsicum and FreeBSD?
    - JoshTriplett 11y ago
      Similar, and we specifically took pdfork into account by trying to make sure interface-compatible userspace wrappers for pdfork could exist using CLONE_FD. (For instance, we made poll() on a CLONE_FD file descriptor set POLLHUP in addition to POLLIN, since poll() on a pdfork file descriptor sets POLLHUP.) However, last I looked at pdfork, it didn't solve the problems we needed it to: 1) Most critically, processes created with pdfork still get picked up by standard waitpid/wait4 calls when they exit, which means you can't separate them from a global wait loop in the parent process. That makes it impossible to handle the child process from within a library without interfering with the parent process at all. (Similar to the problem that a process can only have a single process-wide SIGCHLD handler; those two problems together motivated the creation of CLONE_FD in the first place.) 2) It requires special calls like pdwait4 rather than just a simple read. 3) It defaults to sending SIGKILL when closing the fd, and with capsicum enabled it only allows that mode. 4) pdwait4 didn't actually exist in a functional form yet, so to work with current BSD you'd have to call pdgetpid and wait4 instead. (Which you can't do in Capsicum mode, or from a process other than the parent process.) This may have been fixed since the last time we looked at it, though. 5) pdfork only provides the semantics of fork, rather than the full semantics of clone. All that said, I'm a big fan of Capsicum and the way it rethinks core APIs and resources to function around file descriptor handles.