From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Garzik Subject: Re: [Patch] chunkd: use port xxx82 to build Date: Fri, 07 Aug 2009 19:47:40 -0400 Message-ID: <4A7CBD1C.9020100@garzik.org> References: <22384029.1249688189096.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <22384029.1249688189096.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Sender: hail-devel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Rick Peralta Cc: Project Hail List Rick Peralta wrote: > Hi Jeff, > > Here are the notes on the endian notes. On first blush it looks like the basic problems are related to I/O and structure alignment. Correcting the structure (in the compiler) might be enough (if is supports endian pragmas or some such. The traditional way is to hard code endian conversions of the data before it goes out over the network and converting back on return. There are macros in the networking code that do the core byte swaping function. I was looking from net_write() & net_read() to see where they were called and what was passed to them. struct chunksrv_req & struct chunksrv_resp_get seem to be the primary structures. Where to optimally put the changes is less clear. In struct chunksrv_req, only one member has the possibility of endian problems: data_len. And it appears to me that this is already properly converted: > [jgarzik@bd chunkd]$ grep -w data_len */*.[ch] > include/chunk_msg.h: uint64_t data_len; /* len of addn'l data */ > lib/chunkdc.c: *plen = GUINT64_FROM_LE(resp.req.data_len); > lib/chunkdc.c: req.data_len = GUINT64_TO_LE(content_len); > lib/chunkdc.c: req.data_len = GUINT64_TO_LE(cont_len); > lib/chunkdc.c: content_len = GUINT64_FROM_LE(resp.req.data_len); > server/object.c: uint64_t content_len = GUINT64_FROM_LE(cli->creq.data_len); > server/object.c: resp->req.data_len = GUINT32_TO_LE(obj->size); > server/server.c: resp->data_len = GUINT64_TO_LE(content_len); > server/server.c: (long long) GUINT64_FROM_LE(req->data_len)); In struct chunksrv_resp_get, the only possibility of endian problem with is the 'mtime' struct member, which is only referenced once in server/object.c (the other uses are native-endian internal variables): > [jgarzik@bd chunkd]$ grep -w mtime */*.[ch] > include/chunk_msg.h: uint64_t mtime; > lib/chunkdc.c: if (!net_read(stc, &resp.mtime, sizeof(resp) - sizeof(resp.req))) > server/be-fs.c: obj->bo.mtime = st.st_mtime; > server/be-fs.c: ve->mtime = st.st_mtime; > server/chunkd.h: time_t mtime; > server/chunkd.h: time_t mtime; /* obj last-mod time */ > server/object.c: resp->mtime = GUINT64_TO_LE(obj->mtime); > server/server.c: time2str(timestr, ve->mtime), What are the "basic problems of I/O and structure alignment"? > I cobbled on a VM to get the PPC vm working. It seemed to boot, but needed more configuration than I had time to dope out. I was cool to see a mini-laptop (using the atom processor) run windows (yetch), support a VM running Fedora, support a VM running PPC code! I'm thinking a DVD could still run in the background, on an external monitor... Great! Jeff