linux-kernel - Re: [PATCHSET] FUSE: extend FUSE to support more operations, take #2

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]

Message-Id: <E1L3W52-0007t3-PZ@pomaz-ex.szeredi.hu>
Date:	Fri, 21 Nov 2008 14:29:52 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	tj@...nel.org
CC:	miklos@...redi.hu, linux-kernel@...r.kernel.org,
	fuse-devel@...ts.sourceforge.net
Subject: Re: [PATCHSET] FUSE: extend FUSE to support more operations, take
 #2

On Fri, 21 Nov 2008, Tejun Heo wrote:
> Miklos Szeredi wrote:
> > On Fri, 21 Nov 2008, Tejun Heo wrote:
> >>> I removed ->unrestricted_ioctl() and associated code because it really
> >>> doesn't make any sense: the high level lib won't be used for CUSE
> >>> stuff, otherwise unrestrited ioctls are not allowed (and the interface
> >>> is rather horrible anyway).
> >> Well, CUSE highlevel interface piggy backs on FUSE so it requires
> >> unrestricted_ioctl() there for it and ossp does use it.
> > 
> > I thought it uses the lowlevel interface.  Why doesn't it do that?
> 
> Well, because it's simpler that way and people would be more used to it?
>  It's just easier when you implement a method which returns something
> and looks similar to the respective file operation.

Ah, that.  Yeah, it's more intuitive, but that comes at a price.  I'm
not sure that for CUSE it's worth it.  As I said the biggest feature
is having paths, the others are not that important (like allocating a
buffer for read, that's really not too complex to do in each CUSE
driver).

> > For CUSE there's really no point in going through high level
> > interface, since there's just one file involved, so the path name
> > generation (the main feature of the highlevel lib) doesn't make any
> > sense.
> 
> Well, the choice was mostly for convenience as there also are a few
> places where high level interface wraps things better a bit.  Converting
> wouldn't be difficult.  Do you think it's important?  I think keeping
> things as parallel to FUSE as possible is more important.

I wouldn't care very much, if it weren't for that horrid
unrestricted_ioctl().  Not your fault, the interface is just not well
suited to that.

Miklos
--
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/