The Xen Store Daemon is started in xenstored_core.c. It creates a device file ("/dev/xen/evtchn") in case such a device file does not exists and it opens it. (see : domain_init() ,file tools/xenstore/xenstored_domain.c).
This appears to be out of date.
XenIntro (last edited 2009-02-12 16:31:12 by TimPost)
In Xen 4.0.0 domain_init() calls xc_evtchn_open() which in 'tools/libxc/xc_linux.c' does create this if it does not exist. However, in later versions this is not the case. In commit e645730ee5f8cc5cd6bef73318606768a41baf41  they changed this practice with:
tools: assume that special Xen devices have been created by the platform
Remove all the magic surrounding the special Xen devices in Linux specific code whereby we attempt to figure out what the correct major:minor number is and check the the existing device has these numbers etc. In 2010 we really should be able to trust that the platform has created the devices correctly or provide correct configuration settings such that they are without resorting to tearing down the platform configured state and rebuilding it.
tools/hotplug/Linux/xen-backend.rules already contains the necessary udev rules to create /dev/xen/evtchn and friends in the correct place.
The above rule file creates '/dev/xen/evtchn' when the 'evtchn' kernel driver is loaded. Thus, any kernel with this driver built in, or if this module is loaded, will have this device.
I'm for more than one approach like virt-what does for Xen, but the only thing I can see evtchn telling us is possibly something about paravirtualization.