Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)
- From: Brad Boyer <flar@xxxxxxxxxxxxx>
- Date: Sat, 2 Dec 2006 04:58:51 -0800
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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- References:
- [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)
- From: Jeff Layton
- Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)
- From: Randy Dunlap
- Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)
- From: Jeff Layton
- Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)
- From: Brad Boyer
- Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)
- From: Jeff Layton
- [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)
- Prev by Date: Re: [Bugme-new] [Bug 7621] New: 2.6.19 breaks IPv6
- Next by Date: [PATCH] Export current_is_keventd() for libphy
- Previous by thread: Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)
- Next by thread: Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)
- Index(es):
Relevant Pages
|
