On Tue, Mar 15, 2005 at 02:14:31PM -0800, Greg KH wrote:
> It will not make the reference counting logic easier to get wrong, or
> easier to get right. It totally takes it away from the user, and makes
> them implement it themselves if they so wish (like the USB HCD patch
> does.)
Hi,
While look
On Wed, Mar 16, 2005 at 06:16:19PM -0500, Jon Smirl wrote:
> On Tue, 15 Mar 2005 09:08:34 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > There are 4 patches being posted here in response to this message that
> > start us on the way toward cleaning up the driver model code so that
>
On Tue, 15 Mar 2005 09:08:34 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> There are 4 patches being posted here in response to this message that
> start us on the way toward cleaning up the driver model code so that
> it's actually usable by mere kernel developers :)
Is this going to l
On Tuesday 15 March 2005 17:14, Greg KH wrote:
> > Ease-of-use, maybe. However, it also means
> > ease-of-getting-reference-counting-wrong. And reference counting trumps it
> > all :)
>
> It will not make the reference counting logic easier to get wrong, or
> easier to get right. It totally takes
On Tue, Mar 15, 2005 at 02:14:31PM -0800, Greg KH wrote:
> > So this means every device will have yet another reference count, and you
> > need to be aware of _each_ lifetime to write correct code. And the
> > _reference counting_ is the hard thing to get right, so we should make
> > _that_ easie
On Tuesday 15 March 2005 2:05 pm, Dmitry Torokhov wrote:
> I think I was shopping around for the examples of proper driver model
> integration in 2.6.2 - 2.6.3 timeframe for the serio bus. I was
> looking at how USB was working around the fact that one can not
> add/remove children from the probe/r
On Tue, Mar 15, 2005 at 09:15:03PM +0100, Dominik Brodowski wrote:
> On Tue, Mar 15, 2005 at 11:34:15AM -0800, Greg KH wrote:
> > > And what about device_driver and device structure? Are they going to
> > > be changed over to be separately allocated linked objects?
> >
> > The driver stuff probabl
On Tue, 15 Mar 2005 13:14:40 -0800, David Brownell <[EMAIL PROTECTED]> wrote:
> 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 th
On Tue, Mar 15, 2005 at 01:14:40PM -0800, David Brownell wrote:
> 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.
...
> convertin
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 t
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
On Tue, Mar 15, 2005 at 11:51:21AM -0800, Greg KH wrote:
> > Also, it seems to me that you view the class subsystem to be too closely
> > related to /dev entries -- and for these /dev entries class_simple was
> > introduced, IIRC. However, /dev is not the reason the class subsystem was
> > introdu
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 subsyst
On Tue, 15 Mar 2005 11:51:21 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
>
> class interfaces are not going away, there's a good need for them like
> you have pointed out. I'm not expecting to just delete those api
> functions tomorrow, but slowly phase out the use of them over time, and
> hopefull
On Tue, Mar 15, 2005 at 11:34:15AM -0800, Greg KH wrote:
> > And what about device_driver and device structure? Are they going to
> > be changed over to be separately allocated linked objects?
>
> The driver stuff probably will be, and the device stuff possibly.
> However, they are used by a very
On Tue, 15 Mar 2005 11:34:15 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 15, 2005 at 12:47:38PM -0500, Dmitry Torokhov wrote:
> > Hi Greg,
> >
> > On Tue, 15 Mar 2005 09:08:34 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> >
> > > So I'll be slowly converting the kernel over to using this
On Tue, Mar 15, 2005 at 08:08:47PM +0100, Dominik Brodowski wrote:
> On Tue, Mar 15, 2005 at 09:08:34AM -0800, Greg KH wrote:
> > Then I moved the USB host controller code to use this new interface.
> > That was a bit more complex as it used the struct class and struct
> > class_device code directl
On Tue, Mar 15, 2005 at 12:47:38PM -0500, Dmitry Torokhov wrote:
> Hi Greg,
>
> On Tue, 15 Mar 2005 09:08:34 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
>
> > So I'll be slowly converting the kernel over to using this new
> > interface, and when finished, I can get rid of the old class apis (or
> >
On Tue, March 15, 2005 2:08 pm, Dominik Brodowski said:
> For example, temperature sensors could be exported
> using /sys/class/temp_sensors/... -- then userspace wouldn't need to know
> whether the temperature was determined using an ACPI BIOS call or by
> accessing an i2c device. Such "abstracti
On 03/15/05 13:08:47, Dominik Brodowski wrote:
On Tue, Mar 15, 2005 at 09:08:34AM -0800, Greg KH wrote:
> Then I moved the USB host controller code to use this new interface.
> That was a bit more complex as it used the struct class and struct
> class_device code directly. As you can see by the pa
On Tue, 15 Mar 2005 20:08:47 +0100, Dominik Brodowski
<[EMAIL PROTECTED]> wrote:
> On Tue, Mar 15, 2005 at 09:08:34AM -0800, Greg KH wrote:
> > Then I moved the USB host controller code to use this new interface.
> > That was a bit more complex as it used the struct class and struct
> > class_devic
On Tue, Mar 15, 2005 at 09:08:34AM -0800, Greg KH wrote:
> Then I moved the USB host controller code to use this new interface.
> That was a bit more complex as it used the struct class and struct
> class_device code directly. As you can see by the patch, the result is
> pretty much identical, and
Hi Greg,
On Tue, 15 Mar 2005 09:08:34 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> So I'll be slowly converting the kernel over to using this new
> interface, and when finished, I can get rid of the old class apis (or
> actually, just make them static) so that no one can implement them
> improperl
patch 2 of 4
Subject: tty: move to use the new class code, instead of class_simple
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
diff -Nru a/drivers/char/tty_io.c b/drivers/char/tty_io.c
--- a/drivers/char/tty_io.c 2005-03-15 08:54:22 -08:00
+++ b/drivers/char/tty_io.c 2005-03-1
Hi all,
There are 4 patches being posted here in response to this message that
start us on the way toward cleaning up the driver model code so that
it's actually usable by mere kernel developers :)
The main problem with the class code, is that _everyone_ gets it wrong
when trying to use it (and t
patch 4 of 4
Subject: USB: move the usb hcd code to use the new class code.
This moves a kref into the main hcd structure, which detaches it from
the class device structure.
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
diff -Nru a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
--- a/
patch 1 of 4
Subject: CLASS: move a "simple" class logic into the class core.
One step on improving the class api so that it can not be used incorrectly.
This also fixes the module owner issue with the dev files that happened when
the devt logic moved to the class core.
Based on a patch origina
patch 3 of 4
Subject: INPUT: move to use the new class code, instead of class_simple
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
diff -Nru a/drivers/input/evdev.c b/drivers/input/evdev.c
--- a/drivers/input/evdev.c 2005-03-15 08:54:28 -08:00
+++ b/drivers/input/evdev.c 2005-
28 matches
Mail list logo