Re: [PATCH] for PAS16 functionality for 2.4

[Thomas Molina]

On Sun, 10 Sep 2000, Michael Elizabeth Chastain wrote:

> I have written documentation on Rules.make and the interface between
> Rules.make and Makefiles.  It's here:
> 
>   ftp://ftp.shout.net/pub/users/mec/kbuild/x-Dkm-9.diff
> 
> I would really like to see this documentation in the kernel.  I've sent
> it to Linus three times, and he's ignored it three times.  I will try
> some more after the release of 2.4.0.

Thanks for a very lucid docfile.  I would really urge it be included.  I
have just one metacomment.  You have a number of sections (marked with
===) in the body of the text.  Could we have those lines duplicated at
the top in an "intro" section? (Sort of like This file covers the
following topics...), perhaps with section designators.  That would
allow the reader to quickly search to the specific part he/she was
interested in.  I can produce a patch if you'd like.

> Anyways ... I'd appreciate it if a couple of people would try this patch
> so that I can submit it.
> diff -u -r -N linux-2.4.0-test8/Rules.make linux/Rules.make
> --- linux-2.4.0-test8/Rules.makeSun Aug 13 12:55:51 2000
> +++ linux/Rules.makeSun Sep 10 14:06:02 2000
> @@ -190,7 +190,7 @@
>  #
>  ifdef CONFIG_MODULES
>  
> -SYMTAB_OBJS = $(LX_OBJS) $(OX_OBJS) $(MX_OBJS) $(MIX_OBJS)
> +SYMTAB_OBJS := $(sort $(LX_OBJS) $(OX_OBJS) $(MX_OBJS) $(MIX_OBJS))
>  
>  ifdef CONFIG_MODVERSIONS
>  ifneq "$(strip $(SYMTAB_OBJS))" ""

I tried the patch and it works for me!  Thanks again.

I'm also going to take a look at integrating sb functionality into
pas2_card.c as Mr. Hellwig suggested, unless someone thinks that is a
bad idea.  That'll be later this week after I slog through integration
of partial fractions (yuk).


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] for PAS16 functionality for 2.4

[Thomas Molina]

On Sun, 10 Sep 2000, Christoph Hellwig wrote:

> IMHO you should add some _more_ code to pas2_card.c so the sb stuff
> is completly initialized there and sb.o (sb_card.c) is no more needed
> for pas2. This means basically calling probe_sb() and attach_sb_card()
> with the right parameters.

Yeah.  A quick inspection shows it may not be as complex as I first
thought.  I'll look at it after I catch up on Calculus (solids of
revolution is currently kicking my butt), unless someone beats me to it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] for PAS16 functionality for 2.4

[Christoph Hellwig]

On Sun, Sep 10, 2000 at 01:54:38PM -0500, Thomas Molina wrote:
> I suppose the more basic question is:  Should the Soundblaster-specific
> code in pas2_card.c be ripped out and leave only PAS-specific code in
> the PAS driver?

IMHO you should add some _more_ code to pas2_card.c so the sb stuff
is completly initialized there and sb.o (sb_card.c) is no more needed
for pas2. This means basically calling probe_sb() and attach_sb_card()
with the right parameters.

Christoph

-- 
Always remember that you are unique.  Just like everyone else.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] for PAS16 functionality for 2.4

[Thomas Molina]

On Sun, 10 Sep 2000, Michael Elizabeth Chastain wrote:

> > Yepp. These warnings are there becuse of the way the list-style Makefiles
> > work.  You will see lots of them in drivers/net and drivers/scsi, too.
> 
> Here's a patch.  Let me know if it works for you; if it does,
> I will submit it for 2.4.0.
> 
> Here is some history: drivers/sound was the first of the list-style
> Makefiles and has been using lists since the late 2.1.NN series.
> Originally, drivers/sound/Makefile used $(sort ...) to remove duplicates.
> 
> In 2.3.14, Linus introduced init sections.  This made $(sort ...)
> unusable for the construction of O_OBJS and OX_OBJS.
> 
> Today, O_OBJS and OX_OBJS may contain duplicates, and Rules.make is
> supposed to ignore the duplicates (while still preserving order).
> The fact that SYMTAB_OBJS causes these warning messages is a bug.
> 
> Anyways ... I'd appreciate it if a couple of people would try this patch
> so that I can submit it.

I'll try your patch and look at your documentation.  I agree that the
warnings are bugs.  However, that was not the main point of my patch, it
was a side effect.  The point is that there was code in pas2_card.c to
initialize the Soundblaster emulation in the PAS16.  My patch merely
added the sb.o module to the list of those brought in when
CONFIG_SOUND_PAS was enabled in the configuration.  

