Em Quarta 15 Fevereiro 2006 12:53, Rodrigo Rosenfeld Rosas escreveu:
>Em Terça 14 Fevereiro 2006 22:30, Jan Kiszka escreveu:
>>...
>>
You cannot mmap before you know precisely for which user this should
take place.
>>>
>>> Do you mean that if I use the 'current' and current->mm struct of
Em Quarta 15 Fevereiro 2006 12:53, Rodrigo Rosenfeld Rosas escreveu:
>Em Terça 14 Fevereiro 2006 22:30, Jan Kiszka escreveu:
>>...
>>
You cannot mmap before you know precisely for which user this should
take place.
>>>
>>> Do you mean that if I use the 'current' and current->mm struct of
Em Terça 14 Fevereiro 2006 22:30, Jan Kiszka escreveu:
>...
>>> You cannot mmap before you know precisely for which user this should
>>> take place.
>>
>> Do you mean that if I use the 'current' and current->mm struct of the
>> driver, when mmaping, the user won't be able to use the returned point
Em Terça 14 Fevereiro 2006 22:30, Jan Kiszka escreveu:
>...
>>> You cannot mmap before you know precisely for which user this should
>>> take place.
>>
>> Do you mean that if I use the 'current' and current->mm struct of the
>> driver, when mmaping, the user won't be able to use the returned point
Rodrigo Rosenfeld Rosas wrote:
> Em Terça 14 Fevereiro 2006 05:55, você escreveu:
>> Rodrigo Rosenfeld Rosas wrote:
>>> I forgot to mention, I have one more problem. Since I call mmap on
>>> driver initialization (thus before any rtdm_dev_open), I do not have any
>>> rtdm_user_info_t, so I need to
Rodrigo Rosenfeld Rosas wrote:
Em Terça 14 Fevereiro 2006 05:55, você escreveu:
Rodrigo Rosenfeld Rosas wrote:
Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Jan Kiszka escreveu:
Ok, but even if you decide to let rt-mmap be non-deterministic, you
still need some means to prevent th
Em Terça 14 Fevereiro 2006 05:55, você escreveu:
>Rodrigo Rosenfeld Rosas wrote:
>> Jan Kiszka escreveu:
>>> Rodrigo Rosenfeld Rosas wrote:
Jan Kiszka escreveu:
> Ok, but even if you decide to let rt-mmap be non-deterministic, you
> still need some means to prevent the scenario you des
Rodrigo Rosenfeld Rosas wrote:
> Em Terça 14 Fevereiro 2006 05:55, você escreveu:
>> Rodrigo Rosenfeld Rosas wrote:
>>> I forgot to mention, I have one more problem. Since I call mmap on
>>> driver initialization (thus before any rtdm_dev_open), I do not have any
>>> rtdm_user_info_t, so I need to
Rodrigo Rosenfeld Rosas wrote:
Em Terça 14 Fevereiro 2006 05:55, você escreveu:
Rodrigo Rosenfeld Rosas wrote:
Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Jan Kiszka escreveu:
Ok, but even if you decide to let rt-mmap be non-deterministic, you
still need some means to prevent th
Em Terça 14 Fevereiro 2006 05:55, você escreveu:
>Rodrigo Rosenfeld Rosas wrote:
>> Jan Kiszka escreveu:
>>> Rodrigo Rosenfeld Rosas wrote:
Jan Kiszka escreveu:
> Ok, but even if you decide to let rt-mmap be non-deterministic, you
> still need some means to prevent the scenario you des
Rodrigo Rosenfeld Rosas wrote:
> Jan Kiszka escreveu:
>
>> Rodrigo Rosenfeld Rosas wrote:
>>
>>
>>> Jan Kiszka escreveu:
>>>
Ok, but even if you decide to let rt-mmap be non-deterministic, you
still need some means to prevent the scenario you described above.
Actually, all you
Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Jan Kiszka escreveu:
Ok, but even if you decide to let rt-mmap be non-deterministic, you
still need some means to prevent the scenario you described above.
Actually, all you need is some callback when the mapped memory block was
actua
Rodrigo Rosenfeld Rosas wrote:
> Jan Kiszka escreveu:
>> Ok, but even if you decide to let rt-mmap be non-deterministic, you
>> still need some means to prevent the scenario you described above.
>> Actually, all you need is some callback when the mapped memory block was
>> actually released (munmap
Rodrigo Rosenfeld Rosas wrote:
> Jan Kiszka escreveu:
>
>> Rodrigo Rosenfeld Rosas wrote:
>>
>>
>>> Jan Kiszka escreveu:
>>>
Ok, but even if you decide to let rt-mmap be non-deterministic, you
still need some means to prevent the scenario you described above.
Actually, all you
Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Jan Kiszka escreveu:
Ok, but even if you decide to let rt-mmap be non-deterministic, you
still need some means to prevent the scenario you described above.
Actually, all you need is some callback when the mapped memory block was
actua
Rodrigo Rosenfeld Rosas wrote:
> Jan Kiszka escreveu:
>> Ok, but even if you decide to let rt-mmap be non-deterministic, you
>> still need some means to prevent the scenario you described above.
>> Actually, all you need is some callback when the mapped memory block was
>> actually released (munmap
Jan Kiszka escreveu:
...
I'm not very sure about that. It can work for most situations but there
could be one situation where it would crash just because it was chosen
to have a little smaller code size and a little speed gain... I would
not like to think in the consequences of a crash in the dr
Rodrigo Rosenfeld Rosas wrote:
> ...
>>> I understand your concernings but I really don't think they are
>>> relevant... This checks will be much faster then the procedure itself
>>> and it would conform to normal munmap behaviour. From man page:
>>>
>>> "The address start must be a multiple of the
Jan Kiszka escreveu:
...
I'm not very sure about that. It can work for most situations but there
could be one situation where it would crash just because it was chosen
to have a little smaller code size and a little speed gain... I would
not like to think in the consequences of a crash in the dr
Rodrigo Rosenfeld Rosas wrote:
> ...
>>> I understand your concernings but I really don't think they are
>>> relevant... This checks will be much faster then the procedure itself
>>> and it would conform to normal munmap behaviour. From man page:
>>>
>>> "The address start must be a multiple of the
...
I understand your concernings but I really don't think they are
relevant... This checks will be much faster then the procedure itself
and it would conform to normal munmap behaviour. From man page:
"The address start must be a multiple of the page size. All pages
containing a part of the ind
Rodrigo Rosenfeld Rosas wrote:
> Jan Kiszka escreveu:
>> Rodrigo Rosenfeld Rosas wrote:
>>
>>> Hi Jan, it just happened once and I couldn't reproduce (I didn't want
>>> to reproduce it too since I would need to restart my computer because
>>> the driver wouldn't unload)...
>>>
>>> When it happene
Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Hi Jan, it just happened once and I couldn't reproduce (I didn't want to
reproduce it too since I would need to restart my computer because the driver
wouldn't unload)...
When it happened I forgot to start the timer running the latency pr
...
I understand your concernings but I really don't think they are
relevant... This checks will be much faster then the procedure itself
and it would conform to normal munmap behaviour. From man page:
"The address start must be a multiple of the page size. All pages
containing a part of the ind
Rodrigo Rosenfeld Rosas wrote:
> Jan Kiszka escreveu:
>> Rodrigo Rosenfeld Rosas wrote:
>>
>>> Hi Jan, it just happened once and I couldn't reproduce (I didn't want
>>> to reproduce it too since I would need to restart my computer because
>>> the driver wouldn't unload)...
>>>
>>> When it happene
Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Hi Jan, it just happened once and I couldn't reproduce (I didn't want to
reproduce it too since I would need to restart my computer because the driver
wouldn't unload)...
When it happened I forgot to start the timer running the latency pr
Rodrigo Rosenfeld Rosas wrote:
> Hi Jan, it just happened once and I couldn't reproduce (I didn't want to
> reproduce it too since I would need to restart my computer because the driver
> wouldn't unload)...
>
> When it happened I forgot to start the timer running the latency program and
Alrea
Hi Jan, it just happened once and I couldn't reproduce (I didn't want to
reproduce it too since I would need to restart my computer because the driver
wouldn't unload)...
When it happened I forgot to start the timer running the latency program and
my driver failed to load and due to some mistak
Hi Jan, I started the tests and had problems on unloading the module.
I am probably doing something wrong but I think the driver shouldn't crash.
Probably it is missing some sanity checks on rtdm_munmap like
if (! (user_info && user_info->mm))
return -EXXX;
I'll investigate the problems
Rodrigo Rosenfeld Rosas wrote:
> Hi Jan, it just happened once and I couldn't reproduce (I didn't want to
> reproduce it too since I would need to restart my computer because the driver
> wouldn't unload)...
>
> When it happened I forgot to start the timer running the latency program and
Alrea
Hi Jan, it just happened once and I couldn't reproduce (I didn't want to
reproduce it too since I would need to restart my computer because the driver
wouldn't unload)...
When it happened I forgot to start the timer running the latency program and
my driver failed to load and due to some mistak
Hi Jan, I started the tests and had problems on unloading the module.
I am probably doing something wrong but I think the driver shouldn't crash.
Probably it is missing some sanity checks on rtdm_munmap like
if (! (user_info && user_info->mm))
return -EXXX;
I'll investigate the problems
Jan Kiszka wrote:
> Hi all,
>
> this is a first attempt to add the requested mmap functionality to the
> RTDM driver API.
... and this version is even more useful than the previous one (now with
EXPORT_SYMBOL!). Be warned: I just compiled it, I count on third-party
testers.
Jan
Index: include/rt
Jan Kiszka wrote:
> Hi all,
>
> this is a first attempt to add the requested mmap functionality to the
> RTDM driver API.
... and this version is even more useful than the previous one (now with
EXPORT_SYMBOL!). Be warned: I just compiled it, I count on third-party
testers.
Jan
Index: include/rt
34 matches
Mail list logo
