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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20061202125851.GA30187@cynthia.pants.nu>
Date:	Sat, 2 Dec 2006 04:58:51 -0800
From:	Brad Boyer <flar@...andria.com>
To:	Jeff Layton <jlayton@...hat.com>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)

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@...andria.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/