Alan Cox <[EMAIL PROTECTED]> writes:

> I think we are agreeing
> 
> 
> I'm saying use something like
> 
>       struct 
>       {
>               u16 media_group;
>               union
>               {
>                       struct hdlc_physical ...
>                       struct hdlc_bitstream
>                       struct hdlc_protocol
>                       struct fr_protocol
>                       struct eth_physical
>                       struct atm_physical
>                       struct dsl_physical
>                       struct dsl_bitstream
>                       struct tr_physical
>                       struct wireless_physical
>                       struct wireless_80211
>                       struct wireless_auth
>               } config;
>       }

I think union like this is fine.


We currently have:
ioctl(sock, COMMAND, ifreq*)

where ifreq is defined in include/linux/if.h and is 16 bytes long:

struct ifreq {
        {
                char    ifrn_name[IFNAMSIZ];    /* if name, e.g. "en0" */
        } ifr_ifrn;

        union {
                struct  sockaddr ifru_addr;
                struct  sockaddr ifru_dstaddr;
                struct  sockaddr ifru_broadaddr;
                struct  sockaddr ifru_netmask;
                struct  sockaddr ifru_hwaddr;
                short   ifru_flags;
                int     ifru_ivalue;
                int     ifru_mtu;
                struct  ifmap ifru_map;
                char    ifru_slave[IFNAMSIZ];   /* Just fits the size */
                char    ifru_newname[IFNAMSIZ];
                char *  ifru_data;
        }

I understand we can put a config structure address in ifru_data - but
do we really need another level?
Wouldn't it be better put config structs there (in the union)?

It would then read:
struct ifreq {
        {
                char    ifrn_name[IFNAMSIZ];    /* if name, e.g. "en0" */
        } ifr_ifrn;

        union {
                struct  sockaddr ifru_addr;
                struct  sockaddr ifru_dstaddr;
                struct  sockaddr ifru_broadaddr;
                struct  sockaddr ifru_netmask;
                struct  sockaddr ifru_hwaddr;
                short   ifru_flags;
                int     ifru_ivalue;
                int     ifru_mtu;
                struct  ifmap ifru_map;
                char    ifru_slave[IFNAMSIZ];   /* Just fits the size */
                char    ifru_newname[IFNAMSIZ];
                char *  ifru_data;
                struct hdlc_physical ...
                struct hdlc_bitstream
                struct hdlc_protocol
                struct fr_protocol
                struct eth_physical
                struct atm_physical
                struct dsl_physical
                struct dsl_bitstream
                struct tr_physical
                struct wireless_physical
                struct wireless_80211
                struct wireless_auth
        }

while I'd put "media_group" in ioctl command code:
#define SIOCSHDLC_PHY ...
#define SIOCGHDLC_PHY ... /* get */
#define SIOCSFR ...
#define SIOCSETH_PHY ...
#define SIOCSATM...

A possible problem is if the struct gets longer - we would have to recompile
all utils using it. Doing that before distributions start using 2.4 as
a kernel for general use would save us (we can use pointers in such cases
as well, as some operations - downloading firmware or crypto keys - may have
very long data areas).

What do you think about it?
-- 
Krzysztof Halasa
Network Administrator
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to