cvs commit: src/sys/kern kern_thr.c syscalls.master src/sys/sys

[Scott Long]

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