From: James S. <jsi...@tr...> - 2001-06-06 22:39:41
|
> > It would be nice if we had > > > > 1) A seperate serial directory under drivers. > > > > 2) A nice structure that input devices and the tty layer can use. It is > > just a waste to go threw the tty layer for input devices. It would also > > make serial driver writing easier if the api is designed right :-) > > I am planning some day (don't know when yet though) to convert the 16x50 > driver over to the serial_core stuff. I ported it over to my tree. I will have to figure out how to incorporate the input serial stuff without breaking all the input drivers we have. In CVS we have alot of them. This will make life so much easier since all I will have to do is change one file for changes I make to the tty layer. I have improved andrew mortons console patch to work with multiple consoles and for different types of console devices. Instead of altering all the console drivers I'm planning on intergrating the locking into the tty layer. That patch is needed for serial devices as well as video terminals. Your work might help speed up devleopement. > NB, Ted Tytso mentioned something at the 2.5 conference about integrating > some of the serial layer with the tty layer. What does he have in mind? I like to keep my VT changes in sync with what he has in mind. |
From: Vojtech P. <vo...@su...> - 2001-06-07 06:52:40
|
On Wed, Jun 06, 2001 at 03:39:04PM -0700, James Simmons wrote: > > > It would be nice if we had > > > > > > 1) A seperate serial directory under drivers. > > > > > > 2) A nice structure that input devices and the tty layer can use. It is > > > just a waste to go threw the tty layer for input devices. It would also > > > make serial driver writing easier if the api is designed right :-) > > > > I am planning some day (don't know when yet though) to convert the 16x50 > > driver over to the serial_core stuff. > > I ported it over to my tree. I will have to figure out how to incorporate > the input serial stuff without breaking all the input drivers we have. In > CVS we have alot of them. This will make life so much easier since all I > will have to do is change one file for changes I make to the tty layer. I > have improved andrew mortons console patch to work with multiple consoles > and for different types of console devices. Instead of altering all the > console drivers I'm planning on intergrating the locking into the tty > layer. That patch is needed for serial devices as well as video terminals. > Your work might help speed up devleopement. Sounds cute. Where do I find the result of your work? > > NB, Ted Tytso mentioned something at the 2.5 conference about integrating > > some of the serial layer with the tty layer. > > What does he have in mind? I like to keep my VT changes in sync with what > he has in mind. -- Vojtech Pavlik SuSE Labs |
From: James S. <jsi...@tr...> - 2001-06-07 17:10:09
|
> > I ported it over to my tree. I will have to figure out how to incorporate > > the input serial stuff without breaking all the input drivers we have. In > > CVS we have alot of them. This will make life so much easier since all I > > will have to do is change one file for changes I make to the tty layer. I > > have improved andrew mortons console patch to work with multiple consoles > > and for different types of console devices. Instead of altering all the > > console drivers I'm planning on intergrating the locking into the tty > > layer. That patch is needed for serial devices as well as video terminals. > > Your work might help speed up devleopement. > > Sounds cute. Where do I find the result of your work? For Russell's work I placed it in the ruby tree under linux/drivers/serial. No changes have happened to it. Well at least not yet. What I like to see is: serial_driver -> serial common code -----> serial tty | |--> serial input For my one system I have for my only serial device a joystick. Do I really need a serial terminal for this device. Termios changes to joystick, give me a break. It just another layer of uneeded bloat. A nice clean design like this would be really nice. The code is in CVS if you want to play with it. As for the console lock it is already in CVS as well. Their are a few race conditions dealing with printk and register_console to pound out but its there and it works well. The basic changes I have made are the functions acquire_console_sem and release_console_sem take a struct tty_driver argument. This way we can flush one driver that was busy while printk was running when the tty code finish doing what it was doing. Now when printk gets called it attempts to write data to all the consoles if they already not busy. This way it only locks out one console at a time. This way serial console doesn't have to be locked waiting for fbcon to finish printing to the console. A semaphore in struct tty_driver is shared with struct console. The better news is now we can use IRQ/DMA based devices for the console system. |