I suppose the more basic question is:  Should the Soundblaster-specific
code in pas2_card.c be ripped out and leave only PAS-specific code in
the PAS driver?  Some might argue that would be a "cleaner" way of doing
things.  If the decision of my betters is that initialization should be
left in PAS and the driver as separate (the current situation) then I
believe my patch should stand.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] for PAS16 functionality for 2.4

[Michael Elizabeth Chastain]

> Yepp. These warnings are there becuse of the way the list-style Makefiles
> work.  You will see lots of them in drivers/net and drivers/scsi, too.

Here's a patch.  Let me know if it works for you; if it does,
I will submit it for 2.4.0.

Here is some history: drivers/sound was the first of the list-style
Makefiles and has been using lists since the late 2.1.NN series.
Originally, drivers/sound/Makefile used $(sort ...) to remove duplicates.

In 2.3.14, Linus introduced init sections.  This made $(sort ...)
unusable for the construction of O_OBJS and OX_OBJS.

Today, O_OBJS and OX_OBJS may contain duplicates, and Rules.make is
supposed to ignore the duplicates (while still preserving order).
The fact that SYMTAB_OBJS causes these warning messages is a bug.

I have written documentation on Rules.make and the interface between
Rules.make and Makefiles.  It's here:

  ftp://ftp.shout.net/pub/users/mec/kbuild/x-Dkm-9.diff

Here's a quote:

  The order of files in $(O_OBJS) and $(OX_OBJS) is significant.
  All $(OX_OBJS) files come first, in the order listed, followed by
  all $(O_OBJS) files, in the order listed.  Duplicates in the lists
  are allowed: the first instance will be linked into $(O_TARGET)
  and succeeding instances will be ignored.  (Note: Rules.make may
  emit warning messages for duplicates, but this is harmless).

I would really like to see this documentation in the kernel.  I've sent
it to Linus three times, and he's ignored it three times.  I will try
some more after the release of 2.4.0.

Anyways ... I'd appreciate it if a couple of people would try this patch
so that I can submit it.

Michael Elizabeth Chastain

"love without fear"

===

diff -u -r -N linux-2.4.0-test8/Rules.make linux/Rules.make
--- linux-2.4.0-test8/Rules.makeSun Aug 13 12:55:51 2000
+++ linux/Rules.makeSun Sep 10 14:06:02 2000
@@ -190,7 +190,7 @@
 #
 ifdef CONFIG_MODULES
 
-SYMTAB_OBJS = $(LX_OBJS) $(OX_OBJS) $(MX_OBJS) $(MIX_OBJS)
+SYMTAB_OBJS := $(sort $(LX_OBJS) $(OX_OBJS) $(MX_OBJS) $(MIX_OBJS))
 
 ifdef CONFIG_MODVERSIONS
 ifneq "$(strip $(SYMTAB_OBJS))" ""

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] for PAS16 functionality for 2.4

[Christoph Hellwig]

On Sun, Sep 10, 2000 at 09:48:55AM -0500, Thomas Molina wrote:
> On Sun, 10 Sep 2000, Christoph Hellwig wrote:
> 
> I know I misunderstand things occasionally, but it looks ok to
> me.  Isn't that just an artifact of the diff/patch thing?  I simply
> added sb.o to the line when I edited it.  That's the way I've always
> seen diff act.  It deletes the original line and adds in an identical
> line with what I added in.  The second line above adds in an identical
> line with sb.o added to the line.

Yes. Of cause you're right. Sorry,  you've done one of the right things ...

LART me ;)

