locking in a device driver (was: use of bus_dmamap_sync)

From: Dinesh Nair (dinesh_at_alphaque.com)
Date: 10/27/05

  • Next message: kamal kc: "compiling the kernel faster" 
    Date: Thu, 27 Oct 2005 19:24:30 +0800
To: John Baldwin <jhb@freebsd.org>

    carrying on this discussion, what would be a good locking mechanism to use
    to protect tsleep() and other sensitive areas in a driver in freebsd 4.x ?

    the current code for the driver in 5.x uses mtx_lock and mtx_unlock with
    some parts even being protected by mtx_lock(&Giant).

    would the use of simple_lock() or s_lock() do, given that SIMPLELOCK_DEBUG
    was defined in the 4.x kernel ?

    the mechanism is actually a pseudo device driver which communicates with
    the real device driver. the pseudo device driver creates a bunch of /dev/
    devices which the userland reads/writes to, and the pseudo device driver
    then places data in a few buffers.

    the real device driver then reads these buffers and uses busdma to send the
    data to the device. reading is done by using busdma to read from the device
    and then placing the data in these buffers for the pseudo device to return
    to the userland process.

    locking in the real device driver uses splhigh/splx, but what locking
    should be used in the pseudo device driver ? 

    -- 
Regards,                           /\_/\   "All dogs go to heaven."
dinesh@alphaque.com                (0 0)    http://www.alphaque.com/
+==========================----oOO--(_)--OOo----==========================+
| for a in past present future; do                                        |
|   for b in clients employers associates relatives neighbours pets; do   |
|   echo "The opinions here in no way reflect the opinions of my $a $b."  |
| done; done                                                              |
+=========================================================================+
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
  • Next message: kamal kc: "compiling the kernel faster"

    Relevant Pages

    • Re: i386: pata_cs5520 does not work
      ... Device driver platform lacks bus and class support for being resumed. ... Device driver pci0000:00 lacks bus and class support for being resumed. ...
      (Linux-Kernel)
    • Re: 1394 Virtual Device Driver
      ... Try two machines connected via 1394, one with a virtual device ... > enumerates the bus successfully including the virtual device driver. ...
      (microsoft.public.development.device.drivers)
    • Re: The Kernal Is A Huge Security Whole In Windows
      ... The easiest way to exploit the security hole I am discussing is obviously ... driver writer is ridiculous, I'm sorry. ... responsible for making his device driver secure? ... > Performance Tab> View> Show Kernel Times. ...
      (microsoft.public.win2000.security)
    • Re: hard drive scrubbing utility
      ... we only teach the basics relative to PCI-style bus devices. ... The type of device driver you are writing makes a lot of difference also. ... There are some new books coming out from Microsoft Press on the new Kernel Mode Driver ...
      (microsoft.public.vc.mfc)
    • Re: Sort-of-Newbie Question(s)
      ... task at hand belong to the device driver development realm, ... driver to be backward compatible with Windows XP and Windows 2000, ... WDF works from Windows 2000 on. ... Can I use Visual C++ Express Edition to develop a device driver ...
      (microsoft.public.development.device.drivers)