Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Jan 10, 2017 07:51, "Greg KH"  wrote:

On Mon, Jan 09, 2017 at 01:32:40PM -0800, Reilly Grant wrote:
> On 2017-01-09 9:55 am, Greg KH wrote:
> > On Mon, Jan 09, 2017 at 06:13:04PM +0100, Bjørn Mork wrote:
> > > Greg KH  writes:
> > > > On Mon, Jan 09, 2017 at 09:40:59AM +, Kenneth Rohde
Christiansen wrote:
> > > >> Web USB can only grab devices which has special Web USB headers.
It can not
> > > >> grab any USB device.
> > > >>
> > > >> https://wicg.github.io/webusb/#webusb-descriptors
> > > >
> > > > Ah, fun :(
> > > >
> > > > So, we can add a quirk into the kernel cdc-acm driver to never bind
to a
> > > > device that has the wusb platform capability descriptor,
> > >
> > > I fail to see why a quirk should be necessary. New device classes are
> > > expected to use new class/subclass codes distintly different from
> > > anything handled by existing class drivers.
> >
> > One would hope, but it seems like they want to piggy-back on the cdc-acm
> > spec.  But I could be totally wrong here, does anyone have the actual
> > descriptor dump of a device anywhere?
>
> We don't want to piggy-back on the CDC-ACM spec. A WebUSB device should
> always have its interfaces marked vendor-specific. Below is an example of
a
> device which implements both a CDC-ACM interface and a WebUSB interface.

Ick, why would you want both interfaces on a device?  Are you going to
allow firmware to talk to both endpoints at the same time?  Why?

Why not just make it a "one interface" type of device?

I work for a medical company, where we are using long lived software and
hardware. Having the option of supporting both WebUSB and USB serial will
allow us to move to pure web and still support legacy platforms.

If we - in stead - were to only have WebUSB or standard CDC, we would force
an impossible break.

Having modemmanager estimating that "this WebUSB device is *probably* not a
modem" and furthermore allowing user access to that device (udev/systems)
would be a huge help in the direction of true PnP for users and
manufacturers.

Yesterday night I finally got WebUSB and MM running in parallel (so..Sorta
halfway there on Linux at least):
https://twitter.com/denladeside/status/818717316443676672


thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Greg KH]

On Mon, Jan 09, 2017 at 01:32:40PM -0800, Reilly Grant wrote:
> On 2017-01-09 9:55 am, Greg KH wrote:
> > On Mon, Jan 09, 2017 at 06:13:04PM +0100, Bjørn Mork wrote:
> > > Greg KH  writes:
> > > > On Mon, Jan 09, 2017 at 09:40:59AM +, Kenneth Rohde Christiansen 
> > > > wrote:
> > > >> Web USB can only grab devices which has special Web USB headers. It 
> > > >> can not
> > > >> grab any USB device.
> > > >>
> > > >> https://wicg.github.io/webusb/#webusb-descriptors
> > > >
> > > > Ah, fun :(
> > > >
> > > > So, we can add a quirk into the kernel cdc-acm driver to never bind to a
> > > > device that has the wusb platform capability descriptor,
> > > 
> > > I fail to see why a quirk should be necessary. New device classes are
> > > expected to use new class/subclass codes distintly different from
> > > anything handled by existing class drivers.
> > 
> > One would hope, but it seems like they want to piggy-back on the cdc-acm
> > spec.  But I could be totally wrong here, does anyone have the actual
> > descriptor dump of a device anywhere?
> 
> We don't want to piggy-back on the CDC-ACM spec. A WebUSB device should
> always have its interfaces marked vendor-specific. Below is an example of a
> device which implements both a CDC-ACM interface and a WebUSB interface.

Ick, why would you want both interfaces on a device?  Are you going to
allow firmware to talk to both endpoints at the same time?  Why?

Why not just make it a "one interface" type of device?

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Cannot restart service when StandardInput=tty-force (or tty)

[Tom Vaughan]

Hi,

I don't even pretend to understand this one. Let's say I have a
service that looks like:

[Unit]
Description=nginx
After=docker.service
Requires=docker.service

[Service]
StandardInput=tty-force
ExecStart=/usr/bin/docker run --name %p nginx
ExecStop=/usr/bin/docker stop %p
ExecStopPost=/usr/bin/docker rm %p

[Install]
WantedBy=multi-user.target

I cannot reliably restart this when StandardInput=tty-force (or tty).
Sometimes the stop operations timeout, and sometimes the start
operations time out. At the very least the stop and start operations
take orders of magnitude longer to complete. Everything works as
expected with this commented out. Why and what can I do to work around
this problem?

This is with Ubuntu 16.04 with systemd 229 and CoreOS 1284.0.0 and
systemd 231. There's nothing helpful in `journalctl -u nginx.service`
or `systemctl status nginx.service`. The docker server logs are also
unhelpful. A google search didn't turn up any answers. There was one
similar problem where the solution was to add `KillMode=process` to
docker.service, but this has already been set on each of these two
machines.

This is just an example. I understand that nginx doesn't require a
tty, but the application that I really want to run does.

Thanks,
-Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Tue, Jan 10, 2017 at 12:47 AM, Lars Knudsen  wrote:

> A small update:  When the modemmanager finishes probing (~16 secs after
> connection) data seems to stop flowing in from the WebUSB bulk endpoint
> also.  It is, however, possible to reconnect and get data again - so I need
> to see if there should be anything in the mbed firmware causing that
> behavior or there is some sort of silent reset of interfaces/endpoints
> happening on the linux side when probing is done.
>
Had to separate the CDC and WebUSB serial control signals completely in the
firmware driver. - now survives

>
> On Tue, Jan 10, 2017 at 12:11 AM, Lars Knudsen  wrote:
>
>> I finally managed to make a configuration that *seems* to work and I
>> realize that I may have had something else blocking the WebUSB interface
>> (2) while modemmanager was communicating with the CDC_ACM interface (1).
>>
>> I made a clean arbitrary VID/PID and get what seems to be a functioning
>> WebUSB (now) while modemmanager sends "AT...AT..." to the CDC interface -
>> so while I thought the modemmanager grabbed my WebUSB interface part, it
>> must have been because of a faulty combination on my side - my apologies.
>> WebUSB actually *does* seem to give immediate "bulk" access to a device
>> otherwise claimed by modemmanager - a very nice option to have and sorry
>> for the confusion I had that modemmanager grabbed more interfaces than it
>> should have.
>>
>> Still, the original request still stands and please tell me if it's a
>> viable path:
>>
>> 1.  If a device has a WebUSB descriptor, it's most probably *not* a modem
>> - and should in stead be considered a device that in this rare case needs
>> to be whitelisted (as modem), while defaulting to not being it.  This is to
>> ease the usage from non-browsers to the same hardware, which can then
>> happen immediately and not be required to fail and wait over the
>> modemmanager probing period (30 sec?) - related to modemmanager
>> 2. If a device has a WebUSB descriptor, at least the interface linked to
>> WebUSB should be made accessible in user land by default so no average user
>> has to figure out how to do udev rules - related to udev/systemd
>>
>> my headers that seem to work now for the case above:
>>
>> Bus 002 Device 089: ID 1209:d010 InterBiometrics
>> Device Descriptor:
>>   bLength18
>>   bDescriptorType 1
>>   bcdUSB   2.10
>>   bDeviceClass0 (Defined at Interface level)
>>   bDeviceSubClass 0
>>   bDeviceProtocol 0
>>   bMaxPacketSize064
>>   idVendor   0x1209 InterBiometrics
>>   idProduct  0xd010
>>   bcdDevice0.01
>>   iManufacturer   1 empriKit
>>   iProduct2 empriKit|MOTION
>>   iSerial 3 00.01
>>   bNumConfigurations  1
>>   Configuration Descriptor:
>> bLength 9
>> bDescriptorType 2
>> wTotalLength   90
>> bNumInterfaces  3
>> bConfigurationValue 1
>> iConfiguration  0
>> bmAttributes 0xc0
>>   Self Powered
>> MaxPower  100mA
>> Interface Descriptor:
>>   bLength 9
>>   bDescriptorType 4
>>   bInterfaceNumber0
>>   bAlternateSetting   0
>>   bNumEndpoints   1
>>   bInterfaceClass 2 Communications
>>   bInterfaceSubClass  2 Abstract (modem)
>>   bInterfaceProtocol  1 AT-commands (v.25ter)
>>   iInterface  0
>>   CDC Header:
>> bcdCDC   1.10
>>   CDC Call Management:
>> bmCapabilities   0x03
>>   call management
>>   use DataInterface
>> bDataInterface  1
>>   CDC ACM:
>> bmCapabilities   0x02
>>   line coding and serial state
>>   CDC Union:
>> bMasterInterface0
>> bSlaveInterface 1
>>   Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x81  EP 1 IN
>> bmAttributes3
>>   Transfer TypeInterrupt
>>   Synch Type   None
>>   Usage Type   Data
>> wMaxPacketSize 0x0010  1x 16 bytes
>> bInterval  16
>> Interface Descriptor:
>>   bLength 9
>>   bDescriptorType 4
>>   bInterfaceNumber1
>>   bAlternateSetting   0
>>   bNumEndpoints   2
>>   bInterfaceClass10 CDC Data
>>   bInterfaceSubClass  0 Unused
>>   bInterfaceProtocol  0
>>   iInterface  0
>>   Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x82  EP 2 IN
>> bmAttributes2
>>   Transfer TypeBulk
>>  

Re: [systemd-devel] WebUSB

[Lars Knudsen]

A small update:  When the modemmanager finishes probing (~16 secs after
connection) data seems to stop flowing in from the WebUSB bulk endpoint
also.  It is, however, possible to reconnect and get data again - so I need
to see if there should be anything in the mbed firmware causing that
behavior or there is some sort of silent reset of interfaces/endpoints
happening on the linux side when probing is done.

On Tue, Jan 10, 2017 at 12:11 AM, Lars Knudsen  wrote:

> I finally managed to make a configuration that *seems* to work and I
> realize that I may have had something else blocking the WebUSB interface
> (2) while modemmanager was communicating with the CDC_ACM interface (1).
>
> I made a clean arbitrary VID/PID and get what seems to be a functioning
> WebUSB (now) while modemmanager sends "AT...AT..." to the CDC interface -
> so while I thought the modemmanager grabbed my WebUSB interface part, it
> must have been because of a faulty combination on my side - my apologies.
> WebUSB actually *does* seem to give immediate "bulk" access to a device
> otherwise claimed by modemmanager - a very nice option to have and sorry
> for the confusion I had that modemmanager grabbed more interfaces than it
> should have.
>
> Still, the original request still stands and please tell me if it's a
> viable path:
>
> 1.  If a device has a WebUSB descriptor, it's most probably *not* a modem
> - and should in stead be considered a device that in this rare case needs
> to be whitelisted (as modem), while defaulting to not being it.  This is to
> ease the usage from non-browsers to the same hardware, which can then
> happen immediately and not be required to fail and wait over the
> modemmanager probing period (30 sec?) - related to modemmanager
> 2. If a device has a WebUSB descriptor, at least the interface linked to
> WebUSB should be made accessible in user land by default so no average user
> has to figure out how to do udev rules - related to udev/systemd
>
> my headers that seem to work now for the case above:
>
> Bus 002 Device 089: ID 1209:d010 InterBiometrics
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.10
>   bDeviceClass0 (Defined at Interface level)
>   bDeviceSubClass 0
>   bDeviceProtocol 0
>   bMaxPacketSize064
>   idVendor   0x1209 InterBiometrics
>   idProduct  0xd010
>   bcdDevice0.01
>   iManufacturer   1 empriKit
>   iProduct2 empriKit|MOTION
>   iSerial 3 00.01
>   bNumConfigurations  1
>   Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength   90
> bNumInterfaces  3
> bConfigurationValue 1
> iConfiguration  0
> bmAttributes 0xc0
>   Self Powered
> MaxPower  100mA
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber0
>   bAlternateSetting   0
>   bNumEndpoints   1
>   bInterfaceClass 2 Communications
>   bInterfaceSubClass  2 Abstract (modem)
>   bInterfaceProtocol  1 AT-commands (v.25ter)
>   iInterface  0
>   CDC Header:
> bcdCDC   1.10
>   CDC Call Management:
> bmCapabilities   0x03
>   call management
>   use DataInterface
> bDataInterface  1
>   CDC ACM:
> bmCapabilities   0x02
>   line coding and serial state
>   CDC Union:
> bMasterInterface0
> bSlaveInterface 1
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81  EP 1 IN
> bmAttributes3
>   Transfer TypeInterrupt
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0010  1x 16 bytes
> bInterval  16
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber1
>   bAlternateSetting   0
>   bNumEndpoints   2
>   bInterfaceClass10 CDC Data
>   bInterfaceSubClass  0 Unused
>   bInterfaceProtocol  0
>   iInterface  0
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82  EP 2 IN
> bmAttributes2
>   Transfer TypeBulk
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0040  1x 64 bytes
> bInterval   0
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02  

Re: [systemd-devel] WebUSB

[Lars Knudsen]

I finally managed to make a configuration that *seems* to work and I
realize that I may have had something else blocking the WebUSB interface
(2) while modemmanager was communicating with the CDC_ACM interface (1).

I made a clean arbitrary VID/PID and get what seems to be a functioning
WebUSB (now) while modemmanager sends "AT...AT..." to the CDC interface -
so while I thought the modemmanager grabbed my WebUSB interface part, it
must have been because of a faulty combination on my side - my apologies.
WebUSB actually *does* seem to give immediate "bulk" access to a device
otherwise claimed by modemmanager - a very nice option to have and sorry
for the confusion I had that modemmanager grabbed more interfaces than it
should have.

Still, the original request still stands and please tell me if it's a
viable path:

1.  If a device has a WebUSB descriptor, it's most probably *not* a modem -
and should in stead be considered a device that in this rare case needs to
be whitelisted (as modem), while defaulting to not being it.  This is to
ease the usage from non-browsers to the same hardware, which can then
happen immediately and not be required to fail and wait over the
modemmanager probing period (30 sec?) - related to modemmanager
2. If a device has a WebUSB descriptor, at least the interface linked to
WebUSB should be made accessible in user land by default so no average user
has to figure out how to do udev rules - related to udev/systemd

my headers that seem to work now for the case above:

Bus 002 Device 089: ID 1209:d010 InterBiometrics
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x1209 InterBiometrics
  idProduct  0xd010
  bcdDevice0.01
  iManufacturer   1 empriKit
  iProduct2 empriKit|MOTION
  iSerial 3 00.01
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   90
bNumInterfaces  3
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xc0
  Self Powered
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 2 Communications
  bInterfaceSubClass  2 Abstract (modem)
  bInterfaceProtocol  1 AT-commands (v.25ter)
  iInterface  0
  CDC Header:
bcdCDC   1.10
  CDC Call Management:
bmCapabilities   0x03
  call management
  use DataInterface
bDataInterface  1
  CDC ACM:
bmCapabilities   0x02
  line coding and serial state
  CDC Union:
bMasterInterface0
bSlaveInterface 1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0010  1x 16 bytes
bInterval  16
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass10 CDC Data
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber2
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress

Re: [systemd-devel] WebUSB

[Dan Williams]

On Mon, 2017-01-09 at 20:05 +0100, Lars Knudsen wrote:
> For all practical reasons and looking ahead, I truly believe that
> there
> will be no reason to have a WebUSB header in any of the few coming
> modem
> devices (what are the stats on new USB CDC modems for these years in
> general? - still enough to justify a "blanket claim as modem"?) as
> having a
> functioning/practical webusb header requires an existing internet
> connection letting you access the hardware from a trusted URL.

Ok...  I'm clearly not putting together the pieces here.

When I read the spec at wicg.github.io, it's a bit light on actual use-
cases.  I get that; it's a protocol spec.  But having some context
would be useful.

Would any device type be a candidate for webusb?

Can you describe in a bit more detail how the WebUSB descriptors get
used by a UA?

Do they get exposed to the web app running in the UA?

What do the URLs get used for and could you give me some examples?  eg,
somebody writes a node.js library, hosts it at http://www.foobar.com/ca
meracontrol and only that URL is allowed to access a USB-connected
camera?

> In any case - even if some few would decide to try the combo - the
> far
> majority would not and the same logic (the user can just make a udev
> rule...Not sure how to explain my wife how ;)) to whitelist those
> would be
> the logical approach.
> 
> Even if it is decided that MM should still try to claim the CDC
> interface
> (which I think would be very wrong as a default in this case), the
> remaining WebUSB, custom class (yet CDC style), Bulk interface should
> be
> left untouched and available to user space browsers.
> 
> Btw on the Mac, they seem to have fixed it nicely by creating two
> logical
> tty devices and not claiming anything before the user tries to access
> either the modem one or pure data one (same physical interface -
> different
> protocol "on demand").

