Re: [PATCH v6 2/2] mctp pcc: Implement MCTP over PCC Transport

[Adam Young]

We need a hardware address to create a socket without an EID in order to 
know where we are sending the packets.

The Hardware addressing is needed to be able to use the device in 
point-to-point mode.  It is possible to have multiple devices at the 
hardware level, and also to not use EID based routing.  Thus, the kernel 
needs to expose which device is which.  The Essential piece of 
information is the outbox, which identifies which channel the  message 
will be sent on.  The inbox is in the hardware address as well as a 
confirmation of on which channel the messages are expected to return. In 
the future, it is possible to reuse channels and IRQs in constrained 
situations, and the driver would then be able to deduce from the packet 
which remote device sent it.

Probably not correct to say the  there is no hardware addressing on the 
packet.  Instead, there is a portion of it on outgoing packets, and a 
different portion on incoming packets.

The hardware address format is in an upcoming version of the spec not 
yet published.

The namespace is for future expansion.  I expect this to always be 0.

I'll fix the other review corrections shortly.


On 10/30/24 21:28, Jeremy Kerr wrote:
> I recall querying this in v1, not sure if there was a response, but:
>
> Given there is no hardware addressing in the packet format, what is the
> meaning of the physical address on the interface? It's a little strange
> to define a hardware address here that isn't used for actual addressing.
>
> For point-to-point links like this (and the serial transport), it's fine
> to have no hw address on the device.
>
> If this is purely local-machine-specific instance data, I suspect that
> this belongs elsewhere. A read-only sysfs attribute could work?