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
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 looking
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
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 let me
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
it's
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
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_
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
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
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
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.
...
>
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
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
> >
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
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
>
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
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
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
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
> >
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,
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
>
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
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
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
---
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
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
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
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
---
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
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
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-15
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
improperly
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
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 abstractions,
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_device code
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
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
actually,
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 directly. As
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 new
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
hopefully,
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.
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
introduced for
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
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
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.
...
converting to
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 the driver
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 probably will be,
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
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_ easier. The
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 it away
55 matches
Mail list logo