Can you describe this a bit more?  I'm not completely clear on what
this looks like.  Typically a 'tty' would only be used for AT-style
communication, since most modems these days don't use PPP-over-tty.

At least in the Mac/Windows world you typically install drivers and a
connection manager on first-plug and then, of course, you know from
then on that it's a modem or WiFi dongle or camera or whatever.  So
it's easy to not touch the device after that.

But on Linux, you typically don't do this for various reasons, so tools
like MM have to probe the device to find out it's a modem first, and
that clearly involves touching it.

But after the probing process, MM stops talking to the modem and does
nothing else until the user (or the desktop environment configuration)
tells MM to do something.

Dan

> On Jan 9, 2017 19:40, "Dan Williams"  wrote:
> 
> > On Mon, 2017-01-09 at 19:22 +0100, Lars Knudsen wrote:
> > > On Jan 9, 2017 18:56, "Bjørn Mork"  wrote:
> > > 
> > > > Lars Knudsen  writes:
> > > > 
> > > > > It seemed like if just one interface in the description list
> > > > > was
> > > > > somehow
> > > > > compliant with modem manager, the full device seemed claimed.
> > > > > 
> > > > > I may have missed something in my headers while
> > > > > experimenting.
> > > > > Can you
> > > > 
> > > > give
> > > > > an example of a header structure that will not be assumed to
> > > > > be a
> > > > > modem
> > > > 
> > > > by
> > > > > MM while still accessible as a proper CDC serial device -
> > > > > without
> > > > > blacklisting anything?
> > > > 
> > > > I am slowly starting to wonder if the concern is about
> > > > composite
> > > > devices
> > > > where you want a subset of the functions to be used in one
> > > > context
> > > > (MM)
> > > > and another subset to be used in another context (WebUSB)?  Is
> > > > this
> > > > correct?
> > > > 
> > > 
> > > Well, ideally, any WebUSB device that exposes a CDC interface
> > > (e.g.
> > > configured with [0]CDC INT, [1]CDC BULK and [2]WebUSB CDC/BULK)
> > > would:
> > > 
> > > 1) not be considered a modem (it would not make sense to do a
> > > modem
> > > including webusb headers - in the same device mode at least)
> > > 2) provide standard /dev/ttyUSBx serial functionality on the
> > > standard
> > > CDC
> > > endpoints (e.g. interface 1 above)
> > > 3) provide full user access to the WebUSB CDC/BULK interface (2
> > > above)
> > 
> > So I read the spec quickly but clearly not well enough.
> > 
> > Is the separate WebUSB interface parallel to the others in
> > functionality?  eg, it's just another conduit for the same
> > information
> > as the other interfaces?  Or is it some other completely separate
> > protocol?
> > 
> > Let's take two-tty CDC-ACM, one cdc-ether modem normally controlled
> > with AT commands, like a Nokia 21M-02.  It exposes 8 interfaces; 3
> > ttys
> > and one ethernet device:
> > 
> > 0 - cdc-acm commc
> > 1 - cdc-acm data
> > 2 - cdc-acm commc
> > 3 - cdc-acm data
> > 4 - cdc-acm commc
> > 5 - cdc-acm data
> > 6 - 

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Mon, Jan 9, 2017 at 7:43 PM, Bjørn Mork  wrote:

> Lars Knudsen  writes:
>
> > configured with [0]CDC INT, [1]CDC BULK and [2]WebUSB CDC/BULK) would:
> >
> > 1) not be considered a modem (it would not make sense to do a modem
> > including webusb headers - in the same device mode at least)
> > 2) provide standard /dev/ttyUSBx serial functionality on the standard CDC
> > endpoints (e.g. interface 1 above)
> > 3) provide full user access to the WebUSB CDC/BULK interface (2 above)
> >
> > What I was asking before is for an example header/configuration
> descriptors
> > where MM would *not* pick up the CDC interface but the system still
> > creating a /dev/ttyUSBx device (or ttyACMx - which it's called when MM is
> > installed) - without creating blacklisting rules specifically for e.g.
> > *that* VID/PID combo.
> > When I was experimenting the last few days - this did not seem
> possible.  I
> > had to completely wipe any indication of this device being CDC before MM
> > stopped claiming it.  Surely, MM should not pick it up if the device
> > indicates it doesn't have call functionality?
>
> This is hard to decipher.
>
> I tend to interprete "a CDC interface" as a "Communications Class
> Interface" as defined by "Universal Serial Bus Class Definitions for
> Communications Devices".  But this makes no sense in the context you are
> using it, so I guess I am misunderstanding?
>
> I don't think any current kernel driver will create /dev/ttyUSBx devices
> for any type of CDC function, so that makes no sense either.
>
> /dev/ttyACMx devices are created by the CDC ACM driver, and has nothing
> to do with MM being installed or not.
>
Thanks for clearing that upi - I was wondering why on some devices we have
without MM, the USB serial devices are called /dev/ttyUSBx until MM is
installed (but maybe it pulls cdc_acm?)

