🚀 go-pugleaf

Jordan K. Hubbard writes:
 > *** On the software front: ***
 > 
 > How's Minix coming along? I can't help but (humorously) remember
 > a certain quote from Bruce in <8912081857.AA01037@hplwbc.HPL.HP.COM>
 > on Fri, 8 Dec 89 10:57:10 pst:
 > 
 > >I would guess that a one weekend effort would get Minix running on the
 > >pc-532.
 > 
 > Ah, the simple naivete of youth! :-) (just kidding Bruce, really!)

Yes. Then there were the estimates of time to port GCC to a TMS340x0
and write an X server. I usually stay quiet when people say such
things because I know *I* couldn't do it in that time! Maybe there
really are people that can code an order of magnitude faster than I,
but more likely they are underestimating the size of the job.
Apparantly the tendency to grossly underestimate the size of a
software task is a recognised failing of the whole profession!

 > I really think it's time that we starting thinking in a more "consortium"
 > like fashion on the Unix front. I realize that many of us have different
 > goals and ideas about which Unix would be "best", but there's still
 > a whole lot of common work that can be shared and ideas that can be exchanged.
 > I, for example, am working on porting 4.3 and am currently going through
 > the painful first steps of getting stand-alone versions of mkfs/fsck and
 > friends working as I proceed towards getting a root file system w/simple
 > stand-alone kernel booted up.

I would be very interested in this. Whilst one still needs a AT&T
licence for BSD, the amount of code which has been freed has been
increased. My guess is that the machine dependent stuff would be under
the freed category (AT&T didn't have anything to do with the BSD VM
system for example). You should still be able to make diffs available
for any files still restricted. What are you using as the starting
point? The Tahoe release?

 > Lest I be accused of being all talk and no action, I'm willing to
 > set up and coordinate all this myself if no one else steps forward. We
 > (software developers) really have quite a massive amount of work ahead of
 > us and could reap significant benefits from each others work, if only
 > someone would take the time to properly coordinate it (having everyone
 > think more in terms of writing "building blocks" rather than quick
 > just-make-it-work hacks would also be a major boon).

I have a major aversion to reinventing wheels. I did a lot of work on
the gnu stuff and lo and behold, it seems that others were also
working on the same thing. (I have been using GCC for a long time on
my ICM, but the gas and binutils work was motivated primarilly by the
pc532).

So, I think we need a list of tasks and who is working on them. The
tasks don't have to be universally agreed. If you want to work on a
foobar that no one else wants, then who are we to say don't? But, at
least register the fact that you are working on foobar just in case
someone else decides to do the same. The list of tasks would, I
expect, have some entries with no one assigned to them and anyone who
feels so motivated might pick up some of these.

 > Are 90% of us just
 > sitting around staring owlishly at our boards, or what? Some of us have
 > had working boards for months ...

I wish I did! Parts supply is a problem here in the backwaters.

Just to kick off, I am happy to continue to maintain (and merge in
anyone elses bug-fixes and enhancements) the ports of the gnu tools.
I don't expect to have a lot of time to devote in the next 5 months
or so (a thesis to be done) but I am interested in getting the GDB
remote debugging support working and added to the ROM monitor. I am
currently hampered by not having a complete board, but that should
cease to be a problem soon.

	Software Task					Workers 	Status
        -------------					-------		------
	GCC Port					     ID	       Working
	GDB Port					     ID	       Working
        GDB Remote debugging support			     ID	   Not started
            GDB has support for remote debugging over
	    a serial line.  It requires some code at
	    the remote end.  The standard GNU
	    distribution only has such code for a 68K.
	    Equivalent code for the 32k needs to be
	    developed.
	GDB Support for Cross Debugging			     *
	    GDB does not support reading symbolic
	    information from little endian
	    executables on a big endian machine. This
	    is desirable in a cross development
	    environment.
	GAS Port					    ID	     Working
	GNU LD and other Binutils Port			    ID	     Working
	GNU AR Cross Development Support		     *
	    AR does not support reading symbolic
	    information from little endian
	    object files on a big endian machine. This
	    is desirable in a cross development
	    environment.
	GNU RANLIB Cross Development Support		     *
	    RANLIB does not support reading symbolic
	    information from little endian
	    object files on a big endian machine. This
	    is desirable in a cross development
	    environment.
	GNU NM Cross Development Support		     *
	    NM does not support reading symbolic
	    information from little endian object
	    files and executables on a big endian
	    machine. This is desirable in a cross
	    development environment.
	GNU STRIP Cross Development Support		    *
	    STRIP does not support reading symbolic
	    information from little endian
	    execuatbles on a big endian machine. This
	    is desirable in a cross development
	    environment.

It would be an ideal thing for emacs outline mode. The organisation
of the above could be improved no doubt. It would probably be good to
have a section for each program or package of interrelated programs
and make the Software Tasks subsection.  Maybe as well as a list of
workers for each task we need a coodinator for each package, but
appointing one might be too bureaucratic.  I'd suggest a key matching
initials with email address at the end of the list.  The '*' is used
to indicate no one has registered that they are working on it. I
think someone *has* done at least some of the cross development stuff
but I am not sure who. The simplest thing is probably to leave
coordination on a single package up to those working on it. If you
maintain such a list at least we will *know* who are working on it. I
would appreciate any changes to the GNU tools (especially if they are
based on my patches, reported back to me).

Ian Dall