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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d54b294e-d641-bb14-84ed-39d9a9079dc7@hartkopp.net>
Date:   Wed, 24 Apr 2019 13:48:31 +0200
From:   Oliver Hartkopp <socketcan@...tkopp.net>
To:     Andreas Färber <afaerber@...e.de>,
        "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
Cc:     Sven Van Asbroeck <thesven73@...il.com>,
        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

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