>
> In short: I don't understand anything of the above. I believe the
> requested descriptor samples would clear up some of this.  As would some
> references to the CDC spec if you are going to continue using parts of
> if to describe the device.
>

Ok - one example would be taking e.g. the USBCDC descriptors from mbed:

https://developer.mbed.org/users/mbed_official/code/USBDevice/file/4f589e246b9e/USBSerial/USBCDC.cpp

and adding a bulk WebUSB interface or the ones from Zephyr/Intel:

https://github.com/nagineni/zephyr-webusb/blob/master/samples/usb/webusb/src/webusb_serial.c

(where the webusb interface is added)

I'd like if we by default:

1. assume it's not a modem (I still can't think of any practical examples
where WebUSB descriptors [that requires online] would be added in a modem
[to get online?]) - this would be
2. could have user space access to the endpoints (at least the WebUSB
endpoints - the desired behavior could probably be to have the system
create a serial device on the CDC port andlet the firmware tie the two up
functionality wise, Reilly?) - this is probably udev/systemd

does this make more sense?

br
Lars


>
> Bjørn
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

For all practical reasons and looking ahead, I truly believe that there
will be no reason to have a WebUSB header in any of the few coming modem
devices (what are the stats on new USB CDC modems for these years in
general? - still enough to justify a "blanket claim as modem"?) as having a
functioning/practical webusb header requires an existing internet
connection letting you access the hardware from a trusted URL.

In any case - even if some few would decide to try the combo - the far
majority would not and the same logic (the user can just make a udev
rule...Not sure how to explain my wife how ;)) to whitelist those would be
the logical approach.

Even if it is decided that MM should still try to claim the CDC interface
(which I think would be very wrong as a default in this case), the
remaining WebUSB, custom class (yet CDC style), Bulk interface should be
left untouched and available to user space browsers.

Btw on the Mac, they seem to have fixed it nicely by creating two logical
tty devices and not claiming anything before the user tries to access
either the modem one or pure data one (same physical interface - different
protocol "on demand").

On Jan 9, 2017 19:40, "Dan Williams"  wrote:

> On Mon, 2017-01-09 at 19:22 +0100, Lars Knudsen wrote:
> > On Jan 9, 2017 18:56, "Bjørn Mork"  wrote:
> >
> > > Lars Knudsen  writes:
> > >
> > > > It seemed like if just one interface in the description list was
> > > > somehow
> > > > compliant with modem manager, the full device seemed claimed.
> > > >
> > > > I may have missed something in my headers while experimenting.
> > > > Can you
> > >
> > > give
> > > > an example of a header structure that will not be assumed to be a
> > > > modem
> > >
> > > by
> > > > MM while still accessible as a proper CDC serial device - without
> > > > blacklisting anything?
> > >
> > > I am slowly starting to wonder if the concern is about composite
> > > devices
> > > where you want a subset of the functions to be used in one context
> > > (MM)
> > > and another subset to be used in another context (WebUSB)?  Is this
> > > correct?
> > >
> >
> > Well, ideally, any WebUSB device that exposes a CDC interface (e.g.
> > configured with [0]CDC INT, [1]CDC BULK and [2]WebUSB CDC/BULK)
> > would:
> >
> > 1) not be considered a modem (it would not make sense to do a modem
> > including webusb headers - in the same device mode at least)
> > 2) provide standard /dev/ttyUSBx serial functionality on the standard
> > CDC
> > endpoints (e.g. interface 1 above)
> > 3) provide full user access to the WebUSB CDC/BULK interface (2
> > above)
>
> So I read the spec quickly but clearly not well enough.
>
> Is the separate WebUSB interface parallel to the others in
> functionality?  eg, it's just another conduit for the same information
> as the other interfaces?  Or is it some other completely separate
> protocol?
>
> Let's take two-tty CDC-ACM, one cdc-ether modem normally controlled
> with AT commands, like a Nokia 21M-02.  It exposes 8 interfaces; 3 ttys
> and one ethernet device:
>
> 0 - cdc-acm commc
> 1 - cdc-acm data
> 2 - cdc-acm commc
> 3 - cdc-acm data
> 4 - cdc-acm commc
> 5 - cdc-acm data
> 6 - cdc-ether commc
> 7 - cdc-ether data
>
> Now if that supported webusb, would you have:
>
> 8 - webusb
>
> If that is true, then what is supposed to happen with this modem when
> you plug it in?  Just because it has a WebUSB descriptor, should it be
> automatically "claimed" by a running browser or such, and be
> unavailable to the rest of the system?  Would all the ttys and ethernet
> devs be re-permissioned to the browser user?
>
> Or, could you expand on "it wouldn't make sense" to do a modem with
> WebUSB descriptors?  Why not?
>
> > What I was asking before is for an example header/configuration
> > descriptors
> > where MM would *not* pick up the CDC interface but the system still
> > creating a /dev/ttyUSBx device (or ttyACMx - which it's called when
> > MM is
> > installed) - without creating blacklisting rules specifically for
> > e.g.
> > *that* VID/PID combo.
>
> It depends. If MM is running and MM has been configured to probe
> devices (which can be easily changed with udev rules) then MM will
> probe and claim any device that it determines is a modem, including
> devices that expose ttys that respond to queries like AT+GCAP
> indicating they support WWAN standards.  Also including cdc-wdm devices
> that speak QMI or MBIM or AT.
>
> So it's certianly possible to configure the scenario you're trying, if
> you use udev rules to blacklist devices or if you disable probing
> entirely.
>
> If you can write udev rules that detect the presence of a webusb
> descriptor, then you can disable MM probing for that device too.
>
> > When I was experimenting the last few days - this did not seem
> > possible.  I
> > had to completely wipe any indication of this device being CDC before
> > MM
> > stopped claiming it.  Surely, MM should not pick 

Re: [systemd-devel] WebUSB

[Dan Williams]

On Mon, 2017-01-09 at 19:22 +0100, Lars Knudsen wrote:
> On Jan 9, 2017 18:56, "Bjørn Mork"  wrote:
> 
> > Lars Knudsen  writes:
> > 
> > > It seemed like if just one interface in the description list was
> > > somehow
> > > compliant with modem manager, the full device seemed claimed.
> > > 
> > > I may have missed something in my headers while experimenting.
> > > Can you
> > 
> > give
> > > an example of a header structure that will not be assumed to be a
> > > modem
> > 
> > by
> > > MM while still accessible as a proper CDC serial device - without
> > > blacklisting anything?
> > 
> > I am slowly starting to wonder if the concern is about composite
> > devices
> > where you want a subset of the functions to be used in one context
> > (MM)
> > and another subset to be used in another context (WebUSB)?  Is this
> > correct?
> > 
> 
> Well, ideally, any WebUSB device that exposes a CDC interface (e.g.
> configured with [0]CDC INT, [1]CDC BULK and [2]WebUSB CDC/BULK)
> would:
> 
> 1) not be considered a modem (it would not make sense to do a modem
> including webusb headers - in the same device mode at least)
> 2) provide standard /dev/ttyUSBx serial functionality on the standard
> CDC
> endpoints (e.g. interface 1 above)
> 3) provide full user access to the WebUSB CDC/BULK interface (2
> above)

