Hoe een ttyS1 te faken op Debian/Linux ?

[Roel Broersma]

Ik ben bezig om een Linux applicatie te virtualiseren op Xenserver.
Nu controleert die applicatie bij het opstarten of hij een ttyS0 kan vinden (niet dat hij die later nodig heeft, in de applicatie kun je namelijk aangeven dat je alle interfacing via het network wilt doen ipv via de Serial COM port, dan moet de applicatie echter wel gestart zijn).

Ik heb alles geprobeerd:
- touch /dev/ttyS0
- mkdir /dev/ttyS0
- De tool: interceptty (interceptty -s 'ispeed 115200 ospeed 115200' /dec/ttyS1 @/localhost:6666 echter gaf dat de ouput: "error opening backend device '/dev/ttyS0': No such file or directory"
- Symlinken naar andere devices

Met VMWare Player/Workstation kan ik de applicatie op Linux/Debian wel goed virtualiseren, die mapt namelijk gewoon de COM port van mijn werkstation naar de VM. Vervolgens start de applicatie en geef ik daarin aan dat hij via het Network moet interfacen.

Ik zoek dus een tool of iets dat een ttyS0 kan faken of een dummy ttyS0 kan maken.

[Nielson]

Heb er verder geen verstand van, maar als ik dit zo lees kun je met 't MAKEDEV script een ttyS0 aanmaken.

[eXcyle]

Als het goed is kan je met :

code:

mkdev ttyS0 c 4 64
chmod 610 ttyS0
chgrp tty ttyS0

een ttyS0 maken en de juiste rechten zetten

[Roel Broersma]

Het werkt allemaal niet...

Ik heb ook met mknod en MAKEDEV (in hoofdletters) geprobeerd.
Ik 'controleer' of het werkt met 'setserial /dev/ttyS0 autoconfig'.

Ik krijg dan steeds: /dev/ttyS0: No such device or address

Is het iemand ooit is gelukt met mknod of MAKEDEV een extra 'dummy' COM poort aan te maken en dan met setserial te bekijken ?

PS. MAKEDEV -v ttyS0 maakt een device aan in /dev/.static/dev/ttyS0 ik heb die geprobeerd te symlinken, maar ook dan krijg ik bovenstaande error.

[ Voor 16% gewijzigd door Roel Broersma op 04-09-2009 22:39 ]

[Rainmaker]

En "gewoon" mknod?

mknod -m 660 /dev/ttyS0 c 4 64

als root natuurlijk.

En kun je die applicatie niet iets van argumenten meegeven om hier niet voor te checken?

[ Voor 37% gewijzigd door Rainmaker op 04-09-2009 23:34 ]

[doctormetal]

Het aanmaken van de device files zal je in dit geval niet veel helpen. De device file is alleen een soort van entry point voor de device driver, Er moet dus ook iets achter zitten. Je zou in dit geval dus een dummy driver voor een tty moeten hebben, omdat hij als tty moet reageren. Daarom werkt symlinken naar een ander device, zoals /dev/null ook niet.
Weet eigenlijk niet zo snel off er een dummy tty driver standaard aanwezig is.

[Super_ik]

je moet wel een driver hebben die iets doet met de compoort, anders kan je wel een file node hebben, maar werkt 't nog niet.
kun je /dev/ttyS0 niet simlinken naar /dev/null?

$ ln -sr /dev/null /dev/ttyS0

[LeechGuy]

Waarom geef je niet gewoon je compoorten door aan je VM?

Even het volgende toevoegen aan je vm config file:

code:

# Enable access to serial ports
irq = [3, 4]
ioports = ["3f8-3ff", "2f8-2ff"]

Ik heb op mijn module regel in de grub menu.lst ook nog xencons=off toegevoegd, maar ik weet niet zeker of dat echt nodig is.

[Roel Broersma]

LeechGuy schreef op zaterdag 05 september 2009 @ 18:42:
Waarom geef je niet gewoon je compoorten door aan je VM?

Even het volgende toevoegen aan je vm config file:

code:

# Enable access to serial ports
irq = [3, 4]
ioports = ["3f8-3ff", "2f8-2ff"]

Ik heb op mijn module regel in de grub menu.lst ook nog xencons=off toegevoegd, maar ik weet niet zeker of dat echt nodig is.

Ik had het over Citrix XenServer he,. niet Xen. Dus dat wijkt een klein pietske af. Waar staat die VM config file ? Want in Xenserver doet met alles via de API "xe vm-shutdown param=xx" enzo..
Thanks voor de tip alvast!

[Rainmaker]

doctormetal schreef op zaterdag 05 september 2009 @ 13:46:
Het aanmaken van de device files zal je in dit geval niet veel helpen. De device file is alleen een soort van entry point voor de device driver, Er moet dus ook iets achter zitten. Je zou in dit geval dus een dummy driver voor een tty moeten hebben, omdat hij als tty moet reageren. Daarom werkt symlinken naar een ander device, zoals /dev/null ook niet.
Weet eigenlijk niet zo snel off er een dummy tty driver standaard aanwezig is.

Daar is het major / minor nummer juist voor

Door major nummer weet de kernel welke driver er gebruikt moet worden.
Minor nummer is een "argument" aan die driver zodat ie weet welk device (1e harddrive gedecteerd -> minor 0, 2e harddrive, minor 1, partitie 1, disk 1 -> minor 2 etc.)

Zie devices.txt in de kernel docs.

[doctormetal]

Misschien lukt het met een pseudo tty. Het is een virtuele tty, dus misschien gaat het werken.

offtopic:
@RainMaker: Heb je überhaupt gelezen waarop je reageerde? Ik gaf een verklaring waarom puur het aanmaken van de device node of het maken van een symlink niet werkt en jij komt met een total ongerelateerd verhaal over major en minor nummers.

[smokalot]

Is t niet een betere oplossing om de tty-check in dat programma te fixen zodat ie alleen maar nodig heeft wat ie ook daadwerkelijk gaat gebruiken? Is vast niet lastig (of is het een closed source programma van een niet-klantvriendelijke fabrikant?), en een stuk handiger in de toekomst voor jou en alle andere mensen die tegen dit probleem oplopen...

[LeechGuy]

Roel Broersma schreef op zaterdag 05 september 2009 @ 20:38:
[...]


Ik had het over Citrix XenServer he,. niet Xen. Dus dat wijkt een klein pietske af. Waar staat die VM config file ? Want in Xenserver doet met alles via de API "xe vm-shutdown param=xx" enzo..
Thanks voor de tip alvast!

Oops... ik had even gemist dat het om Citrix ging (ken ik alleen van naam, nooit wat mee gedaan)... Bij ubuntu staan ze normaal gesproken in /etc/xen/

Opstarten van een vm gaat dan via sudo xm create /etc/xen/<vmconfigfile>

Werkt dus inderdaad net iets anders.

Volgens de XenServer Virtual Machine Installation Guide kan het niet met XenServer:

(pagina 5):

Good candidates for virtualization are:
• servers whose CPU and memory usage and NIC and disk throughput are low will be more likely to coexist as a VM on a XenServer host with a few other VMs without unduly constraining its performance.
• servers that are a few years old - so their performance as VMs hosted on a newer server would be
comparable to their existing state.
• servers that do not use any incompatible hardware which cannot be virtualized, such as dongles, serial or parallel ports, or other unsupported PCI cards (serial cards, cryptographic accelerators, and so on).