[OpenWrt-Devel] [PATCH fstools V3 1/2] Revert "block: mount_action: handle mount/umount deps"

Rafał Miłecki zajec5 at gmail.com
Fri May 1 05:09:03 EDT 2020


Sorry for a late reply :|

On 02.04.2020 14:35, Jo-Philipp Wich wrote:
> instead of reverting the hierarchical mount handling, isn't fixing the
> unintended mounts just a matter of doing a prefix compare during
> vlist_for_first_to_element() traversal?
> 
> Assuming that `the_dev` refers to the block we do want to mount and `dev` is
> the iterator pointing to each `dev` which is lexically ordered before
> `the_dev`, would something like the below code suffice?

I don't really like that as it's just patching something that wasn't
properly designed in the first place.

1. Not every entry has mount point but we try sorting by it anyway
2. Mounts points are only read from UCI - current code ignores those
    "dynamic" ones.
3. It handles a single case only (with limitations) - what if another
    case requires sorting by label name? That could be desired when
    presenting all devices to a user. Or what if I want to sort by
    device path (which sounds the most natural by the way)?

So instead forcing fstools low level design based on a single use case
we should rather have:
1) Generic low level design
2) High level code handling specific needs

I posted a WIP patch showing how this could be handled without forcing
the way fstools stores its entries on the low level:

[PATCH fstools WIP] block: check for parent mount point before mounting

I believe above PATCH could be used to handle hierarchical mounting.
Your code from attached diff (dev->m->target handling) is something I
didn't figure out before and could be useful in that WIP work.

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



More information about the openwrt-devel mailing list