On Sat, Dec 02, 2006 at 09:56:27PM -0500, Jeff Layton wrote: > My main reasoning for doing this was that the structures involved are > per-superblock. There is virtually no reason that a filesystem would > ever need to touch these structures in another filesystem. I don't think this is relevant to the issue. I wouldn't expect that if you allow people to use this functionality that they would go poking around in other filesystems. I would expect people to use it on the filesystem they are writing. > So, this is essentially a service to make it easy for filesystems to > implement i_ino uniqueness. I'm not terribly interested in making things > easier for proprietary filesystems, so I don't see a real reason to make > this available to them. They can always implement their own scheme to do > this. This sounds slightly petty to me. For example, generic_file_read() is there just to make it easier to implement the read callback, but it isn't required. In fact, I would think that any filesystem complex enough to be worth making proprietary would not use it. However, that doesn't seem to me to be a good argument for marking it GPL-only. The functionality in question is easier to reimplement, but that doesn't make it right to force it on people just because of a license choice. > I'm certainly open to discussion though. Is there a compelling reason to > open this up to proprietary software authors? I don't think there is a compelling reason to open it up since the functionality could be reimplemented if needed, but I also think the only reason it is being marked GPL-only is the very common attitude that there should not be any proprietary modules. To be honest, I think it looks bad for someone associated with redhat to be suggesting that life should be made more difficult for those who write proprietary software on Linux. The support from commercial software is a major reason for the success of the RHEL product line. I can't imagine that this attitude will affect support from software companies as long as there is a demand for software on Linux, but it isn't exactly supportive. Brad Boyer flar@xxxxxxxxxxxxx - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