So I read the spec quickly but clearly not well enough.

Is the separate WebUSB interface parallel to the others in
functionality?  eg, it's just another conduit for the same information
as the other interfaces?  Or is it some other completely separate
protocol?

Let's take two-tty CDC-ACM, one cdc-ether modem normally controlled
with AT commands, like a Nokia 21M-02.  It exposes 8 interfaces; 3 ttys
and one ethernet device:

0 - cdc-acm commc
1 - cdc-acm data
2 - cdc-acm commc
3 - cdc-acm data
4 - cdc-acm commc
5 - cdc-acm data
6 - cdc-ether commc
7 - cdc-ether data

Now if that supported webusb, would you have:

8 - webusb

If that is true, then what is supposed to happen with this modem when
you plug it in?  Just because it has a WebUSB descriptor, should it be
automatically "claimed" by a running browser or such, and be
unavailable to the rest of the system?  Would all the ttys and ethernet
devs be re-permissioned to the browser user?

Or, could you expand on "it wouldn't make sense" to do a modem with
WebUSB descriptors?  Why not?

> What I was asking before is for an example header/configuration
> descriptors
> where MM would *not* pick up the CDC interface but the system still
> creating a /dev/ttyUSBx device (or ttyACMx - which it's called when
> MM is
> installed) - without creating blacklisting rules specifically for
> e.g.
> *that* VID/PID combo.

It depends. If MM is running and MM has been configured to probe
devices (which can be easily changed with udev rules) then MM will
probe and claim any device that it determines is a modem, including
devices that expose ttys that respond to queries like AT+GCAP
indicating they support WWAN standards.  Also including cdc-wdm devices
that speak QMI or MBIM or AT.

So it's certianly possible to configure the scenario you're trying, if
you use udev rules to blacklist devices or if you disable probing
entirely.

If you can write udev rules that detect the presence of a webusb
descriptor, then you can disable MM probing for that device too.

> When I was experimenting the last few days - this did not seem
> possible.  I
> had to completely wipe any indication of this device being CDC before
> MM
> stopped claiming it.  Surely, MM should not pick it up if the device
> indicates it doesn't have call functionality?

MM disregards the "call functionality" part because only Nokia and
Ericsson ever actually filled that in.  Nobody really cares about
getting the detailed parts of cdc-acm correct, and because there's no
real certification or anything, nobody bothered.  So these fields are
essentially useless in the real world.

Same reason some vendors put "0123456789abcdef" into the USB serial
number field for *every single device* of a given VID/PID.  You simply
cannot rely on vendors getting descriptors correct.

Dan

> > 
> > If so, then I believe you won't be able handle that in a single
> > configuration.  If you mix all functions in a single configuration
> > then
> > you are correct that MM will take control of the device based on
> > the
> > functions it (or the kernel) supports.
> > 
> > Split the function subsets in different configurations and make the
> > OS
> > and/or userspace select the active one if you need to support these
> > different use cases.  Anything else is going to be an endless mess
> > of
> > workarounds and quirk lists all over the place.
> > 
> > 
> > Bjørn
> > 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel 

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Jan 9, 2017 18:56, "Bjørn Mork"  wrote:

> Lars Knudsen  writes:
>
> > It seemed like if just one interface in the description list was somehow
> > compliant with modem manager, the full device seemed claimed.
> >
> > I may have missed something in my headers while experimenting. Can you
> give
> > an example of a header structure that will not be assumed to be a modem
> by
> > MM while still accessible as a proper CDC serial device - without
> > blacklisting anything?
>
> I am slowly starting to wonder if the concern is about composite devices
> where you want a subset of the functions to be used in one context (MM)
> and another subset to be used in another context (WebUSB)?  Is this
> correct?
>

Well, ideally, any WebUSB device that exposes a CDC interface (e.g.
configured with [0]CDC INT, [1]CDC BULK and [2]WebUSB CDC/BULK) would:

1) not be considered a modem (it would not make sense to do a modem
including webusb headers - in the same device mode at least)
2) provide standard /dev/ttyUSBx serial functionality on the standard CDC
endpoints (e.g. interface 1 above)
3) provide full user access to the WebUSB CDC/BULK interface (2 above)

What I was asking before is for an example header/configuration descriptors
where MM would *not* pick up the CDC interface but the system still
creating a /dev/ttyUSBx device (or ttyACMx - which it's called when MM is
installed) - without creating blacklisting rules specifically for e.g.
*that* VID/PID combo.
When I was experimenting the last few days - this did not seem possible.  I
had to completely wipe any indication of this device being CDC before MM
stopped claiming it.  Surely, MM should not pick it up if the device
indicates it doesn't have call functionality?


>
> If so, then I believe you won't be able handle that in a single
> configuration.  If you mix all functions in a single configuration then
> you are correct that MM will take control of the device based on the
> functions it (or the kernel) supports.
>
> Split the function subsets in different configurations and make the OS
> and/or userspace select the active one if you need to support these
> different use cases.  Anything else is going to be an endless mess of
> workarounds and quirk lists all over the place.
>
>
> Bjørn
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Greg KH]

On Mon, Jan 09, 2017 at 06:13:04PM +0100, Bjørn Mork wrote:
> Greg KH  writes:
> > On Mon, Jan 09, 2017 at 09:40:59AM +, Kenneth Rohde Christiansen wrote:
> >> Web USB can only grab devices which has special Web USB headers. It can not
> >> grab any USB device.
> >> 
> >> https://wicg.github.io/webusb/#webusb-descriptors
> >
> > Ah, fun :(
> >
> > So, we can add a quirk into the kernel cdc-acm driver to never bind to a
> > device that has the wusb platform capability descriptor,
> 
> I fail to see why a quirk should be necessary. New device classes are
> expected to use new class/subclass codes distintly different from
> anything handled by existing class drivers.

One would hope, but it seems like they want to piggy-back on the cdc-acm
spec.  But I could be totally wrong here, does anyone have the actual
descriptor dump of a device anywhere?

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

It seemed like if just one interface in the description list was somehow
compliant with modem manager, the full device seemed claimed.

I may have missed something in my headers while experimenting. Can you give
an example of a header structure that will not be assumed to be a modem by
MM while still accessible as a proper CDC serial device - without
blacklisting anything?

BR
Lars

On Jan 9, 2017 18:13, "Bjørn Mork"  wrote:

Greg KH  writes:
> On Mon, Jan 09, 2017 at 09:40:59AM +, Kenneth Rohde Christiansen
wrote:
>> Web USB can only grab devices which has special Web USB headers. It can
not
>> grab any USB device.
>>
>> https://wicg.github.io/webusb/#webusb-descriptors
>
> Ah, fun :(
>
> So, we can add a quirk into the kernel cdc-acm driver to never bind to a
> device that has the wusb platform capability descriptor,

I fail to see why a quirk should be necessary. New device classes are
expected to use new class/subclass codes distintly different from
anything handled by existing class drivers.


Bjørn
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemd: add RDTCacheReservation= option to support CAT (Cache Allocation Technology)

[Daniel P. Berrange]

On Fri, Jan 06, 2017 at 01:51:17PM -0200, Marcelo Tosatti wrote:
> On Fri, Jan 06, 2017 at 05:26:36PM +0200, Mantas Mikulėnas wrote:
> > On Fri, Jan 6, 2017 at 3:59 PM, Marcelo Tosatti  wrote:
> > 
> > >
> > >
> > > Cache Allocation Technology is a feature on selected recent Intel Xeon
> > > processors which allows control over L3 cache allocation.
> > >
> > > Kernel support has been merged to the upstream kernel, via a filesystem
> > > resctrlfs.
> > >
> > > On top of that, a userspace utility, resctrltool has been written
> > > to facilitate writing applications and using the filesystem
> > > interface (see the rationale at
> > > http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1300792.html).
> > >
> > > This patch adds a new option to systemd, RDTCacheReservation,
> > > to allow configuration of CAT via resctrltool.
> > >
> > > See the first hunk of the patch for a description of the option
> > 
> > 
> > This really doesn't look pretty, neither the approach nor the
> > implementation...
> 
> Suggestions to improve the code or the approach are welcome.
> 
> > Is the option actually so complex that calling resctrltool is the only way
> > to adjust it? What about writing to the resctrlfs directly?
> 
> You'll have to deal with the issues that resctrltool deals with,
> namely:
> 
> 1) Filesystem locking.
> 2) Reading in every directory and the default 
> directory.
> 3) Converting the reservation request to proper sizes.
> 4) Converting:
>   type=both --> type=data/type=code
> 
>   type=data/type=code --> type=both
> 
> 4) Finding free space for the reservation.
> 5) Adjusting the default group reservation.
> 
> Since this steps must be performed by every user of
> CAT (including libvirt which plans to execute resctrltool
> as well), it was decided its better to maintain this logic
> in a centralized place.

