I didn't fit into devsd because the device names (sdXn) weren't helpful and I need the ability to do extra control processing I couldn't see how to get from devsd.
e.g.,
I currently have devices named aoe{major}.{minor};
the blade in shelf 10, slot 9 is aoe10.9/. This
addressing mechanism is much easier to understand
than any sd controller to ethernet controller
mapping I could think up.Telling devaoe to start using interface ether0 is done with:
echo bind /net/ether0 >aoectl
There's also an aoeevents file our raid/lvm software can monitor (for device retransmits, eg).
The interface is still rather pliable as I'm trying to figure out what will work best.
For each system I've written an aoe driver someone has asked why I didn't fit into the current code. It always turns out that it's easier to cut a new one than bend the existing code to make it work. Disk drivers don't typically have to worry about multiple outstanding requests, retransmission timeouts, or anytime device discovery. This isn't to say they don't do command queueing or support hot plugging, it's just not usually something I can fit into.
Thanks for the lock tip -
Sam
On Tue, 12 Apr 2005 [EMAIL PROTECTED] wrote:
no, you should not be holding a spinlock when trying that. why is your driver trying to copy directly to user space, isn't it a subdevice of devsd? (i'm not saying that's the way to do it, just curious).
On Tue Apr 12 13:20:53 EDT 2005, [EMAIL PROTECTED] wrote:Hello 9fans,
I'm testing my AoE driver and have hit something curious.
On devaoe.c read, after getting the sectors from the remote disk and when trying to copy the data to the user process using memmove, I get a write page fault. At the time, I happen to be holding a spinlock over the device structure, which causes both port/fault.c:/^fault/ and port/fault.c/^seg/ (via qlock) to squawk at me about up->nlocks.ref > 0.
The user address in question is 7fffaedc. Firstly, does this address seem appropriate and secondly, is dropping the spinlock during the memmove appropriate?
All signs point to yes, but I'd like some reassurance.
Cheers,
Sam
