/dev/ttyk0 (Was: Re: 2.0 installer integration)

[Chris Turner <c.turner@xxxxxxxxxxxxxxxxxxx>]

Matthew Dillon wrote:
> 
>     Alternatively it would be possible to create a feature where the real
>     machine could 'connect' to the VT devices on a live virtual kernel...
>     that would be a pretty cool feature if you ask me.  Anyone want to have
>     a go at it?  It would mean using the kqueue API in the vkernel to set
>     up a unix domain socket on the real machine to accept from, then be
>     able to connect to the socket from the real machine.  Not trivial, but
>     not difficult either.
> 

I made a quick attempt at some proof-of-concept's for this a while back
in pure-userland, essentially using 'dup' calls to rearrange
std(in|out|err) onto a fifo, and then exec()ing 'login' such that it was
hooked up to the fifo, And another test that hooked 'login -' up to stdin..

In the the first test, I couldn't get any real output by catting the
fifo on one end and 'cu -l-ing' on the other end (later realized I'd
probably need 2 fifos), and in the second, 'login -' would core due to
'inappropriate IOCTL for device' on some kind of serial or terminal
related ioctls..

but:

1) (as discussed a couple months earlier) a fifo isn't necessarily the
best way to do this due to buffering, etc.
2) my code-foo is probably not up to snuff in this area
3) null-emulating the ioctls used by login (if even needed) inside the
vkernel might be easier - or perhaps serializing them across the socket
 somehow ?

in the meantime, I've written some wrapper scripts to launch vkernels
via screen, but the notion of not only being able to use a simple
'cu/tip' type of vkernel login, but to also run a VKERNEL UUCP network
is intriguing :)

I suppose I might give it another go inside the VKERNEL directly
after I clean up the shutdown patch, but I told myself to swear
off of vkernel coding this weekend so my regular duties don't go
completely to s**t .. so we'll see .. and kudos on the VK-CD patch for
helping out with that :)

- Chris