From: Krzysztof Halasa <khc@pm.waw.pl>
To: <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] HDLC patch for 2.5.5 (0/3)
Date: 19 Feb 2002 12:02:08 +0100 [thread overview]
Message-ID: <m34rkdohu7.fsf@defiant.pm.waw.pl> (raw)
In-Reply-To: <20020217193005.B14629@se1.cogenit.fr> <m3zo27outs.fsf@defiant.pm.waw.pl> <20020218143448.B7530@fafner.intra.cogenit.fr>
In-Reply-To: <20020218143448.B7530@fafner.intra.cogenit.fr>
Francois Romieu <romieu@cogenit.fr> writes:
> I agree there's a way for an application to cause binary incompatibility if
> it does:
>
> struct userspace_foo {
> struct if_settings frob;
> int nitz;
> } bar;
>
> If size of struct if_settings changes (increases OR decreases), access to
> bar.nitz doesn't work as expected.
I assumed it's union and not a struct, you're right.
> But:
> in hdlc_xxx_ioctl, only knowledge of the protocol-related member of the
> union
> hdlcs_hdlcu is required. Nowhere does the code depend on size of if_settings.
I see now, t seems I haven't read the patches carefully enough.
Now... You just want to introduce an artificial struct which contains
only the union... Why? We could use just the union instead (?).
struct hdlc_settings {
union {
/* sync_serial_settings removed */
raw_hdlc_proto raw_hdlc;
cisco_proto cisco;
fr_proto fr;
fr_proto_pvc fr_pvc;
te1_settings te1;
} hdlcs_hdlcu;
};
Still, te1_settings are interface-related :-) Ok, I assume it goes
to the following:
> include/linux/whatever/ioctl.h:
> [...]
> struct whatever_settings {
> union {
> /* sync_serial_settings is back */
> sync_serial_settings sync;
> fancy_settings fancy;
> }
> };
>
> include/linux/if.h:
> [...]
> struct if_settings
> {
> unsigned int type; /* Type of physical device or protocol */
> union {
> struct hdlc_settings ifsu_hdlc;
> struct whatever_settings ifsu_whatever;
> } ifs_ifsu;
> };
>
> As long as the application only accesses its data and doesn't try to embed
> the variable sized kernel structure into its own, it won't break here either.
Yes, the compiler would compile that. Anyway, don't you think it's
a little messy? Void * pointers are IMHO not that evil.
Not sure about that, I have to think on it...
--
Krzysztof Halasa
Network Administrator
next prev parent reply other threads:[~2002-02-20 7:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-17 18:30 [PATCH] HDLC patch for 2.5.5 (0/3) Francois Romieu
2002-02-17 23:22 ` Jeff Garzik
2002-02-20 1:32 ` Linus Torvalds
2002-02-20 12:15 ` Jeff Garzik
2002-02-21 23:52 ` Krzysztof Halasa
2002-02-22 0:57 ` Jeff Garzik
2002-02-18 12:09 ` Krzysztof Halasa
2002-02-18 13:34 ` Francois Romieu
2002-02-19 11:02 ` Krzysztof Halasa [this message]
2002-02-20 13:39 ` Francois Romieu
2002-02-20 13:51 ` Jeff Garzik
2002-02-20 23:15 ` [PATCH] HDLC patch for 2.5.5 (updated) Francois Romieu
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=m34rkdohu7.fsf@defiant.pm.waw.pl \
--to=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