On Thu, Jun 16, 2005 at 06:57:54PM -0700, Andrew Morton wrote:
> hm, what a lot of filesystems.
>
> bix:/usr/src/linux-2.6.12-rc6> grep -rl simple_dir_operations .
> ./drivers/usb/gadget/inode.c
> ./drivers/usb/core/inode.c
> ./drivers/isdn/capi/capifs.c
> ./drivers/oprofile/oprofilefs.c
> ./drivers/misc/ibmasm/ibmasmfs.c
> ./fs/libfs.c
> ./fs/debugfs/inode.c
> ./fs/autofs/inode.c
> ./fs/devpts/inode.c
> ./fs/hugetlbfs/inode.c
> ./fs/ramfs/inode.c
> ./include/linux/fs.h
> ./net/sunrpc/rpc_pipe.c
> ./kernel/cpuset.c
> ./security/selinux/selinuxfs.c
> ./ipc/mqueue.c
> ./mm/shmem.c
>
> I can't think of any reason why any of these would want fsync(dir_fd) to
> return -EINVAL.
Logically I think we can only expect 'real' filesystems with block
devices or similiar behind them to do something with fsync and
everyone else to be more or less undefined.
Undefined creates problems I guess so I guess simple_dir_operations
could return 0 (it sorta does make sense, if you have no backing store
you are always in-sync?).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
