On 05/12/2018 13:39, Rafał Miłecki wrote:
On 2018-12-05 13:31, Paul Oranje wrote:
Op 4 dec. 2018, om 12:32 heeft Rafał Miłecki <zaj...@gmail.com> het
volgende geschreven:
From: Rafał Miłecki <ra...@milecki.pl>
Device gets removed from the list (vlist_delete()) when block calls
"hotplug" method of blockd using ubus. Right after that block unmounts
that device on its own.
blockd shouldn't care about unmounting on its own for following
reasons:
1) To avoid code/behavior duplication with blockThe chicken or the
eggThe chicken or the egg
2) To keep behavior consistent with mounting (blockd doesn't mount)
3) To allow implementing more features in block (e.g. hotplug.d events)
The design should be to:
1) Have block handle (un)mounting
2) Use blockd for providing devices/mounts state (using ubus)
3) Have blockd handle autofs and call block when needed
Can this cause a transition into a state where a device is (still)
mounted but removed from the list, and if so, is that a valid, an
admissible state ? Shouldn't block be required to first unmount before
calling blockd's hotplug entry ?
The chicken or the egg? ;)
We don't have any mutex/semaphore mechanism in place right now. So
unless that gets implemented, we have to chooce what's better.
I believe the correct order would be to:
1) Stop reporting mounted device
2) Notify all users about unmounting (hotplug.d event I work on)
3) Unmount
That's the safest way that will stop applications from trying to access
device due to blockd incorrectly reporting it as mounted.
please update the description before pushing
Acked-by: John Crispin <j...@phrozen.org>
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
