Re: [PATCH] common: add support for the "local" file system type

["Theodore Ts'o" <tytso@mit.edu>]

On Tue, Sep 27, 2016 at 08:18:14AM +1000, Dave Chinner wrote:
> 
> Ignoring the code changes for the moment - what's the reason/use
> case for running /kernel/ test suites inside a user container with
> such restricted access to filesystems and devices? Especially
> considering test failures can take the kernel down, which will kill
> /everything/ on the machine, not just the container.
> 
> This doesn't make a whole lot of sense to me - who is going to use
> this and what extra test coverage does it bring to the table
> compared to just running inside a guest VM with full privileges?

So I'm doing this work on behalf of a team who is working on an
to-be-announced project, so the details aren't mine to give.  However,
I can say that obviously, if they could do that they would.

Let me give an other example where this might be useful.  Suppose you
are using the Windows Subsystem for Linux which emulates system calls
for Linux, so you can run most Linux binaries, but for which certain
system calls simply aren't implemented, either for security reasons or
because they just don't make sense (e.g., reboot, kexec, mount,
unmount, etc.).  To the extent that such a subsystem purports to offer
Linux compatibility, and has a Linux VFS emulation, it would be useful
to have a "local" file system type which doesn't try to do any mounts
and unmounts, but which could otherwise stress test the file system
layer and find bugs in the system call emulation for file systems,
that would be a good and useful thing to do.

As I recall, AIX also had a Linux system emulator (the better to run
the huge numbers of commercial third-party Linux binaries :-), and if
I recall correctly, it didn't support mount and unmount either.
NetBSD also has a Linux emulation layer (and in the past, an Irix
emulation layer), and again, it's not clear that it would extend to
things like mount/unmount --- nor would it really need to in order to
be useful for most of their desired use cases.

Cheers,

						- Ted