[...] > Yes, I would. The issue is less a case of "throwing > my toys out > of the pram" because I only want to license under the > GPL, but > more the serious issue that the Squashfs kernel code > doesn't make > a distinction between core Squashfs filesystem code > and Linux > VFS interfacing code. Due to this at the moment the > whole lot counts > as a derived work of the Linux kernel, and so must be > licensed > under the GPL. > > At the moment to license under CDDL I would have to > split the > code into two parts, a Squashfs filesystem core, and > a Linux > VFS interface wrapper. The alternative which may > take less > work is to base the code on Unsquashfs, which is a > separate > independent implementation which isn't derived from > anything. > > I'll have to study the code and think about the > options.
I suppose most of it could be re-implemented using little more than the header files and pseudo code abstracted from the rest. But even if compatibility were maintained initially, the two implementations could easily become incompatible over time and changes. Refactoring/ restructuring would initially offer less parallelism of the work to be done, but would hopefully pay off massively in the long run. If it were me (and keeping in mind that I haven't seen the code nor ever written a filesystem of my own!), I think I'd take a look at Darwin/MacOS X and some of the *BSDs as well as Linux and Solaris, if I were considering restructuring to isolate most of the implementation from the interface to the kernel(s), or increase portability, or both. That way, I'd be likelier to restructure in such a way as to not have to do it again for a future port. And I might also look at FiST (www.filesystems.org) (which last I heard only was up to Solaris 7, but I'd sure like to see updated to reflect VFS changes since then) as a possible existing solution to separating filesystem implementation from the OS specific details. Even if getting the FiST support for Solaris updated for the current VFS implementation wasn't going to happen, it might still be worth looking at for some ideas on how the code might be restructured. Of course, I'm just speculating (guessing) here... This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
