Re: feature request - why not make netif_rx() a pointer?

Re: feature request - why not make netif_rx() a pointer?

[Jean Tourrilhes]

Slavcho Nikolov wrote :
> Non GPL modules that want to attach themselves between all L2 drivers and
> upper layers would not have to incur a performance loss if netif_rx() is
> made a
> pointer instead of a function (whether or not NET filters are compiled in
> the kernel).
> Currently control can be easily wrested from netif_rx() and others through
> injection of a few instructions into the running kernel (SMC - self
> modifying code)

	Assuming that every L2 is Ethernet and every L3 is IP ?
	Well, I've got news for you : IrDA drivers are using
netif_rx() to pass IrLAP frames to the IrDA stack, and 802.11 driver
in the future will pass 802.11 frames to the 802.2 LLC layer via
netif_rx().
	Please don't do that, I don't want people breaking the IrDA
stack in weird ways just because some random clueless code hijacked
netif_rx(). Use netfilters, or define your own private protocol/packet
type to do what you want.

	Regards,

	Jean

Re: feature request - why not make netif_rx() a pointer?

[Slavcho Nikolov]

Unfortunately, I cannot assume that every L2 (or maybe I can, we'll see) is
ethernet and I definitely cannot know in advance that every L3 is IP.
Nor can the assumption be made that netfilter has been built into the
kernel.
If I define my own private protocol handler (to catch all), I see cloned
skb's
which is not what I want. I tried that and dropped each one of them in the
handler, yet traffic continued to flow unimpeded (so I must have dropped
clones).
As for GPL, I hope that commercial enterprises be allowed to utilize
business models
which do not necessarily consist in providing services around free software.
The more replaceable hooks you provide to filesystems and network stacks,
the better.
S.N.


| Assuming that every L2 is Ethernet and every L3 is IP ?
| Well, I've got news for you : IrDA drivers are using
| netif_rx() to pass IrLAP frames to the IrDA stack, and 802.11 driver
| in the future will pass 802.11 frames to the 802.2 LLC layer via
| netif_rx().
| Please don't do that, I don't want people breaking the IrDA
| stack in weird ways just because some random clueless code hijacked
| netif_rx(). Use netfilters, or define your own private protocol/packet
| type to do what you want.

Re: feature request - why not make netif_rx() a pointer?

[Chris Friesen]

Slavcho Nikolov wrote:


> As for GPL, I hope that commercial enterprises be allowed to utilize
> business models
> which do not necessarily consist in providing services around free software.
> The more replaceable hooks you provide to filesystems and network stacks,
> the better.

I don't think you understand the nature of the GPL and linux development.

The kernel developers do not have any obligation to anything other than 
technical excellence.  You're getting a highly optimized operating 
system *at no financial cost*.  In return, the community requires that 
certain types of modifications be made publicly available.

If you want to replace the messaging code, make a GPL'd kernel patch and 
make it available to your clients (of course they can then publish it 
all over the place if they so desire).  If those terms are not 
acceptable, there's always BSD.

Chris



-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

over&out (Re: feature request - why not make netif_rx() a pointer?)

[Slavcho Nikolov]

Chris Friesen wrote
| I don't think you understand the nature of the GPL and linux development.

What a presumptuous opening statement!

| The kernel developers do not have any obligation to anything other than
| technical excellence.  You're getting a highly optimized operating
| system *at no financial cost*.  In return, the community requires that
| certain types of modifications be made publicly available.

Yes, many companies from time to time feed smaller or larger contributions
back into the community.
But they don't usually release *all* their modifications because they just
might be irrelevant to everyone but a small niche of enterprise users.

| If you want to replace the messaging code, make a GPL'd kernel patch and
| make it available to your clients (of course they can then publish it
| all over the place if they so desire).  If those terms are not
| acceptable, there's always BSD.

It doesn't quite work that way. Big name distributors (e.g. Suse, Redhat)
usually supply
and support big customers with Linux distributions. Third parties usually
supply modules.
Integration of the two is demanded by the customer, so it's not our choice
to
use BSD or ask the end users that our patches be applied and their kernels
recompiled.
Certainly patches can be rolled out but it's a costly proposition
(especially to customers)
and requires a level of expertise and commitment on the part of the
customers that
may not be available.

Nearly every storage or networking startup that uses Linux (hundreds of them
exist)
has tried to find hooks into the filesystems or network stacks, within the
constraints
of  modules and GPL. It isn't always easy to insert oneself where we want
but they have found interesting solutions and work-arounds whether or not on
the
legal grounds are shaky.
All I said was that it's good to make life easier for these startups.
S.N.

Re: feature request - why not make netif_rx() a pointer?

[Jean Tourrilhes]

On Wed, Oct 23, 2002 at 09:39:12AM -0400, Slavcho Nikolov wrote:
> Unfortunately, I cannot assume that every L2 (or maybe I can, we'll see) is
> ethernet and I definitely cannot know in advance that every L3 is IP.
> Nor can the assumption be made that netfilter has been built into the
> kernel.

	So, you thing assuming a modified netif_rx is different than
assuming netfilter support ?
	Your idea is just too dangerous.

> If I define my own private protocol handler (to catch all), I see cloned
> skb's
> which is not what I want. I tried that and dropped each one of them in the
> handler, yet traffic continued to flow unimpeded (so I must have dropped
> clones).

	For this to work, you need to modify the driver. The driver
generates a private packet type or protocol, and you will be the only
to to catch it.

> As for GPL, I hope that commercial enterprises be allowed to utilize
> business models
> which do not necessarily consist in providing services around free software.
> The more replaceable hooks you provide to filesystems and network stacks,
> the better.

	You can still use *BSD, Windows, VxWorks or else, which are
very capable OSes. Nobody forces you to use Linux.

> S.N.

	Jean

Re: feature request - why not make netif_rx() a pointer?

[Ben Greear]

Jean Tourrilhes wrote:
> On Wed, Oct 23, 2002 at 09:39:12AM -0400, Slavcho Nikolov wrote:
> 
>>Unfortunately, I cannot assume that every L2 (or maybe I can, we'll see) is
>>ethernet and I definitely cannot know in advance that every L3 is IP.
>>Nor can the assumption be made that netfilter has been built into the
>>kernel.
> 
> 
> 	So, you thing assuming a modified netif_rx is different than
> assuming netfilter support ?
> 	Your idea is just too dangerous.

If you added something like this to netif_rx, I think it would accomplish
the goals of those who want to add their own hooks.  It would probably not
please the folks who want to keep this code out for GPL/political/legal/moral
reasons.

Note that the hook basically exists already in the bridging code.  It may
be illegal for GPL reasons to assign your own method to this hook, but I'm
sure you could put up a good legal fight if you wanted to (the bridge hook
is not exported GPL)

int netif_rx(struct sk_buff *skb)
{
	int this_cpu = smp_processor_id();
	struct softnet_data *queue;
	unsigned long flags;

+#idfef EVIL_COMPANY_NETWORK_HOOK_HACK
+       if (evil_hook) {
+          int rv = evil_hook(skb);
+          if (rv) { return; /* skb was consumed by evil hook, gawd help us all */ }
+        }
+#endif

	if (skb->stamp.tv_sec == 0)
		do_gettimeofday(&skb->stamp);


> 
> 
>>If I define my own private protocol handler (to catch all), I see cloned
>>skb's
>>which is not what I want. I tried that and dropped each one of them in the
>>handler, yet traffic continued to flow unimpeded (so I must have dropped
>>clones).
> 
> 
> 	For this to work, you need to modify the driver. The driver
> generates a private packet type or protocol, and you will be the only
> to to catch it.

So, it would be ok to modify the driver to call a new hook, one that
may be over-written by proprietary code?  Otherwise, you have to write
a non-gpl driver....yuck!


Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: over&out (Re: feature request - why not make netif_rx() a pointer?)

[jw schultz]

On Wed, Oct 23, 2002 at 12:23:03PM -0400, Slavcho Nikolov wrote:
> Chris Friesen wrote
> | I don't think you understand the nature of the GPL and linux development.
> 
> What a presumptuous opening statement!

It is a statement of opinion based on proximate evidence and
was phrased as such.  Only a statement of fact not in
evidence could have been presumptuous.  You could persuade
us that he is wrong by showing us your applicable
understanding.

> | The kernel developers do not have any obligation to anything other than
> | technical excellence.  You're getting a highly optimized operating
> | system *at no financial cost*.  In return, the community requires that
> | certain types of modifications be made publicly available.
> 
> Yes, many companies from time to time feed smaller or larger contributions
> back into the community.
> But they don't usually release *all* their modifications because they just
> might be irrelevant to everyone but a small niche of enterprise users.

That is obviously untrue or a complete misunderstanding.

Even the tiniest, most specialized patch is more relevant
than a spelling error in a comment or some crook from
Nigeria asking for access to our bank accounts.  If the
patches are really irrelevant then it won't matter to you if
they are publicly available.  Maybe they won't seem so
irrelevant to someone else.

There would be little objection to their posting these
irrelevant modifications here.  The GPL only requires that
they be made available.  Stick them somewhere on your web
site with an obscure link pointing to them.

Irrelevance is no reason not to share patches.  Shamefully
bad code i can see not sharing, but such bad code shouldn't
be in a commercial offering.  The only reason not to share
commercially viable patches is the same reason the Linux
kernel is GPL.

Pay the price (free code) or shop somewhere else.  With GPL
that is _your_ choice.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: feature request - why not make netif_rx() a pointer?

[David S. Miller]

On Wed, 2002-10-23 at 06:39, Slavcho Nikolov wrote:
> As for GPL, I hope that commercial enterprises be allowed to utilize
> business models
> which do not necessarily consist in providing services around free software.
> The more replaceable hooks you provide to filesystems and network stacks,
> the better.

While more hooks may be in your interest, they are not in the interest
of free software.

I really hope you have competant legal advice for the things you are
doing, because binary-only derivative works of a GPL work are illegal.

Re: over&out (Re: feature request - why not make netif_rx() a pointer?)

[Gilad Ben-Yossef]

On Thu, 2002-10-24 at 00:59, jw schultz wrote:

> There would be little objection to their posting these
> irrelevant modifications here.  The GPL only requires that
> they be made available.  Stick them somewhere on your web
> site with an obscure link pointing to them.

<nitpick>

IANAL but AFAIK the GPL V2 requires you to either distribute the
source/patch together with the binary or include a *written* obligation
valid for three years to supply the sources to any thrid party.

So, for example, if you disribute the binary on a CD, or some embedded
device, sticking the patch somewhere on your web site with an obscure
link pointing to them is technicaly a violation of the GPL.

But as I said, this is just nitpicking... :-)

</nitpick>

-- 
Gilad Ben-Yossef <gilad@benyossef.com>
http://benyossef.com

 "Geeks rock bands cool name #8192: RAID against the machine"

Re: over&out (Re: feature request - why not make netif_rx() a pointer?)

[Ben Greear]

Gilad Ben-Yossef wrote:

> IANAL but AFAIK the GPL V2 requires you to either distribute the
> source/patch together with the binary or include a *written* obligation
> valid for three years to supply the sources to any thrid party.
> 
> So, for example, if you disribute the binary on a CD, or some embedded
> device, sticking the patch somewhere on your web site with an obscure
> link pointing to them is technicaly a violation of the GPL.

You could hide the source in the documentation, no one ever reads that ;)

Ben

-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: feature request - why not make netif_rx() a pointer?

[Henning P. Schmiedehausen]

"David S. Miller" <davem@rth.ninka.net> writes:

>I really hope you have competant legal advice for the things you are
>doing, because binary-only derivative works of a GPL work are illegal.

No. Distributing work based on GPL code binary-only without supplying
the source and the modifications is (might be? is considered?)
illegal. This is a major difference. 

Else I'd have to delete some of the kernels running here, because I
lost the sources for these. :-) (They're still running happily).

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: feature request - why not make netif_rx() a pointer?

[David S. Miller]

On Thu, 2002-10-24 at 02:28, Henning P. Schmiedehausen wrote:
> Distributing work based on GPL code binary-only without supplying
> the source and the modifications is (might be? is considered?)
> illegal. This is a major difference. 

That's what I meant.

Obviouslly this guy is intending to distribute his work though :)

Re: feature request - why not make netif_rx() a pointer?

[Henning Schmiedehausen]

On Thu, 2002-10-24 at 12:15, David S. Miller wrote:
> On Thu, 2002-10-24 at 02:28, Henning P. Schmiedehausen wrote:
> > Distributing work based on GPL code binary-only without supplying
> > the source and the modifications is (might be? is considered?)
> > illegal. This is a major difference. 
> 
> That's what I meant.
> 
> Obviouslly this guy is intending to distribute his work though :)

