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]

Message-ID: <1264155893.3469.46.camel@violet>
Date:	Fri, 22 Jan 2010 11:24:53 +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 ;)  
> > 
> 
> 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. 

what about having a script for that. Something that takes the "clean"
kernel code. Does some sed etc. magic and still lets you run your unit
tests in userspace.

Or what a about a kernel module that does these unit tests in kernel
space. I really don't know how feasible this is, but think about it.

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