Messages in this thread | | | Date | Sat, 20 Jul 2002 09:03:45 +0400 | From | Hans Reiser <> | Subject | Re: [2.6] Most likely to be merged by Halloween... THE LIST] |
| |
Oliver Xymoron wrote:
> > > > > >>So, I am assuming a new system call must go in before feature freeze. >> One can reasonably argue that because it only affects one experimental >>filesystem named reiser4 (until other FS authors see how nice it is and >>start to use it;-) ) and does not complicate VFS, it is not core code, >>and should not be subject to the freeze. I'll make that argument if we >>don't have it ready in time....;-) >> >> > >It only doesn't complicate VFS because we haven't discussed generalizing >it yet. The desire to do transactional processing is not unique to Reiser >any more than journalling is. See recent thread about fsync and MTAs. > > >If you hide all your nifty features under a carpet (aka ioctl) where no >one but Viro notices them, then maybe you'll be able to push this stuff >late September and get them in. But FS-specific syscalls are a non-starter >- what happens to the second FS that decides it wants transactions or >multi-file I/O but doesn't quite fit your model? > > > The way the Linux community works is first you show that it works, then you ask others to follow you. In 2.6 we will show that it works. In 2.7 we will ask others to consider adopting it. In 5-15 years, some of them will. Trust me that there is no queue of other FS authors seeking to take advantage of our code, and complaining that we are locking them out from our transactions API. Shoot, some of them are still using linear search directories and not packing small files together into one block.;-)
So, we are not hiding it under a carpet in ioctl, we are doing something clean and powerful and general enough to be usable by any other storage layer that chooses to implement the required functions.
We need to compete with Microsoft's OFS. We have a tight and busy schedule if we are to ship a filesystem offering superior semantics for semi-structured data queries with a clean and powerful code architecture behind it, and ship it before OFS ships. Reiser4 gets the storage layer foundation in place, and reduces the amount of code required for the later stages several fold. It also provides a framework for several serious approaches to security problems (like giving apps a transactions API), and has some features that are just plain nifty (e.g. inheritance).
All of this squabbling over filesystem (distro) competition within Linux is just a distraction from the important job of getting something ready for when OFS comes over that hill over yonder there..... unless you want to hear from your friends in 2004+ about the superior namespace integration Longhorn offers in Windows compared to Linux, and how it makes everything simpler....
-- Hans
- 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/
| |