* why is O_TMPFILE multiplexed over open() instead of being a separate syscall? @ 2013-08-01 8:42 Christoph Hellwig 2013-08-02 12:59 ` Jeff Layton 0 siblings, 1 reply; 3+ messages in thread From: Christoph Hellwig @ 2013-08-01 8:42 UTC (permalink / raw) To: viro, torvalds; +Cc: linux-fsdevel Sorry for being a bit late to the game, but.. Why is the useful tmpfile functionality multiplexed over open when it has very different semantics from a normal open? In addition to the flag problems already discussed to death it also just leads to splattering of the code in the implementaiton, given that path_openat branches out really early in path_openat. What's the problem with a clear single purpose tmpfile() system call? ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: why is O_TMPFILE multiplexed over open() instead of being a separate syscall? 2013-08-01 8:42 why is O_TMPFILE multiplexed over open() instead of being a separate syscall? Christoph Hellwig @ 2013-08-02 12:59 ` Jeff Layton 2013-08-08 11:47 ` Michael Kerrisk 0 siblings, 1 reply; 3+ messages in thread From: Jeff Layton @ 2013-08-02 12:59 UTC (permalink / raw) To: Christoph Hellwig; +Cc: viro, torvalds, linux-fsdevel On Thu, 1 Aug 2013 01:42:53 -0700 Christoph Hellwig <hch@infradead.org> wrote: > Sorry for being a bit late to the game, but.. > > Why is the useful tmpfile functionality multiplexed over open when it > has very different semantics from a normal open? > > In addition to the flag problems already discussed to death it also just > leads to splattering of the code in the implementaiton, given that > path_openat branches out really early in path_openat. > > What's the problem with a clear single purpose tmpfile() system call? Agreed. A new syscall for this seems like it would be a lot cleaner. I mentioned that to Al via IRC when he first showed me these patches but he didn't like the idea (I don't recall his rationale though). I probably should have followed that up with an email to the mailing list, but the first public mention of it was the pull request... -- Jeff Layton <jlayton@redhat.com> ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: why is O_TMPFILE multiplexed over open() instead of being a separate syscall? 2013-08-02 12:59 ` Jeff Layton @ 2013-08-08 11:47 ` Michael Kerrisk 0 siblings, 0 replies; 3+ messages in thread From: Michael Kerrisk @ 2013-08-08 11:47 UTC (permalink / raw) To: Jeff Layton Cc: Christoph Hellwig, Al Viro, Linus Torvalds, linux-fsdevel, Andy Lutomirski Al (et al.), On Fri, Aug 2, 2013 at 2:59 PM, Jeff Layton <jlayton@redhat.com> wrote: > On Thu, 1 Aug 2013 01:42:53 -0700 > Christoph Hellwig <hch@infradead.org> wrote: > >> Sorry for being a bit late to the game, but.. >> >> Why is the useful tmpfile functionality multiplexed over open when it >> has very different semantics from a normal open? >> >> In addition to the flag problems already discussed to death it also just >> leads to splattering of the code in the implementaiton, given that >> path_openat branches out really early in path_openat. Independently, I happened to note the same thing while reviewing a man-pages patch that Andy Lutomirski sent. >> What's the problem with a clear single purpose tmpfile() system call? > > Agreed. A new syscall for this seems like it would be a lot cleaner. The fact that O_TMPFILE is special cased at the start of path_openat(), and that the 'pathname' argument has a different meaning solely for O_TMPFILE, does indeed suggest that this is better as a separate system call. In addition, as a separate system call, one could dispense with the hack added in bb458c644a59dbba3a1fe59b27106c5e68e1c4bd that makes O_DIRECTORY part of O_TMPFILE. In the current implementation, O_TMPFILE is crudding up an already overloaded open() API with further special cases. > I mentioned that to Al via IRC when he first showed me these patches > but he didn't like the idea (I don't recall his rationale though). I > probably should have followed that up with an email to the mailing > list, but the first public mention of it was the pull request... And, unfortunately, no mention of the API change was CCed to linux-api, where it might have prodded some input from parties with an interest in the API. Al, why can this not be changed as Jeff suggested, before the API is set in stone? Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface", http://blog.man7.org/ ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-08-08 11:48 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-08-01 8:42 why is O_TMPFILE multiplexed over open() instead of being a separate syscall? Christoph Hellwig 2013-08-02 12:59 ` Jeff Layton 2013-08-08 11:47 ` Michael Kerrisk
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).