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

Fix for #396 #408

Merged
merged 7 commits into from
May 26, 2016
Merged

Fix for #396 #408

merged 7 commits into from
May 26, 2016

Conversation

RikusW
Copy link
Contributor

@RikusW RikusW commented May 19, 2016

Fix for #396
pci_connect seems to be duplicated 5 times...

@RikusW
Copy link
Contributor Author

RikusW commented May 19, 2016

In daemons/gptp/linux/src/linux_hal_i210.cpp pci_connect does not call igb_attach_tx, should it ?
The others appear identical, please advise on a common location.
#409

@andrew-elder
Copy link

We have a large "automotive" pull request pending that I would like to merge before addressing this one.

continue;
}
/*igb_attach_tx missing here ???*/
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not positive, but I think agb_attach_tx is only needed when dealing with the userspace interface to transmit on the AVB high-priority queues. I don't think the gPTP implementation uses that interface.

@RikusW
Copy link
Contributor Author

RikusW commented May 26, 2016

Just fixed errno to err.

continue;
}
err = igb_attach_tx(igb_dev);
if (err) {
printf("attach_tx failed! (%s)\n", strerror(err)); /*errno or err ??*/
printf("attach_tx failed! (%s)\n", strerror(err));

Choose a reason for hiding this comment

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

I like these changes, but I'm left with the question about what it means to call strerror() with an error returned from a user library. Seems to me there should be a igb_strerror() function since the igb library is the entity that understands what it's returned error codes actually mean.

Copy link
Contributor

Choose a reason for hiding this comment

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

The igb library returns system error codes. I don't see anything wrong with this approach. If we want to create our own set of user codes that's fine, but, in my opinion unnecessary. I think an intermediate approach might be to just wrap strerror in igb_strerror() and in the future it could be changed a little more easily.

@andrew-elder
Copy link

My vote is to accept this pull request as-is and create an issue to review what calling strerror(err) on igb error returns should really be.
Comments?

@intel-ethernet
Copy link
Contributor

i agree.
Merge and start a new thread.

@pinealservo
Copy link
Contributor

I don't see anything wrong with strerror being called on an error value returned by a user library if the library has been designed to use standard error numbers. It is a bit limiting in the sort of errors you can return, but for things that mostly fail in standard ways, it's nice to not have to redefine a whole alternate set of error codes.

Anyway, looks like consensus is to merge.

@pinealservo pinealservo merged commit 84bcce2 into Avnu:open-avb-next May 26, 2016
andrew-elder pushed a commit to audioscience/Open-AVB that referenced this pull request Jun 7, 2016
andrew-elder pushed a commit to audioscience/Open-AVB that referenced this pull request Jun 7, 2016
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.

5 participants