LKML Archive on
help / color / mirror / Atom feed
From: Stefan Richter <>
To: Peter Hurley <>
Cc: Clemens Ladisch <>,
	Greg Kroah-Hartman <>,,,
Subject: Re: [PATCH] staging/fwserial: use correct vendor/version IDs
Date: Tue, 3 Feb 2015 22:22:26 +0100	[thread overview]
Message-ID: <20150203222226.7f0e8446@kant> (raw)
In-Reply-To: <>

On Feb 03 Peter Hurley wrote:
> On 02/03/2015 03:44 AM, Stefan Richter wrote:
> > On Feb 02 Peter Hurley wrote:
> >> The problem is a host with the old OUIs will not recognize a remote
> >> unit with the new OUIs, and vice versa.
> >>
> >> Even though the new ids could be added to the unit driver's id_table,
> >> (which would let hosts with the new OUI connect to either OUI remote),
> >> it wouldn't let 3.19- hosts connect to 3.20+ hosts.
> > 
> > Actually there are no 3.19- hosts that speak fwserial; there are only
> > staging hosts that do so.  So, with this patch added, certain staging
> > hosts would become unable to talk with certain other staging hosts (and
> > with future Linux hosts, once fwserial gets merged upstream).
> The breakage seems gratuitous especially considering the existing OUI
> has been in use for a decade.

This ID has never been in use to identify the specifier of a unit
architecture though, nor has it been used otherwise in any protocol.
And the way how the ID /was/ used doesn't make it an OUI.

[Since 7.5 years ago the new firewire-core puts a fixed, unregistered
value into the config ROM's root dir's vendor ID leaf, whereas until
4 years ago ieee1394 has been copying the upper 24 bits of the node's
EUI-64 there.  Years counted according to mainline Linux releases.
As another historical note, 7.5 years ago the occupied OUI space consisted
of 10456 IDs from 0…acde48, now it is 19896 IDs from 0…fcffaa.]

> > Both fwserial-the-implementation and fwserial-the-protocol are your own,
> > and as yet unmerged.
> I've been waiting for you to work through the patch backlog from Feb and
> Mar of last year before sending you more patches to merge fwserial.

If there is one or another patch among them which directly blocks your
work on fwserial, ping me so that I can reconsider priorities.  Though if
you were just expressing dissatisfaction with the subsystem's maintenance
progress, well, then that's noted and quite agreed.

> >  (In addition, there does not yet exist a second
> > implementation, AFAIK.)  So I'd say there is still opportunity to improve
> > the protocol even in incompatible ways if justified.  Switching to
> > valid identifiers may very well be such a justifiable change.
> I would appreciate you sharing any suggestions for improving the protocol.
> While I concede the protocol is not perfect, I'm struggling to see how
> changing the OUI improves it.

The difference of course is nothing more than that the interoperability of
the specifier_ID:software_version tuple either depends on made-up IDs, or
on IDs whose uniqueness is based on a proper chain of registrations.
Stefan Richter
-=====-===== --=- ---==

  reply	other threads:[~2015-02-03 21:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2015-01-28 20:07 ` Clemens Ladisch
2015-01-29  9:44   ` Stefan Richter
2015-02-02 22:08   ` Peter Hurley
2015-02-03  8:44     ` Stefan Richter
2015-02-03 14:00       ` Peter Hurley
2015-02-03 21:22         ` Stefan Richter [this message]
2015-02-07  9:10   ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150203222226.7f0e8446@kant \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] staging/fwserial: use correct vendor/version IDs' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).