FPGA: Device and Driver

[IgnoreWarnings]

This PR adds devices and drivers with features of binding, unbinding and probing. The IpDevice class adds additional features for devices which correspond to an ip on the fpga, such as getting the ip name and baseaddress.

Used by #783.

[n-eiling]

I think this should go into common/lib/kernel. Also there we already have a class Device in pci.hpp. Maybe it makes sense to make a top class Device from which you derive PciDevice and PlatformDevice (instead of IpDevice)?

Doesn't this make some of the functions in common/kernel obsolete? Can we remove something there?
Also please add me to the CODEOWNERS file for the new files you created.

[IgnoreWarnings]

I think this should go into common/lib/kernel. Also there we already have a class Device in pci.hpp. Maybe it makes sense to make a top class Device from which you derive PciDevice and PlatformDevice (instead of IpDevice)?

Doesn't this make some of the functions in common/kernel obsolete? Can we remove something there? Also please add me to the CODEOWNERS file for the new files you created.

Thank you for the tip. It is a good Idea to move it to the Kernel.

Refactor

Naming
The existing Device in "pci.cpp", which is specific for PCI devices, should be renamed to PciDevice.

File Structure
The class should be move to its own "PciDevice" file.

Obsolete Code / Integration
PciDevice can be partially integrated with the new system. Obviously the existing PciDevice wasnt designed with inheritance in mind, which makes it tough to identify common grounds.
The whole code there is questionable: it uses hard coded c_strings as paths, c pointers, fprintf instead of logging, obscure naming... e.g.:

if (tmp[0] && strcmp(tmp, "*")) {
long int x = strtol(tmp, &e, 16);                        
if ((e && *e) || (x < 0 || x > 0x7fffffff)) {...}

I dont think it is worth to port this to the modern style in this PR. Just leave it as is.
@n-eiling Whats your opinion on the suggestions?

[IgnoreWarnings]

I will add you as author.

[IgnoreWarnings]

Also the Device class i implemented is a toplevel class. IpDevice is what is used for vfio platform devices ;)

[IgnoreWarnings]

Waiting for #814

[IgnoreWarnings]

I think this should go into common/lib/kernel. Also there we already have a class Device in pci.hpp. Maybe it makes sense to make a top class Device from which you derive PciDevice and PlatformDevice (instead of IpDevice)?

Doesn't this make some of the functions in common/kernel obsolete? Can we remove something there? Also please add me to the CODEOWNERS file for the new files you created.

A seperate PR will integrate pci_device with the new interface #816

[IgnoreWarnings]

@stv0g @n-eiling
I addressed all your suggestions and rebased the branch on master.
Would you like me to squash the (conversation) commits before merge?

[stv0g]

A little request: please do not resolve conversations about points raised by a reviewer yourself. Its the task of the reviewer to check if the points have been addressed.

[IgnoreWarnings]

A little request: please do not resolve conversations about points raised by a reviewer yourself. Its the task of the reviewer to check if the points have been addressed.

Okay, I will from now on leave closing discretion to reviewer.

[IgnoreWarnings]

Lets only comment the headers to avoid duplication.

[stv0g]

Lets only comment the headers to avoid duplication.

This will break consistency. If its decided to add descriptions/comments only to headers we need to do this in all source files of the repo. As this would be a larger change, we will need to do it in a separete MR. So for now, please keep consistent with the rest of the code base. Thanks :)

[IgnoreWarnings]

Lets only comment the headers to avoid duplication.

This will break consistency. If its decided to add descriptions/comments only to headers we need to do this in all source files of the repo. As this would be a larger change, we will need to do it in a separete MR. So for now, please keep consistent with the rest of the code base. Thanks :)

The headers and cpp files can be commented but it makes no sense to write the same description in both. This is what will really break consistency because an update of one comment will not automatically update the other. It breaks DRY Principle and introduces dependency.

[IgnoreWarnings]

Also if you want comments in a specific way, write a coding guideline so I dont have to guess and you dont have to write 10+ change requests only regarding comments.

[IgnoreWarnings]

@stv0g I added the comments (duplicated) in the .cpp files.