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/

Reply via email to