Fine, then we're in violent agreement. :-)

	Regards
		Henning


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: feature request - why not make netif_rx() a pointer?

[Slavcho Nikolov]

David Miller wrote
 
| While more hooks may be in your interest, they are not in the interest
| of free software.
| 
| I really hope you have competant legal advice for the things you are
| doing, because binary-only derivative works of a GPL work are illegal.


Thanks for the heads-up. What I propose to do is NOT to re-implement
some existing linux routine by reusing all or some of its code.
That is not only illegal, it's immoral.
In other words, the new routine will not be a derivative of the old one
or some other part of the kernel.
Instead, I'll create my own (cleanroom) handler that doesn't reuse any
existing code, which in the end will either pass control to the GPL routine
being replaced or destroy the parameters and return.
I can't see how that is a violation of GPL. If it is, then hundreds of
Linux startups had better go bankrupt now instead of fighting losing 
legal battles later.
S.N.

Re: feature request - why not make netif_rx() a pointer?

[David S. Miller]

On Thu, 2002-10-24 at 06:30, Slavcho Nikolov wrote:
> In other words, the new routine will not be a derivative of the old one
> or some other part of the kernel.
> Instead, I'll create my own (cleanroom) handler that doesn't reuse any
> existing code, which in the end will either pass control to the GPL routine
> being replaced or destroy the parameters and return.
> I can't see how that is a violation of GPL. If it is, then hundreds of
> Linux startups had better go bankrupt now instead of fighting losing 
> legal battles later.

