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]

Message-ID: <0CE8B6BE3C4AD74AB97D9D29BD24E5520147D879@CORPEXCH1.na.ads.idt.com>
Date:	Tue, 26 Oct 2010 06:39:29 -0700
From:	"Bounine, Alexandre" <Alexandre.Bounine@....com>
To:	"Micha Nelissen" <micha@...i.hopto.org>
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

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.

> 
> Why no relation? My experience is that during debugging it's useful to
> have the destid directly at hand, it's just very practical. (Otherwise
> any drawing of a random network would need two "identification"
numbers
> per drawn node: the component tag (true identification), and destid
> since that's what everyone uses to identify a device, what needs to
> programmed into the LUTs of a switch, identification in sysfs, etc.).

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). 

Regardless of an implementation, having a way that ensures unified
identification of switches by all processor boards is better than the
current mainline implementation. 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.

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.

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.   

Alex.

--
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/