[vbox-dev] How does the virtualbox object-orientation work ? Any documentation ?

[Knut St. Osmundsen]

On Jan 28, 2010, at 20:01, Christophe Devriese wrote:

> As the name indicates, PDM concerns itself with emulated devices and
> drivers that interfaces the host system.  A device may have multiple
> LUNs (abused SCSI term) each of which may have a chain of drivers
> attached to it.  The driver chain is a doubly linked list of driver
> instances anchored to the LUN at the "top".  (Topology: The VMM is at
> the top, devices below it, drivers under there).  To see how we
> configure drivers for LUNs take a look at the CFGM dump in the  
> VBox.log.
>
> What does this "mean" for a device to have a "lun" ? On SCSI it's  
> sort of a partition ? What does it represent ?
>
> Is it that you, say, have a "disk subsystem" driver which then has  
> multiple disks (but it looks like that is implemented, at least for  
> SATA, by having multiple "ports") ? It's also confusing that you  
> have an actual scsi driver that indeed supports multiple LUNs.

As I hinted above, we've abused the term LUN here in this context and  
it is confusing.   All I can say in defense is that LUN is less  
frequently used than "port", "socket", "connector" and the other  
alternatives that were considered, and it therefore seemed like the  
least confusing term at the time.

A device can have zero or more LUNs. Usually a LUN corresponds  
directly to some connector, port, socket, receptacle or similar that  
is present on the corresponding real hardware. So for instance  
DrvATA.cpp has 4 normal LUNs where HDs or DVDs can be attaches and one  
status LUN where the LEDs are attached.  DrvPCNet.cpp has one LUN  
corresponding to the RJ-45 jack and one LUN for the activity LEDs.  
DevPIC.cpp on the other hand doesn't have any LUNs (it registers  
itself as a PIC with PDM and PDM mediates the setting and getting of  
IRQs).

>
> Since each kind of LUN/device have different needs from their drivers
> and ditto between the drivers, a COM inspired approach was selected
> where interfaces could be queried and used.  Unlike COM there is no  
> need
> for reference counting.  We'd already chosen not to use C++ classes
> anywhere near the VMM, so there was no need to be compatible with any
> C++ object layout either.
>
>
> I have also a rather specific question : what does the code at  
> DrvVD.cpp:1132 do ? The code just following this comment :
>
>         /* First of all figure out what kind of TCP networking stack  
> interface
>          * to use. This is done unconditionally, as backends which  
> don't need
>          * it will just ignore it. */
>
> Or is that for the exclusive usage of the iSCSI backend ?

Yes, that's for iSCSI. We can do iSCSI over the host's TCP/IP stack  
(fHostIP == true) and talk to whatever the host can talk to. Or, we  
can connect to another VM over the internal VirtualBox network  
(fHostIP==false). You'll find a light weight TCP/IP stack under  
Network/lwip with DevINIP.cpp providing the service interface (Dev ==  
service hack in this case, very ugly, but quicker than implementing  
what is outlined in include/VBox/pdmsrv.h for one single use case).

Kind Regards,
  knut