Let me give you an example of what would be illegal.

Using this netif_rx() hook to implement a proprietary TCP stack
to replace the GPL'd one in the kernel right now.  And that is exactly
the reason I want any such netif_rx  function pointer crap to be
EXPORT_GPL

And before someone, I forget who it was, barks again, EXPORT_GPL has
no legal significance, it is merely an annotation.  Whether a symbol
is marked this way or not has no consequence on legal matters.

Re: over&out (Re: feature request - why not make netif_rx() a pointer?)

[Adrian Bunk]

On Wed, 23 Oct 2002, Slavcho Nikolov wrote:

>...
> Yes, many companies from time to time feed smaller or larger contributions
> back into the community.
> But they don't usually release *all* their modifications because they just
> might be irrelevant to everyone but a small niche of enterprise users.

It might be that a modification isn't of big interest for the majority of
users but:
- It might be interesting for people working in similar niches.
- E.g. several development boards are supported in the MIPS port in the
  standard Linux kernel. The niche of people using them isn't very big but
  this doesn't prevent the inclusion into the main kernel.

> | If you want to replace the messaging code, make a GPL'd kernel patch and
> | make it available to your clients (of course they can then publish it
> | all over the place if they so desire).  If those terms are not
> | acceptable, there's always BSD.
>
> It doesn't quite work that way. Big name distributors (e.g. Suse, Redhat)
> usually supply
> and support big customers with Linux distributions. Third parties usually
> supply modules.
> Integration of the two is demanded by the customer, so it's not our choice
> to
> use BSD or ask the end users that our patches be applied and their kernels
> recompiled.
> Certainly patches can be rolled out but it's a costly proposition
> (especially to customers)
> and requires a level of expertise and commitment on the part of the
> customers that
> may not be available.

