It works at least a little.
I'm slightly stuck .. I'd appreciate some help! The scsi driver seems
to be stealing requests after the first couple. I can intercept and
redistribute the first two in a train, but the rest go straight to the
target device instead of being distributed by my driver. I never see
them!
I've put the code up for ftp and on cvs. It's written for 2.0.* but
trivially ports to 2.2/3.*. Just put in the odd couple of dcache
indirections and use the newer module architecture. I'll do it tomorrow
to make it more accessible to people.
http://www.it.uc3m.es/~ptb/cgi-bin/cvs-yoke.cgi
ftp://oboe.it.uc3m.es/pub/Programs/yoke-0.2.1.tgz
There's only one driver file, yoke.c. Theres a utility ytools.c to
manipulate the devices. There's an explanation of how to use it
in the README, and an explanation of the theory in the yoke.c header
comments. Essentially:
yadd /dev/yd0 /dev/hda1 /dev/hda2;
yrun /dev/yd0
echo hi > /dev/hda1
head -c2 /dev/hda2
ystop /dev/yd0
There's status info in /proc/yokeinfo.
I intercept write requests to the device by supplanting the request_fn
registered with the kernel. I mark the buffer_heads in the requests as
though they were raid'ed (with BH_MD) and that causes end_request to
turn over control to an end_request function that I put in the
personality field of the buffer_head. Instead of marking the buffer up
to date in my end_request I redirect it to a different device with
make_request (and schedule the orignal request_fn in a task queue).
The basic idea is not bad, but needs more knowledge of the way some of
the block devices play around than I have. The scsi device in
particular has me baffled. What is plugging? I am unplugging whenever
I see it but I want to get rid of it a bit more spectacularly ...
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/