enbd 2.4.34 works on ARM
"Peter T. Breuer" <[email protected]> Thu, 11 Oct 2007 20:20:54 +0200 (CEST)
| Newsgroups | gmane.linux.enbd.general |
|---|---|
| Message-ID | <[email protected]> |
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