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 21:14:21 +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 Thu, 13 Nov 2008, Tejun Heo wrote:
>> I don't really mind people doing strange things in userland as long as
>> it's safe but you're the maintainer.  It's a bit strange to export the
>> feature only for CUSE, so I'm a little bit hesitant.
> 
> You are starting from the fact that ioctl is a good API.  It's not,
> it's a bad API, so I don't want to encourage the use of it.

Heh heh, I don't think ioctl is a good API but it's fun to watch people
screw up themselves.  :-P

>>  I wanna make it
>> useful for both.  So, at the kernel level, only well formed for FUSE and
>> everything goes for CUSE.  Does that sound good enough?
> 
> With additional restrictions for ptraceability yes.  But if you just
> restrict it to CUSE at first, that's fine by me as well :)

It actually wasn't a big change.  Now only well formed ioctls are
allowed for FUSE server and kernel will dispatch the correct amount of
input data and feed back the correct amount of output data without any
retry.  With proper massaging of FUSE ioctl API, ioctl, at least for
FUSE, will be very straight forward.

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/