Errr, no, that's not correct - Libvirt is certainly not going to
spawn some python program to do this. If there's no C library API
for this, libvirt will simply implement all the logic itself.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemd: add RDTCacheReservation= option to support CAT (Cache Allocation Technology)

[Marcelo Tosatti]

On Fri, Jan 06, 2017 at 07:51:05PM +0100, Lennart Poettering wrote:
> On Fri, 06.01.17 11:59, Marcelo Tosatti (mtosa...@redhat.com) wrote:
> 
> > Cache Allocation Technology is a feature on selected recent Intel Xeon
> > processors which allows control over L3 cache allocation.
> 
> What precisely is the benefit of making this configurable? Can you
> describe a basic usecase why I'd want to set this on some service?

http://www.intel.com/content/www/us/en/communications/cache-allocation-technology-white-paper.html

"On systems with multiple workloads running simultaneously, which
heavily utilize the cache; system administrators can utilize CAT to
improve performance. CAT can be used to better utilize the caches and
as a result some applications are more likely to hit the cache which
results in fewer accesses to system memory. This results in lower
latency and greater performance."



For example, with a job with large memory reaccess distances (where
caching hardly brings any benefit), you can limit that job to reclaim a
small portion of L3 cache (so you don't throw away data from other jobs
from L3 cache).

> 
> > Index: systemd/man/systemd.exec.xml
> > ===
> > --- systemd.orig/man/systemd.exec.xml
> > +++ systemd/man/systemd.exec.xml
> 
> Hmm, this doesn't look like a git patch? We generally prefer
> submissions as github PRs these days, btw.
> 
> > @@ -233,6 +233,31 @@
> >
> >  
> >
> > +RDTCacheReservation=
> > +
> > +Creates a L3 CAT reservation in resctrlfs
> > +for the executed processes. Takes a ";" separated list of
> > +tuples (optionally triples) containing type,size and
> > +optionally cacheid:
> 
> if I read this, then I am puzzled what "RDT Cache" is, what "L3 CAT"
> is. Can you explain?

RDT: Resource Director Technology(RDT)
CAT: Cache Allocation Technology (CAT), a subcomponent of RDT 
(which includes other things such as CMT: Cache Monitoring Technology).

> 
> > +type=type,size=size,cacheid=id;
> > +type=type,size=size,cacheid=id;...
> > +
> > +Where:
> > +
> > +type is one of: both, data, code.
> > +size is size in kbytes.
> > +cacheid (optional) is the cacheid for
> > +the reservation.
> 
> what is a "cacheid"?

Cache IDs
-
On current generation systems there is one L3 cache per socket and L2
caches are generally just shared by the hyperthreads on a core, but this
isn't an architectural requirement. We could have multiple separate L3
caches on a socket, multiple cores could share an L2 cache. So instead
of using "socket" or "core" to define the set of logical cpus sharing
a resource we use a "Cache ID". At a given cache level this will be a
unique number across the whole system (but it isn't guaranteed to be a
contiguous sequence, there may be gaps).  To find the ID for each
logical
CPU look in /sys/devices/system/cpu/cpu*/cache/index*/id


> 
> > +
> > +Rules for the parameters:
> > +* type=code must be paired with type=data entry.
> > +
> > +See the output of resctrltool for more details.
> > +
> > +
> > +  
> 
> This syntax doesn't appear to be in line with how we'd do this in
> systemd usually. Ideally, we try to hide the fact that our settings
> syntax is one-dimensional as much as we can. Hence, a syntax like this
> sounds more appropriate to me:
> 
>RDTCacheReservation=4K code
>RDTCacheReservation=16K data
> 
> and so on...

What you suggest is to essentially to split

RDTCacheReservation=type=type,size=size,cacheid=id;type=type,size=size,cacheid=id

Into

RDTCacheReservation=type=type,size=size,cacheid=id
RDTCacheReservation=type=type,size=size,cacheid=id

(yes sure can get rid of the commas as well, looks better).

> But then again, I have no idea what all of this actually really is,
> hence I am not sure my proposed syntax makes much sense.
> 
> sizes are generally parsed with parse_bytes() in systemd, so that K,
> M, G suffixes are properly recognized...
> 
> > +ExecContext *c = userdata;
> > +int r;
> > +int i;
> > +
> > +assert(bus);
> > +assert(reply);
> > +assert(c);
> > +
> > +r = sd_bus_message_open_container(reply, 'a', "s");
> > +if (r < 0)
> > +return r;
> > +
> > +for (i = 0; i < c->argmidx; i++) {
> > +r = sd_bus_message_append(reply, "s", c->argm[i]);
> > +if (r < 0)
> > +return r;
> > +}
> 
> indentation is borked. Please indent to multiples of 8ch.
> 
> > +static char* convert_rdt_back(char *argm[], int argmidx)
> > +{
> 
> Please follow coding style, place opening bracket on same name as
> funciton name.
> 
> > +   int i, ret;
> > +   char *buf, *str;
> > +   int size = 0;
> > +   int printcomma = 0;
> > +   int 

Re: [systemd-devel] WebUSB

[Greg KH]

On Mon, Jan 09, 2017 at 01:12:11PM +0200, Felipe Balbi wrote:
> 
> I don't think we need to change anything in the kernel. What we need is
> generic udev rule that fixes up permissions for the WebUSB Interface.
> 
> IIRC, WebUSB is implemented much like CDC ACM, however bInterfaceClass
> is set to Vendor Specific. That should be enough to prevent CDC-ACM
> driver from binding to WebUSB Interface.

Yeah, someone drug you into this thread a bit late, I already suggested
that a simple kernel patch would resolve all of this  :)

Now all we do is wait for someone to make that patch...

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Felipe Balbi]

