From owner-freebsd-ports@FreeBSD.ORG Wed Sep 17 23:06:16 2008 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA9C31065671; Wed, 17 Sep 2008 23:06:16 +0000 (UTC) (envelope-from chris@vindaloo.com) Received: from corellia.vindaloo.com (corellia.vindaloo.com [64.51.148.100]) by mx1.freebsd.org (Postfix) with ESMTP id 9AF9C8FC08; Wed, 17 Sep 2008 23:06:16 +0000 (UTC) (envelope-from chris@vindaloo.com) Received: from hadar.vindaloo.com (hadar.vindaloo.com [172.24.145.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by corellia.vindaloo.com (Postfix) with ESMTP id 6A32F5D3D; Wed, 17 Sep 2008 18:38:57 -0400 (EDT) Message-Id: <6C55E656-6B08-4B35-8CE7-6CCE00DDC871@vindaloo.com> From: Christopher Sean Hilton To: freebsd-questions@freebsd.org, freebsd-ports@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 17 Sep 2008 18:38:56 -0400 X-Mailer: Apple Mail (2.929.2) Cc: Subject: port: security/cfs X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 23:06:16 -0000 The port security/cfs, Matt Blaze's userland Cryptographic filesystem, is marked as broken because it does not compile under FreeBSD-7.0 or later. I've managed to get it to compile through some simple changes but I don't know enough about RPC to know if I am on the right track. I'm asking for the help of an RPC wizard to check my train of thought. The big change is rpcgen. In FreeBSD 6.0 it builds a C header file with prototypes like this: void * rpc_entry_point(); Now it builds prototypes like this: void * rpc_entry_point(struct yourtype * yourvar, CLIENT * clnt); I'm guessing that the first prototype caused GCC 4.x to gag so rpcgen was patched to produce the second when the move was made to FreeBSD-7.0. The second problem is that CFS is coded with rpc entry points that look like this. void * rpc_entry_point(yourvar, rp) struct yourtype * yourvar; struct svc_req *rp; { int ret = 0; ... return ret; } While gcc doesn't completely gag on that one it's not that happy about it either. The small issue here is that the coding style is ancient. Returning an (int) 0 as NULL has been taboo in C for years and gcc is getting more and more fussy about these problems as time passes. The bigger problem is that the parameter types don't match up. But the mismatch is so huge that I find it difficult to believe that code ever worked. Looking further into things I discovered that rpcgen is basically specifying an client-server interface. For every: void * rpc_entry_point(struct yourtype * yt, CLIENT * clnt); You also get: void * rpc_entry_point_svc(struct yourtype *yt, struct svc_req *rp); Now CFS uses K&R to mangle up the _svc functions pretty well to but basically if you patch cfs_adm.c and cfs_nfs.c to change the rpc entry points from client to service definitions then the code compiles reasonably cleanly with gcc 4. After that long discussion does someone know RPC programming well enough to verify that CFS was defining the Service side of thing all along and that in the past RPC was loose enough to take rpc_entry_point(... as the definition of the service which is now properly called rpc_entry_point_svc(... ? -- Chris -- Chris Hilton chris-at-vindaloo-dot-com ------------------------------------------------------------------------ "All I was doing was trying to get home from work!" -- Rosa Parks