Re: [PATCH] char: xillybus: use stream_open for stream semantics

[mdshahid03]

Hi Eli,

Thanks for the detailed explanation and testing in HW.

I think, if this doesn not break anything and using stream_open()
for these channels more logical ,then ,it make sense to use it.

Thanks
Shahid.

On 2026-11-02 12:23 +0100, Eli Billauer wrote:
> Hello Mohammad,
> 
> On 31/10/2026 9:36, mdshahid03@xxxxxxxxx wrote:
> > Use stream_open() to mark these channels as streams and
> > disable unnecessary file position handling,
> 
> The difference between stream_open() and nonseekable_open() is that the 
> former sets FMODE_STREAM and clears FMODE_ATOMIC_POS. I made a quick 
> test run, and FMODE_ATOMIC_POS isn't set in either case. As 
> FMODE_ATOMIC_POS is clear, no lock is taken while updating fpos either way.
> 
> So in effect, the only difference is that FMODE_STREAM is set. Frankly 
> speaking, I'm not sure in what way this matters, if at all.
> 
> > allowing read
> > and write operations to run concurrently.
> 
> I checked that with hardware. There's no problem running read() and 
> write() concurrently even before this patch. And I don't see why there 
> would be a problem.
> 
> It seems like FMODE_STREAM was supposed to replace FMODE_ATOMIC_POS 
> somewhere back in 2019 with Linus' commit 0be0ee71816b ("vfs: properly 
> and reliably lock f_pos in fdget_pos()"). That is where he urged the 
> move towards stream_open(). But then he reverted it with commit 
> 2be7d348fe92 soon afterwards.
> 
> All in all, I don't know what to say about this. Calling stream_open() 
> does sound more correct, and nothing broke with this patch. But I'm 
> generally unhappy fiddling with code unless it fixes something.
> 
> Regards,
>     Eli
> 
>