But this doesn't prevent you from releasing the source code of your module
under the terms of the GPL.

> Nearly every storage or networking startup that uses Linux (hundreds of them
> exist)
> has tried to find hooks into the filesystems or network stacks, within the
> constraints
> of  modules and GPL. It isn't always easy to insert oneself where we want
> but they have found interesting solutions and work-arounds whether or not on
> the
> legal grounds are shaky.

The legal grounds become more shaky as soon as you consider that court
decisions might be different in different countries. If someone wants to
sue you he might have the possibility to choose between different
countries where he wants to sue you...  8)

> All I said was that it's good to make life easier for these startups.
> S.N.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: feature request - why not make netif_rx() a pointer?

[Henning P. Schmiedehausen]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

>> Not putting an export into the source or exporting GPL_ONLY symbols
>> won't hinder anyone. Because putting the hooks into a GPL source and
>> then releasing the result (code + hooks) under GPL is perfectly legal.

>Not according to lawyers

"The kernel source code + hooks under GPL" definitely are.

"The kernel source code + hooks + binary modules" are doubtful, correct.

Sorry, my wording wasn't clear.

	Regards
		Henning


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: feature request - why not make netif_rx() a pointer?

[Alan Cox]

On Wed, 2002-10-23 at 16:16, Henning P. Schmiedehausen wrote:
> You will never understand, that <insert evil vendor here> can simply
> add this modification to the kernel source ("vendor tree"), give this
> source away under GPL license and then ship its binary kernel modules
> with the source tree.

