Messages in this thread |  | | Date | Mon, 21 Aug 2000 00:10:59 +0100 (BST) | From | James Sutherland <> | Subject | Re: abstract file (support multi-part) |
| |
On Sun, 20 Aug 2000, Mo McKinlay wrote:
> > > Eurgh. Do it userside: the kernel provides enough of an API to do it. > > No it doesn't. That's the point.
It does - that's the point.
> Unless I'm mistaken, in which case would you be so kind as to point me at > an example of userspace code which accesses HFS forks,
Netatalk does, apparently. HFS forks are certainly accessible to userspace without ANY changes to the API.
> NTFS streams,
Off-hand, I don't know of any code which uses them. The NTFS driver could certainly allow access to them without ANY VFS or API changes at all, though, as I have explained before.
> as well as HPFS and BeFS EAs, without resorting to direct manipulation > of the device (hence rendering any compatibility with filesystem > implementation changes null and void)?
HFS and NTFS, yes: no changes needed at all. HPFS's EAs aren't a concept VFS was really designed to handle; again, though, the HPFS driver can allow userspace to access EAs as a block of data via VFS without any API changes at all.
> If so, then I'm happy, because this is what I want. If not, then it'd seem > you're arguing against the very concept of this, not the method of > interfacing with filesystems which support it already.
It can be done, and in HFS's case already is. No API change needed.
> While "Are streams/forks a good idea?" is a very interesting topic with > plenty of arguments both for and against, it isn't the topic at > hand.
Agreed.
James.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |