Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Jan 18, 2022 at 11:16:28AM -0800, Benson Leung wrote:
> Hi Greg,
> 
> On Tue, Jan 18, 2022 at 07:33:39PM +0100, Greg KH wrote:
> > On Tue, Jan 18, 2022 at 10:01:02PM +0530, Rajaram Regupathy wrote:
> > > > Again, why does this have to be a library?
> > > >
> > > The aim of having a library is to abstract application(s) from OS,
> > > platform, PD Controller or Embedded Controller protocols ambiguities
> > > and provide common methods. The methods will be similar/closer to UCSI
> > > standard.
> > 
> > What methods are needed by an operating system that your library is
> > going to provide?  How will it be done in a unified way that the current
> > user/kernel api isn't providing already today?
> > 
> 
> A unified libtypec would be useful because the USB Type-C and USB PD
> specifications are evolving, and continue to change. Spec changes affect the
> decoding of the objects that are exposed by the connector class (the existing
> API), and we are at a point where if we left it as-is, you'd have multiple
> userspace implementations that would have to independently be updated and
> fixed every time there's a new USB PD spec revision or version update.
> 
> Just as a concrete example, Jameson (jthies@google.com), who works on my team,
> recently put together a little helper utility to decode the typec connector
> class in order to print it to our feedback report collector. This was all
> done before libtypec:
> 
> https://chromium.googlesource.com/chromiumos/platform2/+/749621a6288cc5e80b31a9e6050437a419209fb9/debugd/src/helpers/typec_connector_class_helper.cc
> 
> A problem we ran into almost immediately was that the utility was based on
> the most recent USB PD specification documents (USB PD R2.0 and USB PD R3.1),
> and had definitions on how to decode PD 2.0 and PD 3.1 objects that it would
> read from the typec connector class, however, it was missing definitions for
> USB PD R3.0 (a spec revision which is not obvious how to find in USB-IF's
> document archive).
> 
> So, we added it: https://chromium.googlesource.com/chromiumos/platform2/+/eb1efefc187feab1182a7680f42fcec6bb14c618
> 
> Now, every other hypothetical type-c connector class user application or daemon
> could potentially make this mistake, and would have to duplicate the work
> to fix it.
> 
> If we had libtypec, it would be the unified place to make such a change, and
> we'd reduce the burden of new typec apps from having to do all this decode
> in the future.

Ok, that's fine, but please work to create a library that can handle
such changes in non-breaking ways.  The first version of this library
does not look like it would do that at all as it is exporting way too
many things in a "public" interface.

thanks,

greg k-h