linux-kernel - Re: [fuse-devel] [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>] [day] [month] [year] [list]

Date:	Tue, 14 Oct 2008 23:04:27 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	matt.craighead@...ifersystems.com
CC:	miklos@...redi.hu, tj@...nel.org, fuse-devel@...ts.sourceforge.net,
	greg@...ah.com, linux-kernel@...r.kernel.org
Subject: Re: [fuse-devel] [PATCHSET] FUSE: extend FUSE to support more operations

On Tue, 14 Oct 2008, Matt Craighead wrote:
> > The other is that I really
> > really don't want people to start implementing new custom ioctls for
> > their filesystems, as I think that way lies madness.
> 
> Do you have a proposed alternative for file systems that need complex
> non-standard file system operations?  I think the suggestion on the web site
> was to use get/setxattr.  I tried that and found two problems:
> 
> 1. there's no bidirectional version that both sends arguments to the
> operation and receives more than just a status back in a single API call --
> you can get, you can set, but you can't set and get extra info back
> 2. xattr's are limited in size by the kernel; large ones get truncated

Another alternative is to use some sort of out-of-band communication
with the server (socket, shared memory, etc).  Doesn't suffer from
either of the above issues and does not have the limitations and
implementation problems (having to access another process's address
space directly) of ioctls.

OTOH if you can solve it with standard file operations within the same
namespace as the regular files, that's the best solution.  Like you
said you get network transparency, and you also let normal tools
operate on the special control files, which can be a very powerful
thing (think scripting).  You'd never get that with ioctls, and that's
one of the reasons why ioctls suck.

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/