Re: [RFC-2] Configuring Synchronous Interfaces in Linux

Krzysztof Halasa (khc@intrepid.pm.waw.pl)
19 Mar 2001 17:28:56 +0100


Alan Cox <alan@lxorguk.ukuu.org.uk> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/