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] [day] [month] [year] [list]
Date:   Mon, 29 Apr 2019 15:54:30 +0200
From:   "Enrico Weigelt, metux IT consult" <>
To:     Sven Van Asbroeck <>,
        Oliver Hartkopp <>
Cc:     Andreas Färber <>,
        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 17:10, Sven Van Asbroeck wrote:

> The subsystem is called fieldbus_dev "fieldbus device" because it> abstracts Linux fieldbus clients that want to expose themselves as>
e.g. an actuator, motor, console light, switch, ...
Sounds a bit confusing. With that description, I'd expect highlevel
interfaces similar to LED, input, IIO, etc ... but you're actually
implementing an distributed process memory system. This in turn is
just a subset of the fieldbus world.

> During one of the eleven review cycles, drivers/fieldbus_dev got> truncated to drivers/fieldbus because the reviewers felt that> _dev
was redundant, given the lack of other fieldbus> subsystems.
There is at least one: CAN. Sometimes CAN is used in the IEC61158-way,
but also completely different, even both in combination.

> These cards are not controllers, but slaves on the bus.

Do they really implement the process memory part or just the lower
layer communications ?

> I'm by no means a fieldbus expert. It seems that the term> 'fieldbus' is much broader than these process-memory based> standards?

Yes, indeed.

> I am open to any _concrete_ naming suggestion
> that can get consensus.
Maybe IEC61158 ?

> I'm a bit confused by Wikipedia's entry for fieldbus.
> It suggests that IEC 61158 and Fieldbus are
> interchangeable?

That's wrong.

> <quote>
> Fieldbus is the name of a family of industrial computer
> network protocols used for real-time distributed control,
> standardized as IEC 61158.
> </quote>

IEC 61158 only standardizes one particular approach: the distributed
process memory.

> Given that CAN/EtherCAT are not process memory based
> (that I know of), the fieldbus_dev subsystem is probably
> not a good fit.

ACK. Neither are MVB+friends.


Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering -- +49-151-27565287

Powered by blists - more mailing lists