At Thu, 18 Mar 2021 16:26:08 -0700, Brian Buhrow <buhrow%nfbcal.org@localhost> wrote:
Subject: Re: How to get xenconsole working on freeBSD-12 without burning up vnc ports or extra tty ports
>
> On my FreeBSD pvh system, I see a line like:
>
> xc0: <Xen Console> on xenpv0
Yup, same here. I think that's equivalent NetBSD's (PV, i.e. XEN3_DOMU;
and PVH, i.e. -current GENERIC) kernel saying:
xencons0 at hypervisor0: Xen Virtual Console Driver
> I have been under the impression that the console terminal, as
> denoted in /etc/ttys, for both FreeBSD and NetBSD, is a logical
> device, which floats with the system console.
Yes, that's right. It's effectively a device that attaches itself to
the first "physical" device that is probed, attached, and has advertised
itself as being capable of being the console.
> I'm pretty sure, on
> NetBSD, at least, I've told init to activate a getty process on the
> console terminal and I didn't have to change that whether the console
> was on a serial port or on a vga screen.
That's true and that's traditionally the way things were done for ages
in almost all Unix systems.
In NetBSD there's now /dev/constty, which is a kind of a clone of
/dev/console, and is now the device where the getty(8) is recommended.
(Now /dev/console is mostly to be used by processes, such as syslogd,
that want to write messages to the console, and of course internally the
console(4) device it maps to is used by the kernel when it wants to
print to the console.)
> xc0,
> by contrast, is a specific device, much like /dev/ttyu0 or /dev/ttyE0
> are. Do I have that wrong?
Yes, that's exactly right
However it looks like FreeBSD's /etc/ttys "onifconsole" flag, and the
way they're using it turns the way they activate a login prompt on the
console around. They don't enable a getty on /dev/console, but instead
mark each capable device as "onifconsole".
After thinking about it a bit more I'm not sure the FreeBSD scheme is
any better, just different.
FreeBSD now has to maintain /etc/ttys with all the console-capable
devices (which is why they recommend adding the line for xc0).
With the NetBSD scheme you do get the arguably maintenance-free ability to
always have a login prompt on whatever /dev/constty attaches to
However NetBSD's traditional scheme is not necessarily better as you do
still have to be sure to _NOT_ enable (by default) the getty on any
physical device that might be attached to by cons{ole,tty} while users
also still having to enable the getty on whichever of those devices they
do _also_ want a login prompt on if it is not the console.
For the NetBSD scheme the opposite sense flag, i.e. "onifNOTconsole"
would be infinitely more useful and would actually solve the problem I
have with wanting a login on ttyE0 regardless of whether it is used as
the console or not (e.g. when the real console is a serial line).
--
Greg A. Woods <gwoods%acm.org@localhost>
Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpgsf8OnkV4e.pgp
Description: OpenPGP Digital Signature