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

In Rocky Linux 9.2 got compilation failures related with PDE_DATA #37

Open
rodolfojcj opened this issue Sep 25, 2023 · 8 comments
Open

Comments

@rodolfojcj
Copy link

When using either the DAHDI linux complete 3.2.0 tar.gz file or the master branch sources, trying to compile on Rocky Linux 9.2 fails with error messages like these (not necessarily all of them at the same attempt):

linux/drivers/dahdi/xpp/xbus-core.c:1842:50: error: implicit declaration of function ‘PDE_DATA’; did you mean ‘NODE_DATA’? [-Werror=implicit-function-declaration]
1842 |         return single_open(file, xbus_proc_show, PDE_DATA(inode));
                                                        ^~~~~~~~
|                                                       NODE_DATA

Or

linux/drivers/dahdi/xpp/xbus-core.c:1842:50: warning: passing argument 3 of ‘single_open’ makes pointer from integer without a cast [-Wint-conversion]
1842 |         return single_open(file, xbus_proc_show, PDE_DATA(inode));
|                                                       ^~~~~~~~~~~~~~~
|                                                       |
|                                                       int

Or

linux/drivers/dahdi/xpp/xbus-core.c:1949:28: warning: assignment to ‘void *’ from ‘ int’ makes pointer from integer without a cast [-Wint-conversion]
1949 |         file->private_data = PDE_DATA(inode);
@rodolfojcj
Copy link
Author

The attached file dahdi-linux-issue-37-fix-24sept2023.zip has a possible fix to this issue.

I tested it with:

  • Ubuntu 23.04, kernel 6.2.0-20-generic
  • Ubuntu 22.10, kernel 5.19.0-43-generic
  • Ubuntu 22.04, kernel 5.15.0-73-generic
  • Ubuntu 20.04, kernel 5.4.0-150-generic
  • Ubuntu 18.04, kernel 4.15.0-212-generic
  • Ubuntu 16.04, kernel 4.4.0-210-generic
  • Debian 12, kernel 6.1.0-10-amd64
  • Debian 11, kernel 5.10.0-23-amd64
  • Debian 10, kernel 4.19.0-24-amd64
  • CentOS 7.9.2009 3.10.0-1160.95.1.el7.x86_64
  • Rocky Linux 9.2, kernel 5.14.0-284.25.1.el9_2.x86_64
  • Rocky Linux 8.8, kernel 4.18.0-477.21.1.el8_8.x86_64

In all those cases the compilation is successful.

Thanks in advance for any developer of this project that may review and possibly apply this fix for the master branch.

@InterLinked1
Copy link
Contributor

@push143smart Seems like this issue was addressed in 08fda50 and can be closed.

@rodolfojcj
Copy link
Author

Hello @InterLinked1 and @push143smart .
Last week I found that the most recent unreleased dahdi-linux sources failed in Rocky Linux 8.10 because of wrong quantity of parameters passed to the netif_napi_add function, which is defined next to the PDE_DATA function. To solve that, I used a manual patch like this:

--- original/linux/include/dahdi/kernel.h       2024-09-12 04:07:14.000000000 +0000
+++ modified/linux/include/dahdi/kernel.h       2024-09-12 04:37:45.849184105 +0000
@@ -1557,6 +1557,8 @@
               RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(9,1)
 #define netif_napi_add netif_napi_add_weight
 #define PDE_DATA(i)     pde_data(i)
+#elif defined(RHEL_RELEASE_CODE) && RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(8,10)
+#define netif_napi_add netif_napi_add_weight
 #endif
 #endif

I don't know which Rocky Linux versions <= 8.9, if any, will also benefit from a patch like that.

Would you like to apply that change, or an equivalent one, to the official dahdi-linux sources, please?

Thank you.

@InterLinked1
Copy link
Contributor

Hello @InterLinked1 and @push143smart . Last week I found that the most recent unreleased dahdi-linux sources failed in Rocky Linux 8.10 because of wrong quantity of parameters passed to the netif_napi_add function, which is defined next to the PDE_DATA function. To solve that, I used a manual patch like this:

--- original/linux/include/dahdi/kernel.h       2024-09-12 04:07:14.000000000 +0000
+++ modified/linux/include/dahdi/kernel.h       2024-09-12 04:37:45.849184105 +0000
@@ -1557,6 +1557,8 @@
               RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(9,1)
 #define netif_napi_add netif_napi_add_weight
 #define PDE_DATA(i)     pde_data(i)
+#elif defined(RHEL_RELEASE_CODE) && RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(8,10)
+#define netif_napi_add netif_napi_add_weight
 #endif
 #endif

