In article <43F4A170.6080208@tadpole.com>,
Garrett D'Amore <garrett_damore@tadpole.com> wrote:
>Hey.
>
>A few questions.
>
>First (and foremost!), I want to add a member to struct
>pcmcia_io_handle.  Basically, I need an opaque handle for use by the
>chipset.  Much like struct pcmcia_mem_handle has an "mhandle" field, I
>would declare an "ihandle" field.   I would declare it as void *, or
>intptr_t.
>
>This brings us to the 2nd issue.  struct pcmcia_mem_handle has a member
>called "mhandle" which is just an opaque field for use by the chipset. 
>Right now it is declared as "pcmcia_mem_handle_t", which is typedef'd to
>"int".
>
>There are two problems with this:
>
>    1) on a 64-bit machine (LP model), mhandle is too small to hold a
>pointer
>
>    2) the type pcmcia_mem_handle_t is pretty confusing because it is
>different than the structure "struct pcmcia_mem_handle".   I think it is
>a reasonable convention that typedefs that end in xxx_t should be the
>same as the struct xxx (assuming that there is such a struct).
>
>I propose to solve both problems by changing the typedef to void *, or
>if an integer type is preferred, I can use intptr_t.  (intptr_t might be
>attractive because it means I don't have to add casts to pcic, which
>assumes mhandle is an integral type.)
>
>Does anyone out there feel any ownership for the pcmcia framework? 
>There are other "issues" with the framework (e.g. inconsistency in the
>handling of IO vs. memory vs. attribute space), but the above issues are
>the most annoying.
>
>I only need an answer to the first item (new ihandle member of struct
>pcmcia_io_handle) right now.

I think that the appropriate type for both of those handles is "void *"
and no typedef should be necessary. I find using intptr_t for handles
clumsy.

christos