Re: Sysfs and suicidal attributes

Cornelia Huck
2007-07-09T15:26:21Z

On Sun, 8 Jul 2007 10:31:21 -0400 (EDT),
Alan Stern <stern@rowland.harvard.edu> wrote:

> There are some ways around this such as using a different workqueue,
> one that could safely be blocked during the suspend.

This would be the simplest solution, I think.

> The user writes to an attribute file.
>
> The sysfs core calls the attribute's store method.
>
> The method tells the sysfs core to pretend that the call
> temporarily doesn't exist, or has completed, or something
> like that.

Or add an ignore-for-now-flag to the buffer? It would need to be
processed in a second pass.

> The method safely unregisters the attribute file, with no
> mutual exclusion problems and no deadlock. Of course, the
> unregistration will still block until all _other_ method
> calls for this attribute are complete.
>
> The method tells the sysfs core to stop pretending and
> go back to its normal state.
>
> The method returns, and the sysfs core takes whatever actions
> are needed to fully release the attribute file.

It would need to retain a reference to the buffer collection so it can
get rid of the formerly-ignored buffer.

> The idea is that there could be a way to allow unregistration while a
> method is still running, if the method specifically requests it. If we
> could do this then device_schedule_callback() would be unnecessary.
>
> What do you think?

I don't think that this is easy to get correct. Another workqueue looks
like a solution which is easy to get right, even if it may not seem so
nice.