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]
Message-ID: <alpine.LNX.2.03.1412281540440.18200@gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