On Wed, Sep 23, 2009 at 04:05:43PM -0700, David Brownell wrote: > On Wednesday 23 September 2009, Dmitry Torokhov wrote: > > This is one possible design... however you are not talking about the > > current Linux kernel but some other OS. > > What other OS might it be then, which has carried around > that exit section scrubbing mechanism for quite a few years > now, and is distributed through www.kernel.org with labels > such as "Linux 2.6.31" ??? > It can't be it since it does not exibit the behavior you are describing. > > > > And thus, if any code is presuming that *every* driver > > > can be unbound, it's wrong. > > > > > > As I said: bug in other code. > > > > Not an implementation bug, the system behaves as designed. > > Yes, absolutely an implementation bug. > > At best you can say that there are two "designs" that > are in conflict with each other. And argue, for some > reason, that the relatively-recently-introduced oops > (OK, mid-2005, so it's been lurking for quite a while) > is "more intended" than the previous safe-no-oops one > (predating mid-2005 by many years). Driver model was introduced what, 7 years ago? And since then at no point remove methods() could be __devexit. > > > > > Looking at this a bit more, it seems like there will need > > > to be some "can this bus remove this driver" check, since > > > the struct device.remove method is now managed at the bus > > > level. Easy enough to do instead of the null check that > > > I mentioned below. Provide it for platform bus, and the > > > main potential trouble spots will be resolved. > > > > ... deletia ... > > > > > I am talking about current design of the Linux driver code, as it is > > present in mainline and in this particular instance probe() and remove() > > do not do what you think they do. > > You're arguing about what it "should" do, and ignoring > all the evidence I've provided. So I guess "talking" > is right, not "listening" or better yet "discussing". > Ok, then let me tell this once again since you snipped it off: Until driver model is fixed so that using unbind sysfs attribute does not cause trouble if devices discard their remove methods I will not accept or ack drivers that mark their remove() methods as __exit. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
