From: Krzysztof Halasa <khc@intrepid.pm.waw.pl>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC-2] Configuring Synchronous Interfaces in Linux
Date: 19 Mar 2001 17:28:56 +0100 [thread overview]
Message-ID: <m3r8ztpvsn.fsf@intrepid.pm.waw.pl> (raw)
In-Reply-To: <E1441je-0002T3-00@the-village.bc.nu>
In-Reply-To: Alan Cox's message of "Thu, 7 Dec 2000 14:09:19 +0000 (GMT)"
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
next prev parent reply other threads:[~2001-03-19 16:34 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-12-05 22:55 [RFC-2] Configuring Synchronous Interfaces in Linux Stuart Lynne
2000-12-06 1:21 ` Alan Cox
2000-12-06 1:34 ` Dan Hollis
2000-12-06 1:55 ` Stuart Lynne
2000-12-07 0:14 ` Krzysztof Halasa
2000-12-07 14:09 ` Alan Cox
2000-12-07 14:12 ` Jeff Garzik
2000-12-07 14:40 ` Alan Cox
2000-12-09 22:33 ` parport0 problem ebi4
2001-03-19 16:28 ` Krzysztof Halasa [this message]
[not found] <Pine.LNX.4.30.0012051925330.6718-100000@pc24.sr.bham.ac.uk>
2000-12-05 19:46 ` [RFC-2] Configuring Synchronous Interfaces in Linux Ivan Passos
-- strict thread matches above, loose matches on Subject: below --
2000-12-05 5:58 Ivan Passos
2000-12-05 9:38 ` Francois Romieu
2000-12-05 19:17 ` Ivan Passos
2000-12-05 9:41 ` Alan Cox
2000-12-05 15:15 ` Greg Parrott
2000-12-05 19:23 ` Ivan Passos
2000-12-05 20:41 ` Peter Samuelson
2000-12-05 21:56 ` Alan Cox
2000-12-05 14:43 ` Matthew G. Marsh
2000-12-05 19:40 ` Ivan Passos
2000-12-05 15:18 ` Paul Fulghum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3r8ztpvsn.fsf@intrepid.pm.waw.pl \
--to=khc@intrepid.pm.waw.pl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox