From: "Lv Zheng" <lv.zheng@soliton.com.cn>
To: <netdev@vger.kernel.org>
Subject: socket layer incorrectness
Date: Mon, 1 Feb 2010 13:05:45 +0800 [thread overview]
Message-ID: <1C8BCB3F488645A99B76E803ED3BD094@lzheng> (raw)
Hi, all
I'm new to this mailing list. Please forgive me if this mail is
interrupting you.
I read the kernel socket layer implementation recently.
Wondering whether one can kindly make some detailed explaination
for me, I sent this email to the netdev mailing list.
==================================================
I noted BSD had presented socket API as follows:
socket(family, type, protocol)
Which means there should be sth. like:
sock_register_family
sock_register_type
sock_register_protocol
in the world.
As far as these abstractions are concerned, struct sock should be:
struct sock {
struct family_ops *family_ops;
struct sock_type_ops *type_ops;
struct proto_ops *proto_ops;
};
==================================================
A. family abstaction
For family, I think it looks like a protocol factory, and owns
create/release ops might be enough for family_ops just like current
kernel does.
B. type abstaction
For type, we have SOCK_STREAM, SOCK_DGRAM, SOCK_RAW
for INET:
1. SOCK_STREAM: buffer requeued orderly for the upper level
protocol layer without lower level protocol's head/tail.
2. SOCK_DGRAM: buffer defrag/fraged aligning lower level
protocol's content due to lower level's MTU without lower level
protocol's head/tail.
3. SOCK_RAW: buffer is copied directly from lower level queue.
If socket is implemented in this way, defrag/frag/streaming can go
into the socket layer and we can involve hardware as much as it
could to accelarate fragmentation and streaming.
But currently we do not have type abstraction in the Linux kernel.
C. protocol abstaction
For protocol, we have proto_register in the kernel, but it does not
affect sock_create. In the socket layer, only /proc/net/protocols is
affected by such registration, proto_ops is mostly a family specific
implementation.
proto_ops should not related to the socket operations which should
be type_ops' responsibility while current kernel takes proto_ops as
type_ops.
IMO, proto_ops should contain operations as head/tail analysis,
buffer ordering determination and so on.
==================================================
Can someone tell me why current Linux kernel is not implemented in
the way that BSD socket abstraction tells us to do?
Best regards/Lv Zheng
reply other threads:[~2010-02-01 5:17 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1C8BCB3F488645A99B76E803ED3BD094@lzheng \
--to=lv.zheng@soliton.com.cn \
--cc=netdev@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