Jeff Garzik wrote :
> Don't load your drivers up with 2.2.x compatibility junk. Write a 2.4.x
> driver... and use this toolkit to make it work under 2.2.
Actually, wouldn't it be better to have people writting 2.5.X
driver and having your toolkit enabling them for 2.4.X and 2.2.X ?
Also, have you looked at the Pcmcia package, David Hinds has a
pretty complete compatibility toolkit going back to 1.2.X, and used by
many Pcmcia drivers (it's actually pretty amazing to see all those
Pcmcia drivers working regardless). Maybe you could propose David a
merge of the two (you get some more code and some more userbase).
Yes, of course, NIH...
Have fun...
Jean
Jean Tourrilhes wrote:
> Jeff Garzik wrote :
>
>>Don't load your drivers up with 2.2.x compatibility junk. Write a 2.4.x
>>driver... and use this toolkit to make it work under 2.2.
>
>
> Actually, wouldn't it be better to have people writting 2.5.X
> driver and having your toolkit enabling them for 2.4.X and 2.2.X ?
Sure, that would be fine too.
The main user demand has been for 2.4.x drivers on 2.2.x. If there is
demand for 2.0.x driver support or, what you describe, 2.5.x driver
support on 2.[24].x, that's a good direction to head towards. I haven't
seen any requests for that from driver authors yet.
> Also, have you looked at the Pcmcia package, David Hinds has a
> pretty complete compatibility toolkit going back to 1.2.X, and used by
> many Pcmcia drivers (it's actually pretty amazing to see all those
> Pcmcia drivers working regardless). Maybe you could propose David a
> merge of the two (you get some more code and some more userbase).
> Yes, of course, NIH...
I am sadly guilty of "NIH" in several cases, but actually this is not
one of them :) I think that kcompat24 provides a bit more of a complete
compatibility package than the other solutions. So, I would like to
borrow code from pcmcia and other sources to make this toolkit even
better. (patches accepted! :))
Jeff
On Wed, Jun 12, 2002 at 06:50:10PM -0400, Jeff Garzik wrote:
>
> Sure, that would be fine too.
>
> The main user demand has been for 2.4.x drivers on 2.2.x. If there is
> demand for 2.0.x driver support or, what you describe, 2.5.x driver
> support on 2.[24].x, that's a good direction to head towards. I haven't
> seen any requests for that from driver authors yet.
It seems that most of the 2.5.X construct are also available
in 2.4.X, but 2.5.X obsolete some of the old 2.4.X construct (for
example pci API).
For me, the problem between 2.5.X and 2.4.X is the USB API
which has significantely changed (urb_submit anyone ?). I end up
having two quite different version of irda-usb to maintain. But
probably USB in 2.5.X. is too much a moving target for you to include
in your package.
> I am sadly guilty of "NIH" in several cases, but actually this is not
> one of them :) I think that kcompat24 provides a bit more of a complete
> compatibility package than the other solutions. So, I would like to
> borrow code from pcmcia and other sources to make this toolkit even
> better. (patches accepted! :))
Actually, NIH works both ways (so don't take personally). It
would be nice to have David Hinds using your package, because you
would immediately gain a sizeable user base, and because a lot of
Pcmcia drivers are both in the kernel and the Pcmcia package, and some
pour souls attempt to keep them in sync.
For example, we currently have a unsatisfactory situation with
the orinoco and airo drivers.
By the way, I didn't look in detail at kcompat24, but I
guarantee you that the latest Pcmcia package has quite a complete
solution.
> Jeff
Have fun...
Jean
On Wed, Jun 12, 2002 at 04:27:14PM -0700, Jean Tourrilhes wrote:
> For me, the problem between 2.5.X and 2.4.X is the USB API
> which has significantely changed (urb_submit anyone ?). I end up
> having two quite different version of irda-usb to maintain. But
> probably USB in 2.5.X. is too much a moving target for you to include
> in your package.
Heh, this is the first complaint I've had about this, which is quite
surprising :)
I'll be putting most of the 2.5 USB api changes into 2.4 once
2.4.19-final comes out, so then you can go back to having 1 version of
your driver (if you like that kind of thing, personally I don't.)
thanks,
greg k-h
On Wed, Jun 12, 2002 at 04:39:55PM -0700, Greg KH wrote:
> On Wed, Jun 12, 2002 at 04:27:14PM -0700, Jean Tourrilhes wrote:
> > For me, the problem between 2.5.X and 2.4.X is the USB API
> > which has significantely changed (urb_submit anyone ?). I end up
> > having two quite different version of irda-usb to maintain. But
> > probably USB in 2.5.X. is too much a moving target for you to include
> > in your package.
>
> Heh, this is the first complaint I've had about this, which is quite
> surprising :)
I guess you are the one doing most of the work in 2.5.X, and
most outside drivers are only targetting 2.4.X.
> I'll be putting most of the 2.5 USB api changes into 2.4 once
> 2.4.19-final comes out,
Don't rush, I'm not sure if you are done with USB
changes. When the new HCD stuff will be in, I'm sure you will find
something else to tinker with.
> so then you can go back to having 1 version of
> your driver (if you like that kind of thing, personally I don't.)
If my driver was static, I would not care. But because I need
to fix and update it, the patching and testing work is multiplied by
two.
Bah, I'm not really complaining. I was just thinking that it
would be a nice feature, but I can live without it.
> thanks,
>
> greg k-h
Have fun...
Jean
On Wed, Jun 12, 2002 at 04:50:30PM -0700, Jean Tourrilhes wrote:
> Don't rush, I'm not sure if you are done with USB
> changes. When the new HCD stuff will be in, I'm sure you will find
> something else to tinker with.
Heh, I _know_ I'm not done with USB changes :)
I'll just be backporting the ones that are now stable, and have been in
the tree for a long time. I'll not be backporting all of the new HCD
drivers for one.
Here's what I think I'll change in 2.4.20 that is now in the 2.5 tree:
- update the USB documentation
- remove the horrible typedefs in usb.h
- change usb_submit_urb and usb_alloc_urb apis
- add new drivers
- backport the usb-serial api and locking changes
And that will probably be enough for 2.4.20. In the meantime, the USB
changes in 2.5 will continue on, giving us more fodder to backport in
2.4.21, not to mention 2.2.22 :)
thanks,
greg k-h
On Wed, Jun 12, 2002, Greg KH <[email protected]> wrote:
> On Wed, Jun 12, 2002 at 04:50:30PM -0700, Jean Tourrilhes wrote:
> > Don't rush, I'm not sure if you are done with USB
> > changes. When the new HCD stuff will be in, I'm sure you will find
> > something else to tinker with.
>
> Heh, I _know_ I'm not done with USB changes :)
> I'll just be backporting the ones that are now stable, and have been in
> the tree for a long time. I'll not be backporting all of the new HCD
> drivers for one.
>
> Here's what I think I'll change in 2.4.20 that is now in the 2.5 tree:
> - update the USB documentation
> - remove the horrible typedefs in usb.h
> - change usb_submit_urb and usb_alloc_urb apis
Do you think it's a good idea to change the API in a stable kernel
series?
> - add new drivers
> - backport the usb-serial api and locking changes
>
> And that will probably be enough for 2.4.20. In the meantime, the USB
> changes in 2.5 will continue on, giving us more fodder to backport in
> 2.4.21, not to mention 2.2.22 :)
The rest sound good to me.
JE
On Wed, Jun 12, 2002 at 08:36:20PM -0400, Johannes Erdfelt wrote:
> On Wed, Jun 12, 2002, Greg KH <[email protected]> wrote:
> > - change usb_submit_urb and usb_alloc_urb apis
>
> Do you think it's a good idea to change the API in a stable kernel
> series?
When it fixes the real problems these api changes offer, yes.
I will be fixing up all of the in-kernel references, so I don't see any
problem this can cause. Any out-of-kernel drivers will just have to
deal with it :)
thanks,
greg k-h