> Ahh. Well, this is definately one of those cases where you don't
> want to use vmalloc. In fact, don't even use the sysv code as a
> starting point since it's a mess. We've discussed a few different
> ways of doing this on linux-mm a while back (archieves on
> ftp.kvack.org/pub/archives/linux-mm/), but I think the best way to
> handle it is along the lines of what Eric did for his shmfs: provide
> a set of inode operations to back the vma. That way, all the
> duplication of (sometimes trick) mm code is eliminated. Eric had a
> rather complete filesystem, but it was broken when the page cache
> code was changed. Nevertheless, it's a good starting point.
Yes I know about Erics shmfs, but I do not know if it will be
available in the near future. I had some conversation with him about
our work and we agreed that it would be fine to do it in parallel and
compare both implementation.
I agree that his idea is much nicer and in the long run probably the
better solution. We could get rid of all this special handling for
SYSV shm. Also the SYSV stuff is really ugly, but: it is just now
the only implementation we have and shm is really needed for big
applications like databases and R/3.
Further the implementation changes to be able to do posix shm over
SYSV shm are really small since the possibility to map arbitrary parts
of a shm segment are internally available. (I wrote a little patch to
access this via shmctl and it is about 40 lines). The only thing
missing is the ftruncate stuff. This needs a rewritten array
allocation. But this is apparently needed anyways as we agreed before.
So I think I will proceed with my work, but I will really happily drop
it as soon as Erics shmfs is really available and has proven to be
stable.
What do you think?
Christoph
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/