New DRM model

[Benjamin Herrenschmidt]

> The problem here is that my DRM driver and FB are both claiming the same PCI IDs
> and the kernel will only let one load. Same for putting entries into sysfs. The
> kernel is simply not designed to support two device drivers trying to control
> the same piece of hardware.  So I'm not saying remove fb, I'm saying that you
> have to choose, FB or DRM. They only reason the sharing works right now is
> because DRM runs in stealth mode and plays with all of the hardware without
> letting the kernel in on the fact. 

But nothing prevent us from having a low level "stub" driver claiming
the resources and both the DRI and the FB driver layer on top of that.

Actually, it would even be simpler to have your DRI radeon be part of
radeonfb at first ;)

> I also recognize that FB serves a useful purpose. So I'm trying to modify DRM to
> support the areas that FB serves. That's what made me come up with the idea of
> booting console to user space and eliminating the TTY/VC stuff. The TTY/VC is
> single user by design -- all of my system have multiple video cards. User space
> console could easily support a keyboard for each screen allowing multiple users.
> I thought this might be valuable in a class room/internet cafe type setting.

I'm perectly fine with full-featured VT emulation & VCs beeing a all
userspace implementation. We just need to be careful about keeping an
"emergency" channel for printk.

In fact, the kernel does really few printk's when normal operations are
going on. Probably close to all of them are actually valuable
informations that we may just let crash on top of whatever is frontmost
at this point, provided we can get proper engine discipline in place.
That is having basically an in-kernel lock that is taken when actively
tweaking registers. The debug path would trylock on this. If that fails,
the printk is deferred to something like work queue. If that succeed,
we synchronously stop the CCE, wait for everything to be idle, blast
the text using a very simple low level text engine (like the one I use
for early boot debug on ppc), and restart the CCE engine.

That's just an idea at this point... if we go that way, we may want
to still use the console loglevel to avoid having things like ethernet
link change messages override the Xserver on normal setups :)

> It would be fun to convert DRM to a read/write model. Maybe someone else will
> chip in with that piece of work. How about using IDL to describe the interface
> and using the IDL compiler to generate the stubs? Code for serializing the IDL
> data area exists in Mozilla's xpcom library.  A great big 2.7 project could be
> to convert everything from IOCTLs to marshaled IDL.

Hrm.... I'll leave that debate to others ;)

Ben.