lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090915130357.GC5247@amit-x200.redhat.com>
Date:	Tue, 15 Sep 2009 18:33:57 +0530
From:	Amit Shah <amit.shah@...hat.com>
To:	Anthony Liguori <anthony@...emonkey.ws>
Cc:	Alan Cox <alan@...ux.intel.com>, rusty@...tcorp.com.au,
	virtualization@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, greg@...ah.com
Subject: Re: [PATCH] virtio_console: Add support for multiple ports for
	generic guest and host communication

On (Tue) Sep 15 2009 [07:57:10], Anthony Liguori wrote:
> Amit Shah wrote:
>> Hey Greg,
>>
>> Can you tell me how this could work out -- each console port could have
>> a "role" string associated with it (obtainable from the invoking qemu
>> process in case of qemu/kvm). Something that I have in mind currently
>> is:
>>
>> $ qemu-kvm ... -virtioconsole role=org/qemu/clipboard
>>
>> and then the guest kernel sees the string, and puts the
>> "org/qemu/clipboard" in some file in sysfs. Guest userspace should then
>> be able to open and read/write to
>>
>> /dev/virtio_console/org/qemu/clipboard
>>   
>
> That's probably not what we want.  I imagine what we want is:
>
> /dev/ttyV0
> /dev/ttyV1
> /dev/ttyVN
>
> And then we want:
>
> /sys/class/virtio-console/ttyV0/name -> "org.qemu.clipboard"
>
> Userspace can detect when new virtio-consoles appear via udev events.   
> When it sees a new ttyVN, it can then look in sysfs to discover it's 
> name.

OK; but that's kind of roundabout isn't it? An application, instead of
watching for the console port it's interested in, has to instead monitor
all the ports.

So in effect there has to be one app monitoring for new ports and then
that app exec'ing the corresponding app meant for that port.

		Amit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