>>>>> " " == Michael Eisler <mre@Zambeel.com> writes:
> I'm not a Linux kernel literate. However, I found your
> assertion surprising. Does procfs do page i/o as well?
No. It has its own setup.
> file.c in fs/nfs suggests that the Linux VFS has non-page
> interfaces in addition to page interfaces. fs/read_write.c
> suggests that the read and write system calls uses the non-page
> interface.
Yes. fs/read_write calls the NFS subsystem. The problem then is that
NFS uses the generic_file_{read,write,mmap}() interfaces. These are
what enforce use of the page cache.
You could drop these functions, but that would mean designing an
entire VFS for NFS's use alone. Such a decision would have to be very
well motivated in order to convince Linus.
>> As far as I can see, the current use of the page cache should
>> be safe as long as applications respect the locking boundaries,
>> and don't expect consistency outside locked areas.
> Then the code ought to enforce page aligned locks. Of course,
> while that will produce correctness, it will violate the
> principle of least surprise. It might be better to simply
AFAICS that would be a bad idea, since it will lead to programs having
to know about the hardware granularity. You could easily imagine
deadlock situations that could arise if one program is unwittingly
locking an area that is meant to be claimed by another.
I'm not clear on why you want to enforce page alignedness though? As
long as writes respect the lock boundaries (and not page boundaries)
why would use of a page cache change matters?
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:13 EST