lkml.org 
[lkml]   [2000]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 12:37    [W:0.061 / U:10.640 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site