Messages in this thread | | | Subject | Re: [RFC-2] Configuring Synchronous Interfaces in Linux | From | Krzysztof Halasa <> | Date | 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/
| |