Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Brad Boyer wrote:

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.


Yes, most filesystems have their own scheme for managing i_ino assignment, so this is primarily for "pseudo-filesystems". Stuff like pipefs, sockfs, /proc, etc...

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.


I have no problem with someone writing, selling and supporting proprietary modules. Knock yourself out. I just don't see a reason why I should contribute code to such an effort.

Still though, this was coded in part on company time. I certainly don't want to go against Red Hat's policy in such a matter, so I'll do some due diligence internally as to how this should be done.

In the meantime, does anyone have objections or comments on this approach on technical grounds?

Thanks,
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux