lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 24 Apr 2019 13:48:31 +0200
From:   Oliver Hartkopp <>
To:     Andreas Färber <>,
        "Enrico Weigelt, metux IT consult" <>
Cc:     Sven Van Asbroeck <>,
        Linus Walleij <>,
        Lee Jones <>,,, David Lechner <>,,,
        Michal Simek <>,,
        Arnd Bergmann <>,
        Greg KH <>,,,,
        Paul Gortmaker <>,,,
        Stuart Yoder <>,
        "J. Kiszka" <>,,
        Linux Kernel Mailing List <>,
        netdev <>
Subject: Re: [PATCH v10 0/7] Add Fieldbus subsystem + support HMS Profinet

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

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


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.


Powered by blists - more mailing lists