Thats what lawyers are for. 

> Not putting an export into the source or exporting GPL_ONLY symbols
> won't hinder anyone. Because putting the hooks into a GPL source and
> then releasing the result (code + hooks) under GPL is perfectly legal.

Not according to lawyers

Re: feature request - why not make netif_rx() a pointer?

[Henning P. Schmiedehausen]

"David S. Miller" <davem@rth.ninka.net> writes:

>On Tue, 2002-10-22 at 14:15, Matti Aarnio wrote:
>>   ftp://zmailer.org/linux/netif_rx.patch

>Please EXPORT_GPL this, if you are going to do it at all.

>Only non-GPL compliant binary-modules can result from this
>change.

>People can easily do things like implement their own entire
>networking stack with this hook, which is not what we want nor
>is it allowed.

You will never understand, that <insert evil vendor here> can simply
add this modification to the kernel source ("vendor tree"), give this
source away under GPL license and then ship its binary kernel modules
with the source tree.

You won't be able to stop anyone doing this "illegal" thing. But you
hinder many legal users of this.

Not putting an export into the source or exporting GPL_ONLY symbols
won't hinder anyone. Because putting the hooks into a GPL source and
then releasing the result (code + hooks) under GPL is perfectly legal.

The only result are questions on this list, why the <insert your video
card / network / hw driver here> module works under "foobar" Linux and
not with the pristine sources.

Ah and lots of patches like "please put this into the kernel so I can
use the <insert your video card / network / hw driver here> module.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: feature request - why not make netif_rx() a pointer?

[Jeff Garzik]

David S. Miller wrote:
> On Tue, 2002-10-22 at 14:15, Matti Aarnio wrote:
> 
>>  ftp://zmailer.org/linux/netif_rx.patch
> 
> 
> Please EXPORT_GPL this, if you are going to do it at all.



