On Mon, Aug 31, 2020 at 09:34:20AM +0200, Miklos Szeredi wrote: > On Sun, Aug 30, 2020 at 9:10 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > > > On Sun, Aug 30, 2020 at 09:05:40PM +0200, Miklos Szeredi wrote: > > > Yes, open(..., O_ALT) would be special. Let's call it open_alt(2) to > > > avoid confusion with normal open on a normal filesystem. No special > > > casing anywhere at all. It's a completely new interface that returns > > > a file which either has ->read/write() or ->iterate() and which points > > > to an inode with empty i_ops. > > > > I think fiemap() should be allowed on a stream. After all, these extents > > do exist. But I'm opposed to allowing getdents(); it'll only encourage > > people to think they can have non-files as streams. > > Call it whatever you want. I think getdents (without lseek!!!) is a > fine interface for enumeration. > > Also let me stress again, that this ALT thing is not just about > streams, but a generic interface for getting OOB/meta/whatever data > for a given inode/path. Hence it must have a depth of at least 2, but > limiting it to 2 would again be shortsighted. As I said to Dave, you and I have a strong difference of opinion here. I think that what you are proposing is madness. You're making it too flexible which comes with too much opportunity for abuse. I just want to see alternate data streams for the same filename in order to support existing use cases. You seem to be able to want to create an entire new world inside a file, and that's just too confusing.
