Re: [LSF/MM/BPF TOPIC] Should we make inode->i_ino a u64?
"Theodore Tso" <[email protected]>
| Newsgroups | gmane.linux.file-systems,gmane.linux.ports.m68k,gmane.linux.ports.sh.devel |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Apr 24, 2026 at 08:38:56AM +0200, Kolbjørn Barmen wrote: > > This tells me that it is time for "the 32-bit community" (wtf) to either > look elsewhere, or start thinking of forking the Linux kernel perhaps > sooner rather than later, so we don't bother "the 64-bit community" so > much. My point was that having people whine about a decision isn't a particularly productive way to engage with the kernel development community. Especiually when the person who was complaining was the HFS maintainer, and the mailing list that he *should* have been paying attention to was linux-fsdevel, since it's marked as the primary list where HFS bugs and development issues should be discussed, and linux-fsdevel was one of the mailing lists where the 64-bit inode proposal was cc'ed --- maybe that says something about how engaged he *really* was with Linux Kernel development. But hey, it's open source. Forking is always allowed. My guess is that a fork would involve a stagnating code base that won't be to keep up with bug fixes, including security bugs. This is especially if most people working on 32-bit architectures are as engaged as the OP. Most forked projects don't end up working well, but everyone has the right to find that out for themselves. Cheers, - Ted