I haven't done any work on it, nor has anyone else to my knowledge.

I've been pretty satisified with the thruput I get -- latency is
another issue, but since you have to poll the darn thing that may not
go away entirely.

Handling rarp is pretty darn trivial.  I would guess it's 10% of the
lines of code in rarpd.c, and should be easy to add to etherd.  I'm
not trying to hold up etherd as something great -- it isn't.  But it
does work, which is after all the important thing.

I've wondered if it would be easier to write a real driver that
depends on a user process for context (ie; a process which does an
ioctl() which never returns) for the scsi I/O.

-phil