ALSA update
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 1 line
ChangeSet 1.885.1.5, 2002/12/18 10:13:22+01:00, [email protected]
<snip>
sound/usb/usbaudio.c
Quoted 28 lines
diff -Nru
a/sound/usb/usbaudio.cb/sound/usb/usbaudio.csound/usb/usbaudio.c +8
-0@@ -526,7 +526,11 @@/* * complete callback from data urb */ +#ifndef OLD_USB static void snd_complete_urb(struct urb *urb, struct pt_regs *regs) +#else +static void snd_complete_urb(struct urb *urb) +#endif {snd_urb_ctx_t *ctx = (snd_urb_ctx_t *)urb->context;snd_usb_substream_t *subs = ctx->subs;@@ -551,7 +555,11 @@/* * complete callback from sync urb */ +#ifndef OLD_USB static void snd_complete_sync_urb(struct urb *urb, struct pt_regs *regs) +#else +static void snd_complete_sync_urb(struct urb *urb) +#endif {snd_urb_ctx_t *ctx = (snd_urb_ctx_t *)urb->context;snd_usb_substream_t *subs = ctx->subs;@@ -583,6 +591,9 @@
Ick, you're kidding me, right? Why do this? Are you trying to keep a common code base with 2.4 and 2.5 USB drivers? If so, I don't recommend it, as the code will be sprinkled with these ifdef's...
thanks,
greg k-h
Quoted 28 lines · Greg KH
Quoted 1 line
ChangeSet 1.885.1.5, 2002/12/18 10:13:22+01:00, [email protected]
<snip>
Quoted 24 lines
diff -Nru
a/sound/usb/usbaudio.cb/sound/usb/usbaudio.csound/usb/usbaudio.c +8
-0@@ -526,7 +526,11 @@/* * complete callback from data urb */ +#ifndef OLD_USB static void snd_complete_urb(struct urb *urb, struct pt_regs *regs) +#else +static void snd_complete_urb(struct urb *urb) +#endif {snd_urb_ctx_t *ctx = (snd_urb_ctx_t *)urb->context;snd_usb_substream_t *subs = ctx->subs;@@ -551,7 +555,11 @@/* * complete callback from sync urb */ +#ifndef OLD_USB static void snd_complete_sync_urb(struct urb *urb, struct pt_regs *regs) +#else +static void snd_complete_sync_urb(struct urb *urb) +#endif
Quoted 8 lines
sound/usb/usbaudio.c
Quoted 4 lines
sound/usb/usbaudio.c +0
-0{snd_urb_ctx_t *ctx = (snd_urb_ctx_t *)urb->context;snd_usb_substream_t *subs = ctx->subs;@@ -583,6 +591,9 @@Ick, you're kidding me, right? Why do this? Are you trying to keep a common code base with 2.4 and 2.5 USB drivers? If so, I don't recommend it, as the code will be sprinkled with these ifdef's...
Not much. We have 9 #ifdef's and all trying to resolve the conflicts with new function prototypes which is difficult to replace with defines or inline functions. Perhaps, you'll have an idea to solve this problem.
For us, it's very important to have only one code base for all kernels, but on the other hand, we're trying to leave the 2.2/2.4 kernel code specific parts separate in our CVS repository if possible.
Jaroslav
-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
Quoted 4 lines · Jaroslav Kysela
Not much. We have 9 #ifdef's and all trying to resolve the conflicts with new function prototypes which is difficult to replace with defines or inline functions. Perhaps, you'll have an idea to solve this problem.
Short of keeping a 2.4 version and a 2.5/2.6 version, no, I do not have any ideas, sorry. The USB core has changed a lot between those two trees, as you know.
Quoted 3 lines
For us, it's very important to have only one code base for all kernels, but on the other hand, we're trying to leave the 2.2/2.4 kernel code specific parts separate in our CVS repository if possible.
Then you might want to leave the OLD_USB stuff out of the 2.5 kernel :)
thanks,
greg k-h
At Wed, 18 Dec 2002 11:27:40 -0800,
Quoted 10 lines · Greg KH
Quoted 4 lines · Jaroslav Kysela
Not much. We have 9 #ifdef's and all trying to resolve the conflicts with new function prototypes which is difficult to replace with defines or inline functions. Perhaps, you'll have an idea to solve this problem.
Short of keeping a 2.4 version and a 2.5/2.6 version, no, I do not have any ideas, sorry. The USB core has changed a lot between those two trees, as you know.
yep, i know :)
but it's also nice to keep the same codebase, because the test environment of most of users is still on 2.4.
i'll do clean up the codes once when all major bugs are fixed.
Takashi
Quoted 43 lines · Jaroslav Kysela
Quoted 28 lines · Greg KH
Quoted 1 line
ChangeSet 1.885.1.5, 2002/12/18 10:13:22+01:00, [email protected]
<snip>
Quoted 24 lines
diff -Nru
a/sound/usb/usbaudio.cb/sound/usb/usbaudio.csound/usb/usbaudio.c +8
-0@@ -526,7 +526,11 @@/* * complete callback from data urb */ +#ifndef OLD_USB static void snd_complete_urb(struct urb *urb, struct pt_regs *regs) +#else +static void snd_complete_urb(struct urb *urb) +#endif {snd_urb_ctx_t *ctx = (snd_urb_ctx_t *)urb->context;snd_usb_substream_t *subs = ctx->subs;@@ -551,7 +555,11 @@/* * complete callback from sync urb */ +#ifndef OLD_USB static void snd_complete_sync_urb(struct urb *urb, struct pt_regs *regs) +#else +static void snd_complete_sync_urb(struct urb *urb) +#endif Quoted 8 lines
sound/usb/usbaudio.c
Quoted 4 lines
sound/usb/usbaudio.c +0
-0{snd_urb_ctx_t *ctx = (snd_urb_ctx_t *)urb->context;snd_usb_substream_t *subs = ctx->subs;@@ -583,6 +591,9 @@Ick, you're kidding me, right? Why do this? Are you trying to keep a common code base with 2.4 and 2.5 USB drivers? If so, I don't recommend it, as the code will be sprinkled with these ifdef's...
Not much. We have 9 #ifdef's and all trying to resolve the conflicts with new function prototypes which is difficult to replace with defines or inline functions. Perhaps, you'll have an idea to solve this problem.
Quoted 6 lines
For us, it's very important to have only one code base for all kernels, but on the other hand, we're trying to leave the 2.2/2.4 kernel code specific parts separate in our CVS repository if possible.
Jaroslav
Hello, Jaroslav and All.
How about other changes in new 2.5 kernel, like new PnP layer (Adam Belay) or changes with module & boot params (Rusty Russel)? There are now some changes in 2.5.52 kernel in sound/isa/opl3sa2.c that make this driver not compatible with other kernels. May be it's better split your tree in several trees for each version of kernels?
Ruslan.
At Wed, 18 Dec 2002 22:51:27 +0300 (MSK),
Quoted 7 lines · Ruslan U. Zakirov
Hello, Jaroslav and All.
How about other changes in new 2.5 kernel, like new PnP layer (Adam Belay) or changes with module & boot params (Rusty Russel)? There are now some changes in 2.5.52 kernel insound/isa/opl3sa2.cthat make this driver not compatible with other kernels. May be it's better split your tree in several trees for each version of kernels?
if possible, we'll build up some wrapper for 2.4 on alsa-driver (not the codebase for 2.5) tree. if not possible, yes, splitting to two trees would be reasonable for such big changes...
thanks for noticing this issue. i'll check them now.
Signature · 2 lines
Takashi Iwai <[email protected]> SuSE Linux AG - www.suse.de ALSA Developer ALSA Project - www.alsa-project.org
Quoted 10 lines · Takashi Iwai
At Wed, 18 Dec 2002 22:51:27 +0300 (MSK),
Quoted 7 lines · Ruslan U. Zakirov
Hello, Jaroslav and All.
How about other changes in new 2.5 kernel, like new PnP layer (Adam Belay) or changes with module & boot params (Rusty Russel)? There are now some changes in 2.5.52 kernel insound/isa/opl3sa2.cthat make this driver not compatible with other kernels. May be it's better split your tree in several trees for each version of kernels?
Quoted 5 lines
if possible, we'll build up some wrapper for 2.4 on alsa-driver (not the codebase for 2.5) tree. if not possible, yes, splitting to two trees would be reasonable for such big changes...
thanks for noticing this issue. i'll check them now.
I just removed the complete callback redefinitions from the 2.5 tree, but we still have three small OLD_USB sections (mainly commenting 2.5 code which 2.4 code requires to override). Hopefully, it's quite reasonable. What do you think, Greg?
Jaroslav
-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
Quoted 16 lines · Jaroslav Kysela
Quoted 14 lines · Takashi Iwai
At Wed, 18 Dec 2002 22:51:27 +0300 (MSK),
Quoted 7 lines · Ruslan U. Zakirov
Hello, Jaroslav and All.
How about other changes in new 2.5 kernel, like new PnP layer (Adam Belay) or changes with module & boot params (Rusty Russel)? There are now some changes in 2.5.52 kernel insound/isa/opl3sa2.cthat make this driver not compatible with other kernels. May be it's better split your tree in several trees for each version of kernels?if possible, we'll build up some wrapper for 2.4 on alsa-driver (not the codebase for 2.5) tree. if not possible, yes, splitting to two trees would be reasonable for such big changes...
Quoted 6 lines
Quoted 1 line
thanks for noticing this issue. i'll check them now.
I just removed the complete callback redefinitions from the 2.5 tree, but we still have three small
OLD_USBsections (mainly commenting 2.5 code which 2.4 code requires to override). Hopefully, it's quite reasonable. What do you think, Greg?
In the end, whatever is easiest for you do to, as I'm not the one who has to maintain the code :)
That being said, the smaller the number of #ifdefs, the better. Personally I would just have two different trees, but that's just me...
thanks,
greg k-h
Quoted 10 lines · Takashi Iwai
At Wed, 18 Dec 2002 22:51:27 +0300 (MSK),
Quoted 7 lines · Ruslan U. Zakirov
Hello, Jaroslav and All.
How about other changes in new 2.5 kernel, like new PnP layer (Adam Belay) or changes with module & boot params (Rusty Russel)? There are now some changes in 2.5.52 kernel insound/isa/opl3sa2.cthat make this driver not compatible with other kernels. May be it's better split your tree in several trees for each version of kernels?
Quoted 5 lines
if possible, we'll build up some wrapper for 2.4 on alsa-driver (not the codebase for 2.5) tree. if not possible, yes, splitting to two trees would be reasonable for such big changes...
thanks for noticing this issue. i'll check them now.
If you really want single source you might use something like m4 to split out both 2.4 and 2.5 versions which are less cluttered.
I admit this doesn't make your job a bit easier, but people reading the drivers for one series or the other would have an easier job reading the code. In a perfect world that would means they would find bugs for you and just send patches. In reality you wouldn't have people telling you your code was ugly.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.