lkml.org 
[lkml]   [2018]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v5 1/6] fieldbus_dev: add Fieldbus Device subsystem.
Hi Greg,

On Thu, Dec 6, 2018 at 9:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> And as these are really devices, why not make them a "device" and a bus?
> What type of topology do you have on these busses? Are everything
> "flat" and connected directly to a PCI/USB/platform device? Or are
> there multiple devices attached to a single controller?
>
> It really feels like you want to use 'struct device' and a bus_type and
> not a class here to me...
>

I don't believe that the bus/device abstraction is appropriate for fieldbus
peripherals. But obviously I'm not a fieldbus or kernel expert, so I keep an
open mind to any elegant solutions I may have missed.

The name FieldBUS is misleading - it's an industrial network, not a bus. The
underlying network technology varies: Profinet runs over Ethernet,
Profibus over RS485. The topology is typical for networks AFAIK.

The actual layout of the raw packets exchanged over the network is proprietary;
fieldbus cards will typically implement this internally, and hide the details.

To the user, a fieldbus card typically exposes shared memory regions.
For example, a robotic arm may store its arm angle at offset 27 of its memory
region. The PC controlling the arm writes a new value to offset 27 in the
memory of its own fieldbus card. The cards then communicate over the network,
the memory in the arm's fieldbus card is updated, and the arm is notified of
the data change by an interrupt.

Like I said, I'm by no means a fieldbus expert. But this 'feels' unlike a
device/bus abstraction. And it also doesn't 'feel' right to make this part
of the network stack. But I keep an open mind.

Sven

\
 
 \ /
  Last update: 2018-12-06 19:33    [W:0.042 / U:0.488 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site