The HyperNews Linux KHG Discussion Pages

Possible, but takes work

Forum: The Linux Kernel Hackers' Guide
Re: Question calling interupts from linux (John J. Binder)
Re: Sad You can't (Michael K. Johnson)
Re: Question Calling BIOS interrupts from Linux kernel (Ian Collier)
Keywords: interrupts callable from C.
Date: Thu, 25 Sep 1997 20:27:48 GMT
From: Michael K. Johnson <johnsonm@redhat.com>

I'm sorry, I didn't notice that he was talking about software interrupts in the BIOS. Not paying close enough attention...

In order to call anything in the BIOS, you need to put the processor in VM86 mode. From user mode, it is possible to do that in vm86 mode if you map the BIOS into the process's memory. dosemu does this in order to use the video bios. However, you won't be able to just call int 0x10. Linux reprograms the interrupt controller on boot. You can put code in to see what slot 0x10 points at and save that pointer and call it directly.

From kernel mode, you can look at how the APM bios calls are made in the file /usr/src/linux/drivers/char/apm_bios.c and copy how it is done there. Even in kernel mode, you need to get a pointer rather than blindly call int 0x10. And for 16-bit bioses, you need segment/offset, then use them to do an lcall. See arch/i386/boot/setup.S and arch/i386/kernel/setup.c for how these kinds of parameters get passed into the kernel on startup. The are recorded before the kernel goes into protected mode at all.

Note that this is completely dependent on not booting with a protected-mode boot utility that starts up the kernel already in 32-bit mode. Several such utilities exist, but they aren't much used at this point by Linux folks.

However, calling the BIOS is slow. It's fine for the apm stuff that doesn't need to be high-performance, but I wouldn't touch it for a video driver. Every call involves saving the processor state, changing processor mode, calling the bios, changing processor mode, and restoring the processor state. Assuming that you are calling into the kernel to do this, that's really an extra set of context switches. If you are doing it in a user-level library, you have device contention to deal with, as well as security issues, since you certainly need to be root to do this.

If I were in your shoes, I would try to use this interface only to set up a framebuffer, and then have the X server write to memory which is mmap()ed to that framebuffer. That will probably be faster than thunking through a 16-bit bios call level for every screen operation... There's a generic Linux framebuffer interface that is used on Linux/m68k, Linux/PPC, Linux/SPARC, and I think other platforms as well. You can start looking at that by reading /usr/src/linux/drivers/char/fbmem.c; I don't know the interface in any detail and can't help you beyond that.

If the bios is a 32-bit bios, you can skip saving state; that won't be such a problem. But since it wants a real mode address for a block in memory, I doubt that's the case.

Good luck, but I won't be able to be much more help than this.