On Tuesday 15 March 2005 12:48 pm, Dmitry Torokhov wrote: > On Tue, 15 Mar 2005 12:35:02 -0800, David Brownell <[EMAIL PROTECTED]> wrote: > > On Tuesday 15 March 2005 12:14 pm, Dmitry Torokhov wrote: > > > > > > It looks to me (and I might be wrong) that USB was never really > > > integrated into the driver model. It was glued with it but the driver > > > model came after most of the domain was defined, and it did not get to > > > be "bones" of the subsystem. This is why it is so easy to deatch it. > > > > That doesn't seem accurate to me. Are you thinking maybe about > > just how it uses the class device stuff? ... > > > > David, > > I was not criticizing the code, not at all, I was commenting on > evolution of the code (at least the way I perceive it). The fact that > there is (or was until recently) pre-driver-model binding code shows > that merging is still ongoing and this fact makes reversing the > process easier.
You still haven't answered my question. My observation was that only the class code can in any sense be called "new" ... so your blanket statement seemed to overlook several essential points! Which parts of the driver model were you thinking of? That pre-driver model stuff went away in maybe 2.6.5 or so, I forget just when. If you think those changes can easily be reversed, I suggest you think again ... they enabled a LOT of likewise-overdue cleanups. And they only affected the case of drivers that bound to multiple interfaces, gettng rid of a funky "half bound" state and making it look like the primary case (drivers binding to one interface at a time), which has been working since 2.5.early. It's been a long slog to get to a usb core that's a good match to the relatively complex requirements of USB. With a few notable exceptions (like PM non-support for wakeup events and for selective suspend, and strange locking side effects), converting to the driver model has been a win at every step of the way. It's gone both ways; the driver core has changed to work better with USB too. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
