Re: [Xenomai] Modified rtcan_virt driver

[Jan Kiszka <jan.kiszka@web.de>]

On 2012-10-11 08:08, Thierry Bultel wrote:
> 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 ?

Keep it simple, just number them consecutively as they need to be
created according to the array.

> 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).

You could a) make userland configurable in the same way, telling it
rtcanN..M is bus X, or export the rtcan_virt topology via its /proc folder.

> 
> 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 ?

My proposal is fully compatible with the existing driver as no new
parameter is added. Existing users can continue to consider 'device' as
an array with only one entry.

Jan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20121011/dde82570/attachment.pgp>