"Right" way to construct a VFS for a test

[Justin Mattson]

I find I'm trying to serve a Directory for a test I'm writing and I've never had occasion to look at doing this from the start. Is there a recommended library or example to do this? I'm writing in Rust, so I'm guessing this VFS lib is what I want. If that is the case I'm wondering if there is a map for what I need to plug together to create a thing that actually speaks the FIDL directory protocol.

I'm sure if I rummage around I'll find examples in the codebase of doing just what I'm asking, but my impression is there has been a fair deal of flux on the "right" way of doing this and I'm not sure I'd stumble on this "right" path.

My guess is that I need to implement the Directory trait and then hand that to BaseConnection::new? But then I think I'd want to hand this to something which also takes the server end of a FIDL Directory channel and gives me a future that listens for requests on the channel. Does that seem about right?

Cheers,

Justin

[Yegor Pomortsev]

Try the pseudo_directory! macro or TreeBuilder.

--
All posts must follow the Fuchsia Code of Conduct https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
---
You received this message because you are subscribed to the Google Groups "component-framework-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to component-framewo...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CA%2BX8dX-RCjfNun868f9WR556oFU6zQ%2BuwaRVga8wkV61TfH9Hw%40mail.gmail.com.

[John Wittrock]

Software Delivery has a bunch of examples of these in //src/sys/pkg, mostly in combination with RealmBuilder. If you're not using RealmBuilder, the implementation should still be similar - you just need to hook it up to whatever is serving FIDL.

Here's an example I referenced yesterday from the pkg-resolver tests. This is serving multiple directories from the same local_child.

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAMmMHD6diwvHLQneDucU5mt16gez29at9CUYkexSDVzfDpBTUA%40mail.gmail.com.

[Stephen Demos]

Hey Justin,

Are you just trying to set up a pseudo-dir with some fake files in it for your test? If so, you can use the pseudo_directory! macro and place different kinds of pseudo-files depending on what you need. Then you can just use the DirectoryEntry trait to open the initial connection to it.

Thanks,

Stephen

On Wed, Oct 12, 2022 at 9:18 AM 'Justin Mattson' via component-framework-dev <component-f...@fuchsia.dev> wrote:

--

[Justin Mattson]

I'm trying to see, but does this macro support `query_filesystem`? This is really the call that I need to support for the test.

Cheers,

Justin

How am I doing? (anonymous feedback)

[Stephen Demos]

No, I don't think we implement QueryFilesystem for our pseudo-fs stuff in rust. If you need that, it might be easier to set up a memfs for your test, either through whatever mechanism you can use to ask for some temporary storage from component manager, or setting up a memfs child component. It's also possible that we should implement QueryFilesystem for the pseudo-fs stuff, I'm not sure, I would have to think about that more.

[Justin Mattson]

Since I need to implement QueryFilesystem I figured I wanted a new ImmutableConnection, which I constructed, giving it a reference to my mock directory that implements the Directory trait. Then I figured I would connect I/O requests to the ImmutableConnection struct with creation_connection, but what the heck is the `directory` arg supposed to be?

Thanks,

Justin

[Stephen Demos]

Trying to make your own new node implementation in the rust vfs today will likely lead to pain and suffering. What exactly are you trying to do?

[Justin Mattson]

will likely lead to pain and suffering.

Can confirm. 

I'm surely doing something wrong, but what I'm trying to do overall is mock out a StorageAdmin server. Specifically I want to allow the code to call OpenComponentStorageById and connect to something that speaks the Directory protocol and be able to call QueryFilesystem.

[Stephen Demos]

Is the reason you call QueryFilesystem to confirm that the type of filesystem you are getting back is the one you expect then?

[Justin Mattson]

No, it is to check the filesystem utilization.

[Stephen Demos]

As in, just to make sure that whatever is on the other end of the StorageAdmin api will respond to requests? If you just want to check the responsiveness, I would try just calling GetAttr. If it needs to have a specific response depending on the test, I would recommend constructing directories with well-known files in them and making sure those exist when you call the api. If you need something more complicated than that, let me know, because it'll start getting into a rabbit hole.

[Justin Mattson]

Not just to check responsiveness, to check what percentage of storage is used. Mocking StorageAdmin is relatively easy. The problem is that to check filesystem storage utilization I need to get a Directory and then use QueryFilesystem to get a FilesystemInfo object. Wiring things up to do this seems like it is hard.

I feel like I'm missing something though because it seems like I want to do whatever the macro! is doing, plus a little more and it seems like I should be able to type what the macro generates.

Cheers,

Justin

[Stephen Demos]

Hmm, interesting. That gets into a bit of a weird area - what does filesystem utilization mean for pseudo files? I suppose for testing you want to be able to control what the utilization says, so that you can test different scenarios of space usage. So basically, you want an otherwise normal directory, but you want to override the response to QueryFilesystem for testing? Or did I jump too far, maybe you just want any QueryFilesystem response at all?

[Justin Mattson]

In the real world my code will actually want to know what the utilization of a disk-backed filesystem is. In a test, well, I just want to fake it.

[Stephen Demos]

If you just want a QueryFilesystem response at all, I think it's probably fine to make pseudo directories respond with something other than NOT_SUPPORTED, just populated with mostly zeros. Does that work, or do you need to specifically control the response to test different scenarios?

[Justin Mattson]

My problem is more, how do I create a directory that can even give that response. The current guidance is "use a macro", but that macro doesn't do what I need. What pieces can I use instead?

[Stephen Demos]

Sorry, I meant If all you need is any valid response from QueryFilesystem, then if we modify the vfs crate to have an implementation of query_filesystem in the Directory impl for pseudo directories, the macro will work. If that's all you need, then my original suggestion of using memfs to back the mock directory instead of the rust vfs will also work.

[Justin Mattson]

I understand your question better now, no, I need to control the response from QueryFilesystem.

[Stephen Demos]

Hmm, okay. One more question - is QueryFilesystem the _only_ thing you need responses from? Or do you need this node to respond to all the normal Directory requests, but _also_ have a custom QueryFilesystem response?

This is a last-ditch attempt before making you work with the internals of the rust vfs - if QueryFilesystem is all you need to respond to we might be able to set up a service node that "implements" Node as it's protocol and just responds to that one call. If you need a real directory with controllable QueryFilesystem responses then you were right about having to build something bespoke. I can help you out with that but I would love to avoid it if possible.

[Justin Mattson]

No, it really only needs to handle that one response.

I really thought this should be easy that there would be some sort of request handler type that accepts something that implements a couple of traits and then handles translating FIDL traffic into calls on to the struct that implements the traits.

[Stephen Demos]

That would be awesome wouldn't it? The rust vfs needs a lot of work.

If you only need to handle QueryFilesystem, try using a Service node that takes a NodeRequestStream and responds with the data you want when the request is QueryFilesystem and errors on all other calls. Here is an example of using the host function.

[Justin Mattson]

Just a quick follow-up here that after enough stumbling around I finally got things to do what I needed after I understood enough of how the different pieces were supposed to interact.

[Wez]

Apologies to come late to this, but are you looking for something like the "_TestBase" bindings that are generated for C++ from FIDLs, which let you just override the parts of the protocol your test will call?

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CA%2BX8dX-oByvW79MiRZksSChanWHNO7T%2B2QAnazp5PuTaetB91Q%40mail.gmail.com.