ragge@ludd.luth.se wrote:
>> ragge@ludd.luth.se wrote:
>>     
>>>> I do have other opinions, of course.  Like wtf is pdp10 doing in sys/
>>>> since it can't even build much less boot (and never has been able to do
>>>> either of those), but that's a different issue.
>>>>
>>>>     
>>>>         
>>> Where should it be kept then?   And what is your problem?  I doubt
>>> space in the CVS tree is any concern.
>>>   
>>>       
>> Its the amount of time dealing with things like output from grep, and
>> find, etc.  And, should, for example, we have to sustain MI hacks for
>> this platform, if it can't boot?  I don't think that is the right
>> answer.   I think if a platform is in src, it should have at least one
>> real user, and be able to build and boot to a shell.  Otherwise the code
>> has no value to the _project_.
>>
>>     
> MI hacks for any platform should preferably not exist, but that's 
> another issue.  And if you think grep etc. takes too long time to
> execute I would say that it is a cheap prize to pay to get this support.
>   

No, but sifting thru the _output_ when you're doing a rototill is a
PITA.  The recent work I've done with com(4) and todr are good
examples.  I'm not sure why I bothered to fix pdp10, but I did.

>   
>>> And at least for me it both compiles and boots (up to the point that
>>> the root filesystem should be mounted).
>>>   
>>>       
>> Certainly not with ./build.sh then.   I'm surprised to hear you say it
>> boots, I cleared several panics from inittodr and company the other
>> day.  But then again, this is code that would get called _after_ root is
>> mounted.  If you can't mount a root filesystem, then I would argue you
>> aren't booting.
>>
>>     
> Gcc and the gnu tools don't support this platform and is unlikely to
> ever do in a reasonable manner.  There are a separate toolchain to
> compile the system.  And I don't feel to try to define "boot" :-)
>
> The root file system issue is a challenge though. Finding a way
> to use a 32-bit filesystem on a 36-bit hardware :-)
>   

Frankly, that the challenge exists or not is not interesting to me.  To
me, this problem is one that is either going to be fixed or it isn't. 
If it isn't, then why bother having pdp10 in-tree?

>   
>>> I think it's of benefit of the project to be able to support older
>>> architectures (obviously as opposed to your opinion).  
>>>   
>>>       
>> Do we actually "support" pdp10?   Or is this just still a project in
>> incubation?   If you can't get to a single user shell on any system,
>> then I contend we don't "support" this platform at all.
>>
>>     
> I reference to that probably more than 50% of all archs we have are
> extinct by now, but they are still important.  That is one of the 
> things that splits out NetBSD from all other OSes - the ability to 
> run on any hardware, both new and old.
>   

I think there is good evidence that most of the archs are not extinct. 
da30 is the only such, and we don't support it any longer.   Many of the
archs have software simulators too.  Lack of hardware or simulation
support is not the reason I'm suggesting it be moved out-of-tree.  I'm
suggesting it be moved out of tree because the platform is not
supportable using any 'ordinary and reasonable' approaches -- correct me
if I'm wrong, but its my understanding that no version of NetBSD has
ever booted to a shell prompt on this platform?  What is the use of it then?

> This also have the side effect of forcing the developers to think
> some extra time before implementing something, so that it works on
> all hardware and not just what's on the desks this year.
>   

Think about what?  Machines with non-power-of-two word sizes?  Come on,
36-bit words are a historical mistake, and will never be repeated.  I
think any other portability concern where pdp10 offers something is
equally well reproduced by one of the other ports -- mips, powerpc, heck
-- even vax.  pdp10 in netbsd is a waste of cycles as it stands now.

Even worse, if we have old unmaintained code in the tree, some poor
newbie might start looking at _that_ code (perhaps because it is less
convoluted because it doesn't have to actually _run_?), and make
assumptions about the internal APIs that are just flat wrong.  And, the
rest of us will be none the wiser because we're all ignoring this port,
because it doesn't build with in-tree tools, and doesn't actually boot.

By the way, has the pdp10 external toolchain ever been updated to
support C99 features?  Because if it hasn't, then you won't be able to
build a kernel.  MI code is adopting C99 structure initializations, for
example.

Anyway, I didn't intend to bring this thread up again, so I'm going to
drop it.  But I suggest, rather strongly, that you take a long hard look
at the #ifdef spaghetti and the build infrastructure required to support
each platform before you make the argument that having a port is
"free".  That's a fallacy -- the cost may be cheap, but it is definitely
non-zero.

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191