DEV transition roadmap.
Matthew Dillon
dillon at apollo.backplane.com
Sun Jul 20 11:06:27 PDT 2003
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
More information about the Kernel
mailing list