[linux-fbdev] Re: vm86 in kernel [was: vesafb...]

[James A Simmons]

On Wed, 26 Jan 2000, Aki M Laukkanen wrote:

> On Tue, 25 Jan 2000, James A Simmons wrote:
> > > cleaned up/completed as planned (Alan)? In this case would you accept
> > > calling PMI functions from kernel-space or should it be done from
> > > user-space?  
> > The purpose of fbdev was to have mode setting in the kernel. I know
> 
> So you're saying that the patch shouldn't be included in the kernel?

No. I'm saying be careful what you allow from userspace :)

> Obviously you misread. Jeff Garzik's proposal was to get rid of the
> separate dev/vesafb device and do the communication via /dev/fb ioctl
> interface. Supposedly all the people in the video group are "trusted" but
> that nevertheless opens a whole new can of worms.

I did misread you. Soory about that. I agree with the idea of extra ioctls
to /dev/fb would be better. Their are two reason for the "trusting"
problem. The reason /dev/fb needs root is because of VT switching and
the ablity to mapping MMIO regions . Some cards are brain dead that they
mix mode setting registers with accel registers :( I have patches that
deal with this so /dev/fb will be safe in the future.

> See my vesafb patch and vesafb_dev_close(). Nobody's trying to restart
> anything. At close time all the framebuffer operations are reverted back
> to their `dummy´ counterparts which simply return an error or do nothing
> if the user tries to change modes etc. 

Okay.

Codito, ergo sum - "I code, therefore I am"
James Simmons                                                      (o_
fbdev/gfx developer                                      (o_  (o_ //\
http://www.linux-fbdev.org                              (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/