Am Freitag, 5. Juni 2015, 13:28:06 schrieb Herbert Xu:
Hi Herbert,
>
> Steffen, I think we need to revisit the idea of having a list
> of callbacks.
Ok, I will reactivate my patch with the list.
>
> Cheers,
--
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-ke
On Tue, May 19, 2015 at 10:18:05PM +0800, Herbert Xu wrote:
> On Tue, May 19, 2015 at 09:50:28AM -0400, Theodore Ts'o wrote:
> >
> > Finally, this is only going to block *once*, when the system is
> > initially botting up. Why is it so important that we get the
> > asynchronous nature of this righ
Am Mittwoch, 20. Mai 2015, 06:55:33 schrieb Herbert Xu:
Hi Herbert,
>
>You still need to handle the case where wait_event_interruptible
>returns an error. Otherwise this looks fine.
Thank you. I would suggest to add a while loop around the call that sets up
the wait if it terminated with ERESTA
On Tue, May 19, 2015 at 04:36:58PM +0200, Stephan Mueller wrote:
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index 9cd6968..6f71354 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -1245,6 +1245,20 @@ void get_random_bytes(void *buf, int nbytes)
> EXPORT_S
Am Dienstag, 19. Mai 2015, 22:30:22 schrieb Herbert Xu:
Hi Herbert,
>On Tue, May 19, 2015 at 04:27:54PM +0200, Stephan Mueller wrote:
>> The current modification with patch 1 to random.c is the smallest change to
>> date. Is that then appropriate?
>>
>> Herbert, based on your comment now, would
On Tue, May 19, 2015 at 04:27:54PM +0200, Stephan Mueller wrote:
>
> The current modification with patch 1 to random.c is the smallest change to
> date. Is that then appropriate?
>
> Herbert, based on your comment now, would the currently discussed patch with
> waiting in the work queue in patch
Am Dienstag, 19. Mai 2015, 22:18:05 schrieb Herbert Xu:
Hi Herbert,
>On Tue, May 19, 2015 at 09:50:28AM -0400, Theodore Ts'o wrote:
>> Finally, this is only going to block *once*, when the system is
>> initially botting up. Why is it so important that we get the
>> asynchronous nature of this ri
On Tue, May 19, 2015 at 09:50:28AM -0400, Theodore Ts'o wrote:
>
> Finally, this is only going to block *once*, when the system is
> initially botting up. Why is it so important that we get the
> asynchronous nature of this right, and why can't we solve it simply by
> just simply doing the work in
On Tue, May 19, 2015 at 03:51:55PM +0800, Herbert Xu wrote:
> On Tue, May 19, 2015 at 09:35:15AM +0200, Stephan Mueller wrote:
> >
> > Thank you for the hints. I will follow your guidance.
> >
> > Just for my edification: why is this (rather complex sounding) approach
> > preferred over a simple
Am Dienstag, 19. Mai 2015, 15:51:55 schrieb Herbert Xu:
Hi Herbert,
>You're right. The cancel function is indeed simpler. I can
>certainly live with that.
Thank you. I will test my patch a bit more and then release it with the
discussed changes.
Ciao
Stephan
--
To unsubscribe from this list:
On Tue, May 19, 2015 at 09:35:15AM +0200, Stephan Mueller wrote:
>
> Thank you for the hints. I will follow your guidance.
>
> Just for my edification: why is this (rather complex sounding) approach
> preferred over a simple cancel API? Other async APIs (e.g. the AIO syscalls
> with io_cancel)
Am Dienstag, 19. Mai 2015, 15:22:27 schrieb Herbert Xu:
Hi Herbert,
> On Tue, May 19, 2015 at 07:58:25AM +0200, Stephan Mueller wrote:
> > Herbert, do you have any ideas?
>
> On the /dev/random side,
>
> 1) Add a struct module argument in addition to func/data.
> 2) Grab module ref count when f
On Tue, May 19, 2015 at 07:58:25AM +0200, Stephan Mueller wrote:
>
> Herbert, do you have any ideas?
On the /dev/random side,
1) Add a struct module argument in addition to func/data.
2) Grab module ref count when func/data is registered.
3) Drop module ref count after func returns.
On the drbg
Am Montag, 18. Mai 2015, 11:02:34 schrieb Theodore Ts'o:
Hi Theodore, Herbert,
>
> The simplest thing to do is to put a refcount on inside the DRBG
> handle structure. The caller instantiates the DRBG handle, and
> invokes the the DRBG. The DRBG, since it is kicking off an
> asynchronous operat
On Mon, May 18, 2015 at 03:26:13PM +0200, Stephan Mueller wrote:
>
> I am just running into an interesting problem with a missing cancel
> operation:
> a caller instantiates a DRBG handle and invokes the seeding operation. The
> nonblocking_pool is not initialized. Therefore, the callback is pu
Am Montag, 18. Mai 2015, 15:07:10 schrieb Stephan Mueller:
Hi Herbert,
>>
>>You can simplify this further and get rid of buf/nbytes. All
>>we need to know is whether the pool is ready. Everything else
>>can come from private.
>
>So, the async function is now just a notification of the caller. S
Am Montag, 18. Mai 2015, 17:21:31 schrieb Herbert Xu:
Hi Herbert,
>> +/*
>> + * Equivalent function to get_random_bytes with the difference that this
>> + * function blocks the request until the nonblocking_pool is initialized.
>> + */
>> +int get_blocking_random_bytes_cb(void *buf, int nbytes, v
On Mon, May 18, 2015 at 07:32:01AM +0200, Stephan Mueller wrote:
>
> Thanks for the hint to the list. Before handing in another formal patch, may
> i ask for checking the following approach? I would think that this one should
> cover your concerns.
Yes this is definitely going in the right dire
Am Freitag, 15. Mai 2015, 14:46:26 schrieb Herbert Xu:
Hi Herbert,
> On Wed, May 13, 2015 at 09:54:41PM +0200, Stephan Mueller wrote:
> > /*
> >
> > + * Equivalent function to get_random_bytes with the difference that this
> > + * function blocks the request until the nonblocking_pool is initia
On Wed, May 13, 2015 at 09:54:41PM +0200, Stephan Mueller wrote:
> /*
> + * Equivalent function to get_random_bytes with the difference that this
> + * function blocks the request until the nonblocking_pool is initialized.
> + */
> +void get_blocking_random_bytes(void *buf, int nbytes)
> +{
> +
The added API calls provide a synchronous function call
get_blocking_random_bytes where the caller is blocked until
the nonblocking_pool is initialized.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
drivers/char/random.c | 14 ++
includ
21 matches
Mail list logo
