netdev - RE: [PATCH net-next-2.6 03/13] net-caif: add CAIF generic protocol stack header files

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 22 Jan 2010 11:12:04 +0100
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Sjur Brændeland 
	<sjur.brandeland@...ricsson.com>
Cc:	netdev@...r.kernel.org, davem@...emloft.net,
	stefano.babic@...ic.homelinux.org, randy.dunlap@...cle.com
Subject: RE: [PATCH net-next-2.6 03/13] net-caif: add CAIF generic protocol
 stack header files

Hi Sjur,

> >> Add include files for the generic CAIF protocol stack. This layer is
> >> somewhat generic in order to be able to use and test it outside the
> >> Linux Kernel.
> >> 
> >> caif_layer.h - Defines the structure of the CAIF protocol layers
> >> cfcnfg.h     - CAIF Configuration Module for services and link layers
> >> cfctrl.h     - CAIF Control Protocol Layer
> >> cffrml.h     - CAIF Framing Layer
> >> cfglue.h     - CAIF Glue Layer for allocation, logging etc
> >> cflist.h     - CAIF List implementation
> >> cfmuxl.h     - CAIF Muxing Layer
> >> cfpkt.h	     - CAIF Packet layer (skb helper functions)
> >> cfserl.h     - CAIF Serial Layer
> >> cfsrvl.h     - CAIF Service Layer
> > 
> > is it really needed to keep the "generic" piece in the path here. I
> > would prefer if we get rid of it. 
> 
> Are you suggesting to move this files to include/net/caif? 
> I can do this in the next patch set.
> The reason for the term "generic" is that this that the core part of the CAIF
> stack originally was designed to be OS independent. 

I understand where you are coming from, but for the Linux implementation
it doesn't really sound like a good idea. Especially with the move to a
socket based implementation you really diverge here already.

Also the cfglue.[ch] pieces are really controversial. I would prefer not
to have OS glue code here. Just use native lists, locks etc. It makes
the code a lot easier to review for all the Linux people ;)

Regards

Marcel


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html