> > Changes from V3 to V4:
> > ----------------------
> > 1. As suggested by Peter, use completions instead of flush_work() as the
> > former is cheaper
> > 2. Call efi_delete_dummy_variable() from efisubsys_init(). Sorry! Ard,
> > wasn't able to find a better alternative to keep this change local to
> > arch/x86.
> >
>
> Two questions:
> - Should the non-blocking variants of the query and set_variable_store use the
> work queue? Doesn't that make them blocking?
That's a good question . I think you are right, calling non-blocking variants of efi_rts
using work queues makes them blocking. But, I have a follow on question.
Assume some user requested to execute some non-blocking variant of efi_rts and
the kernel hasn't called efi_call_virt() yet, but was scheduled out. IOW, even though
user requests for non-blocking efi call, we might still block. Am I right?
With efi_rts_wq, I think, I have increased the window of getting blocked. With efi_rts_wq,
kernel should explicitly call schedule() to run firmware and the chances of getting blocked
are much more.
Expect this increased window, I think firmware should be executed as before.
So, can you please explain me the difference between blocking and non-blocking variants
from kernel perspective?
(the way we get locks are different down_interruptible() vs down_trylock())
> - If the non-blocking set_variable() does not use the work queue, can we just call
> it from efi_delete_dummy_variable(), and keep the calls where they are?
Yes, I think we can do that (if we don't use efi_rts_wq for non-blocking variants).
Regards,
Sai
��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
