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

Wrong permissions + Timing issue in NewOutput/NewInput #6

Open
andreacioni opened this issue Jan 15, 2018 · 2 comments
Open

Wrong permissions + Timing issue in NewOutput/NewInput #6

andreacioni opened this issue Jan 15, 2018 · 2 comments

Comments

@andreacioni
Copy link
Contributor

Hi @brian-armstrong,

I'm start testing your work on Beaglebone Black, I'm getting the following error: failed to open gpio 60 direction file for writing. I've changed last parameter in all occurences of os.OpenFile in sys.fs to 0666 (r/w for everyone) and everything works. I'm using it as a non-root user but my account belongs to gpio group.

Andrea Cioni

@andreacioni
Copy link
Contributor Author

andreacioni commented Jan 17, 2018

Hi Brian,

there is not only a problem with permissions. As I said here #8 , I'm having timing issue (causing the same error above: "failed to open gpio X direction file for writing") related to fast Sleep in NewOutput. Increasing it to 1 second solved it and should be safe and quite short.
What do you think?

Cheers

@andreacioni andreacioni changed the title Wrong permissions (?) Timing issue cause: "failed to open gpio X direction file for writing" on NewOutput/NewInput Jan 17, 2018
@andreacioni andreacioni changed the title Timing issue cause: "failed to open gpio X direction file for writing" on NewOutput/NewInput Wrong permissions + Timing issue on NewOutput/NewInput Jan 17, 2018
@andreacioni andreacioni changed the title Wrong permissions + Timing issue on NewOutput/NewInput Wrong permissions + Timing issue in NewOutput/NewInput Jan 17, 2018
@brian-armstrong
Copy link
Owner

1 second feels like a while to need to sleep in a library like this. I think it's sort of exposing the limitations of this approach. Ideally we could get notified by the kernel that the file has been exported, but I don't know of a good way of doing that without bringing in inotify, which might be fairly heavyweight for this.

I think the next best solution would be to poll this file fairly aggressively, maybe every 5ms or so. I would feel more comfortable watching it for up to a second if we could spend less time watching it, on average.

Also, are you sure the file mode is causing an issue? It seems weird that the file would export as a different user than the user exporting it. At any rate, I think 0660 would be more appropriate here than 0666.

tms320 pushed a commit to tms320/gpio that referenced this issue May 8, 2018
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