Kris Moore wrote:
Robert Watson wrote:
This work was done by Tijl at the request of the PC-BSD guys, who
would like to be able to run windows applications out of the box on
PC-BSD for their next release (impending). David then reviewed and
committed the patch giving it his approval. The goal here was to
avoid having the PC-BSD people have to run around with additional
system call patches for the forseeable future, and to avoid requiring
PC-BSD to fork the FreeBSD kernel to do that.
Robert is correct here. Tijl has done a fantastic job with getting Wine
up to spec on FreeBSD, and it will help us greatly in trying to pursue
our goal of getting PC-BSD / FreeBSD on as many desktops as possible.
Easily the two most requested features we get from users who want to
switch over to BSD is working Wine support, and Flash 9 support. This
patch is a HUGE step in the right direction, and allows our users to
very easily run old legacy business apps or play the latest games, like
WoW. As such I really can't underscore the importance of this enough for
a viable desktop product.
I certainly appreciate the work that the PC-BSD guys are doing, and I
apologize if it seemed like I didn't. However, adding a new syscall is
a very big deal; once it's in, it lives with the OS for a very, very
long time. So, it's something that does discussion.
That being said, most of the technical details are a bit over my head,
but I will add my $0.02 to this. Whatever the solution, there needs to
be a working solution in the end. If there's a better, more portable way
to do this, then by all means lets get it done. If nobody can or will
write this solution, then lets not just drop the original patch. A fix
is greatly needed either way, so I hope this is added in the very near
future.
Even if you decide to only add this new functionality to FreeBSD 7.x,
that's fine with us. Our next release of PC-BSD will be our last based
on FreeBSD 6.x before moving to 7. We're committed to shipping with the
patch Tijl wrote, since the improvements to Wine with it are night and
day. Of course if you roll this into the tree, all the better since I
won't have to spend the next 6 months to a year reminding users that
when they update world, they have to apply the Wine patch first ;-)
Robert's comparison to Linux is only half-valid. There's really no
reason to hold linux's clone/vfork threads up as a model to emulate via
a new first-class interface into the kernel. If you want to emulate it,
compile your app against the linux-threads package and be done with it.
The Linux developers are moving beyond that primitive "threads" package
anyways and onto real threads and a complementary API to manage those
threads. So tkill and tgkill are interesting things to look at, not
just here but in the broader need to work with Linux both at a source
and a binary level. I believe that Dan also suggested something along
this line in his discussion about having Solaris-style (and thus
linux-style) thread groups, so I'm not exactly sure who is disagreeing
with whom in Robert's response. Thread groups do seem like a logical
next step, but it's impossible to say at this point whether the syscall
API to support them would at all be served by the syscall that was just
added. If it isn't, then this syscall becomes a 1-off orphan and a
long-term liability to both users and developers. That's what
ultimately needs to be avoided.
So, supporting Wine is definitely a good idea, and there's no doubt a
good solution available. It just makes me nervous when syscalls are
added with such little discussion and commitment.
Scott
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
