| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Reiser4 and kernel inclusion
Reiser4 and kernel inclusion
Posted Sep 24, 2005 18:01 UTC (Sat) by giraffedata (subscriber, #1954)In reply to: Reiser4 and kernel inclusion by iabervon
Parent article: Reiser4 and kernel inclusion
The problem is really that Hans didn't start by understanding how the division of labor among kernel subsystems worked and why it was set up that way
He understood. He was trying to balance a grand vision with practicality. He has said he thinks his work should replace the VFS layer; i.e. he doesn't think it belongs in a normal filesystem driver. But he figured it would be easier to ship separately, and get included, as a loadable kernel module. I think Reiser4 would look a lot different if Hans Reiser owned the Linux kernel.
(Log in to post comments)
Moot point - he doesn't.
Posted Sep 27, 2005 2:49 UTC (Tue) by kirkengaard (subscriber, #15022) [Link]
And it's so good that he doesn't, and indeed, that no-one/everyone owns the linux kernel, and that it is dedicated to reproducing POSIX-standard functionality. See the Massachusetts OpenDocument debate for one example of why standardized functionality is ultimately optimal, and manufacturer-specific, non-standard implementations are less than optimal, even if they provide useful functionality. Grand visions are nice, but world-reproducible, world-repeatable, world-implementable specifications win. Hans didn't create an open specification, nor did he create a systematic approach to anything above filesystem data management. Look at his documentation. He starts, not with Linux integration at all, but with "What is a file?". His grand vision is generated a priori, ex nihil. He picks Linux as the recipient of his gift by default. His other options are Microsoft or the graveyard of niche OSes. He is doomed to see his beautiful whole-cloth implementations broken down into usable functions and adapted for use by people who don't have his ends in mind (with the possible exception of whatever DARPA uses it for). It's the commoditization problem.
Moot point - he doesn't.
Posted Sep 27, 2005 14:49 UTC (Tue) by IkeTo (subscriber, #2122) [Link]
Standardized functionalities might be "ultimately" optimal, but there are many points in the time when we haven't reach that "ultimate" state. At such times, standardization does far more bad than good.
Standardization requires that there is a group of people who are enthusiastic about the field, knowledgable with the field, and have implementation experience with the field. Without that, it is moot to even talk about standardization. Given that "viewing a filesystem as a file and directory at the same time, and nothing else, in order to implement a superset of POSIX functionality" is such a new vision, I don't think it to be a candidate for standardization or formal specification. At times, it is best to have no specification and no standards to obstruct experiments and developments.