I have tried for a good while to figure out how one would statically assign a pty or pts to a given uml instance. I have no problem getting it to assign pty's dynamically using con=pty, but no luck in either having control of the assignment nor in finding out from the host-OS side what the assigned pty was.
Has anyone successfully assigned pty's to a uml process so that all access to the machine can be done through minicom at a specific device?
Alternatively, does anyone know any way to log the pty's that were automatically assigned to the host OS, perhaps in the /tmp/uml directory that mconsole and pid are stored?
Bottom line: I'm wanting to have each machine have a console on a determined port that I can connect to with minicom - how can I do this without needing to parse the boot log in each virtual machine itself?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can't. pty and pts devices are assigned dynamically, so there's no way to say 'make sure you get /dev/ptyp5', because the driver may have other ideas.
The host's virtual consoles are probably what you want. Use 'con0=tty:/dev/tty9' or whatever.
Also, I'm planning on adding configuration requests to the mconsole protocol, so you'd be able to get the configuration of a console from there, which would be easier than parsing the console log.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunatly my C coding isn't up to par but someone who knows what they are doing should be able to merge the pty code and the xterm code and come up with something that integrates nicely with screen in short order I would think.
Anyway, just an idea for a feature request.
Thanks,
Matt Durell
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have tried for a good while to figure out how one would statically assign a pty or pts to a given uml instance. I have no problem getting it to assign pty's dynamically using con=pty, but no luck in either having control of the assignment nor in finding out from the host-OS side what the assigned pty was.
Has anyone successfully assigned pty's to a uml process so that all access to the machine can be done through minicom at a specific device?
Alternatively, does anyone know any way to log the pty's that were automatically assigned to the host OS, perhaps in the /tmp/uml directory that mconsole and pid are stored?
Bottom line: I'm wanting to have each machine have a console on a determined port that I can connect to with minicom - how can I do this without needing to parse the boot log in each virtual machine itself?
You can't. pty and pts devices are assigned dynamically, so there's no way to say 'make sure you get /dev/ptyp5', because the driver may have other ideas.
The host's virtual consoles are probably what you want. Use 'con0=tty:/dev/tty9' or whatever.
Also, I'm planning on adding configuration requests to the mconsole protocol, so you'd be able to get the configuration of a console from there, which would be easier than parsing the console log.
Thanks for adding the support for doing something like this:
uml_mconsole UML-Name config con1
That allows me to script the abilty to add screen windows for each console and assign them in a sane manner (i.e. tty1 on screen 1, tty5 on screen 5).
Now, what would really be cool is if UML would interface with screen like it does with xterm. In other words a parameters like this:
con=screen umid=my-boxen
would start UML through a screen session called (with -S) my-boxen.
Then, as the ptys are assigned for the virtual sessions UML could then execute something like this for each console:
screen -S $umid -X screen -t con$id $id /dev/pts/$pts
where $id is the console id (con0, con1, etc).
Unfortunatly my C coding isn't up to par but someone who knows what they are doing should be able to merge the pty code and the xterm code and come up with something that integrates nicely with screen in short order I would think.
Anyway, just an idea for a feature request.
Thanks,
Matt Durell