Terminate and Stay Resident Software (TSR) in Linux

Perhaps you could explain what you want to do?

-f

Excluding daemons, there is no equivalent of the MSDOS TSR in the Linux environment.

TSRs were a dirty hack to give a pseudo-multi-tasking facade to an inherently single-tasking single-threaded program loader that masqueraded as an operating system. They have no place in a well-designed OS like Linux.

Tell us what it is that you think a Linux TSR will do for you, and we'll tell you the /proper/ way to do it.

HTH

Your program would just wait for input. The process running your program would then not be scheduled until some input comes.

For instance, if your program awakens itself when there's data coming from a pipe, it would simply do:

read(pipe_fd, buf, sizeof(buf));

the "read" would block (that is that particular process wouldn't do anything) until someone writes to the other end of the pipe.

If to be awaken by a signal, use wait(2).

If waiting from incoming connections, use listen, from incoming data from a socket use recv... and so on.

Depends what that program is meant to do and how you want to invoke (summon) it.

A daemon is an abstract concept. It doesn't exactly map to one type of process.

However, generally we call daemon a process that has been detached from a terminal, and is not interacting with a human user.

Your description of a TSRs leaves out one important aspect.

Before exiting, the TSR links itself into some part of the OS usually by "hooking" itself into one or more of the OS interrupt handlers. It does this by replacing the original interrupt vector with an address in the TSR. If the TSR doesn't "hook" itself in then it would just be a waste of memory since there would be no effective way for it to ever be executed to do something useful (or malicous). If it is appropriate for the original interrupt handler to execute, the TSR "remembers" the original vector so it can just jump to it after doing whatever processing it intends to do. Otherwise, the TSR does a return from interrupt like the original interrupt handler would have done.

A user application trying to do the same thing under Linux will generate a protection fault when it attempts to overwrite an interrupt vector.

There are ways to augment the Linux operating system after it running. Do a Google search for "Linux loadable driver" and "Linux streams".

Hello,

Do you mean it is not running at all if no input comes through? I thought every process gets at least a time slice every now and then. Is this assumption thereby wrong?

In my opinion a process which waits would react to a time slice with something like "Oh, I've got nothing to do, scheduler, switch to your next process".

You mean blocking calls interfere with the low-level scheduler so that the program simply don't get cpu time?

Regards, Sebastian

Why give a timeslice to a process waiting for input that the scheduler knows has not received that input? That's just a waste of resources.

The low-level scheduler should be aware of what is blocking various threads and only bother to wake them up (or at least add them to the run queue) when the block is cleared.

Hello,

Yes, that was my idea, too. I did not know how/if it's done. I'll get the Minix book at Christmas, so I can then read some more about the real low-level stuff. I have read a lot, but not about everything. A good book is worth more than a thousand web sites, I think...

next

the

Thank you for your answer. I did not know this was possible. I'm not much of a programmer, but that will change.

Regards, Sebastian

There isn't anything equivalent to a TSR in linux. A deamon or background process is a little similar but not equivalent.

Correct.

Correct.

There is no equivalent to a TSR in any of the multitasking systems with which I'm familiar.l

I've no clue what you mean.

TSRs don't fint into Linux.

TSRs are a DOSism. Linus isn't DOS.

Hi,

Every process is marked with a state which tells the scheduler whether or not to even try scheduling it in for a time slice. One of the states is "blocking" ie. waiting for something. When that something happens (usually in another process) the state of the blocked process is changed to "run". That way, when the scheduler next comes around to considering the process, it picks up where it left off.

-- Peter

A kernel driver compiled as a module can be added to the kernel after the kernel has started running,

$ modprobe mymodule par1= name="yyy" etc.

It's done with interrupts. The task goes to sleep and never gets a timeslice until the interrupt occurs to wake it up.

Timeslices are only allocated to tasks which are actually runnable, ie they are not sleeping waiting for an interrupt.

MS-DOS did not support concurrency of any kind, technically DOS was a single tasking, non-reentrant, interrupt handler (INT 21h) this (and the price) made it ideal for some soft embedded systems.

The DOS TSR service was an officially unsupported way to load a standard DOS program into memory and exit in a way that did not corrupt program code/data. Typically you would specify the number of paragraphs (16byte multiples) to retain - part of that address was also used to provide a kind of DOS PID or process identifier.

TSRs utilised concurrency by chaining one of the PCs hardware interrupt services eg. keyboard, timer etc.

One of the most popular programs to do this was Borlands Sidekick PIM (personal information manager) but it was also used for implementing things like network services etc.

The key points to remember are that they were officially unsupported, could and would crash systems and were, really, a terrible hack very specific to DOS. On any proper OS you would consider using a task or thread, possibly a unix like daemon.

Regards

dmctek.googlepages.com Software Development Consultancy.