[Xenomai] Modified rtcan_virt driver

[Xenomai] Modified rtcan_virt driver

[Thierry Bultel]

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.

Cheers
Thierry

Re: [Xenomai] Modified rtcan_virt driver

[Gilles Chanteperdrix]

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?

-- 
					    Gilles.

Re: [Xenomai] Modified rtcan_virt driver

[Thierry Bultel]

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.

Re: [Xenomai] Modified rtcan_virt driver

[Gilles Chanteperdrix]

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 ?

-- 
					    Gilles.

Re: [Xenomai] Modified rtcan_virt driver

[Jan Kiszka]

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

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

Re: [Xenomai] Modified rtcan_virt driver

[Thierry Bultel]

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

Re: [Xenomai] Modified rtcan_virt driver

[Jan Kiszka]

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>

Re: [Xenomai] Modified rtcan_virt driver

[Thierry Bultel]

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

Re: [Xenomai] Modified rtcan_virt driver

[Jan Kiszka]

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>