I don't think we need to change anything in the kernel. What we need is
generic udev rule that fixes up permissions for the WebUSB Interface.

IIRC, WebUSB is implemented much like CDC ACM, however bInterfaceClass
is set to Vendor Specific. That should be enough to prevent CDC-ACM
driver from binding to WebUSB Interface.

Babu once showed me on WebUSB device but I can't recall if the
descriptors were setup as I mentioned above or not. Babu, care to
confirm?

thanks

"Poussa, Sakari"  writes:
> +Balbi
>
> On 1/9/17, 11:37 AM, "Kenneth Rohde Christiansen" 
>  wrote:
>
> Adding Sakari and Babu, who might want to add a few people from our side. 
>
> Cheers
>
> Kenneth
>
> On Mon, Jan 9, 2017 at 10:20 AM Lars Knudsen  wrote:
>
>  Hi, 
>
>  I am currently looking into how we can make using WebUSB devices less 
> painful for users on Linux.
>
>  The main purpose of WebUSB (as far as I can see) is to enable certain CDC 
> (in particular - but not limited to) devices communicate directly with 
> browsers visiting certain trusted sites (listed inside a binary object store 
> - sent on initial handshake).
>
>  The spec is here: https://wicg.github.io/webusb/ (already running fine in 
> chrome stable)
>
>  Examples:
>
>  https://www.youtube.com/watch?v=Z1Nk2hH2wFE
>
>  https://www.youtube.com/watch?v=o7wGt9RfHVA
>
>  https://twitter.com/denladeside/status/817451203076427783
>
>  I'm guessing the solution will consist of 2 parts:
>
>  1. make sure no WebUSB device is picked up by modemmanager (modemmanager 
> task)
>
>  2. make sure that webusb devices will be somehow accessible to be used by a 
> browser running with user permissions (current temp solution listed here: 
> adding user to plugdev, adding 0664 permissions to device:
>  
> https://developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web
>  ) (udev/systemd task).
>
>  For 2. we need to either making all webusb devices accessible or find some 
> other way the browsers can - in a generic way - gain access. In all cases, 
> it's important that no USB interfaces has been pre-claimed by the system 
> (e.g. by cdc_acm) or
>  it should be possible for the browser to throw off the claims.
>
>  thoughts?
>
>  br
>
>  Lars
>

-- 
balbi


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Mon, Jan 9, 2017 at 11:39 AM, Greg KH  wrote:

> On Mon, Jan 09, 2017 at 11:29:24AM +0100, Aleksander Morgado wrote:
> > On Mon, Jan 9, 2017 at 11:07 AM, Greg KH  wrote:
> > > On Mon, Jan 09, 2017 at 09:40:59AM +, Kenneth Rohde Christiansen
> wrote:
> > >> Web USB can only grab devices which has special Web USB headers. It
> can not
> > >> grab any USB device.
> > >>
> > >> https://wicg.github.io/webusb/#webusb-descriptors
> > >
> > > Ah, fun :(
> > >
> > > So, we can add a quirk into the kernel cdc-acm driver to never bind to
> a
> > > device that has the wusb platform capability descriptor, which will
> > > prevent you from having to disconnect the driver from the device (and
> > > the permissions issues involved in that.)
> > >
> > > Would that help out?
> > >
> > > And just do the same thing in modem manager, never grab a device with
> > > this descriptor, and let the browser/webusb handle the control of the
> > > device if it so desires.
> >
> > Not sure anything would be required in ModemManager if the kernel
> > already skips the binding to cdc-acm; i.e. ModemManager won't do
> > anything unless the TTY is exposed.
>
> Great, that was easy then!
>
> So, who is going to send in the kernel patch for this? :)
>

To be sure we don't miss anything, let's give the folks in California a
chance to give their input.

In any case, WebUSB looks very cool and looks like a starting point for
finally getting an easy way (a bit like BLE vs Bluetooth) for average users
connecting USB devices in a secure and cross-platform compliant way to the
web.

br
Lars


>
> thanks,
>
> greg k-h
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Poussa, Sakari]

+Balbi

On 1/9/17, 11:37 AM, "Kenneth Rohde Christiansen" 
> wrote:

Adding Sakari and Babu, who might want to add a few people from our side.

Cheers
Kenneth
On Mon, Jan 9, 2017 at 10:20 AM Lars Knudsen 
> wrote:
Hi,

I am currently looking into how we can make using WebUSB devices less painful 
for users on Linux.

The main purpose of WebUSB (as far as I can see) is to enable certain CDC (in 
particular - but not limited to) devices communicate directly with browsers 
visiting certain trusted sites (listed inside a binary object store - sent on 
initial handshake).

The spec is here: https://wicg.github.io/webusb/ (already running fine in 
chrome stable)
Examples:
https://www.youtube.com/watch?v=Z1Nk2hH2wFE
https://www.youtube.com/watch?v=o7wGt9RfHVA
https://twitter.com/denladeside/status/817451203076427783

I'm guessing the solution will consist of 2 parts:

1. make sure no WebUSB device is picked up by modemmanager (modemmanager task)

2. make sure that webusb devices will be somehow accessible to be used by a 
browser running with user permissions (current temp solution listed here: 
adding user to plugdev, adding 0664 permissions to device: 
https://developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web 
)  (udev/systemd task).

For 2. we need to either making all webusb devices accessible or find some 
other way the browsers can - in a generic way - gain access.  In all cases, 
it's important that no USB interfaces has been pre-claimed by the system (e.g. 
by cdc_acm) or it should be possible for the browser to throw off the claims.

thoughts?

br
Lars


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Greg KH]

On Mon, Jan 09, 2017 at 11:29:24AM +0100, Aleksander Morgado wrote:
> On Mon, Jan 9, 2017 at 11:07 AM, Greg KH  wrote:
> > On Mon, Jan 09, 2017 at 09:40:59AM +, Kenneth Rohde Christiansen wrote:
> >> Web USB can only grab devices which has special Web USB headers. It can not
> >> grab any USB device.
> >>
> >> https://wicg.github.io/webusb/#webusb-descriptors
> >
> > Ah, fun :(
> >
> > So, we can add a quirk into the kernel cdc-acm driver to never bind to a
> > device that has the wusb platform capability descriptor, which will
> > prevent you from having to disconnect the driver from the device (and
> > the permissions issues involved in that.)
> >
> > Would that help out?
> >
> > And just do the same thing in modem manager, never grab a device with
> > this descriptor, and let the browser/webusb handle the control of the
> > device if it so desires.
> 
> Not sure anything would be required in ModemManager if the kernel
> already skips the binding to cdc-acm; i.e. ModemManager won't do
> anything unless the TTY is exposed.

Great, that was easy then!

So, who is going to send in the kernel patch for this? :)

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

I have som more input - but really need Reilly's comments on this:

As hardware manufacturers most often want to make it possible for users to
use their hardware in a WebUSB setting as well as in a "normal" app mode,
we will most likely see composite devices that could have the following
interfaces defined:

1. INT IF (for std CDC)
2. BULK CDC (non-webusb - e.g. for normal serial port bindings)
3. WebUSB CDC/bulk

In this case - ideally - the system should be allowed to grab 1 and 2 (but
most probably not modemmanager - as it's very unlikely that a modem will be
a webusb device.. as webusb devices assume internet) but leave 3 untouched
(unclaimed) for WebUSB bulk communication.  This means that the udev rules
need to be made on an interface level and not "blanket cover" the whole
device.

