[ENBD] enbd 2.4.34 works on ARM
Peter T. Breuer
ptb at inv.it.uc3m.es
Thu Oct 11 12:20:54 MDT 2007
I have the current enbd 2.4.34 up and working on an ARM machine (ARM
version 5, I believe, non-smp, kernel 2.6.12.6).
Porting difficulties were mainly in getting the ARM gcc-3.5 compiler to
compile properly. It's prone to strange things with local functions and
inlines. So code had to be put firmly middle of the road.
---
I've also eliminated the strange long pause (90s) at startup that was
bedevilling 2.4.33 and 2.4.34. Story:
It turns out that the kernel in recent releases has stopped intercepting
standard ioctl calls for GETBLKSIZE and the like, although it still
provides them. Presumably one is now supposed to call these standard
functions oneself from the driver when one gets the corresponding ioctl.
Early in the 2.6 kernel series these ioctls were never seen by the
driver, being intercepted higher up.
I didn't know about the change. As a result a GETBLKSIZE ioctl or
BLKBSZGET or something (I forget) early in the daemon startup sequence
was being passed across the enbd tcp link to the server as a remote
ioctl, instead of being treated locally. I hadn't expected to receive
the ioctl at all.
Trouble is that the connection wasn't up yet. There was a wait of 90s
for the unexpected remote ioctl to time out, before initialisation
proceeded and the startup sequence could go on to establish the
connection for real.
That's all. I handled the ioctl locally instead, returning error before
the tcp link comes up. All sweet and light as a result. The error
return is just a signal to the startup sequence that the device size has
not yet been established and it needs to negotiate with the server about
it.
Peter
More information about the ENBD
mailing list