Re: Sun4c interrupt controller - Sun4d relevance

Re: Sun4c interrupt controller - Sun4d relevance

[Chris Newport]

Mark Fortescue wrote:

>
> There is source code for Solaris 2.6 on the web. This is the best 
> source code reference you will get for sun4c as the low level code has 
> not been changed significantly from that of the architecture reference 
> kernel (SunOS 4.1 - see Sparc SCD 1.1).

This is VERY interesting as it should be possible to fix Sun4d by finding
the differences between sun4d and sun4m in Solaris and covering those 
points.

This would almost certainly be easier than trying to fix the current 
mess. Unfortunately I am no longer able to do this but maybe someone 
will be interested enough to try. It might even be possible to fix 
pluto/fc but maybe that is too much to ask.

Re: Sun4c interrupt controller - Sun4d relevance

[Blue Swirl]

On 8/12/07, Chris Newport <crn@netunix.com> wrote:
> This is VERY interesting as it should be possible to fix Sun4d by finding
> the differences between sun4d and sun4m in Solaris and covering those
> points.
>
> This would almost certainly be easier than trying to fix the current
> mess. Unfortunately I am no longer able to do this but maybe someone
> will be interested enough to try. It might even be possible to fix
> pluto/fc but maybe that is too much to ask.

It is also possible to add sun4d emulation to Qemu. I think the
architecture is similar to sun4m except for sbi, io-unit and different
counter. CPU/MMU (with working SMP) and I/O devices are already
emulated.

Re: Sun4c interrupt controller - Sun4d relevance

[Mark Fortescue]

>
> This is VERY interesting as it should be possible to fix Sun4d by finding
> the differences between sun4d and sun4m in Solaris and covering those points.
>
> This would almost certainly be easier than trying to fix the current mess. 
> Unfortunately I am no longer able to do this but maybe someone will be 
> interested enough to try. It might even be possible to fix pluto/fc but maybe 
> that is too much to ask.
>

The code I found only explicitly supports sun4c, sun4m and sun4u. Given 
this, you may find that it does not help. Check the sun web site to find 
out which version of Solaris/SunOS was the last version with sun4d 
support as this will help track down any source code. For sun4c it was 
Solaris 2.7 but I did not find anything that looked like full source code 
(for the sun4c specific elements) for Solaris 2.7.

Re: Sun4c interrupt controller - Sun4d relevance

[Chris Newport]

Mark Fortescue wrote:

>
>>
>> This is VERY interesting as it should be possible to fix Sun4d by 
>> finding
>> the differences between sun4d and sun4m in Solaris and covering those 
>> points.
>>
>> This would almost certainly be easier than trying to fix the current 
>> mess. Unfortunately I am no longer able to do this but maybe someone 
>> will be interested enough to try. It might even be possible to fix 
>> pluto/fc but maybe that is too much to ask.
>>
>
> The code I found only explicitly supports sun4c, sun4m and sun4u. 
> Given this, you may find that it does not help. Check the sun web site 
> to find out which version of Solaris/SunOS was the last version with 
> sun4d support as this will help track down any source code. For sun4c 
> it was Solaris 2.7 but I did not find anything that looked like full 
> source code (for the sun4c specific elements) for Solaris 2.7.

Last Solaris support for sun4d was Solaris 2.8 so all of the code will 
be there in 2.6 somewhere. Maybe it is just a special case within sun4m 
with a few extra drivers, or maybe the code has not been released.
The SS1000 is frustratingly similar to the SS20, most of the devices are 
common.

ISTR that Sun4d was a joint venture with Cray, so some code might
be encumbered. I have not seen code so I can only guess.

Re: Sun4c interrupt controller - Sun4d relevance

[Tom "spot" Callaway]

On Sun, 2007-08-12 at 20:23 +0100, Chris Newport wrote:

> Last Solaris support for sun4d was Solaris 2.8 so all of the code will 
> be there in 2.6 somewhere. Maybe it is just a special case within sun4m 
> with a few extra drivers, or maybe the code has not been released.
> The SS1000 is frustratingly similar to the SS20, most of the devices are 
> common.
> 
> ISTR that Sun4d was a joint venture with Cray, so some code might
> be encumbered. I have not seen code so I can only guess.

I hate to be a bother here, but aren't there some legal concerns with
looking at Solaris source code, then implementing code in Linux?

Even on OpenSolaris, there is a grey area as to whether one can legally
view CDDL licensed code, then reimplement it as GPL (CDDL is
GPL-Incompatible) for Linux... but on old Solaris, that code should be
proprietary, unless Sun opened it when I wasn't looking.

Mark, can you legally be doing this? 

~spot

Re: Sun4c interrupt controller - Sun4d relevance

[Mark Fortescue]

On Sun, 12 Aug 2007, Tom "spot" Callaway wrote:

>
> On Sun, 2007-08-12 at 20:23 +0100, Chris Newport wrote:
>
>> Last Solaris support for sun4d was Solaris 2.8 so all of the code will
>> be there in 2.6 somewhere. Maybe it is just a special case within sun4m
>> with a few extra drivers, or maybe the code has not been released.
>> The SS1000 is frustratingly similar to the SS20, most of the devices are
>> common.
>>
>> ISTR that Sun4d was a joint venture with Cray, so some code might
>> be encumbered. I have not seen code so I can only guess.
>
> I hate to be a bother here, but aren't there some legal concerns with
> looking at Solaris source code, then implementing code in Linux?
>
> Even on OpenSolaris, there is a grey area as to whether one can legally
> view CDDL licensed code, then reimplement it as GPL (CDDL is
> GPL-Incompatible) for Linux... but on old Solaris, that code should be
> proprietary, unless Sun opened it when I wasn't looking.
>

I do not know how much (if any) old solaris code was officially released. 
I just did a search on the web for the SunMMU as Sun don't apear to have 
any usefull documentation available (there was more when they supported 
sun4c) and LSI apear to have lost all their documentation on the chips 
used in my SS1/SS2.

> Mark, can you legally be doing this?
>

There are serveral points to make at this point.

1) I have not changed any Linux code based on Solaris or OpenSolaris 
source code, so no copyright issues there.

2) As I understand the numerous documents on the Sun web site, Sun do not 
support sun4c, sun4d or Sun4m so it is posible to argue that copyright is 
not very relevent to the architecture specific elements relating to these 
hardware architectures. They do not exist in OpenSolaris code anyway. 
Lawers may disagree :).

3) What I have been doing for sun4c is to compare what Linux is doing with 
what is going on in the Solaris/SunOS code in order to see if they shead 
light on why verious scenirious in Linux behave badly. So far all I have 
rearly managed to confirm is that the vast magority of the Linux low level 
code for sun4c is functionaly identical to Solaris/SunOS. I have not 
managed to explain why Linux fails in the verious ways it does and the 
Solaris Source code has not helped. I may be wrong but I can't see any 
copyright issues with doing this comparison.

4) There can't be any copyright against writing values into the sun4c MMU 
PTE registers/memory and reading values back to see what they contain. 
With the SunMMU.txt file, all I have done is merge the information from 
Linux source code. and the tests I have done, to provide a document that 
matches what I have found. This has then been checked to see if it is 
consistant with what is indicated in the Solaris code. Where there are 
some grey areas (where code operation is consistant but not identical) I 
have made a note to indicate that what is documented may not be correct 
or may vary from system to system. Is there an issue with this?

Regards
 	Mark.

Re: Sun4c interrupt controller - Sun4d relevance

[David Miller]

From: Chris Newport <crn@netunix.com>
Date: Sun, 12 Aug 2007 20:23:35 +0100