ug :(   Can we please have this not be in the fast path.  Thanks.

Make netif_rx_ the pointer, don't slow down my net drivers further...

	Jeff

Re: feature request - why not make netif_rx() a pointer?

[Ben Greear]

David S. Miller wrote:
> On Tue, 2002-10-22 at 14:15, Matti Aarnio wrote:
> 
>>  ftp://zmailer.org/linux/netif_rx.patch
> 
> 
> Please EXPORT_GPL this, if you are going to do it at all.
> 
> Only non-GPL compliant binary-modules can result from this
> change.
> 
> People can easily do things like implement their own entire
> networking stack with this hook, which is not what we want nor
> is it allowed.

Don't assume we all want what you want.

As for allowed, it can
be worked around fairly easily by removing all protocol handlers and
then registering only yourself as the proprietary protocol handler,
and gobble all packets.  Sure, it's a bit of a kludge, and will have
the various crufts (like the gettimeofday code) in there, but it
will basically allow you to replace the entire stack.

If I'm right about that, then what is the difference between replacing
the stack like that and replacing the netif_rx method entirely?

Ben


> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: feature request - why not make netif_rx() a pointer?

[David S. Miller]

On Tue, 2002-10-22 at 14:15, Matti Aarnio wrote:
>   ftp://zmailer.org/linux/netif_rx.patch

Please EXPORT_GPL this, if you are going to do it at all.

Only non-GPL compliant binary-modules can result from this
change.

People can easily do things like implement their own entire
networking stack with this hook, which is not what we want nor
is it allowed.

Re: feature request - why not make netif_rx() a pointer?

[David S. Miller]

On Tue, 2002-10-22 at 14:01, Slavcho Nikolov wrote:
> Non GPL modules that want to attach themselves between all L2 drivers and
> upper layers would not have to incur a performance loss if netif_rx() is
> made a

What you are suggesting can only result in illegal binary-only
modules.

If you override netif_rx(), you are by definition implementing a derived
work of the kernel reimplementing core functionality, thus your binary
only driver is not abiding by the GPL and you are on very shaky legal
ground.

It isn't exported for a reason, there is legitimate use of it from
modules.

Re: feature request - why not make netif_rx() a pointer?

[Alan Cox]

On Tue, 2002-10-22 at 22:01, Slavcho Nikolov wrote:
> Non GPL modules that want to attach themselves between all L2 drivers and
> upper layers would not have to incur a performance loss if netif_rx() is

You could of course write GPL code 8)

Re: feature request - why not make netif_rx() a pointer?

[Matti Aarnio]

On Tue, Oct 22, 2002 at 05:01:53PM -0400, Slavcho Nikolov wrote:
> Non GPL modules that want to attach themselves between all L2 drivers and
> upper layers would not have to incur a performance loss if netif_rx() is
> made a pointer instead of a function (whether or not NET filters are
> compiled in the kernel).
> Currently control can be easily wrested from netif_rx() and others through
> injection of a few instructions into the running kernel (SMC - self
> modifying code) but decreased performance is one sad consequence.
> Architecture specific maintenance of SMC slows down portability,
> too.
> The following suggestion would lead to the least amount of modifications.

  ftp://zmailer.org/linux/netif_rx.patch

  Done for 2.3.99-pre7-3  but should be easy to port to 2.5.x ...

> S.N.

/Matti Aarnio

feature request - why not make netif_rx() a pointer?

[Slavcho Nikolov]

Non GPL modules that want to attach themselves between all L2 drivers and
upper layers would not have to incur a performance loss if netif_rx() is
made a
pointer instead of a function (whether or not NET filters are compiled in
the kernel).
Currently control can be easily wrested from netif_rx() and others through
injection of a few instructions into the running kernel (SMC - self
modifying code)
but decreased performance is one sad consequence. Architecture specific
maintenance of SMC slows down portability, too.
The following suggestion would lead to the least amount of modifications.

The global variable "int (*netif_rx)(struct sk_buff *) = &default_netif_rx;"
gets initialized to the address of a function whose body is the default
implementation.
Drivers calling netif_rx explicitly need to be able to see the prototype
"extern int (*netif_rx)(struct sk_buff *);" or else blow up.
No further changes would be necessary because the current 200+ explicit
references
to "netif_rx(skb);"  become a poorly written "(*netif_rx)(skb);" call.
S.N.