Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PDK PDDF HLD PR request #406

Merged
merged 1 commit into from
Dec 6, 2019
Merged

PDK PDDF HLD PR request #406

merged 1 commit into from
Dec 6, 2019

Conversation

FuzailBrcm
Copy link
Contributor

This document describes the Platform Driver Development Framework (PDDF) which optimises platform driver and SONiC plugin development using a data-driven model.

@msftclas
Copy link

msftclas commented Jun 17, 2019

CLA assistant check
All CLA requirements met.


## 1 Requirements Overview
SONiC OS is portable across different network devices with supported ASIC via Switch Abstraction Interface (SAI). These devices primarily differ in the way various device specific hardware components are accessed, and thus require custom device drivers and python plugins. Each platform vendor implements these custom device drivers and plugins. The feature requirement is to support a SONiC platform driver development framework to enable rapid development of custom device drivers and plugins.

Copy link
Collaborator

@keboliu keboliu Jul 5, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently SONiC is in the process to replace platform plugin with a newly designed platform APIs, the target is to switch to new platform API in 201908 release, so should also considering to support platform API for the coming transform. The design doc of new platform API is here: #285 the new platform base class is defined here: https://github.com/Azure/sonic-platform-common/tree/master/sonic_platform_base

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Kebo Liu,

Yes, we are aware of the new platform API in August, 2019 release. We plan to support new platform base class in PDDF.

-Fuzail

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fk410167: Do you have plans to update this document to reflect the new platform API? Vendors are currently in the process of migrating over to the new API. At this point in time, this document should reflect the new API rather than the old plugins.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes we have already started to move the whole framework to use 2.0 platform APIs. We will modify the HLD accordingly.

@stepanblyschak
Copy link
Contributor

@fk410167 assuming platform vendor will use its own drivers and not using generic drivers with JSON descriptor files approach, how can vendor use generic plugin/platform API implementation by providing sysfs path or symlink to sysfs and attributes list?
From the picture in https://github.com/Azure/SONiC/blob/6d59a095d6bb9dcb3ecb18e8dacec0ce44e886ad/doc/platform/brcm_pdk_pddf.md#33-generic-plugin-design it is assumed sysfs path is auto generated based on json description.

@FuzailBrcm
Copy link
Contributor Author

@fk410167 assuming platform vendor will use its own drivers and not using generic drivers with JSON descriptor files approach, how can vendor use generic plugin/platform API implementation by providing sysfs path or symlink to sysfs and attributes list?
From the picture in https://github.com/Azure/SONiC/blob/6d59a095d6bb9dcb3ecb18e8dacec0ce44e886ad/doc/platform/brcm_pdk_pddf.md#33-generic-plugin-design it is assumed sysfs path is auto generated based on json description.

Hi stepanblyschak,
The SysFS path derivation is solely based on I2C topology info and attribute name in JSON file. In the scenario you mentioned, the vendor can still use the generic plugins/CLI utils given,

  1. User has defined the attribute lists for the non-pddf drivers in JSON descriptor file.
  2. The topology data, parent_bus, virt_bus, parent device, dev_addr, dev_type etc are provided correctly in JSON as per your custom driver implementation.
  3. Copy the generic PDDF plugins to your platform plugins folder.

-Fuzail

lguohan pushed a commit to sonic-net/sonic-utilities that referenced this pull request Dec 6, 2019
…624)

This change is related to Platform Driver Development Framework (PDDF) which is being added to sonic-buildimage repo. More details can be found here, sonic-net/SONiC#406

PDDF supports its own CLI utilities, which use generic PDDF component plugins. I added these PDDF CLI utilities.
@lguohan lguohan merged commit a59630b into sonic-net:master Dec 6, 2019
@FuzailBrcm FuzailBrcm deleted the pddf_doc branch December 7, 2019 13:57
abdosi pushed a commit to sonic-net/sonic-utilities that referenced this pull request Feb 24, 2020
…624)

This change is related to Platform Driver Development Framework (PDDF) which is being added to sonic-buildimage repo. More details can be found here, sonic-net/SONiC#406

PDDF supports its own CLI utilities, which use generic PDDF component plugins. I added these PDDF CLI utilities.
malletvapid23 added a commit to malletvapid23/Sonic-Utility that referenced this pull request Aug 3, 2023
…#624)

This change is related to Platform Driver Development Framework (PDDF) which is being added to sonic-buildimage repo. More details can be found here, sonic-net/SONiC#406

PDDF supports its own CLI utilities, which use generic PDDF component plugins. I added these PDDF CLI utilities.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants