linux-kernel - Re: [PATCH anybus v4 1/7] fieldbus_dev: add Fieldbus Device subsystem.

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]

Message-ID: <CAGngYiXYVoesCQyf4+trM1V4ydwasrZnx_CqSDzQGHM-v81ZZA@mail.gmail.com>
Date:   Wed, 28 Nov 2018 14:39:55 -0500
From:   Sven Van Asbroeck <thesven73@...il.com>
To:     gregkh@...uxfoundation.org
Cc:     Sven Van Asbroeck <svendev@...x.com>, robh+dt@...nel.org,
        Linus Walleij <linus.walleij@...aro.org>,
        Lee Jones <lee.jones@...aro.org>, mark.rutland@....com,
        Andreas Färber <afaerber@...e.de>,
        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>, john.garry@...wei.com,
        geert+renesas@...der.be, robin.murphy@....com,
        paul.gortmaker@...driver.com,
        sebastien.bourdelin@...oirfairelinux.com, icenowy@...c.io,
        Stuart Yoder <stuyoder@...il.com>, maxime.ripard@...tlin.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>
Subject: Re: [PATCH anybus v4 1/7] fieldbus_dev: add Fieldbus Device subsystem.

On Wed, Nov 28, 2018 at 1:36 PM Greg KH <gregkh@...uxfoundation.org> wrote:

> So you still need a char device, and you will have have a load of them,
> just use the misc device api.  It's simple, clean, and is hard to get
> wrong.  The cdev api is hard, complex, and trivial to get wrong in any
> number of different ways that it can be used :)

Awesome little nugget! These things you just can't tell by reading the kernel
tree. In many cases, it's not immediately obvious to me which of the various
methods are 'recommended', and which ones are historic leftovers.

> And your /sys/class/fieldbus_dev/ is "interesting", why name it that?

Not sure why it's interesting? I figured it would allow userspace to enumerate
all fieldbus devices simply by going to /sys/class/fieldbus_dev/ and process
every subdirectory.

Example with 3 fieldbus cards:
/sys/class/fieldbus_dev/fieldbus_dev0/name etc
/sys/class/fieldbus_dev/fieldbus_dev1/name etc
/sys/class/fieldbus_dev/fieldbus_dev2/name etc

Is there a better way?

> So keep submitting, I'll try to review it the next time around, and all
> should be fine.  But keep your user api as simple as possible for now,
> only doing what you need it to do, worry about future stuff then.

Thanks, that's awesome !!

I figured that I should take baby steps. I simplified the userspace API to the
absolute bare minimum. To the point that the profinet card isn't useable in
our company's specific use case, because there's no configuration API yet.

> Why not just /sys/class/fieldbus/ ?  No need for "dev", right?

Good question... Two very different classes of devices sit on a fieldbus:
Fieldbus device     is like a slave
Fieldbus controller is like a master

This subsystem is specific for fieldbus *devices*. I figured I'd encode this
in the API name, in case someone wants to support fieldbus controllers later.