6 ms·

Again, this would be more if you needed to emulate things like precise kernel thread semantics, page eviction strategies or whatnot. When talking about system c

Again, this would be more if you needed to emulate things like precise kernel thread semantics, page eviction strategies or whatnot. When talking about system calls (the overwhelming majority of cases), then those are usually well-defined, relatively high level "chunks" of resource management that either have corollaries or can be safely reimplemented in a utility library.

JoshTriplett 11y ago
How would you suggest reimplementing cgroups on every other POSIX OS? In particular, the behavior where an entire tree of child processes can't escape from that group? Some kernels may have an equivalent to this (though the semantics may not match), but others don't. How about prctl's PR_SET_CHILD_SUBREAPER, which makes a process act like PID 1, as the target for reparenting child processes? Or fanotify/inotify/etc? (A polling-based interface doesn't work here: it misses things due to races, and wastes power by waking up too often.) Or mount namespaces, network namespaces, and other unshare/clone flags? You could reimplement those things in another kernel, but almost certainly not in userspace unless a feature with the same semantics already exists in the target kernel.
- vezzy-fnord 11y ago
  unless a feature with the same semantics already exists in the target kernel The point is they do. For instance, Solaris has contracts (direct corollary to cgroups, actually predating cgroups). In Solaris, orphans are adopted by the kernel and init(1M) can be restarted upon a failure condition. Some BSD flavors have procctl(2). Polling-based interfaces can work, since a port does not have to be completely equivalent in terms of benchmarking, it must conform well by a cost-benefit analysis. File system event notifications are something many platforms reliably have, so that even devices with strict power management policy can incur them (or more often than not they'll incur the cost of polling regardless). Most Unixes have converged on rfork(2)-like primitives that can customize process contexts to share reasonably well. I'm not panning systemd for anything, mind you. I'm speaking in general terms. systemd is decidedly unportable, I'm more than well aware and don't have trouble with that aspect.
  - JoshTriplett 11y ago
    > In Solaris, orphans are adopted by the kernel and init(1M) can be restarted upon a failure condition. Some BSD flavors have procctl(2). Neither of which provides the same semantics as PR_SET_CHILD_SUBREAPER. Unless your desired target platform already has equivalent functionality, "porting" can't happen. It's easy enough to look at individual features and say "Solaris has something kinda like that" or "FreeBSD has something kinda like that". But Linux has quite a bit of functionality with no functional equivalent in other OSes. (And, conversely, some other OSes have functionality with no equivalent in Linux.) And I don't think it's unreasonable to make software that uses the full functionality of a target platform, rather than a less capable subset that can be made to work on other platforms. > Polling-based interfaces can work, since a port does not have to be completely equivalent in terms of benchmarking, Race conditions that cause you to miss events aren't OK, though. And even in terms of benchmarking, once people are done complaining about portable software, they complain that it doesn't run well on their platform. And most of the time they don't blame the platform for that.
    - vezzy-fnord 11y ago
      The point was you don't need subreapers, so you'd presumably just remove the relevant code.
      - JoshTriplett 11y ago
        The kernel adopting orphaned processes doesn't make PR_SET_CHILD_SUBREAPER unnecessary. If you just wanted the processes to get reparented somewhere and reaped when they exit, you could let PID 1 do that. You also seem to have intentionally ignored the general point in favor of picking apart a specific example. The solution to all uses of non-portable interfaces isn't either "you can implement a compatibility layer using features of your target OS" or "you don't really want that code anyway, just rip it out".
- tedunangst 11y ago
  Indeed, one can reimplement those things on other systems. And other systems have already done this! But forcing the use of epoll instead of an existing abstraction like libevent means that now epoll is added to the list of things that must be implemented. I could go through my code and change all the open(O_CREAT) calls to open(0x200) because that's the same thing. And then none of that code would work on linux, where O_CREAT is 0x40. Would that be an improvement?
  - JoshTriplett 11y ago
    > But forcing the use of epoll instead of an existing abstraction like libevent means that now epoll is added to the list of things that must be implemented. Only if you care about being compatible with Linux. There's a 100% Linux-compatible kernel already available, though. :) And any platform that wants 100% compatibility with Linux could always run it through virtualization. I'm not saying portability is always a bad thing; far from it. It's also not always a good thing, though. And there's something to be said for the mindset that any time spent on portability is time not spent making the best possible program for the only platform you care about. Some programs should be portable. It's awesome that Firefox, Libreoffice, and other user-level software runs on Windows, for instance, to introduce people to FOSS and make it easier to switch platforms later. On the other hand, quite a bit of low-level or server software just doesn't make sense to run elsewhere, especially now that virtualization exists. At some point, it seems like the simplest portability layer is a copy of a Linux kernel and a way to run it on your target platform. > I could go through my code and change all the open(O_CREAT) calls to open(0x200) because that's the same thing. And then none of that code would work on linux, where O_CREAT is 0x40. Would that be an improvement? No; that wouldn't be an improvement even for code that only needs to run on one platform, because O_CREAT produces more self-documenting code. On the other hand, you could write all your code using openat and friends, and never call chdir, which can make software that otherwise had to worry about the working directory much simpler. That may be an improvement, even though that code then won't run on arbitrary POSIX OSes.
    - tedunangst 11y ago
      openat is posix.

JoshTriplett 11y ago

How would you suggest reimplementing cgroups on every other POSIX OS? In particular, the behavior where an entire tree of child processes can't escape from that group? Some kernels may have an equivalent to this (though the semantics may not match), but others don't. How about prctl's PR_SET_CHILD_SUBREAPER, which makes a process act like PID 1, as the target for reparenting child processes? Or fanotify/inotify/etc? (A polling-based interface doesn't work here: it misses things due to races, and wastes power by waking up too often.) Or mount namespaces, network namespaces, and other unshare/clone flags? You could reimplement those things in another kernel, but almost certainly not in userspace unless a feature with the same semantics already exists in the target kernel.

