Hi,
Is it intended that non-gpl file systems cannot use functions like i_uid_read() and i_uid_write() (introduced by Eric Biederman in 3.5 kernel)?
They resolve to the below (in include/linux/fs.h):
static inline uid_t i_uid_read(const struct inode *inode)
{
return from_kuid(&init_user_ns, inode->i_uid);
}
static inline void i_uid_write(struct inode *inode, uid_t uid)
{
inode->i_uid = make_kuid(&init_user_ns, uid);
}
And both from_kuid() and make_kuid() are EXPORT_SYMBOL() so they are fine but the problem is that init_user_ns is EXPORT_SYMBOL_GPL() and because i_uid_read() and i_uid_write() are static inline it causes them to be unusable from non-gpl kernel modules...
Same thing applies to i_gid_read() and i_gid_write().
These seem pretty fundamental calls that a non-gpl file system should be able to call, no?
Best regards,
Anton
--
Anton Altaparmakov <anton at tuxera.com> (replace at with @)
Lead in File System Development, Tuxera Inc., http://www.tuxera.com/
Linux NTFS maintainer
Anton Altaparmakov <[email protected]> writes:
> Hi,
>
> Is it intended that non-gpl file systems cannot use functions like
> i_uid_read() and i_uid_write() (introduced by Eric Biederman in 3.5
> kernel)?
>
> They resolve to the below (in include/linux/fs.h):
>
> static inline uid_t i_uid_read(const struct inode *inode)
> {
> return from_kuid(&init_user_ns, inode->i_uid);
> }
>
> static inline void i_uid_write(struct inode *inode, uid_t uid)
> {
> inode->i_uid = make_kuid(&init_user_ns, uid);
> }
>
> And both from_kuid() and make_kuid() are EXPORT_SYMBOL() so they are
> fine but the problem is that init_user_ns is EXPORT_SYMBOL_GPL() and
> because i_uid_read() and i_uid_write() are static inline it causes
> them to be unusable from non-gpl kernel modules...
>
> Same thing applies to i_gid_read() and i_gid_write().
>
> These seem pretty fundamental calls that a non-gpl file system should
> be able to call, no?
I believe you are asking should a deriviative work of a GPL'd piece of
software be licenseable under something other than the GPL. I don't see
any provision in the GPLv2 for such a thing.
I am pretty certain that kuid_t is unique to the linux kernel and any
use of it makes your software a derivative work.
All EXPORT_SYMBOL_GPL does is provide a hint that the author could not
imagine that you could possibly use it in something that was not a
derivative work. EXPORT_SYMBOL makes no comment whatsoever.
As long as you are complying with the license of the kernel I don't see
how the question of a non-gpl file system can make any sense.
Eric