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

[Aki M Laukkanen]

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?

> and also some things you can only do from the kernel in reasonable time
> (ex interrupt handling). 

There are no interrupts involved in VESA/VBE.

> > When having a
> > separate device for the daemon, the access can be restricted to root
> > only.  
> Why should you make it so only root can change a video mode ? Like me

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.

> > Second advantage to a separate device is the ability to control
> > having only one instance opened at any time.  
> Look at linux/include/linux/fb.h in the newest kernel. Look at struct

See above.

> > Third kernel gets
> > notified immediately if the daemon dies and can act accordingly. 
> When daemons normally die you have to start them yourself. I have cron
> jobs that. I never seen a kernel that restarts a deamon. 

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. That functionality in the patch is
not currently finished though. All the consoles should be changed to the
mode which is currently on, the request queue should be flushed and I'll
have to think about the concurrency issues.

-- 
D.


-
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/