netdev
[Top] [All Lists]

Re: ipt_physdev.c alignment problems on parisc64

To: Bart De Schuymer <bdschuym@xxxxxxxxxx>
Subject: Re: ipt_physdev.c alignment problems on parisc64
From: "David S. Miller" <davem@xxxxxxxxxx>
Date: Mon, 15 Sep 2003 23:02:59 -0700
Cc: laforge@xxxxxxxxxxxxx, acme@xxxxxxxxxxxxxxxx, netfilter-devel@xxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <200309160805.08171.bdschuym@xxxxxxxxxx>
References: <200309022116.41697.bdschuym@xxxxxxxxxx> <200309132159.37834.bdschuym@xxxxxxxxxx> <20030915155903.12a3f95d.davem@xxxxxxxxxx> <200309160805.08171.bdschuym@xxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Tue, 16 Sep 2003 08:05:07 +0200
Bart De Schuymer <bdschuym@xxxxxxxxxx> wrote:

> Anyway, this rule about not changing structs exported to userspace truly 
> sucks, IMHO.

Welcome to the real world.

> If someone decides to compile her own kernel this person should 
> not expect every userspace tool to keep working, again IMHO.

Wouldn't it be great if you recompiled you kernel and the args
to the read() system call got rearranged?

There is simply no difference in this case.  The situation doesn't
change because the object is being passed into some netfilter module.

You can't arbitrarily change userland exported APIs at your convenience
to fix some bug.  You either have to create a new interface for the user
to use, or fix the bug without changing the API.

Will it be the end of the world if you do a byte at a time comparison,
at least as a temporary solution?

Also, another solution could be to store the object inside the kernel
using a different structure, one where you can guarentee the alignment
of these things properly.

<Prev in Thread] Current Thread [Next in Thread>