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

From: Aki M Laukkanen (amlaukka@cc.helsinki.fi)
Date: Wed Jan 26 2000 - 11:40:33 EST

  • Next message: Richard B. Johnson: "Re: [PATCH] root-hopping for pre-2.3.41-3"

    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@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/



    This archive was generated by hypermail 2b29 : Wed Jan 26 2000 - 17:16:00 EST