On Sat, 11 Sep 2004, Alan Cox wrote:
> On Sad, 2004-09-11 at 18:02, Linus Torvalds wrote:
> > My personal preference for this whole mess has always been the "silly
> > driver" that isn't even hardware-specific, and really does _nothing_ on
> > its own. This one would be the only thing that actually reserves the IO
> > regions and "owns" the card from the respect of the resources. EVERYBODY
> > else would be a "stealth" driver. Not just DRM.
>
> How do you plan to deal with hot plug. At the point the "silly driver"
> (in my case this is the vga class driver) claims the PCI device and
> propogates things onwards hotplug seems to work.
Since the users would have to use the locking methods, they'd all be
dependent on it, so it would either be compiled in, or "modprobe" would
just automagically load it.
And yes, it would just attach directly to any VGA class device on PCI (and
have some other way to detect any other kind of graphics devices).
If we make it small, simple and generic enough (serialization isn't really
a gfx-only thing), we could frigging attach it to _every_ device in the
system, at which point it doesn't even need to "attach" any more. It would
just be there. That obviously requires that it really only do a _very_
generic set of minimal locks.
> The second fun bit is that Jon is right that in some cases the fb driver
> for a card may want to use the DRI layer if loaded - but only some and
> only in a controlled manner. Sometimes the drivers want to co-operate
> sometimes they just want to avoid beating each other senseless.
They can put whatever data they want in the shared data area (called
"gfx_data" in my previous pseudo-code-posting). They'd need to know about
each other if they want to cooperate, of course. The "silly driver" never
uses the data area itself, really. It just contains a few predefined
things, like the lock pointers, but the silly driver doesn't really even
access them, it's up to the low-level drivers to pass in the proper lock
to the silly driver.
> > Now, the reason why these things are _pointers_ to locks rather than
> > locks themselves is that maybe some hardware ends up sharing resources
> > between these things (maybe "modeswitch" needs the accelerator to
>
> How do you deal with making sure the lock doesn't get freed and knowing
> who needs it still ? I ended up with locks in the shared area itself
> because I couldn't figure that one out ?
That's exactly what I would do. See the example I sent out.
> Linus let me run what I have now past you for comment (the code isnt
> working yet since I've been having a fight with the class code)
Please realize that I have not a _frigging_ clue what I'm talking about.
I'm just listening in to the flame war, and throwing out suggestions in
the middle to try to get the discussion going _forward_. I hate seeing
hundreds of emails in my mailbox that don't seem to actually make any
_progress_.
So my comments are likely worthless.
Linus
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
