Rik van Riel a écrit :
>
> On Tue, 24 Jul 2001, Jerome de Vivie wrote:
> > You only set a global variable to select on which configuration
> > you want to work. You can't do it simplier Rik: everything else
> > is transparent: read, write, ... !
>
> *nod*
>
> Sounds like a great idea indeed.
thx ;-)
>
> > > Now if you want to make this kernel-accessible, why
> > > not make a userland NFS daemon which uses something
> > > like bitkeeper or PRCS as its backend ?
> > >
> > > The system would then look like this:
> > >
> > > _____ _______ _____ _____
> > > | | | | | | | |
> > > | SCM |--| UNFSD |--| NET |--| NFS |
> > > |_____| |_______| |_____| |_____|
> >
> > Your architecture is too complex for me.
I've re-thought my draft and... your architecture is
not so complex !
Here's pros for userland SCM:
-easier to write
-easier to maintain (and no synchronization with kernel dvlp)
-work under every type of FS
-portable
-force me not to touch FS and properly write interface between
the SCM extension and the FS.
And cons:
-Multiple entry point to access data ( => risk of inconsistancy)
-Perhaps, a filesystem is the best place to put file (...even
for multiple-version files)
As it was mention by A. Viro, do it in the kernel may lead
to "devfs like" problems (...even after big simplifictions
like "one node for all version of a file").
I've change a bit my opinion: i'm not sure that userland
is the best place (...because there are cons pending) but,
i'm now nearest the userland solution of "hacking a nfsd".
j.
-- Jerome de Vivie jerome . de - vivie @ wanadoo . fr - 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/