From: Francois Romieu <romieu@cogenit.fr>
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: linux-kernel@vger.kernel.org, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Jeff Garzik <jgarzik@mandrakesoft.com>
Subject: Re: Generic HDLC interface continued
Date: Sat, 28 Sep 2002 20:21:38 +0200 [thread overview]
Message-ID: <20020928202138.A17244@se1.cogenit.fr> (raw)
In-Reply-To: <m3y99nrtsu.fsf@defiant.pm.waw.pl>; from khc@pm.waw.pl on Fri, Sep 27, 2002 at 11:45:05PM +0200
<disclaimer>
It's ok for me to trim the Cc: list if noboy objects.
Don't hesistate to ask for clarification if my english comes from Mars.
</disclaimer>
Krzysztof Halasa <khc@pm.waw.pl> :
[...]
> Addressing the second problem (unknown data length) requires the caller
> (user-space utils) to supply allocated space size. The kernel would
> update the size to reflect the actual amount of data required, allowing
> the caller to allocate more space and try again (or ignore the unknown
> interface).
If size/limit of an underlying object is in a structure for other purpose
than debygging, it means something (S) is working with an object and it (S)
doesn't know what it is. Design proble: always work with an object whose
identity you know or simply pass a reference to someone knowing better.
I don't see why a 'size' parameter is required. Thus I'm fine with the
following (we are lucky enough that there is enough space in union ifr_ifru
to hold ifru_settings):
struct ifreq
{
#define IFHWADDRLEN 6
#define IFNAMSIZ 16
union
{
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 {
int type;
union {
raw_hdlc_proto *;
...
sync_serial_settings *;
etc_line_settings *;
}
} ifru_settings;
} ifr_ifru;
};
Note however that struct ifreq on amphetamin (wrt lines of code) doesn't
improve readability for everybody. That's a slightly different problem.
> What is important here is that inner union consists of pointers
> to *_proto / *_settings structs and not of the structs themselves.
Agree on this.
> Another solution - using a different ifreq structs for different tasks
> (something like the sockaddr_*) - sort of:
[...]
I am not too fond of this and, again, what are these 'size' for ?
If it's supposed to replace/duplicate ifreq, the 'settings' part should
be a pointer imho. Same reason as before: size change => compatibility
problems for tools (we have sources but downgrading tools when returning to
previous kernel sucks).
--
Ueimor
next prev parent reply other threads:[~2002-09-28 18:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-27 21:45 Generic HDLC interface continued Krzysztof Halasa
2002-09-28 18:21 ` Francois Romieu [this message]
2002-09-29 13:49 ` Krzysztof Halasa
2002-09-30 20:54 ` Francois Romieu
2002-09-30 23:48 ` Krzysztof Halasa
2002-10-01 18:01 ` Francois Romieu
2002-10-01 22:09 ` Krzysztof Halasa
2002-10-02 16:30 Kevin Curtis
2002-10-10 16:27 Pavel Selivanov
2002-10-10 19:08 ` Francois Romieu
2002-10-15 20:20 ` Krzysztof Halasa
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=20020928202138.A17244@se1.cogenit.fr \
--to=romieu@cogenit.fr \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jgarzik@mandrakesoft.com \
--cc=khc@pm.waw.pl \
--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;
as well as URLs for NNTP newsgroup(s).