linux-kernel - Re: [PATCH -mm 0/2] RapidIO: Changes to handling of RIO switches

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:	Tue, 26 Oct 2010 16:22:52 +0200
From:	Micha Nelissen <micha@...i.hopto.org>
To:	"Bounine, Alexandre" <Alexandre.Bounine@....com>
CC:	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	linuxppc-dev@...ts.ozlabs.org,
	Matt Porter <mporter@...nel.crashing.org>,
	Li Yang <leoli@...escale.com>,
	Kumar Gala <galak@...nel.crashing.org>,
	Thomas Moll <thomas.moll@...go.com>
Subject: Re: [PATCH -mm 0/2] RapidIO: Changes to handling of RIO switches

Bounine, Alexandre wrote:
> Micha Nelissen <micha@...i.hopto.org> wrote:
>> I look at it this way: it prevents the need for another layer of
>> indirection: translating component tag to a destid.
> 
> The destid alone is not enough. You will need an entire rio_dev object
> for that device anyway.

?? I did not say a rio_dev object is not needed; on the contrary, I do 
have it.

In various parts of the enumeration and routing algorithm, it would need 
to lookup the tag to find the destid, if the destid is in the tag then 
this lookup is not needed.

> I think we are mixing two things together here. I understand your idea
> but do not see how it prevents me from having one common set of access
> coordinates for RIO devices (the starting point of our discussion). 

I'm trying to argue we do not want redundant identification in the first 
  place unless absolutely necessary.

> Regardless of an implementation, having a way that ensures unified
> identification of switches by all processor boards is better than the
> current mainline implementation. 

Well, we both know "the current mainline implementation" is easily 
improved to unique identification I proposed. Therefore this statement 
is misleading.

> Methods of forming a component tag may
> differ but still serve the same purpose. Personally I prefer to avoid
> any link of device identification to the destid because it may not be as
> intuitive as it seems for large systems with hot-plug. I will discuss
> this with some of RIO TWG guys to get their opinion on the best
> approach.

Please do, please elaborate: "may not be as intuitive" ... to what? for 
implementation of ...?

> I will make a patch that defines fields of component tag, probably just
> one for now - identification field. This will ensure that any method
> used to assign component tag (id part of it) will be compatible with RIO
> spec part 8 error management.

Again slightly misleading information. Any unique identification 
satisfies this requirement.

To prove my point: are you going to recycle the component tags as well 
in case of hot-swaps, just like the destids?

> As for switch identification, at this moment I still prefer replacing
> rswitch->switchid with ID portion of the component tag because it is
> very simple and does not require changes to enumeration algorithm.   

Yes, I agree switchid = tag, that's what I use also.

Micha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/