Re: [PATCH] [UBI] 1/4 UBI volume notifications - UBI changes

[Artem Bityutskiy <dedekind@infradead.org>]

On Thu, 2008-12-11 at 12:25 +0300, dmitry pervushin wrote:
> > > > I do not understand this change. The point is to prevent anyone from
> > > > opening the volume before it is completely initialized. What you do -
> > > > you allow the volume to be opened while it is in the middle of
> > > > initialization, which is wrong. E.g., what if the initialization fails
> > > > at some point?
> > > > 
> > > > And this change does not seem to be relevant to this patch.
> > > This change is absolutely needed :)
> > > Well, the sequence of steps is as follows:
> > > 1. uif_init calls ubi_add_volume
> > > 2. ubi_add_volume notifies everyone about volume adding
> > > 3. (successful exit is not interested to us)
> > > 4. in case of errors reported by uif_init ubi_attach_mtd_dev calls
> > > ubi_kill_volumes
> > > 5. ubi_kill_volumes calls ubi_free_volume, which notifies everyone about
> > > volume deleting.
> 
> Isn't it better then to protect the critical section in uif_init and
> open_volume by mutexes?

May be. If you need this, feel free to send a patch. But it would not
give you much, because you would have to call your notifiers _outside_
the mutexes, i.e. at the very end of the attach function.

>  Now it looks as you are adding volumes on
> non-existing-yet device.

Right. For a short period of time during the attach process you may see
volumes which you cannot really open (you get -ENODEV). That was not a
problem so far, and it was just easier to implement things this way.

If you want to improve this and make the opening processes wait on a
mutex - please, go ahead. But I doubt you really need this.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)