DragonFlyBSD

And now in the form of a patch..

Thanks,
Nuno.

:And now in the form of a patch..
:
:Thanks,
:Nuno.

I like it!  You know what this means, though... this means we need
    to implement some sort of connect-to-console support so the vkernels
    can all have background consoles.  And we need to be able to rotate
    the log file(s) too.  Not in this patch, but at some point.

It also occurs to me that it would be possible to have the vkernel
    create a unix domain socket that one could then connect to to access
    the console.... there's no real reason why it has to be a tty.

In anycase, lets plan on committing this patch Saturday, to give people
    time for some feedback and/or updated patches.

-Matt

FYI, next up on ye-olde agenda for me is a vkernel -p pidfile option
(right now am kludging via $!). This should be quick, but won't have a
chance until after the shutdown script cleanup , so probably won't
happen until sat. evening at the earliest.

Also, for discussion sake, should the vkernel actually be
installed somewhere outside of the build tree? I know manual copying is
an option, but this is messy IMHO

Thinking either

1) /usr/bin/vkernel

This isn't 'clean' compared to the rest of the source tree
  (e.g. /usr/src/usr.bin), unless the vkernel sources are moved there,
  but that would probably be tricky build wise.

Perhaps installing there would be a justified 'special case' ?
  (could put pointer doc if needed for clarification)

2) /vkernel

Keeps more with the 'traditional' /vmunix, /bsd, /kernel , etc,
   but perhaps is 'clutter' in terms of not really being true
   'system' code..

anyhow.. good to see my simple patch inspring something :)

Good! I'll update my patch once vkernel has a pid saving functionality.

I usually copy my vkernels near their root images. I would prefer not
to install it at /usr/bin or /. The way I see it a vkernel is not a
regular command and you can have several different vkernel binaries
(different kernel versions, different configs, etc).

:-)

Nuno.

:FYI, next up on ye-olde agenda for me is a vkernel -p pidfile option
:(right now am kludging via $!). This should be quick, but won't have a
:chance until after the shutdown script cleanup , so probably won't
:happen until sat. evening at the earliest.
:
:Also, for discussion sake, should the vkernel actually be
:installed somewhere outside of the build tree? I know manual copying is
:an option, but this is messy IMHO

We already use /var/vkernel for the memory and disk image files
    (/var/vkernel is typically going to be a softlink to somewhere else).

So I suggest:  /var/vkernel/sbin/vkernel as a default location for
    the installation.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Hi all.

Here is a revised patch that makes use of vkernel's newly learned
pidfile functionality. Comments/suggestions are appreciated!

Thanks,
Nuno

Anyone take a crack at this one?

personally I haven't yet, but just thought I'd mention it before the
dust settles on the release branch..

- Chris

:Nuno Antunes wrote:
:>
:> Hi all.
:>
:> Here is a revised patch that makes use of vkernel's newly learned
:> pidfile functionality. Comments/suggestions are appreciated!
:>
:> Thanks,
:> Nuno
:
:Anyone take a crack at this one?
:
:personally I haven't yet, but just thought I'd mention it before the
:dust settles on the release branch..
:
:- Chris

It always nice if something can be tested but this isn't on my hotlist
     for the release.

-Matt

Hmm I think it needs more polishing. I seem I remember some problems
with the way vkernel's std{in, out,err} are redirected. IMHO a script
like this should be introduced only when we have a way to attach to a
running vkernel console.

Nuno.

cheers.. well..

if the author thinks it autta wait:

... I suppose it's time to start on the vktty :)

sometime ..

:Hmm I think it needs more polishing. I seem I remember some problems
:with the way vkernel's std{in, out,err} are redirected. IMHO a script
:like this should be introduced only when we have a way to attach to a
:running vkernel console.
:
:Nuno.

Instead of doing that it may be better to actually give the vkernel
    the ability to sit its console on a unix domain socket and connect
    to it with a simple little program which connects to the socket.

In anycase, we're talking post-release here.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Yeah :-)

Unfortunately I can't take that hint right now.. But if you wanna
tackle it, i'll be more than happy to test!

Cheers,
Nuno

What was the final outcome of all this patches and ideas?
Will the patches be discarded in favour of Dillon's idea of sitting vkernel's
console on a unix domain socket?

Antonio Huete Jimenez (via DragonFly issue tracker) schrieb:

Antonio Huete Jimenez <tuxillo@quantumachine.net> added the comment:

What was the final outcome of all this patches and ideas?
Will the patches be discarded in favour of Dillon's idea of sitting vkernel's
console on a unix domain socket?

I think Nuno's patches are useful should be committed until someone
chooses to implement Matt's ideas. They worked fine when I tested them last.

If there are no objections, I will commit it within the next few days.

Sascha

On Wed, Aug 26, 2009 at 12:31 PM, Sascha Wildner <saw@online.de> wrote:

Hi guys!

Do we have any tool readily available to connect to a unix socket or would
it be necessary to create one?

I think Nuno's patches are useful should be committed until someone chooses
to implement Matt's ideas. They worked fine when I tested them last.

I do not object although I would prefer having a way to connect to the
console of a live vkernel to go with this patch. But if I keep wanting
everything to be perfect, probably nothing from me ever gets committed, hehe
:)

Cheers,
Nuno

Sascha,

has this been committed?

Cheers,
Alex Hornung

No, but I'll do once 2.6 is fully released.

Committed, see 2feb07f7abb4bffe29b49fd92b952ed329c2f968

Thanks for the submission, Nuno!