linux-kernel - Re: [PATCH v10 0/7] Add Fieldbus subsystem + support HMS Profinet card

lists.openwall.net		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 11:10:17 -0400
From:   Sven Van Asbroeck <thesven73@...il.com>
To:     Oliver Hartkopp <socketcan@...tkopp.net>
Cc:     Andreas Färber <afaerber@...e.de>,
        "Enrico Weigelt, metux IT consult" <lkml@...ux.net>,
        Linus Walleij <linus.walleij@...aro.org>,
        Lee Jones <lee.jones@...aro.org>, mark.rutland@....com,
        treding@...dia.com, David Lechner <david@...hnology.com>,
        noralf@...nnes.org, johan@...nel.org,
        Michal Simek <monstr@...str.eu>, michal.vokac@...ft.com,
        Arnd Bergmann <arnd@...db.de>,
        Greg KH <gregkh@...uxfoundation.org>, john.garry@...wei.com,
        geert+renesas@...der.be, robin.murphy@....com,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        sebastien.bourdelin@...oirfairelinux.com, icenowy@...c.io,
        Stuart Yoder <stuyoder@...il.com>,
        "J. Kiszka" <jan.kiszka@...mens.com>, maxime.ripard@...tlin.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH v10 0/7] Add Fieldbus subsystem + support HMS Profinet card

Hello Oliver, thank you for your input, appreciate it !

On Wed, Apr 24, 2019 at 7:50 AM Oliver Hartkopp <socketcan@...tkopp.net> wrote:
>
> 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?!?

Close ! Devices that "feel like" a Fieldbus _device_ can register.

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

The commit message fully describes this, and so does the
Documentation. Any improvements are welcome.
https://lkml.org/lkml/2019/4/16/817
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/tree/drivers/staging/fieldbus/Documentation/fieldbus_dev.txt?h=staging-next

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.

This subsystem came about because I'm trying to mainline
support for three HMS cards: FLNet, Profinet and CC-Link.
These cards are not controllers, but slaves on the bus.
All three make heavy use of process memory. From the
get-go, the kernel reviewers made it clear that the userspace
cannot be specific and must be generic. So I crafted a generic
ABI that works for clients on process-memory based busses,
and called it 'fieldbus_dev', for lack of a better name.

I'm by no means a fieldbus expert. It seems that the term
'fieldbus' is much broader than these process-memory based
standards? I am open to any _concrete_ naming suggestions
that can get consensus.

I'm a bit confused by Wikipedia's entry for fieldbus.
It suggests that IEC 61158 and Fieldbus are
interchangeable?
https://en.wikipedia.org/wiki/Fieldbus

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

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

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

Also no good for bus controllers, the subsystem deals
with slave devices only.

Sven