> No there isn't a runtime problem.  Linus went through a phase recently
> where he forced people to clean up "warnings" during the compile
> stage.  If you answer yes to both CONFIG_SOUND_PAS and CONFIG_SOUND_SB
> you get "warinings" like this:
> /mnt/hd/src/linux-2.3.99pre/Rules.make:267: target `uart401.o' given
> more than once in the same rule.

Yepp. These warnings are there becuse of the way the list-style Makefiles work.
You will see lots of them in drivers/net and drivers/scsi, too.

> My change eliminates that by eliminating the need to include both.  It
> also makes thing clearer IMHO.

Yepp, adding sb.o is ok - but is has nothing to do with the warnings.

Christoph

-- 
Always remember that you are unique.  Just like everyone else.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] for PAS16 functionality for 2.4

[Thomas Molina]

On Sun, 10 Sep 2000, Christoph Hellwig wrote:

> In article <[EMAIL PROTECTED]> you wrote:
> > The enclosed patch corrects the Makefile and makes appropriate changes
> > to various doc files.  Please consider accepting this for the next
> > kernel.  This patch is against 2.4.0-test8.
> 
> Aehmm. Your Makefile patch looks very strange:
> 
> > -obj-$(CONFIG_SOUND_PAS)  += pas2.o sb_lib.o uart401.o
> > +obj-$(CONFIG_SOUND_PAS)  += pas2.o sb.o sb_lib.o uart401.o
> 
> Why do you remove sb.o from the object list?
> The pas2 driver has no code to use the functions in sb_lib.o -
> It has only some code to enable the sb emulation of the pas2 card.
> Either you remove both sb.o and sb_lib.o and the pas2 sb emulation is gone,
> or you leave it as is. Alternative: you can add code to use the sb_lib.o
> stuff directly from the pas2 driver (this is the best solution, IMHO).

I know I misunderstand things occasionally, but it looks ok to
me.  Isn't that just an artifact of the diff/patch thing?  I simply
added sb.o to the line when I edited it.  That's the way I've always
seen diff act.  It deletes the original line and adds in an identical
line with what I added in.  The second line above adds in an identical
line with sb.o added to the line.

> > -  PAS16 compatible. Please read Documentation/sound/PAS16.
> > +  PAS16 compatible. Do not enable both PAS16 support and Soundblaster
> > +  support since PAS16 support includes support for Soundblaster.
> > +  Please read Documentation/sound/PAS16.
> 
> Why not - there shouldn't really be an issue with it.
> It builds fine for me (and the various distributions kernel rpms).
> And I doubt there is any runtime problem with that ...

No there isn't a runtime problem.  Linus went through a phase recently
where he forced people to clean up "warnings" during the compile
stage.  If you answer yes to both CONFIG_SOUND_PAS and CONFIG_SOUND_SB
you get "warinings" like this:
/mnt/hd/src/linux-2.3.99pre/Rules.make:267: target `uart401.o' given
more than once in the same rule.

My change eliminates that by eliminating the need to include both.  It
also makes thing clearer IMHO.

> > -  insmod opl3
> > +  modprobe opl3
> 
> either works well ...

Modprobe seems cleaner to me.  It's an opinion and it's in my docfile so
I didn't see it as that big of a deal.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] for PAS16 functionality for 2.4

[Christoph Hellwig]

In article <[EMAIL PROTECTED]> you wrote:
> The PAS16 sound support includes code for the Soundblaster capability on
> the card. 

Yes.

> I found an apparent Makefile error which does not enable the
> Soundblaster support as anticipated.  Adding SB support induces an error
> for uart401 being included twice at various points of the build process.

That no real problem - it's a 'feature' of the list-style Makefiles unless
a little patch for Rules.make goes in ...

> The enclosed patch corrects the Makefile and makes appropriate changes
> to various doc files.  Please consider accepting this for the next
> kernel.  This patch is against 2.4.0-test8.

Aehmm. Your Makefile patch looks very strange:

> -obj-$(CONFIG_SOUND_PAS)  += pas2.o sb_lib.o uart401.o
> +obj-$(CONFIG_SOUND_PAS)  += pas2.o sb.o sb_lib.o uart401.o

Why do you remove sb.o from the object list?
The pas2 driver has no code to use the functions in sb_lib.o -
It has only some code to enable the sb emulation of the pas2 card.
Either you remove both sb.o and sb_lib.o and the pas2 sb emulation is gone,
or you leave it as is. Alternative: you can add code to use the sb_lib.o
stuff directly from the pas2 driver (this is the best solution, IMHO).

> -  PAS16 compatible. Please read Documentation/sound/PAS16.
> +  PAS16 compatible. Do not enable both PAS16 support and Soundblaster
> +  support since PAS16 support includes support for Soundblaster.
> +  Please read Documentation/sound/PAS16.

Why not - there shouldn't really be an issue with it.
It builds fine for me (and the various distributions kernel rpms).

And I doubt there is any runtime problem with that ...

> @@ -43,11 +43,10 @@
>Pro Audio Studio 16 or Logitech SoundMan 16 (be sure that
>you read the above list correctly). Don't answer 'y' if you
>have some other card made by Media Vision or Logitech since they
> -  are not PAS16 compatible.
> -  NOTE! Since 3.5-beta10 you need to enable SB support (next question)
> -  if you want to use the SB emulation of PAS16. It's also possible to
> -  the emulation if you want to use a true SB card together with PAS16
> -  (there is another question about this that is asked later).
> +  are not PAS16 compatible.  PAS16 support includes support for
> +  Soundblaster (sb.o module) so do not enable them both. 

You can use both - but for pas2 only you don''t have to.

> -  insmod opl3
> +  modprobe opl3

either works well ...

Christoph

-- 
Always remember that you are unique.  Just like everyone else.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/