[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] First release candidate for 3.2.0


  • To: John Levon <levon@xxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Wed, 12 Dec 2007 14:28:13 +0000
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 12 Dec 2007 06:29:15 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acg8yt5CHNpBHqi+Edye3QAX8io7RQAAFvLX
  • Thread-topic: [Xen-devel] First release candidate for 3.2.0

On 12/12/07 14:25, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx> wrote:

>> The first big one, as you say, is our privcmd driver.  We have to decode the
>> hypercall and essentially do a copy_from/to_user() on all the buffers passed
>> in. The best way to fix this is to do it in userspace: make xc_solaris.c use
>> a
>> new ioctl() that passes in buffer address+size information as well as the
>> structs themselves. To do this cleanly means pushing a lot of do_domctl()
>> etc.
>> into xc_$OS.c, and we just haven't had time - though I'd certainly be
>> interested to know how you felt about a change like that.
> 
> I'm happy to see OS-specific changes in libxc, and even some restructuring
> if absolutely necessary. I'd much rather that than have kernel dependencies
> on domctl and sysctl. libxc is not in its current form due to some grand
> plan. ;-)

I'd like to see a brief proposal before you really go to town though...

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.