vezzy-fnord 11y ago
unless a feature with the same semantics already exists in the target kernel The point is they do. For instance, Solaris has contracts (direct corollary to cgroups, actually predating cgroups). In Solaris, orphans are adopted by the kernel and init(1M) can be restarted upon a failure condition. Some BSD flavors have procctl(2). Polling-based interfaces can work, since a port does not have to be completely equivalent in terms of benchmarking, it must conform well by a cost-benefit analysis. File system event notifications are something many platforms reliably have, so that even devices with strict power management policy can incur them (or more often than not they'll incur the cost of polling regardless). Most Unixes have converged on rfork(2)-like primitives that can customize process contexts to share reasonably well. I'm not panning systemd for anything, mind you. I'm speaking in general terms. systemd is decidedly unportable, I'm more than well aware and don't have trouble with that aspect.
- JoshTriplett 11y ago
  > In Solaris, orphans are adopted by the kernel and init(1M) can be restarted upon a failure condition. Some BSD flavors have procctl(2). Neither of which provides the same semantics as PR_SET_CHILD_SUBREAPER. Unless your desired target platform already has equivalent functionality, "porting" can't happen. It's easy enough to look at individual features and say "Solaris has something kinda like that" or "FreeBSD has something kinda like that". But Linux has quite a bit of functionality with no functional equivalent in other OSes. (And, conversely, some other OSes have functionality with no equivalent in Linux.) And I don't think it's unreasonable to make software that uses the full functionality of a target platform, rather than a less capable subset that can be made to work on other platforms. > Polling-based interfaces can work, since a port does not have to be completely equivalent in terms of benchmarking, Race conditions that cause you to miss events aren't OK, though. And even in terms of benchmarking, once people are done complaining about portable software, they complain that it doesn't run well on their platform. And most of the time they don't blame the platform for that.
  - vezzy-fnord 11y ago
    The point was you don't need subreapers, so you'd presumably just remove the relevant code.
    - JoshTriplett 11y ago
      The kernel adopting orphaned processes doesn't make PR_SET_CHILD_SUBREAPER unnecessary. If you just wanted the processes to get reparented somewhere and reaped when they exit, you could let PID 1 do that. You also seem to have intentionally ignored the general point in favor of picking apart a specific example. The solution to all uses of non-portable interfaces isn't either "you can implement a compatibility layer using features of your target OS" or "you don't really want that code anyway, just rip it out".
tedunangst 11y ago
Indeed, one can reimplement those things on other systems. And other systems have already done this! But forcing the use of epoll instead of an existing abstraction like libevent means that now epoll is added to the list of things that must be implemented. I could go through my code and change all the open(O_CREAT) calls to open(0x200) because that's the same thing. And then none of that code would work on linux, where O_CREAT is 0x40. Would that be an improvement?
- JoshTriplett 11y ago
  > But forcing the use of epoll instead of an existing abstraction like libevent means that now epoll is added to the list of things that must be implemented. Only if you care about being compatible with Linux. There's a 100% Linux-compatible kernel already available, though. :) And any platform that wants 100% compatibility with Linux could always run it through virtualization. I'm not saying portability is always a bad thing; far from it. It's also not always a good thing, though. And there's something to be said for the mindset that any time spent on portability is time not spent making the best possible program for the only platform you care about. Some programs should be portable. It's awesome that Firefox, Libreoffice, and other user-level software runs on Windows, for instance, to introduce people to FOSS and make it easier to switch platforms later. On the other hand, quite a bit of low-level or server software just doesn't make sense to run elsewhere, especially now that virtualization exists. At some point, it seems like the simplest portability layer is a copy of a Linux kernel and a way to run it on your target platform. > I could go through my code and change all the open(O_CREAT) calls to open(0x200) because that's the same thing. And then none of that code would work on linux, where O_CREAT is 0x40. Would that be an improvement? No; that wouldn't be an improvement even for code that only needs to run on one platform, because O_CREAT produces more self-documenting code. On the other hand, you could write all your code using openat and friends, and never call chdir, which can make software that otherwise had to worry about the working directory much simpler. That may be an improvement, even though that code then won't run on arbitrary POSIX OSes.
  - tedunangst 11y ago
    openat is posix.