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

RE: [Xen-users] RE: How to add additional drivers to xen-kernel ?


  • To: "anant" <ANigam@xxxxxxxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx
  • From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
  • Date: Thu, 1 Feb 2007 15:05:54 +0100
  • Delivery-date: Thu, 01 Feb 2007 06:06:06 -0800
  • List-id: Xen user discussion <xen-users.lists.xensource.com>
  • Thread-index: AcdGBnRpdKZNEhCBRh6iy+UoP018jQAAL4Tw
  • Thread-topic: [Xen-users] RE: How to add additional drivers to xen-kernel ?

 

> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of anant
> Sent: 01 February 2007 13:37
> To: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-users] RE: How to add additional drivers to xen-kernel ?
> 
> 
> 
> >
> >To see which drivers are involved with this, look at the
> >.../linux-2.6-xen-sparse/drivers to see which drivers have 
> been changed
> >and compare (diff) with .../pristine-linux-2.6.x/drivers - 
> you'll then
> >see what's actually changed between the Xen drivers and the 
> native Linux
> >drivers. Note that there's no hwmon driver directory at all, so the
> >hwmon drivers don't need any changes (or at least, no one has made
> >changes to them - they may all be broken for Xen of course). 
> 
> Is this the right loaction for drivers
> /lib/modules/2.6.16.21-0.8-xen/kernel/drivers and
> /lib/modules/2.6.16.21-0.8-default/kernel/drivers 

Those are the driver (modules) compiled for the kernel for the two
models of the kernel, so what you find there is (essnetially) the
drivers that are available to your system at present. 
> 
> Yeh there is hwmon directory over default and no directory 
> over xen

So you're saying that there are NO hwmon directory in the Xen
installation at all? Probably because whoever decided what modules to
build for Xen shouldn't include the hwmon drivers - don't ask me why
this decision was taken that way... 

> ..What
> does this hwmon driver do basically...

They provide an interface between a user-mode application (such as
openWBEM) and the low-level hardware functions that provide the
measurement - fan-speed, temperature(s), etc, etc. I believe most of the
hwmon is exported as special files under /sys/...  - similar to
/proc/cpuinfo that is reporting information about your CPU. 

> and i can see most of 
> the drivers in
> default also exist in xen....what about having same drivers 
> as common for
> both as xen is under the linux so cant they have same driver 
> for both..

They are "common" in the sense that they share the same source-code (the
code is IDENTICAL). But when you build Linux for Xen, there are some
high-level changes that makes ALL of the Linux kernel and it's drivers
(modules) change in some ways because there are some things that Xen
cares about that the Kernel can't just do on it's own - and some of
those changes are within the driver support functionality. So whilst
it's the same source code, it's not compiled to the exact same binary.
So it's not possible to have THE SAME binary for both. 

For example, a driver may want to disable interrupts, Xen needs to know
this so that it doesn't forward interrupts to that Linux kernel, but the
kernel/driver can't ACTUALLY disable the interrupts for real, as that
would disable Xen from working correctly. So Xen pretends that
interrupts are disabled for that particular kernel, but not the entire
system - in the native Linux version, it's a single instruction to
disable interrupts, in Xenified Linux it's a hypercall to Xen
hypervisor, that stores some information to "remember" that this kernel
version doesn't want to be interrupted. [I'm completely ignoring the
fact that SMP has interresting effects on "disable interrupts", and it's
JUST AN EXAMPLE to make it understandable {I hope}, and I AM aware that
disabling interrupts is both nasty and usually not a good idea.]

This is all part of "para-virtualization", which is where the OS
source-code is modified to understand some aspects of virtualization.
The alternative, which uses completely unmodified OS code is the "full
virtualization" or HVM. In this case, the CPU has features that allows
each virtual machine to manage itself, but also a set of "traps" to
capture when the VM does something that the hypervisor needs to know
about. 


> So i guess it works something like this first drivers for linux gets
> installed and then the drivers needed by xen gets patched...not really
> sure...just an assumption...

The -default drivers are used when you boot without Xen (including
before you've installed Xen, if you do that separately), and when you
boot the Xen installation, the -xen drivers are used. The patching
happens during the build-process for the Xen hypervisor and xenified
Linux kernel and related components. No patching happens of the actual
binary, it's the source-code that is modified before the build starts.
If you're not building your own Xen + Linux kernel, you'll not be
patching anything (to do with Xen at least). And the way it really works
is that the Xen source tree contains complete copies of certain files
that have been modified by the Xen community. These files are used to
REPLACE the corresponding files in the original Linux source-code, and
then the build is performed just like a normal Linux build. 

--
Mats
> 
> thanks
> 
> -- 
> View this message in context: 
> http://www.nabble.com/How-to-add-additional-drivers-to-xen-ker
> nel---tf3149634.html#a8748286
> Sent from the Xen - User mailing list archive at Nabble.com.
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
> 
> 
> 



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


 


Rackspace

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