From: kuznet@ms2.inr.ac.ru
Message-Id: <200112111919.WAA03827@ms2.inr.ac.ru>
Subject: Re: [RFC] cleaning up struct sock
To: davem@redhat.COM (David S. Miller)
Date: Tue, 11 Dec 2001 22:19:51 +0300 (MSK)
Cc: netdev@oss.sgi.com, acme@conectiva.COM.BR, steve@gw.CHygwyn.COM
In-Reply-To: <20011211.034755.74751257.davem@redhat.com> from "David S. Miller" at Dec 11, 1 05:49:15 pm
MIME-Version: 1.0
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Content-Length: 1020
Lines: 29

Hello!

>      a) struct inode
>      b) struct socket

(A bit out of topic) The last is just absent now, by the way.
The information inlined into private part of inode is wrong anyway
and causes lots of troubles, starting from problems with async
signaling and finishing with identd returning wrong answers
about socket owners.

If the plan of VFS is getting rid of private part, we just should
kill struct socket. If no such plans exist, we could return to the
question of ability to get/put inodes on softirqs and move some junk
from sock to inode.


>      c) struct sock (minus per protocol areas)
>      d) struct my_protocol (whatever the socket actually is)

... which is exactly current situation.

Listen, the situation is very clear really. Reality is TCP/IP.
The only thing which could justify getting rid of padding each socket
to tcp size would be a protocol, which has status different of marginal
ans requires massive allocations like tcp. I do not see any signs of this
on horizont. Do you see?

Alexey