lkml.org 
[lkml]   [2019]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v10 0/7] Add Fieldbus subsystem + support HMS Profinet card
From
Date
On 24.04.19 13:00, Andreas Färber wrote:
> Am 24.04.19 um 12:26 schrieb Oliver Hartkopp:

>> The Controller Area Network also belongs to the class of field busses
>> and has its own networking subsystem in linux/net/can.
>>
>> So using a 'class' of communication protocols as naming scheme doesn't
>> fit IMHO.
>
> And - again - NACK. Calling a subsystem just iec61158 is going to hide
> what it is and stand in the way of development of this niche system. I
> asked Enrico to come up with a better naming proposal such as having
> iec61158 as subfolder to human-readable fieldbus, but I did not see him
> coming up with any such new proposals apart from repeating this name.
>
> Also please read Sven's comment again: It you don't like the current
> naming you'll need to post follow-up patches, as v11 of this subsystem
> has been merged into staging. No complaint about piggy-backing on v10 is
> going to change that fact now!
>
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/tree/drivers/staging/fieldbus?h=staging-next
>
> And since we're at it, Enrico's response to me just threw around a bunch
> of acronyms instead of explaining which ones have an _actual_ conflict
> with this subsystem - my point precisely was that if they use sockets or
> ttys then there's no real conflict apart from lots of things classifying
> as "fieldbus".

Ok, I either tried to get through the fieldbus code and the
documentation from above.

I hopefully got it right by: You implemented a standardized chardev ABI
that enables a data exchange between userspace and kernel, where other
drivers can register 'from inside the kernel', that feel like being a
fieldbus controller?!?

When checking out the Anybus website the first hit for serial fieldbus
is https://www.anybus.com/technologies/fieldbus-serial/can-canopen .

CANopen is CAN based - and the CAN network drivers and CAN controllers
definitely do not expose sysfs entries like

/sys/class/fieldbus_dev/fieldbus_devX/write_area_size

How can this fit together for me and what would be the plan to cover
CANopen or EtherCAT in the fieldbus subsystem? Does it need some kind of
CANopen protocol driver that registers to your ABI and speaks to CAN
interfaces on the other side?

If this would have been outlined more clearly I wouldn't have stumbled
over the fieldbus naming scheme.

Regards,
Oliver

\
 
 \ /
  Last update: 2019-04-24 13:51    [W:0.084 / U:3.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site