The many software interrupts of Linux

So I'm working on coverting a project over from a DOS/Windows environment to a Linux environment.  The issue is that there are some custom written interrupt handlers that are used in the project, INT 60h to be exact.  In the DOS/Windows environment, the advantage is that this is a free interrupt that can have the vector address changed without any concerns for f-ing the OS.  However, despite the open-source nature of Linux, I can't seem to find something as simple as a list of all the software interrupts and what they direct to for Linux.

To make a long story short, does anyone know the list of all software interrupts for Linux and what they do, or know of where on the web you find it?  Google is unfortunately not being my friend for this.

Oh, I see. Software interrupts were used in MS-DOS because it has no virtual memory spaces. They aren't used in Windows NT or Linux, as you have kernel calls for it.

When a process is loaded, it's given a virtual memory space where it sits alone with all its threads, shared memory segments, the OS, and the hardware devices mapped to RAM. The process can't access other processes' memory or screw them, and the system will allocate real memory for all the memory pages you "touch". Part of these memory pages might be actually swapped to disk (or they might be memory mapped files), but this is handled transparently.

To call kernel functions, the process just calls a function in a specific address which is the same for all processes. The compiler will know what to do; just use the functions described in man, like open or dup.

>>2
and you get a cookie for doing your own homework!

Note: I'm >>2 and I'm not >>1. The "O I C" was me just understanding what did >>1 miss.

It is called talking to the bear. Everyone should explain their problem to the bear. Then if they still have a problem, go to someone who can help.

1 here again.

So Linux offers no extra interrupts to make use of, eh.  So what would be the solution to my problem under Linux?  I need some way of making an interrupt handler for external processes to call and make use of.  Is there a way to write my own kernel call?

>>6
While you can do that, you probably want to make a library. Processes may load any library and run it. You can even distribute it in compiled form (although Linux people will tell you it's against religion to). Google for how, there should be tutorials or guides. Oh, and if you make a library, please, PLEASE make next versions backwards compatible.

I suppose I need to clarify even further.  In essence what I am doing is I have a program that starts up and manages other processes.  As these processes run, they make "system calls" by interrupting to an interrupt function that is defined in the main program through a re-mapped interrupt number that was unused.  So what I'm saying is that I don't need to be making system calls to the Linux kernel but system calls to the main program I have written.  So in the end I still need access to an interrupt.  I find it hard to believe that Linux would deny all interrupts, that's kind of ridiculous.  I mean, sometimes you need to write your own interrupt function.

gb2/DOS

>>9
Try and make a serious post here.  The fact is interrupts are a hardware level implementation.  Since an OS is built on top of the hardware, that means that the OS uses interrupts.  gb2/school and relearn how computers work.

>>8
I don't need to be making system calls to the Linux kernel but system calls to the main program I have written
Yes, but you can't or want to hook interrupts in modern OSes for a number of reasons. What I suggested is that you make a library offering the functions you need to call from the other processes. That library would be what you call "main program", and separate programs would be what you call "other processes".

I find it hard to believe that Linux would deny all interrupts, that's kind of ridiculous.
You don't deal with interrupts in software other than the kernel and device drivers. The kernel and drivers provide you with functions which are called from everything else. You can add functions to the kernel if you need to, but you can also create libraries which is what you want most times.

The fact is interrupts are a hardware level implementation.
As I said, hardware interrupts are handled by the kernel and device drivers; software interrupts (i.e. what you used to hook and call with the "int" processor instruction in MS-DOS) are good for nothing and are no longer in use, really.

gb2/school and relearn how computers work.
I don't want to sound rude or anything, but gb2/school and learn how operating systems work.

but that's just it, I am writing my own device drivers, thus the need to access interrupts.  And I do know how OS's work, so stop being rude.

You know what, doesn't matter.  I finally managed to find a list of all the software interrupts of Linux.  Linux uses int 80h to invoke its system calls.  That's really all I needed to know before writing my own interrupt calls so I know which interrupts to leave alone.  So no further need for the thread.

You never mentioned you're writing a device driver; in >>8 you had said you were writing some kind of process manager, and if that's the case, then you don't need to hook any interrupts.

If you are writing a device driver (i.e. a driver that controls hardware), you *may* want to use an IRQ (hardware interrupt), but you won't be using software interrupts (i.e. the ones in MS-DOS), and you won't be servicing anything through interrupts either. Software that uses your driver will have to call functions, not interrupts.

>>14 wrote before seeing >>13

Still puzzled at what you are actually doing and trying to accomplish.

You can look at the address of the IDT (Interrupt Descriptor Table, where the address of the interrupt handlers are) from userland, using the SIDT instruction. After that, you can read and write to it using /dev/kmem (since the address it'll return is in the kernel address space).
You'll have to be careful when writing to it that the address of your new handler is in the kernel address space as well, or any program that'll try to use the interrupt will segfault (unless you do some other magic to make sure that the location of the handler is mapped to the same address for every process (you could do that by mmapping the code of the handler with a MAP_FIXED address, for every program that needs to use it)).

Interrupts are obsolete. Use OS calls

>>17
FrozenTroll, stop bumping these old threads.
Interrupts are not obsolete, go read your fucking processor manual, how do you think exceptions get handled, without them, you scheduling tasks, debugging, handling errors(real ones, or self caused exceptions which should handle cleanly) in applications works? Calling an interrupt directly instead of a using a syscall is a matter of preference for a systems developer, the methods are nearly equivalent.

Lain.

FOLLOW THE NEW GNAA TWITTER AT http://twitter.com/Gary_Niger

<-- check em dubz