|
|
|
|
|
|
| Author |
Message |
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 |
|
 |
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 |
|
|
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: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 |
|
|
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 |
|
|
David Schwartz
*nix forums Guru
Joined: 26 Feb 2005
Posts: 914
|
| Posted: Sat Feb 11, 2006 9:09 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:dsl53j$1hja$1@gavrilo.mtu.ru...
| 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.
|
I'm pretty sure this is not the case. When hardware is attached, the
driver for whatever that hardware was attached to invokes a software process
to locate, load, and attach the appropriate driver. That software process
instructs the kernel to load the driver, which then attaches to the hardware
by attaching to the driver for whatever device the new hardware attached to.
DS |
|
| Back to top |
|
|
Maxim S. Shatskih
*nix forums addict
Joined: 02 Apr 2005
Posts: 55
|
| Posted: Sat Feb 11, 2006 9:37 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
| Quote: | At least in Windows, the USB drivers are loaded when the hardware is
attached,
and not on software demand.
I'm pretty sure this is not the case. When hardware is attached, the
driver for whatever that hardware was attached to invokes a software process
to locate, load, and attach the appropriate driver. That software process
instructs the kernel to load the driver, which then attaches to the hardware
by attaching to the driver for whatever device the new hardware attached to.
|
Yes, but not on file open. Not on the app's demand "I want to work with this
device, please load the driver for it".
When PnP service demands driver loading - it is not when user app demands this.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com |
|
| Back to top |
|
|
Ben Bacarisse
*nix forums Guru Wannabe
Joined: 19 Jun 2005
Posts: 110
|
| Posted: Sat Feb 11, 2006 11:12 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
On Sun, 12 Feb 2006 00:37:09 +0300, Maxim S. Shatskih wrote:
| Quote: | At least in Windows, the USB drivers are loaded when the hardware is
attached,
and not on software demand.
I'm pretty sure this is not the case. When hardware is attached, the
driver for whatever that hardware was attached to invokes a software
process to locate, load, and attach the appropriate driver. That
software process instructs the kernel to load the driver, which then
attaches to the hardware by attaching to the driver for whatever device
the new hardware attached to.
Yes, but not on file open. Not on the app's demand "I want to work with
this device, please load the driver for it".
|
Are you referring to fixed device nodes? If so, you are are rather
out of date. That meachanism still exists if, for some reason, an app
were to want it, but I do no know on any that work that way. DS'd
description is pretty much what happens, particularly with USB devices
(with the usual Linux caveat that you can change it and do it another way
if you want).
--
Ben. |
|
| Back to top |
|
|
Nick Roberts
*nix forums beginner
Joined: 12 Feb 2006
Posts: 5
|
| Posted: Sun Feb 12, 2006 1:23 am Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
Maxim S. Shatskih wrote:
| 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.
|
I think the term 're-entrant' is fine; it is used in a lot of technical
documentation that I have seen. But, like most of these technical terms,
it is always best to define what you mean whenever you use it.
My own experience of the term is when it is applied to subroutines
within a program, where it has the meaning: two or more different
threads can safely call the same subroutine in parallel.
Of course, this definition can be hedged around with subtleties; for
example, an otherwise re-entrant subroutine may only be re-entrant for a
certain portion of the execution of the program (e.g. between completion
of an initialisation phase and initiation of a finalisation phase of the
program).
I don't think the term 're-entrant' is generally used when speaking
about operating system calls (even though, in practice, such a call will
typically just call some OS subroutine, perhaps in a privileged hardware
state). I have seen the term used in conjunction with calls to the
MS-DOS and PC BIOS APIs (in that they are not re-entrant), but never any
other OS.
I've never come across a full OS that supports multi-threading (or
equivalent) which doesn't provide a fully thread-safe API, except for
Win16 and Win32 (which I attribute to Microsoft's exceptional
incompetence in the technology). As for skeleton OSes (e.g. RTOSes and
microkernels), the timing and synchronisation details of using their
facilities can be extremely complex and tricky.
I use the term 'thread-safe' here to mean that two threads can call the
same API routine in parallel safely, except for interactions that are
(or should be!) explicitly detailed in the API documentation.
Thus, there can be a subtle but significant difference between the
meanings of 're-entrant' and 'thread-safe'. Again, the only safe thing
to do is to define exactly what you mean when you use one of these terms.
One interesting phenomenon that I have observed is that many programs
which are multi-threaded and work correctly on both single processor and
SMP (symmetric multi-processor) machines seem to work very inefficiently
on the SMP machines (e.g. barely any faster than on a single-processor
machine running at the same clock speed). This, I am convinced, is due
to the program using the memory caches on the SMP machine in a way that
causes a huge level of contention (each instance of which requires a
large number of bus transactions to be resolved). Thus, a program can be
'SMP-safe' but nevertheless almost 'SMP-useless'.
--
Nick Roberts
[Cross posted: alt.os.development; comp.unix.internals;
comp.unix.programmer] |
|
| Back to top |
|
|
Logan Shaw
*nix forums Guru
Joined: 21 Feb 2005
Posts: 474
|
| Posted: Sun Feb 12, 2006 5:28 am Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
Maxim S. Shatskih wrote:
| Quote: | At least in Windows, the USB drivers are loaded when the hardware is
attached,
and not on software demand.
I'm pretty sure this is not the case. When hardware is attached, the
driver for whatever that hardware was attached to invokes a software process
to locate, load, and attach the appropriate driver. That software process
instructs the kernel to load the driver, which then attaches to the hardware
by attaching to the driver for whatever device the new hardware attached to.
Yes, but not on file open. Not on the app's demand "I want to work with this
device, please load the driver for it".
|
I guess that means that when you said "not on software demand", you
actually meant "not on apps' demand"? (There is such a thing as
user-mode software that isn't an application. At least on most
operating systems I've encountered.)
- Logan |
|
| Back to top |
|
|
Brian Raiter
*nix forums beginner
Joined: 15 Mar 2005
Posts: 5
|
| Posted: Sun Feb 12, 2006 7:54 am Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
| Quote: | My own experience of the term is when it is applied to subroutines
within a program, where it has the meaning: two or more different
threads can safely call the same subroutine in parallel.
|
Perhaps this distinction is now mainly archaic, but I believe that the
original meaning had little to do with threads or processes. It
specifically meant a function that could be invoked while already in
the middle of an invocation. In other words, if the function called
another function during its execution, could that sub-function
potentionally wind up calling the first function again -- and if so,
would it work correctly or not? If it did, then the function was
re-entrant -- it could literally be re-entered.
b |
|
| Back to top |
|
|
Gordon Burditt
*nix forums Guru
Joined: 02 Mar 2005
Posts: 773
|
| Posted: Sun Feb 12, 2006 8:08 am Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
| Quote: | My own experience of the term is when it is applied to subroutines
within a program, where it has the meaning: two or more different
threads can safely call the same subroutine in parallel.
Perhaps this distinction is now mainly archaic, but I believe that the
original meaning had little to do with threads or processes. It
specifically meant a function that could be invoked while already in
the middle of an invocation. In other words, if the function called
another function during its execution, could that sub-function
potentionally wind up calling the first function again -- and if so,
would it work correctly or not? If it did, then the function was
re-entrant -- it could literally be re-entered.
|
I don't think the distinction (applied to functions or subroutines)
is archaic. For example, can you safely call it from a C signal
handler (or an OS interrupt handler)? If it's reentrant, yes. If
it's not, you may have to go through a lot of trouble ensuring that
the main process is not going to be doing something that will get
messed up, and that perhaps means sections where signals are masked.
Note: a signal handler can't "wait" for the main process to do
something (like release a mutex); until it returns, the main process
won't do anything.
Can it safely be used recursively? If it's reentrant, yes (assuming
a couple of other things like it's not INFINITE recursion and you
won't run out of stack).
Gordon L. Burditt |
|
| Back to top |
|
|
Maxim S. Shatskih
*nix forums addict
Joined: 02 Apr 2005
Posts: 55
|
| Posted: Sun Feb 12, 2006 11:34 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
| Quote: | I guess that means that when you said "not on software demand", you
actually meant "not on apps' demand"?
|
Correct. Windows loads drivers on _PnP's_ demand, which is a part of the kernel
(software) and sometimes even user-mode helper service (when the driver is not
yet installed for this devnode, so an INF scan or maybe even bothering the user
is needed).
My intent was to say - "on _application_ software demand".
I know that there were some filesystems in Linux which could do this, IIRC
experimental ones. Windows also has this feature called SWENUM, but it is
hardly tied to audio/video subsystems, so that MS's people do not recommend to
use it in any other software.
Older Windows - 9x/Me - had the feature of loading the driver on file open. It
has its own major issues too - for instance, you cannot enumerate all devices
on the machine which expose some function (like audio), etc. Maybe that's why
modern Windows do not use it (except for SWENUM).
And, surely, non-PnP drivers (i.e. non-hardware related kernel modules) - can
be loaded on app's demand, if the app is running under sufficient privileges.
--
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: Sun Feb 12, 2006 11:39 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
| Quote: | equivalent) which doesn't provide a fully thread-safe API, except for
Win16 and Win32 (which I attribute to Microsoft's exceptional
incompetence in the technology).
|
Please note where and when the Win32 APIs are not thread-safe. Please do not
mix them with the obsolete and ancient C runtime calls like asctime().
| Quote: | I use the term 'thread-safe' here to mean that two threads can call the
same API routine in parallel safely, except for interactions that are
(or should be!) explicitly detailed in the API documentation.
|
Correct. All Win32 is such.
| Quote: | which are multi-threaded and work correctly on both single processor and
SMP (symmetric multi-processor) machines seem to work very inefficiently
on the SMP machines (e.g. barely any faster than on a single-processor
machine running at the same clock speed). This, I am convinced, is due
to the program using the memory caches on the SMP machine in a way that
|
Yes. Starvation can also be an issue - if the CPU-heavy activity is waiting for
IO heavy activity, or such.
| Quote: | 'SMP-safe' but nevertheless almost 'SMP-useless'.
|
Using SMP _just to raise the speed of the interactive UI app_ requires some
smartness. With server software, it is simpler - the OS dispatcher will take
care on thread distribution across CPUs, so, the CPU will no more be a
bottleneck for your server (if you had 100% before installing second CPU, you
will have 60% or so).
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com |
|
| Back to top |
|
|
Brian Inglis
*nix forums beginner
Joined: 16 Feb 2005
Posts: 22
|
| Posted: Mon Feb 13, 2006 1:48 am Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
On 9 Feb 2006 09:11:22 -0800 in comp.unix.internals, "Olumide"
<50295@web.de> wrote:
| Quote: | 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.
|
[generalized conceptual overview of some points]
Device drivers may have to be reentrant to handle multiple devices, or
allow a device interrupt to be serviced while an I/O request is setup;
really depends on the OS and driver contexts.
If no operations are currently pending on a device, a requested
operation will be started immediately.
Any rejection or queuing of requests has to be handled by the device
driver as each device (sometimes controller) will have its own limit
on the number of concurrent users and/or requests it can handle (often
just one).
When a device interrupts to signal an operation is complete, and there
is a queued request, the next operation will be started before the
driver returns.
In the case of normal disk device drivers where more than one request
is queued, the driver could maintain the queue in order to minimize
the seek or rotational distance between subsequent operations.
HTH
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian.Inglis@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Sat Nov 22, 2008 1:12 pm | All times are GMT
|
|
Sauna | Property in Spain | Property in Spain | MPAA | Ringtones
|
|
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
