lkml.org 
[lkml]   [2005]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: reiser4 plugins
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hubert Chan wrote:
> On Thu, 30 Jun 2005 15:52:25 -0400, Horst von Brand <vonbrand@inf.utfsm.cl> said:
>
>
>>>This doesn't even invalidate the userland VFSs of the other guys,
>>>they're still needed for systems whose kernels don't have a metadata
>>>facility.
>
>
>>So the metadata facility in kernel won't be used, for portability's
>>sake.
>
>
> Oh gee. Every operating system does threads differently. Mozilla has
> an abstraction layer called nspr that allows them to handle threads
> portably. glib/gtk has their own threads abstraction. On Windows, nspr
> will use the Windows method for handling threads. On Linux, it will use
> the Linux way. On systems that don't support threads, it can usually
> emulate it using timers.
>
> It's the exact same thing with the userspace VFS. If GNOME needs to
> handle extended attributes, it can use one mechanism under one operating
> system, or emulate it using some ugly hack on operating systems that
> don't support extended attributes.
>
> Isn't that the whole point of having a VFS?
>

So basically if I write a program that works in both Gnome and KDE
I should (according to your description) implement my own VFS that
will use the Gnome or KDE VFS that will then use the OS VFS.

Is it only me finding that a little silly?

I mean, if I am to have the same functionality under neither Gnome
nor VFS and they don't support something I need I _NEED_ a vfs so
that my program is so totally independent on anything at all.

My program calling My VFS which calls KDE/Gnome's VFS which calls the OS
VFS will be slowe than just calling the VFS immidiately - I do hope you
can see that.

// Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFC0GUxBrn2kJu9P78RApViAJ4q6BrVh0H19S4pN+Zc0bqh7zk2sgCeLRVK
8b+qlg2BHjwxg8HnVANQ5XA=
=2uNQ
-----END PGP SIGNATURE-----
-
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/

\
 
 \ /
  Last update: 2005-07-11 00:25    [W:0.334 / U:0.400 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site