See my earlier post to -emulation. The if_tap/vmnet driver bogusly
uses FreeBSD's definition of SIOCGIFADDR/SIOCGIFADDR/SIOCSIFADDR
for ioctls that do not use a `struct ifreq'. It was just fluke that
it worked before, because the linux emulation code must have translated
between the Linux and FreeBSD versions without any error checking.
It's also just fluke that the 2-byte and 6-byte data that vmware
passed in happened to not be near enough to an unmapped page for
ioctl() to fail on the copyin/copyout. Whatever the correct solution,
if_tap/vmnet should be changed to define it's own ioctl numbers
with the correct lengths, and something at the linux emulation
layer (probably linux_emu.c in vmmon.ko) should translate.
I think the above patch would work (in the old bogus sense) if you
add translation from the Linux ioctl numbers to FreeBSD numbers,
but I don't think it can work as it is. Because of the major
difference between the way Linux and FreeBSD interpret ioctl numbers,
it never makes sense to pass on a Linux args->cmd to FreeBSD's
ioctl() without translation. The most useful approach is to
return ENOIOCTL from the handler unless you are certain that
you can deal with the ioctl correctly.
Ian
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-emulation" in the body of the message
With the previous version of vmware (vmware2-2.0.3.799_1) there
once was a patch to allow multiple vmware sessions running at the
same time. I tried to use these patches instead of the patches
for vmware2-2.0.4.1142 but (as I already expected) they don't
apply anymore.
Does anyone know of a way to run multiple instances concurrently
under FreeBSD 4-STABLE?
Thanks in advance,
Paul Schenkeveld
On Fri, Nov 16, 2001 at 05:49:04PM +0000, Ian Dowse wrote:
> In message <xzpofm2...@flood.ping.uio.no>, Dag-Erling Smorgrav writes:
> >
> >Corrected patch attached (and uploaded to the usual place).
>
> Ok, I tried a -stable version of that. It got past the LINUX_SIOCGIFADDR
> ioctl, but failed on the LINUX_SIOCGIFFLAGS call. I added SIOCGIFFLAGS
> conversion to linux_ioctl_special and the code that calls it, and
> vmware got past setting up the network interface but died with a
> vmware panic as soon as the guest OS tried to use the network.
>
> I then fixed two cases where the ioctl handlers should have been
> returning ENOIOCTL (one was blindly calling ioctl() with no
> translation and the other returned ENOTTY). Now it works. Below is
> the full patch I used (against -stable).
For what it's worth, I applied your patch to my stable branch (which
I had just cvsup'ed), and it did fix the problem I was seeing. I was
able to do a fair amount of vmware-based testing today, which was good
because I needed to do that testing!
Thanks for tracking this down. I had done a buildworld early last
week, but I didn't happen to need to run vmware until today. It would
have been a pretty depressing day for me if I had come in and not been
able to do any of the stuff I had planned.
For what it's worth, I did also recompile the vmware2 port. I forget
whether I came across something which suggested I needed to, or if
I was just on a roll compiling things and figured I would do that too.
[I was experimenting with portupgrade for the first time today, and
by the time I was done I had everything but XFree86 updated...]
Thanks again!
--
Garance Alistair Drosehn = g...@eclipse.acs.rpi.edu
Senior Systems Programmer or g...@freebsd.org
Rensselaer Polytechnic Institute or dro...@rpi.edu