On Nov 3, 2013, at 12:59 PM, Peter Grehan wrote:
Peter, can you restate the problem for Nathan so that we can
maybe find a better home for this change? or perhaps more clearly
define (than I) how we arrived at the code for the bhyve work?
The issue is that /etc/ttys is static. Serial console installs
assume that the user knows that the file should be edited manually
to enable getty on the serial port. This seems at odds with a server
o/s :(
Yes, I agree. It's a significant usability issue...
The suggestion I brought up with Devin was to see if the install was
done on a serial port, and if so, then ask if the user wanted to
enable a getty on that terminal. I think the patch might need some
work: for instance, a sysctl could be used to see if the console is
on a ttyu* device, and only enable for that and not for all ttys. I
was going to try it out this weekend but was a bit slow off the
mark :)
This was something along the lines of what I was thinking.
So I guess the real problem here is that init does not know enough to
start a login prompt on the console. This has irritated me for a
while
actually. Maybe that should be fixed? The "console" entry, which
would
always automatically work, in /etc/ttys is marked off, which
apparently
happened in the runup to 4.0. It might be time to revisit that.
That's also not good :( /dev/console is assumed to be a sink for log
messages and not really an interactive tty.
Is there any way to extract the backing device via, for example, an
ioctl() from /dev/console? It seems bizarre that up until the login
prompt the OS can figure out where to route console messages up until
the login prompt and then gets confused at that point. I'd really
prefer to have the intelligence there, since all the information
needed is present, rather than have the installer guess. conscontrol
has the ability to get the console backing TTY device through the
kern.console TTY. Maybe init could do the same trick and add whatever
is in kern.console if not manually specified in /etc/ttys?
-Nathan
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
