* 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).