BKL in tty code?
Hi,
I'm very much a newbie, and I'm wondering about the big kernel locks in tty_io.c. What exactly are the locks in the read and write for? Is the tty device that contested? Couldn't a finer grained lock be used? -Alex Khripin
Quoted 3 lines · Alex Khripin
I'm very much a newbie, and I'm wondering about the big kernel locks in
tty_io.c. What exactly are the locks in the read and write for? Is the tty device that contested? Couldn't a finer grained lock be used?
It has less to do with lock contention and much more to do with the design of the tty / console layer. It isn't the kernel's prettiest code.
There is probably some cleanup that is possible, but really getting the thing in gear (which means no BKL, which is probably the hardest part to rip out) require some level of rewrite.
Robert Love
Quoted 5 lines
There is probably some cleanup that is possible, but really getting the thing in gear (which means no BKL, which is probably the hardest part to rip out) require some level of rewrite.
Is there a specific maintainer for the TTY code. This is the part of the
kernel which I am most interested in. I have many TTYs in a mid size (100 user Unix network) and could get to do some testing if anyone is writing patches for this system. I would also be willing to do minor review of code for spelling and such. I would _really_ like to get involved with this specific system.
Thanks,
Karl Tatgenhorst
Quoted 7 lines
Is there a specific maintainer for the TTY code. This is the part of the
kernel which I am most interested in. I have many TTYs in a mid size (100 user Unix network) and could get to do some testing if anyone is writing patches for this system. I would also be willing to do minor review of code for spelling and such. I would _really_ like to get involved with this specific system.
Thedore Tyso was originally the maintainer but he seems to have disappeared from the face of the earth. For the past year I have been working on a totally rewrite of the tty/console system.
Quoted 5 lines
Quoted 4 lines
I'm very much a newbie, and I'm wondering about the big kernel locks in
tty_io.c. What exactly are the locks in the read and write for? Is the tty device that contested? Couldn't a finer grained lock be used?
Quoted 7 lines
It has less to do with lock contention and much more to do with the design of the tty / console layer. It isn't the kernel's prettiest code.
There is probably some cleanup that is possible, but really getting the thing in gear (which means no BKL, which is probably the hardest part to rip out) require some level of rewrite.
I'm working on it in the DJ tree. I'm going from the lowest level up to the tty layer. I agree with about the BKL. I plan to move acquire_console_lock into the tty lock shortly. No reason that only the VT system should be able to take advantage of it. I also plan to implement that lock on a per hardware device level instead of a general global lock. This will solve alot of problems. Plus their is no reason why serial devices or VT tty system have to reimplement the wheel.
Quoted 7 lines · Robert Love
It has less to do with lock contention and much more to do with the design of the tty / console layer. It isn't the kernel's prettiest code.
There is probably some cleanup that is possible, but really getting the thing in gear (which means no BKL, which is probably the hardest part to rip out) require some level of rewrite.
I've been thinking about the serial layer, and its far from trivial. Unless its done right, we'll end up with a mess of locks -> deadlock.
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 7 lines
Quoted 4 lines
There is probably some cleanup that is possible, but really getting the thing in gear (which means no BKL, which is probably the hardest part to rip out) require some level of rewrite.
I've been thinking about the serial layer, and its far from trivial. Unless its done right, we'll end up with a mess of locks -> deadlock.
All the locking should be moved to the upper tty layers. Why implement the wheel over and over agin for each type of tty device.
Quoted 2 lines · James Simmons
All the locking should be moved to the upper tty layers. Why implement the wheel over and over agin for each type of tty device.
By that statement, I can see that you haven't really done any analysis of the tty nor serial locking. Its not a simple case of "just add a per tty semaphore in the tty layer and everything will be fine".
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 8 lines · James Simmons
Quoted 2 lines
All the locking should be moved to the upper tty layers. Why implement the wheel over and over agin for each type of tty device.
By that statement, I can see that you haven't really done any analysis of the tty nor serial locking. Its not a simple case of "just add a per tty semaphore in the tty layer and everything will be fine".
I have to say no. I have been to busy cleaning up the fbdev layer right now. What I have done is work on a way to haev each console device have its own lock and then share that with struct tty_driver to protect hardware access. This is just the first step. I knew the tty layer would require more than just that. Since I haven't had time to look at all the details I'm curious to what you have discovered. I still believe that locking could be moved to the upper layer tho. I don't see why not.
Mr. King,
I tried to send this to your e mail address but I think your spam filter
doesn't like me. I am very interested in getting involved with any (low)level work with the TTY system in Linux I work as a Unix admin with a network of serial devices and PCS. I have found that I want specifically to learn to understand serial TTY communication. (Unfortunately my coding skills are about enough to read code and understand it, I have no design skills yet) as I said though I would love to test stuff for you or anyone active in this. That would allow me to learn it and apply my own knowledge of TTY implementations from AIX and Unixware.
For testing I have an Ibm Netfinity with an Equinox Multi Port Card (I am
interested in multi port devices) running RH 7.2 with the 4.17 Stable Kernel. I also have an IBM RS6000 which I hope to get running Linux soon (it too has a multi port card). Both cards are 128 port serial.
I look forward to hearing more you.
Karl Tatgenhorst
Quoted 10 lines · Robert Love
Quoted 4 lines · Alex Khripin
I'm very much a newbie, and I'm wondering about the big kernel locks in
tty_io.c. What exactly are the locks in the read and write for? Is the tty device that contested? Couldn't a finer grained lock be used?There is probably some cleanup that is possible, but really getting the thing in gear (which means no BKL, which is probably the hardest part to rip out) require some level of rewrite.
People working on BKL removal tend to ignore these types of things (I know I do). We concentrate on scalability and performance and the tty code isn't exactly a high point of lock contention.