On Mon, Oct 7, 2013 at 10:45 AM, Brian Behlendorf <[email protected]>wrote:
> On 10/05/13 17:54, Matthew Ahrens wrote: > >> On Sat, Oct 5, 2013 at 5:29 PM, Richard Yao <[email protected] >> <mailto:[email protected]>> wrote: >> >> Brian was concerned that there could be subtle compatibility issues >> between the C89 kernel and a C99 kernel module (or a C89 module and a >> C99 userland), so he decided to make the entire project C89 to be >> safe. >> >> >> The ABI (application binary interface) should be the same for C89 and >> C99. I.e. code written in one can call the other. So I would not >> expect there to be any compatibility issues. Do you (Brian) know of any >> specific problems? >> > > It's my understanding that the C ISO standard doesn't make any claims > about ABI compatibility between C89 and C99. That's something which has > been left to the compiler. In my experience gcc does generate compatible > code, but it wouldn't at all surprise me if there are subtle > incompatibilies lurking. > > To be absolutely safe I removed the C99'isms from the ZFS code when > porting it to Linux. I didn't want to risk it causing any subtle issues > while porting the rest of the code base. Doing so was pretty easy becuase > it turns out ZFS makes relatively light use of the C99 linguistic > extensions. And for a freestanding C environment like a kernel there > really should be minimal assumptions made about library support. > > While I personally like C99 better I'd argue that using C89 is more > portable and the required style changes are minimal. That said, I think we > should explore building ZFS as C99 on the Linux side before deciding > anything. Hopefully my worries are unfounded! > Cool, I'd definitely be interested in the results of that experiment. > > And since we're on the topic of portabity I think there's a bigger issue > we need to address. One of the major frustions I've seen when porting > changes is when a patch brings in a dependency on some additional kernel > subsystem. When that happens we're forced to either add that subsystems > functionality to our compatibility layer, which can be a lot of work, or > rewrite the original patch to use a different approach. Agreeing on a > common kABI would make sharing patches much easier. > > Agreed! As we consider creating a platform-independent codebase for OpenZFS, we will need to define what interfaces it is allowed to use. Something like libzpool's zfs_context.h + kernel.c, but less hacky. --matt
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