> ISTR that Sun4d was a joint venture with Cray, so some code might
> be encumbered. I have not seen code so I can only guess.

This is most likely the issue.  The XBUS backplane designed jointly
with Cray is almost certainly severely encumbered.

Re: Sun4c interrupt controller - Sun4d relevance

[David Miller]

From: Mark Fortescue <mark@mtfhpc.demon.co.uk>
Date: Sun, 12 Aug 2007 21:58:08 +0100 (BST)

> Lawers may disagree :).

It is a very serious issue.

Even if the specific bits you are examining might be "not care",
there are side effects to contamination on your part in the long
term.

Let's say, for example, that you notice that Solaris does something
clever in their VFS layer while you happen to be scanning around
the sun4c code.  Sun has patented this technique.

Next, you (several months later) add a refinement to the Linux VFS
layer that subconsciously incorporates some of these techniques.

Sun launches legal action against Linux distribution vendors because
of the tainted code.

This is a very obvious example, but much less obvious scenerio's are
possible.  Therefore the only safe course of action is "don't do it".

It is very dangerous to even read the Solaris code, in any form, in
order to prevent from becomming tainted.

The only "safe" way I am aware of to handle this issue is to do clean
room transfer of information.  Which means one person reads the
Solaris code, then writes a document explaining in detail how the chip
is programmed without copying any source code from the Solaris tree
whatsoever.

A second person, reads the document written by the first person,
and then writes the Linux changes solely based upon that document.

The first person is tainted and cannot every be the implementer of
any code on the Linux side.

Mark and others, I've very seriously concerned about this and I think
I need to take the safe course of action and not accept any further
Sparc32 low-level changes from you guys since you have publicly stated
that you've read the Solaris code and thus are tainted already.

Sorry :-(  I really had high hopes for you with the sparc32 port
Mark, but you blew it by taking this legal risk that I want the
sparc32 port to be no part of.

I've spent 10+ years carefully avoiding this thorny legal issue,
and I'm not going to toss that much work down the drain by taking
a risk in this area.

It would have been entirely sufficient to work on and fix lowlevel
bugs by experimentation and also using the BSD sparc32 ports and
drivers as a reference.

Re: Sun4c interrupt controller - Sun4d relevance

[David Miller]

From: "Tom \"spot\" Callaway" <tcallawa@redhat.com>
Date: Sun, 12 Aug 2007 15:27:24 -0400

> I hate to be a bother here, but aren't there some legal concerns with
> looking at Solaris source code, then implementing code in Linux?
> 
> Even on OpenSolaris, there is a grey area as to whether one can legally
> view CDDL licensed code, then reimplement it as GPL (CDDL is
> GPL-Incompatible) for Linux... but on old Solaris, that code should be
> proprietary, unless Sun opened it when I wasn't looking.
> 
> Mark, can you legally be doing this? 

Tom is absolutely right, the situation is questionable at best,
so we have to take the safe course of action and now not accept
contributions from those who have gone so far as to publicly
state that they've read the Solaris code and thus are tainted.

It's unfortunate, but really there is no other reasonable course
of action at this point, sorry :-/

Re: Sun4c interrupt controller - Sun4d relevance

[Chris Newport]

David Miller wrote:

>Tom is absolutely right, the situation is questionable at best,
>so we have to take the safe course of action and now not accept
>contributions from those who have gone so far as to publicly
>state that they've read the Solaris code and thus are tainted.
>
>It's unfortunate, but really there is no other reasonable course
>of action at this point, sorry :-/
>  
>
Whilst I understand your reaction on this one I believe that you are 
being rather harsh on both Mark and Sun.

Would it not be wiser to clarify the conditions under which Sun have  
generously released this information as a reference resource and ask for 
clarification if necessary.

Sun are making great efforts to open up their code and it seems rather 
churlish to imply possible bad faith where none has been shown to exist. 
There can be no harm in asking for clarification and/or permission to 
use this material.