Skip to contentSkip to conversation

ALSA update

DISCUSSION Greg KH 5 participants 9 messages Dec 18, 2002 – Dec 20, 2002 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Greg KH

author
#1 lore raw
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.c b/sound/usb/usbaudio.c

sound/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

#2 lore raw
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.c b/sound/usb/usbaudio.c

sound/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

author
#3 lore raw
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

#4 lore raw

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

#5 lore raw
In reply to Jaroslav Kysela
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.c b/sound/usb/usbaudio.c

sound/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.

#6 lore raw

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 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?

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
#7 lore raw
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 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?

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

author
#8 lore raw
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 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?

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_USB sections (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

#9 lore raw
In reply to Takashi Iwai
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 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?

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.