David Masover <[EMAIL PROTECTED]> writes: > Jeremy Maitin-Shepard wrote: >> David Masover <[EMAIL PROTECTED]> writes: >> >> [snip] >> >> >>>> I have. And have seen /no/ benefit to you. Except, of course, the benefit >>>> accrued from some magic in Linus' kernel, by which all format differences >>>> go in a puff of smoke if they are implemented inside it, and furthermore >>>> all userland gets rebuilt to use the kernel's way overnight. >> >> >>> Let's say cryptocompress gets implemented. Not all of userland >>> rewritten, not even any of userland rewritten, just a cryptocompress >>> plugin for the kernel. And instead of having to learn a new tool, I can >>> just browse around in /meta. >> >> >> What is the relationship between file-as-dir or special meta-data and >> transparent encryption+compression? I do not see why file-as-dir would >> require such a special interface.
I mistyped this --- I meant to ask "why transparent encryption+compression would require such a special interface." > I'm ignoring file-as-dir until/unless someone figures out a sane way of > doing it. [snip] > Some methods actually do something, like secret.txt/compression. [snip] Okay, so you are suggesting that file-as-dir would provide the user interface for enabling the encryption or compression. Alternatively, though, an ioctl could be used to control compression and encryption. -- Jeremy Maitin-Shepard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/