Comments on: Whatever you do, don't fix the kernel! http://netsplit.com/2008/08/14/whatever-you-do-dont-fix-the-kernel/ Tue, 07 Feb 2012 11:48:49 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Scott James Remnant » Blog Archive » Calling things by the same name http://netsplit.com/2008/08/14/whatever-you-do-dont-fix-the-kernel/#comment-1740 Scott James Remnant » Blog Archive » Calling things by the same name Thu, 28 Aug 2008 13:55:39 +0000 http://www.netsplit.com/?p=170#comment-1740 [...] response to my blog post “Whatever you do, don’t fix the kernel!“, David Zeuthen (prominent plumber, the maintainer of HAL and author of DeviceKit) wrote: [...] [...] response to my blog post “Whatever you do, don’t fix the kernel!“, David Zeuthen (prominent plumber, the maintainer of HAL and author of DeviceKit) wrote: [...]

]]> By: nona http://netsplit.com/2008/08/14/whatever-you-do-dont-fix-the-kernel/#comment-1739 nona Sat, 16 Aug 2008 09:11:19 +0000 http://www.netsplit.com/?p=170#comment-1739 A couple of points to consider: 1) Aside from udev and hal, what other userspace apps rely on the kernel device name (as it appears in sysfs too)? 2) If there aren't any, do we already have to upgrade udev/hal in lock-step with the kernel for other reasons? 3) In what way would old userspace (old udev) break with a new kernel, or new userspace break with an old kernel? 4) How much extra boot time is needed for all the extra rules/shell callouts/etc. Generally I believe you're right. But remembering all the past breakage with udev vs kernel across up/downgrades, I can understand why some people might be apprehensive about doing this. Of course, if we have to up/downgrade the kernel in lock-step with udev/hal for other reasons, then this API break doesn't really matter - we might as well sneak in the cleanup. If the added advantages (cleanup, speed, etc) outweigh the added risks then it's a no-brainer of course. A couple of points to consider:

1) Aside from udev and hal, what other userspace apps rely on the kernel device name (as it appears in sysfs too)?

2) If there aren’t any, do we already have to upgrade udev/hal in lock-step with the kernel for other reasons?

3) In what way would old userspace (old udev) break with a new kernel, or new userspace break with an old kernel?

4) How much extra boot time is needed for all the extra rules/shell callouts/etc.

Generally I believe you’re right. But remembering all the past breakage with udev vs kernel across up/downgrades, I can understand why some people might be apprehensive about doing this.

Of course, if we have to up/downgrade the kernel in lock-step with udev/hal for other reasons, then this API break doesn’t really matter – we might as well sneak in the cleanup.

If the added advantages (cleanup, speed, etc) outweigh the added risks then it’s a no-brainer of course.

]]> By: Blackpaw http://netsplit.com/2008/08/14/whatever-you-do-dont-fix-the-kernel/#comment-1738 Blackpaw Thu, 14 Aug 2008 21:48:28 +0000 http://www.netsplit.com/?p=170#comment-1738 Expose a raft of backward compatibility issues and any unknown current ones just to shave a few seconds (if that) off boot time? Don't fix stuff that isn't broken. Expose a raft of backward compatibility issues and any unknown current ones just to shave a few seconds (if that) off boot time?

Don’t fix stuff that isn’t broken.

]]> By: Susan http://netsplit.com/2008/08/14/whatever-you-do-dont-fix-the-kernel/#comment-1737 Susan Thu, 14 Aug 2008 21:21:48 +0000 http://www.netsplit.com/?p=170#comment-1737 As a simple user, does all this stuff your talking about have to do with why hot-plugging my camera into Fedora no longer works when I upgraded to Fedora 9? -Susan As a simple user, does all this stuff your talking about have to do with why hot-plugging my camera into Fedora no longer works when I upgraded to Fedora 9?