Beware that I might not be 100% correct on these assumptions and really
need some input on the intentions from Reilly or others with more knowledge
in the area (let's give California time to wake up :))

br
Lars


On Mon, Jan 9, 2017 at 11:29 AM, Aleksander Morgado <
aleksan...@aleksander.es> wrote:

> On Mon, Jan 9, 2017 at 11:07 AM, Greg KH  wrote:
> > On Mon, Jan 09, 2017 at 09:40:59AM +, Kenneth Rohde Christiansen
> wrote:
> >> Web USB can only grab devices which has special Web USB headers. It can
> not
> >> grab any USB device.
> >>
> >> https://wicg.github.io/webusb/#webusb-descriptors
> >
> > Ah, fun :(
> >
> > So, we can add a quirk into the kernel cdc-acm driver to never bind to a
> > device that has the wusb platform capability descriptor, which will
> > prevent you from having to disconnect the driver from the device (and
> > the permissions issues involved in that.)
> >
> > Would that help out?
> >
> > And just do the same thing in modem manager, never grab a device with
> > this descriptor, and let the browser/webusb handle the control of the
> > device if it so desires.
>
> Not sure anything would be required in ModemManager if the kernel
> already skips the binding to cdc-acm; i.e. ModemManager won't do
> anything unless the TTY is exposed.
>
> --
> Aleksander
> https://aleksander.es
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Disk Utilization part of systemd-bootchart is empty

[Eswaran Vinothkumar (BEG-PT/PJ-IOT1)]

Sorry for my mistake,I have attached the output from busybox-bootchart 
initially.

Now I have attached the correct file from systemd-bootchart. The I/O 
utilization part is empty. Please let me know how to enable that for NAND flash.

> Hello systemd developers,
> 
> I am currently analyzing the boot time of an embedded product. Systemd is 
> used as the init system. I am trying to get the details about CPU load and 
> I/O utilization from the systemd-bootchart. The disk utilization part of 
> bootchart is empty, I am not sure what is the error.
> Can anyone here let me know about the issue and how to fix this problem.
> 
> I have attached the systemd-bootchart for reference.

No,

you have attached the output of another bootchart program. For
reference: systemd-bootchart creates SVG files, not PNGs.

Auke

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Mantas Mikulėnas]

On Mon, Jan 9, 2017 at 11:20 AM, Lars Knudsen  wrote:

Hi,

I am currently looking into how we can make using WebUSB devices less
painful for users on Linux.

The main purpose of WebUSB (as far as I can see) is to enable certain CDC
(in particular - but not limited to) devices communicate directly with
browsers visiting certain trusted sites (listed inside a binary object
store - sent on initial handshake).

The spec is here: https://wicg.github.io/webusb/ (already running fine in
chrome stable)
Examples:
https://www.youtube.com/watch?v=Z1Nk2hH2wFE
https://www.youtube.com/watch?v=o7wGt9RfHVA
https://twitter.com/denladeside/status/817451203076427783

I'm guessing the solution will consist of 2 parts:

1. make sure no WebUSB device is picked up by modemmanager (modemmanager
task)

2. make sure that webusb devices will be somehow accessible to be used by a
browser running with user permissions (current temp solution listed here:
adding user to plugdev, adding 0664 permissions to device:
https://developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web
)  (udev/systemd task).

For 2. we need to either making all webusb devices accessible or find some
other way the browsers can - in a generic way - gain access.  In all cases,
it's important that no USB interfaces has been pre-claimed by the system
(e.g. by cdc_acm) or it should be possible for the browser to throw off the
claims.


I'm not sure how ModemManager could possibly avoid claiming a device based
on a website visit that will happen *sometime in the future*, if ever.

As for permissions, uaccess might work if the device types are known (see
e.g. the Yubikey udev rules), but... somehow, it sounds like webapps will
end up being more privileged than local software, a bit odd.

-- 
Mantas Mikulėnas 
-- 

Mantas Mikulėnas 
Sent from my phone
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Jan 9, 2017 10:53, "Mantas Mikulėnas"  wrote:

On Mon, Jan 9, 2017 at 11:20 AM, Lars Knudsen  wrote:

Hi,

I am currently looking into how we can make using WebUSB devices less
painful for users on Linux.

The main purpose of WebUSB (as far as I can see) is to enable certain CDC
(in particular - but not limited to) devices communicate directly with
browsers visiting certain trusted sites (listed inside a binary object
store - sent on initial handshake).

The spec is here: https://wicg.github.io/webusb/ (already running fine in
chrome stable)
Examples:
https://www.youtube.com/watch?v=Z1Nk2hH2wFE
https://www.youtube.com/watch?v=o7wGt9RfHVA
https://twitter.com/denladeside/status/817451203076427783

I'm guessing the solution will consist of 2 parts:

1. make sure no WebUSB device is picked up by modemmanager (modemmanager
task)

2. make sure that webusb devices will be somehow accessible to be used by a
browser running with user permissions (current temp solution listed here:
adding user to plugdev, adding 0664 permissions to device:
https://developers.google.com/web/updates/2016/03/access-
usb-devices-on-the-web )  (udev/systemd task).

For 2. we need to either making all webusb devices accessible or find some
other way the browsers can - in a generic way - gain access.  In all cases,
it's important that no USB interfaces has been pre-claimed by the system
(e.g. by cdc_acm) or it should be possible for the browser to throw off the
claims.


I'm not sure how ModemManager could possibly avoid claiming a device based
on a website visit that will happen *sometime in the future*, if ever.

It is in the USB descriptors. Should be easy to do a clean detection. It is
not likely anyone would ever make a modem with webusb descriptors.


As for permissions, uaccess might work if the device types are known (see
e.g. the Yubikey udev rules), but... somehow, it sounds like webapps will
end up being more privileged than local software, a bit odd.

-- 
Mantas Mikulėnas 
-- 

Mantas Mikulėnas 
Sent from my phone
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] WebUSB

[Lars Knudsen]

Hi,

I am currently looking into how we can make using WebUSB devices less
painful for users on Linux.

The main purpose of WebUSB (as far as I can see) is to enable certain CDC
(in particular - but not limited to) devices communicate directly with
browsers visiting certain trusted sites (listed inside a binary object
store - sent on initial handshake).

The spec is here: https://wicg.github.io/webusb/ (already running fine in
chrome stable)
Examples:
https://www.youtube.com/watch?v=Z1Nk2hH2wFE
https://www.youtube.com/watch?v=o7wGt9RfHVA
https://twitter.com/denladeside/status/817451203076427783

I'm guessing the solution will consist of 2 parts:

1. make sure no WebUSB device is picked up by modemmanager (modemmanager
task)

2. make sure that webusb devices will be somehow accessible to be used by a
browser running with user permissions (current temp solution listed here:
adding user to plugdev, adding 0664 permissions to device:
https://developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web
)  (udev/systemd task).

For 2. we need to either making all webusb devices accessible or find some
other way the browsers can - in a generic way - gain access.  In all cases,
it's important that no USB interfaces has been pre-claimed by the system
(e.g. by cdc_acm) or it should be possible for the browser to throw off the
claims.

thoughts?

br
Lars
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel