Re: Periodic clock synchronization in vmt(4)

[Julio Merino <julio%meroh.net@localhost>]

On Fri, Mar 15, 2013 at 4:29 PM, Iain Hibbert <plunky%ogmig.net@localhost> 
wrote:
> On Fri, 15 Mar 2013, Julio Merino wrote:
>
>> On Fri, Mar 15, 2013 at 5:32 AM, Iain Hibbert <plunky%ogmig.net@localhost> 
>> wrote:
>> > On Thu, 14 Mar 2013, Julio Merino wrote:
>> >
>> >> Could anyone please review the attached patch?  It appears to work as
>> >> intended, but the sysctl API is really confusing and I don't know if
>> >> I got all details right.
>> >
>> > seems ok but as you make the machdep.vmt.clock_sync.period node, what
>> > happens if more than one vmt device attaches?  I don't know if that can
>> > happen of course..  for ubt(4) I made a node for each instance of the
>> > driver, using device_xname()
>>
>> I don't think more than one vmt can attach.  It wouldn't make sense
>> because this driver handles global "resources" like the clock and
>> power events.
>
> It is not crystal clear to me what it does, since I am not familiar with
> VMWare Tools.. it seems to be a conduit between the host and a guest, but
> the manpage refers to "the guest" so is it only possible to run a single
> guest? If so, is it unreasonable that this restriction might be removed in
> the future?

This driver is supposed to be run in the guest OS, that is, inside the
virtual machine. NetBSD is the guest. And because the VM runs only one
NetBSD kernel at a time, there can only be one vmt instance. The host
in this context is not NetBSD.

The purpose of this driver is to process various events sent from the
VMware monitor running on the host to the guest so that NetBSD (guest)
can react to them. For example, suspending and resuming the VM in
which NetBSD is running are events to which the kernel can react.

>> But what would be the right to do?  Use device_xname()?  It feels like
>> so, but then it doesn't make much sense as mentioned above.
>
> Well, you could ignore errors which might occur if the vmt node already
> existed..
>
> I think using the xname is better though, since the sysctl will appear on
> the host, where all the console messages will be prefixed with that.

The sysctl will appear on the guest. There is no NetBSD host.

> And,
> this removes all question of what to do if more than one guest can be run

This is the wrong question though.

So, basically, whether to call the sysctl vmt or vmt0 is a question of
what's considered to be a better approach when exposing sysctls from a
device driver. Most other drivers would be required to use xname, so I
think using xname here is probably good for consistency reasons.

-- 
Julio Merino / @jmmv