[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <61D8D34BB13CFE408D154529C120E0790323209A@eseldmw101.eemea.ericsson.se>
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
Powered by blists - more mailing lists