|
|
|
|
|
|
| Author |
Message |
Paul Barker
*nix forums beginner
Joined: 09 Feb 2006
Posts: 4
|
 Posted: Sat Feb 11, 2006 5:48 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
I'm talking rubbish, I should think before I start posting...
| Quote: | I don't remember this in Linux
|
I said I thought it was used in linux. The rest is about the concept
not linux.
| Quote: | So, the idea of central disk scheduling is bad a bit. For instance, the best
place of request scheduling of the USB disk is the USB stack itself, and not
some central "disk schedulers".
|
True. Scheduling centrally is simple and is possibly a good place to
start, but isn't really going to give good performance.
| Quote: | I don't remember any "driver processes" in Linux disk stack.
|
Again I was talking about the concept, not linux.
| Quote: | This is not an advantage at all, since nobody ever needs it  cache is a part
of the VFS/filesystems code in modern OSes, and is tied to mmap()
implementation - both need the "pile of physical pages which contain this
file's data" facility.
|
I think a central cache mapping (memory inode number, offset) onto a
page is a good idea, which can be used for block devices and normal
files, as long as every open file is given a memory inode. Since this
is the system I plan to use, If you've got any suggestions I'd be glad
to hear them. I'd rather re-design any problems now than after I've
coded them.
On the more general point, I was trying to illustrate that operating
systems are quite varied in how they interface drivers, and that even
in one OS there may be several ways of interfacing drivers (eg. Block
devices treated differently to character devices). That first paragraph
of my post maybe needed a bit more research.
Thanks,
Paul Barker |
|
| Back to top |
|
 |
Maxim S. Shatskih
*nix forums addict
Joined: 02 Apr 2005
Posts: 55
|
| Posted: Sat Feb 11, 2006 5:19 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
| Quote: | 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
|
I'm against the whole word of ''reentrant". It is, in fact, something from the
old time of MS-DOS add-ons which tried to do multitasking from this pathetic
OS.
"Thread-safe" or "SMP-safe" are better words.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com |
|
| Back to top |
|
|
Maxim S. Shatskih
*nix forums addict
Joined: 02 Apr 2005
Posts: 55
|
| Posted: Sat Feb 11, 2006 5:17 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
| Quote: | common idea, which I think is used in linux, is to have a central
scheduler for block devices.
|
I don't remember this in Linux. Disk scheduler/queue code should surely know
about the concepts of SCSI tagged queue and such (hardware-side scheduling),
so, it must be as low level as possible.
In Windows, the disk driver just deals with partition stuff and translates
read/write to SCSI commands sent down to the so-called "storage port". No
queues in the disk driver.
The storage port is conceptually the driver for "controller with storage
devices attached", be it hardware or virtual, and talks SCSI on its upper edge.
For real SCSI controllers, it is SCSIPORT.SYS which a small plugin which is
exactly the controller's hardware driver (called "the miniport"). Essentially,
the main 2 routines called by SCSIPORT in the miniport are - StartIo and the
interrupt handler. The main reverse calls are - RequestComplete and NextRequest
(ready for next request). There are a couple of other calls too, and yes,
initialization and termination, but the general concept is such.
So, the driver for a real SCSI card is a miniport plugged to SCSIPORT, and must
be very simple - in fact, only the hardware-access stuff.
All queing is done in SCSIPORT.SYS, so is the SCSI queue tag assignment.
For IDE/SATA the things are similar, but ATAPI.SYS is instead SCSIPORT.SYS. It
contains the major duplicate of SCSIPORT code (I've heard MS just copy-pasted
it) for queue management and such, and also the standard PIO 0x1f0-based
controller driver code. ATAPI.SYS also supports plugins (like VIAIDE.SYS) for
to do DMA - to start DMA and so o.
ATAPI.SYS can only work with the hardware which is port-level compatible with
0x1f0 AT disk controller. All other IDE/SATA controllers are treated as SCSI in
Windows and the driver is a SCSIPORT's miniport.
For USB, the USBSTOR is a storage port, it converts the SCSI requests to USB
requests and sends them down to USB stack. I have doubts about USBSTOR having
any queues.
So is 1394, the storage port is SBP2PORT.SYS.
Needless to say that all these storage ports all support CD/DVD-ROMs and - for
XP and later - CD writing. w2k's USBSTOR driver did not support the command set
for CD writing.
So, the idea of central disk scheduling is bad a bit. For instance, the best
place of request scheduling of the USB disk is the USB stack itself, and not
some central "disk schedulers".
| Quote: | requests by simply queueing them and the drivers process / kernel
|
I don't remember any "driver processes" in Linux disk stack. kflushd? Yes, but
it is above the disk stack, and not a "driver process".
| Quote: | drivers running as daemons. The other advantage of central handling for
block devices is the ability to keep a central cache.
|
This is not an advantage at all, since nobody ever needs it cache is a part
of the VFS/filesystems code in modern OSes, and is tied to mmap()
implementation - both need the "pile of physical pages which contain this
file's data" facility.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com |
|
| Back to top |
|
|
Maxim S. Shatskih
*nix forums addict
Joined: 02 Apr 2005
Posts: 55
|
| Posted: Sat Feb 11, 2006 5:02 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
| Quote: | using specific calls for the type of driver it is. This is typical for
drivers that are dynamically loaded, such as USB device drivers.
|
At least in Windows, the USB drivers are loaded when the hardware is attached,
and not on software demand.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com |
|
| 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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Thu Jan 08, 2009 12:25 pm | All times are GMT
|
|
Prepaid Credit Cards | Bentley Autos | Business Sales | Debt Consolidation | Chess Board Setup
|
|
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
