Em Quarta 08 Fevereiro 2006 16:26, Jan Kiszka escreveu:
>>>> ...
>>>> Jan, actually I didn't like the /dev/zero hack. If someone else is
>>>> using /dev/zero it will result in a problem... I think it would be
>>>> better to
>>>
>>> Why? It isn't an exclusive device. And I'm only invoking open/close on
>>> the original instance (which even have no handlers associated, see
>>> drivers/char/mem.c), mmap gets overloaded.
>>
>> I'm a little confused here. I noted you have made a backup of the
>> file_operations struct and private_data. So, I've concluded, wrongly, that
>> those handlers would be used by every process that called that open
>> handler. But, looking at the mem.c code, I think that those data (file_ops
>> and private_data) are different structs each time the user issues a call
>> to open.
>
>Yep, that's the point. Actually, I was inspired by some other mmap'ing
>driver which does a similar overloading on it's own device type.
>
>> If that is true, I don't see any problem in using your approach. But I
>> don't see neither any needs for making that backup...
>
>On first sight this is true and the backup is redundant. But it is
>cleaner to not rely on a specific kernel implementation.
But if the kernel implementation will change it won't be safer to operate this
way... Because someone else could try to use the /dev/zero while you changed
the handlers... If this happens some day, you could change /dev/zero to some
file descriptor or your own then.
>Instead it's
>saner to look at the model: I'm changing the fops without knowing what
>the open handler did, so make sure that a possible release handler can
>run. And this is also not very costly here. :)
Ok, I got your point. You mean if the driver rely on fops when releasing. Ok,
I think that the approach you suggested is great. As I've said I would only
change the return of rtdm_mmap_to_user to NULL on error. Then you could add
it to RTDM...
Rodrigo.
_______________________________________________________
Yahoo! doce lar. Faça do Yahoo! sua homepage.
http://br.yahoo.com/homepageset.html
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
