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  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:24:53 +0100
From:	Marcel Holtmann <>
To:	Sjur Brændeland 
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.



To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists