Re: [OE-core] [PATCH 05/17] unfs: update 0.9.22 -> 0.10.0

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2022-11-24 at 14:07 +0100, Alexander Kanavin wrote:
> On Tue, 22 Nov 2022 at 16:09, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > It would help, yes. If you do that it could be good to understand and
> > document which areas we do/don't have test coverage of some kind for as
> > we could then look at either adding it or dropping that support if it
> > isn't used.
> 
> I sent a second version where each patch is separately reviewed for
> necessity, and also the runqemu use of unfsd is manually tested and
> fixed (there's no test or usage of it on the AB).

Thanks, the details in the review there are really helpful and the
patch is clearly a good improvement to the situation. I'm happy the
situation is well documented now. I'd forgotten the NFS ports situation
was clearly resolved in 2017!

> The scenario with qemu is that when given a tarball or directory with
> a rootfs, the content of that is extracted and given to a nfs server.
> Then the kernel is instructed to mount / from that nfs share, instead
> of reading it from a file. I'm not sure what use case this fulfils
> that can't be done with 'standard' .wic or .ext4 rootfs files.

There is one really neat scenario where if booted that way, you can
change files on the emulated system "live" directly from the host's
filesystem. For some kinds of development or debugging, having a
fast/instant way to sync things to the target as a normal filesystem
can be very helpful. For that reason we should keep it around, it is
part of our more unique developer support.

Do we need special privileges to be able to run that?

Thanks again for looking at it, it does look much better as a patch
now!

Cheers,

Richard