Re: [Xenomai] Modified rtcan_virt driver

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

Le 11/10/2012 08:23, Jan Kiszka a écrit :
> 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
>
I got it.
What you mean is that the topology is described by a

unsigned int virt_bus[NB_MAX_BUSES];

and the entries are the number of devices for each bus.
So the existing would be virt_bus[0] = devices; ('devices' is the existing module option)

and for the usage I want (I have 2 buses)

virt_bus[0] = 2;
virt_bus[1] = 2;

I find your idea to publish the topology via /proc great. I could also come
with a nice display tool, like "lspci -t" does, and also have the "lspci -mm" way.
What about lsrtcan ?

However, making it userland configurable needs more detailed specications,
what are you thinking about exactly ? Are we talking about the module loading
(I do not think so because you said no newer option)
or an ioctl ?

Thierry