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

DEV transition roadmap.


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sun, 20 Jul 2003 11:05:50 -0700 (PDT)

    Here's a DEV update.  I am working on a transitioning scheme for 
    devices, i.e. the cdevsw structure.

    What I am doing is changing the primary control structure from 
    struct cdevsw to struct cmsgsw.  cmsgsw will initially be declared
    in a degenerate form which simply references the old cdevsw for any
    given device.  This way the problem can be bitten off in smaller
    chewable pieces... I don't want to have to rip out cdevsw in the
    first pass!

    As the transition progresses devices can use additional fields
    in cmsgsw as various device functions become asynchronizable, eventually
    to the point where the device will specify the port mp_beginmsg function
    directly and throw away the old cdevsw structure entirely.

    In this first pass these basic API changes touch around 163 files, which
    isn't too bad.  The three passes/stages are going to be:

    (1) Change all cdevsw references to cmsgsw and port references.  All
	initial device entries will be moved to the messaging format but
	the system-supplied port shim will just call the original cdevsw
	functions to run the messages synchronously in the context of the
	caller.

    (2) Asynchronize the entry points.  Determine which functions depend on
	the original thread/process context and remove the direct 
	curproc/curthread dependancies.  This step will result in a 
	serious drop in performance but we absolutely need to prove-out
	the ability for all dev functions to run outside the callers address
	space (in the device thread rather then the caller's context).

    (3) (long term) Devices can then be converted to full-blown message
	based devices, with their own custom port function, and optimized
	appropriately.   We would start with the most important devices
	such as the disk devices, which will bring us back to 4.x performance
	levels. 

    I need to do step 1 myself, which I expect to take around two days, but 
    then anyone who is interested can start working on steps 2 and 3 since
    those are done on a device-by-device basis.

    I'll post another update once I've committed the basic infrastructure.
    Despite all the work this first stage should not result in any instability
    since it's just degenerating into what cdevsw did before.

						-Matt




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