LUFS is a hybrid userspace filesystem framework supporting many "exotic" filesystems (localfs, sshfs, ftpfs, httpfs, socketfs, freenetfs, and nutellafs) transparently for any application. It can be regarded as doing the same job as the VFS (virtual filesystem switch) in the kernel: it is a switch, distributing the filesystem calls to its supported filesystems. However, LUFS filesystems are implemented in userspace. This would be a drawback for local filesystems where the access speed is important, but proves to be a huge advantage for networked filesystems where the userland flexibility is most important.
Snoop is a GNU/Linux file descriptor monitoring tool inspired by FreeBSD's 'watch'. It goes beyond simple TTY snooping by allowing the interception of any file descriptor. You can attach on the fly to regular files, TTYs, named pipes, character devices, and pretty much anything that is represented by a file descriptor and addressable in the standard name space.
Re: Snoop is badly chosen name
> > The "snoop" sniffer was never ported
> > to Linux[...]
> Probably because there are alternate
> solutions available, such as ttyrpld
This doesn't quite make sense: the discussion you're quoting was about name clashes with a network sniffer. A network sniffer (snoop from SVr4 according to Jorg) not being ported to linux has nothing to do with the availability of tty snoopers.
> which, while relying on patching the
> source, does not change a filp's f_op
> (which can lead to surprising crashes
> just like trying to override syscalls).
> for details.
Nice plug, but avoiding patching and rebuilding the kernel is quite a feature. How many kernel versions does ttyrpld support? I seriously doubt you generated rpldhk patches for more than a handful of kernels. What happens with the people using unsupported versions (or distro-patched kernels - which probably count for more than 90% of the installed base)? The patch based approach (besides being inconvenient) simply doesn't scale.
There's also a significant difference in scope: snoop is not just a tty logger but a generic fd monitoring tool. You can attach to any open file descriptor - sockets, files, pipes - you name it. If you can find it in /proc/<pid>/fd/, you can attach to it and take a peek at what's going on in a non intrusive way.
As far as stability is concerned, I have yet to see or hear of crashes caused by the snoop module. The tty layer plays tricks with fipl->f_op too, so that in itself is not fundamentally broken. If you can spot any races please file a bug report, but as far as I can tell the f_op updates are performed in a safe manner.
Re: Snoop is badly chosen name
You do have a point but so is http://www.die.net/doc/linux/man/man1/watch.1.html vs http://www.bsdguides.org/guides/freebsd/misc/watch.php and a dozen other commands.
The "snoop" sniffer was never ported to Linux and I think the Linux package namespace is different enough from other UNIces to make this a non-issue. Heck, the availability of "snoop" on Freshmeat & SourceForge tells it all :)
Thanks for pointing it out though.