Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!mips!daver!bungi.com!news From: ian@sibyl.eleceng.ua.oz.au Newsgroups: comp.sys.nsc.32k Subject: Re: various unresolved issues. Message-ID: <9005091636.29536@munnari.oz.au> Date: 9 May 90 15:48:51 GMT References: <<9005071615.AA02112@meepmeep.pcs.com>> Sender: news@daver.bungi.com Lines: 133 Approved: news@daver.bungi.com 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