On Wed, Sep 28, 2016 at 11:56:36PM -0400, Theodore Ts'o wrote: > On Thu, Sep 29, 2016 at 12:16:29PM +1000, Dave Chinner wrote: > > > > So, sooper-s3kr3t internal google stuff that you can't talk > > about and may never see the light of day. When it is announced > > and released, then let's talk about integration.... > > Fair enough, I'll carry it as an out-of-tree patch at > > https://github.com/tytso/xfstests > > ... for anyone else who might find it useful for their purposes. > > > xfstests is not designed for validating system call API > > compliance - it's for exercising /filesystem implementations/. > > xfstests assumes the syscall API is valid and working, and tries > > to break the underlying storage implementation. As such, your > > example really isn't something you should be using xfstests for > > - it doesn't test anything like what is needed to verify that > > the "VFS emulation" is valid and complete and working exactly as > > documented in the linux man pages. > > Who says there isn't an underlying file system implementation > which we want to test? In fact we *are* using the right tool for the job. Nobody outside the google echo chamber can say, Ted, because you haven't told anyone what it is you want this for. binary emulation layers (your example, not mine) don't implement persistent filesystems - they translate syscalls. So let's revist this when everyone has the same information available and we can have an informed discussion.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
