In article <20020905135442.A19682@namesys.com>,
Oleg Drokin <green@namesys.com> wrote:
>
>Ok, since I really like this approach, below is the patch (for 2.4) that
>demonstrates my solution.
No, please just change i_nlink in <linux/fs.h> to be an "unsigned int"
instead.
The kernel internal VFS layers should not care about the fact that
nlink_t is of a limited type - the same way we internally can use larger
inode numbers than the old stat interfaces export. I'm already using a
32-bit i_nlink in my tree on 2.5.x for other reasons (/proc overflow
with hundreds of thousands of threads), we should internally be able to
handle them even if the external interfaces have problems.
(Besides, almost nobody in user space cares about i_nlink. And as long
as the kernel internally doesn't care, if you actually have people with
nlink values in the >16-bit range, they can at least work around the few
problems they might have by using things like "-noleaf" for their find
commands.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 07 2002 - 22:00:25 EST