-Susan

]]> By: Arpad Borsos http://netsplit.com/2008/08/14/whatever-you-do-dont-fix-the-kernel/#comment-1736 Arpad Borsos Thu, 14 Aug 2008 16:39:43 +0000 http://www.netsplit.com/?p=170#comment-1736 I hope at least Ubuntus kernel is patched this way so that this unnecessary work doesn't slow my boot time down. I hope at least Ubuntus kernel is patched this way so that this unnecessary work doesn’t slow my boot time down.

]]> By: knipknap http://netsplit.com/2008/08/14/whatever-you-do-dont-fix-the-kernel/#comment-1735 knipknap Thu, 14 Aug 2008 16:21:42 +0000 http://www.netsplit.com/?p=170#comment-1735 Well, Linux does have a strong commitment to backwards compatibility, so renaming user space API (and device names are considered that) will forever leave a trail. In your proposal the kernel will have to support the new DEVNAME forever and future changes can only be made by adding new ones; input/mice is forever. I expect breaking this API would be much less of a pain in Hotplug. If there is a performance problem, why not come up with a user-space way of changing the device name that does not require spawning a shell instead? Well, Linux does have a strong commitment to backwards compatibility, so renaming user space API (and device names are considered that) will forever leave a trail. In your proposal the kernel will have to support the new DEVNAME forever and future changes can only be made by adding new ones; input/mice is forever. I expect breaking this API would be much less of a pain in Hotplug. If there is a performance problem, why not come up with a user-space way of changing the device name that does not require spawning a shell instead?

]]> By: davidz http://netsplit.com/2008/08/14/whatever-you-do-dont-fix-the-kernel/#comment-1734 davidz Thu, 14 Aug 2008 15:27:12 +0000 http://www.netsplit.com/?p=170#comment-1734 Scott, here's why you're wrong. It's very simple and comes down to two points - you obviously agree we can't break huge amounts of userspace by changing DEVPATH - having two names emitted from the kernel (_just_ because lots of user space is broken) is just wrong and confusing => much better to fix up things in user space Besides, what's in a freaking name _anyway_? Apps should be using stable symlinks or, gosh, a device enumeration framework like HAL or the upcoming DeviceKit. Scott, here’s why you’re wrong. It’s very simple and comes down to two points

– you obviously agree we can’t break huge amounts of userspace by changing DEVPATH

– having two names emitted from the kernel (_just_ because lots of user space is
broken) is just wrong and confusing
=> much better to fix up things in user space

Besides, what’s in a freaking name _anyway_? Apps should be using stable symlinks or, gosh, a device enumeration framework like HAL or the upcoming DeviceKit.

]]> By: Scott James Remnant http://netsplit.com/2008/08/14/whatever-you-do-dont-fix-the-kernel/#comment-1733 Scott James Remnant Thu, 14 Aug 2008 14:30:22 +0000 http://www.netsplit.com/?p=170#comment-1733 @Fabrice: which is why my DEVNAME proposal *explicitly* preserves backwards compatibility - anything not using it would have rules to rename the kernel name anyway @Fabrice: which is why my DEVNAME proposal *explicitly* preserves backwards compatibility – anything not using it would have rules to rename the kernel name anyway

]]> By: FACORAT Fabrice http://netsplit.com/2008/08/14/whatever-you-do-dont-fix-the-kernel/#comment-1732 FACORAT Fabrice Thu, 14 Aug 2008 14:19:14 +0000 http://www.netsplit.com/?p=170#comment-1732 IMHO kernel dev won't fix this because it could be seen as a API exposed to userspace, and so kernel dev will not change it. Please note that not all users are using udev ( think embedded devices ), so IMHO they end up using the default kernel names. Chaging the name in the kernel will break theses devices. IMHO kernel dev won’t fix this because it could be seen as a API exposed to userspace, and so kernel dev will not change it.
Please note that not all users are using udev ( think embedded devices ), so IMHO they end up using the default kernel names. Chaging the name in the kernel will break theses devices.

]]>