|
|
|
|
|
|
| Author |
Message |
Maxim S. Shatskih
*nix forums addict
Joined: 02 Apr 2005
Posts: 55
|
 Posted: Thu Feb 09, 2006 6:24 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
| Quote: | A process calls a kernel IO function, saves state, context switch,
|
No context switch. Mode switch - yes. Saving state - yes. But still the same
process identity and the same thread identity (with the same related stuff -
security context, parent IDs etc).
| Quote: | and here's the source of confusion. If the request is for disk access,
reads and/or writes cannot have to be scheduled, and this suggests that
there be some sort of adjudicator (okay, scheduler)
|
This is a part of each driver itself, possibly using some general-purpose queue
implementation in the kernel (like IoStartPacket/IoStartNextPacket in Windows).
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com |
|
| Back to top |
|
 |
Francesco Frigo
*nix forums beginner
Joined: 09 Feb 2006
Posts: 2
|
| Posted: Thu Feb 09, 2006 7:21 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
Hi,
| Quote: | it seems unwise to me to allow every process in kernel
mode to play the scheduler.
|
Processes running in "kernel mode" are can be seen as "kernel processes"
because they are in fact executing kernel code, which is trustworthy by
definition.
Hence what you should do is:
1) acquire a spinlock for the driver request queue;
2) enqueue your I/O request;
3) go back to user mode (if you have asynchronous I/O) or block
(sleep/suspend the process) until the driver signals you;
Then your driver would dequeue I/O requests according to some priority
criteria. The simplest one is FIFO, but there are more efficient
ones.
| Quote: | So, I guess my question is: does the process pass its request to a
kernel level process running the device driver and then block, or does
it act the scheduler in the manner I (probably wrongly) suggested
above.
|
See above.
Probably what you were missing was the lock/signal part.
HTH,
Francesco Frigo
--
To e-mail me, remove "NOSPAM" from my e-mail address. |
|
| Back to top |
|
|
50295@web.de
*nix forums beginner
Joined: 09 Feb 2005
Posts: 32
|
| Posted: Thu Feb 09, 2006 8:26 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
Francesco Frigo wrote:
| Quote: | Processes running in "kernel mode" are can be seen as "kernel processes"
because they are in fact executing kernel code, which is trustworthy by
definition.
|
Thanks.
| Quote: | Hence what you should do is:
1) acquire a spinlock for the driver request queue;
2) enqueue your I/O request;
3) go back to user mode (if you have asynchronous I/O) or block
(sleep/suspend the process) until the driver signals you;
Then your driver would dequeue I/O requests according to some priority
criteria. The simplest one is FIFO, but there are more efficient
ones.
|
So, you're saying is that the device driver is a kernel level process?
....
(BTW, I'm not trying to write a device driver. I just want to know
more.) |
|
| Back to top |
|
|
David Schwartz
*nix forums Guru
Joined: 26 Feb 2005
Posts: 914
|
| Posted: Thu Feb 09, 2006 8:29 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
"Olumide" <50295@web.de> wrote in message
news:1139516768.361867.113010@o13g2000cwo.googlegroups.com...
| Quote: | So, you're saying is that the device driver is a kernel level process?
|
No, a device driver is not a process. It is a chunk of code that is
executed by the kernel as its functions are invoked. It can start a kernel
level process if it wants to, but that would only be part of the driver.
DS |
|
| Back to top |
|
|
Paul Barker
*nix forums beginner
Joined: 09 Feb 2006
Posts: 4
|
| Posted: Thu Feb 09, 2006 9:18 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
The device driver could be a piece of kernel code, or it could be a
user process, or it could even be running on a different machine (in a
distributed OS). Basically, it depends on the system. For linux most
drivers run in kernel mode, in windows I think its a mix of kernel mode
and user mode depending on the device.
Some more info about what system you're thinking of would help.
Cheers,
Paul |
|
| Back to top |
|
|
50295@web.de
*nix forums beginner
Joined: 09 Feb 2005
Posts: 32
|
| Posted: Thu Feb 09, 2006 9:20 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
David Schwartz wrote:
| Quote: | So, you're saying is that the device driver is a kernel level process?
No, a device driver is not a process. It is a chunk of code that is
executed by the kernel as its functions are invoked. It can start a kernel
level process if it wants to, but that would only be part of the driver.
|
Okay, I know. The driver is code. But what I meant to say was, who
(typically) runs it? |
|
| Back to top |
|
|
50295@web.de
*nix forums beginner
Joined: 09 Feb 2005
Posts: 32
|
| Posted: Thu Feb 09, 2006 9:25 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
Paul Barker wrote:
| Quote: | The device driver could be a piece of kernel code, or it could be a
user process, or it could even be running on a different machine (in a
distributed OS). Basically, it depends on the system. For linux most
drivers run in kernel mode, in windows I think its a mix of kernel mode
and user mode depending on the device.
Some more info about what system you're thinking of would help.
|
Thanks Paul, but please refer to my original question. I am interested
in the operation(?) of device drivers, and I have no perticular
architecture in mind, but I suppose mordern OSs have similar principles. |
|
| Back to top |
|
|
David Schwartz
*nix forums Guru
Joined: 26 Feb 2005
Posts: 914
|
| Posted: Thu Feb 09, 2006 11:13 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
"Olumide" <50295@web.de> wrote in message
news:1139520049.821751.182140@g44g2000cwa.googlegroups.com...
| Quote: | David Schwartz wrote:
So, you're saying is that the device driver is a kernel level process?
No, a device driver is not a process. It is a chunk of code that is
executed by the kernel as its functions are invoked. It can start a
kernel
level process if it wants to, but that would only be part of the driver.
Okay, I know. The driver is code. But what I meant to say was, who
(typically) runs it?
|
There are three common cases:
1) The kernel discovers the hardware and loads/activates the appropriate
driver by calling its initialization function. The initialization function
adds information about the hardware to kernel tables that result in the
kernel making more calls into the driver later. The calls occur from the
kernel's own contexts, usually meaning the kernel's startup context,
interrupt context, or the context of a user-space process that indirectly
invokes the driver. This is typical for network drivers.
2) A user-space process opens a device file that refers to a particular
driver. The kernel calls the device driver's 'open' function from a kernel
context associated with that process. The device driver is free to create a
kernel thread or do other things during the invocation of this function. If
it allows the 'open' to succeed, the kernel will typically refer all other
things related to that file to that device driver, calling it in the kernel
context corresponding to the invoking process. This is typical for drivers
like the null driver.
3) A user-space process commands the kernel to load/activate a device
driver. The kernel loads and links the device driver code and calls its
startup function, often from the kernel context corresponding to some kind
of 'module loader' process. The device driver generally makes calls into the
kernel that arrange for the kernel to call it back when things happen, often
using specific calls for the type of driver it is. This is typical for
drivers that are dynamically loaded, such as USB device drivers.
DS |
|
| Back to top |
|
|
Paul Barker
*nix forums beginner
Joined: 09 Feb 2006
Posts: 4
|
| Posted: Thu Feb 09, 2006 11:49 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
Modern OS's have very different principles depending on whether they
are monolithic or micro-kernel, as well as other design issues. A
common idea, which I think is used in linux, is to have a central
scheduler for block devices. This scheduler handles all block device
requests by simply queueing them and the drivers process / kernel
thread / whatever reads items off the queue. This avoids the problems
of re-entrancy everywhere except the main scheduler, which can be
protected, for example, by a spinlock. This is effectively like the
drivers running as daemons. The other advantage of central handling for
block devices is the ability to keep a central cache.
On the other hand, consider that with some devices it makes no sense
for more than 1 process to have them open at one time (maybe a simple
console or soundcard), and some devices have no issues at all with
re-entracy (eg. /dev/null). You might want to take a look at the
Windows DDK (device driver kit - for writing device drivers) which will
give you some idea of the interface between drivers and the kernel in
Windows (I have very little idea of this so I can only provide a
pointer). In linux (at least in my kernel) the folder "block" at the
root of the source tree contains all the generic block device stuff.
There may also be some good docs included with the kernel source.
At the end of the day, most operating systems have no compatibility
with drivers from other operating systems. Also, devices themselves
need handling in a huge variety of ways and a single OS may have
several ways of comunicating with different types of devices. It's a
zoo.
HTH,
Paul Barker |
|
| Back to top |
|
|
Alexei A. Frounze
*nix forums Guru Wannabe
Joined: 10 Apr 2005
Posts: 243
|
| Posted: Fri Feb 10, 2006 3:17 am Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
"Olumide" <50295@web.de> wrote in message
news:1139520049.821751.182140@g44g2000cwa.googlegroups.com...
| Quote: | David Schwartz wrote:
So, you're saying is that the device driver is a kernel level process?
No, a device driver is not a process. It is a chunk of code that is
executed by the kernel as its functions are invoked. It can start a
kernel
level process if it wants to, but that would only be part of the driver.
Okay, I know. The driver is code. But what I meant to say was, who
(typically) runs it?
|
The dumbest way would be basically to process the I/O request right away,
which may have a look like basically calling a subroutine. When that
subroutine finishes, it returns to the caller. This is the way BIOS and DOS
worked (unless disk caches were loaded such as smartdrv.exe). A call to r/w
a file on the disk (DOS int 21h) ended up calling int 13h (BIOS routines for
disk I/O). The actual I/O routine could in fact require interrupt servicing
if it is important to get some information from the device and this
information isn't available immedieately (e.g. DMA signals about I/O
completion by issuing an IRQ). This is the point where you can't truly think
of the things in terms of single-processing or plain subroutines, some form
of preemtion and multiprocessing is already present here. Now, if we
consider the same thing but with one of the popular disk caches for DOS
(e.g. smartdrv), then the I/O request is passed to the caching software and
it is free to do some job in the background, or kind off in parallel, to
your application that issues the I/O requests. The cache activity may be
triggered by several events: incoming I/O requests, timer interrupts (e.g.
buffered data gets saved from memory to disk every n seconds; reading
ahead), completion of the I/O on the disk level (e.g. DMA interrupt or
simply completion of int 13h). This ultimately makes the caching software
appear more complex than just a subroutine to call, it really becomes
something of the process/daemon/whatever. And now, if we introduce a
multitasking OS (which DOS wasn't), then this scales up manyfold. And it may
be possible that not just one process services the I/O requests, but
actually a few may be available to do some job for the users. And them,
consider the case when you have multiple I/O devices, a few hard drives. If
you want the I/O to be efficient, you definetely want to access them
independently, from different processes, so that you may do some meaningful
work with one drive fron one process/thread while the other one is serviced
by another. If you had just one, you'd process one at a time. Recently I
installed 2nd harddrive on my machine at work and it greatly improved the
usability of the machine while building the project on it. If the compiler
constantly does disk I/O and even doesn't utilize the CPU fully, you still
can't do much having just one disk because other applications need file
access too and therefore they get real unresponsive not because there's no
CPU time for them but because their requests get queued along with the
compiler requests and they don't get serviced quickly. That could probably
changed by altering priorities of the requests or applications (the latter
if the disk requests inherit the application priorities). But simply putting
another drive and removing the competition for the disk I/O fixes the
problem because the disks are accessed independently from different
procesess and don't interfere too much with one another. That's what I think
it is.
Alex |
|
| Back to top |
|
|
Matthias Bethke
*nix forums beginner
Joined: 24 Feb 2005
Posts: 2
|
| Posted: Fri Feb 10, 2006 12:31 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
begin followup to Paul Barker in comp.unix.programmer:
| Quote: | In linux (at least in my kernel) the folder "block" at the
root of the source tree contains all the generic block device stuff.
There may also be some good docs included with the kernel source.
|
There's a pretty good book by O'Reilly on Linux device drivers from
kernel 2.0 to 2.4, available on dead trees as well as free hypertext:
http://www.xml.com/ldd/chapter/book/
cheers!
Matthias
--
end |
|
| Back to top |
|
|
Norm Dresner
*nix forums addict
Joined: 13 Mar 2005
Posts: 74
|
| Posted: Fri Feb 10, 2006 6:44 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
"Olumide" <50295@web.de> wrote in message
news:1139520049.821751.182140@g44g2000cwa.googlegroups.com...
| Quote: | David Schwartz wrote:
So, you're saying is that the device driver is a kernel level process?
No, a device driver is not a process. It is a chunk of code that is
executed by the kernel as its functions are invoked. It can start a
kernel
level process if it wants to, but that would only be part of the driver.
Okay, I know. The driver is code. But what I meant to say was, who
(typically) runs it?
|
It's functions are called by other kernel code. Therefore it's kernel
(level) code when it executes.
Norm |
|
| Back to top |
|
|
James Harris
*nix forums beginner
Joined: 07 Jun 2005
Posts: 8
|
| Posted: Fri Feb 10, 2006 10:24 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
"Olumide" <50295@web.de> wrote in message
news:1139505082.346373.216660@z14g2000cwz.googlegroups.com...
| Quote: | Hi -
I wonder if device drivers are reentrant, my guess is perhaps not.
Here
is my possibly-flawed reasoning:
A process calls a kernel IO function, saves state, context switch,
enters kernel mode (at this point the process is running kernel code),
after which the request is passed to the appropriate device driver -
and here's the source of confusion. If the request is for disk access,
reads and/or writes cannot have to be scheduled, and this suggests
that
there be some sort of adjudicator (okay, scheduler) which is aware of
all requests and services them as it sees fit. And although the
process
now that its in kernel mode, and now executing device driver code (I
know I'm on shaky ground here) can access kernel information relating
to requests, it seems unwise to me to allow every process in kernel
mode to play the scheduler.
So, I guess my question is: does the process pass its request to a
kernel level process running the device driver and then block, or does
it act the scheduler in the manner I (probably wrongly) suggested
above.
Thanks for resisting the urge to flame me ;-)
- Olumide
|
|
|
| Back to top |
|
|
James Harris
*nix forums beginner
Joined: 07 Jun 2005
Posts: 8
|
| Posted: Fri Feb 10, 2006 10:57 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
"Olumide" <50295@web.de> wrote in message
news:1139505082.346373.216660@z14g2000cwz.googlegroups.com...
| Quote: | Hi -
I wonder if device drivers are reentrant, my guess is perhaps not.
Here
is my possibly-flawed reasoning:
snip
So, I guess my question is: does the process pass its request to a
kernel level process running the device driver and then block, or does
it act the scheduler in the manner I (probably wrongly) suggested
above.
|
I'm not sure what 'reentrant' means here. AFAIK a program code segment
is usually reentrant in that it cannot normally be written to - so
multiple processes can use the same copy of the code. A process is
normally not reentrant because it has state - variables, if you like. If
you can safely have multiple copies of that type of process - each with
its own state - does that make the process reentrant?
As for device drivers since you asked about the theory rather than a
specific OS I'd suggest not seeing them as a single process. There can
be multiple levels or, in theory, even multiple processes in a driver.
At the lowest level, since it is interacting with a device it seems to
me that it would have to have some state. In other words you couldn't
have multiple copies of it controlling one device unless the parts they
controlled were independent. (You may well have one copy of the driver
for each device of a given type.) The lowest level, then, cannot be
duplicated. However, each program may refer to the same code if that
code is non-modifiable, i.e. reentrant.
In short, it seems appropriate to classify /modules/ by whether they are
stateful or stateless rather than reentrant or not.
As for whether they block, that depends on the design. If the call to
the device driver requires no response the caller doesn't need to block.
If it requires a response it needs to block (until it gets a response).
Practically, if the response is something that is stored in the driver's
state it would not be normal to call that 'blocking' as the response
would always be ready immediately. If, on the other hand, the response
may require interaction with an external source - I/O device, server
process etc. - it would be normal to call that a blocking call (even if
the result can sometimes be available immediately due to, say,
read-ahead).
I guess you still may have intended a question different from what I've
tried to answer....!
HTH,
James |
|
| Back to top |
|
|
Gordon Burditt
*nix forums Guru
Joined: 02 Mar 2005
Posts: 773
|
| Posted: Sat Feb 11, 2006 12:11 am Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
| Quote: | So, I guess my question is: does the process pass its request to a
kernel level process running the device driver and then block, or does
it act the scheduler in the manner I (probably wrongly) suggested
above.
I'm not sure what 'reentrant' means here. AFAIK a program code segment
is usually reentrant in that it cannot normally be written to - so
multiple processes can use the same copy of the code. A process is
normally not reentrant because it has state - variables, if you like. If
|
Reentrant code may have state in the form of *LOCAL* variables. If
it modifies GLOBAL variables, it's not reentrant. For example, the
C function strtok() is not reentrant because it is required to have
hidden state. You can't fix it without changing the interface.
(sometimes done by adding a parameter that points at someplace to
put the state, supplied by the caller).
I'm not sure what the term "reentrant process" means.
| Quote: | you can safely have multiple copies of that type of process - each with
its own state - does that make the process reentrant?
|
If you can safely have multiple activations of a function - each
with its own state - and they do not interfere with each other,
that makes the function reentrant.
| Quote: | As for device drivers since you asked about the theory rather than a
specific OS I'd suggest not seeing them as a single process. There can
|
I suggest not seeing them as a process at all (they don't have to
be, although some implementations do it that way). They are often
subroutines of the caller (granted, kernel code, not user-supplied
code) and interrupt handlers.
Gordon L. Burditt |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Sat Nov 22, 2008 1:48 pm | All times are GMT
|
|
Agencia de turismo | Repair Bad Credit | Download Firefox Extensions and Themes | Myspace Layouts | Hotels in Calais
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Programming
»
Unix internals
