The 2D part does need a kernel mode driver though, for features such as
suspend-and-resume, and for getting rid of the security issues associated
with /dev/xsvc & allowing user space processes to have ring-0 access so
that the Xserver can access the hardware from user space.
Solaris & Linux are both moving this direction on x86 (Solaris has always
had kernel mode drivers for graphics on SPARC) - see:
http://www.keithp.com/blog/kernel-mode-drivers.html
http://blogs.sun.com/alanc/entry/moving_x86_video_drivers_into
-Alan Coopersmith- [EMAIL PROTECTED]
Sun Microsystems, Inc. - X Window System Engineering
Freeman Liu wrote:
Hi, Douglas,
Glad to hear from you.
As for moving X drivers to kernel, I have investigated on it. We must be
aware that nowadays the display card include two functions, 2d and 3d,
the first part does not need dma, thus can be implemented in user space
conveniently, as the 3d part, it relies on dma heavily and must have a
kernel driver. The advantages of user space drivers is portability,
while it make the implementation some complex. IMHO, the situation of 2d
user space drivers plus 3d kernel drivers will last for a long period
beside all these small bearable flaws.
Respecting to interrupt handling, it works now on the speed of about 7
times slower. It works well for the audio device. I will try other
hardware later.
For register access, thanks to pcitool, it is not a problem anymore.
The DMA part, which I think is the most dangerous part, is far from
perfect, though it works.
You suggestion on microkernel approach is a very good one. I think we
should go this direction, in an evolutional way. We should leave the
primitive hardware operation mechanism inside kernel, while how to
leverage them to achieve specific function outside in user space. I will
look at the minix approach you referred. Thanks a lot.
Looking forward to talk with you again.
Thank you
--Freeman
Douglas Atique wrote:
Hi Freeman,
I have seen blogs talking about the opposite direction (I recall
having read some blog entry about moving X drivers into the kernel).
However, with every new build of Solaris Express, I get some good or
bad surprise. The bad ones usually have to do with new kernel modules
that don't like my hardware and make my machine hang on boot or
thereafter. So to me it looks just great if the kernel becomes really
compact and changes seldom or never and new drivers are added as SMF
services running in userland. I don't know much about the feasibility
of this, but I have heard about others that tried.
If you are really going to carry out this project, I recommend you
take a look at this thesis:
http://www.cs.vu.nl/~jnherder/masters-thesis.php
It talks about some primitives that could be provided by the kernel so
that it handles high-level interrupts on behalf of user mode drivers.
Direct hardware access is, I think, the greatest difficulty of moving
a driver out of kernel space. Maybe you can have some inspiration on
Minix's approach.
Good luck.
-- Douglas
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
