public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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