On Tue, Apr 22, 2008 at 5:30 AM, Dave Airlie <[EMAIL PROTECTED]> wrote:
>
> So on modesetting and in F9 I've got some bits of multi-master mostly
> working, but it involves some deep hackage inside the drm core, mainly
> around sareas and locks so I want to get people to give what I've done so
> far a quick look over and let me know any possible madnesses..
>
> The patch is attached and tries to explain where its going...
>
> I'd like to backport the core changes to master to get them some up-front
> testing. This patch only really addresses i915, but also makes radeon work
> as a single master client properly.. I know nouveau needs changes and I
> think mga/savage may also...
It looks good to me, you pretty much just factor out the master role
from the device object. A few comments:
- could we delay the "make the first opener master" until it does
DRM_IOCTL_AUTH_MAGIC and add a new ioctl to say "make me a master"?
New drm masters will use the new ioctl, and old masters will continue
to become master automatically as they call DRM_IOCTL_AUTH_MAGIC to
authenticate their clients. That should be a nice way to keep old
setups working while moving to a new semantics where masters need to
explicitly issue an ioctl to become master.
- we should tie buffer object permissions to the master. unless a
client is authenticated with a master, it shouldn't be allowed to
reference the buffer objects created by other clients associated with
that master or the master itself.
- should a client be able to authenticate with multiple masters? For
example, a switcher app that animates a transition from one X server
to another. This app will need to access buffer objects from both X
servers (and should probably be a master itself) and thus need to
authenticate with both masters. Another use for this is if we want to
"containerize" a dri client (for security reasons). We create a new
master just for one client and then the x server client authenticates
with that new master. That way, client can't access anything outside
it's little domain, and only the x server can peek in, typically for
swap buffers.
- the locking just sucks more and more
- maybe this is a matter of taste, but embedding struct drm_master in
drm_i915_master_private and providing a drm_init_master() function
seems a lot nicer, makes for one less error path (which would simplify
the error handling in drm_open_helper) and is more in line with how
other subsystems do this kind of sub-classing:
struct drm_i915_master {
struct drm_master base;
/* i915 stuff */
};
int i915_master_create(...)
{
struct drm_i915_master *master;
master = drm_calloc(1, sizeof *master, DRM_MEM_DRIVER);
drm_init_master(&master->base);
...
return &master->base;
}
Kristian
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
