jkh@meepmeep.pcs.com (Jordan K. Hubbard) (05/07/90)
I was feeling especially masochistic this weekend and decided to re-read the entire pc532 mailing list archive. It's amazing how many questions I've posted to this group that had already been answered somewhere in the mists of time. Sigh. It's a pity that the "FM" is almost 3 megabytes now or I'd have been more willing to RTFM (but that's still no excuse, I guess). Anyway, that's all off the subject. After reading all those messages, I started wondering about a number of issues that seemed to have slipped between the cracks: *** On the hardware front: *** Ken S. was talking about a DSP board, whatever became of that? Is anyone working on, or planning to work on, a decent intelligent frame buffer card? This seems like it would be a mondo priority. Given that I'm a software type, I'm in the position of having to plead and whine for this stuff and hope that some hardware jock gets irritated enough to knock something out just to shut me up :-). Still, give me the hardware, I'll give you an R4 server. What's the story on the eth532 card? I've seen one message saying that it supports only thin ethernet and another saying that it supports both thin-and-thick. What's the truth, here? G&D: Have you guys done a complete parts cost estimate yet? I want one. *** 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!) 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. This will naturally be the first step for many others as well, regardless of the unix in question. The same commonality will occur with the MMU code, scsi device and terminal drivers, etc etc. If we can manage to stay in close communication (probably via private mailing lists to avoid lots of nitty-specific issues from clogging this list), we can arrange things so as to minimize wheel re-inventing wherever possible. I have already attempted something along these lines with the libso/libc libs I posted recently, though they are certainly no more than a rough start. 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). Are 90% of us just sitting around staring owlishly at our boards, or what? Some of us have had working boards for months and I have yet to see even one program to pong the friggin' lights back and forth! That is a disgrace! :-) Jordan
culberts@hplwbc.hpl.hp.com (Bruce Culbertson) (05/08/90)
> *** 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. Oh well, I knew at the time that was a dumb thing to say. It's always better to do something and then say you did it. However, in my defense... I just spent my second weekend at home since November. The first weekend was consumed getting the monitor to talk to my OMTI SCSI to floppy/ST-506 interface. This was prerequisite to working on Minix. I finally got some time to work on Minix this weekend. Those UART's are a pain in the arse to use -- I wasted a lot of time getting the TTY task working. I got the kernel running (no fs or mm yet) but still have stubs for the SCSI driver and the page manipulation routines. I compiled a few test versions with some hard-wired "user" processes. One test checked out the TTY driver. Another had two processes which passed a token (really a Minix message) back and forth. The current token holder printed a string to the screen and then sent the token back to the other process. Hence, the screen looked like process 1 process 2 process 1 ... That's even less useful than printing pi to 10,000 places, eh? I'm pretty sure I will not get any more time to work on Minix in the next two weeks. But then (here comes another soon-to-be-regretted statement), I expect to see a Minix login after another weekend of work. Bruce
ian@sibyl.eleceng.ua.oz.au (05/09/90)
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