On Thu, Jun 19, 2008 at 1:29 AM, <
olafBuddenhagen@gmx.net> wrote:
On Wed, Jun 18, 2008 at 08:15:10PM +0300, Sergiu Ivanov wrote:
> On Mon, Jun 16, 2008 at 6:13 PM, <
olafBuddenhagen@gmx.net> wrote:
> > These could be put in a completely separate interface for translator
> > control. But it might be easier just to add them to the existing
> > fs.defs -- after all, this is closely related to some of the
> > functionality fs.defs already provides...
>
> Doesn't fs.defs describe the interface common to all translators,
> which implement a filesystem interface? In this case, won't altering
> this file bring about problems because of the fact that the existing
> FS translators will not comply with the new interface definition?
Hm... I don't remember, whether translators always have to implement all
the callbacks from libtrivfs/libnetfs/libdiskfs, or whether some of them
are optional?...
In the latter case, additional RPCs probably could be introduced without
modifying the actualy translators.
Yes, indeed, some of the callbacks are optional (I hope I understand that
right). I'll abandon clarifying this matter for now, but will get back to it in at
most two weeks' time, I think. I'd like to finish the filtering translator and get
sufficiently familiar with libnetfs at first.
But you are right that creating a new interface most likely is easier --
I just wonder whether extending the existing one wouldn't be more
elegant...
But I think we can safely postpone this questions, as we aren't even
sure yet whether new interfaces are needed at all :-)
Agreed. I'll concentrate my attention on libnetfs at the moment.
> Will it be right if I try to read the code of something like ext2fs in
> order to understand how to exhibit an interface complying with
> fs.defs?
I have doubts about this being the best place. Probably better to look
at the helper libraries (trivs/netfs/diskfs), and/or the MiG-generated
server side stubs.
Got it. Thanks for advice!
Well, it was clear that you did understand the underlying file system
doesn't change. But before my latest protest, you still didn't have
understood that accessing a node through special syntax doesn't have
*any* side effects at all... :-)
> As far as I can understand now, if the user wants to access simply
> 'file' after applying '-u', they will always get the node 'file' with
> translators 'x', 'u', 'y', and 'z' -- all the static translators
> present in the underlying filesystem, right?
Exactly.
> So, requests for 'file,,-u' will always yield the same result, won't
> they? (I'm asking this to make sure I understand everything correctly)
Indeed :-) I'm glad we got that sorted out.
Oh yeah! I'm really happy now :-)
scolobb