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]
Date: Sat, 27 Apr 2024 16:27:17 +0000
From: Chris Wulff <Chris.Wulff@...mp.com>
To: Pavel Hofman <pavel.hofman@...tera.com>,
        "linux-usb@...r.kernel.org"
	<linux-usb@...r.kernel.org>
CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        James Gruber
	<jimmyjgruber@...il.com>, Lee Jones <lee@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>
Subject: Re: [PATCH v2] usb: gadget: f_uac2: Expose all string descriptors
 through configfs.

>From: Pavel Hofman <pavel.hofman@...tera.com>
>>>> +             p_it_name               playback input terminal name
>>>> +             p_ot_name               playback output terminal name
>>>> +             p_fu_name               playback function unit name
>>>> +             p_alt0_name             playback alt mode 0 name
>>>> +             p_alt1_name             playback alt mode 1 name
>>>
>>> Nacked-by: Pavel Hofman <pavel.hofman@...tera.com>
..
>If the params in the upper level were to stand as defaults for the
>altsettings (and for the existing altsetting 1 if no specific altset
>subdir configs were given), maybe the naming xxx_alt1_xxx could become a
>bit confusing. E.g. p_altx_name or p_alt_non0_name?

I've been prototyping this a bit to see how it will work. My current configfs
structure looks something like:

(all existing properties)
c_it_name
c_it_ch_name
c_fu_name
c_ot_name
p_it_name
p_it_ch_name
p_fu_name
p_ot_name
num_alt_modes (settable to 2..5 in my prototype)

alt.0
  c_alt_name
  p_alt_name
alt.1 (for alt.1, alt.2, etc.)
  c_alt_name
  p_alt_name
  c_ssize
  p_ssize
  (Additional properties here for other things that are settable for each alt mode,
   but the only one I've implemented in my prototype so far is sample size.)

This brings up a few questions:

Is a property for setting the number of alt modes preferred, or being able to
make directories like some other things (eg, "mkdir alt.5" would add alt mode 5)?
The former is what I started with, but I am leaning towards the latter as it is a bit
more flexible (you could create alt modes of any index, though I'm not entirely
sure why you'd want to.) It does involve a bit more dynamic memory allocation,
but nothing crazy.

And second, should the alt.x directories go back to the defaults if you remove
and re-create them? I'm assuming it makes sense to do that, just putting it out
there since my current prototype doesn't work that way.

I appreciate your thoughts on this.

  -- Chris Wulff

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