lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <81C3A93C17462B4BBD7E272753C1057916954ED6B0@EXDCVYMBSTM005.EQ1STM.local> Date: Wed, 17 Mar 2010 12:04:11 +0100 From: Sjur BRENDELAND <sjur.brandeland@...ricsson.com> To: Marcel Holtmann <marcel@...tmann.org> Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "davem@...emloft.net" <davem@...emloft.net>, Daniel MARTENSSON <daniel.martensson@...ricsson.com>, "kaber@...sh.net" <kaber@...sh.net>, "stefano.babic@...ic.homelinux.org" <stefano.babic@...ic.homelinux.org>, "randy.dunlap@...cle.com" <randy.dunlap@...cle.com> Subject: RE: [PATCH net-next-2.6 v6 08/12] net-caif: add CAIF socket implementation Hi Marcel, >> >> + * The sock->type specifies the socket type to use. The CAIF >> >> socket is + * a packet stream in the sence that it is packet based. >> >> + * CAIF trusts the reliability of the link, no resending is >> >> implemented. + */ + if (sock->type != SOCK_SEQPACKET) >> >> + return -ESOCKTNOSUPPORT; >> > >> > we came to an interesting detail here when testing with a STE modem. >> > Why is this SEQPACKET and not a STREAM. >> >> The reason is that CAIF provides different services not just AT, >> and some of them are really packet oriented such as Utility links and >> Video. It would not be right to provide a stream based solution in this case. >> >> > Especially with the AT >> > command channels it is kinda weird that you have an MTU. The AT >> > specification doesn't really have any defined behavior when using a >> > sequential packet transport. It is more a stream based socket. >> >> Yes I see your point. In order to limit the effort and simplify >> caif_socket we ended up implementing only SEQPACKET. > >I think we need to split this. Use SEQPACKET for packet based services >and have STREAM for AT command channel. >So while this might cause internally some more code. It would take away >the complexity from userspace to turn it into a stream. And that is what >the userspace is expecting. Ok Marcel, I'll look into supporting both STREAM and SEQPACKET. BR/Sjur
Powered by blists - more mailing lists