Re: Default Xen PVM console?
On Sun, 24 May 2009, Scott Long wrote: Please don't. Someone on IRC told me Xen also has some framebuffer feature. Say, someone would port syscons to Xen, the naming would conflict with the console device node. /dev/xc0 is good enough. I even think it should have been called ttyx0, not xc0. Given that there will be increasing levels of support for "pass-through" hardware access in virtual machine environments and a trend in the direction of virtualization-friendly hardware, we shouldn't preclude the possibility of something a lot closer to syscons working inside of Xen in the future. This means we should leave the syscons device names open so that syscons can claim them if desired. HVM mode already supports "pass-through" with syscons working in it. That is orthogonal to the discussion of supporting the native virtualization features of Xen. Not sure I follow this comment: what I'm saying is that the Xen-specific console device should not use the same device names as syscons, so that the two can coexist in a single installation. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Default Xen PVM console?
Robert Watson wrote: On Sun, 24 May 2009, Ed Schouten wrote: * Adrian Chadd wrote: * Modify the xenconsole driver to attach to ttyv0 (via a kernel environment variable) so /etc/ttys doesn't need modifying (but this may confuse tools that assumes /dev/ttyvX == syscons.) Please don't. Someone on IRC told me Xen also has some framebuffer feature. Say, someone would port syscons to Xen, the naming would conflict with the console device node. /dev/xc0 is good enough. I even think it should have been called ttyx0, not xc0. Given that there will be increasing levels of support for "pass-through" hardware access in virtual machine environments and a trend in the direction of virtualization-friendly hardware, we shouldn't preclude the possibility of something a lot closer to syscons working inside of Xen in the future. This means we should leave the syscons device names open so that syscons can claim them if desired. HVM mode already supports "pass-through" with syscons working in it. That is orthogonal to the discussion of supporting the native virtualization features of Xen. Scott ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Default Xen PVM console?
Adrian Chadd wrote: Ed has also suggested renaming the console device to "ttyx0" to keep in line with the "typical TTY name in BSDs." I don't think that the loss of continuity in naming here is a very good idea. It's been over 15 years, that qualifies as "typical TTY name for FreeBSD". Scott ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Default Xen PVM console?
Adrian Chadd wrote: 2009/5/24 Scott Long : Treat xen as a new platform and have a src/etc/etc.xen directory that holds the xen-specific ttys files, along with similar things that it'll likely need. In -theory- there could be Xen PVM support for i386, amd64 and ia64; with apparently some random work being done on ARM support in the future. Once you start shifting away from full HVM mode, the instruction set architecture starts becoming much less relevant. Anything using the xc driver is going to behave pretty much the same in respect to the ttys file, regardless of if it's i386 or amd64 or arm. Scott ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Default Xen PVM console?
* Robert Watson wrote: > Given that there will be increasing levels of support for "pass-through" > hardware access in virtual machine environments and a trend in the > direction of virtualization-friendly hardware, we shouldn't preclude the > possibility of something a lot closer to syscons working inside of Xen in > the future. This means we should leave the syscons device names open so > that syscons can claim them if desired. Yes, exactly! -- Ed Schouten WWW: http://80386.nl/ pgpymbiLOnL8e.pgp Description: PGP signature
Re: Default Xen PVM console?
On Sun, 24 May 2009, Ed Schouten wrote: * Adrian Chadd wrote: * Modify the xenconsole driver to attach to ttyv0 (via a kernel environment variable) so /etc/ttys doesn't need modifying (but this may confuse tools that assumes /dev/ttyvX == syscons.) Please don't. Someone on IRC told me Xen also has some framebuffer feature. Say, someone would port syscons to Xen, the naming would conflict with the console device node. /dev/xc0 is good enough. I even think it should have been called ttyx0, not xc0. Given that there will be increasing levels of support for "pass-through" hardware access in virtual machine environments and a trend in the direction of virtualization-friendly hardware, we shouldn't preclude the possibility of something a lot closer to syscons working inside of Xen in the future. This means we should leave the syscons device names open so that syscons can claim them if desired. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Default Xen PVM console?
Ed has also suggested renaming the console device to "ttyx0" to keep in line with the "typical TTY name in BSDs." Adrian ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Default Xen PVM console?
2009/5/24 Scott Long : > Treat xen as a new platform and have a src/etc/etc.xen directory that holds > the xen-specific ttys files, along with similar things that it'll > likely need. In -theory- there could be Xen PVM support for i386, amd64 and ia64; with apparently some random work being done on ARM support in the future. I'll chat on IRC with you/others about the most likely sensible way of doing this and then post a summary to the list(s). Thanks, Adrian ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Default Xen PVM console?
2009/5/24 Ed Schouten : > * Adrian Chadd wrote: >> * Modify the xenconsole driver to attach to ttyv0 (via a kernel >> environment variable) so /etc/ttys doesn't need modifying (but this >> may confuse tools that assumes /dev/ttyvX == syscons.) > > Please don't. Someone on IRC told me Xen also has some framebuffer > feature. Say, someone would port syscons to Xen, the naming would > conflict with the console device node. /dev/xc0 is good enough. I even > think it should have been called ttyx0, not xc0. It sounds like I should just stick to modifying etc/ttys then. I'll see about getting consensus on the right way of doing that and then do it in the next couple days. Thanks, Adrian ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Default Xen PVM console?
* Adrian Chadd wrote: > * Modify the xenconsole driver to attach to ttyv0 (via a kernel > environment variable) so /etc/ttys doesn't need modifying (but this > may confuse tools that assumes /dev/ttyvX == syscons.) Please don't. Someone on IRC told me Xen also has some framebuffer feature. Say, someone would port syscons to Xen, the naming would conflict with the console device node. /dev/xc0 is good enough. I even think it should have been called ttyx0, not xc0. -- Ed Schouten WWW: http://80386.nl/ pgpZGKeJPwaIu.pgp Description: PGP signature
Re: Default Xen PVM console?
Adrian Chadd wrote: G'day, I'd like to twiddle the Xen console stuff a little bit to make it easier to bootstrap a PVM. There's a couple of options I can think of: * Patch /etc/ttys to have a default "xc0" Xen console, but disabled (which makes it trivial for users / scripts to disable the syscons console and enable the xc console); * Modify the xenconsole driver to attach to ttyv0 (via a kernel environment variable) so /etc/ttys doesn't need modifying (but this may confuse tools that assumes /dev/ttyvX == syscons.) Opinions? I'd like to sneak in one of these before the release process begins for 8.0. Thanks, Treat xen as a new platform and have a src/etc/etc.xen directory that holds the xen-specific ttys files, along with similar things that it'll likely need. Scott ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Default Xen PVM console?
G'day, I'd like to twiddle the Xen console stuff a little bit to make it easier to bootstrap a PVM. There's a couple of options I can think of: * Patch /etc/ttys to have a default "xc0" Xen console, but disabled (which makes it trivial for users / scripts to disable the syscons console and enable the xc console); * Modify the xenconsole driver to attach to ttyv0 (via a kernel environment variable) so /etc/ttys doesn't need modifying (but this may confuse tools that assumes /dev/ttyvX == syscons.) Opinions? I'd like to sneak in one of these before the release process begins for 8.0. Thanks, Adrian ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
