Fix name of Xen event-channel device
in [Kernel]
|
Prev: [PATCH 3/4] [tip:x86/mm] NX protection for kernel data
Next: eeepc_laptop - 1005PE webcam not working properly.
From: Michael Tokarev on 27 May 2010 13:00 Bastian Blank wrote: > The Xen event-channel device is named evtchn in the kernel but always > used as /dev/xen/evtchn in userspace. This patch fixes the name. > > Signed-off-by: Bastian Blank <waldi(a)debian.org> > > diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c > index 66e185c..89cd743 100644 > --- a/drivers/xen/evtchn.c > +++ b/drivers/xen/evtchn.c > @@ -471,7 +471,7 @@ static const struct file_operations evtchn_fops = { > > static struct miscdevice evtchn_miscdev = { > .minor = MISC_DYNAMIC_MINOR, > - .name = "evtchn", > + .name = "xen/evtchn", Um. Will existing userspace - esp. udev rules - continue to work after this change? Also, how about other xen-related devices which are moved to /dev/xen in that same udev rules? Thanks! /mjt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Bastian Blank on 27 May 2010 13:20 On Thu, May 27, 2010 at 08:50:39PM +0400, Michael Tokarev wrote: > Bastian Blank wrote: > > The Xen event-channel device is named evtchn in the kernel but always > > used as /dev/xen/evtchn in userspace. This patch fixes the name. > > > > Signed-off-by: Bastian Blank <waldi(a)debian.org> > > > > diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c > > index 66e185c..89cd743 100644 > > --- a/drivers/xen/evtchn.c > > +++ b/drivers/xen/evtchn.c > > @@ -471,7 +471,7 @@ static const struct file_operations evtchn_fops = { > > > > static struct miscdevice evtchn_miscdev = { > > .minor = MISC_DYNAMIC_MINOR, > > - .name = "evtchn", > > + .name = "xen/evtchn", > > Um. Will existing userspace - esp. udev rules - continue > to work after this change? The udev rules will just not longer match, as they only rename the device, this is no problem. However libxc _will_ break, as it lacks proper error check in its own device creation routine. However there are not much possibilities here: this support will go away and it will annoy every user for some time. > Also, how about other xen-related > devices which are moved to /dev/xen in that same udev rules? This is the only device currently supported by the vanilla kernel, everything else is in the Xen tree only. Bastian -- Totally illogical, there was no chance. -- Spock, "The Galileo Seven", stardate 2822.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Kay Sievers on 28 May 2010 09:40 On Thu, May 27, 2010 at 19:13, Bastian Blank <waldi(a)debian.org> wrote: > On Thu, May 27, 2010 at 08:50:39PM +0400, Michael Tokarev wrote: >> Bastian Blank wrote: >> > The Xen event-channel device is named evtchn in the kernel but always >> > used as /dev/xen/evtchn in userspace. This patch fixes the name. >> > >> > Signed-off-by: Bastian Blank <waldi(a)debian.org> >> > >> > diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c >> > index 66e185c..89cd743 100644 >> > --- a/drivers/xen/evtchn.c >> > +++ b/drivers/xen/evtchn.c >> > @@ -471,7 +471,7 @@ static const struct file_operations evtchn_fops = { >> > >> > static struct miscdevice evtchn_miscdev = { >> > .minor = MISC_DYNAMIC_MINOR, >> > - .name = "evtchn", >> > + .name = "xen/evtchn", >> >> Um. Will existing userspace - esp. udev rules - continue >> to work after this change? > > The udev rules will just not longer match, as they only rename the > device, this is no problem. However libxc _will_ break, as it lacks > proper error check in its own device creation routine. > > However there are not much possibilities here: this support will go away > and it will annoy every user for some time. > >> Also, how about other xen-related >> devices which are moved to /dev/xen in that same udev rules? > > This is the only device currently supported by the vanilla kernel, > everything else is in the Xen tree only. And naming of primary device nodes is no longer udev's task. All these rules are removed from the default udev rules. These names must all come from the kernel these days. Udev will log errors if udev rules specify names which are not in sync with the kernel, so they can be fixed in the kernel or in the rules. With devtmpfs the kernel needs to know all the names to create them on its own. Udev only manages permissions, possibly creates additional symlinks, runs programs, and distribute the events to userspace. Udev no longer manages the naming of any primary device node. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michael Tokarev on 28 May 2010 09:50 Kay Sievers wrote: > On Thu, May 27, 2010 at 19:13, Bastian Blank <waldi(a)debian.org> wrote: [] >>> Also, how about other xen-related >>> devices which are moved to /dev/xen in that same udev rules? >> This is the only device currently supported by the vanilla kernel, >> everything else is in the Xen tree only. > > And naming of primary device nodes is no longer udev's task. All these > rules are removed from the default udev rules. These names must all > come from the kernel these days. Udev will log errors if udev rules > specify names which are not in sync with the kernel, so they can be > fixed in the kernel or in the rules. Finally!... It's been hashed and rehashed back when udevd were invented to replace devfs and we returned back to traditional kernel-generated names for a base. Oh well... That's, actually, _excellent_ news, something that bothered me for all these years since 2.4 kernel - that I don't have some devices in /dev (because they're named differently or moved to a subdir) which are mentioned in dmesg or sysfs. Hooray! Will check for all sound (/dev/snd/), input (/dev/input/), usb (/dev/usb/) and oh, the famous tun (/dev/net/tun) devices - you intrigued me!.. ;) Thanks! /mjt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jeremy Fitzhardinge on 28 May 2010 19:30
On 05/27/2010 10:13 AM, Bastian Blank wrote: > The udev rules will just not longer match, as they only rename the > device, this is no problem. However libxc _will_ break, as it lacks > proper error check in its own device creation routine. > Yeah, that's really annoying. I can't change the kernel without also having a flag day to update libxc. I guess we could make sure all the stable Xen branches get a libxc fix backported to them, but I wonder if it would break other toolstacks? > However there are not much possibilities here: this support will go away > and it will annoy every user for some time. > But if we don't make any kernel changes then libxc will muddle on even if udev stops handling the device name properly? J -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |