DragonFly BSD
DragonFly commits List (threaded) for 2003-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

cvs commit: src/sys/isofs/cd9660 cd9660_vfsops.c

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 22 Jul 2003 10:03:32 -0700 (PDT)

dillon      2003/07/22 10:03:32 PDT

  Modified files:
    sys/isofs/cd9660     cd9660_vfsops.c 
  DEV messaging stage 2/4: In this stage all DEV commands are now being
  funneled through the message port for action by the port's beginmsg function.
  CONSOLE and DISK device shims replace the port with their own and then
  forward to the original.  FB (Frame Buffer) shims supposedly do the same
  thing but I haven't been able to test it.   I don't expect instability
  in mainline code but there might be easy-to-fix, and some drivers still need
  to be converted.  See primarily: kern/kern_device.c (new dev_*() functions and
  inherits cdevsw code from kern/kern_conf.c), sys/device.h, and kern/subr_disk.c
  for the high points.
  In this stage all DEV messages are still acted upon synchronously in the
  context of the caller.  We cannot create a separate handler thread until
  the copyin's (primarily in ioctl functions) are made thread-aware.
  Note that the messaging shims are going to look rather messy in these early
  days but as more subsystems are converted over we will begin to use
  pre-initialized messages and message forwarding to avoid having to constantly
  rebuild messages prior to use.
  Note that DEV itself is a mess oweing to its 4.x roots and will be cleaned
  up in subsequent passes.  e.g. the way sub-devices inherit the main device's
  cdevsw was always a bad hack and it still is, and several functions
  (mmap, kqfilter, psize, poll) return results rather then error codes, which
  will be fixed since now we have a message to store the result in :-)
  Revision  Changes    Path
  1.7       +3 -9      src/sys/isofs/cd9660/cd9660_vfsops.c

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]