Re: [Xenomai] Modified rtcan_virt driver

[Thierry Bultel <thierry.bultel@wanadoo.fr>]

Le 11/10/2012 06:50, Jan Kiszka a écrit :
> On 2012-10-04 15:26, Gilles Chanteperdrix wrote:
>> On 10/04/2012 02:58 PM, Thierry Bultel wrote:
>>> Le 04/10/2012 14:36, Gilles Chanteperdrix a écrit :
>>>> On 10/04/2012 02:15 PM, Thierry Bultel wrote:
>>>>> Hi,
>>>>>
>>>>> The existing rtcan_virt driver simulates a single CAN bus, on which are
>>>>> N devices.
>>>>> Sending to one dispatches the frame to all the others but the not to the
>>>>> sender.
>>>>>
>>>>> This has several disadvantages:
>>>>>
>>>>> - First, to run an application that uses 2 or more physical buses, it
>>>>> does not fit, because both devices would be linked together.
>>>>> - Second, having N instantiated virtual devices is in some cases not
>>>>> necessary, because an application can open the
>>>>> same device several times, and simulate many CAN nodes, on that single
>>>>> device.
>>>>>
>>>>> Thus I have written another rtcan_virt driver, based on the original one.
>>>>>
>>>>> Its behavior is as follows:
>>>>>
>>>>> - It instantiates N rtcan devices, that are independent (no frame from
>>>>> one to another)
>>>>> - Each virtual rtcan (rtcan0, rtcan1 ...) device has a matching peer
>>>>> (rtcan0s, rtcan1s ...)
>>>>> ('s' like 'slave' but I am opened to any other naming) another to
>>>>> communicate with.
>>>>> That 'slave' device isautomatically created.
>>>>> I say 'slave' in quotes because the word hides the symmetrical aspect,
>>>>> so it is likely unappropriate..
>>>>>
>>>>> It is today fully tested, my question was if it could be of interest for
>>>>> the Xenomai mainline.
>>>>> If Yes:
>>>>> - some questions come, to my mind the most important one is if is a new
>>>>> driver, or a patch for the existing one,
>>>>> to modify its behavior depending on a parameter. If it is a new one,
>>>>> what would be the appropriate name ?
>>>>> - I would be happy to make it as a patch (not ready for that yet, and
>>>>> until the first questions are answered)
>>>>>
>>>>> If No, I just apologize for the noise.
>>>> I think it is interesting, what about linking the odd ones to the even
>>>> ones for the symetry?
>>>>
>>> I have been thinking about it, but that would break a 'I do not modify
>>> my application' rule.
>>> In my special case, the app uses buses "0" and "1", that the CanFestival
>>> stack translates to "rtcan0" and "rtcan1"
>>>
>>> It is Ok to have the "emulated remote nodes" configured to use whatever
>>> "rtcan" name,
>>> but from the application point of view it should be transparent.
>> Ok, then, what about adding an "nr_devs" parameter to rtcan_virt, and
>> linking device #n with device #n + nr_devs for n between 0 and nr_devs - 1 ?
>>
> You could make 'devices' an array and create a bus for each non-zero
> array entry. Like with the number of virtual devices, this will just
> require an upper limit of buses.
>
> Jan
>
Sure, but what would be you prefered naming rule for the "slave" devices ?
I do not completely agree with Gilles' last proposal, because even if there
is a logical matching (eg slave# = master# + n), the relationship is not
trivial from userland, especially when you use both virtual and real driver(s).

And for the driver itself ? Shall I create a new one (if yes what would be its name ?),
or add an option to the existing,
for creating devices in the "peer to peer" mode ?

Thierry