linux-kernel - Re: [PATCHSET] FUSE: extend FUSE to support more operations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 13 Nov 2008 14:54:39 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Miklos Szeredi <miklos@...redi.hu>
CC:	fuse-devel@...ts.sourceforge.net, greg@...ah.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCHSET] FUSE: extend FUSE to support more operations

Miklos Szeredi wrote:
> On Wed, 12 Nov 2008, Tejun Heo wrote:
>>> Comments about the others:
>>>
>>>   0002-FUSE-pass-nonblock-flag-to-client.patch
>>>
>>> this is not needed, f_flags are already passed to userspace for read
>>> and write.
>> Hmmm... I'll try to find out whether I can use f_flags.  There was
>> something that prevented it from working properly.  I'll dig.
> 
> Support for this was missing from libfuse, but now I fixed that in the
> CVS version.

Yeah, right, it can just use fi.flags.  0002 dropped.

>>>   0004-FUSE-implement-direct-lseek-support.patch
>>>
>>> this is trickier to get the interface right I think.  If we want to
>>> allow filesystems to implement a custom lseek, then we also want them
>>> to keep track of the file position, which means we must differentiate
>>> between a write(2) and a pwrite(2) and similarly for reads.  AFAICS
>>> this isn't needed for CUSE so we can leave this to later.
>> Read/write already passes @offset, so the only thing required is an
>> extra flag there.  I mainly wanted a way for a CUSE server to veto lseek
>> with proper error and still think it's better to have this as we don't
>> really know what wacky users are out there.  What do you think about an
>> extra flag?
> 
> OK, but that's gonna involve a fair bit of API churn, and I'm not sure
> it's worth it at this stage.  If this is not needed for the OSS
> emulation, I think we should postpone it.

Alright.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/