Messages in this thread | | | From | (Eric W. Biederman) | Date | Fri, 10 Apr 2015 23:04:04 -0500 | Subject | Re: i_uid_read()/i_uid_write() and friends |
| |
Anton Altaparmakov <anton@tuxera.com> 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
| |