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]
Date:   Wed, 17 Apr 2019 19:04:37 +0200
From:   Andreas Färber <>
To:     "Enrico Weigelt, metux IT consult" <>
Cc:     Sven Van Asbroeck <>,
        Rob Herring <>,
        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

Hi Enrico,

Am 16.04.19 um 18:49 schrieb Enrico Weigelt, metux IT consult:
> On 15.04.19 20:31, Sven Van Asbroeck wrote:
>>> Maybe it would be better calling it "IEC-61158" instead of "fieldbus" ?>>> > Yes, we are certainly open to that, if it is more correct and/or
> better> accepted by users.
> Thanks, I'd really appreciate that :)
> Maybe I'm a bit beaurocratic here, but I really believe that precise
> naming is important, eg. for avoiding potential conflicts w/ different
> fieldbus classes (eg. mvb) that might come in the future.

I somewhat see your point, but I would not have recognized iec61158 as
something relevant to my hardware, whereas fieldbus is understandable.

If you see specific conflicts or differences, please explain them
instead of just throwing around bus names. :) Then we can more easily
discuss whether to make changes to this framework or whether we indeed
need some fieldbus/iec61158/ subdirectory. For your RS-485 I don't see a
conflict as that'll just go via tty/serial/ and optionally serdev, no?
However, I'd be curious how I/O Link might relate to this, it seems to
have no public specifications.

> By the way: any special reason for doing this via device instead of
> socket (like we have w/ can) ?
> I'm, personally, pretty undecided which way is better. Device nodes give
> us easy access control via fs permissions, while socket allows
> firewalling.

While I do like sockets, they seem more useful for packet-based
communication, which may be an implementation detail of fieldbus_dev
drivers, but AFAIU that's unrelated to Sven's memory-focused subsystem
representing a view of the data received, which may be different from
the last packet received. Also, when a packet is received via socket, it
gets dequeued, whereas you'll want to access the device's memory without


SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)

Powered by blists - more mailing lists