Thanks for the feedback so far. Correcting cinap's email address on this reply.
I don't believe having a #c/magicfds file is a net win. Certainly if it is writable / configurable, then much of the benefit is lost. The benefit is not having to do set up like opening files and holding an fd open at process startup, even temporarily. Like rfork(2) or sbrk(2) or other system calls, I argue that these specific operations (read time and read entropy) have become so fundamental to modern programs that they should be available without the ceremony and conceptual overhead of managing long-term fds. A readable one might be useful as documentation, but if it's a hard-coded set then the kread(2) man page should suffice. As for user-space time access, it is true that on 386 and amd64 we could use RDTSC and saved clock parameters. We've actually moved away from that on basically every operating system at this point, because the parameters do change, and we need to know when to update them. Or the kernel would have to share a memory page with the parameters with the user process, and then that layout becomes part of the kernel interface. Of course we could add shared code that the kernel leaves to be called as well. All of that seems too complex and bespoke. (On Linux that's exactly what happens, but I repeat myself.) And I don't know what we'd do instead on arm. The Blue Gene system call batching also seems a bit much to me, especially since (1) we want to not have to keep the fd open, (2) we don't want to hard-code the target pointer for the read, and (3) ideally we don't want to go through a per-process setup dance that includes opening files each time a process is created. I wouldn't mind the per-process setup if (1) and (2) were not problems as well. Best, Russ ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T59810df4fe34a033-M8cf21f21f8efb2e6ad43994c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
