Messages in this thread | | | Date | Wed, 23 Jun 1999 21:58:52 -0400 (EDT) | From | "Albert D. Cahalan" <> | Subject | Re: (reiserfs) Re: I discussed reading directories as files with jra, Stallman, |
| |
Jeff Epler (jepler@inetnebr.com) writes: > On Tue, Jun 22, 1999 at 07:49:01PM -0400, Albert D. Cahalan wrote:
>> You might wonder what older software will do when it encounters such >> a file. Anything using the proper API is handled by the DLL, but that >> leaves general tools like GNU tar. The NT kernel takes care of the >> remaining problems, using reparse point drivers to create an old-format >> file as needed. >> >> No joke. We'd do this with loadable modules, much like masquerading >> has drivers for all the odd network protocols. > > You're going to put application data file formats in the kernel? > > YOU'RE GOING TO PUT APPLICATION DATA FILE FORMATS IN THE KERNEL?
Hey, don't look at the Quake support we already have.
> If I'm guessing right at the complexity of the Microsoft Word file format > you mention, this'll be far, far worse than the extremely simple rules that > allow protocols like FTP to be masqueraded. And even the case for FTP was
Don't guess. The "Microsoft Word file format" is actually a highly structured compound document format. It doesn't work like TeX. It is a somewhat like a filesystem inside, complete with some sort of namespace and block allocation.
One need not understand the Word-specific aspects of the format. Forget about bold text and image format details. Not even NT would have all that in the kernel. No, this is only a filesystem-like structure to be dished out in pieces by a simple driver.
> If what you want is translation between data formats at open() time, why > can't you do it with a userspace library? For instance, today, if I want
The whole point of this is performance. We wouldn't even be discussing this if traditional compound document files were adequate.
Consider a 1200 MB document composed of text, images, charts, and other data. (perhaps a book manuscript with map data) The author makes a change to an internal component... now what? You need to reallocate the space it uses. You might need to move hundreds of megabytes of data (bad), leave a HUGE hole (bad), or add a layer of indirection (bad). Whatever you do, performance will be bad. Compare this to the multi-forked file solution: destroy one fork and create another. Since the OS already has a layer of indirection for block allocation, you don't suffer any additional performance loss beyond that of using a filesystem.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |