[KJ] need a better name for existing "FIELD_SIZE" macro under

[KJ] need a better name for existing "FIELD_SIZE" macro under

[Robert P. J. Day]

  one of the outstanding tasks in the wiki is to use the
"FIELD_SIZE()" macro (currently defined as FIELD_SIZEOF but that's
being renamed in the patch) in include/linux/kernel.h to simplify some
code in the tree.  i had already submitted that patch without noticing
that a few files under the sound/ directory already define a
"FIELD_SIZE" macro which clashes:

  $ grep -rw FIELD_SIZE *

  andrew morton suggested that the easiest solution is to just rename
the one under the sound/ directory, but i have no idea what that macro
represents.  anyone know what's going on there and can recommend a
better (and less universally intrusive) name that doesn't steal prime
macro naming real estate?

  once the name "FIELD_SIZE" is reclaimed from those sound files, i
can resubmit the global patch.  thanks.

rday

-- 
====================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
====================================
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] need a better name for existing "FIELD_SIZE" macro sound/.

[walter harms]

in my old kernel code is is only used inside the vx driver.
IMHO it can be replaced with VX_FIELD_SIZE

is is only used by functions in .h (eek) and one .c code.

re,
 wh



Robert P. J. Day wrote:
>   one of the outstanding tasks in the wiki is to use the
> "FIELD_SIZE()" macro (currently defined as FIELD_SIZEOF but that's
> being renamed in the patch) in include/linux/kernel.h to simplify some
> code in the tree.  i had already submitted that patch without noticing
> that a few files under the sound/ directory already define a
> "FIELD_SIZE" macro which clashes:
> 
>   $ grep -rw FIELD_SIZE *
> 
>   andrew morton suggested that the easiest solution is to just rename
> the one under the sound/ directory, but i have no idea what that macro
> represents.  anyone know what's going on there and can recommend a
> better (and less universally intrusive) name that doesn't steal prime
> macro naming real estate?
> 
>   once the name "FIELD_SIZE" is reclaimed from those sound files, i
> can resubmit the global patch.  thanks.
> 
> rday
> 
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] need a better name for existing "FIELD_SIZE" macro sound/.

[Robert P. J. Day]

On Mon, 12 Feb 2007, walter harms wrote:

>
> in my old kernel code is is only used inside the vx driver.
> IMHO it can be replaced with VX_FIELD_SIZE
>
> is is only used by functions in .h (eek) and one .c code.

that's not quite true in the latest "git pull":

$ grep -rwl FIELD_SIZE sound
sound/drivers/vx/vx_cmd.h
sound/drivers/vx/vx_pcm.c
sound/pci/pcxhr/pcxhr_core.h
sound/pci/pcxhr/pcxhr_hwdep.c
sound/pci/pcxhr/pcxhr_core.c

i *could* submit a patch renaming that macro to VX_FIELD_SIZE and
PCXHR_FIELD_SIZE respectively but, if you want to look at those files
more closely, it *seems* that that field represents the same thing in
each, and i'd hate to deliberately rename a macro to two different
names for no good reason when they represent the same thing.

is there a more descriptive name that might be used that describes
what that field is *for*?

rday
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] need a better name for existing "FIELD_SIZE" macro sound/.

[walter harms]

Robert P. J. Day wrote:
> On Mon, 12 Feb 2007, walter harms wrote:
> 
>> in my old kernel code is is only used inside the vx driver.
>> IMHO it can be replaced with VX_FIELD_SIZE
>>
>> is is only used by functions in .h (eek) and one .c code.
> 
> that's not quite true in the latest "git pull":
> 
> $ grep -rwl FIELD_SIZE sound
> sound/drivers/vx/vx_cmd.h
> sound/drivers/vx/vx_pcm.c
> sound/pci/pcxhr/pcxhr_core.h
> sound/pci/pcxhr/pcxhr_hwdep.c
> sound/pci/pcxhr/pcxhr_core.c
> 
> i *could* submit a patch renaming that macro to VX_FIELD_SIZE and
> PCXHR_FIELD_SIZE respectively but, if you want to look at those files
> more closely, it *seems* that that field represents the same thing in
> each, and i'd hate to deliberately rename a macro to two different
> names for no good reason when they represent the same thing.


your are right picking a later kernel code reveals it.
I guess they are something like controlfield the comment in
pcxhr_hwdep.c /* test 8 or 2 phys in */
seem to point to that.
Just rename it, perhaps you can make emums ?
the simple fact to have 2 common named macros show that the want to be renamed.


The alsa-page seems to indicate the chips are related, perhaps some sound expert can comment on that ?
http://www.alsa-project.org/alsa-doc/index.php?vendor=vendor-Digigram#matrix

re,
 wh


> 
> is there a more descriptive name that might be used that describes
> what that field is *for*?
> 
> rday
> 
> 
> 
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors