Adrien Destugues
0f6f5adb50
The code in this module was derived from the one in driver/tty. However, the driver uses a shared lock between the master and slave side of a TTY, and this was changed to use two separate locks. The approach with two locks does not work. It seems the change was unfinished and the second TTY was never locked. But attempting to lock it will result in lock inversion problems, unless we do complicated things (try to find which of the two TTY is the master side, and lock that first, for example). It is simpler to restore the shared lock as used in the driver. To set up the shared lock, I modified the tty_create function to take a pointer to the master TTY when creating the slave. Maybe it makes more sense to create both sides in the same call, create_tty_pair? However, this does not work as easily as I wanted, because there is some recursion going on: at least in one case, the tty_control function is calling the driver's tty_service function, which in turns attempts to call back into tty_control for the "other side" TTY. To handle this case, replace the mutex with a recursive_lock. Fixes #17091, where the root problem was access to other_tty->select_pool without locking. This was also made unconvenient to debug because select_pool objects are self-deleting, when the last item in the pool is removed. As a result, the code accessing it without log would suddenly find out that the data it was accessing had been freed and erased. This also makes the TTY code in driver/tty and generic/tty a bit more similar than it was before, and brings us one step closer to merging the two together. There are still two main differences and I don't know enough about TTY to decide if they are important, and which version should be kept: - The driver has extra code for "background" read and write. I don't know what this is used for. - The driver has a single "settings" instance shared by a master and slave TTY, while the module has two separate instances, but seems to copy one to the other. I'm not sure which approach is correct. Change-Id: Ie2daddd027859ce32ba395af76b4f109f8b984b0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/4604 Reviewed-by: waddlesplash <[email protected]>
Haiku
Homepage | Mailing Lists | IRC Channels | Issue Tracker | API docs
Haiku is an open-source operating system that specifically targets personal computing. Inspired by the BeOS, Haiku is fast, simple to use, easy to learn and yet very powerful.
Goals
- Sensible defaults with minimal configuration required.
- Clean, clear, concise code.
- Unified desktop environment.
Trying Haiku
Haiku provides pre-built nightly images and release images. Haiku is compatible with a large variety of hardware, but in case you don't want to "take the plunge" and install Haiku on bare metal, you can install it on a virtual machine (VM) instead. If you've never used a VM before, you can follow one of the "Emulating Haiku" guides.
Compiling Haiku
See ReadMe.Compiling.
Contributing
Haiku is a meritocratic open source project with a large variety of tasks. Even if you can't write code, you can still help! Haiku needs designers, (technical) writers, translators, testers... Get involved and help out!
Contributing code
If you're submitting a patch to us, please make sure you're following the patch submitting guidelines.
If you're having trouble finding something in the source tree, you can use one of our web-based source code browsers:
- https://xref.landonf.org/ (OpenGrok, provided by Landon Fuller)
- https://git.haiku-os.org/ (git, provided by Haiku, Inc.)
Contributing documentation
The main piece of documentation that still needs work are the API docs (found
in the tree at docs/user). Just find an undocumented class, write
documentation for it, and submit a patch.
Contributing translations
See wiki:i18n.
Contributing software ports
See HaikuPorts.
Contributing to our infrastructure
See Infrastructure.