I don't know which Rocky Linux versions <= 8.9, if any, will also benefit from a patch like that.

Would you like to apply that change, or an equivalent one, to the official dahdi-linux sources, please?

Thank you.

Isn't this what you've already opened an issue for here? #38
If so, could we continue the discussion on that issue, to keep all the notes in one place? The repo's already kind of a mess and I'm trying to clean it up a bit.

In general though, the project doesn't accept patches that are posted in an issue, you would want to sign the CLA, and then submit a PR with your patch so it can be reviewed then the maintainer can merge it.

@rodolfojcj
Copy link
Author

Hi @InterLinked1.
Yes, it seems to be the same.
Given that almost a year passed since I opened it, I did not remember it and found it again.
On the other hand, where that CLA can be signed? Alternatively, I would be OK if someone takes that patch, apply it and publish it, so that the needed fixes are available to everyone.
Regards.

@InterLinked1
Copy link
Contributor

Hi @InterLinked1. Yes, it seems to be the same. Given that almost a year passed since I opened it, I did not remember it and found it again. On the other hand, where that CLA can be signed? Alternatively, I would be OK if someone takes that patch, apply it and publish it, so that the needed fixes are available to everyone. Regards.

I've been trying to look into this (and am in the process of trying to reconcile some of these, at least for PhreakScript), but since @push143smart has merged some of these changes with differing version numbers, new patches will be need to be created to fix those issues. I was able to reproduce a build failure on RHEL 8.9, but I don't test on RHEL very often because frankly it's a huge pain in the rear end. You seem to have pretty good awareness of exactly which versions have these changes.

If you create a PR, you should see the CLA come up as part of that. I am not sure if there is a way to do that outside of the PR process.

What I would recommend is maybe seeing if you can submit a single PR for all the various RHEL fixes based on what's currently in the tree, if you're able. It's changed slightly since you submitted these issues because @push143smart basically ignored several issues and PRs and made his own commits with different version numbers.

@InterLinked1
Copy link
Contributor

Hi @InterLinked1. Yes, it seems to be the same. Given that almost a year passed since I opened it, I did not remember it and found it again. On the other hand, where that CLA can be signed? Alternatively, I would be OK if someone takes that patch, apply it and publish it, so that the needed fixes are available to everyone. Regards.

I've been trying to look into this (and am in the process of trying to reconcile some of these, at least for PhreakScript), but since @push143smart has merged some of these changes with differing version numbers, new patches will be need to be created to fix those issues. I was able to reproduce a build failure on RHEL 8.9, but I don't test on RHEL very often because frankly it's a huge pain in the rear end. You seem to have pretty good awareness of exactly which versions have these changes.

If you create a PR, you should see the CLA come up as part of that. I am not sure if there is a way to do that outside of the PR process.

What I would recommend is maybe seeing if you can submit a single PR for all the various RHEL fixes based on what's currently in the tree, if you're able. It's changed slightly since you submitted these issues because @push143smart basically ignored several issues and PRs and made his own commits with different version numbers.

@rodolfojcj Okay, I had some time to go through this and sort it out today - I can submit a PR for the changes that need to be made. Thanks for raising these for attention.

@InterLinked1
Copy link
Contributor

Hello @InterLinked1 and @push143smart . Last week I found that the most recent unreleased dahdi-linux sources failed in Rocky Linux 8.10 because of wrong quantity of parameters passed to the netif_napi_add function, which is defined next to the PDE_DATA function. To solve that, I used a manual patch like this:

--- original/linux/include/dahdi/kernel.h       2024-09-12 04:07:14.000000000 +0000
+++ modified/linux/include/dahdi/kernel.h       2024-09-12 04:37:45.849184105 +0000
@@ -1557,6 +1557,8 @@
               RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(9,1)
 #define netif_napi_add netif_napi_add_weight
 #define PDE_DATA(i)     pde_data(i)
+#elif defined(RHEL_RELEASE_CODE) && RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(8,10)
+#define netif_napi_add netif_napi_add_weight
 #endif
 #endif

I don't know which Rocky Linux versions <= 8.9, if any, will also benefit from a patch like that.

Would you like to apply that change, or an equivalent one, to the official dahdi-linux sources, please?

Thank you.

So your original patch was for >= 8.8 and that indeed is an issue on 8.9 so I'd say the original patch you proposed a year ago is correct.

I've submitted an updated patch for the remaining RHEL issues here: #57

@push143smart This issue itself was actually resolved so you can still go ahead and close it.

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

No branches or pull requests

2 participants