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:16:04 +0100
From:	Sjur Brændeland <sjur.brandeland@...ricsson.com>
To:	"Marcel Holtmann" <marcel@...tmann.org>
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 Marcel.

Marcel Holtmann wrote:
> 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 ;)  
> 

Yes, I was kind of expecting this feedback. The problem is that I have
to ditch more than 50 unit tests that I have in user space. They are 
very handy when debugging protocol problems. 

BR/Sjur
--
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