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

add generic stub for unsupported ops on ioman(X) #625

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

israpps
Copy link
Contributor

@israpps israpps commented May 30, 2024

  • improves readability (IMO)
  • unified return value for unsupported ops (-ENOTSUP) making it clear from EE side that the operation that just failed is simply stubbed on the IOP

@israpps israpps force-pushed the ioman-iomanx-notsup-generic-response branch from 52c3fcf to 7547bd1 Compare May 30, 2024 19:01
@israpps israpps changed the title add generic stub for unsupported ops on ioman(x) add generic stub for unsupported ops on ioman(X) May 30, 2024
@@ -87,6 +87,11 @@ typedef struct _iomanX_iop_device {
struct _iomanX_iop_device_ops *ops;
} iomanX_iop_device_t;


#define DECL_NOT_SUPPORTED_OP() \
Copy link
Member

Choose a reason for hiding this comment

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

instead of using macros you can also use:

static inline int not_supported_op (void) {return -134;}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You're right, I'll apply the change later.

Although, I would like to read a review of @uyjulian on this regard, specially with the DVR related IRX modules

@uyjulian
Copy link
Member

Suggest to use ENOSYS instead of making up a new error code 134

@israpps
Copy link
Contributor Author

israpps commented Jul 30, 2024

Suggest to use ENOSYS instead of making up a new error code 134

134 corresponds to -ENOTSUP without including errno everywhere.

@fjtrujy
Copy link
Member

fjtrujy commented Jul 30, 2024

Suggest to use ENOSYS instead of making up a new error code 134

134 corresponds to -ENOTSUP without including errno everywhere.

But I think this is where the issue is coming from, to include errno in every file where it is needed it is a good practice. In this way you don't care about the "actual value" however you care about the "meaning" ENOSYS.

@israpps
Copy link
Contributor Author

israpps commented Jul 30, 2024

Suggest to use ENOSYS instead of making up a new error code 134

134 corresponds to -ENOTSUP without including errno everywhere.

But I think this is where the issue is coming from, to include errno in every file where it is needed it is a good practice. In this way you don't care about the "actual value" however you care about the "meaning" ENOSYS.

I thought including errno also includes the array of descriptions that comes with it. Or that is stripped away by the compiler? If that's the case I'll correct it

@fjtrujy
Copy link
Member

fjtrujy commented Jul 30, 2024

Suggest to use ENOSYS instead of making up a new error code 134

134 corresponds to -ENOTSUP without including errno everywhere.

But I think this is where the issue is coming from, to include errno in every file where it is needed it is a good practice. In this way you don't care about the "actual value" however you care about the "meaning" ENOSYS.

I thought including errno also includes the array of descriptions that comes with it. Or that is stripped away by the compiler? If that's the case I'll correct it

It shouldn’t increase binary size, it must be exactly the same, if not something else is wrong

- improves readability (IMO)
- unified return value for unsupported ops (`-ENOTSUP`) making it clear from EE side that the operation that just failed is simply stubbed on the IOP
@israpps israpps force-pushed the ioman-iomanx-notsup-generic-response branch from 7547bd1 to a7d7262 Compare August 28, 2024 13:58
@israpps israpps requested a review from fjtrujy August 28, 2024 13:58
s64 dvripl_df_null_long()
{
return -48LL;
return -134LL;
Copy link
Member

Choose a reason for hiding this comment

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

Why have you changed the value here?

Copy link
Member

@fjtrujy fjtrujy left a comment

Choose a reason for hiding this comment

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

I’m ok merging this change @rickgaiser @uyjulian .
However this improvement is quite difficult to check if other devs will maintain.
Just to put an example, uyjulian has created 2 extra PRs where he adds more IOP modules, he is not using that function there…

@israpps
Copy link
Contributor Author

israpps commented Aug 31, 2024

Just to put an example, uyjulian has created 2 extra PRs where he adds more IOP modules, he is not using that function there…

Well of course he's not using something that has not been merged yet.😬

If this gets merged let's just propagate the change to any open PR.

@uyjulian
Copy link
Member

uyjulian commented Sep 4, 2024

Including errno.h won't increase binary size as it is just preprocessor macro definitions. Basically the equivalent of copy and paste.

@israpps
Copy link
Contributor Author

israpps commented Sep 4, 2024

Including errno.h won't increase binary size as it is just preprocessor macro definitions. Basically the equivalent of copy and paste.

excellent. I thought it did. at least my local copy of errno.h (did not check the one on ps2sdk) had a char** buffer for the descriptions of errno values

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.

3 participants