Terminate and Stay Resident Software (TSR) in Linux

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi,
What is the equivalent of TSR in linux ?
With the help of google, I found in one link that daemons are the TSRs
of linux.
But the TSR concept is quite different from the daemon concept in
Linux.

I find that, A daemon (or service) is a background process that is
designed to run autonomously,with little or not user intervention.

Further, TSR is rather than simply saying "terminate me" to DOS, it
says: "I'm xxx bytes
long. Now terminate me but DON'T OVERWRITE ME." Which is to
say: Terminate me, but let me Stay Resident.
TSR programs will be eliminated by the presence of full
multitasking operating systems.
TSR programs will be here for the duration as
necessary and viable add-ons to otherwise incomplete solutions.

So, how does TSR fit into linux as Linux is a multitasking operating
system with good solutions ?

Kindly share your views / info  regarding the TSR in linux .

Thx in advans,
Karthik Balaguru


Re: Terminate and Stay Resident Software (TSR) in Linux
Quoted text here. Click to load it

[snip]

Perhaps you could explain what you want to do?

    -f
--

Re: Terminate and Stay Resident Software (TSR) in Linux

Quoted text here. Click to load it
[snip]

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

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

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


Re: Terminate and Stay Resident Software (TSR) in Linux
2006-11-22, 09:28(-08), karthikbg:
[...]
Quoted text here. Click to load it
[...]

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.

--
Stéphane

Re: Terminate and Stay Resident Software (TSR) in Linux
Hello,

Quoted text here. Click to load it

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".

Quoted text here. Click to load it

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

Regards,
Sebastian



Re: Terminate and Stay Resident Software (TSR) in Linux
Quoted text here. Click to load it
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.

Quoted text here. Click to load it
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.

--
Dave
mail da snipped-for-privacy@llondel.org (without the space)
We've slightly trimmed the long signature. Click to see the full one.
Re: Terminate and Stay Resident Software (TSR) in Linux
Hello,

Quoted text here. Click to load it

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

Quoted text here. Click to load it
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



Re: Terminate and Stay Resident Software (TSR) in Linux
Hi,

Quoted text here. Click to load it

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

Re: Terminate and Stay Resident Software (TSR) in Linux

Quoted text here. Click to load it

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.


Re: Terminate and Stay Resident Software (TSR) in Linux

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".

--
James T. White



Re: Terminate and Stay Resident Software (TSR) in Linux

Quoted text here. Click to load it

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

Quoted text here. Click to load it

Correct.


Correct.


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

Quoted text here. Click to load it

I've no clue what you mean.

Quoted text here. Click to load it

TSRs don't fint into Linux.

Quoted text here. Click to load it

TSRs are a DOSism.  Linus isn't DOS.

--
Grant Edwards
snipped-for-privacy@visi.com

Re: Terminate and Stay Resident Software (TSR) in Linux
Quoted text here. Click to load it

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

$ modprobe mymodule par1=<xxx>  name="yyy" etc.


Quoted text here. Click to load it

--
Best Regards,
Ulf Samuelsson
We've slightly trimmed the long signature. Click to see the full one.
Re: Terminate and Stay Resident Software (TSR) in Linux

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.


----

karthikbg wrote:

Quoted text here. Click to load it


Site Timeline