[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1219164367.10772.420.camel@koto.keithp.com>
Date: Tue, 19 Aug 2008 09:46:07 -0700
From: Keith Packard <keithp@...thp.com>
To: Nick Piggin <nickpiggin@...oo.com.au>
Cc: keithp@...thp.com, Dave Airlie <airlied@...il.com>,
Christoph Hellwig <hch@...radead.org>,
Eric Anholt <eric@...olt.net>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Export shmem_file_setup and shmem_getpage for DRM-GEM
On Tue, 2008-08-19 at 20:00 +1000, Nick Piggin wrote:
> Not exactly sure what you mean by this. But I would like to see an effort
> made to use existing userspace APIs in order to do this swappable object
> allocation over tmpfs scheme. As I said, I don't object to a nice kernel
> implementation, but we would be in a much better position to assess it if
> we had an existing userspace implementation to compare it with.
We need to allocate objects from kernel mode to get the console running.
I'd prefer to let that occur before user mode was available. Also,
emulating the existing fbdev syscall interface will require that we
allocate objects within the kernel.
Hence, the question about how we should create objects from kernel mode.
I think we can do this with a series of VFS function calls. Would that
series of VFS calls be preferable to directly accessing the existing
shmem API?
Another alternative is to improve the existing shmem API to better
capture what we're trying to do here. Both drm and sysv shm just want
anonymous pages that are backed by swap. If we started from scratch,
what API would we like to have here? Would we have it support both shmem
and hugetlbfs?
--
keith.packard@...el.com
Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)
Powered by blists - more mailing lists