Re: [PATCH] rtc: Make rtc-ds1742 driver hotplug-aware
- From: Kay Sievers <kay.sievers@xxxxxxxx>
- Date: Sat, 18 Aug 2007 12:45:39 +0200
On Fri, 2007-08-17 at 21:06 -0700, David Brownell wrote:
On Friday 17 August 2007, Kay Sievers wrote:
I'm not the one who's advocating a change here. If you want to
first change/break and then fix things, all of that is up to you.
I'm happy to do that. Patch is attached.
NAK. That wasn't even a serious attempt at the "fix" part,
though it does the "break" part well enough to cause severe
regressions.
You disabled uevents which breaks udev and HAL setups, because we can't
track the existence of the devices, You can't just disable device events
to disable module loading. Uevents have are by far not only about module
loading.
(As well as leaving all my technical points about your pushback
un-addressed. As I noted before, the evident fact that you don't
have technical responses to them says to me that your pushback
has no real technical basis ...)
It has. Disabling uevents to control module loading is just the totally
wrong thing to do. Uevents are there to let userspace know that a device
exists. Only the existence of MODALIAS and the "modalias" file controls
module loading, not the enabling and disabling of uevents, which is a
completely broken hack.
My patch fixes tons of issues, and that is "technical basis" enough. It
makes platform play nice with userspace, by behaving like the rest of
the kernel.
Userspace udev/HAL relies entirely on uevents, for hot- and for
coldplug. Coldplug is done by writing "add" to all "uevent" files during
early boot, that does not work anymore with platform, and needs to be
fixed.
Out of around 300 platform drivers in the tree (and many more
not yet merged upstream), this makes it so that only *THREE* of
them can hotplug ... versus in the current tree, essentially
everything that's not a legacy driver is hotplugging just fine.
That's one heck of a regression. Just shy of 100% ...
So where are the 100's of drivers that send an uevent? I'll go and fix them.
Plus it treats rtc-ds1742 as if it's a platform_driver not
an i2c_driver.
Wrong, the whole model is the other way around. MODALIAS does not tie
other drivers to a device. A driver matches on a device, and the ds1742
driver triggers on the existence of a platform driver. The alias strings
don't "treat" anything.
The whole kernel works that way, a lot of drivers get loaded by matching
on "dmi:*" or "acpi:*" strings by not letting the driver be a dmi driver
or acpi driver.
Please stop doing adding weird hacks to the kernel to fit your personal
taste and breaking all assumptions existing tools rely on. Fix the stuff
you broke and enable uevent for _all_ devices again. And let userspace
make the decision what to do with the event, like all other subsystems
in the kernel do.
Thanks,
Kay
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: legacy platform drivers and hotplugging
- From: David Brownell
- Re: legacy platform drivers and hotplugging
- References:
- Re: [PATCH] rtc: Make rtc-ds1742 driver hotplug-aware
- From: David Brownell
- Re: [PATCH] rtc: Make rtc-ds1742 driver hotplug-aware
- From: David Brownell
- Re: [PATCH] rtc: Make rtc-ds1742 driver hotplug-aware
- From: Kay Sievers
- Re: [PATCH] rtc: Make rtc-ds1742 driver hotplug-aware
- From: David Brownell
- Re: [PATCH] rtc: Make rtc-ds1742 driver hotplug-aware
- Prev by Date: Re: System call interposition/unprotecting the table
- Next by Date: [PATCH] Add some help texts to recently-introduced kconfig items
- Previous by thread: Re: [PATCH] rtc: Make rtc-ds1742 driver hotplug-aware
- Next by thread: Re: legacy platform drivers and hotplugging
- Index(es):
Relevant Pages
|
