netdev - refactoring cdc

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 for Android: free password hash cracker in your pocket

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

Date:	Sun, 28 Dec 2014 15:53:13 +0100 (CET)
From:	Enrico Mioso <mrkiko.rs@...il.com>
To:	Bjørn Mork <bjorn@...k.no>
cc:	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: refactoring cdc_ncm

Hello everyone, hello Bjorn.
Sorry for my prevous private mail, didn't think about it.

So I was wondering how it could be possible to refactor the cdc_ncm.c driver to 
queue frames and only when enough data was collected, generate a full NCM 
packet.

so I am trying to get clear what's the way to go.
My idea was to try to not change the layout of the code so much: I would like 
not breaking cdc_mbim.c and other code sharing some of these functions, so all 
of the work would be done in the cdc_ncm_fill_tx_frame function.

Before starting with code, I would like to organize ideas:
- when an SKB comes in, if the queue isn't empty, I would queue it
   Somethink like
   if (skb_queue_empty(ctx->skb_tx_queue)){
     skb_insert(skb);
   } else {
     ready2send=1;
   }
- at this point, performs some check to see if we have enough data:how can I do
   so? What should I check? Sizes of nth16 + ntb16 + ... ?

   - if not enough data is present, exit the function returning NULL
   else
   - invoke some functions to prepare the NCM packet

I plan to move / rewrite the needed code to isolate it completely from the 
queue logic: making it also a little bit more clear. I would like to have 
separate functions for any parts of the NCM packet construction.
This would allow better flexibility and probably less maintenance burden in the 
long run, and might open the road to extending the driver to support 32-bit NCM 
and different signness handling.

In the current code, we are carrying around the "sign" variable in the 
cdc_ncm_fill_tx_frame: why? Can different NCM packets have different sign 
settings?
Thank you guys, waiting for your replies,
Enrico
--
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