Re: [Xenomai] Modified rtcan_virt driver

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

On 2012-10-11 09:27, Thierry Bultel wrote:
> 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];

No, I'm thinking of

static unsigned int devices[NB_MAX_BUSES] = { 2 };

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

We already have rtcanconfig, and the virtual buses are a special case,
so I wouldn't overdo here.

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

I mean to make the userland program configurable, telling it on the
command line or wherever which rtcan devices belong to a single bus.

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/65cfa0af/attachment.pgp>